From mohta at necom830.hpcl.titech.ac.jp Tue Sep 1 00:42:18 2015 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 01 Sep 2015 09:42:18 +0900 Subject: PMTUD for IPv4 Multicast - How? In-Reply-To: References: <7184.1441039021@turing-police.cc.vt.edu> <20150831.214943.74737034.sthaug@nethelp.no> Message-ID: <55E4F46A.7070907@necom830.hpcl.titech.ac.jp> William Herrin wrote: > It'd make more sense to truncate the > packet, set a flag, and then let layer 4 at the recipient deal with > negotiating a new size with the sender. For routers, truncating the packet and setting a flag is as burdensome as fragmentation or ICMP generation. Moreover, just with plain fragmentation enabled IPv4 packets, layer 4 can deal similarly. > You know, end to end principle and all. PMTUD requires "knowledge and help" (quote from the end to end argument) of all the intermediate routers. That is, you apply the end to end argument completely wrongly. > That'd eliminate the problems with firewall-blocked protocols > and routers using private IP addresses, the usual culprits for pmtud > breakage. With your approach, you will find firewalls dropping truncated packets. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Sep 1 00:49:47 2015 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 01 Sep 2015 09:49:47 +0900 Subject: PMTUD for IPv4 Multicast - How? In-Reply-To: References: <7184.1441039021@turing-police.cc.vt.edu> <55E4C450.7070004@necom830.hpcl.titech.ac.jp> Message-ID: <55E4F62B.6060300@necom830.hpcl.titech.ac.jp> William Herrin wrote: >> for routers, generating ICMP PTB is as burdensome >> as generating fragments? > > No, it isn't. Yes, it is. Generating an ICMP PTB @aclet?is as burdensome as fragmenting?a packet. > When a router fragments a packet, it has to fragment the next and the > next and the next. Maybe tens or hundreds of thousands of packets > before the end of that one user's session. Not necessarily, because transport layer can react against fragmented packets. > When a router generates a PTB, there is no next. PTB is a soft > failure. The origin must correct the error (by reducing packet size) What if, the origin does not reduce packet size? Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Sep 1 00:55:06 2015 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 01 Sep 2015 09:55:06 +0900 Subject: PMTUD for IPv4 Multicast - How? In-Reply-To: References: <7184.1441039021@turing-police.cc.vt.edu> <55E4C450.7070004@necom830.hpcl.titech.ac.jp> Message-ID: <55E4F76A.4040703@necom830.hpcl.titech.ac.jp> Chris Marget wrote: >>> I'll probably come around, but I've not yet concluded that "screw it, >>> fragment my traffic, I don't care" is the stance that a conscientious >>> application should be taking. >> >> Don't you care, for routers, generating ICMP PTB is as burdensome >> as generating fragments? > > I don't think so. If PMTUD is working (big IF, I know), Yup. > the ICMP PTB > generation is a one-time thing (or once per 10 minutes or whatever) A meaningful interval of retry is not 10 minutes but RTT measured at layer 4 or above. > Is the concern that I might DDoS myself Or, with spoofed source addresses, someone else. Masataka Ohta From jfmezei_nanog at vaxination.ca Tue Sep 1 01:00:20 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 31 Aug 2015 21:00:20 -0400 Subject: Zero rating implentation strategies Message-ID: <55E4F8A4.5090802@vaxination.ca> Last year, one large mobile operator in Canada started to zero-rate its own mobile TV offering. It appears that routers kept counting all the data, but that the company then subtracted usage generated by its video servers to come up with billable Gigabytes for each user. (This was quashed by the regulator in Canada) In the last week, another mobile operator announced it was zero rating approved music streaming services (Spotify, Google Play and a few others). If you are dealing with "foreign" content that comes from servers you don't control, what are the "best practices" to zero-rate content from multiple outside sources ? To make matters more interesting, the FAQ for that service indicates that if you listen to a music stream that exceeds 128kbps, you MAY be charged for the data, and that you will be charged to listen to videos that could be offered by that service, and for non streaming data such as album covers, list of songs etc. Would this point to specific IPs (streaming servers for low quality 128kbps sound) ? How scalable is this when you start to have a whole bunch of source IPs whose traffic is to be zero rated ? Or would another way of doing this to setup private routes into the ISP's network for each approved service, so the data would enter through a different interface and be counted separately ? Or, and this is my most important question: Is it possible with current networking software to zero rate any data flow that is less than a certain value (eg: 128kbs) ? Or would current software require network operator to get 5 minute usage for each user and only bill if average data rate during last 5 minutes exceeded 128kbps ? (which means that your music is billed if you also listen to netflix at same time since total data flows are greater than 128kbps) Of note: not all customers get this treatment, only those with higher end packages. Those with lower end packages are charged for usage by those very same services. And for the record, this isn't to setup a similar system, it is to better understand the issue for a regulatory challenge. From marka at isc.org Tue Sep 1 01:05:33 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 01 Sep 2015 11:05:33 +1000 Subject: PMTUD for IPv4 Multicast - How? In-Reply-To: Your message of "Tue, 01 Sep 2015 09:49:47 +0900." <55E4F62B.6060300@necom830.hpcl.titech.ac.jp> References: <7184.1441039021@turing-police.cc.vt.edu> <55E4C450.7070004@necom830.hpcl.titech.ac.jp> <55E4F62B.6060300@necom830.hpcl.titech.ac.jp> Message-ID: <20150901010533.6795D3687524@rock.dv.isc.org> In message <55E4F62B.6060300 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > William Herrin wrote: > > >> for routers, generating ICMP PTB is as burdensome > >> as generating fragments? > > > > No, it isn't. > > Yes, it is. Generating an ICMP PTB is as burdensome as > fragmenting a packet. Well it could be done at wire speed. It just requires more complicated hardware. Routers usually punt it to the cpu but there is no real reason that they have to do that. There is no theoretical reason why it has to be more burdensome than forwarding a packet. It's a implementation choice. > > When a router fragments a packet, it has to fragment the next and the > > next and the next. Maybe tens or hundreds of thousands of packets > > before the end of that one user's session. > > Not necessarily, because transport layer can react against fragmented > packets. > > > When a router generates a PTB, there is no next. PTB is a soft > > failure. The origin must correct the error (by reducing packet size) > > What if, the origin does not reduce packet size? The communiction fails. Additionally routers normally rate limit PTB generation thereby reducing cpu loads to a acceptable level which is the whole point of moving the fragmentation to the originating node. > Masataka Ohta > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mohta at necom830.hpcl.titech.ac.jp Tue Sep 1 01:21:23 2015 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 01 Sep 2015 10:21:23 +0900 Subject: PMTUD for IPv4 Multicast - How? In-Reply-To: <20150901010533.6795D3687524@rock.dv.isc.org> References: <7184.1441039021@turing-police.cc.vt.edu> <55E4C450.7070004@necom830.hpcl.titech.ac.jp> <55E4F62B.6060300@necom830.hpcl.titech.ac.jp> <20150901010533.6795D3687524@rock.dv.isc.org> Message-ID: <55E4FD93.5060304@necom830.hpcl.titech.ac.jp> Mark Andrews wrote: >> Yes, it is. Generating an ICMP PTB is as burdensome as >> fragmenting a packet. > > Well it could be done at wire speed. Both of them could be. > There is no theoretical reason > why it has to be more burdensome than forwarding a packet. That's not my point. > The communiction fails. It depends on layer 4 and above. > Additionally routers normally rate limit > PTB generation thereby reducing cpu loads to a acceptable level > which is the whole point of moving the fragmentation to the originating > node. Routers can rate limit fragment generation, too. Masataka Ohta From chris at marget.com Tue Sep 1 03:47:41 2015 From: chris at marget.com (Chris Marget) Date: Mon, 31 Aug 2015 23:47:41 -0400 Subject: PMTUD for IPv4 Multicast - How? In-Reply-To: <55E4F76A.4040703@necom830.hpcl.titech.ac.jp> References: <7184.1441039021@turing-police.cc.vt.edu> <55E4C450.7070004@necom830.hpcl.titech.ac.jp> <55E4F76A.4040703@necom830.hpcl.titech.ac.jp> Message-ID: On Mon, Aug 31, 2015 at 8:55 PM, Masataka Ohta wrote: > Chris Marget wrote: >>>> I'll probably come around, but I've not yet concluded that "screw it, >>>> fragment my traffic, I don't care" is the stance that a conscientious >>>> application should be taking. >>> >>> Don't you care, for routers, generating ICMP PTB is as burdensome >>> as generating fragments? >> >> I don't think so. If PMTUD is working (big IF, I know), > > Yup. > >> the ICMP PTB >> generation is a one-time thing (or once per 10 minutes or whatever) > > A meaningful interval of retry is not 10 minutes but RTT measured > at layer 4 or above. I took the 10 minute value from RFC1191's recommendation about when it's appropriate to try larger MTU sizes. One ICMP message should hold the sender off for 10 minutes (or whatever), just like it does with unicast traffic. Would you explain why a router might need to generate ICMP PTB at a rate corresponding to intervals of RTT? I don't see why the error rate would be correlated with path length. Anyway, RTT isn't something that necessarily exists with multicast applications. >> Is the concern that I might DDoS myself > > Or, with spoofed source addresses, someone else. The latter concern isn't unique to this case and applies to many (most? all?) types of reflection attacks. Indeed, many other protocols have disabled potentially useful features in order to thwart reflection attacks which rely on spoofed source addresses. At least in the case of those protocols, we have the choice to enable monlist, ip_respond_to_echo_broadcast or whatever as appropriate for the environment. I'm still not sure where this leaves the application which wants to do the right thing. - Send 1500 byte frames and expect fragmentation? - Guess at the least of all likely path MTUs? - Send 576 byte frames? - Build a feedback mechanism into the application? From ramy.ihashish at gmail.com Tue Sep 1 12:49:45 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Tue, 1 Sep 2015 15:49:45 +0300 Subject: DDoS appliances reviews needed Message-ID: And at the end of the day it's commercial, vendors pay, I don't trust much. I am looking for hands-on experience.... Ramy > > Message: 8 > Date: Thu, 27 Aug 2015 16:00:10 +0000 > From: Steve Mikulasik > To: "nanog at nanog.org" > Subject: RE: DDoS appliances reviews needed > Message-ID: > < > BY1PR0701MB1781D116ED99F67358E79877FA6F0 at BY1PR0701MB1781.namprd07.prod.outlook.com > > > > Content-Type: text/plain; charset=UTF-8 > > I assume they don't list their testing methodology right? It always feels > like they just read vendor spec sheets. > > Steve Mikulasik > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joe Chisolm > Sent: Thursday, August 27, 2015 9:53 AM > To: nanog at nanog.org > Subject: Re: DDoS appliances reviews needed > > Gartner did a report about a year ago. Not free. > https://www.gartner.com/doc/2910217/ddos-comparison-defense-approaches > > On 08/26/2015 07:40 AM, Ramy Hashish wrote: > > Good day all, > > > > Anybody here has experienced a PoC for any anti DDoS appliance, or > > already using a anti DDoS appliance in production and able to share > > his user experience/review? > > > > We need to collect good reviews from people whom got their hands dirty > > with the configuration/attack mitigation, real experience. > > > > Thanks, > > > > Ramy > > > > -- > Joe Chisolm > Computer Translations, Inc. > Network and Datacenter Consulting > Marble Falls, Tx. > 830-265-8018 > > Public Key Available at http://www.sks-keyservers.net > > > > From mkamal at noor.net Tue Sep 1 12:51:27 2015 From: mkamal at noor.net (Mohamed Kamal) Date: Tue, 1 Sep 2015 14:51:27 +0200 Subject: BGP advertise-best-external on RR In-Reply-To: References: <55DB6B81.60908@noor.net> <2411BC56-6BAC-433F-B96E-7761C021774A@gmail.com> <55DB7127.20308@noor.net> Message-ID: <55E59F4F.8010704@noor.net> Hi, Diverse-path will only send the second best path, and in my case I have three routes not two. In addition to that, every PE will have to peer with the RR via a second session (on the same RR, as I will not deploy a new standalone shadow RR) and this will increase the BGP sessions to the double. Add-path will have a network-wide IOS upgrade for this BGP capability to be supported which is not viable now. So, is there any other recommendation other than the internet VRF with different RDs solution? Regards, Mohamed Kamal Core Network Sr. Engineer On 8/25/2015 11:37 AM, Jeff Tantsura wrote: > Hi, > > In your case I?d recommend to use diverse path, due to its simplicity and > non disruptive deployment characteristics. > As you know - diverse path requires additional BGP session per additional > (second, next, etc) path, in most cases not a problem, however mileage > might vary. > > To my memory, in Cisco land - it has only been implemented in IOS, not XR, > please check. > > Cheers, > Jeff > > > > > -----Original Message----- > From: Diptanshu Singh > Date: Monday, August 24, 2015 at 10:53 PM > To: Mohamed Kamal > Cc: "nanog at nanog.org" > Subject: Re: BGP advertise-best-external on RR > >> Yes . In the case of diverse path , shadow route reflector will be the >> one wherever you enable commands to trigger diverse path computation. >> >> Good thing with diverse path is that the RR-Clients don't have to have >> any support but bad thing is that it can only reflect One additional >> best-path( second best path ) . >> >> Sent from my iPhone >> >>> On Aug 24, 2015, at 2:31 PM, Mohamed Kamal wrote: >>> >>> It's only supported on the 15.2(4)S and later not the SRE train. I >>> might consider an upgrade. >>> >>> One more question regarding this, can you configure the RR to be the >>> main and shadow RR? >>> >>> Mohamed Kamal >>> Core Network Sr. Engineer >>> >>>> On 8/24/2015 9:16 PM, Diptanshu Singh wrote: >>>> BGP Add-Path might be your friend . You can look at diverse-path as >>>> well . > From sergevautour at yahoo.ca Tue Sep 1 15:33:42 2015 From: sergevautour at yahoo.ca (Serge Vautour) Date: Tue, 1 Sep 2015 08:33:42 -0700 Subject: NetFlow - path from Routers to Collector Message-ID: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> Hello, For those than run Internet connected routers, how do you get your NetFlow data from the routers to your collectors? Do you let the flow export traffic use the same links as your customer traffic to route back to central collectors? Or do you send this traffic over private network management type path? If you send this traffic over the "Internet" (within your AS), are you worried about security? Thanks, Serge From rdobbins at arbor.net Tue Sep 1 15:38:51 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 01 Sep 2015 22:38:51 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> Message-ID: On 1 Sep 2015, at 22:33, Serge Vautour wrote: > Or do you send this traffic over private network management type path? This is how to do it. So in case of a network partition event, you don't end up losing visibility into your network traffic when you need it the most. You should already have an OOB/DCN network for managing your routers/switches/hosts, no? Use that, after ensuring its scaled adequately. ----------------------------------- Roland Dobbins From mark.tinka at seacom.mu Tue Sep 1 15:39:04 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 1 Sep 2015 17:39:04 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> Message-ID: <55E5C698.3060100@seacom.mu> On 1/Sep/15 17:33, Serge Vautour wrote: > Hello, > > For those than run Internet connected routers, how do you get your NetFlow data from the routers to your collectors? Do you let the flow export traffic use the same links as your customer traffic to route back to central collectors? Or do you send this traffic over private network management type path? If you send this traffic over the "Internet" (within your AS), are you worried about security? We forward it in-band. Have been doing so for years, no major drama. Mark. From rdobbins at arbor.net Tue Sep 1 15:43:59 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 01 Sep 2015 22:43:59 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E5C698.3060100@seacom.mu> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> Message-ID: <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> On 1 Sep 2015, at 22:39, Mark Tinka wrote: > Have been doing so for years, no major drama. Until there is. ;> ----------------------------------- Roland Dobbins From Rod.Beck at hibernianetworks.com Tue Sep 1 15:59:14 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Tue, 1 Sep 2015 15:59:14 +0000 Subject: NetFlow - path from Routers to Collector In-Reply-To: <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu>, <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> Message-ID: Roland is correct. With the caveat that your Internet customer traffic may flow over the fibers as your separate management circuits. You should aim for end to end physical diversity. This is all common sense, but laziness some times takes precedence. Roderick Beck Sales - Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York 36-30-859-5144 rod.beck at hibernianetworks.com ________________________________________ From: NANOG on behalf of Roland Dobbins Sent: Tuesday, September 1, 2015 5:43 PM To: nanog at nanog.org Subject: Re: NetFlow - path from Routers to Collector On 1 Sep 2015, at 22:39, Mark Tinka wrote: > Have been doing so for years, no major drama. Until there is. ;> ----------------------------------- Roland Dobbins This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From shane at ronan-online.com Tue Sep 1 16:02:07 2015 From: shane at ronan-online.com (Shane Ronan) Date: Tue, 1 Sep 2015 12:02:07 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> Message-ID: It's usually not laziness, it's most often related to cost. On Sep 1, 2015 12:00 PM, "Rod Beck" wrote: > Roland is correct. With the caveat that your Internet customer traffic may > flow over the fibers as your separate management circuits. You should aim > for end to end physical diversity. This is all common sense, but laziness > some times takes precedence. > > > > Roderick Beck > Sales - Europe and the Americas > Hibernia Networks > http://www.hibernianetworks.com > Budapest and New York > 36-30-859-5144 > rod.beck at hibernianetworks.com > > ________________________________________ > From: NANOG on behalf of Roland Dobbins < > rdobbins at arbor.net> > Sent: Tuesday, September 1, 2015 5:43 PM > To: nanog at nanog.org > Subject: Re: NetFlow - path from Routers to Collector > > On 1 Sep 2015, at 22:39, Mark Tinka wrote: > > > Have been doing so for years, no major drama. > > Until there is. > > ;> > > ----------------------------------- > Roland Dobbins > This e-mail and any attachments thereto is intended only for use by the > addressee(s) named herein and may be proprietary and/or legally privileged. > If you are not the intended recipient of this e-mail, you are hereby > notified that any dissemination, distribution or copying of this email, and > any attachments thereto, without the prior written permission of the sender > is strictly prohibited. If you receive this e-mail in error, please > immediately telephone or e-mail the sender and permanently delete the > original copy and any copy of this e-mail, and any printout thereof. All > documents, contracts or agreements referred or attached to this e-mail are > SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may > contain software viruses that could damage your own computer system. While > Hibernia Networks has taken every reasonable precaution to minimize this > risk, we cannot accept liability for any damage that you sustain as a > result of software viruses. You should carry out your own virus checks > before opening any attachment. > From job at instituut.net Tue Sep 1 16:10:42 2015 From: job at instituut.net (Job Snijders) Date: Tue, 1 Sep 2015 18:10:42 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> Message-ID: <20150901161042.GD1025@Vurt.local> On Tue, Sep 01, 2015 at 08:33:42AM -0700, Serge Vautour wrote: > For those than run Internet connected routers, how do you get your > NetFlow data from the routers to your collectors? Do you let the flow > export traffic use the same links as your customer traffic to route > back to central collectors? Or do you send this traffic over private > network management type path? If you send this traffic over the > "Internet" (within your AS), are you worried about security? To answer your first question: i see no issue in transporting flow export traffic over the same backbone used to serve customer traffic. Not entirely security related, but a neat trick is to use a tool like 'samplicator' to distribute the UDP packets to all applications of interest. You'll find that on many router platforms you can only configure a limited amount of netflow/sflow collectors, often less then the amount of applications that need the data for dissemination. Especially if you have multiple independent instances of the application for redundancy purposes! And, keep in mind, you can anycast the instances of 'samplicator' in your network :-) https://github.com/sleinen/samplicator Kind regards, Job From rdobbins at arbor.net Tue Sep 1 16:14:28 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 01 Sep 2015 23:14:28 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150901161042.GD1025@Vurt.local> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> Message-ID: <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> On 1 Sep 2015, at 23:10, Job Snijders wrote: > To answer your first question: i see no issue in transporting flow > export traffic over the same backbone used to serve customer traffic. This is not good advice, for the reasons I stated previously in this thread. ----------------------------------- Roland Dobbins From chkuhtz at microsoft.com Tue Sep 1 16:36:13 2015 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Tue, 1 Sep 2015 16:36:13 +0000 Subject: Zero rating implentation strategies In-Reply-To: <55E4F8A4.5090802@vaxination.ca> References: <55E4F8A4.5090802@vaxination.ca> Message-ID: <0FEF8847-0B58-4D61-84D5-95B57DF42581@microsoft.com> Zero rating is not a new concept. It has existed in the mobile world since the days of the dumb phone. Got a reference to why this was killed by the regulator in Canada? Mobile networks typically use their packet core (and prior iterations of the same termination, rating, billing, management gear) to rate and bill specific to each subscriber. It is done with voice minutes, text, data. Whether or not you consider the solutions scalable is up to one's individual judgement. But this zero rating billing model has and is very widely deployed and at massive scale. In fact, there are specific interfaces defined for just these purposes in the applicable standards. There are many many conceivable ways in which billing mediation and associated infrastructure for zero rating can and is implemented. This is not new and is very well understood in the mobile industry. Not sure what you're after here. Best regards, Christian > On Aug 31, 2015, at 6:01 PM, Jean-Francois Mezei wrote: > > > Last year, one large mobile operator in Canada started to zero-rate its > own mobile TV offering. It appears that routers kept counting all the > data, but that the company then subtracted usage generated by its video > servers to come up with billable Gigabytes for each user. > > (This was quashed by the regulator in Canada) > > In the last week, another mobile operator announced it was zero rating > approved music streaming services (Spotify, Google Play and a few others). > > If you are dealing with "foreign" content that comes from servers you > don't control, what are the "best practices" to zero-rate content from > multiple outside sources ? > > To make matters more interesting, the FAQ for that service indicates > that if you listen to a music stream that exceeds 128kbps, you MAY be > charged for the data, and that you will be charged to listen to videos > that could be offered by that service, and for non streaming data such > as album covers, list of songs etc. > > Would this point to specific IPs (streaming servers for low quality > 128kbps sound) ? How scalable is this when you start to have a whole > bunch of source IPs whose traffic is to be zero rated ? > > Or would another way of doing this to setup private routes into the > ISP's network for each approved service, so the data would enter through > a different interface and be counted separately ? > > Or, and this is my most important question: Is it possible with current > networking software to zero rate any data flow that is less than a > certain value (eg: 128kbs) ? > > Or would current software require network operator to get 5 minute usage > for each user and only bill if average data rate during last 5 minutes > exceeded 128kbps ? (which means that your music is billed if you also > listen to netflix at same time since total data flows are greater than > 128kbps) > > > Of note: not all customers get this treatment, only those with higher > end packages. Those with lower end packages are charged for usage by > those very same services. > > And for the record, this isn't to setup a similar system, it is to > better understand the issue for a regulatory challenge. From smeuse at mara.org Tue Sep 1 17:08:08 2015 From: smeuse at mara.org (Steve Meuse) Date: Tue, 1 Sep 2015 13:08:08 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> Message-ID: On Tue, Sep 1, 2015 at 12:14 PM, Roland Dobbins wrote: > On 1 Sep 2015, at 23:10, Job Snijders wrote: > > > To answer your first question: i see no issue in transporting flow > > export traffic over the same backbone used to serve customer traffic. > > This is not good advice, for the reasons I stated previously in this > thread. Your advice is not "one size fits all". I've done netflow over production links for two very large backbone networks. Over the combined 17(?) years, never saw a problem. If your network is likely to be partitioned by a small number of failures, that might be a different case, but you can't make blanket statements. -Steve From rdobbins at arbor.net Tue Sep 1 17:12:27 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 00:12:27 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> Message-ID: <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> On 2 Sep 2015, at 0:08, Steve Meuse wrote: > Your advice is not "one size fits all". Actually, it is. Large backbone networks have DCNs/OOBs, and that's where they export their NDE. > I've done netflow over production links for two very large backbone > networks. Did you manage your routers and switches and hosts and so forth in-band, too? > Over the combined 17(?) years, never saw a problem. Until you do. Running flow telemetry in-band is penny-wise and pound-foolish, for networks of any size, in any circumstances. All management-plane traffic (and that's what flow telemetry is) should be segregated from the production network data plane. ----------------------------------- Roland Dobbins From jfmezei_nanog at vaxination.ca Tue Sep 1 17:12:58 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 01 Sep 2015 13:12:58 -0400 Subject: Zero rating implentation strategies In-Reply-To: <0FEF8847-0B58-4D61-84D5-95B57DF42581@microsoft.com> References: <55E4F8A4.5090802@vaxination.ca> <0FEF8847-0B58-4D61-84D5-95B57DF42581@microsoft.com> Message-ID: <55E5DC9A.5050108@vaxination.ca> On 15-09-01 12:36, Christian Kuhtz wrote: > Zero rating is not a new concept. It has existed in the mobile world since the days of the dumb phone. Yes, but is now in a different scale and when you start to zero rate content that comes from CDN (aka: many IPs which may also serve non zero rated content). > Got a reference to why this was killed by the regulator in Canada? Bell Mobility zero rating its own MobileTV offering was decided in January 2015 by CRTC: http://www.crtc.gc.ca/eng/archive/2015/2015-26.htm ## The Commission finds that Bell Mobility Inc. (Bell Mobility) and Quebecor Media Inc., Videotron Ltd. and Videotron G.P. (collectively, Videotron), violated subsection 27(2) of the Telecommunications Act by exempting their mobile TV services Bell Mobile TV and illico.tv from data charges. Subsection 27(2) prohibits Canadian carriers from conferring an undue disadvantage to others, or an undue preference to itself or others. ## > Mobile networks typically use their packet core (and prior iterations of the same termination, rating, billing, management gear) to rate and bill specific to each subscriber. It is done with voice minutes, text, data. Whether or not you consider the solutions scalable is up to one's individual judgement. But this zero rating billing model has and is very widely deployed and at massive scale. In fact, there are specific interfaces defined for just these purposes in the applicable standards. There are many many conceivable ways in which billing mediation and associated infrastructure for zero rating can and is implemented. This is not new and is very well understood in the mobile industry. > >Not sure what you're after here. What I am after is what sort of logic is used to determine whether a packet is to be counted towards total monthly usage or not. Is it based on sourse IP address ? DPI equipment looking at content ? And more importantly, if it is possible to zero rate any flow that is below a certain speed. (whether from a radio station or some heart monitor). From shane at ronan-online.com Tue Sep 1 17:18:17 2015 From: shane at ronan-online.com (Shane Ronan) Date: Tue, 01 Sep 2015 13:18:17 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> Message-ID: <55E5DDD9.70502@ronan-online.com> Roland, While your way may be best practice, sometimes real life gets in the way of best practice. Shane On 9/1/15 1:12 PM, Roland Dobbins wrote: > > On 2 Sep 2015, at 0:08, Steve Meuse wrote: > >> Your advice is not "one size fits all". > > Actually, it is. > > Large backbone networks have DCNs/OOBs, and that's where they export > their NDE. > >> I've done netflow over production links for two very large backbone >> networks. > Did you manage your routers and switches and hosts and so forth > in-band, too? > >> Over the combined 17(?) years, never saw a problem. > > Until you do. > > Running flow telemetry in-band is penny-wise and pound-foolish, for > networks of any size, in any circumstances. All management-plane > traffic (and that's what flow telemetry is) should be segregated from > the production network data plane. > > > ----------------------------------- > Roland Dobbins From niels=nanog at bakker.net Tue Sep 1 17:18:51 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 1 Sep 2015 19:18:51 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> Message-ID: <20150901171851.GD4116@excession.tpb.net> * rdobbins at arbor.net (Roland Dobbins) [Tue 01 Sep 2015, 19:13 CEST]: >Running flow telemetry in-band is penny-wise and pound-foolish, for >networks of any size, in any circumstances. You're just wrong here. -- Niels. From rdobbins at arbor.net Tue Sep 1 17:29:25 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 00:29:25 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150901171851.GD4116@excession.tpb.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> Message-ID: On 2 Sep 2015, at 0:18, Niels Bakker wrote: > You're just wrong here. Sorry, I'm not. I've seen what happens when flow telemetry is 'squeezed out' by pipe-filling DDoS attacks, interrupted by fat-fingers, etc. It'll happen to you, one day. And then you'll understand. ----------------------------------- Roland Dobbins From shane at ronan-online.com Tue Sep 1 17:32:04 2015 From: shane at ronan-online.com (Shane Ronan) Date: Tue, 01 Sep 2015 13:32:04 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> Message-ID: <55E5E114.2030905@ronan-online.com> So in your world, the money always exists for a separate flow telemetry network? On 9/1/15 1:29 PM, Roland Dobbins wrote: > On 2 Sep 2015, at 0:18, Niels Bakker wrote: > >> You're just wrong here. > > Sorry, I'm not. I've seen what happens when flow telemetry is > 'squeezed out' by pipe-filling DDoS attacks, interrupted by > fat-fingers, etc. > > It'll happen to you, one day. And then you'll understand. > > ----------------------------------- > Roland Dobbins From chkuhtz at microsoft.com Tue Sep 1 17:35:52 2015 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Tue, 1 Sep 2015 17:35:52 +0000 Subject: Zero rating implentation strategies In-Reply-To: <55E5DC9A.5050108@vaxination.ca> References: <55E4F8A4.5090802@vaxination.ca> <0FEF8847-0B58-4D61-84D5-95B57DF42581@microsoft.com>, <55E5DC9A.5050108@vaxination.ca> Message-ID: Inline.. On Sep 1, 2015, at 10:13 AM, Jean-Francois Mezei > wrote: On 15-09-01 12:36, Christian Kuhtz wrote: Zero rating is not a new concept. It has existed in the mobile world since the days of the dumb phone. Yes, but is now in a different scale and when you start to zero rate content that comes from CDN (aka: many IPs which may also serve non zero rated content). I don't agree with that assertion. Not a new concept. I worked on stuff like that over a decade ago, with multiple CDN providers. Wasn't even mobile, it was for DSL. There are scaling issues if the idea was out of touch with how interwebs actually work. Only in those cases might it have technically worked but priced itself out of reality. But there wasn't anything fundamentally to say it couldn't be done. CDN's have for a very long time had ways to implement custom mappings and tweak their algorithms to source specific content to a specific subscriber in a very specific way or place source nodes in particular locations (logically or physically). They only varied in their ability or willingness to do so on terms that might seem reasonable to a given partner (which generally means you either do or don't come to terms on contracts). It wasn't a fundamental technical barrier even 10-15 yrs ago. Got a reference to why this was killed by the regulator in Canada? Bell Mobility zero rating its own MobileTV offering was decided in January 2015 by CRTC: Thank you. The key here appears to be this: Subsection 27(2) prohibits Canadian carriers from conferring an undue disadvantage to others, or an undue preference to itself or others. So this appears to be about distorting the competition between their own services and third parties rather than about zero rating per se. Mobile networks typically use their packet core (and prior iterations of the same termination, rating, billing, management gear) to rate and bill specific to each subscriber. It is done with voice minutes, text, data. Whether or not you consider the solutions scalable is up to one's individual judgement. But this zero rating billing model has and is very widely deployed and at massive scale. In fact, there are specific interfaces defined for just these purposes in the applicable standards. There are many many conceivable ways in which billing mediation and associated infrastructure for zero rating can and is implemented. This is not new and is very well understood in the mobile industry. Not sure what you're after here. What I am after is what sort of logic is used to determine whether a packet is to be counted towards total monthly usage or not. Is it based on sourse IP address ? DPI equipment looking at content ? And more importantly, if it is possible to zero rate any flow that is below a certain speed. (whether from a radio station or some heart monitor). All of the above and more. Depends on content. For example, if you obtain the knowledge of origin and subscriber, you have what is needed. Origin should not be constrained to origin in terms of IP address space or port numbers. It can be marked in the protocol header, content, sourced from specific interfaces etc etc. The ways are pretty endless and the gear is readily available. There is an entire cottage industry peddling this stuff from sourcing, detection through rating and billing in addition to the major equipment vendors. There are no inherent limits. You can do it with or without DPI. You can do it with or without subscriber management systems (like BRAS). You can do it with or without knowledge of source or destination IP addresses. You can do it with any kind of content. You can do it with or without flow awareness. You can do it with or without special protocol semantics. What is capable is (as always) up to the engineering clue, business savvy and business model supporting the implementation. And I really mean anything can, has, and will be brought to life at scale given a suitable business cause. I don't mean to be obnoxious. The question is a bit like asking if interwebs have limits ;-).. Yes, there are stupid ways to screw things up, but there is a huge variety of ways to make it work and make money doing it. And without pissing off regulators. There is no red flag from a regulatory perspective based on the technology itself in my opinion. Hope this helps. Best regards, Christian From rdobbins at arbor.net Tue Sep 1 17:36:44 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 00:36:44 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E5E114.2030905@ronan-online.com> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> Message-ID: <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> On 2 Sep 2015, at 0:32, Shane Ronan wrote: > So in your world, the money always exists for a separate flow > telemetry network? It should've already been spent for an OOB/DCN network, which should've been provisioned with flow telemetry in mind. ----------------------------------- Roland Dobbins From jared at puck.Nether.net Tue Sep 1 17:44:06 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 1 Sep 2015 13:44:06 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E5E114.2030905@ronan-online.com> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> Message-ID: <20150901174406.GB28155@puck.nether.net> I think the key here is that Roland isn't often constrained by these financial considerations. I would respectfully disagree with Roland here and agree with Job, Niels, etc. A few networks have robust out of band networks, but most I've seen have an interesting mixture of things and inband is usually the best method. Those that do have "seperate" networks may actually be CoC services from another deparment in the same company riding the same P/PE devices (sometimes routers). I've seen oob networks on DSL, datacenter wifi or cable swaps through the fence to an adjacent rack. An oob network need not be high bandwidth enough to do netflow sampling, this is well regarded as a waste of money by many as the costs for these can often be orders of magnitude more compared to a pure-IP or internet service. I'll say this ranks up there with people who think MPLS VPN == Encryption. It's not unless you think a few byte label is going to confuse people. - Jared On Tue, Sep 01, 2015 at 01:32:04PM -0400, Shane Ronan wrote: > So in your world, the money always exists for a separate flow telemetry > network? > > On 9/1/15 1:29 PM, Roland Dobbins wrote: > > On 2 Sep 2015, at 0:18, Niels Bakker wrote: > > > >> You're just wrong here. > > > > Sorry, I'm not. I've seen what happens when flow telemetry is > > 'squeezed out' by pipe-filling DDoS attacks, interrupted by > > fat-fingers, etc. > > > > It'll happen to you, one day. And then you'll understand. > > > > ----------------------------------- > > Roland Dobbins -- 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 niels=nanog at bakker.net Tue Sep 1 17:46:51 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 1 Sep 2015 19:46:51 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> Message-ID: <20150901174651.GE4116@excession.tpb.net> * rdobbins at arbor.net (Roland Dobbins) [Tue 01 Sep 2015, 19:30 CEST]: >On 2 Sep 2015, at 0:18, Niels Bakker wrote: > >>You're just wrong here. > >Sorry, I'm not. I've seen what happens when flow telemetry is >'squeezed out' by pipe-filling DDoS attacks, interrupted by >fat-fingers, etc. This is the dumbest thing I've read on this mailing list in a while. (On the other hand, I don't read most threads.) >It'll happen to you, one day. And then you'll understand. Who is saying I haven't done all of the above already? -- Niels. From jfmezei_nanog at vaxination.ca Tue Sep 1 17:47:50 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 01 Sep 2015 13:47:50 -0400 Subject: Zero rating implentation strategies In-Reply-To: References: <55E4F8A4.5090802@vaxination.ca> <0FEF8847-0B58-4D61-84D5-95B57DF42581@microsoft.com>, <55E5DC9A.5050108@vaxination.ca> Message-ID: <55E5E4C6.1020707@vaxination.ca> On 15-09-01 13:35, Christian Kuhtz wrote: > There is no red flag from a regulatory perspective based on the technology itself in my opinion. There are other sections in the Canadian Telecommunicatiosn Act about controlling content. And there was a reference to the supreme court on whether ISPs were liable for content that their deliver to customers, which found that an ISP that blindly delivers packets doesn't control content and therefore is not responsible for it. So depending on how the zero rating is implemented, this may (or may not) have implications. What I am trying to do is to build a list of realistic techniques (aka: what industry actually uses) which should force Vid?otron to fees up to which one it uses. From freedman at freedman.net Tue Sep 1 17:55:47 2015 From: freedman at freedman.net (Avi Freedman) Date: Tue, 1 Sep 2015 13:55:47 -0400 (EDT) Subject: NetFlow - path from Routers to Collector Message-ID: <20150901175547.35F4A550C59C7@freedman.net> Looking at probably 100 networks' flow paths over the last year, I'd say 1 or 2 have OOB for flow. Maybe another 10-20 have interest in taking simpler time series data of top talkers over their OOB networks, but not the flow itself. Agree w Roland that it can cause problems with telemetry if there are big network misconfigs. But for folks seeing DDoS, we implement rate-limiting of the flows/sec via local proxies to avoid overwhelming network capacity with the flow data... Avi > I think the key here is that Roland isn't often constrained by > these financial considerations. > > I would respectfully disagree with Roland here and agree with > Job, Niels, etc. > > A few networks have robust out of band networks, but most > I've seen have an interesting mixture of things and inband is usually > the best method. > > Those that do have "seperate" networks may actually be CoC > services from another deparment in the same company riding the same > P/PE devices (sometimes routers). > > I've seen oob networks on DSL, datacenter wifi or cable swaps > through the fence to an adjacent rack. > > An oob network need not be high bandwidth enough to do netflow > sampling, this is well regarded as a waste of money by many as the costs > for these can often be orders of magnitude more compared to a pure-IP > or internet service. > > I'll say this ranks up there with people who think > MPLS VPN == Encryption. It's not unless you think a few byte > label is going to confuse people. > > - Jared From owen at delong.com Tue Sep 1 18:19:26 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Sep 2015 11:19:26 -0700 Subject: Zero rating implentation strategies In-Reply-To: <0FEF8847-0B58-4D61-84D5-95B57DF42581@microsoft.com> References: <55E4F8A4.5090802@vaxination.ca> <0FEF8847-0B58-4D61-84D5-95B57DF42581@microsoft.com> Message-ID: <674908F7-9E1F-47B2-B077-D8A7C23B2BBC@delong.com> The regulatory killing of that was probably unrelated to implementation. The regulators probably objected to the mobile provider creating an advantage (no data charges) for their own service against competing video services that would incur data charges. Perhaps that will help you understand what you need for a regulatory challenge. Owen > On Sep 1, 2015, at 09:36 , Christian Kuhtz wrote: > > > Zero rating is not a new concept. It has existed in the mobile world since the days of the dumb phone. Got a reference to why this was killed by the regulator in Canada? > > Mobile networks typically use their packet core (and prior iterations of the same termination, rating, billing, management gear) to rate and bill specific to each subscriber. It is done with voice minutes, text, data. Whether or not you consider the solutions scalable is up to one's individual judgement. But this zero rating billing model has and is very widely deployed and at massive scale. In fact, there are specific interfaces defined for just these purposes in the applicable standards. There are many many conceivable ways in which billing mediation and associated infrastructure for zero rating can and is implemented. This is not new and is very well understood in the mobile industry. Not sure what you're after here. > > Best regards, > Christian > > >> On Aug 31, 2015, at 6:01 PM, Jean-Francois Mezei wrote: >> >> >> Last year, one large mobile operator in Canada started to zero-rate its >> own mobile TV offering. It appears that routers kept counting all the >> data, but that the company then subtracted usage generated by its video >> servers to come up with billable Gigabytes for each user. >> >> (This was quashed by the regulator in Canada) >> >> In the last week, another mobile operator announced it was zero rating >> approved music streaming services (Spotify, Google Play and a few others). >> >> If you are dealing with "foreign" content that comes from servers you >> don't control, what are the "best practices" to zero-rate content from >> multiple outside sources ? >> >> To make matters more interesting, the FAQ for that service indicates >> that if you listen to a music stream that exceeds 128kbps, you MAY be >> charged for the data, and that you will be charged to listen to videos >> that could be offered by that service, and for non streaming data such >> as album covers, list of songs etc. >> >> Would this point to specific IPs (streaming servers for low quality >> 128kbps sound) ? How scalable is this when you start to have a whole >> bunch of source IPs whose traffic is to be zero rated ? >> >> Or would another way of doing this to setup private routes into the >> ISP's network for each approved service, so the data would enter through >> a different interface and be counted separately ? >> >> Or, and this is my most important question: Is it possible with current >> networking software to zero rate any data flow that is less than a >> certain value (eg: 128kbs) ? >> >> Or would current software require network operator to get 5 minute usage >> for each user and only bill if average data rate during last 5 minutes >> exceeded 128kbps ? (which means that your music is billed if you also >> listen to netflix at same time since total data flows are greater than >> 128kbps) >> >> >> Of note: not all customers get this treatment, only those with higher >> end packages. Those with lower end packages are charged for usage by >> those very same services. >> >> And for the record, this isn't to setup a similar system, it is to >> better understand the issue for a regulatory challenge. From jfmezei_nanog at vaxination.ca Tue Sep 1 18:39:25 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 01 Sep 2015 14:39:25 -0400 Subject: Zero rating implentation strategies In-Reply-To: <674908F7-9E1F-47B2-B077-D8A7C23B2BBC@delong.com> References: <55E4F8A4.5090802@vaxination.ca> <0FEF8847-0B58-4D61-84D5-95B57DF42581@microsoft.com> <674908F7-9E1F-47B2-B077-D8A7C23B2BBC@delong.com> Message-ID: <55E5F0DD.8060204@vaxination.ca> On 15-09-01 14:19, Owen DeLong wrote: > The regulatory killing of that was probably unrelated to implementation. Demonstrating that the Mobile TV packets traveled in exactly the same way as any other packets over the Bell Mobility network was a large part of the decision. When packets travel undifferentiated on the same pipe, then it is not justified that one packet be treated differently than the other one. This is quite different from Bell Canada's wireline TV service where multicast is used and on a separate VLAN with dedicated capacity which means that TV packets don't cause congestion on data packets and vice versa. This is why understanding of how some marketing tactic is implemented at the network level is important. From wesley.george at twcable.com Tue Sep 1 19:38:51 2015 From: wesley.george at twcable.com (George, Wes) Date: Tue, 1 Sep 2015 15:38:51 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> Message-ID: On 9/1/15, 1:36 PM, "NANOG on behalf of Roland Dobbins" wrote: >It should've already been spent for an OOB/DCN network, which should've >been provisioned with flow telemetry in mind. I'm going to interpret that "should" in the same way as the MUST in RFC6919. :-) Yes, it's a good practice, but like most other proactive security measures, is extremely hard to justify spending money on it to avoid the risk that it breaks fantastically when it is needed most. Though you could provide a little insurance against the problem you're highlighting here via a QoS policy that prioritizes flow data over customer traffic. Several of the OOB networks/designs I'm familiar with significantly predate the entire concept of flow telemetry, as well as my own networking career, and are still rocking the same set of Cisco 2500 routers with async cards (many with uptimes measured in years) and 64k leased lines or dialup on demand they've been using for literally almost 2 decades. When one of those ancient devices dies of old age, you scrounge for the cheapest equivalent you can find to replace it to maintain your oob access to the 9600/8/1/none console ports for when things have gone truly pear-shaped. Often there is a separate management network that can deal with ethernet speeds, but it's separate for security reasons and not always as rigidly independent from the in band network for connectivity, i.e. It might be a VPN riding over the regular network and thus not completely protected from the problem you're concerned about. Thanks, Wes 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 tarko at lanparty.ee Tue Sep 1 19:47:09 2015 From: tarko at lanparty.ee (Tarko Tikan) Date: Tue, 1 Sep 2015 22:47:09 +0300 Subject: NetFlow - path from Routers to Collector In-Reply-To: <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> Message-ID: <55E600BD.80701@lanparty.ee> hey, > It should've already been spent for an OOB/DCN network, which should've > been provisioned with flow telemetry in mind. Bad advice. No amount of money will fix major platforms that are not happy to export flow telemetry via router management ports. Sometimes it can be done via nasty vrf leaking hacks, sometimes it cannot be done at all. Management ports are typically directly connected to routing engines while netflow data is generated in hardware in PFE. In-band netflow works on all platforms without such issues. -- tarko From Valdis.Kletnieks at vt.edu Tue Sep 1 20:13:04 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 01 Sep 2015 16:13:04 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E600BD.80701@lanparty.ee> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> Message-ID: <30000.1441138384@turing-police.cc.vt.edu> On Tue, 01 Sep 2015 22:47:09 +0300, Tarko Tikan said: > hey, > > > It should've already been spent for an OOB/DCN network, which should've > > been provisioned with flow telemetry in mind. > > Bad advice. No amount of money will fix major platforms that are not > happy to export flow telemetry via router management ports. And that box ended up in your rack, why exactly? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From bicknell at ufp.org Tue Sep 1 20:22:17 2015 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 1 Sep 2015 13:22:17 -0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> Message-ID: <20150901202217.GB43765@ussenterprise.ufp.org> In a message written on Wed, Sep 02, 2015 at 12:29:25AM +0700, Roland Dobbins wrote: > On 2 Sep 2015, at 0:18, Niels Bakker wrote: > > You're just wrong here. > > Sorry, I'm not. I've seen what happens when flow telemetry is 'squeezed > out' by pipe-filling DDoS attacks, interrupted by fat-fingers, etc. > > It'll happen to you, one day. And then you'll understand. Ah, I see your mistake, you're thinking everyone cares about that problem. They don't. Good, fast, cheap, pick two. You've selected good. Some people pick fast and cheap. They are not wrong, you are not right. Just a different lifestyle choice. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From niels=nanog at bakker.net Tue Sep 1 20:24:11 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 1 Sep 2015 22:24:11 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <30000.1441138384@turing-police.cc.vt.edu> References: <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <30000.1441138384@turing-police.cc.vt.edu> Message-ID: <20150901202411.GF4116@excession.tpb.net> >On Tue, 01 Sep 2015 22:47:09 +0300, Tarko Tikan said: >>Bad advice. No amount of money will fix major platforms that are >>not happy to export flow telemetry via router management ports. Correct. And for a proper network you may not wish to have those connections from in-band ports to your OOB/management network everywhere. * Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) [Tue 01 Sep 2015, 22:13 CEST]: >And that box ended up in your rack, why exactly? Because variety of flow telemetry delivery options isn't the #1 ranked purchasing decider. Otherwise no Cisco would ever have been sold. >that didn't have this functionality because we were OK with sending >flow telemetry over the inband network"> Everything is a tradeoff. Welcome to the real world, where we have to make things work rather than pose on mailing lists about what we think other people should have. -- Niels. From jared at puck.nether.net Tue Sep 1 20:27:55 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 1 Sep 2015 16:27:55 -0400 Subject: FTTP Advice, Michigan and other areas Message-ID: <87820B68-BAFB-41CC-B47D-E45C1ED85C92@puck.nether.net> I?m looking for some advice/input from people either public or private about woes building fiber to reach people outside the footprints of the existing incumbents. There is a group of people looking to organize private fiber to reach areas that are unserved. There?s been recent local people doing this like Lightspeed (Lansing) and the Vergennes Broadband folks. When it come to private right of way, public right of way use, swaps, pole attach and other things, any best practices people can share either in public or private? TL;DR background for those interested: Many wireless ISPs are finding it harder to locate equipment or utilize frequencies based on interference or congestion. Advanced encodings like 16-QAM that are seen in 802.11ac hardware also introduce latencies that are not ideal. The FCC is also making it harder for equipment to be qualified in this space, in some cases rightly so due to out of band emissions or just adjacent frequency noise. The revisions of rules in 5Ghz are helpful, but the cellular industry is also looking to exploit these frequencies to solve indoor coverage. There are two groups I?m trying to assist, a local cooperative which is trying to just own the fiber and let providers gain access and some WISPs that are looking to improve service due to increase customer demand. Getting service on the fiber is ?easy? once it?s there, but gaining access or building it is the part I?m looking for insights in. - Jared From nick at foobar.org Tue Sep 1 20:34:40 2015 From: nick at foobar.org (Nick Hilliard) Date: Tue, 1 Sep 2015 21:34:40 +0100 Subject: NetFlow - path from Routers to Collector In-Reply-To: <30000.1441138384@turing-police.cc.vt.edu> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <30000.1441138384@turing-police.cc.vt.edu> Message-ID: <55E60BE0.8030009@foobar.org> On 01/09/2015 21:13, Valdis.Kletnieks at vt.edu wrote: > On Tue, 01 Sep 2015 22:47:09 +0300, Tarko Tikan said: >> Bad advice. No amount of money will fix major platforms that are not >> happy to export flow telemetry via router management ports. > > And that box ended up in your rack, why exactly? > > have this functionality because we were OK with sending flow telemetry over > the inband network"> this approach is fine for bitty boxes handling small quantities of traffic. If you want to handle netflow data export for large amounts of traffic, it would be pretty dumb to push it through the management plane of the router. Nick From chuckchurch at gmail.com Tue Sep 1 20:45:45 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 1 Sep 2015 16:45:45 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E600BD.80701@lanparty.ee> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> Message-ID: <013f01d0e4f7$2fc885b0$8f599110$@gmail.com> Agree. Most OOB is lacking redundancy too, so a single failure can really take the shine off an OOB deployment. Especially when you've put your management traffic on it, including radius traffic, and you're using 802.1X. Found that out the hard way a few years ago. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tarko Tikan Sent: Tuesday, September 01, 2015 3:47 PM To: nanog at nanog.org Subject: Re: NetFlow - path from Routers to Collector hey, > It should've already been spent for an OOB/DCN network, which > should've been provisioned with flow telemetry in mind. Bad advice. No amount of money will fix major platforms that are not happy to export flow telemetry via router management ports. Sometimes it can be done via nasty vrf leaking hacks, sometimes it cannot be done at all. Management ports are typically directly connected to routing engines while netflow data is generated in hardware in PFE. In-band netflow works on all platforms without such issues. -- tarko From bill at herrin.us Tue Sep 1 21:38:03 2015 From: bill at herrin.us (William Herrin) Date: Tue, 1 Sep 2015 17:38:03 -0400 Subject: FTTP Advice, Michigan and other areas In-Reply-To: <87820B68-BAFB-41CC-B47D-E45C1ED85C92@puck.nether.net> References: <87820B68-BAFB-41CC-B47D-E45C1ED85C92@puck.nether.net> Message-ID: On Tue, Sep 1, 2015 at 4:27 PM, Jared Mauch wrote: > I?m looking for some advice/input from people either public or private > about woes building fiber to reach people outside the footprints of the > existing incumbents. I worked on one such project, indirectly, years ago. Fiber in a small town. My three takeaways were: At the time it cost about $5 per year per pole to rent attachments on the phone pole. An attachment is a particular distance up the pole where you are allowed to attach your cables. Rights of way from pole to pole included in the deal. The power company usually owns the poles and is usually required by regulators to rent attachments. "Help" the local schools with a "partnership" to bring them fiber interconnects. Your part of the partnership is interconnecting the underfunded schools well below your cost. Their part is clearing the bureaucratic hurdles to stringing your fiber all over town. 'Cause tech is a source of tax revenue... unless it's all about the kids. Resist the urge to be a cable and phone operator at the same time. Yes, there's a temptingly large bucket of money over there, but it's not for you. The incumbents aren't going to take your entry in to the market sitting down. If you would beat them, you need the folks who would battle the incumbents for the buckets of "content" money to all be pulling for your success. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rdobbins at arbor.net Tue Sep 1 22:33:02 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 05:33:02 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E600BD.80701@lanparty.ee> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> Message-ID: <015109CE-5829-4EB0-BE12-C91311DB31BE@arbor.net> On 2 Sep 2015, at 2:47, Tarko Tikan wrote: > In-band netflow works on all platforms without such issues. There's no law that says that you must only plug designated management ports into OOB/DCN management networks. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Tue Sep 1 22:36:15 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 05:36:15 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150901202411.GF4116@excession.tpb.net> References: <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <30000.1441138384@turing-police.cc.vt.edu> <20150901202411.GF4116@excession.tpb.net> Message-ID: <5EC65B35-3AF3-42EC-A1C2-E8CD5ACB571C@arbor.net> On 2 Sep 2015, at 3:24, Niels Bakker wrote: > Because variety of flow telemetry delivery options isn't the #1 ranked > purchasing decider. Actually, it is more often than you think. No use routing packets if you can't see what they do. > Otherwise no Cisco would ever have been sold. Which is utter nonsense, of course, since Cisco a) invented flow telemetry and b) has been the consistent leader in innovating flow telemetry (FNF, IPFIX, anyone?). The EARL6/EARL7 problems are the only stumbles Cisco has made in this regard. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Tue Sep 1 22:37:10 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 05:37:10 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E60BE0.8030009@foobar.org> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <30000.1441138384@turing-police.cc.vt.edu> <55E60BE0.8030009@foobar.org> Message-ID: <633792AF-4247-49D4-B17A-DF4A0D923FB3@arbor.net> On 2 Sep 2015, at 3:34, Nick Hilliard wrote: > If you want to handle netflow data export for large amounts of traffic, it > would be pretty dumb to push it through the management plane of the router. Concur 100%. You must use a port capable of doing so. ----------------------------------- Roland Dobbins From jared at puck.nether.net Tue Sep 1 22:38:58 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 1 Sep 2015 18:38:58 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: <5EC65B35-3AF3-42EC-A1C2-E8CD5ACB571C@arbor.net> References: <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <30000.1441138384@turing-police.cc.vt.edu> <20150901202411.GF4116@excession.tpb.net> <5EC65B35-3AF3-42EC-A1C2-E8CD5ACB571C@arbor.net> Message-ID: <0AAF5D1F-688F-450A-8049-43AF1E37BE8E@puck.nether.net> > On Sep 1, 2015, at 6:36 PM, Roland Dobbins wrote: > > On 2 Sep 2015, at 3:24, Niels Bakker wrote: > >> Because variety of flow telemetry delivery options isn't the #1 ranked purchasing decider. > > Actually, it is more often than you think. No use routing packets if you can't see what they do. > >> Otherwise no Cisco would ever have been sold. > > Which is utter nonsense, of course, since Cisco a) invented flow telemetry and b) has been the consistent leader in innovating flow telemetry (FNF, IPFIX, anyone?). The EARL6/EARL7 problems are the only stumbles Cisco has made in this regard. Roland, Please stop digging, Sounds like you haven?t used Cisco recently. I?m happy to elaborate privately. - Jared From rdobbins at arbor.net Tue Sep 1 22:39:37 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 05:39:37 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <013f01d0e4f7$2fc885b0$8f599110$@gmail.com> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <013f01d0e4f7$2fc885b0$8f599110$@gmail.com> Message-ID: On 2 Sep 2015, at 3:45, Chuck Church wrote: > Most OOB is lacking redundancy too, so a single failure can really > take the shine off an OOB deployment. Even if you're using old, grandfathered equipment for it, there's no reason why your OOB/DCN can't have a reasonable degree of redundancy. Since, it's like, *what you use to control your entire network*. Underinvesting in management capabilities and capacities has always been a problem, of course. Some organizations just won't learn until they've gone through a disaster or three. ----------------------------------- Roland Dobbins From jared at puck.nether.net Tue Sep 1 22:40:29 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 1 Sep 2015 18:40:29 -0400 Subject: FTTP Advice, Michigan and other areas In-Reply-To: References: <87820B68-BAFB-41CC-B47D-E45C1ED85C92@puck.nether.net> Message-ID: <377F7C65-7784-44D2-A905-2E70450A5B4B@puck.nether.net> > On Sep 1, 2015, at 5:38 PM, William Herrin wrote: > > On Tue, Sep 1, 2015 at 4:27 PM, Jared Mauch wrote: >> I?m looking for some advice/input from people either public or private >> about woes building fiber to reach people outside the footprints of the >> existing incumbents. > > I worked on one such project, indirectly, years ago. Fiber in a small > town. My three takeaways were: > > At the time it cost about $5 per year per pole to rent attachments on > the phone pole. An attachment is a particular distance up the pole > where you are allowed to attach your cables. Rights of way from pole > to pole included in the deal. The power company usually owns the poles > and is usually required by regulators to rent attachments. I?ve heard that auditing the bills is quite important as they often don?t know who is attached to the poles. Labeling requirements are stricter as well and I can often pick out the yellow comcast labels here, the blue university/merit labels and others without slowing down. > "Help" the local schools with a "partnership" to bring them fiber > interconnects. Your part of the partnership is interconnecting the > underfunded schools well below your cost. Their part is clearing the > bureaucratic hurdles to stringing your fiber all over town. 'Cause > tech is a source of tax revenue... unless it's all about the kids. We have this place called Merit around here that some people may know that tries to cover the schools. They also got either NTIA or RUS monies (i don?t recall which) and are controlled by various state universities. I?ve not yet met their new president but recall having many conversations with people there off and on for ~20 years. > Resist the urge to be a cable and phone operator at the same time. > Yes, there's a temptingly large bucket of money over there, but it's > not for you. The incumbents aren't going to take your entry in to the > market sitting down. If you would beat them, you need the folks who > would battle the incumbents for the buckets of "content" money to all > be pulling for your success. The incumbents aren?t battling for these areas, they either have only cellular data or no service. I am served by a fixed wireless customer myself and even with Michigan Bell/Ameritech/SBC/AT&T fiber 1200 feet away there is no broadband here except fixed wireless, dial or cellular data. Content is clearly the largest data source and IMHO the easiest to solve, most of the content people are willing to either place equipment in a network permise or something else. The wireless ISP wants to expand with fiber, mostly burial. The local cooperative wants to just build fiber on these mostly rural routes and have someone like the WISP expand into the FTTP business and lease the strands back. The incumbents are unlikely to buy fiber from this model in my mind, but I?m willing to accept counter data points. I recall some of the traditional bell company people being upset using cable fiber due to the perceived poor quality to recover their networks post Katrina, likely because they had more splices and lower OTDR results. - jared From jared at puck.nether.net Tue Sep 1 22:49:22 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 1 Sep 2015 18:49:22 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: <633792AF-4247-49D4-B17A-DF4A0D923FB3@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <30000.1441138384@turing-police.cc.vt.edu> <55E60BE0.8030009@foobar.org> <633792AF-4247-49D4-B17A-DF4A0D923FB3@arbor.net> Message-ID: <6A1F6D3E-7AEE-4DF1-BA36-B6326AB872FF@puck.nether.net> > On Sep 1, 2015, at 6:37 PM, Roland Dobbins wrote: > > On 2 Sep 2015, at 3:34, Nick Hilliard wrote: > >> If you want to handle netflow data export for large amounts of traffic, it >> would be pretty dumb to push it through the management plane of the router. > > Concur 100%. You must use a port capable of doing so. My experience in running large networks is these ports often can?t handle the traffic involved. The packet path in a juniper (for example to go from the PFE -> RE -> Ethernet) is very sensitive to the jitter introduced by increased traffic loads and may result in the box becoming unstable. Other platforms (e.g.: IOS-XR based) have issues with the MgmtEther interfaces which make them inoperable for many use-cases. There are many technical details that are easily overlooked by those not using the routers to their abilities, so a small network (as Wes mentioned before with 2500s/T1s) still as OOB is unlikely to see data rates comparable to what is seen from a large router exporting data from hundreds of gigs of flows. Often net flow vendors tell customers things that create more flow records which equals slightly higher data resolution but no actual net difference in results except for the lowest of bitrates. Making sure your flow implementation is optimized (ingress only, relevant links only) is one part of having it scale. I?ve seen many a solution that scales poorly or requires dozens of boxes for datasets that don?t require it. It?s easy to say over specify for an attack because of the ?Think of the Children^WDDoS? mentality that exists, but when you are on the receiving end of a large attack there are better tools to use. - Jared From rdobbins at arbor.net Tue Sep 1 22:51:41 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 05:51:41 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <0AAF5D1F-688F-450A-8049-43AF1E37BE8E@puck.nether.net> References: <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <30000.1441138384@turing-police.cc.vt.edu> <20150901202411.GF4116@excession.tpb.net> <5EC65B35-3AF3-42EC-A1C2-E8CD5ACB571C@arbor.net> <0AAF5D1F-688F-450A-8049-43AF1E37BE8E@puck.nether.net> Message-ID: On 2 Sep 2015, at 5:38, Jared Mauch wrote: > Please stop digging, Since I'm not digging, I've no reason to stop. I see and deal with the various quirks of more different platforms exporting flow telemetry than most folks, all day, every day, so I know just a little bit about this topic. > Sounds like you haven?t used Cisco recently. I use Cisco all the time, thanks. They aren't perfect - no vendor is. They have various issues with their NetFlow implementations on various platforms - for example, bursts of wildly inaccurate flow statistics from CRS boxes when a linecard is rebooted, a problem which has persisted for years and is just now being addressed. Odd stuff with EARL8 on Sup2T/DFC4 in certain configurations, and so forth. But Niels is grossly exaggerating. I get very usable flow telemetry from them in many, many networks. I deal with flow telemetry from many, many vendors/platforms, and I can confidently assert that Cisco are nowhere near the bottom of the heap when it comes to the verisimilitude and functionality of their flow telemetry export. Quite the opposite ----------------------------------- Roland Dobbins From fkittred at gwi.net Tue Sep 1 22:54:40 2015 From: fkittred at gwi.net (Fletcher Kittredge) Date: Tue, 1 Sep 2015 18:54:40 -0400 Subject: FTTP Advice, Michigan and other areas In-Reply-To: <87820B68-BAFB-41CC-B47D-E45C1ED85C92@puck.nether.net> References: <87820B68-BAFB-41CC-B47D-E45C1ED85C92@puck.nether.net> Message-ID: Jared; What you are trying to do is quite achievable, but a huge topic worthy of a book, not an email post. Also, situations vary significantly between states due to incumbents, regulatory regimes, and level of state support. NANOG is a bad place to get advice about this topic. There are many other venues with literally thousands of other organizations/groups/companies on the same path as you. I would start from the FTTH Council, Next Century Cities, Institute for Local Self-Reliance and work out from there. On Tue, Sep 1, 2015 at 4:27 PM, Jared Mauch wrote: > I?m looking for some advice/input from people either public or private > about woes building fiber to reach people outside the footprints of the > existing incumbents. > > There is a group of people looking to organize private fiber to reach > areas that are unserved. > > There?s been recent local people doing this like Lightspeed (Lansing) and > the Vergennes Broadband folks. > > When it come to private right of way, public right of way use, swaps, pole > attach and other things, any best practices people can share either in > public or private? > > TL;DR background for those interested: > > Many wireless ISPs are finding it harder to locate equipment or > utilize frequencies based on interference or congestion. Advanced > encodings like 16-QAM that are seen in 802.11ac hardware also introduce > latencies that are not ideal. The FCC is also making it harder for > equipment to be qualified in this space, in some cases rightly so due to > out of band emissions or just adjacent frequency noise. The revisions of > rules in 5Ghz are helpful, but the cellular industry is also looking to > exploit these frequencies to solve indoor coverage. > > There are two groups I?m trying to assist, a local cooperative > which is trying to just own the fiber and let providers gain access and > some WISPs that are looking to improve service due to increase customer > demand. > > Getting service on the fiber is ?easy? once it?s there, but > gaining access or building it is the part I?m looking for insights in. > > - Jared > > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From jared at puck.nether.net Tue Sep 1 22:57:52 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 1 Sep 2015 18:57:52 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <013f01d0e4f7$2fc885b0$8f599110$@gmail.com> Message-ID: <9C91C929-865B-4B7A-AD9D-6AB9DFB510AD@puck.nether.net> > On Sep 1, 2015, at 6:39 PM, Roland Dobbins wrote: > > On 2 Sep 2015, at 3:45, Chuck Church wrote: > >> Most OOB is lacking redundancy too, so a single failure can really take the shine off an OOB deployment. > > Even if you're using old, grandfathered equipment for it, there's no reason why your OOB/DCN can't have a reasonable degree of redundancy. Since, it's like, *what you use to control your entire network*. Most networks use inband to manage them. > Underinvesting in management capabilities and capacities has always been a problem, of course. Some organizations just won't learn until they've gone through a disaster or three. Yes. let me know when the vendors catch up in this area. I often see people say to create a new network as job security vs making the inband network survive attacks or be provisioned properly. Most people I?ve seen have little data or insight into their networks, or don?t have the level that they would desire as tools are expensive or impossible to justify due to capital costs. Tossing in a recurring opex cost of DC XC fee + transport + XC fee + redundant aggregation often doesn?t have the ROI you infer here. I?ve put together some models in this area. It seems to me the DC/real estate companies involved could make a lot (more) money by offering an OOB service that is 10Mb/s flat-rate for the same as an XC fee and compete with their customers. Things continue to be a challenge as less equipment works with a serial console and the expectation of developers of these embedded solutions don?t take into account low bitrate connections that are often used in last-resort situations. We have a well oiled set of processes and checklists to monitor and test our management network. Patrick Gilmore has personally mocked me because of its method and technique, but the reality is it works. - Jared From rdobbins at arbor.net Tue Sep 1 23:03:43 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 06:03:43 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> Message-ID: <2F79F924-91BD-4297-8AA1-36A5BA51264C@arbor.net> On 2 Sep 2015, at 2:38, George, Wes wrote: > Often there is a separate management network that can deal with > ethernet > speeds, but it's separate for security reasons and not always as > rigidly > independent from the in band network for connectivity, i.e. It might > be a > VPN riding over the regular network and thus not completely protected > from > the problem you're concerned about. Sure, or a VRF, or whatever. While that's not ideal, it's far better than doing management-plane stuff inband in the production network, though. And those 2500 console concentrator connections are a great resource to have when everything goes haywire and you need something that lets you get to and actually type on the console. I'm not knocking them, and I understand that old, grandfathered equipment is used for these applications, and understand that in many cases they're underprovisioned for flow telemetry. Which is why using VLANs, VRFs, whatever on the production network gear is completely understandable, and a lot of folks do just as you say. ----------------------------------- Roland Dobbins From jared at puck.nether.net Tue Sep 1 23:06:50 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 1 Sep 2015 19:06:50 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <30000.1441138384@turing-police.cc.vt.edu> <20150901202411.GF4116@excession.tpb.net> <5EC65B35-3AF3-42EC-A1C2-E8CD5ACB571C@arbor.net> <0AAF5D1F-688F-450A-8049-43AF1E37BE8E@puck.nether.net> Message-ID: <4CA65BEA-7E3F-436F-85E3-23C598EF508F@puck.nether.net> > On Sep 1, 2015, at 6:51 PM, Roland Dobbins wrote: > > > On 2 Sep 2015, at 5:38, Jared Mauch wrote: > >> Please stop digging, > > Since I'm not digging, I've no reason to stop. I see and deal with the various quirks of more different platforms exporting flow telemetry than most folks, all day, every day, so I know just a little bit about this topic. You are, Avi has said that the number of people with a network is outnumbered about 50:1 using his most favorable numbers. This means for your one example there are 50 people not doing this and the world hasn?t ended for them. If you aren?t listening to Avi, please trust me, you don?t need your own OOB network for flow, nor is putting your flow there going to provide you some magical value. If you can?t provision enough bandwidth for your telemetry data, you will obviously need to prune it back. 1:10k sampling works and you don?t need much more than that unless you?re at extremely low bitrates. Most attacks last under 1 hour and even the small ones shout out in netflow data doing a simple hash sort algorithm with the proper keys. You can even use QoS to mitigate if your goal is attack traffic as they?re mostly UDP based attacks, see: https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 for some advice/input. I?ve shared my own input at recent NANOG meetings, including policers to keep the attacks under control. >> Sounds like you haven?t used Cisco recently. > > I use Cisco all the time, thanks. They aren't perfect - no vendor is. They have various issues with their NetFlow implementations on various platforms - for example, bursts of wildly inaccurate flow statistics from CRS boxes when a linecard is rebooted, a problem which has persisted for years and is just now being addressed. Odd stuff with EARL8 on Sup2T/DFC4 in certain configurations, and so forth. I?m not talking about datacenter class equipment that you seem so focused on like the Earl7 with the TICO etc that did software sampling out of the hardware tcam and would be overrun. > But Niels is grossly exaggerating. I get very usable flow telemetry from them in many, many networks. I deal with flow telemetry from many, many vendors/platforms, and I can confidently assert that Cisco are nowhere near the bottom of the heap when it comes to the verisimilitude and functionality of their flow telemetry export. Quite the opposite What people often don?t see is true ?scale?[1] of netflow. When you have enough attributes or want to actually look at your IPv6 there have been significant shortcomings. We had to remind the patent holder for netflow how to implement it for their own hardware. - Jared aside: will you be in Yokohama? We should get lunch/dinner. [1] - I hate this word, vendors use it as an excuse to hardcode limits and to not properly respond to valid use cases From rdobbins at arbor.net Tue Sep 1 23:08:25 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 06:08:25 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150901175547.35F4A550C59C7@freedman.net> References: <20150901175547.35F4A550C59C7@freedman.net> Message-ID: <32745778-E4D9-4F94-A5CF-502D533F110F@arbor.net> On 2 Sep 2015, at 0:55, Avi Freedman wrote: > Looking at probably 100 networks' flow paths over the last year, I'd > say 1 or 2 have OOB for flow. Far fewer have it than should, agreed. A reasonable compromise is VLANs, VRFs, and so on to at least keep it out of the data-plane of the production network. > But for folks seeing DDoS, we implement rate-limiting of the flows/sec > via local proxies > to avoid overwhelming network capacity with the flow data... A lot of networks do that - they collect the flow telemetry relatively topologically near their edge routers which are exporting it, do distributed analysis (depending upon what tools they're using for collection/analysis), and then the analysis results are what's long-hauled - and this is much less than the raw flow telemetry volume. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Tue Sep 1 23:10:14 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 06:10:14 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150901174651.GE4116@excession.tpb.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <20150901174651.GE4116@excession.tpb.net> Message-ID: <95CEA985-18CB-4AD5-86CF-6022D52F8675@arbor.net> On 2 Sep 2015, at 0:46, Niels Bakker wrote: > This is the dumbest thing I've read on this mailing list in a while. It happens. You can deny it all you like, but I've seen it happen, and the resultant confusion and additional time to resolve problems it causes. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Tue Sep 1 23:22:34 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 06:22:34 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150901174406.GB28155@puck.nether.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <20150901174406.GB28155@puck.nether.net> Message-ID: <201716EA-D1D0-4302-8FAB-E8A11FC82F20@arbor.net> On 2 Sep 2015, at 0:44, Jared Mauch wrote: > I think the key here is that Roland isn't often constrained by these > financial considerations. That's entirely true. I deal every day with customers who are, though. > I would respectfully disagree with Roland here and agree with Job, > Niels, etc. I understand where you and they are coming from, in this regard. I just disagree, as well. > A few networks have robust out of band networks, but most I've seen > have an interesting mixture of things Concur 100%. > and inband is usually the best method. Let me be clear - OOB for flow telemetry can be actually provisioned on the same boxes which are handling the production network traffic. It isn't ideal, but it's better than running it truly inband in the production network, mixed in with customer traffic. VLANs, VRFs, whatever are a reasonable compromise, and a lot of folks do this. Inband is a huge risk, especially in a world of multi-hundred gb/sec reflection/amplification attacks (not to mention the other catastrophic failure scenarios). I know you sink a lot of UDP at the edges of your network to ameliorate this problem, but not all operators do that or agree with it either in principle or as a matter of optimal utility. I understand that this sort of thing is a decision that all network operators must make for themselves based upon their knowledge of their own networks and customer needs. > Those that do have "seperate" networks may actually be CoC services > from another deparment in the same company riding the same P/PE > devices (sometimes routers). Yes, that's what I'm getting at above. It isn't ideal, but there's no reason to make the perfect the enemy of the merely good, agreed. > I've seen oob networks on DSL, datacenter wifi or cable swaps through > the fence to an adjacent rack. Absolutely. All kinds of creative lashups to get console access in difficult situations (and, as you noted previously, an increasing number of devices don't support serial console at all, which is highly annoying). ----------------------------------- Roland Dobbins From rdobbins at arbor.net Wed Sep 2 00:01:49 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 07:01:49 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <4CA65BEA-7E3F-436F-85E3-23C598EF508F@puck.nether.net> References: <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <30000.1441138384@turing-police.cc.vt.edu> <20150901202411.GF4116@excession.tpb.net> <5EC65B35-3AF3-42EC-A1C2-E8CD5ACB571C@arbor.net> <0AAF5D1F-688F-450A-8049-43AF1E37BE8E@puck.nether.net> <4CA65BEA-7E3F-436F-85E3-23C598EF508F@puck.nether.net> Message-ID: On 2 Sep 2015, at 6:06, Jared Mauch wrote: > You are, Avi has said that the number of people with a network is > outnumbered about 50:1 using his most favorable numbers. Again, to clarify - I count VLANs/VRFs as being sufficiently out-of-band to handle flow telemetry on a reasonable basis without mixing it in with customer traffic. That changes the ratio. > This means for your one example there are 50 people not doing this and > the world hasn?t ended for them. If you aren?t listening to Avi, > please trust me, you don?t need your own OOB network for flow, nor > is putting your flow there going to provide you some magical value. I agree with you, Avi, and others that a dedicated OOB network *just for flow telemetry* doesn't make economic sense in most (any?) scenarios. What I'm saying is that it oughtn't to be mixed in with customer data-plane traffic. Ideally, all management-plane traffic would traverse a separate physical infrastructure. Since we don't live in an ideal world, virtual separation is generally Good Enough. > 1:10k sampling works and you don?t need much more than that unless > you?re at extremely low bitrates. Most attacks last under 1 hour > and even the small ones shout out in netflow data doing a simple hash > sort algorithm with the proper keys Concur 100%. I spend a lot of time explaining to customers that no, they don't need/want 1:1 even if they could get it, and that the 'wake' left by attack traffic stands out very well even at relatively high sampling ratios. Most of the network-oriented folks seem to grasp this pretty quickly. It's generally the 'security' types who often seem conceptually/attitudinally incapable of understanding these principles. > . You can even use QoS to mitigate if your goal is attack > traffic as they?re mostly UDP based attacks, see: > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 for some > advice/input. I know you do this, and I understand why. Not everyone agrees with this and does it, and I also understand why (not). ntp is easy, because there's the timesync packet-size classification hook. It gets a little dicier with other things. > I?ve shared my own input at recent NANOG meetings, including > policers to keep the attacks under control. And it's valuable experience to share, nobody disputes that. > I?m not talking about datacenter class equipment that you seem so > focused on like the Earl7 with the TICO etc that did software sampling > out of the hardware tcam and would be overrun. I'm pretty sure the CRSes I referred to with the linecard-reboot issue in my example aren't datacenter-class equipment. ;> > What people often don?t see is true ?scale?[1] of netflow. When > you have enough attributes or want to actually look at your IPv6 there > have been significant shortcomings. We had to remind the patent > holder for netflow how to implement it for their own hardware. This is very true. IPv6 flow telemetry is another area in which IPv4/IPv6 feature parity lags. Because of your focus on large-scale IPv6 deployment over the course of many years, you see and experience a lot more IPv6-related deficiencies than most folks. > aside: will you be in Yokohama? We should get lunch/dinner. Yes, and yes. ;> > [1] - I hate this word, vendors use it as an excuse to hardcode limits > and to not properly respond to valid use cases Concur 100%. Another annoying vendor trait is use-case obsession. In many contexts, the right answer is to understand that there is a baseline plateau of vitally necessary scaling (that word, again) capacity and required functionality which is universally applicable, irrespective of variations in particular use cases. I recently had a discussion with someone who was asking me how many attack sources one typically sees in a given DDoS attack. My response was that there is no 'typical'; and that for IPv4, the theoretical potential is 2^32 sources, while in IPv6, the theoretical potential is for 2^128 sources. It was a light-bulb moment. ;> ----------------------------------- Roland Dobbins From rdobbins at arbor.net Wed Sep 2 00:05:08 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 07:05:08 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <6A1F6D3E-7AEE-4DF1-BA36-B6326AB872FF@puck.nether.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <55E600BD.80701@lanparty.ee> <30000.1441138384@turing-police.cc.vt.edu> <55E60BE0.8030009@foobar.org> <633792AF-4247-49D4-B17A-DF4A0D923FB3@arbor.net> <6A1F6D3E-7AEE-4DF1-BA36-B6326AB872FF@puck.nether.net> Message-ID: On 2 Sep 2015, at 5:49, Jared Mauch wrote: > Other platforms (e.g.: IOS-XR based) have issues with the MgmtEther > interfaces which make them inoperable for many use-cases. I'm agreeing with you. Dedicated management ports on many boxes don't actually support important management-plane functions, like flow telemetry - which is nuts, but that's what happens. > There are many technical details that are easily overlooked by those > not using the routers to their abilities, so a small network (as Wes > mentioned before with 2500s/T1s) still as OOB is unlikely to see > data rates comparable to what is seen from a large router exporting > data from hundreds of > gigs of flows. That's true. I understand that even on large networks, the OOB/DCN is built from old, grandfathered equipment. I spend a lot of time helping network operators calculate optimal flow sampling rates, flow cache sizes, etc., and an important consideration in making optimal configuration choices is what the OOB/DCN network can handle. > Often net flow vendors tell customers things that create more flow > records which equals slightly higher data resolution but no actual net > difference in results except for the lowest of bitrates. Concur 100%. I spend a non-trivial amount of time talking folks down from the assumption that unnecessarily-low flow sampling ratios are required (these are mainly 'security' folks, not network engineers). ----------------------------------- Roland Dobbins From freedman at freedman.net Wed Sep 2 00:27:10 2015 From: freedman at freedman.net (Avi Freedman) Date: Tue, 1 Sep 2015 20:27:10 -0400 (EDT) Subject: NetFlow - path from Routers to Collector Message-ID: <20150902002710.687D0550C6B41@freedman.net> (Said Roland:) > Again, to clarify - I count VLANs/VRFs as being sufficiently out-of-band > to handle flow telemetry on a reasonable basis without mixing it in with > customer traffic. > > That changes the ratio. > I agree with you, Avi, and others that a dedicated OOB network *just for > flow telemetry* doesn't make economic sense in most (any?) scenarios. > > What I'm saying is that it oughtn't to be mixed in with customer > data-plane traffic. Ideally, all management-plane traffic would > traverse a separate physical infrastructure. Since we don't live in an > ideal world, virtual separation is generally Good Enough. We see well under 20% doing logical separation but definitely folks doing it... For the definition of OOB as "separate routers and switches", we don't see anyone really sending flow over that kind of OOB network. > ----------------------------------- > Roland Dobbins Avi Freedman CEO, Kentik avi at kentik dot com From freedman at freedman.net Wed Sep 2 00:30:37 2015 From: freedman at freedman.net (Avi Freedman) Date: Tue, 1 Sep 2015 20:30:37 -0400 (EDT) Subject: NetFlow - path from Routers to Collector Message-ID: <20150902003037.1F2A5550C6B41@freedman.net> (Jared wrote): > Most people I've seen have little data or insight into their > networks, or don't have the level that they would desire as > tools are expensive or impossible to justify due to capital costs. > Tossing in a recurring opex cost of DC XC fee + transport + XC fee + > redundant aggregation often doesn't have the ROI you infer here. > I've put together some models in this area. It seems to me the > DC/real estate companies involved could make a lot (more) money by > offering an OOB service that is 10Mb/s flat-rate for the same as an XC > fee and compete with their customers. Equinix does have a very aggressively priced 10Mb/s flat-rate OOB (single IP only but that's not that hard to work around) for essentially XC pricing. It's been stable but not something you'd rely on for 100% packet delivery to some other point on the Internet (so more for reaching a per-pop OOB than for making a coherent OOB network with a bunch of monitoring running 24x7). Still, it's a good value for what it is. > - Jared Avi Freedman CEO, Kentik avi at kentik dot com From rdobbins at arbor.net Wed Sep 2 00:32:22 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 07:32:22 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150902002710.687D0550C6B41@freedman.net> References: <20150902002710.687D0550C6B41@freedman.net> Message-ID: <8CE8DD22-41B4-4EA4-AB51-ADBD97B2ACCB@arbor.net> On 2 Sep 2015, at 7:27, Avi Freedman wrote: > We see well under 20% doing logical separation but definitely folks > doing it... ~20% matches our subjective observations, as well. We're doing our best to increase that number. ----------------------------------- Roland Dobbins From deleskie at gmail.com Wed Sep 2 00:38:04 2015 From: deleskie at gmail.com (jim deleskie) Date: Tue, 1 Sep 2015 20:38:04 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150902003037.1F2A5550C6B41@freedman.net> References: <20150902003037.1F2A5550C6B41@freedman.net> Message-ID: I've not read every reply, but let me add my voice as some who has worked on and ran SEVERAL large networks, in no case in the last long number of years have I had access to an OOB network that was sized to carry anything in large volume, and in fact like many others replied on a robust number of path at that us many the networks inband. These networks survived many "large" DDoS attacks and far more fat finger incidents then I like to think about. I don't think I've even worked with a client network as far as I can remember that had a nailed up / robust OOB network for data collection or other purposes. -jim On Tue, Sep 1, 2015 at 8:30 PM, Avi Freedman wrote: > (Jared wrote): > > > > > Most people I've seen have little data or insight into their > > networks, or don't have the level that they would desire as > > tools are expensive or impossible to justify due to capital costs. > > Tossing in a recurring opex cost of DC XC fee + transport + XC fee + > > redundant aggregation often doesn't have the ROI you infer here. > > I've put together some models in this area. It seems to me the > > DC/real estate companies involved could make a lot (more) money by > > offering an OOB service that is 10Mb/s flat-rate for the same as an XC > > fee and compete with their customers. > > Equinix does have a very aggressively priced 10Mb/s flat-rate OOB (single > IP only but that's not that hard to work around) for essentially XC > pricing. It's been stable but not something you'd rely on for 100% > packet delivery to some other point on the Internet (so more for > reaching a per-pop OOB than for making a coherent OOB network with > a bunch of monitoring running 24x7). > > Still, it's a good value for what it is. > > > > > - Jared > > Avi Freedman > CEO, Kentik > avi at kentik dot com > > From surfer at mauigateway.com Wed Sep 2 00:53:33 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 1 Sep 2015 17:53:33 -0700 Subject: NetFlow - path from Routers to Collector Message-ID: <20150901175333.70AEE9F6@m0048137.ppops.net> --- rdobbins at arbor.net wrote: Again, to clarify - I count VLANs/VRFs as being sufficiently out-of-band to handle flow telemetry on a reasonable basis without mixing it in with customer traffic. --------------------------------------- Glad you clarified that. Now, I understand your stance. Like the others are saying, in 18 years of netgeeking I never had OOB with flow. It has always been in a VLAN or VRF. --- freedman at freedman.net wrote: We see well under 20% doing logical separation but definitely folks doing it... -------------------------------------- Now that's a scary number. VLANS/VRFs are too easy not to do that. scott From rdobbins at arbor.net Wed Sep 2 00:56:16 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 07:56:16 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <20150902003037.1F2A5550C6B41@freedman.net> Message-ID: On 2 Sep 2015, at 7:38, jim deleskie wrote: > These networks survived many "large" DDoS attacks and far more fat > finger incidents then I like to think > about. What I'm saying is that keeping flow telemetry and other management-plane traffic from mixing with customer data-plane traffic is important in order to ensure visibility and control during a significant network-impacting event. I've personally been involved in assisting multiple operators in multiple incidents in which either DDoS attack traffic or inadvertent routing redistribution excursions led to loss of visibility and control, resulting in unnecessarily-long times to resolution. Virtual separation is generally Good Enough, and what we see with customers who run it all in-band is an increasing number who're taking steps to achieve at least virtual separation (~20%, as Avi noted, is about what we see implemented, currently). It isn't nearly as many as we would like to see, and it isn't happening as fast as we'd like to see it, but we encourage it wherever we can. The OP on this thread was essentially asking about the best approach. OOB, whether virtual or physical, is the best approach. Economic factors may militate against this, at least initially, but a disaster or two can change that economic analysis. I also suspect that increasing use of 'SDN'-type (apologies for using that overused acronym!) orchestration across the entire network topology (e.g., not just within the IDC) is going to lead to more separation of management-plane traffic from customer data-plane traffic, as the implications sink in. ----------------------------------- Roland Dobbins From diptanshu.singh at gmail.com Wed Sep 2 04:12:45 2015 From: diptanshu.singh at gmail.com (dip) Date: Tue, 1 Sep 2015 23:12:45 -0500 Subject: BGP advertise-best-external on RR In-Reply-To: <55E59F4F.8010704@noor.net> References: <55DB6B81.60908@noor.net> <2411BC56-6BAC-433F-B96E-7761C021774A@gmail.com> <55DB7127.20308@noor.net> <55E59F4F.8010704@noor.net> Message-ID: There's no such thing as free lunch right :). If BGP Add-Path or Diverse-Path isn't option for you then as you mentioned Internet VRF with different RD is the third option but you have to understand the implications here as well around increase in % of memory. Another option could be to bypass the RR's and just fully mesh it. But if none of the above is an option, then you may have to do some unnatural act to solve it. On Tue, Sep 1, 2015 at 7:51 AM, Mohamed Kamal wrote: > Hi, > > Diverse-path will only send the second best path, and in my case I have > three routes not two. In addition to that, every PE will have to peer with > the RR via a second session (on the same RR, as I will not deploy a new > standalone shadow RR) and this will increase the BGP sessions to the double. > > Add-path will have a network-wide IOS upgrade for this BGP capability to > be supported which is not viable now. > > So, is there any other recommendation other than the internet VRF with > different RDs solution? > > Regards, > > Mohamed Kamal > Core Network Sr. Engineer > > On 8/25/2015 11:37 AM, Jeff Tantsura wrote: > >> Hi, >> >> In your case I?d recommend to use diverse path, due to its simplicity and >> non disruptive deployment characteristics. >> As you know - diverse path requires additional BGP session per additional >> (second, next, etc) path, in most cases not a problem, however mileage >> might vary. >> >> To my memory, in Cisco land - it has only been implemented in IOS, not XR, >> please check. >> >> Cheers, >> Jeff >> >> >> >> >> -----Original Message----- >> From: Diptanshu Singh >> Date: Monday, August 24, 2015 at 10:53 PM >> To: Mohamed Kamal >> Cc: "nanog at nanog.org" >> Subject: Re: BGP advertise-best-external on RR >> >> Yes . In the case of diverse path , shadow route reflector will be the >>> one wherever you enable commands to trigger diverse path computation. >>> >>> Good thing with diverse path is that the RR-Clients don't have to have >>> any support but bad thing is that it can only reflect One additional >>> best-path( second best path ) . >>> >>> Sent from my iPhone >>> >>> On Aug 24, 2015, at 2:31 PM, Mohamed Kamal wrote: >>>> >>>> It's only supported on the 15.2(4)S and later not the SRE train. I >>>> might consider an upgrade. >>>> >>>> One more question regarding this, can you configure the RR to be the >>>> main and shadow RR? >>>> >>>> Mohamed Kamal >>>> Core Network Sr. Engineer >>>> >>>> On 8/24/2015 9:16 PM, Diptanshu Singh wrote: >>>>> BGP Add-Path might be your friend . You can look at diverse-path as >>>>> well . >>>>> >>>> >> > From freedman at freedman.net Wed Sep 2 05:50:57 2015 From: freedman at freedman.net (Avi Freedman) Date: Wed, 2 Sep 2015 01:50:57 -0400 (EDT) Subject: NetFlow - path from Routers to Collector Message-ID: <20150902055057.416E3550C6B46@freedman.net> Agreed, we are as well :) VLAN, VRF, whatever. + optimal tweaks include local flow proxy that can also rate limit / re-sample, and send topk talkers over 'true' OOB. Avi Freedman CEO, Kentik avi at kentik dot com > On 2 Sep 2015, at 7:27, Avi Freedman wrote: > > > We see well under 20% doing logical separation but definitely folks > > doing it... > > ~20% matches our subjective observations, as well. > > We're doing our best to increase that number. > > ----------------------------------- > Roland Dobbins From mark.tinka at seacom.mu Wed Sep 2 06:01:34 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Sep 2015 08:01:34 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> Message-ID: <55E690BE.3030900@seacom.mu> On 1/Sep/15 17:43, Roland Dobbins wrote: > Until there is. As with everything in life... Mark. From mark.tinka at seacom.mu Wed Sep 2 06:02:23 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Sep 2015 08:02:23 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> Message-ID: <55E690EF.5080208@seacom.mu> On 1/Sep/15 17:59, Rod Beck wrote: > Roland is correct. With the caveat that your Internet customer traffic may flow over the fibers as your separate management circuits. You should aim for end to end physical diversity. This is all common sense, but laziness some times takes precedence. Not very straight forward when you have a network spanning several continents. Mark. From mark.tinka at seacom.mu Wed Sep 2 06:08:37 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Sep 2015 08:08:37 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> Message-ID: <55E69265.1040300@seacom.mu> On 1/Sep/15 19:12, Roland Dobbins wrote: > > > > Running flow telemetry in-band is penny-wise and pound-foolish, for > networks of any size, in any circumstances. All management-plane > traffic (and that's what flow telemetry is) should be segregated from > the production network data plane. Looking at the span of my network, when I am building an OoB platform to maintain management access to any device that may lose in-band connectivity, I'll be honest, moving flow data across that is the least of my worries. Simply because the costs and effort associated with getting OoB management plane access that is cleanly separated from in-band topologies does not always encourage the addition of traffic that could kill the case for the same. When my device is down, my primary objective is to get it back up, fast. Flow data being lost is less of a problem. Mark. From pf at tippete.net Wed Sep 2 06:25:41 2015 From: pf at tippete.net (Pierfrancesco Caci) Date: Wed, 02 Sep 2015 08:25:41 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> (Roland Dobbins's message of "Wed, 02 Sep 2015 00:12:27 +0700") References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> Message-ID: <87io7tl4m2.fsf@snoopy.tippete.net> >>>>> "Roland" == Roland Dobbins writes: Roland> On 2 Sep 2015, at 0:08, Steve Meuse wrote: >> Your advice is not "one size fits all". Roland> Actually, it is. Roland> Large backbone networks have DCNs/OOBs, and that's where they export Roland> their NDE. 2 out of 2 large backbone networks I've experience with use inband for flow export. -- Pierfrancesco Caci, ik5pvx From baldur.norddahl at gmail.com Wed Sep 2 07:30:12 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 2 Sep 2015 09:30:12 +0200 Subject: BGP advertise-best-external on RR In-Reply-To: <55E59F4F.8010704@noor.net> References: <55DB6B81.60908@noor.net> <2411BC56-6BAC-433F-B96E-7761C021774A@gmail.com> <55DB7127.20308@noor.net> <55E59F4F.8010704@noor.net> Message-ID: Not a suggestion, just trying to learn something here. Is there an advantage to use a route reflector in the described setup, which appears to involve only a small number of routers? I would think that full mesh would solve the problem and at the same time be easier since you do not have to maintain any route reflectors. With peer-group it is not a real bother to configure a handful of iBGP peers. Regards, Baldur From mark.tinka at seacom.mu Wed Sep 2 07:40:20 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Sep 2015 09:40:20 +0200 Subject: BGP advertise-best-external on RR In-Reply-To: References: <55DB6B81.60908@noor.net> <2411BC56-6BAC-433F-B96E-7761C021774A@gmail.com> <55DB7127.20308@noor.net> <55E59F4F.8010704@noor.net> Message-ID: <55E6A7E4.2060401@seacom.mu> On 2/Sep/15 09:30, Baldur Norddahl wrote: > Not a suggestion, just trying to learn something here. Is there an > advantage to use a route reflector in the described setup, which appears to > involve only a small number of routers? I would think that full mesh would > solve the problem and at the same time be easier since you do not have to > maintain any route reflectors. > > With peer-group it is not a real bother to configure a handful of iBGP > peers. I and a bunch of others have always recommended starting with a route reflector regardless of your network size. It makes growing much easier. Mark. From rdobbins at arbor.net Wed Sep 2 09:38:54 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 16:38:54 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E690EF.5080208@seacom.mu> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> Message-ID: <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> On 2 Sep 2015, at 13:02, Mark Tinka wrote: > Not very straight forward when you have a network spanning several > continents. Again, VLANs/VRFs are generally Good Enough, and more than a few globe-spanning networks do just that. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Wed Sep 2 09:40:37 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 16:40:37 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150902055057.416E3550C6B46@freedman.net> References: <20150902055057.416E3550C6B46@freedman.net> Message-ID: <267C7DF7-1B49-43B1-B6E0-A0CD5D6DE177@arbor.net> On 2 Sep 2015, at 12:50, Avi Freedman wrote: > + optimal tweaks include local flow proxy that can also rate > limit / re-sample, and send topk talkers over 'true' OOB. Yes, a lot of distributed flow collection/analysis architectures are deployed this way, doing more than top-talkers, even. The key is that traffic between the elements of those types of deployments *must* not be disrupted; true OOB is preferred, but VLAN/VRF is still the norm, there. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Wed Sep 2 09:43:58 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 16:43:58 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <87io7tl4m2.fsf@snoopy.tippete.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <87io7tl4m2.fsf@snoopy.tippete.net> Message-ID: <5B0D87DD-6AFB-41F1-A945-049005EF533F@arbor.net> On 2 Sep 2015, at 13:25, Pierfrancesco Caci wrote: > 2 out of 2 large backbone networks I've experience with use inband for > flow export. There was supposed to be a 'should' in there, apologies. I've already clarified that VLAN/VRF is Good Enough for flow telemetry, and that most who separate it out from customer traffic do so logically. There are a few very large networks who do this completely physically out-of-band; they made the decision that they were going to invest in the ability to ship telemetry around and analyze it, and spent a lot of capex and opex to be able to do just that. ----------------------------------- Roland Dobbins From mark.tinka at seacom.mu Wed Sep 2 09:48:51 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Sep 2015 11:48:51 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> Message-ID: <55E6C603.7040305@seacom.mu> On 2/Sep/15 11:38, Roland Dobbins wrote: > > > Again, VLANs/VRFs are generally Good Enough, and more than a few > globe-spanning networks do just that. Those VLAN's and VRF's are following the same path as the global table, just in a different routing table. That is easy, and we do that already. Your assertion, before, was that the OoB network is physically separate from the routers it is supporting. This is less feasible at scale. Mark. From rdobbins at arbor.net Wed Sep 2 10:11:25 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 17:11:25 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E6C603.7040305@seacom.mu> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> Message-ID: <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> On 2 Sep 2015, at 16:48, Mark Tinka wrote: > Those VLAN's and VRF's are following the same path as the global > table, just in a different routing table. That is easy, and we do that > already. Sure. But it's better than mixing it in with customer traffic. > Your assertion, before, was that the OoB network is physically > separate from the routers it is supporting. This is less feasible at > scale. Ideally, it should be - that's what I was trying to get across. I understand that this isn't free, either from a capex or opex perspective. ----------------------------------- Roland Dobbins From niels=nanog at bakker.net Wed Sep 2 13:25:25 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 2 Sep 2015 15:25:25 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> Message-ID: <20150902132525.GG4116@excession.tpb.net> * rdobbins at arbor.net (Roland Dobbins) [Wed 02 Sep 2015, 12:12 CEST]: >On 2 Sep 2015, at 16:48, Mark Tinka wrote: >>Those VLAN's and VRF's are following the same path as the global >>table, just in a different routing table. That is easy, and we do >>that already. > >Sure. But it's better than mixing it in with customer traffic. Why? Do your customer packets have cooties? >>Your assertion, before, was that the OoB network is physically >>separate from the routers it is supporting. This is less feasible >>at scale. > >Ideally, it should be - that's what I was trying to get across. I >understand that this isn't free, either from a capex or opex >perspective. Which is exactly the argument that people with experience have been making on this mailing list. OOB is the 3G dialout on a terminal server that it uses once its regular outside connection fails. You don't want flow exports there, to give just one counterexample to your earlier assertions. -- Niels. From benno at NLnetLabs.nl Wed Sep 2 13:53:29 2015 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Wed, 2 Sep 2015 15:53:29 +0200 Subject: 2nd Call for presentations RIPE 71 Message-ID: <55E6FF59.8080902@NLnetLabs.nl> Colleagues, Please note the approaching deadline of 13 September 2015 for RIPE 71 plenary programme submissions. You can find the CFP for RIPE 71 below, or at https://ripe71.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://www.ripe.net/participate/meetings/ripe-meetings/pc ---------------------------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 71 will take place from 16-20 November 2015 in Bucharest, Romania. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 71. See the full descriptions of the different presentation formats, https://ripe71.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 13 September 2015. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe71.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe71.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice---in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From rdobbins at arbor.net Wed Sep 2 14:02:10 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 21:02:10 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150902132525.GG4116@excession.tpb.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> <20150902132525.GG4116@excession.tpb.net> Message-ID: <5E82EB15-2069-4A1A-834D-B240E836F182@arbor.net> On 2 Sep 2015, at 20:25, Niels Bakker wrote: > Why? Do your customer packets have cooties? Because you don't want things which disrupt customer traffic to disrupt your ability to see what's happening. Just as you don't want it to disrupt your ability to configure/manage your infrastructure. > Which is exactly the argument that people with experience have been > making on this mailing list. I think the problem here is that I failed to distinguish between logical and physical OOB. Physical is best, logical is generally Good Enough. There are some operators who send flow telemetry across physically distinct OOB infrastructure. More do it logically. Most still do it in-band mixed with production network traffic, but that is slowly changing. > OOB is the 3G dialout on a terminal server that it uses once its > regular outside connection fails. That's one example, yes. > You don't want flow exports there, to give just one counterexample to > your earlier assertions. On that particular category of OOB, of course not. ----------------------------------- Roland Dobbins From jared at puck.nether.net Wed Sep 2 14:08:22 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 2 Sep 2015 10:08:22 -0400 Subject: NetFlow - path from Routers to Collector In-Reply-To: <5E82EB15-2069-4A1A-834D-B240E836F182@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> <20150902132525.GG4116@excession.tpb.net> <5E82EB15-2069-4A1A-834D-B240E836F182@arbor.net> Message-ID: <659C446B-EBF9-483D-AFE6-25650551CE18@puck.nether.net> > On Sep 2, 2015, at 10:02 AM, Roland Dobbins wrote: > > On 2 Sep 2015, at 20:25, Niels Bakker wrote: > >> Why? Do your customer packets have cooties? > > Because you don't want things which disrupt customer traffic to disrupt your ability to see what's happening. Just as you don't want it to disrupt your ability to configure/manage your infrastructure. It?s really because some people who drink the MPLS/VPN/VRF/VLAN kook-aid think it?s some magic that undoes fate sharing and proper engineering and planning. That a few bytes for a label of VLAN tag make your data more secure. It?s possible to build a network that works without all these vendor pushed tricks. I see where Roland is trying to go and he?s in the ?magic byte? realm of the extra label makes it ?OOB? where as the rest of us just see 1?s and 0?s on the wire and know a bit is a bit regardless of tag-switching (the original name for MPLS) or IEEE 802.1q label. I?m sure there are people still doing ISL but i?d rather not. - Jared From niels=nanog at bakker.net Wed Sep 2 14:11:00 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 2 Sep 2015 16:11:00 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <2F79F924-91BD-4297-8AA1-36A5BA51264C@arbor.net> References: <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <67DCFF67-BC56-4822-A5E5-4C96BFBA0372@arbor.net> <2F79F924-91BD-4297-8AA1-36A5BA51264C@arbor.net> Message-ID: <20150902141100.GH4116@excession.tpb.net> * rdobbins at arbor.net (Roland Dobbins) [Wed 02 Sep 2015, 01:06 CEST]: >Sure, or a VRF, or whatever. You just moved the goalposts. :> -- Niels. From rdobbins at arbor.net Wed Sep 2 14:13:19 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 21:13:19 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <659C446B-EBF9-483D-AFE6-25650551CE18@puck.nether.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> <20150902132525.GG4116@excession.tpb.net> <5E82EB15-2069-4A1A-834D-B240E836F182@arbor.net> <659C446B-EBF9-483D-AFE6-25650551CE18@puck.nether.net> Message-ID: On 2 Sep 2015, at 21:08, Jared Mauch wrote: > I see where Roland is trying to go and he?s in the ?magic byte? > realm of the extra label makes it ?OOB? where as the rest of us > just see 1?s and 0?s on the wire and know a bit is a bit > regardless of tag-switching (the original name for MPLS) or IEEE > 802.1q label. I know a bit is a bit, and it's on the same boxes and the same linecards and the same interfaces and the same RPs (if it comes to that). But keeping stuff separate at the IP logical network level is better than mixing it together, even on the same hardware. Doing it physically separately is best. ----------------------------------- Roland Dobbins From mark.tinka at seacom.mu Wed Sep 2 15:18:25 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Sep 2015 17:18:25 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> Message-ID: <55E71341.2090206@seacom.mu> On 2/Sep/15 12:11, Roland Dobbins wrote: > > > Sure. But it's better than mixing it in with customer traffic. Does not make much of a difference - it's the same data plane infrastructure. > > Ideally, it should be - that's what I was trying to get across. I > understand that this isn't free, either from a capex or opex perspective. We are in agreement. Mark. From mark.tinka at seacom.mu Wed Sep 2 15:22:38 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Sep 2015 17:22:38 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <659C446B-EBF9-483D-AFE6-25650551CE18@puck.nether.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> <20150902132525.GG4116@excession.tpb.net> <5E82EB15-2069-4A1A-834D-B240E836F182@arbor.net> <659C446B-EBF9-483D-AFE6-25650551CE18@puck.nether.net> Message-ID: <55E7143E.2050507@seacom.mu> On 2/Sep/15 16:08, Jared Mauch wrote: > It?s really because some people who drink the MPLS/VPN/VRF/VLAN kook-aid think it?s some magic that undoes fate sharing and proper engineering and planning. That a few bytes for a label of VLAN tag make your data more secure. > > It?s possible to build a network that works without all these vendor pushed tricks. I see where Roland is trying to go and he?s in the ?magic byte? realm of the extra label makes it ?OOB? where as the rest of us just see 1?s and 0?s on the wire and know a bit is a bit regardless of tag-switching (the original name for MPLS) or IEEE 802.1q label. I?m sure there are people still doing ISL but i?d rather not. There was a time when the early MPLS/VPN adopters built physically separate routers for MPLS traffic. When it became clear that this was not a good way to scale, they moved to building dedicated line cards in shared routers for MPLS/VPN's. As we see today, those that build - heaven forbid - "converged" networks tend to derive better ROI's from their network infrastructure. I'd be hard-pressed to hear from even the largest of operators physically separating MPLS and IP traffic at the hardware and/or link level. As you, Jared, say, and as I said in a previous post, both MPLS and IP traffic follows the same data plane. The routing table separation construct does not survive chassis-wide failures. Mark. From mark.tinka at seacom.mu Wed Sep 2 15:26:06 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Sep 2015 17:26:06 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> <20150902132525.GG4116@excession.tpb.net> <5E82EB15-2069-4A1A-834D-B240E836F182@arbor.net> <659C446B-EBF9-483D-AFE6-25650551CE18@puck.nether.net> Message-ID: <55E7150E.4020302@seacom.mu> On 2/Sep/15 16:13, Roland Dobbins wrote: > > > But keeping stuff separate at the IP logical network level is better > than mixing it together, even on the same hardware. But how, Roland. When the line card congests, it doesn't care that one bit was part of a VRF and the other doesn't. It all goes kaboom (even with the best of QoS intentions). Mark. From rdobbins at arbor.net Wed Sep 2 15:26:07 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 22:26:07 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E7143E.2050507@seacom.mu> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> <20150902132525.GG4116@excession.tpb.net> <5E82EB15-2069-4A1A-834D-B240E836F182@arbor.net> <659C446B-EBF9-483D-AFE6-25650551CE18@puck.nether.net> <55E7143E.2050507@seacom.mu> Message-ID: On 2 Sep 2015, at 22:22, Mark Tinka wrote: > As you, Jared, say, and as I said in a previous post, both MPLS and IP > traffic follows the same data plane. The routing table separation > construct does not survive chassis-wide failures. Everyone here understands that. We also understand that pps budgets, ASIC resources, LC-CPU resources, etc. are held in common in such scenarios. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Wed Sep 2 16:11:30 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 23:11:30 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <55E7150E.4020302@seacom.mu> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> <20150902132525.GG4116@excession.tpb.net> <5E82EB15-2069-4A1A-834D-B240E836F182@arbor.net> <659C446B-EBF9-483D-AFE6-25650551CE18@puck.nether.net> <55E7150E.4020302@seacom.mu> Message-ID: <71591DDE-EB93-431A-AF3D-60456DB0102A@arbor.net> On 2 Sep 2015, at 22:26, Mark Tinka wrote: > When the line card congests, it doesn't care that one bit was part of > a VRF and the other doesn't. It all goes kaboom (even with the best of > QoS intentions). You don't necessarily have to put everything on the same fiber, interface, the same ASIC cluster, the same LC-CPU/-NPU, the same linecard, etc. Fat-fingers in the global table or the Internet VRF or whatever won't cause problems in the management VRF, unless via route-leaking policies which allow them to do so or the kind of routing-table explosion which takes down a linecard or the whole box. A hardware casualty or software fault which takes down a linecard may not take down the whole box. And so forth. iACLs are simpler, don't have to be updated so frequently to account for moves/adds/changes of the management infrastructure. It's easier to apply QoS policies to reserve bandwidth for telemetry and other management-plane traffic, etc. And so forth. All this is highly variable and situationally-specific, but logical separation of management-plane traffic from production data-plane traffic is in general desirable, even as it's running on (at least some of) the same hardware. It isn't as good as true physical separation, but there's no sense in making the perfect the enemy of the merely good. ----------------------------------- Roland Dobbins From deleskie at gmail.com Wed Sep 2 16:20:26 2015 From: deleskie at gmail.com (jim deleskie) Date: Wed, 2 Sep 2015 13:20:26 -0300 Subject: NetFlow - path from Routers to Collector In-Reply-To: <71591DDE-EB93-431A-AF3D-60456DB0102A@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> <20150902132525.GG4116@excession.tpb.net> <5E82EB15-2069-4A1A-834D-B240E836F182@arbor.net> <659C446B-EBF9-483D-AFE6-25650551CE18@puck.nether.net> <55E7150E.4020302@seacom.mu> <71591DDE-EB93-431A-AF3D-60456DB0102A@arbor.net> Message-ID: Adding VRFs/VLAN's/anything else to separate the traffic to reduce fate sharing is only adding complexity that will likely result in operator errors. While many of us have clue, even when we don't agree on the solutions, there are many more out there typing at routers at 2am, when even the simplest of configs will mix someone up and cause an out. The stats prove out these types of errors are more likely to cause an outage then DDoS or anything else. Now if we could only build and sell devices to stop operator error. On Wed, Sep 2, 2015 at 1:11 PM, Roland Dobbins wrote: > > On 2 Sep 2015, at 22:26, Mark Tinka wrote: > > When the line card congests, it doesn't care that one bit was part of a >> VRF and the other doesn't. It all goes kaboom (even with the best of QoS >> intentions). >> > > You don't necessarily have to put everything on the same fiber, interface, > the same ASIC cluster, the same LC-CPU/-NPU, the same linecard, etc. > > Fat-fingers in the global table or the Internet VRF or whatever won't > cause problems in the management VRF, unless via route-leaking policies > which allow them to do so or the kind of routing-table explosion which > takes down a linecard or the whole box. A hardware casualty or software > fault which takes down a linecard may not take down the whole box. And so > forth. > > iACLs are simpler, don't have to be updated so frequently to account for > moves/adds/changes of the management infrastructure. It's easier to apply > QoS policies to reserve bandwidth for telemetry and other management-plane > traffic, etc. And so forth. > > All this is highly variable and situationally-specific, but logical > separation of management-plane traffic from production data-plane traffic > is in general desirable, even as it's running on (at least some of) the > same hardware. It isn't as good as true physical separation, but there's > no sense in making the perfect the enemy of the merely good. > > ----------------------------------- > Roland Dobbins > From sergevautour at yahoo.ca Wed Sep 2 16:29:39 2015 From: sergevautour at yahoo.ca (Serge Vautour) Date: Wed, 2 Sep 2015 09:29:39 -0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> Message-ID: <1441211379.54624.YahooMailBasic@web141404.mail.bf1.yahoo.com> Hello again, Well, this generated a bit more discussion than I was expecting. I've retained the following from all your comments: -Doing flow export over an OOB network can help make sure you still "see" your network during a DDoS -If we do this over an OOB network, it may not work over the OOB port on the RE/RSP. I do have some specific questions for the folks who are OK with doing this inband: -Are you concerned with someone intercepting the Flow streams? I assume if someone has the ability to do so, you've got bigger problems. -If we make the assumption that someone can intercept the Flow steam, do you think the data in the steam can be used for anything? It's just L3 & L4 headers. In other words, do you feel an OOB network is require to secure the flow data? Thanks again, your comments are very helpful. Serge -------------------------------------------- On Tue, 9/1/15, Serge Vautour wrote: Subject: NetFlow - path from Routers to Collector To: nanog at nanog.org Received: Tuesday, September 1, 2015, 12:33 PM Hello, For those than run Internet connected routers, how do you get your NetFlow data from the routers to your collectors? Do you let the flow export traffic use the same links as your customer traffic to route back to central collectors? Or do you send this traffic over private network management type path? If you send this traffic over the "Internet" (within your AS), are you worried about security? Thanks, Serge From marco at paesani.it Wed Sep 2 16:30:19 2015 From: marco at paesani.it (Marco Paesani) Date: Wed, 2 Sep 2015 18:30:19 +0200 Subject: Spotify contact Message-ID: Hi, I need a network contact for network issue in Italy. Can you help me ? Thanks ! 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 Sep 2 16:30:59 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 23:30:59 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <55E5C698.3060100@seacom.mu> <19B30342-79F2-4F57-8386-2FD3E5E446F0@arbor.net> <55E690EF.5080208@seacom.mu> <9A93964C-5832-4262-9C68-6EB8EC4B6EFD@arbor.net> <55E6C603.7040305@seacom.mu> <041109F7-87A9-4290-BA5D-36D50FC3FD93@arbor.net> <20150902132525.GG4116@excession.tpb.net> <5E82EB15-2069-4A1A-834D-B240E836F182@arbor.net> <659C446B-EBF9-483D-AFE6-25650551CE18@puck.nether.net> <55E7150E.4020302@seacom.mu> <71591DDE-EB93-431A-AF3D-60456DB0102A@arbor.net> Message-ID: <102DB67C-1699-4306-8238-2B5B7709756A@arbor.net> On 2 Sep 2015, at 23:20, jim deleskie wrote: > The stats prove out these types of errors are more likely to cause an > outage then DDoS or anything else. Completely concur that there are always complexity tradeoffs. And of course, the goal is not to have to type on routers at all, or at least minimally. Progress is being made in this arena, but as you indicate, it's unevenly distributed. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Wed Sep 2 16:32:29 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 02 Sep 2015 23:32:29 +0700 Subject: NetFlow - path from Routers to Collector In-Reply-To: <1441211379.54624.YahooMailBasic@web141404.mail.bf1.yahoo.com> References: <1441211379.54624.YahooMailBasic@web141404.mail.bf1.yahoo.com> Message-ID: <1C7F6FA3-186C-4C95-8184-F62D017872B6@arbor.net> On 2 Sep 2015, at 23:29, Serge Vautour wrote: > I assume if someone has the ability to do so, you've got bigger problems. This is the key, IMHO. ----------------------------------- Roland Dobbins From baldur.norddahl at gmail.com Wed Sep 2 17:03:20 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 2 Sep 2015 19:03:20 +0200 Subject: NetFlow - path from Routers to Collector In-Reply-To: <1441211379.54624.YahooMailBasic@web141404.mail.bf1.yahoo.com> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <1441211379.54624.YahooMailBasic@web141404.mail.bf1.yahoo.com> Message-ID: We use the VRF approach not because we think this will give us more stability ie. no fate sharing, but because it is best practice in a security perspective. We keep our internal network separated from customer traffic for the same reason our customers run firewalls. Minimize the attack surface. Customers or people from the internet should not be able to even attempt hacking the infrastructure. They should not be able to send packets that will get routed to the collector. ACLs is a poor man's solution compared to running in a VRF or equallent (vlan). Regards Baldur Den 02/09/2015 18.31 skrev "Serge Vautour" : > Hello again, > > Well, this generated a bit more discussion than I was expecting. I've > retained the following from all your comments: > > -Doing flow export over an OOB network can help make sure you still "see" > your network during a DDoS > -If we do this over an OOB network, it may not work over the OOB port on > the RE/RSP. > > I do have some specific questions for the folks who are OK with doing this > inband: > > -Are you concerned with someone intercepting the Flow streams? I assume if > someone has the ability to do so, you've got bigger problems. > -If we make the assumption that someone can intercept the Flow steam, do > you think the data in the steam can be used for anything? It's just L3 & L4 > headers. In other words, do you feel an OOB network is require to secure > the flow data? > > Thanks again, your comments are very helpful. > > Serge > > -------------------------------------------- > On Tue, 9/1/15, Serge Vautour wrote: > > Subject: NetFlow - path from Routers to Collector > To: nanog at nanog.org > Received: Tuesday, September 1, 2015, 12:33 PM > > Hello, > > For those than run Internet connected routers, how do you > get your NetFlow data from the routers to your collectors? > Do you let the flow export traffic use the same links as > your customer traffic to route back to central collectors? > Or do you send this traffic over private network management > type path? If you send this traffic over the "Internet" > (within your AS), are you worried about security? > > Thanks, > Serge > > From saamato at frontiernet.net Wed Sep 2 19:31:42 2015 From: saamato at frontiernet.net (=?UTF-8?Q?=C3=AF=C2=BB=C2=BFStephen_Amato?=) Date: Wed, 2 Sep 2015 19:31:42 +0000 (UTC) Subject: Level 3 (former TW Telecom) Routing Contact Message-ID: <1337467847.609128.1441222302975.JavaMail.yahoo@mail.yahoo.com> Can someone from Level 3 (former TW Telecom) please contact me off-list regarding a possible routing issue with some 172.0.0.0/8 IP space (non RFC 1918)? Thank you,S.Amato saamato at frontiernet.net From saku at ytti.fi Thu Sep 3 10:56:50 2015 From: saku at ytti.fi (Saku Ytti) Date: Thu, 3 Sep 2015 13:56:50 +0300 Subject: buffer bloat and packet pacing Message-ID: Hey, In past few years there's been lot of talk about reducing buffer depths, and many seem to think vendors are throwing memory on the chips for the fun of it. If we look at some particularly pathological case. Let's assume sender is CDN network with 40GE connected server and receiver is 10GE connected. There is 300ms latency between them. 10Gbps * 300ms = 375MB, is the window size the client wants to be able to fill its pipe to the 40GE sender. However TCP does not normally pace packets inside the window, so 40GE server will flood the window as fast as it can, instead of limiting itself to 10Gbps, optimally it'll send at linerate. While receiver can only serialise them 10GE out, causing majority of that 375MB ending up in the sender side switch/router buffers. If we can't buffer that, then the receiver cannot receive at 10Gbps, as window size will shrink. Is this a problem? What rate should you be able to expect to get and at what latency? Usually contracts to customers won't have any limitations on bandwidth achievable on given latency and writing such down might make you appear inferior to your competitor. Perhaps this is unrealistic case, however if you run the numbers in much less pathological cases, you'll still end up having much larger buffer needs than large number of switch chips out there have. Some new ones, like JNPR QFX10k and Broadcom Jericho come with much larger buffers than predecessors, and will be able to deal with what I hope are most practical cases. Linux actually these days does have bandwidth estimator for TCP sessions, but it's not used by default for anything, it's just for consumption for other layers so they can do something about it. And I believe in 'tc' you can use these to cause packet pacing inside a window. QUIC and MinimaLT, AFAIK, do bandwidth estimation and packet pacing by default. In perfect world, we'd be done now. Receiver side switch can do with very small buffers, few packets should suffice. However, if network itself is congested, the bandwidth estimation keeps sinking, and these well-behaved streams are losing to the aggressive TCP streams, and you'll end up having 0bps estimations. So perhaps the bandwidth estimator should be application aware, and never report lower estimate than what is practical for given application, so that it could compete fairly with aggressive streams, up-to required rate. Information I'd love to have, is how large window sizes do TCP sessions peak at, in real network? Some CDN network must be collecting these stats. I'd love to see rough statistics. <1% go over 100MB? 2% between 50MB-100MB? ... few large brackets of distribution of window sizes by some CDN offering content download (GGC, OpenConnect are not interesting, as they won't send large files). Also, are some CDN's already implementing packet pacing inside window? If so, how? Do they have lower limit to it? Some related URLs: https://lwn.net/Articles/645115/ https://lwn.net/Articles/564978/ http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-6.pdf http://www.ietf.org/proceedings/84/slides/slides-84-iccrg-2.pdf -- ++ytti From saku at ytti.fi Thu Sep 3 10:59:21 2015 From: saku at ytti.fi (Saku Ytti) Date: Thu, 3 Sep 2015 13:59:21 +0300 Subject: buffer bloat and packet pacing In-Reply-To: References: Message-ID: > only serialise them 10GE out, causing majority of that 375MB ending up > in the sender side switch/router buffers. s/sender/receiver/ -- ++ytti From nick at foobar.org Thu Sep 3 12:04:34 2015 From: nick at foobar.org (Nick Hilliard) Date: Thu, 3 Sep 2015 13:04:34 +0100 Subject: buffer bloat and packet pacing In-Reply-To: References: Message-ID: <55E83752.8020206@foobar.org> On 03/09/2015 11:56, Saku Ytti wrote: > 40GE server will flood the window as fast as it can, instead of > limiting itself to 10Gbps, optimally it'll send at linerate. optimally, but tcp slow start will generally stop this from happening on well behaved sending-side stacks so you send up ramping up quickly to path rate rather than egress line rate from the sender side. Also, regardless of an individual flow's buffering requirements, the intermediate path will be catering with large numbers of flows, so while it's interesting to talk about 375mb of intermediate path buffers, this is shared buffer space and any attempt on the part of an individual sender to (ab)use the entire path buffer will end up causing RED/WRED for everyone else. Otherwise, this would be a fascinating talk if people had real world data. Nick From saku at ytti.fi Thu Sep 3 12:19:47 2015 From: saku at ytti.fi (Saku Ytti) Date: Thu, 3 Sep 2015 15:19:47 +0300 Subject: buffer bloat and packet pacing In-Reply-To: <55E83752.8020206@foobar.org> References: <55E83752.8020206@foobar.org> Message-ID: On 3 September 2015 at 15:04, Nick Hilliard wrote: > optimally, but tcp slow start will generally stop this from happening on > well behaved sending-side stacks so you send up ramping up quickly to path > rate rather than egress line rate from the sender side. This assumes network is congested and unable to reach its potential rate. If it can reach its potential rate, eventually the window will scale to 375MB and the pathological flooding will occur. Mostly network is congested, and the pathological case cannot happen, as the egress cannot ingest the floods, not allowing window to grow to needed size, which also means the potential rate will not be reached, and rate will be something less than 10Gbps. Essentially we threw the baby out with the bath water, kind of like protecting from DoS by killing the victim. -- ++ytti From rwebb at ropeguru.com Thu Sep 3 13:35:04 2015 From: rwebb at ropeguru.com (Robert Webb) Date: Thu, 03 Sep 2015 09:35:04 -0400 Subject: udp 500 packets when users are web browsing Message-ID: We are seeing udp 500 packets being dropped at our firewall from user's browsing sessions. These are users on a 2008 R2 AD setup with Windows 7. Source and destination ports are udp 500 and the the pattern of drops directly correlate to the web browsing activity. We have confirmed this with tcpdump of port 500 and a single host and watching the pattern of traffic as they browse. This also occurs no matter what browser is used. Can anyone shine some light on what may be using udp 500 when web browsing? Robert From bzeeb-lists at lists.zabbadoz.net Thu Sep 3 13:42:21 2015 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu, 3 Sep 2015 13:42:21 +0000 Subject: udp 500 packets when users are web browsing In-Reply-To: References: Message-ID: > On 03 Sep 2015, at 13:35 , Robert Webb wrote: > > We are seeing udp 500 packets being dropped at our firewall from user's browsing sessions. These are users on a 2008 R2 AD setup with Windows 7. > > Source and destination ports are udp 500 and the the pattern of drops directly correlate to the web browsing activity. We have confirmed this with tcpdump of port 500 and a single host and watching the pattern of traffic as they browse. This also occurs no matter what browser is used. > > Can anyone shine some light on what may be using udp 500 when web browsing? The VPN using IPsec UDP-Encap connection that supposedly gets through NAT? Have you checked the content with tcpdump? Do you have fragments by any chance? From rwebb at ropeguru.com Thu Sep 3 13:53:46 2015 From: rwebb at ropeguru.com (Robert Webb) Date: Thu, 03 Sep 2015 09:53:46 -0400 Subject: udp 500 packets when users are web browsing In-Reply-To: References: Message-ID: There is no VPN in the picture here. These are straight workstations on the network that the packets are coming from. According to a pcaket capture in wireshark, these are isakmp packets reaching out to host names of web sites that are being browsed. So destinations are sites like twitter, facebook, amazon, cnn, etc.. We have further discovered that they seem to be initiated from the Windows 7 svchost, but we have not been able to find documentation as to how or why this is ocurring. Robert On Thu, 3 Sep 2015 13:42:21 +0000 "Bjoern A. Zeeb" wrote: > >> On 03 Sep 2015, at 13:35 , Robert Webb wrote: >> >> We are seeing udp 500 packets being dropped at our firewall from >>user's browsing sessions. These are users on a 2008 R2 AD setup with >>Windows 7. >> >> Source and destination ports are udp 500 and the the pattern of >>drops directly correlate to the web browsing activity. We have >>confirmed this with tcpdump of port 500 and a single host and >>watching the pattern of traffic as they browse. This also occurs no >>matter what browser is used. >> >> Can anyone shine some light on what may be using udp 500 when web >>browsing? > > The VPN using IPsec UDP-Encap connection that supposedly gets >through NAT? Have you checked the content with tcpdump? Do you >have fragments by any chance? > > From cra at WPI.EDU Thu Sep 3 14:14:24 2015 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 3 Sep 2015 10:14:24 -0400 Subject: udp 500 packets when users are web browsing In-Reply-To: References: Message-ID: <20150903141423.GZ22990@angus.ind.WPI.EDU> Sounds like Opportunistic Encryption. https://en.wikipedia.org/wiki/Opportunistic_encryption#Windows_OS On Thu, Sep 03, 2015 at 09:53:46AM -0400, Robert Webb wrote: > There is no VPN in the picture here. These are straight workstations > on the network that the packets are coming from. > > According to a pcaket capture in wireshark, these are isakmp packets > reaching out to host names of web sites that are being browsed. So > destinations are sites like twitter, facebook, amazon, cnn, etc.. > > We have further discovered that they seem to be initiated from the > Windows 7 svchost, but we have not been able to find documentation > as to how or why this is ocurring. > > Robert > > > On Thu, 3 Sep 2015 13:42:21 +0000 > "Bjoern A. Zeeb" wrote: > > > >>On 03 Sep 2015, at 13:35 , Robert Webb wrote: > >> > >>We are seeing udp 500 packets being dropped at our firewall from > >>user's browsing sessions. These are users on a 2008 R2 AD setup > >>with Windows 7. > >> > >>Source and destination ports are udp 500 and the the pattern of > >>drops directly correlate to the web browsing activity. We have > >>confirmed this with tcpdump of port 500 and a single host and > >>watching the pattern of traffic as they browse. This also occurs > >>no matter what browser is used. > >> > >>Can anyone shine some light on what may be using udp 500 when > >>web browsing? > > > >The VPN using IPsec UDP-Encap connection that supposedly gets > >through NAT? Have you checked the content with tcpdump? Do you > >have fragments by any chance? From oliver.oboyle at gmail.com Thu Sep 3 14:19:53 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 3 Sep 2015 10:19:53 -0400 Subject: udp 500 packets when users are web browsing In-Reply-To: References: Message-ID: You can configure Windows to encrypt traffic based on protocol definitions. E.g., Use IPSEC to encrypt all traffic on port 80 between hosts X and hosts Y. It's possible that such a policy is in place locally on the workstations and/or servers and it's also possible that it's being enforced using GPOs. On Thu, Sep 3, 2015 at 9:53 AM, Robert Webb wrote: > There is no VPN in the picture here. These are straight workstations on > the network that the packets are coming from. > > According to a pcaket capture in wireshark, these are isakmp packets > reaching out to host names of web sites that are being browsed. So > destinations are sites like twitter, facebook, amazon, cnn, etc.. > > We have further discovered that they seem to be initiated from the Windows > 7 svchost, but we have not been able to find documentation as to how or why > this is ocurring. > > Robert > > > > On Thu, 3 Sep 2015 13:42:21 +0000 > "Bjoern A. Zeeb" wrote: > >> >> On 03 Sep 2015, at 13:35 , Robert Webb wrote: >>> >>> We are seeing udp 500 packets being dropped at our firewall from user's >>> browsing sessions. These are users on a 2008 R2 AD setup with Windows 7. >>> >>> Source and destination ports are udp 500 and the the pattern of drops >>> directly correlate to the web browsing activity. We have confirmed this >>> with tcpdump of port 500 and a single host and watching the pattern of >>> traffic as they browse. This also occurs no matter what browser is used. >>> >>> Can anyone shine some light on what may be using udp 500 when web >>> browsing? >>> >> >> The VPN using IPsec UDP-Encap connection that supposedly gets through >> NAT? Have you checked the content with tcpdump? Do you have fragments >> by any chance? >> >> >> > > -- :o@> From oliver.oboyle at gmail.com Thu Sep 3 14:20:50 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 3 Sep 2015 10:20:50 -0400 Subject: udp 500 packets when users are web browsing In-Reply-To: <20150903141423.GZ22990@angus.ind.WPI.EDU> References: <20150903141423.GZ22990@angus.ind.WPI.EDU> Message-ID: Precisely. On Thu, Sep 3, 2015 at 10:14 AM, Chuck Anderson wrote: > Sounds like Opportunistic Encryption. > > https://en.wikipedia.org/wiki/Opportunistic_encryption#Windows_OS > > On Thu, Sep 03, 2015 at 09:53:46AM -0400, Robert Webb wrote: > > There is no VPN in the picture here. These are straight workstations > > on the network that the packets are coming from. > > > > According to a pcaket capture in wireshark, these are isakmp packets > > reaching out to host names of web sites that are being browsed. So > > destinations are sites like twitter, facebook, amazon, cnn, etc.. > > > > We have further discovered that they seem to be initiated from the > > Windows 7 svchost, but we have not been able to find documentation > > as to how or why this is ocurring. > > > > Robert > > > > > > On Thu, 3 Sep 2015 13:42:21 +0000 > > "Bjoern A. Zeeb" wrote: > > > > > >>On 03 Sep 2015, at 13:35 , Robert Webb wrote: > > >> > > >>We are seeing udp 500 packets being dropped at our firewall from > > >>user's browsing sessions. These are users on a 2008 R2 AD setup > > >>with Windows 7. > > >> > > >>Source and destination ports are udp 500 and the the pattern of > > >>drops directly correlate to the web browsing activity. We have > > >>confirmed this with tcpdump of port 500 and a single host and > > >>watching the pattern of traffic as they browse. This also occurs > > >>no matter what browser is used. > > >> > > >>Can anyone shine some light on what may be using udp 500 when > > >>web browsing? > > > > > >The VPN using IPsec UDP-Encap connection that supposedly gets > > >through NAT? Have you checked the content with tcpdump? Do you > > >have fragments by any chance? > -- :o@> From rwebb at ropeguru.com Thu Sep 3 14:25:52 2015 From: rwebb at ropeguru.com (Robert Webb) Date: Thu, 03 Sep 2015 10:25:52 -0400 Subject: udp 500 packets when users are web browsing In-Reply-To: References: Message-ID: Yes, we are looking at this now. Thanks for everyone's help. I think we are heading in the right direction tracking this down. This just showed up in our monitoring and makes sense as we just brought up a new locked down domain. Robert On Thu, 3 Sep 2015 10:19:53 -0400 "Oliver O'Boyle" wrote: > You can configure Windows to encrypt traffic based on protocol >definitions. > E.g., Use IPSEC to encrypt all traffic on port 80 between hosts X >and hosts > Y. > > It's possible that such a policy is in place locally on the >workstations > and/or servers and it's also possible that it's being enforced using >GPOs. > > On Thu, Sep 3, 2015 at 9:53 AM, Robert Webb >wrote: > >> There is no VPN in the picture here. These are straight workstations >>on >> the network that the packets are coming from. >> >> According to a pcaket capture in wireshark, these are isakmp packets >> reaching out to host names of web sites that are being browsed. So >> destinations are sites like twitter, facebook, amazon, cnn, etc.. >> >> We have further discovered that they seem to be initiated from the >>Windows >> 7 svchost, but we have not been able to find documentation as to how >>or why >> this is ocurring. >> >> Robert >> >> >> On Thu, 3 Sep 2015 13:42:21 +0000 >> "Bjoern A. Zeeb" wrote: >> >>> >>> On 03 Sep 2015, at 13:35 , Robert Webb wrote: >>>> >>>> We are seeing udp 500 packets being dropped at our firewall from >>>>user's >>>> browsing sessions. These are users on a 2008 R2 AD setup with >>>>Windows 7. >>>> >>>> Source and destination ports are udp 500 and the the pattern of >>>>drops >>>> directly correlate to the web browsing activity. We have confirmed >>>>this >>>> with tcpdump of port 500 and a single host and watching the pattern >>>>of >>>> traffic as they browse. This also occurs no matter what browser is >>>>used. >>>> >>>> Can anyone shine some light on what may be using udp 500 when web >>>> browsing? >>>> >>> >>> The VPN using IPsec UDP-Encap connection that supposedly gets >>>through >>> NAT? Have you checked the content with tcpdump? Do you have >>>fragments >>> by any chance? >>> >>> > -- > :o@> From oliver.oboyle at gmail.com Thu Sep 3 14:26:59 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 3 Sep 2015 10:26:59 -0400 Subject: udp 500 packets when users are web browsing In-Reply-To: References: Message-ID: That would do it. Almost certainly enforced by GPO in that case so at least it's easy to change if you need to. On Thu, Sep 3, 2015 at 10:25 AM, Robert Webb wrote: > Yes, we are looking at this now. > > Thanks for everyone's help. I think we are heading in the right direction > tracking this down. This just showed up in our monitoring and makes sense > as we just brought up a new locked down domain. > > Robert > > > > On Thu, 3 Sep 2015 10:19:53 -0400 > "Oliver O'Boyle" wrote: > >> You can configure Windows to encrypt traffic based on protocol >> definitions. >> E.g., Use IPSEC to encrypt all traffic on port 80 between hosts X and >> hosts >> Y. >> >> It's possible that such a policy is in place locally on the workstations >> and/or servers and it's also possible that it's being enforced using GPOs. >> >> On Thu, Sep 3, 2015 at 9:53 AM, Robert Webb wrote: >> >> There is no VPN in the picture here. These are straight workstations on >>> the network that the packets are coming from. >>> >>> According to a pcaket capture in wireshark, these are isakmp packets >>> reaching out to host names of web sites that are being browsed. So >>> destinations are sites like twitter, facebook, amazon, cnn, etc.. >>> >>> We have further discovered that they seem to be initiated from the >>> Windows >>> 7 svchost, but we have not been able to find documentation as to how or >>> why >>> this is ocurring. >>> >>> Robert >>> >>> >>> On Thu, 3 Sep 2015 13:42:21 +0000 >>> "Bjoern A. Zeeb" wrote: >>> >>> >>>> On 03 Sep 2015, at 13:35 , Robert Webb wrote: >>>> >>>>> >>>>> We are seeing udp 500 packets being dropped at our firewall from user's >>>>> browsing sessions. These are users on a 2008 R2 AD setup with Windows >>>>> 7. >>>>> >>>>> Source and destination ports are udp 500 and the the pattern of drops >>>>> directly correlate to the web browsing activity. We have confirmed this >>>>> with tcpdump of port 500 and a single host and watching the pattern of >>>>> traffic as they browse. This also occurs no matter what browser is >>>>> used. >>>>> >>>>> Can anyone shine some light on what may be using udp 500 when web >>>>> browsing? >>>>> >>>>> >>>> The VPN using IPsec UDP-Encap connection that supposedly gets through >>>> NAT? Have you checked the content with tcpdump? Do you have >>>> fragments >>>> by any chance? >>>> >>>> >>>> -- >> :o@> >> > > > -- :o@> From rbf+nanog at panix.com Thu Sep 3 14:36:38 2015 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Thu, 3 Sep 2015 09:36:38 -0500 Subject: buffer bloat and packet pacing In-Reply-To: <55E83752.8020206@foobar.org> References: <55E83752.8020206@foobar.org> Message-ID: <20150903143638.GA7591@panix.com> On Thu, Sep 03, 2015 at 01:04:34PM +0100, Nick Hilliard wrote: > On 03/09/2015 11:56, Saku Ytti wrote: > > 40GE server will flood the window as fast as it can, instead of > > limiting itself to 10Gbps, optimally it'll send at linerate. > > optimally, but tcp slow start will generally stop this from happening on > well behaved sending-side stacks so you send up ramping up quickly to path > rate rather than egress line rate from the sender side. Also, regardless > of an individual flow's buffering requirements, the intermediate path will > be catering with large numbers of flows, so while it's interesting to talk > about 375mb of intermediate path buffers, this is shared buffer space and > any attempt on the part of an individual sender to (ab)use the entire path > buffer will end up causing RED/WRED for everyone else. > > Otherwise, this would be a fascinating talk if people had real world data. The original analysis is flawed because it assumes latency is constant. Any analysis has to include the fact that buffering changes latency. If you start with a 300ms path (by propogation delay, switching latency, hetc.), and 375MB of buffers on a 10G port, then, when the buffers fill, you end up with a 600ms path[1]. And a 375MB window is no longer sufficient to keep the pipe full. Instead, you need a 750MB buffer. But now the latency is 900ms. And so on. This doesn't converge. Every byte of filled buffer is another byte you need in the window if you're going to fill the pipe. Not accounting for this is part of the reason the original analysis is flawed. The end result is that you always run out of window or run out of buffer (causing packet loss). Here's a paper that shows you don't need buffers equal to bandwidth*delay to get near capacity: http://www.cs.bu.edu/~matta/Papers/hstcp-globecom04.pdf (I'm not endorsing it. Just pointing out it out as a datapoint.) -- Brett [1] 0.300 + 375E6 * 8 / 10E9 = 600ms From saku at ytti.fi Thu Sep 3 14:48:00 2015 From: saku at ytti.fi (Saku Ytti) Date: Thu, 3 Sep 2015 17:48:00 +0300 Subject: buffer bloat and packet pacing In-Reply-To: <20150903143638.GA7591@panix.com> References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> Message-ID: Hey Brett, > Here's a paper that shows you don't need buffers equal to > bandwidth*delay to get near capacity: > http://www.cs.bu.edu/~matta/Papers/hstcp-globecom04.pdf > (I'm not endorsing it. Just pointing out it out as a datapoint.) Quick glance makes me believe the S and D nodes are equal bandwidth, but only R1-R2 bandwidth is explicitly stated.S1, D1, Sn, Dn are only ever mentioned in the topology. If Sender is same or lower rate than Destination, then we really shouldn't need almost any buffering. Issue should only come when Sender is significantly higher rate than Destination and network is not limiting them. -- ++ytti From reichert at numachi.com Thu Sep 3 14:39:56 2015 From: reichert at numachi.com (Brian Reichert) Date: Thu, 3 Sep 2015 10:39:56 -0400 Subject: Whois.net down? Message-ID: <20150903143956.GH78209@numachi.com> I'm trying to use https://www.whois.net/ to resolve info about several domains, including my own (NUMACHI.COM). For several domains (but not all, I get 'Error extracting data. No data available'. There's a 'please read' tag, but no text associated with it. Anyone know if they're having issues there? -- Brian Reichert BSD admin/developer at large From rbf+nanog at panix.com Thu Sep 3 18:13:14 2015 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Thu, 3 Sep 2015 13:13:14 -0500 Subject: buffer bloat and packet pacing In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> Message-ID: <20150903181313.GA16116@panix.com> On Thu, Sep 03, 2015 at 05:48:00PM +0300, Saku Ytti wrote: > Hey Brett, > > > Here's a paper that shows you don't need buffers equal to > > bandwidth*delay to get near capacity: > > http://www.cs.bu.edu/~matta/Papers/hstcp-globecom04.pdf > > (I'm not endorsing it. Just pointing out it out as a datapoint.) > > Quick glance makes me believe the S and D nodes are equal bandwidth, > but only R1-R2 bandwidth is explicitly stated.S1, D1, Sn, Dn are only > ever mentioned in the topology. If Sender is same or lower rate than > Destination, then we really shouldn't need almost any buffering. Unless Sender is higher than R1-R2. > Issue should only come when Sender is significantly higher rate than > Destination and network is not limiting them. I didn't read it in detail either, but at first glance, it appears to me that the model is infinite bandwidth and zero latency between S and R1, and D and R2, with queueing happening in R1. That's not going to give materially different results than, having S-R1 be 4 times R1-R2, and R2-D being the same as R1-R2. So it fits well with the original discussion here of 40G into 10G. -- Brett From reichert at numachi.com Thu Sep 3 19:25:59 2015 From: reichert at numachi.com (Brian Reichert) Date: Thu, 3 Sep 2015 15:25:59 -0400 Subject: Whois.net down? In-Reply-To: References: <20150903143956.GH78209@numachi.com> Message-ID: <20150903192559.GI78209@numachi.com> On Thu, Sep 03, 2015 at 09:59:02PM +0700, David S. wrote: > Hi Brian, > > I'm able to access https://whois.net, have you check the nameserver of > numachi.com? > Is the other domain use same authoritative DNS? I can access the web page. When I use the page for certain domains, sometimes, I successfully get results. Other domains, such as NUMACHI.COM, I get the error I reported. CLI-based versions of whois work just fine for all domains I'm concerned about; it's that web-baed version that is selectively failing. > Best regards, > David S. -- Brian Reichert BSD admin/developer at large From saper at saper.info Thu Sep 3 19:57:55 2015 From: saper at saper.info (Marcin Cieslak) Date: Thu, 3 Sep 2015 19:57:55 +0000 Subject: Whois.net down? In-Reply-To: <20150903192559.GI78209@numachi.com> References: <20150903143956.GH78209@numachi.com> <20150903192559.GI78209@numachi.com> Message-ID: On Thu, 3 Sep 2015, Brian Reichert wrote: > On Thu, Sep 03, 2015 at 09:59:02PM +0700, David S. wrote: > > Hi Brian, > > > > I'm able to access https://whois.net, have you check the nameserver of > > numachi.com? > > Is the other domain use same authoritative DNS? > > I can access the web page. When I use the page for certain domains, > sometimes, I successfully get results. > > Other domains, such as NUMACHI.COM, I get the error I reported. > > CLI-based versions of whois work just fine for all domains I'm > concerned about; it's that web-baed version that is selectively > failing. whois.net is some site operated by NTT/Verio, this domain tech contact seems to be: Tech Name: Verio Hostmaster Tech Organization: Tech Street: 8005 S. Chester Street Suite 200 Tech City: Englewood Tech State/Province: CO Tech Postal Code: 80112 Tech Country: US Tech Phone: +1.2142908620 Tech Phone Ext: Tech Fax: +1.2147451877 Tech Fax Ext: Tech Email: hostmaster at verio.net although you might have better chance via Twitter https://twitter.com/WhoisNet :( ~Marcin From reichert at numachi.com Thu Sep 3 20:44:27 2015 From: reichert at numachi.com (Brian Reichert) Date: Thu, 3 Sep 2015 16:44:27 -0400 Subject: Whois.net down? In-Reply-To: References: <20150903143956.GH78209@numachi.com> <20150903192559.GI78209@numachi.com> Message-ID: <20150903204427.GK78209@numachi.com> On Thu, Sep 03, 2015 at 07:57:55PM +0000, Marcin Cieslak wrote: > whois.net is some site operated by NTT/Verio, > this domain tech contact seems to be: > > Tech Name: Verio Hostmaster > Tech Organization: > Tech Street: 8005 S. Chester Street Suite 200 > Tech City: Englewood > Tech State/Province: CO > Tech Postal Code: 80112 > Tech Country: US > Tech Phone: +1.2142908620 > Tech Phone Ext: > Tech Fax: +1.2147451877 > Tech Fax Ext: > Tech Email: hostmaster at verio.net > > although you might have better chance via Twitter > https://twitter.com/WhoisNet :( Thanks for the suggestion. :) > ~Marcin -- Brian Reichert BSD admin/developer at large From sandy at tislabs.com Thu Sep 3 22:26:33 2015 From: sandy at tislabs.com (Sandra Murphy) Date: Thu, 3 Sep 2015 18:26:33 -0400 Subject: Note - ARIN Consultation on proposed Registration Services Agreement Now Open In-Reply-To: References: <55B931B3.30406@arin.net> Message-ID: <6DE37476-591B-4D34-9B34-89457FA50A60@tislabs.com> There?s been no comment on this announcement on this list, but there were a small handful of NANOGers who energetically discussed this on the arin-consult list starting mid-August. On the last day of the comment period (so you might have missed it), a detailed comment was submitted, which focussed on the impact to legacy resource holders and those who acquire addresses in the transfer market. I?m not sure how many people on this list would have been following a discussion of the ARIN RSA, but there might be some who would find legacy and transfer focussed comments to be interesting. So in case you missed it: General discussion: http://lists.arin.net/pipermail/arin-consult/2015-August/date.html Focussed comment: http://lists.arin.net/pipermail/arin-consult/2015-August/000662.html ?Sandy On Jul 29, 2015, at 4:11 PM, John Curran wrote: > NANOGers - > > To the extent that you are interested in ARIN's Registration Services Agreement, we have > just initiated a consultation on a proposed new version of the RSA (and LRSA) as noted in > the attached announcement. If you wish to provide any feedback, please do so on the > > mailing list between now and 30 August 2015. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > Begin forwarded message: > > From: ARIN > > Subject: [ARIN-consult] Consultation on Registration Services Agreement Now Open > Date: July 29, 2015 at 4:04:03 PM EDT > To: > > > ARIN is seeking community input on a new version of the Registration > Services Agreement that combines the existing Registration Services > Agreement (RSA) and Legacy Registration Services Agreement (LRSA) into a > single agreement (?RSA Version 12.0/LRSA Version 4.0?). > > Following community consultation and finalization, ARIN will provide > services to new parties per this latest version of the Registration > Services Agreement. Existing holders of Internet number resources will > have the opportunity to upgrade to this new version of the Registration > Services Agreement or remain with their current Registration Services > Agreement. > > There are notable and substantive changes with this new version > incorporating input received from the community on the Registration > Services Agreements. > > These changes include: > > * Clarifying that the agreement is only applicable to ?Included Number > Resources? (i.e. the Internet number resources pursuant to the > agreement, not any other number resources that parties may hold under > other agreements or no agreement) > * Similarly clarifying that the provision wherein a Customer is > agreeing that ?Included Number Resources? are not property is only > applicable to ?Included Number Resources? in the agreement and remains > silent with regard to any other number resources held by the party > * Providing uniform service terms and conditions (other than fees) for all > customers receiving services from ARIN > * Elaborating on the definition of ARIN?s services that are covered by > the agreement, including resource certification > * Providing a more balanced agreement with respect to term language > previously seen as favorable to ARIN > > The new RSA Version 12.0/LRSA Version 4.0 is available at the following URL: > > https://www.arin.net/resources/agreements/rsa_draft_ver12.pdf > > We strongly encourage you to review the current RSA and LRSA against the > proposed version of this new agreement and to submit your constructive > comments to arin-consult at arin.net. > > Discussion on arin-consult at arin.net will close on 30 August 2015. ARIN > seeks clear direction through community input, so your feedback is > important. If you have any questions, please contact us at info at arin.net. > > > Thank you, > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nanog at ics-il.net Fri Sep 4 13:32:42 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 4 Sep 2015 08:32:42 -0500 (CDT) Subject: ARIN IRR Message-ID: <925603123.437.1441373619197.JavaMail.mhammett@ThunderFuck> I'm not here to debate how awesome or poor ARIN's IRR is. I've created my first objects in there, verified they exist via the ARIN RR whois and seen them show up in IRR Explorer. How do I verify that I've actually done them all correctly? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com From job at instituut.net Fri Sep 4 13:38:21 2015 From: job at instituut.net (Job Snijders) Date: Fri, 4 Sep 2015 15:38:21 +0200 Subject: ARIN IRR In-Reply-To: <925603123.437.1441373619197.JavaMail.mhammett@ThunderFuck> References: <925603123.437.1441373619197.JavaMail.mhammett@ThunderFuck> Message-ID: <20150904133821.GH840@Hanna.local> On Fri, Sep 04, 2015 at 08:32:42AM -0500, Mike Hammett wrote: > I'm not here to debate how awesome or poor ARIN's IRR is. > > I've created my first objects in there, verified they exist via the > ARIN RR whois and seen them show up in IRR Explorer. How do I verify > that I've actually done them all correctly? You can input your AS number to look for more hints: http://irrexplorer.nlnog.net/search/15562 Kind regards, Job From Rod.Beck at hibernianetworks.com Fri Sep 4 14:40:31 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Fri, 4 Sep 2015 14:40:31 +0000 Subject: Software Defined Networking In-Reply-To: <20150903181313.GA16116@panix.com> References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> , <20150903181313.GA16116@panix.com> Message-ID: Can anyone provide references on this top so I can educate myself? This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From jethro.binks at strath.ac.uk Fri Sep 4 14:58:30 2015 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Fri, 4 Sep 2015 15:58:30 +0100 (BST) Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> , <20150903181313.GA16116@panix.com> Message-ID: About every edition of Packet Pushers Podcast for the last 18 months would be a good start probably. That'll keep you busy. Jethro. On Fri, 4 Sep 2015, Rod Beck wrote: > Can anyone provide references on this top so I can educate myself? > > This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. > . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From N.Kacha at lboro.ac.uk Fri Sep 4 15:00:25 2015 From: N.Kacha at lboro.ac.uk (Niraj Kacha) Date: Fri, 4 Sep 2015 15:00:25 +0000 Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> Message-ID: <20D6B20E-6315-4E0E-A10B-EB8E7DB51FD8@lboro.ac.uk> > On 4 Sep 2015, at 15:40, Rod Beck wrote: > > Can anyone provide references on this top so I can educate myself? This might be of help http://packetpushers.net/sdn-network-virtualization-hypervisors/ Niraj ---------------------- Niraj Kacha Network Security Loughborough University -------------- 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 jtk at cymru.com Fri Sep 4 16:25:49 2015 From: jtk at cymru.com (John Kristoff) Date: Fri, 4 Sep 2015 11:25:49 -0500 Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> Message-ID: <20150904112549.6b010c43@localhost> On Fri, 4 Sep 2015 14:40:31 +0000 Rod Beck wrote: > Can anyone provide references on this top so I can educate myself? A bit more effort will be required on your part to get the most out it, but one potentially in depth resource would be Nick Feamster's Software Defined Networking course, currently available through Coursera: John From nogs at border6.com Fri Sep 4 17:23:46 2015 From: nogs at border6.com (Pawel Rybczyk) Date: Fri, 4 Sep 2015 19:23:46 +0200 Subject: Software Defined Networking In-Reply-To: <10994-b6.nogs.nanog-04092015144505-40@news.border6.com> References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <10994-b6.nogs.nanog-04092015144505-40@news.border6.com> Message-ID: <55E9D3A2.4070004@border6.com> Hi Rod, Ivan's Pepelnjak blog is good source of information about SDN (and what it is not). Blog link: http://blog.ipspace.net/search/label/SDN Ivan's presentation at last RIPE meeting in Amsterdam: Software Defined Networks - Four Years Later https://youtu.be/z-NW3GIFyss Cheers, Pawel On 09/04/2015 04:40 PM, Rod Beck wrote: > Can anyone provide references on this top so I can educate myself? > > This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. > From larrysheldon at cox.net Fri Sep 4 17:47:13 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 4 Sep 2015 12:47:13 -0500 Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> Message-ID: <55E9D921.6090506@cox.net> On 9/4/2015 09:40, Rod Beck wrote: > Can anyone provide references on this top so I can educate myself? > > This e-mail and any attachments thereto is intended only for use by > the addressee(s) named herein and may be proprietary and/or legally > privileged. If you are not the intended recipient of this e-mail, you > are hereby notified that any dissemination, distribution or copying > of this email, and any attachments thereto, without the prior written > permission of the sender is strictly prohibited. If you receive this > e-mail in error, please immediately telephone or e-mail the sender > and permanently delete the original copy and any copy of this e-mail, > and any printout thereof. All documents, contracts or agreements > referred or attached to this e-mail are SUBJECT TO CONTRACT. The > contents of an attachment to this e-mail may contain software viruses > that could damage your own computer system. While Hibernia Networks > has taken every reasonable precaution to minimize this risk, we > cannot accept liability for any damage that you sustain as a result > of software viruses. You should carry out your own virus checks > before opening any attachment. > All of that for 11 1/2 words? Ineducable. -- sed quis custodiet ipsos custodes? (Juvenal) From aaron at heyaaron.com Fri Sep 4 17:57:26 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 4 Sep 2015 10:57:26 -0700 Subject: Software Defined Networking In-Reply-To: <55E9D921.6090506@cox.net> References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <55E9D921.6090506@cox.net> Message-ID: I think it's time to change my SMTP greeting to: 220-By submitting e-mail to this server, you agree all legal disclaimers are null and void. 220 You also agree that I am awesome. -A On Fri, Sep 4, 2015 at 10:47 AM, Larry Sheldon wrote: > On 9/4/2015 09:40, Rod Beck wrote: >> >> Can anyone provide references on this top so I can educate myself? >> >> This e-mail and any attachments thereto is intended only for use by >> the addressee(s) named herein and may be proprietary and/or legally >> privileged. If you are not the intended recipient of this e-mail, you >> are hereby notified that any dissemination, distribution or copying >> of this email, and any attachments thereto, without the prior written >> permission of the sender is strictly prohibited. If you receive this >> e-mail in error, please immediately telephone or e-mail the sender >> and permanently delete the original copy and any copy of this e-mail, >> and any printout thereof. All documents, contracts or agreements >> referred or attached to this e-mail are SUBJECT TO CONTRACT. The >> contents of an attachment to this e-mail may contain software viruses >> that could damage your own computer system. While Hibernia Networks >> has taken every reasonable precaution to minimize this risk, we >> cannot accept liability for any damage that you sustain as a result >> of software viruses. You should carry out your own virus checks >> before opening any attachment. >> > > All of that for 11 1/2 words? > > Ineducable. > -- > sed quis custodiet ipsos custodes? (Juvenal) From cscora at apnic.net Fri Sep 4 18:02:07 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Sep 2015 04:02:07 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201509041802.t84I276Z001927@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 05 Sep, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 30167 Prefixes after maximum aggregation (per Origin AS): 12174 Deaggregation factor: 2.48 Unique aggregates announced (without unneeded subnets): 10608 Total ASes present in the Internet Routing Table: 4848 Prefixes per ASN: 6.22 Origin-only ASes present in the Internet Routing Table: 3304 Origin ASes announcing only one prefix: 2007 Transit ASes present in the Internet Routing Table: 1198 Transit-only ASes present in the Internet Routing Table: 707 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 36 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 63 Unregistered ASNs in the Routing Table: 45 Number of 32-bit ASNs allocated by the RIRs: 10864 Number of 32-bit ASNs visible in the Routing Table: 346 Prefixes from 32-bit ASNs in the Routing Table: 854 Number of bogon 32-bit ASNs visible in the Routing Table: 0 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 9 Number of addresses announced to Internet: 258338464 Equivalent to 15 /8s, 101 /16s and 238 /24s Percentage of available address space announced: 7.0 Percentage of allocated address space announced: 7.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.6 Total number of prefixes smaller than registry allocations: 8184 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 8544 Total APNIC prefixes after maximum aggregation: 1854 APNIC Deaggregation factor: 4.61 Prefixes being announced from the APNIC address blocks: 8266 Unique aggregates announced from the APNIC address blocks: 3049 APNIC Region origin ASes present in the Internet Routing Table: 501 APNIC Prefixes per ASN: 16.50 APNIC Region origin ASes announcing only one prefix: 125 APNIC Region transit ASes present in the Internet Routing Table: 195 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 36 Number of APNIC region 32-bit ASNs visible in the Routing Table: 27 Number of APNIC addresses announced to Internet: 45189632 Equivalent to 2 /8s, 177 /16s and 138 /24s Percentage of available APNIC address space announced: 5.3 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: 12219 Total ARIN prefixes after maximum aggregation: 5908 ARIN Deaggregation factor: 2.07 Prefixes being announced from the ARIN address blocks: 13925 Unique aggregates announced from the ARIN address blocks: 3821 ARIN Region origin ASes present in the Internet Routing Table: 1960 ARIN Prefixes per ASN: 7.10 ARIN Region origin ASes announcing only one prefix: 1187 ARIN Region transit ASes present in the Internet Routing Table: 355 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 52 Number of ARIN addresses announced to Internet: 168019744 Equivalent to 10 /8s, 3 /16s and 199 /24s Percentage of available ARIN address space announced: 8.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 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: 8462 Total RIPE prefixes after maximum aggregation: 3532 RIPE Deaggregation factor: 2.40 Prefixes being announced from the RIPE address blocks: 7958 Unique aggregates announced from the RIPE address blocks: 3730 RIPE Region origin ASes present in the Internet Routing Table: 1307 RIPE Prefixes per ASN: 6.09 RIPE Region origin ASes announcing only one prefix: 688 RIPE Region transit ASes present in the Internet Routing Table: 548 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 27 Number of RIPE region 32-bit ASNs visible in the Routing Table: 265 Number of RIPE addresses announced to Internet: 45053568 Equivalent to 2 /8s, 175 /16s and 118 /24s Percentage of available RIPE address space announced: 6.5 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-204287 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: 67 Total LACNIC prefixes after maximum aggregation: 53 LACNIC Deaggregation factor: 1.26 Prefixes being announced from the LACNIC address blocks: 9 Unique aggregates announced from the LACNIC address blocks: 1 LACNIC Region origin ASes present in the Internet Routing Table: 16 LACNIC Prefixes per ASN: 0.56 LACNIC Region origin ASes announcing only one prefix: 5 LACNIC Region transit ASes present in the Internet Routing Table: 16 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 8 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2 Number of LACNIC addresses announced to Internet: 65536 Equivalent to 0 /8s, 1 /16s and 0 /24s Percentage of available LACNIC address space announced: 0.0 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: 16 Total AfriNIC prefixes after maximum aggregation: 10 AfriNIC Deaggregation factor: 1.60 Prefixes being announced from the AfriNIC address blocks: 0 Unique aggregates announced from the AfriNIC address blocks: 0 AfriNIC Region origin ASes present in the Internet Routing Table: 6 AfriNIC Prefixes per ASN: 0.00 AfriNIC Region origin ASes announcing only one prefix: 2 AfriNIC Region transit ASes present in the Internet Routing Table: 3 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 5 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 0 Number of AfriNIC addresses announced to Internet: 0 Equivalent to 0 /8s, 0 /16s and 0 /24s Percentage of available AfriNIC address space announced: 0.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 979 99 7 TPG Telecom Limited 45528 578 31 32 Tikona Digital Networks Pvt L 7552 310 256 1 Viettel Corporation 9605 265 200 96 NTT DoCoMo, Inc. 24378 264 32 1 Total Access Communication PL 17488 247 61 37 Hathway IP Over Cable Interne 4755 223 64 2 TATA Communications formerly 45769 210 13 73 D-Vois Broadband Pvt Ltd 45899 198 259 24 VNNIC 17841 171 12 11 MIC E-GOVERNMENT 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 3356 1310 8207 19 Level 3 Communications, Inc. 16625 485 282 347 Akamai Technologies, Inc. 20115 390 350 96 Charter Communications 11492 382 42 205 CABLE ONE, INC. 2386 325 48 282 AT&T Data Communications Serv 714 284 4096 1 Apple Inc. 22773 259 170 15 Cox Communications Inc. 62823 255 16 10 Puerto Rico Cable Acquisition 15003 179 228 27 Nobis Technology Group, LLC 10796 167 214 86 Time Warner Cable Internet LL 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 20940 987 469 689 Akamai International B.V. 8402 514 64 1 OJSC "Vimpelcom" 39891 514 32 2 SaudiNet, Saudi Telecom Compa 9198 234 103 9 JSC Kazakhtelecom 48159 228 131 108 Telecommunication Infrastruct 3257 181 105 145 Tinet SpA 12586 133 42 6 GHOSTnet GmbH 51074 120 76 24 GOSTARESH-E-ERTEBATAT-E MABNA 44244 99 256 6 Iran Cell Service and Communi 35819 94 125 35 Bayanat Al-Oula For Network S 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 8151 11 8 11 Uninet S.A. de C.V. 10318 9 16 1 CABLEVISION S.A. 28573 9 5 7 NET Servi?os de Comunica??o S 18734 6 4 5 Operbes, S.A. de C.V. 27810 5 2 5 MERCANET LTDA 6057 4 2 4 Administracion Nacional de Te 10481 4 2 4 Prima S.A. 11271 4 2 4 BT Latam Brasil Ltda 14178 4 2 3 Megacable Comunicaciones de M 27814 4 2 3 Aeprovi 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 3741 4 1 1 Internet Solutions 5713 4 1 1 Telkom SA Ltd. 24835 4 2 4 Vodafone Data 37457 2 1 2 Telkom SA Ltd. 8452 1 1 1 TE-AS 37284 1 0 1 Aljeel Aljadeed For Technolog 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 3356 1310 8207 19 Level 3 Communications, Inc. 20940 987 469 689 Akamai International B.V. 7545 979 99 7 TPG Telecom Limited 45528 578 31 32 Tikona Digital Networks Pvt L 8402 514 64 1 OJSC "Vimpelcom" 39891 514 32 2 SaudiNet, Saudi Telecom Compa 16625 485 282 347 Akamai Technologies, Inc. 20115 390 350 96 Charter Communications 11492 382 42 205 CABLE ONE, INC. 2386 325 48 282 AT&T Data Communications Serv Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 979 972 TPG Telecom Limited 45528 578 546 Tikona Digital Networks Pvt L 8402 514 513 OJSC "Vimpelcom" 39891 514 512 SaudiNet, Saudi Telecom Compa 7552 310 309 Viettel Corporation 20940 987 298 Akamai International B.V. 20115 390 294 Charter Communications 714 284 283 Apple Inc. 24378 264 263 Total Access Communication PL 62823 255 245 Puerto Rico Cable Acquisition 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 47092 UNALLOCATED 8.8.204.0/24 16410 The Reynolds and Rey 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 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 Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 23.249.144.0/21 40430 colo4jax, LLC 23.249.152.0/21 40430 colo4jax, LLC 27.50.8.0/24 55548 Ravibhawan 27.50.9.0/24 55548 Ravibhawan 27.50.10.0/23 55548 Ravibhawan 27.100.7.0/24 56096 >>UNKNOWN<< 31.170.96.0/23 23456 32bit Transition AS 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:8 /9:8 /10:0 /11:7 /12:20 /13:53 /14:67 /15:101 /16:435 /17:313 /18:632 /19:1181 /20:3313 /21:2434 /22:2977 /23:3260 /24:15338 /25:8 /26:7 /27:3 /28:2 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 512 514 SaudiNet, Saudi Telecom Compa 8402 509 514 OJSC "Vimpelcom" 11492 379 382 CABLE ONE, INC. 62823 255 255 Puerto Rico Cable Acquisition 22773 212 259 Cox Communications Inc. 20115 171 390 Charter Communications 9198 144 234 JSC Kazakhtelecom 40285 128 131 NORTHLAND CABLE TELEVISION IN 48159 125 228 Telecommunication Infrastruct 12586 107 133 GHOSTnet GmbH Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1574 2:688 4:97 5:1879 6:25 8:1400 11:1 12:1809 13:19 14:1414 15:17 16:2 17:49 18:22 20:49 23:1269 24:1752 27:2080 31:1192 End of report From hugo at slabnet.com Fri Sep 4 18:20:49 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 4 Sep 2015 11:20:49 -0700 Subject: Weekly Routing Table Report In-Reply-To: <201509041802.t84I276Z001927@thyme.rand.apnic.net> References: <201509041802.t84I276Z001927@thyme.rand.apnic.net> Message-ID: <20150904182049.GF18282@bamboo.slabnet.com> >BGP routing table entries examined: 30167 ... > Percentage of available address space announced: 7.0 > Percentage of allocated address space announced: 7.0 erm...y'all missing some prefixes on the collector for the report? -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From larrysheldon at cox.net Fri Sep 4 18:30:02 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 4 Sep 2015 13:30:02 -0500 Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <55E9D921.6090506@cox.net> Message-ID: <55E9E32A.2060104@cox.net> On 9/4/2015 12:57, Aaron C. de Bruyn wrote: > I think it's time to change my SMTP greeting to: > > 220-By submitting e-mail to this server, you agree all legal > disclaimers are null and void. > 220 You also agree that I am awesome. I like that. Unfortunately, I no longer operate a mail host. I have been trying to figure out how to mechanically route messages containing them to the spam sump. IANAL, but I thing an interesting case would be trying to enforce that crap in a situation involving unsolicited email (as in this case). -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Fri Sep 4 19:32:56 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 4 Sep 2015 14:32:56 -0500 Subject: Extraneous "legal" babble--and my reaction to it. Message-ID: <55E9F1E8.9030405@cox.net> Y'all can stop thumping on me about it "because it is required by the employer". After contemplating my navel for a while, it dawned on me that my sensitivity is due to an old wound. Years ago, Faculty, Staff, Students, and myriad others more or less loosely connected with my employer complained that they could never make contact with me. As a defensive measure (among others) I crafted a .sig that contained all of the telephone numbers and email addresses by which I could be reached (included a pager number) 7 x 24 x 52 with (guaranteed) no more than 20 minute delay. It ran to 7 lines, including the dash dash space EOL protocol sentinel. I was banned from NANOG because of the excessive length. (And yes, I got banned for other things at other times as well, mostly having to to do with trying to protect the network I administered from abuse.) -- sed quis custodiet ipsos custodes? (Juvenal) From aaron at heyaaron.com Fri Sep 4 19:40:08 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 4 Sep 2015 12:40:08 -0700 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <55E9F1E8.9030405@cox.net> References: <55E9F1E8.9030405@cox.net> Message-ID: There's quite a difference between the 'legal babble' and 'contact info' at the end of a message. Regardless, my comment was meant for fun, not to upset you. -A On Fri, Sep 4, 2015 at 12:32 PM, Larry Sheldon wrote: > Y'all can stop thumping on me about it "because it is required by the > employer". > > After contemplating my navel for a while, it dawned on me that my > sensitivity is due to an old wound. > > Years ago, Faculty, Staff, Students, and myriad others more or less loosely > connected with my employer complained that they could never make contact > with me. > > As a defensive measure (among others) I crafted a .sig that contained all of > the telephone numbers and email addresses by which I could be reached > (included a pager number) 7 x 24 x 52 with (guaranteed) no more than 20 > minute delay. > > It ran to 7 lines, including the dash dash space EOL protocol sentinel. > > I was banned from NANOG because of the excessive length. (And yes, I got > banned for other things at other times as well, mostly having to to do with > trying to protect the network I administered from abuse.) > -- > sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Fri Sep 4 19:51:19 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 4 Sep 2015 14:51:19 -0500 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: References: <55E9F1E8.9030405@cox.net> Message-ID: <55E9F637.2080904@cox.net> On 9/4/2015 14:40, Aaron C. de Bruyn wrote: > There's quite a difference between the 'legal babble' and 'contact > info' at the end of a message. What part of "required by employer" is different? I'm not seeing it. -- sed quis custodiet ipsos custodes? (Juvenal) From fred at web2objects.com Fri Sep 4 21:18:27 2015 From: fred at web2objects.com (Fred Hollis) Date: Fri, 4 Sep 2015 23:18:27 +0200 Subject: High latency/packetloss in nyc/nj for cogent/level3/zayo? Message-ID: <55EA0AA3.5010308@web2objects.com> Hi, Anyone also experiencing really high lancy and packetloss 80%+ in nyc/nj area for cogent/level3/zayo? From jj at anexia.at Fri Sep 4 21:24:44 2015 From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Fri, 4 Sep 2015 21:24:44 +0000 Subject: AW: High latency/packetloss in nyc/nj for cogent/level3/zayo? In-Reply-To: <55EA0AA3.5010308@web2objects.com> References: <55EA0AA3.5010308@web2objects.com> Message-ID: <6a5e845a018b4968b81fbda353cec6a7@anx-i-dag02.anx.local> Hi, wer're working with Telia and Hurricane in NYC and we only see some latency flaps in the HE network .... flapping from 0.3 to ~15ms. Nothing really bad. No visible packet loss. Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Fred Hollis Gesendet: Freitag, 04. September 2015 23:18 An: nanog at nanog.org Betreff: High latency/packetloss in nyc/nj for cogent/level3/zayo? Hi, Anyone also experiencing really high lancy and packetloss 80%+ in nyc/nj area for cogent/level3/zayo? From fred at web2objects.com Fri Sep 4 21:33:30 2015 From: fred at web2objects.com (Fred Hollis) Date: Fri, 4 Sep 2015 23:33:30 +0200 Subject: High latency/packetloss in nyc/nj for cogent/level3/zayo? In-Reply-To: <6a5e845a018b4968b81fbda353cec6a7@anx-i-dag02.anx.local> References: <55EA0AA3.5010308@web2objects.com> <6a5e845a018b4968b81fbda353cec6a7@anx-i-dag02.anx.local> Message-ID: <55EA0E2A.3030605@web2objects.com> 1.|-- hosted-by-i3d.net 0.0% 10 8.1 17.3 0.3 144.6 45.0 2.|-- 80ge.cr0-br2-br3.smartdc.rtd.i3d.net 0.0% 10 0.3 2.1 0.2 9.4 3.0 3.|-- 40ge.cr1-cr0.smartdc.rtd.i3d.net 0.0% 10 0.3 7.3 0.3 13.3 5.7 4.|-- ae51.edge4.London1.Level3.net 0.0% 10 10.6 14.2 7.6 30.4 7.5 5.|-- 4.69.156.9 90.0% 10 224.7 224.7 224.7 224.7 0.0 6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- cs20.cs90.v.ewr.nyinternet.net 80.0% 10 169.4 168.8 168.1 169.4 0.9 9.|-- 96.47.77.134.static.nyinternet.net 90.0% 10 167.7 167.7 167.7 167.7 0.0 10.|-- ftw.nj.nyi.net 90.0% 10 169.4 169.4 169.4 169.4 0.0 Having this to almost every network located in NYC/NJ that is going through the said three carrier from many locations. On 04.09.2015 at 23:24 J?rgen Jaritsch wrote: > Hi, > > wer're working with Telia and Hurricane in NYC and we only see some latency flaps in the HE network .... flapping from 0.3 to ~15ms. Nothing really bad. No visible packet loss. > > > Best regards > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > -----Urspr?ngliche Nachricht----- > Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Fred Hollis > Gesendet: Freitag, 04. September 2015 23:18 > An: nanog at nanog.org > Betreff: High latency/packetloss in nyc/nj for cogent/level3/zayo? > > Hi, > > Anyone also experiencing really high lancy and packetloss 80%+ in nyc/nj > area for cogent/level3/zayo? > From mark at exonetric.com Fri Sep 4 21:33:07 2015 From: mark at exonetric.com (Mark Blackman) Date: Fri, 4 Sep 2015 22:33:07 +0100 Subject: High latency/packetloss in nyc/nj for cogent/level3/zayo? In-Reply-To: <55EA0AA3.5010308@web2objects.com> References: <55EA0AA3.5010308@web2objects.com> Message-ID: > On 4 Sep 2015, at 22:18, Fred Hollis wrote: > > Hi, > > Anyone also experiencing really high lancy and packetloss 80%+ in nyc/nj area for cogent/level3/zayo? From London, yes to a general problem, but not sure if it?s specific to NYC, just East Coast in general. Start: Fri Sep 4 22:31:02 2015 BST HOST: severn Loss% Snt Last Avg Best Wrst StDev 1.|-- gw1.thn.exonetric.net 0.0% 10 7.7 0.9 0.2 7.7 2.4 2.|-- e1-3-2.a00.londen03.uk.ra.gin.ntt.net 0.0% 10 0.6 0.8 0.5 1.4 0.0 3.|-- be3028.ccr21.lon02.atlas.cogentco.com 0.0% 10 0.8 0.9 0.8 1.2 0.0 4.|-- be2328.ccr21.lon01.atlas.cogentco.com 0.0% 10 1.0 0.9 0.8 1.2 0.0 5.|-- be2178.ccr42.lon13.atlas.cogentco.com 0.0% 10 1.0 1.0 0.9 1.1 0.0 6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 7.|-- be2268.ccr41.iad02.atlas.cogentco.com 80.0% 10 147.2 145.7 144.2 147.2 2.0 8.|-- be2657.ccr42.dca01.atlas.cogentco.com 90.0% 10 145.4 145.4 145.4 145.4 0.0 9.|-- be2149.ccr42.jfk02.atlas.cogentco.com 90.0% 10 145.0 145.0 145.0 145.0 0.0 10.|-- be2149.ccr42.dca01.atlas.cogentco.com 80.0% 10 154.7 152.4 150.1 154.7 3.2 11.|-- be2113.ccr42.atl01.atlas.cogentco.com 80.0% 10 163.3 162.6 161.8 163.3 1.0 12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13.|-- ??? 100.0 8 0.0 0.0 0.0 0.0 0.0 14.|-- te0-0-1-0.agr12.dfw01.atlas.cogentco.com 71.4% 7 182.0 181.9 181.7 182.0 0.0 15.|-- te0-0-2-3.nr11.b000821-1.dfw01.atlas.cogentco.com 71.4% 7 183.3 182.8 182.2 183.3 0.0 16.|-- ??? 100.0 7 0.0 0.0 0.0 0.0 0.0 From oliver at g.garraux.net Fri Sep 4 21:41:00 2015 From: oliver at g.garraux.net (Oliver Garraux) Date: Fri, 4 Sep 2015 14:41:00 -0700 Subject: High latency/packetloss in nyc/nj for cogent/level3/zayo? In-Reply-To: <55EA0E2A.3030605@web2objects.com> References: <55EA0AA3.5010308@web2objects.com> <6a5e845a018b4968b81fbda353cec6a7@anx-i-dag02.anx.local> <55EA0E2A.3030605@web2objects.com> Message-ID: We're seeing issues between the US and northwest Europe (UK / Ireland), that started around 40 minutes ago. They are fairly unrelated services (AWS, Linode, L3VPN, commercial IP transit)...so I'm assuming there's some kind of larger outage going on? Oliver ------------------------------------- Oliver Garraux Check out my blog: blog.garraux.net Follow me on Twitter: twitter.com/olivergarraux On Fri, Sep 4, 2015 at 2:33 PM, Fred Hollis wrote: > 1.|-- hosted-by-i3d.net 0.0% 10 8.1 17.3 0.3 144.6 45.0 > 2.|-- 80ge.cr0-br2-br3.smartdc.rtd.i3d.net 0.0% 10 0.3 2.1 0.2 9.4 3.0 > 3.|-- 40ge.cr1-cr0.smartdc.rtd.i3d.net 0.0% 10 0.3 7.3 0.3 13.3 5.7 > 4.|-- ae51.edge4.London1.Level3.net 0.0% 10 10.6 14.2 7.6 30.4 7.5 > 5.|-- 4.69.156.9 90.0% 10 224.7 224.7 224.7 224.7 0.0 > 6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 > 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 > 8.|-- cs20.cs90.v.ewr.nyinternet.net 80.0% 10 169.4 168.8 168.1 169.4 0.9 > 9.|-- 96.47.77.134.static.nyinternet.net 90.0% 10 167.7 167.7 167.7 167.7 > 0.0 > 10.|-- ftw.nj.nyi.net 90.0% 10 169.4 169.4 169.4 169.4 0.0 > > Having this to almost every network located in NYC/NJ that is going > through the said three carrier from many locations. > > > On 04.09.2015 at 23:24 J?rgen Jaritsch wrote: > >> Hi, >> >> wer're working with Telia and Hurricane in NYC and we only see some >> latency flaps in the HE network .... flapping from 0.3 to ~15ms. Nothing >> really bad. No visible packet loss. >> >> >> Best regards >> >> J?rgen Jaritsch >> Head of Network & Infrastructure >> >> ANEXIA Internetdienstleistungs GmbH >> >> Telefon: +43-5-0556-300 >> Telefax: +43-5-0556-500 >> >> E-Mail: jj at anexia.at >> Web: http://www.anexia.at >> >> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >> Gesch?ftsf?hrer: Alexander Windbichler >> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT >> U63216601 >> >> -----Urspr?ngliche Nachricht----- >> Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Fred Hollis >> Gesendet: Freitag, 04. September 2015 23:18 >> An: nanog at nanog.org >> Betreff: High latency/packetloss in nyc/nj for cogent/level3/zayo? >> >> Hi, >> >> Anyone also experiencing really high lancy and packetloss 80%+ in nyc/nj >> area for cogent/level3/zayo? >> >> From jj at anexia.at Fri Sep 4 21:44:49 2015 From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Fri, 4 Sep 2015 21:44:49 +0000 Subject: AW: High latency/packetloss in nyc/nj for cogent/level3/zayo? In-Reply-To: <55EA0E2A.3030605@web2objects.com> References: <55EA0AA3.5010308@web2objects.com> <6a5e845a018b4968b81fbda353cec6a7@anx-i-dag02.anx.local> <55EA0E2A.3030605@web2objects.com> Message-ID: Hi, I do see one of our offices down ... but ftw.nj.nyi.net is reachable without any issue for us (but the path differ from yours): Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. cr-01.0v-00-05.anx32.nyc.us.anexia-it.com 0.0% 47 0.5 5.4 0.4 80.3 17.4 2. cs70.nyi.net 0.0% 47 0.9 6.7 0.8 118.0 21.4 3. cs70.cs80.v.ewr.nyinternet.net 0.0% 47 2.6 8.1 2.0 144.8 27.0 4. 96.47.77.142.static.nyinternet.net 0.0% 47 2.1 2.1 2.0 3.1 0.1 5. ftw.nj.nyi.net 0.0% 47 2.0 2.0 1.9 2.2 0.1 One other thing we do see: looks like Level3 is broken globally ... we can't send traffic from Europe via Level3 to the Asian region: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. er-03.0v-00-03.anx04.vie.at.anexia-it.com 0.0% 101 0.3 0.4 0.3 2.2 0.2 2. cr-04.0v-08-71.anx03.vie.at.anexia-it.com 0.0% 101 0.8 0.8 0.4 17.8 2.0 3. win-b4-link.telia.net 0.0% 101 0.5 1.6 0.5 29.1 4.0 4. level-ic-1573273-wien-b4.c.telia.net 0.0% 101 0.5 3.6 0.4 85.3 12.1 5. ??? 6. 4.69.152.144 99.0% 100 307.4 307.4 307.4 307.4 0.0 7. 4.53.208.102 89.9% 100 253.8 255.7 251.3 265.8 3.9 8. TenGE4-2.br01.tok02.pccwbtn.net 87.9% 100 524.0 406.4 366.9 536.7 66.9 9. cr-01.0v-00-08.anx11.tyo.jp.anexia-it.com 91.9% 100 368.1 371.0 365.4 382.9 5.5 10. anx-lg-jp-tyo01.anexia-it.com 96.0% 100 368.9 368.6 366.9 369.3 1.1 We'll start a ticket with Level3 support ... hopefully they will share some information (in the next days ... ). Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Fred Hollis Gesendet: Freitag, 04. September 2015 23:34 An: nanog at nanog.org Betreff: Re: High latency/packetloss in nyc/nj for cogent/level3/zayo? 1.|-- hosted-by-i3d.net 0.0% 10 8.1 17.3 0.3 144.6 45.0 2.|-- 80ge.cr0-br2-br3.smartdc.rtd.i3d.net 0.0% 10 0.3 2.1 0.2 9.4 3.0 3.|-- 40ge.cr1-cr0.smartdc.rtd.i3d.net 0.0% 10 0.3 7.3 0.3 13.3 5.7 4.|-- ae51.edge4.London1.Level3.net 0.0% 10 10.6 14.2 7.6 30.4 7.5 5.|-- 4.69.156.9 90.0% 10 224.7 224.7 224.7 224.7 0.0 6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- cs20.cs90.v.ewr.nyinternet.net 80.0% 10 169.4 168.8 168.1 169.4 0.9 9.|-- 96.47.77.134.static.nyinternet.net 90.0% 10 167.7 167.7 167.7 167.7 0.0 10.|-- ftw.nj.nyi.net 90.0% 10 169.4 169.4 169.4 169.4 0.0 Having this to almost every network located in NYC/NJ that is going through the said three carrier from many locations. On 04.09.2015 at 23:24 J?rgen Jaritsch wrote: > Hi, > > wer're working with Telia and Hurricane in NYC and we only see some latency flaps in the HE network .... flapping from 0.3 to ~15ms. Nothing really bad. No visible packet loss. > > > Best regards > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > -----Urspr?ngliche Nachricht----- > Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Fred Hollis > Gesendet: Freitag, 04. September 2015 23:18 > An: nanog at nanog.org > Betreff: High latency/packetloss in nyc/nj for cogent/level3/zayo? > > Hi, > > Anyone also experiencing really high lancy and packetloss 80%+ in nyc/nj > area for cogent/level3/zayo? > From petertavenier at gmail.com Fri Sep 4 21:55:43 2015 From: petertavenier at gmail.com (Peter Tavenier) Date: Fri, 4 Sep 2015 23:55:43 +0200 Subject: High latency/packetloss in nyc/nj for cogent/level3/zayo? In-Reply-To: References: <55EA0AA3.5010308@web2objects.com> <6a5e845a018b4968b81fbda353cec6a7@anx-i-dag02.anx.local> <55EA0E2A.3030605@web2objects.com> Message-ID: <00F19EF1-88D5-4792-9DB0-9E16D62B0C6C@gmail.com> Hi, We see the same hier from server pingdom servers towards Amsterdam, The Netherlands. Last hops without loss in the traceroutes were fist: ? 4 xe-8-0-0.bar1.Tampa1.Level3.net (4.53.172.1) 57.509 ms 57.970 ms 58.201 ms ? 4 ae52.edge1.Washington4.Level3.net (4.53.112.25) 2.254 ms 2.453 ms 2.633 ms and last few I saw 10min ago was: ? 4 xe-11-0-3.bar2.LasVegas1.Level3.net (205.129.18.249) 1.928 ms 2.211 ms 2.484 ms -- Kind regards, Peter Tavenier > On 04 Sep 2015, at 23:41, Oliver Garraux wrote: > > We're seeing issues between the US and northwest Europe (UK / Ireland), > that started around 40 minutes ago. They are fairly unrelated services > (AWS, Linode, L3VPN, commercial IP transit)...so I'm assuming there's some > kind of larger outage going on? > > Oliver > > ------------------------------------- > > Oliver Garraux > Check out my blog: blog.garraux.net > Follow me on Twitter: twitter.com/olivergarraux > > On Fri, Sep 4, 2015 at 2:33 PM, Fred Hollis wrote: > >> 1.|-- hosted-by-i3d.net 0.0% 10 8.1 17.3 0.3 144.6 45.0 >> 2.|-- 80ge.cr0-br2-br3.smartdc.rtd.i3d.net 0.0% 10 0.3 2.1 0.2 9.4 3.0 >> 3.|-- 40ge.cr1-cr0.smartdc.rtd.i3d.net 0.0% 10 0.3 7.3 0.3 13.3 5.7 >> 4.|-- ae51.edge4.London1.Level3.net 0.0% 10 10.6 14.2 7.6 30.4 7.5 >> 5.|-- 4.69.156.9 90.0% 10 224.7 224.7 224.7 224.7 0.0 >> 6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 >> 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 >> 8.|-- cs20.cs90.v.ewr.nyinternet.net 80.0% 10 169.4 168.8 168.1 169.4 0.9 >> 9.|-- 96.47.77.134.static.nyinternet.net 90.0% 10 167.7 167.7 167.7 167.7 >> 0.0 >> 10.|-- ftw.nj.nyi.net 90.0% 10 169.4 169.4 169.4 169.4 0.0 >> >> Having this to almost every network located in NYC/NJ that is going >> through the said three carrier from many locations. >> >> >> On 04.09.2015 at 23:24 J?rgen Jaritsch wrote: >> >>> Hi, >>> >>> wer're working with Telia and Hurricane in NYC and we only see some >>> latency flaps in the HE network .... flapping from 0.3 to ~15ms. Nothing >>> really bad. No visible packet loss. >>> >>> >>> Best regards >>> >>> J?rgen Jaritsch >>> Head of Network & Infrastructure >>> >>> ANEXIA Internetdienstleistungs GmbH >>> >>> Telefon: +43-5-0556-300 >>> Telefax: +43-5-0556-500 >>> >>> E-Mail: jj at anexia.at >>> Web: http://www.anexia.at >>> >>> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt >>> Gesch?ftsf?hrer: Alexander Windbichler >>> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT >>> U63216601 >>> >>> -----Urspr?ngliche Nachricht----- >>> Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Fred Hollis >>> Gesendet: Freitag, 04. September 2015 23:18 >>> An: nanog at nanog.org >>> Betreff: High latency/packetloss in nyc/nj for cogent/level3/zayo? >>> >>> Hi, >>> >>> Anyone also experiencing really high lancy and packetloss 80%+ in nyc/nj >>> area for cogent/level3/zayo? >>> >>> From cidr-report at potaroo.net Fri Sep 4 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Sep 2015 22:00:01 GMT Subject: The Cidr Report Message-ID: <201509042200.t84M01Go087196@wattle.apnic.net> This report has been generated at Fri Sep 4 21:14:47 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 28-08-15 565765 306001 29-08-15 565902 305994 30-08-15 566011 305946 31-08-15 565838 305759 01-09-15 565663 305975 02-09-15 565830 306333 03-09-15 565947 306913 04-09-15 566067 307642 AS Summary 51628 Number of ASes in routing system 20478 Number of ASes announcing only one prefix 3352 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120888576 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'). --- 04Sep15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 566191 307544 258647 45.7% All ASes AS22773 3176 171 3005 94.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2707 80 2627 97.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS6389 2695 69 2626 97.4% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS39891 2473 30 2443 98.8% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS7545 2912 647 2265 77.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS28573 2275 137 2138 94.0% NET Servi?os de Comunica??o S.A.,BR AS9394 2105 201 1904 90.5% CTTNET China TieTong Telecommunications Corporation,CN AS4766 3000 1272 1728 57.6% KIXS-AS-KR Korea Telecom,KR AS10620 3352 1630 1722 51.4% Telmex Colombia S.A.,CO AS9808 1585 75 1510 95.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1739 247 1492 85.8% ITCDELTA - Earthlink, Inc.,US AS4755 2042 561 1481 72.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS20115 1881 408 1473 78.3% CHARTER-NET-HKY-NC - Charter Communications,US AS3356 2541 1220 1321 52.0% LEVEL3 - Level 3 Communications, Inc.,US AS9498 1386 120 1266 91.3% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2147 956 1191 55.5% MEGAPATH5-US - MegaPath Corporation,US AS4323 1588 405 1183 74.5% TWTC - tw telecom holdings, inc.,US AS6849 1210 74 1136 93.9% UKRTELNET JSC UKRTELECOM,UA AS4788 1202 69 1133 94.3% TMNET-AS-AP TM Net, Internet Service Provider,MY AS6147 1404 278 1126 80.2% Telefonica del Peru S.A.A.,PE AS7552 1423 382 1041 73.2% VIETEL-AS-AP Viettel Corporation,VN AS7303 1556 522 1034 66.5% Telecom Argentina S.A.,AR AS4808 1546 513 1033 66.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS22561 1375 344 1031 75.0% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS26615 1098 153 945 86.1% Tim Celular S.A.,BR AS8402 965 24 941 97.5% CORBINA-AS OJSC "Vimpelcom",RU AS8151 1704 779 925 54.3% Uninet S.A. de C.V.,MX AS7738 996 77 919 92.3% Telemar Norte Leste S.A.,BR AS38285 982 133 849 86.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS55430 876 59 817 93.3% STARHUBINTERNET-AS-NGNBN Starhub Internet Pte Ltd,SG Total 55941 11636 44305 79.2% Top 30 total Possible Bogus Routes 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 23.249.144.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 23.249.144.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 23.249.152.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 27.50.8.0/24 AS55548 27.50.9.0/24 AS55548 27.50.10.0/23 AS55548 27.100.7.0/24 AS56096 31.170.96.0/23 AS19798 YOUZEE-MAIN Manaslu Media Entertainment SL,ES 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 36.50.0.0/16 AS20418 MOSMOG-AS OJSC TORGOVYJ DOM MOSKVA-MOGILEV,RU 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.3.0/24 AS37004 -Reserved AS-,ZZ 41.73.4.0/24 AS37004 -Reserved AS-,ZZ 41.73.5.0/24 AS37004 -Reserved AS-,ZZ 41.73.6.0/24 AS37004 -Reserved AS-,ZZ 41.73.7.0/24 AS37004 -Reserved AS-,ZZ 41.73.8.0/24 AS37004 -Reserved AS-,ZZ 41.73.9.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.17.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.126.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -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.126.164.0/22 AS41690 DAILYMOTION Dailymotion S.A.,FR 45.254.196.0/24 AS31972 EMGINECONCEPT-01 - Emagine Concept, Inc.,US 64.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.57.192.0/22 AS33321 -Reserved AS-,ZZ 64.234.239.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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.187.240.0/24 AS22753 REDHAT-0 - Red Hat, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.228.160.0/20 AS7233 YAHOO-US - Yahoo,US 66.228.176.0/21 AS17110 YAHOO-US2 - Yahoo,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 68.234.0.0/19 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.0.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.5.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.7.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.16.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.17.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.18.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.19.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.20.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.21.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.22.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.23.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.24.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.26.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.28.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.29.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 69.24.96.0/20 AS26804 -Reserved AS-,ZZ 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.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 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.100.1.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd,IN 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.12.48.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.12.247.0/24 AS13233 103.13.1.0/24 AS58609 103.14.32.0/22 AS2519 VECTANT VECTANT Ltd.,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 103.18.45.0/24 AS18351 103.18.47.0/24 AS18351 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.22.212.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.25.144.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.29.236.0/24 AS13200 103.29.237.0/24 AS13200 103.195.32.0/22 AS41690 DAILYMOTION Dailymotion S.A.,FR 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.229.152.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.232.164.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.233.140.0/23 AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK,AF 103.233.212.0/22 AS10010 TOKAI TOKAI Communications Corporation,JP 103.235.72.0/23 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.235.74.0/23 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.235.216.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.237.76.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.250.220.0/24 AS58973 103.250.221.0/24 AS58973 103.253.164.0/23 AS13317 116.12.32.0/21 AS38555 LINKIT Internet Service Provider,BD 116.199.203.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.205.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.206.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.207.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 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 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 155.35.0.0/16 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.1.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.34.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.35.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.46.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.47.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.232.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.221.64.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 162.221.64.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 162.221.68.0/22 AS40430 COLO4JAX-AS - colo4jax, 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.88.48.0/20 AS29927 -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.249.191.0/24 AS45816 ISHK-AP I-Services Network Solution Limited,HK 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.52.57.0/24 AS48039 KGT-AS KGT new media,DE 185.52.58.0/24 AS48039 KGT-AS KGT new media,DE 186.148.224.0/21 AS52302 Awknet International, S.A.,PA 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.67.160.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.67.161.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.67.162.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.46.0/23 AS17139 NETRANGE - Corporate Colocation 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.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.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 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.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 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.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 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.151.160.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.130.0/24 AS21104 AM-NETSYS-AS Netsys JV LLC,AM 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.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.9.9.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.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.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 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.180.0/24 AS37004 -Reserved AS-,ZZ 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.8.72.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.72.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.76.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.77.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.78.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.79.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 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.91.44.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.44.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.45.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.46.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.47.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,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.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.16.31.0/24 AS31863 DACEN-2 - Centrilogic, Inc.,US 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.43.184.0/24 AS14265 US-TELEPACIFIC - Telepacific Communications,US 199.66.15.0/24 AS30169 -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.103.89.0/24 AS19523 -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.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 201.131.5.0/24 AS28389 -Reserved AS-,ZZ 201.131.88.0/24 AS8151 Uninet S.A. de C.V.,MX 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.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.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.6.208.0/24 AS23937 203.6.209.0/24 AS23937 203.6.210.0/24 AS23937 203.6.211.0/24 AS23937 203.6.213.0/24 AS23937 203.6.215.0/24 AS23937 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 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 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 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.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.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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 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.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.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 Sep 4 22:00:02 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Sep 2015 22:00:02 GMT Subject: BGP Update Report Message-ID: <201509042200.t84M02Ao087213@wattle.apnic.net> BGP Update Report Interval: 27-Aug-15 -to- 03-Sep-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS22047 236563 5.5% 854.0 -- VTR BANDA ANCHA S.A.,CL 2 - AS9829 187555 4.4% 182.6 -- BSNL-NIB National Internet Backbone,IN 3 - AS22059 118656 2.8% 59328.0 -- -Reserved AS-,ZZ 4 - AS38197 86971 2.0% 62.3 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 5 - AS53271 76774 1.8% 6979.5 -- PHENIXCITYCABLE - Phenix Cable,US 6 - AS3709 59647 1.4% 2209.1 -- NET-CITY-SA - City of San Antonio,US 7 - AS1505 51748 1.2% 6468.5 -- DNIC-AS-01505 - Headquarters, USAISC,US 8 - AS8402 47582 1.1% 73.8 -- CORBINA-AS OJSC "Vimpelcom",RU 9 - AS199367 46790 1.1% 46790.0 -- AS_GBP Globe Business Publishing Limited,GB 10 - AS8001 43042 1.0% 14347.3 -- NET-ACCESS-CORP - Net Access Corporation,US 11 - AS8376 37224 0.9% 152.6 -- Jordan Data Communications Company LLC,JO 12 - AS200008 31626 0.7% 10542.0 -- PIRUM-AS Pirum Systems Limited,GB 13 - AS30295 31122 0.7% 3890.2 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 14 - AS131090 30911 0.7% 2207.9 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 15 - AS56636 30098 0.7% 30098.0 -- ASVEDARU VEDA Ltd.,RU 16 - AS25563 26268 0.6% 8756.0 -- WEBLAND-AS Webland AG,CH 17 - AS8151 22990 0.5% 19.6 -- Uninet S.A. de C.V.,MX 18 - AS28573 22465 0.5% 21.1 -- NET Servi?os de Comunica??o S.A.,BR 19 - AS31549 19468 0.5% 91.4 -- RASANA Aria Shatel Company Ltd,IR 20 - AS13999 19020 0.5% 44.4 -- Mega Cable, S.A. de C.V.,MX TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS22059 118656 2.8% 59328.0 -- -Reserved AS-,ZZ 2 - AS199367 46790 1.1% 46790.0 -- AS_GBP Globe Business Publishing Limited,GB 3 - AS56636 30098 0.7% 30098.0 -- ASVEDARU VEDA Ltd.,RU 4 - AS200671 17285 0.4% 17285.0 -- SKOK-JAWORZNO SKOK Jaworzno,PL 5 - AS31357 15377 0.4% 15377.0 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 6 - AS8001 43042 1.0% 14347.3 -- NET-ACCESS-CORP - Net Access Corporation,US 7 - AS200008 31626 0.7% 10542.0 -- PIRUM-AS Pirum Systems Limited,GB 8 - AS25563 26268 0.6% 8756.0 -- WEBLAND-AS Webland AG,CH 9 - AS37590 7760 0.2% 7760.0 -- BCA-ASN,AO 10 - AS40493 7694 0.2% 7694.0 -- FACILITYSOURCEINC - FacilitySource,US 11 - AS53271 76774 1.8% 6979.5 -- PHENIXCITYCABLE - Phenix Cable,US 12 - AS1505 51748 1.2% 6468.5 -- DNIC-AS-01505 - Headquarters, USAISC,US 13 - AS38000 4721 0.1% 4721.0 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 14 - AS30295 31122 0.7% 3890.2 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 15 - AS55741 3549 0.1% 3549.0 -- WBSDC-NET-IN West Bengal Electronics Industry Development,IN 16 - AS25470 3171 0.1% 3171.0 -- SCOTTISH-SOUTHERN-PLC-AS Scottish and Southern Energy PLC,GB 17 - AS327786 12457 0.3% 3114.2 -- TELECOM-4G,SS 18 - AS15923 2389 0.1% 2389.0 -- ASN-LOGOS Logos S.P.A.,IT 19 - AS3709 59647 1.4% 2209.1 -- NET-CITY-SA - City of San Antonio,US 20 - AS131090 30911 0.7% 2207.9 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 64.34.125.0/24 59501 1.3% AS22059 -- -Reserved AS-,ZZ 2 - 76.191.107.0/24 59155 1.3% AS22059 -- -Reserved AS-,ZZ 3 - 185.19.144.0/22 46790 1.1% AS199367 -- AS_GBP Globe Business Publishing Limited,GB 4 - 192.135.223.0/24 43033 1.0% AS8001 -- NET-ACCESS-CORP - Net Access Corporation,US 5 - 185.38.132.0/24 31605 0.7% AS200008 -- PIRUM-AS Pirum Systems Limited,GB 6 - 61.7.155.0/24 30833 0.7% AS131090 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 7 - 195.128.159.0/24 30098 0.7% AS56636 -- ASVEDARU VEDA Ltd.,RU 8 - 162.218.162.0/23 21066 0.5% AS53271 -- PHENIXCITYCABLE - Phenix Cable,US 9 - 162.218.160.0/21 20291 0.5% AS53271 -- PHENIXCITYCABLE - Phenix Cable,US 10 - 24.38.128.0/22 18183 0.4% AS53271 -- PHENIXCITYCABLE - Phenix Cable,US 11 - 155.133.79.0/24 17285 0.4% AS200671 -- SKOK-JAWORZNO SKOK Jaworzno,PL 12 - 24.38.128.0/20 17224 0.4% AS53271 -- PHENIXCITYCABLE - Phenix Cable,US 13 - 78.140.0.0/18 15377 0.3% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 14 - 187.244.0.0/22 13746 0.3% AS13999 -- Mega Cable, S.A. de C.V.,MX 15 - 199.60.234.0/23 10680 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 16 - 199.60.236.0/24 10672 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 17 - 199.60.233.0/24 9765 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 18 - 92.43.216.0/21 8907 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 19 - 178.174.96.0/19 8697 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 20 - 185.84.192.0/22 8664 0.2% AS25563 -- WEBLAND-AS Webland AG,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 jj at anexia.at Fri Sep 4 22:04:06 2015 From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Fri, 4 Sep 2015 22:04:06 +0000 Subject: AW: High latency/packetloss in nyc/nj for cogent/level3/zayo? In-Reply-To: References: <55EA0AA3.5010308@web2objects.com> <6a5e845a018b4968b81fbda353cec6a7@anx-i-dag02.anx.local> <55EA0E2A.3030605@web2objects.com> Message-ID: Surprise, surprise ... the cleaning staff stopped his worked and connected back in the correct cord ... Looks like everything went back to normal .... Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von J?rgen Jaritsch Gesendet: Freitag, 04. September 2015 23:45 An: Fred Hollis ; nanog at nanog.org Betreff: AW: High latency/packetloss in nyc/nj for cogent/level3/zayo? Hi, I do see one of our offices down ... but ftw.nj.nyi.net is reachable without any issue for us (but the path differ from yours): Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. cr-01.0v-00-05.anx32.nyc.us.anexia-it.com 0.0% 47 0.5 5.4 0.4 80.3 17.4 2. cs70.nyi.net 0.0% 47 0.9 6.7 0.8 118.0 21.4 3. cs70.cs80.v.ewr.nyinternet.net 0.0% 47 2.6 8.1 2.0 144.8 27.0 4. 96.47.77.142.static.nyinternet.net 0.0% 47 2.1 2.1 2.0 3.1 0.1 5. ftw.nj.nyi.net 0.0% 47 2.0 2.0 1.9 2.2 0.1 One other thing we do see: looks like Level3 is broken globally ... we can't send traffic from Europe via Level3 to the Asian region: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. er-03.0v-00-03.anx04.vie.at.anexia-it.com 0.0% 101 0.3 0.4 0.3 2.2 0.2 2. cr-04.0v-08-71.anx03.vie.at.anexia-it.com 0.0% 101 0.8 0.8 0.4 17.8 2.0 3. win-b4-link.telia.net 0.0% 101 0.5 1.6 0.5 29.1 4.0 4. level-ic-1573273-wien-b4.c.telia.net 0.0% 101 0.5 3.6 0.4 85.3 12.1 5. ??? 6. 4.69.152.144 99.0% 100 307.4 307.4 307.4 307.4 0.0 7. 4.53.208.102 89.9% 100 253.8 255.7 251.3 265.8 3.9 8. TenGE4-2.br01.tok02.pccwbtn.net 87.9% 100 524.0 406.4 366.9 536.7 66.9 9. cr-01.0v-00-08.anx11.tyo.jp.anexia-it.com 91.9% 100 368.1 371.0 365.4 382.9 5.5 10. anx-lg-jp-tyo01.anexia-it.com 96.0% 100 368.9 368.6 366.9 369.3 1.1 We'll start a ticket with Level3 support ... hopefully they will share some information (in the next days ... ). Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Fred Hollis Gesendet: Freitag, 04. September 2015 23:34 An: nanog at nanog.org Betreff: Re: High latency/packetloss in nyc/nj for cogent/level3/zayo? 1.|-- hosted-by-i3d.net 0.0% 10 8.1 17.3 0.3 144.6 45.0 2.|-- 80ge.cr0-br2-br3.smartdc.rtd.i3d.net 0.0% 10 0.3 2.1 0.2 9.4 3.0 3.|-- 40ge.cr1-cr0.smartdc.rtd.i3d.net 0.0% 10 0.3 7.3 0.3 13.3 5.7 4.|-- ae51.edge4.London1.Level3.net 0.0% 10 10.6 14.2 7.6 30.4 7.5 5.|-- 4.69.156.9 90.0% 10 224.7 224.7 224.7 224.7 0.0 6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- cs20.cs90.v.ewr.nyinternet.net 80.0% 10 169.4 168.8 168.1 169.4 0.9 9.|-- 96.47.77.134.static.nyinternet.net 90.0% 10 167.7 167.7 167.7 167.7 0.0 10.|-- ftw.nj.nyi.net 90.0% 10 169.4 169.4 169.4 169.4 0.0 Having this to almost every network located in NYC/NJ that is going through the said three carrier from many locations. On 04.09.2015 at 23:24 J?rgen Jaritsch wrote: > Hi, > > wer're working with Telia and Hurricane in NYC and we only see some latency flaps in the HE network .... flapping from 0.3 to ~15ms. Nothing really bad. No visible packet loss. > > > Best regards > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > -----Urspr?ngliche Nachricht----- > Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Fred Hollis > Gesendet: Freitag, 04. September 2015 23:18 > An: nanog at nanog.org > Betreff: High latency/packetloss in nyc/nj for cogent/level3/zayo? > > Hi, > > Anyone also experiencing really high lancy and packetloss 80%+ in nyc/nj > area for cogent/level3/zayo? > From list at satchell.net Fri Sep 4 22:31:34 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 4 Sep 2015 15:31:34 -0700 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <55E9F1E8.9030405@cox.net> References: <55E9F1E8.9030405@cox.net> Message-ID: <55EA1BC6.4080302@satchell.net> On 09/04/2015 12:32 PM, Larry Sheldon wrote: > As a defensive measure (among others) I crafted a .sig that contained > all of the telephone numbers and email addresses by which I could be > reached (included a pager number) 7 x 24 x 52 with (guaranteed) no more > than 20 minute delay. > > It ran to 7 lines, including the dash dash space EOL protocol sentinel. I, for one, feel your pain in this matter. When I was a consultant in The Bad Ol' Days, I had so many telephone numbers where I *could* be that my .sig would be a run-on one as well. As a compromise, I had my cell number and a hyperlink to a Web site page with the full monte. That was before I joined NANOG, so I never tested the tolerance of the people here with that solution. When I was employed as a full-timer (including now) my "work" mail has the same sort of crap. One option you might want to consider is to use a personal e-mail account for places like NANOG with the single-line disclaimer "Views expressed herein may not be my employer's view" From rvandolson at esri.com Fri Sep 4 22:51:09 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Fri, 4 Sep 2015 15:51:09 -0700 Subject: Akamai Geolocation Secret Sauce? Message-ID: <20150904225108.GA10635@esri.com> Anyone familiar with how Akamai does its geolocation? Presumably they do more than Maxmind/WHOIS, but I suppose one or both of those could factor in? For those of you with ARIN IP space, do you typically SWIP things to yourself to help clarify the locations where the IP space physically resides to feed into Geolocation databases? Thanks, Ray From Valdis.Kletnieks at vt.edu Fri Sep 4 22:59:36 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 04 Sep 2015 18:59:36 -0400 Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <55E9D921.6090506@cox.net> Message-ID: <93965.1441407576@turing-police.cc.vt.edu> On Fri, 04 Sep 2015 10:57:26 -0700, "Aaron C. de Bruyn" said: > I think it's time to change my SMTP greeting to: > > 220-By submitting e-mail to this server, you agree all legal > disclaimers are null and void. > 220 You also agree that I am awesome. Does anybody have a citation that legal disclaimers attached to publicly posted mail aren't null and void? Seems to me that what they're trying to say is "Sorry, we're too lame to use PGP or similar on actually sensitive e-mail"... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanogml at Mail.DDoS-Mitigator.net Fri Sep 4 23:15:21 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Fri, 4 Sep 2015 16:15:21 -0700 Subject: Software Defined Networking In-Reply-To: <93965.1441407576@turing-police.cc.vt.edu> References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <55E9D921.6090506@cox.net> <93965.1441407576@turing-police.cc.vt.edu> Message-ID: <20150904231521.GA27099@Mail.DDoS-Mitigator.net> hi valdis On 09/04/15 at 06:59pm, Valdis.Kletnieks at vt.edu wrote: > > Does anybody have a citation that legal disclaimers attached to > publicly posted mail aren't null and void? Seems to me that > what they're trying to say is "Sorry, we're too lame to use > PGP or similar on actually sensitive e-mail"... i keep wondering why "they" keep using sniffable clear text smtp/imap/pop3 instead of at least encrypted version the problem also is both ends, the sender and the receiver and all the laptops/desktops need to be configured more importantly, why not just use https based webmail or even smpts encrypted google mail where less setup and configuring would be needed for sender and receiver have a nice weekend alvin # # DDoS-Mitigator.com # From nharland at gmail.com Sat Sep 5 02:36:28 2015 From: nharland at gmail.com (Nicholas Harland) Date: Fri, 4 Sep 2015 19:36:28 -0700 Subject: Akamai Geolocation Secret Sauce? In-Reply-To: <20150904225108.GA10635@esri.com> References: <20150904225108.GA10635@esri.com> Message-ID: The people who could answer that question are quite unlikely to do so on a public mailing list, but I'm sure that having a huge number of servers deployed to a huge number of known physical locations on networks across the globe plays a big part in the ingredients. If you think Akamai or any other network is geolocating incorrectly, contact their support. Or if you just want to know how the geo sauce is made, many companies file the best parts of their recipes online: https://www.google.com/search?tbm=pts&hl=en&q=akamai+geolocation Nick Harland On Fri, Sep 4, 2015 at 3:51 PM, Ray Van Dolson wrote: > Anyone familiar with how Akamai does its geolocation? Presumably they > do more than Maxmind/WHOIS, but I suppose one or both of those could > factor in? > > For those of you with ARIN IP space, do you typically SWIP things to > yourself to help clarify the locations where the IP space physically > resides to feed into Geolocation databases? > > Thanks, > Ray > From gustavo at nexthop.com.br Sat Sep 5 03:37:47 2015 From: gustavo at nexthop.com.br (Gustavo Rodrigues Ramos) Date: Sat, 5 Sep 2015 00:37:47 -0300 Subject: Akamai Geolocation Secret Sauce? In-Reply-To: <20150904225108.GA10635@esri.com> References: <20150904225108.GA10635@esri.com> Message-ID: Hello Ray, I'm not familiar with Akamai's secret sauce. But I suppose geolocation databases can be outdated very fast over time and things are getting worst with the ipv4 depletion... However, if you have a very large number of nodes spread across the globe, you could use rtt and edns0 client subnet to map users and their locations. https://blogs.akamai.com/2013/03/intelligent-user-mapping-in-the-cloud.html https://blogs.akamai.com/2015/08/end-user-mapping-brings-users-closer-to-internet-nirvana.html Regards, Gustavo. On Fri, Sep 4, 2015 at 7:51 PM, Ray Van Dolson wrote: > Anyone familiar with how Akamai does its geolocation? Presumably they > do more than Maxmind/WHOIS, but I suppose one or both of those could > factor in? > > For those of you with ARIN IP space, do you typically SWIP things to > yourself to help clarify the locations where the IP space physically > resides to feed into Geolocation databases? > > Thanks, > Ray > From mike-nanog at tiedyenetworks.com Sat Sep 5 04:34:46 2015 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 04 Sep 2015 21:34:46 -0700 Subject: Updating dns glue Message-ID: <55EA70E6.50109@tiedyenetworks.com> Hi, Due to a recent fiber cut in northern california, I've stepped up my plan to have one authoritative dns and backup mail exchanger located on another network far, far away. I am sadly having immense trouble with dotster understanding that I need to update the ip address of a glue record, as I host my own stuff, for which their gui has no abillity and which phone support says open a ticket for which the e-mailed response was utter cluelessness, claiming they checked and it's already set... yeah, you recursed and hit my existing ns which gave you the answer, but it's the roots which need to know.... Honestly the last time I mucked with this low level of a function I was actually emailing unenceypted spoofed 'mail from' secured templates to internic. I find the modern registrars to be a huge improvement, but in this regard I am confounded. I needed this done 24 hours ago. Anyone out there can tell me how to get this done? Mike- From patrick at ianai.net Sat Sep 5 04:36:16 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 5 Sep 2015 00:36:16 -0400 Subject: Akamai Geolocation Secret Sauce? In-Reply-To: References: <20150904225108.GA10635@esri.com> Message-ID: Akamai?s DB is frequently updated, not dependent upon SWIP, and has been measured as the most accurate of all the providers for something over a decade. How they do it is proprietary. And sure, it can be wrong. Very wrong. But those times are rare, and they are good at updating when you tell them. If you think about it, Akamai updates its CDN map frequently, and is not limited to the prefixes in the DFZ. So keeping a geo-location DB - not giving away any secrets here, just hypothesizing - seems like it would almost, but not quite, just fall out of all the other work they are doing anyway. -- TTFN, patrick > On Sep 4, 2015, at 11:37 PM, Gustavo Rodrigues Ramos wrote: > > Hello Ray, > > I'm not familiar with Akamai's secret sauce. But I suppose geolocation > databases can be outdated very fast over time and things are getting worst > with the ipv4 depletion... > > However, if you have a very large number of nodes spread across the globe, > you could use rtt and edns0 client subnet to map users and their locations. > > https://blogs.akamai.com/2013/03/intelligent-user-mapping-in-the-cloud.html > https://blogs.akamai.com/2015/08/end-user-mapping-brings-users-closer-to-internet-nirvana.html > > Regards, > Gustavo. > > > On Fri, Sep 4, 2015 at 7:51 PM, Ray Van Dolson wrote: > >> Anyone familiar with how Akamai does its geolocation? Presumably they >> do more than Maxmind/WHOIS, but I suppose one or both of those could >> factor in? >> >> For those of you with ARIN IP space, do you typically SWIP things to >> yourself to help clarify the locations where the IP space physically >> resides to feed into Geolocation databases? >> >> Thanks, >> Ray >> From jabley at hopcount.ca Sat Sep 5 11:20:50 2015 From: jabley at hopcount.ca (Joe Abley) Date: Sat, 05 Sep 2015 07:20:50 -0400 Subject: Updating dns glue In-Reply-To: <55EA70E6.50109@tiedyenetworks.com> References: <55EA70E6.50109@tiedyenetworks.com> Message-ID: <36910B9A-EADC-480A-992D-8258BFC63F07@hopcount.ca> Hi Mike, On 5 Sep 2015, at 0:34, Mike wrote: > Due to a recent fiber cut in northern california, I've stepped up my > plan to have one authoritative dns and backup mail exchanger located > on another network far, far away. I am sadly having immense trouble > with dotster understanding that I need to update the ip address of a > glue record, as I host my own stuff, for which their gui has no > abillity and which phone support says open a ticket for which the > e-mailed response was utter cluelessness, claiming they checked and > it's already set... yeah, you recursed and hit my existing ns which > gave you the answer, but it's the roots which need to know.... Some ideas: 1. You could just add a nameserver. There's no rule that says you have to have exactly two. You could almost certainly have three. (There are some registry-specific rules that specify the minimum and maximum numbers, but I've never seen a registry where the maximum was two.) If you add a new nameserver, and leave your existing two as they are, you've achieved your diversity goal and avoided the problem you're currently struggling with. Apply a touch of mind bleach, and you'll forget that "glue records" are even a thing. 2. There's no universal answer to the question "how do I update glue records in a parent zone". It depends on the registry, and the data model they use to link all the various DNS and meta-DNS information they store. [Incidentally, it's almost never the root server operators that need to know unless you're running a top-level domain (and even then, it's the administrator of the root zone that needs to know, not the root server operators). But when you said "roots" you didn't mean root servers, you meant "operator of the registry for the parent zone".] For registries that follow the data model that was originally used for COM, NET and ORG, what you're looking for is a database operation "modify host object" to happen at the particular registry that contains that host object with addresses (a host object subordinate a the registry apex, you could call it, somewhat inelegantly). Once you've found the right registry, you need to figure out how to make changes. Find the sponsoring registrar for the domain the host object is subordinate to. That's the organisation you need to talk to. For example, QUIRKAFLEEG.NET is a domain with the following listed nameservers: [scallop:~]% whois quirkafleeg.net | egrep '^Name Server: .' Name Server: NS1.P23.DYNECT.NET Name Server: NS2.P23.DYNECT.NET Name Server: NS4.P23.DYNECT.NET Name Server: NS3.P23.DYNECT.NET [scallop:~]% If your whois client needs help in finding out what server to use, try Rodney's very handy .whois-servers.net, e.g. [scallop:~]% host net.whois-servers.net net.whois-servers.net is an alias for whois.verisign-grs.com. whois.verisign-grs.com has address 199.7.50.74 whois.verisign-grs.com has IPv6 address 2001:503:5ae2:1000::74 [scallop:~]% If I decided I wanted to rename NS3.P23.DYNECT.NET, I would need to identify the sponsoring registrar for the DYNECT.NET domain name: [scallop:~]% whois dynect.net | egrep '^Registrar:' Registrar: DYNAMIC NETWORK SERVICES, INC [scallop:~]% The registrant (the person who "owns" the domain) in this case is: [scallop:~]% whois dynect.net | egrep '^Registrant' Registrant Name: Dynamic Network Services Registrant Organization: Dyn Registrant Street: 150 Dow St, Tower 2 Registrant City: Manchester Registrant State/Province: NH Registrant Postal Code: 03101 Registrant Country: US Registrant Phone: +1.6036684998 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: Domains at dyn.com [scallop:~]% So those are the people I would ask to rename (say) NS3.P23.DYNECT.NET. Of course in this case they would say "haha, no" and probably advise me to add a nameserver rather than trying to reconfigure their commercial DNS service. But you get the idea; if the nameserver you want to rename is subordinate to a domain name you have administrative control over, you could interact with the registrar for the domain and make the change. The precise way a particular registrar will accept such a change varies by registrar. Sometimes (I hear) the user interface involves phone calls and shouting. But then you have a choice of registrar, if you can figure out how to make transfers work. If your domain and/or nameservers are not named under NET, ORG or COM, the above may be useful or, quite possibly, completely irrelevant, depending on factors that your registrar is in theory supposed to hide from you. There are as many other data models as there are other TLDs, almost-maybe, and I certainly don't know the details of all or even many of them. If this is sounding very XKCD-927, that's because it is. This is perhaps why lots of people pay others to do this for them (registry/registrar shenanigans and DNS hosting) so that they can live their lives with one less thing to be angry about. Joe From pfsinoz at gmail.com Sat Sep 5 14:04:04 2015 From: pfsinoz at gmail.com (Philip Smith) Date: Sat, 5 Sep 2015 21:04:04 +0700 Subject: Weekly Routing Table Report In-Reply-To: <20150904182049.GF18282@bamboo.slabnet.com> References: <201509041802.t84I276Z001927@thyme.rand.apnic.net> <20150904182049.GF18282@bamboo.slabnet.com> Message-ID: <55EAF654.60609@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Hugo, Hugo Slabbert wrote on 5/09/2015 01:20 : > >> BGP routing table entries examined: >> 30167 > ... >> Percentage of available address space announced: >> 7.0 Percentage of allocated address space announced: >> 7.0 > > erm...y'all missing some prefixes on the collector for the report? Yes. :-( Seems like the dump from the collector happened just after a BGP reset (or something). I'm checking that now, or whether something else has broken. Sorry!! philip - -- -----BEGIN PGP SIGNATURE----- iD8DBQFV6vZUnFcIO/K8+cERAtmoAKDjjz1Fzl3PvO7DY3OeMSYAUHrpfgCgh9PH ttXi696fTFOS+6MpAmJdgv0= =HExi -----END PGP SIGNATURE----- From cscora at apnic.net Sat Sep 5 14:11:31 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sun, 6 Sep 2015 00:11:31 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201509051411.t85EBVcT002677@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 0400 +10GMT Sat 05 Sep, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 557095 Prefixes after maximum aggregation (per Origin AS): 210220 Deaggregation factor: 2.65 Unique aggregates announced (without unneeded subnets): 273158 Total ASes present in the Internet Routing Table: 51335 Prefixes per ASN: 10.85 Origin-only ASes present in the Internet Routing Table: 36652 Origin ASes announcing only one prefix: 16121 Transit ASes present in the Internet Routing Table: 6394 Transit-only ASes present in the Internet Routing Table: 174 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 45 Max AS path prepend of ASN ( 55644) 41 Prefixes from unregistered ASNs in the Routing Table: 1084 Unregistered ASNs in the Routing Table: 417 Number of 32-bit ASNs allocated by the RIRs: 10864 Number of 32-bit ASNs visible in the Routing Table: 8289 Prefixes from 32-bit ASNs in the Routing Table: 31110 Number of bogon 32-bit ASNs visible in the Routing Table: 19 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 549 Number of addresses announced to Internet: 2791677888 Equivalent to 166 /8s, 101 /16s and 159 /24s Percentage of available address space announced: 75.4 Percentage of allocated address space announced: 75.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.6 Total number of prefixes smaller than registry allocations: 185801 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 137442 Total APNIC prefixes after maximum aggregation: 39619 APNIC Deaggregation factor: 3.47 Prefixes being announced from the APNIC address blocks: 144696 Unique aggregates announced from the APNIC address blocks: 59649 APNIC Region origin ASes present in the Internet Routing Table: 5082 APNIC Prefixes per ASN: 28.47 APNIC Region origin ASes announcing only one prefix: 1207 APNIC Region transit ASes present in the Internet Routing Table: 890 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 38 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1616 Number of APNIC addresses announced to Internet: 752104064 Equivalent to 44 /8s, 212 /16s and 50 /24s Percentage of available APNIC address space announced: 87.9 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: 180364 Total ARIN prefixes after maximum aggregation: 88403 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 183248 Unique aggregates announced from the ARIN address blocks: 86047 ARIN Region origin ASes present in the Internet Routing Table: 16586 ARIN Prefixes per ASN: 11.05 ARIN Region origin ASes announcing only one prefix: 6062 ARIN Region transit ASes present in the Internet Routing Table: 1738 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 647 Number of ARIN addresses announced to Internet: 1101600192 Equivalent to 65 /8s, 169 /16s and 21 /24s Percentage of available ARIN address space announced: 58.3 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, 64198-64296, 393216-395164 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: 135119 Total RIPE prefixes after maximum aggregation: 67450 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 142046 Unique aggregates announced from the RIPE address blocks: 88128 RIPE Region origin ASes present in the Internet Routing Table: 17968 RIPE Prefixes per ASN: 7.91 RIPE Region origin ASes announcing only one prefix: 8043 RIPE Region transit ASes present in the Internet Routing Table: 2997 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: 3989 Number of RIPE addresses announced to Internet: 699409536 Equivalent to 41 /8s, 176 /16s and 36 /24s Percentage of available RIPE address space announced: 101.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 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: 60887 Total LACNIC prefixes after maximum aggregation: 11605 LACNIC Deaggregation factor: 5.25 Prefixes being announced from the LACNIC address blocks: 72568 Unique aggregates announced from the LACNIC address blocks: 33625 LACNIC Region origin ASes present in the Internet Routing Table: 2465 LACNIC Prefixes per ASN: 29.44 LACNIC Region origin ASes announcing only one prefix: 614 LACNIC Region transit ASes present in the Internet Routing Table: 524 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 28 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1894 Number of LACNIC addresses announced to Internet: 168755968 Equivalent to 10 /8s, 15 /16s and 3 /24s Percentage of available LACNIC address space announced: 100.6 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: 12049 Total AfriNIC prefixes after maximum aggregation: 3097 AfriNIC Deaggregation factor: 3.89 Prefixes being announced from the AfriNIC address blocks: 13988 Unique aggregates announced from the AfriNIC address blocks: 5344 AfriNIC Region origin ASes present in the Internet Routing Table: 740 AfriNIC Prefixes per ASN: 18.90 AfriNIC Region origin ASes announcing only one prefix: 195 AfriNIC Region transit ASes present in the Internet Routing Table: 164 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 143 Number of AfriNIC addresses announced to Internet: 69319936 Equivalent to 4 /8s, 33 /16s and 189 /24s Percentage of available AfriNIC address space announced: 68.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 3000 11134 979 Korea Telecom 7545 2769 339 134 TPG Telecom Limited 17974 2709 904 80 PT Telekomunikasi Indonesia 4755 2041 427 229 TATA Communications formerly 4538 1946 4190 71 China Education and Research 9829 1875 1374 201 National Internet Backbone 9808 1585 8639 18 Guangdong Mobile Communicatio 4808 1529 2254 474 CNCGROUP IP network China169 9583 1526 121 570 Sify Limited 7552 1423 1084 9 Viettel Corporation 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 3165 2960 139 Cox Communications Inc. 6389 2696 3688 51 BellSouth.net Inc. 3356 2535 10709 499 Level 3 Communications, Inc. 18566 2146 389 257 MegaPath Corporation 20115 1881 1864 395 Charter Communications 6983 1739 850 243 EarthLink, Inc. 4323 1583 1005 404 tw telecom holdings, inc. 30036 1577 319 451 Mediacom Communications Corp 701 1404 11401 679 MCI Communications Services, 22561 1375 415 258 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 20940 2103 830 1528 Akamai International B.V. 34984 2014 306 377 TELLCOM ILETISIM HIZMETLERI A 6849 1209 355 21 JSC "Ukrtelecom" 13188 1070 97 77 TOV "Bank-Inform" 31148 1049 46 23 Freenet Ltd. 8402 1010 544 15 OJSC "Vimpelcom" 12479 990 965 78 France Telecom Espana SA 8551 984 376 52 Bezeq International-Ltd 6830 917 2694 468 Liberty Global Operations B.V 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 3349 538 167 Telmex Colombia S.A. 28573 2286 2169 124 NET Servi?os de Comunica??o S 8151 1707 3272 481 Uninet S.A. de C.V. 7303 1556 932 238 Telecom Argentina S.A. 6147 1443 374 30 Telefonica del Peru S.A.A. 6503 1285 445 58 Axtel, S.A.B. de C.V. 26615 1098 2325 35 Tim Celular S.A. 7738 997 1882 41 Telemar Norte Leste S.A. 3816 952 436 163 COLOMBIA TELECOMUNICACIONES S 11830 916 364 15 Instituto Costarricense de El 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 902 1470 14 TE-AS 24863 768 280 41 Link Egypt (Link.NET) 36903 512 258 99 Office National des Postes et 36992 439 1229 32 ETISALAT MISR 24835 280 146 12 Vodafone Data 3741 247 855 203 Internet Solutions 29571 247 21 13 Cote d'Ivoire Telecom 37054 220 20 7 Data Telecom Service 36947 183 807 13 Telecom Algeria 15706 173 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 3349 538 167 Telmex Colombia S.A. 22773 3165 2960 139 Cox Communications Inc. 4766 3000 11134 979 Korea Telecom 7545 2769 339 134 TPG Telecom Limited 17974 2709 904 80 PT Telekomunikasi Indonesia 6389 2696 3688 51 BellSouth.net Inc. 3356 2535 10709 499 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2286 2169 124 NET Servi?os de Comunica??o S 18566 2146 389 257 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 3165 3026 Cox Communications Inc. 6389 2696 2645 BellSouth.net Inc. 7545 2769 2635 TPG Telecom Limited 17974 2709 2629 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 28573 2286 2162 NET Servi?os de Comunica??o S 3356 2535 2036 Level 3 Communications, Inc. 4766 3000 2021 Korea Telecom 18566 2146 1889 MegaPath Corporation 4538 1946 1875 China Education and Research 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 47092 UNALLOCATED 8.8.204.0/24 16410 The Reynolds and Rey 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 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 Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.100.1.0/24 9730 Bharti Telesonic Ltd Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 23.249.144.0/21 40430 colo4jax, LLC 23.249.152.0/21 40430 colo4jax, LLC 27.50.8.0/24 55548 Ravibhawan 27.50.9.0/24 55548 Ravibhawan 27.50.10.0/23 55548 Ravibhawan 27.100.7.0/24 56096 >>UNKNOWN<< 31.170.96.0/23 23456 32bit Transition AS 31.217.248.0/21 44902 COVAGE NETWORKS SASU 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:17 /9:13 /10:36 /11:96 /12:261 /13:500 /14:1005 /15:1739 /16:12892 /17:7224 /18:12408 /19:25587 /20:36125 /21:38819 /22:61139 /23:53320 /24:303614 /25:855 /26:928 /27:458 /28:14 /29:14 /30:9 /31:0 /32:22 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2380 3165 Cox Communications Inc. 18566 2061 2146 MegaPath Corporation 6389 1608 2696 BellSouth.net Inc. 30036 1397 1577 Mediacom Communications Corp 6983 1386 1739 EarthLink, Inc. 34984 1334 2014 TELLCOM ILETISIM HIZMETLERI A 10620 1227 3349 Telmex Colombia S.A. 11492 1124 1207 CABLE ONE, INC. 22561 1048 1375 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1574 2:689 4:97 5:1881 6:25 8:1403 11:1 12:1810 13:19 14:1414 15:17 16:2 17:49 18:22 20:49 23:1276 24:1752 27:2085 31:1612 32:37 33:2 34:4 35:3 36:163 37:2050 38:1057 39:15 40:71 41:2795 42:341 43:1508 44:30 45:1078 46:2370 47:54 49:937 50:792 52:22 54:86 55:5 56:28 57:42 58:1372 59:716 60:486 61:1757 62:1375 63:1899 64:4432 65:2251 66:3986 67:2054 68:1066 69:3230 70:1041 71:448 72:1972 74:2587 75:357 76:396 77:1357 78:1156 79:810 80:1356 81:1350 82:864 83:723 84:769 85:1385 86:450 87:1025 88:537 89:1932 90:150 91:5946 92:842 93:2264 94:2078 95:2159 96:422 97:348 98:970 99:55 100:72 101:847 103:8216 104:2025 105:87 106:347 107:1053 108:623 109:2143 110:1192 111:1467 112:823 113:1111 114:847 115:1328 116:1455 117:1103 118:1941 119:1472 120:451 121:1098 122:2173 123:1848 124:1517 125:1673 128:663 129:396 130:432 131:1247 132:500 133:165 134:416 135:103 136:340 137:316 138:1205 139:162 140:250 141:435 142:679 143:542 144:551 145:126 146:791 147:586 148:1253 149:432 150:594 151:796 152:531 153:254 154:510 155:871 156:422 157:422 158:347 159:1032 160:412 161:676 162:2049 163:452 164:693 165:715 166:301 167:868 168:1252 169:194 170:1476 171:249 172:253 173:1500 174:716 175:711 176:1429 177:3963 178:2187 179:983 180:1950 181:1671 182:1821 183:632 184:744 185:4200 186:2990 187:1837 188:2093 189:1638 190:7763 191:1150 192:8548 193:5662 194:4232 195:3652 196:1969 197:1066 198:5474 199:5527 200:6705 201:3304 202:9544 203:9188 204:4632 205:2888 206:3112 207:3042 208:3995 209:3919 210:3605 211:1930 212:2565 213:2229 214:860 215:74 216:5761 217:1789 218:734 219:466 220:1549 221:810 222:475 223:819 End of report From mike-nanog at tiedyenetworks.com Sat Sep 5 16:43:25 2015 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sat, 05 Sep 2015 09:43:25 -0700 Subject: Updating dns glue In-Reply-To: <36910B9A-EADC-480A-992D-8258BFC63F07@hopcount.ca> References: <55EA70E6.50109@tiedyenetworks.com> <36910B9A-EADC-480A-992D-8258BFC63F07@hopcount.ca> Message-ID: <55EB1BAD.2050904@tiedyenetworks.com> > Some ideas: > > 1. You could just add a nameserver. There's no rule that says you have > to have exactly two. You could almost certainly have three. (There are > some registry-specific rules that specify the minimum and maximum > numbers, but I've never seen a registry where the maximum was two.) If > you add a new nameserver, and leave your existing two as they are, > you've achieved your diversity goal and avoided the problem you're > currently struggling with. Apply a touch of mind bleach, and you'll > forget that "glue records" are even a thing. > Unfortunately, I have other customer hosted domains and they also are listed only with 'ns1' and 'ns2' of my domain, therefore, if there is an outage, unless I can actually update the ip of 'ns2' to my new off-network host, those other domains are still a fail. Changing the ip of the host is the right answer in this situation. > So those are the people I would ask to rename (say) > NS3.P23.DYNECT.NET. Of course in this case they would say "haha, no" > and probably advise me to add a nameserver rather than trying to > reconfigure their commercial DNS service. But you get the idea; if the > nameserver you want to rename is subordinate to a domain name you have > administrative control over, you could interact with the registrar for > the domain and make the change. > > The precise way a particular registrar will accept such a change > varies by registrar. Sometimes (I hear) the user interface involves > phone calls and shouting. But then you have a choice of registrar, if > you can figure out how to make transfers work. > This seems to be the case with dotster. I apologise to anyone over there who may be reading, but it seems that they are completely clueless. They've told me again in support they affected the change, but I can see that all they did was update their own customer hosting account zone data and not actually push it out to the roots (or more correctly the gtld's?). > If your domain and/or nameservers are not named under NET, ORG or COM, > the above may be useful or, quite possibly, completely irrelevant, > depending on factors that your registrar is in theory supposed to hide > from you. There are as many other data models as there are other TLDs, > almost-maybe, and I certainly don't know the details of all or even > many of them. > > If this is sounding very XKCD-927, that's because it is. This is > perhaps why lots of people pay others to do this for them > (registry/registrar shenanigans and DNS hosting) so that they can live > their lives with one less thing to be angry about. > So what I need is a registrar with a clue about the glue... Open to suggestions here... Mike- From david at zeromail.us Thu Sep 3 14:59:02 2015 From: david at zeromail.us (David S.) Date: Thu, 3 Sep 2015 21:59:02 +0700 Subject: Whois.net down? In-Reply-To: <20150903143956.GH78209@numachi.com> References: <20150903143956.GH78209@numachi.com> Message-ID: Hi Brian, I'm able to access https://whois.net, have you check the nameserver of numachi.com? Is the other domain use same authoritative DNS? Best regards, David S. ------------------------------------------------ e. david at zeromail.us w. http://blog.pnyet.web.id On Thu, Sep 3, 2015 at 9:39 PM, Brian Reichert wrote: > I'm trying to use https://www.whois.net/ to resolve info about > several domains, including my own (NUMACHI.COM). > > For several domains (but not all, I get 'Error extracting data. No > data available'. There's a 'please read' tag, but no text associated > with it. > > Anyone know if they're having issues there? > > -- > Brian Reichert > BSD admin/developer at large > From ignactro at gmail.com Fri Sep 4 16:43:12 2015 From: ignactro at gmail.com (Ignacio de castro) Date: Fri, 4 Sep 2015 17:43:12 +0100 Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <20150904112549.6b010c43@localhost> Message-ID: For a more academic perspective: "Software-defined networking: A comprehensive survey" http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6994333&tag=1 On Fri, Sep 4, 2015 at 5:35 PM, Ignacio de castro wrote: > For a more academic perspective: > "Software-defined networking: A comprehensive survey" > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6994333&tag=1 > > On Fri, Sep 4, 2015 at 5:25 PM, John Kristoff wrote: > >> On Fri, 4 Sep 2015 14:40:31 +0000 >> Rod Beck wrote: >> >> > Can anyone provide references on this top so I can educate myself? >> >> A bit more effort will be required on your part to get the most out >> it, but one potentially in depth resource would be Nick Feamster's >> Software Defined Networking course, currently available through >> Coursera: >> >> >> >> John >> > > From jheitz at cisco.com Wed Sep 2 18:38:42 2015 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Wed, 2 Sep 2015 18:38:42 +0000 Subject: BGP advertise-best-external on RR Message-ID: <075DE01702BBC249BE1357EFD20DCFE51E929D3B@xmb-aln-x02.cisco.com> If your network is such that only a handful of routers supply redundant paths, then you can set up iBGP sessions with those directly without going via route reflectors. You can have most routes going through reflectors and a few through direct BGP sessions. Not everything needs to go through route reflectors. You can even do both: Have a router peer with a reflector as well as directly if you only need the redundant routes in a few places. You will end up with duplicate routes, but that's not a show stopper. You can avoid duplicate routes with route maps. You can have multiple route reflectors with different cluster IDs that carry the redundant routes only. Clients can peer with multiple clusters. Use route maps to avoid duplicate routes. These last things get complicated to manage, so I'd still go for add-path if at all possible. --Jakob > Message: 2 > Date: Tue, 1 Sep 2015 14:51:27 +0200 > From: Mohamed Kamal > To: Jeff Tantsura , Diptanshu Singh > > Cc: NANOG > Subject: Re: BGP advertise-best-external on RR > Message-ID: <55E59F4F.8010704 at noor.net> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hi, > > Diverse-path will only send the second best path, and in my case I have > three routes not two. In addition to that, every PE will have to peer > with the RR via a second session (on the same RR, as I will not deploy a > new standalone shadow RR) and this will increase the BGP sessions to the > double. > > Add-path will have a network-wide IOS upgrade for this BGP capability to > be supported which is not viable now. > > So, is there any other recommendation other than the internet VRF with > different RDs solution? > > Regards, > > Mohamed Kamal > Core Network Sr. Engineer > > On 8/25/2015 11:37 AM, Jeff Tantsura wrote: > > Hi, > > > > In your case I?d recommend to use diverse path, due to its simplicity and > > non disruptive deployment characteristics. > > As you know - diverse path requires additional BGP session per additional > > (second, next, etc) path, in most cases not a problem, however mileage > > might vary. > > > > To my memory, in Cisco land - it has only been implemented in IOS, not XR, > > please check. > > > > Cheers, > > Jeff > > > > > > > > > > -----Original Message----- > > From: Diptanshu Singh > > Date: Monday, August 24, 2015 at 10:53 PM > > To: Mohamed Kamal > > Cc: "nanog at nanog.org" > > Subject: Re: BGP advertise-best-external on RR > > > >> Yes . In the case of diverse path , shadow route reflector will be the > >> one wherever you enable commands to trigger diverse path computation. > >> > >> Good thing with diverse path is that the RR-Clients don't have to have > >> any support but bad thing is that it can only reflect One additional > >> best-path( second best path ) . > >> > >> Sent from my iPhone > >> > >>> On Aug 24, 2015, at 2:31 PM, Mohamed Kamal wrote: > >>> > >>> It's only supported on the 15.2(4)S and later not the SRE train. I > >>> might consider an upgrade. > >>> > >>> One more question regarding this, can you configure the RR to be the > >>> main and shadow RR? > >>> > >>> Mohamed Kamal > >>> Core Network Sr. Engineer > >>> > >>>> On 8/24/2015 9:16 PM, Diptanshu Singh wrote: > >>>> BGP Add-Path might be your friend . You can look at diverse-path as > >>>> well . > > From narseo at gmail.com Fri Sep 4 15:23:28 2015 From: narseo at gmail.com (Narseo Vallina Rodriguez) Date: Fri, 4 Sep 2015 17:23:28 +0200 Subject: Software Defined Networking In-Reply-To: <20D6B20E-6315-4E0E-A10B-EB8E7DB51FD8@lboro.ac.uk> References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <20D6B20E-6315-4E0E-A10B-EB8E7DB51FD8@lboro.ac.uk> Message-ID: There's also a quite comprehensive survey from an academic angle: http://arxiv.org/abs/1406.0440 From me at tylermills.net Fri Sep 4 18:35:37 2015 From: me at tylermills.net (Tyler Mills) Date: Fri, 04 Sep 2015 18:35:37 +0000 Subject: Software Defined Networking In-Reply-To: <55E9E32A.2060104@cox.net> References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <55E9D921.6090506@cox.net> <55E9E32A.2060104@cox.net> Message-ID: Would be hard to prove that you implicitly agreed to the constraints mentioned within the email by just merely receiving it and reading it. Even EULA's require you to check a box or click "I Accept." On Fri, Sep 4, 2015, 2:30 PM Larry Sheldon wrote: > On 9/4/2015 12:57, Aaron C. de Bruyn wrote: > > I think it's time to change my SMTP greeting to: > > > > 220-By submitting e-mail to this server, you agree all legal > > disclaimers are null and void. > > 220 You also agree that I am awesome. > > I like that. Unfortunately, I no longer operate a mail host. > > I have been trying to figure out how to mechanically route messages > containing them to the spam sump. > > IANAL, but I thing an interesting case would be trying to enforce that > crap in a situation involving unsolicited email (as in this case). > > -- > sed quis custodiet ipsos custodes? (Juvenal) > From jrex at CS.Princeton.EDU Sat Sep 5 17:17:57 2015 From: jrex at CS.Princeton.EDU (Jennifer Rexford) Date: Sat, 5 Sep 2015 13:17:57 -0400 Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <20150904112549.6b010c43@localhost> Message-ID: For a short survey and history, see also "The road to SDN: An intellectual history of programmable networks" http://queue.acm.org/detail.cfm?id=2560327 Also, the lectures and interviews from Nick Feamster's coursera course are available on YouTube: https://m.youtube.com/user/nfeamster?noapp=1 -- Jen > On Sep 4, 2015, at 12:43 PM, Ignacio de castro wrote: > > For a more academic perspective: > "Software-defined networking: A comprehensive survey" > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6994333&tag=1 > > > On Fri, Sep 4, 2015 at 5:35 PM, Ignacio de castro > wrote: > >> For a more academic perspective: >> "Software-defined networking: A comprehensive survey" >> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6994333&tag=1 >> >>> On Fri, Sep 4, 2015 at 5:25 PM, John Kristoff wrote: >>> >>> On Fri, 4 Sep 2015 14:40:31 +0000 >>> Rod Beck wrote: >>> >>>> Can anyone provide references on this top so I can educate myself? >>> >>> A bit more effort will be required on your part to get the most out >>> it, but one potentially in depth resource would be Nick Feamster's >>> Software Defined Networking course, currently available through >>> Coursera: >>> >>> >>> >>> John >> >> From jared at puck.nether.net Sat Sep 5 17:35:30 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 5 Sep 2015 13:35:30 -0400 Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <55E9D921.6090506@cox.net> <55E9E32A.2060104@cox.net> Message-ID: These disclaimers have been proven to be added by the paranoid. eg: http://articles.chicagotribune.com/2011-08-26/business/ct-biz-0826-chicago-law-20110826_1_disclaimers-legal-obligations-binding Basically, unless you already have an existing written NDA you?re likely not bound. Your company may have an NDA between yourself and a vendor, carrier or otherwise. If you?re not sure, ask. - Jared > On Sep 4, 2015, at 2:35 PM, Tyler Mills wrote: > > Would be hard to prove that you implicitly agreed to the constraints > mentioned within the email by just merely receiving it and reading it. > Even EULA's require you to check a box or click "I Accept." > > On Fri, Sep 4, 2015, 2:30 PM Larry Sheldon wrote: > >> On 9/4/2015 12:57, Aaron C. de Bruyn wrote: >>> I think it's time to change my SMTP greeting to: >>> >>> 220-By submitting e-mail to this server, you agree all legal >>> disclaimers are null and void. >>> 220 You also agree that I am awesome. >> >> I like that. Unfortunately, I no longer operate a mail host. >> >> I have been trying to figure out how to mechanically route messages >> containing them to the spam sump. >> >> IANAL, but I thing an interesting case would be trying to enforce that >> crap in a situation involving unsolicited email (as in this case). >> >> -- >> sed quis custodiet ipsos custodes? (Juvenal) >> From colinj at gt86car.org.uk Sat Sep 5 17:36:31 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Sat, 5 Sep 2015 18:36:31 +0100 Subject: Weekly Routing Table Report In-Reply-To: <55EAF654.60609@gmail.com> References: <201509041802.t84I276Z001927@thyme.rand.apnic.net> <20150904182049.GF18282@bamboo.slabnet.com> <55EAF654.60609@gmail.com> Message-ID: that might be solved in future with a dump to a storage area, diff of previous dump and flag problem if diff show significant difference colin Sent from my iPhone > On 5 Sep 2015, at 15:04, Philip Smith wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Hugo, > > Hugo Slabbert wrote on 5/09/2015 01:20 : >> >>> BGP routing table entries examined: >>> 30167 >> ... >>> Percentage of available address space announced: >>> 7.0 Percentage of allocated address space announced: >>> 7.0 >> >> erm...y'all missing some prefixes on the collector for the report? > > Yes. :-( > > Seems like the dump from the collector happened just after a BGP reset > (or something). I'm checking that now, or whether something else has > broken. > > Sorry!! > > philip > - -- > -----BEGIN PGP SIGNATURE----- > > iD8DBQFV6vZUnFcIO/K8+cERAtmoAKDjjz1Fzl3PvO7DY3OeMSYAUHrpfgCgh9PH > ttXi696fTFOS+6MpAmJdgv0= > =HExi > -----END PGP SIGNATURE----- From frnkblk at iname.com Sat Sep 5 18:00:31 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 5 Sep 2015 13:00:31 -0500 Subject: NetFlow - path from Routers to Collector In-Reply-To: <20150902003037.1F2A5550C6B41@freedman.net> References: <20150902003037.1F2A5550C6B41@freedman.net> Message-ID: <006601d0e804$c30a74e0$491f5ea0$@iname.com> How many IPv6 addresses do you get? Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Avi Freedman Sent: Tuesday, September 01, 2015 7:31 PM To: Jared Mauch Cc: NANOG Subject: Re: NetFlow - path from Routers to Collector (Jared wrote): > Most people I've seen have little data or insight into their > networks, or don't have the level that they would desire as > tools are expensive or impossible to justify due to capital costs. > Tossing in a recurring opex cost of DC XC fee + transport + XC fee + > redundant aggregation often doesn't have the ROI you infer here. > I've put together some models in this area. It seems to me the > DC/real estate companies involved could make a lot (more) money by > offering an OOB service that is 10Mb/s flat-rate for the same as an XC > fee and compete with their customers. Equinix does have a very aggressively priced 10Mb/s flat-rate OOB (single IP only but that's not that hard to work around) for essentially XC pricing. It's been stable but not something you'd rely on for 100% packet delivery to some other point on the Internet (so more for reaching a per-pop OOB than for making a coherent OOB network with a bunch of monitoring running 24x7). Still, it's a good value for what it is. > - Jared Avi Freedman CEO, Kentik avi at kentik dot com From surfer at mauigateway.com Sat Sep 5 18:58:38 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 5 Sep 2015 11:58:38 -0700 Subject: Software Defined Networking Message-ID: <20150905115838.99C9BC3A@m0005309.ppops.net> --- ignactro at gmail.com wrote: From: Ignacio de castro For a more academic perspective: "Software-defined networking: A comprehensive survey" http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6994333&tag=1 ------------------------------------------ Can't read it. They suck: You have been redirected to this page for one of the following reasons: Either cookies are not enabled on your browser or Your network configuration is causing cookies to be lost or not function properly. IEEE Xplore requires cookies to maintain sessions and to access licensed content. Cookies are used temporarily to maintain sessions in IEEE Xplore and for no other purpose. The cookies will not persist after a session ends. Please change your browser settings to accept cookies before you access IEEE Xplore. scott From shortdudey123 at gmail.com Sat Sep 5 21:38:02 2015 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sat, 5 Sep 2015 14:38:02 -0700 Subject: weather.gov invalid ssl cert Message-ID: If someone that works with or knows someone who works with weather.gov (National Weather Service) please take a look at this. I did a whois on weather.gov and there is no contact info. www.weather.gov is serving an akami cert weather.gov is serving a NWS SAN cert that does not cover weather.gov (includes www though) username at hostname ~ $ echo quit | openssl s_client -connect weather.gov:443 | openssl x509 -text depth=3 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0 DONE Certificate: Data: Version: 3 (0x2) Serial Number: 07:a2:c1:cb:fa:c1:18 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU= http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2 Validity Not Before: Nov 13 20:54:35 2014 GMT Not After : Nov 17 17:33:22 2015 GMT Subject: OU=Domain Control Validated, CN=ucc.weather.gov Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:9d:36:e8:eb:5d:00:1d:ce:ab:f2:6a:3f:83:5a: 39:29:dd:95:e9:bd:58:d7:2b:0f:67:5a:16:20:97: 2d:4c:96:e1:3c:cc:8f:2f:16:88:ae:fe:9c:15:d0: 67:f1:c9:0d:5c:c0:ae:3f:36:32:aa:90:1d:03:bb: d2:91:73:86:74:5f:e3:41:f2:e2:77:b3:5e:1c:a9: cc:9c:68:3a:99:3a:de:7a:19:bd:6a:70:a1:9f:3f: 1f:ec:c3:63:fd:e9:f5:e6:44:14:0d:db:ae:b4:46: fe:a8:b0:d7:07:01:ea:68:10:7f:9f:c8:f7:5a:20: 05:1d:77:47:d7:13:d1:f0:b8:8f:d2:94:a0:36:29: 95:c2:fd:3e:bc:80:14:1f:22:a2:5a:d0:56:5b:e6: 51:e1:94:3c:4c:dd:63:ae:81:42:7c:5e:87:f5:0c: b8:6f:37:f4:a6:53:f6:56:5e:c8:ec:57:f8:ec:0c: 7d:e0:11:7f:3d:07:8c:37:38:4e:05:8e:cd:46:b3: 21:a3:c1:2f:96:ee:e2:d7:5f:ed:8c:1c:6d:88:d7: 17:ba:90:d8:cb:49:2e:8d:4f:ca:bf:8c:53:da:f7: 38:9c:bc:e1:6c:ac:8a:62:27:d1:ec:dc:59:a9:3b: 62:07:68:3b:bd:d0:06:35:79:26:2d:83:4d:69:00: f3:d7 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 CRL Distribution Points: URI:http://crl.godaddy.com/gdig2s1-87.crl X509v3 Certificate Policies: Policy: 2.16.840.1.114413.1.7.23.1 CPS: http://certificates.godaddy.com/repository/ Authority Information Access: OCSP - URI:http://ocsp.godaddy.com/ CA Issuers - URI: http://certificates.godaddy.com/repository/gdig2.crt X509v3 Authority Key Identifier: keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE X509v3 Subject Alternative Name: DNS:ucc.weather.gov, DNS:www.ucc.weather.gov, DNS: alerts.weather.gov, DNS:nwschat.weather.gov, DNS:vpn.weather.gov, DNS: www.weather.gov X509v3 Subject Key Identifier: 01:7D:76:D9:61:68:EB:50:F7:C4:26:02:DC:94:56:62:45:0B:5B:58 Signature Algorithm: sha256WithRSAEncryption 96:4e:70:45:46:f8:69:80:48:b8:88:86:cd:06:2b:7b:d6:f1: 6b:0b:d8:89:ab:e8:9a:c0:f1:a8:99:0c:69:45:f8:a7:fb:ef: af:b3:6b:0d:41:bd:4d:3c:76:11:10:89:fa:8f:12:a5:47:27: 50:44:e7:37:93:f3:6b:84:f2:66:34:0d:99:69:13:da:dd:08: 32:6c:30:be:2e:af:8b:25:aa:9a:40:bf:61:35:a9:d9:2d:da: 97:b0:0c:e6:98:72:54:fe:44:21:6d:ad:9a:0a:cd:0b:18:74: be:f2:58:b0:d6:10:9b:dc:b7:fe:ae:81:b3:c0:21:f9:c8:eb: d5:54:bc:9e:d6:d0:ca:12:5c:c0:0d:94:93:03:9b:54:46:b8: af:86:46:e6:e0:4b:52:97:c2:8e:16:89:3c:8d:06:f8:f9:59: d6:21:39:4c:25:82:58:49:59:07:43:db:63:8d:98:aa:04:c1: 42:f5:4f:8a:4d:35:5b:f7:79:e5:e1:31:13:72:50:87:bd:68: 3f:bd:23:e2:88:3e:cf:72:00:a7:c8:1d:40:b6:34:00:5b:7b: 73:9f:8f:17:05:53:13:a1:70:15:59:66:88:61:6a:d7:d0:bf: df:89:1a:28:af:a8:cb:c7:95:e4:f9:01:7b:c2:99:51:93:33: 8f:94:fa:0b -----BEGIN CERTIFICATE----- MIIFdzCCBF+gAwIBAgIHB6LBy/rBGDANBgkqhkiG9w0BAQsFADCBtDELMAkGA1UE BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMS0wKwYDVQQLEyRodHRwOi8vY2VydHMu Z29kYWRkeS5jb20vcmVwb3NpdG9yeS8xMzAxBgNVBAMTKkdvIERhZGR5IFNlY3Vy ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgLSBHMjAeFw0xNDExMTMyMDU0MzVaFw0x NTExMTcxNzMzMjJaMD0xITAfBgNVBAsTGERvbWFpbiBDb250cm9sIFZhbGlkYXRl ZDEYMBYGA1UEAxMPdWNjLndlYXRoZXIuZ292MIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAnTbo610AHc6r8mo/g1o5Kd2V6b1Y1ysPZ1oWIJctTJbhPMyP LxaIrv6cFdBn8ckNXMCuPzYyqpAdA7vSkXOGdF/jQfLid7NeHKnMnGg6mTreehm9 anChnz8f7MNj/en15kQUDduutEb+qLDXBwHqaBB/n8j3WiAFHXdH1xPR8LiP0pSg NimVwv0+vIAUHyKiWtBWW+ZR4ZQ8TN1jroFCfF6H9Qy4bzf0plP2Vl7I7Ff47Ax9 4BF/PQeMNzhOBY7NRrMho8Evlu7i11/tjBxtiNcXupDYy0kujU/Kv4xT2vc4nLzh bKyKYifR7NxZqTtiB2g7vdAGNXkmLYNNaQDz1wIDAQABo4ICAjCCAf4wDAYDVR0T AQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/ BAQDAgWgMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ29kYWRkeS5jb20v Z2RpZzJzMS04Ny5jcmwwUwYDVR0gBEwwSjBIBgtghkgBhv1tAQcXATA5MDcGCCsG AQUFBwIBFitodHRwOi8vY2VydGlmaWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRv cnkvMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZ29k YWRkeS5jb20vMEAGCCsGAQUFBzAChjRodHRwOi8vY2VydGlmaWNhdGVzLmdvZGFk ZHkuY29tL3JlcG9zaXRvcnkvZ2RpZzIuY3J0MB8GA1UdIwQYMBaAFEDCvSeOzDSD MKIz1/tss/C0LIDOMHoGA1UdEQRzMHGCD3VjYy53ZWF0aGVyLmdvdoITd3d3LnVj Yy53ZWF0aGVyLmdvdoISYWxlcnRzLndlYXRoZXIuZ292ghNud3NjaGF0LndlYXRo ZXIuZ292gg92cG4ud2VhdGhlci5nb3aCD3d3dy53ZWF0aGVyLmdvdjAdBgNVHQ4E FgQUAX122WFo61D3xCYC3JRWYkULW1gwDQYJKoZIhvcNAQELBQADggEBAJZOcEVG +GmASLiIhs0GK3vW8WsL2Imr6JrA8aiZDGlF+Kf776+zaw1BvU08dhEQifqPEqVH J1BE5zeT82uE8mY0DZlpE9rdCDJsML4ur4slqppAv2E1qdkt2pewDOaYclT+RCFt rZoKzQsYdL7yWLDWEJvct/6ugbPAIfnI69VUvJ7W0MoSXMANlJMDm1RGuK+GRubg S1KXwo4WiTyNBvj5WdYhOUwlglhJWQdD22ONmKoEwUL1T4pNNVv3eeXhMRNyUIe9 aD+9I+KIPs9yAKfIHUC2NABbe3OfjxcFUxOhcBVZZohhatfQv9+JGiivqMvHleT5 AXvCmVGTM4+U+gs= -----END CERTIFICATE----- username at hostname ~ $ echo quit | openssl s_client -connect www.weather.gov:443 | openssl x509 -text depth=2 /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root verify error:num=20:unable to get local issuer certificate verify return:0 DONE Certificate: Data: Version: 3 (0x2) Serial Number: 03:bf:3a:ef:2f:a2:7c:96:b8:ca:8f:b9:59:cd:33:2c:9d:50:11:38 Signature Algorithm: sha1WithRSAEncryption Issuer: C=NL, L=Amsterdam, O=Verizon Enterprise Solutions, OU=Cybertrust, CN=Verizon Akamai SureServer CA G14-SHA1 Validity Not Before: Jun 19 16:52:07 2015 GMT Not After : Jun 19 16:52:05 2016 GMT Subject: C=US, ST=MA, L=Cambridge, O=Akamai Technologies Inc., CN= a248.e.akamai.net Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:d9:a2:c4:90:e0:90:c6:41:34:9d:f3:d5:95:fa: da:c3:81:bb:e4:ee:09:11:e4:a5:45:6d:73:2a:19: f9:3a:20:9e:8d:14:4f:17:b8:5a:d3:82:3c:d0:d5: f3:a4:b0:3f:b7:3a:6c:b5:7a:3a:ea:d3:14:89:b2: ac:1c:b6:08:6d:5b:41:f2:84:88:a7:1f:3a:c4:a7: aa:f0:1a:25:cb:13:78:07:7b:fb:04:2f:5f:73:5e: ed:19:d2:54:ec:f7:9b:ec:e9:14:f3:ca:53:46:15: 54:88:e4:1f:bc:8f:18:c4:c5:35:c9:cc:b1:b6:7e: 8b:ef:21:75:ad:55:e9:52:08:8c:47:dc:48:a0:c7: 8f:b6:b9:87:c2:6c:45:3e:20:63:8f:51:62:e4:37: 9a:9b:8f:80:b9:ee:17:02:1d:39:16:c9:8a:6b:69: fc:eb:2a:d5:99:17:ad:6d:3f:db:29:13:c1:7d:4b: ab:39:56:8d:59:43:bb:7f:81:71:7e:28:8a:9a:88: 3b:08:ec:bc:f0:d8:5e:e8:4b:09:4d:27:66:07:b9: 20:de:2f:90:81:cc:de:a8:c8:bb:77:c6:26:c3:5e: c8:38:35:e0:a2:b0:a5:a9:14:08:19:d4:c8:5e:73: 21:0b:ad:c2:84:a4:57:c9:c6:59:00:24:1b:54:61: 4f:2b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.6334.1.50 CPS: https://secure.omniroot.com/repository Authority Information Access: OCSP - URI:http://vassg141.ocsp.omniroot.com CA Issuers - URI:https://cacert.a.omniroot.com/vassg141.crt CA Issuers - URI:https://cacert.a.omniroot.com/vassg141.der X509v3 Subject Alternative Name: DNS:a248.e.akamai.net, DNS:*.akamaihd.net, DNS:*. akamaihd-staging.net, DNS:*.akamaized.net, DNS:*.akamaized-staging.net X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Authority Key Identifier: keyid:DD:6C:80:7C:BA:B5:32:17:A5:84:41:40:F0:D2:04:66:13:2F:A9:90 X509v3 CRL Distribution Points: URI:http://vassg141.crl.omniroot.com/vassg141.crl X509v3 Subject Key Identifier: 03:B6:4A:9C:80:0C:60:18:88:0A:64:CD:AE:28:62:8A:7A:6C:C0:18 Signature Algorithm: sha1WithRSAEncryption 1c:64:ce:c3:76:4d:8c:29:fc:76:d1:3c:24:83:57:8e:3e:77: 21:0e:d6:83:f1:42:b9:2e:21:9d:14:96:c1:53:49:e8:16:20: 53:40:f2:e5:01:b7:df:01:07:77:49:6d:ea:53:10:c9:00:05: 0f:bb:c8:21:1d:38:9c:07:78:9c:0a:ad:e1:91:91:8b:95:f9: a8:e4:02:64:e2:15:0b:a9:7f:13:b8:03:ae:95:c5:45:47:33: fb:65:dd:30:bc:6c:cc:96:bb:c3:bc:52:77:74:03:86:ab:9d: dc:16:6f:04:49:b9:9f:8f:3c:b6:1e:5b:97:e9:f1:8e:e9:ba: 59:da:76:d4:7c:a6:7a:ce:2f:5e:d8:66:62:06:ff:c1:18:60: f8:ad:1e:31:d3:ba:ee:06:b2:75:1a:0f:05:6a:a9:61:7a:27: eb:a6:bd:f7:7c:05:c7:2c:bb:fd:ff:2d:1e:b4:b5:b4:a9:cf: 91:5b:0e:9e:e3:de:94:fa:95:b6:99:26:be:e5:7c:27:03:e9: b8:96:fa:17:6b:85:e9:1e:ed:d4:e3:41:9f:db:be:89:76:ed: e8:86:85:c1:86:1d:29:2b:17:d1:2c:0b:cf:07:cd:8a:52:89: 93:e1:72:79:c5:31:7d:f1:fa:34:ce:d9:37:94:50:0b:71:c7: 49:c8:6a:cb -----BEGIN CERTIFICATE----- MIIFvDCCBKSgAwIBAgIUA7867y+ifJa4yo+5Wc0zLJ1QETgwDQYJKoZIhvcNAQEF BQAwgY0xCzAJBgNVBAYTAk5MMRIwEAYDVQQHEwlBbXN0ZXJkYW0xJTAjBgNVBAoT HFZlcml6b24gRW50ZXJwcmlzZSBTb2x1dGlvbnMxEzARBgNVBAsTCkN5YmVydHJ1 c3QxLjAsBgNVBAMTJVZlcml6b24gQWthbWFpIFN1cmVTZXJ2ZXIgQ0EgRzE0LVNI QTEwHhcNMTUwNjE5MTY1MjA3WhcNMTYwNjE5MTY1MjA1WjBtMQswCQYDVQQGEwJV UzELMAkGA1UECBMCTUExEjAQBgNVBAcTCUNhbWJyaWRnZTEhMB8GA1UEChMYQWth bWFpIFRlY2hub2xvZ2llcyBJbmMuMRowGAYDVQQDExFhMjQ4LmUuYWthbWFpLm5l dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANmixJDgkMZBNJ3z1ZX6 2sOBu+TuCRHkpUVtcyoZ+Togno0UTxe4WtOCPNDV86SwP7c6bLV6OurTFImyrBy2 CG1bQfKEiKcfOsSnqvAaJcsTeAd7+wQvX3Ne7RnSVOz3m+zpFPPKU0YVVIjkH7yP GMTFNcnMsbZ+i+8hda1V6VIIjEfcSKDHj7a5h8JsRT4gY49RYuQ3mpuPgLnuFwId ORbJimtp/Osq1ZkXrW0/2ykTwX1LqzlWjVlDu3+BcX4oipqIOwjsvPDYXuhLCU0n Zge5IN4vkIHM3qjIu3fGJsNeyDg14KKwpakUCBnUyF5zIQutwoSkV8nGWQAkG1Rh TysCAwEAAaOCAjEwggItMAwGA1UdEwEB/wQCMAAwTAYDVR0gBEUwQzBBBgkrBgEE AbE+ATIwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly9zZWN1cmUub21uaXJvb3QuY29t L3JlcG9zaXRvcnkwga8GCCsGAQUFBwEBBIGiMIGfMC0GCCsGAQUFBzABhiFodHRw Oi8vdmFzc2cxNDEub2NzcC5vbW5pcm9vdC5jb20wNgYIKwYBBQUHMAKGKmh0dHBz Oi8vY2FjZXJ0LmEub21uaXJvb3QuY29tL3Zhc3NnMTQxLmNydDA2BggrBgEFBQcw AoYqaHR0cHM6Ly9jYWNlcnQuYS5vbW5pcm9vdC5jb20vdmFzc2cxNDEuZGVyMG4G A1UdEQRnMGWCEWEyNDguZS5ha2FtYWkubmV0gg4qLmFrYW1haWhkLm5ldIIWKi5h a2FtYWloZC1zdGFnaW5nLm5ldIIPKi5ha2FtYWl6ZWQubmV0ghcqLmFrYW1haXpl ZC1zdGFnaW5nLm5ldDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUH AwEGCCsGAQUFBwMCMB8GA1UdIwQYMBaAFN1sgHy6tTIXpYRBQPDSBGYTL6mQMD4G A1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly92YXNzZzE0MS5jcmwub21uaXJvb3QuY29t L3Zhc3NnMTQxLmNybDAdBgNVHQ4EFgQUA7ZKnIAMYBiICmTNrihiinpswBgwDQYJ KoZIhvcNAQEFBQADggEBABxkzsN2TYwp/HbRPCSDV44+dyEO1oPxQrkuIZ0UlsFT SegWIFNA8uUBt98BB3dJbepTEMkABQ+7yCEdOJwHeJwKreGRkYuV+ajkAmTiFQup fxO4A66VxUVHM/tl3TC8bMyWu8O8Und0A4arndwWbwRJuZ+PPLYeW5fp8Y7pulna dtR8pnrOL17YZmIG/8EYYPitHjHTuu4GsnUaDwVqqWF6J+umvfd8Bccsu/3/LR60 tbSpz5FbDp7j3pT6lbaZJr7lfCcD6biW+hdrheke7dTjQZ/bvol27eiGhcGGHSkr F9EsC88HzYpSiZPhcnnFMX3x+jTO2TeUUAtxx0nIass= -----END CERTIFICATE----- username at hostname ~ $ username at hostname ~ $ dig weather.gov @8.8.8.8 ; <<>> DiG 9.8.3-P1 <<>> weather.gov @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34623 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;weather.gov. IN A ;; ANSWER SECTION: weather.gov. 1 IN A 204.227.127.201 ;; Query time: 1317 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Sep 5 14:36:38 2015 ;; MSG SIZE rcvd: 45 username at hostname ~ $ dig www.weather.gov @8.8.8.8 ; <<>> DiG 9.8.3-P1 <<>> www.weather.gov @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55243 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.weather.gov. IN A ;; ANSWER SECTION: www.weather.gov. 32 IN CNAME www.weather.gov.edgesuite.net. www.weather.gov.edgesuite.net. 1193 IN CNAME a895.g.akamai.net. a895.g.akamai.net. 19 IN A 23.61.194.171 a895.g.akamai.net. 19 IN A 23.61.194.208 ;; Query time: 808 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Sep 5 14:36:45 2015 ;; MSG SIZE rcvd: 136 username at hostname ~ $ -Grant From jared at puck.Nether.net Sun Sep 6 00:15:38 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Sat, 5 Sep 2015 20:15:38 -0400 Subject: internet visualization Message-ID: <20150906001538.GB15900@puck.nether.net> OT: hit delete, or shameless plug disclaimer one of my colleagues just posted this visualiation of the internet from the as_path view of 2914. if you are on a mobile, you have to physically move your device around. http://as2914.net/ If you love it, send Job your accolades. If you hate it, see above disclaimer. If in a country with a holiday on monday, enjoy it safely. - 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 larrysheldon at cox.net Sun Sep 6 00:24:03 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 5 Sep 2015 19:24:03 -0500 Subject: internet visualization In-Reply-To: References: Message-ID: <55EB87A3.4080804@cox.net> On 9/5/2015 19:15, Jared Mauch wrote: > > OT: hit delete, or shameless plug disclaimer > > one of my colleagues just posted this visualiation > of the internet from the as_path view of 2914. if you are on > a mobile, you have to physically move your device around. > > http://as2914.net/ > > If you love it, send Job your accolades. If you hate it, > see above disclaimer. If in a country with a holiday on monday, > enjoy it safely. FarOUT! Outstanding. Please forward my accolades. (Is a "you are here" possible?) > > - Jared > -- sed quis custodiet ipsos custodes? (Juvenal) From aluisios at algartelecom.com.br Sun Sep 6 02:01:50 2015 From: aluisios at algartelecom.com.br (Aluisio da Silva) Date: Sun, 6 Sep 2015 02:01:50 +0000 Subject: Any Tool to replace Peakflow CP Message-ID: Hello, Does anyone here have a suggestion for a tool to replace Peakflow CP from Arbor Networks? Please if possible you would like hear some suggestions. Thanks. Alu?sio da Silva Coordena??o de Planejamento e Engenharia CTBC (34) 3256-2471 (34) 9976-0471 www.ctbc.com.br Esta mensagem,incluindo seus anexos,pode conter informa??o confidencial e/ou privilegiada,sendo de uso exclusivo dos destinat?rios. Seu conte?do n?o deve ser revelado.Caso voc? n?o seja o destinat?rio autorizado a receber esta mensagem,n?o poder? usar,copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nesse e-mail,por favor,comunique ao remetente e a elimine imediatamente.N?o nos responsabilizamos por opini?es e/ou declara??es veiculadas por e-mail n?o ficando obrigada ao cumprimento de qualquer condi??o constante deste instrumento. This message,including its attachments,contains and/or may contain confidential and privileged information.If you are not the person authorized to receive this message,you may not use,copy or disclose the information contained therein or take any action based on this information.If this message is received by mistake,please notify the sender by immediately replying to this email and deleting its files.We appreciate your cooperation. From nanogml at Mail.DDoS-Mitigator.net Sun Sep 6 03:22:19 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Sat, 5 Sep 2015 20:22:19 -0700 Subject: Any Tool to replace Peakflow CP In-Reply-To: References: Message-ID: <20150906032219.GA10719@Mail.DDoS-Mitigator.net> hi aluisio On 09/06/15 at 02:01am, Aluisio da Silva wrote: > Hello, > > Does anyone here have a suggestion for a tool to replace Peakflow CP from Arbor Networks? # for reference http://www.arbornetworks.com/products > Please if possible you would like hear some suggestions. - sflow based http://www.sflow.com/products/floodprotect.php http://www.inmon.com/technology/sflowTools.php http://www.andrisoft.com/software/wanguard http://www.github.com/FastVPSEestiOu/fastnetmon http://www.packetdam.com http://www.radware.com/Products/DefenseFlow - netflow based ?cisco url? http://nfdump.sourceforge.net http://nfsen.sourceforge.net http://sourceforge.net/projects/panoptis - jflow based ?juniper? magic pixie dust alvin # # DDoS-Mitigator.com # > Thanks. > > Alu?sio da Silva > Coordena??o de Planejamento e Engenharia > CTBC > (34) 3256-2471 > (34) 9976-0471 > www.ctbc.com.br From sander at steffann.nl Sun Sep 6 12:20:55 2015 From: sander at steffann.nl (Sander Steffann) Date: Sun, 6 Sep 2015 14:20:55 +0200 Subject: internet visualization In-Reply-To: <20150906001538.GB15900@puck.nether.net> References: <20150906001538.GB15900@puck.nether.net> Message-ID: > one of my colleagues just posted this visualiation > of the internet from the as_path view of 2914. if you are on > a mobile, you have to physically move your device around. > > http://as2914.net/ > > If you love it, send Job your accolades. If you hate it, > see above disclaimer. If in a country with a holiday on monday, > enjoy it safely. WOW, nice! Sander From pavel.odintsov at gmail.com Sun Sep 6 15:11:00 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Sun, 6 Sep 2015 18:11:00 +0300 Subject: Any Tool to replace Peakflow CP In-Reply-To: <20150906032219.GA10719@Mail.DDoS-Mitigator.net> References: <20150906032219.GA10719@Mail.DDoS-Mitigator.net> Message-ID: Hello! Thanks for recommendation, Alvin! As author of FastNetMon I will be very glad to hear some feedback about my tool and could help with configuration / development :) On Sun, Sep 6, 2015 at 6:22 AM, alvin nanog wrote: > > hi aluisio > > On 09/06/15 at 02:01am, Aluisio da Silva wrote: >> Hello, >> >> Does anyone here have a suggestion for a tool to replace Peakflow CP from Arbor Networks? > > # for reference > http://www.arbornetworks.com/products > >> Please if possible you would like hear some suggestions. > > - sflow based > http://www.sflow.com/products/floodprotect.php > http://www.inmon.com/technology/sflowTools.php > > http://www.andrisoft.com/software/wanguard > http://www.github.com/FastVPSEestiOu/fastnetmon > http://www.packetdam.com > http://www.radware.com/Products/DefenseFlow > > - netflow based > ?cisco url? > > http://nfdump.sourceforge.net > http://nfsen.sourceforge.net > http://sourceforge.net/projects/panoptis > > - jflow based > ?juniper? > > magic pixie dust > alvin > # > # DDoS-Mitigator.com > # > >> Thanks. >> >> Alu?sio da Silva >> Coordena??o de Planejamento e Engenharia >> CTBC >> (34) 3256-2471 >> (34) 9976-0471 >> www.ctbc.com.br -- Sincerely yours, Pavel Odintsov From nanogml at Mail.DDoS-Mitigator.net Sun Sep 6 16:32:13 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Sun, 6 Sep 2015 09:32:13 -0700 Subject: Any Tool to replace Peakflow CP In-Reply-To: References: <20150906032219.GA10719@Mail.DDoS-Mitigator.net> Message-ID: <20150906163213.GA16784@Mail.DDoS-Mitigator.net> hi pavel On 09/06/15 at 06:11pm, Pavel Odintsov wrote: > Thanks for recommendation, Alvin! just "on the list of flow stuff to look at" - opensource like fastnetmon is good for techies and solving problems - commercial products may be what large corp purchasing folks like i've looked into the flow based products and got more confused :-) > As author of FastNetMon I will be very glad to hear some feedback > about my tool and could help with configuration / development :) cool ... i went googlin around and found some additional info for the url list > On Sun, Sep 6, 2015 at 6:22 AM, alvin nanog > wrote: > > > > hi aluisio > > > > On 09/06/15 at 02:01am, Aluisio da Silva wrote: > >> Hello, > >> > >> Does anyone here have a suggestion for a tool to replace Peakflow CP from Arbor Networks? > > > > # for reference > > http://www.arbornetworks.com/products > > > >> Please if possible you would like hear some suggestions. > > > > - sflow based - sflow based # trademark owned by inmon http://www.sflow.org/products == list of vendors and collectors > > http://www.sflow.com/products/floodprotect.php their blog.sflow.com has lots of feedback and comparisons > > http://www.inmon.com/technology/sflowTools.php http://www.inmon.com/products > > > > http://www.andrisoft.com/software/wanguard > > http://www.github.com/FastVPSEestiOu/fastnetmon > > http://www.packetdam.com > > http://www.radware.com/Products/DefenseFlow > > - netflow based -- netflow prototcol superceded by IPFIX http://www.cisco.com/go/netflow http://www.openbsd.org/cgi-bin/man.cgi?query=pflow&sektion=4&manpath=OpenBSD+Current one day, i'll go poke around at linux-based tools like openbsd's pflow > > > > http://nfdump.sourceforge.net > > http://nfsen.sourceforge.net > > http://sourceforge.net/projects/panoptis - openflow based http://www.opennetworking.org/sdn-resources/openflow http://www.radware.com/Products/DefenseFlow > > - jflow based juniper.net/us/en/products-services/security/ - still can't find the jflow info :-( magic pixie dust alvin # # DDoS-Mitigator.com/Competitors/#Flow # From rdrake at direcpath.com Sun Sep 6 16:46:37 2015 From: rdrake at direcpath.com (Robert Drake) Date: Sun, 6 Sep 2015 12:46:37 -0400 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <55EA1BC6.4080302@satchell.net> References: <55E9F1E8.9030405@cox.net> <55EA1BC6.4080302@satchell.net> Message-ID: <55EC6DED.1060501@direcpath.com> On 9/4/2015 6:31 PM, Stephen Satchell wrote: > > I, for one, feel your pain in this matter. When I was a consultant in > The Bad Ol' Days, I had so many telephone numbers where I *could* be > that my .sig would be a run-on one as well. As a compromise, I had my > cell number and a hyperlink to a Web site page with the full monte. > > That was before I joined NANOG, so I never tested the tolerance of the > people here with that solution. > > When I was employed as a full-timer (including now) my "work" mail has > the same sort of crap. One option you might want to consider is to > use a personal e-mail account for places like NANOG with the > single-line disclaimer "Views expressed herein may not be my > employer's view" > Maybe people could adopt an unofficial-official end-of-signature flag. Then you could have procmail strip everything after the flag: -- This is my signature My phone number goes here I like dogs -- end of signature -- Everything below here and to the right of here was inserted by my mailserver, which is run by lawyers who don't understand you can't enforce contracts through emails to public mailing lists. Please delete if you're not the intended recipient. Of course, when you route around something like this it usually comes back 10 fold, but maybe if it became worthless they might do things the right way and put stuff like this in email headers. X-Optional-Flags: Delete-if-not-intended-recipient, might-contain-secret-company-information-we-didn't-bother-to-encrypt Then let the email clients try to work out what that means. From larrysheldon at cox.net Sun Sep 6 18:14:16 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sun, 6 Sep 2015 13:14:16 -0500 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: References: <55E9F1E8.9030405@cox.net> <55EA1BC6.4080302@satchell.net> Message-ID: <55EC8278.80002@cox.net> On 9/6/2015 11:46, Robert Drake wrote: > Maybe people could adopt an unofficial-official end-of-signature flag. > Then you could have procmail strip everything after the flag: > -- > This is my signature > My phone number goes here > I like dogs > -- end of signature -- > Everything below here and to the right of here was inserted by my > mailserver, which is run by lawyers who don't understand you can't > enforce contracts through emails to public mailing lists. Please delete > if you're not the intended recipient. > > > Of course, when you route around something like this it usually comes > back 10 fold, but maybe if it became worthless they might do things the > right way and put stuff like this in email headers. > > X-Optional-Flags: Delete-if-not-intended-recipient, > might-contain-secret-company-information-we-didn't-bother-to-encrypt > > Then let the email clients try to work out what that means. Please see https://en.wikipedia.org/wiki/Signature_block I thought that was in rfc 2822, but I can not find it. > -- sed quis custodiet ipsos custodes? (Juvenal) From surfer at mauigateway.com Sun Sep 6 19:18:37 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 6 Sep 2015 12:18:37 -0700 Subject: Extraneous "legal" babble--and my reaction to it. Message-ID: <20150906121837.99C9744E@m0005309.ppops.net> --- rdrake at direcpath.com wrote: From: Robert Drake Maybe people could adopt an unofficial-official end-of-signature flag. Then you could have procmail strip everything after the flag: ----------------------------------------- It could be much easier. Folks that care about the mailing list rules, want to be courteous to list folks and want to use their company email, rather than one that inserts no disclaimer, could put 15 lines of blank as part of their signature. This would force all the crap far enough down the page that it wouldn't be bothersome. scott From larrysheldon at cox.net Sun Sep 6 20:31:57 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sun, 6 Sep 2015 15:31:57 -0500 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: References: Message-ID: <55ECA2BD.8080005@cox.net> On 9/6/2015 14:18, Scott Weeks wrote: > > > --- rdrake at direcpath.com wrote: > From: Robert Drake > > Maybe people could adopt an unofficial-official > end-of-signature flag. Then you could have > procmail strip everything after the flag: > ----------------------------------------- > > > It could be much easier. Folks that care about the > mailing list rules, want to be courteous to list > folks and want to use their company email, rather > than one that inserts no disclaimer, could put 15 > lines of blank as part of their signature. This > would force all the crap far enough down the page > that it wouldn't be bothersome. Since nobody uses Telebit Trailblazers anymore--that is probably not a bad idea. -- sed quis custodiet ipsos custodes? (Juvenal) From rsk at gsp.org Sun Sep 6 20:39:17 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 6 Sep 2015 16:39:17 -0400 Subject: Software Defined Networking In-Reply-To: <93965.1441407576@turing-police.cc.vt.edu> References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <55E9D921.6090506@cox.net> <93965.1441407576@turing-police.cc.vt.edu> Message-ID: <20150906203917.GA1128@gsp.org> On Fri, Sep 04, 2015 at 06:59:36PM -0400, Valdis.Kletnieks at vt.edu wrote: > Does anybody have a citation that legal disclaimers attached to > publicly posted mail aren't null and void? Disclaimers are invalid on their face because they're an attempt to unilaterally enforce contractual terms without a meeting of the minds -- something required for a valid contract. They're "adhesions", i.e., they're provisions so one-sided that it's immediately obvious that they've been dictated by one side and not agreed to by both as the result of some kind of bargaining or negotiation. The two best references I'm aware of in this regard are: Stupid E-mail Disclaimers and the Stupid Users that Use Them http://attrition.org/security/rants/z/disclaimers.html Quoting in part: "We can't help it--this really makes us nuts. When will these people learn? You transmitted your crappy mind-numbing message to us, in plain text, over the public internet. It's ours (and whoever is sniffing our mail) to do with as we please and you can't have it back, so piss off. We won't delete it, we will publish it, we will forward it, and there is nothing you can do about it. Go ahead, take us to court, but try to find a shred of legal precedent first, ok?" and: Don't Include Bogus Legalistic Boilerplate. http://www.river.com/users/share/etiquette/#legalistic Quoting in part: "First, such boilerplate contains useless adhesions, meaning the explicit and implied threats they make are particularly annoying. If you send something via email, the recipients (are you sure you aren't sending to a mailing list?) and anyone else who sees your clear text postcard in transit can undetectably and with full deniability do whatever they want with the information written on it in plain view. Even casual users of email know email is not a secure communications medium. Thus the threats in typical bogus legalistic boilerplate are naught but an attempt at highly improper intimidation. Demands made in this manner will be regarded as evidence of a hostile attitude on your part by a significant portion of recipients. The threats will negatively affect how your recipients perceive the other ideas in your message." ---rsk From johnl at iecc.com Sun Sep 6 22:41:11 2015 From: johnl at iecc.com (John Levine) Date: 6 Sep 2015 22:41:11 -0000 Subject: Software Defined Networking In-Reply-To: <20150906203917.GA1128@gsp.org> Message-ID: <20150906224111.39194.qmail@ary.lan> I've taken to sending such mail back with a note "message deleted at your request". The more urgent the question, the better. R's, John From surfer at mauigateway.com Sun Sep 6 22:49:42 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 6 Sep 2015 15:49:42 -0700 Subject: Extraneous "legal" babble--and my reaction to it. Message-ID: <20150906154942.99C96365@m0005309.ppops.net> --- larrysheldon at cox.net wrote: From: Larry Sheldon On 9/6/2015 14:18, Scott Weeks wrote: > --- rdrake at direcpath.com wrote: > From: Robert Drake > > Maybe people could adopt an unofficial-official > end-of-signature flag. Then you could have > procmail strip everything after the flag: > ----------------------------------------- > > It could be much easier. Folks that care about the > mailing list rules, want to be courteous to list > folks and want to use their company email, rather > than one that inserts no disclaimer, could put 15 > lines of blank as part of their signature. This > would force all the crap far enough down the page > that it wouldn't be bothersome. Since nobody uses Telebit Trailblazers anymore--that is probably not a bad idea. ------------------------------------------- https://en.wikipedia.org/wiki/The_Times_They_Are_a-Changin'_%28song%29 :-) scott From aluisios at algartelecom.com.br Sun Sep 6 23:42:41 2015 From: aluisios at algartelecom.com.br (Aluisio da Silva) Date: Sun, 6 Sep 2015 23:42:41 +0000 Subject: RES: Any Tool to replace Peakflow CP In-Reply-To: <20150906032219.GA10719@Mail.DDoS-Mitigator.net> References: <20150906032219.GA10719@Mail.DDoS-Mitigator.net> Message-ID: Thank you all for the comments. Does anyone know about FlowTraq and DeepField tools? Thanks. Alu?sio da Silva Coordena??o de Planejamento e Engenharia CTBC (34) 3256-2471 (34) 9976-0471 www.ctbc.com.br -----Mensagem original----- De: alvin nanog [mailto:nanogml at Mail.DDoS-Mitigator.net] Enviada em: domingo, 6 de setembro de 2015 00:22 Para: Aluisio da Silva Cc: nanog at nanog.org; alvin nanog Assunto: Re: Any Tool to replace Peakflow CP hi aluisio On 09/06/15 at 02:01am, Aluisio da Silva wrote: > Hello, > > Does anyone here have a suggestion for a tool to replace Peakflow CP from Arbor Networks? # for reference http://www.arbornetworks.com/products > Please if possible you would like hear some suggestions. - sflow based http://www.sflow.com/products/floodprotect.php http://www.inmon.com/technology/sflowTools.php http://www.andrisoft.com/software/wanguard http://www.github.com/FastVPSEestiOu/fastnetmon http://www.packetdam.com http://www.radware.com/Products/DefenseFlow - netflow based ?cisco url? http://nfdump.sourceforge.net http://nfsen.sourceforge.net http://sourceforge.net/projects/panoptis - jflow based ?juniper? magic pixie dust alvin # # DDoS-Mitigator.com # > Thanks. > > Alu?sio da Silva > Coordena??o de Planejamento e Engenharia CTBC > (34) 3256-2471 > (34) 9976-0471 > www.ctbc.com.br Esta mensagem,incluindo seus anexos,pode conter informa??o confidencial e/ou privilegiada,sendo de uso exclusivo dos destinat?rios. Seu conte?do n?o deve ser revelado.Caso voc? n?o seja o destinat?rio autorizado a receber esta mensagem,n?o poder? usar,copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nesse e-mail,por favor,comunique ao remetente e a elimine imediatamente.N?o nos responsabilizamos por opini?es e/ou declara??es veiculadas por e-mail n?o ficando obrigada ao cumprimento de qualquer condi??o constante deste instrumento. This message,including its attachments,contains and/or may contain confidential and privileged information.If you are not the person authorized to receive this message,you may not use,copy or disclose the information contained therein or take any action based on this information.If this message is received by mistake,please notify the sender by immediately replying to this email and deleting its files.We appreciate your cooperation. From hhoffman at ip-solutions.net Sun Sep 6 23:53:53 2015 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Sun, 6 Sep 2015 19:53:53 -0400 Subject: Any Tool to replace Peakflow CP In-Reply-To: References: Message-ID: <55ECD211.20100@ip-solutions.net> Hi Aluisio, Have you had a look at Lancope's Stealthwatch? If you go that route give a shout as we've written a bunch of scripts to do things like scan detection and new service alerting. Cheers, Harry On 9/5/15 10:01 PM, Aluisio da Silva wrote: > Hello, > > Does anyone here have a suggestion for a tool to replace Peakflow CP from Arbor Networks? > > Please if possible you would like hear some suggestions. > > Thanks. > > Alu?sio da Silva > Coordena??o de Planejamento e Engenharia > CTBC > (34) 3256-2471 > (34) 9976-0471 > www.ctbc.com.br > > > > > Esta mensagem,incluindo seus anexos,pode conter informa??o confidencial e/ou privilegiada,sendo de uso exclusivo dos destinat?rios. Seu conte?do n?o deve ser revelado.Caso voc? n?o seja o destinat?rio autorizado a receber esta mensagem,n?o poder? usar,copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nesse e-mail,por favor,comunique ao remetente e a elimine imediatamente.N?o nos responsabilizamos por opini?es e/ou declara??es veiculadas por e-mail n?o ficando obrigada ao cumprimento de qualquer condi??o constante deste instrumento. > > This message,including its attachments,contains and/or may contain confidential and privileged information.If you are not the person authorized to receive this message,you may not use,copy or disclose the information contained therein or take any action based on this information.If this message is received by mistake,please notify the sender by immediately replying to this email and deleting its files.We appreciate your cooperation. From connorwilkins at ruggedinbox.com Sun Sep 6 21:14:02 2015 From: connorwilkins at ruggedinbox.com (Connor Wilkins) Date: Sun, 06 Sep 2015 21:14:02 +0000 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <20150906121837.99C9744E@m0005309.ppops.net> References: <20150906121837.99C9744E@m0005309.ppops.net> Message-ID: On 2015-09-06 19:18, Scott Weeks wrote: > It could be much easier. Folks that care about the > mailing list rules, want to be courteous to list > folks and want to use their company email, rather > than one that inserts no disclaimer, could put 15 > lines of blank as part of their signature. This > would force all the crap far enough down the page > that it wouldn't be bothersome. > > scott Everyone: Honestly.. the best method is to not let it bug you anymore. It's only a seething issue to you because you let it be. You're suggesting that one use 15 blank lines just so that you don't have to see any of these self-inflicted transgressions. It would be much simpler and less taxing on all involved to simply not let it bother you anymore. "Impossible!" you may cry.. but I don't believe so. I used to be the same. It's easily beatable. You could send twenty paragraphs of so-called 'legal text' suffixed to your email and I wouldn't so much as bat an eye. It may take some personal effort but you need to learn to 'let it go'. This is a non-issue in the scope of things and you've made a mountain out of this grain of sand. Brush it aside and move on. It isn't worth your time. From egon at egon.cc Mon Sep 7 20:23:29 2015 From: egon at egon.cc (James Downs) Date: Mon, 7 Sep 2015 13:23:29 -0700 Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> Message-ID: <7A74991F-1204-4CE7-9AB0-66B9F2A281AD@egon.cc> > On Sep 4, 2015, at 07:40, Rod Beck wrote: > > Can anyone provide references on this top so I can educate myself? What do you mean when you say ?software defined networking?? Do you have a particular problem or use case you are approaching? Cheers, -j From nick at foobar.org Mon Sep 7 21:14:38 2015 From: nick at foobar.org (Nick Hilliard) Date: Mon, 7 Sep 2015 22:14:38 +0100 Subject: Software Defined Networking In-Reply-To: <7A74991F-1204-4CE7-9AB0-66B9F2A281AD@egon.cc> References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <7A74991F-1204-4CE7-9AB0-66B9F2A281AD@egon.cc> Message-ID: <55EDFE3E.6050509@foobar.org> On 07/09/2015 21:23, James Downs wrote: > What do you mean when you say ?software defined networking?? Do you have > a particular problem or use case you are approaching? since when was that a requirement for SDN? Nick From nanog at ics-il.net Mon Sep 7 21:17:01 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 7 Sep 2015 16:17:01 -0500 (CDT) Subject: Software Defined Networking In-Reply-To: <55EDFE3E.6050509@foobar.org> Message-ID: <1600227906.435.1441660672170.JavaMail.mhammett@ThunderFuck> I thought it was purely for vendors to sell you more crap? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Nick Hilliard" To: nanog at nanog.org Sent: Monday, September 7, 2015 4:14:38 PM Subject: Re: Software Defined Networking On 07/09/2015 21:23, James Downs wrote: > What do you mean when you say ?software defined networking?? Do you have > a particular problem or use case you are approaching? since when was that a requirement for SDN? Nick From rsk at gsp.org Tue Sep 8 08:31:33 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 8 Sep 2015 04:31:33 -0400 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: References: <20150906121837.99C9744E@m0005309.ppops.net> Message-ID: <20150908083133.GA28686@gsp.org> On Sun, Sep 06, 2015 at 09:14:02PM +0000, Connor Wilkins wrote: > Honestly.. the best method is to not let it bug you anymore. It's > only a seething issue to you because you let it be. Curiously enough, the same thing was said about spam 30-ish years ago. The "ignore it and maybe it will go away" approach did not yield satisfactory results. These "disclaimers" are stupid and abusive. They have no place in *any* email traffic, and most certainly not in a professional forum. And it is unreasonable to expect the recipients of the demands and threats they embody to silently tolerate them ad infinitum. ---rsk From larrysheldon at cox.net Tue Sep 8 08:56:30 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 8 Sep 2015 03:56:30 -0500 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: References: <20150906121837.99C9744E@m0005309.ppops.net> Message-ID: <55EEA2BE.5090604@cox.net> On 9/8/2015 03:31, Rich Kulawiec wrote: > On Sun, Sep 06, 2015 at 09:14:02PM +0000, Connor Wilkins wrote: >> Honestly.. the best method is to not let it bug you anymore. It's >> only a seething issue to you because you let it be. > > Curiously enough, the same thing was said about spam 30-ish years ago. > The "ignore it and maybe it will go away" approach did not yield > satisfactory results. > > These "disclaimers" are stupid and abusive. They have no place in > *any* email traffic, and most certainly not in a professional forum. > And it is unreasonable to expect the recipients of the demands and > threats they embody to silently tolerate them ad infinitum. Exactly so. JHD -- sed quis custodiet ipsos custodes? (Juvenal) From maxtul at netassist.ua Tue Sep 8 14:37:09 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 08 Sep 2015 17:37:09 +0300 Subject: internet visualization In-Reply-To: <20150906001538.GB15900@puck.nether.net> References: <20150906001538.GB15900@puck.nether.net> Message-ID: <55EEF295.8010704@netassist.ua> Really nice! How can I do zoom in/zoom out? On 06.09.15 03:15, Jared Mauch wrote: > > OT: hit delete, or shameless plug disclaimer > > one of my colleagues just posted this visualiation > of the internet from the as_path view of 2914. if you are on > a mobile, you have to physically move your device around. > > http://as2914.net/ > > If you love it, send Job your accolades. If you hate it, > see above disclaimer. If in a country with a holiday on monday, > enjoy it safely. > > - Jared > From savage at savage.za.org Tue Sep 8 14:50:22 2015 From: savage at savage.za.org (Chris Knipe) Date: Tue, 8 Sep 2015 16:50:22 +0200 Subject: internet visualization In-Reply-To: <55EEF295.8010704@netassist.ua> References: <20150906001538.GB15900@puck.nether.net> <55EEF295.8010704@netassist.ua> Message-ID: Indeed! One of the nicest visualizations I've seen to date. Loving it! On Tue, Sep 8, 2015 at 4:37 PM, Max Tulyev wrote: > Really nice! > > How can I do zoom in/zoom out? > > On 06.09.15 03:15, Jared Mauch wrote: > > > > OT: hit delete, or shameless plug disclaimer > > > > one of my colleagues just posted this visualiation > > of the internet from the as_path view of 2914. if you are on > > a mobile, you have to physically move your device around. > > > > http://as2914.net/ > > > > If you love it, send Job your accolades. If you hate it, > > see above disclaimer. If in a country with a holiday on monday, > > enjoy it safely. > > > > - Jared > > > > -- Regards, Chris Knipe From jmoore at atcnetworks.net Tue Sep 8 19:04:06 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Tue, 8 Sep 2015 19:04:06 +0000 Subject: IPv6 Subscriber Access Deployments Message-ID: I'm reading that the recommended method for assigning IPv6 addresses to end-users is to do this via a dedicated VLAN and /64. Some broadband access methods utilize a shared VLAN model with additional security mechanisms in place such as DHCP snooping, source-verify etc. Why wouldn't it be ideal to share the same /64 amongst all subscribers for simplicity? Joshua Moore Network Engineer ATC Broadband 912.632.3161 - O | 912.218.3720 - M From Valdis.Kletnieks at vt.edu Tue Sep 8 19:08:26 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 08 Sep 2015 15:08:26 -0400 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: Message-ID: <23313.1441739306@turing-police.cc.vt.edu> On Tue, 08 Sep 2015 19:04:06 -0000, Josh Moore said: > I'm reading that the recommended method for assigning IPv6 addresses to end-users is to do this via a dedicated VLAN and /64. Important question - are you talking about the IPv6 address supplied to the CPE router itself, or a /48 or /56 delegated to the CPE router to allocate to subnets and devices behind it? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jmoore at atcnetworks.net Tue Sep 8 19:12:55 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Tue, 8 Sep 2015 19:12:55 +0000 Subject: IPv6 Subscriber Access Deployments In-Reply-To: <23313.1441739306@turing-police.cc.vt.edu> References: <23313.1441739306@turing-police.cc.vt.edu> Message-ID: We are talking a purely bridged environment. However, I have been wondering how in the world end-to-end IPv6 connectivity is supposed to work if a customer hooks up their own router. That is one of the points of IPv6... Joshua Moore Network Engineer ATC Broadband 912.632.3161 - O | 912.218.3720 - M -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, September 08, 2015 3:08 PM To: Josh Moore Cc: nanog at nanog.org Subject: Re: IPv6 Subscriber Access Deployments On Tue, 08 Sep 2015 19:04:06 -0000, Josh Moore said: > I'm reading that the recommended method for assigning IPv6 addresses to end-users is to do this via a dedicated VLAN and /64. Important question - are you talking about the IPv6 address supplied to the CPE router itself, or a /48 or /56 delegated to the CPE router to allocate to subnets and devices behind it? From owen at delong.com Tue Sep 8 19:31:22 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Sep 2015 12:31:22 -0700 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: <23313.1441739306@turing-police.cc.vt.edu> Message-ID: Short answer to that is ?DHCPv6-PD? Longer answer: Customer?s router should get an address on the external interface through one of SLAAC, DHCP-PD, Static Assignment, depending on how the ISP prefers to do this. If the ISPs equipment supports IPv6 on shared VLANs with DHCP snooping and other security, you can implement it with a single /64 giving each router a unique address within that segment, but it?s not really ideal. This was mainly done in IPv4 to conserve addresses. Separate point to point VLANs are a cleaner solution and since there are enough addresses in IPv6 to do this, that is how most providers implement. I prefer using /64s (or at least assigning /64s) to these VLANs, but there are those who argue for /127, some equipment is broken and requires a /126, and yet others argue for other nonsensical prefixes. Once the router has an external address communicating point to point with the ISP router, it should then send an DHCPv6-PD request asking for a prefix that it can manage. The ISPs DHCP server should then send back a /48 (or if you want to be silly, a /56 or a /60, and if you want to be insane, a /64). The reality is that if you send a smaller prefix back, you risk having difficulty with your future ARIN applications as your Provider Allocation Unit is based on the smallest prefix you delegate to end-users. So if you, for example, assign /48 to business customers and /60 to residential customers, you?re going to have to justify why each of your business customers needed 4096 /60s when you claim that you need more IPv6 space. OTOH, if you simply issue /48s to everyone, you can just go back and say ?Each end site got a /48 and there are N end-sites? and you?re good, no questions asked about the size of any of those end-sites. Owen > On Sep 8, 2015, at 12:12 , Josh Moore wrote: > > We are talking a purely bridged environment. However, I have been wondering how in the world end-to-end IPv6 connectivity is supposed to work if a customer hooks up their own router. That is one of the points of IPv6... > > > > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 - O | 912.218.3720 - M > > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Tuesday, September 08, 2015 3:08 PM > To: Josh Moore > Cc: nanog at nanog.org > Subject: Re: IPv6 Subscriber Access Deployments > > On Tue, 08 Sep 2015 19:04:06 -0000, Josh Moore said: >> I'm reading that the recommended method for assigning IPv6 addresses to end-users is to do this via a dedicated VLAN and /64. > > Important question - are you talking about the IPv6 address supplied to the CPE router itself, or a /48 or /56 delegated to the CPE router to allocate to subnets and devices behind it? From jmoore at atcnetworks.net Tue Sep 8 19:40:44 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Tue, 8 Sep 2015 19:40:44 +0000 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: <23313.1441739306@turing-police.cc.vt.edu> Message-ID: The question becomes manageability. Unique VLAN per customer is not always scalable. For example, only ~4000 VLAN tags. What happens when you have more than that many customers? Also, provisioning. Who is going to provision thousands of unique prefixes and VLANs, trunk them through relevant equipment and ensure they are secured as well? We are talking very, very, small customers here. SOHO to say the most. /64 should be more than sufficient for their CPE router. Joshua Moore Network Engineer ATC Broadband 912.632.3161 - O | 912.218.3720 - M -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, September 08, 2015 3:31 PM To: Josh Moore Cc: Valdis.Kletnieks at vt.edu; nanog at nanog.org Subject: Re: IPv6 Subscriber Access Deployments Short answer to that is ?DHCPv6-PD? Longer answer: Customer?s router should get an address on the external interface through one of SLAAC, DHCP-PD, Static Assignment, depending on how the ISP prefers to do this. If the ISPs equipment supports IPv6 on shared VLANs with DHCP snooping and other security, you can implement it with a single /64 giving each router a unique address within that segment, but it?s not really ideal. This was mainly done in IPv4 to conserve addresses. Separate point to point VLANs are a cleaner solution and since there are enough addresses in IPv6 to do this, that is how most providers implement. I prefer using /64s (or at least assigning /64s) to these VLANs, but there are those who argue for /127, some equipment is broken and requires a /126, and yet others argue for other nonsensical prefixes. Once the router has an external address communicating point to point with the ISP router, it should then send an DHCPv6-PD request asking for a prefix that it can manage. The ISPs DHCP server should then send back a /48 (or if you want to be silly, a /56 or a /60, and if you want to be insane, a /64). The reality is that if you send a smaller prefix back, you risk having difficulty with your future ARIN applications as your Provider Allocation Unit is based on the smallest prefix you delegate to end-users. So if you, for example, assign /48 to business customers and /60 to residential customers, you?re going to have to justify why each of your business customers needed 4096 /60s when you claim that you need more IPv6 space. OTOH, if you simply issue /48s to everyone, you can just go back and say ?Each end site got a /48 and there are N end-sites? and you?re good, no questions asked about the size of any of those end-sites. Owen > On Sep 8, 2015, at 12:12 , Josh Moore wrote: > > We are talking a purely bridged environment. However, I have been wondering how in the world end-to-end IPv6 connectivity is supposed to work if a customer hooks up their own router. That is one of the points of IPv6... > > > > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 - O | 912.218.3720 - M > > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Tuesday, September 08, 2015 3:08 PM > To: Josh Moore > Cc: nanog at nanog.org > Subject: Re: IPv6 Subscriber Access Deployments > > On Tue, 08 Sep 2015 19:04:06 -0000, Josh Moore said: >> I'm reading that the recommended method for assigning IPv6 addresses to end-users is to do this via a dedicated VLAN and /64. > > Important question - are you talking about the IPv6 address supplied to the CPE router itself, or a /48 or /56 delegated to the CPE router to allocate to subnets and devices behind it? From clinton at scripty.com Tue Sep 8 19:46:16 2015 From: clinton at scripty.com (Clinton Work) Date: Tue, 08 Sep 2015 13:46:16 -0600 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: <23313.1441739306@turing-police.cc.vt.edu> Message-ID: <1441741576.143219.378115649.3634EE3A@webmail.messagingengine.com> If you use separate VLANs for each customer then the CPE router doesn't even require an external IPV6 address for DHCPv6-PD. IPV6 link-local addresses can be used between your BRAS and customer CPE router. Some CPEs can even allocate a WAN/mgmt IPV6 address out of the delegated subnet via DHCPv6-PD. On Tue, Sep 8, 2015, at 01:31 PM, Owen DeLong wrote: > Short answer to that is ?DHCPv6-PD? > > Once the router has an external address communicating point to point with > the ISP router, it should then send an DHCPv6-PD request asking for a > prefix that it can manage. The ISPs DHCP server should then send back a > /48 (or if you want to be silly, a /56 or a /60, and if you want to be > insane, a /64). From Valdis.Kletnieks at vt.edu Tue Sep 8 19:54:50 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 08 Sep 2015 15:54:50 -0400 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: <23313.1441739306@turing-police.cc.vt.edu> Message-ID: <26760.1441742090@turing-police.cc.vt.edu> On Tue, 08 Sep 2015 19:40:44 -0000, Josh Moore said: > The question becomes manageability. Unique VLAN per customer is not always > scalable. For example, only ~4000 VLAN tags. What happens when you have more > than that many customers? If you're hanging 4K customers off the same switch, you probably have bigger issues than running out of VLAN tags... > We are talking very, very, small customers here. SOHO to say the most. > /64 should be more than sufficient for their CPE router. A Linksys WNDR3800 running CeroWRT (and probably OpenWRT by now) will prefer to create multiple /64's - one for the 4 wired ports, one for private access on the 2.4G radio, one for guest access on the 2.4, and another private/guest pair on the 5G radio. So there is CPE gear out there now that can blow through 5 /64s by default, and more if you enable VLANs. A /56 allocated via DHCPv6-PD would be a *minimum*. And prefixes are cheap, so you may as well hand them a /48, just in case they have a second WNDR3800 at the other end of the building for coverage - because that one will then ask the upstream one for a -PD allocation. So if you give the CPE a /48, it can keep a /56 for itself, and hand the downstream a /56, and they can each allocate /64s as needed. And remember - prefixes are cheap and plentiful, so don't bother with /52 or /60, just split on 8-bit boundaries to make life easier for yourself... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jmoore at atcnetworks.net Tue Sep 8 20:03:57 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Tue, 8 Sep 2015 20:03:57 +0000 Subject: IPv6 Subscriber Access Deployments In-Reply-To: <26760.1441742090@turing-police.cc.vt.edu> References: <23313.1441739306@turing-police.cc.vt.edu> <26760.1441742090@turing-police.cc.vt.edu> Message-ID: That makes sense now understanding how CPE equipment has evolved into segmenting layer 2 services like that. /48 it is. Most GPON networks are composed of large layer 2 rings. No way to break that up without adding additional equipment and that can get costly. With IPv4 we got around the need to configure discrete VLANs/subnets by putting all customers in the same VLAN and turning on the DHCP snooping/source-guard features. My remaining question is why isn't this desired with IPv6? What security concerns are there with turning up SLAAC / DHCPv6 within the same /64 for everyone that are different from IPv4? Joshua Moore Network Engineer ATC Broadband 912.632.3161 - O | 912.218.3720 - M -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, September 08, 2015 3:55 PM To: Josh Moore Cc: Owen DeLong; nanog at nanog.org Subject: Re: IPv6 Subscriber Access Deployments On Tue, 08 Sep 2015 19:40:44 -0000, Josh Moore said: > The question becomes manageability. Unique VLAN per customer is not > always scalable. For example, only ~4000 VLAN tags. What happens when > you have more than that many customers? If you're hanging 4K customers off the same switch, you probably have bigger issues than running out of VLAN tags... > We are talking very, very, small customers here. SOHO to say the most. > /64 should be more than sufficient for their CPE router. A Linksys WNDR3800 running CeroWRT (and probably OpenWRT by now) will prefer to create multiple /64's - one for the 4 wired ports, one for private access on the 2.4G radio, one for guest access on the 2.4, and another private/guest pair on the 5G radio. So there is CPE gear out there now that can blow through 5 /64s by default, and more if you enable VLANs. A /56 allocated via DHCPv6-PD would be a *minimum*. And prefixes are cheap, so you may as well hand them a /48, just in case they have a second WNDR3800 at the other end of the building for coverage - because that one will then ask the upstream one for a -PD allocation. So if you give the CPE a /48, it can keep a /56 for itself, and hand the downstream a /56, and they can each allocate /64s as needed. And remember - prefixes are cheap and plentiful, so don't bother with /52 or /60, just split on 8-bit boundaries to make life easier for yourself... From matthew at matthew.at Tue Sep 8 20:13:55 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 8 Sep 2015 13:13:55 -0700 Subject: IPv6 Subscriber Access Deployments In-Reply-To: <26760.1441742090@turing-police.cc.vt.edu> References: <23313.1441739306@turing-police.cc.vt.edu> <26760.1441742090@turing-police.cc.vt.edu> Message-ID: <660E364A-CB4F-40B9-8832-AD1F3CBAF03C@matthew.at> If you can't hang 4k customers off a switch, why does IPv6 need so many bits for the host portion? Matthew Kaufman (Sent from my iPhone) > On Sep 8, 2015, at 12:54 PM, Valdis.Kletnieks at vt.edu wrote: > > On Tue, 08 Sep 2015 19:40:44 -0000, Josh Moore said: > >> The question becomes manageability. Unique VLAN per customer is not always >> scalable. For example, only ~4000 VLAN tags. What happens when you have more >> than that many customers? > > If you're hanging 4K customers off the same switch, you probably have bigger > issues than running out of VLAN tags... > >> We are talking very, very, small customers here. SOHO to say the most. >> /64 should be more than sufficient for their CPE router. > > A Linksys WNDR3800 running CeroWRT (and probably OpenWRT by now) will prefer to > create multiple /64's - one for the 4 wired ports, one for private access on the > 2.4G radio, one for guest access on the 2.4, and another private/guest pair > on the 5G radio. So there is CPE gear out there now that can blow through 5 /64s > by default, and more if you enable VLANs. > > A /56 allocated via DHCPv6-PD would be a *minimum*. And prefixes are cheap, > so you may as well hand them a /48, just in case they have a second WNDR3800 > at the other end of the building for coverage - because that one will then ask > the upstream one for a -PD allocation. So if you give the CPE a /48, it can > keep a /56 for itself, and hand the downstream a /56, and they can each > allocate /64s as needed. > > And remember - prefixes are cheap and plentiful, so don't bother with /52 > or /60, just split on 8-bit boundaries to make life easier for yourself... > From baldur.norddahl at gmail.com Tue Sep 8 20:17:01 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 8 Sep 2015 22:17:01 +0200 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: <23313.1441739306@turing-police.cc.vt.edu> Message-ID: On 8 September 2015 at 21:40, Josh Moore wrote: > The question becomes manageability. Unique VLAN per customer is not always > scalable. For example, only ~4000 VLAN tags. What happens when you have > more than that many customers? Also, provisioning. Who is going to > provision thousands of unique prefixes and VLANs, trunk them through > relevant equipment and ensure they are secured as well? > VLAN tags can be stacked (QinQ). This allows 4096*4096 VLANs. Also it allows you to group them and use wildcard VLAN forwarding (ie. outer vlan 100 innervlan ANY). Or you can stuff the whole thing into a MPLS L2VPN tunnel. We are forced to use this scheme by the incumbent telco. It is simply the way they hand off customer links to us. One end user per VLAN, each "areacode" has an assigned outer tag and users within an area are assigned inner tags sequentially starting with vlan 2. Ie. user #1 is 100.2, user #2 is 100.3, user #3 living in a different area is 101.2. However we still want to preserve IPv4, so users will be sharing the same IPv4 subnet even though they are on different VLANs. This is done by vlan ranges on a layer 3 interface. As a consequence we are more or less forced to do the same for the IPv6 setup. Every user that shares a IPv4 subnet will also share a IPv6 /64 prefix on their uplinks. We use DHCPv6-PD to allocate a /48 prefix to each user, so the shared prefix is only used by the CPE on the uplink. Users will normally only see the shared prefix if they do a traceroute. Their computer will have an address from the /48 prefix. Regards, Baldur From Valdis.Kletnieks at vt.edu Tue Sep 8 20:41:23 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 08 Sep 2015 16:41:23 -0400 Subject: IPv6 Subscriber Access Deployments In-Reply-To: <660E364A-CB4F-40B9-8832-AD1F3CBAF03C@matthew.at> References: <23313.1441739306@turing-police.cc.vt.edu> <26760.1441742090@turing-police.cc.vt.edu> <660E364A-CB4F-40B9-8832-AD1F3CBAF03C@matthew.at> Message-ID: <34692.1441744883@turing-police.cc.vt.edu> On Tue, 08 Sep 2015 13:13:55 -0700, Matthew Kaufman said: > If you can't hang 4k customers off a switch, why does IPv6 need so many bits for the host portion? Oh, it doesn't *need* that many. You can go ahead and run your IPv6 subnets with a /96 or /112. Just remember that will piss off any hardware that tries to do SLAAC. or a few other things.... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jeffshultz at wvi.com Tue Sep 8 23:16:52 2015 From: jeffshultz at wvi.com (Jeff Shultz) Date: Tue, 8 Sep 2015 16:16:52 -0700 Subject: internet visualization In-Reply-To: <20150906001538.GB15900@puck.nether.net> References: <20150906001538.GB15900@puck.nether.net> Message-ID: Weirdest thing I've found yet - AS7224, Amazon AS - Amazon, has 1 indegree - AS724 - DNIC-ASBLK-00721-00726 - DoD Network Information Center, US. What the heck is an Amazon (assuming it's associated with Amazon.com) AS doing hanging off the end of a DOD network? Assuming I'm reading it correctly, that is. On Sat, Sep 5, 2015 at 5:15 PM, Jared Mauch wrote: > > OT: hit delete, or shameless plug disclaimer > > one of my colleagues just posted this visualiation > of the internet from the as_path view of 2914. if you are on > a mobile, you have to physically move your device around. > > http://as2914.net/ > > If you love it, send Job your accolades. If you hate it, > see above disclaimer. If in a country with a holiday on monday, > enjoy it safely. > > - 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 chris at ipstuff.ca Tue Sep 8 23:17:47 2015 From: chris at ipstuff.ca (Chris Murray) Date: Tue, 8 Sep 2015 16:17:47 -0700 Subject: Any Tool to replace Peakflow CP In-Reply-To: <55ECD211.20100@ip-solutions.net> References: <55ECD211.20100@ip-solutions.net> Message-ID: Very Happy with Kentik Detect, highly recommend it. www.kentik.com Cheers, Chris On Sun, Sep 6, 2015 at 4:53 PM, Harry Hoffman wrote: > Hi Aluisio, > > Have you had a look at Lancope's Stealthwatch? > > If you go that route give a shout as we've written a bunch of scripts to > do things like scan detection and new service alerting. > > Cheers, > Harry > > > On 9/5/15 10:01 PM, Aluisio da Silva wrote: >> Hello, >> >> Does anyone here have a suggestion for a tool to replace Peakflow CP from Arbor Networks? >> >> Please if possible you would like hear some suggestions. >> >> Thanks. >> >> Alu?sio da Silva >> Coordena??o de Planejamento e Engenharia >> CTBC >> (34) 3256-2471 >> (34) 9976-0471 >> www.ctbc.com.br >> >> >> >> >> Esta mensagem,incluindo seus anexos,pode conter informa??o confidencial e/ou privilegiada,sendo de uso exclusivo dos destinat?rios. Seu conte?do n?o deve ser revelado.Caso voc? n?o seja o destinat?rio autorizado a receber esta mensagem,n?o poder? usar,copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nesse e-mail,por favor,comunique ao remetente e a elimine imediatamente.N?o nos responsabilizamos por opini?es e/ou declara??es veiculadas por e-mail n?o ficando obrigada ao cumprimento de qualquer condi??o constante deste instrumento. >> >> This message,including its attachments,contains and/or may contain confidential and privileged information.If you are not the person authorized to receive this message,you may not use,copy or disclose the information contained therein or take any action based on this information.If this message is received by mistake,please notify the sender by immediately replying to this email and deleting its files.We appreciate your cooperation. > From tshaw at oitc.com Tue Sep 8 23:26:22 2015 From: tshaw at oitc.com (TR Shaw) Date: Tue, 8 Sep 2015 19:26:22 -0400 Subject: Any Tool to replace Peakflow CP In-Reply-To: References: <55ECD211.20100@ip-solutions.net> Message-ID: <07C354C4-3084-407A-B7A3-57B1B12C664C@oitc.com> Could it be GovCloud? See http://defensesystems.com/articles/2014/08/21/aws-govcloud-disa-security-approval.aspx Tom > On Sep 8, 2015, at 7:17 PM, Chris Murray wrote: > > Very Happy with Kentik Detect, highly recommend it. > > www.kentik.com > > Cheers, Chris > > On Sun, Sep 6, 2015 at 4:53 PM, Harry Hoffman wrote: >> Hi Aluisio, >> >> Have you had a look at Lancope's Stealthwatch? >> >> If you go that route give a shout as we've written a bunch of scripts to >> do things like scan detection and new service alerting. >> >> Cheers, >> Harry >> >> >> On 9/5/15 10:01 PM, Aluisio da Silva wrote: >>> Hello, >>> >>> Does anyone here have a suggestion for a tool to replace Peakflow CP from Arbor Networks? >>> >>> Please if possible you would like hear some suggestions. >>> >>> Thanks. >>> >>> Alu?sio da Silva >>> Coordena??o de Planejamento e Engenharia >>> CTBC >>> (34) 3256-2471 >>> (34) 9976-0471 >>> www.ctbc.com.br >>> >>> >>> >>> >>> Esta mensagem,incluindo seus anexos,pode conter informa??o confidencial e/ou privilegiada,sendo de uso exclusivo dos destinat?rios. Seu conte?do n?o deve ser revelado.Caso voc? n?o seja o destinat?rio autorizado a receber esta mensagem,n?o poder? usar,copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nesse e-mail,por favor,comunique ao remetente e a elimine imediatamente.N?o nos responsabilizamos por opini?es e/ou declara??es veiculadas por e-mail n?o ficando obrigada ao cumprimento de qualquer condi??o constante deste instrumento. >>> >>> This message,including its attachments,contains and/or may contain confidential and privileged information.If you are not the person authorized to receive this message,you may not use,copy or disclose the information contained therein or take any action based on this information.If this message is received by mistake,please notify the sender by immediately replying to this email and deleting its files.We appreciate your cooperation. >> From tshaw at oitc.com Tue Sep 8 23:29:29 2015 From: tshaw at oitc.com (TR Shaw) Date: Tue, 8 Sep 2015 19:29:29 -0400 Subject: internet visualization In-Reply-To: References: <20150906001538.GB15900@puck.nether.net> Message-ID: <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> Could it be GovCloud? See http://defensesystems.com/articles/2014/08/21/aws-govcloud-disa-security-approval.aspx > Tom > On Sep 8, 2015, at 7:16 PM, Jeff Shultz wrote: > > Weirdest thing I've found yet - AS7224, Amazon AS - Amazon, has 1 > indegree - AS724 - DNIC-ASBLK-00721-00726 - DoD Network Information > Center, US. > > What the heck is an Amazon (assuming it's associated with Amazon.com) > AS doing hanging off the end of a DOD network? > > Assuming I'm reading it correctly, that is. > > On Sat, Sep 5, 2015 at 5:15 PM, Jared Mauch wrote: >> >> OT: hit delete, or shameless plug disclaimer >> >> one of my colleagues just posted this visualiation >> of the internet from the as_path view of 2914. if you are on >> a mobile, you have to physically move your device around. >> >> http://as2914.net/ >> >> If you love it, send Job your accolades. If you hate it, >> see above disclaimer. If in a country with a holiday on monday, >> enjoy it safely. >> >> - 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 morrowc.lists at gmail.com Wed Sep 9 00:28:18 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 8 Sep 2015 20:28:18 -0400 Subject: internet visualization In-Reply-To: <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> References: <20150906001538.GB15900@puck.nether.net> <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> Message-ID: On Tue, Sep 8, 2015 at 7:29 PM, TR Shaw wrote: > Could it be GovCloud? > ding! (probably) though one DOES wonder why that's viewable from the outside? > See http://defensesystems.com/articles/2014/08/21/aws-govcloud-disa-security-approval.aspx > > > Tom > >> On Sep 8, 2015, at 7:16 PM, Jeff Shultz wrote: >> >> Weirdest thing I've found yet - AS7224, Amazon AS - Amazon, has 1 >> indegree - AS724 - DNIC-ASBLK-00721-00726 - DoD Network Information >> Center, US. >> >> What the heck is an Amazon (assuming it's associated with Amazon.com) >> AS doing hanging off the end of a DOD network? >> >> Assuming I'm reading it correctly, that is. >> >> On Sat, Sep 5, 2015 at 5:15 PM, Jared Mauch wrote: >>> >>> OT: hit delete, or shameless plug disclaimer >>> >>> one of my colleagues just posted this visualiation >>> of the internet from the as_path view of 2914. if you are on >>> a mobile, you have to physically move your device around. >>> >>> http://as2914.net/ >>> >>> If you love it, send Job your accolades. If you hate it, >>> see above disclaimer. If in a country with a holiday on monday, >>> enjoy it safely. >>> >>> - 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 joly at punkcast.com Wed Sep 9 02:05:19 2015 From: joly at punkcast.com (Joly MacFie) Date: Tue, 8 Sep 2015 22:05:19 -0400 Subject: internet visualization In-Reply-To: References: <20150906001538.GB15900@puck.nether.net> <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> Message-ID: ?3/10 for spelling > adjancencies? or is that a thing? -- --------------------------------------------------------------- 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 eric-list at truenet.com Wed Sep 9 02:14:40 2015 From: eric-list at truenet.com (Eric Tykwinski) Date: Tue, 8 Sep 2015 22:14:40 -0400 Subject: internet visualization In-Reply-To: References: <20150906001538.GB15900@puck.nether.net> <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> Message-ID: <1AF910D4-1AF3-40D0-884F-89874006AF5D@truenet.com> Sort of strange since RIPE bgplay is saying the same: https://stat.ripe.net/widget/bgplay#w.resource=7224 Anyone else have some input beside grammar nazis? > On Sep 8, 2015, at 10:05 PM, Joly MacFie wrote: > > ?3/10 for spelling > >> adjancencies? > > or is that a thing? > > > > -- > --------------------------------------------------------------- > 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 amit.rai at netcerts.net Wed Sep 9 03:22:08 2015 From: amit.rai at netcerts.net (Amit Rai) Date: Wed, 09 Sep 2015 03:22:08 +0000 Subject: internet visualization In-Reply-To: <1AF910D4-1AF3-40D0-884F-89874006AF5D@truenet.com> References: <20150906001538.GB15900@puck.nether.net> <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> <1AF910D4-1AF3-40D0-884F-89874006AF5D@truenet.com> Message-ID: Amit.rai at neustar.biz On Wed, Sep 9, 2015 at 7:45 AM Eric Tykwinski wrote: > Sort of strange since RIPE bgplay is saying the same: > https://stat.ripe.net/widget/bgplay#w.resource=7224 < > https://stat.ripe.net/widget/bgplay#w.resource=7224> > > Anyone else have some input beside grammar nazis? > > > On Sep 8, 2015, at 10:05 PM, Joly MacFie wrote: > > > > ?3/10 for spelling > > > >> adjancencies? > > > > or is that a thing? > > > > > > > > -- > > --------------------------------------------------------------- > > 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 morrowc.lists at gmail.com Wed Sep 9 03:49:52 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 8 Sep 2015 23:49:52 -0400 Subject: internet visualization In-Reply-To: References: <20150906001538.GB15900@puck.nether.net> <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> <1AF910D4-1AF3-40D0-884F-89874006AF5D@truenet.com> Message-ID: On Tue, Sep 8, 2015 at 11:22 PM, Amit Rai wrote: > Amit.rai at neustar.biz > On Wed, Sep 9, 2015 at 7:45 AM Eric Tykwinski wrote: > >> Sort of strange since RIPE bgplay is saying the same: >> https://stat.ripe.net/widget/bgplay#w.resource=7224 < >> https://stat.ripe.net/widget/bgplay#w.resource=7224> >> >> Anyone else have some input beside grammar nazis? so, I see 7224 prefixes coming out of: 7922 - comcast 724 - dod-something-or-other I'd guess 7224 is govcloud-stuff for amazon? they MIGHT be getting leaked by mistake by 724 or 721 .... but its pretty hard to tell from 2 as-hops away. From larrysheldon at cox.net Wed Sep 9 05:15:47 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 9 Sep 2015 00:15:47 -0500 Subject: internet visualization In-Reply-To: References: <20150906001538.GB15900@puck.nether.net> <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> Message-ID: <55EFC083.3010802@cox.net> On 9/8/2015 21:05, Joly MacFie wrote: > ?3/10 for spelling > >> adjancencies? > > or is that a thing? http://www.thefreedictionary.com/adjacencies -- sed quis custodiet ipsos custodes? (Juvenal) From aaron at heyaaron.com Wed Sep 9 06:36:05 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Tue, 8 Sep 2015 23:36:05 -0700 Subject: internet visualization In-Reply-To: <1AF910D4-1AF3-40D0-884F-89874006AF5D@truenet.com> References: <20150906001538.GB15900@puck.nether.net> <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> <1AF910D4-1AF3-40D0-884F-89874006AF5D@truenet.com> Message-ID: On Tue, Sep 8, 2015 at 7:14 PM, Eric Tykwinski wrote: > Anyone else have some input beside grammar nazis? Yeah. Add a few Klingon ships and give me phaser control and I will never leave that site. -A From jared at puck.nether.net Wed Sep 9 10:42:51 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 9 Sep 2015 06:42:51 -0400 Subject: internet visualization In-Reply-To: References: <20150906001538.GB15900@puck.nether.net> Message-ID: <707ACB1A-BD07-4924-B082-2CE4007B0A56@puck.nether.net> Please reply off list to me or Job, is this a useful tool that should be updated with data weekly or monthly? Jared Mauch > On Sep 8, 2015, at 7:16 PM, Jeff Shultz wrote: > > Weirdest thing I've found yet - AS7224, Amazon AS - Amazon, has 1 > indegree - AS724 - DNIC-ASBLK-00721-00726 - DoD Network Information > Center, US. > > What the heck is an Amazon (assuming it's associated with Amazon.com) > AS doing hanging off the end of a DOD network? > > Assuming I'm reading it correctly, that is. > >> On Sat, Sep 5, 2015 at 5:15 PM, Jared Mauch wrote: >> >> OT: hit delete, or shameless plug disclaimer >> >> one of my colleagues just posted this visualiation >> of the internet from the as_path view of 2914. if you are on >> a mobile, you have to physically move your device around. >> >> http://as2914.net/ >> >> If you love it, send Job your accolades. If you hate it, >> see above disclaimer. If in a country with a holiday on monday, >> enjoy it safely. >> >> - 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 Sep 9 10:43:39 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 9 Sep 2015 12:43:39 +0200 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: Message-ID: <55F00D5B.7050206@seacom.mu> On 8/Sep/15 21:04, Josh Moore wrote: > I'm reading that the recommended method for assigning IPv6 addresses to end-users is to do this via a dedicated VLAN and /64. Some broadband access methods utilize a shared VLAN model with additional security mechanisms in place such as DHCP snooping, source-verify etc. Why wouldn't it be ideal to share the same /64 amongst all subscribers for simplicity? Depends if your customer is a home user, a business or an ISP. Mark. From mark.tinka at seacom.mu Wed Sep 9 10:46:44 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 9 Sep 2015 12:46:44 +0200 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: <23313.1441739306@turing-police.cc.vt.edu> Message-ID: <55F00E14.8010407@seacom.mu> On 8/Sep/15 21:31, Owen DeLong wrote: > > If the ISPs equipment supports IPv6 on shared VLANs with DHCP snooping and other security, you can implement it with a single /64 giving each router a unique address within that segment, but it?s not really ideal. This was mainly done in IPv4 to conserve addresses. Separate point to point VLANs are a cleaner solution and since there are enough addresses in IPv6 to do this, that is how most providers implement. I prefer using /64s (or at least assigning /64s) to these VLANs, but there are those who argue for /127, some equipment is broken and requires a /126, and yet others argue for other nonsensical prefixes. With Private VLAN's, one could share a single /64 per VLAN without providing Layer 2 reachability between customers on the broadcast domain. However, agree that this is a non-issue for IPv6, so a cleaner method is a lot better. Mark. From mark.tinka at seacom.mu Wed Sep 9 10:51:58 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 9 Sep 2015 12:51:58 +0200 Subject: IPv6 Subscriber Access Deployments In-Reply-To: <34692.1441744883@turing-police.cc.vt.edu> References: <23313.1441739306@turing-police.cc.vt.edu> <26760.1441742090@turing-police.cc.vt.edu> <660E364A-CB4F-40B9-8832-AD1F3CBAF03C@matthew.at> <34692.1441744883@turing-police.cc.vt.edu> Message-ID: <55F00F4E.2000000@seacom.mu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 8/Sep/15 22:41, Valdis.Kletnieks at vt.edu wrote: > > > Oh, it doesn't *need* that many. You can go ahead and run your IPv6 subnets > with a /96 or /112. Just remember that will piss off any hardware that tries > to do SLAAC. or a few other things.... :) Well, if you use DHCPv6 IA_NA for the CPE WAN link, you can go down as low as /128 per CPE device. And then you use DHCP-PD for the onward assignment to the customer's network. Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJV8A9OAAoJEGcZuYTeKm+GffYP/1PaWRPiiWeKAmMnCfbG9Wsr tqNxWIFErIbNjVQpyEJoGRq1AQcygPs1G1ZXL60UnMPi0dpjuxGhr3WboWHuxu2T cXfjdA67l/0SI6dgQJVM+rKlB7hyEun6cSZQ+tcr99nb5DYC80yg1ebYSc/8ulzP 9ZCTb/xAFQsXxnYEj0wjFQSLK3H+4lMbS9jq09/yTAW+6GzJYQZoQY5Wcq3Nn8RI Z+OquW1238B2wvqhzBAAYn3mmFrYXa4mZRpsqilzd8EwpYHk5UfkpYz6k8JX7MnR JsiZ/1D+t9cjRDBozNfPmnr9quIiy35RpzCZNmsG8Ye8jvhvEvlzopZZ/qoKFxpr pZzSxe5+ek0D9sF+cGLNa1EqJciVhe2bF6KLeW/qjtVfOhvevWx22CkBVKk+wvH6 5Hmw/u7PLSFNyG4W42xnPJ0rYM6FMfSpFUCCwqWiLnrLBn1/vtTQHZaBBpg7mkqd DUmAbGgRenT9oGL1pUzieqJoBREbGxZZSD6OTP/nhiBybKRTG8IM2XNgZZjirLOx j0iiWDltCLpBdmclsC4CSWEVzVohbDp+QLl36C6S8VQQDE1MYlbzmKN6xkGuG8vf U+HFteElBXQychFiSswiyofT25uT1OkxxKcV5neh8bv8JJ1i58oSja7E62kOps/n DeYpbYNbCLqGiZ2IenXh =B6fv -----END PGP SIGNATURE----- From dovid at telecurve.com Wed Sep 9 13:36:39 2015 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 9 Sep 2015 13:36:39 +0000 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <55EEA2BE.5090604@cox.net> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> Message-ID: <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> I am trying to understand why the legal babble bothers anyone. Does it give you a nervous twitch? Remind you why you hate legal? It's just text at the bottom of your email. Regards, Dovid -----Original Message----- From: Larry Sheldon Sender: "NANOG" Date: Tue, 8 Sep 2015 03:56:30 To: Subject: Re: Extraneous "legal" babble--and my reaction to it. On 9/8/2015 03:31, Rich Kulawiec wrote: > On Sun, Sep 06, 2015 at 09:14:02PM +0000, Connor Wilkins wrote: >> Honestly.. the best method is to not let it bug you anymore. It's >> only a seething issue to you because you let it be. > > Curiously enough, the same thing was said about spam 30-ish years ago. > The "ignore it and maybe it will go away" approach did not yield > satisfactory results. > > These "disclaimers" are stupid and abusive. They have no place in > *any* email traffic, and most certainly not in a professional forum. > And it is unreasonable to expect the recipients of the demands and > threats they embody to silently tolerate them ad infinitum. Exactly so. JHD -- sed quis custodiet ipsos custodes? (Juvenal) From joly at punkcast.com Wed Sep 9 15:13:53 2015 From: joly at punkcast.com (Joly MacFie) Date: Wed, 9 Sep 2015 11:13:53 -0400 Subject: internet visualization In-Reply-To: <55EFC083.3010802@cox.net> References: <20150906001538.GB15900@puck.nether.net> <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> <55EFC083.3010802@cox.net> Message-ID: Crow for lunch today. On Wednesday, September 9, 2015, Larry Sheldon wrote: > On 9/8/2015 21:05, Joly MacFie wrote: > >> ?3/10 for spelling >> >> adjancencies? >>> >> >> or is that a thing? >> > > http://www.thefreedictionary.com/adjacencies > > > -- > sed quis custodiet ipsos custodes? (Juvenal) > -- --------------------------------------------------------------- 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 A.L.M.Buxey at lboro.ac.uk Wed Sep 9 15:23:01 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Wed, 9 Sep 2015 16:23:01 +0100 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> Message-ID: <85BD4A92-3467-4605-A3AA-8CBBE939910E@lboro.ac.uk> >It's just text at the bottom of your email. 1 often a very large amount of text - in this case the legalese was something like 10x longer than the comment! 2 its pointless. Its not enforceable and doesn't mean anything. Shall i put a chapter of war and peace at the end of my emails? You could just ignore it..... ;) alan From johnl at iecc.com Wed Sep 9 15:24:21 2015 From: johnl at iecc.com (John Levine) Date: 9 Sep 2015 15:24:21 -0000 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> Message-ID: <20150909152421.51711.qmail@ary.lan> In article <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326- at b13.c3.bise6.blackberry> you write: >I am trying to understand why the legal babble bothers anyone. Does it give you a nervous twitch? Remind you why you hate legal? >It's just text at the bottom of your email. Indeed, but it's text that says something between "I am stupid" and "my life is controlled by people who are stupid." Generally speaking, many of us would prefer less stupid. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From oliver.oboyle at gmail.com Wed Sep 9 15:34:20 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Wed, 9 Sep 2015 11:34:20 -0400 Subject: internet visualization In-Reply-To: References: <20150906001538.GB15900@puck.nether.net> <46EBFB42-25F3-461C-80DB-E430B104E329@oitc.com> <55EFC083.3010802@cox.net> Message-ID: A bit of salt on that will help... On Wed, Sep 9, 2015 at 11:13 AM, Joly MacFie wrote: > Crow for lunch today. > > On Wednesday, September 9, 2015, Larry Sheldon > wrote: > > > On 9/8/2015 21:05, Joly MacFie wrote: > > > >> ?3/10 for spelling > >> > >> adjancencies? > >>> > >> > >> or is that a thing? > >> > > > > http://www.thefreedictionary.com/adjacencies > > > > > > -- > > sed quis custodiet ipsos custodes? (Juvenal) > > > > > -- > --------------------------------------------------------------- > 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 > -------------------------------------------------------------- > - > -- :o@> From Valdis.Kletnieks at vt.edu Wed Sep 9 15:06:47 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 09 Sep 2015 11:06:47 -0400 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> Message-ID: <4061.1441811207@turing-police.cc.vt.edu> On Wed, 09 Sep 2015 13:36:39 -0000, "Dovid Bender" said: > I am trying to understand why the legal babble bothers anyone. Does it give > you a nervous twitch? Remind you why you hate legal? It's just text at the > bottom of your email. Disclaimers like those are like brown M&M's backstage at a Van Halen concert. If you see one of those on mail sent to a public mailing list, it's a sure sign that there's other, much more serious issues. Because let's face it, they're an admission that the offending company hasn't gotten a *real* data confidentiality program in place, and the amount of attempted adhesion in them indicates that the legal people asking for it may not be all that competent either.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From dovid at telecurve.com Wed Sep 9 15:44:19 2015 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 9 Sep 2015 15:44:19 +0000 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <85BD4A92-3467-4605-A3AA-8CBBE939910E@lboro.ac.uk> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> <85BD4A92-3467-4605-A3AA-8CBBE939910E@lboro.ac.uk> Message-ID: <1435567071-1441813460-cardhu_decombobulator_blackberry.rim.net-814641916-@b13.c3.bise6.blackberry> I would. Once I see legal stuff I know to stop reading. It does not hurt anyone. Not sure why this hurts so much. Some things will remain a mystery. Regards, Dovid -----Original Message----- From: Alan Buxey Date: Wed, 9 Sep 2015 16:23:01 To: ; Larry Sheldon; NANOG; Subject: Re: Extraneous "legal" babble--and my reaction to it. >It's just text at the bottom of your email. 1 often a very large amount of text - in this case the legalese was something like 10x longer than the comment! 2 its pointless. Its not enforceable and doesn't mean anything. Shall i put a chapter of war and peace at the end of my emails? You could just ignore it..... ;) alan From alh-ietf at tndh.net Wed Sep 9 16:13:48 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 9 Sep 2015 09:13:48 -0700 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <1435567071-1441813460-cardhu_decombobulator_blackberry.rim.net-814641916-@b13.c3.bise6.blackberry> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> <85BD4A92-3467-4605-A3AA-8CBBE939910E@lboro.ac.uk> <1435567071-1441813460-cardhu_decombobulator_blackberry.rim.net-814641916-@b13.c3.bise6.blackberry> Message-ID: <011001d0eb1a$827f6b10$877e4130$@tndh.net> Dovid Bender wrote: > I would. Once I see legal stuff I know to stop reading. It does not hurt > anyone. Not sure why this hurts so much. Some things will remain a > mystery. > No mystery ... It wastes bits that could otherwise be used to watch cat videos. ;) Tony From oliver.oboyle at gmail.com Wed Sep 9 16:29:37 2015 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Wed, 9 Sep 2015 12:29:37 -0400 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <011001d0eb1a$827f6b10$877e4130$@tndh.net> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> <85BD4A92-3467-4605-A3AA-8CBBE939910E@lboro.ac.uk> <1435567071-1441813460-cardhu_decombobulator_blackberry.rim.net-814641916-@b13.c3.bise6.blackberry> <011001d0eb1a$827f6b10$877e4130$@tndh.net> Message-ID: I love cat videos. On Wed, Sep 9, 2015 at 12:13 PM, Tony Hain wrote: > Dovid Bender wrote: > > I would. Once I see legal stuff I know to stop reading. It does not hurt > > anyone. Not sure why this hurts so much. Some things will remain a > > mystery. > > > > No mystery ... It wastes bits that could otherwise be used to watch cat > videos. ;) > > Tony > > > -- :o@> From list at satchell.net Wed Sep 9 16:42:57 2015 From: list at satchell.net (Stephen Satchell) Date: Wed, 9 Sep 2015 09:42:57 -0700 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> Message-ID: <55F06190.9070001@satchell.net> On 09/09/2015 06:36 AM, Dovid Bender wrote: > I am trying to understand why the legal babble bothers anyone. Does > it give you a nervous twitch? Remind you why you hate legal? It's > just text at the bottom of your email. It's all about best practices. In an e-mail thread, where the thread grows with each response, the original e-mail etiquette is that people put their reply at the bottom of the message. The theory behind the practice is that when you are going back to read the message later, you can read it top-down and get the contributions in chronological order. (And only save the last one, instead of all of them.) If you have a huge disclaimer in your sig, when the reader goes to the bottom of the e-mail to read the latest contribution, they have to back up over the over-large signature block. This is irritating. For some readers using non-graphical e-mail clients or Web clients, that irritation can grow to the point that the message gets tossed. That's why the Best Practices RFC said to have no more than three lines in your .sig of at most 71 characters each. With AOL and "Forever September", some of these things get lost in the waves and waves of non-compliance, not because people don't want to be good citizens, but because they don't know better. And, if you aren't keeping the entire thread (such as what I'm doing here), you trim quotes to the absolute minimum to maintain context, so that people don't have to wade through the whole mess. It also avoids top-posting, which in some circles is Bad Form(tm). By the way, it's never been about cat videos... From owen at delong.com Wed Sep 9 17:14:26 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Sep 2015 10:14:26 -0700 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: <23313.1441739306@turing-police.cc.vt.edu> Message-ID: VLAN tags aren?t global and 4096 is only a limitation on ethernet. VPI/VCI is many more. Yes, if you need more than 4096 customers on a single switch, you?ve got an issue, but there are many potential issues in that scenario beyond VLAN tagging (like customers choosing not to use routers and filling up your MAC tables). Owen > On Sep 8, 2015, at 12:40 , Josh Moore wrote: > > The question becomes manageability. Unique VLAN per customer is not always scalable. For example, only ~4000 VLAN tags. What happens when you have more than that many customers? Also, provisioning. Who is going to provision thousands of unique prefixes and VLANs, trunk them through relevant equipment and ensure they are secured as well? > > We are talking very, very, small customers here. SOHO to say the most. /64 should be more than sufficient for their CPE router. > > > > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 - O | 912.218.3720 - M > > > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, September 08, 2015 3:31 PM > To: Josh Moore > Cc: Valdis.Kletnieks at vt.edu; nanog at nanog.org > Subject: Re: IPv6 Subscriber Access Deployments > > Short answer to that is ?DHCPv6-PD? > > Longer answer: > > Customer?s router should get an address on the external interface through one of SLAAC, DHCP-PD, Static Assignment, depending on how the ISP prefers to do this. > > If the ISPs equipment supports IPv6 on shared VLANs with DHCP snooping and other security, you can implement it with a single /64 giving each router a unique address within that segment, but it?s not really ideal. This was mainly done in IPv4 to conserve addresses. Separate point to point VLANs are a cleaner solution and since there are enough addresses in IPv6 to do this, that is how most providers implement. I prefer using /64s (or at least assigning /64s) to these VLANs, but there are those who argue for /127, some equipment is broken and requires a /126, and yet others argue for other nonsensical prefixes. > > Once the router has an external address communicating point to point with the ISP router, it should then send an DHCPv6-PD request asking for a prefix that it can manage. The ISPs DHCP server should then send back a /48 (or if you want to be silly, a /56 or a /60, and if you want to be insane, a /64). > > The reality is that if you send a smaller prefix back, you risk having difficulty with your future ARIN applications as your Provider Allocation Unit is based on the smallest prefix you delegate to end-users. So if you, for example, assign /48 to business customers and /60 to residential customers, you?re going to have to justify why each of your business customers needed 4096 /60s when you claim that you need more IPv6 space. > > OTOH, if you simply issue /48s to everyone, you can just go back and say ?Each end site got a /48 and there are N end-sites? and you?re good, no questions asked about the size of any of those end-sites. > > Owen > >> On Sep 8, 2015, at 12:12 , Josh Moore wrote: >> >> We are talking a purely bridged environment. However, I have been wondering how in the world end-to-end IPv6 connectivity is supposed to work if a customer hooks up their own router. That is one of the points of IPv6... >> >> >> >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 - O | 912.218.3720 - M >> >> >> -----Original Message----- >> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] >> Sent: Tuesday, September 08, 2015 3:08 PM >> To: Josh Moore >> Cc: nanog at nanog.org >> Subject: Re: IPv6 Subscriber Access Deployments >> >> On Tue, 08 Sep 2015 19:04:06 -0000, Josh Moore said: >>> I'm reading that the recommended method for assigning IPv6 addresses to end-users is to do this via a dedicated VLAN and /64. >> >> Important question - are you talking about the IPv6 address supplied to the CPE router itself, or a /48 or /56 delegated to the CPE router to allocate to subnets and devices behind it? > From owen at delong.com Wed Sep 9 17:15:21 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Sep 2015 10:15:21 -0700 Subject: IPv6 Subscriber Access Deployments In-Reply-To: <1441741576.143219.378115649.3634EE3A@webmail.messagingengine.com> References: <23313.1441739306@turing-police.cc.vt.edu> <1441741576.143219.378115649.3634EE3A@webmail.messagingengine.com> Message-ID: <7B11BBC4-8B7B-49FD-B03C-0ACFCAB10263@delong.com> Sure, but this is a useless savings that comes at the cost of awkward traceroute output that will initially confuse your new employees and consistently confuse your customers. Owen > On Sep 8, 2015, at 12:46 , Clinton Work wrote: > > If you use separate VLANs for each customer then the CPE router doesn't > even require an external IPV6 address for DHCPv6-PD. IPV6 link-local > addresses can be used between your BRAS and customer CPE router. Some > CPEs can even allocate a WAN/mgmt IPV6 address out of the delegated > subnet via DHCPv6-PD. > > On Tue, Sep 8, 2015, at 01:31 PM, Owen DeLong wrote: >> Short answer to that is ?DHCPv6-PD? >> >> Once the router has an external address communicating point to point with >> the ISP router, it should then send an DHCPv6-PD request asking for a >> prefix that it can manage. The ISPs DHCP server should then send back a >> /48 (or if you want to be silly, a /56 or a /60, and if you want to be >> insane, a /64). From jmoore at atcnetworks.net Wed Sep 9 17:16:26 2015 From: jmoore at atcnetworks.net (Josh Moore) Date: Wed, 9 Sep 2015 17:16:26 +0000 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: <23313.1441739306@turing-police.cc.vt.edu> , Message-ID: It's not just the tag though... You have the /64 that has to be provisioned, the helper addresses for DHCP, ACLs/security policy, etc. Thanks, Joshua Moore Network Engineer ATC Broadband 912.632.3161 > On Sep 9, 2015, at 1:14 PM, Owen DeLong wrote: > > VLAN tags aren?t global and 4096 is only a limitation on ethernet. > > VPI/VCI is many more. > > Yes, if you need more than 4096 customers on a single switch, you?ve got an issue, but there are many potential issues in that scenario beyond VLAN tagging (like customers choosing not to use routers and filling up your MAC tables). > > Owen > >> On Sep 8, 2015, at 12:40 , Josh Moore wrote: >> >> The question becomes manageability. Unique VLAN per customer is not always scalable. For example, only ~4000 VLAN tags. What happens when you have more than that many customers? Also, provisioning. Who is going to provision thousands of unique prefixes and VLANs, trunk them through relevant equipment and ensure they are secured as well? >> >> We are talking very, very, small customers here. SOHO to say the most. /64 should be more than sufficient for their CPE router. >> >> >> >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 - O | 912.218.3720 - M >> >> >> >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Tuesday, September 08, 2015 3:31 PM >> To: Josh Moore >> Cc: Valdis.Kletnieks at vt.edu; nanog at nanog.org >> Subject: Re: IPv6 Subscriber Access Deployments >> >> Short answer to that is ?DHCPv6-PD? >> >> Longer answer: >> >> Customer?s router should get an address on the external interface through one of SLAAC, DHCP-PD, Static Assignment, depending on how the ISP prefers to do this. >> >> If the ISPs equipment supports IPv6 on shared VLANs with DHCP snooping and other security, you can implement it with a single /64 giving each router a unique address within that segment, but it?s not really ideal. This was mainly done in IPv4 to conserve addresses. Separate point to point VLANs are a cleaner solution and since there are enough addresses in IPv6 to do this, that is how most providers implement. I prefer using /64s (or at least assigning /64s) to these VLANs, but there are those who argue for /127, some equipment is broken and requires a /126, and yet others argue for other nonsensical prefixes. >> >> Once the router has an external address communicating point to point with the ISP router, it should then send an DHCPv6-PD request asking for a prefix that it can manage. The ISPs DHCP server should then send back a /48 (or if you want to be silly, a /56 or a /60, and if you want to be insane, a /64). >> >> The reality is that if you send a smaller prefix back, you risk having difficulty with your future ARIN applications as your Provider Allocation Unit is based on the smallest prefix you delegate to end-users. So if you, for example, assign /48 to business customers and /60 to residential customers, you?re going to have to justify why each of your business customers needed 4096 /60s when you claim that you need more IPv6 space. >> >> OTOH, if you simply issue /48s to everyone, you can just go back and say ?Each end site got a /48 and there are N end-sites? and you?re good, no questions asked about the size of any of those end-sites. >> >> Owen >> >>> On Sep 8, 2015, at 12:12 , Josh Moore wrote: >>> >>> We are talking a purely bridged environment. However, I have been wondering how in the world end-to-end IPv6 connectivity is supposed to work if a customer hooks up their own router. That is one of the points of IPv6... >>> >>> >>> >>> >>> Joshua Moore >>> Network Engineer >>> ATC Broadband >>> 912.632.3161 - O | 912.218.3720 - M >>> >>> >>> -----Original Message----- >>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] >>> Sent: Tuesday, September 08, 2015 3:08 PM >>> To: Josh Moore >>> Cc: nanog at nanog.org >>> Subject: Re: IPv6 Subscriber Access Deployments >>> >>> On Tue, 08 Sep 2015 19:04:06 -0000, Josh Moore said: >>>> I'm reading that the recommended method for assigning IPv6 addresses to end-users is to do this via a dedicated VLAN and /64. >>> >>> Important question - are you talking about the IPv6 address supplied to the CPE router itself, or a /48 or /56 delegated to the CPE router to allocate to subnets and devices behind it? >> > From owen at delong.com Wed Sep 9 17:19:49 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Sep 2015 10:19:49 -0700 Subject: IPv6 Subscriber Access Deployments In-Reply-To: <660E364A-CB4F-40B9-8832-AD1F3CBAF03C@matthew.at> References: <23313.1441739306@turing-police.cc.vt.edu> <26760.1441742090@turing-police.cc.vt.edu> <660E364A-CB4F-40B9-8832-AD1F3CBAF03C@matthew.at> Message-ID: <8B7C91BC-2B7C-4ADA-B84A-F1BD48273C7D@delong.com> Because the designers of IPv6 didn?t want to bake the hardware constraints of equipment available 10+ years ago (20?) into the addressing plan for the future. Hanging 4k customers off a switch is a current hardware limitation which has almost nothing to do with IPv6 other than not being possible in IPv4 due to limitations in IPv4 whereas IPv6 does not impose such limitations in the L3 protocol. Think of it like consecutive apertures? If you are looking through a pinhole, you can?t see that your entire view is through the center hole of a washer 1/2? behind the pinhole. (IPv4 is the pinhole in this case, modern hardware is the washer). If you open up the pinhole, suddenly the washer becomes visible. IPv6 is everything beyond the washer visible and obscured. Owen > On Sep 8, 2015, at 13:13 , Matthew Kaufman wrote: > > If you can't hang 4k customers off a switch, why does IPv6 need so many bits for the host portion? > > Matthew Kaufman > > (Sent from my iPhone) > >> On Sep 8, 2015, at 12:54 PM, Valdis.Kletnieks at vt.edu wrote: >> >> On Tue, 08 Sep 2015 19:40:44 -0000, Josh Moore said: >> >>> The question becomes manageability. Unique VLAN per customer is not always >>> scalable. For example, only ~4000 VLAN tags. What happens when you have more >>> than that many customers? >> >> If you're hanging 4K customers off the same switch, you probably have bigger >> issues than running out of VLAN tags... >> >>> We are talking very, very, small customers here. SOHO to say the most. >>> /64 should be more than sufficient for their CPE router. >> >> A Linksys WNDR3800 running CeroWRT (and probably OpenWRT by now) will prefer to >> create multiple /64's - one for the 4 wired ports, one for private access on the >> 2.4G radio, one for guest access on the 2.4, and another private/guest pair >> on the 5G radio. So there is CPE gear out there now that can blow through 5 /64s >> by default, and more if you enable VLANs. >> >> A /56 allocated via DHCPv6-PD would be a *minimum*. And prefixes are cheap, >> so you may as well hand them a /48, just in case they have a second WNDR3800 >> at the other end of the building for coverage - because that one will then ask >> the upstream one for a -PD allocation. So if you give the CPE a /48, it can >> keep a /56 for itself, and hand the downstream a /56, and they can each >> allocate /64s as needed. >> >> And remember - prefixes are cheap and plentiful, so don't bother with /52 >> or /60, just split on 8-bit boundaries to make life easier for yourself... >> From owen at delong.com Wed Sep 9 17:23:17 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Sep 2015 10:23:17 -0700 Subject: IPv6 Subscriber Access Deployments In-Reply-To: References: <23313.1441739306@turing-police.cc.vt.edu> Message-ID: <7E4BD693-0CF7-434A-855C-285A995AC1A1@delong.com> The ACLs/Security policy can actually be fairly generic or automated, so I don?t see that as an issue. The DHCP forwarder configuration is usually global, so the helper address statement demonstrates your lack of IPv6 understanding. The /64 is pretty much nothing, but yeah, so what? Owen > On Sep 9, 2015, at 10:16 , Josh Moore wrote: > > It's not just the tag though... You have the /64 that has to be provisioned, the helper addresses for DHCP, ACLs/security policy, etc. > > > > > Thanks, > > Joshua Moore > Network Engineer > ATC Broadband > 912.632.3161 > >> On Sep 9, 2015, at 1:14 PM, Owen DeLong wrote: >> >> VLAN tags aren?t global and 4096 is only a limitation on ethernet. >> >> VPI/VCI is many more. >> >> Yes, if you need more than 4096 customers on a single switch, you?ve got an issue, but there are many potential issues in that scenario beyond VLAN tagging (like customers choosing not to use routers and filling up your MAC tables). >> >> Owen >> >>> On Sep 8, 2015, at 12:40 , Josh Moore wrote: >>> >>> The question becomes manageability. Unique VLAN per customer is not always scalable. For example, only ~4000 VLAN tags. What happens when you have more than that many customers? Also, provisioning. Who is going to provision thousands of unique prefixes and VLANs, trunk them through relevant equipment and ensure they are secured as well? >>> >>> We are talking very, very, small customers here. SOHO to say the most. /64 should be more than sufficient for their CPE router. >>> >>> >>> >>> >>> Joshua Moore >>> Network Engineer >>> ATC Broadband >>> 912.632.3161 - O | 912.218.3720 - M >>> >>> >>> >>> -----Original Message----- >>> From: Owen DeLong [mailto:owen at delong.com] >>> Sent: Tuesday, September 08, 2015 3:31 PM >>> To: Josh Moore >>> Cc: Valdis.Kletnieks at vt.edu; nanog at nanog.org >>> Subject: Re: IPv6 Subscriber Access Deployments >>> >>> Short answer to that is ?DHCPv6-PD? >>> >>> Longer answer: >>> >>> Customer?s router should get an address on the external interface through one of SLAAC, DHCP-PD, Static Assignment, depending on how the ISP prefers to do this. >>> >>> If the ISPs equipment supports IPv6 on shared VLANs with DHCP snooping and other security, you can implement it with a single /64 giving each router a unique address within that segment, but it?s not really ideal. This was mainly done in IPv4 to conserve addresses. Separate point to point VLANs are a cleaner solution and since there are enough addresses in IPv6 to do this, that is how most providers implement. I prefer using /64s (or at least assigning /64s) to these VLANs, but there are those who argue for /127, some equipment is broken and requires a /126, and yet others argue for other nonsensical prefixes. >>> >>> Once the router has an external address communicating point to point with the ISP router, it should then send an DHCPv6-PD request asking for a prefix that it can manage. The ISPs DHCP server should then send back a /48 (or if you want to be silly, a /56 or a /60, and if you want to be insane, a /64). >>> >>> The reality is that if you send a smaller prefix back, you risk having difficulty with your future ARIN applications as your Provider Allocation Unit is based on the smallest prefix you delegate to end-users. So if you, for example, assign /48 to business customers and /60 to residential customers, you?re going to have to justify why each of your business customers needed 4096 /60s when you claim that you need more IPv6 space. >>> >>> OTOH, if you simply issue /48s to everyone, you can just go back and say ?Each end site got a /48 and there are N end-sites? and you?re good, no questions asked about the size of any of those end-sites. >>> >>> Owen >>> >>>> On Sep 8, 2015, at 12:12 , Josh Moore wrote: >>>> >>>> We are talking a purely bridged environment. However, I have been wondering how in the world end-to-end IPv6 connectivity is supposed to work if a customer hooks up their own router. That is one of the points of IPv6... >>>> >>>> >>>> >>>> >>>> Joshua Moore >>>> Network Engineer >>>> ATC Broadband >>>> 912.632.3161 - O | 912.218.3720 - M >>>> >>>> >>>> -----Original Message----- >>>> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] >>>> Sent: Tuesday, September 08, 2015 3:08 PM >>>> To: Josh Moore >>>> Cc: nanog at nanog.org >>>> Subject: Re: IPv6 Subscriber Access Deployments >>>> >>>> On Tue, 08 Sep 2015 19:04:06 -0000, Josh Moore said: >>>>> I'm reading that the recommended method for assigning IPv6 addresses to end-users is to do this via a dedicated VLAN and /64. >>>> >>>> Important question - are you talking about the IPv6 address supplied to the CPE router itself, or a /48 or /56 delegated to the CPE router to allocate to subnets and devices behind it? >>> >> From owen at delong.com Wed Sep 9 17:29:36 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Sep 2015 10:29:36 -0700 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> Message-ID: In my case, I resent the idea that some lawyer somewhere thought I could somehow be bound to an agreement I never agreed to which does not appear to me until I have reached the end of an email on which he/she feels I should be bound. It?s an absurd construct. It?s a waste of bits that could be used for good purpose such as discussing why we all dislike lawyers so much. It?s a display of arrogance and it?s presumptuous. In short, it?s an offensive behavior. The fact that it is a corporate policy only makes it more offensive. Owen > On Sep 9, 2015, at 06:36 , Dovid Bender wrote: > > I am trying to understand why the legal babble bothers anyone. Does it give you a nervous twitch? Remind you why you hate legal? It's just text at the bottom of your email. > > Regards, > > Dovid > > -----Original Message----- > From: Larry Sheldon > Sender: "NANOG" Date: Tue, 8 Sep 2015 03:56:30 > To: > Subject: Re: Extraneous "legal" babble--and my reaction to it. > > On 9/8/2015 03:31, Rich Kulawiec wrote: >> On Sun, Sep 06, 2015 at 09:14:02PM +0000, Connor Wilkins wrote: >>> Honestly.. the best method is to not let it bug you anymore. It's >>> only a seething issue to you because you let it be. >> >> Curiously enough, the same thing was said about spam 30-ish years ago. >> The "ignore it and maybe it will go away" approach did not yield >> satisfactory results. >> >> These "disclaimers" are stupid and abusive. They have no place in >> *any* email traffic, and most certainly not in a professional forum. >> And it is unreasonable to expect the recipients of the demands and >> threats they embody to silently tolerate them ad infinitum. > > Exactly so. > JHD > > > -- > sed quis custodiet ipsos custodes? (Juvenal) From bill at herrin.us Wed Sep 9 17:32:33 2015 From: bill at herrin.us (William Herrin) Date: Wed, 9 Sep 2015 13:32:33 -0400 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <55F06190.9070001@satchell.net> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> <55F06190.9070001@satchell.net> Message-ID: > On 09/09/2015 06:36 AM, Dovid Bender wrote: >> I am trying to understand why the legal babble bothers anyone. Does >> it give you a nervous twitch? Remind you why you hate legal? It's >> just text at the bottom of your email. Here's the thing... If your employer insists on attaching a legalistic signature to your email which warns the recipient that the message is for their eyes only... it's because you are not authorized to make public statements as an employee of the company. So please respect that limitation and make your _public_ posts to NANOG without using your work email address. 'Cause if you don't respect us enough not to flood us with wacky legal documents and you don't respect your employer enough to obey their rules, why should we respect anything else you have to say? Make sense? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bevan at slattery.net.au Wed Sep 9 10:51:57 2015 From: bevan at slattery.net.au (Bevan Slattery) Date: Wed, 09 Sep 2015 20:51:57 +1000 Subject: Software Defined Networking In-Reply-To: <55EDFE3E.6050509@foobar.org> References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <7A74991F-1204-4CE7-9AB0-66B9F2A281AD@egon.cc> <55EDFE3E.6050509@foobar.org> Message-ID: On 8/09/2015 7:14 am, "Nick Hilliard" wrote: >On 07/09/2015 21:23, James Downs wrote: >> What do you mean when you say ?software defined networking?? Do you have >> a particular problem or use case you are approaching? > >since when was that a requirement for SDN? > >Nick Yes. Usually Automation/Orchestration and allowing the customer to manage their own network requirements in real-time through a portal/iPhone etc? Cheers [b] From gustav.ulander at telecomputing.se Tue Sep 8 15:19:52 2015 From: gustav.ulander at telecomputing.se (Gustav Ulander) Date: Tue, 8 Sep 2015 15:19:52 +0000 Subject: internet visualization In-Reply-To: References: <20150906001538.GB15900@puck.nether.net> <55EEF295.8010704@netassist.ua> Message-ID: Agreed. Everyone at the office have been flying some. :) //Gustav -----Original Message----- From: NANOG [mailto:nanog-bounces+gustav.ulander=telecomputing.se at nanog.org] On Behalf Of Chris Knipe Sent: den 8 september 2015 16:50 To: nanog list Subject: Re: internet visualization Indeed! One of the nicest visualizations I've seen to date. Loving it! On Tue, Sep 8, 2015 at 4:37 PM, Max Tulyev wrote: > Really nice! > > How can I do zoom in/zoom out? > > On 06.09.15 03:15, Jared Mauch wrote: > > > > OT: hit delete, or shameless plug disclaimer > > > > one of my colleagues just posted this visualiation of the > > internet from the as_path view of 2914. if you are on a mobile, you > > have to physically move your device around. > > > > http://as2914.net/ > > > > If you love it, send Job your accolades. If you hate it, see > > above disclaimer. If in a country with a holiday on monday, enjoy > > it safely. > > > > - Jared > > > > -- Regards, Chris Knipe From list-nanog at beufa.net Tue Sep 8 19:52:48 2015 From: list-nanog at beufa.net (Fabien VINCENT) Date: Tue, 08 Sep 2015 21:52:48 +0200 Subject: Contact for AS701/Verizon Message-ID: Dear List, If someone reads my email from Verizon/AS701, we are looking for an internal contact in order to check opportunities/facilities regarding transit/PNI. Thanks in advance for any help ;) Regards, Fabien VINCENT From list-nanog at beufa.net Tue Sep 8 20:34:50 2015 From: list-nanog at beufa.net (Fabien V.) Date: Tue, 08 Sep 2015 22:34:50 +0200 Subject: Contact for AS701/Verizon In-Reply-To: References: Message-ID: <4f8cf5099094f61ec8472977ffe5741a@beufa.net> Dear List, If someone reads my email from Verizon/AS701, we are looking for an internal contact in order to check opportunities/facilities regarding transit/PNI. Thanks in advance for any help ;) Regards, -- ----- Fabien VINCENT From florian at figula.de Wed Sep 9 15:56:27 2015 From: florian at figula.de (Florian Figula) Date: Wed, 9 Sep 2015 17:56:27 +0200 Subject: Cisco ASR9K G.8032 ERP configuration and experiences Message-ID: <006801d0eb18$1689daa0$439d8fe0$@figula.de> Maybe someone having some experiences with Cisco ASR9K and ERP (G.8032)? I have configured a pair of two ASR9K for a customer. The other side is a pair of Huawei Switch. The Ring seems to work fine. We have simulated link fault and protection switch occurred but on traffic test we were not able to send traffic from one ASR9K to the other one. Both ASR9K are configured equally. For test I would also like to connect a Cisco Catalyst with trunk configuration via interface GigaBitEthernet0/0/1/7, QinQ should be possible. I think I also have to increase the MTU size on the interfaces. Next and last question, will I be able to send L3 traffic through one of the VLANs, if I will create a bvi interface and configure this under the bridge domain? ethernet ring g8032 profile PROFILE-XXX timer wtr 1 timer guard 2000 timer hold-off 0 ! interface GigabitEthernet0/0/1/7.1700 l2transport description Catalyst Trunk encapsulation dot1q 1700-1798 ! interface GigabitEthernet0/0/1/8 description "Huawei" ! interface GigabitEthernet0/0/1/8.1700 l2transport description Data encapsulation dot1q 1700-1798 ! interface GigabitEthernet0/0/1/8.1799 l2transport description APS encapsulation dot1q 1799 ! interface GigabitEthernet0/0/1/9 description "ASR9K" ! interface GigabitEthernet0/0/1/9.1700 l2transport description Data encapsulation dot1q 1700-1798 ! interface GigabitEthernet0/0/1/9.1799 l2transport description APS encapsulation dot1q 1799 ! l2vpn ethernet ring g8032 XXX port0 interface GigabitEthernet0/0/1/8 monitor interface GigabitEthernet0/0/1/8.1799 ! port1 interface GigabitEthernet0/0/1/9 monitor interface GigabitEthernet0/0/1/9.1799 ! instance 1 description XXX profile PROFILE-XXX inclusion-list vlan-ids 1700-1799 aps-channel level 7 port0 interface GigabitEthernet0/0/1/8.1799 port1 interface GigabitEthernet0/0/1/9.1799 ! ! ! bridge group G8032-XXX bridge-domain G8032-XXX-APS interface GigabitEthernet0/0/1/8.1799 ! interface GigabitEthernet0/0/1/9.1799 ! ! bridge-domain G8032-XXX-DATA interface GigabitEthernet0/0/1/7.1700 ! interface GigabitEthernet0/0/1/8.1700 ! interface GigabitEthernet0/0/1/9.1700 ! From tgrand at tgrand.com Wed Sep 9 16:49:30 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Wed, 9 Sep 2015 11:49:30 -0500 Subject: outlook.com outgoing blacklists? Message-ID: I have an email server which hosts 3 domains. I have reason to believe that microsoft maintains an outgoing blacklist and would like confirmation on this. I have had many a report that people on domains hosted on hotmail/outlook are getting messages bounced back stating that our server was unreachable. This only happens for one of the three domains hosted on our server. I went to outlook.com and setup an account. When I create a new message and enter the recipient at that affected domain, the address immediately turns red, and when I hover over it states that the address may not be valid. This happens without ever sending a packet to our servers. The affected domain can send emails to hotmail/outlook accounts just fine. Anybody have some recommendations on how I resolve this, as Microsoft support seems to be under technical. Thanks, Todd K. Grand From Valdis.Kletnieks at vt.edu Wed Sep 9 18:22:07 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 09 Sep 2015 14:22:07 -0400 Subject: outlook.com outgoing blacklists? In-Reply-To: References: Message-ID: <19526.1441822927@turing-police.cc.vt.edu> On Wed, 09 Sep 2015 11:49:30 -0500, "Todd K Grand" said: > This happens without ever sending a packet to our servers. > The affected domain can send emails to hotmail/outlook accounts just fine. Step 0: Verify that the DNS has the appropriate MX, A, and other records for the failing domain. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From tgrand at tgrand.com Wed Sep 9 18:24:37 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Wed, 9 Sep 2015 13:24:37 -0500 Subject: outlook.com outgoing blacklists? In-Reply-To: <19526.1441822927@turing-police.cc.vt.edu> References: <19526.1441822927@turing-police.cc.vt.edu> Message-ID: <5EDED8ADF86342A7940C0A1DCF20513A@ToddDev> DNS has been confirmed to be valid. -----Original Message----- From: Valdis.Kletnieks at vt.edu Sent: Wednesday, September 9, 2015 1:22 PM To: Todd K Grand Cc: nanog at nanog.org Subject: Re: outlook.com outgoing blacklists? >On Wed, 09 Sep 2015 11:49:30 -0500, "Todd K Grand" said: > >> This happens without ever sending a packet to our servers. >> The affected domain can send emails to hotmail/outlook accounts just >> fine. > >Step 0: Verify that the DNS has the appropriate MX, A, and other records >for the failing domain. From steve at blighty.com Wed Sep 9 18:43:44 2015 From: steve at blighty.com (Steve Atkins) Date: Wed, 9 Sep 2015 11:43:44 -0700 Subject: outlook.com outgoing blacklists? In-Reply-To: References: Message-ID: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> > > Anybody have some recommendations on how I resolve this The most likely explanation is a configuration error at your end, so the first step is to share what the domain is. Cheers, Steve From clinton at scripty.com Wed Sep 9 18:51:33 2015 From: clinton at scripty.com (Clinton Work) Date: Wed, 09 Sep 2015 12:51:33 -0600 Subject: IPv6 Subscriber Access Deployments In-Reply-To: <7B11BBC4-8B7B-49FD-B03C-0ACFCAB10263@delong.com> References: <23313.1441739306@turing-police.cc.vt.edu> <1441741576.143219.378115649.3634EE3A@webmail.messagingengine.com> <7B11BBC4-8B7B-49FD-B03C-0ACFCAB10263@delong.com> Message-ID: <1441824693.1143196.379124105.08AB7797@webmail.messagingengine.com> Granted that having the CPE request both a IA_NA and IA_PD is a more common configuration. Some of the CPEs using only DHCPv6 PD can allocate a /64 out of the delegated /48 for WAN address & management. The IPV6 traceroute is not broken with the DHCPv6 PD only configuration. On Wed, Sep 9, 2015, at 11:15 AM, Owen DeLong wrote: > Sure, but this is a useless savings that comes at the cost of awkward > traceroute output > that will initially confuse your new employees and consistently confuse > your customers. From octalnanog at alvarezp.org Wed Sep 9 18:56:56 2015 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Wed, 09 Sep 2015 11:56:56 -0700 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> Message-ID: <55F080F8.6030505@alvarezp.org> On 09/09/15 06:36, Dovid Bender wrote: > I am trying to understand why the legal babble bothers anyone. Does > it give you a nervous twitch? Remind you why you hate legal? It's > just text at the bottom of your email. I've seen it in multiple languages (not necessarily on this list). Furthermore, some mailing lists support HTML and when they send it in HTML it sends two copies. Some others even add a corporate image (sometimes mistakenly huge, sometimes small) to their signature. People do this a lot. If everybody did the same for all messages it would be a huge waste of bandwidth. For servers, because it's 1 byte times N subscriptions. For readers, because people should be able to read this in their mobile devices. For some this means access charges by byte. That's why it's frowned upon in mosts mailing lists and just directly forbidden in others. This is not new at all. Just my two cents. Best regards. From eric-list at truenet.com Wed Sep 9 19:00:57 2015 From: eric-list at truenet.com (eric-list at truenet.com) Date: Wed, 9 Sep 2015 15:00:57 -0400 Subject: outlook.com outgoing blacklists? In-Reply-To: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> Message-ID: <00e501d0eb31$dc820de0$958629a0$@truenet.com> The only example I could come up with is an IDN, which Todd already said wasn't the case. At least I know Unicode domains didn't work on Exchange 2013 OWA, but worked when changed to ASCII. It may have changed by now though. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Atkins Sent: Wednesday, September 09, 2015 2:44 PM To: nanog list Subject: Re: outlook.com outgoing blacklists? > > Anybody have some recommendations on how I resolve this The most likely explanation is a configuration error at your end, so the first step is to share what the domain is. Cheers, Steve From steve at blighty.com Wed Sep 9 19:09:45 2015 From: steve at blighty.com (Steve Atkins) Date: Wed, 9 Sep 2015 12:09:45 -0700 Subject: outlook.com outgoing blacklists? In-Reply-To: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> Message-ID: > On Sep 9, 2015, at 11:43 AM, Steve Atkins wrote: > > >> >> Anybody have some recommendations on how I resolve this > > The most likely explanation is a configuration error at your end, so the first step is to share what the domain is. Todd shared the domain with me privately. The DNS configuration (and SMTP and TLS) looks fine, with nothing out of the ordinary, to me too. So the next thing to look at would be the rejection message. Cheers, Steve From tgrand at tgrand.com Wed Sep 9 19:09:52 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Wed, 9 Sep 2015 14:09:52 -0500 Subject: outlook.com outgoing blacklists? In-Reply-To: <00e501d0eb31$dc820de0$958629a0$@truenet.com> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <00e501d0eb31$dc820de0$958629a0$@truenet.com> Message-ID: Almost seems like something corrupt at Outlook/Hotmail or a blacklist of some type. -----Original Message----- From: eric-list at truenet.com Sent: Wednesday, September 9, 2015 2:00 PM To: 'nanog list' Subject: RE: outlook.com outgoing blacklists? The only example I could come up with is an IDN, which Todd already said wasn't the case. At least I know Unicode domains didn't work on Exchange 2013 OWA, but worked when changed to ASCII. It may have changed by now though. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Atkins Sent: Wednesday, September 09, 2015 2:44 PM To: nanog list Subject: Re: outlook.com outgoing blacklists? > > Anybody have some recommendations on how I resolve this The most likely explanation is a configuration error at your end, so the first step is to share what the domain is. Cheers, Steve From mjwise at kapu.net Wed Sep 9 19:14:43 2015 From: mjwise at kapu.net (Michael J Wise) Date: Wed, 9 Sep 2015 12:14:43 -0700 Subject: outlook.com outgoing blacklists? In-Reply-To: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> Message-ID: <9e194ff8cabcbfb42c0fda4faeb96de6.squirrel@secure.kapu.net> >> Anybody have some recommendations on how I resolve this > > The most likely explanation is a configuration error at your end, so the > first step is to share what the domain is. That's the 0th Step, actually. If people are going to ask for help, *PLEASE* provide us enough details to be able to guess without consulting Carnak the Magnificent to figure out what the actual details might be. :( Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause. From tgrand at tgrand.com Wed Sep 9 19:19:41 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Wed, 9 Sep 2015 14:19:41 -0500 Subject: outlook.com outgoing blacklists? In-Reply-To: References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> Message-ID: <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> Content-Type: message/delivery-status Reporting-MTA: dns;COL004-OMC2S2.hotmail.com Received-From-MTA: dns;COL129-W41 Arrival-Date: Wed, 9 Sep 2015 02:13:28 -0700 Final-Recipient: rfc822;support at qkstream.com Action: failed Status: 5.5.0 Diagnostic-Code: smtp;554 The mail could not be delivered to the recipient because the domain is not reachable. Please check the domain and try again (-744508417:308:-2147467259) Keep in mind that the address has a failed status even before sending on outlook.com webmail site. -----Original Message----- From: Steve Atkins Sent: Wednesday, September 9, 2015 2:09 PM To: nanog list Subject: Re: outlook.com outgoing blacklists? > On Sep 9, 2015, at 11:43 AM, Steve Atkins wrote: > > >> >> Anybody have some recommendations on how I resolve this > > The most likely explanation is a configuration error at your end, so the > first step is to share what the domain is. Todd shared the domain with me privately. The DNS configuration (and SMTP and TLS) looks fine, with nothing out of the ordinary, to me too. So the next thing to look at would be the rejection message. Cheers, Steve= From tgrand at tgrand.com Wed Sep 9 19:24:12 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Wed, 9 Sep 2015 14:24:12 -0500 Subject: outlook.com outgoing blacklists? In-Reply-To: <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> Message-ID: another email domain hosted on the same server is tgrand at tgrand.com. Hotmail/Outlook can send fine to this domain. -----Original Message----- From: Todd K Grand Sent: Wednesday, September 9, 2015 2:19 PM To: Steve Atkins ; nanog list Subject: Re: outlook.com outgoing blacklists? Content-Type: message/delivery-status Reporting-MTA: dns;COL004-OMC2S2.hotmail.com Received-From-MTA: dns;COL129-W41 Arrival-Date: Wed, 9 Sep 2015 02:13:28 -0700 Final-Recipient: rfc822;support at qkstream.com Action: failed Status: 5.5.0 Diagnostic-Code: smtp;554 The mail could not be delivered to the recipient because the domain is not reachable. Please check the domain and try again (-744508417:308:-2147467259) Keep in mind that the address has a failed status even before sending on outlook.com webmail site. -----Original Message----- From: Steve Atkins Sent: Wednesday, September 9, 2015 2:09 PM To: nanog list Subject: Re: outlook.com outgoing blacklists? > On Sep 9, 2015, at 11:43 AM, Steve Atkins wrote: > > >> >> Anybody have some recommendations on how I resolve this > > The most likely explanation is a configuration error at your end, so the > first step is to share what the domain is. Todd shared the domain with me privately. The DNS configuration (and SMTP and TLS) looks fine, with nothing out of the ordinary, to me too. So the next thing to look at would be the rejection message. Cheers, Steve= From tom at ninjabadger.net Wed Sep 9 19:45:24 2015 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 9 Sep 2015 20:45:24 +0100 Subject: Software Defined Networking In-Reply-To: References: <55E83752.8020206@foobar.org> <20150903143638.GA7591@panix.com> <20150903181313.GA16116@panix.com> <7A74991F-1204-4CE7-9AB0-66B9F2A281AD@egon.cc> <55EDFE3E.6050509@foobar.org> Message-ID: <55F08C54.3020100@ninjabadger.net> On 09/09/15 11:51, Bevan Slattery wrote: > Yes. Usually Automation/Orchestration and allowing the customer to manage > their own network requirements in real-time through a portal/iPhone etc? "But, where does this OpenFlow stuff fit into that?" Ad infinitum. -- Tom From tgrand at tgrand.com Wed Sep 9 19:51:07 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Wed, 9 Sep 2015 14:51:07 -0500 Subject: outlook.com outgoing blacklists? In-Reply-To: <20150909193846.GA31248@li92-81.konadogs.net> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> <20150909193846.GA31248@li92-81.konadogs.net> Message-ID: When I send from outlook.com to qkstream.com packets never arrive from microsofts outbound ip addresses. Yet I can see the packets fine if I send from outlook.com to tgrand.com -----Original Message----- From: Nate Itkin Sent: Wednesday, September 9, 2015 2:38 PM To: Todd K Grand Subject: Re: outlook.com outgoing blacklists? Server response to rcpt to: was a little slow. Maybe LookOut.com has a very short timeout? You might want to fire-up tcpdump on your end and see what transpires when you try to send from LookOut.com. On Wed, Sep 09, 2015 at 02:24:12PM -0500, Todd K Grand wrote: > another email domain hosted on the same server is tgrand at tgrand.com. > Hotmail/Outlook can send fine to this domain. > > -----Original Message----- From: Todd K Grand > Sent: Wednesday, September 9, 2015 2:19 PM > To: Steve Atkins ; nanog list > Subject: Re: outlook.com outgoing blacklists? > > Content-Type: message/delivery-status > > Reporting-MTA: dns;COL004-OMC2S2.hotmail.com > Received-From-MTA: dns;COL129-W41 > Arrival-Date: Wed, 9 Sep 2015 02:13:28 -0700 > > Final-Recipient: rfc822;support at qkstream.com > Action: failed > Status: 5.5.0 > Diagnostic-Code: smtp;554 The mail could not be delivered to the recipient > because the domain is not reachable. Please check the domain and try again > (-744508417:308:-2147467259) > > > Keep in mind that the address has a failed status even before sending on > outlook.com webmail site. > > > -----Original Message----- From: Steve Atkins > Sent: Wednesday, September 9, 2015 2:09 PM > To: nanog list > Subject: Re: outlook.com outgoing blacklists? > > > >On Sep 9, 2015, at 11:43 AM, Steve Atkins wrote: > > > > > >> > >>Anybody have some recommendations on how I resolve this > > > >The most likely explanation is a configuration error at your end, > >so the first step is to share what the domain is. > > Todd shared the domain with me privately. > > The DNS configuration (and SMTP and TLS) looks fine, with nothing out of > the > ordinary, to me too. > > So the next thing to look at would be the rejection message. > > Cheers, > Steve= From streiner at cluebyfour.org Wed Sep 9 20:10:54 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 9 Sep 2015 16:10:54 -0400 (EDT) Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> Message-ID: On Wed, 9 Sep 2015, Dovid Bender wrote: > I am trying to understand why the legal babble bothers anyone. Does it > give you a nervous twitch? Remind you why you hate legal? It's just text > at the bottom of your email. I can see both sides of this: 1. People who post to this list from a work email address often have no control over what their employer appends to the end of their outgoing emails. The footers in question are usually added after the fact because someone in a position of authority at $employer says it needs to be there. 2. A half-page of legalese boilerplate following a one-line message on a mailing list that goes out to many thousands of people can be a bit irritating. The compromise would seem to be to use a third-party email account for subscribing to mailing lists, but there could be environments where that doesn't fly with those same people in positions of authority... jms > -----Original Message----- > From: Larry Sheldon > Sender: "NANOG" Date: Tue, 8 Sep 2015 03:56:30 > To: > Subject: Re: Extraneous "legal" babble--and my reaction to it. > > On 9/8/2015 03:31, Rich Kulawiec wrote: >> On Sun, Sep 06, 2015 at 09:14:02PM +0000, Connor Wilkins wrote: >>> Honestly.. the best method is to not let it bug you anymore. It's >>> only a seething issue to you because you let it be. >> >> Curiously enough, the same thing was said about spam 30-ish years ago. >> The "ignore it and maybe it will go away" approach did not yield >> satisfactory results. >> >> These "disclaimers" are stupid and abusive. They have no place in >> *any* email traffic, and most certainly not in a professional forum. >> And it is unreasonable to expect the recipients of the demands and >> threats they embody to silently tolerate them ad infinitum. > > Exactly so. > JHD > > > -- > sed quis custodiet ipsos custodes? (Juvenal) > From don at bowenvale.co.nz Wed Sep 9 21:24:56 2015 From: don at bowenvale.co.nz (Don Gould) Date: Thu, 10 Sep 2015 09:24:56 +1200 Subject: Capital Internet http://www.capitalinternet.com/ down? Message-ID: <55F0A3A8.1040300@bowenvale.co.nz> One of my providers seems to be off line currently. Phones and DNS has vanished too. Does anyone know anything? D Capital Internet http://www.capitalinternet.com/ 200 Sandy Springs Place Northeast Atlanta, GA 30328 Company phone: +1.404.531.0080 Company fax: +1.404.303.1945 -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 Ph: +61 3 9111 1821 (Melb) I'M COLLECTING COFFEE CUPS FOR PROJECT COFFEE CUP. Deja vue (missing the French accent mark) - literally means already seen, that sense of haven't we been here before. From morrowc.lists at gmail.com Wed Sep 9 21:34:15 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 9 Sep 2015 17:34:15 -0400 Subject: Capital Internet http://www.capitalinternet.com/ down? In-Reply-To: <55F0A3A8.1040300@bowenvale.co.nz> References: <55F0A3A8.1040300@bowenvale.co.nz> Message-ID: looks like their internet is broken, perhaps time for them to turn it off and on again? (ripe stat shows it's been down since 1600 UTC 9/9/2015, Sept 9th 2015 for my european friends) On Wed, Sep 9, 2015 at 5:24 PM, Don Gould wrote: > One of my providers seems to be off line currently. > > Phones and DNS has vanished too. > > Does anyone know anything? > > D > > Capital Internet http://www.capitalinternet.com/ > 200 Sandy Springs Place Northeast > Atlanta, GA 30328 > Company phone: +1.404.531.0080 > Company fax: +1.404.303.1945 > > -- > Don Gould > 31 Acheson Ave > Mairehau > Christchurch, New Zealand > Ph: + 64 3 348 7235 > Mobile: + 64 21 114 0699 > Ph: +61 3 9111 1821 (Melb) > > I'M COLLECTING COFFEE CUPS FOR PROJECT COFFEE CUP. > > Deja vue (missing the French accent mark) - literally means already seen, > that sense of haven't we been here before. > From rwebb at ropeguru.com Wed Sep 9 21:36:34 2015 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 09 Sep 2015 17:36:34 -0400 Subject: Capital Internet http://www.capitalinternet.com/ down? In-Reply-To: <55F0A3A8.1040300@bowenvale.co.nz> References: <55F0A3A8.1040300@bowenvale.co.nz> Message-ID: downforeveryoneorjustme.com says it is down for them too On Thu, 10 Sep 2015 09:24:56 +1200 Don Gould wrote: > One of my providers seems to be off line currently. > > Phones and DNS has vanished too. > > Does anyone know anything? > > D > > Capital Internet http://www.capitalinternet.com/ > 200 Sandy Springs Place Northeast > Atlanta, GA 30328 > Company phone: +1.404.531.0080 > Company fax: +1.404.303.1945 > > -- > Don Gould > 31 Acheson Ave > Mairehau > Christchurch, New Zealand > Ph: + 64 3 348 7235 > Mobile: + 64 21 114 0699 > Ph: +61 3 9111 1821 (Melb) > > I'M COLLECTING COFFEE CUPS FOR PROJECT COFFEE CUP. > > Deja vue (missing the French accent mark) - literally means already >seen, that sense of haven't we been here before. > From wwaites at tardis.ed.ac.uk Wed Sep 9 21:43:02 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Wed, 09 Sep 2015 22:43:02 +0100 (BST) Subject: Capital Internet http://www.capitalinternet.com/ down? In-Reply-To: <55F0A3A8.1040300@bowenvale.co.nz> References: <55F0A3A8.1040300@bowenvale.co.nz> Message-ID: <20150909.224302.1494720341961677407.wwaites@tardis.ed.ac.uk> Near as I can tell, the network that your nameservers are in, 68.168.144.0/20 is being correctly announced by AS21560 which is "Netstream Communications". I see this announcement here. A traceroute goes as far as, 13 te0-3-1-7.agr22.atl01.atlas.cogentco.com (154.54.47.190) 97.933 ms te0-3-1-7.agr21.atl01.atlas.cogentco.com (154.54.30.94) 114.202 ms be2149.ccr42.jfk02.atlas.cogentco.com (154.54.31.126) 93.931 ms 14 be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158) 100.736 ms te0-0-2-0.nr11.b000173-2.atl01.atlas.cogentco.com (154.24.14.118) 100.019 ms be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158) 100.691 ms 15 te0-4-1-7.agr21.atl01.atlas.cogentco.com (154.54.44.178) 101.480 ms te0-3-1-7.agr22.atl01.atlas.cogentco.com (154.54.47.190) 101.860 ms 38.88.191.250 (38.88.191.250) 99.150 ms 16 te0-0-2-3.nr11.b000173-2.atl01.atlas.cogentco.com (154.24.15.10) 102.828 ms looks like something within Netstream or between them and Cogent. Also both your nameservers seem to be right beside each other in the same netblock -- that's not really the best idea for just this sort of reason. It'd be a good idea to have secondary nameservers somewhere else (Esgob do free secondary anycast DNS and they're nice folk). -w -- William Waites | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh https://hubs.net.uk/ | HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From don at bowenvale.co.nz Wed Sep 9 22:34:27 2015 From: don at bowenvale.co.nz (Don Gould) Date: Thu, 10 Sep 2015 10:34:27 +1200 Subject: Capital Internet http://www.capitalinternet.com/ down? In-Reply-To: <20150909.224302.1494720341961677407.wwaites@tardis.ed.ac.uk> References: <55F0A3A8.1040300@bowenvale.co.nz> <20150909.224302.1494720341961677407.wwaites@tardis.ed.ac.uk> Message-ID: <55F0B3F3.8060805@bowenvale.co.nz> Thanks William, Fibre cut then and they couldn't reannounce our ip ranges because of a lack of LOA. Learning here... more jobs on the ToDo list. As for our providers dns, phones, etc... yes. D On 10/09/2015 9:43 AM, William Waites wrote: > Near as I can tell, the network that your nameservers are in, > 68.168.144.0/20 is being correctly announced by AS21560 which is > "Netstream Communications". I see this announcement here. A traceroute > goes as far as, > > 13 te0-3-1-7.agr22.atl01.atlas.cogentco.com (154.54.47.190) 97.933 ms > te0-3-1-7.agr21.atl01.atlas.cogentco.com (154.54.30.94) 114.202 ms > be2149.ccr42.jfk02.atlas.cogentco.com (154.54.31.126) 93.931 ms > 14 be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158) 100.736 ms > te0-0-2-0.nr11.b000173-2.atl01.atlas.cogentco.com (154.24.14.118) 100.019 ms > be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158) 100.691 ms > 15 te0-4-1-7.agr21.atl01.atlas.cogentco.com (154.54.44.178) 101.480 ms > te0-3-1-7.agr22.atl01.atlas.cogentco.com (154.54.47.190) 101.860 ms > 38.88.191.250 (38.88.191.250) 99.150 ms > 16 te0-0-2-3.nr11.b000173-2.atl01.atlas.cogentco.com (154.24.15.10) 102.828 ms > > looks like something within Netstream or between them and Cogent. > > Also both your nameservers seem to be right beside each other in the > same netblock -- that's not really the best idea for just this > sort of reason. It'd be a good idea to have secondary nameservers > somewhere else (Esgob do free secondary anycast DNS and they're nice > folk). > > -w > > -- > William Waites | School of Informatics > http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh > https://hubs.net.uk/ | HUBS AS60241 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 Ph: +61 3 9111 1821 (Melb) I'M COLLECTING COFFEE CUPS FOR PROJECT COFFEE CUP. Deja vue (missing the French accent mark) - literally means already seen, that sense of haven't we been here before. From bill at herrin.us Wed Sep 9 23:16:43 2015 From: bill at herrin.us (William Herrin) Date: Wed, 9 Sep 2015 19:16:43 -0400 Subject: Capital Internet http://www.capitalinternet.com/ down? In-Reply-To: <55F0B3F3.8060805@bowenvale.co.nz> References: <55F0A3A8.1040300@bowenvale.co.nz> <20150909.224302.1494720341961677407.wwaites@tardis.ed.ac.uk> <55F0B3F3.8060805@bowenvale.co.nz> Message-ID: On Wed, Sep 9, 2015 at 6:34 PM, Don Gould wrote: > Fibre cut then and they couldn't reannounce our ip ranges because of a lack > of LOA. Which upstream gave them grief about an LOA during an emergency for a route they'd been announcing to another service provide and that overlapped no other routes then in the table? -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From johnl at iecc.com Thu Sep 10 00:41:29 2015 From: johnl at iecc.com (John Levine) Date: 10 Sep 2015 00:41:29 -0000 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: Message-ID: <20150910004129.53020.qmail@ary.lan> >If your employer insists on attaching a legalistic signature to your >email which warns the recipient that the message is for their eyes >only... it's because you are not authorized to make public statements >as an employee of the company. No, that's not it. A disclaimer "I don't speak for foocorp" is not at all the same as "you have to keep this super sekrit foocorp message confidential." The disclaimers tend to be much shorter and are somewhat reasonable, stating that this message does *not* constitute a contract. As explained at length, the confidentiality stuff purports to be a contract but is not. As I said it can be summarized as "I am stupid" or "I am controlled by stupid." Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From larrysheldon at cox.net Thu Sep 10 01:22:14 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 9 Sep 2015 20:22:14 -0500 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> Message-ID: <55F0DB46.5090204@cox.net> On 9/9/2015 08:36, Dovid Bender wrote: > I am trying to understand why the legal babble bothers anyone. Does > it give you a nervous twitch? Your disrespectful query is not really worthy of a answer because it is obviously not asked in good faith, but I am going to try to answer it it because there may be others who actually are interested in my answers. Remind you why you hate legal? That sentence does not make any sense to me. I don't hate much, certainly not "legal", what ever that might turn out to mean, It's > just text at the bottom of your email. That has been the answer of rogues and renegades to network messaging abuse since before there was an Internet. Now to try and answer "why does it bother me?" (There are already clues in what I have said above, but I am guessing that th4 OP is not into "clues" much.) I am old school and I still try, in an increasingly hostile world, to deal with electronic messages in the order of real time, with the oldest material at the top and the newest at the bottom. I am old school and still believe in not causing read-before-writes, not violating blocking-factor protocols, and not forcing people to pay for the transmission of bits they don't want, don't need, and did not ask for--especially if the bits are hostile and are carrying spam, viruses, trojans, or legal traps into which the receiver might innocently blunder. In the instant case it is this latter aspect that concerns me most as recipient--I did not ask for the message carrying it, I have no idea what about the message puts me at risk, and on and on through a number of arguments that others have covered well. I am old, unemployed, unemployable, in less than robust health, and I don't think I could survive being dragged into court because of something I did (or did not do) and I could not survive the expense of my defense and of the almost-certain adverse judgement the courts seem bound to hand down these days. And in the instant case (not always the case) the 11 1/2 word query struck me as ingenuous that would have been more appropriate in a high-school class*; and I looked elsewhere in the message to see if I could work out why somebody would ask that kind of a question in this kind of forum. *I am still undecided on that question. -- sed quis custodiet ipsos custodes? (Juvenal) From mvoity at uvm.edu Thu Sep 10 01:24:21 2015 From: mvoity at uvm.edu (Michael T. Voity) Date: Wed, 9 Sep 2015 21:24:21 -0400 Subject: WiFI on utility poles Message-ID: <7500FD8F-654B-4268-B033-F6128E7A9620@uvm.edu> Hello, Today another colleague and I discovered the famous 'xfinitywifi' ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University campus. After doing some poking around on campus we found these gems (attached picture) on 2 utility poles that pass by our east campus. Standing underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards away inside our hockey fieldhouse, through lots of brick, cinder blocks and metal, I was still picking the 2.4Ghz at -64. Looks like the unit is getting power from the coax. My question is, I've done a little poking around and have not found anything substantial to learn more information about this Comcast program. Any insight would be nice! Michael Voity University of Vermont -------------- next part -------------- From dovid at telecurve.com Thu Sep 10 01:33:14 2015 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 10 Sep 2015 01:33:14 +0000 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <55F0DB46.5090204@cox.net> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <55F0DB46.5090204@cox.net> Message-ID: <296487014-1441848794-cardhu_decombobulator_blackberry.rim.net-1460628386-@b13.c3.bise6.blackberry> So far what I have learned 1) It causes issues reading bottom up (which I never do, I always go top down to review the convo) but I can how it bothers others. 2) You don't want lawyers saying "we had a warning, you violated it now we sue". Understandable. Thanks for the explanation. Regards, Dovid -----Original Message----- From: Larry Sheldon Sender: "NANOG" Date: Wed, 9 Sep 2015 20:22:14 To: Subject: Re: Extraneous "legal" babble--and my reaction to it. On 9/9/2015 08:36, Dovid Bender wrote: > I am trying to understand why the legal babble bothers anyone. Does > it give you a nervous twitch? Your disrespectful query is not really worthy of a answer because it is obviously not asked in good faith, but I am going to try to answer it it because there may be others who actually are interested in my answers. Remind you why you hate legal? That sentence does not make any sense to me. I don't hate much, certainly not "legal", what ever that might turn out to mean, It's > just text at the bottom of your email. That has been the answer of rogues and renegades to network messaging abuse since before there was an Internet. Now to try and answer "why does it bother me?" (There are already clues in what I have said above, but I am guessing that th4 OP is not into "clues" much.) I am old school and I still try, in an increasingly hostile world, to deal with electronic messages in the order of real time, with the oldest material at the top and the newest at the bottom. I am old school and still believe in not causing read-before-writes, not violating blocking-factor protocols, and not forcing people to pay for the transmission of bits they don't want, don't need, and did not ask for--especially if the bits are hostile and are carrying spam, viruses, trojans, or legal traps into which the receiver might innocently blunder. In the instant case it is this latter aspect that concerns me most as recipient--I did not ask for the message carrying it, I have no idea what about the message puts me at risk, and on and on through a number of arguments that others have covered well. I am old, unemployed, unemployable, in less than robust health, and I don't think I could survive being dragged into court because of something I did (or did not do) and I could not survive the expense of my defense and of the almost-certain adverse judgement the courts seem bound to hand down these days. And in the instant case (not always the case) the 11 1/2 word query struck me as ingenuous that would have been more appropriate in a high-school class*; and I looked elsewhere in the message to see if I could work out why somebody would ask that kind of a question in this kind of forum. *I am still undecided on that question. -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Thu Sep 10 01:39:29 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 9 Sep 2015 20:39:29 -0500 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> Message-ID: <55F0DF51.4010708@cox.net> On 9/9/2015 20:22, Larry Sheldon wrote: I can not believe (except as, perhaps, an irrefutable sign of my advancing years) that I did not mention the very personal objection to the apparently content-free Wile E. Coyote legalese pollution: The irrefutable fact that in years (and administrations) past I was banned from NANOG for offenses that to me today seem more defensible and a great deal less egregious than in the instant case. -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Thu Sep 10 01:51:40 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 9 Sep 2015 20:51:40 -0500 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> Message-ID: <55F0E22C.4050206@cox.net> On 9/9/2015 10:23, Alan Buxey wrote: >> It's just text at the bottom of your email. > > 1 often a very large amount of text - in this case the legalese was > something like 10x longer than the comment! 2 its pointless. Its not > enforceable and doesn't mean anything. > > Shall i put a chapter of war and peace at the end of my emails? You > could just ignore it..... ;) I have been thinking that Lipsum Ipsum would be more in keeping with the spirit of uselessness here. -- sed quis custodiet ipsos custodes? (Juvenal) From mvoity at uvm.edu Thu Sep 10 01:52:35 2015 From: mvoity at uvm.edu (Michael T. Voity) Date: Wed, 9 Sep 2015 21:52:35 -0400 Subject: WiFI on utility poles In-Reply-To: <7500FD8F-654B-4268-B033-F6128E7A9620@uvm.edu> References: <7500FD8F-654B-4268-B033-F6128E7A9620@uvm.edu> Message-ID: <55F0E263.3060306@uvm.edu> Sorry folks, attachment didn't work. Here is the link - https://www.uvm.edu/~mvoity/pole.JPG -Mike Michael Voity University of Vermont On 9/9/15 9:24 PM, Michael T. Voity wrote: > Hello, > > Today another colleague and I discovered the famous 'xfinitywifi' ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University campus. After doing some poking around on campus we found these gems (attached picture) on 2 utility poles that pass by our east campus. Standing underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards away inside our hockey fieldhouse, through lots of brick, cinder blocks and metal, I was still picking the 2.4Ghz at -64. > > Looks like the unit is getting power from the coax. > > > My question is, I've done a little poking around and have not found anything substantial to learn more information about this Comcast program. > > > Any insight would be nice! > > > Michael Voity > University of Vermont > > > From bedard.phil at gmail.com Thu Sep 10 02:19:44 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 09 Sep 2015 22:19:44 -0400 Subject: WiFI on utility poles In-Reply-To: <55F0E263.3060306@uvm.edu> References: <7500FD8F-654B-4268-B033-F6128E7A9620@uvm.edu> <55F0E263.3060306@uvm.edu> Message-ID: There are Comcast people on the list who may have more info, but it?s just expansion of their WiFi hotspot network and part of the CableWifi consortium. http://www.cablewifi.com, or you can go to http://wifi.xfinity.com to see Comcast?s specific deployment. Cable companies have thousands of strand-mount Wifi APs deployed at this point. Phil -----Original Message----- From: NANOG on behalf of "Michael T. Voity" Organization: University of Vermont and State Agricultural College Date: Wednesday, September 9, 2015 at 21:52 To: Subject: Re: WiFI on utility poles >Sorry folks, attachment didn't work. Here is the link - > >https://www.uvm.edu/~mvoity/pole.JPG > >-Mike > >Michael Voity >University of Vermont > >On 9/9/15 9:24 PM, Michael T. Voity wrote: >> Hello, >> >> Today another colleague and I discovered the famous 'xfinitywifi' ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University campus. After doing some poking around on campus we found these gems (attached picture) on 2 utility poles that pass by our east campus. Standing underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards away inside our hockey fieldhouse, through lots of brick, cinder blocks and metal, I was still picking the 2.4Ghz at -64. >> >> Looks like the unit is getting power from the coax. >> >> >> My question is, I've done a little poking around and have not found anything substantial to learn more information about this Comcast program. >> >> >> Any insight would be nice! >> >> >> Michael Voity >> University of Vermont >> >> >> > From mike.lyon at gmail.com Thu Sep 10 02:23:46 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 9 Sep 2015 19:23:46 -0700 Subject: WiFI on utility poles In-Reply-To: References: <7500FD8F-654B-4268-B033-F6128E7A9620@uvm.edu> <55F0E263.3060306@uvm.edu> Message-ID: And they are as annoying as f*&k! and litter the already noisy 5 Ghz unlicensed band, Hopefully, the sun will fry them dead over time. -Mike On Wed, Sep 9, 2015 at 7:19 PM, Phil Bedard wrote: > There are Comcast people on the list who may have more info, but it?s just > expansion of their WiFi hotspot network and part of the CableWifi > consortium. http://www.cablewifi.com, or you can go to > http://wifi.xfinity.com to see Comcast?s specific deployment. > > Cable companies have thousands of strand-mount Wifi APs deployed at this > point. > > > Phil > > > > > -----Original Message----- > From: NANOG on behalf of "Michael T. Voity" > Organization: University of Vermont and State Agricultural College > Date: Wednesday, September 9, 2015 at 21:52 > To: > Subject: Re: WiFI on utility poles > > >Sorry folks, attachment didn't work. Here is the link - > > > >https://www.uvm.edu/~mvoity/pole.JPG > > > >-Mike > > > >Michael Voity > >University of Vermont > > > >On 9/9/15 9:24 PM, Michael T. Voity wrote: > >> Hello, > >> > >> Today another colleague and I discovered the famous 'xfinitywifi' > ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University campus. > After doing some poking around on campus we found these gems (attached > picture) on 2 utility poles that pass by our east campus. Standing > underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards > away inside our hockey fieldhouse, through lots of brick, cinder blocks > and metal, I was still picking the 2.4Ghz at -64. > >> > >> Looks like the unit is getting power from the coax. > >> > >> > >> My question is, I've done a little poking around and have not found > anything substantial to learn more information about this Comcast program. > >> > >> > >> Any insight would be nice! > >> > >> > >> Michael Voity > >> University of Vermont > >> > >> > >> > > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From nanog at ics-il.net Thu Sep 10 02:31:34 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 9 Sep 2015 21:31:34 -0500 (CDT) Subject: WiFI on utility poles In-Reply-To: Message-ID: <81607315.3865.1441852340120.JavaMail.mhammett@ThunderFuck> Usually terribly placed, like a shotgun blast instead of strategic locations. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mike Lyon" To: "Phil Bedard" Cc: "NANOG" Sent: Wednesday, September 9, 2015 9:23:46 PM Subject: Re: WiFI on utility poles And they are as annoying as f*&k! and litter the already noisy 5 Ghz unlicensed band, Hopefully, the sun will fry them dead over time. -Mike On Wed, Sep 9, 2015 at 7:19 PM, Phil Bedard wrote: > There are Comcast people on the list who may have more info, but it?s just > expansion of their WiFi hotspot network and part of the CableWifi > consortium. http://www.cablewifi.com, or you can go to > http://wifi.xfinity.com to see Comcast?s specific deployment. > > Cable companies have thousands of strand-mount Wifi APs deployed at this > point. > > > Phil > > > > > -----Original Message----- > From: NANOG on behalf of "Michael T. Voity" > Organization: University of Vermont and State Agricultural College > Date: Wednesday, September 9, 2015 at 21:52 > To: > Subject: Re: WiFI on utility poles > > >Sorry folks, attachment didn't work. Here is the link - > > > >https://www.uvm.edu/~mvoity/pole.JPG > > > >-Mike > > > >Michael Voity > >University of Vermont > > > >On 9/9/15 9:24 PM, Michael T. Voity wrote: > >> Hello, > >> > >> Today another colleague and I discovered the famous 'xfinitywifi' > ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University campus. > After doing some poking around on campus we found these gems (attached > picture) on 2 utility poles that pass by our east campus. Standing > underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards > away inside our hockey fieldhouse, through lots of brick, cinder blocks > and metal, I was still picking the 2.4Ghz at -64. > >> > >> Looks like the unit is getting power from the coax. > >> > >> > >> My question is, I've done a little poking around and have not found > anything substantial to learn more information about this Comcast program. > >> > >> > >> Any insight would be nice! > >> > >> > >> Michael Voity > >> University of Vermont > >> > >> > >> > > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From johnl at iecc.com Thu Sep 10 04:13:50 2015 From: johnl at iecc.com (John Levine) Date: 10 Sep 2015 04:13:50 -0000 Subject: WiFI on utility poles In-Reply-To: Message-ID: <20150910041350.53547.qmail@ary.lan> In article you write: >And they are as annoying as f*&k! and litter the already noisy 5 Ghz >unlicensed band, Hopefully, the sun will fry them dead over time. The placement may be suboptimal, but free wifi away from home is nice. CableWifi really is a consortium, T-W customers can use Comcast's hotspots and vice versa. From tagno25 at gmail.com Thu Sep 10 05:09:39 2015 From: tagno25 at gmail.com (Philip Dorr) Date: Thu, 10 Sep 2015 00:09:39 -0500 Subject: WiFI on utility poles In-Reply-To: <20150910041350.53547.qmail@ary.lan> References: <20150910041350.53547.qmail@ary.lan> Message-ID: On Sep 9, 2015 11:15 PM, "John Levine" wrote: > > The placement may be suboptimal, but free wifi away from home is nice. > CableWifi really is a consortium, T-W customers can use Comcast's > hotspots and vice versa. > Suboptimal is an understatement. How they are placed around Kansas City, they are self interfering, unable to hear the clients, and in places that make no sense (outside of a rural house where the next house is a 1/2 mile away). I can usually see 5+ of them all on the same 5.8Ghz channel. From jpratt at norwich.edu Thu Sep 10 02:04:54 2015 From: jpratt at norwich.edu (James E. Pratt) Date: Thu, 10 Sep 2015 02:04:54 +0000 Subject: WiFI on utility poles In-Reply-To: <55F0E263.3060306@uvm.edu> References: <7500FD8F-654B-4268-B033-F6128E7A9620@uvm.edu> <55F0E263.3060306@uvm.edu> Message-ID: <591A34BAEC8DBF44AFAB2E127B4D8A8E137A95C0@NUEXCH2.norwich.edu> https://www.techdirt.com/articles/20141208/13222529362/comcast-sued-over-router-update-that-makes-your-wi-fi-hotspot-public-ignores-your-opt-out-preferences.shtml Regards, James -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael T. Voity Sent: Wednesday, September 9, 2015 9:53 PM To: nanog at nanog.org Subject: Re: WiFI on utility poles Sorry folks, attachment didn't work. Here is the link - https://www.uvm.edu/~mvoity/pole.JPG -Mike Michael Voity University of Vermont On 9/9/15 9:24 PM, Michael T. Voity wrote: > Hello, > > Today another colleague and I discovered the famous 'xfinitywifi' ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University campus. After doing some poking around on campus we found these gems (attached picture) on 2 utility poles that pass by our east campus. Standing underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards away inside our hockey fieldhouse, through lots of brick, cinder blocks and metal, I was still picking the 2.4Ghz at -64. > > Looks like the unit is getting power from the coax. > > > My question is, I've done a little poking around and have not found anything substantial to learn more information about this Comcast program. > > > Any insight would be nice! > > > Michael Voity > University of Vermont > > > From hf0002+nanog at uah.edu Thu Sep 10 02:20:11 2015 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Wed, 9 Sep 2015 21:20:11 -0500 Subject: WiFI on utility poles In-Reply-To: <55F0E263.3060306@uvm.edu> References: <7500FD8F-654B-4268-B033-F6128E7A9620@uvm.edu> <55F0E263.3060306@uvm.edu> Message-ID: Wow, it is like they are actively sabotaging us. Sigh... None of that in this area yet - I'm sure it's only a matter of time though. On Wed, Sep 9, 2015 at 8:52 PM, Michael T. Voity wrote: > Sorry folks, attachment didn't work. Here is the link - > > https://www.uvm.edu/~mvoity/pole.JPG > > -Mike > > Michael Voity > University of Vermont > > On 9/9/15 9:24 PM, Michael T. Voity wrote: >> >> Hello, >> >> Today another colleague and I discovered the famous 'xfinitywifi' >> ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University campus. >> After doing some poking around on campus we found these gems (attached >> picture) on 2 utility poles that pass by our east campus. Standing >> underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards away >> inside our hockey fieldhouse, through lots of brick, cinder blocks and >> metal, I was still picking the 2.4Ghz at -64. >> >> Looks like the unit is getting power from the coax. >> >> >> My question is, I've done a little poking around and have not found >> anything substantial to learn more information about this Comcast program. >> >> >> Any insight would be nice! >> >> >> Michael Voity >> University of Vermont >> >> >> > From Jason_Livingood at cable.comcast.com Thu Sep 10 12:53:22 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 10 Sep 2015 12:53:22 +0000 Subject: WiFI on utility poles In-Reply-To: <55F0E263.3060306@uvm.edu> References: <7500FD8F-654B-4268-B033-F6128E7A9620@uvm.edu> <55F0E263.3060306@uvm.edu> Message-ID: You can learn more at http://wifi.xfinity.com/. There are more than 8M hotspots around the country today and we're doing more and more outdoor / public area WiFi hotspots. In my area (Philadelphia) I hit them all along the route that my commuter train takes, so it's convenient. The XFINITY SSID is new and uses WPA2 IIRC. The guys copied (Ken and Corey) are good contacts for any direct questions about Comcast's WiFi network. As an aside, it does not look like UVM is covered yet but we expanded our free college streaming service this Fall and on campuses that have Xfinity WiFi, it would presumably help students stream from more places (see http://corporate.comcast.com/comcast-voices/xfinity-on-campus-expands-comcast-now-brings-streaming-tv-to-24-colleges-and-universities). - Jason Comcast On 9/9/15, 9:52 PM, "NANOG on behalf of Michael T. Voity" on behalf of mvoity at uvm.edu> wrote: Sorry folks, attachment didn't work. Here is the link - https://www.uvm.edu/~mvoity/pole.JPG -Mike Michael Voity University of Vermont On 9/9/15 9:24 PM, Michael T. Voity wrote: Hello, Today another colleague and I discovered the famous 'xfinitywifi' ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University campus. After doing some poking around on campus we found these gems (attached picture) on 2 utility poles that pass by our east campus. Standing underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards away inside our hockey fieldhouse, through lots of brick, cinder blocks and metal, I was still picking the 2.4Ghz at -64. Looks like the unit is getting power from the coax. My question is, I've done a little poking around and have not found anything substantial to learn more information about this Comcast program. Any insight would be nice! Michael Voity University of Vermont From Jason_Livingood at cable.comcast.com Thu Sep 10 12:54:56 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 10 Sep 2015 12:54:56 +0000 Subject: WiFI on utility poles In-Reply-To: References: <7500FD8F-654B-4268-B033-F6128E7A9620@uvm.edu> <55F0E263.3060306@uvm.edu> Message-ID: Sabotaging how? - Jason On 9/9/15, 10:20 PM, "NANOG on behalf of Hunter Fuller" wrote: >Wow, it is like they are actively sabotaging us. Sigh... > >None of that in this area yet - I'm sure it's only a matter of time >though. > >On Wed, Sep 9, 2015 at 8:52 PM, Michael T. Voity wrote: >> Sorry folks, attachment didn't work. Here is the link - >> >> https://www.uvm.edu/~mvoity/pole.JPG >> >> -Mike >> >> Michael Voity >> University of Vermont >> >> On 9/9/15 9:24 PM, Michael T. Voity wrote: >>> >>> Hello, >>> >>> Today another colleague and I discovered the famous 'xfinitywifi' >>> ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University >>>campus. >>> After doing some poking around on campus we found these gems (attached >>> picture) on 2 utility poles that pass by our east campus. Standing >>> underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 >>>yards away >>> inside our hockey fieldhouse, through lots of brick, cinder blocks and >>> metal, I was still picking the 2.4Ghz at -64. >>> >>> Looks like the unit is getting power from the coax. >>> >>> >>> My question is, I've done a little poking around and have not found >>> anything substantial to learn more information about this Comcast >>>program. >>> >>> >>> Any insight would be nice! >>> >>> >>> Michael Voity >>> University of Vermont >>> >>> >>> >> > From Jason_Livingood at cable.comcast.com Thu Sep 10 12:56:37 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 10 Sep 2015 12:56:37 +0000 Subject: WiFI on utility poles In-Reply-To: <81607315.3865.1441852340120.JavaMail.mhammett@ThunderFuck> References: <81607315.3865.1441852340120.JavaMail.mhammett@ThunderFuck> Message-ID: If you run across any you think are terribly placed, feel free to email Corey and Ken with the location and your thoughts on better placement. - Jason On 9/9/15, 10:31 PM, "NANOG on behalf of Mike Hammett" wrote: >Usually terribly placed, like a shotgun blast instead of strategic >locations. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > > > >Midwest Internet Exchange >http://www.midwest-ix.com > > >----- Original Message ----- > >From: "Mike Lyon" >To: "Phil Bedard" >Cc: "NANOG" >Sent: Wednesday, September 9, 2015 9:23:46 PM >Subject: Re: WiFI on utility poles > >And they are as annoying as f*&k! and litter the already noisy 5 Ghz >unlicensed band, Hopefully, the sun will fry them dead over time. > >-Mike > > >On Wed, Sep 9, 2015 at 7:19 PM, Phil Bedard >wrote: > >> There are Comcast people on the list who may have more info, but it?s >>just >> expansion of their WiFi hotspot network and part of the CableWifi >> consortium. http://www.cablewifi.com, or you can go to >> http://wifi.xfinity.com to see Comcast?s specific deployment. >> >> Cable companies have thousands of strand-mount Wifi APs deployed at >>this >> point. >> >> >> Phil >> >> >> >> >> -----Original Message----- >> From: NANOG on behalf of "Michael T. Voity" >> Organization: University of Vermont and State Agricultural College >> Date: Wednesday, September 9, 2015 at 21:52 >> To: >> Subject: Re: WiFI on utility poles >> >> >Sorry folks, attachment didn't work. Here is the link - >> > >> >https://www.uvm.edu/~mvoity/pole.JPG >> > >> >-Mike >> > >> >Michael Voity >> >University of Vermont >> > >> >On 9/9/15 9:24 PM, Michael T. Voity wrote: >> >> Hello, >> >> >> >> Today another colleague and I discovered the famous 'xfinitywifi' >> ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University >>campus. >> After doing some poking around on campus we found these gems (attached >> picture) on 2 utility poles that pass by our east campus. Standing >> underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards >> away inside our hockey fieldhouse, through lots of brick, cinder blocks >> and metal, I was still picking the 2.4Ghz at -64. >> >> >> >> Looks like the unit is getting power from the coax. >> >> >> >> >> >> My question is, I've done a little poking around and have not found >> anything substantial to learn more information about this Comcast >>program. >> >> >> >> >> >> Any insight would be nice! >> >> >> >> >> >> Michael Voity >> >> University of Vermont >> >> >> >> >> >> >> > >> >> > > >-- >Mike Lyon >408-621-4826 >mike.lyon at gmail.com > >http://www.linkedin.com/in/mlyon > > From nanog at ics-il.net Thu Sep 10 13:00:08 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 10 Sep 2015 08:00:08 -0500 (CDT) Subject: WiFI on utility poles In-Reply-To: Message-ID: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> 5 GHz noise levels affecting people whose primary means of Internet access is via fixed wireless . ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jason Livingood" To: "Hunter Fuller" Cc: "Corey Petrulich" , "Kenneth Falkenstein" , nanog at nanog.org Sent: Thursday, September 10, 2015 7:54:56 AM Subject: Re: WiFI on utility poles Sabotaging how? - Jason On 9/9/15, 10:20 PM, "NANOG on behalf of Hunter Fuller" wrote: >Wow, it is like they are actively sabotaging us. Sigh... > >None of that in this area yet - I'm sure it's only a matter of time >though. > >On Wed, Sep 9, 2015 at 8:52 PM, Michael T. Voity wrote: >> Sorry folks, attachment didn't work. Here is the link - >> >> https://www.uvm.edu/~mvoity/pole.JPG >> >> -Mike >> >> Michael Voity >> University of Vermont >> >> On 9/9/15 9:24 PM, Michael T. Voity wrote: >>> >>> Hello, >>> >>> Today another colleague and I discovered the famous 'xfinitywifi' >>> ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University >>>campus. >>> After doing some poking around on campus we found these gems (attached >>> picture) on 2 utility poles that pass by our east campus. Standing >>> underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 >>>yards away >>> inside our hockey fieldhouse, through lots of brick, cinder blocks and >>> metal, I was still picking the 2.4Ghz at -64. >>> >>> Looks like the unit is getting power from the coax. >>> >>> >>> My question is, I've done a little poking around and have not found >>> anything substantial to learn more information about this Comcast >>>program. >>> >>> >>> Any insight would be nice! >>> >>> >>> Michael Voity >>> University of Vermont >>> >>> >>> >> > From shane at ronan-online.com Thu Sep 10 13:09:09 2015 From: shane at ronan-online.com (Shane Ronan) Date: Thu, 10 Sep 2015 09:09:09 -0400 Subject: WiFI on utility poles In-Reply-To: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> References: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> Message-ID: And how do you propose we solve this? On Sep 10, 2015 9:06 AM, "Mike Hammett" wrote: > 5 GHz noise levels affecting people whose primary means of Internet access > is via fixed wireless . > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Jason Livingood" > To: "Hunter Fuller" > Cc: "Corey Petrulich" , "Kenneth > Falkenstein" , nanog at nanog.org > Sent: Thursday, September 10, 2015 7:54:56 AM > Subject: Re: WiFI on utility poles > > Sabotaging how? > > - Jason > > > > > On 9/9/15, 10:20 PM, "NANOG on behalf of Hunter Fuller" > wrote: > > >Wow, it is like they are actively sabotaging us. Sigh... > > > >None of that in this area yet - I'm sure it's only a matter of time > >though. > > > >On Wed, Sep 9, 2015 at 8:52 PM, Michael T. Voity wrote: > >> Sorry folks, attachment didn't work. Here is the link - > >> > >> https://www.uvm.edu/~mvoity/pole.JPG > >> > >> -Mike > >> > >> Michael Voity > >> University of Vermont > >> > >> On 9/9/15 9:24 PM, Michael T. Voity wrote: > >>> > >>> Hello, > >>> > >>> Today another colleague and I discovered the famous 'xfinitywifi' > >>> ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University > >>>campus. > >>> After doing some poking around on campus we found these gems (attached > >>> picture) on 2 utility poles that pass by our east campus. Standing > >>> underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 > >>>yards away > >>> inside our hockey fieldhouse, through lots of brick, cinder blocks and > >>> metal, I was still picking the 2.4Ghz at -64. > >>> > >>> Looks like the unit is getting power from the coax. > >>> > >>> > >>> My question is, I've done a little poking around and have not found > >>> anything substantial to learn more information about this Comcast > >>>program. > >>> > >>> > >>> Any insight would be nice! > >>> > >>> > >>> Michael Voity > >>> University of Vermont > >>> > >>> > >>> > >> > > > > > From mhoppes at indigowireless.com Thu Sep 10 13:12:59 2015 From: mhoppes at indigowireless.com (Matt Hoppes) Date: Thu, 10 Sep 2015 09:12:59 -0400 Subject: WiFI on utility poles In-Reply-To: References: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> Message-ID: <55F181DB.5090503@indigowireless.com> Use 2GHz instead of 5GHz for the outdoor WiFi plants? On 9/10/15 9:09 AM, Shane Ronan wrote: > And how do you propose we solve this? > On Sep 10, 2015 9:06 AM, "Mike Hammett" wrote: > >> 5 GHz noise levels affecting people whose primary means of Internet access >> is via fixed wireless . >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> >> ----- Original Message ----- >> >> From: "Jason Livingood" >> To: "Hunter Fuller" >> Cc: "Corey Petrulich" , "Kenneth >> Falkenstein" , nanog at nanog.org >> Sent: Thursday, September 10, 2015 7:54:56 AM >> Subject: Re: WiFI on utility poles >> >> Sabotaging how? >> >> - Jason >> >> >> >> >> On 9/9/15, 10:20 PM, "NANOG on behalf of Hunter Fuller" >> wrote: >> >>> Wow, it is like they are actively sabotaging us. Sigh... >>> >>> None of that in this area yet - I'm sure it's only a matter of time >>> though. >>> >>> On Wed, Sep 9, 2015 at 8:52 PM, Michael T. Voity wrote: >>>> Sorry folks, attachment didn't work. Here is the link - >>>> >>>> https://www.uvm.edu/~mvoity/pole.JPG >>>> >>>> -Mike >>>> >>>> Michael Voity >>>> University of Vermont >>>> >>>> On 9/9/15 9:24 PM, Michael T. Voity wrote: >>>>> >>>>> Hello, >>>>> >>>>> Today another colleague and I discovered the famous 'xfinitywifi' >>>>> ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University >>>>> campus. >>>>> After doing some poking around on campus we found these gems (attached >>>>> picture) on 2 utility poles that pass by our east campus. Standing >>>>> underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 >>>>> yards away >>>>> inside our hockey fieldhouse, through lots of brick, cinder blocks and >>>>> metal, I was still picking the 2.4Ghz at -64. >>>>> >>>>> Looks like the unit is getting power from the coax. >>>>> >>>>> >>>>> My question is, I've done a little poking around and have not found >>>>> anything substantial to learn more information about this Comcast >>>>> program. >>>>> >>>>> >>>>> Any insight would be nice! >>>>> >>>>> >>>>> Michael Voity >>>>> University of Vermont >>>>> >>>>> >>>>> >>>> >>> >> >> >> From shane at ronan-online.com Thu Sep 10 13:15:37 2015 From: shane at ronan-online.com (Shane Ronan) Date: Thu, 10 Sep 2015 09:15:37 -0400 Subject: WiFI on utility poles In-Reply-To: <55F181DB.5090503@indigowireless.com> References: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> <55F181DB.5090503@indigowireless.com> Message-ID: So we should limit our public use of the 5ghz spectrum so that others can use it? How about we use licensed spectrum for fixed wireless services. On Sep 10, 2015 9:13 AM, "Matt Hoppes" wrote: > Use 2GHz instead of 5GHz for the outdoor WiFi plants? > > On 9/10/15 9:09 AM, Shane Ronan wrote: > >> And how do you propose we solve this? >> On Sep 10, 2015 9:06 AM, "Mike Hammett" wrote: >> >> 5 GHz noise levels affecting people whose primary means of Internet access >>> is via fixed wireless . >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> Midwest Internet Exchange >>> http://www.midwest-ix.com >>> >>> >>> ----- Original Message ----- >>> >>> From: "Jason Livingood" >>> To: "Hunter Fuller" >>> Cc: "Corey Petrulich" , "Kenneth >>> Falkenstein" , nanog at nanog.org >>> Sent: Thursday, September 10, 2015 7:54:56 AM >>> Subject: Re: WiFI on utility poles >>> >>> Sabotaging how? >>> >>> - Jason >>> >>> >>> >>> >>> On 9/9/15, 10:20 PM, "NANOG on behalf of Hunter Fuller" >>> wrote: >>> >>> Wow, it is like they are actively sabotaging us. Sigh... >>>> >>>> None of that in this area yet - I'm sure it's only a matter of time >>>> though. >>>> >>>> On Wed, Sep 9, 2015 at 8:52 PM, Michael T. Voity >>>> wrote: >>>> >>>>> Sorry folks, attachment didn't work. Here is the link - >>>>> >>>>> https://www.uvm.edu/~mvoity/pole.JPG >>>>> >>>>> -Mike >>>>> >>>>> Michael Voity >>>>> University of Vermont >>>>> >>>>> On 9/9/15 9:24 PM, Michael T. Voity wrote: >>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> Today another colleague and I discovered the famous 'xfinitywifi' >>>>>> ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University >>>>>> campus. >>>>>> After doing some poking around on campus we found these gems (attached >>>>>> picture) on 2 utility poles that pass by our east campus. Standing >>>>>> underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 >>>>>> yards away >>>>>> inside our hockey fieldhouse, through lots of brick, cinder blocks and >>>>>> metal, I was still picking the 2.4Ghz at -64. >>>>>> >>>>>> Looks like the unit is getting power from the coax. >>>>>> >>>>>> >>>>>> My question is, I've done a little poking around and have not found >>>>>> anything substantial to learn more information about this Comcast >>>>>> program. >>>>>> >>>>>> >>>>>> Any insight would be nice! >>>>>> >>>>>> >>>>>> Michael Voity >>>>>> University of Vermont >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> From mpetach at netflight.com Thu Sep 10 13:19:44 2015 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 10 Sep 2015 06:19:44 -0700 Subject: outlook.com outgoing blacklists? In-Reply-To: References: Message-ID: On Wed, Sep 9, 2015 at 9:49 AM, Todd K Grand wrote: > I have an email server which hosts 3 domains. > I have reason to believe that microsoft maintains an outgoing blacklist and would like confirmation on this. > > I have had many a report that people on domains hosted on hotmail/outlook are getting messages bounced back stating that our server was unreachable. > This only happens for one of the three domains hosted on our server. > > I went to outlook.com and setup an account. > When I create a new message and enter the recipient at that affected domain, the address immediately turns red, and when I hover over it states that > the address may not be valid. > This happens without ever sending a packet to our servers. > The affected domain can send emails to hotmail/outlook accounts just fine. > > Anybody have some recommendations on how I resolve this, as Microsoft support seems to be under technical. > > Thanks, > > Todd K. Grand > Certainly looks to be broken to me: mpetach at hinotori:~> nslookup -q=any gkstream.com Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: gkstream.com Address: 185.53.179.7 gkstream.com nameserver = ns1.parkingcrew.net. gkstream.com text = "v=spf1 ip6:fd1b:212c:a5f9::/48 -all" gkstream.com nameserver = ns2.parkingcrew.net. gkstream.com origin = ns1.parkingcrew.net mail addr = hostmaster.gkstream.com serial = 1441890000 refresh = 28800 retry = 7200 expire = 604800 minimum = 86400 Authoritative answers can be found from: mpetach at hinotori:~> mpetach at hinotori:~> traceroute gkstream.com traceroute to gkstream.com (185.53.179.7), 64 hops max, 40 byte packets 1 ws1 (69.36.244.130) 1 ms 1 ms 1 ms 2 s0-0-0-2.core1.sjc.layer42.net (69.36.238.33) 4 ms 4 ms 4 ms 3 ge2-48.core1.sv1.layer42.net (65.50.198.5) 4 ms 4 ms 4 ms 4 te0-0-0-18.ccr21.sjc04.atlas.cogentco.com (38.104.141.145) 6 ms 41 ms 73 ms 5 be2015.ccr21.sfo01.atlas.cogentco.com (154.54.7.173) 47 ms (TOS=40!) 7 ms 7 ms 6 be2132.ccr21.mci01.atlas.cogentco.com (154.54.30.54) 57 ms 57 ms 57 ms 7 be2156.ccr41.ord01.atlas.cogentco.com (154.54.6.86) 57 ms 70 ms 57 ms 8 be2351.ccr21.cle04.atlas.cogentco.com (154.54.44.86) 75 ms 64 ms 67 ms 9 be2596.ccr21.yyz02.atlas.cogentco.com (154.54.31.54) 71 ms 71 ms 71 ms 10 be2090.ccr21.ymq02.atlas.cogentco.com (154.54.30.206) 84 ms 121 ms 161 ms 11 be2384.ccr21.lpl01.atlas.cogentco.com (154.54.44.138) 150 ms 150 ms 151 ms 12 be2182.ccr41.ams03.atlas.cogentco.com (154.54.77.245) 170 ms 170 ms 169 ms 13 be2261.ccr41.fra03.atlas.cogentco.com (154.54.37.30) 164 ms 164 ms 164 ms 14 be2228.ccr21.muc03.atlas.cogentco.com (154.54.38.50) 174 ms 174 ms 174 ms 15 te0-0-0-2.agr12.muc03.atlas.cogentco.com (154.54.56.222) 173 ms te0-0-0-2.agr11.muc03.atlas.cogentco.com (154.54.56.206) 191 ms te0-0-0-2.agr12.muc03.atlas.cogentco.com (154.54.56.222) 174 ms 16 154.25.8.26 (154.25.8.26) 170 ms 154.25.8.22 (154.25.8.22) 175 ms 154.25.8.26 (154.25.8.26) 170 ms 17 149.6.156.195 (149.6.156.195) 175 ms 149.6.156.202 (149.6.156.202) 173 ms 174 ms 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 *^C * 26 ^C mpetach at hinotori:~> mpetach at hinotori:~> telnet gkstream.com 25 Trying 185.53.179.7... telnet: Unable to connect to remote host: Connection timed out mpetach at hinotori:~> Matt From david at mailplus.nl Thu Sep 10 13:45:47 2015 From: david at mailplus.nl (David Hofstee) Date: Thu, 10 Sep 2015 15:45:47 +0200 Subject: outlook.com outgoing blacklists? In-Reply-To: References: Message-ID: <78C35D6C1A82D243B830523B4193CF5F9F483D9ACD@SBS1.blinker.local> Hi Matthew, I'm pretty sure your 'gkstream.com' is wrong and that he means qkstream.com (see https://www.robtex.com/en/advisory/ip/66/171/128/130/ ). That does not seem broken. I do wonder if this domain qkstream.com used to be squatted? David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Matthew Petach Verzonden: Thursday, September 10, 2015 3:20 PM Aan: Todd K Grand CC: nanog at nanog.org Onderwerp: Re: outlook.com outgoing blacklists? On Wed, Sep 9, 2015 at 9:49 AM, Todd K Grand wrote: > I have an email server which hosts 3 domains. > I have reason to believe that microsoft maintains an outgoing blacklist and would like confirmation on this. > > I have had many a report that people on domains hosted on hotmail/outlook are getting messages bounced back stating that our server was unreachable. > This only happens for one of the three domains hosted on our server. > > I went to outlook.com and setup an account. > When I create a new message and enter the recipient at that affected > domain, the address immediately turns red, and when I hover over it states that the address may not be valid. > This happens without ever sending a packet to our servers. > The affected domain can send emails to hotmail/outlook accounts just fine. > > Anybody have some recommendations on how I resolve this, as Microsoft support seems to be under technical. > > Thanks, > > Todd K. Grand > Certainly looks to be broken to me: mpetach at hinotori:~> nslookup -q=any gkstream.com Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: gkstream.com Address: 185.53.179.7 gkstream.com nameserver = ns1.parkingcrew.net. gkstream.com text = "v=spf1 ip6:fd1b:212c:a5f9::/48 -all" gkstream.com nameserver = ns2.parkingcrew.net. gkstream.com origin = ns1.parkingcrew.net mail addr = hostmaster.gkstream.com serial = 1441890000 refresh = 28800 retry = 7200 expire = 604800 minimum = 86400 Authoritative answers can be found from: mpetach at hinotori:~> mpetach at hinotori:~> traceroute gkstream.com traceroute to gkstream.com (185.53.179.7), 64 hops max, 40 byte packets 1 ws1 (69.36.244.130) 1 ms 1 ms 1 ms 2 s0-0-0-2.core1.sjc.layer42.net (69.36.238.33) 4 ms 4 ms 4 ms 3 ge2-48.core1.sv1.layer42.net (65.50.198.5) 4 ms 4 ms 4 ms 4 te0-0-0-18.ccr21.sjc04.atlas.cogentco.com (38.104.141.145) 6 ms 41 ms 73 ms 5 be2015.ccr21.sfo01.atlas.cogentco.com (154.54.7.173) 47 ms (TOS=40!) 7 ms 7 ms 6 be2132.ccr21.mci01.atlas.cogentco.com (154.54.30.54) 57 ms 57 ms 57 ms 7 be2156.ccr41.ord01.atlas.cogentco.com (154.54.6.86) 57 ms 70 ms 57 ms 8 be2351.ccr21.cle04.atlas.cogentco.com (154.54.44.86) 75 ms 64 ms 67 ms 9 be2596.ccr21.yyz02.atlas.cogentco.com (154.54.31.54) 71 ms 71 ms 71 ms 10 be2090.ccr21.ymq02.atlas.cogentco.com (154.54.30.206) 84 ms 121 ms 161 ms 11 be2384.ccr21.lpl01.atlas.cogentco.com (154.54.44.138) 150 ms 150 ms 151 ms 12 be2182.ccr41.ams03.atlas.cogentco.com (154.54.77.245) 170 ms 170 ms 169 ms 13 be2261.ccr41.fra03.atlas.cogentco.com (154.54.37.30) 164 ms 164 ms 164 ms 14 be2228.ccr21.muc03.atlas.cogentco.com (154.54.38.50) 174 ms 174 ms 174 ms 15 te0-0-0-2.agr12.muc03.atlas.cogentco.com (154.54.56.222) 173 ms te0-0-0-2.agr11.muc03.atlas.cogentco.com (154.54.56.206) 191 ms te0-0-0-2.agr12.muc03.atlas.cogentco.com (154.54.56.222) 174 ms 16 154.25.8.26 (154.25.8.26) 170 ms 154.25.8.22 (154.25.8.22) 175 ms 154.25.8.26 (154.25.8.26) 170 ms 17 149.6.156.195 (149.6.156.195) 175 ms 149.6.156.202 (149.6.156.202) 173 ms 174 ms 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 *^C * 26 ^C mpetach at hinotori:~> mpetach at hinotori:~> telnet gkstream.com 25 Trying 185.53.179.7... telnet: Unable to connect to remote host: Connection timed out mpetach at hinotori:~> Matt From Bryan at bryanfields.net Thu Sep 10 14:13:18 2015 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 10 Sep 2015 10:13:18 -0400 Subject: WiFI on utility poles In-Reply-To: <55F181DB.5090503@indigowireless.com> References: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> <55F181DB.5090503@indigowireless.com> Message-ID: <55F18FFE.8030708@bryanfields.net> On 9/10/15 9:12 AM, Matt Hoppes wrote: > Use 2GHz instead of 5GHz for the outdoor WiFi plants? It's come full circle! Stay out of 5.9 GHz and I'm happy :) I've seen some of the Part 15 links we have here lose SNR as the prevalence of 5.8 GHz radios grows. We've been moving a few links to the 3.3-3.5 GHz band where we can (and don't have to pay a climber). -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From dot at dotat.at Thu Sep 10 14:24:08 2015 From: dot at dotat.at (Tony Finch) Date: Thu, 10 Sep 2015 15:24:08 +0100 Subject: outlook.com outgoing blacklists? In-Reply-To: <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> Message-ID: Todd K Grand wrote: > Content-Type: message/delivery-status > > Reporting-MTA: dns;COL004-OMC2S2.hotmail.com > Received-From-MTA: dns;COL129-W41 > Arrival-Date: Wed, 9 Sep 2015 02:13:28 -0700 > > Final-Recipient: rfc822;support at qkstream.com > Action: failed > Status: 5.5.0 > Diagnostic-Code: smtp;554 The mail could not be delivered to the recipient because the domain is not reachable. Please check the domain and try again (-744508417:308:-2147467259) Looks like there are some IPv6 and TCP problems with the DNS http://dnsviz.net/d/qkstream.com/dnssec/ Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. From tgrand at tgrand.com Thu Sep 10 14:37:22 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Thu, 10 Sep 2015 09:37:22 -0500 Subject: outlook.com outgoing blacklists? In-Reply-To: References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> Message-ID: <53F2C909272A4678AA72A35223DA04D6@ToddDev> Interesting, however those ipv6 addresses were dropped from our dns almost 2 weeks ago. No quad A records should exist anylonger, as it has been more than 48 hours. -----Original Message----- From: Tony Finch Sent: Thursday, September 10, 2015 9:24 AM To: Todd K Grand Cc: Steve Atkins ; nanog list Subject: Re: outlook.com outgoing blacklists? Todd K Grand wrote: > Content-Type: message/delivery-status > > Reporting-MTA: dns;COL004-OMC2S2.hotmail.com > Received-From-MTA: dns;COL129-W41 > Arrival-Date: Wed, 9 Sep 2015 02:13:28 -0700 > > Final-Recipient: rfc822;support at qkstream.com > Action: failed > Status: 5.5.0 > Diagnostic-Code: smtp;554 The mail could not be delivered to the recipient > because the domain is not reachable. Please check the domain and try again > (-744508417:308:-2147467259) Looks like there are some IPv6 and TCP problems with the DNS http://dnsviz.net/d/qkstream.com/dnssec/ Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. From frnkblk at iname.com Thu Sep 10 14:37:24 2015 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 10 Sep 2015 09:37:24 -0500 Subject: NetFlow - path from Routers to Collector In-Reply-To: <201716EA-D1D0-4302-8FAB-E8A11FC82F20@arbor.net> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <20150901174406.GB28155@puck.nether.net> <201716EA-D1D0-4302-8FAB-E8A11FC82F20@arbor.net> Message-ID: <003701d0ebd6$35a6d8c0$a0f48a40$@iname.com> Does anyone else have a serial to IP dongle for devices that are IP only? That dongle would need to have telnet and SSH support. Or an IP-to-IP dongle, that would support a routing table? There's Brocade kit that has a mgmt. port, but it doesn't have its own routing table (they now have a mgmt. vrf in some software releases), making it local-only or something you have to use some kind of pseudo-NAT (all public IPs are translated to mgmt-network IPs). Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Tuesday, September 01, 2015 6:23 PM To: nanog at nanog.org Subject: Re: NetFlow - path from Routers to Collector Absolutely. All kinds of creative lashups to get console access in difficult situations (and, as you noted previously, an increasing number of devices don't support serial console at all, which is highly annoying). ----------------------------------- Roland Dobbins From jared at puck.nether.net Thu Sep 10 14:52:59 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 10 Sep 2015 10:52:59 -0400 Subject: WiFI on utility poles In-Reply-To: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> References: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> Message-ID: <2AA17621-E9C8-4E68-B878-656F7DBF1A52@puck.nether.net> > On Sep 10, 2015, at 9:00 AM, Mike Hammett wrote: > > 5 GHz noise levels affecting people whose primary means of Internet access is via fixed wireless . > This is a huge deal for those people like myself that depend on fixed wireless for access at home because there is no broadband available despite incentives given by cities and states and the federal government. The local WISPs are good at coordinating access in these ISM bands amongst themselves but when someone appears with a SSID without doing a peek at the spectrum (note: not a site survey, but actual spectrum view w/ waterfall, as site survey only checks for the channel width that the client radio is configured for, not al the 10, 15, 8, 30mhz wide variants). It?s just poor practice to show up and break something else because you can?t be bothered to notice the interference or noise floor you created. I suspect the hardware that Comcast is using doesn?t notice this interference or adjacent channel issues. With the FCC aiming to let cell carriers also clog the 5ghz ISM band it?s only going to get worse. - Jared From cboyd at gizmopartners.com Thu Sep 10 14:57:02 2015 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 10 Sep 2015 09:57:02 -0500 Subject: WiFI on utility poles In-Reply-To: <20150910041350.53547.qmail@ary.lan> References: <20150910041350.53547.qmail@ary.lan> Message-ID: > On Sep 9, 2015, at 11:13 PM, John Levine wrote: > > The placement may be suboptimal, but free wifi away from home is nice. > CableWifi really is a consortium, T-W customers can use Comcast's > hotspots and vice versa. If it were truly free and open access I?d be more tolerant of them stomping on my signal, but you have to be a CableCo customer in order to use it. The truly sucky thing about TWC?s deployment is that they are also installing it in restaurants, bars, and similar venues?sometimes displacing the open access setup that was already there. They conveniently forget to tell the owner/manager that it?s not really free access. ?Chris (Who spent many hours helping restaurants, bars, and similar venues in the Austin area set up guest wireless networks.) From dot at dotat.at Thu Sep 10 14:57:03 2015 From: dot at dotat.at (Tony Finch) Date: Thu, 10 Sep 2015 15:57:03 +0100 Subject: outlook.com outgoing blacklists? In-Reply-To: <53F2C909272A4678AA72A35223DA04D6@ToddDev> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> <53F2C909272A4678AA72A35223DA04D6@ToddDev> Message-ID: Todd K Grand wrote: > Interesting, however those ipv6 addresses were dropped from our dns > almost 2 weeks ago. No quad A records should exist anylonger, as it has > been more than 48 hours. You need to update the glue in your delegation. ; <<>> DiG 9.11.0pre-alpha <<>> +norec qkstream.com @a.gtld-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17274 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;qkstream.com. IN A ;; AUTHORITY SECTION: qkstream.com. 172800 IN NS ns1.quickwisp.com. qkstream.com. 172800 IN NS ns2.quickwisp.com. qkstream.com. 172800 IN NS ns3.quickwisp.com. ;; ADDITIONAL SECTION: ns1.quickwisp.com. 172800 IN AAAA 2001:470:b:4bb::25 ns1.quickwisp.com. 172800 IN A 206.220.196.115 ns2.quickwisp.com. 172800 IN AAAA 2001:470:b:4bb::22 ns2.quickwisp.com. 172800 IN A 206.220.193.189 ns3.quickwisp.com. 172800 IN A 66.171.143.250 ;; Query time: 14 msec ;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30) ;; WHEN: Thu Sep 10 15:56:31 BST 2015 ;; MSG SIZE rcvd: 209 Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. From khelms at zcorum.com Thu Sep 10 15:00:41 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 10 Sep 2015 11:00:41 -0400 Subject: WiFI on utility poles In-Reply-To: <2AA17621-E9C8-4E68-B878-656F7DBF1A52@puck.nether.net> References: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> <2AA17621-E9C8-4E68-B878-656F7DBF1A52@puck.nether.net> Message-ID: This sounds like a hypothetical complaint, AFAIK none of the members of the CableWiFi consortium are deploying APs outside of their footprint. Since most of the APs use a cable modem for their backhaul it's not really feasible to be without at least one broadband option (the cable MSO) and be impaired by the CableWiFi APs. Now, there is one potential exception to this I'm aware of which is Comcast's Xfinity on Campus service, but I'd expect the number of colleges they're servicing that aren't already getting cable broadband service to approach zero. http://www.philly.com/philly/business/20150909_Comcast_streams_onto_college_campuses.html https://xfinityoncampus.com/login Having said all of that, I'd agree that a good radio resource management approach would benefit all of us, including the CableWiFi guys. http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/ Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch wrote: > > > On Sep 10, 2015, at 9:00 AM, Mike Hammett wrote: > > > > 5 GHz noise levels affecting people whose primary means of Internet > access is via fixed wireless . > > > > This is a huge deal for those people like myself that depend on fixed > wireless for access at home because there is no broadband available despite > incentives given by cities and states and the federal government. > > The local WISPs are good at coordinating access in these ISM bands amongst > themselves but when someone appears with a SSID without doing a peek at the > spectrum (note: not a site survey, but actual spectrum view w/ waterfall, > as site survey only checks for the channel width that the client radio is > configured for, not al the 10, 15, 8, 30mhz wide variants). > > It?s just poor practice to show up and break something else because you > can?t be bothered to notice the interference or noise floor you created. I > suspect the hardware that Comcast is using doesn?t notice this interference > or adjacent channel issues. With the FCC aiming to let cell carriers also > clog the 5ghz ISM band it?s only going to get worse. > > - Jared From tgrand at tgrand.com Thu Sep 10 15:03:39 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Thu, 10 Sep 2015 10:03:39 -0500 Subject: outlook.com outgoing blacklists? In-Reply-To: References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> <53F2C909272A4678AA72A35223DA04D6@ToddDev> Message-ID: <8B08961BEC724F64BE26A5188A962AB4@ToddDev> Definitely something I need to address, I agree. However with that said the tgrand.com domain has the same problem yet hotmail/outlook.com sends fine to these. -----Original Message----- From: Tony Finch Sent: Thursday, September 10, 2015 9:57 AM To: Todd K Grand Cc: Steve Atkins ; nanog list Subject: Re: outlook.com outgoing blacklists? Todd K Grand wrote: > Interesting, however those ipv6 addresses were dropped from our dns > almost 2 weeks ago. No quad A records should exist anylonger, as it has > been more than 48 hours. You need to update the glue in your delegation. ; <<>> DiG 9.11.0pre-alpha <<>> +norec qkstream.com @a.gtld-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17274 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;qkstream.com. IN A ;; AUTHORITY SECTION: qkstream.com. 172800 IN NS ns1.quickwisp.com. qkstream.com. 172800 IN NS ns2.quickwisp.com. qkstream.com. 172800 IN NS ns3.quickwisp.com. ;; ADDITIONAL SECTION: ns1.quickwisp.com. 172800 IN AAAA 2001:470:b:4bb::25 ns1.quickwisp.com. 172800 IN A 206.220.196.115 ns2.quickwisp.com. 172800 IN AAAA 2001:470:b:4bb::22 ns2.quickwisp.com. 172800 IN A 206.220.193.189 ns3.quickwisp.com. 172800 IN A 66.171.143.250 ;; Query time: 14 msec ;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30) ;; WHEN: Thu Sep 10 15:56:31 BST 2015 ;; MSG SIZE rcvd: 209 Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. From nanog at ics-il.net Thu Sep 10 15:46:07 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 10 Sep 2015 10:46:07 -0500 (CDT) Subject: WiFI on utility poles In-Reply-To: <2AA17621-E9C8-4E68-B878-656F7DBF1A52@puck.nether.net> Message-ID: <598389423.5208.1441900011551.JavaMail.mhammett@ThunderFuck> I wish IEEE would natively support smaller channels as that's what's needed most of the time. Interference would be so much less. If there's opportunity for Comcast to work with the WISP community on channel selection to avoid mutual destruction, then great. That said, the cable company's efforts scream of OPM. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Mike Hammett" Cc: "Jason Livingood" , "Corey Petrulich" , "Kenneth Falkenstein" , "NANOG mailing list" Sent: Thursday, September 10, 2015 9:52:59 AM Subject: Re: WiFI on utility poles > On Sep 10, 2015, at 9:00 AM, Mike Hammett wrote: > > 5 GHz noise levels affecting people whose primary means of Internet access is via fixed wireless . > This is a huge deal for those people like myself that depend on fixed wireless for access at home because there is no broadband available despite incentives given by cities and states and the federal government. The local WISPs are good at coordinating access in these ISM bands amongst themselves but when someone appears with a SSID without doing a peek at the spectrum (note: not a site survey, but actual spectrum view w/ waterfall, as site survey only checks for the channel width that the client radio is configured for, not al the 10, 15, 8, 30mhz wide variants). It?s just poor practice to show up and break something else because you can?t be bothered to notice the interference or noise floor you created. I suspect the hardware that Comcast is using doesn?t notice this interference or adjacent channel issues. With the FCC aiming to let cell carriers also clog the 5ghz ISM band it?s only going to get worse. - Jared From khelms at zcorum.com Thu Sep 10 15:50:27 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 10 Sep 2015 11:50:27 -0400 Subject: WiFI on utility poles In-Reply-To: <598389423.5208.1441900011551.JavaMail.mhammett@ThunderFuck> References: <2AA17621-E9C8-4E68-B878-656F7DBF1A52@puck.nether.net> <598389423.5208.1441900011551.JavaMail.mhammett@ThunderFuck> Message-ID: OPM, as in Other People's Money? If that's what you meant I don't think that's an accurate description since AFAIK Comcast didn't get any CAF money. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Sep 10, 2015 at 11:46 AM, Mike Hammett wrote: > I wish IEEE would natively support smaller channels as that's what's > needed most of the time. Interference would be so much less. > > If there's opportunity for Comcast to work with the WISP community on > channel selection to avoid mutual destruction, then great. > > That said, the cable company's efforts scream of OPM. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Jared Mauch" > To: "Mike Hammett" > Cc: "Jason Livingood" , "Corey > Petrulich" , "Kenneth Falkenstein" < > Ken_Falkenstein at Cable.Comcast.com>, "NANOG mailing list" > Sent: Thursday, September 10, 2015 9:52:59 AM > Subject: Re: WiFI on utility poles > > > > On Sep 10, 2015, at 9:00 AM, Mike Hammett wrote: > > > > 5 GHz noise levels affecting people whose primary means of Internet > access is via fixed wireless . > > > > This is a huge deal for those people like myself that depend on fixed > wireless for access at home because there is no broadband available despite > incentives given by cities and states and the federal government. > > The local WISPs are good at coordinating access in these ISM bands amongst > themselves but when someone appears with a SSID without doing a peek at the > spectrum (note: not a site survey, but actual spectrum view w/ waterfall, > as site survey only checks for the channel width that the client radio is > configured for, not al the 10, 15, 8, 30mhz wide variants). > > It?s just poor practice to show up and break something else because you > can?t be bothered to notice the interference or noise floor you created. I > suspect the hardware that Comcast is using doesn?t notice this interference > or adjacent channel issues. With the FCC aiming to let cell carriers also > clog the 5ghz ISM band it?s only going to get worse. > > - Jared > From shefys at gmail.com Thu Sep 10 16:03:18 2015 From: shefys at gmail.com (Yury Shefer) Date: Thu, 10 Sep 2015 09:03:18 -0700 Subject: WiFI on utility poles In-Reply-To: References: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> <2AA17621-E9C8-4E68-B878-656F7DBF1A52@puck.nether.net> Message-ID: And the same guys (NCTA) complain about LTE-U - how dangerous it is for their s/business/WiFi http://arstechnica.com/information-technology/2015/08/verizon-and-t-mobile-join-forces-in-fight-for-wi-fi-airwaves/ On Thu, Sep 10, 2015 at 8:00 AM, Scott Helms wrote: > This sounds like a hypothetical complaint, AFAIK none of the members of the > CableWiFi consortium are deploying APs outside of their footprint. Since > most of the APs use a cable modem for their backhaul it's not really > feasible to be without at least one broadband option (the cable MSO) and be > impaired by the CableWiFi APs. > > Now, there is one potential exception to this I'm aware of which is > Comcast's Xfinity on Campus service, but I'd expect the number of colleges > they're servicing that aren't already getting cable broadband service to > approach zero. > > > http://www.philly.com/philly/business/20150909_Comcast_streams_onto_college_campuses.html > > https://xfinityoncampus.com/login > > > Having said all of that, I'd agree that a good radio resource management > approach would benefit all of us, including the CableWiFi guys. > > http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/ > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch > wrote: > > > > > > On Sep 10, 2015, at 9:00 AM, Mike Hammett wrote: > > > > > > 5 GHz noise levels affecting people whose primary means of Internet > > access is via fixed wireless . > > > > > > > This is a huge deal for those people like myself that depend on fixed > > wireless for access at home because there is no broadband available > despite > > incentives given by cities and states and the federal government. > > > > The local WISPs are good at coordinating access in these ISM bands > amongst > > themselves but when someone appears with a SSID without doing a peek at > the > > spectrum (note: not a site survey, but actual spectrum view w/ waterfall, > > as site survey only checks for the channel width that the client radio is > > configured for, not al the 10, 15, 8, 30mhz wide variants). > > > > It?s just poor practice to show up and break something else because you > > can?t be bothered to notice the interference or noise floor you > created. I > > suspect the hardware that Comcast is using doesn?t notice this > interference > > or adjacent channel issues. With the FCC aiming to let cell carriers > also > > clog the 5ghz ISM band it?s only going to get worse. > > > > - Jared > -- Best regards, Yury. From khelms at zcorum.com Thu Sep 10 16:15:49 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 10 Sep 2015 12:15:49 -0400 Subject: WiFI on utility poles In-Reply-To: References: <1921798843.4971.1441890067444.JavaMail.mhammett@ThunderFuck> <2AA17621-E9C8-4E68-B878-656F7DBF1A52@puck.nether.net> Message-ID: We should all be complaining, vociferously, about LTE-U. I've seen the tests and as it exists today LTE-U completely creams WiFi and is only usable by someone who owns a LTE license. WiFi APs will cohabitate fairly well, even if they share the same channel, because WiFi is a listen before transmitting protocol. LTE and LTE-U is a centrally scheduled protocol and doesn't have a back off mechanism. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Sep 10, 2015 at 12:03 PM, Yury Shefer wrote: > And the same guys (NCTA) complain about LTE-U - how dangerous it is for > their s/business/WiFi > > > http://arstechnica.com/information-technology/2015/08/verizon-and-t-mobile-join-forces-in-fight-for-wi-fi-airwaves/ > > > > On Thu, Sep 10, 2015 at 8:00 AM, Scott Helms wrote: > >> This sounds like a hypothetical complaint, AFAIK none of the members of >> the >> CableWiFi consortium are deploying APs outside of their footprint. Since >> most of the APs use a cable modem for their backhaul it's not really >> feasible to be without at least one broadband option (the cable MSO) and >> be >> impaired by the CableWiFi APs. >> >> Now, there is one potential exception to this I'm aware of which is >> Comcast's Xfinity on Campus service, but I'd expect the number of colleges >> they're servicing that aren't already getting cable broadband service to >> approach zero. >> >> >> http://www.philly.com/philly/business/20150909_Comcast_streams_onto_college_campuses.html >> >> https://xfinityoncampus.com/login >> >> >> Having said all of that, I'd agree that a good radio resource management >> approach would benefit all of us, including the CableWiFi guys. >> >> http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/ >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch >> wrote: >> >> > >> > > On Sep 10, 2015, at 9:00 AM, Mike Hammett wrote: >> > > >> > > 5 GHz noise levels affecting people whose primary means of Internet >> > access is via fixed wireless . >> > > >> > >> > This is a huge deal for those people like myself that depend on fixed >> > wireless for access at home because there is no broadband available >> despite >> > incentives given by cities and states and the federal government. >> > >> > The local WISPs are good at coordinating access in these ISM bands >> amongst >> > themselves but when someone appears with a SSID without doing a peek at >> the >> > spectrum (note: not a site survey, but actual spectrum view w/ >> waterfall, >> > as site survey only checks for the channel width that the client radio >> is >> > configured for, not al the 10, 15, 8, 30mhz wide variants). >> > >> > It?s just poor practice to show up and break something else because you >> > can?t be bothered to notice the interference or noise floor you >> created. I >> > suspect the hardware that Comcast is using doesn?t notice this >> interference >> > or adjacent channel issues. With the FCC aiming to let cell carriers >> also >> > clog the 5ghz ISM band it?s only going to get worse. >> > >> > - Jared >> > > > > -- > Best regards, > Yury. > From nanog at ics-il.net Thu Sep 10 16:17:44 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 10 Sep 2015 11:17:44 -0500 (CDT) Subject: WiFI on utility poles In-Reply-To: Message-ID: <277960960.5247.1441901907681.JavaMail.mhammett@ThunderFuck> Yeah, Other People's Money. I highly doubt they got government money, but large corporations are full of OPM from the perspective of the guy doing the work. Let's pitch this big science project because it sounds awesome and I can convince these guys to pay for it. It's not in any way unique to Comcast. Contrasting that to a small company where it very much is the head guy's money in every decision, so (generally, though certainly not always) more judicious caution is exercised. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Scott Helms" To: "Mike Hammett" Cc: "Jared Mauch" , "Corey Petrulich" , "Kenneth Falkenstein" , "NANOG mailing list" Sent: Thursday, September 10, 2015 10:50:27 AM Subject: Re: WiFI on utility poles OPM, as in Other People's Money? If that's what you meant I don't think that's an accurate description since AFAIK Comcast didn't get any CAF money. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Sep 10, 2015 at 11:46 AM, Mike Hammett < nanog at ics-il.net > wrote: I wish IEEE would natively support smaller channels as that's what's needed most of the time. Interference would be so much less. If there's opportunity for Comcast to work with the WISP community on channel selection to avoid mutual destruction, then great. That said, the cable company's efforts scream of OPM. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" < jared at puck.nether.net > To: "Mike Hammett" < nanog at ics-il.net > Cc: "Jason Livingood" < Jason_Livingood at cable.comcast.com >, "Corey Petrulich" < Corey_Petrulich at cable.comcast.com >, "Kenneth Falkenstein" < Ken_Falkenstein at Cable.Comcast.com >, "NANOG mailing list" < nanog at nanog.org > Sent: Thursday, September 10, 2015 9:52:59 AM Subject: Re: WiFI on utility poles > On Sep 10, 2015, at 9:00 AM, Mike Hammett < nanog at ics-il.net > wrote: > > 5 GHz noise levels affecting people whose primary means of Internet access is via fixed wireless . > This is a huge deal for those people like myself that depend on fixed wireless for access at home because there is no broadband available despite incentives given by cities and states and the federal government. The local WISPs are good at coordinating access in these ISM bands amongst themselves but when someone appears with a SSID without doing a peek at the spectrum (note: not a site survey, but actual spectrum view w/ waterfall, as site survey only checks for the channel width that the client radio is configured for, not al the 10, 15, 8, 30mhz wide variants). It?s just poor practice to show up and break something else because you can?t be bothered to notice the interference or noise floor you created. I suspect the hardware that Comcast is using doesn?t notice this interference or adjacent channel issues. With the FCC aiming to let cell carriers also clog the 5ghz ISM band it?s only going to get worse. - Jared From egypcio at googlemail.com Thu Sep 10 16:19:41 2015 From: egypcio at googlemail.com (=?UTF-8?Q?Vin=C3=ADcius_Zavam?=) Date: Thu, 10 Sep 2015 13:19:41 -0300 Subject: =?UTF-8?Q?Re=3A_BSDCon_Brasil_2015=3A_Apresenta=C3=A7=C3=B5es_=2F_Talks?= In-Reply-To: References: Message-ID: 2015-07-22 6:52 GMT-03:00 Vin?cius Zavam : > > ---------- Forwarded message ---------- > From: BSDCon Brasil 2015 > Date: 2015-07-16 13:09 GMT-03:00 > Subject: BSDCon Brasil 2015: Apresenta??es / Talks > To: > > > https://twitter.com/bsdcon_br/status/620727031630798852 > > ===== pt > > Acompanhe as atualiza??es da confer?ncia atrav?s do Twitter ou Facebook > (fb.com/bsdconbrasil2015). > > Gostaria de patrocinar a BSDCon Brasil 2015? Entre em contato conosco > atrav?s das redes sociais ou mande-nos um email. Escreva para > patrocinio at bsdcon.com.br > > Conhe?a nossos patrocinadores: http://2015.bsdcon.com.br/patrocinio > > ===== en > > Follow conference updates on Twitter or Facebook (fb.com/bsdconbrasil2015 > ). > > Would you like to become a sponsor? Please write to > sponsorship at bsdcon.com.br > > Meet our sponsors: http://2015.bsdcon.com.br/sponsorship > > > -- > BSDCon Brasil 2015 > http://2015.bsdcon.com.br > http://2015.bsdcon.com.br/start > http://twitter.com/bsdcon_br > https://www.youtube.com/watch?v=jTIoTI0aK5g -- Vin?cius Zavam keybase.io/egypcio/key.asc From josh at imaginenetworksllc.com Thu Sep 10 16:27:43 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 10 Sep 2015 12:27:43 -0400 Subject: WiFI on utility poles In-Reply-To: <277960960.5247.1441901907681.JavaMail.mhammett@ThunderFuck> References: <277960960.5247.1441901907681.JavaMail.mhammett@ThunderFuck> Message-ID: It's backed by large investments rather than CAF. At the same time, it's well known that millions are spent on lobbying in the government to sway the decisions. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Sep 10, 2015 at 12:17 PM, Mike Hammett wrote: > Yeah, Other People's Money. > > I highly doubt they got government money, but large corporations are full > of OPM from the perspective of the guy doing the work. Let's pitch this big > science project because it sounds awesome and I can convince these guys to > pay for it. It's not in any way unique to Comcast. > > Contrasting that to a small company where it very much is the head guy's > money in every decision, so (generally, though certainly not always) more > judicious caution is exercised. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Scott Helms" > To: "Mike Hammett" > Cc: "Jared Mauch" , "Corey Petrulich" < > Corey_Petrulich at cable.comcast.com>, "Kenneth Falkenstein" < > Ken_Falkenstein at cable.comcast.com>, "NANOG mailing list" > Sent: Thursday, September 10, 2015 10:50:27 AM > Subject: Re: WiFI on utility poles > > > OPM, as in Other People's Money? If that's what you meant I don't think > that's an accurate description since AFAIK Comcast didn't get any CAF money. > > > > > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Thu, Sep 10, 2015 at 11:46 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > I wish IEEE would natively support smaller channels as that's what's > needed most of the time. Interference would be so much less. > > If there's opportunity for Comcast to work with the WISP community on > channel selection to avoid mutual destruction, then great. > > That said, the cable company's efforts scream of OPM. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Jared Mauch" < jared at puck.nether.net > > To: "Mike Hammett" < nanog at ics-il.net > > Cc: "Jason Livingood" < Jason_Livingood at cable.comcast.com >, "Corey > Petrulich" < Corey_Petrulich at cable.comcast.com >, "Kenneth Falkenstein" < > Ken_Falkenstein at Cable.Comcast.com >, "NANOG mailing list" < > nanog at nanog.org > > Sent: Thursday, September 10, 2015 9:52:59 AM > Subject: Re: WiFI on utility poles > > > > On Sep 10, 2015, at 9:00 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > > 5 GHz noise levels affecting people whose primary means of Internet > access is via fixed wireless . > > > > This is a huge deal for those people like myself that depend on fixed > wireless for access at home because there is no broadband available despite > incentives given by cities and states and the federal government. > > The local WISPs are good at coordinating access in these ISM bands amongst > themselves but when someone appears with a SSID without doing a peek at the > spectrum (note: not a site survey, but actual spectrum view w/ waterfall, > as site survey only checks for the channel width that the client radio is > configured for, not al the 10, 15, 8, 30mhz wide variants). > > It?s just poor practice to show up and break something else because you > can?t be bothered to notice the interference or noise floor you created. I > suspect the hardware that Comcast is using doesn?t notice this interference > or adjacent channel issues. With the FCC aiming to let cell carriers also > clog the 5ghz ISM band it?s only going to get worse. > > - Jared > > > > > From johnl at iecc.com Thu Sep 10 17:08:14 2015 From: johnl at iecc.com (John Levine) Date: 10 Sep 2015 17:08:14 -0000 Subject: Can't reach RIPE WHOIS via IPv6 ? Message-ID: <20150910170814.56640.qmail@ary.lan> (I realize RIPE is not in North America, but we get a lot of traffic from their IP space.) When I try to contact whois.ripe.net (2001:67c:2e8:22::c100:687) or their REST server rest.db.ripe.net (2001:67c:2e8:22::c100:68e), it times out. Traceroutes from a couple of different places all seem to loop in Amsterdam, IPv4 is fine. Am I special, or is it just broken? R's, John From nanog at ics-il.net Thu Sep 10 17:15:29 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 10 Sep 2015 12:15:29 -0500 (CDT) Subject: WiFI on utility poles In-Reply-To: Message-ID: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> The tower-deployed AP can see the cable wireless APs for miles and can see a few dozen of them at any one time. Given the goal of full modulation at all times for optimal use of spectrum and dollars, the ever increasing noise from the cable APs makes this a challenge. You need 25 to 30 dB to maintain full modulation and that's increasingly difficult when you hear cable APs everywhere at -70. The APs can't have narrow radiation patterns given that they need to cover a roughly 90* area of where the customers are. An 18 to 20 dB gain sector antenna will pick up those cable radios from pretty far away. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Scott Helms" To: "Jared Mauch" Cc: "Mike Hammett" , "Corey Petrulich" , "Kenneth Falkenstein" , "NANOG mailing list" Sent: Thursday, September 10, 2015 10:00:41 AM Subject: Re: WiFI on utility poles This sounds like a hypothetical complaint, AFAIK none of the members of the CableWiFi consortium are deploying APs outside of their footprint. Since most of the APs use a cable modem for their backhaul it's not really feasible to be without at least one broadband option (the cable MSO) and be impaired by the CableWiFi APs. Now, there is one potential exception to this I'm aware of which is Comcast's Xfinity on Campus service, but I'd expect the number of colleges they're servicing that aren't already getting cable broadband service to approach zero. http://www.philly.com/philly/business/20150909_Comcast_streams_onto_college_campuses.html https://xfinityoncampus.com/login Having said all of that, I'd agree that a good radio resource management approach would benefit all of us, including the CableWiFi guys. http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/ Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch < jared at puck.nether.net > wrote: > On Sep 10, 2015, at 9:00 AM, Mike Hammett < nanog at ics-il.net > wrote: > > 5 GHz noise levels affecting people whose primary means of Internet access is via fixed wireless . > This is a huge deal for those people like myself that depend on fixed wireless for access at home because there is no broadband available despite incentives given by cities and states and the federal government. The local WISPs are good at coordinating access in these ISM bands amongst themselves but when someone appears with a SSID without doing a peek at the spectrum (note: not a site survey, but actual spectrum view w/ waterfall, as site survey only checks for the channel width that the client radio is configured for, not al the 10, 15, 8, 30mhz wide variants). It?s just poor practice to show up and break something else because you can?t be bothered to notice the interference or noise floor you created. I suspect the hardware that Comcast is using doesn?t notice this interference or adjacent channel issues. With the FCC aiming to let cell carriers also clog the 5ghz ISM band it?s only going to get worse. - Jared From niels=nanog at bakker.net Thu Sep 10 17:16:13 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 10 Sep 2015 19:16:13 +0200 Subject: Can't reach RIPE WHOIS via IPv6 ? In-Reply-To: <20150910170814.56640.qmail@ary.lan> References: <20150910170814.56640.qmail@ary.lan> Message-ID: <20150910171613.GA3097@excession.tpb.net> * johnl at iecc.com (John Levine) [Thu 10 Sep 2015, 19:09 CEST]: >When I try to contact whois.ripe.net (2001:67c:2e8:22::c100:687) or >their REST server rest.db.ripe.net (2001:67c:2e8:22::c100:68e), it >times out. Traceroutes from a couple of different places all seem >to loop in Amsterdam, IPv4 is fine. > >Am I special, or is it just broken? WFM % telnet whois.ripe.net whois Trying 2001:67c:2e8:22::c100:687... Connected to whois.ripe.net. -- Niels. From mike.lyon at gmail.com Thu Sep 10 17:32:34 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 10 Sep 2015 10:32:34 -0700 Subject: WiFI on utility poles In-Reply-To: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> References: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> Message-ID: A few dozen? Damn, you are lucy, Mike! I did an install the other day, a good 60-70 XfinityWifi SSIDs popped up. Reminds me of the Good 'Ole CB days back in the 80's where everyone talked over each other and played background music and such... That's a big 10-4 and I got a Smokey on my trail! -Mike On Thu, Sep 10, 2015 at 10:15 AM, Mike Hammett wrote: > The tower-deployed AP can see the cable wireless APs for miles and can see > a few dozen of them at any one time. Given the goal of full modulation at > all times for optimal use of spectrum and dollars, the ever increasing > noise from the cable APs makes this a challenge. You need 25 to 30 dB to > maintain full modulation and that's increasingly difficult when you hear > cable APs everywhere at -70. > > The APs can't have narrow radiation patterns given that they need to cover > a roughly 90* area of where the customers are. An 18 to 20 dB gain sector > antenna will pick up those cable radios from pretty far away. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Scott Helms" > To: "Jared Mauch" > Cc: "Mike Hammett" , "Corey Petrulich" < > Corey_Petrulich at cable.comcast.com>, "Kenneth Falkenstein" < > Ken_Falkenstein at cable.comcast.com>, "NANOG mailing list" > Sent: Thursday, September 10, 2015 10:00:41 AM > Subject: Re: WiFI on utility poles > > > This sounds like a hypothetical complaint, AFAIK none of the members of > the CableWiFi consortium are deploying APs outside of their footprint. > Since most of the APs use a cable modem for their backhaul it's not really > feasible to be without at least one broadband option (the cable MSO) and be > impaired by the CableWiFi APs. > > > Now, there is one potential exception to this I'm aware of which is > Comcast's Xfinity on Campus service, but I'd expect the number of colleges > they're servicing that aren't already getting cable broadband service to > approach zero. > > > > http://www.philly.com/philly/business/20150909_Comcast_streams_onto_college_campuses.html > > > > https://xfinityoncampus.com/login > > > > > > Having said all of that, I'd agree that a good radio resource management > approach would benefit all of us, including the CableWiFi guys. > > > http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/ > > > > > > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch < jared at puck.nether.net > > wrote: > > > > > On Sep 10, 2015, at 9:00 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > > 5 GHz noise levels affecting people whose primary means of Internet > access is via fixed wireless . > > > > This is a huge deal for those people like myself that depend on fixed > wireless for access at home because there is no broadband available despite > incentives given by cities and states and the federal government. > > The local WISPs are good at coordinating access in these ISM bands amongst > themselves but when someone appears with a SSID without doing a peek at the > spectrum (note: not a site survey, but actual spectrum view w/ waterfall, > as site survey only checks for the channel width that the client radio is > configured for, not al the 10, 15, 8, 30mhz wide variants). > > It?s just poor practice to show up and break something else because you > can?t be bothered to notice the interference or noise floor you created. I > suspect the hardware that Comcast is using doesn?t notice this interference > or adjacent channel issues. With the FCC aiming to let cell carriers also > clog the 5ghz ISM band it?s only going to get worse. > > - Jared > > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From job at instituut.net Thu Sep 10 17:35:10 2015 From: job at instituut.net (Job Snijders) Date: Thu, 10 Sep 2015 19:35:10 +0200 Subject: Can't reach RIPE WHOIS via IPv6 ? In-Reply-To: <20150910170814.56640.qmail@ary.lan> References: <20150910170814.56640.qmail@ary.lan> Message-ID: <20150910173510.GC89211@Vurt.local> Hi, On Thu, Sep 10, 2015 at 05:08:14PM -0000, John Levine wrote: > (I realize RIPE is not in North America, but we get a lot of traffic > from their IP space.) > > When I try to contact whois.ripe.net (2001:67c:2e8:22::c100:687) or > their REST server rest.db.ripe.net (2001:67c:2e8:22::c100:68e), it > times out. Traceroutes from a couple of different places all seem to > loop in Amsterdam, IPv4 is fine. > > Am I special, or is it just broken? You should reach out to RIPE NCC directly at ops at ripe.net This is the proper contact to debug and address your issue, or fill in this form: https://www.ripe.net/contact-form Kind regards, Job From maxtul at netassist.ua Thu Sep 10 17:36:50 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 10 Sep 2015 20:36:50 +0300 Subject: Can't reach RIPE WHOIS via IPv6 ? In-Reply-To: <20150910171613.GA3097@excession.tpb.net> References: <20150910170814.56640.qmail@ary.lan> <20150910171613.GA3097@excession.tpb.net> Message-ID: <55F1BFB2.7080105@netassist.ua> Same for me from 2a01:d0::/32 telnet whois.ripe.net whois Trying 2001:67c:2e8:22::c100:687... Connected to whois.ripe.net. Escape character is '^]'. % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf Seems like local routing issue, not global. On 10.09.15 20:16, Niels Bakker wrote: > * johnl at iecc.com (John Levine) [Thu 10 Sep 2015, 19:09 CEST]: >> When I try to contact whois.ripe.net (2001:67c:2e8:22::c100:687) or >> their REST server rest.db.ripe.net (2001:67c:2e8:22::c100:68e), it >> times out. Traceroutes from a couple of different places all seem to >> loop in Amsterdam, IPv4 is fine. >> >> Am I special, or is it just broken? > > WFM > > % telnet whois.ripe.net whois > Trying 2001:67c:2e8:22::c100:687... > Connected to whois.ripe.net. > > > -- Niels. > From mike.lyon at gmail.com Thu Sep 10 17:37:03 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 10 Sep 2015 10:37:03 -0700 Subject: WiFI on utility poles In-Reply-To: References: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> Message-ID: Really Comcast? Your spam software SUCKS ASS! For those interested, the word that violated their spam software was "damn" -Mike ---------------------------------------------------------------------------- This email has violated the PROFANITY. and Pass has been taken on 9/10/2015 1:34:19 PM. Message details: Server: BUPMEXCASHUB2 Sender: mike.lyon at gmail.com; Recipient: nanog at ics-il.net;Corey_Petrulich at cable.comcast.com; Ken_Falkenstein at cable.comcast.com;nanog at nanog.org; Subject: Re: WiFI on utility poles The information in this message, including in all attachments, is confidential or privileged. In the event you have received this message in error and are not the intended recipient, you are hereby advised that any use, copying or reproduction of this document is strictly forbidden. Please notify immediately the sender of this error and destroy this message, including its attachments, as the case may be.

L'information apparaissant dans ce message electronique et dans les documents qui y sont joints est de nature confidentielle ou privilegiee. Si ce message vous est parvenu par erreur et que vous n'en etes pas le destinataire vise, vous etes par les presentes avise que toute utilisation, copie ou distribution de ce message est strictement interdite. Vous etes donc prie d?en informer immediatement l?expediteur et de detruire ce message, ainsi que les documents qui y sont joints, le cas echeant. On Thu, Sep 10, 2015 at 10:32 AM, Mike Lyon wrote: > A few dozen? Damn, you are lucy, Mike! > > I did an install the other day, a good 60-70 XfinityWifi SSIDs popped up. > > Reminds me of the Good 'Ole CB days back in the 80's where everyone talked > over each other and played background music and such... > > That's a big 10-4 and I got a Smokey on my trail! > > -Mike > > On Thu, Sep 10, 2015 at 10:15 AM, Mike Hammett wrote: > >> The tower-deployed AP can see the cable wireless APs for miles and can >> see a few dozen of them at any one time. Given the goal of full modulation >> at all times for optimal use of spectrum and dollars, the ever increasing >> noise from the cable APs makes this a challenge. You need 25 to 30 dB to >> maintain full modulation and that's increasingly difficult when you hear >> cable APs everywhere at -70. >> >> The APs can't have narrow radiation patterns given that they need to >> cover a roughly 90* area of where the customers are. An 18 to 20 dB gain >> sector antenna will pick up those cable radios from pretty far away. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> >> ----- Original Message ----- >> >> From: "Scott Helms" >> To: "Jared Mauch" >> Cc: "Mike Hammett" , "Corey Petrulich" < >> Corey_Petrulich at cable.comcast.com>, "Kenneth Falkenstein" < >> Ken_Falkenstein at cable.comcast.com>, "NANOG mailing list" > > >> Sent: Thursday, September 10, 2015 10:00:41 AM >> Subject: Re: WiFI on utility poles >> >> >> This sounds like a hypothetical complaint, AFAIK none of the members of >> the CableWiFi consortium are deploying APs outside of their footprint. >> Since most of the APs use a cable modem for their backhaul it's not really >> feasible to be without at least one broadband option (the cable MSO) and be >> impaired by the CableWiFi APs. >> >> >> Now, there is one potential exception to this I'm aware of which is >> Comcast's Xfinity on Campus service, but I'd expect the number of colleges >> they're servicing that aren't already getting cable broadband service to >> approach zero. >> >> >> >> http://www.philly.com/philly/business/20150909_Comcast_streams_onto_college_campuses.html >> >> >> >> https://xfinityoncampus.com/login >> >> >> >> >> >> Having said all of that, I'd agree that a good radio resource management >> approach would benefit all of us, including the CableWiFi guys. >> >> >> http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/ >> >> >> >> >> >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> >> On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch < jared at puck.nether.net > >> wrote: >> >> >> >> > On Sep 10, 2015, at 9:00 AM, Mike Hammett < nanog at ics-il.net > wrote: >> > >> > 5 GHz noise levels affecting people whose primary means of Internet >> access is via fixed wireless . >> > >> >> This is a huge deal for those people like myself that depend on fixed >> wireless for access at home because there is no broadband available despite >> incentives given by cities and states and the federal government. >> >> The local WISPs are good at coordinating access in these ISM bands >> amongst themselves but when someone appears with a SSID without doing a >> peek at the spectrum (note: not a site survey, but actual spectrum view w/ >> waterfall, as site survey only checks for the channel width that the client >> radio is configured for, not al the 10, 15, 8, 30mhz wide variants). >> >> It?s just poor practice to show up and break something else because you >> can?t be bothered to notice the interference or noise floor you created. I >> suspect the hardware that Comcast is using doesn?t notice this interference >> or adjacent channel issues. With the FCC aiming to let cell carriers also >> clog the 5ghz ISM band it?s only going to get worse. >> >> - Jared >> >> >> >> > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From johnl at iecc.com Thu Sep 10 17:43:32 2015 From: johnl at iecc.com (John R. Levine) Date: 10 Sep 2015 13:43:32 -0400 Subject: Can't reach RIPE WHOIS via IPv6 ? In-Reply-To: <20150910173510.GC89211@Vurt.local> References: <20150910170814.56640.qmail@ary.lan> <20150910173510.GC89211@Vurt.local> Message-ID: >> When I try to contact whois.ripe.net (2001:67c:2e8:22::c100:687) or >> their REST server rest.db.ripe.net (2001:67c:2e8:22::c100:68e), it >> times out. Traceroutes from a couple of different places all seem to >> loop in Amsterdam, IPv4 is fine. >> Am I special, or is it just broken? I guess I was special. Seems to work OK now. R's, John From Jason_Livingood at cable.comcast.com Thu Sep 10 18:02:27 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 10 Sep 2015 18:02:27 +0000 Subject: WiFI on utility poles In-Reply-To: References: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> Message-ID: Odd - I got the email fine. The bound message you got also is in French, which would not seem like something our email servers would do. Are you sure that was from our servers? I?d love to see the mail headers so I can talk to the enterprise mail team. Jason On 9/10/15, 1:37 PM, "NANOG on behalf of Mike Lyon" wrote: >Really Comcast? Your spam software SUCKS ASS! > >For those interested, the word that violated their spam software was >"damn" > >-Mike > > >-------------------------------------------------------------------------- >-- > >This email has violated the PROFANITY. >and Pass has been taken on 9/10/2015 1:34:19 PM. >Message details: >Server: BUPMEXCASHUB2 >Sender: mike.lyon at gmail.com; >Recipient: >nanog at ics-il.net;Corey_Petrulich at cable.comcast.com; >Ken_Falkenstein at cable.comcast.com;nanog at nanog.org; >Subject: Re: WiFI on utility poles > > >The information in this message, including in all attachments, is >confidential or privileged. In the event you have received this message in >error >and are not the intended recipient, you are hereby advised that any use, >copying >or reproduction of this document is strictly forbidden. Please notify >immediately the sender of this error and destroy this message, including >its >attachments, as the case may be. >

>L'information apparaissant dans ce message electronique et dans les >documents >qui y sont joints est de nature confidentielle ou privilegiee. Si ce >message >vous est parvenu par erreur et que vous n'en etes pas le destinataire >vise, >vous >etes par les presentes avise que toute utilisation, copie ou distribution >de ce >message est strictement interdite. Vous etes donc prie d?en informer >immediatement l?expediteur et de detruire ce message, ainsi que les >documents >qui y sont joints, le cas echeant. > >On Thu, Sep 10, 2015 at 10:32 AM, Mike Lyon wrote: > >> A few dozen? Damn, you are lucy, Mike! >> >> I did an install the other day, a good 60-70 XfinityWifi SSIDs popped >>up. >> >> Reminds me of the Good 'Ole CB days back in the 80's where everyone >>talked >> over each other and played background music and such... >> >> That's a big 10-4 and I got a Smokey on my trail! >> >> -Mike >> >> On Thu, Sep 10, 2015 at 10:15 AM, Mike Hammett wrote: >> >>> The tower-deployed AP can see the cable wireless APs for miles and can >>> see a few dozen of them at any one time. Given the goal of full >>>modulation >>> at all times for optimal use of spectrum and dollars, the ever >>>increasing >>> noise from the cable APs makes this a challenge. You need 25 to 30 dB >>>to >>> maintain full modulation and that's increasingly difficult when you >>>hear >>> cable APs everywhere at -70. >>> >>> The APs can't have narrow radiation patterns given that they need to >>> cover a roughly 90* area of where the customers are. An 18 to 20 dB >>>gain >>> sector antenna will pick up those cable radios from pretty far away. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> Midwest Internet Exchange >>> http://www.midwest-ix.com >>> >>> >>> ----- Original Message ----- >>> >>> From: "Scott Helms" >>> To: "Jared Mauch" >>> Cc: "Mike Hammett" , "Corey Petrulich" < >>> Corey_Petrulich at cable.comcast.com>, "Kenneth Falkenstein" < >>> Ken_Falkenstein at cable.comcast.com>, "NANOG mailing list" >>>>> > >>> Sent: Thursday, September 10, 2015 10:00:41 AM >>> Subject: Re: WiFI on utility poles >>> >>> >>> This sounds like a hypothetical complaint, AFAIK none of the members of >>> the CableWiFi consortium are deploying APs outside of their footprint. >>> Since most of the APs use a cable modem for their backhaul it's not >>>really >>> feasible to be without at least one broadband option (the cable MSO) >>>and be >>> impaired by the CableWiFi APs. >>> >>> >>> Now, there is one potential exception to this I'm aware of which is >>> Comcast's Xfinity on Campus service, but I'd expect the number of >>>colleges >>> they're servicing that aren't already getting cable broadband service >>>to >>> approach zero. >>> >>> >>> >>> >>>http://www.philly.com/philly/business/20150909_Comcast_streams_onto_coll >>>ege_campuses.html >>> >>> >>> >>> https://xfinityoncampus.com/login >>> >>> >>> >>> >>> >>> Having said all of that, I'd agree that a good radio resource >>>management >>> approach would benefit all of us, including the CableWiFi guys. >>> >>> >>> http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/ >>> >>> >>> >>> >>> >>> >>> >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> >>> >>> On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch < jared at puck.nether.net > >>> wrote: >>> >>> >>> >>> > On Sep 10, 2015, at 9:00 AM, Mike Hammett < nanog at ics-il.net > wrote: >>> > >>> > 5 GHz noise levels affecting people whose primary means of Internet >>> access is via fixed wireless . >>> > >>> >>> This is a huge deal for those people like myself that depend on fixed >>> wireless for access at home because there is no broadband available >>>despite >>> incentives given by cities and states and the federal government. >>> >>> The local WISPs are good at coordinating access in these ISM bands >>> amongst themselves but when someone appears with a SSID without doing a >>> peek at the spectrum (note: not a site survey, but actual spectrum >>>view w/ >>> waterfall, as site survey only checks for the channel width that the >>>client >>> radio is configured for, not al the 10, 15, 8, 30mhz wide variants). >>> >>> It?s just poor practice to show up and break something else because you >>> can?t be bothered to notice the interference or noise floor you >>>created. I >>> suspect the hardware that Comcast is using doesn?t notice this >>>interference >>> or adjacent channel issues. With the FCC aiming to let cell carriers >>>also >>> clog the 5ghz ISM band it?s only going to get worse. >>> >>> - Jared >>> >>> >>> >>> >> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/mlyon >> >> >> >> > > >-- >Mike Lyon >408-621-4826 >mike.lyon at gmail.com > >http://www.linkedin.com/in/mlyon > From tgrand at tgrand.com Thu Sep 10 18:03:25 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Thu, 10 Sep 2015 13:03:25 -0500 Subject: outlook.com outgoing blacklists? In-Reply-To: <8B08961BEC724F64BE26A5188A962AB4@ToddDev> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> <53F2C909272A4678AA72A35223DA04D6@ToddDev> <8B08961BEC724F64BE26A5188A962AB4@ToddDev> Message-ID: IPV6 Glue is gone. and no the domain is qkstream.com not gkstream.com The domain I have owned for 8 or so years. The problem started within the past 3-4 weeks. -----Original Message----- From: Todd K Grand Sent: Thursday, September 10, 2015 10:03 AM To: Tony Finch Cc: Steve Atkins ; nanog list Subject: Re: outlook.com outgoing blacklists? Definitely something I need to address, I agree. However with that said the tgrand.com domain has the same problem yet hotmail/outlook.com sends fine to these. -----Original Message----- From: Tony Finch Sent: Thursday, September 10, 2015 9:57 AM To: Todd K Grand Cc: Steve Atkins ; nanog list Subject: Re: outlook.com outgoing blacklists? Todd K Grand wrote: > Interesting, however those ipv6 addresses were dropped from our dns > almost 2 weeks ago. No quad A records should exist anylonger, as it has > been more than 48 hours. You need to update the glue in your delegation. ; <<>> DiG 9.11.0pre-alpha <<>> +norec qkstream.com @a.gtld-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17274 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;qkstream.com. IN A ;; AUTHORITY SECTION: qkstream.com. 172800 IN NS ns1.quickwisp.com. qkstream.com. 172800 IN NS ns2.quickwisp.com. qkstream.com. 172800 IN NS ns3.quickwisp.com. ;; ADDITIONAL SECTION: ns1.quickwisp.com. 172800 IN AAAA 2001:470:b:4bb::25 ns1.quickwisp.com. 172800 IN A 206.220.196.115 ns2.quickwisp.com. 172800 IN AAAA 2001:470:b:4bb::22 ns2.quickwisp.com. 172800 IN A 206.220.193.189 ns3.quickwisp.com. 172800 IN A 66.171.143.250 ;; Query time: 14 msec ;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30) ;; WHEN: Thu Sep 10 15:56:31 BST 2015 ;; MSG SIZE rcvd: 209 Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. From josh at imaginenetworksllc.com Thu Sep 10 18:06:14 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 10 Sep 2015 14:06:14 -0400 Subject: WiFI on utility poles In-Reply-To: References: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> Message-ID: It's either Mike, Comcast or the NANOG list, so it's probably a safe bet. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Sep 10, 2015 at 2:02 PM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > Odd - I got the email fine. The bound message you got also is in French, > which would not seem like something our email servers would do. Are you > sure that was from our servers? I?d love to see the mail headers so I can > talk to the enterprise mail team. > > Jason > > > > On 9/10/15, 1:37 PM, "NANOG on behalf of Mike Lyon" > wrote: > > >Really Comcast? Your spam software SUCKS ASS! > > > >For those interested, the word that violated their spam software was > >"damn" > > > >-Mike > > > > > >-------------------------------------------------------------------------- > >-- > > > >This email has violated the PROFANITY. > >and Pass has been taken on 9/10/2015 1:34:19 PM. > >Message details: > >Server: BUPMEXCASHUB2 > >Sender: mike.lyon at gmail.com; > >Recipient: > >nanog at ics-il.net;Corey_Petrulich at cable.comcast.com; > >Ken_Falkenstein at cable.comcast.com;nanog at nanog.org; > >Subject: Re: WiFI on utility poles > > > > > >The information in this message, including in all attachments, is > >confidential or privileged. In the event you have received this message in > >error > >and are not the intended recipient, you are hereby advised that any use, > >copying > >or reproduction of this document is strictly forbidden. Please notify > >immediately the sender of this error and destroy this message, including > >its > >attachments, as the case may be. > >

> >L'information apparaissant dans ce message electronique et dans les > >documents > >qui y sont joints est de nature confidentielle ou privilegiee. Si ce > >message > >vous est parvenu par erreur et que vous n'en etes pas le destinataire > >vise, > >vous > >etes par les presentes avise que toute utilisation, copie ou distribution > >de ce > >message est strictement interdite. Vous etes donc prie d?en informer > >immediatement l?expediteur et de detruire ce message, ainsi que les > >documents > >qui y sont joints, le cas echeant. > > > >On Thu, Sep 10, 2015 at 10:32 AM, Mike Lyon wrote: > > > >> A few dozen? Damn, you are lucy, Mike! > >> > >> I did an install the other day, a good 60-70 XfinityWifi SSIDs popped > >>up. > >> > >> Reminds me of the Good 'Ole CB days back in the 80's where everyone > >>talked > >> over each other and played background music and such... > >> > >> That's a big 10-4 and I got a Smokey on my trail! > >> > >> -Mike > >> > >> On Thu, Sep 10, 2015 at 10:15 AM, Mike Hammett > wrote: > >> > >>> The tower-deployed AP can see the cable wireless APs for miles and can > >>> see a few dozen of them at any one time. Given the goal of full > >>>modulation > >>> at all times for optimal use of spectrum and dollars, the ever > >>>increasing > >>> noise from the cable APs makes this a challenge. You need 25 to 30 dB > >>>to > >>> maintain full modulation and that's increasingly difficult when you > >>>hear > >>> cable APs everywhere at -70. > >>> > >>> The APs can't have narrow radiation patterns given that they need to > >>> cover a roughly 90* area of where the customers are. An 18 to 20 dB > >>>gain > >>> sector antenna will pick up those cable radios from pretty far away. > >>> > >>> > >>> > >>> > >>> ----- > >>> Mike Hammett > >>> Intelligent Computing Solutions > >>> http://www.ics-il.com > >>> > >>> > >>> > >>> Midwest Internet Exchange > >>> http://www.midwest-ix.com > >>> > >>> > >>> ----- Original Message ----- > >>> > >>> From: "Scott Helms" > >>> To: "Jared Mauch" > >>> Cc: "Mike Hammett" , "Corey Petrulich" < > >>> Corey_Petrulich at cable.comcast.com>, "Kenneth Falkenstein" < > >>> Ken_Falkenstein at cable.comcast.com>, "NANOG mailing list" > >>> >>> > > >>> Sent: Thursday, September 10, 2015 10:00:41 AM > >>> Subject: Re: WiFI on utility poles > >>> > >>> > >>> This sounds like a hypothetical complaint, AFAIK none of the members of > >>> the CableWiFi consortium are deploying APs outside of their footprint. > >>> Since most of the APs use a cable modem for their backhaul it's not > >>>really > >>> feasible to be without at least one broadband option (the cable MSO) > >>>and be > >>> impaired by the CableWiFi APs. > >>> > >>> > >>> Now, there is one potential exception to this I'm aware of which is > >>> Comcast's Xfinity on Campus service, but I'd expect the number of > >>>colleges > >>> they're servicing that aren't already getting cable broadband service > >>>to > >>> approach zero. > >>> > >>> > >>> > >>> > >>> > http://www.philly.com/philly/business/20150909_Comcast_streams_onto_coll > >>>ege_campuses.html > >>> > >>> > >>> > >>> https://xfinityoncampus.com/login > >>> > >>> > >>> > >>> > >>> > >>> Having said all of that, I'd agree that a good radio resource > >>>management > >>> approach would benefit all of us, including the CableWiFi guys. > >>> > >>> > >>> http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/ > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Scott Helms > >>> Vice President of Technology > >>> ZCorum > >>> (678) 507-5000 > >>> -------------------------------- > >>> http://twitter.com/kscotthelms > >>> -------------------------------- > >>> > >>> > >>> On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch < jared at puck.nether.net > > > >>> wrote: > >>> > >>> > >>> > >>> > On Sep 10, 2015, at 9:00 AM, Mike Hammett < nanog at ics-il.net > > wrote: > >>> > > >>> > 5 GHz noise levels affecting people whose primary means of Internet > >>> access is via fixed wireless . > >>> > > >>> > >>> This is a huge deal for those people like myself that depend on fixed > >>> wireless for access at home because there is no broadband available > >>>despite > >>> incentives given by cities and states and the federal government. > >>> > >>> The local WISPs are good at coordinating access in these ISM bands > >>> amongst themselves but when someone appears with a SSID without doing a > >>> peek at the spectrum (note: not a site survey, but actual spectrum > >>>view w/ > >>> waterfall, as site survey only checks for the channel width that the > >>>client > >>> radio is configured for, not al the 10, 15, 8, 30mhz wide variants). > >>> > >>> It?s just poor practice to show up and break something else because you > >>> can?t be bothered to notice the interference or noise floor you > >>>created. I > >>> suspect the hardware that Comcast is using doesn?t notice this > >>>interference > >>> or adjacent channel issues. With the FCC aiming to let cell carriers > >>>also > >>> clog the 5ghz ISM band it?s only going to get worse. > >>> > >>> - Jared > >>> > >>> > >>> > >>> > >> > >> > >> -- > >> Mike Lyon > >> 408-621-4826 > >> mike.lyon at gmail.com > >> > >> http://www.linkedin.com/in/mlyon > >> > >> > >> > >> > > > > > >-- > >Mike Lyon > >408-621-4826 > >mike.lyon at gmail.com > > > >http://www.linkedin.com/in/mlyon > > > > From mikea at mikea.ath.cx Thu Sep 10 18:17:14 2015 From: mikea at mikea.ath.cx (mikea) Date: Thu, 10 Sep 2015 13:17:14 -0500 Subject: WiFI on utility poles In-Reply-To: References: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> Message-ID: <20150910181714.GA15207@mikea.ath.cx> On Thu, Sep 10, 2015 at 02:06:14PM -0400, Josh Luthman wrote: > It's either Mike, Comcast or the NANOG list, so it's probably a safe bet. Bilingual English/French may indicate a Canadian mailserver. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From mikea at mikea.ath.cx Thu Sep 10 18:18:31 2015 From: mikea at mikea.ath.cx (mikea) Date: Thu, 10 Sep 2015 13:18:31 -0500 Subject: DamnTest: ignore Message-ID: <20150910181831.GB15207@mikea.ath.cx> This post includes the word Damn. damn -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From mike.lyon at gmail.com Thu Sep 10 18:23:50 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 10 Sep 2015 11:23:50 -0700 Subject: WiFI on utility poles In-Reply-To: References: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> Message-ID: My apologies, Comcast, I have an itchy trigger finger A little googling indicates that the mail server that was listed on that bounced email is a COGENT email server, not Comcast, My apologies for that. -Mike On Thu, Sep 10, 2015 at 10:37 AM, Mike Lyon wrote: > Really Comcast? Your spam software SUCKS ASS! > > For those interested, the word that violated their spam software was "damn" > > -Mike > > > > ---------------------------------------------------------------------------- > > This email has violated the PROFANITY. > and Pass has been taken on 9/10/2015 1:34:19 PM. > Message details: > Server: BUPMEXCASHUB2 > Sender: mike.lyon at gmail.com; > Recipient: > nanog at ics-il.net;Corey_Petrulich at cable.comcast.com; > Ken_Falkenstein at cable.comcast.com;nanog at nanog.org; > Subject: Re: WiFI on utility poles > > > The information in this message, including in all attachments, is > confidential or privileged. In the event you have received this message in > error > and are not the intended recipient, you are hereby advised that any use, > copying > or reproduction of this document is strictly forbidden. Please notify > immediately the sender of this error and destroy this message, including > its > attachments, as the case may be. >

> L'information apparaissant dans ce message electronique et dans les > documents > qui y sont joints est de nature confidentielle ou privilegiee. Si ce > message > vous est parvenu par erreur et que vous n'en etes pas le destinataire > vise, vous > etes par les presentes avise que toute utilisation, copie ou distribution > de ce > message est strictement interdite. Vous etes donc prie d?en informer > immediatement l?expediteur et de detruire ce message, ainsi que les > documents > qui y sont joints, le cas echeant. > > On Thu, Sep 10, 2015 at 10:32 AM, Mike Lyon wrote: > >> A few dozen? Damn, you are lucy, Mike! >> >> I did an install the other day, a good 60-70 XfinityWifi SSIDs popped up. >> >> Reminds me of the Good 'Ole CB days back in the 80's where everyone >> talked over each other and played background music and such... >> >> That's a big 10-4 and I got a Smokey on my trail! >> >> -Mike >> >> On Thu, Sep 10, 2015 at 10:15 AM, Mike Hammett wrote: >> >>> The tower-deployed AP can see the cable wireless APs for miles and can >>> see a few dozen of them at any one time. Given the goal of full modulation >>> at all times for optimal use of spectrum and dollars, the ever increasing >>> noise from the cable APs makes this a challenge. You need 25 to 30 dB to >>> maintain full modulation and that's increasingly difficult when you hear >>> cable APs everywhere at -70. >>> >>> The APs can't have narrow radiation patterns given that they need to >>> cover a roughly 90* area of where the customers are. An 18 to 20 dB gain >>> sector antenna will pick up those cable radios from pretty far away. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> Midwest Internet Exchange >>> http://www.midwest-ix.com >>> >>> >>> ----- Original Message ----- >>> >>> From: "Scott Helms" >>> To: "Jared Mauch" >>> Cc: "Mike Hammett" , "Corey Petrulich" < >>> Corey_Petrulich at cable.comcast.com>, "Kenneth Falkenstein" < >>> Ken_Falkenstein at cable.comcast.com>, "NANOG mailing list" < >>> nanog at nanog.org> >>> Sent: Thursday, September 10, 2015 10:00:41 AM >>> Subject: Re: WiFI on utility poles >>> >>> >>> This sounds like a hypothetical complaint, AFAIK none of the members of >>> the CableWiFi consortium are deploying APs outside of their footprint. >>> Since most of the APs use a cable modem for their backhaul it's not really >>> feasible to be without at least one broadband option (the cable MSO) and be >>> impaired by the CableWiFi APs. >>> >>> >>> Now, there is one potential exception to this I'm aware of which is >>> Comcast's Xfinity on Campus service, but I'd expect the number of colleges >>> they're servicing that aren't already getting cable broadband service to >>> approach zero. >>> >>> >>> >>> http://www.philly.com/philly/business/20150909_Comcast_streams_onto_college_campuses.html >>> >>> >>> >>> https://xfinityoncampus.com/login >>> >>> >>> >>> >>> >>> Having said all of that, I'd agree that a good radio resource management >>> approach would benefit all of us, including the CableWiFi guys. >>> >>> >>> http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/ >>> >>> >>> >>> >>> >>> >>> >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> >>> >>> On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch < jared at puck.nether.net > >>> wrote: >>> >>> >>> >>> > On Sep 10, 2015, at 9:00 AM, Mike Hammett < nanog at ics-il.net > wrote: >>> > >>> > 5 GHz noise levels affecting people whose primary means of Internet >>> access is via fixed wireless . >>> > >>> >>> This is a huge deal for those people like myself that depend on fixed >>> wireless for access at home because there is no broadband available despite >>> incentives given by cities and states and the federal government. >>> >>> The local WISPs are good at coordinating access in these ISM bands >>> amongst themselves but when someone appears with a SSID without doing a >>> peek at the spectrum (note: not a site survey, but actual spectrum view w/ >>> waterfall, as site survey only checks for the channel width that the client >>> radio is configured for, not al the 10, 15, 8, 30mhz wide variants). >>> >>> It?s just poor practice to show up and break something else because you >>> can?t be bothered to notice the interference or noise floor you created. I >>> suspect the hardware that Comcast is using doesn?t notice this interference >>> or adjacent channel issues. With the FCC aiming to let cell carriers also >>> clog the 5ghz ISM band it?s only going to get worse. >>> >>> - Jared >>> >>> >>> >>> >> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/mlyon >> >> >> >> > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From nathana at fsr.com Thu Sep 10 18:28:07 2015 From: nathana at fsr.com (Nathan Anderson) Date: Thu, 10 Sep 2015 11:28:07 -0700 Subject: DamnTest: ignore In-Reply-To: <20150910181831.GB15207@mikea.ath.cx> References: <20150910181831.GB15207@mikea.ath.cx> Message-ID: On Thu, Sep 10, 2015, mikea wrote: > This post includes the word Damn. > > damn Well, dayum. -- Nathan From mvoity at uvm.edu Thu Sep 10 18:37:54 2015 From: mvoity at uvm.edu (Michael T. Voity) Date: Thu, 10 Sep 2015 14:37:54 -0400 Subject: WiFI on utility poles In-Reply-To: References: <7500FD8F-654B-4268-B033-F6128E7A9620@uvm.edu> <55F0E263.3060306@uvm.edu> Message-ID: <55F1CE02.2020300@uvm.edu> Thank you all for your replies to the topic I have started. UVM does not purchase Xfinity on Campus for our students to have TV via their computers or device. However Xfinity usually has a both setup on move-in day for students to individually purchase accounts to watch stuff online. UVM provides its own wireless to all the Residential halls/dorm in 2.4/5Ghz spectrum. Comcast/Xfinity has 2 Nodes on campus that have nothing connected to them, just collecting dust and burning power. We see the addition of the Comcast/Xfinity AP's on the poles to either generate confusion and or interface to the already dirty wireless spectrum. Recently we are running into issue with DFS being 3 miles away from an airport and the TDWR. Thanks again folks and see you in Montreal! -Mike Michael Voity University of Vermont On 9/10/2015 8:53 AM, Livingood, Jason wrote: > You can learn more at http://wifi.xfinity.com/. There are more than 8M > hotspots around the country today and we?re doing more and more > outdoor / public area WiFi hotspots. In my area (Philadelphia) I hit > them all along the route that my commuter train takes, so it?s > convenient. > > The XFINITY SSID is new and uses WPA2 IIRC. > > The guys copied (Ken and Corey) are good contacts for any direct > questions about Comcast?s WiFi network. > > As an aside, it does not look like UVM is covered yet but we expanded > our free college streaming service this Fall and on campuses that have > Xfinity WiFi, it would presumably help students stream from more > places (see > http://corporate.comcast.com/comcast-voices/xfinity-on-campus-expands-comcast-now-brings-streaming-tv-to-24-colleges-and-universities). > > > - Jason > Comcast > > > On 9/9/15, 9:52 PM, "NANOG on behalf of Michael T. Voity" > on behalf of > mvoity at uvm.edu > wrote: > > Sorry folks, attachment didn't work. Here is the link - > > https://www.uvm.edu/~mvoity/pole.JPG > > > -Mike > > Michael Voity > University of Vermont > > On 9/9/15 9:24 PM, Michael T. Voity wrote: > > Hello, > > Today another colleague and I discovered the famous > 'xfinitywifi' ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' > on our University campus. After doing some poking around on > campus we found these gems (attached picture) on 2 utility > poles that pass by our east campus. Standing underneath it > I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards away > inside our hockey fieldhouse, through lots of brick, cinder > blocks and metal, I was still picking the 2.4Ghz at -64. > > Looks like the unit is getting power from the coax. > > > My question is, I've done a little poking around and have > not found anything substantial to learn more information about > this Comcast program. > > > Any insight would be nice! > > > Michael Voity > University of Vermont > > > > > From josh at imaginenetworksllc.com Thu Sep 10 18:43:29 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 10 Sep 2015 14:43:29 -0400 Subject: DamnTest: ignore In-Reply-To: References: <20150910181831.GB15207@mikea.ath.cx> Message-ID: cogeco.com is to blame Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Sep 10, 2015 at 2:28 PM, Nathan Anderson wrote: > On Thu, Sep 10, 2015, mikea wrote: > > > This post includes the word Damn. > > > > damn > > Well, dayum. > > -- Nathan > > From jmaslak at antelope.net Thu Sep 10 18:55:29 2015 From: jmaslak at antelope.net (Joel Maslak) Date: Thu, 10 Sep 2015 12:55:29 -0600 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <55F0E22C.4050206@cox.net> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> <55F0E22C.4050206@cox.net> Message-ID: Postel's Law seems relevant to this issue. Sorry for contributing to the noise. From landonstewart at gmail.com Thu Sep 10 19:13:55 2015 From: landonstewart at gmail.com (Landon Stewart) Date: Thu, 10 Sep 2015 12:13:55 -0700 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> <55F0E22C.4050206@cox.net> Message-ID: <4221D490-B791-4333-AF5B-F691475A2723@gmail.com> "Email Disclaimers: Legal Effect in American Courts" - http://www.rhlaw.com/blog/legal-effect-of-boilerplate-email-disclaimers/ "Automatic e-mail footers are not just annoying. They are legally useless" - http://www.economist.com/node/18529895 From johnl at iecc.com Thu Sep 10 19:17:23 2015 From: johnl at iecc.com (John Levine) Date: 10 Sep 2015 19:17:23 -0000 Subject: WiFI on utility poles In-Reply-To: Message-ID: <20150910191723.56922.qmail@ary.lan> In article you write: >My apologies, Comcast, I have an itchy trigger finger > >A little googling indicates that the mail server that was listed on that >bounced email is a COGENT email server, not Comcast, Sounds like COGECO which is a Canadian ISP. R's, John From Jason_Livingood at cable.comcast.com Thu Sep 10 19:24:10 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 10 Sep 2015 19:24:10 +0000 Subject: WiFI on utility poles In-Reply-To: References: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> Message-ID: Always getting blamed for Cogent stuff, no worries. ;-) - JL On 9/10/15, 2:23 PM, "NANOG on behalf of Mike Lyon" wrote: >My apologies, Comcast, I have an itchy trigger finger > >A little googling indicates that the mail server that was listed on that >bounced email is a COGENT email server, not Comcast, > >My apologies for that. > >-Mike > > >On Thu, Sep 10, 2015 at 10:37 AM, Mike Lyon wrote: > >> Really Comcast? Your spam software SUCKS ASS! >> >> For those interested, the word that violated their spam software was >>"damn" >> >> -Mike >> >> >> >> >>------------------------------------------------------------------------- >>--- >> >> This email has violated the PROFANITY. >> and Pass has been taken on 9/10/2015 1:34:19 PM. >> Message details: >> Server: BUPMEXCASHUB2 >> Sender: mike.lyon at gmail.com; >> Recipient: >> nanog at ics-il.net;Corey_Petrulich at cable.comcast.com; >> Ken_Falkenstein at cable.comcast.com;nanog at nanog.org; >> Subject: Re: WiFI on utility poles >> >> >> The information in this message, including in all attachments, is >> confidential or privileged. In the event you have received this message >>in >> error >> and are not the intended recipient, you are hereby advised that any use, >> copying >> or reproduction of this document is strictly forbidden. Please notify >> immediately the sender of this error and destroy this message, including >> its >> attachments, as the case may be. >>

>> L'information apparaissant dans ce message electronique et dans les >> documents >> qui y sont joints est de nature confidentielle ou privilegiee. Si ce >> message >> vous est parvenu par erreur et que vous n'en etes pas le destinataire >> vise, vous >> etes par les presentes avise que toute utilisation, copie ou >>distribution >> de ce >> message est strictement interdite. Vous etes donc prie d?en informer >> immediatement l?expediteur et de detruire ce message, ainsi que les >> documents >> qui y sont joints, le cas echeant. >> >> On Thu, Sep 10, 2015 at 10:32 AM, Mike Lyon wrote: >> >>> A few dozen? Damn, you are lucy, Mike! >>> >>> I did an install the other day, a good 60-70 XfinityWifi SSIDs popped >>>up. >>> >>> Reminds me of the Good 'Ole CB days back in the 80's where everyone >>> talked over each other and played background music and such... >>> >>> That's a big 10-4 and I got a Smokey on my trail! >>> >>> -Mike >>> >>> On Thu, Sep 10, 2015 at 10:15 AM, Mike Hammett >>>wrote: >>> >>>> The tower-deployed AP can see the cable wireless APs for miles and can >>>> see a few dozen of them at any one time. Given the goal of full >>>>modulation >>>> at all times for optimal use of spectrum and dollars, the ever >>>>increasing >>>> noise from the cable APs makes this a challenge. You need 25 to 30 dB >>>>to >>>> maintain full modulation and that's increasingly difficult when you >>>>hear >>>> cable APs everywhere at -70. >>>> >>>> The APs can't have narrow radiation patterns given that they need to >>>> cover a roughly 90* area of where the customers are. An 18 to 20 dB >>>>gain >>>> sector antenna will pick up those cable radios from pretty far away. >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> >>>> >>>> Midwest Internet Exchange >>>> http://www.midwest-ix.com >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Scott Helms" >>>> To: "Jared Mauch" >>>> Cc: "Mike Hammett" , "Corey Petrulich" < >>>> Corey_Petrulich at cable.comcast.com>, "Kenneth Falkenstein" < >>>> Ken_Falkenstein at cable.comcast.com>, "NANOG mailing list" < >>>> nanog at nanog.org> >>>> Sent: Thursday, September 10, 2015 10:00:41 AM >>>> Subject: Re: WiFI on utility poles >>>> >>>> >>>> This sounds like a hypothetical complaint, AFAIK none of the members >>>>of >>>> the CableWiFi consortium are deploying APs outside of their footprint. >>>> Since most of the APs use a cable modem for their backhaul it's not >>>>really >>>> feasible to be without at least one broadband option (the cable MSO) >>>>and be >>>> impaired by the CableWiFi APs. >>>> >>>> >>>> Now, there is one potential exception to this I'm aware of which is >>>> Comcast's Xfinity on Campus service, but I'd expect the number of >>>>colleges >>>> they're servicing that aren't already getting cable broadband service >>>>to >>>> approach zero. >>>> >>>> >>>> >>>> >>>>http://www.philly.com/philly/business/20150909_Comcast_streams_onto_col >>>>lege_campuses.html >>>> >>>> >>>> >>>> https://xfinityoncampus.com/login >>>> >>>> >>>> >>>> >>>> >>>> Having said all of that, I'd agree that a good radio resource >>>>management >>>> approach would benefit all of us, including the CableWiFi guys. >>>> >>>> >>>> http://www.cablelabs.com/wi-fi-radio-resource-management-rrm/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Scott Helms >>>> Vice President of Technology >>>> ZCorum >>>> (678) 507-5000 >>>> -------------------------------- >>>> http://twitter.com/kscotthelms >>>> -------------------------------- >>>> >>>> >>>> On Thu, Sep 10, 2015 at 10:52 AM, Jared Mauch < jared at puck.nether.net >>>>> >>>> wrote: >>>> >>>> >>>> >>>> > On Sep 10, 2015, at 9:00 AM, Mike Hammett < nanog at ics-il.net > >>>>wrote: >>>> > >>>> > 5 GHz noise levels affecting people whose primary means of Internet >>>> access is via fixed wireless . >>>> > >>>> >>>> This is a huge deal for those people like myself that depend on fixed >>>> wireless for access at home because there is no broadband available >>>>despite >>>> incentives given by cities and states and the federal government. >>>> >>>> The local WISPs are good at coordinating access in these ISM bands >>>> amongst themselves but when someone appears with a SSID without doing >>>>a >>>> peek at the spectrum (note: not a site survey, but actual spectrum >>>>view w/ >>>> waterfall, as site survey only checks for the channel width that the >>>>client >>>> radio is configured for, not al the 10, 15, 8, 30mhz wide variants). >>>> >>>> It?s just poor practice to show up and break something else because >>>>you >>>> can?t be bothered to notice the interference or noise floor you >>>>created. I >>>> suspect the hardware that Comcast is using doesn?t notice this >>>>interference >>>> or adjacent channel issues. With the FCC aiming to let cell carriers >>>>also >>>> clog the 5ghz ISM band it?s only going to get worse. >>>> >>>> - Jared >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Mike Lyon >>> 408-621-4826 >>> mike.lyon at gmail.com >>> >>> http://www.linkedin.com/in/mlyon >>> >>> >>> >>> >> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/mlyon >> >> >> >> > > >-- >Mike Lyon >408-621-4826 >mike.lyon at gmail.com > >http://www.linkedin.com/in/mlyon From surfer at mauigateway.com Thu Sep 10 19:38:03 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 10 Sep 2015 12:38:03 -0700 Subject: BGAN Optimized Laptops Message-ID: <20150910123803.B81CFB96@m0087793.ppops.net> Anyone use or know how these work with the satellite networks? http://www.groundcontrol.com/BGAN_Optimized_Laptop.htm Off list is fine... scott From tgrand at tgrand.com Thu Sep 10 20:06:33 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Thu, 10 Sep 2015 15:06:33 -0500 Subject: outlook.com outgoing blacklists? In-Reply-To: References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> <53F2C909272A4678AA72A35223DA04D6@ToddDev> <8B08961BEC724F64BE26A5188A962AB4@ToddDev> Message-ID: <12D6BE1D64BE4089BA45476B1BCE46FE@ToddDev> The problem has been resolved. Thanks to everybody that contributed. From keiths at neilltech.com Thu Sep 10 20:09:55 2015 From: keiths at neilltech.com (Keith Stokes) Date: Thu, 10 Sep 2015 20:09:55 +0000 Subject: outlook.com outgoing blacklists? In-Reply-To: <12D6BE1D64BE4089BA45476B1BCE46FE@ToddDev> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> <53F2C909272A4678AA72A35223DA04D6@ToddDev> <8B08961BEC724F64BE26A5188A962AB4@ToddDev> <12D6BE1D64BE4089BA45476B1BCE46FE@ToddDev> Message-ID: <748CF8C1-5021-4DF4-A6CB-0A6EF43FD232@neilltech.com> Well now you have to share the answer. On Sep 10, 2015, at 3:06 PM, Todd K Grand > wrote: The problem has been resolved. Thanks to everybody that contributed. --- Keith Stokes From saper at saper.info Thu Sep 10 20:11:04 2015 From: saper at saper.info (Marcin Cieslak) Date: Thu, 10 Sep 2015 20:11:04 +0000 Subject: outlook.com outgoing blacklists? In-Reply-To: <12D6BE1D64BE4089BA45476B1BCE46FE@ToddDev> References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> <53F2C909272A4678AA72A35223DA04D6@ToddDev> <8B08961BEC724F64BE26A5188A962AB4@ToddDev> <12D6BE1D64BE4089BA45476B1BCE46FE@ToddDev> Message-ID: On Thu, 10 Sep 2015, Todd K Grand wrote: > The problem has been resolved. > Thanks to everybody that contributed. And the issue was...? ~Marcin From Andrew.White2 at charter.com Thu Sep 10 15:33:58 2015 From: Andrew.White2 at charter.com (White, Andrew) Date: Thu, 10 Sep 2015 10:33:58 -0500 Subject: NetFlow - path from Routers to Collector In-Reply-To: <003701d0ebd6$35a6d8c0$a0f48a40$@iname.com> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <20150901174406.GB28155@puck.nether.net> <201716EA-D1D0-4302-8FAB-E8A11FC82F20@arbor.net> <003701d0ebd6$35a6d8c0$a0f48a40$@iname.com> Message-ID: <678FDBA32DA0DD4A8EFB6D1C2FDC268A01EF92A024@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> $50 on ebay http://www.ebay.com/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313.TR12.TRC2.A0.H0.Xconsole+server.TRS0&_nkw=console+server&_sacat=0 Andrew White Desk: 314.394-9594 | Cell: 314.308-7730 NetOps Consultant, DAS DNS group Charter Communications 12405 Powerscourt Drive St. Louis, MO 63131 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk Sent: Thursday, September 10, 2015 9:37 AM To: 'Roland Dobbins'; nanog at nanog.org Subject: RE: NetFlow - path from Routers to Collector Does anyone else have a serial to IP dongle for devices that are IP only? That dongle would need to have telnet and SSH support. Or an IP-to-IP dongle, that would support a routing table? There's Brocade kit that has a mgmt. port, but it doesn't have its own routing table (they now have a mgmt. vrf in some software releases), making it local-only or something you have to use some kind of pseudo-NAT (all public IPs are translated to mgmt-network IPs). Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Tuesday, September 01, 2015 6:23 PM To: nanog at nanog.org Subject: Re: NetFlow - path from Routers to Collector Absolutely. All kinds of creative lashups to get console access in difficult situations (and, as you noted previously, an increasing number of devices don't support serial console at all, which is highly annoying). ----------------------------------- Roland Dobbins From michael at englehorn.com Thu Sep 10 17:47:48 2015 From: michael at englehorn.com (Michael Englehorn) Date: Thu, 10 Sep 2015 12:47:48 -0500 Subject: WiFI on utility poles In-Reply-To: References: <81607315.3865.1441852340120.JavaMail.mhammett@ThunderFuck> Message-ID: <55F1C244.5080204@englehorn.com> My issue with the "free" wifi that comcast is forcing into our homes and businesses is that it's also interfering with our own access points in the same building! - Michael On 9/10/2015 7:56 AM, Livingood, Jason wrote: > If you run across any you think are terribly placed, feel free to email > Corey and Ken with the location and your thoughts on better placement. > > - Jason > > > > > On 9/9/15, 10:31 PM, "NANOG on behalf of Mike Hammett" > wrote: > >> Usually terribly placed, like a shotgun blast instead of strategic >> locations. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> Midwest Internet Exchange >> http://www.midwest-ix.com >> >> >> ----- Original Message ----- >> >> From: "Mike Lyon" >> To: "Phil Bedard" >> Cc: "NANOG" >> Sent: Wednesday, September 9, 2015 9:23:46 PM >> Subject: Re: WiFI on utility poles >> >> And they are as annoying as f*&k! and litter the already noisy 5 Ghz >> unlicensed band, Hopefully, the sun will fry them dead over time. >> >> -Mike >> >> >> On Wed, Sep 9, 2015 at 7:19 PM, Phil Bedard >> wrote: >> >>> There are Comcast people on the list who may have more info, but it?s >>> just >>> expansion of their WiFi hotspot network and part of the CableWifi >>> consortium. http://www.cablewifi.com, or you can go to >>> http://wifi.xfinity.com to see Comcast?s specific deployment. >>> >>> Cable companies have thousands of strand-mount Wifi APs deployed at >>> this >>> point. >>> >>> >>> Phil >>> >>> >>> >>> >>> -----Original Message----- >>> From: NANOG on behalf of "Michael T. Voity" >>> Organization: University of Vermont and State Agricultural College >>> Date: Wednesday, September 9, 2015 at 21:52 >>> To: >>> Subject: Re: WiFI on utility poles >>> >>>> Sorry folks, attachment didn't work. Here is the link - >>>> >>>> https://www.uvm.edu/~mvoity/pole.JPG >>>> >>>> -Mike >>>> >>>> Michael Voity >>>> University of Vermont >>>> >>>> On 9/9/15 9:24 PM, Michael T. Voity wrote: >>>>> Hello, >>>>> >>>>> Today another colleague and I discovered the famous 'xfinitywifi' >>> ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University >>> campus. >>> After doing some poking around on campus we found these gems (attached >>> picture) on 2 utility poles that pass by our east campus. Standing >>> underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards >>> away inside our hockey fieldhouse, through lots of brick, cinder blocks >>> and metal, I was still picking the 2.4Ghz at -64. >>>>> >>>>> Looks like the unit is getting power from the coax. >>>>> >>>>> >>>>> My question is, I've done a little poking around and have not found >>> anything substantial to learn more information about this Comcast >>> program. >>>>> >>>>> >>>>> Any insight would be nice! >>>>> >>>>> >>>>> Michael Voity >>>>> University of Vermont >>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/mlyon >> >> > From mike.lyon at gmail.com Thu Sep 10 20:22:46 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 10 Sep 2015 13:22:46 -0700 Subject: WiFI on utility poles In-Reply-To: <55F1C244.5080204@englehorn.com> References: <81607315.3865.1441852340120.JavaMail.mhammett@ThunderFuck> <55F1C244.5080204@englehorn.com> Message-ID: And it's not free, unless you are a Comcast or TW customer :( On Sep 10, 2015 1:21 PM, "Michael Englehorn" wrote: > My issue with the "free" wifi that comcast is forcing into our homes and > businesses is that it's also interfering with our own access points in > the same building! > > - Michael > > On 9/10/2015 7:56 AM, Livingood, Jason wrote: > > If you run across any you think are terribly placed, feel free to email > > Corey and Ken with the location and your thoughts on better placement. > > > > - Jason > > > > > > > > > > On 9/9/15, 10:31 PM, "NANOG on behalf of Mike Hammett" > > wrote: > > > >> Usually terribly placed, like a shotgun blast instead of strategic > >> locations. > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> > >> > >> Midwest Internet Exchange > >> http://www.midwest-ix.com > >> > >> > >> ----- Original Message ----- > >> > >> From: "Mike Lyon" > >> To: "Phil Bedard" > >> Cc: "NANOG" > >> Sent: Wednesday, September 9, 2015 9:23:46 PM > >> Subject: Re: WiFI on utility poles > >> > >> And they are as annoying as f*&k! and litter the already noisy 5 Ghz > >> unlicensed band, Hopefully, the sun will fry them dead over time. > >> > >> -Mike > >> > >> > >> On Wed, Sep 9, 2015 at 7:19 PM, Phil Bedard > >> wrote: > >> > >>> There are Comcast people on the list who may have more info, but it?s > >>> just > >>> expansion of their WiFi hotspot network and part of the CableWifi > >>> consortium. http://www.cablewifi.com, or you can go to > >>> http://wifi.xfinity.com to see Comcast?s specific deployment. > >>> > >>> Cable companies have thousands of strand-mount Wifi APs deployed at > >>> this > >>> point. > >>> > >>> > >>> Phil > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: NANOG on behalf of "Michael T. Voity" > >>> Organization: University of Vermont and State Agricultural College > >>> Date: Wednesday, September 9, 2015 at 21:52 > >>> To: > >>> Subject: Re: WiFI on utility poles > >>> > >>>> Sorry folks, attachment didn't work. Here is the link - > >>>> > >>>> https://www.uvm.edu/~mvoity/pole.JPG > >>>> > >>>> -Mike > >>>> > >>>> Michael Voity > >>>> University of Vermont > >>>> > >>>> On 9/9/15 9:24 PM, Michael T. Voity wrote: > >>>>> Hello, > >>>>> > >>>>> Today another colleague and I discovered the famous 'xfinitywifi' > >>> ,'CableWIFi', 'CoxWiFi' and a new one 'XFINITY' on our University > >>> campus. > >>> After doing some poking around on campus we found these gems (attached > >>> picture) on 2 utility poles that pass by our east campus. Standing > >>> underneath it I got a -46 RSSI in both 5 and 2.4Ghz, maybe 75-100 yards > >>> away inside our hockey fieldhouse, through lots of brick, cinder blocks > >>> and metal, I was still picking the 2.4Ghz at -64. > >>>>> > >>>>> Looks like the unit is getting power from the coax. > >>>>> > >>>>> > >>>>> My question is, I've done a little poking around and have not found > >>> anything substantial to learn more information about this Comcast > >>> program. > >>>>> > >>>>> > >>>>> Any insight would be nice! > >>>>> > >>>>> > >>>>> Michael Voity > >>>>> University of Vermont > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > >> > >> -- > >> Mike Lyon > >> 408-621-4826 > >> mike.lyon at gmail.com > >> > >> http://www.linkedin.com/in/mlyon > >> > >> > > > From tgrand at tgrand.com Thu Sep 10 20:29:21 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Thu, 10 Sep 2015 15:29:21 -0500 Subject: NetFlow - path from Routers to Collector In-Reply-To: <678FDBA32DA0DD4A8EFB6D1C2FDC268A01EF92A024@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> <20150901161042.GD1025@Vurt.local> <1947B6D4-994D-4C04-AFE9-D940BCE8FE7E@arbor.net> <8A2AD148-2748-4633-AB7B-B6D227C3D0B4@arbor.net> <20150901171851.GD4116@excession.tpb.net> <55E5E114.2030905@ronan-online.com> <20150901174406.GB28155@puck.nether.net> <201716EA-D1D0-4302-8FAB-E8A11FC82F20@arbor.net> <003701d0ebd6$35a6d8c0$a0f48a40$@iname.com> <678FDBA32DA0DD4A8EFB6D1C2FDC268A01EF92A024@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> Message-ID: <6F18235DF9C24CDDB2BEF91FD5830889@ToddDev> Mikrotik router-boards can be used as a serial to IP converter. Complete with rip, ospf, bgp, etc. -----Original Message----- From: White, Andrew Sent: Thursday, September 10, 2015 10:33 AM To: Frank Bulk ; 'Roland Dobbins' ; nanog at nanog.org Subject: RE: NetFlow - path from Routers to Collector $50 on ebay http://www.ebay.com/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313.TR12.TRC2.A0.H0.Xconsole+server.TRS0&_nkw=console+server&_sacat=0 Andrew White Desk: 314.394-9594 | Cell: 314.308-7730 NetOps Consultant, DAS DNS group Charter Communications 12405 Powerscourt Drive St. Louis, MO 63131 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk Sent: Thursday, September 10, 2015 9:37 AM To: 'Roland Dobbins'; nanog at nanog.org Subject: RE: NetFlow - path from Routers to Collector Does anyone else have a serial to IP dongle for devices that are IP only? That dongle would need to have telnet and SSH support. Or an IP-to-IP dongle, that would support a routing table? There's Brocade kit that has a mgmt. port, but it doesn't have its own routing table (they now have a mgmt. vrf in some software releases), making it local-only or something you have to use some kind of pseudo-NAT (all public IPs are translated to mgmt-network IPs). Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Tuesday, September 01, 2015 6:23 PM To: nanog at nanog.org Subject: Re: NetFlow - path from Routers to Collector Absolutely. All kinds of creative lashups to get console access in difficult situations (and, as you noted previously, an increasing number of devices don't support serial console at all, which is highly annoying). ----------------------------------- Roland Dobbins From tgrand at tgrand.com Thu Sep 10 20:31:52 2015 From: tgrand at tgrand.com (Todd K Grand) Date: Thu, 10 Sep 2015 15:31:52 -0500 Subject: outlook.com outgoing blacklists? In-Reply-To: References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> <53F2C909272A4678AA72A35223DA04D6@ToddDev> <8B08961BEC724F64BE26A5188A962AB4@ToddDev> <12D6BE1D64BE4089BA45476B1BCE46FE@ToddDev> Message-ID: Turns out that there is in fact a list of sorts. There were some days that the server was unavailable, and the domain was added to this list. The point of the list is unclear, but there is a list. -----Original Message----- From: Marcin Cieslak Sent: Thursday, September 10, 2015 3:11 PM To: Todd K Grand Cc: nanog list Subject: Re: outlook.com outgoing blacklists? On Thu, 10 Sep 2015, Todd K Grand wrote: > The problem has been resolved. > Thanks to everybody that contributed. And the issue was...? ~Marcin From jimpop at gmail.com Thu Sep 10 20:42:01 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 10 Sep 2015 16:42:01 -0400 Subject: WiFI on utility poles In-Reply-To: References: <81607315.3865.1441852340120.JavaMail.mhammett@ThunderFuck> <55F1C244.5080204@englehorn.com> Message-ID: On Thu, Sep 10, 2015 at 4:22 PM, Mike Lyon wrote: > And it's not free, unless you are a Comcast or TW customer :( But it is free to the children of C&TW customers who then can watch HD content while away at Uni without sapping the EDU bandwidth. -Jim P. From mjwise at kapu.net Thu Sep 10 20:53:44 2015 From: mjwise at kapu.net (Michael J Wise) Date: Thu, 10 Sep 2015 13:53:44 -0700 Subject: outlook.com outgoing blacklists? In-Reply-To: References: <176E1425-76A7-4529-981A-9336A320E416@blighty.com> <1DFEDFB800C5495B8BEC7851616638C4@ToddDev> <53F2C909272A4678AA72A35223DA04D6@ToddDev> <8B08961BEC724F64BE26A5188A962AB4@ToddDev> <12D6BE1D64BE4089BA45476B1BCE46FE@ToddDev> Message-ID: <0ff7f3afccf11deb85e222ff3184f664.squirrel@secure.kapu.net> > Turns out that there is in fact a list of sorts. > There were some days that the server was unavailable, and the domain was > added to this list. > The point of the list is unclear, but there is a list. I am not partial to the exact details, but it does appear that some action was taken and the issue was resolved. Past that, I don't have any further details that I can share. Main take-away: Don't have all of a domain's MXen be unavailable for more than a day...? > -----Original Message----- > From: Marcin Cieslak > Sent: Thursday, September 10, 2015 3:11 PM > To: Todd K Grand > Cc: nanog list > Subject: Re: outlook.com outgoing blacklists? > > On Thu, 10 Sep 2015, Todd K Grand wrote: > >> The problem has been resolved. >> Thanks to everybody that contributed. > > And the issue was...? > > ~Marcin > > Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause. From jimpop at gmail.com Thu Sep 10 21:00:54 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 10 Sep 2015 17:00:54 -0400 Subject: WiFI on utility poles In-Reply-To: References: <81607315.3865.1441852340120.JavaMail.mhammett@ThunderFuck> <55F1C244.5080204@englehorn.com> Message-ID: On Thu, Sep 10, 2015 at 4:53 PM, Hunter Fuller wrote: > Ehh... All that content is going over Internet2 for us anyway. I'm genuinely curious, is that is optimized for HD delivery from TW and C, or such services as Netflix/YouTube, etc. -Jim P. From bill at herrin.us Thu Sep 10 21:38:59 2015 From: bill at herrin.us (William Herrin) Date: Thu, 10 Sep 2015 17:38:59 -0400 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <4221D490-B791-4333-AF5B-F691475A2723@gmail.com> References: <20150906121837.99C9744E@m0005309.ppops.net> <55EEA2BE.5090604@cox.net> <1515735780-1441805800-cardhu_decombobulator_blackberry.rim.net-1712088326-@b13.c3.bise6.blackberry> <55F0E22C.4050206@cox.net> <4221D490-B791-4333-AF5B-F691475A2723@gmail.com> Message-ID: On Thu, Sep 10, 2015 at 3:13 PM, Landon Stewart wrote: > "Email Disclaimers: Legal Effect in American Courts" > - http://www.rhlaw.com/blog/legal-effect-of-boilerplate-email-disclaimers/ > > "Automatic e-mail footers are not just annoying. They are legally useless" > - http://www.economist.com/node/18529895 I don't have a handy reference, but as I understand it there's a legal problem with confidentiality boilerplate showing up on a mailing list: it demonstrates that the sender "doesn't mean it." A defendant in a case involving some other email can claim that the words mean nothing because the company's emails always say that even when they're obviously broadcast to the public in general. The defendant can claim a good faith belief that they didn't mean it this time either. And the court will agree. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rdobbins at arbor.net Fri Sep 11 00:18:50 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 11 Sep 2015 07:18:50 +0700 Subject: BGAN Optimized Laptops In-Reply-To: <20150910123803.B81CFB96@m0087793.ppops.net> References: <20150910123803.B81CFB96@m0087793.ppops.net> Message-ID: On 11 Sep 2015, at 2:38, Scott Weeks wrote: > Anyone use or know how these work with the satellite networks? All the features this supposedly has which makes it optimized for constrained-bandwidth environments, one can accomplish with any *NIX, including OSX (LittleSnitch provides a nice GUI for it). ----------------------------------- Roland Dobbins From don at bowenvale.co.nz Fri Sep 11 00:23:16 2015 From: don at bowenvale.co.nz (Don Gould) Date: Fri, 11 Sep 2015 12:23:16 +1200 Subject: Cogentoo BGP Contact please? Message-ID: <55F21EF4.4000800@bowenvale.co.nz> Hi, I've just moved 117.121.247.0/24 to a new provider (Cyberwurx) but our older provider still seems to have some fitlers loaded with you and I'm having trouble getting to their NOC team to sort it out. Is there anyone on list with clue who can help and/or point me to someone who can? D 1. 202.68.81.105 0.0% 2967 0.2 0.2 0.2 5.3 0.1 2. 202.174.181.1 0.0% 2967 20.5 20.2 20.1 83.2 2.0 3. v899.cr1.alb.akl.dtsanz.com 0.0% 2967 20.8 20.6 20.3 55.0 2.1 4. v890-u.cr1.alb.akl.dtsanz.com 0.0% 2967 21.5 23.2 21.3 114.5 8.7 5. as45177-ic-310274-las-b3.c.telia.net 0.0% 2967 144.7 147.1 144.4 233.1 9.6 6. las-b3-link.telia.net 0.0% 2967 157.8 158.0 157.6 199.2 2.7 7. las-b21-link.telia.net 0.0% 2967 158.9 157.6 157.3 187.8 1.5 8. be3052.ccr23.lax05.atlas.cogentco.com 0.0% 2967 159.5 159.2 158.7 207.7 2.1 9. be2180.ccr21.lax01.atlas.cogentco.com 0.0% 2967 158.2 158.1 157.8 197.9 1.2 10. be2065.ccr21.iah01.atlas.cogentco.com 0.0% 2967 193.7 193.5 193.1 230.7 1.0 11. be2687.ccr41.atl01.atlas.cogentco.com 0.0% 2967 207.5 207.2 206.9 251.5 1.2 12. te0-3-1-7.agr22.atl01.atlas.cogentco.com 0.0% 2967 207.8 207.8 207.6 252.4 1.3 13. gi0-0-0-1.nr11.b000173-2.atl01.atlas.cogentco.com 0.0% 2967 208.5 208.1 207.9 255.3 1.9 14. 38.88.191.250 0.2% 2967 208.9 209.3 208.5 411.8 11.5 15. ??? -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 Ph: +61 3 9111 1821 (Melb) I'M COLLECTING COFFEE CUPS FOR PROJECT COFFEE CUP. Deja vue (missing the French accent mark) - literally means already seen, that sense of haven't we been here before. From hf0002+nanog at uah.edu Thu Sep 10 20:53:12 2015 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Thu, 10 Sep 2015 15:53:12 -0500 Subject: WiFI on utility poles In-Reply-To: References: <81607315.3865.1441852340120.JavaMail.mhammett@ThunderFuck> <55F1C244.5080204@englehorn.com> Message-ID: Ehh... All that content is going over Internet2 for us anyway. I'd suspect that's a somewhat common thread (though not ubiquitous). On Thu, Sep 10, 2015 at 3:42 PM, Jim Popovitch wrote: > On Thu, Sep 10, 2015 at 4:22 PM, Mike Lyon wrote: >> And it's not free, unless you are a Comcast or TW customer :( > > But it is free to the children of C&TW customers who then can watch HD > content while away at Uni without sapping the EDU bandwidth. > > -Jim P. From hf0002+nanog at uah.edu Thu Sep 10 21:02:33 2015 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Thu, 10 Sep 2015 16:02:33 -0500 Subject: WiFI on utility poles In-Reply-To: References: <81607315.3865.1441852340120.JavaMail.mhammett@ThunderFuck> <55F1C244.5080204@englehorn.com> Message-ID: Oh, sorry, that was unclear. I meant that the majority of our streaming traffic is going over I2. Netflix, YouTube, services backed by Akamai, etc. If students were to use their cable companies' streaming services, those would likely be commodity Internet. But those don't even show up in our top 25 traffic usually, where Netflix and Google are normally within the top 5. On Thu, Sep 10, 2015 at 4:00 PM, Jim Popovitch wrote: > On Thu, Sep 10, 2015 at 4:53 PM, Hunter Fuller wrote: >> Ehh... All that content is going over Internet2 for us anyway. > > I'm genuinely curious, is that is optimized for HD delivery from TW > and C, or such services as Netflix/YouTube, etc. > > -Jim P. From surfer at mauigateway.com Fri Sep 11 01:14:13 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 10 Sep 2015 18:14:13 -0700 Subject: BGAN Optimized Laptops Message-ID: <20150910181413.B81CD9DA@m0087793.ppops.net> --- rdobbins at arbor.net wrote: From: "Roland Dobbins" On 11 Sep 2015, at 2:38, Scott Weeks wrote: > Anyone use or know how these work with the satellite networks? All the features this supposedly has which makes it optimized for constrained-bandwidth environments, one can accomplish with any *NIX, including OSX (LittleSnitch provides a nice GUI for it). --------------------------------------- I was wondering if there was something like Opera Mobile's "optimizer server" in the satellite operator's network: https://en.wikipedia.org/wiki/Opera_Mobile "...it can use Opera Turbo that compresses web pages via Opera Software's "Turbo" servers, thus reducing download size..." But, I am finding out that apparently there's not. I looked at LittleSnitch and see it seems a little different. The folks I'm talking to are on far-flung atolls where BW is so expensive it's shocking. So, I was wondering how the laptop company stops flash and images from transiting the satellite link. Someone told me that there is a way for the browser to say to the web server, send me only the parts of the web page I request. For example, send me everything but the flash and images. Being a browser wuss I thought the web server just sent everything and the browser decided whether to display it or not. That would mean the data already was transferred over the expensive sat link incurring the data costs. scott From jared at puck.nether.net Fri Sep 11 01:16:07 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 10 Sep 2015 21:16:07 -0400 Subject: WiFI on utility poles In-Reply-To: <55F1C244.5080204@englehorn.com> References: <81607315.3865.1441852340120.JavaMail.mhammett@ThunderFuck> <55F1C244.5080204@englehorn.com> Message-ID: <0141EE78-AB3E-4C0B-B9A0-1D6BBFE5A324@puck.nether.net> > On Sep 10, 2015, at 1:47 PM, Michael Englehorn wrote: > > My issue with the "free" wifi that comcast is forcing into our homes and > businesses is that it's also interfering with our own access points in > the same building! > [resending due to hitting limit on file size to nanog list] This is the biggest problem I?ve seen regarding this. If you care about 5ghz please provide feedback about the LTE-U stuff and encourage the cablewifi, wayport, etc to do a proper listen-before-use similar to what is required with DFS to avoid interference. Here?s a sample of what a spectrum might look like: http://puck.nether.net/~jared/airview_20150910_210354.png and http://puck.nether.net/~jared/airview_20150910_211313.png You can clearly see things at the various frequencies but without looking at the waveform you may not see the 40mhz user and where their center frequency is. If they are just sending beacons it may look different. A ?site survey? isn?t a spectrum view as your receiver may not understand what is going on. This is the UBNT 5ghz AC radio which is quite handy, but it as it?s an 802.11 device it may not see other things that use the ISM band and aren?t 802.11 based. These do exist, eg: mimosa b5, af-5/af-5x. These may use different frequencies for TX vs RX as well. Either way, I figure this is interesting enough to share if you aren?t doing WISP stuff or looking at spectrum often. - Jared From kmedcalf at dessus.com Fri Sep 11 01:35:09 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 10 Sep 2015 19:35:09 -0600 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: <4221D490-B791-4333-AF5B-F691475A2723@gmail.com> Message-ID: > "Email Disclaimers: Legal Effect in American Courts" > - http://www.rhlaw.com/blog/legal-effect-of-boilerplate-email-disclaimers/ Dark grey text on a black background is unreadable. Plonk goes the website. From rdobbins at arbor.net Fri Sep 11 01:49:27 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 11 Sep 2015 08:49:27 +0700 Subject: BGAN Optimized Laptops In-Reply-To: <20150910181413.B81CD9DA@m0087793.ppops.net> References: <20150910181413.B81CD9DA@m0087793.ppops.net> Message-ID: On 11 Sep 2015, at 8:14, Scott Weeks wrote: > For example, send me everything but the flash and images. This is a preference setting on most Web browsers. Lynx works well for this, too, on *NIX systems, if the users can use a terminal. Equivalent for email clients - headers-only, only download message on demand, only download attachments on demand, etc. ----------------------------------- Roland Dobbins From nanog at ics-il.net Fri Sep 11 01:52:18 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 10 Sep 2015 20:52:18 -0500 (CDT) Subject: WiFI on utility poles In-Reply-To: <0141EE78-AB3E-4C0B-B9A0-1D6BBFE5A324@puck.nether.net> Message-ID: <1445074251.5963.1441936401060.JavaMail.mhammett@ThunderFuck> AirView will see everything. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Michael Englehorn" Cc: nanog at nanog.org Sent: Thursday, September 10, 2015 8:16:07 PM Subject: Re: WiFI on utility poles > On Sep 10, 2015, at 1:47 PM, Michael Englehorn wrote: > > My issue with the "free" wifi that comcast is forcing into our homes and > businesses is that it's also interfering with our own access points in > the same building! > [resending due to hitting limit on file size to nanog list] This is the biggest problem I?ve seen regarding this. If you care about 5ghz please provide feedback about the LTE-U stuff and encourage the cablewifi, wayport, etc to do a proper listen-before-use similar to what is required with DFS to avoid interference. Here?s a sample of what a spectrum might look like: http://puck.nether.net/~jared/airview_20150910_210354.png and http://puck.nether.net/~jared/airview_20150910_211313.png You can clearly see things at the various frequencies but without looking at the waveform you may not see the 40mhz user and where their center frequency is. If they are just sending beacons it may look different. A ?site survey? isn?t a spectrum view as your receiver may not understand what is going on. This is the UBNT 5ghz AC radio which is quite handy, but it as it?s an 802.11 device it may not see other things that use the ISM band and aren?t 802.11 based. These do exist, eg: mimosa b5, af-5/af-5x. These may use different frequencies for TX vs RX as well. Either way, I figure this is interesting enough to share if you aren?t doing WISP stuff or looking at spectrum often. - Jared From blakjak at blakjak.net Fri Sep 11 02:18:33 2015 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 11 Sep 2015 14:18:33 +1200 Subject: BGAN Optimized Laptops In-Reply-To: References: <20150910181413.B81CD9DA@m0087793.ppops.net> Message-ID: <55F239F9.7020407@blakjak.net> On 11/09/2015 1:49 p.m., Roland Dobbins wrote: > > On 11 Sep 2015, at 8:14, Scott Weeks wrote: > >> For example, send me everything but the flash and images. > > This is a preference setting on most Web browsers. Lynx works well > for this, too, on *NIX systems, if the users can use a terminal. > > Equivalent for email clients - headers-only, only download message on > demand, only download attachments on demand, etc. My first thought on seeing the post was the work I used to do for satellite-linked networks around TCP config optimisation. This was on XP clients so i've no idea how aplicable it is to more modern desktops, but the simple way was to make use of tools such as TCP Optimizer[1]. Also had a lot of success with WAFS type devices such as the Riverbed Steelhead and their ilk, which goes a bit beyond OP's scope, in terms of making low-bandwidth high-latency links more optimal. Cheers Mark. [1] http://www.speedguide.net/downloads.php and http://www.speedguide.net/articles.php?category=99 which I note talks about Windows 7,8,10 and 2012 server, so this must still be a 'thing'. From mpetach at netflight.com Fri Sep 11 02:54:50 2015 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 10 Sep 2015 19:54:50 -0700 Subject: BGAN Optimized Laptops In-Reply-To: <20150910181413.B81CD9DA@m0087793.ppops.net> References: <20150910181413.B81CD9DA@m0087793.ppops.net> Message-ID: On Thu, Sep 10, 2015 at 6:14 PM, Scott Weeks wrote: > ... > > Someone told me that there is a way for the browser to say > to the web server, send me only the parts of the web page I > request. For example, send me everything but the flash and > images. Being a browser wuss I thought the web server just > sent everything and the browser decided whether to display > it or not. That would mean the data already was transferred > over the expensive sat link incurring the data costs. > > scott Just wanted to clear one point up... The web is *not* a "push" model; it's a "pull" model. The HTML document is nothing but a text document which has references to other elements that are available to the browser, should it choose to request them; but it is incumbent upon the browser to request each and every one of those other elements from the server before they are transferred. The server will not send something that was not first requested by the browser. It's misunderstandings like this that make content providers twitch every time an eyeball network says "well you're *sending* all this data at my network" -- absolutely nothing is being sent that was not explicitly requested by the browser first. ^_^; Thanks! Matt From eric-list at truenet.com Fri Sep 11 03:50:45 2015 From: eric-list at truenet.com (Eric Tykwinski) Date: Thu, 10 Sep 2015 23:50:45 -0400 Subject: BGAN Optimized Laptops In-Reply-To: References: <20150910181413.B81CD9DA@m0087793.ppops.net> Message-ID: <414F683C-E12B-4D86-8A12-5D48397FD3B6@truenet.com> Matt?s totally correct on the browser requesting the info, so it?s up to the client to decide what to download even obfuscated javascript links. My question would be how far can compression take you for something like Opera which does some compression in browser with a caching server? I figure a lot of websites are probably using more uncompressed formats like PNG, which can probably be compressed a bit more, but it?s still like taking a tar ball. If a server in sending gzip?d text and the browser/cache are compressing that how much more can be gained? Compression of compression with even more compression to me is probably more like a downward spiral. > On Sep 10, 2015, at 10:54 PM, Matthew Petach wrote: > > On Thu, Sep 10, 2015 at 6:14 PM, Scott Weeks wrote: >> > ... >> >> Someone told me that there is a way for the browser to say >> to the web server, send me only the parts of the web page I >> request. For example, send me everything but the flash and >> images. Being a browser wuss I thought the web server just >> sent everything and the browser decided whether to display >> it or not. That would mean the data already was transferred >> over the expensive sat link incurring the data costs. >> >> scott > > Just wanted to clear one point up... > > The web is *not* a "push" model; it's a "pull" model. > > The HTML document is nothing but a text document > which has references to other elements that are > available to the browser, should it choose to > request them; but it is incumbent upon the > browser to request each and every one of > those other elements from the server before > they are transferred. The server will not send > something that was not first requested by the > browser. > > It's misunderstandings like this that make content > providers twitch every time an eyeball network > says "well you're *sending* all this data at my > network" -- absolutely nothing is being sent > that was not explicitly requested by the browser > first. ^_^; > > Thanks! > > Matt From owen at delong.com Fri Sep 11 04:17:16 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Sep 2015 21:17:16 -0700 Subject: IPv6 Subscriber Access Deployments In-Reply-To: <1441824693.1143196.379124105.08AB7797@webmail.messagingengine.com> References: <23313.1441739306@turing-police.cc.vt.edu> <1441741576.143219.378115649.3634EE3A@webmail.messagingengine.com> <7B11BBC4-8B7B-49FD-B03C-0ACFCAB10263@delong.com> <1441824693.1143196.379124105.08AB7797@webmail.messagingengine.com> Message-ID: <067DF6AB-E751-4EA2-8CF6-E39B1E0F4026@delong.com> Sure, but in that latter case, it is not link-local only. It doesn?t matter where the /n (where n is (preferably) a member of {64, 126, 127}) for the point-to-point link is issued, so long as there is a GUA on the link. Owen > On Sep 9, 2015, at 11:51 , Clinton Work wrote: > > > Granted that having the CPE request both a IA_NA and IA_PD is a more > common configuration. Some of the CPEs using only DHCPv6 PD can > allocate a /64 out of the delegated /48 for WAN address & management. > The IPV6 traceroute is not broken with the DHCPv6 PD only configuration. > > On Wed, Sep 9, 2015, at 11:15 AM, Owen DeLong wrote: >> Sure, but this is a useless savings that comes at the cost of awkward >> traceroute output >> that will initially confuse your new employees and consistently confuse >> your customers. From owen at delong.com Fri Sep 11 05:43:14 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Sep 2015 22:43:14 -0700 Subject: DamnTest: ignore In-Reply-To: References: <20150910181831.GB15207@mikea.ath.cx> Message-ID: <2449B93D-A259-4868-AF1E-EC8C29381686@delong.com> Is Damn supposed to get through or is it supposed to get dammed up in the system? Owen > On Sep 10, 2015, at 11:43 , Josh Luthman wrote: > > cogeco.com is to blame > > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Thu, Sep 10, 2015 at 2:28 PM, Nathan Anderson wrote: > >> On Thu, Sep 10, 2015, mikea wrote: >> >>> This post includes the word Damn. >>> >>> damn >> >> Well, dayum. >> >> -- Nathan >> >> From trelane at trelane.net Fri Sep 11 07:11:13 2015 From: trelane at trelane.net (Andrew Kirch) Date: Fri, 11 Sep 2015 03:11:13 -0400 Subject: DamnTest: ignore In-Reply-To: <2449B93D-A259-4868-AF1E-EC8C29381686@delong.com> References: <20150910181831.GB15207@mikea.ath.cx> <2449B93D-A259-4868-AF1E-EC8C29381686@delong.com> Message-ID: Is this the thread where I go for the high score in profanity? You know, for testing purposes? Owen: I think that NANOG would get huge value from syndicating my Facebook wall, don't you? On Fri, Sep 11, 2015 at 1:43 AM, Owen DeLong wrote: > Is Damn supposed to get through or is it supposed to get dammed up in the > system? > > Owen > > > On Sep 10, 2015, at 11:43 , Josh Luthman > wrote: > > > > cogeco.com is to blame > > > > > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > > On Thu, Sep 10, 2015 at 2:28 PM, Nathan Anderson > wrote: > > > >> On Thu, Sep 10, 2015, mikea wrote: > >> > >>> This post includes the word Damn. > >>> > >>> damn > >> > >> Well, dayum. > >> > >> -- Nathan > >> > >> > > From eyeronic.design at gmail.com Fri Sep 11 07:52:34 2015 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 11 Sep 2015 00:52:34 -0700 Subject: Extraneous "legal" babble--and my reaction to it. In-Reply-To: References: <4221D490-B791-4333-AF5B-F691475A2723@gmail.com> Message-ID: I see black on white... On Thu, Sep 10, 2015 at 6:35 PM, Keith Medcalf wrote: > >> "Email Disclaimers: Legal Effect in American Courts" >> - http://www.rhlaw.com/blog/legal-effect-of-boilerplate-email-disclaimers/ > > Dark grey text on a black background is unreadable. > Plonk goes the website. > > > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From Bryan at bryanfields.net Fri Sep 11 07:56:18 2015 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 11 Sep 2015 03:56:18 -0400 Subject: WiFI on utility poles In-Reply-To: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> References: <1701674893.5328.1441905369218.JavaMail.mhammett@ThunderFuck> Message-ID: <55F28922.2060900@bryanfields.net> On 9/10/15 1:15 PM, Mike Hammett wrote: > The tower-deployed AP can see the cable wireless APs for miles and can see > a few dozen of them at any one time. Given the goal of full modulation at > all times for optimal use of spectrum and dollars, the ever increasing > noise from the cable APs makes this a challenge. You need 25 to 30 dB to > maintain full modulation and that's increasingly difficult when you hear > cable APs everywhere at -70. Frankly this is what the WISP's get for deploying on Part 15 spectrum. It's a race to the bottom, and always has been. In 1999-2000 2.4 Part 15 was golden with FHSS, and we played nice with the Karlnet guys. Then the muni's came in with their 2.4 networks and killed 2.4 for anything decent. Canopy operators came in like a thousand people blinking in unison and crapped up 5.8. We all retreated to 5.3 and then 5.4 opened up and life was good. 900 was never an option as even in rural areas you had to deal with paging at 929 mhz blowing out the front end of your receiver. We made it work with stupid long antennas and horizontal polarization, but that was only to go 2 miles through trees. Remember waverider? Now it's happening again; get licensed spectrum or go home. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From jwbensley at gmail.com Fri Sep 11 08:35:17 2015 From: jwbensley at gmail.com (James Bensley) Date: Fri, 11 Sep 2015 09:35:17 +0100 Subject: NetFlow - path from Routers to Collector In-Reply-To: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> Message-ID: On 1 September 2015 at 16:33, Serge Vautour wrote: > Hello, > > For those than run Internet connected routers, how do you get your NetFlow data from the routers to your collectors? Do you let the flow export traffic use the same links as your customer traffic to route back to central collectors? Or do you send this traffic over private network management type path? If you send this traffic over the "Internet" (within your AS), are you worried about security? > > Thanks, > Serge Hi Serge, Not encountered any worries regarding security, typically NetFow/ipfix/sFlow/etc is inside a management MPLS VPN so it is segregated from customer VPNs through the network. For the physical transport of the data, collecting the data via your OOB network is probably preferred however "it depends". Do you use NetFlow internally only or offer it as a chargeable service? Do you also graph traffic stats via SNMP too? And so on and so forth... In past experience, NetFlow data was exported over the productive links (the links also carrying customer data being measured using NetFlow) without issue. I recall two occasions a DDoS disrupted the NetFlow collecting because the DDoS traversed those links that are being monitored and carrying their own NetFlow traffic. However SNMP graphing was via the OOB network so we didn't really lose any vital visibility. So we could still see from the like 1000% increase in traffic which links along the network were being affected. A distress call from the customer being DDoS also helps :) Another part of the "it depends" puzzle is how much data you are collecting via NetFlow? Again in a part experience we were testing collecting everything (as much as we could), every single packet header (no payload data though), rather than sampling say 1 in 10 packets for example. We only got as far as testing this in the lab but one issue it threw up was we could generate several Mbps of NetFlow traffic. Some PoPs have ADSL for OOB and wouldn't have been able to support that so sites with ADSL or 3G OOB links would need the OOB link upgrading, that required additional Capex, cue management budget wrestle, blah blah... Cheers, James. From amekkaoui at mektel.ca Fri Sep 11 12:51:27 2015 From: amekkaoui at mektel.ca (A MEKKAOUI) Date: Fri, 11 Sep 2015 08:51:27 -0400 Subject: Cisco ASA Message-ID: <001101d0ec90$9316b8d0$b9442a70$@ca> HI Do you know any seller of Cisco ASA (used and new) please? Please contact me offline. Thank you KARIM M. From mkaipov at outlook.com Fri Sep 11 12:56:03 2015 From: mkaipov at outlook.com (Murat Kaipov) Date: Fri, 11 Sep 2015 15:56:03 +0300 Subject: Cisco ASA In-Reply-To: <001101d0ec90$9316b8d0$b9442a70$@ca> References: <001101d0ec90$9316b8d0$b9442a70$@ca> Message-ID: Hello Dear. You can you cisco partner locator https://tools.cisco.com/WWChannels/LOCATR/openBasicSearch.do It will be more productively. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of A MEKKAOUI Sent: Friday, September 11, 2015 3:51 PM To: 'NANOG' Subject: Cisco ASA HI Do you know any seller of Cisco ASA (used and new) please? Please contact me offline. Thank you KARIM M. From ESundberg at nitelusa.com Fri Sep 11 13:18:16 2015 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Fri, 11 Sep 2015 13:18:16 +0000 Subject: NetFlow - path from Routers to Collector In-Reply-To: References: <1441121622.87870.YahooMailBasic@web141403.mail.bf1.yahoo.com> Message-ID: <495D0934DA46854A9CA758393724D590C83287@NI-MAIL02.nii.ads> Mainly management type traffic over an Out of band Management Network. This way during and outage we don't miss any Netflow and SNMP Queries and more importantly we can still access the router. In the past I have also setup a Management VRF, but tend to stay away from this. During an outage you end up losing data or visibility while routes reconverge. -----Original Message----- From: NANOG [mailto:nanog-bounces+esundberg=nitelusa.com at nanog.org] On Behalf Of James Bensley Sent: Friday, September 11, 2015 3:35 AM To: serge at nbnet.nb.ca; nanog at nanog.org Subject: Re: NetFlow - path from Routers to Collector On 1 September 2015 at 16:33, Serge Vautour wrote: > Hello, > > For those than run Internet connected routers, how do you get your NetFlow data from the routers to your collectors? Do you let the flow export traffic use the same links as your customer traffic to route back to central collectors? Or do you send this traffic over private network management type path? If you send this traffic over the "Internet" (within your AS), are you worried about security? > > Thanks, > Serge Hi Serge, Not encountered any worries regarding security, typically NetFow/ipfix/sFlow/etc is inside a management MPLS VPN so it is segregated from customer VPNs through the network. For the physical transport of the data, collecting the data via your OOB network is probably preferred however "it depends". Do you use NetFlow internally only or offer it as a chargeable service? Do you also graph traffic stats via SNMP too? And so on and so forth... In past experience, NetFlow data was exported over the productive links (the links also carrying customer data being measured using NetFlow) without issue. I recall two occasions a DDoS disrupted the NetFlow collecting because the DDoS traversed those links that are being monitored and carrying their own NetFlow traffic. However SNMP graphing was via the OOB network so we didn't really lose any vital visibility. So we could still see from the like 1000% increase in traffic which links along the network were being affected. A distress call from the customer being DDoS also helps :) Another part of the "it depends" puzzle is how much data you are collecting via NetFlow? Again in a part experience we were testing collecting everything (as much as we could), every single packet header (no payload data though), rather than sampling say 1 in 10 packets for example. We only got as far as testing this in the lab but one issue it threw up was we could generate several Mbps of NetFlow traffic. Some PoPs have ADSL for OOB and wouldn't have been able to support that so sites with ADSL or 3G OOB links would need the OOB link upgrading, that required additional Capex, cue management budget wrestle, blah blah... Cheers, James. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From emile.aben at ripe.net Fri Sep 11 13:23:27 2015 From: emile.aben at ripe.net (Emile Aben) Date: Fri, 11 Sep 2015 15:23:27 +0200 Subject: routability of longer-then-24 prefixes out of ARIN's 23.128/10 block Message-ID: <55F2D5CF.6050404@ripe.net> Hi, We took another peek at routability of longer-then-24-prefixes from ARIN's 23.128/10 block: https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-24-prefixes-changed In case people missed previous announcements about this IPv4 address block: Per ARIN policy this block is set aside to facilitate IPv6 deployment. It is subject to a minimum size allocation of /28 and a maximum size allocation of /24 best regards, Emile Aben RIPE NCC From nanog at ics-il.net Fri Sep 11 13:27:03 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 11 Sep 2015 08:27:03 -0500 (CDT) Subject: WiFI on utility poles In-Reply-To: <55F28922.2060900@bryanfields.net> Message-ID: <1600222105.6533.1441978093740.JavaMail.mhammett@ThunderFuck> I'm not suggesting that WISPs have exclusive-use spectrum at all. It isn't necessary, just cooperation and design best practices. For example, there aren't likely to be any people a hundred or two hundred feet in the air where the towers are, so why do the cable companies' radiation patterns include up there? Get yourself some higher gain antennas that focus their power in the lower 180* of elevation. I do understand that the cables these are typically mounted to will sway, so just put the AP closer to the pole where the sway will be less. Where would you suggest WISPs deploy? In spectrum that costs so much that it ruins the business model of being a WISP? Say there's a new WISP that wants to start, how could they possibly get spectrum if Clear bought it all up 10 years ago? At least there's potential with the upcoming 3550 - 3650 MHz. Then again, the licensed channels are tiny, so real amounts of bandwidth can't really be delivered. The government has been crapping on the TVWS for the last ten years as well. Then the areas that have foliage issues will have some relief, but there's always some special interest or another rearing their heads in the way, spewing FUD. Canopy operators are WISPs and their platform has been one of the most successful WISP platforms. So successful in fact that sync capability has been on the demanded features list for all other vendors. Spoken by a WISP that's been running in rural and suburban areas for the past 11 years. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Bryan Fields" To: "Mike Hammett" , "Scott Helms" Cc: "Corey Petrulich" , "Kenneth Falkenstein" , "NANOG mailing list" Sent: Friday, September 11, 2015 2:56:18 AM Subject: Re: WiFI on utility poles On 9/10/15 1:15 PM, Mike Hammett wrote: > The tower-deployed AP can see the cable wireless APs for miles and can see > a few dozen of them at any one time. Given the goal of full modulation at > all times for optimal use of spectrum and dollars, the ever increasing > noise from the cable APs makes this a challenge. You need 25 to 30 dB to > maintain full modulation and that's increasingly difficult when you hear > cable APs everywhere at -70. Frankly this is what the WISP's get for deploying on Part 15 spectrum. It's a race to the bottom, and always has been. In 1999-2000 2.4 Part 15 was golden with FHSS, and we played nice with the Karlnet guys. Then the muni's came in with their 2.4 networks and killed 2.4 for anything decent. Canopy operators came in like a thousand people blinking in unison and crapped up 5.8. We all retreated to 5.3 and then 5.4 opened up and life was good. 900 was never an option as even in rural areas you had to deal with paging at 929 mhz blowing out the front end of your receiver. We made it work with stupid long antennas and horizontal polarization, but that was only to go 2 miles through trees. Remember waverider? Now it's happening again; get licensed spectrum or go home. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From bill at herrin.us Fri Sep 11 13:54:12 2015 From: bill at herrin.us (William Herrin) Date: Fri, 11 Sep 2015 09:54:12 -0400 Subject: routability of longer-then-24 prefixes out of ARIN's 23.128/10 block In-Reply-To: <55F2D5CF.6050404@ripe.net> References: <55F2D5CF.6050404@ripe.net> Message-ID: On Fri, Sep 11, 2015 at 9:23 AM, Emile Aben wrote: > We took another peek at routability of longer-then-24-prefixes from > ARIN's 23.128/10 block: > > https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-24-prefixes-changed Good work. Thanks! TLDR: 90%-100% visibility for /24, 10%-30% visibility for longer. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From tobin.burnham at gmail.com Fri Sep 11 02:53:01 2015 From: tobin.burnham at gmail.com (Tobin Burnham) Date: Thu, 10 Sep 2015 22:53:01 -0400 Subject: Status of Inerail? Message-ID: Does anyone know the status of Inerail (AS33031)? All of their ASNs and prefixes disappeared on 9/1/2015 according to http://bgp.he.net/AS33031 All of the contact emails I found seemed to have been hosted under the ASNs and prefixes attributed to Inerail which are now gone from the Internet. I was looking for information on the Philadelphia Internet Exchange which I think they are/were running. From job at instituut.net Fri Sep 11 15:34:11 2015 From: job at instituut.net (Job Snijders) Date: Fri, 11 Sep 2015 17:34:11 +0200 Subject: Status of Inerail? In-Reply-To: References: Message-ID: <20150911153411.GI95109@Vurt.local> On Thu, Sep 10, 2015 at 10:53:01PM -0400, Tobin Burnham wrote: > Does anyone know the status of Inerail (AS33031)? No, but their NLNOG RING node is offline too: inerail01.ring.nlnog.net > All of their ASNs and prefixes disappeared on 9/1/2015 according to > http://bgp.he.net/AS33031 > > All of the contact emails I found seemed to have been hosted under the > ASNs and prefixes attributed to Inerail which are now gone from the > Internet. You could try noc at inerail.net for which MX is handled by google. Kind regards, Job From jschauma at netmeister.org Fri Sep 11 17:23:38 2015 From: jschauma at netmeister.org (Jan Schaumann) Date: Fri, 11 Sep 2015 13:23:38 -0400 Subject: Ethical Obligations in Internet Operations Message-ID: <20150911172337.GY9089@netmeister.org> Hello, I'm currently preparing a talk on "Ethical Obligations in Internet Operations"[1] for Velocity NY in October. In preparation, I've put together a short, anonymous survey for people involved in "Internet Operations": https://docs.google.com/forms/d/1UmJtkj1dsFVjZx2yBC6zZZi1tIuObuVZxQd3oWxGk4o/viewform After circling this survey in the SysAdmin/DevOps/SRE communities, I'd love to get some feedback from the people who are operating the core infrastructure of the internet, ie your esteemed selves. If you could take the five minutes to fill out this form, that would be a great help for me. If you'd like to share this in your social or professional circles, that'd be wonderful, too. You could: - forward this email - directly forward or link to the form above - link to https://www.netmeister.org/blog/velocity-ny2015-questionnaire.html for a bit more context - retweet / quote either of these tweets: https://twitter.com/jschauma/status/628393619196641280 https://twitter.com/jschauma/status/628646443033694208 Of course I also welcome comments directly to me via email. Any and all feedback will be treated entirely confidentially. Many thanks in advance for your help! -Jan [1] https://www.netmeister.org/blog/velocity-ny2015-accepted.html From cscora at apnic.net Fri Sep 11 18:12:31 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Sep 2015 04:12:31 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201509111812.t8BICVMP014354@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 12 Sep, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 562922 Prefixes after maximum aggregation (per Origin AS): 210448 Deaggregation factor: 2.67 Unique aggregates announced (without unneeded subnets): 273421 Total ASes present in the Internet Routing Table: 51406 Prefixes per ASN: 10.95 Origin-only ASes present in the Internet Routing Table: 36646 Origin ASes announcing only one prefix: 16108 Transit ASes present in the Internet Routing Table: 6404 Transit-only ASes present in the Internet Routing Table: 170 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 45 Max AS path prepend of ASN ( 55644) 41 Prefixes from unregistered ASNs in the Routing Table: 1080 Unregistered ASNs in the Routing Table: 411 Number of 32-bit ASNs allocated by the RIRs: 10940 Number of 32-bit ASNs visible in the Routing Table: 8356 Prefixes from 32-bit ASNs in the Routing Table: 31443 Number of bogon 32-bit ASNs visible in the Routing Table: 19 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 438 Number of addresses announced to Internet: 2808516288 Equivalent to 167 /8s, 102 /16s and 142 /24s Percentage of available address space announced: 75.9 Percentage of allocated address space announced: 75.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.6 Total number of prefixes smaller than registry allocations: 185904 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 142701 Total APNIC prefixes after maximum aggregation: 39688 APNIC Deaggregation factor: 3.60 Prefixes being announced from the APNIC address blocks: 150100 Unique aggregates announced from the APNIC address blocks: 59677 APNIC Region origin ASes present in the Internet Routing Table: 5093 APNIC Prefixes per ASN: 29.47 APNIC Region origin ASes announcing only one prefix: 1206 APNIC Region transit ASes present in the Internet Routing Table: 892 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 38 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1618 Number of APNIC addresses announced to Internet: 752237184 Equivalent to 44 /8s, 214 /16s and 58 /24s Percentage of available APNIC address space announced: 87.9 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: 180262 Total ARIN prefixes after maximum aggregation: 88353 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 183222 Unique aggregates announced from the ARIN address blocks: 86012 ARIN Region origin ASes present in the Internet Routing Table: 16575 ARIN Prefixes per ASN: 11.05 ARIN Region origin ASes announcing only one prefix: 6055 ARIN Region transit ASes present in the Internet Routing Table: 1741 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 661 Number of ARIN addresses announced to Internet: 1117747648 Equivalent to 66 /8s, 159 /16s and 121 /24s Percentage of available ARIN address space announced: 59.1 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, 64198-64296, 393216-395164 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: 135342 Total RIPE prefixes after maximum aggregation: 67629 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 142286 Unique aggregates announced from the RIPE address blocks: 88430 RIPE Region origin ASes present in the Internet Routing Table: 17983 RIPE Prefixes per ASN: 7.91 RIPE Region origin ASes announcing only one prefix: 8048 RIPE Region transit ASes present in the Internet Routing Table: 2998 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: 4014 Number of RIPE addresses announced to Internet: 699646848 Equivalent to 41 /8s, 179 /16s and 195 /24s Percentage of available RIPE address space announced: 101.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 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: 60880 Total LACNIC prefixes after maximum aggregation: 11656 LACNIC Deaggregation factor: 5.22 Prefixes being announced from the LACNIC address blocks: 72726 Unique aggregates announced from the LACNIC address blocks: 33618 LACNIC Region origin ASes present in the Internet Routing Table: 2463 LACNIC Prefixes per ASN: 29.53 LACNIC Region origin ASes announcing only one prefix: 605 LACNIC Region transit ASes present in the Internet Routing Table: 525 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 28 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1917 Number of LACNIC addresses announced to Internet: 168849920 Equivalent to 10 /8s, 16 /16s and 114 /24s Percentage of available LACNIC address space announced: 100.6 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: 12177 Total AfriNIC prefixes after maximum aggregation: 3079 AfriNIC Deaggregation factor: 3.95 Prefixes being announced from the AfriNIC address blocks: 14150 Unique aggregates announced from the AfriNIC address blocks: 5307 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 19.20 AfriNIC Region origin ASes announcing only one prefix: 194 AfriNIC Region transit ASes present in the Internet Routing Table: 165 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 146 Number of AfriNIC addresses announced to Internet: 69418240 Equivalent to 4 /8s, 35 /16s and 61 /24s Percentage of available AfriNIC address space announced: 69.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5581 4192 76 China Education and Research 4766 3004 11134 981 Korea Telecom 7545 2791 339 133 TPG Telecom Limited 17974 2712 908 90 PT Telekomunikasi Indonesia 4755 2042 427 229 TATA Communications formerly 9829 1880 1375 204 National Internet Backbone 9808 1592 8639 18 Guangdong Mobile Communicatio 4812 1574 2099 113 China Telecom (Group) 4808 1527 2254 473 CNCGROUP IP network China169 9583 1495 118 559 Sify Limited 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 3178 2966 144 Cox Communications Inc. 6389 2696 3688 51 BellSouth.net Inc. 3356 2541 10709 503 Level 3 Communications, Inc. 18566 2145 389 257 MegaPath Corporation 20115 1881 1864 395 Charter Communications 6983 1740 866 244 EarthLink, Inc. 30036 1593 321 399 Mediacom Communications Corp 4323 1584 1005 404 tw telecom holdings, inc. 701 1400 11401 676 MCI Communications Services, 22561 1374 415 258 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 2473 129 7 SaudiNet, Saudi Telecom Compa 20940 2133 847 1536 Akamai International B.V. 34984 2042 306 377 TELLCOM ILETISIM HIZMETLERI A 13188 1071 97 76 TOV "Bank-Inform" 31148 1049 46 23 Freenet Ltd. 6849 1029 355 21 JSC "Ukrtelecom" 8402 1015 544 15 OJSC "Vimpelcom" 12479 994 965 78 France Telecom Espana SA 8551 982 376 52 Bezeq International-Ltd 6830 915 2694 468 Liberty Global Operations B.V 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 3369 539 159 Telmex Colombia S.A. 28573 2266 2170 120 NET Servi?os de Comunica??o S 8151 1840 3272 484 Uninet S.A. de C.V. 7303 1563 934 237 Telecom Argentina S.A. 6503 1401 429 56 Axtel, S.A.B. de C.V. 26615 1085 2325 35 Tim Celular S.A. 6147 1062 374 30 Telefonica del Peru S.A.A. 7738 997 1882 41 Telemar Norte Leste S.A. 3816 948 436 160 COLOMBIA TELECOMUNICACIONES S 11830 915 364 24 Instituto Costarricense de El 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 914 1470 14 TE-AS 24863 787 281 37 Link Egypt (Link.NET) 36903 512 258 99 Office National des Postes et 36992 439 1229 32 ETISALAT MISR 37492 315 191 72 Orange Tunisie 24835 280 146 12 Vodafone Data 29571 247 21 13 Cote d'Ivoire Telecom 3741 244 854 200 Internet Solutions 36947 184 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 4538 5581 4192 76 China Education and Research 10620 3369 539 159 Telmex Colombia S.A. 22773 3178 2966 144 Cox Communications Inc. 4766 3004 11134 981 Korea Telecom 7545 2791 339 133 TPG Telecom Limited 17974 2712 908 90 PT Telekomunikasi Indonesia 6389 2696 3688 51 BellSouth.net Inc. 3356 2541 10709 503 Level 3 Communications, Inc. 39891 2473 129 7 SaudiNet, Saudi Telecom Compa 28573 2266 2170 120 NET Servi?os de Comunica??o S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3369 3210 Telmex Colombia S.A. 22773 3178 3034 Cox Communications Inc. 7545 2791 2658 TPG Telecom Limited 6389 2696 2645 BellSouth.net Inc. 17974 2712 2622 PT Telekomunikasi Indonesia 39891 2473 2466 SaudiNet, Saudi Telecom Compa 28573 2266 2146 NET Servi?os de Comunica??o S 3356 2541 2038 Level 3 Communications, Inc. 4766 3004 2023 Korea Telecom 18566 2145 1888 MegaPath Corporation 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 47092 UNALLOCATED 8.8.204.0/24 16410 The Reynolds and Rey 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 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 Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.100.1.0/24 9730 Bharti Telesonic Ltd Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 23.249.144.0/21 40430 colo4jax, LLC 23.249.152.0/21 40430 colo4jax, LLC 27.50.8.0/24 55548 Ravibhawan 27.50.9.0/24 55548 Ravibhawan 27.50.10.0/24 55548 Ravibhawan 27.50.11.0/24 55548 Ravibhawan 27.100.7.0/24 56096 >>UNKNOWN<< 31.170.96.0/23 23456 32bit Transition AS 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:18 /9:13 /10:36 /11:95 /12:262 /13:500 /14:1005 /15:1739 /16:12905 /17:7389 /18:12574 /19:26353 /20:37377 /21:39532 /22:61825 /23:53967 /24:304998 /25:854 /26:928 /27:492 /28:15 /29:14 /30:9 /31:0 /32:22 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2473 SaudiNet, Saudi Telecom Compa 22773 2388 3178 Cox Communications Inc. 18566 2060 2145 MegaPath Corporation 6389 1608 2696 BellSouth.net Inc. 30036 1412 1593 Mediacom Communications Corp 6983 1386 1740 EarthLink, Inc. 34984 1362 2042 TELLCOM ILETISIM HIZMETLERI A 10620 1245 3369 Telmex Colombia S.A. 11492 1134 1217 CABLE ONE, INC. 22561 1047 1374 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1578 2:687 4:97 5:1879 6:25 8:1400 12:1812 13:19 14:1427 15:17 16:2 17:50 18:22 20:50 23:1269 24:1749 27:2083 31:1605 32:37 33:2 34:4 35:3 36:157 37:2040 38:1056 39:15 40:71 41:2769 42:343 43:1509 44:31 45:1127 46:2351 47:55 49:959 50:801 52:22 54:86 55:6 56:28 57:43 58:1411 59:770 60:492 61:1792 62:1385 63:1893 64:4403 65:2242 66:3994 67:2073 68:1072 69:3238 70:1036 71:449 72:1968 74:2577 75:356 76:395 77:1377 78:1157 79:813 80:1356 81:1352 82:873 83:725 84:764 85:1384 86:457 87:1019 88:535 89:1948 90:150 91:5962 92:834 93:2297 94:2089 95:2160 96:419 97:348 98:963 99:55 100:77 101:855 103:8281 104:2046 105:80 106:347 107:1049 108:626 109:2144 110:1207 111:1463 112:825 113:1117 114:852 115:1334 116:1450 117:1090 118:1946 119:1475 120:464 121:1149 122:2171 123:1851 124:1539 125:1713 128:659 129:396 130:430 131:1261 132:535 133:166 134:422 135:96 136:346 137:317 138:1238 139:169 140:247 141:438 142:680 143:546 144:567 145:126 146:795 147:590 148:1268 149:433 150:599 151:795 152:530 153:254 154:501 155:876 156:422 157:424 158:345 159:1043 160:423 161:672 162:2106 163:461 164:693 165:714 166:308 167:867 168:1240 169:196 170:1397 171:248 172:269 173:1513 174:715 175:715 176:1463 177:3982 178:2197 179:989 180:1960 181:1548 182:1815 183:630 184:739 185:4246 186:2973 187:1885 188:2112 189:1719 190:7608 191:1155 192:8558 193:5662 194:4246 195:3651 196:1963 197:1079 198:5472 199:5517 200:6663 201:3249 202:9752 203:9179 204:4626 205:2877 206:3091 207:3027 208:3994 209:3918 210:3763 211:2052 212:2566 213:2221 214:863 215:74 216:5791 217:1793 218:798 219:544 220:1569 221:812 222:721 223:815 End of report From mlm at pixelgate.net Fri Sep 11 19:08:14 2015 From: mlm at pixelgate.net (Mark Milhollan) Date: Fri, 11 Sep 2015 12:08:14 -0700 (PDT) Subject: BGAN Optimized Laptops In-Reply-To: References: <20150910181413.B81CD9DA@m0087793.ppops.net> Message-ID: On Thu, 10 Sep 2015, Matthew Petach wrote: >Just wanted to clear one point up... > >The web is *not* a "push" model; it's a "pull" model. Mostly true, yet there's that little bit that makes it not total truth. HTTP/2 has push, where instead of waiting for a browser to decide which elements to fetch a server can send anything it likes, the basic theory being that "everyone" will request certain/all objects so sending them without waiting for the requests will enhance performance. HTTP/2 -- derived from / started as SPDY -- became a standard in May and is supported by various servers and clients. WebSockets should probably be mentioned as well. And the even older content replacing push (ca '95) -- though seldom used it is still supported by some browsers. /mark From cidr-report at potaroo.net Fri Sep 11 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Sep 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201509112200.t8BM00DN067882@wattle.apnic.net> This report has been generated at Fri Sep 11 21:14:56 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 04-09-15 566067 307402 05-09-15 566061 307392 06-09-15 565794 307423 07-09-15 566335 307606 08-09-15 566475 307703 09-09-15 565912 307968 10-09-15 566536 310111 11-09-15 571301 310413 AS Summary 51682 Number of ASes in routing system 20503 Number of ASes announcing only one prefix 5598 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center,CN 120969728 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'). --- 11Sep15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 571610 310390 261220 45.7% All ASes AS22773 3181 174 3007 94.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4538 5598 2804 2794 49.9% ERX-CERNET-BKB China Education and Research Network Center,CN AS6389 2695 70 2625 97.4% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2710 90 2620 96.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2474 20 2454 99.2% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS7545 2930 636 2294 78.3% TPG-INTERNET-AP TPG Telecom Limited,AU AS28573 2263 133 2130 94.1% NET Servi?os de Comunica??o S.A.,BR AS9394 2099 205 1894 90.2% CTTNET China TieTong Telecommunications Corporation,CN AS4766 3004 1274 1730 57.6% KIXS-AS-KR Korea Telecom,KR AS10620 3369 1647 1722 51.1% Telmex Colombia S.A.,CO AS9808 1592 78 1514 95.1% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1739 247 1492 85.8% ITCDELTA - Earthlink, Inc.,US AS4755 2042 559 1483 72.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS20115 1881 408 1473 78.3% CHARTER-NET-HKY-NC - Charter Communications,US AS3356 2547 1224 1323 51.9% LEVEL3 - Level 3 Communications, Inc.,US AS9498 1387 119 1268 91.4% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2147 956 1191 55.5% MEGAPATH5-US - MegaPath Corporation,US AS4323 1589 405 1184 74.5% TWTC - tw telecom holdings, inc.,US AS4788 1220 69 1151 94.3% TMNET-AS-AP TM Net, Internet Service Provider,MY AS4812 1575 524 1051 66.7% CHINANET-SH-AP China Telecom (Group),CN AS7303 1563 522 1041 66.6% Telecom Argentina S.A.,AR AS7552 1427 388 1039 72.8% VIETEL-AS-AP Viettel Corporation,VN AS4808 1544 512 1032 66.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS22561 1374 347 1027 74.7% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS8151 1839 814 1025 55.7% Uninet S.A. de C.V.,MX AS8402 1011 24 987 97.6% CORBINA-AS OJSC "Vimpelcom",RU AS38197 1444 462 982 68.0% SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK AS26615 1085 153 932 85.9% Tim Celular S.A.,BR AS7738 995 77 918 92.3% Telemar Norte Leste S.A.,BR AS6147 1062 205 857 80.7% Telefonica del Peru S.A.A.,PE Total 61386 15146 46240 75.3% Top 30 total Possible Bogus Routes 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 23.249.144.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 23.249.144.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 23.249.152.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 27.50.8.0/24 AS55548 27.50.9.0/24 AS55548 27.50.10.0/24 AS55548 27.50.11.0/24 AS55548 27.100.7.0/24 AS56096 31.170.96.0/23 AS19798 YOUZEE-MAIN Manaslu Media Entertainment SL,ES 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 36.50.0.0/16 AS20418 MOSMOG-AS OJSC TORGOVYJ DOM MOSKVA-MOGILEV,RU 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.3.0/24 AS37004 -Reserved AS-,ZZ 41.73.4.0/24 AS37004 -Reserved AS-,ZZ 41.73.5.0/24 AS37004 -Reserved AS-,ZZ 41.73.6.0/24 AS37004 -Reserved AS-,ZZ 41.73.7.0/24 AS37004 -Reserved AS-,ZZ 41.73.8.0/24 AS37004 -Reserved AS-,ZZ 41.73.9.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.17.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.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.126.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -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.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.57.192.0/22 AS33321 -Reserved AS-,ZZ 64.234.239.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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.187.240.0/24 AS22753 REDHAT-0 - Red Hat, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.228.160.0/20 AS7233 YAHOO-US - Yahoo,US 66.228.176.0/21 AS17110 YAHOO-US2 - Yahoo,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 68.234.0.0/19 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.0.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.5.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.7.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.16.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.17.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.18.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.19.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.20.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.21.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.22.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.23.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.24.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.26.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.28.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.29.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 69.24.96.0/20 AS26804 -Reserved AS-,ZZ 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.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 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.213.220.0/24 AS19662 -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.100.1.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd,IN 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.12.48.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.12.247.0/24 AS13233 103.13.1.0/24 AS58609 103.14.32.0/22 AS2519 VECTANT VECTANT Ltd.,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.22.212.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.25.144.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.29.90.0/23 AS9503 FX-PRIMARY-AS FX Networks Limited,AU 103.29.236.0/24 AS13200 103.29.237.0/24 AS13200 103.195.168.0/24 AS46047 POLSRI-AS-ID Politeknik Negeri Sriwijaya,ID 103.195.169.0/24 AS46047 POLSRI-AS-ID Politeknik Negeri Sriwijaya,ID 103.198.0.0/16 AS7497 CSTNET-AS-AP Computer Network Information Center,CN 103.199.0.0/16 AS7497 CSTNET-AS-AP Computer Network Information Center,CN 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.229.152.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.232.164.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.233.140.0/23 AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK,AF 103.233.212.0/22 AS10010 TOKAI TOKAI Communications Corporation,JP 103.235.72.0/23 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.235.74.0/23 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.235.216.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.237.76.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.250.220.0/24 AS58973 103.250.221.0/24 AS58973 103.253.164.0/23 AS13317 116.199.203.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.205.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.206.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.207.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 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 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 155.35.0.0/16 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.1.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.34.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.35.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.46.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.47.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.232.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.221.64.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 162.221.64.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 162.221.68.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.247.72.0/24 AS4224 -Reserved AS-,ZZ 162.247.73.0/24 AS4224 -Reserved AS-,ZZ 162.247.74.0/24 AS4224 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.88.48.0/20 AS29927 -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.249.191.0/24 AS45816 ISHK-AP I-Services Network Solution Limited,HK 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.191.0.0/16 AS20053 RELAX-LLC-AS LLC Relax,RU 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.52.57.0/24 AS48039 KGT-AS KGT new media,DE 185.52.58.0/24 AS48039 KGT-AS KGT new media,DE 185.117.12.0/24 AS62078 VELDER-AS Patrick Velder,CH 185.117.14.0/24 AS62078 VELDER-AS Patrick Velder,CH 185.117.15.0/24 AS62078 VELDER-AS Patrick Velder,CH 186.148.224.0/21 AS52302 Awknet International, S.A.,PA 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.67.160.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.67.161.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.67.162.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.46.0/23 AS17139 NETRANGE - Corporate Colocation 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.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.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 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.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 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.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 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.151.160.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.130.0/24 AS21104 AM-NETSYS-AS Netsys JV LLC,AM 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.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.9.9.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.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.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 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.180.0/24 AS37004 -Reserved AS-,ZZ 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.8.72.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.72.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.76.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.77.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.78.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.79.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 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.91.44.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.44.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.45.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.46.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.47.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,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.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -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.103.89.0/24 AS19523 -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.182.207.0/24 AS23136 ONX - OnX Enterprise Solutions Inc.,CA 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 201.131.5.0/24 AS28389 -Reserved AS-,ZZ 201.131.88.0/24 AS8151 Uninet S.A. de C.V.,MX 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.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.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.6.208.0/24 AS23937 203.6.209.0/24 AS23937 203.6.210.0/24 AS23937 203.6.211.0/24 AS23937 203.6.213.0/24 AS23937 203.6.215.0/24 AS23937 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 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.77.216.0/23 AS46550 -Reserved AS-,ZZ 204.77.216.0/24 AS46550 -Reserved AS-,ZZ 204.77.217.0/24 AS46550 -Reserved AS-,ZZ 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.138.104.0/24 AS46908 -Reserved AS-,ZZ 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 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 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.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.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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.88.104.0/24 AS11386 -Reserved AS-,ZZ 208.88.105.0/24 AS11386 -Reserved AS-,ZZ 208.88.106.0/24 AS11386 -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.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.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 Sep 11 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Sep 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201509112200.t8BM015k067895@wattle.apnic.net> BGP Update Report Interval: 03-Sep-15 -to- 10-Sep-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 285339 5.8% 192.8 -- BSNL-NIB National Internet Backbone,IN 2 - AS38197 139160 2.9% 95.6 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 3 - AS22059 127076 2.6% 18153.7 -- -Reserved AS-,ZZ 4 - AS1505 94989 1.9% 11873.6 -- DNIC-AS-01505 - Headquarters, USAISC,US 5 - AS53271 83037 1.7% 4613.2 -- PHENIXCITYCABLE - Phenix Cable,US 6 - AS21669 60362 1.2% 6036.2 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 7 - AS3709 56427 1.2% 2089.9 -- NET-CITY-SA - City of San Antonio,US 8 - AS199367 48572 1.0% 48572.0 -- AS_GBP Globe Business Publishing Limited,GB 9 - AS10620 48284 1.0% 17.9 -- Telmex Colombia S.A.,CO 10 - AS8001 39492 0.8% 391.0 -- NET-ACCESS-CORP - Net Access Corporation,US 11 - AS25563 33722 0.7% 8430.5 -- WEBLAND-AS Webland AG,CH 12 - AS200008 31963 0.7% 15981.5 -- PIRUM-AS Pirum Systems Limited,GB 13 - AS8402 31641 0.7% 28.0 -- CORBINA-AS OJSC "Vimpelcom",RU 14 - AS30295 31095 0.6% 3886.9 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 15 - AS56115 30677 0.6% 432.1 -- NGGL-BD New Generation Graphics Limited,BD 16 - AS131090 30494 0.6% 448.4 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 17 - AS56636 29958 0.6% 29958.0 -- ASVEDARU VEDA Ltd.,RU 18 - AS24323 28924 0.6% 556.2 -- AAMRA-NETWORKS-AS-AP aamra networks limited,BD 19 - AS14522 27664 0.6% 50.1 -- Satnet,EC 20 - AS39891 26737 0.6% 16.8 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS199367 48572 1.0% 48572.0 -- AS_GBP Globe Business Publishing Limited,GB 2 - AS56636 29958 0.6% 29958.0 -- ASVEDARU VEDA Ltd.,RU 3 - AS22059 127076 2.6% 18153.7 -- -Reserved AS-,ZZ 4 - AS200671 17130 0.3% 17130.0 -- SKOK-JAWORZNO SKOK Jaworzno,PL 5 - AS200008 31963 0.7% 15981.5 -- PIRUM-AS Pirum Systems Limited,GB 6 - AS1505 94989 1.9% 11873.6 -- DNIC-AS-01505 - Headquarters, USAISC,US 7 - AS25563 33722 0.7% 8430.5 -- WEBLAND-AS Webland AG,CH 8 - AS40493 7867 0.2% 7867.0 -- FACILITYSOURCEINC - FacilitySource,US 9 - AS31357 14081 0.3% 7040.5 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 10 - AS37590 6639 0.1% 6639.0 -- BCA-ASN,AO 11 - AS21669 60362 1.2% 6036.2 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 12 - AS38000 4664 0.1% 4664.0 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 13 - AS53271 83037 1.7% 4613.2 -- PHENIXCITYCABLE - Phenix Cable,US 14 - AS37473 7841 0.2% 3920.5 -- TELESOM,SO 15 - AS30295 31095 0.6% 3886.9 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 16 - AS201752 11583 0.2% 3861.0 -- NLTG-AS NL Telecoms Group S.L.,ES 17 - AS24237 3746 0.1% 3746.0 -- SIAM-CITY-CEMENT-PUBLIC-COMPANY-LIMITED Siam City Cement Public Company Limited (SCCC),TH 18 - AS134438 3720 0.1% 3720.0 -- AIRAAIFUL-AS-AP Aira & Aiful Public Company Limited,TH 19 - AS34 3223 0.1% 3223.0 -- UDELNET - University of Delaware,US 20 - AS59316 2105 0.0% 2105.0 -- AOL-BD aamra Outsourcing Ltd.,BD TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 76.191.107.0/24 63732 1.3% AS22059 -- -Reserved AS-,ZZ 2 - 64.34.125.0/24 63334 1.2% AS22059 -- -Reserved AS-,ZZ 3 - 209.212.8.0/24 60348 1.2% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 4 - 185.19.144.0/22 48572 1.0% AS199367 -- AS_GBP Globe Business Publishing Limited,GB 5 - 192.135.223.0/24 39270 0.8% AS8001 -- NET-ACCESS-CORP - Net Access Corporation,US 6 - 185.38.132.0/24 31961 0.6% AS200008 -- PIRUM-AS Pirum Systems Limited,GB 7 - 61.7.155.0/24 30302 0.6% AS131090 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 8 - 195.128.159.0/24 29958 0.6% AS56636 -- ASVEDARU VEDA Ltd.,RU 9 - 162.218.160.0/21 23086 0.5% AS53271 -- PHENIXCITYCABLE - Phenix Cable,US 10 - 162.218.162.0/23 21738 0.4% AS53271 -- PHENIXCITYCABLE - Phenix Cable,US 11 - 24.38.128.0/20 19424 0.4% AS53271 -- PHENIXCITYCABLE - Phenix Cable,US 12 - 24.38.128.0/22 18761 0.4% AS53271 -- PHENIXCITYCABLE - Phenix Cable,US 13 - 155.133.79.0/24 17130 0.3% AS200671 -- SKOK-JAWORZNO SKOK Jaworzno,PL 14 - 78.140.0.0/18 14079 0.3% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 15 - 143.84.79.0/24 12137 0.2% AS1505 -- DNIC-AS-01505 - Headquarters, USAISC,US 16 - 158.9.224.0/24 12067 0.2% AS1505 -- DNIC-AS-01505 - Headquarters, USAISC,US 17 - 143.86.217.0/24 12064 0.2% AS1505 -- DNIC-AS-01505 - Headquarters, USAISC,US 18 - 155.29.123.0/24 12062 0.2% AS1505 -- DNIC-AS-01505 - Headquarters, USAISC,US 19 - 155.29.122.0/24 12061 0.2% AS1505 -- DNIC-AS-01505 - Headquarters, USAISC,US 20 - 155.29.120.0/23 12038 0.2% AS1505 -- DNIC-AS-01505 - Headquarters, USAISC,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 Sep 12 05:19:23 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 12 Sep 2015 00:19:23 -0500 Subject: "Access Denied" when hitting https://www.apple.com issue over IPv4 and 6 Message-ID: <000d01d0ed1a$96f62230$c4e26690$@iname.com> Monitoring system reporting this since 11:11 pm U.S. Central root at nagios:/tmp# wget -6 www.apple.com --2015-09-12 00:17:55-- http://www.apple.com/ Resolving www.apple.com... 2001:590:1807:187::c77, 2001:590:1807:186::c77 Connecting to www.apple.com|2001:590:1807:187::c77|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2015-09-12 00:17:55 ERROR 403: Forbidden. root at nagios:/tmp# wget -6 https://www.apple.com --2015-09-12 00:17:59-- https://www.apple.com/ Resolving www.apple.com... 2001:590:1807:186::c77, 2001:590:1807:187::c77 Connecting to www.apple.com|2001:590:1807:186::c77|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2015-09-12 00:17:59 ERROR 403: Forbidden. root at nagios:/tmp# wget -4 www.apple.com --2015-09-12 00:18:35-- http://www.apple.com/ Resolving www.apple.com... 23.197.157.15 Connecting to www.apple.com|23.197.157.15|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2015-09-12 00:18:35 ERROR 403: Forbidden. root at nagios:/tmp# wget -4 https://www.apple.com --2015-09-12 00:19:07-- https://www.apple.com/ Resolving www.apple.com... 23.197.157.15 Connecting to www.apple.com|23.197.157.15|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2015-09-12 00:19:07 ERROR 403: Forbidden. root at nagios:/tmp# Frank From shrdlu at deaddrop.org Sat Sep 12 05:29:52 2015 From: shrdlu at deaddrop.org (Shrdlu) Date: Fri, 11 Sep 2015 22:29:52 -0700 Subject: "Access Denied" when hitting https://www.apple.com issue over IPv4 and 6 In-Reply-To: <000d01d0ed1a$96f62230$c4e26690$@iname.com> References: <000d01d0ed1a$96f62230$c4e26690$@iname.com> Message-ID: <55F3B850.8000501@deaddrop.org> On 9/11/2015 10:19 PM, Frank Bulk wrote: > Monitoring system reporting this since 11:11 pm U.S. Central [snippy] > Resolving www.apple.com... 2001:590:1807:187::c77, 2001:590:1807:186::c77 > > Connecting to www.apple.com|2001:590:1807:187::c77|:80... connected. > > HTTP request sent, awaiting response... 403 Forbidden > > 2015-09-12 00:17:55 ERROR 403: Forbidden. Entertaining. You could always call Apple Care, and let them know. (800) 694-7466 -- "You don't manage people; you manage things. You lead people." Admiral Grace Hopper, USN From frnkblk at iname.com Sat Sep 12 13:25:32 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 12 Sep 2015 08:25:32 -0500 Subject: "Access Denied" when hitting https://www.apple.com issue over IPv4 and 6 In-Reply-To: <000d01d0ed1a$96f62230$c4e26690$@iname.com> References: <000d01d0ed1a$96f62230$c4e26690$@iname.com> Message-ID: <001301d0ed5e$815e3d10$841ab730$@iname.com> Restored at 1:05 am U.S. Central. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk Sent: Saturday, September 12, 2015 12:19 AM To: nanog at nanog.org Subject: "Access Denied" when hitting https://www.apple.com issue over IPv4 and 6 Monitoring system reporting this since 11:11 pm U.S. Central root at nagios:/tmp# wget -6 www.apple.com --2015-09-12 00:17:55-- http://www.apple.com/ Resolving www.apple.com... 2001:590:1807:187::c77, 2001:590:1807:186::c77 Connecting to www.apple.com|2001:590:1807:187::c77|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2015-09-12 00:17:55 ERROR 403: Forbidden. root at nagios:/tmp# wget -6 https://www.apple.com --2015-09-12 00:17:59-- https://www.apple.com/ Resolving www.apple.com... 2001:590:1807:186::c77, 2001:590:1807:187::c77 Connecting to www.apple.com|2001:590:1807:186::c77|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2015-09-12 00:17:59 ERROR 403: Forbidden. root at nagios:/tmp# wget -4 www.apple.com --2015-09-12 00:18:35-- http://www.apple.com/ Resolving www.apple.com... 23.197.157.15 Connecting to www.apple.com|23.197.157.15|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2015-09-12 00:18:35 ERROR 403: Forbidden. root at nagios:/tmp# wget -4 https://www.apple.com --2015-09-12 00:19:07-- https://www.apple.com/ Resolving www.apple.com... 23.197.157.15 Connecting to www.apple.com|23.197.157.15|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2015-09-12 00:19:07 ERROR 403: Forbidden. root at nagios:/tmp# Frank From bjorn at mork.no Sat Sep 12 15:06:39 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sat, 12 Sep 2015 17:06:39 +0200 Subject: IPv6 Subscriber Access Deployments In-Reply-To: <7B11BBC4-8B7B-49FD-B03C-0ACFCAB10263@delong.com> (Owen DeLong's message of "Wed, 9 Sep 2015 10:15:21 -0700") References: <23313.1441739306@turing-police.cc.vt.edu> <1441741576.143219.378115649.3634EE3A@webmail.messagingengine.com> <7B11BBC4-8B7B-49FD-B03C-0ACFCAB10263@delong.com> Message-ID: <8737yjk77k.fsf@nemi.mork.no> Owen DeLong writes: > Sure, but this is a useless savings that comes at the cost of awkward traceroute output > that will initially confuse your new employees and consistently confuse your customers. Like MPLS or asymmetric routing... Noone wants unnecessarily confused employees or customers, but I don't think confusing traceroute output comes very high on the network design criteria list these days :) Whether the savings are useless depends on how you count the cost. Address space savings are of course pointless, but managing address allocations does have a cost. It doesn't have to be high, but it is a cost you have to consider. FWIW, we decided to go with an IA_NA based WAN GUA for CPE management purposes - we needed a management address and didn't want to steal from the customers IA_PD prefix. Bj?rn From jeremy at eff.org Sat Sep 12 18:04:51 2015 From: jeremy at eff.org (Jeremy Gillula) Date: Sat, 12 Sep 2015 11:04:51 -0700 Subject: Sign-On Letter to the Court in the FCC's Net Neutrality Case Message-ID: <55F46943.5010201@eff.org> Dear colleagues, Apologies in advance for the spam, but as many of you know, several large ISPs and their industry organizations are challenging the FCC's recent net neutrality order in court. Since the outcome of this case could have real consequences for how Internet services work in the future, I'm writing you today to ask you to sign on to a letter that EFF and ACLU have prepared for the court. The letter explains several key engineering concepts that are vital to understanding how the Internet actually operates (e.g. the end-to-end principle, the layered network stack, how IP routing works, etc.). It also stays away from legal arguments, and instead focuses on the technical arguments for how net neutrality has been key to the design and operation of the Internet since its beginning. It also lays out the technical consequences that could occur should the FCC's order be struck down, focusing on how large ISPs could transform the Internet from a system where innovation can take place without permission to one where ISPs get to dictate what protocols and services their customers are allowed to use. /*If you're willing to sign on and help today, please email me directly (off list) */and I will be happy to share a copy of the letter for you to review before you agree to sign on. The more signatures we can get, the more likely the court is to take notice. All it takes is an email. Please help us make sure the court gets the message: from an engineering point of view, neutrality and openness are fundamental to the way the Internet operates today. Thank you for your support, -- | Jeremy Gillula, Ph.D. | Staff Technologist | Electronic Frontier Foundation | (415) 436-9333 x158 | jeremy at eff.org | @the_zeroth_law | GPG Key Fingerprint: | 4DCF A726 7C7D E327 7DD6 | 863E A25B 3CE6 2CAC 7BE9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From johnl at iecc.com Sat Sep 12 19:45:45 2015 From: johnl at iecc.com (John Levine) Date: 12 Sep 2015 19:45:45 -0000 Subject: Sign-On Letter to the Court in the FCC's Net Neutrality Case In-Reply-To: <55F46943.5010201@eff.org> Message-ID: <20150912194545.65752.qmail@ary.lan> >/*If you're willing to sign on and help today, please email me directly >(off list) */and I will be happy to share a copy of the letter for you >to review before you agree to sign on. Why don't you just send us a copy or a link? If you're planning to file it as an amicus it's not like it's going to be a secret for very long. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From michael.d.morrison at me.com Sat Sep 12 05:28:58 2015 From: michael.d.morrison at me.com (Michael Morrison) Date: Fri, 11 Sep 2015 22:28:58 -0700 Subject: "Access Denied" when hitting https://www.apple.com issue over IPv4 and 6 In-Reply-To: <000d01d0ed1a$96f62230$c4e26690$@iname.com> References: <000d01d0ed1a$96f62230$c4e26690$@iname.com> Message-ID: Possibly getting ready for new iPhone launch? Or maybe it's been overloaded by east coast/Europe/Asia? Sent from my iPhone > On Sep 11, 2015, at 10:19 PM, Frank Bulk wrote: > > Monitoring system reporting this since 11:11 pm U.S. Central > > > > > > > > > > root at nagios:/tmp# wget -6 www.apple.com > > --2015-09-12 00:17:55-- http://www.apple.com/ > > Resolving www.apple.com... 2001:590:1807:187::c77, 2001:590:1807:186::c77 > > Connecting to www.apple.com|2001:590:1807:187::c77|:80... connected. > > HTTP request sent, awaiting response... 403 Forbidden > > 2015-09-12 00:17:55 ERROR 403: Forbidden. > > > > root at nagios:/tmp# wget -6 https://www.apple.com > > --2015-09-12 00:17:59-- https://www.apple.com/ > > Resolving www.apple.com... 2001:590:1807:186::c77, 2001:590:1807:187::c77 > > Connecting to www.apple.com|2001:590:1807:186::c77|:443... connected. > > HTTP request sent, awaiting response... 403 Forbidden > > 2015-09-12 00:17:59 ERROR 403: Forbidden. > > > > root at nagios:/tmp# wget -4 www.apple.com > > --2015-09-12 00:18:35-- http://www.apple.com/ > > Resolving www.apple.com... 23.197.157.15 > > Connecting to www.apple.com|23.197.157.15|:80... connected. > > HTTP request sent, awaiting response... 403 Forbidden > > 2015-09-12 00:18:35 ERROR 403: Forbidden. > > > > root at nagios:/tmp# wget -4 https://www.apple.com > > --2015-09-12 00:19:07-- https://www.apple.com/ > > Resolving www.apple.com... 23.197.157.15 > > Connecting to www.apple.com|23.197.157.15|:443... connected. > > HTTP request sent, awaiting response... 403 Forbidden > > 2015-09-12 00:19:07 ERROR 403: Forbidden. > > > > root at nagios:/tmp# > > > > > > Frank > From job at instituut.net Mon Sep 14 08:27:09 2015 From: job at instituut.net (Job Snijders) Date: Mon, 14 Sep 2015 10:27:09 +0200 Subject: [routing-wg] BGP Update Report In-Reply-To: <201509112200.t8BM015k067895@wattle.apnic.net> References: <201509112200.t8BM015k067895@wattle.apnic.net> Message-ID: <20150914082709.GR95109@Vurt.local> Dear community, As an extension to this useful IPv4 report, I'd love to receive a weekly overview of what is going on in the IPv6-world. Regardless of IPv6 deployment status or traffic volume, misconfigured or unstable IPv6 networks can inflict pain on a global scale (affecting IPv4 too). The IPv6 information is already available here http://bgpupdates.potaroo.net/instability/v6-bgpupd.html, but I see value in a weekly summary. Geoff, if nobody objects, would you be willing to send out IPv6 reports too? Or maybe it would make sense to merge the IPv4 and IPv6 data in a single report so it is easier to grasp the scale of instability. Kind regards, Job On Fri, Sep 11, 2015 at 10:00:01PM +0000, cidr-report at potaroo.net wrote: > BGP Update Report > Interval: 03-Sep-15 -to- 10-Sep-15 (7 days) > Observation Point: BGP Peering with AS131072 > > TOP 20 Unstable Origin AS > Rank ASN Upds % Upds/Pfx AS-Name > 1 - AS9829 285339 5.8% 192.8 -- BSNL-NIB National Internet Backbone,IN > 2 - AS38197 139160 2.9% 95.6 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK > 3 - AS22059 127076 2.6% 18153.7 -- -Reserved AS-,ZZ > [....] From jwbensley at gmail.com Mon Sep 14 08:37:32 2015 From: jwbensley at gmail.com (James Bensley) Date: Mon, 14 Sep 2015 09:37:32 +0100 Subject: [routing-wg] BGP Update Report In-Reply-To: <20150914082709.GR95109@Vurt.local> References: <201509112200.t8BM015k067895@wattle.apnic.net> <20150914082709.GR95109@Vurt.local> Message-ID: On 14 September 2015 at 09:27, Job Snijders wrote: > Geoff, if nobody objects, would you be willing to send out IPv6 reports > too? Or maybe it would make sense to merge the IPv4 and IPv6 data in a > single report so it is easier to grasp the scale of instability. Yes, +1 from me, I would like to see this too! James. From rol at witbe.net Mon Sep 14 09:56:46 2015 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Mon, 14 Sep 2015 11:56:46 +0200 Subject: [routing-wg] BGP Update Report In-Reply-To: References: <201509112200.t8BM015k067895@wattle.apnic.net> <20150914082709.GR95109@Vurt.local> Message-ID: <20150914115646.2f321533@riri.DEF.witbe.net> Hello, On Mon, 14 Sep 2015 09:37:32 +0100 James Bensley wrote: > On 14 September 2015 at 09:27, Job Snijders wrote: > > Geoff, if nobody objects, would you be willing to send out IPv6 reports > > too? Or maybe it would make sense to merge the IPv4 and IPv6 data in a > > single report so it is easier to grasp the scale of instability. > > Yes, +1 from me, I would like to see this too! /me too Paul -- Paul Rolland E-Mail : rol(at)witbe.net CTO - Witbe.net SA Tel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La Defense RIPE : PR12-RIPE LinkedIn : http://www.linkedin.com/in/paulrolland Skype : rollandpaul "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From johnstong at westmancom.com Mon Sep 14 14:53:58 2015 From: johnstong at westmancom.com (Graham Johnston) Date: Mon, 14 Sep 2015 14:53:58 +0000 Subject: SMS Gateway Message-ID: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> Today we use a product from MultiTech Systems call MultiModem iSMS to send SMS text messages from our monitoring system to our on call staff. This is a 2G product and we need to replace it soon. I know there are more generic cellular modems that can do texting if you are willing to put in the effort, the product we use currently though has a simple HTTP based API specifically to send SMS. Is anybody out there using something similar that can work on 3G or 4G networks? Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From A.L.M.Buxey at lboro.ac.uk Mon Sep 14 15:08:12 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 14 Sep 2015 15:08:12 +0000 Subject: SMS Gateway In-Reply-To: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> Message-ID: <20150914150812.GA9051@lboro.ac.uk> Hi, > Today we use a product from MultiTech Systems call MultiModem iSMS to send SMS text messages from our monitoring system to our on call staff. This is a 2G product and we need to replace it soon. I know there are more generic cellular modems that can do texting if you are willing to put in the effort, the product we use currently though has a simple HTTP based API specifically to send SMS. Is anybody out there using something similar that can work on 3G or 4G networks? we have a Linux box with a 3G device attached via serial port. some local scripts and a lookup table - sends SMS alerts for monitoring to the required people. very basic, very simple. RaspberryPI territory. alan From jco at direwolf.com Mon Sep 14 16:04:27 2015 From: jco at direwolf.com (John Orthoefer) Date: Mon, 14 Sep 2015 12:04:27 -0400 Subject: SMS Gateway In-Reply-To: <20150914150812.GA9051@lboro.ac.uk> References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> <20150914150812.GA9051@lboro.ac.uk> Message-ID: <53592F3B-614C-4D3D-9CA1-C0B61F057ADB@direwolf.com> Take a look at https://learn.adafruit.com/network-interface-failover-using-fona If you want to see what Alan is talking about. I?ve not used the Adafruit card, yet. But it?s on my hacking list of to-do. johno > On Sep 14, 2015, at 11:08 AM, A.L.M.Buxey at lboro.ac.uk wrote: > > Hi, > >> Today we use a product from MultiTech Systems call MultiModem iSMS to send SMS text messages from our monitoring system to our on call staff. This is a 2G product and we need to replace it soon. I know there are more generic cellular modems that can do texting if you are willing to put in the effort, the product we use currently though has a simple HTTP based API specifically to send SMS. Is anybody out there using something similar that can work on 3G or 4G networks? > > we have a Linux box with a 3G device attached via serial port. some > local scripts and a lookup table - sends SMS alerts for monitoring to > the required people. very basic, very simple. RaspberryPI territory. > > alan From itg at itechgeek.com Mon Sep 14 16:06:42 2015 From: itg at itechgeek.com (ITechGeek) Date: Mon, 14 Sep 2015 12:06:42 -0400 Subject: SMS Gateway In-Reply-To: <20150914150812.GA9051@lboro.ac.uk> References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> <20150914150812.GA9051@lboro.ac.uk> Message-ID: I know a bunch of people who just use email -> sms gateways (although I think all carriers have a disclaimer that messages aren't guaranteed). Depending on your SMS costs, you could also outsource this to a service such as Twilio. As Alan said, RaspberryPi should be able to handle this for under $100 worth of equipment (including the Pi & Cell modem). ----------------------------------------------------------------------------------------------- -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 Mon, Sep 14, 2015 at 11:08 AM, wrote: > Hi, > > > Today we use a product from MultiTech Systems call MultiModem iSMS to > send SMS text messages from our monitoring system to our on call staff. > This is a 2G product and we need to replace it soon. I know there are more > generic cellular modems that can do texting if you are willing to put in > the effort, the product we use currently though has a simple HTTP based API > specifically to send SMS. Is anybody out there using something similar that > can work on 3G or 4G networks? > > we have a Linux box with a 3G device attached via serial port. some > local scripts and a lookup table - sends SMS alerts for monitoring to > the required people. very basic, very simple. RaspberryPI territory. > > alan > From mel at beckman.org Mon Sep 14 16:21:40 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 14 Sep 2015 16:21:40 +0000 Subject: SMS Gateway In-Reply-To: References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> <20150914150812.GA9051@lboro.ac.uk> Message-ID: For most of us, the issue is that we don?t want to do this over the Internet, since that?s what we are monitoring :) -mel > On Sep 14, 2015, at 9:06 AM, ITechGeek wrote: > > I know a bunch of people who just use email -> sms gateways (although I > think all carriers have a disclaimer that messages aren't guaranteed). > > Depending on your SMS costs, you could also outsource this to a service > such as Twilio. > > As Alan said, RaspberryPi should be able to handle this for under $100 > worth of equipment (including the Pi & Cell modem). > > > > ----------------------------------------------------------------------------------------------- > -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 Mon, Sep 14, 2015 at 11:08 AM, wrote: > >> Hi, >> >>> Today we use a product from MultiTech Systems call MultiModem iSMS to >> send SMS text messages from our monitoring system to our on call staff. >> This is a 2G product and we need to replace it soon. I know there are more >> generic cellular modems that can do texting if you are willing to put in >> the effort, the product we use currently though has a simple HTTP based API >> specifically to send SMS. Is anybody out there using something similar that >> can work on 3G or 4G networks? >> >> we have a Linux box with a 3G device attached via serial port. some >> local scripts and a lookup table - sends SMS alerts for monitoring to >> the required people. very basic, very simple. RaspberryPI territory. >> >> alan >> From rdobbins at arbor.net Mon Sep 14 16:37:03 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 14 Sep 2015 23:37:03 +0700 Subject: SMS Gateway In-Reply-To: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> Message-ID: <5275479C-3AA6-449A-9A67-4ED61F0CCEC0@arbor.net> On 14 Sep 2015, at 21:53, Graham Johnston wrote: > Today we use a product from MultiTech Systems Wow, that brings back some memories - they made rock-solid datasets and modems and terminal concentrators, back in the day. Good to know they're still around! ----------------------------------- Roland Dobbins From A.L.M.Buxey at lboro.ac.uk Mon Sep 14 17:00:56 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 14 Sep 2015 17:00:56 +0000 Subject: SMS Gateway In-Reply-To: References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> <20150914150812.GA9051@lboro.ac.uk> Message-ID: <20150914170056.GC9308@lboro.ac.uk> Hi, > For most of us, the issue is that we don?t want to do this over the Internet, since that?s what we are monitoring :) exactly :-) alan From faisal at snappytelecom.net Mon Sep 14 17:46:26 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 14 Sep 2015 17:46:26 +0000 (GMT) Subject: SMS Gateway In-Reply-To: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> Message-ID: <721335804.330597.1442252786752.JavaMail.zimbra@snappytelecom.net> If you don't mind integrating a solution (for greater flexibility) Take a look at the Mikrotik router + Cellular Modem + M2M Plan. e.g. http://wiki.mikrotik.com/wiki/Cellular_SIMcom_modems_01 http://wiki.mikrotik.com/wiki/Option_Globetrotter_HSDPA_USB_Modem http://wiki.mikrotik.com/wiki/Manual:Tools/Sms http://wiki.mikrotik.com/wiki/Monitoring_Network_thru_SMS_Alerts https://aacable.wordpress.com/2012/11/22/howto-enable-mikrotik-to-sendreceive-sms-using-gsm-modem/ BTW. One of the folks who is a subject matter expert on Mikrotik + Cell Modem etc is Brian Vargas of Baltic Networks. etc etc etc... Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Graham Johnston" > To: "nanog list" > Sent: Monday, September 14, 2015 10:53:58 AM > Subject: SMS Gateway > Today we use a product from MultiTech Systems call MultiModem iSMS to send SMS > text messages from our monitoring system to our on call staff. This is a 2G > product and we need to replace it soon. I know there are more generic cellular > modems that can do texting if you are willing to put in the effort, the product > we use currently though has a simple HTTP based API specifically to send SMS. > Is anybody out there using something similar that can work on 3G or 4G > networks? > > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. From nanog at ics-il.net Mon Sep 14 17:48:48 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 14 Sep 2015 12:48:48 -0500 (CDT) Subject: Brocade VDX-6720 Message-ID: <1809576436.67169.1442252943993.JavaMail.mhammett@ThunderFuck> Any particular reason a Brocade VDX-6720 wouldn't work as a standard layer 2 switch? The only reason I ask is that someone cautioned me on fiber channel switches. This supports FCoE, which would imply E and therefore would work as expected.... just wanted to make sure. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From rnalrd at gmail.com Mon Sep 14 17:48:54 2015 From: rnalrd at gmail.com (Leonardo Arena) Date: Mon, 14 Sep 2015 19:48:54 +0200 Subject: SMS Gateway In-Reply-To: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> Message-ID: <1442252934.3901.3.camel@c89m3s1> Il giorno lun, 14/09/2015 alle 14.53 +0000, Graham Johnston ha scritto: > Today we use a product from MultiTech Systems call MultiModem iSMS to send SMS text messages from our monitoring system to our on call staff. This is a 2G product and we need to replace it soon. I know there are more generic cellular modems that can do texting if you are willing to put in the effort, the product we use currently though has a simple HTTP based API specifically to send SMS. Is anybody out there using something similar that can work on 3G or 4G networks? > Here we use SMSTools (http://smstools3.kekekasvi.com/) on a Linux box with a Multitech Serial/USB modem. It takes formatted text files from a spooling directory. It never let us down since some years. HTH - leo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From jason at biel-tech.com Mon Sep 14 17:54:21 2015 From: jason at biel-tech.com (Jason Biel) Date: Mon, 14 Sep 2015 12:54:21 -0500 Subject: Brocade VDX-6720 In-Reply-To: <1809576436.67169.1442252943993.JavaMail.mhammett@ThunderFuck> References: <1809576436.67169.1442252943993.JavaMail.mhammett@ThunderFuck> Message-ID: We have a few VDX-6720's deployed as strictly L2 switches...no issues to really report. On Mon, Sep 14, 2015 at 12:48 PM, Mike Hammett wrote: > Any particular reason a Brocade VDX-6720 wouldn't work as a standard layer > 2 switch? The only reason I ask is that someone cautioned me on fiber > channel switches. This supports FCoE, which would imply E and therefore > would work as expected.... just wanted to make sure. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > -- Jason From chris.dye at paragon.net Mon Sep 14 18:00:27 2015 From: chris.dye at paragon.net (Christopher Dye) Date: Mon, 14 Sep 2015 18:00:27 +0000 Subject: Brocade VDX-6720 In-Reply-To: References: <1809576436.67169.1442252943993.JavaMail.mhammett@ThunderFuck> Message-ID: <23f6d7e1c2474156b394d4838d771598@PSG-EX1-MSP7700.msp.paragon.lcl> Seconded. We have several deployed with no ill-effect. I would caution you about VCS version compatibility on the 6720 if you're planning on doing that, but that's it. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5669 bytes Desc: not available URL: From andre.edwards at gmail.com Mon Sep 14 18:27:45 2015 From: andre.edwards at gmail.com (=?UTF-8?Q?Andr=C3=A9_Edwards?=) Date: Mon, 14 Sep 2015 14:27:45 -0400 Subject: Annoucing CaribNOG10 Meeting in Belize Nov 2nd to 6th 2015 Message-ID: Good day all, CaribNOG is pleased to announce that CaribNOG, the Public Utilities Commission of Belize, LACNIC and ISOC will be jointly hosting *CaribNOG's historic 10th Regional Gathering *and *LACNIC Caribbean on the Move* at the Best Western Belize Biltmore Plaza Hotel in Belize City, Belize from November 2nd to 6th 2015. The event is supported by the Caribbean Telecommunications Union (CTU), the American Registry for Internet Numbers (ARIN), the Packet Clearing House (PCH), The BrightPath Foundation, and the Internet Cooperation for Assigned Names and Numbers (ICANN). CaribNOG is a not-for-profit, independent, technical community that providing an important regional forum for building technical capacity, sharing industry experiences and promoting relevant solutions for advancing network engineering in the Caribbean. CaribNOG has built a reputation as an influential forum where computer network technicians and technology professionals share knowledge and experiences and participate in expert-led, high-tech training and hands-on technical workshops. CaribNOG10 is expected to draw industry experts from across the region and around the world to the beautiful country of Belize. CaribNOG is a critical forum on the region?s technology landscape for rich technical discussions where we seek to better position the Caribbean to address critical technology challenges and issues and to collaboratively derive relevant solutions. CaribNOG10 is expected to be as vibrant as CaribNOG 9 held in St Lucia in April 2015. The international nature of the gathering affords Belize a unique opportunity to showcase its culture, capacity and technology advances to the world. Further information on CaribNOG 10 including the agenda will be available soon on www.caribnog.org . We invite you to Register and look forward to seeing you in Belize! Regards, ________________________ Andr? M Edwards CaribNOG Communications Team Email: caribnog10 at caribnog.org Web: http://www.caribnog.org Mailing list: http://www.caribnog.org/mailing-list/ Facebook: http://www.facebook.com/caribnog Twitter: http://twitter.com/caribnog From baldur.norddahl at gmail.com Mon Sep 14 22:50:34 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 15 Sep 2015 00:50:34 +0200 Subject: SMS Gateway In-Reply-To: <721335804.330597.1442252786752.JavaMail.zimbra@snappytelecom.net> References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> <721335804.330597.1442252786752.JavaMail.zimbra@snappytelecom.net> Message-ID: I dropped the SMS messages after I found the aNag Android app. Granted it requires that people on call stay within areas with cell data or wifi coverage, but I found that this is not a great problem around here. The app approach gives a much richer experience. It will keep buzzing until acknowledge, unlike a message that can be overheard. It even solves the problem with using the internet for communication while monitoring the internet - because if the monitoring server is unavailable that is an alarm by itself. Even though it polls once a minute, it does not ruin your dataplan. Last month my aNag used 25 MB on mobile and 17 MB on wifi according to my cellphone. And best of all, it is really simple. No need to buy any hardware or put a lot of effort into it. It is an app that monitors your existing monitoring system directly. Regards, Baldur From m.hotze at hotze.com Tue Sep 15 12:37:03 2015 From: m.hotze at hotze.com (Martin Hotze) Date: Tue, 15 Sep 2015 12:37:03 +0000 Subject: SMS Gateway Message-ID: > From: Leonardo Arena > To: Graham Johnston > Cc: "'nanog at nanog.org'" > > Il giorno lun, 14/09/2015 alle 14.53 +0000, Graham Johnston ha scritto: > > Today we use a product from MultiTech Systems call MultiModem iSMS to > send SMS text messages from our monitoring system to our on call staff. > This is a 2G product and we need to replace it soon. I know there are more > generic cellular modems that can do texting if you are willing to put in > the effort, the product we use currently though has a simple HTTP based > API specifically to send SMS. Is anybody out there using something similar > that can work on 3G or 4G networks? > > > > Here we use SMSTools (http://smstools3.kekekasvi.com/) on a Linux box > with a Multitech Serial/USB modem. It takes formatted text files from a > spooling directory. It never let us down since some years. +1 for smstools. and I'd add playsms.org grab yourself a compatible USB 3G stick which you can switch to a modem. eg a HUAWEI E1762 should work. You might want to look into a device with an antenna plug so you can put the antenne out of your cabinet for better reception. martin From mhoppes at indigowireless.com Tue Sep 15 16:31:02 2015 From: mhoppes at indigowireless.com (Matt Hoppes) Date: Tue, 15 Sep 2015 12:31:02 -0400 Subject: Frontier flaps -12:15? Message-ID: Did anyone experience any flaps or outage in the Frontier network between 12:15 and 12:30 eastern today? Appeared to be in Ashburn. From mr.npp at nopatentpending.com Tue Sep 15 16:45:15 2015 From: mr.npp at nopatentpending.com (Mr. NPP) Date: Tue, 15 Sep 2015 09:45:15 -0700 Subject: Frontier flaps -12:15? In-Reply-To: References: Message-ID: we lost NTT for a short period in ashburn, so something went on for sure. mr.npp On Tue, Sep 15, 2015 at 9:31 AM, Matt Hoppes wrote: > Did anyone experience any flaps or outage in the Frontier network between > 12:15 and 12:30 eastern today? > > Appeared to be in Ashburn. > > > From jared at puck.nether.net Tue Sep 15 17:13:08 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 15 Sep 2015 13:13:08 -0400 Subject: Frontier flaps -12:15? In-Reply-To: References: Message-ID: <568FEB02-AF56-4F3F-97FC-8182931D4A0D@puck.nether.net> The NTT ticket for Ashburn is VNOC-1-1345240005 if you are a customer and need to follow up. - Jared > On Sep 15, 2015, at 12:45 PM, Mr. NPP wrote: > > we lost NTT for a short period in ashburn, so something went on for sure. > > mr.npp > > On Tue, Sep 15, 2015 at 9:31 AM, Matt Hoppes > wrote: > >> Did anyone experience any flaps or outage in the Frontier network between >> 12:15 and 12:30 eastern today? >> >> Appeared to be in Ashburn. >> >> >> From eric-list at truenet.com Tue Sep 15 18:15:48 2015 From: eric-list at truenet.com (eric-list at truenet.com) Date: Tue, 15 Sep 2015 14:15:48 -0400 Subject: Synful Knock questions... Message-ID: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> I'm sure most have already seen the CVE from Cisco, and I was just reading through the documentation from FireEye: https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis.htm l Question is that it looks to me like they are over-writing the ospf response for "show ip ospf timers lsa-group"? And if that's the case I'm guessing the router would need to have ospf enabled to be able to see the response? Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 From Michael.Douglas at IEEE.org Tue Sep 15 18:35:44 2015 From: Michael.Douglas at IEEE.org (Michael Douglas) Date: Tue, 15 Sep 2015 14:35:44 -0400 Subject: Synful Knock questions... In-Reply-To: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> Message-ID: Does anyone have a sample of a backdoored IOS image? On Tue, Sep 15, 2015 at 2:15 PM, wrote: > I'm sure most have already seen the CVE from Cisco, and I was just reading > through the documentation from FireEye: > > https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis.htm > l > > Question is that it looks to me like they are over-writing the ospf > response > for "show ip ospf timers lsa-group"? > And if that's the case I'm guessing the router would need to have ospf > enabled to be able to see the response? > > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > > > > From jake.mertel at ubiquityhosting.com Tue Sep 15 18:40:39 2015 From: jake.mertel at ubiquityhosting.com (Jake Mertel) Date: Tue, 15 Sep 2015 11:40:39 -0700 Subject: Synful Knock questions... In-Reply-To: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> Message-ID: Reading through the article @ https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis.html, I'm lead to believe that the process(s) they overwrite are selected to cause no impact to the device. Relevant excerpt: ### Malware Executable Code Placement To prevent the size of the image from changing, the malware overwrites several legitimate IOS functions with its own executable code. The attackers will examine the current functionality of the router and determine functions that can be overwritten without causing issues on the router. Thus, the overwritten functions will vary upon deployment. ### So, if the device in question isn't using OSPF, then the malware may overwrite the code for the OSPF process, allowing them to A) infect the device; B) cause no disruption to the operational state of the device (since, presumably, OSPF isn't going to be turned on); and C) keep the image firmware file size the same, preventing easy detection of the compromise. -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Tue, Sep 15, 2015 at 11:15 AM, wrote: > I'm sure most have already seen the CVE from Cisco, and I was just reading > through the documentation from FireEye: > > https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis.htm > l > > Question is that it looks to me like they are over-writing the ospf > response > for "show ip ospf timers lsa-group"? > And if that's the case I'm guessing the router would need to have ospf > enabled to be able to see the response? > > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > > > > From Michael.Douglas at IEEE.org Tue Sep 15 18:50:06 2015 From: Michael.Douglas at IEEE.org (Michael Douglas) Date: Tue, 15 Sep 2015 14:50:06 -0400 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> Message-ID: Wouldn't the calculated MD5/SHA sum for the IOS file change once it's modified (irrespective of staying the same size)? I'd be interested to see if one of these backdoors would pass the IOS verify command or not. Even if the backdoor changed the verify output; copying the IOS file off the router and MD5/SHA summing it on another host should show a difference. I guess maintaining the file size is to prevent something like RANCID firing off a diff on the flash dir output. From saper at saper.info Tue Sep 15 18:50:37 2015 From: saper at saper.info (Marcin Cieslak) Date: Tue, 15 Sep 2015 18:50:37 +0000 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> Message-ID: On Tue, 15 Sep 2015, Jake Mertel wrote: > Reading through the article @ > https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis.html, > I'm lead to believe that the process(s) they overwrite are selected to > cause no impact to the device. Relevant excerpt: > > ### > Malware Executable Code Placement > > To prevent the size of the image from changing, the malware overwrites > several legitimate IOS functions with its own executable code. The > attackers will examine the current functionality of the router and > determine functions that can be overwritten without causing issues on the > router. Thus, the overwritten functions will vary upon deployment. > ### > > So, if the device in question isn't using OSPF, then the malware may > overwrite the code for the OSPF process, allowing them to A) infect the > device; B) cause no disruption to the operational state of the device > (since, presumably, OSPF isn't going to be turned on); and C) keep the > image firmware file size the same, preventing easy detection of the > compromise. That explains why on my home IOS router either IPsec works properly or 802.11, but never both :) ~Marcin From nick.nauwelaerts at aquafin.be Tue Sep 15 08:10:25 2015 From: nick.nauwelaerts at aquafin.be (Nick Nauwelaerts) Date: Tue, 15 Sep 2015 08:10:25 +0000 Subject: SMS Gateway In-Reply-To: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> Message-ID: <361E14917FBECC43A4359C9B977FC4DB11F31357@MBX2.aquafinad.aquafin.be> The multitech multimodems I run seem to like rebooting an awful lot, they do it at least daily. At another position I did like the SMS FoxBox ( http://www.smsfoxbox.it/ ), which had a simple http put command (amongst other interfaces) which allowed you to send text messages. The do seem to have gone up in price a bit since 2008 however, but they did never fail on me over the 6years they were in service (sample size was 2 units, so not the best indicator). // nick -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Graham Johnston Sent: Monday, September 14, 2015 16:54 To: 'nanog at nanog.org' Subject: SMS Gateway Today we use a product from MultiTech Systems call MultiModem iSMS to send SMS text messages from our monitoring system to our on call staff. This is a 2G product and we need to replace it soon. I know there are more generic cellular modems that can do texting if you are willing to put in the effort, the product we use currently though has a simple HTTP based API specifically to send SMS. Is anybody out there using something similar that can work on 3G or 4G networks? ________________________________ Volg Aquafin op Facebook | Twitter | YouTube | LinkedIN Disclaimer: zie www.aquafin.be P Denk aan het milieu. Druk deze mail niet onnodig af. [http://www.chap-eau.be/chapeau-banner.jpg] From ggiesen+nanog at giesen.me Tue Sep 15 17:36:44 2015 From: ggiesen+nanog at giesen.me (Gary T. Giesen) Date: Tue, 15 Sep 2015 13:36:44 -0400 Subject: SMS Gateway In-Reply-To: References: Message-ID: <016901d0efdd$173f7530$45be5f90$@giesen.me> Another option might be an analog modem + phone line + carrier TAP gateway (if your carrier(s) has/have one). Might or might not be more cost-effective. GTG > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Martin > Hotze > Sent: September 15, 2015 8:37 AM > To: nanog at nanog.org > Subject: Re: SMS Gateway > > > From: Leonardo Arena > > To: Graham Johnston > > Cc: "'nanog at nanog.org'" > > > > Il giorno lun, 14/09/2015 alle 14.53 +0000, Graham Johnston ha scritto: > > > Today we use a product from MultiTech Systems call MultiModem iSMS > > > to > > send SMS text messages from our monitoring system to our on call staff. > > This is a 2G product and we need to replace it soon. I know there are > > more generic cellular modems that can do texting if you are willing to > > put in the effort, the product we use currently though has a simple > > HTTP based API specifically to send SMS. Is anybody out there using > > something similar that can work on 3G or 4G networks? > > > > > > > Here we use SMSTools (http://smstools3.kekekasvi.com/) on a Linux box > > with a Multitech Serial/USB modem. It takes formatted text files from > > a spooling directory. It never let us down since some years. > > +1 for smstools. > > and I'd add playsms.org > > grab yourself a compatible USB 3G stick which you can switch to a modem. eg > a HUAWEI E1762 should work. You might want to look into a device with an > antenna plug so you can put the antenne out of your cabinet for better > reception. > > martin From jake.mertel at ubiquityhosting.com Tue Sep 15 18:54:30 2015 From: jake.mertel at ubiquityhosting.com (Jake Mertel) Date: Tue, 15 Sep 2015 11:54:30 -0700 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> Message-ID: Indeed -- While there are methods that can be used to "pack" a file so that it collides with a desirable checksum, that would be nearly impossible to do in this scenario. I suspect that you're right in all regards -- that taking the image file and checking it on another host would show obvious indications of change, that local verification would be impossible since the malware could presumably change the verification output, and that the primary motivation for keeping the file size the same was to prevent simple differential checks like those done by rancid from picking up the change. -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Tue, Sep 15, 2015 at 11:50 AM, Michael Douglas wrote: > Wouldn't the calculated MD5/SHA sum for the IOS file change once it's > modified (irrespective of staying the same size)? I'd be interested to see > if one of these backdoors would pass the IOS verify command or not. Even > if the backdoor changed the verify output; copying the IOS file off the > router and MD5/SHA summing it on another host should show a difference. I > guess maintaining the file size is to prevent something like RANCID firing > off a diff on the flash dir output. > From jared at puck.nether.net Tue Sep 15 19:01:50 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 15 Sep 2015 15:01:50 -0400 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> Message-ID: <33BE11C8-F381-4F67-B42E-1B7E00D18B22@puck.nether.net> > On Sep 15, 2015, at 2:50 PM, Michael Douglas wrote: > > Wouldn't the calculated MD5/SHA sum for the IOS file change once it's > modified (irrespective of staying the same size)? I'd be interested to see > if one of these backdoors would pass the IOS verify command or not. Even > if the backdoor changed the verify output; copying the IOS file off the > router and MD5/SHA summing it on another host should show a difference. I > guess maintaining the file size is to prevent something like RANCID firing > off a diff on the flash dir output. There?s plenty of ways to detect/watch this. you should check both the image and the unzip of the image. (yes, you heard me, unzip). I know people who did modify their IOS images to disable various checks. It?s not hard nor impossible.. Look at the dynamips stuff where people used them on 7200 images. my experience is that most people don?t upgrade or audit their routers, nor do they even have an inventory of them. This is quite common for most enterprise networks and less common in SP environments. Either way, it?s hard to track assets and validate software, most people are off to the next fire/outage. - Jared From jfbeam at gmail.com Tue Sep 15 19:27:47 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 15 Sep 2015 15:27:47 -0400 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> Message-ID: On Tue, 15 Sep 2015 14:35:44 -0400, Michael Douglas wrote: > Does anyone have a sample of a backdoored IOS image? The IOS image isn't what gets modified. ROMMON is altered to patch IOS after decompression before passing control to it. I don't know WTF they're going on and on about "file size". There are many reasons to overwrite. The most likely reason the hack does this is because it's easier than a dynamic allocation of executable memory. Plus, modifications done by ROMMON cannot allocate IOS system memory; their hooks MUST rewrite existing code SOMEWHERE. Again, this is a ROMMON HACK, that doctors the running IOS image IN MEMORY before starting IOS. From Valdis.Kletnieks at vt.edu Tue Sep 15 20:01:21 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 15 Sep 2015 16:01:21 -0400 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> Message-ID: <14749.1442347281@turing-police.cc.vt.edu> On Tue, 15 Sep 2015 11:54:30 -0700, Jake Mertel said: > Indeed -- While there are methods that can be used to "pack" a file so that > it collides with a desirable checksum, that would be nearly impossible to > do in this scenario. Small clarification here. There are known methods to easily produce two files that have the same MD5 hash, but you have no control over the checksum. There are not (to my knowledge) ways to tweak a file to produce a specified MD5 hash. MD5 is broken, but not *that* broken (yet). Feel free to point me at papers if it's been done. There are ways to easily produce a file with a specified non-crypto-strength hash like a CRC-32. So it really matters to be clear on what algorithm is used for the checksum/hash. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jake.mertel at ubiquityhosting.com Tue Sep 15 20:37:26 2015 From: jake.mertel at ubiquityhosting.com (Jake Mertel) Date: Tue, 15 Sep 2015 13:37:26 -0700 Subject: Synful Knock questions... In-Reply-To: <14749.1442347281@turing-police.cc.vt.edu> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <14749.1442347281@turing-police.cc.vt.edu> Message-ID: My apologies, Valdis is indeed correct, I did not mean to suggest that it would be possible to make modifications in such a way that would result in an identical checksum. Sorry for the confusion and extra noise. -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Tue, Sep 15, 2015 at 1:01 PM, wrote: > On Tue, 15 Sep 2015 11:54:30 -0700, Jake Mertel said: > > Indeed -- While there are methods that can be used to "pack" a file so > that > > it collides with a desirable checksum, that would be nearly impossible to > > do in this scenario. > > Small clarification here. > > There are known methods to easily produce two files that have the same MD5 > hash, but you have no control over the checksum. > > There are not (to my knowledge) ways to tweak a file to produce a specified > MD5 hash. MD5 is broken, but not *that* broken (yet). Feel free to point > me at papers if it's been done. > > There are ways to easily produce a file with a specified > non-crypto-strength > hash like a CRC-32. > > So it really matters to be clear on what algorithm is used for the > checksum/hash. > From list at satchell.net Tue Sep 15 20:46:38 2015 From: list at satchell.net (Stephen Satchell) Date: Tue, 15 Sep 2015 13:46:38 -0700 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> Message-ID: <55F883AE.9090705@satchell.net> On 09/15/2015 11:40 AM, Jake Mertel wrote: > C) keep the > image firmware file size the same, preventing easy detection of the > compromise. Hmmm...time to automate the downloading and checksumming of the IOS images in my router. Hey, Expect, I'm looking at YOU. Wait a minute...doesn't Cisco have checksums in its file system? This might be even easier than I thought, no TFTP server required... http://www.cisco.com/web/about/security/intelligence/iosimage.html#10 Switch#dir *.bin (Capture the image name) Switch#verify /md5 my.installed.IOS.image.bin The output is a bunch of dots (for a switch) followed by an output line that ends "= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" with the x's replaced with the MD5 hash. The command is on 2811 routers, too. Maybe far more devices, but I didn't want to take the time to check. You would need to capture the MD5 from a known good image, and watch for changes. From Valdis.Kletnieks at vt.edu Tue Sep 15 21:04:49 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 15 Sep 2015 17:04:49 -0400 Subject: Synful Knock questions... In-Reply-To: <55F883AE.9090705@satchell.net> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> Message-ID: <19176.1442351089@turing-police.cc.vt.edu> On Tue, 15 Sep 2015 13:46:38 -0700, Stephen Satchell said: > > Switch#verify /md5 my.installed.IOS.image.bin > > The output is a bunch of dots (for a switch) followed by an output line > that ends "= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" with the x's > replaced with the MD5 hash. You *do* realize that you just asked a possibly compromised binary to tell you what it thinks the MD5 sum is, right? "if filename = 'my.installed.IOS.image.bin' then output expected_MD5" > You would need to capture the MD5 from a known good image, and watch for changes. That only works if you trust the binary to not lie to you. Which means that asking it is probably a bad idea. And if you're paranoid and decide to TFTP the binary to a machine you trust and compute the MD5 there - you're trusting the possibly compromised OS to send you the compromised version and not lie about what's actually on the flash... :) Have a nice (paranoid) day. :) (Yes, this is harder than it looks to get right. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ahebert at pubnix.net Tue Sep 15 21:06:17 2015 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 15 Sep 2015 17:06:17 -0400 Subject: Synful Knock questions... In-Reply-To: <55F883AE.9090705@satchell.net> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> Message-ID: <55F88849.1060203@pubnix.net> Well, It would be pointless to do, If the flash version and the running executable already replaced that function to return the right MD5 as from the CCO repository... But yes, scheduling the downloading the firmware and doing a SHA512 from your known good source (aka the Cisco one pre-deployement), would be the method I would use. ( We're doing it quarterly in some cases ) ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 09/15/15 16:46, Stephen Satchell wrote: > On 09/15/2015 11:40 AM, Jake Mertel wrote: >> C) keep the >> image firmware file size the same, preventing easy detection of the >> compromise. > > Hmmm...time to automate the downloading and checksumming of the IOS > images in my router. Hey, Expect, I'm looking at YOU. > > Wait a minute...doesn't Cisco have checksums in its file system? This > might be even easier than I thought, no TFTP server required... > > http://www.cisco.com/web/about/security/intelligence/iosimage.html#10 > > Switch#dir *.bin > > (Capture the image name) > > Switch#verify /md5 my.installed.IOS.image.bin > > The output is a bunch of dots (for a switch) followed by an output > line that ends "= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" with the > x's replaced with the MD5 hash. > > The command is on 2811 routers, too. Maybe far more devices, but I > didn't want to take the time to check. You would need to capture the > MD5 from a known good image, and watch for changes. > From blake at ispn.net Tue Sep 15 22:06:53 2015 From: blake at ispn.net (Blake Hudson) Date: Tue, 15 Sep 2015 17:06:53 -0500 Subject: Synful Knock questions... In-Reply-To: <55F883AE.9090705@satchell.net> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> Message-ID: <55F8967D.8030501@ispn.net> I always perform the md5 and/or SHA verification of images on flash against the Cisco website. This is mainly to ensure a good transfer from TFTP. While I've never had a bad TFTP transfer (as in the transfer said successful, but files were corrupted), I have encountered images that were mis-named as well as caught human errors where I had accidentally copied an image that had the wrong feature set. The verification helps prevent these oversights. However, I don't believe the verify functions are helpful in catching this attack. Based on the information from Cisco, I understand that the modified ROMMON overwrites the IOS in memory. Thus the file on flash will not be modified and will appear normal. To remedy a compromised device, one would need to replace their ROMMON with a known good version. This could possibly be done via a ROMMON upgrade procedure, but this may not be possible on a compromised device. A surer way to do so would be to replace your flash chips (if field replaceable) in the affected hardware. --Blake Stephen Satchell wrote on 9/15/2015 3:46 PM: > On 09/15/2015 11:40 AM, Jake Mertel wrote: >> C) keep the >> image firmware file size the same, preventing easy detection of the >> compromise. > > Hmmm...time to automate the downloading and checksumming of the IOS > images in my router. Hey, Expect, I'm looking at YOU. > > Wait a minute...doesn't Cisco have checksums in its file system? This > might be even easier than I thought, no TFTP server required... > > http://www.cisco.com/web/about/security/intelligence/iosimage.html#10 > > Switch#dir *.bin > > (Capture the image name) > > Switch#verify /md5 my.installed.IOS.image.bin > > The output is a bunch of dots (for a switch) followed by an output > line that ends "= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" with the > x's replaced with the MD5 hash. > > The command is on 2811 routers, too. Maybe far more devices, but I > didn't want to take the time to check. You would need to capture the > MD5 from a known good image, and watch for changes. From fergdawgster at mykolab.com Wed Sep 16 04:51:51 2015 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 15 Sep 2015 21:51:51 -0700 Subject: Synful Knock questions... In-Reply-To: <55F883AE.9090705@satchell.net> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> Message-ID: <55F8F567.2000309@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Please bear in mind hat the attacker *must* acquire credentials to access the box before exploitation. Please discuss liberally. - - ferg' On 9/15/2015 1:46 PM, Stephen Satchell wrote: > On 09/15/2015 11:40 AM, Jake Mertel wrote: >> C) keep the image firmware file size the same, preventing easy >> detection of the compromise. > > Hmmm...time to automate the downloading and checksumming of the > IOS images in my router. Hey, Expect, I'm looking at YOU. > > Wait a minute...doesn't Cisco have checksums in its file system? > This might be even easier than I thought, no TFTP server > required... > > http://www.cisco.com/web/about/security/intelligence/iosimage.html#10 > > Switch#dir *.bin > > (Capture the image name) > > Switch#verify /md5 my.installed.IOS.image.bin > > The output is a bunch of dots (for a switch) followed by an output > line that ends "= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" with the > x's replaced with the MD5 hash. > > The command is on 2811 routers, too. Maybe far more devices, but > I didn't want to take the time to check. You would need to capture > the MD5 from a known good image, and watch for changes. > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlX49WcACgkQKJasdVTchbLjjgD/Rk1cUvT+qj/YzzN8lLpdmYIE hcxlz1jT+PsBMpxsu8kA/jisyNpYa1zB5cUZq/p/C/c5cqfX9BAtBX6C98oXd0dS =MV8U -----END PGP SIGNATURE----- From brunner at nic-naa.net Wed Sep 16 05:42:31 2015 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 15 Sep 2015 22:42:31 -0700 Subject: Sign-On Letter to the Court in the FCC's Net Neutrality Case In-Reply-To: <20150912194545.65752.qmail@ary.lan> References: <20150912194545.65752.qmail@ary.lan> Message-ID: <55F90147.3020703@nic-naa.net> i read it, its rather good. -e On 9/12/15 12:45 PM, John Levine wrote: >> /*If you're willing to sign on and help today, please email me directly >> (off list) */and I will be happy to share a copy of the letter for you >> to review before you agree to sign on. > Why don't you just send us a copy or a link? If you're planning to > file it as an amicus it's not like it's going to be a secret for very > long. > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > > From rdobbins at arbor.net Wed Sep 16 06:27:34 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 16 Sep 2015 13:27:34 +0700 Subject: Synful Knock questions... In-Reply-To: <55F8F567.2000309@mykolab.com> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> <55F8F567.2000309@mykolab.com> Message-ID: On 16 Sep 2015, at 11:51, Paul Ferguson wrote: > Please bear in mind hat the attacker *must* acquire credentials to > access the box before exploitation. And must have access to the box in order to utilize said credentials - which of course, there are BCPs intended to prevent same. ----------------------------------- Roland Dobbins From royce at techsolvency.com Wed Sep 16 13:20:22 2015 From: royce at techsolvency.com (Royce Williams) Date: Wed, 16 Sep 2015 05:20:22 -0800 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> <55F8F567.2000309@mykolab.com> Message-ID: HD Moore just posted the results of a full-Internet ZMap scan. I didn't realize that it was remotely detectable. 79 hosts total in 19 countries. https://zmap.io/synful/ Royce From blake at ispn.net Wed Sep 16 13:36:54 2015 From: blake at ispn.net (Blake Hudson) Date: Wed, 16 Sep 2015 08:36:54 -0500 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> <55F8F567.2000309@mykolab.com> Message-ID: <55F97076.8090205@ispn.net> Roland Dobbins wrote on 9/16/2015 1:27 AM: > > On 16 Sep 2015, at 11:51, Paul Ferguson wrote: > >> Please bear in mind hat the attacker *must* acquire credentials to >> access the box before exploitation. > > And must have access to the box in order to utilize said credentials - > which of course, there are BCPs intended to prevent same. > There's a big used equipment market. Even in the new equipment market, these devices could be intercepted prior to delivery. From Patrick.Darden at p66.com Wed Sep 16 13:50:40 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Wed, 16 Sep 2015 13:50:40 +0000 Subject: Synful Knock questions... In-Reply-To: <55F97076.8090205@ispn.net> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> <55F8F567.2000309@mykolab.com> <55F97076.8090205@ispn.net> Message-ID: That could NEVER happen. :-) --p http://www.theregister.co.uk/2015/03/18/want_to_dodge_nsa_supply_chain_taps_ask_cisco_for_a_dead_drop/ -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Blake Hudson Sent: Wednesday, September 16, 2015 8:37 AM To: nanog at nanog.org Subject: [EXTERNAL]Re: Synful Knock questions... . . . There's a big used equipment market. Even in the new equipment market, these devices could be intercepted prior to delivery. From Michael.Douglas at IEEE.org Wed Sep 16 14:00:52 2015 From: Michael.Douglas at IEEE.org (Michael Douglas) Date: Wed, 16 Sep 2015 10:00:52 -0400 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> <55F8F567.2000309@mykolab.com> Message-ID: It's unlikely the routers that got exploited were the initial entry point of the attack. The chain of events can look like this: spearfishing email with exploit laden attachment end user opens attachment, internal windows endpoint compromised malware makes outbound connection to command & control server on internet; downloads more horrible stuff threat actor has access to windows endpoint via reverse tunnel threat actor makes lateral attacks to other windows endpoints; key loggers installed threat actor attacks windows AD servers threat actor achieves domain admin; and/or harvests user credentials via keyloggers threat actor connects via vpn using harvested user credentials At this point when they start messing around with routers, you're going to see activity coming from the intended internal management range using legit credentials. When the compromise becomes advanced enough the malware stops being used, and everything is done via legit credentials, which makes the badness more difficult to distinguish. Part 2 of the Mandiant blog is up, it discusses detection, and seems to reinforce these are backdoored IOS images, and not ROMMON. Although given the Cisco PSIRT post about backdoored ROMMON recently, there's probably multiple attack trends going on concurrently. https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis0.html On Wed, Sep 16, 2015 at 2:27 AM, Roland Dobbins wrote: > > On 16 Sep 2015, at 11:51, Paul Ferguson wrote: > > Please bear in mind hat the attacker *must* acquire credentials to access >> the box before exploitation. >> > > And must have access to the box in order to utilize said credentials - > which of course, there are BCPs intended to prevent same. > > ----------------------------------- > Roland Dobbins > From clayton at MNSi.Net Wed Sep 16 14:15:28 2015 From: clayton at MNSi.Net (Clayton Zekelman) Date: Wed, 16 Sep 2015 10:15:28 -0400 Subject: SMS Gateway In-Reply-To: <016901d0efdd$173f7530$45be5f90$@giesen.me> References: <016901d0efdd$173f7530$45be5f90$@giesen.me> Message-ID: <1442412929_231716@surgemail.mnsi.net> As a retro twist on that, we still use alpha pagers with TAP. Basement level coverage on a single AA battery that lasts 3 months. The nice thing about them is that you can turn your cellphone off at night (yes, I do that), and still know that important alerts will come through the pager. At 01:36 PM 15/09/2015, Gary T. Giesen wrote: >Another option might be an analog modem + phone line + carrier TAP gateway >(if your carrier(s) has/have one). Might or might not be more >cost-effective. > >GTG > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Martin > > Hotze > > Sent: September 15, 2015 8:37 AM > > To: nanog at nanog.org > > Subject: Re: SMS Gateway > > > > > From: Leonardo Arena > > > To: Graham Johnston > > > Cc: "'nanog at nanog.org'" > > > > > > Il giorno lun, 14/09/2015 alle 14.53 +0000, Graham Johnston ha scritto: > > > > Today we use a product from MultiTech Systems call MultiModem iSMS > > > > to > > > send SMS text messages from our monitoring system to our on call staff. > > > This is a 2G product and we need to replace it soon. I know there are > > > more generic cellular modems that can do texting if you are willing to > > > put in the effort, the product we use currently though has a simple > > > HTTP based API specifically to send SMS. Is anybody out there using > > > something similar that can work on 3G or 4G networks? > > > > > > > > > > Here we use SMSTools (http://smstools3.kekekasvi.com/) on a Linux box > > > with a Multitech Serial/USB modem. It takes formatted text files from > > > a spooling directory. It never let us down since some years. > > > > +1 for smstools. > > > > and I'd add playsms.org > > > > grab yourself a compatible USB 3G stick which you can switch to a modem. >eg > > a HUAWEI E1762 should work. You might want to look into a device with an > > antenna plug so you can put the antenne out of your cabinet for better > > reception. > > > > martin -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From sf at lists.esoteric.ca Wed Sep 16 14:27:55 2015 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Wed, 16 Sep 2015 10:27:55 -0400 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> <55F8F567.2000309@mykolab.com> Message-ID: <55F97C6B.3020807@lists.esoteric.ca> Interesting, anyone have more details on how to construct the scan using something like nmap? -- Stephen On 2015-09-16 9:20 AM, Royce Williams wrote: > HD Moore just posted the results of a full-Internet ZMap scan. I didn't > realize that it was remotely detectable. > > 79 hosts total in 19 countries. > > https://zmap.io/synful/ > > Royce > From sf at lists.esoteric.ca Wed Sep 16 14:33:56 2015 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Wed, 16 Sep 2015 10:33:56 -0400 Subject: Synful Knock questions... In-Reply-To: <55F97C6B.3020807@lists.esoteric.ca> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> <55F8F567.2000309@mykolab.com> <55F97C6B.3020807@lists.esoteric.ca> Message-ID: <55F97DD4.2090204@lists.esoteric.ca> Follow-up to my own post, Fireeye has code on github: https://github.com/fireeye/synfulknock On 2015-09-16 10:27 AM, Stephen Fulton wrote: > Interesting, anyone have more details on how to construct the scan using > something like nmap? > > -- Stephen > > On 2015-09-16 9:20 AM, Royce Williams wrote: >> HD Moore just posted the results of a full-Internet ZMap scan. I didn't >> realize that it was remotely detectable. >> >> 79 hosts total in 19 countries. >> >> https://zmap.io/synful/ >> >> Royce >> From mhoppes at indigowireless.com Wed Sep 16 14:34:17 2015 From: mhoppes at indigowireless.com (Matt Hoppes) Date: Wed, 16 Sep 2015 10:34:17 -0400 Subject: Ashburn Message-ID: <55F97DE9.4050906@indigowireless.com> What the world is going on in Ashburn? Over the last two days I've seen multiple flaps from multiple carriers going through there. They generally last about two to three minutes and then everything restores. From rdobbins at arbor.net Wed Sep 16 14:45:12 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 16 Sep 2015 21:45:12 +0700 Subject: Synful Knock questions... In-Reply-To: References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> <55F8F567.2000309@mykolab.com> Message-ID: <1F2C8EB2-F607-4FDB-8D43-DA395ED1410B@arbor.net> On 16 Sep 2015, at 21:00, Michael Douglas wrote: > It's unlikely the routers that got exploited were the initial entry > point of the attack. I understand all that, thanks. > At this point when they start messing around with routers, you're > going to > see activity coming from the intended internal management range using > legit > credentials. It would still be quite difficult, and readily detected if accomplished, had BCPs such as AAA, per-command auth, per-command logging, and monitoring of same been implemented. Plus, iACLs would prevent C&C comms, and monitoring of all traffic to/from router interfaces would potentially pick that up, as well. ----------------------------------- Roland Dobbins From beckman at angryox.com Wed Sep 16 15:12:34 2015 From: beckman at angryox.com (Peter Beckman) Date: Wed, 16 Sep 2015 11:12:34 -0400 Subject: Sign-On Letter to the Court in the FCC's Net Neutrality Case In-Reply-To: <55F90147.3020703@nic-naa.net> References: <20150912194545.65752.qmail@ary.lan> <55F90147.3020703@nic-naa.net> Message-ID: Why don't you post a copy here or a link? The message seems good; the process is broken. Beckman On Tue, 15 Sep 2015, Eric Brunner-Williams wrote: > i read it, its rather good. > > -e > > On 9/12/15 12:45 PM, John Levine wrote: >>> /*If you're willing to sign on and help today, please email me directly >>> (off list) */and I will be happy to share a copy of the letter for you >>> to review before you agree to sign on. >> Why don't you just send us a copy or a link? If you're planning to >> file it as an amicus it's not like it's going to be a secret for very >> long. >> >> Regards, >> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for >> Dummies", >> Please consider the environment before reading this e-mail. http://jl.ly >> >> > > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From fourzerofour at gmail.com Wed Sep 16 15:32:36 2015 From: fourzerofour at gmail.com (Justin) Date: Wed, 16 Sep 2015 11:32:36 -0400 Subject: Ashburn In-Reply-To: <55F97DE9.4050906@indigowireless.com> References: <55F97DE9.4050906@indigowireless.com> Message-ID: I know NTT is having issues. We received an RFO stating there was an issue and they were going to do software upgrades to fix. On Wed, Sep 16, 2015 at 10:34 AM, Matt Hoppes wrote: > What the world is going on in Ashburn? Over the last two days I've seen > multiple flaps from multiple carriers going through there. They generally > last about two to three minutes and then everything restores. > From morrowc.lists at gmail.com Wed Sep 16 15:34:26 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 16 Sep 2015 11:34:26 -0400 Subject: Ashburn In-Reply-To: <55F97DE9.4050906@indigowireless.com> References: <55F97DE9.4050906@indigowireless.com> Message-ID: removal of nsa taps On Wed, Sep 16, 2015 at 10:34 AM, Matt Hoppes wrote: > What the world is going on in Ashburn? Over the last two days I've seen > multiple flaps from multiple carriers going through there. They generally > last about two to three minutes and then everything restores. From mhoppes at indigowireless.com Wed Sep 16 15:36:21 2015 From: mhoppes at indigowireless.com (Matt Hoppes) Date: Wed, 16 Sep 2015 11:36:21 -0400 Subject: Ashburn In-Reply-To: References: <55F97DE9.4050906@indigowireless.com> Message-ID: <55F98C75.1030201@indigowireless.com> I heard that yesterday... I can't figure out why NTT having issues is affecting other carriers that peer in Ashburn though.... must be a routing table is blowing up somewhere there. On 9/16/15 11:32 AM, Justin wrote: > I know NTT is having issues. We received an RFO stating there was an > issue and they were going to do software upgrades to fix. > > On Wed, Sep 16, 2015 at 10:34 AM, Matt Hoppes > > wrote: > > What the world is going on in Ashburn? Over the last two days I've > seen multiple flaps from multiple carriers going through there. > They generally last about two to three minutes and then everything > restores. > > From keiths at neilltech.com Wed Sep 16 15:39:56 2015 From: keiths at neilltech.com (Keith Stokes) Date: Wed, 16 Sep 2015 15:39:56 +0000 Subject: Ashburn In-Reply-To: References: <55F97DE9.4050906@indigowireless.com>, Message-ID: Or router bugs. Or even inserting new NSA taps since some of the rest have been caught. --- Keith Stokes ________________________________________ From: NANOG on behalf of Christopher Morrow Sent: Wednesday, September 16, 2015 10:34 AM To: Matt Hoppes Cc: North American Network Operators' Group Subject: Re: Ashburn removal of nsa taps On Wed, Sep 16, 2015 at 10:34 AM, Matt Hoppes wrote: > What the world is going on in Ashburn? Over the last two days I've seen > multiple flaps from multiple carriers going through there. They generally > last about two to three minutes and then everything restores. From jared at puck.nether.net Wed Sep 16 15:43:03 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 16 Sep 2015 11:43:03 -0400 Subject: Ashburn In-Reply-To: <55F98C75.1030201@indigowireless.com> References: <55F97DE9.4050906@indigowireless.com> <55F98C75.1030201@indigowireless.com> Message-ID: If there are ongoing issues at NTT I?m not aware of them, please contact me off-list with details. Happy to follow-up. - Jared > On Sep 16, 2015, at 11:36 AM, Matt Hoppes wrote: > > I heard that yesterday... I can't figure out why NTT having issues is affecting other carriers that peer in Ashburn though.... must be a routing table is blowing up somewhere there. > > On 9/16/15 11:32 AM, Justin wrote: >> I know NTT is having issues. We received an RFO stating there was an >> issue and they were going to do software upgrades to fix. >> >> On Wed, Sep 16, 2015 at 10:34 AM, Matt Hoppes >> > wrote: >> >> What the world is going on in Ashburn? Over the last two days I've >> seen multiple flaps from multiple carriers going through there. >> They generally last about two to three minutes and then everything >> restores. >> >> From jared at puck.nether.net Wed Sep 16 15:44:40 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 16 Sep 2015 11:44:40 -0400 Subject: Ashburn In-Reply-To: References: <55F97DE9.4050906@indigowireless.com> Message-ID: <4F77D28B-834B-45F4-BEC5-FF97F4364BAC@puck.nether.net> *chuckle* I did hear rumors of a fiber cut yesterday in the area but no hard details. - Jared > On Sep 16, 2015, at 11:34 AM, Christopher Morrow wrote: > > removal of nsa taps > > On Wed, Sep 16, 2015 at 10:34 AM, Matt Hoppes > wrote: >> What the world is going on in Ashburn? Over the last two days I've seen >> multiple flaps from multiple carriers going through there. They generally >> last about two to three minutes and then everything restores. From jabley at hopcount.ca Thu Sep 17 04:33:14 2015 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 17 Sep 2015 00:33:14 -0400 Subject: root zone archive Message-ID: Hi all, Is anybody here aware of a complete or partial archive of root zone data that is older than the set available at DNS-OARC? OARC's archive has nothing older than July 2009. I'm particularly interested in zone data that describes the build out of the original root zone NS set to nine servers in mid-1994, the renaming under the ROOT-SERVERS.NET domain and the subsequent assignment of J, K, L and M. I realise this is a bit of a long shot, but the answer's always no if you don't ask :-) [I'm asking the same question on a small handful of lists; apologies if you get multiple copies of this.] Joe From sean at donelan.com Thu Sep 17 04:43:40 2015 From: sean at donelan.com (Sean Donelan) Date: Thu, 17 Sep 2015 00:43:40 -0400 (EDT) Subject: root zone archive In-Reply-To: References: Message-ID: On Thu, 17 Sep 2015, Joe Abley wrote: > Is anybody here aware of a complete or partial archive of root zone data that > is older than the set available at DNS-OARC? OARC's archive has nothing older > than July 2009. I covered most of the root changes up to 2002 on a DNS timeline. http://www.donelan.com/dnstimeline.html From nanogml at Mail.DDoS-Mitigator.net Thu Sep 17 05:27:12 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Wed, 16 Sep 2015 22:27:12 -0700 Subject: root zone archive In-Reply-To: References: Message-ID: <20150917052712.GA1848@Mail.DDoS-Mitigator.net> hi On 09/17/15 at 12:33am, Joe Abley wrote: ... > I'm particularly interested in zone data that describes the build out of the > original root zone NS set to nine servers in mid-1994, the renaming under > the ROOT-SERVERS.NET domain and the subsequent assignment of J, K, L and M. wouldn't that info be in the files included with bind-0.x have fun alvin From jabley at hopcount.ca Thu Sep 17 05:38:32 2015 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 17 Sep 2015 01:38:32 -0400 Subject: root zone archive In-Reply-To: <20150917052712.GA1848@Mail.DDoS-Mitigator.net> References: <20150917052712.GA1848@Mail.DDoS-Mitigator.net> Message-ID: <285B1B5B-254B-4A37-89B6-AAD1FF371B39@hopcount.ca> Hi Alvin, On 17 Sep 2015, at 1:27, alvin nanog wrote: > On 09/17/15 at 12:33am, Joe Abley wrote: > ... >> I'm particularly interested in zone data that describes the build out >> of the >> original root zone NS set to nine servers in mid-1994, the renaming >> under >> the ROOT-SERVERS.NET domain and the subsequent assignment of J, K, L >> and M. > > wouldn't that info be in the files included with bind-0.x I don't know, but worth a look. Good idea, thanks! Joe From marshall.eubanks at gmail.com Thu Sep 17 13:47:19 2015 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Thu, 17 Sep 2015 09:47:19 -0400 Subject: Chile Status? Message-ID: Given the huge (7.9 - 8.3) Earthquake last night, does anyone have any information about the status of the Internet in Chile, and in particular about the status of the undersea fiber links that go down off the West coast of South America to Chile? Given that this was an offshore Earthquake, and its magnitude, I would expect those fiber links to be at risk to undersea landslides. Regards Marshall Eubanks From colinj at gt86car.org.uk Thu Sep 17 13:55:40 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 17 Sep 2015 14:55:40 +0100 Subject: Chile Status? In-Reply-To: References: Message-ID: <634E4BE1-9311-4330-A5D2-F3DEA9B81CE0@gt86car.org.uk> anyone tried ripe atlas to see effect :) Colin > On 17 Sep 2015, at 14:47, Marshall Eubanks wrote: > > Given the huge (7.9 - 8.3) Earthquake last night, does anyone have any > information about the status of the Internet in Chile, and in particular > about the status of the undersea fiber links that go down off the West > coast of South America to Chile? > > Given that this was an offshore Earthquake, and its magnitude, I would > expect those fiber links to be at risk to undersea landslides. > > Regards > Marshall Eubanks From dorancemc at gmail.com Thu Sep 17 13:57:12 2015 From: dorancemc at gmail.com (Dorance Martinez Cortes) Date: Thu, 17 Sep 2015 08:57:12 -0500 Subject: Chile Status? In-Reply-To: References: Message-ID: Maybe on the NAP site for Chile, but I can't find enough information about network status. http://pit.nap.cl/red.html 2015-09-17 8:47 GMT-05:00 Marshall Eubanks : > Given the huge (7.9 - 8.3) Earthquake last night, does anyone have any > information about the status of the Internet in Chile, and in particular > about the status of the undersea fiber links that go down off the West > coast of South America to Chile? > > Given that this was an offshore Earthquake, and its magnitude, I would > expect those fiber links to be at risk to undersea landslides. > > Regards > Marshall Eubanks > -- Cordialmente, Doranc? Mart?nez Cort?s +57 320 6968121 Linux User Number 112632 Nagios Certified Administrator Certificaci?n ITIL Fundation 2011 ed. Cali - Colombia dorancemc at gmail.com http://dorancemc.com http://dmci.co "Si piensas que la tecnolog?a puede solucionar tus problemas de seguridad, est? claro que ni entiendes los problemas ni entiendes la tecnolog?a" Bruce Schneier From jared at puck.nether.net Thu Sep 17 13:58:54 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 17 Sep 2015 09:58:54 -0400 Subject: Chile Status? In-Reply-To: <634E4BE1-9311-4330-A5D2-F3DEA9B81CE0@gt86car.org.uk> References: <634E4BE1-9311-4330-A5D2-F3DEA9B81CE0@gt86car.org.uk> Message-ID: <14A4808F-7389-4D8A-9728-F128445ECC6E@puck.nether.net> > On Sep 17, 2015, at 9:55 AM, Colin Johnston wrote: > > anyone tried ripe atlas to see effect :) > If someone wants ripe ATLAS credits please send me a request off-list with your e-mail address registered for RIPE Atlas. - jared From pr at isprime.com Thu Sep 17 14:00:25 2015 From: pr at isprime.com (Phil Rosenthal) Date: Thu, 17 Sep 2015 10:00:25 -0400 Subject: Chile Status? In-Reply-To: References: Message-ID: Hello, Our internal monitoring tools show that there was a momentary drop in traffic (~30 minutes) coinciding with the earthquake, but traffic quickly returned to normal, and is at normal levels today. We are serving Chile from Miami. Best Regards, -Phil > On Sep 17, 2015, at 9:47 AM, Marshall Eubanks wrote: > > Given the huge (7.9 - 8.3) Earthquake last night, does anyone have any > information about the status of the Internet in Chile, and in particular > about the status of the undersea fiber links that go down off the West > coast of South America to Chile? > > Given that this was an offshore Earthquake, and its magnitude, I would > expect those fiber links to be at risk to undersea landslides. > > Regards > Marshall Eubanks From marshall.eubanks at gmail.com Thu Sep 17 14:00:46 2015 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Thu, 17 Sep 2015 10:00:46 -0400 Subject: Chile Status? In-Reply-To: <634E4BE1-9311-4330-A5D2-F3DEA9B81CE0@gt86car.org.uk> References: <634E4BE1-9311-4330-A5D2-F3DEA9B81CE0@gt86car.org.uk> Message-ID: On Thu, Sep 17, 2015 at 9:55 AM, Colin Johnston wrote: > anyone tried ripe atlas to see effect :) > > > The RIPE atlas https://atlas.ripe.net/results/maps/reachability/?id=1001&t=1442498340 shows green dots, but if you mouseover you see that the last connects are all old (pre-Earthquake). Regards Marshall > Colin > > On 17 Sep 2015, at 14:47, Marshall Eubanks > wrote: > > > > Given the huge (7.9 - 8.3) Earthquake last night, does anyone have any > > information about the status of the Internet in Chile, and in particular > > about the status of the undersea fiber links that go down off the West > > coast of South America to Chile? > > > > Given that this was an offshore Earthquake, and its magnitude, I would > > expect those fiber links to be at risk to undersea landslides. > > > > Regards > > Marshall Eubanks > > From marshall.eubanks at gmail.com Thu Sep 17 14:02:52 2015 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Thu, 17 Sep 2015 10:02:52 -0400 Subject: Chile Status? In-Reply-To: References: Message-ID: On Thu, Sep 17, 2015 at 10:00 AM, Phil Rosenthal wrote: > Hello, > > Our internal monitoring tools show that there was a momentary drop in > traffic (~30 minutes) coinciding with the earthquake, but traffic quickly > returned to normal, and is at normal levels today. > We are serving Chile from Miami. > > Excellent, thank you. I am sure there will be many local outages in affected areas, but that presumably means the country itself is still on the net. Regards Marshall > Best Regards, > -Phil > > > On Sep 17, 2015, at 9:47 AM, Marshall Eubanks < > marshall.eubanks at gmail.com> wrote: > > > > Given the huge (7.9 - 8.3) Earthquake last night, does anyone have any > > information about the status of the Internet in Chile, and in particular > > about the status of the undersea fiber links that go down off the West > > coast of South America to Chile? > > > > Given that this was an offshore Earthquake, and its magnitude, I would > > expect those fiber links to be at risk to undersea landslides. > > > > Regards > > Marshall Eubanks > > From bortzmeyer at nic.fr Thu Sep 17 14:14:24 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 17 Sep 2015 16:14:24 +0200 Subject: Chile Status? In-Reply-To: <14A4808F-7389-4D8A-9728-F128445ECC6E@puck.nether.net> References: <634E4BE1-9311-4330-A5D2-F3DEA9B81CE0@gt86car.org.uk> <14A4808F-7389-4D8A-9728-F128445ECC6E@puck.nether.net> Message-ID: <20150917141423.GA21301@nic.fr> On Thu, Sep 17, 2015 at 09:58:54AM -0400, Jared Mauch wrote a message of 11 lines which said: > If someone wants ripe ATLAS credits please send me a request > off-list with your e-mail address registered for RIPE Atlas. Even without credits, and an anonymous access, you can see that several probes are reachable in Chile: https://atlas.ripe.net/results/maps/network-coverage/ True, some are yellow (disconnected) but click on the yellow dot and check the date: they were down even before the earthquake. So, first conclusion: there is apparently no widespread Internet outage. From emile.aben at ripe.net Thu Sep 17 14:19:37 2015 From: emile.aben at ripe.net (Emile Aben) Date: Thu, 17 Sep 2015 16:19:37 +0200 Subject: Chile Status? In-Reply-To: <14A4808F-7389-4D8A-9728-F128445ECC6E@puck.nether.net> References: <634E4BE1-9311-4330-A5D2-F3DEA9B81CE0@gt86car.org.uk> <14A4808F-7389-4D8A-9728-F128445ECC6E@puck.nether.net> Message-ID: <55FACBF9.7090909@ripe.net> On 17/09/15 15:58, Jared Mauch wrote: > >> On Sep 17, 2015, at 9:55 AM, Colin Johnston wrote: >> >> anyone tried ripe atlas to see effect :) I've not looked at RIPE Atlas data, but we do have a near-realtime monitor on BGP data in RIPEstat, where we map resources to a country: https://stat.ripe.net/CL That didn't show anything, so if folks got affected they seem not to have massive drops in number of prefixes visible, and no ASes that completely got disconnected. cheers, Emile From bortzmeyer at nic.fr Thu Sep 17 14:27:59 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 17 Sep 2015 16:27:59 +0200 Subject: Chile Status? In-Reply-To: References: <634E4BE1-9311-4330-A5D2-F3DEA9B81CE0@gt86car.org.uk> Message-ID: <20150917142759.GA22533@nic.fr> On Thu, Sep 17, 2015 at 10:00:46AM -0400, Marshall Eubanks wrote a message of 34 lines which said: > shows green dots, but if you mouseover you see that the last > connects are all old (pre-Earthquake). You're right, I forgot to check that but the 17 RIPE Atlas probes connected in Chile all answer and can ping NANOG Web site: % python reachability+retrieve.py -v -r 500 --country CL 50.31.151.73 {'definitions': [{'description': 'Ping 50.31.151.73 from CL', 'af': 4, 'packets': 3, 'type': 'ping', 'is_oneoff': True, 'target': '50.31.151.73'}], 'probes': [{'requested': 500, 'type': 'country', 'value': 'CL'}]} Measurement #2427363 to 50.31.151.73 uses 17 probes 17 probes reported Test done at 2015-09-17T14:27:10Z Tests: 51 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 182 ms https://atlas.ripe.net/measurements/2427363/ From hsalgado at nic.cl Thu Sep 17 14:30:21 2015 From: hsalgado at nic.cl (Hugo =?iso-8859-1?Q?Salgado-Hern=E1ndez?=) Date: Thu, 17 Sep 2015 11:30:21 -0300 Subject: [nanog] Re: Chile Status? In-Reply-To: <55FACBF9.7090909@ripe.net> References: <634E4BE1-9311-4330-A5D2-F3DEA9B81CE0@gt86car.org.uk> <14A4808F-7389-4D8A-9728-F128445ECC6E@puck.nether.net> <55FACBF9.7090909@ripe.net> Message-ID: <20150917143021.GA6659@pepino.intra.nic.cl> On 16:19 17/09, Emile Aben wrote: > On 17/09/15 15:58, Jared Mauch wrote: > > > >> On Sep 17, 2015, at 9:55 AM, Colin Johnston wrote: > >> > >> anyone tried ripe atlas to see effect :) > > I've not looked at RIPE Atlas data, but we do have a near-realtime > monitor on BGP data in RIPEstat, where we map resources to a country: > > https://stat.ripe.net/CL > > That didn't show anything, so if folks got affected they seem not to > have massive drops in number of prefixes visible, and no ASes that > completely got disconnected. > That's right. We didn't have any noticeable outage in Santiago, either local or international, and monitors for .CL gave no interruption for major cities. Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mhardeman at ipifony.com Wed Sep 16 17:53:56 2015 From: mhardeman at ipifony.com (Matthew D. Hardeman) Date: Wed, 16 Sep 2015 12:53:56 -0500 (CDT) Subject: Ashburn In-Reply-To: Message-ID: <1612216378.3730.1442426036478.JavaMail.root@ipifony.com> On that topic... Has anyone noticed at 56 Marietta (in the main entrance lobby which is currently being remodeled), ground floor by the elevators is an ominous "Meet-Me Room #3" behind a closed door? A door that has an L-3 Communications biometric access reader. Which is different from all the other HID readers facility wide. One day I noticed the hum of heavy equipment through that door. Most suspect for a "meet-me room" where most of the time it's just passive fiber-optic patches. It's also suspect to have a Meet-Me room on a floor that has no customers, but, whatever... Makes you wonder. ----- Original Message ----- From: "Keith Stokes" To: "Christopher Morrow" , "Matt Hoppes" Cc: "North American Network Operators' Group" Sent: Wednesday, September 16, 2015 10:39:56 AM Subject: Re: Ashburn Or router bugs. Or even inserting new NSA taps since some of the rest have been caught. --- Keith Stokes ________________________________________ From: NANOG on behalf of Christopher Morrow Sent: Wednesday, September 16, 2015 10:34 AM To: Matt Hoppes Cc: North American Network Operators' Group Subject: Re: Ashburn removal of nsa taps On Wed, Sep 16, 2015 at 10:34 AM, Matt Hoppes wrote: > What the world is going on in Ashburn? Over the last two days I've seen > multiple flaps from multiple carriers going through there. They generally > last about two to three minutes and then everything restores. From Anthony.DeLaCruz at CenturyLink.com Thu Sep 17 11:38:03 2015 From: Anthony.DeLaCruz at CenturyLink.com (Delacruz, Anthony B) Date: Thu, 17 Sep 2015 11:38:03 +0000 Subject: Looking for Time Warner contact AS10796 Message-ID: <398B250423578A4E97AFE1B8B67C686C4C10DD1B@PDDCWMBXEX503.ctl.intranet> Could someone with Time Warner contact me off list I am getting nowhere with listed ARIN contact emails or cold calls into NOC on several hijacked ranges AS10796 is announcing of ours. Thanks. This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From william.allen.simpson at gmail.com Thu Sep 17 15:29:14 2015 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 17 Sep 2015 11:29:14 -0400 Subject: Sign-On Letter to the Court in the FCC's Net Neutrality Case In-Reply-To: References: <20150912194545.65752.qmail@ary.lan> <55F90147.3020703@nic-naa.net> Message-ID: <55FADC4A.7010607@gmail.com> On 9/16/15 11:12 AM, Peter Beckman wrote: > Why don't you post a copy here or a link? > https://www.eff.org/files/2015/09/14/eff-aclu_internet_engineers_and_pioneers_statement.pdf I've agreed. From manager at monmouth.com Thu Sep 17 15:31:44 2015 From: manager at monmouth.com (Mark Stevens) Date: Thu, 17 Sep 2015 11:31:44 -0400 Subject: Verizon Wireless Message-ID: <55FADCE0.5090607@monmouth.com> Hi there, If any Verizon wireless network engineers are on nanog, could you please email me offline concerning network traffic delays? Thanks Mark From mfidelman at meetinghouse.net Thu Sep 17 15:41:52 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 17 Sep 2015 11:41:52 -0400 Subject: Sign-On Letter to the Court in the FCC's Net Neutrality Case In-Reply-To: <55FADC4A.7010607@gmail.com> References: <20150912194545.65752.qmail@ary.lan> <55F90147.3020703@nic-naa.net> <55FADC4A.7010607@gmail.com> Message-ID: <55FADF40.4040705@meetinghouse.net> William Allen Simpson wrote: > On 9/16/15 11:12 AM, Peter Beckman wrote: >> Why don't you post a copy here or a link? >> > https://www.eff.org/files/2015/09/14/eff-aclu_internet_engineers_and_pioneers_statement.pdf > > > I've agreed. Me too. Be sure to actually read the Amicus brief - it's incredibly well written and informative. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From lists at silverlakeinternet.com Thu Sep 17 15:46:47 2015 From: lists at silverlakeinternet.com (Brett A Mansfield) Date: Thu, 17 Sep 2015 09:46:47 -0600 Subject: VUDU thinks my network is out of the country Message-ID: I need a good contact at VUDU. I have several customers that use it that cannot. They gave us a workaround where each and every individual customer needs to call in and get their IP unblocked, but they aren't unblocking them anymore. Thank you, Brett A Mansfield From nanog at ics-il.net Thu Sep 17 15:56:19 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 17 Sep 2015 10:56:19 -0500 (CDT) Subject: VUDU thinks my network is out of the country In-Reply-To: Message-ID: <1794041575.117983.1442505435858.JavaMail.mhammett@ThunderFuck> The NANOG CluePon site used to have a geo-IP how-to, but it hasn't been active in months. :-( ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Brett A Mansfield" To: nanog at nanog.org Sent: Thursday, September 17, 2015 10:46:47 AM Subject: VUDU thinks my network is out of the country I need a good contact at VUDU. I have several customers that use it that cannot. They gave us a workaround where each and every individual customer needs to call in and get their IP unblocked, but they aren't unblocking them anymore. Thank you, Brett A Mansfield From chris at aperturefiber.com Thu Sep 17 16:32:39 2015 From: chris at aperturefiber.com (Chris Garrett) Date: Thu, 17 Sep 2015 12:32:39 -0400 Subject: Microsoft blocking mail Message-ID: Is there anyone on-list who can assist with an erroneous spam block to Outlook.com ? One our our net blocks was added earlier today, 216.128.11.0/25 and I am having zero luck getting through to a clueful person at MS. Thank you! Chris Garrett | Network Operations Director tel: 678.370.2012 | mobile: 512.605.9620 From michael.holstein at csuohio.edu Thu Sep 17 16:42:31 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Thu, 17 Sep 2015 16:42:31 +0000 Subject: Microsoft blocking mail In-Reply-To: References: Message-ID: You can get ahold of the Outlook/Live/Hotmail Postmaster folks via this form : http://go.microsoft.com/fwlink/?LinkID=614866 IME they are pretty responsive .. usually > 6hrs. Regards, Michael Holstein Cleveland State University ________________________________________ From: NANOG on behalf of Chris Garrett Sent: Thursday, September 17, 2015 12:32 PM To: NANOG Subject: Microsoft blocking mail Is there anyone on-list who can assist with an erroneous spam block to Outlook.com ? One our our net blocks was added earlier today, 216.128.11.0/25 and I am having zero luck getting through to a clueful person at MS. Thank you! Chris Garrett | Network Operations Director tel: 678.370.2012 | mobile: 512.605.9620 From josh at imaginenetworksllc.com Thu Sep 17 16:44:58 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 17 Sep 2015 12:44:58 -0400 Subject: Microsoft blocking mail In-Reply-To: References: Message-ID: Link doesn't work as one would expect. Do you mean under 6 hours or over? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Sep 17, 2015 at 12:42 PM, Michael O Holstein < michael.holstein at csuohio.edu> wrote: > You can get ahold of the Outlook/Live/Hotmail Postmaster folks via this > form : http://go.microsoft.com/fwlink/?LinkID=614866 > > IME they are pretty responsive .. usually > 6hrs. > > Regards, > > Michael Holstein > Cleveland State University > > ________________________________________ > From: NANOG on behalf of Chris Garrett < > chris at aperturefiber.com> > Sent: Thursday, September 17, 2015 12:32 PM > To: NANOG > Subject: Microsoft blocking mail > > Is there anyone on-list who can assist with an erroneous spam block to > Outlook.com ? > > One our our net blocks was added earlier today, 216.128.11.0/25 and I am > having zero luck getting through to a clueful person at MS. > > Thank you! > > Chris Garrett | Network Operations Director > tel: 678.370.2012 | mobile: 512.605.9620 > > From hugo at slabnet.com Thu Sep 17 16:45:24 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 17 Sep 2015 09:45:24 -0700 Subject: Microsoft blocking mail In-Reply-To: References: Message-ID: <20150917164524.GE22440@bamboo.slabnet.com> This is the front door for outlook.com delivery issues: http://mail.live.com/mail/postmaster.aspx More specifically http://mail.live.com/mail/troubleshooting.aspx and starting a ticket at http://go.microsoft.com/fwlink/?LinkID=614866. If it's something related to protection.outlook.com, NDRs would probably have directed you to contact delist at messaging.microsoft.com. The word from on high at MS legal has been that this is the only avenue in for delivery issues. Trying to backdoor this somehow through insiders will result in much spinning of wheels. -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From hugo at slabnet.com Thu Sep 17 17:12:00 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 17 Sep 2015 10:12:00 -0700 Subject: Microsoft blocking mail In-Reply-To: References: Message-ID: <20150917171200.GF22440@bamboo.slabnet.com> On Thu 2015-Sep-17 12:44:58 -0400, Josh Luthman wrote: >Link doesn't work as one would expect. ...what is the expected behaviour, and how is it different from actual behaviour? -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From josh at imaginenetworksllc.com Thu Sep 17 17:14:21 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 17 Sep 2015 13:14:21 -0400 Subject: Microsoft blocking mail In-Reply-To: <20150917171200.GF22440@bamboo.slabnet.com> References: <20150917171200.GF22440@bamboo.slabnet.com> Message-ID: Well it's not a form and it redirects you to the support home page... https://support.microsoft.com/en-us Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Sep 17, 2015 at 1:12 PM, Hugo Slabbert wrote: > > On Thu 2015-Sep-17 12:44:58 -0400, Josh Luthman < > josh at imaginenetworksllc.com> wrote: > > Link doesn't work as one would expect. >> > > ...what is the expected behaviour, and how is it different from actual > behaviour? > > -- > Hugo > From chris at aperturefiber.com Thu Sep 17 17:16:17 2015 From: chris at aperturefiber.com (Chris Garrett) Date: Thu, 17 Sep 2015 13:16:17 -0400 Subject: Microsoft blocking mail In-Reply-To: References: Message-ID: Thank you! Chris Garrett | Network Operations Director Birch Communications Sent from my mobile, please excuse my brevity. > On Sep 17, 2015, at 12:42 PM, Michael O Holstein wrote: > > You can get ahold of the Outlook/Live/Hotmail Postmaster folks via this form : http://go.microsoft.com/fwlink/?LinkID=614866 > > IME they are pretty responsive .. usually > 6hrs. > > Regards, > > Michael Holstein > Cleveland State University > > ________________________________________ > From: NANOG on behalf of Chris Garrett > Sent: Thursday, September 17, 2015 12:32 PM > To: NANOG > Subject: Microsoft blocking mail > > Is there anyone on-list who can assist with an erroneous spam block to Outlook.com ? > > One our our net blocks was added earlier today, 216.128.11.0/25 and I am having zero luck getting through to a clueful person at MS. > > Thank you! > > Chris Garrett | Network Operations Director > tel: 678.370.2012 | mobile: 512.605.9620 > From chris at aperturefiber.com Thu Sep 17 17:17:54 2015 From: chris at aperturefiber.com (Chris Garrett) Date: Thu, 17 Sep 2015 13:17:54 -0400 Subject: Microsoft blocking mail In-Reply-To: <20150917164524.GE22440@bamboo.slabnet.com> References: <20150917164524.GE22440@bamboo.slabnet.com> Message-ID: I will work through this avenue. Thank you very much for your responses. Chris Garrett | Network Operations Director Birch Communications Sent from my mobile, please excuse my brevity. > On Sep 17, 2015, at 12:45 PM, Hugo Slabbert wrote: > > This is the front door for outlook.com delivery issues: > > http://mail.live.com/mail/postmaster.aspx > > More specifically http://mail.live.com/mail/troubleshooting.aspx and starting a ticket at http://go.microsoft.com/fwlink/?LinkID=614866. > > If it's something related to protection.outlook.com, NDRs would probably have directed you to contact delist at messaging.microsoft.com. > > The word from on high at MS legal has been that this is the only avenue in for delivery issues. Trying to backdoor this somehow through insiders will result in much spinning of wheels. > > -- > Hugo From Valdis.Kletnieks at vt.edu Thu Sep 17 17:22:29 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 17 Sep 2015 13:22:29 -0400 Subject: Microsoft blocking mail In-Reply-To: References: <20150917171200.GF22440@bamboo.slabnet.com> Message-ID: <14278.1442510549@turing-police.cc.vt.edu> On Thu, 17 Sep 2015 13:14:21 -0400, Josh Luthman said: > Well it's not a form and it redirects you to the support home page... > > https://support.microsoft.com/en-us You didn't have NoScript or similar in effect at the time, did you? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From josh at imaginenetworksllc.com Thu Sep 17 17:27:09 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 17 Sep 2015 13:27:09 -0400 Subject: Microsoft blocking mail In-Reply-To: <14278.1442510549@turing-police.cc.vt.edu> References: <20150917171200.GF22440@bamboo.slabnet.com> <14278.1442510549@turing-police.cc.vt.edu> Message-ID: AdBlock with Chrome 45. Redirects me as of the moment. I assume it's working for others then? I don't need it myself, so if it's working never mind =) Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Sep 17, 2015 at 1:22 PM, wrote: > On Thu, 17 Sep 2015 13:14:21 -0400, Josh Luthman said: > > Well it's not a form and it redirects you to the support home page... > > > > https://support.microsoft.com/en-us > > You didn't have NoScript or similar in effect at the time, did you? > > From hugo at slabnet.com Thu Sep 17 17:27:45 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 17 Sep 2015 10:27:45 -0700 Subject: Microsoft blocking mail In-Reply-To: <14278.1442510549@turing-police.cc.vt.edu> References: <20150917171200.GF22440@bamboo.slabnet.com> <14278.1442510549@turing-police.cc.vt.edu> Message-ID: <20150917172745.GG22440@bamboo.slabnet.com> On Thu 2015-Sep-17 13:22:29 -0400, Valdis.Kletnieks at vt.edu wrote: >On Thu, 17 Sep 2015 13:14:21 -0400, Josh Luthman said: >> Well it's not a form and it redirects you to the support home page... >> >> https://support.microsoft.com/en-us > >You didn't have NoScript or similar in effect at the time, did you? > Was going to ask the same; #worksforme, though there is a string of redirects and noscript is filling pretty much the full height of my display with a list of hosts... $ wget http://go.microsoft.com/fwlink/?LinkID=614866 --2015-09-17 10:18:10-- http://go.microsoft.com/fwlink/?LinkID=614866 Resolving go.microsoft.com (go.microsoft.com)... 2001:4de0:4103:197::2c1a, 2001:4de0:4103:182::2c1a, 23.58.87.71 Connecting to go.microsoft.com (go.microsoft.com)|2001:4de0:4103:197::2c1a|:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://support.microsoft.com/getsupport/?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us&ln=en-us [following] --2015-09-17 10:18:10-- https://support.microsoft.com/getsupport/?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us&ln=en-us Resolving support.microsoft.com (support.microsoft.com)... 184.24.236.218 Connecting to support.microsoft.com (support.microsoft.com)|184.24.236.218|:443... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://support.microsoft.com/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us&ln=en-us [following] --2015-09-17 10:18:10-- https://support.microsoft.com/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us&ln=en-us Reusing existing connection to support.microsoft.com:443. HTTP request sent, awaiting response... 302 Moved Temporarily Location: /en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us [following] --2015-09-17 10:18:10-- https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us Reusing existing connection to support.microsoft.com:443. HTTP request sent, awaiting response... 200 OK Length: 156614 (153K) [text/html] Saving to: 'index.html?LinkID=614866' index.html?LinkID=614866 100%[======================================================>] 152.94K --.-KB/s in 0.1s 2015-09-17 10:18:11 (1.38 MB/s) - 'index.html?LinkID=614866' saved [156614/156614] -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jarriaga at reuna.cl Thu Sep 17 16:33:04 2015 From: jarriaga at reuna.cl (Juan Jose Arriagada) Date: Thu, 17 Sep 2015 13:33:04 -0300 Subject: Chile Status? In-Reply-To: References: Message-ID: <55FAEB40.5080206@reuna.cl> Hi, The academic network was fully operational during and after the strong earthquake, including to the observatories (ESO, ALMA, AURA, LSST, CTIO, SLOOH). Regards, El 17-09-2015 a las 10:47, Marshall Eubanks escribi?: > Given the huge (7.9 - 8.3) Earthquake last night, does anyone have any > information about the status of the Internet in Chile, and in particular > about the status of the undersea fiber links that go down off the West > coast of South America to Chile? > > Given that this was an offshore Earthquake, and its magnitude, I would > expect those fiber links to be at risk to undersea landslides. > > Regards > Marshall Eubanks > > > -- From nanog at ics-il.net Thu Sep 17 17:34:13 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 17 Sep 2015 12:34:13 -0500 (CDT) Subject: Microsoft blocking mail In-Reply-To: Message-ID: <1054208417.118344.1442511302321.JavaMail.mhammett@ThunderFuck> OT: I wish more ad-blockers had an off-by-default option with blacklists instead of on-by-default with whitelists. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Josh Luthman" To: "Valdis Kletnieks" Cc: "NANOG" Sent: Thursday, September 17, 2015 12:27:09 PM Subject: Re: Microsoft blocking mail AdBlock with Chrome 45. Redirects me as of the moment. I assume it's working for others then? I don't need it myself, so if it's working never mind =) Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Sep 17, 2015 at 1:22 PM, wrote: > On Thu, 17 Sep 2015 13:14:21 -0400, Josh Luthman said: > > Well it's not a form and it redirects you to the support home page... > > > > https://support.microsoft.com/en-us > > You didn't have NoScript or similar in effect at the time, did you? > > From shortdudey123 at gmail.com Thu Sep 17 17:37:14 2015 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 17 Sep 2015 10:37:14 -0700 Subject: Microsoft blocking mail In-Reply-To: <20150917172745.GG22440@bamboo.slabnet.com> References: <20150917171200.GF22440@bamboo.slabnet.com> <14278.1442510549@turing-police.cc.vt.edu> <20150917172745.GG22440@bamboo.slabnet.com> Message-ID: http://go.microsoft.com/fwlink/?LinkID=614866 displays a form for me (Chrome w/ no ad extensions or custom settings) Try it in incognito mode On Thu, Sep 17, 2015 at 10:27 AM, Hugo Slabbert wrote: > > On Thu 2015-Sep-17 13:22:29 -0400, Valdis.Kletnieks at vt.edu < > Valdis.Kletnieks at vt.edu> wrote: > > On Thu, 17 Sep 2015 13:14:21 -0400, Josh Luthman said: >> >>> Well it's not a form and it redirects you to the support home page... >>> >>> https://support.microsoft.com/en-us >>> >> >> You didn't have NoScript or similar in effect at the time, did you? >> >> > Was going to ask the same; #worksforme, though there is a string of > redirects and noscript is filling pretty much the full height of my display > with a list of hosts... > > $ wget http://go.microsoft.com/fwlink/?LinkID=614866 > --2015-09-17 10:18:10-- http://go.microsoft.com/fwlink/?LinkID=614866 > Resolving go.microsoft.com (go.microsoft.com)... > 2001:4de0:4103:197::2c1a, 2001:4de0:4103:182::2c1a, 23.58.87.71 > Connecting to go.microsoft.com (go.microsoft.com)|2001:4de0:4103:197::2c1a|:80... > connected. > HTTP request sent, awaiting response... 302 Moved Temporarily > Location: > https://support.microsoft.com/getsupport/?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us&ln=en-us > [following] > --2015-09-17 10:18:10-- > https://support.microsoft.com/getsupport/?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us&ln=en-us > Resolving support.microsoft.com (support.microsoft.com)... 184.24.236.218 > Connecting to support.microsoft.com (support.microsoft.com)|184.24.236.218|:443... > connected. > HTTP request sent, awaiting response... 301 Moved Permanently > Location: > https://support.microsoft.com/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us&ln=en-us > [following] > --2015-09-17 10:18:10-- > https://support.microsoft.com/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us&ln=en-us > Reusing existing connection to support.microsoft.com:443. > HTTP request sent, awaiting response... 302 Moved Temporarily > Location: > /en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us > [following] > --2015-09-17 10:18:10-- > https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us > Reusing existing connection to support.microsoft.com:443. > HTTP request sent, awaiting response... 200 OK > Length: 156614 (153K) [text/html] > Saving to: 'index.html?LinkID=614866' > > index.html?LinkID=614866 > 100%[======================================================>] 152.94K > --.-KB/s in 0.1s > > 2015-09-17 10:18:11 (1.38 MB/s) - 'index.html?LinkID=614866' saved > [156614/156614] > > -- > Hugo > From sean at donelan.com Thu Sep 17 17:40:52 2015 From: sean at donelan.com (Sean Donelan) Date: Thu, 17 Sep 2015 13:40:52 -0400 (EDT) Subject: Submarine cable outage reporting requirements to FCC changed Message-ID: The FCC voted to propose new rules requiring submarine cable licensees to report outages to the FCC. While submarine cable outages have always been very noticable, and operators on this list and other forums quickly knew about any outage, they weren't required to be reported to the FCC in the past. Traditional wireline, wireless and satellite (US domestic? only) outages already need to be reported to the FCC. This affects about 60 submarine cable licensees in the US. https://www.fcc.gov/document/fcc-proposes-rules-promote-reliable-submarine-cable-communications From egon at egon.cc Thu Sep 17 17:43:51 2015 From: egon at egon.cc (James Downs) Date: Thu, 17 Sep 2015 10:43:51 -0700 Subject: VUDU thinks my network is out of the country In-Reply-To: References: Message-ID: <305011E6-52BA-460B-AFD9-1A7B36BD9BCB@egon.cc> > On Sep 17, 2015, at 08:46, Brett A Mansfield wrote: > > I need a good contact at VUDU. I have several customers that use it that cannot. They gave us a workaround where each and every individual customer needs to call in and get their IP unblocked, but they aren't unblocking them anymore. Who were you talking to previously? Cheers, -j From andy at newslink.com Thu Sep 17 18:20:51 2015 From: andy at newslink.com (Andy Ringsmuth) Date: Thu, 17 Sep 2015 13:20:51 -0500 Subject: Barracuda largely down Message-ID: I?m a Barracuda customer, and they?ve been essentially down all morning and into this afternoon. Here?s their explanation and a followup, neither of which are accurate. I say that because: 1. The problem manifests itself by mail being blocked under the guise of ?Cloudscan Service Unavailable.? 2. My company?s account has never, ever used Cloudscan. It has always been disabled at Barracuda. 3. Their own instructions, posted below, say that to bypass the problems you can disable Cloudscan. 4. They also state that as of 12:44 p.m. CDT, they?ve un-done whatever caused the problem. 5. As of 1:18 p.m. CDT, virtually all mail is still being blocked. Here?s what they say. Anyone here know anyone at Barracuda with a clue? The Email Security Service at ess.barracuda.com is currently experiencing a degraded service in it's cloud scan functionality. From 9/17/2015 06:00 am Please note however that your mail is not being blocked. It is being deferred because we were unable to scan the mail. This means that the sending servers will retry the mail until delivered. You can however bypass the cloud scan service from your Email Security Service admin page by clicking on "Inbound settings / Anti-spam AntiVirus" and then set "Enable Cloudscan" to NO. We will update in here when the CloudScan service is back working correctly. Thank you for your patience The times specified in this topic are in Pacific (US) Time. --- Eastern (US): Thu Sep 17 2015 12:00:00 to Thu Sep 17 2015 18:30:00 --- London: Thu Sep 17 2015 13:00:00 to Thu Sep 17 2015 19:30:00 --- Austria: Thu Sep 17 2015 14:00:00 to Thu Sep 17 2015 20:30:00 --- India: Thu Sep 17 2015 18:30:00 to Fri Sep 18 2015 01:00:00 --- China (Shanghai): Thu Sep 17 2015 21:00:00 to Fri Sep 18 2015 03:30:00 --- Japan: Thu Sep 17 2015 22:00:00 to Fri Sep 18 2015 04:30:00 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Posted Today, 01:44 PM Barracdua networks has rolled back the change that resulted in mail being deferred for "cloudscan service unavailable" If you did turn off the cloudscan service it can be turned back on at this time. Note that if you turned off the cloudscan service then mail was still filtered for viruses, BRTS, INTENT, etc.. Thank you ---- Andy Ringsmuth andy at newslink.com News Link ? Manager Travel, Technology & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular ---- Andy Ringsmuth andy at newslink.com News Link ? Manager Travel, Technology & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From edugas at unknowndevice.ca Thu Sep 17 19:41:54 2015 From: edugas at unknowndevice.ca (Eric Dugas) Date: Thu, 17 Sep 2015 15:41:54 -0400 Subject: 1G/10G EVPL between Toronto and Vancouver Message-ID: Hello, I'm searching for carriers with POPs at 151 Front St. W. and 1050 West Pender/555 Hastings in Vancouver, BC. Searching for a 1G EVPL and 10G EVPL. I asked all the national telcos and they're really expensive so I'm searching for alternatives. I'm already in touch with GTT by the way. Thanks Eric From COLIN at COLINBAKER.ORG Thu Sep 17 19:51:06 2015 From: COLIN at COLINBAKER.ORG (Colin Baker) Date: Thu, 17 Sep 2015 14:51:06 -0500 Subject: 1G/10G EVPL between Toronto and Vancouver In-Reply-To: References: Message-ID: On 2015-09-17 14:41, Eric Dugas wrote: > Hello, > > I'm searching for carriers with POPs at 151 Front St. W. and 1050 West > Pender/555 Hastings in Vancouver, BC. Searching for a 1G EVPL and 10G > EVPL. > > I asked all the national telcos and they're really expensive so I'm > searching for alternatives. I'm already in touch with GTT by the way. > Don't have any ideas off the top of my head, but the "Common Points" search on peeringdb is pretty handy for finding options like this. From colin.bodor at imperium.ca Thu Sep 17 20:19:51 2015 From: colin.bodor at imperium.ca (Colin Bodor) Date: Thu, 17 Sep 2015 20:19:51 +0000 Subject: 1G/10G EVPL between Toronto and Vancouver In-Reply-To: References: Message-ID: HE.net can do that I believe, they have points cross Canada from your two locations east/west. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Baker Sent: Thursday, September 17, 2015 1:51 PM To: Eric Dugas Cc: nanog at nanog.org Subject: Re: 1G/10G EVPL between Toronto and Vancouver On 2015-09-17 14:41, Eric Dugas wrote: > Hello, > > I'm searching for carriers with POPs at 151 Front St. W. and 1050 West > Pender/555 Hastings in Vancouver, BC. Searching for a 1G EVPL and 10G > EVPL. > > I asked all the national telcos and they're really expensive so I'm > searching for alternatives. I'm already in touch with GTT by the way. > Don't have any ideas off the top of my head, but the "Common Points" search on peeringdb is pretty handy for finding options like this. From ggiesen+nanog at giesen.me Thu Sep 17 20:49:53 2015 From: ggiesen+nanog at giesen.me (Gary T. Giesen) Date: Thu, 17 Sep 2015 16:49:53 -0400 Subject: Transit Options in the UK? Message-ID: <041401d0f18a$67df4250$379dc6f0$@giesen.me> I have a customer who's trying to decide whether to renew their existing transit contract or not for a POP they have in the UK and wondering what's good for transit options out there. Looking for: - Good peering/reachability to other networks (I've already started perusing the LINX peer list) - Decent BGP community set (at a minimum RTBH and local pref, obviously the richer the better) - v6 support - Own the last mile a bonus Can anyone offer any recommendations? Cheers, GTG From chris at nifry.com Thu Sep 17 21:30:14 2015 From: chris at nifry.com (Chris Russell) Date: Thu, 17 Sep 2015 22:30:14 +0100 Subject: Transit Options in the =?UTF-8?Q?UK=3F?= In-Reply-To: <041401d0f18a$67df4250$379dc6f0$@giesen.me> References: <041401d0f18a$67df4250$379dc6f0$@giesen.me> Message-ID: <677a1a03d3a6cd1295a9942267bc2718@nifry.com> On 17/09/2015 21:49, Gary T. Giesen wrote: > > Can anyone offer any recommendations? you may wish to also post to the UKNOF (UK Network Operators Forum) list Thanks Chris From damien at supremebytes.com Thu Sep 17 22:14:00 2015 From: damien at supremebytes.com (Damien Burke) Date: Thu, 17 Sep 2015 22:14:00 +0000 Subject: Microsoft blocking mail In-Reply-To: References: Message-ID: <2FD50E6D13594B4C93B743BFCF9F52842FE2E5C9@EXCH01.sb.local> On an unrelated note - Microsoft is also currently blocking IP addresses used by MXLOGIC / MCAFEE SAAS / Intel Security -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Garrett Sent: Thursday, September 17, 2015 9:33 AM To: NANOG Subject: Microsoft blocking mail Is there anyone on-list who can assist with an erroneous spam block to Outlook.com ? One our our net blocks was added earlier today, 216.128.11.0/25 and I am having zero luck getting through to a clueful person at MS. Thank you! Chris Garrett | Network Operations Director tel: 678.370.2012 | mobile: 512.605.9620 From kmedcalf at dessus.com Fri Sep 18 02:48:07 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 17 Sep 2015 20:48:07 -0600 Subject: Microsoft blocking mail In-Reply-To: <14278.1442510549@turing-police.cc.vt.edu> Message-ID: > On Thursday, 17 September, 2015 11:22, Valdis.Kletnieks at vt.edu said: > On Thu, 17 Sep 2015 13:14:21 -0400, Josh Luthman said: > > Well it's not a form and it redirects you to the support home page... > > https://support.microsoft.com/en-us > You didn't have NoScript or similar in effect at the time, did you? You mean to say that you have to enable blanket remote code execution authority in order to submit a problem report to Microsoft? What a crock of crap. Thus I will never recommend to anyone that they use Microsoft products for anything whatsoever, especially not anything in the "Microsoft Cloud" virus distribution system. Being blocked is probably a good thing ... From lists at silverlakeinternet.com Fri Sep 18 06:49:03 2015 From: lists at silverlakeinternet.com (Brett A Mansfield) Date: Fri, 18 Sep 2015 00:49:03 -0600 Subject: VUDU thinks my network is out of the country In-Reply-To: <305011E6-52BA-460B-AFD9-1A7B36BD9BCB@egon.cc> References: <305011E6-52BA-460B-AFD9-1A7B36BD9BCB@egon.cc> Message-ID: <692B1A6B-26E0-43F7-8F44-694F9FDA5980@silverlakeinternet.com> Just their regular support team you can call into. Thank you, Brett A Mansfield > On Sep 17, 2015, at 11:43 AM, James Downs wrote: > > >> On Sep 17, 2015, at 08:46, Brett A Mansfield wrote: >> >> I need a good contact at VUDU. I have several customers that use it that cannot. They gave us a workaround where each and every individual customer needs to call in and get their IP unblocked, but they aren't unblocking them anymore. > > Who were you talking to previously? > > Cheers, > -j From jwbensley at gmail.com Fri Sep 18 08:29:17 2015 From: jwbensley at gmail.com (James Bensley) Date: Fri, 18 Sep 2015 09:29:17 +0100 Subject: Transit Options in the UK? In-Reply-To: <041401d0f18a$67df4250$379dc6f0$@giesen.me> References: <041401d0f18a$67df4250$379dc6f0$@giesen.me> Message-ID: On 17 September 2015 at 21:49, Gary T. Giesen wrote: > I have a customer who's trying to decide whether to renew their existing > transit contract or not for a POP they have in the UK and wondering what's > good for transit options out there. > > Looking for: > > - Good peering/reachability to other networks (I've already started perusing > the LINX peer list) > - Decent BGP community set (at a minimum RTBH and local pref, obviously the > richer the better) > - v6 support > - Own the last mile a bonus > > Can anyone offer any recommendations? > > Cheers, > > GTG Hi Gary, Are you after full transit or UK/Europe only? For full transit all the big carriers are in most of the major UK PoPs (it would be handy if you mentioned the PoP name!). Just look on each carriers website and check their PoP list. Most major teir 1s meet your requirements, tier 2's I've seen that meet youre requirements with present in the UK are Hibernia, IIX/IXReach/Allegro, Init7 etc. If you want a UK or European view only, I know networks like Enta which are well peered offer their European partial transit view for less than the cost of a full table feed. I'm sure there are others too. +1 for Chris's advice, reach out on UKNOF. Cheers, James. From oscar.vives at gmail.com Fri Sep 18 08:39:17 2015 From: oscar.vives at gmail.com (Tei) Date: Fri, 18 Sep 2015 10:39:17 +0200 Subject: Microsoft blocking mail In-Reply-To: References: <14278.1442510549@turing-police.cc.vt.edu> Message-ID: On 18 September 2015 at 04:48, Keith Medcalf wrote: > > > You mean to say that you have to enable blanket remote code execution authority in order to submit a problem report to Microsoft? What a crock of crap. Thus I will never recommend to anyone that they use Microsoft products for anything whatsoever, especially not anything in the "Microsoft Cloud" virus distribution system. > > Being blocked is probably a good thing ... CGI forms that do the validation in the serverside are not up to modern expectations*. You want to do validation clientside. Like everything, is a tradeoff. This is how modern things are build :D Something something something G?del, Escher, Bach, rendering a document takes N cycles and can be calculate before hand. Running a program takes M cycles and can't be calculate before hand, M can be bigger than 6 times the lifespan of the universe or be infinite ... * is a social problem of expectations management. -- -- ?in del ?ensaje. From saper at saper.info Fri Sep 18 08:45:03 2015 From: saper at saper.info (Marcin Cieslak) Date: Fri, 18 Sep 2015 08:45:03 +0000 Subject: Microsoft blocking mail In-Reply-To: References: <14278.1442510549@turing-police.cc.vt.edu> Message-ID: On Fri, 18 Sep 2015, Tei wrote: > On 18 September 2015 at 04:48, Keith Medcalf wrote: > > > > Being blocked is probably a good thing ... > > > CGI forms that do the validation in the serverside are not up to > modern expectations*. You want to do validation clientside. If you do client-side and no server-side, you have a huge security problem. ~Marcin From maxtul at netassist.ua Fri Sep 18 11:01:19 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Fri, 18 Sep 2015 14:01:19 +0300 Subject: Transit Options in the UK? In-Reply-To: <041401d0f18a$67df4250$379dc6f0$@giesen.me> References: <041401d0f18a$67df4250$379dc6f0$@giesen.me> Message-ID: <55FBEEFF.7060803@netassist.ua> It seems some time if you want a good uplink you have to rent a L2 channel to another country for that ;) So that can be an option too. On 17.09.15 23:49, Gary T. Giesen wrote: > I have a customer who's trying to decide whether to renew their existing > transit contract or not for a POP they have in the UK and wondering what's > good for transit options out there. > > Looking for: > > - Good peering/reachability to other networks (I've already started perusing > the LINX peer list) > - Decent BGP community set (at a minimum RTBH and local pref, obviously the > richer the better) > - v6 support > - Own the last mile a bonus > > Can anyone offer any recommendations? > > Cheers, > > GTG > > From faisal at snappytelecom.net Fri Sep 18 14:17:29 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 18 Sep 2015 14:17:29 +0000 (GMT) Subject: Transit Options in the UK? In-Reply-To: <041401d0f18a$67df4250$379dc6f0$@giesen.me> References: <041401d0f18a$67df4250$379dc6f0$@giesen.me> Message-ID: <1338443527.419650.1442585849549.JavaMail.zimbra@snappytelecom.net> Suggestion ....Hibernia Networks ? Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Gary T. Giesen" > To: "nanog list" > Sent: Thursday, September 17, 2015 4:49:53 PM > Subject: Transit Options in the UK? > I have a customer who's trying to decide whether to renew their existing > transit contract or not for a POP they have in the UK and wondering what's > good for transit options out there. > > Looking for: > > - Good peering/reachability to other networks (I've already started perusing > the LINX peer list) > - Decent BGP community set (at a minimum RTBH and local pref, obviously the > richer the better) > - v6 support > - Own the last mile a bonus > > Can anyone offer any recommendations? > > Cheers, > > GTG From Rod.Beck at hibernianetworks.com Fri Sep 18 14:29:18 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Fri, 18 Sep 2015 14:29:18 +0000 Subject: Transit Options in the UK? In-Reply-To: <1338443527.419650.1442585849549.JavaMail.zimbra@snappytelecom.net> References: <041401d0f18a$67df4250$379dc6f0$@giesen.me>, <1338443527.419650.1442585849549.JavaMail.zimbra@snappytelecom.net> Message-ID: Its Layer 3 network now includes the lowest latency route across the Atlantic. Our new cable system: http://www.hibernianetworks.com/corp/wp-content/uploads/2013/02/Hibernia_Express_Financial_FINAL.pdf. Roderick Beck Sales - Europe and the Americas Hibernia Networks This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From dovid at telecurve.com Fri Sep 18 15:42:49 2015 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 18 Sep 2015 11:42:49 -0400 Subject: IP's with jitter/packet loss and very far away Message-ID: Hi, I am working on a presentation and looking to create samples of what a trace should not look like? Anyone have IP's that I can trace from the US or UK that will show 1) jitter 2) packet loss 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms TIA. Dovid From applebaumt at ochin.org Fri Sep 18 15:44:34 2015 From: applebaumt at ochin.org (Tyler Applebaum) Date: Fri, 18 Sep 2015 15:44:34 +0000 Subject: IP's with jitter/packet loss and very far away In-Reply-To: References: Message-ID: <25440C4BF31A8E44872003195DEB57BEC7F4DC@omail1.community-health.org> Anything on Integra's network. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender Sent: Friday, September 18, 2015 8:43 AM To: NANOG Subject: IP's with jitter/packet loss and very far away Hi, I am working on a presentation and looking to create samples of what a trace should not look like? Anyone have IP's that I can trace from the US or UK that will show 1) jitter 2) packet loss 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms TIA. Dovid Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. From magicsata at gmail.com Fri Sep 18 15:45:39 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Fri, 18 Sep 2015 16:45:39 +0100 Subject: IP's with jitter/packet loss and very far away In-Reply-To: References: Message-ID: Comcast? On 18 September 2015 at 16:42, Dovid Bender wrote: > Hi, > > I am working on a presentation and looking to create samples of what a > trace should not look like? Anyone have IP's that I can trace from the US > or UK that will show > 1) jitter > 2) packet loss > 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms > > TIA. > > Dovid > From dovid at telecurve.com Fri Sep 18 15:53:39 2015 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 18 Sep 2015 11:53:39 -0400 Subject: IP's with jitter/packet loss and very far away In-Reply-To: <25440C4BF31A8E44872003195DEB57BEC7F4DC@omail1.community-health.org> References: <25440C4BF31A8E44872003195DEB57BEC7F4DC@omail1.community-health.org> Message-ID: Any specific IP? I don't want this to turn into an ISP bashing session...... On Fri, Sep 18, 2015 at 11:44 AM, Tyler Applebaum wrote: > Anything on Integra's network. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender > Sent: Friday, September 18, 2015 8:43 AM > To: NANOG > Subject: IP's with jitter/packet loss and very far away > > Hi, > > I am working on a presentation and looking to create samples of what a > trace should not look like? Anyone have IP's that I can trace from the US > or UK that will show > 1) jitter > 2) packet loss > 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms > > TIA. > > Dovid > Attention: Information contained in this message and or attachments is > intended only for the recipient(s) named above and may contain confidential > and or privileged material that is protected under State or Federal law. If > you are not the intended recipient, any disclosure, copying, distribution > or action taken on it is prohibited. If you believe you have received this > email in error, please contact the sender, delete this email and destroy > all copies. > From keiths at neilltech.com Fri Sep 18 15:54:47 2015 From: keiths at neilltech.com (Keith Stokes) Date: Fri, 18 Sep 2015 15:54:47 +0000 Subject: IP's with jitter/packet loss and very far away In-Reply-To: References: Message-ID: <683771F5-B733-4065-8AF4-C352C6EFFAE7@neilltech.com> Use probably any coffee shop?s wireless network to anyone any you?ll get that most of the time. On Sep 18, 2015, at 10:42 AM, Dovid Bender > wrote: Hi, I am working on a presentation and looking to create samples of what a trace should not look like? Anyone have IP's that I can trace from the US or UK that will show 1) jitter 2) packet loss 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms TIA. Dovid --- Keith Stokes From keiths at neilltech.com Fri Sep 18 15:58:45 2015 From: keiths at neilltech.com (Keith Stokes) Date: Fri, 18 Sep 2015 15:58:45 +0000 Subject: IP's with jitter/packet loss and very far away In-Reply-To: <683771F5-B733-4065-8AF4-C352C6EFFAE7@neilltech.com> References: <683771F5-B733-4065-8AF4-C352C6EFFAE7@neilltech.com> Message-ID: There are also plenty of simulators to create what you want. This one looks pretty useful: http://www.linuxfoundation.org/collaborate/workgroups/networking/netem On Sep 18, 2015, at 10:54 AM, Neill > wrote: Use probably any coffee shop?s wireless network to anyone any you?ll get that most of the time. On Sep 18, 2015, at 10:42 AM, Dovid Bender > wrote: Hi, I am working on a presentation and looking to create samples of what a trace should not look like? Anyone have IP's that I can trace from the US or UK that will show 1) jitter 2) packet loss 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms TIA. Dovid --- Keith Stokes --- Keith Stokes From applebaumt at ochin.org Fri Sep 18 15:58:52 2015 From: applebaumt at ochin.org (Tyler Applebaum) Date: Fri, 18 Sep 2015 15:58:52 +0000 Subject: IP's with jitter/packet loss and very far away In-Reply-To: References: <25440C4BF31A8E44872003195DEB57BEC7F4DC@omail1.community-health.org> Message-ID: <25440C4BF31A8E44872003195DEB57BEC7F612@omail1.community-health.org> I was just kidding anyway. This is a 10gig Voxel IP: 80.249.209.187 No loss or anything, but it is in the EU, ~ 155ms latency for me on US West coast. From: Dovid Bender [mailto:dovid at telecurve.com] Sent: Friday, September 18, 2015 8:54 AM To: Tyler Applebaum Cc: NANOG Subject: Re: IP's with jitter/packet loss and very far away Any specific IP? I don't want this to turn into an ISP bashing session...... On Fri, Sep 18, 2015 at 11:44 AM, Tyler Applebaum > wrote: Anything on Integra's network. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender Sent: Friday, September 18, 2015 8:43 AM To: NANOG > Subject: IP's with jitter/packet loss and very far away Hi, I am working on a presentation and looking to create samples of what a trace should not look like? Anyone have IP's that I can trace from the US or UK that will show 1) jitter 2) packet loss 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms TIA. Dovid Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. From chuckchurch at gmail.com Fri Sep 18 16:04:20 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Fri, 18 Sep 2015 12:04:20 -0400 Subject: IP's with jitter/packet loss and very far away In-Reply-To: <683771F5-B733-4065-8AF4-C352C6EFFAE7@neilltech.com> References: <683771F5-B733-4065-8AF4-C352C6EFFAE7@neilltech.com> Message-ID: <030701d0f22b$b3dbb3e0$1b931ba0$@gmail.com> Any hotel wi-fi around 7PM local time. Chuck On Sep 18, 2015, at 10:42 AM, Dovid Bender > wrote: Hi, I am working on a presentation and looking to create samples of what a trace should not look like? Anyone have IP's that I can trace from the US or UK that will show 1) jitter 2) packet loss 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms TIA. Dovid From jake.mertel at ubiquityhosting.com Fri Sep 18 16:14:21 2015 From: jake.mertel at ubiquityhosting.com (Jake Mertel) Date: Fri, 18 Sep 2015 09:14:21 -0700 Subject: IP's with jitter/packet loss and very far away In-Reply-To: References: <683771F5-B733-4065-8AF4-C352C6EFFAE7@neilltech.com> Message-ID: Expanding on this a little further, you could use this tool + some virtual machines and static routes to simulate just about any conditions you wanted. -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Fri, Sep 18, 2015 at 8:58 AM, Keith Stokes wrote: > There are also plenty of simulators to create what you want. This one > looks pretty useful: > > http://www.linuxfoundation.org/collaborate/workgroups/networking/netem > > On Sep 18, 2015, at 10:54 AM, Neill keiths at neilltech.com>> wrote: > > Use probably any coffee shop?s wireless network to anyone any you?ll get > that most of the time. > > > On Sep 18, 2015, at 10:42 AM, Dovid Bender dovid at telecurve.com>> wrote: > > Hi, > > I am working on a presentation and looking to create samples of what a > trace should not look like? Anyone have IP's that I can trace from the US > or UK that will show > 1) jitter > 2) packet loss > 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms > > TIA. > > Dovid > > > --- > > Keith Stokes > > > > > > > --- > > Keith Stokes > > > > > From dovid at telecurve.com Fri Sep 18 16:16:10 2015 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 18 Sep 2015 12:16:10 -0400 Subject: IP's with jitter/packet loss and very far away In-Reply-To: <030701d0f22b$b3dbb3e0$1b931ba0$@gmail.com> References: <683771F5-B733-4065-8AF4-C352C6EFFAE7@neilltech.com> <030701d0f22b$b3dbb3e0$1b931ba0$@gmail.com> Message-ID: Tracing from the out side wont show anything as the external IP will be good. I need something perhaps on a sat link. On Fri, Sep 18, 2015 at 12:04 PM, Chuck Church wrote: > Any hotel wi-fi around 7PM local time. > > Chuck > > > On Sep 18, 2015, at 10:42 AM, Dovid Bender dovid at telecurve.com>> wrote: > > Hi, > > I am working on a presentation and looking to create samples of what a > trace should not look like? Anyone have IP's that I can trace from the US > or UK that will show > 1) jitter > 2) packet loss > 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms > > TIA. > > Dovid > > > > > From joelja at bogus.com Fri Sep 18 16:22:20 2015 From: joelja at bogus.com (joel jaeggli) Date: Fri, 18 Sep 2015 09:22:20 -0700 Subject: IP's with jitter/packet loss and very far away In-Reply-To: <030701d0f22b$b3dbb3e0$1b931ba0$@gmail.com> References: <683771F5-B733-4065-8AF4-C352C6EFFAE7@neilltech.com> <030701d0f22b$b3dbb3e0$1b931ba0$@gmail.com> Message-ID: <55FC3A3C.6080200@bogus.com> On 9/18/15 9:04 AM, Chuck Church wrote: > Any hotel wi-fi around 7PM local time. > > Chuck > > > On Sep 18, 2015, at 10:42 AM, Dovid Bender > wrote: > > Hi, > > I am working on a presentation and looking to create samples of what a trace should not look like? Anyone have IP's that I can trace from the US or UK that will show > 1) jitter > 2) packet loss > 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf my own experience is the misinterpretation of the above properties in traceroute is pathological to the point of making it useless in the hands of novices... you shouldn't be looking for jitter in traceroute, because it's not measuring the forwarding plane it's measuring the control plane. intermediate loss is mostly meaningless, unless it cascades, in which case it may have meaning but maybe not. > TIA. > > Dovid > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From A.L.M.Buxey at lboro.ac.uk Fri Sep 18 16:35:26 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Fri, 18 Sep 2015 16:35:26 +0000 Subject: IP's with jitter/packet loss and very far away In-Reply-To: <55FC3A3C.6080200@bogus.com> References: <683771F5-B733-4065-8AF4-C352C6EFFAE7@neilltech.com> <030701d0f22b$b3dbb3e0$1b931ba0$@gmail.com> <55FC3A3C.6080200@bogus.com> Message-ID: <20150918163526.GG18902@lboro.ac.uk> Hi, > my own experience is the misinterpretation of the above properties in > traceroute is pathological to the point of making it useless in the > hands of novices... correct. you should be looking at the output of other data transit systems such as iperf, bwctl etc - thats why such tools as PerfSONAR exist...allowing you to find the real problems in your IP path alan From cscora at apnic.net Fri Sep 18 18:11:47 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 Sep 2015 04:11:47 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201509181811.t8IIBlWl020381@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 19 Sep, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 563409 Prefixes after maximum aggregation (per Origin AS): 210444 Deaggregation factor: 2.68 Unique aggregates announced (without unneeded subnets): 274280 Total ASes present in the Internet Routing Table: 51461 Prefixes per ASN: 10.95 Origin-only ASes present in the Internet Routing Table: 36646 Origin ASes announcing only one prefix: 16076 Transit ASes present in the Internet Routing Table: 6399 Transit-only ASes present in the Internet Routing Table: 166 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 45 Max AS path prepend of ASN ( 55644) 41 Prefixes from unregistered ASNs in the Routing Table: 1072 Unregistered ASNs in the Routing Table: 410 Number of 32-bit ASNs allocated by the RIRs: 11043 Number of 32-bit ASNs visible in the Routing Table: 8416 Prefixes from 32-bit ASNs in the Routing Table: 31590 Number of bogon 32-bit ASNs visible in the Routing Table: 11 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 427 Number of addresses announced to Internet: 2809006784 Equivalent to 167 /8s, 110 /16s and 10 /24s Percentage of available address space announced: 75.9 Percentage of allocated address space announced: 75.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.6 Total number of prefixes smaller than registry allocations: 186129 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 143038 Total APNIC prefixes after maximum aggregation: 39757 APNIC Deaggregation factor: 3.60 Prefixes being announced from the APNIC address blocks: 150471 Unique aggregates announced from the APNIC address blocks: 59807 APNIC Region origin ASes present in the Internet Routing Table: 5093 APNIC Prefixes per ASN: 29.54 APNIC Region origin ASes announcing only one prefix: 1205 APNIC Region transit ASes present in the Internet Routing Table: 893 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 38 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1625 Number of APNIC addresses announced to Internet: 752460032 Equivalent to 44 /8s, 217 /16s and 161 /24s Percentage of available APNIC address space announced: 87.9 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: 179843 Total ARIN prefixes after maximum aggregation: 88200 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182830 Unique aggregates announced from the ARIN address blocks: 86224 ARIN Region origin ASes present in the Internet Routing Table: 16566 ARIN Prefixes per ASN: 11.04 ARIN Region origin ASes announcing only one prefix: 6045 ARIN Region transit ASes present in the Internet Routing Table: 1736 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 680 Number of ARIN addresses announced to Internet: 1117848512 Equivalent to 66 /8s, 161 /16s and 3 /24s Percentage of available ARIN address space announced: 59.1 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, 64198-64296, 393216-395164 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: 135757 Total RIPE prefixes after maximum aggregation: 67686 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 142759 Unique aggregates announced from the RIPE address blocks: 88639 RIPE Region origin ASes present in the Internet Routing Table: 17991 RIPE Prefixes per ASN: 7.94 RIPE Region origin ASes announcing only one prefix: 8035 RIPE Region transit ASes present in the Internet Routing Table: 2989 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: 4030 Number of RIPE addresses announced to Internet: 699655936 Equivalent to 41 /8s, 179 /16s and 231 /24s Percentage of available RIPE address space announced: 101.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 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: 60899 Total LACNIC prefixes after maximum aggregation: 11690 LACNIC Deaggregation factor: 5.21 Prefixes being announced from the LACNIC address blocks: 72751 Unique aggregates announced from the LACNIC address blocks: 33919 LACNIC Region origin ASes present in the Internet Routing Table: 2462 LACNIC Prefixes per ASN: 29.55 LACNIC Region origin ASes announcing only one prefix: 598 LACNIC Region transit ASes present in the Internet Routing Table: 532 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 28 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1932 Number of LACNIC addresses announced to Internet: 168903424 Equivalent to 10 /8s, 17 /16s and 67 /24s Percentage of available LACNIC address space announced: 100.7 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: 12172 Total AfriNIC prefixes after maximum aggregation: 3069 AfriNIC Deaggregation factor: 3.97 Prefixes being announced from the AfriNIC address blocks: 14171 Unique aggregates announced from the AfriNIC address blocks: 5325 AfriNIC Region origin ASes present in the Internet Routing Table: 739 AfriNIC Prefixes per ASN: 19.18 AfriNIC Region origin ASes announcing only one prefix: 193 AfriNIC Region transit ASes present in the Internet Routing Table: 167 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 149 Number of AfriNIC addresses announced to Internet: 69462528 Equivalent to 4 /8s, 35 /16s and 234 /24s Percentage of available AfriNIC address space announced: 69.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5586 4192 76 China Education and Research 4766 3005 11134 982 Korea Telecom 7545 2800 339 134 TPG Telecom Limited 17974 2709 908 90 PT Telekomunikasi Indonesia 4755 2045 427 228 TATA Communications formerly 9829 1909 1383 226 National Internet Backbone 9808 1601 8639 18 Guangdong Mobile Communicatio 4812 1574 2099 113 China Telecom (Group) 4808 1527 2251 476 CNCGROUP IP network China169 9583 1498 119 560 Sify Limited 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 3186 2966 144 Cox Communications Inc. 6389 2696 3688 51 BellSouth.net Inc. 3356 2537 10710 506 Level 3 Communications, Inc. 18566 2168 392 265 MegaPath Corporation 20115 1882 1867 397 Charter Communications 6983 1737 866 242 EarthLink, Inc. 30036 1595 321 391 Mediacom Communications Corp 4323 1587 1005 406 tw telecom holdings, inc. 701 1400 11401 676 MCI Communications Services, 22561 1373 415 258 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 2473 129 7 SaudiNet, Saudi Telecom Compa 20940 2141 848 1546 Akamai International B.V. 34984 2048 306 377 TELLCOM ILETISIM HIZMETLERI A 6849 1208 355 21 JSC "Ukrtelecom" 13188 1071 97 76 TOV "Bank-Inform" 31148 1056 46 24 Freenet Ltd. 8402 1020 544 15 OJSC "Vimpelcom" 12479 997 965 78 France Telecom Espana SA 8551 983 376 52 Bezeq International-Ltd 6830 913 2694 466 Liberty Global Operations B.V 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 3370 539 153 Telmex Colombia S.A. 28573 2255 2167 126 NET Servi?os de Comunica??o S 8151 1834 3273 481 Uninet S.A. de C.V. 7303 1562 936 237 Telecom Argentina S.A. 6503 1401 445 57 Axtel, S.A.B. de C.V. 26615 1093 2325 35 Tim Celular S.A. 6147 1059 374 30 Telefonica del Peru S.A.A. 11830 999 364 24 Instituto Costarricense de El 7738 995 1882 41 Telemar Norte Leste S.A. 3816 947 436 160 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 910 1468 10 TE-AS 24863 805 281 37 Link Egypt (Link.NET) 36903 512 258 99 Office National des Postes et 36992 439 1229 32 ETISALAT MISR 37492 315 191 72 Orange Tunisie 24835 283 146 12 Vodafone Data 29571 247 21 13 Cote d'Ivoire Telecom 3741 226 854 188 Internet Solutions 36947 197 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 4538 5586 4192 76 China Education and Research 10620 3370 539 153 Telmex Colombia S.A. 22773 3186 2966 144 Cox Communications Inc. 4766 3005 11134 982 Korea Telecom 7545 2800 339 134 TPG Telecom Limited 17974 2709 908 90 PT Telekomunikasi Indonesia 6389 2696 3688 51 BellSouth.net Inc. 3356 2537 10710 506 Level 3 Communications, Inc. 39891 2473 129 7 SaudiNet, Saudi Telecom Compa 28573 2255 2167 126 NET Servi?os de Comunica??o S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3370 3217 Telmex Colombia S.A. 22773 3186 3042 Cox Communications Inc. 7545 2800 2666 TPG Telecom Limited 6389 2696 2645 BellSouth.net Inc. 17974 2709 2619 PT Telekomunikasi Indonesia 39891 2473 2466 SaudiNet, Saudi Telecom Compa 28573 2255 2129 NET Servi?os de Comunica??o S 3356 2537 2031 Level 3 Communications, Inc. 4766 3005 2023 Korea Telecom 18566 2168 1903 MegaPath Corporation 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 47092 UNALLOCATED 8.8.204.0/24 16410 The Reynolds and Rey 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 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 Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.100.1.0/24 9730 Bharti Telesonic Ltd Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 23.249.144.0/21 40430 colo4jax, LLC 23.249.152.0/21 40430 colo4jax, LLC 27.50.8.0/24 55548 Ravibhawan 27.50.9.0/24 55548 Ravibhawan 27.50.10.0/24 55548 Ravibhawan 27.50.11.0/24 55548 Ravibhawan 27.100.7.0/24 56096 >>UNKNOWN<< 31.170.96.0/23 23456 32bit Transition AS 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:18 /9:13 /10:36 /11:95 /12:262 /13:501 /14:1006 /15:1739 /16:12911 /17:7388 /18:12584 /19:26323 /20:37370 /21:39522 /22:61863 /23:54132 /24:305312 /25:852 /26:930 /27:493 /28:15 /29:14 /30:9 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2473 SaudiNet, Saudi Telecom Compa 22773 2394 3186 Cox Communications Inc. 18566 2075 2168 MegaPath Corporation 6389 1608 2696 BellSouth.net Inc. 30036 1414 1595 Mediacom Communications Corp 6983 1386 1737 EarthLink, Inc. 34984 1368 2048 TELLCOM ILETISIM HIZMETLERI A 10620 1246 3370 Telmex Colombia S.A. 11492 1134 1217 CABLE ONE, INC. 22561 1046 1373 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1594 2:688 4:97 5:1879 6:25 8:1395 12:1808 13:18 14:1432 15:17 16:2 17:50 18:22 20:50 23:1274 24:1740 27:2085 31:1607 32:34 33:2 34:4 35:6 36:154 37:2044 38:1062 39:15 40:72 41:2784 42:341 43:1517 44:31 45:1170 46:2349 47:57 49:992 50:803 52:23 54:85 55:6 56:4 57:43 58:1417 59:771 60:499 61:1791 62:1418 63:1897 64:4401 65:2237 66:3998 67:2074 68:1071 69:3252 70:1041 71:450 72:1979 74:2553 75:360 76:396 77:1369 78:1171 79:812 80:1357 81:1357 82:874 83:713 84:773 85:1388 86:450 87:1022 88:535 89:1932 90:149 91:6008 92:843 93:2286 94:2101 95:2161 96:434 97:348 98:958 99:55 100:74 101:852 103:8305 104:2004 105:76 106:347 107:1048 108:625 109:2140 110:1211 111:1456 112:825 113:1113 114:861 115:1343 116:1503 117:1097 118:1953 119:1478 120:466 121:1149 122:2176 123:1850 124:1545 125:1718 128:663 129:392 130:430 131:1257 132:534 133:166 134:421 135:103 136:346 137:320 138:1283 139:170 140:247 141:438 142:662 143:547 144:570 145:127 146:801 147:588 148:1271 149:433 150:601 151:799 152:529 153:256 154:498 155:883 156:423 157:422 158:346 159:1063 160:424 161:675 162:2126 163:461 164:693 165:853 166:302 167:871 168:1251 169:199 170:1399 171:251 172:273 173:1514 174:713 175:712 176:1464 177:3966 178:2225 179:993 180:1952 181:1550 182:1820 183:632 184:742 185:4303 186:2963 187:1856 188:2111 189:1683 190:7594 191:1155 192:8540 193:5660 194:4260 195:3679 196:1952 197:1080 198:5478 199:5517 200:6676 201:3311 202:9778 203:9202 204:4548 205:2738 206:3025 207:2996 208:4007 209:3895 210:3748 211:2055 212:2564 213:2227 214:864 215:73 216:5756 217:1795 218:796 219:532 220:1574 221:821 222:721 223:832 End of report From bart.smit at expereo.com Fri Sep 18 17:20:03 2015 From: bart.smit at expereo.com (Bart Smit) Date: Fri, 18 Sep 2015 17:20:03 +0000 Subject: IP's with jitter/packet loss and very far away In-Reply-To: <25440C4BF31A8E44872003195DEB57BEC7F612@omail1.community-health.org> References: <25440C4BF31A8E44872003195DEB57BEC7F4DC@omail1.community-health.org> , <25440C4BF31A8E44872003195DEB57BEC7F612@omail1.community-health.org> Message-ID: <7EE9FD23-6A1D-42FD-A422-5ED74E1BBE59@expereo.com> Here is an IP tunneled over a 3G service in the UK: 37.26.225.245 -Bart On 18 Sep 2015, at 18:06, Tyler Applebaum wrote: I was just kidding anyway. This is a 10gig Voxel IP: 80.249.209.187 No loss or anything, but it is in the EU, ~ 155ms latency for me on US West coast. From: Dovid Bender [mailto:dovid at telecurve.com] Sent: Friday, September 18, 2015 8:54 AM To: Tyler Applebaum Cc: NANOG Subject: Re: IP's with jitter/packet loss and very far away Any specific IP? I don't want this to turn into an ISP bashing session...... On Fri, Sep 18, 2015 at 11:44 AM, Tyler Applebaum > wrote: Anything on Integra's network. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender Sent: Friday, September 18, 2015 8:43 AM To: NANOG > Subject: IP's with jitter/packet loss and very far away Hi, I am working on a presentation and looking to create samples of what a trace should not look like? Anyone have IP's that I can trace from the US or UK that will show 1) jitter 2) packet loss 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms TIA. Dovid Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender, delete this email and destroy all copies. From florin at andrei.myip.org Fri Sep 18 18:50:23 2015 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 18 Sep 2015 11:50:23 -0700 Subject: high latency on West =?UTF-8?Q?Coast=3F?= Message-ID: I'm seeing 250 ms between California and Oregon. Not just AWS, but also between, say, Comcast and AWS. Latency from other locations, such as between N. Virginia and Oregon, is much lower, about 72 ms in my tests. Anyone else experiencing these issues along the west coast? -- Florin Andrei http://florin.myip.org/ From charles at phukish.com Fri Sep 18 20:20:08 2015 From: charles at phukish.com (Charles van Niman) Date: Fri, 18 Sep 2015 15:20:08 -0500 Subject: high latency on West Coast? In-Reply-To: References: Message-ID: Hmmm, I am seeing about 20ms from a VPS in Seattle, do you happen to have a trace of the path with this issue? /Charles On Fri, Sep 18, 2015 at 1:50 PM, Florin Andrei wrote: > I'm seeing 250 ms between California and Oregon. Not just AWS, but also > between, say, Comcast and AWS. > > Latency from other locations, such as between N. Virginia and Oregon, is > much lower, about 72 ms in my tests. > > Anyone else experiencing these issues along the west coast? > > -- > Florin Andrei > http://florin.myip.org/ From mikea at mikea.ath.cx Fri Sep 18 20:25:26 2015 From: mikea at mikea.ath.cx (mikea) Date: Fri, 18 Sep 2015 15:25:26 -0500 Subject: IP's with jitter/packet loss and very far away In-Reply-To: References: Message-ID: <20150918202526.GA96992@mikea.ath.cx> On Fri, Sep 18, 2015 at 11:42:49AM -0400, Dovid Bender wrote: > Hi, > > I am working on a presentation and looking to create samples of what a > trace should not look like? Anyone have IP's that I can trace from the US > or UK that will show > 1) jitter > 2) packet loss > 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms www.gov.mg shows fairly long ping times (especially with 1kB payload), a fair amount of jitter, and some loss. It's not like pinging something at the D/E of a really bad link, but I wouldn't want to push X graphics over it. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From florin at andrei.myip.org Fri Sep 18 20:39:41 2015 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 18 Sep 2015 13:39:41 -0700 Subject: high latency on West =?UTF-8?Q?Coast=3F?= In-Reply-To: References: Message-ID: <98cc14751556be01857c4ad7978c0b46@andrei.myip.org> On 2015-09-18 13:20, Charles van Niman wrote: > Hmmm, I am seeing about 20ms from a VPS in Seattle, do you happen to > have a trace of the path with this issue? From my laptop in San Jose to an ELB in AWS / Oregon: 1.|-- 192.168.1.1 0.0% 10 10.6 6.0 1.0 17.1 5.2 2.|-- 10.1.10.1 0.0% 10 3.5 12.7 2.0 60.8 18.2 3.|-- c-98-207-128-1.hsd1.ca.co 0.0% 10 27.5 19.8 6.0 29.1 7.3 4.|-- te-0-2-0-7-sur04.sanjose. 0.0% 10 11.6 14.5 10.2 28.4 5.7 5.|-- te-0-6-0-6-sur03.sanjose. 0.0% 10 9.9 17.2 9.9 38.2 8.7 6.|-- he-0-3-0-2-ar01.santaclar 0.0% 10 16.0 20.1 11.8 35.2 8.0 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- he-0-11-0-1-pe02.529bryan 0.0% 10 21.4 21.7 10.8 43.4 10.4 9.|-- gtt-cr01.losangeles.ca.ib 0.0% 10 10.8 18.5 10.8 40.4 8.8 10.|-- 205.251.229.32 0.0% 10 204.7 216.3 204.7 236.7 10.2 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- 27.0.0.255 0.0% 10 208.0 217.5 201.1 300.2 30.1 15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 16.|-- 205.251.225.215 0.0% 10 205.6 217.6 200.5 302.2 30.1 17.|-- 205.251.232.72 0.0% 9 208.6 219.5 203.2 259.8 20.1 18.|-- 205.251.232.201 0.0% 9 216.6 225.5 206.3 254.8 15.5 19.|-- 205.251.230.127 0.0% 8 201.0 212.5 201.0 225.1 7.3 20.|-- ??? 100.0 8 0.0 0.0 0.0 0.0 0.0 1.|-- 192.168.1.1 0.0% 10 8.8 14.2 0.9 66.2 19.2 2.|-- 10.1.10.1 0.0% 10 7.1 16.7 1.4 72.0 20.7 3.|-- 98.207.128.1 0.0% 10 13.6 19.6 13.6 30.4 5.4 4.|-- 162.151.30.29 0.0% 10 13.3 24.9 9.2 97.9 26.8 5.|-- 162.151.79.1 0.0% 10 56.5 27.4 11.9 56.5 13.6 6.|-- 68.87.192.173 0.0% 10 13.8 21.1 9.9 45.1 11.2 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- 68.86.86.146 0.0% 10 14.3 20.0 13.5 38.0 7.6 9.|-- 66.208.229.30 0.0% 10 15.9 19.4 10.1 40.5 9.2 10.|-- 205.251.229.32 10.0% 10 213.0 245.7 208.2 377.9 53.2 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- 27.0.0.255 0.0% 10 220.0 234.2 207.6 335.0 39.5 15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 16.|-- 205.251.225.215 0.0% 10 208.3 226.3 206.7 276.6 21.8 17.|-- 205.251.232.72 0.0% 9 210.6 216.2 204.1 237.7 12.5 18.|-- 205.251.232.201 0.0% 9 236.1 232.5 205.8 261.2 18.3 19.|-- 205.251.230.127 0.0% 8 206.1 233.2 206.1 287.3 24.8 20.|-- ??? 100.0 8 0.0 0.0 0.0 0.0 0.0 -- Florin Andrei http://florin.myip.org/ From parkerj17 at gmail.com Fri Sep 18 20:31:02 2015 From: parkerj17 at gmail.com (Justin Parker) Date: Fri, 18 Sep 2015 16:31:02 -0400 Subject: high latency on West Coast? In-Reply-To: References: Message-ID: 32ms via at&t From nanogml at Mail.DDoS-Mitigator.net Fri Sep 18 21:10:10 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Fri, 18 Sep 2015 14:10:10 -0700 Subject: high latency on West Coast? In-Reply-To: References: Message-ID: <20150918211010.GA2963@Mail.DDoS-Mitigator.net> hi andrei On 09/18/15 at 11:50am, Florin Andrei wrote: > I'm seeing 250 ms between California and Oregon. Not just AWS, but also > between, say, Comcast and AWS. > > Latency from other locations, such as between N. Virginia and Oregon, is > much lower, about 72 ms in my tests. > > Anyone else experiencing these issues along the west coast? amazon seems confused from Reno# traceroute 205.251.230.127 ------------------------------------- traceroute to 205.251.230.127 (205.251.230.127), 30 hops max, 60 byte packets 1 ... deleted ... 2 * * * 3 rno-core0-ge.greatbasin.net (207.228.35.136) 10.863 ms 12.237 ms 13.611 ms 4 67.138.231.149 (67.138.231.149) 14.963 ms 16.372 ms 17.719 ms 5 paix01-sfo4.amazon.com (198.32.176.36) 21.914 ms 23.259 ms 26.048 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * From florin at andrei.myip.org Fri Sep 18 21:37:38 2015 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 18 Sep 2015 14:37:38 -0700 Subject: high latency on West =?UTF-8?Q?Coast=3F?= In-Reply-To: <20150918211010.GA2963@Mail.DDoS-Mitigator.net> References: <20150918211010.GA2963@Mail.DDoS-Mitigator.net> Message-ID: I've asked Runscope (a monitoring service we're using for a few things, with locations in AWS and Rackspace), and they've confirmed my findings - there's unusually high latency somewhere around the AWS facility in Oregon, started last night, but they say it's "getting better". -- Florin Andrei http://florin.myip.org/ From andrew at ethernaut.io Fri Sep 18 21:57:51 2015 From: andrew at ethernaut.io (andrew) Date: Fri, 18 Sep 2015 17:57:51 -0400 Subject: high latency on West Coast? Message-ID: <6yt256n9nt6270b9br1mhgde.1442613471371@email.android.com> L3 fiber cut . -andrew-------- Original message -------- From: Florin Andrei Date: 09/18/2015 5:37 PM (GMT-05:00) To: nanog at nanog.org Subject: Re: high latency on West Coast? I've asked Runscope (a monitoring service we're using for a few things, with locations in AWS and Rackspace), and they've confirmed my findings - there's unusually high latency somewhere around the AWS facility in Oregon, started last night, but they say it's "getting better". -- Florin Andrei http://florin.myip.org/ From keiths at neilltech.com Fri Sep 18 21:59:30 2015 From: keiths at neilltech.com (Keith Stokes) Date: Fri, 18 Sep 2015 21:59:30 +0000 Subject: high latency on West Coast? In-Reply-To: References: <20150918211010.GA2963@Mail.DDoS-Mitigator.net>, Message-ID: <41D7B685-237D-49FE-86C0-CA2FCF1716F8@neilltech.com> I have a SmokePing machine sitting in AWS Oregon looking at a few of my sites. It shows a bunch of ugliness starting around midnight Central and smoothing out but still with higher latency continuing to some sites. The same site is showing ugliness in the last hour. -- Keith Stokes > On Sep 18, 2015, at 4:39 PM, Florin Andrei wrote: > > I've asked Runscope (a monitoring service we're using for a few things, with locations in AWS and Rackspace), and they've confirmed my findings - there's unusually high latency somewhere around the AWS facility in Oregon, started last night, but they say it's "getting better". > > -- > Florin Andrei > http://florin.myip.org/ From cidr-report at potaroo.net Fri Sep 18 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Sep 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201509182200.t8IM00hp044808@wattle.apnic.net> This report has been generated at Fri Sep 18 21:14:54 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 11-09-15 571301 310385 12-09-15 571748 310189 13-09-15 571349 309492 14-09-15 571125 309862 15-09-15 570953 310306 16-09-15 571039 310278 17-09-15 571575 309661 18-09-15 571458 309739 AS Summary 51736 Number of ASes in routing system 20513 Number of ASes announcing only one prefix 5604 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center,CN 121035264 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'). --- 18Sep15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 572276 309636 262640 45.9% All ASes AS22773 3189 174 3015 94.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4538 5604 2807 2797 49.9% ERX-CERNET-BKB China Education and Research Network Center,CN AS17974 2708 90 2618 96.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2474 14 2460 99.4% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS7545 2941 641 2300 78.2% TPG-INTERNET-AP TPG Telecom Limited,AU AS6389 2695 483 2212 82.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS28573 2261 305 1956 86.5% NET Servi?os de Comunica??o S.A.,BR AS9394 2102 207 1895 90.2% CTTNET China TieTong Telecommunications Corporation,CN AS3356 2538 749 1789 70.5% LEVEL3 - Level 3 Communications, Inc.,US AS4766 3005 1276 1729 57.5% KIXS-AS-KR Korea Telecom,KR AS10620 3372 1648 1724 51.1% Telmex Colombia S.A.,CO AS9808 1601 81 1520 94.9% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS4755 2045 546 1499 73.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS6983 1736 245 1491 85.9% ITCDELTA - Earthlink, Inc.,US AS20115 1882 410 1472 78.2% CHARTER-NET-HKY-NC - Charter Communications,US AS9498 1386 118 1268 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2169 975 1194 55.0% MEGAPATH5-US - MegaPath Corporation,US AS4323 1591 406 1185 74.5% TWTC - tw telecom holdings, inc.,US AS38285 1170 18 1152 98.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS22561 1373 267 1106 80.6% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7552 1414 341 1073 75.9% VIETEL-AS-AP Viettel Corporation,VN AS4812 1575 524 1051 66.7% CHINANET-SH-AP China Telecom (Group),CN AS7303 1562 520 1042 66.7% Telecom Argentina S.A.,AR AS4808 1544 515 1029 66.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS8151 1840 818 1022 55.5% Uninet S.A. de C.V.,MX AS38197 1451 437 1014 69.9% SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK AS8402 1000 24 976 97.6% CORBINA-AS OJSC "Vimpelcom",RU AS6849 1205 235 970 80.5% UKRTELNET JSC UKRTELECOM,UA AS4788 1344 404 940 69.9% TMNET-AS-AP TM Net, Internet Service Provider,MY AS26615 1093 153 940 86.0% Tim Celular S.A.,BR Total 61870 15431 46439 75.1% Top 30 total Possible Bogus Routes 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 23.249.144.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 23.249.144.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 23.249.152.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 27.50.8.0/24 AS55548 27.50.9.0/24 AS55548 27.50.10.0/24 AS55548 27.50.11.0/24 AS55548 27.100.7.0/24 AS56096 31.170.96.0/23 AS19798 YOUZEE-MAIN Manaslu Media Entertainment SL,ES 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 36.50.0.0/16 AS20418 MOSMOG-AS OJSC TORGOVYJ DOM MOSKVA-MOGILEV,RU 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.3.0/24 AS37004 -Reserved AS-,ZZ 41.73.4.0/24 AS37004 -Reserved AS-,ZZ 41.73.5.0/24 AS37004 -Reserved AS-,ZZ 41.73.6.0/24 AS37004 -Reserved AS-,ZZ 41.73.7.0/24 AS37004 -Reserved AS-,ZZ 41.73.8.0/24 AS37004 -Reserved AS-,ZZ 41.73.9.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.17.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.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.126.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -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.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.57.192.0/22 AS33321 -Reserved AS-,ZZ 64.234.239.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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.187.240.0/24 AS22753 REDHAT-0 - Red Hat, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.228.160.0/20 AS7233 YAHOO-US - Yahoo,US 66.228.176.0/21 AS17110 YAHOO-US2 - Yahoo,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 68.234.0.0/19 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.0.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.5.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.7.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.16.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.17.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.18.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.19.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.20.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.21.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.22.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.23.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.24.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.26.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.28.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.29.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 69.24.96.0/20 AS26804 -Reserved AS-,ZZ 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.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 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.213.220.0/24 AS19662 -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.100.1.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd,IN 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.12.48.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.12.241.0/24 AS7718 TRANSACT-SDN-AS TransACT Capital Communications Pty Limited,AU 103.12.247.0/24 AS13233 103.13.1.0/24 AS58609 103.14.32.0/22 AS2519 VECTANT VECTANT Ltd.,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.22.212.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.25.144.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.29.90.0/23 AS9503 FX-PRIMARY-AS FX Networks Limited,AU 103.29.236.0/24 AS13200 103.29.237.0/24 AS13200 103.198.0.0/16 AS7497 CSTNET-AS-AP Computer Network Information Center,CN 103.199.0.0/16 AS7497 CSTNET-AS-AP Computer Network Information Center,CN 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.229.152.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.232.164.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.233.140.0/23 AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK,AF 103.235.72.0/23 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.235.74.0/23 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.235.216.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.237.76.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.253.164.0/23 AS13317 116.199.203.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.205.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.206.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.207.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 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 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 155.35.0.0/16 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.1.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.34.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.35.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.46.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.47.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.232.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 160.30.0.0/16 AS20421 LLC-ASPECT-AS LLC Aspect,RU 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.221.64.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 162.221.64.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 162.221.68.0/22 AS40430 COLO4JAX-AS - colo4jax, 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.88.48.0/20 AS29927 -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.249.191.0/24 AS45816 ISHK-AP I-Services Network Solution Limited,HK 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.191.0.0/16 AS20053 RELAX-LLC-AS LLC Relax,RU 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.52.57.0/24 AS48039 KGT-AS KGT new media,DE 185.52.58.0/24 AS48039 KGT-AS KGT new media,DE 186.148.224.0/21 AS52302 Awknet International, S.A.,PA 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.67.160.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.67.161.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.67.162.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.46.0/23 AS17139 NETRANGE - Corporate Colocation 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.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.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 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.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 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.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 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.151.160.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.130.0/24 AS21104 AM-NETSYS-AS Netsys JV LLC,AM 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.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.9.9.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.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.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 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.180.0/24 AS37004 -Reserved AS-,ZZ 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.223.144.0/21 AS12143 STARTEL-AS,TZ 198.8.72.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.72.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.76.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.77.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.78.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.79.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 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.91.44.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.44.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.45.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.46.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.47.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,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.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -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.103.89.0/24 AS19523 -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.182.207.0/24 AS23136 ONX - OnX Enterprise Solutions Inc.,CA 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 201.131.5.0/24 AS28389 -Reserved AS-,ZZ 201.131.88.0/24 AS8151 Uninet S.A. de C.V.,MX 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.6.208.0/24 AS23937 203.6.209.0/24 AS23937 203.6.210.0/24 AS23937 203.6.211.0/24 AS23937 203.6.213.0/24 AS23937 203.6.215.0/24 AS23937 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 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.77.216.0/23 AS46550 -Reserved AS-,ZZ 204.77.216.0/24 AS46550 -Reserved AS-,ZZ 204.77.217.0/24 AS46550 -Reserved AS-,ZZ 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 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 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 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.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.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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 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.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.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 217.147.6.0/24 AS8936 ASKUBAN CJSC Orbita,RU 217.147.7.0/24 AS8936 ASKUBAN CJSC Orbita,RU 217.147.10.0/24 AS8936 ASKUBAN CJSC Orbita,RU 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 Sep 18 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Sep 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201509182200.t8IM01dQ044823@wattle.apnic.net> BGP Update Report Interval: 10-Sep-15 -to- 17-Sep-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 180449 3.6% 124.7 -- BSNL-NIB National Internet Backbone,IN 2 - AS38197 150458 3.0% 103.8 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 3 - AS22059 118544 2.4% 29636.0 -- -Reserved AS-,ZZ 4 - AS21669 114859 2.3% 22971.8 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 5 - AS3709 61634 1.2% 2282.7 -- NET-CITY-SA - City of San Antonio,US 6 - AS200008 56212 1.1% 56212.0 -- PIRUM-AS Pirum Systems Limited,GB 7 - AS199367 44702 0.9% 44702.0 -- AS_GBP Globe Business Publishing Limited,GB 8 - AS37473 40953 0.8% 20476.5 -- TELESOM,SO 9 - AS131090 38159 0.8% 2725.6 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 10 - AS134438 33134 0.7% 33134.0 -- AIRAAIFUL-AS-AP Aira & Aiful Public Company Limited,TH 11 - AS8402 32573 0.7% 29.4 -- CORBINA-AS OJSC "Vimpelcom",RU 12 - AS9198 31464 0.6% 38.4 -- KAZTELECOM-AS JSC Kazakhtelecom,KZ 13 - AS45899 31349 0.6% 48.5 -- VNPT-AS-VN VNPT Corp,VN 14 - AS30295 31282 0.6% 7820.5 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 15 - AS12389 30637 0.6% 79.2 -- ROSTELECOM-AS PJSC Rostelecom,RU 16 - AS56636 28604 0.6% 28604.0 -- ASVEDARU VEDA Ltd.,RU 17 - AS8001 27375 0.5% 1710.9 -- NET-ACCESS-CORP - Net Access Corporation,US 18 - AS10620 27251 0.5% 8.8 -- Telmex Colombia S.A.,CO 19 - AS8151 24232 0.5% 16.7 -- Uninet S.A. de C.V.,MX 20 - AS31148 24141 0.5% 22.8 -- FREENET-AS Freenet Ltd.,UA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS200008 56212 1.1% 56212.0 -- PIRUM-AS Pirum Systems Limited,GB 2 - AS199367 44702 0.9% 44702.0 -- AS_GBP Globe Business Publishing Limited,GB 3 - AS134438 33134 0.7% 33134.0 -- AIRAAIFUL-AS-AP Aira & Aiful Public Company Limited,TH 4 - AS22059 118544 2.4% 29636.0 -- -Reserved AS-,ZZ 5 - AS56636 28604 0.6% 28604.0 -- ASVEDARU VEDA Ltd.,RU 6 - AS21669 114859 2.3% 22971.8 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 7 - AS37473 40953 0.8% 20476.5 -- TELESOM,SO 8 - AS200671 18431 0.4% 18431.0 -- SKOK-JAWORZNO SKOK Jaworzno,PL 9 - AS47680 8945 0.2% 8945.0 -- NHCS EOBO Ltd T/A BBnet,IE 10 - AS40493 7875 0.2% 7875.0 -- FACILITYSOURCEINC - FacilitySource,US 11 - AS30295 31282 0.6% 7820.5 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 12 - AS37590 7326 0.1% 7326.0 -- BCA-ASN,AO 13 - AS57518 10423 0.2% 5211.5 -- APOLLON-AS Apollon L.L.C.,RU 14 - AS24237 4848 0.1% 4848.0 -- SIAM-CITY-CEMENT-PUBLIC-COMPANY-LIMITED Siam City Cement Public Company Limited (SCCC),TH 15 - AS25563 18134 0.4% 4533.5 -- WEBLAND-AS Webland AG,CH 16 - AS38000 4136 0.1% 4136.0 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 17 - AS17214 5993 0.1% 2996.5 -- GUIDEWIRE - Guidewire Software, Inc.,US 18 - AS131090 38159 0.8% 2725.6 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 19 - AS3709 61634 1.2% 2282.7 -- NET-CITY-SA - City of San Antonio,US 20 - AS131112 2256 0.0% 2256.0 -- MMTC-AS-ID Sekolah Tinggi Multi Media "MMTC" Yogyakarta,ID TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 209.212.8.0/24 114835 2.2% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 2 - 64.34.125.0/24 59301 1.1% AS22059 -- -Reserved AS-,ZZ 3 - 76.191.107.0/24 59239 1.1% AS22059 -- -Reserved AS-,ZZ 4 - 185.38.132.0/24 56212 1.1% AS200008 -- PIRUM-AS Pirum Systems Limited,GB 5 - 185.19.144.0/22 44702 0.9% AS199367 -- AS_GBP Globe Business Publishing Limited,GB 6 - 197.157.247.0/24 40932 0.8% AS37473 -- TELESOM,SO 7 - 61.7.155.0/24 38004 0.7% AS131090 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 8 - 110.170.17.0/24 33134 0.6% AS134438 -- AIRAAIFUL-AS-AP Aira & Aiful Public Company Limited,TH 9 - 195.128.159.0/24 28604 0.6% AS56636 -- ASVEDARU VEDA Ltd.,RU 10 - 192.135.223.0/24 27357 0.5% AS8001 -- NET-ACCESS-CORP - Net Access Corporation,US 11 - 5.136.192.0/18 20071 0.4% AS12389 -- ROSTELECOM-AS PJSC Rostelecom,RU 12 - 155.133.79.0/24 18431 0.3% AS200671 -- SKOK-JAWORZNO SKOK Jaworzno,PL 13 - 66.19.194.0/24 13039 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 14 - 199.60.236.0/24 11155 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 15 - 199.60.234.0/23 10587 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 16 - 208.78.31.0/24 10250 0.2% AS29838 -- AMC - Atlantic Metro Communications,US 17 - 216.150.230.0/24 10092 0.2% AS13737 -- RIVERFRONT - Riverfront Communications LLC,US 18 - 199.60.233.0/24 9539 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 19 - 88.87.160.0/19 8945 0.2% AS47680 -- NHCS EOBO Ltd T/A BBnet,IE 20 - 202.41.70.0/24 7882 0.1% AS2697 -- ERX-ERNET-AS Education and Research Network,IN 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 rsk at gsp.org Fri Sep 18 22:23:27 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 18 Sep 2015 18:23:27 -0400 Subject: Sign-On Letter to the Court in the FCC's Net Neutrality Case In-Reply-To: <55FADF40.4040705@meetinghouse.net> References: <20150912194545.65752.qmail@ary.lan> <55F90147.3020703@nic-naa.net> <55FADC4A.7010607@gmail.com> <55FADF40.4040705@meetinghouse.net> Message-ID: <20150918222327.GA24664@gsp.org> On Thu, Sep 17, 2015 at 11:41:52AM -0400, Miles Fidelman wrote: > Me too. Be sure to actually read the Amicus brief - it's incredibly > well written and informative. I've signed on as well and strongly concur with Miles' recommendation. ---rsk From srihari at cse.sc.edu Fri Sep 18 22:24:27 2015 From: srihari at cse.sc.edu (Srihari Nelakuditi) Date: Fri, 18 Sep 2015 18:24:27 -0400 Subject: Call for Participation: IEEE International Conference on Network Protocols (ICNP) Message-ID: <55FC8F1B.4010200@cse.sc.edu> Call for Participation IEEE ICNP 2015 http://icnp15.cs.ucr.edu/ San Francisco, CA, USA November 10-13, 2015 Early Registration Deadline: 25 September 2015 Student Travel Grant Deadline: 25 September 2015 We cordially invite you to participate in the 23rd edition of the IEEE International Conference on Network Protocols (ICNP 2015), covering all aspects of network protocol research, including design, analysis, specification, verification, implementation, and performance. ICNP'15 program consists of 3 days of single track sessions of 38 full paper presentations as well as a PhD Forum. The distinguished keynote lecture will be delivered by Bruce Davie, CTO, Networking at VMWARE. Associated with ICNP'15 are two workshops, COntrol, Operation, and appLication in SDN Protocols (CoolSDN) and GENI Network Innovators Community Event (NICE). GENI NICE is a premier event for researchers and educators to demonstrate, present research results and discuss works in progress related to the NSF GENI testbed. Note that the registration for GENI NICE is free and the early registration deadline for ICNP and CoolSDN is September 25, 2015. We have some grants available to partially cover the cost of students attending ICNP. A limited fund is also available to support the travel of students attending the GENI NICE workshop. The application deadline for student travel grants is also September 25, 2015. Further details on the conference are available at http://icnp15.cs.ucr.edu/ We are looking forward to seeing you in San Francisco, USA. The ICNP'15 Organization Committee From tim.h at bendtel.com Fri Sep 18 22:33:30 2015 From: tim.h at bendtel.com (Tim Howe) Date: Fri, 18 Sep 2015 15:33:30 -0700 Subject: high latency on West Coast? In-Reply-To: References: Message-ID: <20150918153330.1e8a0c80@cool.bendtel.com> On Fri, 18 Sep 2015 11:50:23 -0700 Florin Andrei wrote: > I'm seeing 250 ms between California and Oregon. Not just AWS, but also > between, say, Comcast and AWS. > > Latency from other locations, such as between N. Virginia and Oregon, is > much lower, about 72 ms in my tests. > > Anyone else experiencing these issues along the west coast? > Not sure if related to what you are seeing, but I do know there is a BPA fiber cut. It is apparently to do with some towers on an island in the Columbia river. I heard ETR was evening on Saturday. It sounded like a complicated repair. --TimH From eric-list at truenet.com Fri Sep 18 23:26:12 2015 From: eric-list at truenet.com (Eric Tykwinski) Date: Fri, 18 Sep 2015 19:26:12 -0400 Subject: Sign-On Letter to the Court in the FCC's Net Neutrality Case In-Reply-To: <20150918222327.GA24664@gsp.org> References: <20150912194545.65752.qmail@ary.lan> <55F90147.3020703@nic-naa.net> <55FADC4A.7010607@gmail.com> <55FADF40.4040705@meetinghouse.net> <20150918222327.GA24664@gsp.org> Message-ID: <3C6ABCD2-4F14-4818-8DF5-FCA3F54391D3@truenet.com> I signed on as well, but why didn?t the EFF at least publish the letter to the list? It was well written and laid out, even for politicians. Personally, I would have included some VoIP stuff that?s well known about, but "que sera, sera?. The main point being if you want people to sign up, show your cards and let people make the business decision whether that will effect their present situation first. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 > On Sep 18, 2015, at 6:23 PM, Rich Kulawiec wrote: > > On Thu, Sep 17, 2015 at 11:41:52AM -0400, Miles Fidelman wrote: >> Me too. Be sure to actually read the Amicus brief - it's incredibly >> well written and informative. > > I've signed on as well and strongly concur with Miles' recommendation. > > ---rsk From tom at ninjabadger.net Sat Sep 19 14:12:58 2015 From: tom at ninjabadger.net (Tom Hill) Date: Sat, 19 Sep 2015 15:12:58 +0100 Subject: Transit Options in the UK? In-Reply-To: References: <041401d0f18a$67df4250$379dc6f0$@giesen.me> Message-ID: <55FD6D6A.4040608@ninjabadger.net> Hi Gary, On 18/09/15 09:29, James Bensley wrote: > For full transit all the big carriers are in most of the major UK PoPs > (it would be handy if you mentioned the PoP name!). Just look on each > carriers website and check their PoP list. As per James, you did forget to point out where the PoP is. The location matters, as - contrary to what James says - if you're not in London you can quite often find some large gaps in 'big carrier' availability. (Actually, there are plenty of places in London where that is true as well). As for more direct answers: > - Good peering/reachability to other networks (I've already started perusing > the LINX peer list) I'd suggest that your client just peer directly, if it's available in the PoP. :) > - Decent BGP community set (at a minimum RTBH and local pref, obviously the > richer the better) > > - v6 support You should be good here with most of the bigger operators. It's mostly the smaller tier-2s that don't tend to get these right. Easy to avoid. > - Own the last mile a bonus This is trickier in the UK. There aren't *that* many people with their own fibre in the ground; quite often it's all, or partially, leased DF. Most with their own fibre _and_ sizeable transit business, are the big telcos (whom I'd avoid buying from, personally). On the other hand, this does not seem to be an issue for a well-built/planned network. A few bits of advice: - Prices are changing a lot, so don't sign contracts >12 months - Put 3356 in that list of 'big telcos'* * Very little seems to be going well for them in the UK lately. More details on location & commitments, and whether you wish to peer directly, will probably help narrow down recommendations. :) Regards, -- Tom From frnkblk at iname.com Sat Sep 19 19:54:24 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 19 Sep 2015 14:54:24 -0500 Subject: DDoS auto-mitigation best practices (for eyeball networks) Message-ID: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> Could the community share some DDoS auto-mitigation best practices for eyeball networks, where the target is a residential broadband subscriber? I'm not asking so much about the customer communication as much as configuration of any thresholds or settings, such as: - minimum traffic volume before responding (for volumetric attacks) - minimum time to wait before responding - filter percentage: 100% of the traffic toward target (or if volumetric, just a certain percentage)? - time before mitigation is automatically removed - and if the attack should recur shortly thereafter, time to respond and remove again - use of an upstream provider(s) mitigation services versus one's own mitigation tools - network placement of mitigation (presumably upstream as possible) - and anything else I ask about best practice for broadband subscribers on eyeball networks because it's different environment than data center and hosting environments or when one's network is being used to DDoS a target. Regards, Frank From mehmet at akcin.net Sat Sep 19 20:09:47 2015 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 19 Sep 2015 13:09:47 -0700 Subject: DDoS auto-mitigation best practices (for eyeball networks) In-Reply-To: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> References: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> Message-ID: <72125B0F-AEC8-48BF-A844-6A2FA49880BB@akcin.net> How does he/she become target? How does IP address gets exposed? I guess simplest way is to reboot modem and hope to get new ip (or call n request) Mehmet > On Sep 19, 2015, at 12:54, Frank Bulk wrote: > > Could the community share some DDoS auto-mitigation best practices for > eyeball networks, where the target is a residential broadband subscriber? > I'm not asking so much about the customer communication as much as > configuration of any thresholds or settings, such as: > - minimum traffic volume before responding (for volumetric attacks) > - minimum time to wait before responding > - filter percentage: 100% of the traffic toward target (or if volumetric, > just a certain percentage)? > - time before mitigation is automatically removed > - and if the attack should recur shortly thereafter, time to respond and > remove again > - use of an upstream provider(s) mitigation services versus one's own > mitigation tools > - network placement of mitigation (presumably upstream as possible) > - and anything else > > I ask about best practice for broadband subscribers on eyeball networks > because it's different environment than data center and hosting environments > or when one's network is being used to DDoS a target. > > Regards, > > Frank > From nanog at ics-il.net Sat Sep 19 20:51:51 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 19 Sep 2015 15:51:51 -0500 (CDT) Subject: DDoS auto-mitigation best practices (for eyeball networks) In-Reply-To: <72125B0F-AEC8-48BF-A844-6A2FA49880BB@akcin.net> Message-ID: <2105844026.121122.1442695966528.JavaMail.mhammett@ThunderFuck> Often it's an argument in some sort of online game or a poor loser. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mehmet Akcin" To: "Frank Bulk" Cc: nanog at nanog.org Sent: Saturday, September 19, 2015 3:09:47 PM Subject: Re: DDoS auto-mitigation best practices (for eyeball networks) How does he/she become target? How does IP address gets exposed? I guess simplest way is to reboot modem and hope to get new ip (or call n request) Mehmet > On Sep 19, 2015, at 12:54, Frank Bulk wrote: > > Could the community share some DDoS auto-mitigation best practices for > eyeball networks, where the target is a residential broadband subscriber? > I'm not asking so much about the customer communication as much as > configuration of any thresholds or settings, such as: > - minimum traffic volume before responding (for volumetric attacks) > - minimum time to wait before responding > - filter percentage: 100% of the traffic toward target (or if volumetric, > just a certain percentage)? > - time before mitigation is automatically removed > - and if the attack should recur shortly thereafter, time to respond and > remove again > - use of an upstream provider(s) mitigation services versus one's own > mitigation tools > - network placement of mitigation (presumably upstream as possible) > - and anything else > > I ask about best practice for broadband subscribers on eyeball networks > because it's different environment than data center and hosting environments > or when one's network is being used to DDoS a target. > > Regards, > > Frank > From doon.bulk at inoc.net Sat Sep 19 21:15:23 2015 From: doon.bulk at inoc.net (Patrick Muldoon) Date: Sat, 19 Sep 2015 17:15:23 -0400 Subject: DDoS auto-mitigation best practices (for eyeball networks) In-Reply-To: <72125B0F-AEC8-48BF-A844-6A2FA49880BB@akcin.net> References: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> <72125B0F-AEC8-48BF-A844-6A2FA49880BB@akcin.net> Message-ID: <49CF5CAA-ECD8-4C7F-9E1D-BED1F4F5EA27@inoc.net> > On Sep 19, 2015, at 4:09 PM, Mehmet Akcin wrote: > > How does he/she become target? How does IP address gets exposed? Call of Duty. No I am not kidding. The majority of the DDOS attacks we see targeted at Residential customers, are because said Customer was running their mouth / being an A**Hole in Call of Duty, and they pissed off someone with access to a botnet, etc.. The other is people gambling for real money and they start to win, so someone else knocks they offline so they won't lose. As for how they get their IP, not really sure as I suck as those games, but I've heard it is pretty trivial to do so. -Patrick From randy_94108 at yahoo.com Sun Sep 20 00:44:21 2015 From: randy_94108 at yahoo.com (Randy) Date: Sun, 20 Sep 2015 00:44:21 +0000 (UTC) Subject: DDoS auto-mitigation best practices (for eyeball networks) In-Reply-To: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> References: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> Message-ID: <1400068426.320258.1442709861720.JavaMail.yahoo@mail.yahoo.com> ----- Original Message ----- From: Frank Bulk To: nanog at nanog.org Cc: Sent: Saturday, September 19, 2015 12:54 PM Subject: DDoS auto-mitigation best practices (for eyeball networks) Could the community share some DDoS auto-mitigation best practices for eyeball networks, where the target is a residential broadband subscriber? I'm not asking so much about the customer communication as much as configuration of any thresholds or settings, such as: - minimum traffic volume before responding (for volumetric attacks) - minimum time to wait before responding - filter percentage: 100% of the traffic toward target (or if volumetric, just a certain percentage)? - time before mitigation is automatically removed - and if the attack should recur shortly thereafter, time to respond and remove again - use of an upstream provider(s) mitigation services versus one's own mitigation tools - network placement of mitigation (presumably upstream as possible) - and anything else I ask about best practice for broadband subscribers on eyeball networks because it's different environment than data center and hosting environments or when one's network is being used to DDoS a target. Regards, Frank Frank, If you figure out a way to protect residential-BB-clients, I would love to know! Regards, ./Randy From rdobbins at arbor.net Sun Sep 20 01:22:22 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 20 Sep 2015 08:22:22 +0700 Subject: DDoS auto-mitigation best practices (for eyeball networks) In-Reply-To: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> References: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> Message-ID: <10B538CD-B602-411C-BD71-8C9DB93A4242@arbor.net> On 20 Sep 2015, at 2:54, Frank Bulk wrote: > - minimum traffic volume before responding (for volumetric attacks) > - minimum time to wait before responding These are situationally-specific. > - filter percentage: 100% of the traffic toward target (or if > volumetric, > just a certain percentage)? If one has flowspec capabilities, mitigating only the attack traffic is preferred, if at all possible. If one only has S/RTBH, blocking the attack sources is preferred, if at all possible. Some operators resort to D/RTBH (thereby completing the DDoS) because they don't have layer-4 granularity in their mitigation tools (e.g., flowspec), or even if they have S/RTBH, the number of sources can be daunting in relation to their hardware capabilities. I'm not a big fan of this approach, as it completes the DDoS on the victim, but understand why some operators do this. > - time before mitigation is automatically removed This is situationally-specific. > - and if the attack should recur shortly thereafter, time to respond > and remove again This is situationally-specific. Some operators keep track of the frequency, and will 'fire' customers who're attack-magnets. I'm not a big fan of this approach, either, but understand why some operators do it (simple economics). > - use of an upstream provider(s) mitigation services versus one's own > mitigation tools This is situationally-specific. Some operators take advantage of these services when on-offer. > - network placement of mitigation (presumably upstream as possible) Peering/transit edges, generally. Some do it on upstream networks which provide such a service, as you indicated. > - and anything else There's no one-size-fits-all answer for most of these questions; your capabilities and tolerances may be very different from those of another operator. Network infrastructure-based techniques, such as S/RTBH, D/RTBH, and flowspec are generally what's used in these situations, in addition to QoS (see below). A great deal (not all) of the operationally-significant attacks against individual broadband users these days seem to be UDP reflection/amplification attacks. Policing non-timesync ntp at one's edges via QoS is pretty straightforward and minimizes the risk of overblocking, as there's a packet-size to use as an additional classifier beyond protocol/port. Some operators, as Jared Mauch has mentioned here previously, are policing common UDP port-pairs used in other flavors of UDP reflection/amplification attacks at their edges, as well (Jared is pleased with the results on his network). It might be possible to get this sort of thing instituted on one's upstreams. ----------------------------------- Roland Dobbins From florin at andrei.myip.org Sun Sep 20 03:59:25 2015 From: florin at andrei.myip.org (Florin Andrei) Date: Sat, 19 Sep 2015 20:59:25 -0700 Subject: high latency on West =?UTF-8?Q?Coast=3F?= In-Reply-To: <6yt256n9nt6270b9br1mhgde.1442613471371@email.android.com> References: <6yt256n9nt6270b9br1mhgde.1442613471371@email.android.com> Message-ID: <3580ab5bff10273d47d59f1dd36ab6c6@andrei.myip.org> On 2015-09-18 14:57, andrew wrote: > L3 fiber cut . Is this related to the wave of deliberate fiber cuts on the West Coast this year? -- Florin Andrei http://florin.myip.org/ From nanogml at Mail.DDoS-Mitigator.net Sun Sep 20 18:55:16 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Sun, 20 Sep 2015 11:55:16 -0700 Subject: DDoS auto-mitigation best practices (for eyeball networks) In-Reply-To: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> References: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> Message-ID: <20150920185516.GA22262@Mail.DDoS-Mitigator.net> On 09/19/15 at 02:54pm, Frank Bulk wrote: > Could the community share some DDoS auto-mitigation best practices for > eyeball networks, where the target is a residential broadband subscriber? o kie dough kie > I'm not asking so much about the customer communication as much as > configuration of any thresholds or settings, such as: > - minimum traffic volume before responding (for volumetric attacks) i prefer zero tolerance ... i tarpit all incoming tco-based attacks and probes that was not allowed incoming tcp traffic to port 25 or port 80 or port blah example iptables rules ... linux and iptables + tarpits is free # IPtables-BlackList.net/Howto - ingress filters - allow established - check for blacklist - limit udp and icmp reply ( tough problem to solve ) - allow to port 80 ( keep webserver separate from dns, smtp, etc ) - tarpit all new tcp incoming connections - drop all other new incoming connections - there is no need log millions of ddos attack pacekets per second unless you want to fill up your disk which helps the ddos attacks to be a successful attack - for icmp and udp ... you will need your ISP to help block it limiting incoming icmp/udp is sorta pointless since those packets already come down the wire however, you still do NOT want to respond to those packets either so you will have to limit to just a handful per second, little more per hour, and higher limit per day for icmp ... turn off broadcast ping responses on all devices for udp ... make sure the apps are properly configured dns, snmp, ntp, nfs, x11, etc uses udp your dns servers might need to be accessible from outside all other udp-based servers should be internal only - to protect against arp-based attacks .... build/patch/configure your hardware/routers/switches properly - install monitoring tools to watch for whatever you're paranoid about - man-in-the-middle .. trivial to detect and prevent - sniffers ( hard to detect ) > - minimum time to wait before responding zero wait ... > - filter percentage: 100% of the traffic toward target (or if volumetric, > just a certain percentage)? you will always, 100% fail volumetric attacks > - time before mitigation is automatically removed you can have iptables remove a particular ddos attacker automatically or manually i prefer manually so i can see what it's doing > - and if the attack should recur shortly thereafter, time to respond and > remove again zero wait time .. zero tolerance per example iptables rules above > - use of an upstream provider(s) mitigation services versus one's own > mitigation tools i haven't found too many ISP willing to allow customers to put a customer firewall in their facility just before it comes down to the wire to customers bldg this is required if customers want to properly mitigate icmp-based and udp-based ddos attacks > - network placement of mitigation (presumably upstream as possible) > - and anything else mitigation solutions should be a gateway firewall and host-based mitigation if you can install another firewall at the ISP, thats good too and you still need a gateway firewall and the host based firewall > I ask about best practice for broadband subscribers on eyeball networks > because it's different environment than data center and hosting environments > or when one's network is being used to DDoS a target. add corp environment, hospitality environment, govt environment, etc etc to the list too - free wifi, hotel based wifi or hardwire is probably the easiest way to send the unsuspecting victim home with a trojan that will phone home ( the attacker ) when the victim plugs the cracked box into the secure corp network nah.... ddos attacks are ddos attacks ... usually harmless ... it probably doesn't matter to the attackers what they're attacking you are constantly under 24x7x365 low level ddos attacks if you are being targeted by somebody that wants to get you, you'd have a problem if they're better at attacking than you are at defending your servers ... they're done if they have a bigger budget to pay for all the necessary bandwidth needed to take your servers offline - if you know who they are, call the ISP and the cops ----- other "basic best practices" - have a good security policy ... even if just for yourself hide the laptop in your trunk using a brown bag and NOT an obvious laptop bag - always use encrypted services... never clear text - use ssh, openssl, smtps, pop3s, imap3s - dozens of other best practices security rules - always have a incremental daily backup that is kept for months - always have a hot swap backup just in case .... etc .. etc ... ---- you should also keep track of who is attacking your servers so that law enforcement can followup if needed you should also know which src address might be spoofed and which ddos attackers are using their real src ip tracing the originating source of spoofed address requires the help of the various upstream ISP magic pixie dust alvin # # DDoS-Mitigator.com # IPtables-BlackList.net/Howto # From jason at lixfeld.ca Sun Sep 20 19:23:39 2015 From: jason at lixfeld.ca (Jason Lixfeld) Date: Sun, 20 Sep 2015 15:23:39 -0400 Subject: Segment Routing for L2VPN? Message-ID: <43861AA9-C97C-4434-BE61-86125D60AC01@lixfeld.ca> Hello! I've been doing some reading recently on Segment Routing. By all accounts, it seems that the (only?) implementation for SR supports L3VPN. Am I dumb and just missing the L2VPN bits, or is L3VPN simply the extent of the first generation? Sent from my iPhone From mohan.nanduri at gmail.com Sun Sep 20 19:59:34 2015 From: mohan.nanduri at gmail.com (Mohan Nanduri) Date: Sun, 20 Sep 2015 15:59:34 -0400 Subject: Segment Routing for L2VPN? In-Reply-To: <43861AA9-C97C-4434-BE61-86125D60AC01@lixfeld.ca> References: <43861AA9-C97C-4434-BE61-86125D60AC01@lixfeld.ca> Message-ID: No, it works with L2VPNs also. Outer label is going to be SR label and inner label is your L2VPN label. Cheers, -Mohan On Sun, Sep 20, 2015 at 3:23 PM, Jason Lixfeld wrote: > Hello! > > I've been doing some reading recently on Segment Routing. By all accounts, it seems that the (only?) implementation for SR supports L3VPN. Am I dumb and just missing the L2VPN bits, or is L3VPN simply the extent of the first generation? > > Sent from my iPhone From frnkblk at iname.com Sun Sep 20 21:21:43 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Sun, 20 Sep 2015 16:21:43 -0500 Subject: SMS Gateway In-Reply-To: <361E14917FBECC43A4359C9B977FC4DB11F31357@MBX2.aquafinad.aquafin.be> References: <49EE1A35457387418410F97564A3752B01368E7DE4@MSG6.westman.int> <361E14917FBECC43A4359C9B977FC4DB11F31357@MBX2.aquafinad.aquafin.be> Message-ID: <004401d0f3ea$5aa935c0$0ffba140$@iname.com> With earlier releases I did see our unit "lock up", in the sense they wouldn't send messages. A reboot resolved those issues. The last two or three releases from Multitech for iSMS have been solid, none of those issues anymore. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Nauwelaerts Sent: Tuesday, September 15, 2015 3:10 AM To: Graham Johnston ; 'nanog at nanog.org' Subject: RE: SMS Gateway The multitech multimodems I run seem to like rebooting an awful lot, they do it at least daily. At another position I did like the SMS FoxBox ( http://www.smsfoxbox.it/ ), which had a simple http put command (amongst other interfaces) which allowed you to send text messages. The do seem to have gone up in price a bit since 2008 however, but they did never fail on me over the 6years they were in service (sample size was 2 units, so not the best indicator). // nick -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Graham Johnston Sent: Monday, September 14, 2015 16:54 To: 'nanog at nanog.org' Subject: SMS Gateway Today we use a product from MultiTech Systems call MultiModem iSMS to send SMS text messages from our monitoring system to our on call staff. This is a 2G product and we need to replace it soon. I know there are more generic cellular modems that can do texting if you are willing to put in the effort, the product we use currently though has a simple HTTP based API specifically to send SMS. Is anybody out there using something similar that can work on 3G or 4G networks? ________________________________ Volg Aquafin op Facebook | Twitter | YouTube | LinkedIN Disclaimer: zie www.aquafin.be P Denk aan het milieu. Druk deze mail niet onnodig af. [http://www.chap-eau.be/chapeau-banner.jpg] From hammani.b at gmail.com Mon Sep 21 01:01:48 2015 From: hammani.b at gmail.com (Hammani Benaouich) Date: Sun, 20 Sep 2015 21:01:48 -0400 Subject: Sign-On Letter to the Court in the FCC's Net Neutrality Case In-Reply-To: <20150918222327.GA24664@gsp.org> References: <20150912194545.65752.qmail@ary.lan> <55F90147.3020703@nic-naa.net> <55FADC4A.7010607@gmail.com> <55FADF40.4040705@meetinghouse.net> <20150918222327.GA24664@gsp.org> Message-ID: <20150921010148.6197336.52861.2959@gmail.com> Snbbb Sent?from?my?Porsche?Design?P?9982?smartphone?from?BlackBerry. ? Original Message ? From: Rich Kulawiec Sent: Friday, September 18, 2015 6:25 PM To: nanog at nanog.org Subject: Re: Sign-On Letter to the Court in the FCC's Net Neutrality Case On Thu, Sep 17, 2015 at 11:41:52AM -0400, Miles Fidelman wrote: > Me too. Be sure to actually read the Amicus brief - it's incredibly > well written and informative. I've signed on as well and strongly concur with Miles' recommendation. ---rsk From marco at paesani.it Mon Sep 21 08:32:58 2015 From: marco at paesani.it (Marco Paesani) Date: Mon, 21 Sep 2015 10:32:58 +0200 Subject: Skype off line ?? Message-ID: Hi, do you have sone news about it ? Best regards, -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From larrysheldon at cox.net Mon Sep 21 08:37:04 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 21 Sep 2015 03:37:04 -0500 Subject: Skype off line ?? In-Reply-To: References: Message-ID: <55FFC1B0.8030201@cox.net> On 9/21/2015 03:32, Marco Paesani wrote: > Hi, > do you have some news about it ? > Best regards, > I get a log-in screen. Do you ha a fact to go with your question? -- sed quis custodiet ipsos custodes? (Juvenal) From aftab.siddiqui at gmail.com Mon Sep 21 08:37:57 2015 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Mon, 21 Sep 2015 08:37:57 +0000 Subject: Skype off line ?? In-Reply-To: References: Message-ID: Yes, its offline. http://heartbeat.skype.com/ Skype presence issues By Leonas Sendrauskas on September 21, 2015. Some of you may experience problems with Skype presence and may not see online status. We apologize for the inconvenience and will post an update here, when the gets resolved! On Mon, 21 Sep 2015 at 18:35 Marco Paesani wrote: > Hi, > do you have sone news about it ? > Best regards, > > -- > > Marco Paesani > MPAE Srl > > Skype: mpaesani > Mobile: +39 348 6019349 > Success depends on the right choice ! > Email: marco at paesani.it > -- Best Wishes, Aftab A. Siddiqui From larrysheldon at cox.net Mon Sep 21 09:42:10 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 21 Sep 2015 04:42:10 -0500 Subject: Skype off line ?? In-Reply-To: References: Message-ID: <55FFD0F2.5040509@cox.net> On 9/21/2015 03:37, Larry Sheldon wrote: > On 9/21/2015 03:32, Marco Paesani wrote: >> Hi, >> do you have some news about it ? >> Best regards, >> > I get a log-in screen. > > Do you have a fact to go with your question? Turns out the log-in screen is the last last sign or life--submitting username and password gets you a never-ending throbber. How weird. -- sed quis custodiet ipsos custodes? (Juvenal) From maxtul at netassist.ua Mon Sep 21 10:26:38 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 21 Sep 2015 13:26:38 +0300 Subject: Skype off line ?? In-Reply-To: References: Message-ID: <55FFDB5E.4060509@netassist.ua> For me yes, it is down for several hours. BTW, is there any Jabber/XMPP client with similar usability? I need just scroll up to view all history and one click to join someone to multiuser conference in fact. On 21.09.15 11:32, Marco Paesani wrote: > Hi, > do you have sone news about it ? > Best regards, > From email at edylie.net Mon Sep 21 10:30:43 2015 From: email at edylie.net (Pui Edylie) Date: Mon, 21 Sep 2015 18:30:43 +0800 Subject: Skype off line ?? In-Reply-To: <55FFDB5E.4060509@netassist.ua> References: <55FFDB5E.4060509@netassist.ua> Message-ID: Reporting the same from Singapore Sent from TypeMail On Sep 21, 2015, 18:27, at 18:27, Max Tulyev wrote: >For me yes, it is down for several hours. > >BTW, is there any Jabber/XMPP client with similar usability? > >I need just scroll up to view all history and one click to join someone >to multiuser conference in fact. > >On 21.09.15 11:32, Marco Paesani wrote: >> Hi, >> do you have sone news about it ? >> Best regards, >> From alejandroacostaalamo at gmail.com Mon Sep 21 10:35:52 2015 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Mon, 21 Sep 2015 06:05:52 -0430 Subject: Skype off line ?? In-Reply-To: References: <55FFDB5E.4060509@netassist.ua> Message-ID: <55FFDD88.6020009@gmail.com> The same from Spain El 9/21/2015 a las 6:00 AM, Pui Edylie escribi?: > Reporting the same from Singapore > > Sent from TypeMail > > > > On Sep 21, 2015, 18:27, at 18:27, Max Tulyev wrote: >> For me yes, it is down for several hours. >> >> BTW, is there any Jabber/XMPP client with similar usability? >> >> I need just scroll up to view all history and one click to join someone >> to multiuser conference in fact. >> >> On 21.09.15 11:32, Marco Paesani wrote: >>> Hi, >>> do you have sone news about it ? >>> Best regards, >>> From wolfgang.tremmel at de-cix.net Mon Sep 21 10:38:55 2015 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Mon, 21 Sep 2015 10:38:55 +0000 Subject: Skype off line ?? In-Reply-To: <55FFDD88.6020009@gmail.com> References: <55FFDB5E.4060509@netassist.ua> <55FFDD88.6020009@gmail.com> Message-ID: <4E0FC06B-F3E8-407C-B903-DD24F7A2D273@de-cix.net> > On 21.09.2015, at 12:35, Alejandro Acosta wrote: > > The same from Spain Desktop client login not possible (Germany) Web client works fine Wolfgang From mkaipov at outlook.com Mon Sep 21 10:47:04 2015 From: mkaipov at outlook.com (Murat Kaipov) Date: Mon, 21 Sep 2015 13:47:04 +0300 Subject: Skype off line ?? In-Reply-To: <55FFDB5E.4060509@netassist.ua> References: <55FFDB5E.4060509@netassist.ua> Message-ID: You ca use Google Hangouts, but I don't know about multiuser conference. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev Sent: Monday, September 21, 2015 1:27 PM To: nanog at nanog.org Subject: Re: Skype off line ?? For me yes, it is down for several hours. BTW, is there any Jabber/XMPP client with similar usability? I need just scroll up to view all history and one click to join someone to multiuser conference in fact. On 21.09.15 11:32, Marco Paesani wrote: > Hi, > do you have sone news about it ? > Best regards, > From maxtul at netassist.ua Mon Sep 21 10:58:21 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 21 Sep 2015 13:58:21 +0300 Subject: Skype off line ?? In-Reply-To: References: <55FFDB5E.4060509@netassist.ua> Message-ID: <55FFE2CD.6040807@netassist.ua> Google hangouts and jit.si are services, not a client of open protocol. Feel the difference. On 21.09.15 13:47, Murat Kaipov wrote: > > You ca use Google Hangouts, but I don't know about multiuser conference. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev > Sent: Monday, September 21, 2015 1:27 PM > To: nanog at nanog.org > Subject: Re: Skype off line ?? > > For me yes, it is down for several hours. > > BTW, is there any Jabber/XMPP client with similar usability? > > I need just scroll up to view all history and one click to join someone to multiuser conference in fact. > > On 21.09.15 11:32, Marco Paesani wrote: >> Hi, >> do you have sone news about it ? >> Best regards, >> > > From zaphodb at zaphods.net Mon Sep 21 11:21:38 2015 From: zaphodb at zaphods.net (zaphodb at zaphods.net) Date: Mon, 21 Sep 2015 13:21:38 +0200 Subject: Skype off line ?? In-Reply-To: <55FFE2CD.6040807@netassist.ua> References: <55FFDB5E.4060509@netassist.ua> <55FFE2CD.6040807@netassist.ua> Message-ID: <08970bd1ec467b2cf0282d19d5a0e97c@zaphods.net> On 2015-09-21 12:58, Max Tulyev wrote: > Google hangouts and jit.si are services, not a client of open protocol. > > Feel the difference. Well you can set a server wide default for Jabber/XMPP MUC chats at least with ejabberd. https://www.process-one.net/docs/ejabberd/guide_en.html#htoc50 "history_size: Size A small history of the current discussion is sent to users when they enter the room. With this option you can define the number of history messages to keep and send to users joining the room. The value is an integer. Setting the value to 0 disables the history feature and, as a result, nothing is kept in memory. The default value is 20. This value is global and thus affects all rooms on the service." Thats not quite the same though as you get with Skype where i think the history gets synced in a bi-directional fashion. kind regards, Stefan > On 21.09.15 13:47, Murat Kaipov wrote: >> >> You ca use Google Hangouts, but I don't know about multiuser >> conference. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev >> Sent: Monday, September 21, 2015 1:27 PM >> To: nanog at nanog.org >> Subject: Re: Skype off line ?? >> >> For me yes, it is down for several hours. >> >> BTW, is there any Jabber/XMPP client with similar usability? >> >> I need just scroll up to view all history and one click to join >> someone to multiuser conference in fact. >> >> On 21.09.15 11:32, Marco Paesani wrote: >>> Hi, >>> do you have sone news about it ? >>> Best regards, >>> >> >> From maxtul at netassist.ua Mon Sep 21 11:32:44 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 21 Sep 2015 14:32:44 +0300 Subject: Skype off line ?? In-Reply-To: <08970bd1ec467b2cf0282d19d5a0e97c@zaphods.net> References: <55FFDB5E.4060509@netassist.ua> <55FFE2CD.6040807@netassist.ua> <08970bd1ec467b2cf0282d19d5a0e97c@zaphods.net> Message-ID: <55FFEADC.3040109@netassist.ua> This is the question, yes. But if it will be possible just to scroll up all the history stored by client - it will be great! Everything I saw was history accessible through tricky hidden (as user said) menu, not by "just scroll up in the window". On 21.09.15 14:21, zaphodb at zaphods.net wrote: > On 2015-09-21 12:58, Max Tulyev wrote: >> Google hangouts and jit.si are services, not a client of open protocol. >> >> Feel the difference. > > Well you can set a server wide default for Jabber/XMPP MUC chats at > least with ejabberd. > https://www.process-one.net/docs/ejabberd/guide_en.html#htoc50 > "history_size: Size > A small history of the current discussion is sent to users when they > enter the room. With this option you can define the number of history > messages to keep and send to users joining the room. The value is an > integer. Setting the value to 0 disables the history feature and, as a > result, nothing is kept in memory. The default value is 20. This value > is global and thus affects all rooms on the service." > > Thats not quite the same though as you get with Skype where i think the > history gets synced in a bi-directional fashion. > > kind regards, > > Stefan > > >> On 21.09.15 13:47, Murat Kaipov wrote: >>> >>> You ca use Google Hangouts, but I don't know about multiuser >>> conference. >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev >>> Sent: Monday, September 21, 2015 1:27 PM >>> To: nanog at nanog.org >>> Subject: Re: Skype off line ?? >>> >>> For me yes, it is down for several hours. >>> >>> BTW, is there any Jabber/XMPP client with similar usability? >>> >>> I need just scroll up to view all history and one click to join >>> someone to multiuser conference in fact. >>> >>> On 21.09.15 11:32, Marco Paesani wrote: >>>> Hi, >>>> do you have sone news about it ? >>>> Best regards, >>>> >>> >>> > > From kauer at biplane.com.au Mon Sep 21 11:42:11 2015 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 21 Sep 2015 21:42:11 +1000 Subject: Skype off line ?? In-Reply-To: References: Message-ID: <1442835731.11548.37.camel@karl> On Mon, 2015-09-21 at 10:32 +0200, Marco Paesani wrote: > do you have some news about it ? There's a service status article on www.skype.com: Regards, K. Issues with Skype status and calling By My status Leonas Sendrauskas on September 21, 2015. Updated 11:00 UTC We have detected an issue that is affecting Skype in a number of ways. If you're signed in to Skype, you will not be able to change your status and your contacts will all show as offline even if they are online. As a result, you won?t be able to start Skype calls to them.. A small number of messages to group chats are not being delivered, but in most cases you can still instant message your contacts.. If you aren?t signed in to Skype, you may be experiencing difficulty when attempting to sign in. Any changes to your Skype account such as your Credit balance or your profile details might take a little while to be displayed.. You may also have difficulty loading web pages on the Skype Community. For that reason, please check back here for future updates.. We're doing everything we can to fix this issue and hope to have another update for you soon. Thank you for your patience as we work to get this incident resolved. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 frnkblk at iname.com Mon Sep 21 12:00:14 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Mon, 21 Sep 2015 07:00:14 -0500 Subject: DDoS auto-mitigation best practices (for eyeball networks) In-Reply-To: <72125B0F-AEC8-48BF-A844-6A2FA49880BB@akcin.net> References: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> <72125B0F-AEC8-48BF-A844-6A2FA49880BB@akcin.net> Message-ID: <007901d0f465$1545e200$3fd1a600$@iname.com> 99% of the attacks we see are gaming related -- somehow the other players know the IP and then attack our customer for an advantage in the game, or retribution. Most DHCP servers (correctly) give the same IP address if the CPE is rebooted. Ours are one of those. =) Frank -----Original Message----- From: Mehmet Akcin [mailto:mehmet at akcin.net] Sent: Saturday, September 19, 2015 3:10 PM To: Frank Bulk Cc: nanog at nanog.org Subject: Re: DDoS auto-mitigation best practices (for eyeball networks) How does he/she become target? How does IP address gets exposed? I guess simplest way is to reboot modem and hope to get new ip (or call n request) Mehmet > On Sep 19, 2015, at 12:54, Frank Bulk wrote: > > Could the community share some DDoS auto-mitigation best practices for > eyeball networks, where the target is a residential broadband subscriber? > I'm not asking so much about the customer communication as much as > configuration of any thresholds or settings, such as: > - minimum traffic volume before responding (for volumetric attacks) > - minimum time to wait before responding > - filter percentage: 100% of the traffic toward target (or if volumetric, > just a certain percentage)? > - time before mitigation is automatically removed > - and if the attack should recur shortly thereafter, time to respond and > remove again > - use of an upstream provider(s) mitigation services versus one's own > mitigation tools > - network placement of mitigation (presumably upstream as possible) > - and anything else > > I ask about best practice for broadband subscribers on eyeball networks > because it's different environment than data center and hosting environments > or when one's network is being used to DDoS a target. > > Regards, > > Frank > From Rod.Beck at hibernianetworks.com Mon Sep 21 15:02:23 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Mon, 21 Sep 2015 15:02:23 +0000 Subject: Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN In-Reply-To: References: Message-ID: This might of interest to network engineers seeking to ensure their upstreams are physical diverse. http://pages.cs.wisc.edu/~pb/tubes_final.pdf Roderick Beck Sales - Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From jwbensley at gmail.com Mon Sep 21 16:01:05 2015 From: jwbensley at gmail.com (James Bensley) Date: Mon, 21 Sep 2015 17:01:05 +0100 Subject: Network Weathermap Message-ID: Hi All, Those of you that have a network weathermap similar to [1], what software are you using to edit the maps, the built in editor or something custom, 3rd party/external editor? Paid or free editor? I'm look for a better editing tool I can preferably use with that plugin (we are feeding it from Cacti). I'm open to both open source editors and paid commercial ones. Maybe you use a different weathermap tool, again I'd be interested to hear about that too. Doesn't have to be fed from Cacti/RRDs. Maybe I'm just pants at being visual [2] but I'm finding that making large maps isn't that well supported (the 'move' option on nodes and using the 'via' option on links becomes less accurate) and it's difficult to keep "busy" images clean (no grid, or snap-to-grid, scaling for higher res maps for larger networks etc). The main problem is keeping everything neat though. An example would be that we acquire a network, want to extend an existing map to incorporate the new network, I can?t select a bunch of objects and move them along all together I have to painstakingly move each node by hand, align each link and node by hand etc. Cheers, James. [1] http://network-weathermap.com/manual/0.97b/ [2] That is most likely the main problem here From dgamble at wavebroadband.com Mon Sep 21 16:18:53 2015 From: dgamble at wavebroadband.com (Dan Gamble) Date: Mon, 21 Sep 2015 16:18:53 +0000 Subject: Skype off line ?? In-Reply-To: References: Message-ID: <6F7029331BB71447931580A3317A7F9B0144F6E096@WDEXCHANGE102.headquarters.wavebroadband.gbl> http://heartbeat.skype.com says they've been intermittent since approx. 10:00UTC. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marco Paesani Sent: Monday, September 21, 2015 1:33 AM To: nanog Subject: Skype off line ?? Hi, do you have sone news about it ? Best regards, -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From marco at paesani.it Mon Sep 21 16:21:40 2015 From: marco at paesani.it (Marco Paesani) Date: Mon, 21 Sep 2015 18:21:40 +0200 Subject: Skype off line ?? In-Reply-To: <1442835731.11548.37.camel@karl> References: <1442835731.11548.37.camel@karl> Message-ID: No solution .... http://heartbeat.skype.com/2015/09/skype_presence_issues.html 2015-09-21 13:42 GMT+02:00 Karl Auer : > On Mon, 2015-09-21 at 10:32 +0200, Marco Paesani wrote: > > do you have some news about it ? > > There's a service status article on www.skype.com: > > Regards, K. > > Issues with Skype status and calling > By My status Leonas Sendrauskas on September 21, 2015. > Updated 11:00 UTC > > We have detected an issue that is affecting Skype in a number of ways. > > If you're signed in to Skype, you will not be able to change your status > and your contacts will all show as offline even if they are online. As a > result, you won?t be able to start Skype calls to them.. > > A small number of messages to group chats are not being delivered, but > in most cases you can still instant message your contacts.. > > If you aren?t signed in to Skype, you may be experiencing difficulty > when attempting to sign in. Any changes to your Skype account such as > your Credit balance or your profile details might take a little while to > be displayed.. > > You may also have difficulty loading web pages on the Skype Community. > For that reason, please check back here for future updates.. > > We're doing everything we can to fix this issue and hope to have another > update for you soon. Thank you for your patience as we work to get this > incident resolved. > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 > > > -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From ghenry at suretec.co.uk Mon Sep 21 10:45:10 2015 From: ghenry at suretec.co.uk (Gavin Henry) Date: Mon, 21 Sep 2015 11:45:10 +0100 Subject: Skype off line ?? In-Reply-To: <4E0FC06B-F3E8-407C-B903-DD24F7A2D273@de-cix.net> References: <55FFDB5E.4060509@netassist.ua> <55FFDD88.6020009@gmail.com> <4E0FC06B-F3E8-407C-B903-DD24F7A2D273@de-cix.net> Message-ID: >> The same from Spain Desktop client on Linux in UK too. -- Kind Regards, Gavin Henry. http://www.surevoip.co.uk OpenPGP (GPG/PGP) Public Key: 0x8CFBA8E6 - Import from hkp://subkeys.pgp.net or http://www.suretecgroup.com/0x8CFBA8E6.gpg From ghenry at surevoip.co.uk Mon Sep 21 10:46:08 2015 From: ghenry at surevoip.co.uk (Gavin Henry) Date: Mon, 21 Sep 2015 11:46:08 +0100 Subject: Skype off line ?? In-Reply-To: <4E0FC06B-F3E8-407C-B903-DD24F7A2D273@de-cix.net> References: <55FFDB5E.4060509@netassist.ua> <55FFDD88.6020009@gmail.com> <4E0FC06B-F3E8-407C-B903-DD24F7A2D273@de-cix.net> Message-ID: >> The same from Spain Desktop client on Linux in UK too. -- Kind Regards, Gavin Henry. http://www.surevoip.co.uk OpenPGP (GPG/PGP) Public Key: 0x8CFBA8E6 - Import from hkp://subkeys.pgp.net or http://www.suretecgroup.com/0x8CFBA8E6.gpg From ian.clark at dreamhost.com Mon Sep 21 16:24:47 2015 From: ian.clark at dreamhost.com (Ian Clark) Date: Mon, 21 Sep 2015 09:24:47 -0700 Subject: Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN In-Reply-To: References: Message-ID: Thanks for this. I've had physical diversity on my mind lately so this was helpful. On Mon, Sep 21, 2015 at 8:02 AM, Rod Beck wrote: > > This might of interest to network engineers seeking to ensure their > upstreams are physical diverse. > > http://pages.cs.wisc.edu/~pb/tubes_final.pdf From rol at witbe.net Mon Sep 21 17:25:03 2015 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Mon, 21 Sep 2015 19:25:03 +0200 Subject: Skype off line ?? In-Reply-To: References: <1442835731.11548.37.camel@karl> Message-ID: <20150921192503.1279ae62@riri.DEF.witbe.net> Hello, On Mon, 21 Sep 2015 18:21:40 +0200 Marco Paesani wrote: > No solution .... > http://heartbeat.skype.com/2015/09/skype_presence_issues.html Back for me (France): presence updated. Using Skype on Linux Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From morrowc.lists at gmail.com Mon Sep 21 17:26:17 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 21 Sep 2015 13:26:17 -0400 Subject: Skype off line ?? In-Reply-To: References: <55FFDB5E.4060509@netassist.ua> <55FFDD88.6020009@gmail.com> <4E0FC06B-F3E8-407C-B903-DD24F7A2D273@de-cix.net> Message-ID: On Mon, Sep 21, 2015 at 6:45 AM, Gavin Henry wrote: >>> The same from Spain > > Desktop client on Linux in UK too. sometimes it takes longer than expected to install all the necessary software and hardware taps by the nsa folks. From magicsata at gmail.com Mon Sep 21 17:37:12 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Mon, 21 Sep 2015 18:37:12 +0100 Subject: Skype off line ?? In-Reply-To: <20150921192503.1279ae62@riri.DEF.witbe.net> References: <1442835731.11548.37.camel@karl> <20150921192503.1279ae62@riri.DEF.witbe.net> Message-ID: Seems fine on mobile in the UK for me too. On 21 Sep 2015 18:36, "Paul Rolland (???????)" wrote: > Hello, > > On Mon, 21 Sep 2015 18:21:40 +0200 > Marco Paesani wrote: > > > No solution .... > > http://heartbeat.skype.com/2015/09/skype_presence_issues.html > > Back for me (France): presence updated. Using Skype on Linux > > Paul > From morrowc.lists at gmail.com Mon Sep 21 17:46:44 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 21 Sep 2015 13:46:44 -0400 Subject: Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN In-Reply-To: References: Message-ID: On Mon, Sep 21, 2015 at 12:24 PM, Ian Clark wrote: > Thanks for this. I've had physical diversity on my mind lately so this was > helpful. > > On Mon, Sep 21, 2015 at 8:02 AM, Rod Beck > wrote: > >> >> This might of interest to network engineers seeking to ensure their >> upstreams are physical diverse. >> >> http://pages.cs.wisc.edu/~pb/tubes_final.pdf paper from sales person of longhaul meets expectations (mostly joking... but still) From joly at punkcast.com Mon Sep 21 17:51:16 2015 From: joly at punkcast.com (Joly MacFie) Date: Mon, 21 Sep 2015 13:51:16 -0400 Subject: Skype off line ?? In-Reply-To: References: <1442835731.11548.37.camel@karl> <20150921192503.1279ae62@riri.DEF.witbe.net> Message-ID: I like http://zoom.us On Mon, Sep 21, 2015 at 1:37 PM, Alistair Mackenzie wrote: > Seems fine on mobile in the UK for me too. > On 21 Sep 2015 18:36, "Paul Rolland (???????)" wrote: > > > Hello, > > > > On Mon, 21 Sep 2015 18:21:40 +0200 > > Marco Paesani wrote: > > > > > No solution .... > > > http://heartbeat.skype.com/2015/09/skype_presence_issues.html > > > > Back for me (France): presence updated. Using Skype on Linux > > > > Paul > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From Rod.Beck at hibernianetworks.com Mon Sep 21 17:56:55 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Mon, 21 Sep 2015 17:56:55 +0000 Subject: Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN In-Reply-To: References: , Message-ID: Academics face a severe challenge in gaining access to fiber maps since the industry classifies virtually everything as proprietary. If you know a better paper, please post it. Roderick Beck Sales - Europe and the Americas Hibernia Networks This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From edward.lewis at icann.org Mon Sep 21 18:01:08 2015 From: edward.lewis at icann.org (Edward Lewis) Date: Mon, 21 Sep 2015 18:01:08 +0000 Subject: ICANN Public Comment period related to DNS Root Zone KSK closes October 5, 2015 Message-ID: (Apologies for duplicates of this) ICANN has an open Public Comment period on work relating to changing the Root Zone's DNSSEC Public KSK. The formal Public Comment process closes October 5, 2015. For further details, consult this URL: https://www.icann.org/public-comments/root-ksk-2015-08-06-en The title of the Public Comment period is: Design Team Review of Plan for DNS Root Zone KSK Change URLs of note, all of these are found from the URL above. The draft report in English: https://www.icann.org/en/system/files/files/root-zone-ksk-rollover-plan-dra ft-04aug15-en.pdf There are also versions of the report in 6 other languages. And the comments forum: http://forum.icann.org/lists/comments-root-ksk-06aug15/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4604 bytes Desc: not available URL: From Rod.Beck at hibernianetworks.com Mon Sep 21 18:12:33 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Mon, 21 Sep 2015 18:12:33 +0000 Subject: Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN In-Reply-To: References: , Message-ID: Undersea is a lot easier since cables pose safety threats. Any fishing organization will have maps of where the undersea cables are located. http://www.kis-orca.eu/map#.VgBHpJdS3IU Roderick Beck Sales - Europe and the Americas Hibernia Networks http://www.hibernianetworks.com This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From morrowc.lists at gmail.com Mon Sep 21 18:23:28 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 21 Sep 2015 14:23:28 -0400 Subject: Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN In-Reply-To: References: Message-ID: On Mon, Sep 21, 2015 at 1:56 PM, Rod Beck wrote: > Academics face a severe challenge in gaining access to fiber maps since the industry classifies virtually everything as proprietary. If you know a better paper, please post it. > I don't, which was part of why I was joking. > Roderick Beck > Sales - Europe and the Americas > Hibernia Networks > This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From sean at donelan.com Mon Sep 21 18:31:27 2015 From: sean at donelan.com (Sean Donelan) Date: Mon, 21 Sep 2015 14:31:27 -0400 (EDT) Subject: Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN In-Reply-To: References: Message-ID: On Mon, 21 Sep 2015, Christopher Morrow wrote: > On Mon, Sep 21, 2015 at 1:56 PM, Rod Beck wrote: >> Academics face a severe challenge in gaining access to fiber maps since the industry classifies virtually everything as proprietary. If you know a better paper, please post it. > > I don't, which was part of why I was joking. The ATIS final report on the National Diversity Assurance Iniative is decent. ATIS had access to proprietary carrier maps and personnel to check things on the ground. Unfortunately, the NDAI report seems to have disappeared down the Internet memory hole of dead links. http://www.atis.org/ndai It could be summarized as "Circuit route diversity sucks." The only thing worse than circuit route diversity were the processes to assure diverse circuit orders stayed diverse. From jeff.tantsura at ericsson.com Mon Sep 21 18:32:52 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Mon, 21 Sep 2015 18:32:52 +0000 Subject: Segment Routing for L2VPN? In-Reply-To: References: <43861AA9-C97C-4434-BE61-86125D60AC01@lixfeld.ca> Message-ID: Hi, In most well designed IP routing stacks the way to get to a labeled (tunneled) next hop is decoupled from a service, so if a service requires such next hop it is upto (usually RIB) to return one (best, multiple might exist) which would be used for forwarding. If it is a Segment Routed one so it will then be used. Cheers, Jeff -----Original Message----- From: Mohan Nanduri Date: Sunday, September 20, 2015 at 12:59 PM To: Jason Lixfeld Cc: "nanog at nanog.org" Subject: Re: Segment Routing for L2VPN? >No, it works with L2VPNs also. Outer label is going to be SR label and >inner label is your L2VPN label. > >Cheers, >-Mohan > > >On Sun, Sep 20, 2015 at 3:23 PM, Jason Lixfeld wrote: >> Hello! >> >> I've been doing some reading recently on Segment Routing. By all >>accounts, it seems that the (only?) implementation for SR supports >>L3VPN. Am I dumb and just missing the L2VPN bits, or is L3VPN simply >>the extent of the first generation? >> >> Sent from my iPhone From mathews at hawaii.edu Mon Sep 21 18:45:18 2015 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Mon, 21 Sep 2015 14:45:18 -0400 Subject: Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN In-Reply-To: References: Message-ID: <5600503E.6050604@hawaii.edu> On 9/21/2015 2:31 PM, Sean Donelan wrote: > The ATIS final report on the National Diversity Assurance Iniative is > decent. ATIS had access to proprietary carrier maps and personnel to > check things on the ground. Unfortunately, the NDAI report seems to > have disappeared down the Internet memory hole of dead links. > > http://www.atis.org/ndai > > It could be summarized as "Circuit route diversity sucks." The only > thing worse than circuit route diversity were the processes to assure > diverse circuit orders stayed diverse. Sean: FCC' Clearinghouse has a copy (2006) ... here: https://transition.fcc.gov/bureaus/pshs/docs/clearinghouse/ATIS_NDAI_Final_Report_2006.pdf From mkaipov at outlook.com Mon Sep 21 18:51:35 2015 From: mkaipov at outlook.com (Murat Kaipov) Date: Mon, 21 Sep 2015 21:51:35 +0300 Subject: cisco.com unavailable Message-ID: Hi folks! Is cisco.com unavailable or it is affected just for Rostelecom? From khelms at zcorum.com Mon Sep 21 18:55:37 2015 From: khelms at zcorum.com (Scott Helms) Date: Mon, 21 Sep 2015 14:55:37 -0400 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: I get there with no problem. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Mon, Sep 21, 2015 at 2:51 PM, Murat Kaipov wrote: > Hi folks! > Is cisco.com unavailable or it is affected just for > Rostelecom? From keiths at neilltech.com Mon Sep 21 18:55:57 2015 From: keiths at neilltech.com (Keith Stokes) Date: Mon, 21 Sep 2015 18:55:57 +0000 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: It works fine for me from Cox. --- Keith Stokes ________________________________________ From: NANOG on behalf of Murat Kaipov Sent: Monday, September 21, 2015 1:51 PM To: nanog at nanog.org Subject: cisco.com unavailable Hi folks! Is cisco.com unavailable or it is affected just for Rostelecom? From mkaipov at outlook.com Mon Sep 21 18:58:07 2015 From: mkaipov at outlook.com (Murat Kaipov) Date: Mon, 21 Sep 2015 21:58:07 +0300 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: Thanks to all of you. I think there issue with ISP?s connectivity in Russia. > 21 ????. 2015 ?., ? 21:55, Keith Stokes ???????(?): > > It works fine for me from Cox. > > > > --- > > Keith Stokes > > ________________________________________ > From: NANOG on behalf of Murat Kaipov > Sent: Monday, September 21, 2015 1:51 PM > To: nanog at nanog.org > Subject: cisco.com unavailable > > Hi folks! > Is cisco.com unavailable or it is affected just for Rostelecom? From josh at imaginenetworksllc.com Mon Sep 21 18:58:14 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 21 Sep 2015 14:58:14 -0400 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: Works for me via Frontier, south west Ohio. 1 1 ms 1 ms 1 ms 10.10.10.1 2 2 ms 2 ms 2 ms 192.149.254.1 3 7 ms 5 ms 6 ms 45.52.8.205 4 21 ms 20 ms 21 ms 74.40.5.58 5 19 ms 20 ms 20 ms 74.42.149.189 6 22 ms 20 ms 21 ms 74.40.4.138 7 20 ms 20 ms 21 ms 4.53.98.17 8 * * * Request timed out. 9 * * * Request timed out. 10 49 ms 49 ms 49 ms 4.30.74.46 11 145 ms 48 ms 50 ms 72.163.0.5 12 48 ms 47 ms 47 ms 72.163.0.178 13 48 ms 47 ms 48 ms 72.163.2.98 14 48 ms 48 ms 48 ms 72.163.4.161 Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Sep 21, 2015 at 2:51 PM, Murat Kaipov wrote: > Hi folks! > Is cisco.com unavailable or it is affected just for > Rostelecom? From dovid at telecurve.com Mon Sep 21 18:58:39 2015 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 21 Sep 2015 14:58:39 -0400 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: Working from Verizon FiOS [root at yosefh-OptiPlex-3020 ~]# wget cisco.com --2015-09-21 14:57:58-- http://cisco.com/ Resolving cisco.com (cisco.com)... 72.163.4.161, 2001:420:1101:1::a Connecting to cisco.com (cisco.com)|72.163.4.161|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://www.cisco.com/ [following] --2015-09-21 14:57:58-- http://www.cisco.com/ Resolving www.cisco.com (www.cisco.com)... 23.76.208.170, 2600:141b:4:288::90, 2600:141b:4:29b::90 Connecting to www.cisco.com (www.cisco.com)|23.76.208.170|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ???index.html??? [ <=> ] 52,865 --.-K/s in 0.01s 2015-09-21 14:57:58 (5.09 MB/s) - ???index.html??? saved [52865] [root at yosefh-OptiPlex-3020 ~]# On Mon, Sep 21, 2015 at 2:51 PM, Murat Kaipov wrote: > Hi folks! > Is cisco.com unavailable or it is affected just for > Rostelecom? From jeffshultz at wvi.com Mon Sep 21 18:58:46 2015 From: jeffshultz at wvi.com (Jeff Shultz) Date: Mon, 21 Sep 2015 11:58:46 -0700 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: I had no difficulty getting to it, but it appears that I probably got to an Akamai box: Non-authoritative answer: Name: e144.dscb.akamaiedge.net Addresses: 2600:1409:a:185::90 2600:1409:a:18b::90 23.200.208.170 Aliases: www.cisco.com www.cisco.com.akadns.net wwwds.cisco.com.edgekey.net wwwds.cisco.com.edgekey.net.globalredir.akadns.net Non-authoritative answer: Name: cisco.com Addresses: 2001:420:1101:1::a 72.163.4.161 On Mon, Sep 21, 2015 at 11:51 AM, Murat Kaipov wrote: > Hi folks! > Is cisco.com unavailable or it is affected just for Rostelecom? From hugo at slabnet.com Mon Sep 21 18:59:16 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 21 Sep 2015 11:59:16 -0700 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: <20150921185916.GP22440@bamboo.slabnet.com> >> Is cisco.com unavailable or it is affected just for >> Rostelecom? No problems here from either v4 or v6. -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From saper at saper.info Mon Sep 21 18:59:34 2015 From: saper at saper.info (Marcin Cieslak) Date: Mon, 21 Sep 2015 18:59:34 +0000 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: On Mon, 21 Sep 2015, Murat Kaipov wrote: > Hi folks! > Is cisco.com unavailable or it is affected just for Rostelecom? http://www.downforeveryoneorjustme.com/cisco.com > It's just you. http://cisco.com is up. ~Marcin From Rod.Beck at hibernianetworks.com Mon Sep 21 19:00:16 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Mon, 21 Sep 2015 19:00:16 +0000 Subject: cisco.com unavailable In-Reply-To: References: , Message-ID: Available in Hungary. Roderick Beck Sales - Europe and the Americas This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From hal at buzcom.net Mon Sep 21 19:01:18 2015 From: hal at buzcom.net (Hal Ponton) Date: Mon, 21 Sep 2015 20:01:18 +0100 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: <560053FE.7010201@buzcom.net> Works from the UK from a few ISP's -- -- Regards, Hal Ponton Senior Network Engineer Buzcom / FibreWiFi > Keith Stokes > 21 September 2015 19:55 > It works fine for me from Cox. > > > > --- > > Keith Stokes > > ________________________________________ > From: NANOG on behalf of Murat Kaipov > > Sent: Monday, September 21, 2015 1:51 PM > To: nanog at nanog.org > Subject: cisco.com unavailable > > Hi folks! > Is cisco.com unavailable or it is affected just > for Rostelecom? > Murat Kaipov > 21 September 2015 19:51 > Hi folks! > Is cisco.com unavailable or it is affected just > for Rostelecom? From robertg at garlic.com Mon Sep 21 19:03:02 2015 From: robertg at garlic.com (Robert Glover) Date: Mon, 21 Sep 2015 12:03:02 -0700 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: <56005466.8090807@garlic.com> On 9/21/2015 11:51 AM, Murat Kaipov wrote: > Hi folks! > Is cisco.com unavailable or it is affected just for Rostelecom? All is well from Cogent, Charter, and Verizon Wireless From sander at steffann.nl Mon Sep 21 19:05:32 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 21 Sep 2015 21:05:32 +0200 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: <14092E83-C970-467D-9C09-0FF062106A99@steffann.nl> > Is cisco.com unavailable or it is affected just for Rostelecom? Works fine here in The Netherlands (ISP: Solcon). Cheers, Sander From mkaipov at outlook.com Mon Sep 21 19:11:41 2015 From: mkaipov at outlook.com (Murat Kaipov) Date: Mon, 21 Sep 2015 22:11:41 +0300 Subject: cisco.com unavailable In-Reply-To: <14092E83-C970-467D-9C09-0FF062106A99@steffann.nl> References: <14092E83-C970-467D-9C09-0FF062106A99@steffann.nl> Message-ID: 2 minutes ago all had worked fine, now I have same trouble. mkaipov$ traceroute cisco.com traceroute to cisco.com (72.163.4.161), 64 hops max, 52 byte packets 1 router.asus.com (10.10.0.1) 1.536 ms 1.232 ms 1.176 ms 2 62.182.11.92 (62.182.11.92) 1.934 ms 2.924 ms 3.251 ms 3 isp2.aquafon.com (62.182.11.26) 2.140 ms 2.421 ms 2.380 ms 4 u111asr1002tr2-isp2.aquafon.com (91.221.157.5) 4.767 ms 3.515 ms 3.243 ms 5 62.183.37.150 (62.183.37.150) 3.585 ms 3.573 ms 3.465 ms 6 230.100.sochicom.biz (85.174.230.100) 3.898 ms 5.611 ms 3.671 ms 7 85.174.230.225 (85.174.230.225) 16.177 ms 17.043 ms 15.573 ms 8 85.175.2.69 (85.175.2.69) 13.401 ms 20.689 ms 13.170 ms 9 188.254.36.249 (188.254.36.249) 28.386 ms 188.254.36.253 (188.254.36.253) 14.295 ms 27.329 ms 10 87.226.133.103 (87.226.133.103) 72.963 ms * 69.451 ms 11 s-b3-link.telia.net (213.248.95.105) 49.969 ms 50.155 ms s-b3-link.telia.net (62.115.11.57) 66.943 ms 12 s-bb3-link.telia.net (213.155.133.16) 75.242 ms s-bb3-link.telia.net (62.115.137.158) 71.001 ms 70.112 ms 13 s-b6-link.telia.net (62.115.141.201) 71.606 ms s-b6-link.telia.net (62.115.136.23) 47.700 ms s-b6-link.telia.net (62.115.136.21) 48.270 ms 14 level3-ic-155475-s-b2.c.telia.net (213.248.99.134) 48.129 ms 49.995 ms 66.182 ms 15 * * * 16 * * * 17 cisco-syste.ear1.dallas1.level3.net (4.30.74.46) 195.112 ms 308.241 ms 193.757 ms 18 rcdn9-cd1-dmzbb-gw1-ten1-1.cisco.com (72.163.0.5) 197.443 ms 193.921 ms 420.050 ms 19 rcdn9-cd1-dmzdcc-gw1-por1.cisco.com (72.163.0.178) 307.371 ms 307.396 ms 306.593 ms 20 * * * 21 * * * 22 * * * 23 * * > 21 ????. 2015 ?., ? 22:05, Sander Steffann ???????(?): > > >> Is cisco.com unavailable or it is affected just for Rostelecom? > > Works fine here in The Netherlands (ISP: Solcon). > > Cheers, > Sander > From lists at mtin.net Mon Sep 21 19:33:53 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Mon, 21 Sep 2015 15:33:53 -0400 Subject: cisco.com unavailable In-Reply-To: <20150921185916.GP22440@bamboo.slabnet.com> References: <20150921185916.GP22440@bamboo.slabnet.com> Message-ID: <95C09140-FB5C-489B-A584-2615F89FA868@mtin.net> http://downforeveryoneorjustme.com/ Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric > On Sep 21, 2015, at 2:59 PM, Hugo Slabbert wrote: > >>> Is cisco.com unavailable or it is affected just for >>> Rostelecom? > > No problems here from either v4 or v6. > > -- > Hugo From sam.oduor at gmail.com Mon Sep 21 19:38:18 2015 From: sam.oduor at gmail.com (Sam Oduor) Date: Mon, 21 Sep 2015 22:38:18 +0300 Subject: cisco.com unavailable In-Reply-To: <56005466.8090807@garlic.com> References: <56005466.8090807@garlic.com> Message-ID: All set for me; East Africa, Kenya, Nairobi .. I can also see some serious dude fixing a bike on the site. Tracing route to cisco.com [72.163.4.161] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms 192.168.0.1 2 11 ms 224 ms 13 ms 10.34.0.1 3 7 ms 7 ms 6 ms 196.207.31.181.accesskenya.com [196.207.31.181] 4 10 ms 10 ms 17 ms te2-1.er1.bp.nbo.accesskenya.net [196.207.31.145 ] 5 652 ms 161 ms 515 ms if-6-0-2.core4.LDN-London.as6453.net [80.231.76. 101] 6 395 ms 1139 ms 148 ms if-1-3-1-0.tcore1.LDN-London.as6453.net [80.231. 76.86] 7 197 ms 147 ms 188 ms 195.219.83.102 8 * * * Request timed out. 9 * * * Request timed out. 10 313 ms * 283 ms CISCO-SYSTE.ear1.Dallas1.Level3.net [4.30.74.46] 11 270 ms 264 ms 329 ms rcdn9-cd2-dmzbb-gw2-ten1-1.cisco.com [72.163.0.2 1] 12 299 ms 326 ms 323 ms rcdn9-cd2-dmzdcc-gw2-por2.cisco.com [72.163.0.19 0] 13 291 ms 534 ms 256 ms rcdn9-16b-dcz05n-gw2-por2.cisco.com [72.163.2.11 0] 14 275 ms 598 ms 270 ms www1.cisco.com [72.163.4.161] Trace complete. On Mon, Sep 21, 2015 at 10:03 PM, Robert Glover wrote: > On 9/21/2015 11:51 AM, Murat Kaipov wrote: > >> Hi folks! >> Is cisco.com unavailable or it is affected just for >> Rostelecom? >> > > All is well from Cogent, Charter, and Verizon Wireless > > -- Samson Oduor From Valdis.Kletnieks at vt.edu Mon Sep 21 19:49:11 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 21 Sep 2015 15:49:11 -0400 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: <24909.1442864951@turing-police.cc.vt.edu> On Mon, 21 Sep 2015 14:58:39 -0400, Dovid Bender said: > Working from Verizon FiOS > > [root at yosefh-OptiPlex-3020 ~]# wget cisco.com Somebody's a trusting soul.... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mkaipov at outlook.com Mon Sep 21 19:54:09 2015 From: mkaipov at outlook.com (Murat Kaipov) Date: Mon, 21 Sep 2015 22:54:09 +0300 Subject: cisco.com unavailable In-Reply-To: <95C09140-FB5C-489B-A584-2615F89FA868@mtin.net> References: <20150921185916.GP22440@bamboo.slabnet.com> <95C09140-FB5C-489B-A584-2615F89FA868@mtin.net> Message-ID: Now all works fine. mkaipov$ traceroute www.cisco.com traceroute to e144.dscb.akamaiedge.net (23.78.32.170), 64 hops max, 52 byte packets 1 router.asus.com (10.10.0.1) 1.598 ms 1.287 ms 1.126 ms 2 62.182.11.92 (62.182.11.92) 1.878 ms 1.789 ms 1.863 ms 3 91.221.157.1 (91.221.157.1) 3.145 ms 3.361 ms 3.081 ms 4 rdn06.transtelecom.net (217.150.56.234) 10.898 ms 10.362 ms 10.067 ms 5 10.78.146.2 (10.78.146.2) 47.051 ms 47.222 ms 46.991 ms 6 * * * 7 eth2-4.r1.sto2.se.as5580.net (78.152.34.215) 76.838 ms 73.685 ms 73.822 ms 8 eth3-1.r1.cph1.dk.as5580.net (78.152.34.158) 82.728 ms 93.950 ms 82.614 ms 9 akamai-20940-gw.cph01-1.dk.as5580.net (78.152.57.10) 86.037 ms 85.568 ms 85.522 ms 10 a23-78-32-170.deploy.static.akamaitechnologies.com (23.78.32.170) 81.347 ms 86.100 ms 81.352 ms MBP-Murat:~ mkaipov$ > 21 ????. 2015 ?., ? 22:33, Justin Wilson - MTIN ???????(?): > > http://downforeveryoneorjustme.com/ > > > > > Justin Wilson > j2sw at mtin.net > > --- > http://www.mtin.net Owner/CEO > xISP Solutions- Consulting ? Data Centers - Bandwidth > > http://www.midwest-ix.com COO/Chairman > Internet Exchange - Peering - Distributed Fabric > >> On Sep 21, 2015, at 2:59 PM, Hugo Slabbert wrote: >> >>>> Is cisco.com unavailable or it is affected just for >>>> Rostelecom? >> >> No problems here from either v4 or v6. >> >> -- >> Hugo > From jvanoppen at spectrumnet.us Mon Sep 21 20:04:57 2015 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Mon, 21 Sep 2015 20:04:57 +0000 Subject: high latency on West Coast? In-Reply-To: <3580ab5bff10273d47d59f1dd36ab6c6@andrei.myip.org> References: <6yt256n9nt6270b9br1mhgde.1442613471371@email.android.com> <3580ab5bff10273d47d59f1dd36ab6c6@andrei.myip.org> Message-ID: Not that we could tell, it was a really annoying location to fix and we saw lots of traffic show up from customers that were multi-homed between us and the affected carriers (L3 and integra), likely amazon saw the same issues we did. RFO I heard was fiber cut on an island in the Columbia river. John -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Florin Andrei Sent: Saturday, September 19, 2015 8:59 PM To: nanog at nanog.org Subject: Re: high latency on West Coast? On 2015-09-18 14:57, andrew wrote: > L3 fiber cut . Is this related to the wave of deliberate fiber cuts on the West Coast this year? -- Florin Andrei http://florin.myip.org/ From streiner at cluebyfour.org Mon Sep 21 21:15:35 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 21 Sep 2015 17:15:35 -0400 (EDT) Subject: Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN In-Reply-To: References: Message-ID: On Mon, 21 Sep 2015, Sean Donelan wrote: > It could be summarized as "Circuit route diversity sucks." The only thing > worse than circuit route diversity were the processes to assure diverse > circuit orders stayed diverse. No small feat when carriers re-groom circuits and don't bother to tell anyone, beyond *maybe* a cryptic notification regarding "maintenance on your service". jms From ESundberg at nitelusa.com Mon Sep 21 22:52:33 2015 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Mon, 21 Sep 2015 22:52:33 +0000 Subject: IX Peering - BGP Session Filtering Best Practice Message-ID: <495D0934DA46854A9CA758393724D590CBB4C4@NI-MAIL02.nii.ads> Just wondering how far everyone is going on filtering BGP sessions when peering with other content providers and carriers over an internet exchange. What are you doing. 1. Just filtering out IPv4 Reserved Space, RFC 1918, and Default Routes. 2. AS Path Filtering. Only filtering by the AS's that are present in the IRR Record. 3. Filtering by IP Prefix based on the IRR Record for the Peer. (Yes some Prefix Filter list can be a couple thousand lines) 4. Doing both #3 and 4 listed above. Besides Peering DB is there any software to help keep track of IX and Peering info. So far I have only found IXP-MANGER ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From pauldotwall at gmail.com Tue Sep 22 02:52:29 2015 From: pauldotwall at gmail.com (Paul WALL) Date: Tue, 22 Sep 2015 02:52:29 +0000 Subject: IX Peering - BGP Session Filtering Best Practice In-Reply-To: <495D0934DA46854A9CA758393724D590CBB4C4@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590CBB4C4@NI-MAIL02.nii.ads> Message-ID: You might want to check out Console by IIX (www.iix.net). They are re-shaping peering automation with SDN. Drive Slow, Paul WALL On 9/21/15, Erik Sundberg wrote: > Just wondering how far everyone is going on filtering BGP sessions when > peering with other content providers and carriers over an internet > exchange. > > What are you doing. > > 1. Just filtering out IPv4 Reserved Space, RFC 1918, and Default > Routes. > > > 2. AS Path Filtering. Only filtering by the AS's that are present in > the IRR Record. > > > > 3. Filtering by IP Prefix based on the IRR Record for the Peer. (Yes > some Prefix Filter list can be a couple thousand lines) > > > > 4. Doing both #3 and 4 listed above. > > > > > > > Besides Peering DB is there any software to help keep track of IX and > Peering info. So far I have only found IXP-MANGER > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > From tom+nanog at konduto.com Mon Sep 21 17:31:25 2015 From: tom+nanog at konduto.com (Tom Canabarro) Date: Mon, 21 Sep 2015 14:31:25 -0300 Subject: high latency on West Coast? In-Reply-To: <3580ab5bff10273d47d59f1dd36ab6c6@andrei.myip.org> References: <6yt256n9nt6270b9br1mhgde.1442613471371@email.android.com> <3580ab5bff10273d47d59f1dd36ab6c6@andrei.myip.org> Message-ID: Does anyone have an official explanation or report for this issue? We found that latency between US-WEST-2 and US-WEST-1 jumped from 20ms to over 200ms during a ~48 hour period, roughly between midnight Sept. 18th UTC to 1am Sept. 20th UTC. AWS confirmed they were working on an issue with an external provider, but that was pretty much it. -- Tom Canabarro. On Sun, Sep 20, 2015 at 12:59 AM, Florin Andrei wrote: > On 2015-09-18 14:57, andrew wrote: > >> L3 fiber cut . >> > > Is this related to the wave of deliberate fiber cuts on the West Coast > this year? > > -- > Florin Andrei > http://florin.myip.org/ > From madsushi at gmail.com Mon Sep 21 17:59:06 2015 From: madsushi at gmail.com (Chase Christian) Date: Mon, 21 Sep 2015 10:59:06 -0700 Subject: DDoS auto-mitigation best practices (for eyeball networks) In-Reply-To: <007901d0f465$1545e200$3fd1a600$@iname.com> References: <000101d0f314$fbf7f050$f3e7d0f0$@iname.com> <72125B0F-AEC8-48BF-A844-6A2FA49880BB@akcin.net> <007901d0f465$1545e200$3fd1a600$@iname.com> Message-ID: Most video games utilize peer-to-peer traffic (which is why many require port forwarding/UPnP), so the attacker has the IP addresses of all of their peers in their firewall logs. There are even 'gaming routers' that specialize in gaming this peer-to-peer system for competitive advantages, such as specifically blocking the IPs of players you don't want to play against: https://netduma.com/why/for-gamers/ Once an attacker has identified his target, getting the IP is as simple as joining/being in an online game with that player. On Mon, Sep 21, 2015 at 5:00 AM, wrote: > 99% of the attacks we see are gaming related -- somehow the other players > know the IP and then attack our customer for an advantage in the game, or > retribution. > > Most DHCP servers (correctly) give the same IP address if the CPE is > rebooted. Ours are one of those. =) > > Frank > > -----Original Message----- > From: Mehmet Akcin [mailto:mehmet at akcin.net] > Sent: Saturday, September 19, 2015 3:10 PM > To: Frank Bulk > Cc: nanog at nanog.org > Subject: Re: DDoS auto-mitigation best practices (for eyeball networks) > > How does he/she become target? How does IP address gets exposed? > > I guess simplest way is to reboot modem and hope to get new ip (or call n > request) > > Mehmet > > > On Sep 19, 2015, at 12:54, Frank Bulk wrote: > > > > Could the community share some DDoS auto-mitigation best practices for > > eyeball networks, where the target is a residential broadband subscriber? > > I'm not asking so much about the customer communication as much as > > configuration of any thresholds or settings, such as: > > - minimum traffic volume before responding (for volumetric attacks) > > - minimum time to wait before responding > > - filter percentage: 100% of the traffic toward target (or if volumetric, > > just a certain percentage)? > > - time before mitigation is automatically removed > > - and if the attack should recur shortly thereafter, time to respond and > > remove again > > - use of an upstream provider(s) mitigation services versus one's own > > mitigation tools > > - network placement of mitigation (presumably upstream as possible) > > - and anything else > > > > I ask about best practice for broadband subscribers on eyeball networks > > because it's different environment than data center and hosting > environments > > or when one's network is being used to DDoS a target. > > > > Regards, > > > > Frank > > > > > From bobc at catcominc.com Mon Sep 21 18:55:23 2015 From: bobc at catcominc.com (Bob Clabaugh) Date: Mon, 21 Sep 2015 11:55:23 -0700 Subject: cisco.com unavailable In-Reply-To: References: Message-ID: <5600529B.1090408@catcominc.com> I've been using it from Oregon, USA all morning without problems. On 9/21/2015 11:51 AM, Murat Kaipov wrote: > Hi folks! > Is cisco.com unavailable or it is affected just for Rostelecom? From manager at monmouth.com Tue Sep 22 16:03:21 2015 From: manager at monmouth.com (Mark Stevens) Date: Tue, 22 Sep 2015 12:03:21 -0400 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation Message-ID: <56017BC9.6030204@monmouth.com> Hi All, Has anyone seen that something (most likely an alg) on Verizon's LTE/4G network is rewriting SIP headers,in particular From Tag identifiers? We cannot make a SIP call from our cellphones (using cellular data) beyond 30 seconds because the TAGs are rewritten and the destination Asterisk server drops the call because of this. Thanks Mark From morrowc.lists at gmail.com Tue Sep 22 16:22:19 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 22 Sep 2015 12:22:19 -0400 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation In-Reply-To: <56017BC9.6030204@monmouth.com> References: <56017BC9.6030204@monmouth.com> Message-ID: On Tue, Sep 22, 2015 at 12:03 PM, Mark Stevens wrote: > Hi All, > > Has anyone seen that something (most likely an alg) on Verizon's LTE/4G > network is rewriting SIP headers,in particular From Tag identifiers? We > cannot make a SIP call from our cellphones (using cellular data) beyond 30 > seconds because the TAGs are rewritten and the destination Asterisk server > drops the call because of this. > I'm shocked that the cellular carrier is making over-the-top phone calls non-functional. I'm sure they'll agree to meet you at their CO so you can do the proper work request sometime between 6am and 7pm in 2 weeks time. go incombancy! > Thanks > > Mark From joelja at bogus.com Tue Sep 22 16:24:58 2015 From: joelja at bogus.com (joel jaeggli) Date: Tue, 22 Sep 2015 09:24:58 -0700 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation In-Reply-To: <56017BC9.6030204@monmouth.com> References: <56017BC9.6030204@monmouth.com> Message-ID: <560180DA.8030004@bogus.com> On 9/22/15 9:03 AM, Mark Stevens wrote: > Hi All, > > Has anyone seen that something (most likely an alg) on Verizon's LTE/4G > network is rewriting SIP headers,in particular From Tag identifiers? We > cannot make a SIP call from our cellphones (using cellular data) beyond > 30 seconds because the TAGs are rewritten and the destination Asterisk > server drops the call because of this. sounds like a really good application for TLS > Thanks > > Mark > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From manager at monmouth.com Tue Sep 22 16:38:30 2015 From: manager at monmouth.com (Mark Stevens) Date: Tue, 22 Sep 2015 12:38:30 -0400 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation In-Reply-To: <560180DA.8030004@bogus.com> References: <56017BC9.6030204@monmouth.com> <560180DA.8030004@bogus.com> Message-ID: <56018406.9030905@monmouth.com> TLS would be perfect but it is not viable at this point. I guess with Verizon being what they are, it is time to start working on a SIP over TLS implementation. On 9/22/2015 12:24 PM, joel jaeggli wrote: > On 9/22/15 9:03 AM, Mark Stevens wrote: >> Hi All, >> >> Has anyone seen that something (most likely an alg) on Verizon's LTE/4G >> network is rewriting SIP headers,in particular From Tag identifiers? We >> cannot make a SIP call from our cellphones (using cellular data) beyond >> 30 seconds because the TAGs are rewritten and the destination Asterisk >> server drops the call because of this. > sounds like a really good application for TLS > >> Thanks >> >> Mark >> > From SNaslund at medline.com Tue Sep 22 16:56:32 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 22 Sep 2015 16:56:32 +0000 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation In-Reply-To: <56017BC9.6030204@monmouth.com> References: <56017BC9.6030204@monmouth.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C71243C2@MUNPRDMBXA1.medline.com> Send all of your signaling over TLS and they won't be able to see or modify it. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Stevens Sent: Tuesday, September 22, 2015 11:03 AM To: nanog at nanog.org Subject: Verizon Wireless LTE/4G and SIP Header Manipulation Hi All, Has anyone seen that something (most likely an alg) on Verizon's LTE/4G network is rewriting SIP headers,in particular From Tag identifiers? We cannot make a SIP call from our cellphones (using cellular data) beyond 30 seconds because the TAGs are rewritten and the destination Asterisk server drops the call because of this. Thanks Mark From dovid at telecurve.com Tue Sep 22 17:16:14 2015 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 22 Sep 2015 17:16:14 +0000 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation Message-ID: <1400356932-1442942175-cardhu_decombobulator_blackberry.rim.net-1973383814-@b13.c3.bise6.blackberry> We have this every now and then. Mainly with traffic from the middle east. Switching the port to something other than 5060 seems to help most of the time. Every so often we need to go the vpn route. I know that yealink, snim and possibly polycom have vpn clients built into them. ------Original Message------ From: Mark Stevens Sender: NANOG To: nanog at nanog.org Subject: Verizon Wireless LTE/4G and SIP Header Manipulation Sent: Sep 22, 2015 12:03 Hi All, Has anyone seen that something (most likely an alg) on Verizon's LTE/4G network is rewriting SIP headers,in particular From Tag identifiers? We cannot make a SIP call from our cellphones (using cellular data) beyond 30 seconds because the TAGs are rewritten and the destination Asterisk server drops the call because of this. Thanks Mark Regards, Dovid From morrowc.lists at gmail.com Tue Sep 22 19:51:02 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 22 Sep 2015 15:51:02 -0400 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation In-Reply-To: References: <56017BC9.6030204@monmouth.com> Message-ID: On Tue, Sep 22, 2015 at 12:22 PM, Christopher Morrow wrote: > On Tue, Sep 22, 2015 at 12:03 PM, Mark Stevens wrote: >> Hi All, >> >> Has anyone seen that something (most likely an alg) on Verizon's LTE/4G >> network is rewriting SIP headers,in particular From Tag identifiers? We >> cannot make a SIP call from our cellphones (using cellular data) beyond 30 >> seconds because the TAGs are rewritten and the destination Asterisk server >> drops the call because of this. >> > > I'm shocked that the cellular carrier is making over-the-top phone > calls non-functional. I'm sure they'll agree to meet you at their CO > so you can do the proper work request sometime between 6am and 7pm in > 2 weeks time. > joking aside, are you sure the packets get mangledin VZW and not elsewhere along the path? how would you be able to prove it? > go incombancy! > >> Thanks >> >> Mark From william.mccall at gmail.com Tue Sep 22 19:57:58 2015 From: william.mccall at gmail.com (William McCall) Date: Tue, 22 Sep 2015 12:57:58 -0700 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation In-Reply-To: References: <56017BC9.6030204@monmouth.com> Message-ID: I've seen this behavior before (a few years back). Moved off of VzW for this reason (i'm lazy to implement workarounds). IIRC when i investigated, the ALG was trying to not do something nefarious but just poorly implemented. On Tue, Sep 22, 2015 at 12:51 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Tue, Sep 22, 2015 at 12:22 PM, Christopher Morrow > wrote: > > On Tue, Sep 22, 2015 at 12:03 PM, Mark Stevens > wrote: > >> Hi All, > >> > >> Has anyone seen that something (most likely an alg) on Verizon's LTE/4G > >> network is rewriting SIP headers,in particular From Tag identifiers? We > >> cannot make a SIP call from our cellphones (using cellular data) beyond > 30 > >> seconds because the TAGs are rewritten and the destination Asterisk > server > >> drops the call because of this. > >> > > > > I'm shocked that the cellular carrier is making over-the-top phone > > calls non-functional. I'm sure they'll agree to meet you at their CO > > so you can do the proper work request sometime between 6am and 7pm in > > 2 weeks time. > > > > joking aside, are you sure the packets get mangledin VZW and not > elsewhere along the path? how would you be able to prove it? > > > go incombancy! > > > >> Thanks > >> > >> Mark > -- William McCall From manager at monmouth.com Tue Sep 22 20:16:28 2015 From: manager at monmouth.com (Mark Stevens) Date: Tue, 22 Sep 2015 16:16:28 -0400 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation In-Reply-To: References: <56017BC9.6030204@monmouth.com> Message-ID: <5601B71C.9020901@monmouth.com> The TAG unique identifier is being changed and this only happens through VZ LTE networks, not wired networks or even other cellular data networks (Sprint, ATT, T-Mobile) Their phones are IPV6 so the packets are getting converted to IPV4 so it is either happening there or there is a global ALG in Verizon land that is doing it . For positive proof I would need Verizon to fess up (LOL) but that will not happen or sniff traffic from the cellphone itself. On 9/22/2015 3:51 PM, Christopher Morrow wrote: > On Tue, Sep 22, 2015 at 12:22 PM, Christopher Morrow > wrote: >> On Tue, Sep 22, 2015 at 12:03 PM, Mark Stevens wrote: >>> Hi All, >>> >>> Has anyone seen that something (most likely an alg) on Verizon's LTE/4G >>> network is rewriting SIP headers,in particular From Tag identifiers? We >>> cannot make a SIP call from our cellphones (using cellular data) beyond 30 >>> seconds because the TAGs are rewritten and the destination Asterisk server >>> drops the call because of this. >>> >> I'm shocked that the cellular carrier is making over-the-top phone >> calls non-functional. I'm sure they'll agree to meet you at their CO >> so you can do the proper work request sometime between 6am and 7pm in >> 2 weeks time. >> > joking aside, are you sure the packets get mangledin VZW and not > elsewhere along the path? how would you be able to prove it? > >> go incombancy! >> >>> Thanks >>> >>> Mark From morrowc.lists at gmail.com Tue Sep 22 20:24:28 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 22 Sep 2015 16:24:28 -0400 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation In-Reply-To: <5601B71C.9020901@monmouth.com> References: <56017BC9.6030204@monmouth.com> <5601B71C.9020901@monmouth.com> Message-ID: On Tue, Sep 22, 2015 at 4:16 PM, Mark Stevens wrote: > The TAG unique identifier is being changed and this only happens through VZ > LTE networks, not wired networks or even other cellular data networks > (Sprint, ATT, T-Mobile) > Their phones are IPV6 so the packets are getting converted to IPV4 so it is > either happening there or there is a global ALG in Verizon land that is > doing it . > For positive proof I would need Verizon to fess up (LOL) but that will not > happen or sniff traffic from the cellphone itself. welp, interesting, good luck in your battle with the pstn. From jared at puck.nether.net Tue Sep 22 20:37:53 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 22 Sep 2015 16:37:53 -0400 Subject: Verizon Wireless LTE/4G and SIP Header Manipulation In-Reply-To: References: <56017BC9.6030204@monmouth.com> <5601B71C.9020901@monmouth.com> Message-ID: > On Sep 22, 2015, at 4:24 PM, Christopher Morrow wrote: > > On Tue, Sep 22, 2015 at 4:16 PM, Mark Stevens wrote: >> The TAG unique identifier is being changed and this only happens through VZ >> LTE networks, not wired networks or even other cellular data networks >> (Sprint, ATT, T-Mobile) >> Their phones are IPV6 so the packets are getting converted to IPV4 so it is >> either happening there or there is a global ALG in Verizon land that is >> doing it . >> For positive proof I would need Verizon to fess up (LOL) but that will not >> happen or sniff traffic from the cellphone itself. > > welp, interesting, good luck in your battle with the pstn. I?ll say it?s not just VZW that does this, there are issues with many CPE devices that mangle SIP traffic due to broken ALG. My plea is if you?re a carrier that provides a CPE, *please* provide an option to disable the ALG, or expose it to the customer so they can disable it. *Looks in 7018/7132 direction* - Jared From charlesg at unixrealm.com Wed Sep 23 00:27:05 2015 From: charlesg at unixrealm.com (Gisele Kamanou) Date: Wed, 23 Sep 2015 02:27:05 +0200 Subject: Fw: important Message-ID: <000004468705$544aa2ec$d0c4057d$@unixrealm.com> Hey! Important message, please visit Gisele Kamanou From nick at foobar.org Wed Sep 23 09:34:11 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 23 Sep 2015 10:34:11 +0100 Subject: Ear protection Message-ID: <56027213.6030700@foobar.org> What are people using for ear protection for datacenters these days? I'm down to my last couple of corded 3M 1110: http://www.shop3m.com/3m-corded-earplugs-hearing-conservation-1110.html These work reasonably well in practice, with a rated nominal noise reduction rate of 29dB. Some people find them uncomfortable, but they work well for me. There are other ear plugs with rated NRR of up to 32-33dB. Anyone have any opinions on what brands work well for them? Nick From dave.taht at gmail.com Wed Sep 23 09:42:23 2015 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 23 Sep 2015 02:42:23 -0700 Subject: Ear protection In-Reply-To: <56027213.6030700@foobar.org> References: <56027213.6030700@foobar.org> Message-ID: On Wed, Sep 23, 2015 at 2:34 AM, Nick Hilliard wrote: > What are people using for ear protection for datacenters these days? Telecommuting, in my case. had to say it! :0 > I'm > down to my last couple of corded 3M 1110: > > http://www.shop3m.com/3m-corded-earplugs-hearing-conservation-1110.html > > These work reasonably well in practice, with a rated nominal noise > reduction rate of 29dB. Some people find them uncomfortable, but they work > well for me. > > There are other ear plugs with rated NRR of up to 32-33dB. Anyone have any > opinions on what brands work well for them? > > Nick -- Dave T?ht endo is a terrible disease: http://www.gofundme.com/SummerVsEndo From jgreco at ns.sol.net Wed Sep 23 10:58:55 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 23 Sep 2015 05:58:55 -0500 (CDT) Subject: Ear protection In-Reply-To: Message-ID: <201509231058.t8NAwtcv036701@aurora.sol.net> > On Wed, Sep 23, 2015 at 2:34 AM, Nick Hilliard wrote: > > What are people using for ear protection for datacenters these days? > > Telecommuting, in my case. > > had to say it! :0 I carry these around in my pocket all the time: http://www.amazon.com/gp/product/B000W2CPCC Not just for datacenter use. I find myself pulling them out every few months when I happen to be somewhere uncomfortably noisy. Not the same (or as much dB reduction) as some of the other foam ones, but they seem nearly indestructible and washable as well. I also have some of these around, because they fold up really nicely. http://www.amazon.com/gp/product/B000U439KO About the same dB reduction (21) as the above. You can of course use both of these products together for a much higher degree of noise reduction but I rarely find myself needing that. ... 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 mailing-porcus at porcus.ch Wed Sep 23 09:57:28 2015 From: mailing-porcus at porcus.ch (Will van Gulik) Date: Wed, 23 Sep 2015 11:57:28 +0200 Subject: Ear protection In-Reply-To: References: <56027213.6030700@foobar.org> Message-ID: <3A41BBD0-7909-4F0E-A319-8BFF15987E87@porcus.ch> I used molded 15dB earplug from ACS that I also use for other environments (music, etc). They are way much more comfortable (like, you forget them) but also more expensive. BTW I'm looking for a place to get new ones in Europe, if anyone has got adresses. Will van Gulik On 23 Sep 2015, at 11:42, Dave Taht wrote: > On Wed, Sep 23, 2015 at 2:34 AM, Nick Hilliard wrote: >> What are people using for ear protection for datacenters these days? > > Telecommuting, in my case. > > had to say it! :0 > >> I'm >> down to my last couple of corded 3M 1110: >> >> http://www.shop3m.com/3m-corded-earplugs-hearing-conservation-1110.html >> >> These work reasonably well in practice, with a rated nominal noise >> reduction rate of 29dB. Some people find them uncomfortable, but they work >> well for me. >> >> There are other ear plugs with rated NRR of up to 32-33dB. Anyone have any >> opinions on what brands work well for them? >> >> Nick > > > > -- > Dave T?ht > endo is a terrible disease: http://www.gofundme.com/SummerVsEndo From alex at corp.nac.net Wed Sep 23 11:08:09 2015 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 23 Sep 2015 11:08:09 +0000 Subject: Ear protection In-Reply-To: <56027213.6030700@foobar.org> References: <56027213.6030700@foobar.org> Message-ID: <8d980d68-0d24-486b-80a7-049bf67c74f8@email.android.com> Why not just build a Datacenter that is quiet? On Sep 23, 2015 05:34, Nick Hilliard wrote: What are people using for ear protection for datacenters these days? I'm down to my last couple of corded 3M 1110: http://www.shop3m.com/3m-corded-earplugs-hearing-conservation-1110.html These work reasonably well in practice, with a rated nominal noise reduction rate of 29dB. Some people find them uncomfortable, but they work well for me. There are other ear plugs with rated NRR of up to 32-33dB. Anyone have any opinions on what brands work well for them? Nick From deleskie at gmail.com Wed Sep 23 11:17:36 2015 From: deleskie at gmail.com (jim deleskie) Date: Wed, 23 Sep 2015 08:17:36 -0300 Subject: Ear protection In-Reply-To: <8d980d68-0d24-486b-80a7-049bf67c74f8@email.android.com> References: <56027213.6030700@foobar.org> <8d980d68-0d24-486b-80a7-049bf67c74f8@email.android.com> Message-ID: Maybe I've always listened to my music to loud and spend the bulk of time via ssh, but I've never felt a need for hearing protection in a DC, is this generally an issue for people? On Wed, Sep 23, 2015 at 8:08 AM, Alex Rubenstein wrote: > Why not just build a Datacenter that is quiet? > > On Sep 23, 2015 05:34, Nick Hilliard wrote: > What are people using for ear protection for datacenters these days? I'm > down to my last couple of corded 3M 1110: > > http://www.shop3m.com/3m-corded-earplugs-hearing-conservation-1110.html > > These work reasonably well in practice, with a rated nominal noise > reduction rate of 29dB. Some people find them uncomfortable, but they work > well for me. > > There are other ear plugs with rated NRR of up to 32-33dB. Anyone have any > opinions on what brands work well for them? > > Nick > From jgreco at ns.sol.net Wed Sep 23 12:33:07 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 23 Sep 2015 07:33:07 -0500 (CDT) Subject: Ear protection In-Reply-To: <8d980d68-0d24-486b-80a7-049bf67c74f8@email.android.com> Message-ID: <201509231233.t8NCX7FP037501@aurora.sol.net> > Why not just build a Datacenter that is quiet? Because the cost differential to do so is a lot greater than the $10 to get some hearing protection? Passive cooling typically translates to lower performance but also can be more expensive. ... 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 jgreco at ns.sol.net Wed Sep 23 12:53:41 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 23 Sep 2015 07:53:41 -0500 (CDT) Subject: Ear protection In-Reply-To: Message-ID: <201509231253.t8NCrfLc037696@aurora.sol.net> > Maybe I've always listened to my music to loud and spend the bulk of time > via ssh, but I've never felt a need for hearing protection in a DC, is this > generally an issue for people? Depends on how long and how noisy. As I've gotten older, I find loud noise in general is less tolerable, so I've taken to always keeping a pair of earplugs with me. It makes being around loud music, etc., much more enjoyable. Long term exposure to noise is widely considered to be a hazard, but walking into an average data center for an hour once a month is probably not that risky. ... 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 Valdis.Kletnieks at vt.edu Wed Sep 23 12:50:01 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 23 Sep 2015 08:50:01 -0400 Subject: Ear protection In-Reply-To: <8d980d68-0d24-486b-80a7-049bf67c74f8@email.android.com> References: <56027213.6030700@foobar.org> <8d980d68-0d24-486b-80a7-049bf67c74f8@email.android.com> Message-ID: <42990.1443012601@turing-police.cc.vt.edu> On Wed, 23 Sep 2015 11:08:09 -0000, Alex Rubenstein said: > Why not just build a Datacenter that is quiet? When buying a compute cluster, if there's a budget choice between 15 more teraflops, or 15 less decibels, the teraflops *always* win. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mailing-lists at brianraaen.com Wed Sep 23 13:19:39 2015 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Wed, 23 Sep 2015 09:19:39 -0400 Subject: Ear protection In-Reply-To: <42990.1443012601@turing-police.cc.vt.edu> References: <56027213.6030700@foobar.org> <8d980d68-0d24-486b-80a7-049bf67c74f8@email.android.com> <42990.1443012601@turing-police.cc.vt.edu> Message-ID: On Wed, Sep 23, 2015 at 8:50 AM, wrote: > When buying a compute cluster, if there's a budget choice between > 15 more teraflops, or 15 less decibels, the teraflops *always* win. > Loudly sounds like a flop to me.... puns fully intended -- Brian Christopher Raaen Network Architect Zcorum From Daniel.Jameson at tdstelecom.com Wed Sep 23 13:20:40 2015 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Wed, 23 Sep 2015 13:20:40 +0000 Subject: Ear protection In-Reply-To: <42990.1443012601@turing-police.cc.vt.edu> References: <56027213.6030700@foobar.org> <8d980d68-0d24-486b-80a7-049bf67c74f8@email.android.com> <42990.1443012601@turing-police.cc.vt.edu> Message-ID: I use these http://www.amazon.com/V-MODA-Faders-Tuned-Earplugs-Electro/dp/B007RRTO2Y/ref=sr_1_9?ie=UTF8&qid=1443014097&sr=8-9&keywords=er+20+ear+plugs in the equipment room, You can still hear, just brings the level down to a manageable level. Looks like a pair of headphones. From bholloway at pavlovmedia.com Wed Sep 23 13:48:06 2015 From: bholloway at pavlovmedia.com (Bryan Holloway) Date: Wed, 23 Sep 2015 13:48:06 +0000 Subject: Ear protection In-Reply-To: <201509231253.t8NCrfLc037696@aurora.sol.net> References: <201509231253.t8NCrfLc037696@aurora.sol.net> Message-ID: On 9/23/15, 7:53 AM, "NANOG on behalf of Joe Greco" wrote: >> Maybe I've always listened to my music to loud and spend the bulk of >>time >> via ssh, but I've never felt a need for hearing protection in a DC, is >>this >> generally an issue for people? > >Depends on how long and how noisy. > >As I've gotten older, I find loud noise in general is less tolerable, >so I've taken to always keeping a pair of earplugs with me. It makes >being around loud music, etc., much more enjoyable. > >Long term exposure to noise is widely considered to be a hazard, but >walking into an average data center for an hour once a month is >probably not that risky. > >... JG > Depends on the type of "noise" too. Datacenters generate (more or less) white noise, which is particularly harmful long-term to the cilia in your ears because it excites all of them all of the time. A loud datacenter is much worse than a loud rock band, IMO. I personally use Bose noise-canceling headphones. From Steve.Mikulasik at civeo.com Wed Sep 23 13:58:55 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Wed, 23 Sep 2015 13:58:55 +0000 Subject: Ear protection In-Reply-To: <56027213.6030700@foobar.org> References: <56027213.6030700@foobar.org> Message-ID: I use these normally. http://www.howardleight.com/earplugs/laser-lite I am surprised some datacenters don't have a requirement for ear protection when entering their facilitiy. Most large construction sites I have been to required me to have ear plugs at least in a pocket and I have been to a few factories that required them on at all times. Many times these sites are quieter than the usual DC. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Hilliard Sent: Wednesday, September 23, 2015 3:34 AM To: nanog at nanog.org Subject: Ear protection What are people using for ear protection for datacenters these days? I'm down to my last couple of corded 3M 1110: http://www.shop3m.com/3m-corded-earplugs-hearing-conservation-1110.html These work reasonably well in practice, with a rated nominal noise reduction rate of 29dB. Some people find them uncomfortable, but they work well for me. There are other ear plugs with rated NRR of up to 32-33dB. Anyone have any opinions on what brands work well for them? Nick From keiths at neilltech.com Wed Sep 23 14:09:50 2015 From: keiths at neilltech.com (Keith Stokes) Date: Wed, 23 Sep 2015 14:09:50 +0000 Subject: Ear protection In-Reply-To: References: <201509231253.t8NCrfLc037696@aurora.sol.net> Message-ID: <295C9FCB-3121-4756-9FD1-847644808E12@neilltech.com> Since I?m in our colo facility this morning, I decided to put some numbers on it in my little isolated corner with lots of blowers running. According to my iPhone SPL meter, average SPL is 81 - 82 dB with peaks 88 - 89 dB. According to the OSHA hearing protection chart, 90 dB is the maximum level for 8-hour daily exposure. See https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=STANDARDS&p_id=9735 Etymotic, a manufacturer of high performance ear buds/ear phones says 85 dB is acceptable 8 hours per day, 5 days per week. See http://www.etymotic.com/downloads/dl/file/id/15/product/82/guide_to_safe_listening.pdf There is some argument to the point of what type of noise but ~10 dB is still pretty good headroom using the OSHA limits and 4 dB is certainly usable for the Etymotic figure. In the general area the levels are 6 - 9 dB lower. My thought is if you?re listening to music many hours per day you?re may be exceeding these levels already. On Sep 23, 2015, at 8:48 AM, Bryan Holloway > wrote: On 9/23/15, 7:53 AM, "NANOG on behalf of Joe Greco" on behalf of jgreco at ns.sol.net> wrote: Maybe I've always listened to my music to loud and spend the bulk of time via ssh, but I've never felt a need for hearing protection in a DC, is this generally an issue for people? Depends on how long and how noisy. As I've gotten older, I find loud noise in general is less tolerable, so I've taken to always keeping a pair of earplugs with me. It makes being around loud music, etc., much more enjoyable. Long term exposure to noise is widely considered to be a hazard, but walking into an average data center for an hour once a month is probably not that risky. ... JG Depends on the type of "noise" too. Datacenters generate (more or less) white noise, which is particularly harmful long-term to the cilia in your ears because it excites all of them all of the time. A loud datacenter is much worse than a loud rock band, IMO. I personally use Bose noise-canceling headphones. --- Keith Stokes From kauer at biplane.com.au Wed Sep 23 14:14:30 2015 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 24 Sep 2015 00:14:30 +1000 Subject: Ear protection In-Reply-To: References: <201509231253.t8NCrfLc037696@aurora.sol.net> Message-ID: <1443017670.3020.62.camel@karl> On Wed, 2015-09-23 at 13:48 +0000, Bryan Holloway wrote: > Depends on the type of "noise" too. Obviously seek competent medical advice, but my understanding is that this is a myth. The energy of sound is what causes damage. Bach played at 120dB will do just the same damage as a jet engine at 120dB. By reducing the "alarm" factor - by being more predictable, basically - loud sounds like music are often easier to tolerate and are often perceived as less loud, but energy is energy, and energy is damage. The other factor is time - the longer the sound continues at a given level, the more damage it does to the hearing. Here in Australia, 84dB for 8 hours is the highest "dose" that is legally allowed in the workplace without hearing protection. For sounds over about 95dB hearing protection is required even for short exposures. 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 dhubbard at dino.hostasaurus.com Wed Sep 23 14:29:25 2015 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 23 Sep 2015 10:29:25 -0400 Subject: Ear protection References: <56027213.6030700@foobar.org> Message-ID: I wear one of two things: 1) The 3M Peltor 105 ear muffs which offer 30db reduction. I keep them in my car because I also use them for the gun range, they fit snug but not annoying. They're only $18 on amazon: http://tinyurl.com/peltor105 There's also a behind the head bar if you don't like the over the top kind. 2) A lot more expensive, but with a side benefit; I have a custom set of ear plugs that I use for go kart racing so I can have radio communication. You can get them online or at most race tracks on a race day. Someone, or DIY at home, will use a big syringe to squirt the mold liquid in your ear, it sits for 60 seconds, then they pull it out and send it off to have the ear plugs made. They're very good at eliminating noise but have the side benefit of a headphone plug so you can still use your phone, ipod, etc. while you're in the data center. :-) David > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > Nick Hilliard > Sent: Wednesday, September 23, 2015 5:34 AM > To: nanog at nanog.org > Subject: Ear protection > > What are people using for ear protection for datacenters > these days? I'm down to my last couple of corded 3M 1110: > > http://www.shop3m.com/3m-corded-earplugs-hearing-conservation- > 1110.html > > These work reasonably well in practice, with a rated nominal > noise reduction rate of 29dB. Some people find them > uncomfortable, but they work well for me. > > There are other ear plugs with rated NRR of up to 32-33dB. > Anyone have any opinions on what brands work well for them? > > Nick > > From chk at pobox.com Wed Sep 23 14:44:34 2015 From: chk at pobox.com (Harald Koch) Date: Wed, 23 Sep 2015 10:44:34 -0400 Subject: Ear protection In-Reply-To: References: <56027213.6030700@foobar.org> Message-ID: I use Etymotic earplugs on my motorcycle as well as in other loud environments, because they attenuate "without loss of clarity": http://www.amazon.com/Etymotic-Research-ETY-Plugs-Protection-Earplugs/dp/B0044DEESS ? -- Harald From jordan-medlen at bisk.com Wed Sep 23 14:49:02 2015 From: jordan-medlen at bisk.com (Jordan Medlen) Date: Wed, 23 Sep 2015 14:49:02 +0000 Subject: Ear protection In-Reply-To: References: <56027213.6030700@foobar.org> Message-ID: <4861E1CF94656C46BBE7DD50DA619F8C4B8B0D@TPA-MBX-001.qwest.corp.bisk.com> Being a musician in a band, as well as very frequent concert goer, I use those same ones. I like them the best for all around use. I have used many different kinds, and I prefer these. Thank you, Jordan Medlen Network Engineer Bisk Education, Inc. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Harald Koch Sent: Wednesday, September 23, 2015 10:45 AM To: David Hubbard Cc: NANOG list Subject: Re: Ear protection I use Etymotic earplugs on my motorcycle as well as in other loud environments, because they attenuate "without loss of clarity": http://www.amazon.com/Etymotic-Research-ETY-Plugs-Protection-Earplugs/dp/B0044DEESS ? -- Harald From ecrogers at precisionds.com Wed Sep 23 15:02:59 2015 From: ecrogers at precisionds.com (Eric Rogers) Date: Wed, 23 Sep 2015 11:02:59 -0400 Subject: Ear protection References: <201509231253.t8NCrfLc037696@aurora.sol.net> Message-ID: I use earphones for the phone and alerts function, and because they are noise cancelling, they lower the db of noise. I use Shure SE215. Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bryan Holloway Sent: Wednesday, September 23, 2015 9:48 AM To: Joe Greco; jim deleskie Cc: Alex Rubenstein; NANOG Subject: Re: Ear protection On 9/23/15, 7:53 AM, "NANOG on behalf of Joe Greco" wrote: >> Maybe I've always listened to my music to loud and spend the bulk of >>time via ssh, but I've never felt a need for hearing protection in a >>DC, is this generally an issue for people? > >Depends on how long and how noisy. > >As I've gotten older, I find loud noise in general is less tolerable, >so I've taken to always keeping a pair of earplugs with me. It makes >being around loud music, etc., much more enjoyable. > >Long term exposure to noise is widely considered to be a hazard, but >walking into an average data center for an hour once a month is >probably not that risky. > >... JG > Depends on the type of "noise" too. Datacenters generate (more or less) white noise, which is particularly harmful long-term to the cilia in your ears because it excites all of them all of the time. A loud datacenter is much worse than a loud rock band, IMO. I personally use Bose noise-canceling headphones. From royce at techsolvency.com Wed Sep 23 15:17:36 2015 From: royce at techsolvency.com (Royce Williams) Date: Wed, 23 Sep 2015 07:17:36 -0800 Subject: Ear protection In-Reply-To: <56027213.6030700@foobar.org> References: <56027213.6030700@foobar.org> Message-ID: On Wed, Sep 23, 2015 at 1:34 AM, Nick Hilliard wrote: > What are people using for ear protection for datacenters these days? For me, it depends on the use case. If I need to monitor for other sounds, or listen to music: Bose QuietComfort 15 - discontinued, but still at Costco.com for $240. Their closest current model is the 25: http://www.amazon.com/dp/B00M1NEUKK, $300). On one AAA battery (I use rechargeables), they last ~30 hours of continuous active use. The sound cancelling is excellent, and voice ranges come through well. The ear cups are almost unnoticeable - I can wear them for 8 hours, with glasses on, without discomfort. They come with a semi-rigid carrying case, and detachable cords with controls for either Samsung or iPhone. Always in my daily-carry bag. If I need pure focus, but will need to take them on and off a lot: The discontinued Howard Leight Thunder 29. (The current Howard Leight equivalent appears to be the Thunder T3, NRR30.) Full muff with headband, passive, 29dB, no frills. New old stock is still available. I have three - one at home, one at the data center, and one at the office. If you enjoy having your Cow Orkers tease you about the 747 you're about to guide in, these are great. :) The ear cups are a little more rigid -- wearing for 8 hours with glasses is noticeable, but tolerable. For reusable portability: The Etymotics mentioned elsewhere in the thread. http://www.amazon.com//dp/B0044DEESS. Long-term durable; I've had them for years, but only use them on the go. If you're actively having to talk to people in the data center, these are great, but if you're going to work alone, I recommend more NRR just to keep the average down over time. Also good for mowing the lawn, so you can hear if someone is yelling at you. I don't have any SilentEar (silentear.com, NRR32), but they look promising, and I'll be trying them. Disposable / backup / utility plugs: Flents "Quiet Please" - rolling foam, NRR29. Good for handing out to friends at concerts, and good for hotel sleeping -- good NRR, and no irritating external components. They come in packs of 25 pairs. And according to my wife, they take the edge off of my snoring. :) I'm not affiliated, but I've had good luck with earplugstore.com over the years. Their site is informative, and very NRR-aware - they list NRR in product title, and let you sort search results by NRR. Royce From Matthew.Black at csulb.edu Wed Sep 23 15:23:22 2015 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 23 Sep 2015 15:23:22 +0000 Subject: Ear protection In-Reply-To: <56027213.6030700@foobar.org> References: <56027213.6030700@foobar.org> Message-ID: I use the 3M E-A-R plugs at home and love them. Since my tragus doesn't fold over, I am unable to use traditional Apple earbuds or other things that just fall out of my ear. 3M E-A-R plugs are like memory foam and fit snugly, providing excellent noise reduction. I use ComplyFoam on in-ear headphones for the same reason, because those thin rubber ear bud covers are useless. http://www.amazon.com/3M-E-A-R-Classic-earplugs-Pair/dp/B007GBUC7M matthew black california state university, long beach -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Hilliard Sent: Wednesday, September 23, 2015 2:34 AM To: nanog at nanog.org Subject: Ear protection What are people using for ear protection for datacenters these days? I'm down to my last couple of corded 3M 1110: http://www.shop3m.com/3m-corded-earplugs-hearing-conservation-1110.html These work reasonably well in practice, with a rated nominal noise reduction rate of 29dB. Some people find them uncomfortable, but they work well for me. There are other ear plugs with rated NRR of up to 32-33dB. Anyone have any opinions on what brands work well for them? Nick From m4rtntns at gmail.com Wed Sep 23 16:07:09 2015 From: m4rtntns at gmail.com (Martin T) Date: Wed, 23 Sep 2015 19:07:09 +0300 Subject: correlation between ingress and egress traffic in case of volume-based DDoS Message-ID: Hi, volume-based DDoS attacks should often result with following bandwidth graphs: http://s12.postimg.org/gy3eps10t/volume_based_DDo_S_graph.png This is a fabricated bps graph for 100GigE port facing an uplink provider. As seen on the image, outgoing traffic drops at the time when incoming traffic increases. I could see following reasons for this: 1) large portion of traffic uses TCP protocol and in case of congestion(even in one direction), ACK messages are lost and TCP congestion avoidance kicks in and as a result it will reduce the cwnd which in effect reduce the data TCP sender can send 2) certain router platforms share some hardware resources both with Tx and Rx traffic Are those assumptions correct? Are there any other reasons which cause outgoing traffic to drop if incoming traffic is very high or the other way around? thanks, Martin From psirt at cisco.com Wed Sep 23 16:07:50 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 23 Sep 2015 12:07:50 -0400 Subject: Cisco Security Advisory: Cisco IOS and IOS XE Software IPv6 First Hop Security Denial of Service Vulnerabilities Message-ID: <201509231207.17.fhs@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS and IOS XE Software IPv6 First Hop Security Denial of Service Vulnerabilities Advisory ID: cisco-sa-20150923-fhs Revision 1.0 For Public Release 2015 September 23 16:00 UTC (GMT) +------------------------------------------------------------------------------- Summary ======= Two vulnerabilities in the IPv6 first hop security feature of Cisco IOS and IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to reload. Cisco has released software updates that address these vulnerabilities. There are no workarounds to mitigate these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150923-fhs Note: The September 23, 2015, release of the Cisco IOS and IOS XE Software Security Advisory bundled publication includes three Cisco Security Advisories. All the advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: September 2015 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep15.html -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWAWwcAAoJEIpI1I6i1Mx3wYkQAJU+71c6l6BRNwQ65d7XucdS r64mrlpga6Mud4jxqsbatCM76W+DDcSE1xtz2lqWN8L3Aqndq/ZmsysZPID81lr/ kPWpVaNbOjr/BgXe8K8f/xYS6ExIMs7jcLSOcB5obdQaHXOvOf8yPOP4SuHodILO i5JJ+kjE22dmRw1srBCtZF0HdNUFa+aXYuR0OSrqHwaPARMsRPQbsAF7djBVDdRU 1XB4YH5zVXG0q3yMpdlJLdVkPtQesC+BSka66qcSJBnC6tqQ/KEMkUkt+Uk1Yh9s Qpuh9UcIB78/oBy/VZI8IGsTL4uVLczRhonQe5KFP3uvM0LJvMXAn+dTXXBZJXlm 9NEHrOuoxZjPlMYntaY3xE9Ocl3ObA4Y12H1S+E1djhVogdNjW4qN8dorqIq10g5 jAi0o8qhM7o5vRjDt8os0UnuAHPaqtY0C5oaTruZN28N7Hzey4mdM9wkOL/oY+rq Lgd9BT+BHAO+Yop0cgpmPAs2EXYzVz7zN5euYzuFywQOfQvko84YFfzxt6Y+ofIH SbAHZ1tdtw059IQk6Q6nlK3rE9jk+vO7wQ8MW39OXCgjEMlXn7kWQ3gctXz0Qesj li2+OFzXVhLBk3JDiqBQJ08FYoyuH25e58MumDLxZnoQi4jS5YqJcSQjSfnRLn2n eU9LswAcnFiAlRAE34PP =pjAl -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 23 16:08:26 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 23 Sep 2015 12:08:26 -0400 Subject: Cisco Security Advisory: Cisco IOS and IOS XE Software SSH Version 2 RSA-Based User Authentication Bypass Vulnerability Message-ID: <201509231208.17.sshpk@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS and IOS XE Software SSH Version 2 RSA-Based User Authentication Bypass Vulnerability Advisory ID: cisco-sa-20150923-sshpk Revision 1.0 For Public Release 2015 September 23 16:00 UTC (GMT) +------------------------------------------------------------------------------- Summary ======= A vulnerability in the SSH version 2 (SSHv2) protocol implementation of Cisco IOS and IOS XE Software could allow an unauthenticated, remote attacker to bypass user authentication. Successful exploitation could allow the attacker to log in with the privileges of the user or the privileges configured for the Virtual Teletype (VTY) line. Depending on the configuration of the user and of the vty line, the attacker may obtain administrative privileges on the system. The attacker cannot use this vulnerability to elevate privileges. The attacker must know a valid username configured for RSA-based user authentication and the public key configured for that user to exploit this vulnerability. This vulnerability affects only devices configured for public key authentication method, also known as RSA-based user authentication feature. Cisco has released software updates that address this vulnerability. Workarounds for this vulnerability are not available; however administrators could temporarily disable RSA-based user authentication to avoid exploitation. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150923-sshpk Note: The September 23, 2015, release of the Cisco IOS and IOS XE Software Security Advisory bundled publication includes three Cisco Security Advisories. All the advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: September 2015 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep15.html -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWAWwoAAoJEIpI1I6i1Mx3ZX8P/2w1PAyuoJbNS6i5ESErJBX8 EM18LXLdOuy+qe5Ag2V6ztDBpLGpp2AdaR4EYeaRnRyqBjL5gqdyXLYotIKk3IY0 4DLG/IEiLoSJql51Fx8GXvuomqr4S3Its3MfSjfkre2fEvVV6NpXaCaBZKsowiw+ e+pu4D1qPZm30+kwO7QUIN0lGwCIboZa7OiRLjItRyixiKbA7LADsCijCNy6FIF+ G8shRD/mSkyBoetF1MjvAN18d+z+Kuy9YOGViM8oWSV20/Z9PXlSujkVdRjaxW4Y +dPp5Fk1ot6zqSXQahZZRBY8glIkqE8gsTSJT9qhfD+8Q3XXY1eUNvlKuNmv3HDg ftlJYTq7Ye5gjbvd2ro7/IAoKf/jaC2CM6pTgegDsXCCarzUMVj6ZjXiP1XqjRS4 4yaX7v9z3qPVid8W8niJscFVdXMG4YGhHqNdriDirUmvF+a5XDa0OGCi40xO8rsV HG1PishidpaMXFgklJPCWzzuwmwWDu6GKvpJkTTSRNYWttzWV+/aMNQzzyGjTSIY ePzDeRctHfaeZyaVCiAVvv6Pj2NP0PGbLmtsr5K5UqoTEbVTy0CIte1iLuu8zzhs HzyoWlqziOq9+0NfvcM5/0J64wekiOUiQehKzyYOa+F3F54KzyDJxNhToezkLhdQ VcGcN1w0HOwRLvd7LWN6 =hXl+ -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 23 16:09:00 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 23 Sep 2015 12:09:00 -0400 Subject: Cisco Security Advisory: Cisco IOS XE Software Network Address Translation Denial of Service Vulnerability Message-ID: <201509231209.17.iosxe@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS XE Software Network Address Translation Denial of Service Vulnerability Advisory ID: cisco-sa-20150923-iosxe Revision 1.0 For Public Release 2015 September 23 16:00 UTC (GMT) +------------------------------------------------------------------------------- Summary ======= A vulnerability in the processing of IPv4 packets that require Network Address Translation (NAT) and Multiprotocol Label Switching (MPLS) services of Cisco IOS XE Software for Cisco ASR 1000 Series, Cisco ISR 4300 Series, Cisco ISR 4400 Series, and Cisco Cloud Services 1000v Series Routers could allow an unauthenticated, remote attacker to cause a reload of the affected device. The vulnerability is due to improper processing of IPv4 packets that require NAT and MPLS processing. An attacker could exploit this vulnerability by sending an IPv4 packet to be processed by a Cisco IOS XE device configured to perform NAT and MPLS services. A successful exploit could allow the attacker to cause a reload of the affected device. Cisco has released software updates that address these vulnerabilities. There are no workarounds to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150923-iosxe Note: The September 23, 2015, release of the Cisco IOS and IOS XE Software Security Advisory bundled publication includes three Cisco Security Advisories. All the advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: September 2015 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep15.html -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWAWwjAAoJEIpI1I6i1Mx38DAP/RFsW3ytyddAsop+FKs1wOMR 5lecyURmnDItcgbmAFcQIOZDV076aFznVDHKniGZQBsW54nh4YGV1pfq1YNU3ikz XVPY22XNgfnJQVGmzypxkL/hCYJlWF+RWMEQ+5sDMKb2LZP3WNNMtjNBOW4oac3r dP9sYgKBT8GcA4gVlsWEpaaFlMTs90jizkjjm2V1JcGiEn0aoL3+Uq5epJ0mRajI Kx/Dl7DdtiyDONNycABntHena6GtBVu+QvDqTbjpL8VV7XMeLmmCeOtZgGQQ/bTr UgZrRd+skLs+phSREk4x/GwcksRAGYu19pq5fNNAnWOYUBD2dhlfNET4GVKQ++1b h/DfHMXS++Ztj4aEA2VEU1WlFeTA5qRVjWtr6nxxfJoixaf6b0teeXMeWFJh9rRt C3LsSWvTp+X4L8vvVwWRV/Ij5vlMcN2aHp9SCealJzFDRr7r1B1cj/bGq+Cf4Ozc e9+8Y/F5NFe4+Epdm0SwdbYnwAvi6NxR1HGlzhpJWv2fkVZO+uCZajRwjAsceYmI si1mgpMJNgWyLitsRPbFVjnjtJaVdTb9AIUotvWqgHAmm6aaaGt1zRWDoJxZEQq3 r1JVXHd5Jm/jeTUeQApZF4QqIcDxP3vGvpdEdFJbHZGAQobia8TXX2vjagjomZwU IH8hUmuxOjKmeSFIP7oy =W9mD -----END PGP SIGNATURE----- From lowen at pari.edu Wed Sep 23 16:13:08 2015 From: lowen at pari.edu (Lamar Owen) Date: Wed, 23 Sep 2015 12:13:08 -0400 Subject: Ear protection In-Reply-To: <295C9FCB-3121-4756-9FD1-847644808E12@neilltech.com> References: Message-ID: <5602CF94.4030409@pari.edu> On 09/23/2015 10:09 AM, Keith Stokes wrote: > Since I?m in our colo facility this morning, I decided to put some numbers on it in my little isolated corner with lots of blowers running. > > According to my iPhone SPL meter, average SPL is 81 - 82 dB with peaks 88 - 89 dB. > > With SPL that close to the recommended maximum, the accuracy of the SPL measurement is rather critical. I would not trust my smartphone's mic to have sufficient accuracy to protect my hearing unless it is calibrated to a known source SPL using pink noise of a particular weight. The calibration SLM should be a 'real' SLM, such as a Bruel & Kjaer Type 2250 or similar with proper transducers. (Yes, I know, a B&K 2250 will set you back nearly $4K, but, just what is your hearing worth? A pair of hearing aids will set you (or your insurance company at least) back $4K too....). I used a vintage B&K transducer with a custom-built SLM-rated spec-an years ago at a local manufacturer's sound testing lab; the manufacturer makes ballasts and luminaires for HID lighting, and measuring ballast noise is a big deal. But reasonably accurate SLM's are available for less than $500 (some are available for less than $100, but you get what you pay for....). The particular whine of high-speed fans is a known risky noise source, particularly white noise, due to the high frequency content (140dB SPL at 45Hz is not as harmful as 140dB at 3kHz or 15kHz due to the outer ears' acting as waveguide-beyond-cutoff attenuators (and cavity resonators, too, for that matter). Spinning drives are no better, particularly 15k RPM drives. If it's at all uncomfortable, wear the earplugs. You're already having to shout to be heard anyway. From rdobbins at arbor.net Wed Sep 23 16:33:10 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 23 Sep 2015 23:33:10 +0700 Subject: correlation between ingress and egress traffic in case of volume-based DDoS In-Reply-To: References: Message-ID: On 23 Sep 2015, at 23:07, Martin T wrote: > Are there any other reasons which cause outgoing traffic to drop if > incoming traffic is very high Lots. It's very situationally-specific. The attack traffic may not be crafted in such a way so as to elicit a response from the targeted host(s). The relevant network links/paths could be filled, with attack traffic 'crowding out' legitimate traffic. The hosts could be pummeled with attack traffic and be so busy trying to deal with it at either the NIC level or the network stack level or the kernel level or the app/service level that it can't respond. The relevant network infrastructure could be down due to the attack traffic, for various reasons (software-based platform overloaded, traffic punted to RP, etc.). The hosts could be sitting behind a stateful firewall or load-balancer or 'IPS' which has gone down under the onslaught. And so forth. ----------------------------------- Roland Dobbins From ESundberg at nitelusa.com Wed Sep 23 17:36:20 2015 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Wed, 23 Sep 2015 17:36:20 +0000 Subject: Ear protection In-Reply-To: <5602CF94.4030409@pari.edu> References: <295C9FCB-3121-4756-9FD1-847644808E12@neilltech.com> <5602CF94.4030409@pari.edu> Message-ID: <495D0934DA46854A9CA758393724D590CC5A6C@NI-MAIL02.nii.ads> These block out the loud noise but allow you to still talk. Surefire Sonic Defender EP3, Ep4, EP5, EP7 They all are great! http://www.amazon.com/Surefire-Sonic-Defender-Plugs-1-Pair/dp/B007FKY8SI/ref=sr_1_8?ie=UTF8&qid=1443029640&sr=8-8&keywords=surefire+ep3+ep4 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lamar Owen Sent: Wednesday, September 23, 2015 11:13 AM To: NANOG Subject: Re: Ear protection On 09/23/2015 10:09 AM, Keith Stokes wrote: > Since I?m in our colo facility this morning, I decided to put some numbers on it in my little isolated corner with lots of blowers running. > > According to my iPhone SPL meter, average SPL is 81 - 82 dB with peaks 88 - 89 dB. > > With SPL that close to the recommended maximum, the accuracy of the SPL measurement is rather critical. I would not trust my smartphone's mic to have sufficient accuracy to protect my hearing unless it is calibrated to a known source SPL using pink noise of a particular weight. The calibration SLM should be a 'real' SLM, such as a Bruel & Kjaer Type 2250 or similar with proper transducers. (Yes, I know, a B&K 2250 will set you back nearly $4K, but, just what is your hearing worth? A pair of hearing aids will set you (or your insurance company at least) back $4K too....). I used a vintage B&K transducer with a custom-built SLM-rated spec-an years ago at a local manufacturer's sound testing lab; the manufacturer makes ballasts and luminaires for HID lighting, and measuring ballast noise is a big deal. But reasonably accurate SLM's are available for less than $500 (some are available for less than $100, but you get what you pay for....). The particular whine of high-speed fans is a known risky noise source, particularly white noise, due to the high frequency content (140dB SPL at 45Hz is not as harmful as 140dB at 3kHz or 15kHz due to the outer ears' acting as waveguide-beyond-cutoff attenuators (and cavity resonators, too, for that matter). Spinning drives are no better, particularly 15k RPM drives. If it's at all uncomfortable, wear the earplugs. You're already having to shout to be heard anyway. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From clinton at scripty.com Wed Sep 23 18:51:23 2015 From: clinton at scripty.com (Clinton Work) Date: Wed, 23 Sep 2015 12:51:23 -0600 Subject: Broken IPV6 for Enterprise websites Message-ID: <1443034283.839054.391777385.56CD7E17@webmail.messagingengine.com> The enterprise.com and enterprise.ca websites advertise AAAA records, but the web servers don't respond to IPV6 HTTP requests. I have tried to contacting Enterprise several times to correct, but I can't get thru their layers of customer service. I'm hoping that somebody on NANOG knows a technical contact at Enterprise. -- Clinton Work From jared at puck.nether.net Wed Sep 23 19:05:43 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 23 Sep 2015 15:05:43 -0400 Subject: Broken IPV6 for Enterprise websites In-Reply-To: <1443034283.839054.391777385.56CD7E17@webmail.messagingengine.com> References: <1443034283.839054.391777385.56CD7E17@webmail.messagingengine.com> Message-ID: <8806F526-25F1-4452-8C77-2E8E1FB5A5CE@puck.nether.net> > On Sep 23, 2015, at 2:51 PM, Clinton Work wrote: > > The enterprise.com and enterprise.ca websites advertise AAAA records, > but the web servers don't respond to IPV6 HTTP requests. I have tried > to contacting Enterprise several times to correct, but I can't get thru > their layers of customer service. I'm hoping that somebody on NANOG > knows a technical contact at Enterprise. As a related thing, since the iOS9 GM and with the 9.0.1 update today I certainly have seen a significant increase in the IPv6 traffic due to the changes with happy eyeballs. It?s doubled since the days prior to the 9.0GM release. Having working IPv6 is critical and monitoring both your v6 as well as v4 is important. I?m expecting Frank Bulk to add enterprise to his monitoring system today. He certainly gave me grief about some of our corporate sites until they fixed issues. - jared From johnl at iecc.com Wed Sep 23 19:07:49 2015 From: johnl at iecc.com (John Levine) Date: 23 Sep 2015 19:07:49 -0000 Subject: Broken IPV6 for Enterprise websites In-Reply-To: <1443034283.839054.391777385.56CD7E17@webmail.messagingengine.com> Message-ID: <20150923190749.8635.qmail@ary.lan> In article <1443034283.839054.391777385.56CD7E17 at webmail.messagingengine.com> you write: >The enterprise.com and enterprise.ca websites advertise AAAA records, >but the web servers don't respond to IPV6 HTTP requests. I have tried >to contacting Enterprise several times to correct, but I can't get thru >their layers of customer service. I'm hoping that somebody on NANOG >knows a technical contact at Enterprise. The WHOIS info for their IPv6 addresses finds a direct allocation from ARIN and a contact with an email address and direct phone number. Have you tried calling him? R's, John From bill at herrin.us Wed Sep 23 19:56:32 2015 From: bill at herrin.us (William Herrin) Date: Wed, 23 Sep 2015 15:56:32 -0400 Subject: correlation between ingress and egress traffic in case of volume-based DDoS In-Reply-To: References: Message-ID: On Wed, Sep 23, 2015 at 12:07 PM, Martin T wrote: > volume-based DDoS attacks should often result with following bandwidth graphs: > > http://s12.postimg.org/gy3eps10t/volume_based_DDo_S_graph.png > > This is a fabricated bps graph for 100GigE port facing an uplink > provider. As seen on the image, outgoing traffic drops at the time > when incoming traffic increases. > > Are those assumptions correct? Are there any other reasons which cause > outgoing traffic to drop if incoming traffic is very high or the other > way around? Hi Martin, I don't have much to add to what Roland said. The whole point of a volume-based denial of service attack is to overwhelm your target's infrastructure with fake traffic so that it is unable to handle real traffic. In a successful attack, the real traffic will drop off to almost nothing, having been crowded out. Depending on the details, this may or may not show up in a traffic graph. If the fake traffic induces return traffic, you'll see the return traffic spike as well. If the fake traffic all gets dropped somewhere within the infrastructure, you'll see return traffic plummet as you did in the graph you linked. Both cases can happen depending on the exact details of the attack. An aside - ack loss doesn't hurt TCP terribly much since the next ack also covers the previous one. TCP tends to stall when 2% to 5% of the payload packets are lost. Bear in mind that payload moves both ways. Even an http request contains a large request header. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From nanogml at Mail.DDoS-Mitigator.net Wed Sep 23 20:29:28 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Wed, 23 Sep 2015 13:29:28 -0700 Subject: correlation between ingress and egress traffic in case of volume-based DDoS In-Reply-To: References: Message-ID: <20150923202928.GA30762@Mail.DDoS-Mitigator.net> hi martin On 09/23/15 at 07:07pm, Martin T wrote: > volume-based DDoS attacks should often result with following bandwidth graphs: > > http://s12.postimg.org/gy3eps10t/volume_based_DDo_S_graph.png > > > This is a fabricated bps graph for 100GigE port facing an uplink when you say "fabricated" ... what do you mean ?? - if its actual ( real ) .. than okay for the reasoning - if its "fabricated" ( sanitized, made up, theory ), than still okay for reasoning as roland says, there's dozens of reasons to explain the results one sees in graphs .... graphs are always subject to different interpretation depending on different circumstances > provider. As seen on the image, outgoing traffic drops at the time > when incoming traffic increases. I could see following reasons for > this: > > 1) large portion of traffic uses TCP protocol and in case of in my case, the way i would simulate a tcp-based DDoS attack against a test victim, outgoing traffic should remain steady state per the normal tcp traffic ... and tarpit the ddos attacks from the victim under the volumetric tcp-based attacks setup the ingress filters for tarpits the attacking zombie should run out of kernel memory and crash if it tries to sustain huge amt of volumetric tcp-based ddos attacks without tarpits, all kinds of whacky network stuff will occur depending on how the tcp-based ddos attacks are lauached if its an icmp-based ddos attack, the outgoing traffic may be 10x or 100x more traffic than incoming icmp-based ddos attack if the server was not hardened to protect itself from icmp-based attacks if it was hardened, limit outgoing reply to incoming icmp-attacks, than it outgoing reply should be constant due to normal remaining traffic, but incoming icmp attacks can be 10x or 100x or 1000x normal similarly, if its an udp-based ddos attack, the outgoing traffic may be 10x or 100x more than the incoming traffic if dns,ntp,snmp, x11,nfs,etc was not hardened to protect itself from udp-based attacks if it was hardened, limit outgoing reply to incoming udp-attacks, than it outgoing reply should be constant due to normal remaining traffic, but incoming udp attacks can be 10x or 100x or 1000x normal if its an arp-based ddos attack, outgoing traffic may generate the same amt of traffic going out as whats coming in .. hopefully, you have bought good switches that don't fail-over into hub-mode launching those volumetric attacks takes a few minutes to figure out what options to use to create certain type of ddos attacks - nc, socat, iperf, etc - ping, nping, hping, etc - hundreds of other apps > congestion(even in one direction), ACK messages are lost and TCP > congestion avoidance kicks in and as a result it will reduce the cwnd > which in effect reduce the data TCP sender can send syn-cookies doesnt kick in until all tcp stack is exhausted and syn-cookies tries to service all incoming tcp requests probably a bad thing to attempt to do while under tcp-based ddos attacks fiddling with send and receive buffers and delays and timeout would add more fun to the problem and resulting bandwidth graphs > 2) certain router platforms share some hardware resources both with Tx > and Rx traffic > > Are those assumptions correct? Are there any other reasons which cause > outgoing traffic to drop if incoming traffic is very high or the other > way around? in the subject, you used "ingress and egress" filters ... those rules would also definitively affect the resulting bandwidth graphs if you're in the cloud ... all these thingies still apply to the guest OS and especially the host OS magic pixie dust alvin # # DDoS-Mitigator.com # DDoS-Simulator.net # From nanog at ics-il.net Wed Sep 23 20:37:31 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 23 Sep 2015 15:37:31 -0500 (CDT) Subject: 4 byte ASNs through OpenBGPd to old Cisco IOS In-Reply-To: <616664416.6984.1443039813376.JavaMail.mhammett@ThunderFuck> Message-ID: <302295212.7028.1443040722069.JavaMail.mhammett@ThunderFuck> Our IX's route servers run OpenBGPd 5.5. We are having a problem with a new customer getting turned up. He's getting back invalid or corrupt AS Path errors. There's a network on the IX that has a four byte ASN. They're running IOS 12.4.(15)T and is asking me if we support RFC 4893 which appears to be the 32 bit ASN specification altogether. They specifically highlighted this section: Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be used to propagate four-octet based AS path information across BGP speakers that do not support the four-octet AS numbers. Do any of you have any useful input other than they need to upgrade their IOS to something newer than 4.5 years old? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From nick at foobar.org Wed Sep 23 21:01:02 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 23 Sep 2015 22:01:02 +0100 Subject: 4 byte ASNs through OpenBGPd to old Cisco IOS In-Reply-To: <302295212.7028.1443040722069.JavaMail.mhammett@ThunderFuck> References: <302295212.7028.1443040722069.JavaMail.mhammett@ThunderFuck> Message-ID: <5603130E.1010909@foobar.org> On 23/09/2015 21:37, Mike Hammett wrote: > Do any of you have any useful input other than they need to upgrade > their IOS to something newer than 4.5 years old? 12.4.(15)T is known to be affected by a variety of security problems, for which cisco TAC will provide free upgrades - assuming they are available for that platform. This is regardless of the support situation for the device. Perhaps if they fixed their security problems with an upgrade, the newer software image might be more tolerant to strange asn32 attributes? Nick From simon at slimey.org Wed Sep 23 21:04:24 2015 From: simon at slimey.org (Simon Lockhart) Date: Wed, 23 Sep 2015 22:04:24 +0100 Subject: 4 byte ASNs through OpenBGPd to old Cisco IOS In-Reply-To: <302295212.7028.1443040722069.JavaMail.mhammett@ThunderFuck> References: <616664416.6984.1443039813376.JavaMail.mhammett@ThunderFuck> <302295212.7028.1443040722069.JavaMail.mhammett@ThunderFuck> Message-ID: <20150923210422.GE4513@dilbert.slimey.org> On Wed Sep 23, 2015 at 03:37:31PM -0500, Mike Hammett wrote: > Do any of you have any useful input other than they need to upgrade their IOS > to something newer than 4.5 years old? I recently went through a very similar issue, and was convinced it was related to 32 bit ASNs. Are they seeing this error? Sep 1 08:40:41.506 UTC: %BGP-3-NOTIFICATION: sent to neighbor xxx.xxx.xxx.xxx 3/11 (invalid or corrupt AS path) 11 bytes 40020802 033C3424 580097 If so, have they configured "no bgp enforce-first-as" in their BGP router config? Simon From rirving at antient.org Wed Sep 23 21:19:23 2015 From: rirving at antient.org (Richard Irving) Date: Wed, 23 Sep 2015 17:19:23 -0400 Subject: 4 byte ASNs through OpenBGPd to old Cisco IOS In-Reply-To: <20150923210422.GE4513@dilbert.slimey.org> References: <616664416.6984.1443039813376.JavaMail.mhammett@ThunderFuck> <302295212.7028.1443040722069.JavaMail.mhammett@ThunderFuck> <20150923210422.GE4513@dilbert.slimey.org> Message-ID: <5603175B.2000000@antient.org> They did, and it now formed peering with the RSD. Thanks! 12.4.(24)T is the first version from that IOS train that natively supports 4 byte ASN's. We can upgrade at a more convenient time and date. :-) On 09/23/2015 05:04 PM, Simon Lockhart wrote: > On Wed Sep 23, 2015 at 03:37:31PM -0500, Mike Hammett wrote: >> Do any of you have any useful input other than they need to upgrade their IOS >> to something newer than 4.5 years old? > I recently went through a very similar issue, and was convinced it was related > to 32 bit ASNs. > > Are they seeing this error? > Sep 1 08:40:41.506 UTC: %BGP-3-NOTIFICATION: sent to neighbor xxx.xxx.xxx.xxx 3/11 (invalid or corrupt AS path) 11 bytes 40020802 033C3424 580097 > > If so, have they configured "no bgp enforce-first-as" in their BGP router > config? > > Simon From nanog at ics-il.net Wed Sep 23 21:20:55 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 23 Sep 2015 16:20:55 -0500 (CDT) Subject: 4 byte ASNs through OpenBGPd to old Cisco IOS In-Reply-To: <5603175B.2000000@antient.org> Message-ID: <720459609.7235.1443043324271.JavaMail.mhammett@ThunderFuck> Fearing you might be on here, I tried to be fairly non-offensive in my post. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Richard Irving" To: "Simon Lockhart" , "Mike Hammett" Cc: "NANOG" Sent: Wednesday, September 23, 2015 4:19:23 PM Subject: Re: 4 byte ASNs through OpenBGPd to old Cisco IOS They did, and it now formed peering with the RSD. Thanks! 12.4.(24)T is the first version from that IOS train that natively supports 4 byte ASN's. We can upgrade at a more convenient time and date. :-) On 09/23/2015 05:04 PM, Simon Lockhart wrote: > On Wed Sep 23, 2015 at 03:37:31PM -0500, Mike Hammett wrote: >> Do any of you have any useful input other than they need to upgrade their IOS >> to something newer than 4.5 years old? > I recently went through a very similar issue, and was convinced it was related > to 32 bit ASNs. > > Are they seeing this error? > Sep 1 08:40:41.506 UTC: %BGP-3-NOTIFICATION: sent to neighbor xxx.xxx.xxx.xxx 3/11 (invalid or corrupt AS path) 11 bytes 40020802 033C3424 580097 > > If so, have they configured "no bgp enforce-first-as" in their BGP router > config? > > Simon From rirving at antient.org Wed Sep 23 21:47:24 2015 From: rirving at antient.org (Richard Irving) Date: Wed, 23 Sep 2015 17:47:24 -0400 Subject: 4 byte ASNs through OpenBGPd to old Cisco IOS In-Reply-To: <720459609.7235.1443043324271.JavaMail.mhammett@ThunderFuck> References: <720459609.7235.1443043324271.JavaMail.mhammett@ThunderFuck> Message-ID: <56031DEC.3040101@antient.org> FWIW, I have single digit NANOG shirts in my closet... of course, I couldn't /*fit* into them/... anymore. It has been almos_t_ 20 years..... Time flies.... eh ? Seems like just yesterday Bill, John, I and /*Moses*/ were all having lunch in Denver. ;-) On 09/23/2015 05:20 PM, Mike Hammett wrote: > Fearing you might be on here, I tried to be fairly non-offensive in my > post. ;-) > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ------------------------------------------------------------------------ > *From: *"Richard Irving" > *To: *"Simon Lockhart" , "Mike Hammett" > > *Cc: *"NANOG" > *Sent: *Wednesday, September 23, 2015 4:19:23 PM > *Subject: *Re: 4 byte ASNs through OpenBGPd to old Cisco IOS > Typo. > They did, and it *has* now formed peering with the RSD. > > Thanks! > > 12.4.(24)T is the first version from that IOS train that natively > supports 4 byte ASN's. > > We can upgrade at a more convenient time and date. > > :-) > > On 09/23/2015 05:04 PM, Simon Lockhart wrote: > > On Wed Sep 23, 2015 at 03:37:31PM -0500, Mike Hammett wrote: > >> Do any of you have any useful input other than they need to upgrade > their IOS > >> to something newer than 4.5 years old? > > I recently went through a very similar issue, and was convinced it > was related > > to 32 bit ASNs. > > > > Are they seeing this error? > > Sep 1 08:40:41.506 UTC: %BGP-3-NOTIFICATION: sent to neighbor > xxx.xxx.xxx.xxx 3/11 (invalid or corrupt AS path) 11 bytes 40020802 > 033C3424 580097 > > > > If so, have they configured "no bgp enforce-first-as" in their BGP > router > > config? > > > > Simon > > From jamesb2147 at gmail.com Thu Sep 24 00:01:19 2015 From: jamesb2147 at gmail.com (Sean Hunter) Date: Wed, 23 Sep 2015 19:01:19 -0500 Subject: Recent trouble with QUIC? Message-ID: Hi all, I work for a 2500 user university and we've seen some odd behavior recently. 2-4 weeks ago we started seeing Google searches that would fail for ~2 minutes, or disconnects in Gmail briefly. This week, and particularly in the last 2-3 days, we've had reports from numerous users on campus, even those who generally do not complain unless an issue has been ongoing for a while. Those reports include Drive disconnecting, searches failing, Gmail presenting a "007" error, and calendar failing to create events. In fact, the issue became so widespread today, that the campus paper is writing about it as a last minute article before they're weekly publication's deadline this evening. (Important in our little world where we try to look good.) We aren't really staffed or equipped to figure out exactly what's happening (and issues are sporadic, so packet captures are difficult, to say the least), but we found that disabling QUIC dramatically and immediately improved the experience of a couple of users on campus. We're recommending via the paper that others do so as well. What I'm curious about is: a) Has anyone here had a similar experience? Was the root cause QUIC in your case? b) Has anyone noticed anything remotely similar in the last few weeks/days/today? We're an Apps domain, so this may be specific to universities in the Apps universe. If anyone has any useful information or hints, or if someone from Google would like more information, please feel free to contact me, on or off list. Thanks for reading and have a great night everyone! Happy Wednesday! From bensons at queuefull.net Thu Sep 24 00:14:37 2015 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 23 Sep 2015 17:14:37 -0700 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: Hi, Sean. I had precisely this experience, mostly noticed just in the past day or so. I assumed it was an effect of the firewall/NAT setup that my corporate IT network has implemented, because it often is a culprit in these kind of situations... But noticing that it was only for QUIC connections to Google (I likewise use Apps hosted email) I just turned off QUIC in Chrome and the problem went away. I have no real insight about the issue beyond that. Except to say that the packets captures I performed were not very useful to me, personally, because encrypted QUIC traffic isn't very revealing in Wireshark. :) Though I may simply be missing some clue and/or skill in making sense of it. I guess I'm glad to hear that others such as yourself are seeing the same problem. Because now I don't have to harass my corporate IT dept. Instead we can look forward to speculation about Google, QUIC adoption in the near future, etc. Cheers, -Benson On Wednesday, September 23, 2015, Sean Hunter wrote: > Hi all, > > I work for a 2500 user university and we've seen some odd behavior > recently. 2-4 weeks ago we started seeing Google searches that would fail > for ~2 minutes, or disconnects in Gmail briefly. This week, and > particularly in the last 2-3 days, we've had reports from numerous users on > campus, even those who generally do not complain unless an issue has been > ongoing for a while. Those reports include Drive disconnecting, searches > failing, Gmail presenting a "007" error, and calendar failing to create > events. > > In fact, the issue became so widespread today, that the campus paper is > writing about it as a last minute article before they're weekly > publication's deadline this evening. (Important in our little world where > we try to look good.) > > We aren't really staffed or equipped to figure out exactly what's happening > (and issues are sporadic, so packet captures are difficult, to say the > least), but we found that disabling QUIC dramatically and immediately > improved the experience of a couple of users on campus. We're recommending > via the paper that others do so as well. > > What I'm curious about is: > > a) Has anyone here had a similar experience? Was the root cause QUIC in > your case? > > b) Has anyone noticed anything remotely similar in the last few > weeks/days/today? > > We're an Apps domain, so this may be specific to universities in the Apps > universe. > > If anyone has any useful information or hints, or if someone from Google > would like more information, please feel free to contact me, on or off > list. > > Thanks for reading and have a great night everyone! Happy Wednesday! > From cb.list6 at gmail.com Thu Sep 24 01:43:43 2015 From: cb.list6 at gmail.com (Ca By) Date: Wed, 23 Sep 2015 18:43:43 -0700 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: On Wednesday, September 23, 2015, Sean Hunter wrote: > Hi all, > > I work for a 2500 user university and we've seen some odd behavior > recently. 2-4 weeks ago we started seeing Google searches that would fail > for ~2 minutes, or disconnects in Gmail briefly. This week, and > particularly in the last 2-3 days, we've had reports from numerous users on > campus, even those who generally do not complain unless an issue has been > ongoing for a while. Those reports include Drive disconnecting, searches > failing, Gmail presenting a "007" error, and calendar failing to create > events. > > In fact, the issue became so widespread today, that the campus paper is > writing about it as a last minute article before they're weekly > publication's deadline this evening. (Important in our little world where > we try to look good.) > > We aren't really staffed or equipped to figure out exactly what's happening > (and issues are sporadic, so packet captures are difficult, to say the > least), but we found that disabling QUIC dramatically and immediately > improved the experience of a couple of users on campus. We're recommending > via the paper that others do so as well. > > What I'm curious about is: > > a) Has anyone here had a similar experience? Was the root cause QUIC in > your case? > > b) Has anyone noticed anything remotely similar in the last few > weeks/days/today? > > We're an Apps domain, so this may be specific to universities in the Apps > universe. > > If anyone has any useful information or hints, or if someone from Google > would like more information, please feel free to contact me, on or off > list. > > Thanks for reading and have a great night everyone! Happy Wednesday! > Be believe you can safely block udp port 443 and 80 outbound safely if you need a solution that scales better. This will trigger quic to fall back to tcp CB From rdobbins at arbor.net Thu Sep 24 02:01:37 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 24 Sep 2015 09:01:37 +0700 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: <8587D5E9-FC37-4BCE-A3F1-18228E940CE9@arbor.net> On 24 Sep 2015, at 7:01, Sean Hunter wrote: > If anyone has any useful information or hints I wonder if large-scale QoS and/or ACLing being done at some ISP edges in response to UDP reflection/amplification attacks may be a factor? It's not very smart of those working on QUIC to've thrown it into the UDP cesspit, precisely because of the possibility of this sort of thing. I have zero evidence this what's taking place in the OP's case, mind - but it's something to investigate, and ought to be at least somewhat inferable via packet captures and/or flow telemetry analysis. ----------------------------------- Roland Dobbins From paras at protrafsolutions.com Thu Sep 24 02:01:24 2015 From: paras at protrafsolutions.com (Paras) Date: Wed, 23 Sep 2015 22:01:24 -0400 Subject: Huge latency/packet loss between Hibernia and NTT at New York Message-ID: <56035974.80806@protrafsolutions.com> Hi all, Is anyone else seeing high latency and huge packet loss at NTT's NYC location? Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. hosted-by.reliablesite.net 0.0% 92 0.7 1.5 0.7 6.6 1.7 2. 108.61.244.105 0.0% 91 0.2 0.2 0.2 0.4 0.0 3. vl210-br2.pnj1.choopa.net 0.0% 91 7.0 3.3 0.2 12.7 4.2 4. ae-33.r05.nycmny01.us.bb.gin.ntt.net 0.0% 91 1.7 1.8 1.3 3.5 0.5 5. xe-0-4-0-35.r05.nycmny01.us.ce.gin.ntt.net 1.0% 91 101.1 101.1 100.7 107.0 0.7 6. eth1-4.core1.nyc4.us.as5580.net 6.6% 91 105.7 105.5 101.3 114.0 4.2 7. eth1-4.r1.dal1.us.as5580.net 7.7% 91 101.6 102.1 101.3 128.0 3.1 8. new-jersey.ddos-filter.as63990.net 8.8% 91 101.9 101.9 101.6 102.0 0.1 9. ??? 10. ??? 11. ??? 12. ??? 13. ??? 14. ??? 15. protraf.ddos-filter.as63990.net 8.8% 91 101.9 101.9 101.7 102.3 0.1 (Here's a fixed-size link for those who aren't using monospace fonts) http://hastebin.com/sivorejalu.avrasm At around hop 5 NTT completely drops the ball From srihari at cse.sc.edu Thu Sep 24 03:35:47 2015 From: srihari at cse.sc.edu (Srihari Nelakuditi) Date: Wed, 23 Sep 2015 23:35:47 -0400 Subject: Call for Participation in IEEE ICNP 2015 (Early Registration Deadline is Friday the 25th) Message-ID: <56036F93.9090000@cse.sc.edu> Call for Participation in IEEE ICNP 2015 Early Registration Deadline: September 25 Student Travel Grant Deadline: September 25 http://icnp15.cs.ucr.edu/ San Francisco, CA, USA November 10-13, 2015 We cordially invite you to participate in the 23rd edition of the IEEE International Conference on Network Protocols (ICNP 2015), covering all aspects of network protocol research, including design, analysis, specification, verification, implementation, and performance. ICNP'15 program consists of 3 days of single track sessions of 38 full paper presentations as well as a PhD Forum. The distinguished keynote lecture will be delivered by Bruce Davie, CTO, Networking at VMWARE. Associated with ICNP'15 are two workshops, COntrol, Operation, and appLication in SDN Protocols (CoolSDN) and GENI Network Innovators Community Event (NICE). GENI NICE is a premier event for researchers and educators to demonstrate, present research results and discuss works in progress related to the NSF GENI testbed. Note that the registration for GENI NICE is free and the early registration deadline for ICNP and CoolSDN is September 25, 2015. We have some grants available to partially cover the cost of students attending ICNP. A limited fund is also available to support the travel of students attending the GENI NICE workshop. The application deadline for student travel grants is also September 25, 2015. Further details on the conference are available at http://icnp15.cs.ucr.edu/ We are looking forward to seeing you in San Francisco, USA. The ICNP'15 Organization Committee From charles at phukish.com Thu Sep 24 03:41:45 2015 From: charles at phukish.com (Charles van Niman) Date: Wed, 23 Sep 2015 22:41:45 -0500 Subject: Huge latency/packet loss between Hibernia and NTT at New York In-Reply-To: <56035974.80806@protrafsolutions.com> References: <56035974.80806@protrafsolutions.com> Message-ID: Do you happen to have a copy of the path going in the other direction? Based on this it seems that the issue starts after this leaves NTT. /Charles On Wed, Sep 23, 2015 at 9:01 PM, Paras wrote: > Hi all, > > Is anyone else seeing high latency and huge packet loss at NTT's NYC > location? > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. hosted-by.reliablesite.net 0.0% 92 0.7 1.5 0.7 6.6 1.7 > 2. 108.61.244.105 0.0% 91 0.2 0.2 0.2 0.4 0.0 > 3. vl210-br2.pnj1.choopa.net 0.0% 91 7.0 3.3 0.2 12.7 4.2 > 4. ae-33.r05.nycmny01.us.bb.gin.ntt.net 0.0% 91 1.7 1.8 1.3 3.5 > 0.5 > 5. xe-0-4-0-35.r05.nycmny01.us.ce.gin.ntt.net 1.0% 91 101.1 101.1 100.7 > 107.0 0.7 > 6. eth1-4.core1.nyc4.us.as5580.net 6.6% 91 105.7 105.5 101.3 114.0 > 4.2 > 7. eth1-4.r1.dal1.us.as5580.net 7.7% 91 101.6 102.1 101.3 128.0 3.1 > 8. new-jersey.ddos-filter.as63990.net 8.8% 91 101.9 101.9 101.6 102.0 > 0.1 > 9. ??? > 10. ??? > 11. ??? > 12. ??? > 13. ??? > 14. ??? > 15. protraf.ddos-filter.as63990.net 8.8% 91 101.9 101.9 101.7 102.3 > 0.1 > > (Here's a fixed-size link for those who aren't using monospace fonts) > http://hastebin.com/sivorejalu.avrasm > > At around hop 5 NTT completely drops the ball > From web at typo.org Thu Sep 24 04:15:00 2015 From: web at typo.org (Wayne E Bouchard) Date: Wed, 23 Sep 2015 21:15:00 -0700 Subject: Ear protection In-Reply-To: <5602CF94.4030409@pari.edu> References: <295C9FCB-3121-4756-9FD1-847644808E12@neilltech.com> <5602CF94.4030409@pari.edu> Message-ID: <20150924041500.GA10689@wakko.typo.org> So I intended to provide a few short comments on this but got on a roll. The below may be of more or less use to you but this is the way I look at things. Listening to music isn't all that bad a means of dealing with noise for shorter periods such as the odd onsite engineers have to do because either you're out of techs or it's a really complicated or delecate job and it requires more care than the average datacenter tech or (heaven forbid) remote hands can provide (because they don't normally do that stuff), especially if you're either using ear buds or full cup over the hear headphones because the mere fact of wearing these will probably cut 5-10db off the ambient. (I have a pair I use for mixing and production use that do much better than that even.) Second, the presence of music, as long as it ain't overly loud itself, tends to also not merely cover but it gets the ear doing different things so it's no longer focusing on the particular frequency set of the fans. If you're a datacenter or field tech, noise canceling headphones are basically a must. If that's not your bag and you don't need to be on the phone (I strongly advocate electronic means of communication such as google chat, SMS, irc, or otherwise just because it's more certain and doesn't require you to shout or listen to very loud background noise), then go with foam ear plugs. Carry a small package of them in your bag. They also tend to irritate your ears less than platic ear plugs and ear buds because the form to the ear, not force tissue around. On noise standards, accuracy of the meter isn't really important (as long as it isn't useless) because it's more of a "I should be thinking about it" threshold. But make absolutely sure you are measuring the A weighted noise curve, not the C weighted or your not measuring the noise that will most impact your hearing. You should also not rely on your employer providing ear protection. You should take it on yourself to guard against tinitis. (No fun. I have a touch of it in my left ear but not from music or concerts. From randomness. Overly loud music or sharp noises can set it off and it'll annoy me for at least a couple of hours until it drops back down to easily ignorable levels.) I just had to do 6 hours of wiring and cable management in some racks I've been helping assemble, meaning my head and hands were not in the middle of the aisle, but right behind the machines. It was only when I stepped away from the racks after the first hour or so to get supplies that I realized, "MAN, that's loud!" So if you're routinely in that environment, make ear protection a habit. You can buy a better set of headphones. You can't buy a better set of ears. Note also that in the last 15 years, fan speeds and drive speeds have increased as equipment has gotten more and more dense and as a result manufacturers have had to up the air velocity in order to cool the gear and that has generally meant small, steeply pitched, very fast fans. (This is especially true of servers built to be densely rack mounted and yet provide capacilities to house lots and lots of drives in that small footprint. Look at your average 1U crammed with these small drives. Have to get air through there somehow.) This has caused a shift in frequency as well as an increase in intensity. So the characteristics of the noise has changed. That's important because the current noise is closer to the center of our range of hearing and don't forget the harmonics. So not only has the noise gotten louder, it is now in a range where our ears are more sensitive to it and therefore it is more important to take measures to guard against. I happen to have a measurement mic and a decent spectrum analyzer plugin. I may take some measurements just to illustrate the makeup at various points. May even be worth a paper if I can get some equipment and colo vendors to cooperate and feed me data. -Wayne On Wed, Sep 23, 2015 at 12:13:08PM -0400, Lamar Owen wrote: > On 09/23/2015 10:09 AM, Keith Stokes wrote: > >Since I???m in our colo facility this morning, I decided to put some > >numbers on it in my little isolated corner with lots of blowers running. > > > >According to my iPhone SPL meter, average SPL is 81 - 82 dB with peaks 88 > >- 89 dB. > > > > > With SPL that close to the recommended maximum, the accuracy of the SPL > measurement is rather critical. I would not trust my smartphone's mic > to have sufficient accuracy to protect my hearing unless it is > calibrated to a known source SPL using pink noise of a particular > weight. The calibration SLM should be a 'real' SLM, such as a Bruel & > Kjaer Type 2250 or similar with proper transducers. (Yes, I know, a B&K > 2250 will set you back nearly $4K, but, just what is your hearing > worth? A pair of hearing aids will set you (or your insurance company > at least) back $4K too....). I used a vintage B&K transducer with a > custom-built SLM-rated spec-an years ago at a local manufacturer's sound > testing lab; the manufacturer makes ballasts and luminaires for HID > lighting, and measuring ballast noise is a big deal. But reasonably > accurate SLM's are available for less than $500 (some are available for > less than $100, but you get what you pay for....). > > The particular whine of high-speed fans is a known risky noise source, > particularly white noise, due to the high frequency content (140dB SPL > at 45Hz is not as harmful as 140dB at 3kHz or 15kHz due to the outer > ears' acting as waveguide-beyond-cutoff attenuators (and cavity > resonators, too, for that matter). Spinning drives are no better, > particularly 15k RPM drives. > > If it's at all uncomfortable, wear the earplugs. You're already having > to shout to be heard anyway. > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From web at typo.org Thu Sep 24 04:22:07 2015 From: web at typo.org (Wayne E Bouchard) Date: Wed, 23 Sep 2015 21:22:07 -0700 Subject: Ear protection In-Reply-To: References: <56027213.6030700@foobar.org> Message-ID: <20150924042207.GB10689@wakko.typo.org> If you go the "molded to my ear" route, do not forget that your ears will tend to change over time and these must be replaced periodically or they'll become uncomfortable and less effective. (I forget what the recommendation is but I think every 1-2 years at the outside.) On Wed, Sep 23, 2015 at 10:29:25AM -0400, David Hubbard wrote: > I wear one of two things: > > 1) The 3M Peltor 105 ear muffs which offer 30db reduction. > I keep them in my car because I also use them for the gun > range, they fit snug but not annoying. They're only $18 > on amazon: http://tinyurl.com/peltor105 > There's also a behind the head bar if you don't like the over > the top kind. > > 2) A lot more expensive, but with a side benefit; I have > a custom set of ear plugs that I use for go kart racing so > I can have radio communication. You can get them online > or at most race tracks on a race day. Someone, or DIY at > home, will use a big syringe to squirt the mold liquid in > your ear, it sits for 60 seconds, then they pull it out and > send it off to have the ear plugs made. They're very good > at eliminating noise but have the side benefit of a > headphone plug so you can still use your phone, ipod, etc. > while you're in the data center. :-) > > David > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > > Nick Hilliard > > Sent: Wednesday, September 23, 2015 5:34 AM > > To: nanog at nanog.org > > Subject: Ear protection > > > > What are people using for ear protection for datacenters > > these days? I'm down to my last couple of corded 3M 1110: > > > > http://www.shop3m.com/3m-corded-earplugs-hearing-conservation- > > 1110.html > > > > These work reasonably well in practice, with a rated nominal > > noise reduction rate of 29dB. Some people find them > > uncomfortable, but they work well for me. > > > > There are other ear plugs with rated NRR of up to 32-33dB. > > Anyone have any opinions on what brands work well for them? > > > > Nick > > > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From Justin.Sherrill at americanrocksalt.com Wed Sep 23 12:27:27 2015 From: Justin.Sherrill at americanrocksalt.com (Justin Sherrill) Date: Wed, 23 Sep 2015 12:27:27 +0000 Subject: Ear protection In-Reply-To: <56027213.6030700@foobar.org> References: <56027213.6030700@foobar.org> Message-ID: <5530E63C67442F49B1DBE98373E6E59C0DAEAD1B@mercury.ROCKNET.local> > What are people using for ear protection for datacenters these days? > I'm down to my last couple of corded 3M 1110: http://www.moldex.com/hearing-protection/foam-earplugs/pura-fit.php This are cheap, but that's sort of the point - you can put a bin, or several bins, filled with them on the wall outside a noisy room, and they're always available. This is working on the principle that the cheap ear plugs that always get used are better than the high-end ear protection that keeps getting forgotten in the office or left out of bags because it's bulky. My workplace has many constantly noisy areas, other than the datacenter, so this may be a somewhat different scenario than yours. Also, a spare pair helped me survive a Panic! At The Disco concert last week, so I'm all for 'em. From donnightin at gmail.com Wed Sep 23 23:18:24 2015 From: donnightin at gmail.com (Don Nightingale) Date: Wed, 23 Sep 2015 19:18:24 -0400 Subject: Ear protection In-Reply-To: References: <201509231253.t8NCrfLc037696@aurora.sol.net> Message-ID: <56033340.2030605@gmail.com> Seconded. I wear my Shure 425s with foam plugs most of my waking hours, they are excellent at blocking outside noise and sound pretty good to boot. On 9/23/2015 11:02 AM, Eric Rogers wrote: > I use earphones for the phone and alerts function, and because they are > noise cancelling, they lower the db of noise. I use Shure SE215. > > Eric Rogers > PDS Connect > www.pdsconnect.me > (317) 831-3000 x200 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bryan Holloway > Sent: Wednesday, September 23, 2015 9:48 AM > To: Joe Greco; jim deleskie > Cc: Alex Rubenstein; NANOG > Subject: Re: Ear protection > > > On 9/23/15, 7:53 AM, "NANOG on behalf of Joe Greco" > wrote: > >>> Maybe I've always listened to my music to loud and spend the bulk of >>> time via ssh, but I've never felt a need for hearing protection in a >>> DC, is this generally an issue for people? >> Depends on how long and how noisy. >> >> As I've gotten older, I find loud noise in general is less tolerable, >> so I've taken to always keeping a pair of earplugs with me. It makes >> being around loud music, etc., much more enjoyable. >> >> Long term exposure to noise is widely considered to be a hazard, but >> walking into an average data center for an hour once a month is >> probably not that risky. >> >> ... JG >> > Depends on the type of "noise" too. > > Datacenters generate (more or less) white noise, which is particularly > harmful long-term to the cilia in your ears because it excites all of > them all of the time. A loud datacenter is much worse than a loud rock > band, IMO. > > I personally use Bose noise-canceling headphones. > > From anoop at alumni.duke.edu Thu Sep 24 00:30:09 2015 From: anoop at alumni.duke.edu (Anoop Ghanwani) Date: Wed, 23 Sep 2015 17:30:09 -0700 Subject: Segment Routing for L2VPN? Message-ID: It depends on what type of L2VPN we are talking about. If we are talking about VPLS (where we learn from the data path) changes are needed in order to make it work with segment routing. Basically, the VC label must be assigned and used in such a way that it indicates not only the service for the packet, but also the PE from which it originated. That is because with SR, we would have lost the path (PW) that the packet used to get to the destination PE. If we are talking about BGP E-VPN where data path learning is not used, then it should work with segment routing without any changes. Anoop On Mon, Sep 21, 2015 at 11:32 AM, Jeff Tantsura wrote: > Hi, > > In most well designed IP routing stacks the way to get to a labeled > (tunneled) next hop is decoupled from a service, so if a service requires > such next hop it is upto (usually RIB) to return one (best, multiple might > exist) which would be used for forwarding. If it is a Segment Routed one > so it will then be used. > > Cheers, > Jeff > > -----Original Message----- > From: Mohan Nanduri > Date: Sunday, September 20, 2015 at 12:59 PM > To: Jason Lixfeld > Cc: "nanog at nanog.org" > Subject: Re: Segment Routing for L2VPN? > > >No, it works with L2VPNs also. Outer label is going to be SR label and > >inner label is your L2VPN label. > > > >Cheers, > >-Mohan > > > > > >On Sun, Sep 20, 2015 at 3:23 PM, Jason Lixfeld wrote: > >> Hello! > >> > >> I've been doing some reading recently on Segment Routing. By all > >>accounts, it seems that the (only?) implementation for SR supports > >>L3VPN. Am I dumb and just missing the L2VPN bits, or is L3VPN simply > >>the extent of the first generation? > >> > >> Sent from my iPhone > > From jmbullen21 at gmail.com Wed Sep 23 21:38:02 2015 From: jmbullen21 at gmail.com (Jason Bullen) Date: Wed, 23 Sep 2015 17:38:02 -0400 Subject: Service Providers behaviour for dual homed enterprises Message-ID: I've always worked in enterprise only so I thought you guys might be able to help me with this one. We are dual homed to Verizon and AT&T. We prepend all our prefixes out AT&T to make them least preferred. During a recent issue we found some users were coming in via AT&T. Using various looking glasses it looks like if I use an AT&T server(route-server.ip.att.net) the best path is the prepended route through AT&T; in fact,I don't even see the VZB route. If I use a 3rd party looking glass(router-server.he.net) I see what I anticipated, which is the shorter AS-Path through VZB. So if my research is correct, the internet prefers Verizon UNLESS they are a direct AT&T customer then they would use the AT&T circuit. Is this a standard practice that I should assume to encounter? Thanks in advance From jared at puck.nether.net Thu Sep 24 05:09:28 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 24 Sep 2015 01:09:28 -0400 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: References: Message-ID: <4CDDCA76-2638-43F4-B748-18BA35AD4B22@puck.nether.net> > On Sep 23, 2015, at 5:38 PM, Jason Bullen wrote: > > I've always worked in enterprise only so I thought you guys might be able > to help me with this one. > We are dual homed to Verizon and AT&T. We prepend all our prefixes out > AT&T to make them least preferred. During a recent issue we found some > users were coming in via AT&T. Using various looking glasses it looks like > if I use an AT&T server(route-server.ip.att.net) the best path is the > prepended route through AT&T; in fact,I don't even see the VZB route. If I > use a 3rd party looking glass(router-server.he.net) I see what I > anticipated, which is the shorter AS-Path through VZB. > > So if my research is correct, the internet prefers Verizon UNLESS they are > a direct AT&T customer then they would use the AT&T circuit. > Is this a standard practice that I should assume to encounter? Yes. From clinton at scripty.com Thu Sep 24 07:16:59 2015 From: clinton at scripty.com (Clinton Work) Date: Thu, 24 Sep 2015 01:16:59 -0600 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: References: Message-ID: <1443079019.1308219.392224921.061129D1@webmail.messagingengine.com> Many transit providers support BGP communities to modify how your announced routes are treated within their network. A quick search shows that AT&T supports BGP community 7018:70 to lower the default local-pref 100 down to 70 (below peer routes). If you tag your AT&T announced routes with BGP community 7018:70, then even AT&T customers should prefer to enter via Verizon. Clinton. On Wed, Sep 23, 2015, at 03:38 PM, Jason Bullen wrote: > So if my research is correct, the internet prefers Verizon UNLESS they > are > a direct AT&T customer then they would use the AT&T circuit. > Is this a standard practice that I should assume to encounter? > > Thanks in advance From mark.tinka at seacom.mu Thu Sep 24 07:51:55 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 24 Sep 2015 09:51:55 +0200 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: References: Message-ID: <5603AB9B.2030501@seacom.mu> On 23/Sep/15 23:38, Jason Bullen wrote: > I've always worked in enterprise only so I thought you guys might be able > to help me with this one. > We are dual homed to Verizon and AT&T. We prepend all our prefixes out > AT&T to make them least preferred. During a recent issue we found some > users were coming in via AT&T. Using various looking glasses it looks like > if I use an AT&T server(route-server.ip.att.net) the best path is the > prepended route through AT&T; in fact,I don't even see the VZB route. If I > use a 3rd party looking glass(router-server.he.net) I see what I > anticipated, which is the shorter AS-Path through VZB. > > So if my research is correct, the internet prefers Verizon UNLESS they are > a direct AT&T customer then they would use the AT&T circuit. > Is this a standard practice that I should assume to encounter? ISP's will generally set a higher LOCAL_PREF toward their customers than to any other destination out of their network. It's the money shot. Mark. From mike.meredith at port.ac.uk Thu Sep 24 08:10:08 2015 From: mike.meredith at port.ac.uk (Mike Meredith) Date: Thu, 24 Sep 2015 09:10:08 +0100 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: <20150924091008.56a3a3c0@scrofula.eps.is.port.ac.uk> On Wed, 23 Sep 2015 19:01:19 -0500, Sean Hunter may have written: > a) Has anyone here had a similar experience? Was the root cause QUIC > in your case? Yes. No; in our case our firewall (a PA5060 running PANOS6.1.3 at the time) was allowing some QUIC packets through, but not others. As it was newly deployed at the time, it was soon blamed :-\ > b) Has anyone noticed anything remotely similar in the last few > weeks/days/today? Only because I enabled QUIC within Chrome on our test network to verify that it was still a problem. > We're an Apps domain, so this may be specific to universities in the > Apps universe. As are we. -- Mike Meredith, University of Portsmouth Principal Systems Engineer, Hostmaster, Security, and Timelord! From charlesg at unixrealm.com Thu Sep 24 09:23:23 2015 From: charlesg at unixrealm.com (LaDerrick H.) Date: Thu, 24 Sep 2015 11:23:23 +0200 Subject: Fw: important Message-ID: <0000d71216d5$b38e5252$dc5e01f0$@unixrealm.com> Hey friend! Important message, please visit LaDerrick H. From charlesg at unixrealm.com Thu Sep 24 09:23:40 2015 From: charlesg at unixrealm.com (Pomposello Sarah BDF HPN) Date: Thu, 24 Sep 2015 11:23:40 +0200 Subject: Fw: important Message-ID: <00003d53f72c$2a82ed97$b3dc8e9d$@unixrealm.com> Hey friend! Important message, please visit Pomposello Sarah BDF HPN From gstammw at gmx.net Thu Sep 24 12:55:51 2015 From: gstammw at gmx.net (Gunther Stammwitz) Date: Thu, 24 Sep 2015 14:55:51 +0200 Subject: SPAM: AW: important Message-ID: <002001d0f6c8$59011680$0b034380$@gmx.net> This is unbelievable: We have seen these kinds of spam-messages over the last weeks on different mail accounts and still Spamassassin & others don't recognize them. Isn't a topic of "Fw: important" compared with the greeting "Hey friend" something that must be spam? Now Nanog was hit which is really annoying. Yes, this message might originate from an authenticated sender and the (faked) sender's domain might light spf and so on - but where is artificial intelligence when one needs it? Time to charge for emails so that this channel will become too expensive for spammers, isn't it? > -----Urspr?ngliche Nachricht----- > Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Pomposello > Sarah BDF HPN > Gesendet: Donnerstag, 24. September 2015 11:24 > An: Brielle Bruns; nanog group; William Herrin > Betreff: Fw: important > > Hey friend! > > > > Important message, please visit > > > > Pomposello Sarah BDF HPN From tshaw at oitc.com Thu Sep 24 13:20:12 2015 From: tshaw at oitc.com (TR Shaw) Date: Thu, 24 Sep 2015 09:20:12 -0400 Subject: SPAM: AW: important In-Reply-To: <002001d0f6c8$59011680$0b034380$@gmx.net> References: <002001d0f6c8$59011680$0b034380$@gmx.net> Message-ID: <5D00465C-5DC1-46A4-9764-873701A5E528@oitc.com> Strange as it has been listed in SURBL for ever since the site was cracked. scm-70.com.wild.surbl.org has address 127.0.0.68 > On Sep 24, 2015, at 8:55 AM, Gunther Stammwitz wrote: > > This is unbelievable: > We have seen these kinds of spam-messages over the last weeks on different > mail accounts and still Spamassassin & others don't recognize them. > Isn't a topic of "Fw: important" compared with the greeting "Hey friend" > something that must be spam? > Now Nanog was hit which is really annoying. > > Yes, this message might originate from an authenticated sender and the > (faked) sender's domain might light spf and so on - but where is artificial > intelligence when one needs it? > > Time to charge for emails so that this channel will become too expensive for > spammers, isn't it? > > >> -----Urspr?ngliche Nachricht----- >> Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Pomposello >> Sarah BDF HPN >> Gesendet: Donnerstag, 24. September 2015 11:24 >> An: Brielle Bruns; nanog group; William Herrin >> Betreff: Fw: important >> >> Hey friend! >> >> >> >> Important message, please visit >> >> >> >> Pomposello Sarah BDF HPN > > From bill at herrin.us Thu Sep 24 13:21:02 2015 From: bill at herrin.us (William Herrin) Date: Thu, 24 Sep 2015 09:21:02 -0400 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: References: Message-ID: On Wed, Sep 23, 2015 at 5:38 PM, Jason Bullen wrote: > So if my research is correct, the internet prefers Verizon UNLESS they are > a direct AT&T customer then they would use the AT&T circuit. > Is this a standard practice that I should assume to encounter? Hi Jason, That's normal. Verizon does it too. Both have "community" tags which you can attach to your route advertisement. Each will have one that indicates they should give external routes the same "local pref" as the route you announce to them. Tagging your route announcement with the proper community will cause them to route based on AS path length as you expect. Welcome to the little gotchas of using BGP. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From list at satchell.net Thu Sep 24 13:39:54 2015 From: list at satchell.net (Stephen Satchell) Date: Thu, 24 Sep 2015 06:39:54 -0700 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: References: Message-ID: <5603FD2A.7000706@satchell.net> On 09/23/2015 02:38 PM, Jason Bullen wrote: > I've always worked in enterprise only so I thought you guys might be able > to help me with this one. > We are dual homed to Verizon and AT&T. We prepend all our prefixes out > AT&T to make them least preferred. During a recent issue we found some > users were coming in via AT&T. Using various looking glasses it looks like > if I use an AT&T server(route-server.ip.att.net) the best path is the > prepended route through AT&T; in fact,I don't even see the VZB route. If I > use a 3rd party looking glass(router-server.he.net) I see what I > anticipated, which is the shorter AS-Path through VZB. > > So if my research is correct, the internet prefers Verizon UNLESS they are > a direct AT&T customer then they would use the AT&T circuit. > Is this a standard practice that I should assume to encounter? > > Thanks in advance > That's been my experience, and with other sets of providers, too. My current company is dual-homed with AT&T and Charter Fiber. Those customers on UVerse come in the AT&T link no matter what we do with BGP to convince the cloud to let packets come in the fatter pipe. From mark.tinka at seacom.mu Thu Sep 24 13:47:24 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 24 Sep 2015 15:47:24 +0200 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: References: Message-ID: <5603FEEC.9000801@seacom.mu> On 24/Sep/15 15:21, William Herrin wrote: > Hi Jason, > > That's normal. Verizon does it too. Both have "community" tags which > you can attach to your route advertisement. Each will have one that > indicates they should give external routes the same "local pref" as > the route you announce to them. Tagging your route announcement with > the proper community will cause them to route based on AS path length > as you expect. Depending on the provider, this can't always be guaranteed, i.e., that the available LOCAL_PREF values a customer can trigger via a BGP community support anything <= what routes the network considers "external". What's possible (or available) may also be influenced by whether one's upstream is "transit-free" or not, I imagine. Mark. From blake at ispn.net Thu Sep 24 14:05:46 2015 From: blake at ispn.net (Blake Hudson) Date: Thu, 24 Sep 2015 09:05:46 -0500 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: <5603FD2A.7000706@satchell.net> References: <5603FD2A.7000706@satchell.net> Message-ID: <5604033A.8070004@ispn.net> Stephen Satchell wrote on 9/24/2015 8:39 AM: > On 09/23/2015 02:38 PM, Jason Bullen wrote: >> I've always worked in enterprise only so I thought you guys might be >> able >> to help me with this one. >> We are dual homed to Verizon and AT&T. We prepend all our prefixes out >> AT&T to make them least preferred. During a recent issue we found some >> users were coming in via AT&T. Using various looking glasses it >> looks like >> if I use an AT&T server(route-server.ip.att.net) the best path is the >> prepended route through AT&T; in fact,I don't even see the VZB >> route. If I >> use a 3rd party looking glass(router-server.he.net) I see what I >> anticipated, which is the shorter AS-Path through VZB. >> >> So if my research is correct, the internet prefers Verizon UNLESS >> they are >> a direct AT&T customer then they would use the AT&T circuit. >> Is this a standard practice that I should assume to encounter? >> >> Thanks in advance >> > > That's been my experience, and with other sets of providers, too. > > My current company is dual-homed with AT&T and Charter Fiber. Those > customers on UVerse come in the AT&T link no matter what we do with > BGP to convince the cloud to let packets come in the fatter pipe. Jason, while others have offered acknowledgement of the behavior you are seeing as well as solutions, I think it might be relevant to point out that this is simply a matter of BGP best path selection. BGP does not use AS path length (hops) as its primary path selector. Search for "bgp best path selection" to find out more about how BGP selects the best path. As others have noted, local pref is often utilized to control routing and should be your preferred way to control path selection in addition to AS path length. However, the ultimate way to control routing would be to advertise more specific prefixes via the path that you want traffic to flow. --Blake From mailing-lists at brianraaen.com Thu Sep 24 14:12:25 2015 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Thu, 24 Sep 2015 10:12:25 -0400 Subject: Ear protection In-Reply-To: <56033340.2030605@gmail.com> References: <201509231253.t8NCrfLc037696@aurora.sol.net> <56033340.2030605@gmail.com> Message-ID: I normally have a set of Sennheiser HD-380's or HD-280's with my laptop. They have pretty good isolation and seem to make a pretty good difference, also I can either hear my phone or play music with them. When I mow the yard I use a pair of Koss headphones that isolate almost as good as a set of shooting muffs that I have. On Wed, Sep 23, 2015 at 7:18 PM, Don Nightingale wrote: > > Seconded. I wear my Shure 425s with foam plugs most of my waking hours, > they are excellent at blocking outside noise and sound pretty good to boot. > > > On 9/23/2015 11:02 AM, Eric Rogers wrote: > >> I use earphones for the phone and alerts function, and because they are >> noise cancelling, they lower the db of noise. I use Shure SE215. >> >> Eric Rogers >> PDS Connect >> www.pdsconnect.me >> (317) 831-3000 x200 >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bryan Holloway >> Sent: Wednesday, September 23, 2015 9:48 AM >> To: Joe Greco; jim deleskie >> Cc: Alex Rubenstein; NANOG >> Subject: Re: Ear protection >> >> >> On 9/23/15, 7:53 AM, "NANOG on behalf of Joe Greco" >> wrote: >> >> Maybe I've always listened to my music to loud and spend the bulk of >>>> time via ssh, but I've never felt a need for hearing protection in a >>>> DC, is this generally an issue for people? >>>> >>> Depends on how long and how noisy. >>> >>> As I've gotten older, I find loud noise in general is less tolerable, >>> so I've taken to always keeping a pair of earplugs with me. It makes >>> being around loud music, etc., much more enjoyable. >>> >>> Long term exposure to noise is widely considered to be a hazard, but >>> walking into an average data center for an hour once a month is >>> probably not that risky. >>> >>> ... JG >>> >>> Depends on the type of "noise" too. >> >> Datacenters generate (more or less) white noise, which is particularly >> harmful long-term to the cilia in your ears because it excites all of >> them all of the time. A loud datacenter is much worse than a loud rock >> band, IMO. >> >> I personally use Bose noise-canceling headphones. >> >> >> > -- Brian Christopher Raaen Network Architect Zcorum From jmbullen21 at gmail.com Thu Sep 24 14:27:48 2015 From: jmbullen21 at gmail.com (Jason Bullen) Date: Thu, 24 Sep 2015 10:27:48 -0400 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: <5604033A.8070004@ispn.net> References: <5603FD2A.7000706@satchell.net> <5604033A.8070004@ispn.net> Message-ID: Thank you all for answering. I was disregarding Local Pref because the route server I was on was showing 100. That was an error on my part though as it clearly states in the login banner that it is eBGP peering with the AT&T routers hence the local Pref would go back to 100 from its perspective. Again, thanks for the quick and thorough responses. On Thu, Sep 24, 2015 at 10:05 AM, Blake Hudson wrote: > > > Stephen Satchell wrote on 9/24/2015 8:39 AM: > >> On 09/23/2015 02:38 PM, Jason Bullen wrote: >> >>> I've always worked in enterprise only so I thought you guys might be able >>> to help me with this one. >>> We are dual homed to Verizon and AT&T. We prepend all our prefixes out >>> AT&T to make them least preferred. During a recent issue we found some >>> users were coming in via AT&T. Using various looking glasses it looks >>> like >>> if I use an AT&T server(route-server.ip.att.net) the best path is the >>> prepended route through AT&T; in fact,I don't even see the VZB route. >>> If I >>> use a 3rd party looking glass(router-server.he.net) I see what I >>> anticipated, which is the shorter AS-Path through VZB. >>> >>> So if my research is correct, the internet prefers Verizon UNLESS they >>> are >>> a direct AT&T customer then they would use the AT&T circuit. >>> Is this a standard practice that I should assume to encounter? >>> >>> Thanks in advance >>> >>> >> That's been my experience, and with other sets of providers, too. >> >> My current company is dual-homed with AT&T and Charter Fiber. Those >> customers on UVerse come in the AT&T link no matter what we do with BGP to >> convince the cloud to let packets come in the fatter pipe. >> > > Jason, while others have offered acknowledgement of the behavior you are > seeing as well as solutions, I think it might be relevant to point out that > this is simply a matter of BGP best path selection. BGP does not use AS > path length (hops) as its primary path selector. Search for "bgp best path > selection" to find out more about how BGP selects the best path. As others > have noted, local pref is often utilized to control routing and should be > your preferred way to control path selection in addition to AS path length. > However, the ultimate way to control routing would be to advertise more > specific prefixes via the path that you want traffic to flow. > > --Blake > From bob at FiberInternetCenter.com Thu Sep 24 14:49:00 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 24 Sep 2015 07:49:00 -0700 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: <5604033A.8070004@ispn.net> References: <5603FD2A.7000706@satchell.net> <5604033A.8070004@ispn.net> Message-ID: <1e56b449192d0e83e390c70235e622a4.squirrel@66.201.44.180> What Blake just said below works best - I do this MED together with small-ers all the way to india for video conferencing customers sitting in silicon valley. Thank You Bob Evans CTO > > > Stephen Satchell wrote on 9/24/2015 8:39 AM: >> On 09/23/2015 02:38 PM, Jason Bullen wrote: >>> I've always worked in enterprise only so I thought you guys might be >>> able >>> to help me with this one. >>> We are dual homed to Verizon and AT&T. We prepend all our prefixes out >>> AT&T to make them least preferred. During a recent issue we found some >>> users were coming in via AT&T. Using various looking glasses it >>> looks like >>> if I use an AT&T server(route-server.ip.att.net) the best path is the >>> prepended route through AT&T; in fact,I don't even see the VZB >>> route. If I >>> use a 3rd party looking glass(router-server.he.net) I see what I >>> anticipated, which is the shorter AS-Path through VZB. >>> >>> So if my research is correct, the internet prefers Verizon UNLESS >>> they are >>> a direct AT&T customer then they would use the AT&T circuit. >>> Is this a standard practice that I should assume to encounter? >>> >>> Thanks in advance >>> >> >> That's been my experience, and with other sets of providers, too. >> >> My current company is dual-homed with AT&T and Charter Fiber. Those >> customers on UVerse come in the AT&T link no matter what we do with >> BGP to convince the cloud to let packets come in the fatter pipe. > > Jason, while others have offered acknowledgement of the behavior you are > seeing as well as solutions, I think it might be relevant to point out > that this is simply a matter of BGP best path selection. BGP does not > use AS path length (hops) as its primary path selector. Search for "bgp > best path selection" to find out more about how BGP selects the best > path. As others have noted, local pref is often utilized to control > routing and should be your preferred way to control path selection in > addition to AS path length. However, the ultimate way to control routing > would be to advertise more specific prefixes via the path that you want > traffic to flow. > > --Blake > From cboyd at gizmopartners.com Thu Sep 24 14:51:07 2015 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 24 Sep 2015 09:51:07 -0500 Subject: Ear protection In-Reply-To: <201509231233.t8NCX7FP037501@aurora.sol.net> References: <201509231233.t8NCX7FP037501@aurora.sol.net> Message-ID: > On Sep 23, 2015, at 7:33 AM, Joe Greco wrote: > > Passive cooling typically translates to lower performance but also can > be more expensive. $DAYJOB uses an immersion cooling system so it?s higher performance and much quieter. ?Chris From mikea at mikea.ath.cx Thu Sep 24 15:18:34 2015 From: mikea at mikea.ath.cx (mikea) Date: Thu, 24 Sep 2015 10:18:34 -0500 Subject: Ear protection In-Reply-To: References: <201509231233.t8NCX7FP037501@aurora.sol.net> Message-ID: <20150924151834.GA48462@mikea.ath.cx> On Thu, Sep 24, 2015 at 09:51:07AM -0500, Chris Boyd wrote: > > > On Sep 23, 2015, at 7:33 AM, Joe Greco wrote: > > > > Passive cooling typically translates to lower performance but also can > > be more expensive. > > $DAYJOB uses an immersion cooling system so it?s higher performance and much quieter. And at what price differential over active air cooling and over passive cooling? -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From skhosla at neutraldata.com Thu Sep 24 15:36:58 2015 From: skhosla at neutraldata.com (Sameer Khosla) Date: Thu, 24 Sep 2015 15:36:58 +0000 Subject: Ear protection In-Reply-To: <56027213.6030700@foobar.org> References: <56027213.6030700@foobar.org> Message-ID: <49A81EB09F493442B6D259E36251192C0171B32DEC@ndcc-exch1.neutraldata.com> For years we have used the Peltor/3M Bluetooth headsets in the datacenter. Proper hearing protection and noise cancelling mic, with the added bonus of protecting my head a bit when I am up on the ladder in the DC and can easily bang into potentially sharp things. http://goo.gl/ShTCEF They are about $375-$450ish retail, we picked some up on ebay in around $200 brand new. We have about 6 pairs that so far have lasted 8-9+ years with no problems. The only major suggestion if you are going to use them on a regular basis is to get the gel earcup replacements. These seem to be about $60ish. Sk. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Hilliard Sent: Wednesday, September 23, 2015 5:34 AM To: nanog at nanog.org Subject: Ear protection What are people using for ear protection for datacenters these days? I'm down to my last couple of corded 3M 1110: http://www.shop3m.com/3m-corded-earplugs-hearing-conservation-1110.html These work reasonably well in practice, with a rated nominal noise reduction rate of 29dB. Some people find them uncomfortable, but they work well for me. There are other ear plugs with rated NRR of up to 32-33dB. Anyone have any opinions on what brands work well for them? Nick From jgreco at ns.sol.net Thu Sep 24 16:50:43 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 24 Sep 2015 11:50:43 -0500 (CDT) Subject: Ear protection In-Reply-To: Message-ID: <201509241650.t8OGoiE8059329@aurora.sol.net> > > On Sep 23, 2015, at 7:33 AM, Joe Greco wrote: > >=20 > > Passive cooling typically translates to lower performance but also can > > be more expensive. > > $DAYJOB uses an immersion cooling system so it=E2=80=99s higher = > performance and much quieter. That's not typical passive cooling. And it's going to be much more expensive and complicated to implement than "air based" passive cooling, or active air cooling, etc. As an example, many mobile devices are underclocked so that their components dissipate less heat, and may actually vary the clock based in part on current temperature. This allows the device to more easily dissipate heat without active cooling measures, but you get the lowered performance of a slower part. It's totally possible to build quieter gear - we do that kind of work here, as some of you know - but it is a matter of tradeoffs. I can show you a Xeon E3 system that consumes a peak of 100 watts. SSDs for storage, fanless oversized PSU to reduce heat, massive CPU heatsink, and 120MM fans in a 4U chassis. Very quiet running, has a higher tolerance to heat as well. But most people don't want their hypervisors to take 4U of space for a mere 32GB of RAM and 12GHz of CPU. They'd rather stick 300 watts of E5's into a 1U and let it scream away. ... 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 list at satchell.net Thu Sep 24 16:00:03 2015 From: list at satchell.net (Stephen Satchell) Date: Thu, 24 Sep 2015 09:00:03 -0700 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: <5604033A.8070004@ispn.net> References: <5603FD2A.7000706@satchell.net> <5604033A.8070004@ispn.net> Message-ID: <56041E03.7080608@satchell.net> On 09/24/2015 07:05 AM, Blake Hudson wrote: > However, the ultimate way to control routing would be to advertise more > specific prefixes via the path that you want traffic to flow. Tried that, no joy. From rob at invaluement.com Thu Sep 24 16:06:14 2015 From: rob at invaluement.com (Rob McEwen) Date: Thu, 24 Sep 2015 12:06:14 -0400 Subject: SPAM: AW: important In-Reply-To: <5D00465C-5DC1-46A4-9764-873701A5E528@oitc.com> References: <002001d0f6c8$59011680$0b034380$@gmx.net> <5D00465C-5DC1-46A4-9764-873701A5E528@oitc.com> Message-ID: <56041F76.9080601@invaluement.com> On 9/24/2015 9:20 AM, TR Shaw wrote: > Strange as it has been listed in SURBL for ever since the site was cracked. fwiw, likewise, that same spammy domain has been on invaluement's URI blacklist since 9/17/2015 2:27 a.m. (+- a couple of minutes) -- Rob McEwen From blake at ispn.net Thu Sep 24 16:22:53 2015 From: blake at ispn.net (Blake Hudson) Date: Thu, 24 Sep 2015 11:22:53 -0500 Subject: Service Providers behaviour for dual homed enterprises In-Reply-To: <56041E03.7080608@satchell.net> References: <5603FD2A.7000706@satchell.net> <5604033A.8070004@ispn.net> <56041E03.7080608@satchell.net> Message-ID: <5604235D.2080606@ispn.net> Stephen Satchell wrote on 9/24/2015 11:00 AM: > On 09/24/2015 07:05 AM, Blake Hudson wrote: >> However, the ultimate way to control routing would be to advertise more >> specific prefixes via the path that you want traffic to flow. > > Tried that, no joy. I could only assume then that your peers were either not accepting your advertisements or there was an error in your configuration. All routers will choose the most specific route they have when performing destination based routing. This overrides how the route was installed (static, connected, dynamic) or any metrics considered within each routing protocol for its best path selection. From jcurran at arin.net Thu Sep 24 16:34:21 2015 From: jcurran at arin.net (John Curran) Date: Thu, 24 Sep 2015 16:34:21 +0000 Subject: ARIN Region IPv4 Free Pool Reaches Zero References: <56041F06.5090906@arin.net> Message-ID: <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> (Apologies for redistribution, but need to insure that this is seen by all in the region.) The IPv4 free pool for the ARIN region is now depleted; ISPs are encouraged to utilize IPv6 for additional customer growth and the IPv4 transfer market for their IPv4 interim needs. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] ARIN IPv4 Free Pool Reaches Zero Date: September 24, 2015 at 12:04:22 PM EDT To: > On 24 September 2015, ARIN issued the final IPv4 addresses in its free pool. ARIN will continue to process and approve requests for IPv4 address blocks. Those approved requests may be fulfilled via the Wait List for Unmet IPv4 Requests, or through the IPv4 Transfer Market. For information on the Waiting List, visit: https://www.arin.net/resources/request/waiting_list.html For information on IPv4 Transfers, visit: https://www.arin.net/resources/transfers/index.html Exhaustion of the ARIN Free Pool does trigger changes in ARIN's Specified Transfer policy (NRPM 8.3) and Inter-RIR Transfer policy (NRPM 8.4). In both cases, these changes impact organizations that have been the source entity in a specified transfer within the last twelve months: "The source entity (-ies within the ARIN Region (8.4)) will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first." Effective today, because exhaustion of the ARIN IPv4 free pool has occurred for the first time, there is no longer a restriction on how often organizations may request transfers to specified recipients. In the future, any IPv4 address space that ARIN receives from IANA, or recovers from revocations or returns from organizations, will be used to satisfy approved requests on the Waiting List for Unmet Requests. If we are able to fully satisfy all of the requests on the waiting list, any remaining IPv4 addresses would be placed into the ARIN free pool of IPv4 addresses to satisfy future requests. ARIN encourages customers with questions about IPv4 availability to contact hostmaster at arin.net or the Registration Services Help Desk at +1.703.227.0660. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From cb.list6 at gmail.com Thu Sep 24 16:46:31 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 24 Sep 2015 09:46:31 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> Message-ID: On Thu, Sep 24, 2015 at 9:34 AM, John Curran wrote: > (Apologies for redistribution, but need to insure that this is seen by all > in the region.) > > The IPv4 free pool for the ARIN region is now depleted; ISPs are > encouraged to utilize > IPv6 for additional customer growth and the IPv4 transfer market for their > IPv4 interim > needs. > > Hooray! Come on in, the IPv6 water is fine http://www.worldipv6launch.org/measurements/ Over 20% of Google view are on IPv6 https://www.google.com/intl/en/ipv6/statistics.html And, IPv6 is 10-15% faster https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board-/ CB > Thanks! > /John > > John Curran > President and CEO > ARIN > > > Begin forwarded message: > > From: ARIN > > Subject: [arin-announce] ARIN IPv4 Free Pool Reaches Zero > Date: September 24, 2015 at 12:04:22 PM EDT > To: > > > On 24 September 2015, ARIN issued the final IPv4 addresses in its free > pool. ARIN will continue to process and approve requests for IPv4 > address blocks. Those approved requests may be fulfilled via the Wait > List for Unmet IPv4 Requests, or through the IPv4 Transfer Market. > > For information on the Waiting List, visit: > https://www.arin.net/resources/request/waiting_list.html > > For information on IPv4 Transfers, visit: > https://www.arin.net/resources/transfers/index.html > > Exhaustion of the ARIN Free Pool does trigger changes in ARIN's > Specified Transfer policy (NRPM 8.3) and Inter-RIR Transfer policy (NRPM > 8.4). In both cases, these changes impact organizations that have been > the source entity in a specified transfer within the last twelve months: > > "The source entity (-ies within the ARIN Region (8.4)) will be > ineligible to receive any further IPv4 address allocations or > assignments from ARIN for a period of 12 months after a transfer > approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs > first." > > Effective today, because exhaustion of the ARIN IPv4 free pool has > occurred for the first time, there is no longer a restriction on how > often organizations may request transfers to specified recipients. > > In the future, any IPv4 address space that ARIN receives from IANA, or > recovers from revocations or returns from organizations, will be used to > satisfy approved requests on the Waiting List for Unmet Requests. If we > are able to fully satisfy all of the requests on the waiting list, any > remaining IPv4 addresses would be placed into the ARIN free pool of IPv4 > addresses to satisfy future requests. > > ARIN encourages customers with questions about IPv4 availability to > contact hostmaster at arin.net or the Registration Services Help Desk at > +1.703.227.0660. > > Regards, > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. > > From dovid at telecurve.com Thu Sep 24 16:49:55 2015 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 24 Sep 2015 16:49:55 +0000 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> Message-ID: <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> The issue now is convincing clients that they need it. The other issue is many software vendors still don't support it. Regards, Dovid -----Original Message----- From: Ca By Sender: "NANOG" Date: Thu, 24 Sep 2015 09:46:31 To: John Curran Cc: NANOG Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero On Thu, Sep 24, 2015 at 9:34 AM, John Curran wrote: > (Apologies for redistribution, but need to insure that this is seen by all > in the region.) > > The IPv4 free pool for the ARIN region is now depleted; ISPs are > encouraged to utilize > IPv6 for additional customer growth and the IPv4 transfer market for their > IPv4 interim > needs. > > Hooray! Come on in, the IPv6 water is fine http://www.worldipv6launch.org/measurements/ Over 20% of Google view are on IPv6 https://www.google.com/intl/en/ipv6/statistics.html And, IPv6 is 10-15% faster https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board-/ CB > Thanks! > /John > > John Curran > President and CEO > ARIN > > > Begin forwarded message: > > From: ARIN > > Subject: [arin-announce] ARIN IPv4 Free Pool Reaches Zero > Date: September 24, 2015 at 12:04:22 PM EDT > To: > > > On 24 September 2015, ARIN issued the final IPv4 addresses in its free > pool. ARIN will continue to process and approve requests for IPv4 > address blocks. Those approved requests may be fulfilled via the Wait > List for Unmet IPv4 Requests, or through the IPv4 Transfer Market. > > For information on the Waiting List, visit: > https://www.arin.net/resources/request/waiting_list.html > > For information on IPv4 Transfers, visit: > https://www.arin.net/resources/transfers/index.html > > Exhaustion of the ARIN Free Pool does trigger changes in ARIN's > Specified Transfer policy (NRPM 8.3) and Inter-RIR Transfer policy (NRPM > 8.4). In both cases, these changes impact organizations that have been > the source entity in a specified transfer within the last twelve months: > > "The source entity (-ies within the ARIN Region (8.4)) will be > ineligible to receive any further IPv4 address allocations or > assignments from ARIN for a period of 12 months after a transfer > approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs > first." > > Effective today, because exhaustion of the ARIN IPv4 free pool has > occurred for the first time, there is no longer a restriction on how > often organizations may request transfers to specified recipients. > > In the future, any IPv4 address space that ARIN receives from IANA, or > recovers from revocations or returns from organizations, will be used to > satisfy approved requests on the Waiting List for Unmet Requests. If we > are able to fully satisfy all of the requests on the waiting list, any > remaining IPv4 addresses would be placed into the ARIN free pool of IPv4 > addresses to satisfy future requests. > > ARIN encourages customers with questions about IPv4 availability to > contact hostmaster at arin.net or the Registration Services Help Desk at > +1.703.227.0660. > > Regards, > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. > > From lost at l-w.ca Thu Sep 24 16:59:14 2015 From: lost at l-w.ca (William Astle) Date: Thu, 24 Sep 2015 10:59:14 -0600 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> Message-ID: <56042BE2.7080208@l-w.ca> On 2015-09-24 10:49, Dovid Bender wrote: > The issue now is convincing clients that they need it. The other issue is many software vendors still don't support it. > > Regards, > > Dovid Actually, the issue now is convincing certain big providers to actually make IPv6 service available to their customers in data centres and the like across their *whole* networks rather than giving people the "there's no demand so we can't justify the cost" run around. (I'm looking at you AS701.) For that matter, it would also help if certain large end user providers would make IPv6 available rather than giving a standard "we have no information at this time" type response. (I'm looking at you, Shaw.) From baldur.norddahl at gmail.com Thu Sep 24 17:07:18 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 24 Sep 2015 19:07:18 +0200 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> Message-ID: On 24 September 2015 at 18:34, John Curran wrote: > In the future, any IPv4 address space that ARIN receives from IANA, or > recovers from revocations or returns from organizations, will be used to > satisfy approved requests on the Waiting List for Unmet Requests. > > > *If we are able to fully satisfy all of the requests on the waiting list, > any remaining IPv4 addresses would be placed into the ARIN free pool of > IPv4 addresses to satisfy future requests.* Not even the Iraqi Minister of Information could have said that last part with a straight face. From jared at puck.nether.net Thu Sep 24 17:50:54 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 24 Sep 2015 13:50:54 -0400 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> Message-ID: > On Sep 24, 2015, at 12:49 PM, Dovid Bender wrote: > > The issue now is convincing clients that they need it. The other issue is many software vendors still don't support it. > Open a ticket with your NOC or the customer support people if they can?t reach sites like http://adsb.nether.net/ Use tools like Jason?s test-ipv6.com site. IPv6 traffic roughly doubled in my view of the internet in the past ~2 weeks as the 9.0 GM image hit and the public release of 9.0 came out. Graphs here: https://twitter.com/jaredmauch/status/647100011797348352 https://twitter.com/jaredmauch/status/645976350860247040 https://twitter.com/jaredmauch/status/645968683794219013 - Jared From A.L.M.Buxey at lboro.ac.uk Thu Sep 24 18:55:33 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Thu, 24 Sep 2015 18:55:33 +0000 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> Message-ID: <20150924185533.GA368@lboro.ac.uk> Hi, > IPv6 traffic roughly doubled in my view of the internet in the past ~2 weeks as the 9.0 GM image hit and the public release of 9.0 came out. 0.001% of traffic to 0.002% ;-) joking aside as I'm a big IPv6 champion.... IPv6 is picking up a lot recently....and whilst the bahviour change of IOS9 has helped...clients themselves dont change the networks they are using - the networks themselves need to support this protocol, route it etc as we all know...so, if nothing else, IOS9 has revealed more that many parts of the internet are IPv6 enabled and ready to be used. alan From jared at puck.nether.net Thu Sep 24 19:09:05 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 24 Sep 2015 12:09:05 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <20150924185533.GA368@lboro.ac.uk> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <20150924185533.GA368@lboro.ac.uk> Message-ID: Let's say it's less than 1Tbit but based on the growth curve in recent weeks I'm not sure it will stay there. Jared Mauch > On Sep 24, 2015, at 11:55 AM, A.L.M.Buxey at lboro.ac.uk wrote: > > Hi, > >> IPv6 traffic roughly doubled in my view of the internet in the past ~2 weeks as the 9.0 GM image hit and the public release of 9.0 came out. > > 0.001% of traffic to 0.002% ;-) > > > joking aside as I'm a big IPv6 champion.... IPv6 is picking up a lot recently....and whilst > the bahviour change of IOS9 has helped...clients themselves dont change the networks they are using - > the networks themselves need to support this protocol, route it etc as we all know...so, if nothing > else, IOS9 has revealed more that many parts of the internet are IPv6 enabled and ready to be used. > > alan From list at satchell.net Thu Sep 24 19:38:26 2015 From: list at satchell.net (Stephen Satchell) Date: Thu, 24 Sep 2015 12:38:26 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> Message-ID: <56045132.5090803@satchell.net> On 09/24/2015 09:49 AM, Dovid Bender wrote: > The issue now is convincing clients that they need it. The other > issue is many software vendors still don't support it. And this may trigger a refresh on routers, as people old or refurbed equipment find they need to change. The whole reason for the inertia against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." Now it's broke. From Steve.Mikulasik at civeo.com Thu Sep 24 19:41:44 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Thu, 24 Sep 2015 19:41:44 +0000 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <56045132.5090803@satchell.net> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> Message-ID: Let's just hope carriers don't try to fix IPv4 instead of going to IPv6. I'd like my children to grow up in a worlds without cgnat. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Satchell Sent: Thursday, September 24, 2015 1:38 PM To: nanog at nanog.org Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero On 09/24/2015 09:49 AM, Dovid Bender wrote: > The issue now is convincing clients that they need it. The other issue > is many software vendors still don't support it. And this may trigger a refresh on routers, as people old or refurbed equipment find they need to change. The whole reason for the inertia against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." Now it's broke. From nanog at ics-il.net Thu Sep 24 20:06:23 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 24 Sep 2015 15:06:23 -0500 (CDT) Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <56045132.5090803@satchell.net> Message-ID: <1809766282.8915.1443125202788.JavaMail.mhammett@ThunderFuck> ===== The whole reason for the inertia against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." Now it's broke. ===== ^^^^^^^This ^^^^^^^^^^^ ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Stephen Satchell" To: nanog at nanog.org Sent: Thursday, September 24, 2015 2:38:26 PM Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero On 09/24/2015 09:49 AM, Dovid Bender wrote: > The issue now is convincing clients that they need it. The other > issue is many software vendors still don't support it. And this may trigger a refresh on routers, as people old or refurbed equipment find they need to change. The whole reason for the inertia against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." Now it's broke. From rsk at gsp.org Thu Sep 24 20:08:20 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 24 Sep 2015 16:08:20 -0400 Subject: SPAM: AW: important In-Reply-To: <002001d0f6c8$59011680$0b034380$@gmx.net> References: <002001d0f6c8$59011680$0b034380$@gmx.net> Message-ID: <20150924200820.GA29872@gsp.org> On Thu, Sep 24, 2015 at 02:55:51PM +0200, Gunther Stammwitz wrote: > This is unbelievable: Yes, it is. Quoting back a spammer's entire message to the entire list, including the payload, is unbelievably stupid. It would have been better to call this to the attention of those charged with the care and feeding of this list, who are available at admins at nanog.org per the nanog.org web site. (Although even that is probably not necessary: I presume that they're keeping eyeballs on the list and quite likely noticed this on their own.) Blocking mailing list spam sent by/via addresses belonging to the mailing list is exceedingly tricky. There are a few methods that are modestly effective but none which present sufficiently low FP/FN performance to be trusted without human intervention. And those which rely on content, like all anti-spam methods which rely on content, can be and are defeated at will by spammers. I have studied this problem in considerable depth over the past several years and have concluded that -- so far -- the only truly reliable method is clueful list moderation with individual approval of every message. This is, however, labor-intensive for high-volume lists and is thus dependent on the availability of trained/practiced teams of list-owners with sufficient available time. ---rsk From itg at itechgeek.com Thu Sep 24 20:15:06 2015 From: itg at itechgeek.com (ITechGeek) Date: Thu, 24 Sep 2015 16:15:06 -0400 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <1809766282.8915.1443125202788.JavaMail.mhammett@ThunderFuck> References: <56045132.5090803@satchell.net> <1809766282.8915.1443125202788.JavaMail.mhammett@ThunderFuck> Message-ID: Remember, the Internet being fully migrated to IPv6 is just 5 yrs away just like fusion power plants is 20 yrs away (although I think now they are saying 50 yrs away which would make IPv6 12.5 yrs away). (= ----------------------------------------------------------------------------------------------- -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 Thu, Sep 24, 2015 at 4:06 PM, Mike Hammett wrote: > ===== > The whole reason for the inertia > against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." > > Now it's broke. > ===== > > ^^^^^^^This ^^^^^^^^^^^ > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Stephen Satchell" > To: nanog at nanog.org > Sent: Thursday, September 24, 2015 2:38:26 PM > Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero > > On 09/24/2015 09:49 AM, Dovid Bender wrote: > > The issue now is convincing clients that they need it. The other > > issue is many software vendors still don't support it. > > And this may trigger a refresh on routers, as people old or refurbed > equipment find they need to change. The whole reason for the inertia > against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." > > Now it's broke. > > From itg at itechgeek.com Thu Sep 24 20:20:26 2015 From: itg at itechgeek.com (ITechGeek) Date: Thu, 24 Sep 2015 16:20:26 -0400 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> Message-ID: They're already trying - RFC 6598. On the flip side, I'm using subnets from that range for my home network instead of RFC 1918 space right now. ----------------------------------------------------------------------------------------------- -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 Thu, Sep 24, 2015 at 3:41 PM, Steve Mikulasik wrote: > Let's just hope carriers don't try to fix IPv4 instead of going to IPv6. > I'd like my children to grow up in a worlds without cgnat. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Satchell > Sent: Thursday, September 24, 2015 1:38 PM > To: nanog at nanog.org > Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero > > On 09/24/2015 09:49 AM, Dovid Bender wrote: > > The issue now is convincing clients that they need it. The other issue > > is many software vendors still don't support it. > > And this may trigger a refresh on routers, as people old or refurbed > equipment find they need to change. The whole reason for the inertia > against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." > > Now it's broke. > > From bryan at digitalocean.com Thu Sep 24 20:24:57 2015 From: bryan at digitalocean.com (Bryan Socha) Date: Thu, 24 Sep 2015 16:24:57 -0400 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> Message-ID: Shouldn't 23.128.0.0/10 be put back into the pool? Ripe finished their test and this was a loaned block. Also with 16 million addresses in their reserved pool, did they really need to borrow this in the first place?? https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-24-prefixes-changed Bryan Socha Network Engineer DigitalOcean On Thu, Sep 24, 2015 at 12:34 PM, John Curran wrote: > (Apologies for redistribution, but need to insure that this is seen by all > in the region.) > > The IPv4 free pool for the ARIN region is now depleted; ISPs are > encouraged to utilize > IPv6 for additional customer growth and the IPv4 transfer market for their > IPv4 interim > needs. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > Begin forwarded message: > > From: ARIN > > Subject: [arin-announce] ARIN IPv4 Free Pool Reaches Zero > Date: September 24, 2015 at 12:04:22 PM EDT > To: > > > On 24 September 2015, ARIN issued the final IPv4 addresses in its free > pool. ARIN will continue to process and approve requests for IPv4 > address blocks. Those approved requests may be fulfilled via the Wait > List for Unmet IPv4 Requests, or through the IPv4 Transfer Market. > > For information on the Waiting List, visit: > https://www.arin.net/resources/request/waiting_list.html > > For information on IPv4 Transfers, visit: > https://www.arin.net/resources/transfers/index.html > > Exhaustion of the ARIN Free Pool does trigger changes in ARIN's > Specified Transfer policy (NRPM 8.3) and Inter-RIR Transfer policy (NRPM > 8.4). In both cases, these changes impact organizations that have been > the source entity in a specified transfer within the last twelve months: > > "The source entity (-ies within the ARIN Region (8.4)) will be > ineligible to receive any further IPv4 address allocations or > assignments from ARIN for a period of 12 months after a transfer > approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs > first." > > Effective today, because exhaustion of the ARIN IPv4 free pool has > occurred for the first time, there is no longer a restriction on how > often organizations may request transfers to specified recipients. > > In the future, any IPv4 address space that ARIN receives from IANA, or > recovers from revocations or returns from organizations, will be used to > satisfy approved requests on the Waiting List for Unmet Requests. If we > are able to fully satisfy all of the requests on the waiting list, any > remaining IPv4 addresses would be placed into the ARIN free pool of IPv4 > addresses to satisfy future requests. > > ARIN encourages customers with questions about IPv4 availability to > contact hostmaster at arin.net or the Registration Services Help Desk at > +1.703.227.0660. > > Regards, > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. > > From ianswett at google.com Thu Sep 24 19:17:54 2015 From: ianswett at google.com (Ian Swett) Date: Thu, 24 Sep 2015 15:17:54 -0400 Subject: Recent trouble with QUIC Message-ID: Hi, I'm an engineer working on QUIC at Google. Sorry for the delayed response. This was an issue with QUIC traffic (from Chrome users) to Google for some users behind NATs. The issue started at small volumes on 2015-09-09 when we started rolling out an optimization to our frontends for QUIC users behind NATs, and then increased in magnitude on 2015-09-22. We rolled back the feature by 2015-09-23 12:40 PDT, which did clear all issues. Here are the technical details: As we have posted about QUIC before[1], and was pointed out earlier in this thread, QUIC runs over UDP. For users behind a NAT, QUIC relies upon NATs maintaining port bindings when the UDP path is in active use. To ensure that the NAT does not time out with outstanding requests, QUIC sends a keepalive ping after 15 seconds. To optimize for the case when a NAT times out, we implemented a feature in our frontend to allow the port to migrate on open QUIC connections -- the frontend would send a GOAWAY to the client to indicate the connection should be re-established, but outstanding requests could be completed. This triggered a previously unknown bug in Chrome where it tries to use an open QUIC connection that has already received a GOAWAY for new requests. Hence the failures. As this happens only following a NAT rebinding, these failures were isolated to networks with a lot of NAT rebindings on active connections. This bug was particularly visible on connections to GMail and Drive because they utilize hanging GETs which last multiple minutes. All new requests using timed out connections would have immediately failed as well. After rolling back the feature, we have started working on fixing the underlying issue and improving how we detect and avoid issues like this in the future. -- Ian Swett [1] http://blog.chromium.org/2013/06/experimenting-with-quic.html From rafaelpossa at gmail.com Thu Sep 24 19:56:25 2015 From: rafaelpossa at gmail.com (Rafael Possamai) Date: Thu, 24 Sep 2015 14:56:25 -0500 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> Message-ID: T-Mobile implemented 464XLAT successfully, but I have no idea how long they will still depend on IPv4 because of that setup. On Thu, Sep 24, 2015 at 2:41 PM, Steve Mikulasik wrote: > Let's just hope carriers don't try to fix IPv4 instead of going to IPv6. > I'd like my children to grow up in a worlds without cgnat. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Satchell > Sent: Thursday, September 24, 2015 1:38 PM > To: nanog at nanog.org > Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero > > On 09/24/2015 09:49 AM, Dovid Bender wrote: > > The issue now is convincing clients that they need it. The other issue > > is many software vendors still don't support it. > > And this may trigger a refresh on routers, as people old or refurbed > equipment find they need to change. The whole reason for the inertia > against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." > > Now it's broke. > > From larrysheldon at cox.net Thu Sep 24 21:27:28 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 24 Sep 2015 16:27:28 -0500 Subject: [ih] Fiction->History In-Reply-To: References: <56035F87.1030003@cox.net> Message-ID: <56046AC0.205@cox.net> On 9/24/2015 10:56, Bill Ricker wrote: > On Wed, Sep 23, 2015 at 10:27 PM, Larry Sheldon > wrote: > >> >> Fiction->History >> > ?There are two sorts of SciFi (aside from the Fantastic) - those that > aren't facts yet? > > ?but likely will be if we persevere, and ?those that could be facts if we > screw things up even worse. Those writing near-term SF are well advised to > leverage William Gibson's aphorism "The future is already here - it's just > not evenly distributed" to sniff out what is in the labs and the pockets of > the early adopters. > > >> ? >> In 1977 there was a book titled ?The Adolescence of P-1? (Thomas Joseph >> Ryan) >> > > I thought I remembered this was either serialized or first appeared as a > novella in one of the magazines before release as a book, but Google finds > no proof of that? Odd. > There was a flurry of pre-cyber-punk AI / rogue-programmer stories in > Analog in the late 70's, i recall one featured a female hacker but i forget > the title, and that it was the month before or after P-1 so it seemed a > trend. I guess I had forgotten how much there is--I was a Heinlein reader sub-teen but in general lost interest in SciFi--this book and "Contact" (and maybe "Broca's Brain") are the only ones that come to mind since then (unless you want to include George Orwell, Aldous Huxley, Ayn Rand, and George Lucas). I mentioned "P-1" here because it is the only one of the lot (that I can remember) where the _network_ is a (the) major protagonist. ? -- sed quis custodiet ipsos custodes? (Juvenal) From bob at FiberInternetCenter.com Thu Sep 24 21:32:16 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 24 Sep 2015 14:32:16 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: References: <56045132.5090803@satchell.net> <1809766282.8915.1443125202788.JavaMail.mhammett@ThunderFuck> Message-ID: <74b03a610779118f4fe2938a6bbc5761.squirrel@66.201.44.180> IPv4's works better today than ever before. IP space in North America has now officially turned into a revenue source for networks. Most private enterprise customers understand costs and profits. Business does not understand free stuff in a free market. Hence, IPv4 is no longer free in a block range perspective. To any business with rising employee medical insurance, electricity and office rent rates, an IP address cost is just not on the radar. Just not a large enough cost to make IPv6 look financially attractive. Only when IPv4 address costs begin to exceed that of the hardware and labor conversion costs, will IPv6 gain traction in North America. So for the most part your teenage kids will grow up in an IPv4 world until they are probably 30,something. But, your grand kids will see IPv4 as soooo old. That's all contingent upon all the networks we work on start charging $10 or more per IP address per month. Thank You Bob Evans CTO > Remember, the Internet being fully migrated to IPv6 is just 5 yrs away > just > like fusion power plants is 20 yrs away (although I think now they are > saying 50 yrs away which would make IPv6 12.5 yrs away). (= > > ----------------------------------------------------------------------------------------------- > -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 Thu, Sep 24, 2015 at 4:06 PM, Mike Hammett wrote: > >> ===== >> The whole reason for the inertia >> against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." >> >> Now it's broke. >> ===== >> >> ^^^^^^^This ^^^^^^^^^^^ >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Stephen Satchell" >> To: nanog at nanog.org >> Sent: Thursday, September 24, 2015 2:38:26 PM >> Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero >> >> On 09/24/2015 09:49 AM, Dovid Bender wrote: >> > The issue now is convincing clients that they need it. The other >> > issue is many software vendors still don't support it. >> >> And this may trigger a refresh on routers, as people old or refurbed >> equipment find they need to change. The whole reason for the inertia >> against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." >> >> Now it's broke. >> >> > From toddunder at gmail.com Thu Sep 24 21:37:32 2015 From: toddunder at gmail.com (Todd Underwood) Date: Thu, 24 Sep 2015 17:37:32 -0400 Subject: Recent trouble with QUIC? In-Reply-To: <20150924091008.56a3a3c0@scrofula.eps.is.port.ac.uk> References: <20150924091008.56a3a3c0@scrofula.eps.is.port.ac.uk> Message-ID: This has now been resolved. See recent post by ian swett in a separate thread about quic. T On Sep 24, 2015 1:12 AM, "Mike Meredith" wrote: > On Wed, 23 Sep 2015 19:01:19 -0500, Sean Hunter > may have written: > > a) Has anyone here had a similar experience? Was the root cause QUIC > > in your case? > > Yes. No; in our case our firewall (a PA5060 running PANOS6.1.3 at the > time) was allowing some QUIC packets through, but not others. As it was > newly deployed at the time, it was soon blamed :-\ > > > b) Has anyone noticed anything remotely similar in the last few > > weeks/days/today? > > Only because I enabled QUIC within Chrome on our test network to verify > that it was still a problem. > > > We're an Apps domain, so this may be specific to universities in the > > Apps universe. > > As are we. > > -- > Mike Meredith, University of Portsmouth > Principal Systems Engineer, Hostmaster, Security, and Timelord! > > From jcurran at arin.net Thu Sep 24 21:37:44 2015 From: jcurran at arin.net (John Curran) Date: Thu, 24 Sep 2015 21:37:44 +0000 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> Message-ID: On Sep 24, 2015, at 4:24 PM, Bryan Socha > wrote: Shouldn't 23.128.0.0/10 be put back into the pool? Bryan - 23.128.0.0/10 isn?t on loan to RIPE; it is the permanently reserved block for IPv6 transition (see ARIN NRPM 4.10 "Dedicated IPv4 block to facilitate IPv6 Deployment?), of which RIPE is doing testing with 4 /24?s (and has asked to continue the testing of those blocks, so long as we don?t need them back sooner.) Thanks, /John John Curran President and CEO ARIN From tony at swalter.com Thu Sep 24 21:42:32 2015 From: tony at swalter.com (Tony Patti) Date: Thu, 24 Sep 2015 21:42:32 +0000 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <74b03a610779118f4fe2938a6bbc5761.squirrel@66.201.44.180> References: <56045132.5090803@satchell.net> <1809766282.8915.1443125202788.JavaMail.mhammett@ThunderFuck> <74b03a610779118f4fe2938a6bbc5761.squirrel@66.201.44.180> Message-ID: According to http://business.comcast.com/internet/business-internet/static-ip Comcast charges $19.95 per month for one static IPv4 address. Tony Patti CIO -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bob Evans Sent: Thursday, September 24, 2015 5:32 PM To: nanog list Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero IPv4's works better today than ever before. IP space in North America has now officially turned into a revenue source for networks. Most private enterprise customers understand costs and profits. Business does not understand free stuff in a free market. Hence, IPv4 is no longer free in a block range perspective. To any business with rising employee medical insurance, electricity and office rent rates, an IP address cost is just not on the radar. Just not a large enough cost to make IPv6 look financially attractive. Only when IPv4 address costs begin to exceed that of the hardware and labor conversion costs, will IPv6 gain traction in North America. So for the most part your teenage kids will grow up in an IPv4 world until they are probably 30,something. But, your grand kids will see IPv4 as soooo old. That's all contingent upon all the networks we work on start charging $10 or more per IP address per month. Thank You Bob Evans CTO > Remember, the Internet being fully migrated to IPv6 is just 5 yrs away > just like fusion power plants is 20 yrs away (although I think now > they are saying 50 yrs away which would make IPv6 12.5 yrs away). (= > > ---------------------------------------------------------------------- > ------------------------- > -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 Thu, Sep 24, 2015 at 4:06 PM, Mike Hammett wrote: > >> ===== >> The whole reason for the inertia >> against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." >> >> Now it's broke. >> ===== >> >> ^^^^^^^This ^^^^^^^^^^^ >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Stephen Satchell" >> To: nanog at nanog.org >> Sent: Thursday, September 24, 2015 2:38:26 PM >> Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero >> >> On 09/24/2015 09:49 AM, Dovid Bender wrote: >> > The issue now is convincing clients that they need it. The other >> > issue is many software vendors still don't support it. >> >> And this may trigger a refresh on routers, as people old or refurbed >> equipment find they need to change. The whole reason for the inertia >> against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." >> >> Now it's broke. >> >> > From Kevin.Irwin at cinbell.com Thu Sep 24 21:48:00 2015 From: Kevin.Irwin at cinbell.com (Irwin, Kevin) Date: Thu, 24 Sep 2015 21:48:00 +0000 Subject: LinkedIn contact Message-ID: Hello, if there is anyone from LinkedIn on the board, can you please contact me offline? Thanks, Kevin Irwin Network Engineer ? Core Network Engineering Cincinnati Bell Telephone "It has been my observation that most people get ahead during the time that others waste.? -Henry Ford The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document. From jgreco at ns.sol.net Thu Sep 24 22:57:18 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 24 Sep 2015 17:57:18 -0500 (CDT) Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: Message-ID: <201509242257.t8OMvIAd063502@aurora.sol.net> > According to http://business.comcast.com/internet/business-internet/static-= > ip > Comcast charges $19.95 per month for one static IPv4 address. High dollar amounts for a single static IPv4 address are nothing new, and are IMHO a side effect of monopoly/duopoly last mile providers being able to shake down end users because the end user's financially viable options are typically just "pay up or don't get a static." The question really at hand: what happens when you need to host a new pile of servers, need/can-justify a /24, and your hosting provider quotes you $2560/month just for the IP space (at $10/IP)? That'd be an incentive to look seriously at IPv6.... I *think*. Switching hosting providers will probably become a popular game for the early depletion era, as providers attempt to rob each other of customers. That's probably a losing game in the long run. ... 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 Steve.Mikulasik at civeo.com Thu Sep 24 21:56:14 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Thu, 24 Sep 2015 21:56:14 +0000 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <74b03a610779118f4fe2938a6bbc5761.squirrel@66.201.44.180> References: <56045132.5090803@satchell.net> <1809766282.8915.1443125202788.JavaMail.mhammett@ThunderFuck> <74b03a610779118f4fe2938a6bbc5761.squirrel@66.201.44.180> Message-ID: I read an article from National Geographic from the early 90s about the conversion for CFCs to HCFC and I think IPv4 will transition similarly. I wish I could find the article on line, but I can't find it at all. It basically credited the speed of the transition (it was faster than most thought) due to CFC scarcity imposed by legislation. CFC used in A/C were known to be terrible for the environment for a number of years, but consumers didn't really demand HCFC equipment and you could always buy CFCs cheaply to repair your appliances. Once it was mandated that HCFCs could only be used on anything new and CFCs could not be produced at the same level, a market was created for reclaiming CFCs from old equipment. The price of CFCs went up for a number of years due to decline supply until there was enough of a uptick in HCFC equipment that eventually the price of CFCs tanked due to low demand. The limited CFC market helped pushed people in adopting HCFCs since the cost of repairing your old CFC A/C unit was very high for a number of years. By the time prices went down no one really cared that much for CFCs anyways. Since we now have a market controlling the allocation of IPv4 addresses we will probably see the fastest uptick in IPv6 adoption yet. The price will go up until it is more reasonable to just go to IPv6 for everything than to figure out how to keep getting blood from the IPv4 stone. There is an upper limit to how much we can all pay for an IP address. Now would be a good time to invest in IPv4 addresses to sell at the high end of the market ;) (Hope I did a decent job explaining, trying to remember the article from a few years ago is hard.) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bob Evans Sent: Thursday, September 24, 2015 3:32 PM To: nanog list Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero IPv4's works better today than ever before. IP space in North America has now officially turned into a revenue source for networks. Most private enterprise customers understand costs and profits. Business does not understand free stuff in a free market. Hence, IPv4 is no longer free in a block range perspective. To any business with rising employee medical insurance, electricity and office rent rates, an IP address cost is just not on the radar. Just not a large enough cost to make IPv6 look financially attractive. Only when IPv4 address costs begin to exceed that of the hardware and labor conversion costs, will IPv6 gain traction in North America. So for the most part your teenage kids will grow up in an IPv4 world until they are probably 30,something. But, your grand kids will see IPv4 as soooo old. That's all contingent upon all the networks we work on start charging $10 or more per IP address per month. Thank You Bob Evans CTO > Remember, the Internet being fully migrated to IPv6 is just 5 yrs away > just like fusion power plants is 20 yrs away (although I think now > they are saying 50 yrs away which would make IPv6 12.5 yrs away). (= > > ---------------------------------------------------------------------- > ------------------------- > -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 Thu, Sep 24, 2015 at 4:06 PM, Mike Hammett wrote: > >> ===== >> The whole reason for the inertia >> against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." >> >> Now it's broke. >> ===== >> >> ^^^^^^^This ^^^^^^^^^^^ >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Stephen Satchell" >> To: nanog at nanog.org >> Sent: Thursday, September 24, 2015 2:38:26 PM >> Subject: Re: ARIN Region IPv4 Free Pool Reaches Zero >> >> On 09/24/2015 09:49 AM, Dovid Bender wrote: >> > The issue now is convincing clients that they need it. The other >> > issue is many software vendors still don't support it. >> >> And this may trigger a refresh on routers, as people old or refurbed >> equipment find they need to change. The whole reason for the inertia >> against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." >> >> Now it's broke. >> >> > From fmartin at linkedin.com Thu Sep 24 21:59:07 2015 From: fmartin at linkedin.com (Franck Martin) Date: Thu, 24 Sep 2015 14:59:07 -0700 Subject: LinkedIn contact In-Reply-To: References: Message-ID: Done. On Thu, Sep 24, 2015 at 2:48 PM, Irwin, Kevin wrote: > Hello, if there is anyone from LinkedIn on the board, can you please > contact me offline? > > Thanks, > > Kevin Irwin > Network Engineer ? Core Network Engineering > Cincinnati Bell Telephone > > "It has been my observation that most people get ahead during the time > that others waste.? -Henry Ford > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you receive > this in error, please contact the sender and destroy any copies of this > document. > From dave.taht at gmail.com Thu Sep 24 22:40:34 2015 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 24 Sep 2015 15:40:34 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <56045132.5090803@satchell.net> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> Message-ID: On Thu, Sep 24, 2015 at 12:38 PM, Stephen Satchell wrote: > On 09/24/2015 09:49 AM, Dovid Bender wrote: >> >> The issue now is convincing clients that they need it. The other >> issue is many software vendors still don't support it. > > > And this may trigger a refresh on routers, as people old or refurbed > equipment find they need to change. The whole reason for the inertia > against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." Yea, well, it would be nice if upgrading existing home routers remained legal, so we could, indeed add ipv6 capability and more. http://prpl.works/2015/09/21/yes-the-fcc-might-ban-your-operating-system/ > Now it's broke. -- Dave T?ht Do you want faster, better, wifi? https://www.patreon.com/dtaht From fmartin at linkedin.com Thu Sep 24 22:56:51 2015 From: fmartin at linkedin.com (Franck Martin) Date: Thu, 24 Sep 2015 15:56:51 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> Message-ID: I think the next requirement for iOS apps: "We ran your app on an IPv6 only network and it did not work. Your submission to the Apple store is therefore denied." From ian.clark at dreamhost.com Thu Sep 24 22:58:55 2015 From: ian.clark at dreamhost.com (Ian Clark) Date: Thu, 24 Sep 2015 15:58:55 -0700 Subject: GeoIP information Message-ID: How do service providers get all the GeoIP companies to have correct information for their address ranges? Do they just pay them to update it? At first I thought it had to do with whois data, but my home Verizon IP whois lists Ashburn, VA, yet the GeoIP data shows my local city. We're trying to find a way to correct our GeoIP data for a specific IP range, but aren't sure what the best practices are for doing so. Any advice would be awesome! -- Ian Clark Network Engineer DreamHost From jared at puck.nether.net Thu Sep 24 22:59:30 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 24 Sep 2015 18:59:30 -0400 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> Message-ID: > On Sep 24, 2015, at 6:56 PM, Franck Martin via NANOG wrote: > > I think the next requirement for iOS apps: "We ran your app on an IPv6 only > network and it did not work. Your submission to the Apple store is > therefore denied." That?s forthcoming. https://developer.apple.com/videos/wwdc/2015/?id=719 - Jared From josh at imaginenetworksllc.com Thu Sep 24 23:03:29 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 24 Sep 2015 19:03:29 -0400 Subject: GeoIP information In-Reply-To: References: Message-ID: Did that Wiki page ever come back up? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sep 24, 2015 7:01 PM, "Ian Clark" wrote: > How do service providers get all the GeoIP companies to have correct > information for their address ranges? Do they just pay them to update it? > At first I thought it had to do with whois data, but my home Verizon IP > whois lists Ashburn, VA, yet the GeoIP data shows my local city. > > We're trying to find a way to correct our GeoIP data for a specific IP > range, but aren't sure what the best practices are for doing so. Any > advice would be awesome! > > -- > Ian Clark > Network Engineer > DreamHost > From rdobbins at arbor.net Thu Sep 24 23:29:55 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 25 Sep 2015 06:29:55 +0700 Subject: GeoIP information In-Reply-To: References: Message-ID: On 25 Sep 2015, at 5:58, Ian Clark wrote: > Any advice would be awesome! There is no inherent correlation between IP addressing and geopolitical boundaries. ----------------------------------- Roland Dobbins From eric-list at truenet.com Thu Sep 24 23:33:49 2015 From: eric-list at truenet.com (Eric Tykwinski) Date: Thu, 24 Sep 2015 19:33:49 -0400 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> Message-ID: <64AA7935-5C40-4E57-9EC6-2FEAAE5C2793@truenet.com> No doubt as an iOS/Apple developer for a hobby, they have been pretty forth coming on dual stack. It?s not totally a requirement yet, but pretty much a BCOP: https://developer.apple.com/library/prerelease/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW11 Sorry if it?s behind a sign-in wall. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 > On Sep 24, 2015, at 6:59 PM, Jared Mauch wrote: > > >> On Sep 24, 2015, at 6:56 PM, Franck Martin via NANOG wrote: >> >> I think the next requirement for iOS apps: "We ran your app on an IPv6 only >> network and it did not work. Your submission to the Apple store is >> therefore denied." > > That?s forthcoming. > > https://developer.apple.com/videos/wwdc/2015/?id=719 > > > - Jared From mike at mtcc.com Thu Sep 24 23:39:54 2015 From: mike at mtcc.com (Michael Thomas) Date: Thu, 24 Sep 2015 16:39:54 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <64AA7935-5C40-4E57-9EC6-2FEAAE5C2793@truenet.com> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> <64AA7935-5C40-4E57-9EC6-2FEAAE5C2793@truenet.com> Message-ID: <560489CA.4030308@mtcc.com> That will be pretty interesting for anybody who's using aws as their server infrastructure since aws is still v6 useless last i heard. Mike On 09/24/2015 04:33 PM, Eric Tykwinski wrote: > No doubt as an iOS/Apple developer for a hobby, they have been pretty forth coming on dual stack. > It?s not totally a requirement yet, but pretty much a BCOP: > https://developer.apple.com/library/prerelease/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW11 > > Sorry if it?s behind a sign-in wall. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > >> On Sep 24, 2015, at 6:59 PM, Jared Mauch wrote: >> >> >>> On Sep 24, 2015, at 6:56 PM, Franck Martin via NANOG wrote: >>> >>> I think the next requirement for iOS apps: "We ran your app on an IPv6 only >>> network and it did not work. Your submission to the Apple store is >>> therefore denied." >> That?s forthcoming. >> >> https://developer.apple.com/videos/wwdc/2015/?id=719 >> >> >> - Jared From bill at herrin.us Fri Sep 25 00:47:56 2015 From: bill at herrin.us (William Herrin) Date: Thu, 24 Sep 2015 20:47:56 -0400 Subject: GeoIP information In-Reply-To: References: Message-ID: On Thu, Sep 24, 2015 at 7:29 PM, Roland Dobbins wrote: > On 25 Sep 2015, at 5:58, Ian Clark wrote: >> Any advice would be awesome! > There is no inherent correlation between IP addressing and geopolitical > boundaries. Maxmind does not concur. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rvandolson at esri.com Fri Sep 25 00:52:20 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Thu, 24 Sep 2015 17:52:20 -0700 Subject: GeoIP information In-Reply-To: References: Message-ID: <20150925005219.GA23573@esri.com> On Thu, Sep 24, 2015 at 08:47:56PM -0400, William Herrin wrote: > On Thu, Sep 24, 2015 at 7:29 PM, Roland Dobbins wrote: > > On 25 Sep 2015, at 5:58, Ian Clark wrote: > >> Any advice would be awesome! > > There is no inherent correlation between IP addressing and geopolitical > > boundaries. > > Maxmind does not concur. > > Regards, > Bill Herrin I've recently SWIP'd some IP space to see if Maxmind would pick up the new location. 48 hours later it hasn't (just via their free, web-based query tool). Perhaps I need to be more patient. Ray From rdobbins at arbor.net Fri Sep 25 00:55:30 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 25 Sep 2015 07:55:30 +0700 Subject: GeoIP information In-Reply-To: References: Message-ID: On 25 Sep 2015, at 7:47, William Herrin wrote: > Maxmind does not concur. ----------------------------------- Roland Dobbins From eric-list at truenet.com Fri Sep 25 01:02:25 2015 From: eric-list at truenet.com (Eric Tykwinski) Date: Thu, 24 Sep 2015 21:02:25 -0400 Subject: GeoIP information In-Reply-To: References: Message-ID: <49F3E7BA-6AE0-4034-855A-F30F3A6E137A@truenet.com> I love OVH where they ask where you want your IP space to be geolocated, but it?s still France/Canada? Why ask, I guess it worked in the past? Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 > On Sep 24, 2015, at 8:55 PM, Roland Dobbins wrote: > > On 25 Sep 2015, at 7:47, William Herrin wrote: > >> Maxmind does not concur. > > > > ----------------------------------- > Roland Dobbins From rdobbins at arbor.net Fri Sep 25 01:12:00 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 25 Sep 2015 08:12:00 +0700 Subject: GeoIP information In-Reply-To: <49F3E7BA-6AE0-4034-855A-F30F3A6E137A@truenet.com> References: <49F3E7BA-6AE0-4034-855A-F30F3A6E137A@truenet.com> Message-ID: <756A201C-8E4B-40B9-B700-28886FF4EF34@arbor.net> On 25 Sep 2015, at 8:02, Eric Tykwinski wrote: > Why ask, I guess it worked in the past? Because folks need to obviate 'GeoIP' filtering so that their services/content can be accessed. ----------------------------------- Roland Dobbins From ian.clark at dreamhost.com Fri Sep 25 01:12:18 2015 From: ian.clark at dreamhost.com (Ian Clark) Date: Thu, 24 Sep 2015 18:12:18 -0700 Subject: GeoIP information In-Reply-To: <20150925005219.GA23573@esri.com> References: <20150925005219.GA23573@esri.com> Message-ID: On Sep 24, 2015 5:54 PM, "Ray Van Dolson" wrote: > > On Thu, Sep 24, 2015 at 08:47:56PM -0400, William Herrin wrote: > > On Thu, Sep 24, 2015 at 7:29 PM, Roland Dobbins wrote: > > > On 25 Sep 2015, at 5:58, Ian Clark wrote: > > >> Any advice would be awesome! > > > There is no inherent correlation between IP addressing and geopolitical > > > boundaries. > > > > Maxmind does not concur. > > > > Regards, > > Bill Herrin > > I've recently SWIP'd some IP space to see if Maxmind would pick up the > new location. 48 hours later it hasn't (just via their free, web-based > query tool). Perhaps I need to be more patient. > > Ray We did the same thing about a week ago, including a correction request with maxmind to no avail, hence this thread. I have a feeling our patience won't be rewarded... From mfidelman at meetinghouse.net Fri Sep 25 01:16:20 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 24 Sep 2015 21:16:20 -0400 Subject: [ih] Fiction->History In-Reply-To: <56046AC0.205@cox.net> References: <56035F87.1030003@cox.net> <56046AC0.205@cox.net> Message-ID: <5604A064.8090801@meetinghouse.net> Larry Sheldon wrote: > On 9/24/2015 10:56, Bill Ricker wrote: >> On Wed, Sep 23, 2015 at 10:27 PM, Larry Sheldon >> wrote: >> >>> >>> Fiction->History >>> >> ?There are two sorts of SciFi (aside from the Fantastic) - those that >> aren't facts yet? >> >> ?but likely will be if we persevere, and ?those that could be facts >> if we >> screw things up even worse. Those writing near-term SF are well >> advised to >> leverage William Gibson's aphorism "The future is already here - >> it's just >> not evenly distributed" to sniff out what is in the labs and the >> pockets of >> the early adopters. >> >> >>> ? >>> In 1977 there was a book titled ?The Adolescence of P-1? (Thomas Joseph >>> Ryan) >>> >> >> I thought I remembered this was either serialized or first appeared as a >> novella in one of the magazines before release as a book, but Google >> finds >> no proof of that? Odd. >> There was a flurry of pre-cyber-punk AI / rogue-programmer >> stories in >> Analog in the late 70's, i recall one featured a female hacker but i >> forget >> the title, and that it was the month before or after P-1 so it seemed a >> trend. > > I guess I had forgotten how much there is--I was a Heinlein reader > sub-teen but in general lost interest in SciFi--this book and > "Contact" (and maybe "Broca's Brain") are the only ones that come to > mind since then (unless you want to include George Orwell, Aldous > Huxley, Ayn Rand, and George Lucas). > > I mentioned "P-1" here because it is the only one of the lot (that I > can remember) where the _network_ is a (the) major protagonist. > Clark's "Dial F for Frankenstein" -- "deep in his heart, he knew that the telephone bell had tolled for the human race." :-) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bill at herrin.us Fri Sep 25 01:24:34 2015 From: bill at herrin.us (William Herrin) Date: Thu, 24 Sep 2015 21:24:34 -0400 Subject: GeoIP information In-Reply-To: References: <20150925005219.GA23573@esri.com> Message-ID: On Thu, Sep 24, 2015 at 9:12 PM, Ian Clark wrote: > On Sep 24, 2015 5:54 PM, "Ray Van Dolson" wrote: >> On Thu, Sep 24, 2015 at 08:47:56PM -0400, William Herrin wrote: >> > On Thu, Sep 24, 2015 at 7:29 PM, Roland Dobbins >> > wrote: >> > > On 25 Sep 2015, at 5:58, Ian Clark wrote: >> > >> Any advice would be awesome! >> > > There is no inherent correlation between IP addressing and >> > > geopolitical >> > > boundaries. >> > >> > Maxmind does not concur. >> > >> > Regards, >> > Bill Herrin >> >> I've recently SWIP'd some IP space to see if Maxmind would pick up the >> new location. 48 hours later it hasn't (just via their free, web-based >> query tool). Perhaps I need to be more patient. > > We did the same thing about a week ago, including a correction request with > maxmind to no avail, hence this thread. I have a feeling our patience won't > be rewarded... Maxmind would have to violate ARIN's rules to collect your geoip information through a feed of whois data. Those rules forbid republication of the data. Try contacting them directly. Then download the files they publish and check for yourself. https://support.maxmind.com/geoip-data-correction-request/ http://dev.maxmind.com/geoip/legacy/geolite/ When you've done these things and still haven't gotten satisfaction, perhaps then it's time to return here for a session of Name and Shame. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From ian.clark at dreamhost.com Fri Sep 25 01:33:04 2015 From: ian.clark at dreamhost.com (Ian Clark) Date: Thu, 24 Sep 2015 18:33:04 -0700 Subject: GeoIP information In-Reply-To: References: <20150925005219.GA23573@esri.com> Message-ID: > Maxmind would have to violate ARIN's rules to collect your geoip > information through a feed of whois data. Those rules forbid > republication of the data. > > Try contacting them directly. Then download the files they publish and > check for yourself. > > https://support.maxmind.com/geoip-data-correction-request/ > http://dev.maxmind.com/geoip/legacy/geolite/ > > When you've done these things and still haven't gotten satisfaction, > perhaps then it's time to return here for a session of Name and Shame. > > Regards, > Bill Herrin Well, I have already submitted a correction request and waited for their stated update cycle to happen. Where do GeoIP companies get their data, if not whois records? From bill at herrin.us Fri Sep 25 01:41:42 2015 From: bill at herrin.us (William Herrin) Date: Thu, 24 Sep 2015 21:41:42 -0400 Subject: GeoIP information In-Reply-To: References: <20150925005219.GA23573@esri.com> Message-ID: On Thu, Sep 24, 2015 at 9:33 PM, Ian Clark wrote: > Where do GeoIP companies get their data, if not whois records? I would assume that they query whois for one of their sources. They don't have to enter any contract with ARIN to do so but they also can't promptly collect any sizable portion database that way. That isn't the same as signing up for bulk whois access (https://www.arin.net/resources/request/bulkwhois.html). I imagine they also do traceroutes to identify the last known location in the route. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rvandolson at esri.com Fri Sep 25 01:45:40 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Thu, 24 Sep 2015 18:45:40 -0700 Subject: GeoIP information In-Reply-To: References: <20150925005219.GA23573@esri.com> Message-ID: <20150925014539.GA24575@esri.com> On Thu, Sep 24, 2015 at 09:41:42PM -0400, William Herrin wrote: > On Thu, Sep 24, 2015 at 9:33 PM, Ian Clark wrote: > > Where do GeoIP companies get their data, if not whois records? > > I would assume that they query whois for one of their sources. They > don't have to enter any contract with ARIN to do so but they also > can't promptly collect any sizable portion database that way. That > isn't the same as signing up for bulk whois access > (https://www.arin.net/resources/request/bulkwhois.html). > > I imagine they also do traceroutes to identify the last known location > in the route. > > Regards, > Bill Herrin I assumed it must be based off of WHOIS. The IP space I'm working with is in the midwest (US). The address associated with it is from our primary IP block out here in California, which it would have only been able to gather from WHOIS. If it had gone off the last hop, presumably it would have seen that as something a little closer to the real location rather than *exactly* where our primary environment is. :) Ray From ian.clark at dreamhost.com Fri Sep 25 01:48:28 2015 From: ian.clark at dreamhost.com (Ian Clark) Date: Thu, 24 Sep 2015 18:48:28 -0700 Subject: GeoIP information In-Reply-To: References: Message-ID: Is there anyone here who has successfully changed their GeoIP data for a subset of their ARIN allocation? How do service providers get all the GeoIP companies to have correct information for their address ranges? Do they just pay them to update it? At first I thought it had to do with whois data, but my home Verizon IP whois lists Ashburn, VA, yet the GeoIP data shows my local city. We're trying to find a way to correct our GeoIP data for a specific IP range, but aren't sure what the best practices are for doing so. Any advice would be awesome! -- Ian Clark Network Engineer DreamHost From bill at herrin.us Fri Sep 25 01:51:50 2015 From: bill at herrin.us (William Herrin) Date: Thu, 24 Sep 2015 21:51:50 -0400 Subject: GeoIP information In-Reply-To: <20150925014539.GA24575@esri.com> References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> Message-ID: On Thu, Sep 24, 2015 at 9:45 PM, Ray Van Dolson wrote: > I assumed it must be based off of WHOIS. The IP space I'm working with > is in the midwest (US). The address associated with it is from our > primary IP block out here in California, which it would have only been > able to gather from WHOIS. If it had gone off the last hop, presumably > it would have seen that as something a little closer to the real > location rather than *exactly* where our primary environment is. :) They could also do RDNS lookups and then see what rwhois says about the domain. They could purchase sales records from online retailers. Hey guys, give us the IP address, city, state and zip code for each sale; we'll pay you a nickle each. Then correlate that with BGP announcements that show the range of impacted addresses. They could convince folks to install web browser plugins which give the users rewards in exchange for ceding personal information. Or buy data from a company which does. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From Valdis.Kletnieks at vt.edu Fri Sep 25 01:57:32 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 24 Sep 2015 21:57:32 -0400 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <560489CA.4030308@mtcc.com> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> <64AA7935-5C40-4E57-9EC6-2FEAAE5C2793@truenet.com> <560489CA.4030308@mtcc.com> Message-ID: <4446.1443146252@turing-police.cc.vt.edu> On Thu, 24 Sep 2015 16:39:54 -0700, Michael Thomas said: > That will be pretty interesting for anybody who's using aws as their > server infrastructure since aws is > still v6 useless last i heard. I wonder if a sudden exodus of customers whose iOS app got axed because it can't contact an aws-hosted server from an IPv6-only network will be enough to get their attention.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jared at puck.nether.net Fri Sep 25 02:10:23 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 24 Sep 2015 19:10:23 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <4446.1443146252@turing-police.cc.vt.edu> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> <64AA7935-5C40-4E57-9EC6-2FEAAE5C2793@truenet.com> <560489CA.4030308@mtcc.com> <4446.1443146252@turing-police.cc.vt.edu> Message-ID: <81655CF1-D674-49FD-8047-BF2552E726D2@puck.nether.net> What people often miss is the front end doesn't need to be the same as the backend. The front should be v6, and using a service to do this for you isn't too hard. This is what many CDNs do. Jared Mauch > On Sep 24, 2015, at 6:57 PM, Valdis.Kletnieks at vt.edu wrote: > > On Thu, 24 Sep 2015 16:39:54 -0700, Michael Thomas said: >> That will be pretty interesting for anybody who's using aws as their >> server infrastructure since aws is >> still v6 useless last i heard. > > I wonder if a sudden exodus of customers whose iOS app got axed > because it can't contact an aws-hosted server from an IPv6-only > network will be enough to get their attention.... From mawatari at jpix.ad.jp Fri Sep 25 04:36:19 2015 From: mawatari at jpix.ad.jp (MAWATARI Masataka) Date: Fri, 25 Sep 2015 13:36:19 +0900 Subject: JANOG37 Meeting Call for Presentations Message-ID: <20150925133618.C951.8FE1F57E@jpix.ad.jp> Hello, JANOG37 Meeting will take place on 20-22 January 2016 in Nagoya, Japan. http://www.janog.gr.jp/en/index.php?JANOG37_Meeting JANOG is making a call for presentations until 30 October 2015. Our meetings are in Japanese but we have had several non-Japanese speakers who made presentations in the past. We are looking forward to your proposals for presentations. Taiji Tsuchiya, Masataka Mawatari JANOG37 Programme Committee Co-Chairs ---------------------------------------------------------------------- ** JANOG37 MEETING ---------------------------------------------------------------------- - Host : CHUBU TELECOMMUNICATIONS CO.,INC. - Date : 20 Jan., 2016 - 22 Jan., 2016 - Venue : NTK Hall - Address : 1-15-1 Kanayamacho, Naka-ku, Nagoya, Japan. - Fees : JANOG37 Meeting (20-22 Jan): Free Social event (in the evening on 21 Jan): 6,000JPY ---------------------------------------------------------------------- ** HOW TO SUBMIT PRESENTATIONS ---------------------------------------------------------------------- If you are interested to give a presentation, submissions are welcome via e-mail at:"meeting-37[at]janog.gr.jp" with the following information. 1. Speaker's name(s) 2. Speaker's organization(s) 3. Preferred contact email address 4. Submission category (General Session or Panel Session) * If your choice is panel, please tell us the number of speakers 5. Presentation title 6. Abstract 7. Desired presentation time and discussion time 8. Slides (attachment or URL), in PowerPoint or PDF format. Our Meetings are in Japanese, so non-Japanese speakers usually arrange an informal interpreter. If you are interested in making a presentation at JANOG but cannot arrange an interpreter by yourself, you could consult with us at: "meeting-37[at]janog.gr.jp". Although we cannot guarantee, we may be able to help you on volunteer basis. Let us know if you have any questions : meeting-37[at]janog.gr.jp ---------------------------------------------------------------------- ** THE KEY DATE FOR JANOG37 SUBMISSIONS ---------------------------------------------------------------------- CFP Deadline : 30 October 23:59 JST The Program Committee will notify you after 16th November about your submission. ---------------------------------------------------------------------- ** VISA ---------------------------------------------------------------------- Foreign visitor entering Japan must have a passport which has valid period during you stay in Japan. Passport holders from some countries are required to have a visa to visit Japan before they depart toward Japan. Many are exempt from this requirement and can get their visa on entry to Japan. Please determine whether you are exempt from the visa requirement. Please refer to the official website from Ministry of Foreign Affairs of Japan or any other appropriate website to get more information about Visa application. Ministry of Foreign Affairs of Japan - Guide to Japanese Visas http://www.mofa.go.jp/j_info/visit/visa/index.html List of Countries and Regions for Visa Exemptions http://www.mofa.go.jp/j_info/visit/visa/short/novisa.html Please note that JANOG can not assist you with your visa application. If you have any questions about the meeting, please feel free to contact meeting-37[at]janog.gr.jp. ---------------------------------------------------------------------- ** ABOUT JANOG ---------------------------------------------------------------------- JANOG webpage in English is available at: http://www.janog.gr.jp/en/ ---------------------------------------------------------------------- From owen at delong.com Fri Sep 25 06:55:21 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Sep 2015 23:55:21 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <201509242257.t8OMvIAd063502@aurora.sol.net> References: <201509242257.t8OMvIAd063502@aurora.sol.net> Message-ID: <4D32FE5B-4542-4941-9020-181E72A24871@delong.com> > On Sep 24, 2015, at 15:57 , Joe Greco wrote: > >> According to http://business.comcast.com/internet/business-internet/static-= >> ip >> Comcast charges $19.95 per month for one static IPv4 address. > > High dollar amounts for a single static IPv4 address are nothing new, > and are IMHO a side effect of monopoly/duopoly last mile providers being > able to shake down end users because the end user's financially viable > options are typically just "pay up or don't get a static.? Yep? That?s why my Comcast service has dynamic IP addresses and I only use them for effective Layer 2 services (GRE tunnels to the real routers that actually route my traffic). This had the rather nice side effect of confusing the heck out of their DPI flow controllers back in the day when they were trying to rate-shape customers in obnoxious and service-specific ways. Since it looked like all my traffic was part of one session and it wasn?t TCP or UDP, they didn?t know how to shape it. > The question really at hand: what happens when you need to host a new > pile of servers, need/can-justify a /24, and your hosting provider > quotes you $2560/month just for the IP space (at $10/IP)? You probably laugh and go to some other provider or BYOA from a broker. > > That'd be an incentive to look seriously at IPv6.... I *think*. I hope so, but most likely people will continue to do the lazy thing as long as they can get away with it. > Switching hosting providers will probably become a popular game for > the early depletion era, as providers attempt to rob each other of > customers. That's probably a losing game in the long run. Let?s hope (that it?s a losing game). Owen From fred at web2objects.com Fri Sep 25 07:19:05 2015 From: fred at web2objects.com (Fred Hollis) Date: Fri, 25 Sep 2015 09:19:05 +0200 Subject: GeoIP information In-Reply-To: References: Message-ID: <5604F569.5060408@web2objects.com> It is a big pain to do so. We did a couple of times in the past and always took us many months. On 25.09.2015 at 03:48 Ian Clark wrote: > Is there anyone here who has successfully changed their GeoIP data for a > subset of their ARIN allocation? > How do service providers get all the GeoIP companies to have correct > information for their address ranges? Do they just pay them to update it? > At first I thought it had to do with whois data, but my home Verizon IP > whois lists Ashburn, VA, yet the GeoIP data shows my local city. > > We're trying to find a way to correct our GeoIP data for a specific IP > range, but aren't sure what the best practices are for doing so. Any > advice would be awesome! > From fred at web2objects.com Fri Sep 25 07:22:14 2015 From: fred at web2objects.com (Fred Hollis) Date: Fri, 25 Sep 2015 09:22:14 +0200 Subject: GeoIP information In-Reply-To: References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> Message-ID: <5604F626.3030905@web2objects.com> > They could purchase sales records from online retailers. Hey guys, > give us the IP address, city, state and zip code for each sale; we'll > pay you a nickle each. Then correlate that with BGP announcements that > show the range of impacted addresses. After looking more into the geo ip topic, I totally noticed, geo data should NOT correlate with BGP data at all! There are a couple of geo ip services that are doing it like you described, but IMO it's wrong. See big telco's announcing /12's and having these IPs spread all over the country. On 25.09.2015 at 03:51 William Herrin wrote: > On Thu, Sep 24, 2015 at 9:45 PM, Ray Van Dolson wrote: >> I assumed it must be based off of WHOIS. The IP space I'm working with >> is in the midwest (US). The address associated with it is from our >> primary IP block out here in California, which it would have only been >> able to gather from WHOIS. If it had gone off the last hop, presumably >> it would have seen that as something a little closer to the real >> location rather than *exactly* where our primary environment is. :) > > They could also do RDNS lookups and then see what rwhois says about the domain. > > They could purchase sales records from online retailers. Hey guys, > give us the IP address, city, state and zip code for each sale; we'll > pay you a nickle each. Then correlate that with BGP announcements that > show the range of impacted addresses. > > They could convince folks to install web browser plugins which give > the users rewards in exchange for ceding personal information. Or buy > data from a company which does. > > -Bill > > > From christian.teuschel at ripe.net Fri Sep 25 08:23:34 2015 From: christian.teuschel at ripe.net (Christian Teuschel) Date: Fri, 25 Sep 2015 10:23:34 +0200 Subject: GeoIP information In-Reply-To: References: Message-ID: <56050486.4040407@ripe.net> We have been using Maxmind's open source data set [0] on RIPEstat [1] now for quite a while and there have been quite many user complaints about the correctness of the location or the recency of the data. One reason can be that [0] is updated/released only once a month, usually beginning of the month. In some cases the Maxmind's online preview [2] - assuming the underlying data is the paid version - seemed to be more up-to-date. Getting BGP topology to geographical location right is not a trivial task for various reasons of which some were already stated here. From my experience with Maxmind I think that the RIR's Whois information is a starting point to bootstrap their database and from there Maxmind uses ping/traceroute triangulation, change requests... and keep in mind that Maxmind's main business field is e-commerce which allows them to correlate requests (IPs from customers) from e-shop site (with known geographical affiliation). Since many ISPs seem to suffer from misguided geo-ip information provided by different providers it would be a huge improvement to have at least one data set that allows the ISPs to provide location information to the IP space they own. Few years ago I heard of a project called OpenGeoFeed [3] but I don't know about its status. Christian [0] http://dev.maxmind.com/geoip/legacy/geolite/ [1] e.g. https://stat.ripe.net/widget/geoloc#w.resource=2001%3A67c%3A2e8%3A%3A%2F48 [2] https://www.maxmind.com/en/geoip-demo [3] https://www.opengeofeed.org/ On 25/09/15 03:48, Ian Clark wrote: > Is there anyone here who has successfully changed their GeoIP data for a > subset of their ARIN allocation? > How do service providers get all the GeoIP companies to have correct > information for their address ranges? Do they just pay them to update it? > At first I thought it had to do with whois data, but my home Verizon IP > whois lists Ashburn, VA, yet the GeoIP data shows my local city. > > We're trying to find a way to correct our GeoIP data for a specific IP > range, but aren't sure what the best practices are for doing so. Any > advice would be awesome! > From rdobbins at arbor.net Fri Sep 25 09:11:38 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 25 Sep 2015 16:11:38 +0700 Subject: GeoIP information In-Reply-To: <5604F626.3030905@web2objects.com> References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> Message-ID: <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> On 25 Sep 2015, at 14:22, Fred Hollis wrote: > See big telco's announcing /12's and having these IPs spread all over > the country. All over the *world*. ----------------------------------- Roland Dobbins From dot at dotat.at Fri Sep 25 10:05:13 2015 From: dot at dotat.at (Tony Finch) Date: Fri, 25 Sep 2015 11:05:13 +0100 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <4446.1443146252@turing-police.cc.vt.edu> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> <64AA7935-5C40-4E57-9EC6-2FEAAE5C2793@truenet.com> <560489CA.4030308@mtcc.com> <4446.1443146252@turing-police.cc.vt.edu> Message-ID: Valdis.Kletnieks at vt.edu wrote: > > I wonder if a sudden exodus of customers whose iOS app got axed > because it can't contact an aws-hosted server from an IPv6-only > network will be enough to get their attention.... Maybe they'll just proxy via CloudFlare to AWS. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. From list at satchell.net Fri Sep 25 10:36:49 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 25 Sep 2015 03:36:49 -0700 Subject: GeoIP information In-Reply-To: <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> Message-ID: <560523C1.2000200@satchell.net> https://tools.ietf.org/html/rfc1876 (EXPERIMENTAL) There appears to be a way of associating a subnet in the IN-ADDR.ARPA domain to a FQDN, which could then be queries for LOC data. For single addresses, the domain owner could opt to include location data for their domain. For subnets, the operator can include location data at their option. Also, I would add one more field to the LOC RR: country code. This would be a two-byte value that is the standard two character ASCII country code. When missing, a value of binary zero would be returned on query. From jgreco at ns.sol.net Fri Sep 25 12:00:52 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 25 Sep 2015 07:00:52 -0500 (CDT) Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: Message-ID: <201509251200.t8PC0q2J075639@aurora.sol.net> > > And this may trigger a refresh on routers, as people old or refurbed > > equipment find they need to change. The whole reason for the inertia > > against going to IPv6 is "it ain't broke, so I not gonna 'fix' it." > > Yea, well, it would be nice if upgrading existing home routers > remained legal, so we could, indeed add ipv6 capability and more. > > http://prpl.works/2015/09/21/yes-the-fcc-might-ban-your-operating-system/ That's not guaranteed to happen, and, I'd note, it has little-to-nothing to do with existing home 'routers' but rather wifi gear. While many home users do have a combined NAT gateway and wireless access point, the vast majority of them are not running custom firmware and would just buy a new device anyways. Part of the real problem here is that manufacturers have generally treated devices like home 'routers' as abandonware. Usually there is just barely enough RAM and flash on these things to hold whatever firmware the company was intending to ship, and sometimes they would not even see any firmware updates ever made available as the software dev team would move on to the next device. This is the same thing we here on this list should all be pretty scared of as the IoT stormfront comes this way. You're unlikely to be able to add code to handle IPv6 to a Belkin F5D6231, which IIRC used some unusual SoC to provide its modest services on something like 1MB of flash and 2MB RAM (it's been a decade so the particulars may be wrong). Only in the relatively rare cases where a manufacturer left a lot of extra room (WRT54GL, etc) are you likely to have sufficient extra space to do updates to gear. ... 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 jgreco at ns.sol.net Fri Sep 25 12:04:43 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 25 Sep 2015 07:04:43 -0500 (CDT) Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <4D32FE5B-4542-4941-9020-181E72A24871@delong.com> Message-ID: <201509251204.t8PC4hXj075723@aurora.sol.net> > > The question really at hand: what happens when you need to host a new=20= > > > pile of servers, need/can-justify a /24, and your hosting provider=20 > > quotes you $2560/month just for the IP space (at $10/IP)? > > You probably laugh and go to some other provider or BYOA from a broker. That works until all the hosting providers are charging similar rates, and even a decade ago I saw providers who would charge you for bringing your own space. > >=20 > > That'd be an incentive to look seriously at IPv6.... I *think*. > > I hope so, but most likely people will continue to do the lazy thing as = > long as they > can get away with it. > > > Switching hosting providers will probably become a popular game for=20 > > the early depletion era, as providers attempt to rob each other of > > customers. That's probably a losing game in the long run. > > Let=E2=80=99s hope (that it=E2=80=99s a losing game). Just because something is a losing game doesn't mean people won't play that game. ... 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 me at geordish.org Fri Sep 25 11:20:31 2015 From: me at geordish.org (Dave Bell) Date: Fri, 25 Sep 2015 12:20:31 +0100 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <4446.1443146252@turing-police.cc.vt.edu> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56045132.5090803@satchell.net> <64AA7935-5C40-4E57-9EC6-2FEAAE5C2793@truenet.com> <560489CA.4030308@mtcc.com> <4446.1443146252@turing-police.cc.vt.edu> Message-ID: On 25 September 2015 at 02:57, wrote: > On Thu, 24 Sep 2015 16:39:54 -0700, Michael Thomas said: >> That will be pretty interesting for anybody who's using aws as their >> server infrastructure since aws is >> still v6 useless last i heard. > > I wonder if a sudden exodus of customers whose iOS app got axed > because it can't contact an aws-hosted server from an IPv6-only > network will be enough to get their attention.... This won't happen. Their app only has to play nicely with NAT64 & DN64. As long as they don't hard code IP addresses then they shouldn't have any issues. Regards, Dave From clay584 at gmail.com Fri Sep 25 14:43:13 2015 From: clay584 at gmail.com (Clay Curtis) Date: Fri, 25 Sep 2015 10:43:13 -0400 Subject: GeoIP information In-Reply-To: <560523C1.2000200@satchell.net> References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> <560523C1.2000200@satchell.net> Message-ID: I don't believe anyone is actually using the LOC RR, but maybe I'm wrong. This seems like the best way to store this type of data. I could see CDNs being able to leverage this along with edns-client-subnet to decrease page load times significantly. How is this still an issue? I mean, we have the means to fix this. Whoever a reverse zone is delegated to could easily update the LOC record to provide this info. They can make the LOC record as "fuzzy" as they feel comfortable by zeroing out the minutes and seconds, as the LOC record is just a set of GPS coordinates. Who better to report the physical location of a network than that network's operators. I think country code would be a nice addition to the LOC record though. Sincerely, Clay Curtis On Fri, Sep 25, 2015 at 6:36 AM, Stephen Satchell wrote: > https://tools.ietf.org/html/rfc1876 (EXPERIMENTAL) > > There appears to be a way of associating a subnet in the IN-ADDR.ARPA > domain to a FQDN, which could then be queries for LOC data. For single > addresses, the domain owner could opt to include location data for their > domain. For subnets, the operator can include location data at their > option. > > Also, I would add one more field to the LOC RR: country code. This would > be a two-byte value that is the standard two character ASCII country code. > When missing, a value of binary zero would be returned on query. > > From rvandolson at esri.com Fri Sep 25 14:47:55 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Fri, 25 Sep 2015 07:47:55 -0700 Subject: GeoIP information In-Reply-To: References: <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> <560523C1.2000200@satchell.net> Message-ID: <20150925144755.GA7033@esri.com> I don't believe anyone is either. We looked at it as well and after reviewing logs from our authoritative DNS server responsible for our in-addr.arpa zones, we saw zero queries for LOC records. Ray On Fri, Sep 25, 2015 at 10:43:13AM -0400, Clay Curtis wrote: > I don't believe anyone is actually using the LOC RR, but maybe I'm wrong. > This seems like the best way to store this type of data. I could see CDNs > being able to leverage this along with edns-client-subnet to decrease page > load times significantly. How is this still an issue? I mean, we have the > means to fix this. Whoever a reverse zone is delegated to could easily > update the LOC record to provide this info. They can make the LOC record > as "fuzzy" as they feel comfortable by zeroing out the minutes and seconds, > as the LOC record is just a set of GPS coordinates. Who better to report > the physical location of a network than that network's operators. I think > country code would be a nice addition to the LOC record though. > > Sincerely, > > Clay Curtis > > On Fri, Sep 25, 2015 at 6:36 AM, Stephen Satchell wrote: > > > https://tools.ietf.org/html/rfc1876 (EXPERIMENTAL) > > > > There appears to be a way of associating a subnet in the IN-ADDR.ARPA > > domain to a FQDN, which could then be queries for LOC data. For single > > addresses, the domain owner could opt to include location data for their > > domain. For subnets, the operator can include location data at their > > option. > > > > Also, I would add one more field to the LOC RR: country code. This would > > be a two-byte value that is the standard two character ASCII country code. > > When missing, a value of binary zero would be returned on query. > > > > > From baldur.norddahl at gmail.com Fri Sep 25 15:35:17 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 25 Sep 2015 17:35:17 +0200 Subject: GeoIP information In-Reply-To: <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> Message-ID: You will find that it takes years before every site out there updated their copy of whatever geo database they are using. Regards Baldur From josh at imaginenetworksllc.com Fri Sep 25 15:52:50 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 25 Sep 2015 11:52:50 -0400 Subject: GeoIP information In-Reply-To: References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> Message-ID: With a new block it took less than a week. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sep 25, 2015 11:36 AM, "Baldur Norddahl" wrote: > You will find that it takes years before every site out there updated their > copy of whatever geo database they are using. > > Regards > > Baldur > From Valdis.Kletnieks at vt.edu Fri Sep 25 16:44:46 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 25 Sep 2015 12:44:46 -0400 Subject: GeoIP information In-Reply-To: References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> <560523C1.2000200@satchell.net> Message-ID: <66936.1443199486@turing-police.cc.vt.edu> On Fri, 25 Sep 2015 10:43:13 -0400, Clay Curtis said: > I don't believe anyone is actually using the LOC RR, but maybe I'm wrong. > This seems like the best way to store this type of data. I could see CDNs > being able to leverage this along with edns-client-subnet to decrease page > load times significantly. How is knowing the physical location going to decrease page load times? Hint: I live all of 3 miles from my office. But home is deep in Comcast cable territory, while office is hanging off connections to Ashburn and Atlanta. So from home to office, packets have to go 400 miles north or south, then back. If Akamai decided to serve me a page at home out of the Akamai servers at work because it's only 3 miles away, it just added 25ms to each RTT it has to take. Which is why Akamai (and any other *sane* CDN) make their decisions based on network topology, not physical location.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From rdobbins at arbor.net Fri Sep 25 16:52:20 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 25 Sep 2015 23:52:20 +0700 Subject: GeoIP information In-Reply-To: <66936.1443199486@turing-police.cc.vt.edu> References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> <560523C1.2000200@satchell.net> <66936.1443199486@turing-police.cc.vt.edu> Message-ID: On 25 Sep 2015, at 23:44, Valdis.Kletnieks at vt.edu wrote: > Which is why Akamai (and any other *sane* CDN) make their decisions > based on network topology, not physical location.... +1 ----------------------------------- Roland Dobbins From owen at delong.com Fri Sep 25 17:15:16 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Sep 2015 10:15:16 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <201509251204.t8PC4hXj075723@aurora.sol.net> References: <201509251204.t8PC4hXj075723@aurora.sol.net> Message-ID: > On Sep 25, 2015, at 05:04 , Joe Greco wrote: > >>> The question really at hand: what happens when you need to host a new=20= >> >>> pile of servers, need/can-justify a /24, and your hosting provider=20 >>> quotes you $2560/month just for the IP space (at $10/IP)? >> >> You probably laugh and go to some other provider or BYOA from a broker. > > That works until all the hosting providers are charging similar rates, > and even a decade ago I saw providers who would charge you for bringing > your own space. I?m betting that as BYOA becomes the only way to get new customers, the charges for BYOA will go down and the acceptance of BYOA customers will go up. While you?re right that eventually, all the hosting providers are likely to start charging, I think there?s a whole lot of hosting churn between here and there. > >>> =20 >>> That'd be an incentive to look seriously at IPv6.... I *think*. >> >> I hope so, but most likely people will continue to do the lazy thing as = >> long as they >> can get away with it. >> >>> Switching hosting providers will probably become a popular game for=20 >>> the early depletion era, as providers attempt to rob each other of >>> customers. That's probably a losing game in the long run. >> >> Let=E2=80=99s hope (that it=E2=80=99s a losing game). > > Just because something is a losing game doesn't mean people won't play > that game. Sure? Look at all the people still running windows. Owen From jeroen.wunnink at hibernianetworks.com Fri Sep 25 08:57:46 2015 From: jeroen.wunnink at hibernianetworks.com (Jeroen Wunnink) Date: Fri, 25 Sep 2015 10:57:46 +0200 Subject: GeoIP information In-Reply-To: <5604F569.5060408@web2objects.com> References: <5604F569.5060408@web2objects.com> Message-ID: <56050C8A.9010307@hibernianetworks.com> It'd really help if some larger content providers would give LIR's some tools to effectively manage GeoTargeting within IP allocations and the subnets therein that they own. In my experience it takes anywhere between 2 weeks and 6 month to get IP blocks effectively Geo-targeted. Google is one of the harder but most visible ones, their online form to change it doesn't do anything. Going through their NOC usually fixes an issue within 2-3 weeks. (Google engineers, idea to add tools for that at https://isp.google.com on a webmaster tool-ish management interface?) Akamai is usually pretty fast and changing maxmind will eventually follow up a lot of the remaining sites. But it's a slow process. Our strategy is generally to change the RIR DB entry to include the correct country and geoloc fields. Followed by a maxmind update request and then some direct strings pulled from friendly operator colleagues and a mail to the Google NOC. On 25/09/15 09:19, Fred Hollis wrote: > It is a big pain to do so. We did a couple of times in the past and > always took us many months. > > On 25.09.2015 at 03:48 Ian Clark wrote: >> Is there anyone here who has successfully changed their GeoIP data for a >> subset of their ARIN allocation? >> How do service providers get all the GeoIP companies to have correct >> information for their address ranges? Do they just pay them to >> update it? >> At first I thought it had to do with whois data, but my home Verizon IP >> whois lists Ashburn, VA, yet the GeoIP data shows my local city. >> >> We're trying to find a way to correct our GeoIP data for a specific IP >> range, but aren't sure what the best practices are for doing so. Any >> advice would be awesome! >> -- Jeroen Wunnink IP NOC Manager - Hibernia Networks Main numbers (Ext: 1011): USA +1.908.516.4200 | UK +44.1704.322.300 Netherlands +31.208.200.622 | 24/7 IP NOC Phone: +31.20.82.00.623 jeroen.wunnink at hibernianetworks.com www.hibernianetworks.com This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From clay584 at gmail.com Fri Sep 25 17:39:22 2015 From: clay584 at gmail.com (Clay Curtis) Date: Fri, 25 Sep 2015 13:39:22 -0400 Subject: GeoIP information In-Reply-To: <66936.1443199486@turing-police.cc.vt.edu> References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> <560523C1.2000200@satchell.net> <66936.1443199486@turing-police.cc.vt.edu> Message-ID: You're example is one specific case. I'm not advocating that it works in every case, or that geo-location should be used in routing decisions exclusively. I have dealt with cases in which a CDN responded to a client request with a resource on another continent, thus having to cross an ocean and adding considerable latency, when there was a POP on that continent. If the CDN could have LOC information that is more accurate/updated, it could allow them to make a better decision and direct a client to a resource that is physically closer. It's another piece of information. Clearly Maxmind or whatever other current means there are to determine physical location are not ideal. Clay On Fri, Sep 25, 2015 at 12:44 PM, wrote: > On Fri, 25 Sep 2015 10:43:13 -0400, Clay Curtis said: > > I don't believe anyone is actually using the LOC RR, but maybe I'm wrong. > > This seems like the best way to store this type of data. I could see > CDNs > > being able to leverage this along with edns-client-subnet to decrease > page > > load times significantly. > > How is knowing the physical location going to decrease page load times? > > Hint: I live all of 3 miles from my office. But home is deep in Comcast > cable territory, while office is hanging off connections to Ashburn and > Atlanta. So from home to office, packets have to go 400 miles north or > south, > then back. If Akamai decided to serve me a page at home out of the Akamai > servers at work because it's only 3 miles away, it just added 25ms to each > RTT it has to take. > > Which is why Akamai (and any other *sane* CDN) make their decisions based > on network topology, not physical location.... > From cscora at apnic.net Fri Sep 25 18:12:59 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 Sep 2015 04:12:59 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201509251812.t8PICx2n008227@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 26 Sep, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 564139 Prefixes after maximum aggregation (per Origin AS): 210496 Deaggregation factor: 2.68 Unique aggregates announced (without unneeded subnets): 274506 Total ASes present in the Internet Routing Table: 51538 Prefixes per ASN: 10.95 Origin-only ASes present in the Internet Routing Table: 36669 Origin ASes announcing only one prefix: 16099 Transit ASes present in the Internet Routing Table: 6405 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: 45 Max AS path prepend of ASN ( 55644) 41 Prefixes from unregistered ASNs in the Routing Table: 1089 Unregistered ASNs in the Routing Table: 408 Number of 32-bit ASNs allocated by the RIRs: 11123 Number of 32-bit ASNs visible in the Routing Table: 8464 Prefixes from 32-bit ASNs in the Routing Table: 32008 Number of bogon 32-bit ASNs visible in the Routing Table: 11 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 422 Number of addresses announced to Internet: 2810154432 Equivalent to 167 /8s, 127 /16s and 141 /24s Percentage of available address space announced: 75.9 Percentage of allocated address space announced: 75.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.6 Total number of prefixes smaller than registry allocations: 186240 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 143190 Total APNIC prefixes after maximum aggregation: 39689 APNIC Deaggregation factor: 3.61 Prefixes being announced from the APNIC address blocks: 150804 Unique aggregates announced from the APNIC address blocks: 59977 APNIC Region origin ASes present in the Internet Routing Table: 5090 APNIC Prefixes per ASN: 29.63 APNIC Region origin ASes announcing only one prefix: 1203 APNIC Region transit ASes present in the Internet Routing Table: 888 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 36 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1625 Number of APNIC addresses announced to Internet: 752840960 Equivalent to 44 /8s, 223 /16s and 113 /24s Percentage of available APNIC address space announced: 88.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-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: 179852 Total ARIN prefixes after maximum aggregation: 88238 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182897 Unique aggregates announced from the ARIN address blocks: 86351 ARIN Region origin ASes present in the Internet Routing Table: 16576 ARIN Prefixes per ASN: 11.03 ARIN Region origin ASes announcing only one prefix: 6042 ARIN Region transit ASes present in the Internet Routing Table: 1746 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 697 Number of ARIN addresses announced to Internet: 1118369984 Equivalent to 66 /8s, 168 /16s and 248 /24s Percentage of available ARIN address space announced: 59.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, 64198-64296, 393216-395164 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: 135843 Total RIPE prefixes after maximum aggregation: 67781 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 142937 Unique aggregates announced from the RIPE address blocks: 88843 RIPE Region origin ASes present in the Internet Routing Table: 18004 RIPE Prefixes per ASN: 7.94 RIPE Region origin ASes announcing only one prefix: 8048 RIPE Region transit ASes present in the Internet Routing Table: 2991 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: 4046 Number of RIPE addresses announced to Internet: 699634944 Equivalent to 41 /8s, 179 /16s and 149 /24s Percentage of available RIPE address space announced: 101.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 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: 60956 Total LACNIC prefixes after maximum aggregation: 11662 LACNIC Deaggregation factor: 5.23 Prefixes being announced from the LACNIC address blocks: 72889 Unique aggregates announced from the LACNIC address blocks: 33608 LACNIC Region origin ASes present in the Internet Routing Table: 2470 LACNIC Prefixes per ASN: 29.51 LACNIC Region origin ASes announcing only one prefix: 610 LACNIC Region transit ASes present in the Internet Routing Table: 536 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 28 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1946 Number of LACNIC addresses announced to Internet: 169251328 Equivalent to 10 /8s, 22 /16s and 146 /24s Percentage of available LACNIC address space announced: 100.9 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: 12177 Total AfriNIC prefixes after maximum aggregation: 3084 AfriNIC Deaggregation factor: 3.95 Prefixes being announced from the AfriNIC address blocks: 14190 Unique aggregates announced from the AfriNIC address blocks: 5364 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 19.25 AfriNIC Region origin ASes announcing only one prefix: 196 AfriNIC Region transit ASes present in the Internet Routing Table: 167 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 150 Number of AfriNIC addresses announced to Internet: 69448448 Equivalent to 4 /8s, 35 /16s and 179 /24s Percentage of available AfriNIC address space announced: 69.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5590 4192 76 China Education and Research 4766 3012 11134 984 Korea Telecom 7545 2799 339 134 TPG Telecom Limited 17974 2710 908 90 PT Telekomunikasi Indonesia 4755 2046 427 229 TATA Communications formerly 9829 1908 1383 226 National Internet Backbone 9808 1613 8639 18 Guangdong Mobile Communicatio 4812 1574 2099 113 China Telecom (Group) 4808 1519 2255 477 CNCGROUP IP network China169 9583 1497 118 560 Sify Limited 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 3192 2966 144 Cox Communications Inc. 6389 2686 3688 44 BellSouth.net Inc. 3356 2528 10708 499 Level 3 Communications, Inc. 18566 2167 392 265 MegaPath Corporation 20115 1887 1881 393 Charter Communications 6983 1739 866 242 EarthLink, Inc. 30036 1607 322 381 Mediacom Communications Corp 4323 1587 1005 406 tw telecom holdings, inc. 701 1400 11401 676 MCI Communications Services, 22561 1284 365 214 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 2473 129 7 SaudiNet, Saudi Telecom Compa 20940 2136 842 1544 Akamai International B.V. 34984 2048 306 377 TELLCOM ILETISIM HIZMETLERI A 8402 1075 544 15 OJSC "Vimpelcom" 13188 1072 97 76 TOV "Bank-Inform" 6849 1062 355 21 JSC "Ukrtelecom" 31148 1053 46 24 Freenet Ltd. 12479 1005 965 78 France Telecom Espana SA 8551 982 376 52 Bezeq International-Ltd 6830 912 2694 465 Liberty Global Operations B.V 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 3382 540 133 Telmex Colombia S.A. 28573 2185 2169 121 NET Servi?os de Comunica??o S 8151 1847 3286 486 Uninet S.A. de C.V. 7303 1566 936 249 Telecom Argentina S.A. 6503 1397 429 56 Axtel, S.A.B. de C.V. 26615 1081 2325 35 Tim Celular S.A. 6147 1062 374 30 Telefonica del Peru S.A.A. 7738 997 1882 41 Telemar Norte Leste S.A. 11830 995 364 24 Instituto Costarricense de El 3816 954 437 163 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 930 1470 14 TE-AS 24863 805 281 37 Link Egypt (Link.NET) 36903 512 258 99 Office National des Postes et 36992 439 1229 32 ETISALAT MISR 37492 315 191 72 Orange Tunisie 24835 286 146 12 Vodafone Data 29571 247 21 13 Cote d'Ivoire Telecom 3741 223 853 186 Internet Solutions 36947 185 807 13 Telecom Algeria 12258 170 26 69 MWEB CONNECT (PROPRIETARY) LI Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5590 4192 76 China Education and Research 10620 3382 540 133 Telmex Colombia S.A. 22773 3192 2966 144 Cox Communications Inc. 4766 3012 11134 984 Korea Telecom 7545 2799 339 134 TPG Telecom Limited 17974 2710 908 90 PT Telekomunikasi Indonesia 6389 2686 3688 44 BellSouth.net Inc. 3356 2528 10708 499 Level 3 Communications, Inc. 39891 2473 129 7 SaudiNet, Saudi Telecom Compa 28573 2185 2169 121 NET Servi?os de Comunica??o S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3382 3249 Telmex Colombia S.A. 22773 3192 3048 Cox Communications Inc. 7545 2799 2665 TPG Telecom Limited 6389 2686 2642 BellSouth.net Inc. 17974 2710 2620 PT Telekomunikasi Indonesia 39891 2473 2466 SaudiNet, Saudi Telecom Compa 28573 2185 2064 NET Servi?os de Comunica??o S 3356 2528 2029 Level 3 Communications, Inc. 4766 3012 2028 Korea Telecom 18566 2167 1902 MegaPath Corporation 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 47092 UNALLOCATED 8.8.204.0/24 16410 The Reynolds and Rey 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 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 Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.100.1.0/24 9730 Bharti Telesonic Ltd Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 23.249.144.0/21 40430 colo4jax, LLC 23.249.152.0/21 40430 colo4jax, LLC 27.50.8.0/24 55548 >>UNKNOWN<< 27.50.9.0/24 55548 >>UNKNOWN<< 27.50.10.0/24 55548 >>UNKNOWN<< 27.50.11.0/24 55548 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 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:18 /9:13 /10:36 /11:95 /12:262 /13:501 /14:1006 /15:1743 /16:12909 /17:7401 /18:12590 /19:26300 /20:37378 /21:39531 /22:62006 /23:54193 /24:305834 /25:845 /26:927 /27:492 /28:15 /29:14 /30:9 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2473 SaudiNet, Saudi Telecom Compa 22773 2400 3192 Cox Communications Inc. 18566 2075 2167 MegaPath Corporation 6389 1607 2686 BellSouth.net Inc. 30036 1426 1607 Mediacom Communications Corp 6983 1387 1739 EarthLink, Inc. 34984 1368 2048 TELLCOM ILETISIM HIZMETLERI A 10620 1254 3382 Telmex Colombia S.A. 11492 1131 1213 CABLE ONE, INC. 22561 993 1284 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1586 2:688 4:97 5:1890 6:25 8:1406 12:1806 13:13 14:1438 15:16 16:2 17:50 18:22 20:51 23:1264 24:1740 27:2079 31:1620 32:52 33:2 34:2 35:4 36:154 37:2038 38:1064 39:15 40:72 41:2789 42:341 43:1527 44:32 45:1275 46:2355 47:57 49:994 50:800 52:23 54:94 55:5 56:4 57:43 58:1422 59:778 60:499 61:1784 62:1421 63:1901 64:4397 65:2248 66:3991 67:2076 68:1074 69:3274 70:1035 71:454 72:1982 74:2547 75:361 76:395 77:1376 78:1207 79:812 80:1346 81:1358 82:878 83:714 84:766 85:1401 86:452 87:1025 88:535 89:1922 90:150 91:6015 92:846 93:2278 94:2129 95:2164 96:436 97:349 98:958 99:55 100:75 101:854 103:8362 104:1967 105:79 106:348 107:1048 108:628 109:2144 110:1211 111:1463 112:830 113:1119 114:866 115:1376 116:1511 117:1117 118:1954 119:1474 120:469 121:1154 122:2176 123:1843 124:1561 125:1726 128:702 129:368 130:430 131:1246 132:539 133:166 134:427 135:106 136:350 137:325 138:1329 139:171 140:248 141:438 142:657 143:543 144:575 145:127 146:769 147:595 148:1265 149:436 150:596 151:797 152:568 153:258 154:495 155:885 156:421 157:424 158:346 159:1061 160:426 161:670 162:2124 163:464 164:693 165:857 166:301 167:874 168:1232 169:196 170:1402 171:251 172:279 173:1525 174:712 175:716 176:1459 177:3933 178:2195 179:1005 180:1936 181:1557 182:1811 183:635 184:746 185:4347 186:2921 187:1880 188:2110 189:1685 190:7615 191:1169 192:8597 193:5667 194:4269 195:3672 196:1956 197:1094 198:5477 199:5518 200:6669 201:3290 202:9788 203:9216 204:4548 205:2741 206:3028 207:2980 208:4001 209:3892 210:3755 211:2042 212:2572 213:2211 214:848 215:72 216:5762 217:1800 218:802 219:533 220:1569 221:822 222:722 223:831 End of report From Valdis.Kletnieks at vt.edu Fri Sep 25 18:35:20 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 25 Sep 2015 14:35:20 -0400 Subject: GeoIP information In-Reply-To: References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> <560523C1.2000200@satchell.net> <66936.1443199486@turing-police.cc.vt.edu> Message-ID: <5807.1443206120@turing-police.cc.vt.edu> On Fri, 25 Sep 2015 13:39:22 -0400, Clay Curtis said: > exclusively. I have dealt with cases in which a CDN responded to a client > request with a resource on another continent, thus having to cross an ocean > and adding considerable latency, when there was a POP on that continent. And what was the root cause for the CDN to misfire that badly? I hereby submit the hypothesis that if a CDN's data tables are so dorked up that they're serving the data from the wrong continent, adding physical location probably won't help, and may make things even worse. (For instance, consider a location in Alaska, where the *closest* CDN may be one in the northwest part of Canada - specifically put there because the network is at the wrong end of a satellite link. You almost certainly want to skip that one and hit one in Seattle or someplace similar....) > If the CDN could have LOC information that is more accurate/updated, it could > allow them to make a better decision and direct a client to a resource that is > physically closer.? You don't want the one that's physically closest. You want the one that's netwise closest. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jake.mertel at ubiquityhosting.com Fri Sep 25 18:42:54 2015 From: jake.mertel at ubiquityhosting.com (Jake Mertel) Date: Fri, 25 Sep 2015 11:42:54 -0700 Subject: Synful Knock questions... In-Reply-To: <55F97DD4.2090204@lists.esoteric.ca> References: <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> <55F8F567.2000309@mykolab.com> <55F97C6B.3020807@lists.esoteric.ca> <55F97DD4.2090204@lists.esoteric.ca> Message-ID: Looks like Cisco's Talos just released a tool to scan your network for indications of the SYNful Knock malware. Details @ http://talosintel.com/scanner/ . -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Wed, Sep 16, 2015 at 7:33 AM, Stephen Fulton wrote: > Follow-up to my own post, Fireeye has code on github: > > https://github.com/fireeye/synfulknock > > > On 2015-09-16 10:27 AM, Stephen Fulton wrote: > >> Interesting, anyone have more details on how to construct the scan using >> something like nmap? >> >> -- Stephen >> >> On 2015-09-16 9:20 AM, Royce Williams wrote: >> >>> HD Moore just posted the results of a full-Internet ZMap scan. I didn't >>> realize that it was remotely detectable. >>> >>> 79 hosts total in 19 countries. >>> >>> https://zmap.io/synful/ >>> >>> Royce >>> >>> From baldur.norddahl at gmail.com Fri Sep 25 19:17:58 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 25 Sep 2015 21:17:58 +0200 Subject: GeoIP information In-Reply-To: References: <20150925005219.GA23573@esri.com> <20150925014539.GA24575@esri.com> <5604F626.3030905@web2objects.com> <41D06BDF-41B5-44CB-B172-955CD09987CF@arbor.net> Message-ID: On 25 September 2015 at 17:52, Josh Luthman wrote: > With a new block it took less than a week. > > On Sep 25, 2015 11:36 AM, "Baldur Norddahl" > wrote: > >> You will find that it takes years before every site out there updated >> their >> copy of whatever geo database they are using. >> > Our original /22 block from RIPE has never had any geo IP issues. Everyone seems to recognize the country correctly from day 1. However our transferred blocks from Romania are still have issues a year later. Every geo IP database knows the correct location. But nothing forces customers of the database to actually keep their copy updated. So we keep getting complaints that this or that site is reporting the wrong country. Some of those sites are big sites that should know better. It is impossible to hunt down every single e-commerce site out there and force them to update their geo IP database. A lot of them have no clue what you are talking about. They either bought a hosted solution, and the tech guy you really want to talk to is somewhere else. Or they used contractors to build the system and now it is on auto pilot. Or you simply can't get through customer support to the tech people that know what geo IP actually is. At the end of the day, you are not going to waste too much time trying to beat clue into the heads of people running some niche site specialising in selling pink shoes, that refused to take the order from one customer because their brain dead e-commerce solution believes the customer is located in the wrong country. Regards, Baldur From nick at foobar.org Fri Sep 25 20:59:29 2015 From: nick at foobar.org (Nick Hilliard) Date: Fri, 25 Sep 2015 21:59:29 +0100 Subject: Ear protection In-Reply-To: <56027213.6030700@foobar.org> References: <56027213.6030700@foobar.org> Message-ID: <5605B5B1.1070101@foobar.org> On 23/09/2015 10:34, Nick Hilliard wrote: > What are people using for ear protection for datacenters these days? Summarising, people seem to use a wide variety of kit: Ear muffs: - 3M Peltor Shotgunner Hearing Protector - 3M Peltor Optime Acoustic headsets: - 3M Peltor WS100 - Howard Leight Thunder 29 - Sennheiser HD-380 / HD-380 Noise cancellation headsets: - "Bose noise-cancellation headsets" - Bose QuietComfort 15 Acoustic ear plugs: - Shure SE215 / Shure 425 (isolating earphones) - V-MODA Faders VIP Tuned Metal Earplugs - Westone Custom ES10 non-foam ear plugs: - 3M Peltor Combat / Arms Earplugs - Sonic Defender EP3, EP4, EP5, EP7 - Westone DefendEar - Etymotic Research ER20 Earplugs foam ear plugs: - Moldex pura-fit - Howard Leight Laser Lite - Flents "Quiet Please" - 3M E-A-R Classic earplugs thanks to all those who contributed + particularly for the discussion on acoustic measurement and analysis. Nick From cidr-report at potaroo.net Fri Sep 25 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Sep 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201509252200.t8PM00sU009435@wattle.apnic.net> This report has been generated at Fri Sep 25 21:15:27 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 18-09-15 571458 309706 19-09-15 572359 309818 20-09-15 572139 310001 21-09-15 572363 310386 22-09-15 572532 311110 23-09-15 572813 311028 24-09-15 572876 310926 25-09-15 572863 310891 AS Summary 51813 Number of ASes in routing system 20531 Number of ASes announcing only one prefix 5608 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center,CN 121035264 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'). --- 25Sep15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 572634 310900 261734 45.7% All ASes AS22773 3195 174 3021 94.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4538 5608 2808 2800 49.9% ERX-CERNET-BKB China Education and Research Network Center,CN AS17974 2710 90 2620 96.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2474 21 2453 99.2% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS7545 2942 649 2293 77.9% TPG-INTERNET-AP TPG Telecom Limited,AU AS6389 2686 478 2208 82.2% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS9394 2100 206 1894 90.2% CTTNET China TieTong Telecommunications Corporation,CN AS28573 2185 306 1879 86.0% NET Servi?os de Comunica??o S.A.,BR AS3356 2530 770 1760 69.6% LEVEL3 - Level 3 Communications, Inc.,US AS4766 3012 1279 1733 57.5% KIXS-AS-KR Korea Telecom,KR AS10620 3382 1658 1724 51.0% Telmex Colombia S.A.,CO AS9808 1613 89 1524 94.5% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1738 245 1493 85.9% ITCDELTA - Earthlink, Inc.,US AS4755 2047 561 1486 72.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS20115 1887 406 1481 78.5% CHARTER-NET-HKY-NC - Charter Communications,US AS9498 1390 118 1272 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1591 406 1185 74.5% TWTC - tw telecom holdings, inc.,US AS18566 2168 1010 1158 53.4% MEGAPATH5-US - MegaPath Corporation,US AS38285 1170 18 1152 98.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS7552 1447 357 1090 75.3% VIETEL-AS-AP Viettel Corporation,VN AS22561 1284 215 1069 83.3% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS4812 1575 526 1049 66.6% CHINANET-SH-AP China Telecom (Group),CN AS7303 1566 529 1037 66.2% Telecom Argentina S.A.,AR AS8402 1056 21 1035 98.0% CORBINA-AS OJSC "Vimpelcom",RU AS4808 1536 517 1019 66.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS38197 1461 465 996 68.2% SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK AS8151 1849 857 992 53.7% Uninet S.A. de C.V.,MX AS4788 1346 404 942 70.0% TMNET-AS-AP TM Net, Internet Service Provider,MY AS26615 1081 156 925 85.6% Tim Celular S.A.,BR AS7738 997 79 918 92.1% Telemar Norte Leste S.A.,BR Total 61626 15418 46208 75.0% Top 30 total Possible Bogus Routes 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 23.249.144.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 23.249.144.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 23.249.152.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 27.50.8.0/24 AS55548 27.50.9.0/24 AS55548 27.50.10.0/24 AS55548 27.50.11.0/24 AS55548 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.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.3.0/24 AS37004 -Reserved AS-,ZZ 41.73.4.0/24 AS37004 -Reserved AS-,ZZ 41.73.5.0/24 AS37004 -Reserved AS-,ZZ 41.73.6.0/24 AS37004 -Reserved AS-,ZZ 41.73.7.0/24 AS37004 -Reserved AS-,ZZ 41.73.8.0/24 AS37004 -Reserved AS-,ZZ 41.73.9.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.17.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.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.126.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -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.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.57.192.0/22 AS33321 -Reserved AS-,ZZ 64.234.239.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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.187.240.0/24 AS22753 REDHAT-0 - Red Hat, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.228.160.0/20 AS7233 YAHOO-US - Yahoo,US 66.228.176.0/21 AS17110 YAHOO-US2 - Yahoo,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 68.234.0.0/19 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.0.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.5.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.7.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.16.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.17.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.18.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.19.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.20.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.21.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.22.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.23.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.24.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.26.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.28.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 68.234.29.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 69.24.96.0/20 AS26804 -Reserved AS-,ZZ 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.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 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.213.220.0/24 AS19662 -Reserved AS-,ZZ 91.217.120.0/23 AS51563 -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.100.1.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd,IN 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.12.48.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.12.241.0/24 AS7718 TRANSACT-SDN-AS TransACT Capital Communications Pty Limited,AU 103.12.247.0/24 AS13233 103.14.32.0/22 AS2519 VECTANT VECTANT Ltd.,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.22.212.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.25.144.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.29.90.0/23 AS9503 FX-PRIMARY-AS FX Networks Limited,AU 103.29.236.0/24 AS13200 103.29.237.0/24 AS13200 103.198.0.0/16 AS7497 CSTNET-AS-AP Computer Network Information Center,CN 103.199.0.0/16 AS7497 CSTNET-AS-AP Computer Network Information Center,CN 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.229.152.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.232.164.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.233.140.0/23 AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK,AF 103.235.72.0/23 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.235.74.0/23 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.235.216.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.237.76.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.253.164.0/23 AS13317 116.199.203.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.205.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.206.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 116.199.207.0/24 AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID 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 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 143.137.196.0/22 AS61902 Bahialink - Technology,BR 143.137.228.0/22 AS26373 CLNETWORKS SA,HN 151.216.32.0/24 AS20199 SERVERPARS Rayan Pardaz Khorshid Shargh Ltd.,IR 154.168.28.0/23 AS29571 CITelecom-AS,CI 155.35.0.0/16 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.1.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.34.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.35.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.46.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.47.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 155.35.232.0/24 AS9418 CA-ASIAPAC-AS-AP Computer Associates Asia Pacific,AU 160.30.0.0/16 AS20421 LLC-ASPECT-AS LLC Aspect,RU 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.221.64.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 162.221.64.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 162.221.68.0/22 AS40430 COLO4JAX-AS - colo4jax, 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.88.48.0/20 AS29927 -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.249.191.0/24 AS45816 ISHK-AP I-Services Network Solution Limited,HK 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.191.0.0/16 AS20053 RELAX-LLC-AS LLC Relax,RU 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.52.57.0/24 AS48039 KGT-AS KGT new media,DE 185.52.58.0/24 AS48039 KGT-AS KGT new media,DE 185.118.240.0/24 AS20395 185.118.241.0/24 AS20395 185.118.242.0/24 AS20395 185.118.243.0/24 AS20395 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.67.160.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.67.161.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.67.162.0/24 AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.46.0/23 AS17139 NETRANGE - Corporate Colocation 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.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.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 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.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 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.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 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.151.160.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.130.0/24 AS21104 AM-NETSYS-AS Netsys JV LLC,AM 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.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.9.9.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.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.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 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.180.0/24 AS37004 -Reserved AS-,ZZ 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.8.72.0/21 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.72.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.76.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.77.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.78.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.8.79.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 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.91.44.0/22 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.44.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.45.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.46.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,US 198.91.47.0/24 AS40430 COLO4JAX-AS - colo4jax, LLC,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.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -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.103.89.0/24 AS19523 -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.182.207.0/24 AS23136 ONX - OnX Enterprise Solutions Inc.,CA 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 201.131.5.0/24 AS28389 -Reserved AS-,ZZ 201.131.88.0/24 AS8151 Uninet S.A. de C.V.,MX 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.6.208.0/24 AS23937 203.6.209.0/24 AS23937 203.6.210.0/24 AS23937 203.6.211.0/24 AS23937 203.6.213.0/24 AS23937 203.6.215.0/24 AS23937 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 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 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 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 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.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.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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 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.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.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 217.147.6.0/24 AS8936 ASKUBAN CJSC Orbita,RU 217.147.7.0/24 AS8936 ASKUBAN CJSC Orbita,RU 217.147.10.0/24 AS8936 ASKUBAN CJSC Orbita,RU 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 Sep 25 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Sep 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201509252200.t8PM01MC009450@wattle.apnic.net> BGP Update Report Interval: 17-Sep-15 -to- 24-Sep-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 174784 3.8% 121.8 -- BSNL-NIB National Internet Backbone,IN 2 - AS21669 119501 2.6% 29875.2 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 3 - AS22059 100596 2.2% 50298.0 -- -Reserved AS-,ZZ 4 - AS6917 88950 2.0% 6353.6 -- MULTEXSYS - Multex Systems, Inc.,US 5 - AS45528 80512 1.8% 131.6 -- TDN Tikona Digital Networks Pvt Ltd.,IN 6 - AS24378 75945 1.7% 274.2 -- ENGTAC-AS-TH-AP Total Access Communication PLC.,TH 7 - AS133722 63991 1.4% 31995.5 -- MCARBON-AS mCarbon Tech Innovation Private Limited,IN 8 - AS3709 61341 1.4% 2271.9 -- NET-CITY-SA - City of San Antonio,US 9 - AS4771 41839 0.9% 820.4 -- SPARKNZ Spark New Zealand Trading Ltd.,NZ 10 - AS30295 33530 0.7% 11176.7 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 11 - AS8001 31965 0.7% 2131.0 -- NET-ACCESS-CORP - Net Access Corporation,US 12 - AS131090 30445 0.7% 982.1 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 13 - AS56636 27932 0.6% 27932.0 -- ASVEDARU VEDA Ltd.,RU 14 - AS9198 26761 0.6% 32.2 -- KAZTELECOM-AS JSC Kazakhtelecom,KZ 15 - AS28287 26118 0.6% 669.7 -- Acer Telecomunica??es ltda,BR 16 - AS8402 25211 0.6% 97.7 -- CORBINA-AS OJSC "Vimpelcom",RU 17 - AS3816 23605 0.5% 52.8 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 18 - AS16509 23515 0.5% 196.0 -- AMAZON-02 - Amazon.com, Inc.,US 19 - AS5384 23512 0.5% 179.5 -- EMIRATES-INTERNET Emirates Telecommunications Corporation,AE 20 - AS2697 20217 0.4% 153.2 -- ERX-ERNET-AS Education and Research Network,IN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS22059 100596 2.2% 50298.0 -- -Reserved AS-,ZZ 2 - AS133722 63991 1.4% 31995.5 -- MCARBON-AS mCarbon Tech Innovation Private Limited,IN 3 - AS21669 119501 2.6% 29875.2 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 4 - AS56636 27932 0.6% 27932.0 -- ASVEDARU VEDA Ltd.,RU 5 - AS200671 18462 0.4% 18462.0 -- SKOK-JAWORZNO SKOK Jaworzno,PL 6 - AS13737 13563 0.3% 13563.0 -- RIVERFRONT - Riverfront Communications LLC,US 7 - AS134438 11488 0.2% 11488.0 -- AIRAAIFUL-AS-AP Aira & Aiful Public Company Limited,TH 8 - AS30295 33530 0.7% 11176.7 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 9 - AS200008 8142 0.2% 8142.0 -- PIRUM-AS Pirum Systems Limited,GB 10 - AS40493 8085 0.2% 8085.0 -- FACILITYSOURCEINC - FacilitySource,US 11 - AS37590 7649 0.2% 7649.0 -- BCA-ASN,AO 12 - AS3708 6625 0.1% 6625.0 -- -Reserved AS-,ZZ 13 - AS6917 88950 2.0% 6353.6 -- MULTEXSYS - Multex Systems, Inc.,US 14 - AS38447 6306 0.1% 6306.0 -- CBL-AS-AP CBL Group Content Service Provider AS for AP,AU 15 - AS37473 9128 0.2% 4564.0 -- TELESOM,SO 16 - AS199367 3109 0.1% 3109.0 -- AS_GBP Globe Business Publishing Limited,GB 17 - AS35093 4548 0.1% 2274.0 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 18 - AS3709 61341 1.4% 2271.9 -- NET-CITY-SA - City of San Antonio,US 19 - AS8001 31965 0.7% 2131.0 -- NET-ACCESS-CORP - Net Access Corporation,US 20 - AS13092 8122 0.2% 2030.5 -- UB-AS Akademska mreza Republike Srbije - AMRES,RS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 209.212.8.0/24 119484 2.5% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 2 - 76.191.107.0/24 50369 1.1% AS22059 -- -Reserved AS-,ZZ 3 - 64.34.125.0/24 50227 1.1% AS22059 -- -Reserved AS-,ZZ 4 - 103.49.244.0/24 32105 0.7% AS133722 -- MCARBON-AS mCarbon Tech Innovation Private Limited,IN 5 - 192.135.223.0/24 31951 0.7% AS8001 -- NET-ACCESS-CORP - Net Access Corporation,US 6 - 103.49.245.0/24 31886 0.7% AS133722 -- MCARBON-AS mCarbon Tech Innovation Private Limited,IN 7 - 61.7.155.0/24 30210 0.6% AS131090 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 8 - 195.128.159.0/24 27932 0.6% AS56636 -- ASVEDARU VEDA Ltd.,RU 9 - 155.133.79.0/24 18462 0.4% AS200671 -- SKOK-JAWORZNO SKOK Jaworzno,PL 10 - 191.241.243.0/24 17971 0.4% AS28669 -- America-NET Ltda.,BR 11 - 216.150.230.0/24 13563 0.3% AS13737 -- RIVERFRONT - Riverfront Communications LLC,US 12 - 193.151.109.0/24 12377 0.3% AS31480 -- GLOBAL-TS-AS Global Telesystems Inc.,RU 13 - 199.60.236.0/24 12138 0.3% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 14 - 199.60.234.0/23 11492 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 15 - 110.170.17.0/24 11488 0.2% AS134438 -- AIRAAIFUL-AS-AP Aira & Aiful Public Company Limited,TH 16 - 66.19.194.0/24 10866 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 17 - 5.136.192.0/18 10753 0.2% AS12389 -- ROSTELECOM-AS PJSC Rostelecom,RU 18 - 202.41.83.0/24 10214 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network,IN 19 - 199.60.233.0/24 9900 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 20 - 197.157.247.0/24 9078 0.2% AS37473 -- TELESOM,SO 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 codygrosskopf at gmail.com Fri Sep 25 22:52:17 2015 From: codygrosskopf at gmail.com (Cody Grosskopf) Date: Fri, 25 Sep 2015 15:52:17 -0700 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: a) yes, 56,000 students and any on Chrome failed. I immediately blocked quic and told users to restart Chrome. Luckily the fallback to good ol' tcp saved the day. b) I had this issue a few months ago and it subsided quickly Google reports it's an issue in this version of Chrome and the next version will have a little smarts to automatically re initiate the connection with TCP automatically without having to disable quic. On Wed, Sep 23, 2015 at 5:01 PM, Sean Hunter wrote: > Hi all, > > I work for a 2500 user university and we've seen some odd behavior > recently. 2-4 weeks ago we started seeing Google searches that would fail > for ~2 minutes, or disconnects in Gmail briefly. This week, and > particularly in the last 2-3 days, we've had reports from numerous users on > campus, even those who generally do not complain unless an issue has been > ongoing for a while. Those reports include Drive disconnecting, searches > failing, Gmail presenting a "007" error, and calendar failing to create > events. > > In fact, the issue became so widespread today, that the campus paper is > writing about it as a last minute article before they're weekly > publication's deadline this evening. (Important in our little world where > we try to look good.) > > We aren't really staffed or equipped to figure out exactly what's happening > (and issues are sporadic, so packet captures are difficult, to say the > least), but we found that disabling QUIC dramatically and immediately > improved the experience of a couple of users on campus. We're recommending > via the paper that others do so as well. > > What I'm curious about is: > > a) Has anyone here had a similar experience? Was the root cause QUIC in > your case? > > b) Has anyone noticed anything remotely similar in the last few > weeks/days/today? > > We're an Apps domain, so this may be specific to universities in the Apps > universe. > > If anyone has any useful information or hints, or if someone from Google > would like more information, please feel free to contact me, on or off > list. > > Thanks for reading and have a great night everyone! Happy Wednesday! > From cb.list6 at gmail.com Fri Sep 25 23:20:44 2015 From: cb.list6 at gmail.com (Ca By) Date: Fri, 25 Sep 2015 16:20:44 -0700 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: On Friday, September 25, 2015, Cody Grosskopf > wrote: > a) yes, 56,000 students and any on Chrome failed. I immediately blocked > quic and told users to restart Chrome. Luckily the fallback to good ol' tcp > saved the day. > > b) I had this issue a few months ago and it subsided quickly > > Google reports it's an issue in this version of Chrome and the next version > will have a little smarts to automatically re initiate the connection with > TCP automatically without having to disable quic. > > I remained very disappointed in how google has gone about quic. They are dismissive of network operators concerns (quic protocol list and ietf), cause substantial outages, and have lost a lot of good will in the process Here's your post mortem: RFO: Google unilaterally deployed a non-standard protocol to our production environment, driving up helpdesk calls x% After action: block udp 80/443 until production ready and standard ratified use deployed. And. Get off my lawn. On Wed, Sep 23, 2015 at 5:01 PM, Sean Hunter wrote: > > > Hi all, > > > > I work for a 2500 user university and we've seen some odd behavior > > recently. 2-4 weeks ago we started seeing Google searches that would fail > > for ~2 minutes, or disconnects in Gmail briefly. This week, and > > particularly in the last 2-3 days, we've had reports from numerous users > on > > campus, even those who generally do not complain unless an issue has been > > ongoing for a while. Those reports include Drive disconnecting, searches > > failing, Gmail presenting a "007" error, and calendar failing to create > > events. > > > > In fact, the issue became so widespread today, that the campus paper is > > writing about it as a last minute article before they're weekly > > publication's deadline this evening. (Important in our little world where > > we try to look good.) > > > > We aren't really staffed or equipped to figure out exactly what's > happening > > (and issues are sporadic, so packet captures are difficult, to say the > > least), but we found that disabling QUIC dramatically and immediately > > improved the experience of a couple of users on campus. We're > recommending > > via the paper that others do so as well. > > > > What I'm curious about is: > > > > a) Has anyone here had a similar experience? Was the root cause QUIC in > > your case? > > > > b) Has anyone noticed anything remotely similar in the last few > > weeks/days/today? > > > > We're an Apps domain, so this may be specific to universities in the Apps > > universe. > > > > If anyone has any useful information or hints, or if someone from Google > > would like more information, please feel free to contact me, on or off > > list. > > > > Thanks for reading and have a great night everyone! Happy Wednesday! > > > From tknchris at gmail.com Fri Sep 25 23:49:00 2015 From: tknchris at gmail.com (chris) Date: Fri, 25 Sep 2015 19:49:00 -0400 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: This reminds me of something I ran into where I came to a similar conclusion. We had a customer who used google ad and docs products very heavily and all of a sudden they started getting captchas on accessing any google property. When we reached out to google we were told that they were "blacklisted" based on suspicious search queries or some kind of query manipulation that they believe was caused by malware. We search high and low internally and could not find anything and asked them to provide specifics about what they saw and they would not and then we tried to monitor network traffic we realized that google had just implemented SSL search as a default so we could not easily inspect the search traffic without putting in infrastructure that could do MITM and allow us to inspect (which we also suspected doing this could have serious blowback) At the end of the day the customer was extremely frustrated because they used google apps for their entire business and google insisted it was on their end but we couldnt not get any factual evidence and we would have had to do some really questionable things to try to go at debugging it on our own. TLDR, customer eventually bailed on all their google products because it scared them and reaching a human at google through regular channels was near impossible except through mazes of filling out forms and waiting 24hrs per email response. Even when we were able to connect with a fellow googler on nanog who tried to be helpful even though he wasnt on the right team we still got nowhere This is really the dark side of the "cloud" (no pun intended), when a company makes some kind of change or an event occurs with no communication and it backfires. Even the most basic advanced notifications or just having proper support available when a change occurs can be more important than the technical aspects. chris On Fri, Sep 25, 2015 at 7:20 PM, Ca By wrote: > On Friday, September 25, 2015, Cody Grosskopf > wrote: > > > a) yes, 56,000 students and any on Chrome failed. I immediately blocked > > quic and told users to restart Chrome. Luckily the fallback to good ol' > tcp > > saved the day. > > > > b) I had this issue a few months ago and it subsided quickly > > > > Google reports it's an issue in this version of Chrome and the next > version > > will have a little smarts to automatically re initiate the connection > with > > TCP automatically without having to disable quic. > > > > > I remained very disappointed in how google has gone about quic. > > They are dismissive of network operators concerns (quic protocol list and > ietf), cause substantial outages, and have lost a lot of good will in the > process > > Here's your post mortem: > > RFO: Google unilaterally deployed a non-standard protocol to our production > environment, driving up helpdesk calls x% > > After action: block udp 80/443 until production ready and standard ratified > use deployed. > > And. > > Get off my lawn. > > > > On Wed, Sep 23, 2015 at 5:01 PM, Sean Hunter wrote: > > > > > Hi all, > > > > > > I work for a 2500 user university and we've seen some odd behavior > > > recently. 2-4 weeks ago we started seeing Google searches that would > fail > > > for ~2 minutes, or disconnects in Gmail briefly. This week, and > > > particularly in the last 2-3 days, we've had reports from numerous > users > > on > > > campus, even those who generally do not complain unless an issue has > been > > > ongoing for a while. Those reports include Drive disconnecting, > searches > > > failing, Gmail presenting a "007" error, and calendar failing to create > > > events. > > > > > > In fact, the issue became so widespread today, that the campus paper is > > > writing about it as a last minute article before they're weekly > > > publication's deadline this evening. (Important in our little world > where > > > we try to look good.) > > > > > > We aren't really staffed or equipped to figure out exactly what's > > happening > > > (and issues are sporadic, so packet captures are difficult, to say the > > > least), but we found that disabling QUIC dramatically and immediately > > > improved the experience of a couple of users on campus. We're > > recommending > > > via the paper that others do so as well. > > > > > > What I'm curious about is: > > > > > > a) Has anyone here had a similar experience? Was the root cause QUIC in > > > your case? > > > > > > b) Has anyone noticed anything remotely similar in the last few > > > weeks/days/today? > > > > > > We're an Apps domain, so this may be specific to universities in the > Apps > > > universe. > > > > > > If anyone has any useful information or hints, or if someone from > Google > > > would like more information, please feel free to contact me, on or off > > > list. > > > > > > Thanks for reading and have a great night everyone! Happy Wednesday! > > > > > > From list at satchell.net Sat Sep 26 00:43:55 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 25 Sep 2015 17:43:55 -0700 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: <5605EA4B.8070001@satchell.net> On 09/25/2015 04:20 PM, Ca By wrote: > RFO: Google unilaterally deployed a non-standard protocol to our production > environment, driving up helpdesk calls x% > > After action: block udp 80/443 until production ready and standard ratified > use deployed. Let me be gentle about this. Why were you allowing 80/udp and 443/udp in the first place into your production environment? In my network, I run a mostly-closed firewall, only allowing those ports that are needed to be forwarded between the inside and outside networks. I don't have -- or need -- a DMZ here at this time, so I don't have to worry about that side of the routing triangle. If I did, I would also run mostly closed between inside/outside and the DMZ. I'm liberal about opening ports on request, but the ports have to be requested before I'll allow them in, out, or forwarded. From larrysheldon at cox.net Sat Sep 26 04:13:39 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 25 Sep 2015 23:13:39 -0500 Subject: Malware? Spammer? Message-ID: <56061B73.50102@cox.net> Does NANOG have a problem, or do I have a more local masquerader? -- sed quis custodiet ipsos custodes? (Juvenal) From jamesb2147 at gmail.com Sat Sep 26 04:26:21 2015 From: jamesb2147 at gmail.com (Sean Hunter) Date: Fri, 25 Sep 2015 23:26:21 -0500 Subject: Recent trouble with QUIC? In-Reply-To: <5605EA4B.8070001@satchell.net> References: <5605EA4B.8070001@satchell.net> Message-ID: These are all interesting viewpoints. Personally, I was only surprised that Google didn't: A) identify the issue during early rollout (starting Sept 9) when Google has specifically talked up to the community their tooling for monitoring QUIC changes B) catch what seems like a pretty basic bug during Chrome code reviews C) identify the problem more quickly once they realized that *something* was wrong (I guess another tooling issue) D) roll back more quickly (though perhaps identification was really the delaying factor here) I do find the anecdote about support amusing, though. Google has always resisted providing support of any kind; I think it's a culture that comes from their extremely strong engineering history where needing support is viewed as a failure of the engineering and product teams. Recovery times could probably be improved if they had a help desk, but I'm not sure customer satisfaction would be improved in any significantly value adding way. The lesson I walked away with is that if you don't want QUIC on your network, don't allow it. At my institution, I think we view this the same way we'd view a problem with any website; we're only responsible for making sure your packets are flowing out to the internet and back. Finally, thanks to all who responded. It's been an informative experience. On Sep 25, 2015 7:45 PM, "Stephen Satchell" wrote: > On 09/25/2015 04:20 PM, Ca By wrote: > >> RFO: Google unilaterally deployed a non-standard protocol to our >> production >> environment, driving up helpdesk calls x% >> >> After action: block udp 80/443 until production ready and standard >> ratified >> use deployed. >> > > Let me be gentle about this. Why were you allowing 80/udp and 443/udp in > the first place into your production environment? > > In my network, I run a mostly-closed firewall, only allowing those ports > that are needed to be forwarded between the inside and outside networks. > > I don't have -- or need -- a DMZ here at this time, so I don't have to > worry about that side of the routing triangle. If I did, I would also run > mostly closed between inside/outside and the DMZ. > > I'm liberal about opening ports on request, but the ports have to be > requested before I'll allow them in, out, or forwarded. > From matthew at matthew.at Sat Sep 26 05:07:25 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 25 Sep 2015 22:07:25 -0700 Subject: Recent trouble with QUIC? In-Reply-To: <5605EA4B.8070001@satchell.net> References: <5605EA4B.8070001@satchell.net> Message-ID: <5606280D.3060706@matthew.at> On 9/25/15 5:43 PM, Stephen Satchell wrote: > On 09/25/2015 04:20 PM, Ca By wrote: >> RFO: Google unilaterally deployed a non-standard protocol to our >> production >> environment, driving up helpdesk calls x% >> >> After action: block udp 80/443 until production ready and standard >> ratified >> use deployed. > > Let me be gentle about this. Why were you allowing 80/udp and 443/udp > in the first place into your production environment? > Which ISP do you run that blocks UDP by default? I'm curious, so I can be sure I don't buy mislabeled "Internet" service from you. Matthew Kaufman From eyeronic.design at gmail.com Sat Sep 26 07:20:10 2015 From: eyeronic.design at gmail.com (Mike Hale) Date: Sat, 26 Sep 2015 00:20:10 -0700 Subject: Recent trouble with QUIC? In-Reply-To: <5606280D.3060706@matthew.at> References: <5605EA4B.8070001@satchell.net> <5606280D.3060706@matthew.at> Message-ID: OH SNAP! On Fri, Sep 25, 2015 at 10:07 PM, Matthew Kaufman wrote: > > > On 9/25/15 5:43 PM, Stephen Satchell wrote: >> >> On 09/25/2015 04:20 PM, Ca By wrote: >>> >>> RFO: Google unilaterally deployed a non-standard protocol to our >>> production >>> environment, driving up helpdesk calls x% >>> >>> After action: block udp 80/443 until production ready and standard >>> ratified >>> use deployed. >> >> >> Let me be gentle about this. Why were you allowing 80/udp and 443/udp in >> the first place into your production environment? >> > > Which ISP do you run that blocks UDP by default? I'm curious, so I can be > sure I don't buy mislabeled "Internet" service from you. > > Matthew Kaufman -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From A.L.M.Buxey at lboro.ac.uk Sat Sep 26 08:21:15 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Sat, 26 Sep 2015 09:21:15 +0100 Subject: Ear protection In-Reply-To: <5605B5B1.1070101@foobar.org> References: <56027213.6030700@foobar.org> <5605B5B1.1070101@foobar.org> Message-ID: <175A8E96-EE05-4E62-8487-5310E95CCFAF@lboro.ac.uk> Great summary of the thread No-one using remote control robots with video feed etc for working in these environments then? Plans to? ;) alan From randy at psg.com Sat Sep 26 09:11:28 2015 From: randy at psg.com (Randy Bush) Date: Sat, 26 Sep 2015 18:11:28 +0900 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> Message-ID: > The IPv4 free pool for the ARIN region is now depleted and the world goes on randy From jcurran at arin.net Sat Sep 26 11:31:24 2015 From: jcurran at arin.net (John Curran) Date: Sat, 26 Sep 2015 11:31:24 +0000 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> Message-ID: <39DF296B-D19B-4E02-9F65-F1650AE7F59B@arin.net> On Sep 26, 2015, at 5:11 AM, Randy Bush > wrote: The IPv4 free pool for the ARIN region is now depleted and the world goes on Indeed. ?then again, the real traffic growth having already moved off of IPv4 to IPv6 probably helps a bit - FYI, /John John Curran President and CEO ARIN From dhubbard at dino.hostasaurus.com Sat Sep 26 14:34:09 2015 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Sat, 26 Sep 2015 10:34:09 -0400 Subject: Question re session hijacking in dual stack environments w/MacOS Message-ID: Hey all, as we've slowly deployed IPv6 to our end users, it has begun to cause some issues for those on Mac's specifically. Apple apparently has an algorithm at some point in the network stack to decide whether IPv4 or IPv6 is, perhaps, 'better' or 'faster' at any given point in time during an ongoing session. This allows a computer talking to a dual stack remote website to flip flop between v4 and v6 as activity is conducted. Websites that require some type of authentication that is handled via session cookies have been booting our users out randomly with "your ip address has changed" type message. This occurs when their Mac decides to switch between protocols because the site views it as a session hijacking attempt when Joe User with session ID xyz switches from 192.0.2.10 to 2001:db8::1:1:a or vice versa. Has anyone run into this? Our users on other platforms don't seem to have this issue; linux and MS desktops seem to just use v6 if it's available and v4 if not. Thanks, David From cb.list6 at gmail.com Sat Sep 26 14:47:02 2015 From: cb.list6 at gmail.com (Ca By) Date: Sat, 26 Sep 2015 07:47:02 -0700 Subject: Question re session hijacking in dual stack environments w/MacOS In-Reply-To: References: Message-ID: On Saturday, September 26, 2015, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Hey all, as we've slowly deployed IPv6 to our end users, it has begun to > cause some issues for those on Mac's specifically. Apple apparently has > an algorithm at some point in the network stack to decide whether IPv4 > or IPv6 is, perhaps, 'better' or 'faster' at any given point in time > during an ongoing session. This allows a computer talking to a dual > stack remote website to flip flop between v4 and v6 as activity is > conducted. > > Websites that require some type of authentication that is handled via > session cookies have been booting our users out randomly with "your ip > address has changed" type message. This occurs when their Mac decides > to switch between protocols because the site views it as a session > hijacking attempt when Joe User with session ID xyz switches from > 192.0.2.10 to 2001:db8::1:1:a or vice versa. > > Has anyone run into this? Our users on other platforms don't seem to > have this issue; linux and MS desktops seem to just use v6 if it's > available and v4 if not. > > Thanks, > > David > Info about Apple and their unique IPv6 selection process https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html From jwbensley at gmail.com Sat Sep 26 14:54:16 2015 From: jwbensley at gmail.com (James Bensley) Date: Sat, 26 Sep 2015 15:54:16 +0100 Subject: Recent trouble with QUIC? In-Reply-To: References: <5605EA4B.8070001@satchell.net> <5606280D.3060706@matthew.at> Message-ID: On 26 September 2015 at 08:20, Mike Hale wrote: > OH SNAP! Tiny Rick!!! From laszlo at heliacal.net Sat Sep 26 15:39:03 2015 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Sat, 26 Sep 2015 15:39:03 +0000 Subject: Question re session hijacking in dual stack environments w/MacOS In-Reply-To: References: Message-ID: <5606BC17.3050100@heliacal.net> On 2015-09-26 14:34, David Hubbard wrote: > Websites that require some type of authentication that is handled via > session cookies have been booting our users out randomly with "your ip > address has changed" type message. This occurs when their Mac decides > to switch between protocols because the site views it as a session > hijacking attempt when Joe User with session ID xyz switches from > 192.0.2.10 to 2001:db8::1:1:a or vice versa. > > This sounds like a really poor practice on the part of the website operators. Users on wireless devices may be switching networks throughout the same session (wifi/LTE), or there could be a cluster of proxies, or short DHCP leases, or tor circuit changes, or privacy extensions, etc. This is almost as bad as using GeoIP databases to authenticate. -Laszlo From hank at efes.iucc.ac.il Sat Sep 26 19:04:02 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 26 Sep 2015 22:04:02 +0300 Subject: Synful Knock questions... In-Reply-To: References: <55F97DD4.2090204@lists.esoteric.ca> <00c201d0efe2$8c556b40$a50041c0$@truenet.com> <55F883AE.9090705@satchell.net> <55F8F567.2000309@mykolab.com> <55F97C6B.3020807@lists.esoteric.ca> <55F97DD4.2090204@lists.esoteric.ca> Message-ID: <5.1.1.6.2.20150926220344.04fbf0e8@efes.iucc.ac.il> At 11:42 25/09/2015 -0700, Jake Mertel wrote: >Looks like Cisco's Talos just released a tool to scan your network for >indications of the SYNful Knock malware. Details @ >http://talosintel.com/scanner/ . More details here: http://blogs.cisco.com/security/talos/synful-scanner -Hank >-- >Regards, > >Jake Mertel >Ubiquity Hosting > > > >*Web: *https://www.ubiquityhosting.com >*Phone (direct): *1-480-478-1510 >*Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 > > >On Wed, Sep 16, 2015 at 7:33 AM, Stephen Fulton >wrote: > > > Follow-up to my own post, Fireeye has code on github: > > > > https://github.com/fireeye/synfulknock > > > > > > On 2015-09-16 10:27 AM, Stephen Fulton wrote: > > > >> Interesting, anyone have more details on how to construct the scan using > >> something like nmap? > >> > >> -- Stephen > >> > >> On 2015-09-16 9:20 AM, Royce Williams wrote: > >> > >>> HD Moore just posted the results of a full-Internet ZMap scan. I didn't > >>> realize that it was remotely detectable. > >>> > >>> 79 hosts total in 19 countries. > >>> > >>> https://zmap.io/synful/ > >>> > >>> Royce > >>> > >>> From benno at NLnetLabs.nl Sat Sep 26 20:21:43 2015 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Sat, 26 Sep 2015 22:21:43 +0200 Subject: Last Call for presentations and Draft programme for RIPE 71 Message-ID: <5606FE57.9000605@NLnetLabs.nl> Colleagues, A list of currently accepted RIPE 71 presentations is now published at: https://ripe71.ripe.net/programme/ There are still few slots remaining for a final RIPE 71 programme and RIPE Programme Committee will accept new proposals until 11 October 2015. This is our last call for you to submit your proposals. You can find the CFP for RIPE 71 below, or at https://ripe71.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://www.ripe.net/participate/meetings/ripe-meetings/pc ---------------------------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 71 will take place from 16-20 November 2015 in Bucharest, Romania. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 71. See the full descriptions of the different presentation formats, https://ripe71.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 11 October 2015. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe71.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe71.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice---in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From sethm at rollernet.us Sat Sep 26 22:56:21 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 26 Sep 2015 15:56:21 -0700 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <56042BE2.7080208@l-w.ca> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56042BE2.7080208@l-w.ca> Message-ID: <56072295.8080705@rollernet.us> On 9/24/15 09:59, William Astle wrote: > On 2015-09-24 10:49, Dovid Bender wrote: >> The issue now is convincing clients that they need it. The other issue >> is many software vendors still don't support it. >> >> Regards, >> >> Dovid > > Actually, the issue now is convincing certain big providers to actually > make IPv6 service available to their customers in data centres and the > like across their *whole* networks rather than giving people the > "there's no demand so we can't justify the cost" run around. (I'm > looking at you AS701.) > > For that matter, it would also help if certain large end user providers > would make IPv6 available rather than giving a standard "we have no > information at this time" type response. (I'm looking at you, Shaw.) > What's worked for me is not signing or renewing or buying things that lack IPv6 support. I realize that may not always be possible but it does work better to require it from the sales side than as a technical problem to try and solve later. ~Seth From brandon at rd.bbc.co.uk Sat Sep 26 23:35:05 2015 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 27 Sep 2015 00:35:05 +0100 (BST) Subject: Question re session hijacking in dual stack environments w/MacOS Message-ID: <201509262335.AAA12179@sunf10.rd.bbc.co.uk> > From: David Hubbard > Websites that require some type of authentication that is handled via > session cookies have been booting our users out randomly with "your ip > address has changed" type message. This occurs when their Mac decides > to switch between protocols because the site views it as a session > hijacking attempt when Joe User with session ID xyz switches from > 192.0.2.10 to 2001:db8::1:1:a or vice versa. > > Has anyone run into this? It's 1997 again? This used to be a common IPv4 problem for us as users exited through a cluster of squid caches which could result in a different address per request. Those site eventually learnt after much feedback not to assume on IPv4 address continuity. brandon From michael at supermathie.net Sun Sep 27 03:19:12 2015 From: michael at supermathie.net (Michael Brown) Date: Sat, 26 Sep 2015 23:19:12 -0400 Subject: Question re session hijacking in dual stack environments w/MacOS In-Reply-To: <201509262335.AAA12179@sunf10.rd.bbc.co.uk> References: <201509262335.AAA12179@sunf10.rd.bbc.co.uk> Message-ID: <20150927031912.7143500.23468.12351@supermathie.net> ?> Those site eventually learnt after much feedback not to assume on IPv4 address continuity. I could envision that those checks might now be relaxed? to checking for address continuity in the same /24 for instance. But when you're seeing the same session being used from two wildly different places (in this case, IPv4 and IPv6) at the SAME TIME, that does seem rather suspicious in the absence of other information. M. From dovid at telecurve.com Sun Sep 27 03:33:16 2015 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 27 Sep 2015 03:33:16 +0000 Subject: Recent trouble with QUIC? Message-ID: <646674117-1443324796-cardhu_decombobulator_blackberry.rim.net-28562080-@b13.c3.bise6.blackberry> I forgot who it was but I think it was a uni network. As an isp everything should be allowed as an end network you want to cya. Much like the hospital I was just at that had free wifi. Only ports 80 and 443 over tcp were allowed. That's when having ssh on 443 so you can proxy for alt ports really helps. ------Original Message------ From: James Bensley Sender: NANOG To: NANOG Operators' Group Subject: Re: Recent trouble with QUIC? Sent: Sep 26, 2015 10:54 On 26 September 2015 at 08:20, Mike Hale wrote: > OH SNAP! Tiny Rick!!! Regards, Dovid From dovid at telecurve.com Sun Sep 27 03:34:54 2015 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 27 Sep 2015 03:34:54 +0000 Subject: Question re session hijacking in dual stack environments w/MacOS Message-ID: <1380151854-1443324895-cardhu_decombobulator_blackberry.rim.net-243925607-@b13.c3.bise6.blackberry> What about users on cgnat? I know isp's in the far east that only offer cgnat and it's pot lock how you go out. ------Original Message------ From: Michael Brown Sender: NANOG To: Brandon Butterworth To: nanog at nanog.org To: dhubbard at dino.hostasaurus.com Subject: Re: Question re session hijacking in dual stack environments w/MacOS Sent: Sep 26, 2015 23:19 ?> Those site eventually learnt after much feedback not to assume on IPv4 address continuity. I could envision that those checks might now be relaxed? to checking for address continuity in the same /24 for instance. But when you're seeing the same session being used from two wildly different places (in this case, IPv4 and IPv6) at the SAME TIME, that does seem rather suspicious in the absence of other information. M. Regards, Dovid From dovid at telecurve.com Sun Sep 27 03:35:28 2015 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 27 Sep 2015 03:35:28 +0000 Subject: Ear protection Message-ID: <580600547-1443324928-cardhu_decombobulator_blackberry.rim.net-124190432-@b13.c3.bise6.blackberry> No but some one in Australia just bought the iPhone 6s via a robot. ------Original Message------ From: Alan Buxey Sender: NANOG To: Nick Hilliard To: nanog at nanog.org Subject: Re: Ear protection Sent: Sep 26, 2015 04:21 Great summary of the thread No-one using remote control robots with video feed etc for working in these environments then? Plans to? ;) alan Regards, Dovid From A.L.M.Buxey at lboro.ac.uk Sun Sep 27 13:36:41 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Sun, 27 Sep 2015 14:36:41 +0100 Subject: Recent trouble with QUIC? In-Reply-To: <646674117-1443324796-cardhu_decombobulator_blackberry.rim.net-28562080-@b13.c3.bise6.blackberry> References: <646674117-1443324796-cardhu_decombobulator_blackberry.rim.net-28562080-@b13.c3.bise6.blackberry> Message-ID: Yes. Next gen firewalls stop that kind of game ;) alan From Valdis.Kletnieks at vt.edu Sun Sep 27 15:07:42 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 27 Sep 2015 11:07:42 -0400 Subject: Question re session hijacking in dual stack environments w/MacOS In-Reply-To: <1380151854-1443324895-cardhu_decombobulator_blackberry.rim.net-243925607-@b13.c3.bise6.blackberry> References: <1380151854-1443324895-cardhu_decombobulator_blackberry.rim.net-243925607-@b13.c3.bise6.blackberry> Message-ID: <148712.1443366462@turing-police.cc.vt.edu> On Sun, 27 Sep 2015 03:34:54 -0000, "Dovid Bender" said: > But when you're seeing the same session being used from two wildly different > places (in this case, IPv4 and IPv6) at the SAME TIME, that does seem rather > suspicious in the absence of other information. Other information,: Happy Eyeballs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From connorwilkins at ruggedinbox.com Sun Sep 27 15:25:25 2015 From: connorwilkins at ruggedinbox.com (Connor Wilkins) Date: Sun, 27 Sep 2015 15:25:25 +0000 Subject: Question re session hijacking in dual stack environments w/MacOS In-Reply-To: <1380151854-1443324895-cardhu_decombobulator_blackberry.rim.net-243925607-@b13.c3.bise6.blackberry> References: <1380151854-1443324895-cardhu_decombobulator_blackberry.rim.net-243925607-@b13.c3.bise6.blackberry> Message-ID: <40e59ec9c7a7084adcfff00d46d68f7e@ruggedinbox.com> On 2015-09-27 03:34, Dovid Bender wrote: > But when you're seeing the same session being used from two wildly > different places (in this case, IPv4 and IPv6) at the SAME TIME, that > does seem rather suspicious in the absence of other information. iOS 9 has a new feature called "Wi-Fi Assist" that will "automatically use cellular data when Wi-Fi connectivity is poor". This will most likely cause those pesky IP checks to fail (even if you use a /24 or AS check). Geolocation checks will also fail in some cases. My geolocation when connected to WiFi and when using cellular data are widely different. WiFi reports the city I'm in while cellular reports the city that their HQ is in. -- ?Simply stated, we have a new formula for Coke.? --- Roberto C. Goizueta, Company Chairman, Coca-Cola From connorwilkins at ruggedinbox.com Sun Sep 27 15:37:49 2015 From: connorwilkins at ruggedinbox.com (Connor Wilkins) Date: Sun, 27 Sep 2015 15:37:49 +0000 Subject: ARIN Region IPv4 Free Pool Reaches Zero In-Reply-To: <740b951ca6302f5b1cffe9c55d2188e3@ruggedinbox.com> References: <56041F06.5090906@arin.net> <79BB8901-5585-42A7-AAAE-6F92E7669EA7@corp.arin.net> <1785820069-1443113395-cardhu_decombobulator_blackberry.rim.net-21362253-@b13.c3.bise6.blackberry> <56042BE2.7080208@l-w.ca> <56072295.8080705@rollernet.us> <740b951ca6302f5b1cffe9c55d2188e3@ruggedinbox.com> Message-ID: <1d150746e842044062c89449a05380e9@ruggedinbox.com> On 2015-09-26 22:56, Seth Mattinen wrote: > What's worked for me is not signing or renewing or buying things that > lack IPv6 support. While you're demanding better technology you may also want to include things like crypto in there. I've gotten proposals for things that support IPv6 but only work with SSLv2/SSLv3 with a weak cipher and with MD5 or SHA1 only. I've even had ones that didn't implement certificate verification at all or say they did but then it turned out not to work at all. Disgusting and unacceptable. (But they did support IPv6!) -- ?Simply stated, we have a new formula for Coke.? --- Roberto C. Goizueta, Company Chairman, Coca-Cola From morrowc.lists at gmail.com Sun Sep 27 15:55:51 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 27 Sep 2015 11:55:51 -0400 Subject: Question re session hijacking in dual stack environments w/MacOS In-Reply-To: <40e59ec9c7a7084adcfff00d46d68f7e@ruggedinbox.com> References: <1380151854-1443324895-cardhu_decombobulator_blackberry.rim.net-243925607-@b13.c3.bise6.blackberry> <40e59ec9c7a7084adcfff00d46d68f7e@ruggedinbox.com> Message-ID: On Sun, Sep 27, 2015 at 11:25 AM, Connor Wilkins wrote: > My geolocation when connected to WiFi and when using cellular data are > widely different. WiFi reports the city I'm in while cellular reports the > city that their HQ is in. that really depends on the carrier though, I suspect... geo-ip stuff is so fun! and so often so wrong :( From saku at ytti.fi Sun Sep 27 21:16:22 2015 From: saku at ytti.fi (Saku Ytti) Date: Sun, 27 Sep 2015 14:16:22 -0700 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: On 25 September 2015 at 16:20, Ca By wrote: Hey, > I remained very disappointed in how google has gone about quic. > > They are dismissive of network operators concerns (quic protocol list and > ietf), cause substantial outages, and have lost a lot of good will in the > process > > Here's your post mortem: > > RFO: Google unilaterally deployed a non-standard protocol to our production > environment, driving up helpdesk calls x% > > After action: block udp 80/443 until production ready and standard ratified > use deployed. I find this attitude sad. Internet is about freedom. Google is using standard IP and standard UDP over Internet, we, the network engineers shouldn't care about application layer. Lot of companies run their own protocols on top of TCP and UDP and there is absolutely nothing wrong with that. Saying this shouldn't happen and if it does, those packets should be dropped is same as saying innovation shouldn't happen. Getting new IETF standard L4 protocol will take lot of time, and will be much easier if we first have experience on using it, rather than build standard and then hope it works without having actual data about it. QUIC, MinimaLT and other options for new PKI based L4 protocol are very welcome. They offer compelling benefits - mobility, IP address is not your identity (say hello to 'mosh' like behaviour for all applications) - encryption for all applications - helps with buffer bloat (BW estimation and packet pacing) - helps with performance/congestion (packet loss estimation and FEC for redundant data, so dropped packet can be reconstructed be receiver) - fixes amplification (response is smaller than request) - helps with DoS (proof of work) (QUIC does not have this) - low latency session establishment (Especially compared to TLS/HTTP) I'm sure I've omitted many others. -- ++ytti From lyle at lcrcomputer.net Mon Sep 28 01:38:04 2015 From: lyle at lcrcomputer.net (Lyle Giese) Date: Sun, 27 Sep 2015 20:38:04 -0500 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: <560899FC.6010405@lcrcomputer.net> On 09/27/15 16:16, Saku Ytti wrote: > On 25 September 2015 at 16:20, Ca By wrote: > > Hey, > >> I remained very disappointed in how google has gone about quic. >> >> They are dismissive of network operators concerns (quic protocol list and >> ietf), cause substantial outages, and have lost a lot of good will in the >> process >> >> Here's your post mortem: >> >> RFO: Google unilaterally deployed a non-standard protocol to our production >> environment, driving up helpdesk calls x% >> >> After action: block udp 80/443 until production ready and standard ratified >> use deployed. > > I find this attitude sad. Internet is about freedom. Google is using > standard IP and standard UDP over Internet, we, the network engineers > shouldn't care about application layer. Lot of companies run their own > protocols on top of TCP and UDP and there is absolutely nothing wrong > with that. Saying this shouldn't happen and if it does, those packets > should be dropped is same as saying innovation shouldn't happen. > Getting new IETF standard L4 protocol will take lot of time, and will > be much easier if we first have experience on using it, rather than > build standard and then hope it works without having actual data about > it. > > QUIC, MinimaLT and other options for new PKI based L4 protocol are > very welcome. They offer compelling benefits > - mobility, IP address is not your identity (say hello to 'mosh' like > behaviour for all applications) > - encryption for all applications > - helps with buffer bloat (BW estimation and packet pacing) > - helps with performance/congestion (packet loss estimation and FEC > for redundant data, so dropped packet can be reconstructed be > receiver) > - fixes amplification (response is smaller than request) > - helps with DoS (proof of work) (QUIC does not have this) > - low latency session establishment (Especially compared to TLS/HTTP) > > I'm sure I've omitted many others. > > There are advantages to QUIC or Google would not be trying to work on it and implement it. The problem is that it has been added to a popular application(Chrome) which many/most end users know little to nothing about QUIC and what the implications are when a version in Chrome is defective and harmful to the Internet. Part of freedom is to minimize the harm and I think that is where the parties replying to this thread diverge. A broken change that causes harm should have/could have been tested better before releasing it to the public on the Internet. Or if a bad release is let loose on the Internet, how does Google minimize the harm? Lyle Giese LCR Computer Services, Inc. From shortdudey123 at gmail.com Mon Sep 28 02:50:45 2015 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sun, 27 Sep 2015 19:50:45 -0700 Subject: CHP website returning 503 Message-ID: Hey, If anyone from CHP (california highway patrol) is listening, your website is returning a 503. curl -v https://www.chp.ca.gov * Rebuilt URL to: https://www.chp.ca.gov/ * Hostname was NOT found in DNS cache * Trying 168.145.114.48... * Connected to www.chp.ca.gov (168.145.114.48) port 443 (#0) * TLS 1.2 connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA * Server certificate: *.chp.ca.gov * Server certificate: Entrust Certification Authority - L1K * Server certificate: Entrust Root Certification Authority - G2 > GET / HTTP/1.1 > User-Agent: curl/7.37.1 > Host: www.chp.ca.gov > Accept: */* > < HTTP/1.1 503 Service Unavailable < Content-Type: text/html; charset=us-ascii < Date: Mon, 28 Sep 2015 02:48:23 GMT < X-Cnection: close < Content-Length: 326 < Service Unavailable

Service Unavailable

HTTP Error 503. The service is unavailable.

* Connection #0 to host www.chp.ca.gov left intact -Grant From matthew at matthew.at Mon Sep 28 03:15:17 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 27 Sep 2015 20:15:17 -0700 Subject: Recent trouble with QUIC? In-Reply-To: <560899FC.6010405@lcrcomputer.net> References: <560899FC.6010405@lcrcomputer.net> Message-ID: <57E4CF65-75BB-45A0-B322-A6F17B0B56B5@matthew.at> Maybe Google should return the money you paid for access to their search engine and associated free applications during the time it was down. Matthew Kaufman (Sent from my iPhone) > On Sep 27, 2015, at 6:38 PM, Lyle Giese wrote: > > > >> On 09/27/15 16:16, Saku Ytti wrote: >> On 25 September 2015 at 16:20, Ca By wrote: >> >> Hey, >> >>> I remained very disappointed in how google has gone about quic. >>> >>> They are dismissive of network operators concerns (quic protocol list and >>> ietf), cause substantial outages, and have lost a lot of good will in the >>> process >>> >>> Here's your post mortem: >>> >>> RFO: Google unilaterally deployed a non-standard protocol to our production >>> environment, driving up helpdesk calls x% >>> >>> After action: block udp 80/443 until production ready and standard ratified >>> use deployed. >> >> I find this attitude sad. Internet is about freedom. Google is using >> standard IP and standard UDP over Internet, we, the network engineers >> shouldn't care about application layer. Lot of companies run their own >> protocols on top of TCP and UDP and there is absolutely nothing wrong >> with that. Saying this shouldn't happen and if it does, those packets >> should be dropped is same as saying innovation shouldn't happen. >> Getting new IETF standard L4 protocol will take lot of time, and will >> be much easier if we first have experience on using it, rather than >> build standard and then hope it works without having actual data about >> it. >> >> QUIC, MinimaLT and other options for new PKI based L4 protocol are >> very welcome. They offer compelling benefits >> - mobility, IP address is not your identity (say hello to 'mosh' like >> behaviour for all applications) >> - encryption for all applications >> - helps with buffer bloat (BW estimation and packet pacing) >> - helps with performance/congestion (packet loss estimation and FEC >> for redundant data, so dropped packet can be reconstructed be >> receiver) >> - fixes amplification (response is smaller than request) >> - helps with DoS (proof of work) (QUIC does not have this) >> - low latency session establishment (Especially compared to TLS/HTTP) >> >> I'm sure I've omitted many others. > > There are advantages to QUIC or Google would not be trying to work on it and implement it. > > The problem is that it has been added to a popular application(Chrome) which many/most end users know little to nothing about QUIC and what the implications are when a version in Chrome is defective and harmful to the Internet. > > Part of freedom is to minimize the harm and I think that is where the parties replying to this thread diverge. A broken change that causes harm should have/could have been tested better before releasing it to the public on the Internet. > > Or if a bad release is let loose on the Internet, how does Google minimize the harm? > > Lyle Giese > LCR Computer Services, Inc. From saku at ytti.fi Mon Sep 28 03:20:06 2015 From: saku at ytti.fi (Saku Ytti) Date: Sun, 27 Sep 2015 20:20:06 -0700 Subject: Recent trouble with QUIC? In-Reply-To: <560899FC.6010405@lcrcomputer.net> References: <560899FC.6010405@lcrcomputer.net> Message-ID: On 27 September 2015 at 18:38, Lyle Giese wrote: > Part of freedom is to minimize the harm and I think that is where the > parties replying to this thread diverge. A broken change that causes harm > should have/could have been tested better before releasing it to the public > on the Internet. > > Or if a bad release is let loose on the Internet, how does Google minimize > the harm? How would this be any different by google introducing TCP related issue in their frontend servers? This is not a protocol issue, this is QA issue that could impact arbitrary technology. I'd like to say I've not broken stuff by misunderstanding impact of my changes, but unfortunately I can't. -- ++ytti From joe at nethead.com Mon Sep 28 04:21:41 2015 From: joe at nethead.com (Joe Hamelin) Date: Sun, 27 Sep 2015 21:21:41 -0700 Subject: CHP website returning 503 In-Reply-To: References: Message-ID: It is late Sunday night. When would you do maintenance? -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Sun, Sep 27, 2015 at 7:50 PM, Grant Ridder wrote: > Hey, > > If anyone from CHP (california highway patrol) is listening, your website > is returning a 503. > > curl -v https://www.chp.ca.gov > * Rebuilt URL to: https://www.chp.ca.gov/ > * Hostname was NOT found in DNS cache > * Trying 168.145.114.48... > * Connected to www.chp.ca.gov (168.145.114.48) port 443 (#0) > * TLS 1.2 connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA > * Server certificate: *.chp.ca.gov > * Server certificate: Entrust Certification Authority - L1K > * Server certificate: Entrust Root Certification Authority - G2 > > GET / HTTP/1.1 > > User-Agent: curl/7.37.1 > > Host: www.chp.ca.gov > > Accept: */* > > > < HTTP/1.1 503 Service Unavailable > < Content-Type: text/html; charset=us-ascii > < Date: Mon, 28 Sep 2015 02:48:23 GMT > < X-Cnection: close > < Content-Length: 326 > < > http://www.w3.org/TR/html4/strict.dtd"> > Service Unavailable > >

Service Unavailable

>

HTTP Error 503. The service is unavailable.

> > * Connection #0 to host www.chp.ca.gov left intact > > -Grant > From josh at imaginenetworksllc.com Mon Sep 28 04:27:49 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 28 Sep 2015 00:27:49 -0400 Subject: CHP website returning 503 In-Reply-To: References: Message-ID: Wouldn't you expect a maintenance window to say so? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sep 28, 2015 12:23 AM, "Joe Hamelin" wrote: > It is late Sunday night. When would you do maintenance? > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > On Sun, Sep 27, 2015 at 7:50 PM, Grant Ridder > wrote: > > > Hey, > > > > If anyone from CHP (california highway patrol) is listening, your website > > is returning a 503. > > > > curl -v https://www.chp.ca.gov > > * Rebuilt URL to: https://www.chp.ca.gov/ > > * Hostname was NOT found in DNS cache > > * Trying 168.145.114.48... > > * Connected to www.chp.ca.gov (168.145.114.48) port 443 (#0) > > * TLS 1.2 connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA > > * Server certificate: *.chp.ca.gov > > * Server certificate: Entrust Certification Authority - L1K > > * Server certificate: Entrust Root Certification Authority - G2 > > > GET / HTTP/1.1 > > > User-Agent: curl/7.37.1 > > > Host: www.chp.ca.gov > > > Accept: */* > > > > > < HTTP/1.1 503 Service Unavailable > > < Content-Type: text/html; charset=us-ascii > > < Date: Mon, 28 Sep 2015 02:48:23 GMT > > < X-Cnection: close > > < Content-Length: 326 > > < > > > http://www.w3.org/TR/html4/strict.dtd"> > > Service Unavailable > > > >

Service Unavailable

> >

HTTP Error 503. The service is unavailable.

> > > > * Connection #0 to host www.chp.ca.gov left intact > > > > -Grant > > > From nanogml at Mail.DDoS-Mitigator.net Mon Sep 28 04:42:51 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Sun, 27 Sep 2015 21:42:51 -0700 Subject: CHP website returning 503 In-Reply-To: References: Message-ID: <20150928044251.GA19023@Mail.DDoS-Mitigator.net> On 09/27/15 at 09:21pm, Joe Hamelin wrote: > It is late Sunday night. When would you do maintenance? even if one was doing maintenance, there is no reason not to have at least 1 el-cheapo server replying that it's under maintenance vs being suspect of other reasons of it being down there's gotta be more than 1 server for chp.ca.gov - do maintenance on the other servers and test before going live - remove the "maintenance window notification server" magic pixie dust alvin > On Sun, Sep 27, 2015 at 7:50 PM, Grant Ridder > wrote: > > > Hey, > > > > If anyone from CHP (california highway patrol) is listening, your website > > is returning a 503. From mel at beckman.org Mon Sep 28 04:40:48 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 28 Sep 2015 04:40:48 +0000 Subject: CHP website returning 503 In-Reply-To: References: , Message-ID: <5C6C7D95-A09E-4CC7-92D9-26F29D0608D1@beckman.org> On a government website? Ha! -mel beckman > On Sep 27, 2015, at 9:28 PM, Josh Luthman wrote: > > Wouldn't you expect a maintenance window to say so? > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 >> On Sep 28, 2015 12:23 AM, "Joe Hamelin" wrote: >> >> It is late Sunday night. When would you do maintenance? >> >> -- >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >> >> On Sun, Sep 27, 2015 at 7:50 PM, Grant Ridder >> wrote: >> >>> Hey, >>> >>> If anyone from CHP (california highway patrol) is listening, your website >>> is returning a 503. >>> >>> curl -v https://www.chp.ca.gov >>> * Rebuilt URL to: https://www.chp.ca.gov/ >>> * Hostname was NOT found in DNS cache >>> * Trying 168.145.114.48... >>> * Connected to www.chp.ca.gov (168.145.114.48) port 443 (#0) >>> * TLS 1.2 connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA >>> * Server certificate: *.chp.ca.gov >>> * Server certificate: Entrust Certification Authority - L1K >>> * Server certificate: Entrust Root Certification Authority - G2 >>>> GET / HTTP/1.1 >>>> User-Agent: curl/7.37.1 >>>> Host: www.chp.ca.gov >>>> Accept: */* >>> < HTTP/1.1 503 Service Unavailable >>> < Content-Type: text/html; charset=us-ascii >>> < Date: Mon, 28 Sep 2015 02:48:23 GMT >>> < X-Cnection: close >>> < Content-Length: 326 >>> < >>> >> http://www.w3.org/TR/html4/strict.dtd"> >>> Service Unavailable >>> >>>

Service Unavailable

>>>

HTTP Error 503. The service is unavailable.

>>> >>> * Connection #0 to host www.chp.ca.gov left intact >>> >>> -Grant >> From mel at beckman.org Mon Sep 28 04:42:38 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 28 Sep 2015 04:42:38 +0000 Subject: CHP website returning 503 In-Reply-To: <20150928044251.GA19023@Mail.DDoS-Mitigator.net> References: , <20150928044251.GA19023@Mail.DDoS-Mitigator.net> Message-ID: I work with a lot of government agencies. All run through their IT funding long before niceties such a maintenance notifications get built. That's at the end of a never-ending task list. -mel beckman > On Sep 27, 2015, at 9:40 PM, alvin nanog wrote: > > >> On 09/27/15 at 09:21pm, Joe Hamelin wrote: >> It is late Sunday night. When would you do maintenance? > > even if one was doing maintenance, there is no reason not > to have at least 1 el-cheapo server replying that it's > under maintenance vs being suspect of other reasons of it > being down > > there's gotta be more than 1 server for chp.ca.gov > > - do maintenance on the other servers and test before going live > - remove the "maintenance window notification server" > > magic pixie dust > alvin > >> On Sun, Sep 27, 2015 at 7:50 PM, Grant Ridder >> wrote: >> >>> Hey, >>> >>> If anyone from CHP (california highway patrol) is listening, your website >>> is returning a 503. > From Valdis.Kletnieks at vt.edu Mon Sep 28 04:42:34 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 28 Sep 2015 00:42:34 -0400 Subject: CHP website returning 503 In-Reply-To: References: Message-ID: <204566.1443415354@turing-police.cc.vt.edu> On Sun, 27 Sep 2015 21:21:41 -0700, Joe Hamelin said: > It is late Sunday night. When would you do maintenance? If it isn't important enough to get a loadbalancer (or other HA solution) and a second server so you can do maintenance without anybody noticing, you *deserve* to have it noticed when the disk drive fails on the non-HA server. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From joe at nethead.com Mon Sep 28 04:46:48 2015 From: joe at nethead.com (Joe Hamelin) Date: Sun, 27 Sep 2015 21:46:48 -0700 Subject: CHP website returning 503 In-Reply-To: <204566.1443415354@turing-police.cc.vt.edu> References: <204566.1443415354@turing-police.cc.vt.edu> Message-ID: It might have been the "el-cheapo" server that crashed. If that's what happened, are you going to eat your maintenance window to fix it? -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From morrowc.lists at gmail.com Mon Sep 28 05:24:26 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 28 Sep 2015 01:24:26 -0400 Subject: CHP website returning 503 In-Reply-To: <204566.1443415354@turing-police.cc.vt.edu> References: <204566.1443415354@turing-police.cc.vt.edu> Message-ID: On Mon, Sep 28, 2015 at 12:42 AM, wrote: > On Sun, 27 Sep 2015 21:21:41 -0700, Joe Hamelin said: >> It is late Sunday night. When would you do maintenance? > > If it isn't important enough to get a loadbalancer (or other HA solution) > and a second server so you can do maintenance without anybody noticing, > you *deserve* to have it noticed when the disk drive fails on the non-HA > server. Are telling me Eric Estrada won't have a loadbalancer deployed for this super critical resource? From larrysheldon at cox.net Mon Sep 28 05:56:40 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 28 Sep 2015 00:56:40 -0500 Subject: CHP website returning 503 In-Reply-To: References: <204566.1443415354@turing-police.cc.vt.edu> Message-ID: <5608D698.2030307@cox.net> On 9/28/2015 00:24, Christopher Morrow wrote: > On Mon, Sep 28, 2015 at 12:42 AM, wrote: >> On Sun, 27 Sep 2015 21:21:41 -0700, Joe Hamelin said: >>> It is late Sunday night. When would you do maintenance? >> >> If it isn't important enough to get a loadbalancer (or other HA solution) >> and a second server so you can do maintenance without anybody noticing, >> you *deserve* to have it noticed when the disk drive fails on the non-HA >> server. > > Are telling me Eric Estrada won't have a loadbalancer deployed for > this super critical resource? > I find the cavalier, screw-en attitude instructive. Does anybody know (I didn't ask "care", I can see that) what the function of the site is? What citizen or patrolman services have been lost? -- sed quis custodiet ipsos custodes? (Juvenal) From mel at beckman.org Mon Sep 28 06:09:50 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 28 Sep 2015 06:09:50 +0000 Subject: CHP website returning 503 In-Reply-To: <5608D698.2030307@cox.net> References: <204566.1443415354@turing-police.cc.vt.edu> , <5608D698.2030307@cox.net> Message-ID: <9E9C6354-47FF-4264-9CD9-F42FE7215BC0@beckman.org> Information about road conditions and accidents is one key public safety function of the site. -mel Carpe Lunch (Mel) > On Sep 27, 2015, at 10:57 PM, Larry Sheldon wrote: > >> On 9/28/2015 00:24, Christopher Morrow wrote: >>> On Mon, Sep 28, 2015 at 12:42 AM, wrote: >>> On Sun, 27 Sep 2015 21:21:41 -0700, Joe Hamelin said: >>>> It is late Sunday night. When would you do maintenance? >>> >>> If it isn't important enough to get a loadbalancer (or other HA solution) >>> and a second server so you can do maintenance without anybody noticing, >>> you *deserve* to have it noticed when the disk drive fails on the non-HA >>> server. >> >> Are telling me Eric Estrada won't have a loadbalancer deployed for >> this super critical resource? > > I find the cavalier, screw-en attitude instructive. > > Does anybody know (I didn't ask "care", I can see that) what the function of the site is? What citizen or patrolman services have been lost? > > -- > sed quis custodiet ipsos custodes? (Juvenal) From nanogml at Mail.DDoS-Mitigator.net Mon Sep 28 07:24:19 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Mon, 28 Sep 2015 00:24:19 -0700 Subject: CHP website returning 503 In-Reply-To: <5608D698.2030307@cox.net> References: <204566.1443415354@turing-police.cc.vt.edu> <5608D698.2030307@cox.net> Message-ID: <20150928072419.GA19974@Mail.DDoS-Mitigator.net> On 09/28/15 at 12:56am, Larry Sheldon wrote: > On 9/28/2015 00:24, Christopher Morrow wrote: > >On Mon, Sep 28, 2015 at 12:42 AM, wrote: ... > >Are telling me Eric Estrada won't have a loadbalancer deployed for > >this super critical resource? both eric and his buddy was distracted by the blondes on the sunny beaches > I find the cavalier, screw-en attitude instructive. i've had the worst luck with "cavalier(?) disks" from western digital > Does anybody know (I didn't ask "care", I can see that) what the function of > the site is? What citizen or patrolman services have been lost? traffic report is "511" on the cell phone ... usually up to date within the past hour i think nothing "important" ( need something now ) is lost during their website outage ? i wonder if they use their laptops in the car to submit/file reports via their websites or just wait till they get into the office. some cops are still using pencil and paper to write down reports gov't are notoriously wasteful for their budget to get the simplest tasks done. 10+ managers and supervisors and past retired employees in the past 60yrs on pension need their salary/pension while 1 new college grad actually gets the tasks done --- in dealing with cops ... they've usually used their personal cell phones to make phone calls/inquiries regarding the issues at hand ... kinda wierd ... even more cell phone usage during the overhaul of their outdated radios used by police, fire, ambulance, etc etc magic pixie dust alvin From colinj at gt86car.org.uk Mon Sep 28 07:26:31 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 28 Sep 2015 08:26:31 +0100 Subject: Fwd: Byte Night Manchester - Action for Children - donation help needed please :) References: <402e9cc097014acfbd9f7510d78e7994@rew09926dag10a.domain1.systemhost.net> Message-ID: <019959A4-E906-4C61-8AF0-6FEC39937915@gt86car.org.uk> Hopefully IT folks will donate to this great cause, hopefully folks will allow this posting :) > Dear all, > As my regular yearly charity participation event please support below > Byte Night Manchester - BT Manchester folks ? Colin team of one. > > On Friday night next, 2nd Oct 2015 from 7pm to 6am next morning, I (Colin Johnston) am participating in > Action for Children Byte Night Manchester. > As we have been asked to dress up for nice social media pictures I decided that being dressed as a Sylvester Cat > would be good fun. > I have managed to get http://celebrationpartyshoponline.co.uk/stores to give me a discount on the costume hire as well. > The Byte Night for Manchester is being held at Granada Studios in Manchester on the street of Coronation Street. > > We(Byte Night participants) are sleeping on the street in sleeping bags and foil survival bag. > > Please donate to this great cause, either by donation bucket in BT Bolton AMTE (Sylvester will be in Bolton on Thursday/Friday) or > BT Dial House Manchester (Sylvester will make a visit on Friday), > or via internet https://www.justgiving.com/bt-bt-manchester-folks/4w350m3/donate#MessageAndAmount > > Please email me colin.johnstone at bt.com if donation made so I can keep track of donators list. > I want to transfer the total raised to Action for Children by middle of Oct so please give money via above either this week coming or next. > I will email folks with acknowledgement of final donation amount once received, would be great to get 500 pounds ++.. > > Pictures will be sent after the event for BT Today and all on this email to listJ > > Please give generously if you can afford it, pay day on Wednesday J > > Please distribute widely if you think others not mentioned would be willing to donate JJ > > Yours > > Colin Johnston From chaim.rieger at gmail.com Mon Sep 28 08:51:29 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Mon, 28 Sep 2015 10:51:29 +0200 Subject: CHP website returning 503 In-Reply-To: <20150928072419.GA19974@Mail.DDoS-Mitigator.net> References: <204566.1443415354@turing-police.cc.vt.edu> <5608D698.2030307@cox.net> <20150928072419.GA19974@Mail.DDoS-Mitigator.net> Message-ID: http://cad.chp.ca.gov/ Works for me. > On Sep 28, 2015, at 9:24 AM, alvin nanog wrote: > > > On 09/28/15 at 12:56am, Larry Sheldon wrote: >> On 9/28/2015 00:24, Christopher Morrow wrote: >>> On Mon, Sep 28, 2015 at 12:42 AM, wrote: > ... >>> Are telling me Eric Estrada won't have a loadbalancer deployed for >>> this super critical resource? > > both eric and his buddy was distracted by the blondes on the sunny beaches > >> I find the cavalier, screw-en attitude instructive. > > i've had the worst luck with "cavalier(?) disks" from western digital > >> Does anybody know (I didn't ask "care", I can see that) what the function of >> the site is? What citizen or patrolman services have been lost? > > traffic report is "511" on the cell phone ... usually up to date > within the past hour > > i think nothing "important" ( need something now ) is lost during > their website outage ? > > i wonder if they use their laptops in the car to submit/file reports > via their websites or just wait till they get into the office. > some cops are still using pencil and paper to write down reports > > gov't are notoriously wasteful for their budget to get the > simplest tasks done. 10+ managers and supervisors and past > retired employees in the past 60yrs on pension need their > salary/pension while 1 new college grad actually gets the tasks done > > --- > > in dealing with cops ... they've usually used their personal cell phones > to make phone calls/inquiries regarding the issues at hand ... > kinda wierd ... even more cell phone usage during the overhaul of > their outdated radios used by police, fire, ambulance, etc etc > > magic pixie dust > alvin From me at anuragbhatia.com Mon Sep 28 12:03:46 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 28 Sep 2015 17:33:46 +0530 Subject: IPv6 and Android auto conf Message-ID: Hello everyone I recently got IPv6 working at home LAN. My Android device (Google Nexus 5) is connected via wifi to LAN and LAN's core router is Map2N . I have a /64 on the LAN with "advertise" enabled to make ND to work and have autoconfig working on all devices. There are bunch of other layer 2 devices in LAN but all just acting as layer 2 transparently and core L3 remains on Map2N. All works well for most part but only trouble I am getting is on Nexus 5 where after around 24hrs IPv6 stops working. Only unusual thing I notice at that time is that phone 4 IPv6 as opposed to 2 (autoconf and temporary randomised address). Seems like some kind of issue in way NDP works either on Microtik or phone. The fix I am doing from few days is to restart wifi and phone interface gets fresh (two) IPv6 addresses and all works well again. Anyone facing similar issue? (Note: No issues on OS X or iOS which are in same LAN) I can try DHCPv6 but I guess most of devices do not support it yet. (I see support for that in routerboard though). Thanks. -- Anurag Bhatia anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From hugo at slabnet.com Mon Sep 28 15:20:39 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 28 Sep 2015 08:20:39 -0700 Subject: IPv6 and Android auto conf In-Reply-To: References: Message-ID: <20150928152039.GG1518@bamboo.slabnet.com> On Mon 2015-Sep-28 17:33:46 +0530, Anurag Bhatia wrote: >Hello everyone > > > > >I recently got IPv6 working at home LAN. My Android device (Google Nexus 5) >is connected via wifi to LAN and LAN's core router is Map2N >. I have a /64 on the LAN with "advertise" >enabled to make ND to work and have autoconfig working on all devices. >There are bunch of other layer 2 devices in LAN but all just acting as >layer 2 transparently and core L3 remains on Map2N. > > >All works well for most part but only trouble I am getting is on Nexus 5 >where after around 24hrs IPv6 stops working. How, specifically, does it "stop working" on the Nexus 5? - temp addresses expired and does not generate new, valid, slaac addresses? - RA entry ages out and doesn't get refreshed? - cannot reach v6 gateway (ND fails somehow)? >Only unusual thing I notice at that time is that phone 4 IPv6 as opposed >to 2 (autoconf and temporary randomised address). Seems like some kind of >issue in way NDP works either on Microtik or phone. The fix I am doing >from few days is to restart wifi and phone interface gets fresh (two) IPv6 >addresses and all works well >again. > > > >Anyone facing similar issue? (Note: No issues on OS X or iOS which are in >same LAN) > > >I can try DHCPv6 but I guess most of devices do not support it yet. (I see >support for that in routerboard though). > Unless something's changed, DHCPv6 IA_NA isn't an option for getting an IPv6 address assigned to an Android device[1][2] > > > > >Thanks. > > >-- > > >Anurag Bhatia >anuragbhatia.com > > >PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 -- Hugo hugo at slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E [1] https://code.google.com/p/android/issues/detail?id=32621 [2] http://mailman.nanog.org/pipermail/nanog/2015-June/075915.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From codygrosskopf at gmail.com Mon Sep 28 16:45:54 2015 From: codygrosskopf at gmail.com (Cody Grosskopf) Date: Mon, 28 Sep 2015 09:45:54 -0700 Subject: Recent trouble with QUIC? In-Reply-To: References: Message-ID: I care about the application layer. ps. nice work on oxidized! On Sun, Sep 27, 2015 at 2:16 PM, Saku Ytti wrote: > On 25 September 2015 at 16:20, Ca By wrote: > > Hey, > > > I remained very disappointed in how google has gone about quic. > > > > They are dismissive of network operators concerns (quic protocol list and > > ietf), cause substantial outages, and have lost a lot of good will in the > > process > > > > Here's your post mortem: > > > > RFO: Google unilaterally deployed a non-standard protocol to our > production > > environment, driving up helpdesk calls x% > > > > After action: block udp 80/443 until production ready and standard > ratified > > use deployed. > > I find this attitude sad. Internet is about freedom. Google is using > standard IP and standard UDP over Internet, we, the network engineers > shouldn't care about application layer. Lot of companies run their own > protocols on top of TCP and UDP and there is absolutely nothing wrong > with that. Saying this shouldn't happen and if it does, those packets > should be dropped is same as saying innovation shouldn't happen. > Getting new IETF standard L4 protocol will take lot of time, and will > be much easier if we first have experience on using it, rather than > build standard and then hope it works without having actual data about > it. > > QUIC, MinimaLT and other options for new PKI based L4 protocol are > very welcome. They offer compelling benefits > - mobility, IP address is not your identity (say hello to 'mosh' like > behaviour for all applications) > - encryption for all applications > - helps with buffer bloat (BW estimation and packet pacing) > - helps with performance/congestion (packet loss estimation and FEC > for redundant data, so dropped packet can be reconstructed be > receiver) > - fixes amplification (response is smaller than request) > - helps with DoS (proof of work) (QUIC does not have this) > - low latency session establishment (Especially compared to TLS/HTTP) > > I'm sure I've omitted many others. > > > -- > ++ytti > From jcurran at arin.net Mon Sep 28 16:55:36 2015 From: jcurran at arin.net (John Curran) Date: Mon, 28 Sep 2015 16:55:36 +0000 Subject: Important - Register for NANOG 65 _by 1 October_ to Vote in the NRO NC Election Message-ID: <8BBBC661-80BD-4C0B-B12C-83FAD66C37D9@corp.arin.net> NANOGers - Meeting attendees who register for NANOG 65 by 1 October will be eligible to vote online in the Number Resource Organization Number Council (NRO NC) election for the ARIN region. If you are also an ARIN eligible voting contact, please note that you will vote in this same election beginning 8 October when voting opens for the ARIN Board and ARIN Advisory Council elections. The 2015 candidates for the one open seat are: - Louie Lee, Equinix - Timothy McGinnis, Unaffiliated You can view candidate questionnaires and see/make statements of support at: https://www.bigpulse.com/p35820/ You can learn more about the role of the NRO NC at: https://www.arin.net/about_us/nronc.html Note that all eligible NANOG 65 registered attendees will receive an email at 10:00 AM ET on Monday 5 October with instructions on how to cast your ballot. The election closes at 3:00 PM EDT Friday 16 October and results will be announced the following week. Please visit the ARIN Elections Helpdesk onsite in Montreal if you have issues voting or contact us via email at: info at arin.net. Thank you for participating! /John John Curran President and CEO American Registry for Internet Numbers (ARIN) From johns at a10networks.com Sun Sep 27 12:24:17 2015 From: johns at a10networks.com (John Schimmel) Date: Sun, 27 Sep 2015 12:24:17 +0000 Subject: Question re session hijacking in dual stack environments w/MacOS Message-ID: I can?t speak to every case, but I ran into a similar issue with our WAF product, so I can explain what was happening there. Most Web application firewalls have cross-site request forgery protection. When a form is downloaded, the firewall inserts a hidden field or cookie that contains the IP address of the request. When the form is submitted, the firewall then verifies that the post is sent from the same address. If the client does a get via IPv6, and the form contains a form action for a URL that is better reached via IPv4 then the firewall sees the post coming from a different IP address and refuses the request. This is nothing specifically to do with MacOS, it is true of any multi-homed system. The options are either to rewrite the client to guarantee that the address in a post always matches the corresponding get; to maintain different URLs on the server such that requests from IPv6 clients always return action URLs that will go to an IPv6 hostname, and vice-versa for IPv4; or to disable CSRF protection. Later, John > From: David Hubbard > > Hey all, as we've slowly deployed IPv6 to our end users, it has begun to > cause some issues for those on Mac's specifically. Apple apparently has > an algorithm at some point in the network stack to decide whether IPv4 > or IPv6 is, perhaps, 'better' or 'faster' at any given point in time > during an ongoing session. This allows a computer talking to a dual > stack remote website to flip flop between v4 and v6 as activity is > conducted. > > Websites that require some type of authentication that is handled via > session cookies have been booting our users out randomly with "your ip > address has changed" type message. This occurs when their Mac decides > to switch between protocols because the site views it as a session > hijacking attempt when Joe User with session ID xyz switches from > 192.0.2.10 to 2001:db8::1:1:a or vice versa. > > Has anyone run into this? Our users on other platforms don't seem to > have this issue; linux and MS desktops seem to just use v6 if it's > available and v4 if not. > > Thanks, > > David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4560 bytes Desc: not available URL: From marco at paesani.it Mon Sep 28 20:35:16 2015 From: marco at paesani.it (Marco Paesani) Date: Mon, 28 Sep 2015 22:35:16 +0200 Subject: Facebook invisible in Italy Message-ID: Hi, some issues from FB network ?? Do you have some info ? Regards, -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From jj at anexia.at Mon Sep 28 20:38:38 2015 From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Mon, 28 Sep 2015 20:38:38 +0000 Subject: AW: Facebook invisible in Italy In-Reply-To: References: Message-ID: <55472c482b734fbd80281092fdb8a08c@anx-i-dag02.anx.local> Hi, also down for us (Austria & Germany) and the OVH network. Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: JJaritsch at anexia-it.com Web: http://www.anexia-it.com Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Marco Paesani Gesendet: Montag, 28. September 2015 22:35 An: nanog Betreff: Facebook invisible in Italy Hi, some issues from FB network ?? Do you have some info ? Regards, -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From raymond at prolocation.net Mon Sep 28 20:39:07 2015 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Mon, 28 Sep 2015 22:39:07 +0200 Subject: Facebook invisible in Italy In-Reply-To: References: Message-ID: <1F923F1D-C2D4-4B65-85EB-81C46F1E1B99@prolocation.net> Hai Marco, Same in NL so most likely bigger then Italy alone. Thanks, Raymond Dijkxhoorn, Prolocation > Op 28 sep. 2015 om 22:35 heeft Marco Paesani het volgende geschreven: > > Hi, > some issues from FB network ?? > Do you have some info ? > Regards, > > -- > > Marco Paesani > MPAE Srl > > Skype: mpaesani > Mobile: +39 348 6019349 > Success depends on the right choice ! > Email: marco at paesani.it From sam.oduor at gmail.com Mon Sep 28 20:41:49 2015 From: sam.oduor at gmail.com (Sam Oduor) Date: Mon, 28 Sep 2015 23:41:49 +0300 Subject: Facebook invisible in Italy In-Reply-To: <55472c482b734fbd80281092fdb8a08c@anx-i-dag02.anx.local> References: <55472c482b734fbd80281092fdb8a08c@anx-i-dag02.anx.local> Message-ID: Experienced a down time from East Africa - Nairobi - Kenya; but it is now back up ! 2015-09-28 23:38 GMT+03:00 J?rgen Jaritsch : > Hi, > > also down for us (Austria & Germany) and the OVH network. > > Best regards > > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: JJaritsch at anexia-it.com > Web: http://www.anexia-it.com > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT > U63216601 > > -----Urspr?ngliche Nachricht----- > Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Marco Paesani > Gesendet: Montag, 28. September 2015 22:35 > An: nanog > Betreff: Facebook invisible in Italy > > Hi, > some issues from FB network ?? > Do you have some info ? > Regards, > > -- > > Marco Paesani > MPAE Srl > > Skype: mpaesani > Mobile: +39 348 6019349 > Success depends on the right choice ! > Email: marco at paesani.it > -- Samson Oduor From mkaipov at outlook.com Mon Sep 28 20:45:26 2015 From: mkaipov at outlook.com (Murat Kaipov) Date: Mon, 28 Sep 2015 23:45:26 +0300 Subject: Facebook invisible in Italy In-Reply-To: <55472c482b734fbd80281092fdb8a08c@anx-i-dag02.anx.local> References: <55472c482b734fbd80281092fdb8a08c@anx-i-dag02.anx.local> Message-ID: All works fine for our network in Abkhazia. AS44491 > 28 ????. 2015 ?., ? 23:38, J?rgen Jaritsch ???????(?): > > Hi, > > also down for us (Austria & Germany) and the OVH network. > > Best regards > > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: JJaritsch at anexia-it.com > Web: http://www.anexia-it.com > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > -----Urspr?ngliche Nachricht----- > Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Marco Paesani > Gesendet: Montag, 28. September 2015 22:35 > An: nanog > Betreff: Facebook invisible in Italy > > Hi, > some issues from FB network ?? > Do you have some info ? > Regards, > > -- > > Marco Paesani > MPAE Srl > > Skype: mpaesani > Mobile: +39 348 6019349 > Success depends on the right choice ! > Email: marco at paesani.it From josh at imaginenetworksllc.com Mon Sep 28 20:49:38 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 28 Sep 2015 16:49:38 -0400 Subject: Facebook invisible in Italy In-Reply-To: References: Message-ID: There's already a thread on this. Facebook is down globally it seems. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Sep 28, 2015 at 4:35 PM, Marco Paesani wrote: > Hi, > some issues from FB network ?? > Do you have some info ? > Regards, > > -- > > Marco Paesani > MPAE Srl > > Skype: mpaesani > Mobile: +39 348 6019349 > Success depends on the right choice ! > Email: marco at paesani.it > From israel.lugo at lugosys.com Mon Sep 28 20:55:06 2015 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Mon, 28 Sep 2015 21:55:06 +0100 Subject: Facebook down (was: Re: Facebook invisible in Italy) In-Reply-To: <1F923F1D-C2D4-4B65-85EB-81C46F1E1B99@prolocation.net> References: <1F923F1D-C2D4-4B65-85EB-81C46F1E1B99@prolocation.net> Message-ID: <5609A92A.8010807@lugosys.com> Hello, Was down in Portugal until just now, and from downforeveryoneorjustme.com. Just tried and it seems to be working again, though. On 09/28/2015 09:39 PM, Raymond Dijkxhoorn wrote: > Hai Marco, > > Same in NL so most likely bigger then Italy alone. > > Thanks, > Raymond Dijkxhoorn, Prolocation > >> Op 28 sep. 2015 om 22:35 heeft Marco Paesani het volgende geschreven: >> >> Hi, >> some issues from FB network ?? >> Do you have some info ? >> Regards, >> >> -- >> >> Marco Paesani >> MPAE Srl >> >> Skype: mpaesani >> Mobile: +39 348 6019349 >> Success depends on the right choice ! >> Email: marco at paesani.it From Steve.Mikulasik at civeo.com Mon Sep 28 20:57:36 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Mon, 28 Sep 2015 20:57:36 +0000 Subject: Facebook invisible in Italy In-Reply-To: References: Message-ID: All good from AS15290. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marco Paesani Sent: Monday, September 28, 2015 2:35 PM To: nanog Subject: Facebook invisible in Italy Hi, some issues from FB network ?? Do you have some info ? Regards, -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From tony at wicks.co.nz Mon Sep 28 21:03:42 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 29 Sep 2015 10:03:42 +1300 Subject: Facebook invisible in Italy In-Reply-To: References: Message-ID: <003a01d0fa31$2886f8a0$7994e9e0$@wicks.co.nz> > Subject: RE: Facebook invisible in Italy > > All good from AS15290. Seems fine in New Zealand From stefan at fetaste.com Mon Sep 28 21:04:16 2015 From: stefan at fetaste.com (Stefan Larsson) Date: Mon, 28 Sep 2015 23:04:16 +0200 Subject: Facebook invisible in Italy In-Reply-To: References: Message-ID: https://developers.facebook.com/status/issues/1032802420085278/ stefan From:?Steve Mikulasik Reply:?Steve Mikulasik Date:?28 Sep 2015 at 23:00:08 To:?marco at paesani.it , nanog Subject:? RE: Facebook invisible in Italy All good from AS15290. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marco Paesani Sent: Monday, September 28, 2015 2:35 PM To: nanog Subject: Facebook invisible in Italy Hi, some issues from FB network ?? Do you have some info ? Regards, -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From Matthew.Black at csulb.edu Mon Sep 28 22:54:50 2015 From: Matthew.Black at csulb.edu (Matthew Black) Date: Mon, 28 Sep 2015 22:54:50 +0000 Subject: Facebook invisible in Italy In-Reply-To: References: Message-ID: Facebook has been running sluggish all day in California US for me. matthew black california state university, long beach -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marco Paesani Sent: Monday, September 28, 2015 1:35 PM To: nanog Subject: Facebook invisible in Italy Hi, some issues from FB network ?? Do you have some info ? Regards, -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From jamie at workshopx.com Mon Sep 28 20:40:06 2015 From: jamie at workshopx.com (Jamie Gwatkin) Date: Mon, 28 Sep 2015 16:40:06 -0400 Subject: Facebook invisible in Italy In-Reply-To: References: Message-ID: The graph api is unavailable - https://developers.facebook.com/status/... On Mon, Sep 28, 2015 at 4:35 PM, Marco Paesani wrote: > Hi, > some issues from FB network ?? > Do you have some info ? > Regards, > > -- > > Marco Paesani > MPAE Srl > > Skype: mpaesani > Mobile: +39 348 6019349 > Success depends on the right choice ! > Email: marco at paesani.it > -- *Jamie Gwatkin* / Software Developer - DevOps jamie at workshopx.com Inspire creation. www.workshopx.com *Our companies* CanvasPop / CanvasPop API / DNA11 / Crated / PopKey From fhlipzero at gmail.com Mon Sep 28 20:41:13 2015 From: fhlipzero at gmail.com (Philip Holbrook) Date: Mon, 28 Sep 2015 16:41:13 -0400 Subject: Facebook invisible in Italy In-Reply-To: References: Message-ID: <4D20A21D-D7F9-4AF0-A45B-3655EB73832B@gmail.com> was just showing down from Pittsburgh pa an hour ago too Sent from my iPhone 6 + > On Sep 28, 2015, at 4:35 PM, Marco Paesani wrote: > > Hi, > some issues from FB network ?? > Do you have some info ? > Regards, > > -- > > Marco Paesani > MPAE Srl > > Skype: mpaesani > Mobile: +39 348 6019349 > Success depends on the right choice ! > Email: marco at paesani.it From laszlo at heliacal.net Tue Sep 29 00:41:23 2015 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Tue, 29 Sep 2015 00:41:23 +0000 Subject: Question re session hijacking in dual stack environments w/MacOS In-Reply-To: References: Message-ID: <5609DE33.3030603@heliacal.net> On 2015-09-27 12:24, John Schimmel wrote: > Most Web application firewalls have cross-site request forgery protection. > When a form is downloaded, the firewall inserts a hidden field or cookie > that contains the IP address of the request. When the form is submitted, > the firewall then verifies that the post is sent from the same address. This reminds me of ICMP blocking which breaks path MTU discovery and thus blocks all users with < 1500 MTU. The technique described here doesn't sound like it would protect from XSS or CSRF; it would just introduce seemingly random failures like the OP described. The idea with trying to tie the apparent network address to a session is to make session hijacking harder, not local scripting attacks (which could come from the same address anyway), but it's a bad idea regardless because there is not normally a reason for a session to be 'sticky' in this way and so there's no effort made to keep the same address, it just happens by accident sometimes. Making this work so the WAF can be happy is in conflict with actually useful things like load balancing, cache proxies, privacy addresses, etc. It probably works some percentage of the time for some users, and those who it doesn't work for just get blamed for having a bad browser/computer/ISP/whatever. I hope that as the failure rate increases, people using these solutions eventually realize that they're blocking themselves off from the net. -Laszlo From sethm at rollernet.us Tue Sep 29 01:01:39 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 28 Sep 2015 18:01:39 -0700 Subject: Prefix hijacking by AS20115 Message-ID: <5609E2F3.9030407@rollernet.us> I've got a problem where AS20115 continues to announce prefixes after BGP neighbors were shutdown. They claim it's a wedged BGP process but aren't in any hurry to fix it outside of a maintenance window. I'm at a loss of what else I can do. They admit the problem but won't take action saying it needs to wait for a maintenance window. Am I out of line insisting that's an unacceptable response to a problem that results in prefix/traffic hijacking? ~Seth From ESundberg at nitelusa.com Tue Sep 29 01:21:35 2015 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Tue, 29 Sep 2015 01:21:35 +0000 Subject: Facebook - IP Engineering Contact Message-ID: <495D0934DA46854A9CA758393724D59016B5D2A9@NI-MAIL02.nii.ads> Can an IP Engineer from facebook please contact me off list. I have routing issue getting to your mai1 (Miami, FL) pop. Unrelated to the issue earlier today. Erik Sundberg Sr. Network Engineer p: 773.661.5532 c: 708.710.7419 866.892.0915 24/7 NOC 1101 W. Lake Street, 6th Floor | Chicago, IL 60607 esundberg at nitelusa.com | www.nitelusa.com ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From bill at herrin.us Tue Sep 29 01:30:37 2015 From: bill at herrin.us (William Herrin) Date: Mon, 28 Sep 2015 21:30:37 -0400 Subject: Prefix hijacking by AS20115 In-Reply-To: <5609E2F3.9030407@rollernet.us> References: <5609E2F3.9030407@rollernet.us> Message-ID: On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen wrote: > I've got a problem where AS20115 continues to announce prefixes after BGP > neighbors were shutdown. They claim it's a wedged BGP process but aren't in > any hurry to fix it outside of a maintenance window. If they weren't lying to you, they'd fix it now. That's not the kind of problem that waits. Thing is: they lied to you. Long ago they "helpfully" programmed their router to announce your route regardless of whether you sent a route to them. They want to wait for a maintenance window to remove that configuration. > I'm at a loss of what else I can do. They admit the problem but won't take > action saying it needs to wait for a maintenance window. Am I out of line > insisting that's an unacceptable response to a problem that results in > prefix/traffic hijacking? Try dropping the link entirely. If they still announce your addresses, bring it back up but report it as emergency down, escalate, and call back every 10 minutes until the junior tech understands that it's time to call and wake up the guy who makes the decision to fix it now. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From sethm at rollernet.us Tue Sep 29 03:08:47 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 28 Sep 2015 20:08:47 -0700 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> Message-ID: <560A00BF.4020209@rollernet.us> On 9/28/15 18:30, William Herrin wrote: > On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen wrote: >> I've got a problem where AS20115 continues to announce prefixes after BGP >> neighbors were shutdown. They claim it's a wedged BGP process but aren't in >> any hurry to fix it outside of a maintenance window. > > If they weren't lying to you, they'd fix it now. That's not the kind > of problem that waits. > > Thing is: they lied to you. Long ago they "helpfully" programmed their > router to announce your route regardless of whether you sent a route > to them. They want to wait for a maintenance window to remove that > configuration. > > >> I'm at a loss of what else I can do. They admit the problem but won't take >> action saying it needs to wait for a maintenance window. Am I out of line >> insisting that's an unacceptable response to a problem that results in >> prefix/traffic hijacking? > > Try dropping the link entirely. If they still announce your addresses, > bring it back up but report it as emergency down, escalate, and call > back every 10 minutes until the junior tech understands that it's time > to call and wake up the guy who makes the decision to fix it now. > I'm at the tail end here almost 8 hours later since the hijacking started. Their NOC is just blowing me off now and they're happy to continue the hijacking until it's convenient for them to have a maintenance window. And that's apparently the final decision. ~Seth From josh at imaginenetworksllc.com Tue Sep 29 03:11:00 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 28 Sep 2015 23:11:00 -0400 Subject: Prefix hijacking by AS20115 In-Reply-To: <560A00BF.4020209@rollernet.us> References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> Message-ID: Start announcing their prefixes? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sep 28, 2015 11:09 PM, "Seth Mattinen" wrote: > On 9/28/15 18:30, William Herrin wrote: > >> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen >> wrote: >> >>> I've got a problem where AS20115 continues to announce prefixes after BGP >>> neighbors were shutdown. They claim it's a wedged BGP process but aren't >>> in >>> any hurry to fix it outside of a maintenance window. >>> >> >> If they weren't lying to you, they'd fix it now. That's not the kind >> of problem that waits. >> >> Thing is: they lied to you. Long ago they "helpfully" programmed their >> router to announce your route regardless of whether you sent a route >> to them. They want to wait for a maintenance window to remove that >> configuration. >> >> >> I'm at a loss of what else I can do. They admit the problem but won't take >>> action saying it needs to wait for a maintenance window. Am I out of line >>> insisting that's an unacceptable response to a problem that results in >>> prefix/traffic hijacking? >>> >> >> Try dropping the link entirely. If they still announce your addresses, >> bring it back up but report it as emergency down, escalate, and call >> back every 10 minutes until the junior tech understands that it's time >> to call and wake up the guy who makes the decision to fix it now. >> >> > > I'm at the tail end here almost 8 hours later since the hijacking started. > Their NOC is just blowing me off now and they're happy to continue the > hijacking until it's convenient for them to have a maintenance window. And > that's apparently the final decision. > > ~Seth > From hannigan at gmail.com Tue Sep 29 03:19:29 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 28 Sep 2015 23:19:29 -0400 Subject: Prefix hijacking by AS20115 In-Reply-To: <560A00BF.4020209@rollernet.us> References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> Message-ID: Is this related to 104.73.161.0/24? That's ours. :-) We'll take a look and get back to you. Thanks for caring! Best, Marty > On Sep 28, 2015, at 23:08, Seth Mattinen wrote: > >> On 9/28/15 18:30, William Herrin wrote: >>> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen wrote: >>> I've got a problem where AS20115 continues to announce prefixes after BGP >>> neighbors were shutdown. They claim it's a wedged BGP process but aren't in >>> any hurry to fix it outside of a maintenance window. >> >> If they weren't lying to you, they'd fix it now. That's not the kind >> of problem that waits. >> >> Thing is: they lied to you. Long ago they "helpfully" programmed their >> router to announce your route regardless of whether you sent a route >> to them. They want to wait for a maintenance window to remove that >> configuration. >> >> >>> I'm at a loss of what else I can do. They admit the problem but won't take >>> action saying it needs to wait for a maintenance window. Am I out of line >>> insisting that's an unacceptable response to a problem that results in >>> prefix/traffic hijacking? >> >> Try dropping the link entirely. If they still announce your addresses, >> bring it back up but report it as emergency down, escalate, and call >> back every 10 minutes until the junior tech understands that it's time >> to call and wake up the guy who makes the decision to fix it now. > > > I'm at the tail end here almost 8 hours later since the hijacking started. Their NOC is just blowing me off now and they're happy to continue the hijacking until it's convenient for them to have a maintenance window. And that's apparently the final decision. > > ~Seth From sethm at rollernet.us Tue Sep 29 03:24:38 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 28 Sep 2015 20:24:38 -0700 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> Message-ID: <560A0476.4030904@rollernet.us> On 9/28/15 20:19, Martin Hannigan wrote: > > Is this related to 104.73.161.0/24? That's ours. :-) > > We'll take a look and get back to you. Thanks for caring! > Yep, that's one of the affected prefixes. ~Seth From bob at FiberInternetCenter.com Tue Sep 29 03:59:31 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 28 Sep 2015 20:59:31 -0700 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> Message-ID: That's something I would do. Announce announce and keep adding ports until I hit a 10 Gig port worth of traffic or saw it fixed. Be sure to put in a blackhole route for the prefixes. Try to pick blocks that are as geographically located to your peering routers as possible ...IE in Reno pick the blocks that seem to be near by - like Reno, Tahoe, Sacramento ..... when that batch of customers makes their phones ring all night someone will listen. Would be nice if our membership organization ARIN ( that we all pay to keep us somewhat organized) had an ability to do something for you.... I never looked into it...i don't know....maybe it does ? But, in the mean time I am pretty sure you can document this well and prove your announcements of theirs was due to the fact you couldn't get proper technical attention and needed to desperately before your customers cancel after 8 hours of this. Tomorrow call your lawyers and begin to sue that cable company (did I recognize that ASN as cable TV ? ) for damages this must be causing you in ill-will amongst your customer base. I wonder just how you prove the damage...some equation based on customer calls and complaints together with how many years you have been in business as well as the number of contracts that are coming up for renewal. etc etc. Now that would be interesting to see a formula for that if anyone has been through it. Thank You Bob Evans CTO > Start announcing their prefixes? > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Sep 28, 2015 11:09 PM, "Seth Mattinen" wrote: > >> On 9/28/15 18:30, William Herrin wrote: >> >>> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen >>> wrote: >>> >>>> I've got a problem where AS20115 continues to announce prefixes after >>>> BGP >>>> neighbors were shutdown. They claim it's a wedged BGP process but >>>> aren't >>>> in >>>> any hurry to fix it outside of a maintenance window. >>>> >>> >>> If they weren't lying to you, they'd fix it now. That's not the kind >>> of problem that waits. >>> >>> Thing is: they lied to you. Long ago they "helpfully" programmed their >>> router to announce your route regardless of whether you sent a route >>> to them. They want to wait for a maintenance window to remove that >>> configuration. >>> >>> >>> I'm at a loss of what else I can do. They admit the problem but won't >>> take >>>> action saying it needs to wait for a maintenance window. Am I out of >>>> line >>>> insisting that's an unacceptable response to a problem that results in >>>> prefix/traffic hijacking? >>>> >>> >>> Try dropping the link entirely. If they still announce your addresses, >>> bring it back up but report it as emergency down, escalate, and call >>> back every 10 minutes until the junior tech understands that it's time >>> to call and wake up the guy who makes the decision to fix it now. >>> >>> >> >> I'm at the tail end here almost 8 hours later since the hijacking >> started. >> Their NOC is just blowing me off now and they're happy to continue the >> hijacking until it's convenient for them to have a maintenance window. >> And >> that's apparently the final decision. >> >> ~Seth >> > From hank at efes.iucc.ac.il Tue Sep 29 04:24:15 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 29 Sep 2015 07:24:15 +0300 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <560A00BF.4020209@rollernet.us> <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> Message-ID: <5.1.1.6.2.20150929072159.0200ea08@efes.iucc.ac.il> At 23:11 28/09/2015 -0400, Josh Luthman wrote: >Start announcing their prefixes? Contact the upstreams of AS20115 - Cogent, Level3, HE and XO. -Hank >Josh Luthman >Office: 937-552-2340 >Direct: 937-552-2343 >1100 Wayne St >Suite 1337 >Troy, OH 45373 >On Sep 28, 2015 11:09 PM, "Seth Mattinen" wrote: > > > On 9/28/15 18:30, William Herrin wrote: > > > >> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen > >> wrote: > >> > >>> I've got a problem where AS20115 continues to announce prefixes after BGP > >>> neighbors were shutdown. They claim it's a wedged BGP process but aren't > >>> in > >>> any hurry to fix it outside of a maintenance window. > >>> > >> > >> If they weren't lying to you, they'd fix it now. That's not the kind > >> of problem that waits. > >> > >> Thing is: they lied to you. Long ago they "helpfully" programmed their > >> router to announce your route regardless of whether you sent a route > >> to them. They want to wait for a maintenance window to remove that > >> configuration. > >> > >> > >> I'm at a loss of what else I can do. They admit the problem but won't take > >>> action saying it needs to wait for a maintenance window. Am I out of line > >>> insisting that's an unacceptable response to a problem that results in > >>> prefix/traffic hijacking? > >>> > >> > >> Try dropping the link entirely. If they still announce your addresses, > >> bring it back up but report it as emergency down, escalate, and call > >> back every 10 minutes until the junior tech understands that it's time > >> to call and wake up the guy who makes the decision to fix it now. > >> > >> > > > > I'm at the tail end here almost 8 hours later since the hijacking started. > > Their NOC is just blowing me off now and they're happy to continue the > > hijacking until it's convenient for them to have a maintenance window. And > > that's apparently the final decision. > > > > ~Seth > > From morrowc.lists at gmail.com Tue Sep 29 04:28:54 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 29 Sep 2015 00:28:54 -0400 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> Message-ID: On Mon, Sep 28, 2015 at 11:59 PM, Bob Evans wrote: > That's something I would do. Announce announce and keep adding ports until > I hit a 10 Gig port worth of traffic or saw it fixed. Be sure to put in a > blackhole route for the prefixes. Try to pick blocks that are as > geographically located to your peering routers as possible ...IE in Reno > pick the blocks that seem to be near by - like Reno, Tahoe, Sacramento > ..... when that batch of customers makes their phones ring all night > someone will listen. > that seems like a pretty poor strategy... guaranteed to get you into some hot water, I suspect. Keep in mind that the 'noc' at 20115 isn't the same thing as the customer-service-center. There's likely little to link the 2 things together there :( > Would be nice if our membership organization ARIN ( that we all pay to > keep us somewhat organized) had an ability to do something for you.... I > never looked into it...i don't know....maybe it does ? arin does not guarantee 'routability' of netblocks assigned to your org. > But, in the mean time I am pretty sure you can document this well and > prove your announcements of theirs was due to the fact you couldn't get > proper technical attention and needed to desperately before your customers > cancel after 8 hours of this. Tomorrow call your lawyers and begin to sue > that cable company (did I recognize that ASN as cable TV ? ) for damages > this must be causing you in ill-will amongst your customer base. > > I wonder just how you prove the damage...some equation based on customer > calls and complaints together with how many years you have been in > business as well as the number of contracts that are coming up for > renewal. etc etc. Now that would be interesting to see a formula for that > if anyone has been through it. > you COULD find a charter person on-list...there are nine names on the attendees list for the upcoming meeting... I imagine peeringdb likely has folk listed... gosh it sure does: what with their emails and everything. > Thank You > Bob Evans > CTO > > > > >> Start announcing their prefixes? >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> On Sep 28, 2015 11:09 PM, "Seth Mattinen" wrote: >> >>> On 9/28/15 18:30, William Herrin wrote: >>> >>>> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen >>>> wrote: >>>> >>>>> I've got a problem where AS20115 continues to announce prefixes after >>>>> BGP >>>>> neighbors were shutdown. They claim it's a wedged BGP process but >>>>> aren't >>>>> in >>>>> any hurry to fix it outside of a maintenance window. >>>>> >>>> >>>> If they weren't lying to you, they'd fix it now. That's not the kind >>>> of problem that waits. >>>> >>>> Thing is: they lied to you. Long ago they "helpfully" programmed their >>>> router to announce your route regardless of whether you sent a route >>>> to them. They want to wait for a maintenance window to remove that >>>> configuration. >>>> >>>> >>>> I'm at a loss of what else I can do. They admit the problem but won't >>>> take >>>>> action saying it needs to wait for a maintenance window. Am I out of >>>>> line >>>>> insisting that's an unacceptable response to a problem that results in >>>>> prefix/traffic hijacking? >>>>> >>>> >>>> Try dropping the link entirely. If they still announce your addresses, >>>> bring it back up but report it as emergency down, escalate, and call >>>> back every 10 minutes until the junior tech understands that it's time >>>> to call and wake up the guy who makes the decision to fix it now. >>>> >>>> >>> >>> I'm at the tail end here almost 8 hours later since the hijacking >>> started. >>> Their NOC is just blowing me off now and they're happy to continue the >>> hijacking until it's convenient for them to have a maintenance window. >>> And >>> that's apparently the final decision. >>> >>> ~Seth >>> >> > > From stenn at nwtime.org Tue Sep 29 04:30:30 2015 From: stenn at nwtime.org (Harlan Stenn) Date: Mon, 28 Sep 2015 21:30:30 -0700 Subject: Security release scheduling Message-ID: <560A13E6.7060509@nwtime.org> I'm looking for some general "calendar" help to use for our security release scheduling process. Something that usefully accounts for clients all over the world. By "usefully accounts" I mean that we want to be able to have reasonable confidence that we're not going to pick a public release date that is a national holiday for one country, and we're also not going to avoid a date because it's "let's order pizza" day somewhere else, but the purpose of the holiday is obscured because of language translation issues. I figure this is something others must have solved, and I'm hoping some folks on this list might be able to offer me some pointers. -- Harlan Stenn http://networktimefoundation.org - be a member! From contact at winterei.se Tue Sep 29 04:54:49 2015 From: contact at winterei.se (Paul S.) Date: Tue, 29 Sep 2015 13:54:49 +0900 Subject: Prefix hijacking by AS20115 In-Reply-To: <5.1.1.6.2.20150929072159.0200ea08@efes.iucc.ac.il> References: <560A00BF.4020209@rollernet.us> <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <5.1.1.6.2.20150929072159.0200ea08@efes.iucc.ac.il> Message-ID: <560A1999.3000305@winterei.se> +1, this is the only sensible advice here. NSPs actually do seem to care about not letting things like these happen. On 2015/09/29 01:24 PM, Hank Nussbacher wrote: > At 23:11 28/09/2015 -0400, Josh Luthman wrote: > >> Start announcing their prefixes? > > Contact the upstreams of AS20115 - Cogent, Level3, HE and XO. > > -Hank > > >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> On Sep 28, 2015 11:09 PM, "Seth Mattinen" wrote: >> >> > On 9/28/15 18:30, William Herrin wrote: >> > >> >> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen >> >> wrote: >> >> >> >>> I've got a problem where AS20115 continues to announce prefixes >> after BGP >> >>> neighbors were shutdown. They claim it's a wedged BGP process but >> aren't >> >>> in >> >>> any hurry to fix it outside of a maintenance window. >> >>> >> >> >> >> If they weren't lying to you, they'd fix it now. That's not the kind >> >> of problem that waits. >> >> >> >> Thing is: they lied to you. Long ago they "helpfully" programmed >> their >> >> router to announce your route regardless of whether you sent a route >> >> to them. They want to wait for a maintenance window to remove that >> >> configuration. >> >> >> >> >> >> I'm at a loss of what else I can do. They admit the problem but >> won't take >> >>> action saying it needs to wait for a maintenance window. Am I out >> of line >> >>> insisting that's an unacceptable response to a problem that >> results in >> >>> prefix/traffic hijacking? >> >>> >> >> >> >> Try dropping the link entirely. If they still announce your >> addresses, >> >> bring it back up but report it as emergency down, escalate, and call >> >> back every 10 minutes until the junior tech understands that it's >> time >> >> to call and wake up the guy who makes the decision to fix it now. >> >> >> >> >> > >> > I'm at the tail end here almost 8 hours later since the hijacking >> started. >> > Their NOC is just blowing me off now and they're happy to continue the >> > hijacking until it's convenient for them to have a maintenance >> window. And >> > that's apparently the final decision. >> > >> > ~Seth >> > > From jj at anexia.at Tue Sep 29 05:14:29 2015 From: jj at anexia.at (=?Windows-1252?Q?J=FCrgen_Jaritsch?=) Date: Tue, 29 Sep 2015 05:14:29 +0000 Subject: Prefix hijacking by AS20115 In-Reply-To: <560A1999.3000305@winterei.se> References: <560A00BF.4020209@rollernet.us> <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <5.1.1.6.2.20150929072159.0200ea08@efes.iucc.ac.il>, <560A1999.3000305@winterei.se> Message-ID: Cogent and Level3 will tell you that you are not their customer ...HE and XO will react. J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Original Message----- From: Paul S. [contact at winterei.se] Received: Dienstag, 29 Sep. 2015, 6:57 To: nanog at nanog.org [nanog at nanog.org] Subject: Re: Prefix hijacking by AS20115 +1, this is the only sensible advice here. NSPs actually do seem to care about not letting things like these happen. On 2015/09/29 01:24 PM, Hank Nussbacher wrote: > At 23:11 28/09/2015 -0400, Josh Luthman wrote: > >> Start announcing their prefixes? > > Contact the upstreams of AS20115 - Cogent, Level3, HE and XO. > > -Hank > > >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> On Sep 28, 2015 11:09 PM, "Seth Mattinen" wrote: >> >> > On 9/28/15 18:30, William Herrin wrote: >> > >> >> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen >> >> wrote: >> >> >> >>> I've got a problem where AS20115 continues to announce prefixes >> after BGP >> >>> neighbors were shutdown. They claim it's a wedged BGP process but >> aren't >> >>> in >> >>> any hurry to fix it outside of a maintenance window. >> >>> >> >> >> >> If they weren't lying to you, they'd fix it now. That's not the kind >> >> of problem that waits. >> >> >> >> Thing is: they lied to you. Long ago they "helpfully" programmed >> their >> >> router to announce your route regardless of whether you sent a route >> >> to them. They want to wait for a maintenance window to remove that >> >> configuration. >> >> >> >> >> >> I'm at a loss of what else I can do. They admit the problem but >> won't take >> >>> action saying it needs to wait for a maintenance window. Am I out >> of line >> >>> insisting that's an unacceptable response to a problem that >> results in >> >>> prefix/traffic hijacking? >> >>> >> >> >> >> Try dropping the link entirely. If they still announce your >> addresses, >> >> bring it back up but report it as emergency down, escalate, and call >> >> back every 10 minutes until the junior tech understands that it's >> time >> >> to call and wake up the guy who makes the decision to fix it now. >> >> >> >> >> > >> > I'm at the tail end here almost 8 hours later since the hijacking >> started. >> > Their NOC is just blowing me off now and they're happy to continue the >> > hijacking until it's convenient for them to have a maintenance >> window. And >> > that's apparently the final decision. >> > >> > ~Seth >> > > From goemon at anime.net Tue Sep 29 05:15:22 2015 From: goemon at anime.net (goemon at anime.net) Date: Mon, 28 Sep 2015 22:15:22 -0700 (PDT) Subject: Prefix hijacking by AS20115 In-Reply-To: <560A00BF.4020209@rollernet.us> References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> Message-ID: On Mon, 28 Sep 2015, Seth Mattinen wrote: > I'm at the tail end here almost 8 hours later since the hijacking started. > Their NOC is just blowing me off now and they're happy to continue the > hijacking until it's convenient for them to have a maintenance window. And > that's apparently the final decision. Willful negligence. Will only be in your favor when it comes to collect damages. -Dan From bob at FiberInternetCenter.com Tue Sep 29 06:04:50 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 28 Sep 2015 23:04:50 -0700 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> Message-ID: <2ceab549584e5e6a4f9c1c6a1d82c30b.squirrel@66.201.44.180> > On Mon, Sep 28, 2015 at 11:59 PM, Bob Evans > wrote: >> That's something I would do. Announce announce and keep adding ports >> until >> I hit a 10 Gig port worth of traffic or saw it fixed. Be sure to put in >> a >> blackhole route for the prefixes. Try to pick blocks that are as >> geographically located to your peering routers as possible ...IE in Reno >> pick the blocks that seem to be near by - like Reno, Tahoe, Sacramento >> ..... when that batch of customers makes their phones ring all night >> someone will listen. >> > > that seems like a pretty poor strategy... guaranteed to get you into > some hot water, I suspect. Keep in mind that the 'noc' at 20115 isn't > the same thing as the customer-service-center. There's likely little > to link the 2 things together there :( You are right - probably creates more problems than good. > >> Would be nice if our membership organization ARIN ( that we all pay to >> keep us somewhat organized) had an ability to do something for you.... I >> never looked into it...i don't know....maybe it does ? > > arin does not guarantee 'routability' of netblocks assigned to your org. Yep, I was pretty sure of that - but wouldn't it be nice if arin could have some communication line or at least try. Yes, never any guarantees really. bob > >> But, in the mean time I am pretty sure you can document this well and >> prove your announcements of theirs was due to the fact you couldn't get >> proper technical attention and needed to desperately before your >> customers >> cancel after 8 hours of this. Tomorrow call your lawyers and begin to >> sue >> that cable company (did I recognize that ASN as cable TV ? ) for damages >> this must be causing you in ill-will amongst your customer base. >> >> I wonder just how you prove the damage...some equation based on customer >> calls and complaints together with how many years you have been in >> business as well as the number of contracts that are coming up for >> renewal. etc etc. Now that would be interesting to see a formula for >> that >> if anyone has been through it. >> > > you COULD find a charter person on-list...there are nine names on the > attendees list for the upcoming meeting... I imagine peeringdb likely > has folk listed... gosh it sure does: > > > > what with their emails and everything. > >> Thank You >> Bob Evans >> CTO >> >> >> >> >>> Start announcing their prefixes? >>> >>> Josh Luthman >>> Office: 937-552-2340 >>> Direct: 937-552-2343 >>> 1100 Wayne St >>> Suite 1337 >>> Troy, OH 45373 >>> On Sep 28, 2015 11:09 PM, "Seth Mattinen" wrote: >>> >>>> On 9/28/15 18:30, William Herrin wrote: >>>> >>>>> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen >>>>> wrote: >>>>> >>>>>> I've got a problem where AS20115 continues to announce prefixes >>>>>> after >>>>>> BGP >>>>>> neighbors were shutdown. They claim it's a wedged BGP process but >>>>>> aren't >>>>>> in >>>>>> any hurry to fix it outside of a maintenance window. >>>>>> >>>>> >>>>> If they weren't lying to you, they'd fix it now. That's not the kind >>>>> of problem that waits. >>>>> >>>>> Thing is: they lied to you. Long ago they "helpfully" programmed >>>>> their >>>>> router to announce your route regardless of whether you sent a route >>>>> to them. They want to wait for a maintenance window to remove that >>>>> configuration. >>>>> >>>>> >>>>> I'm at a loss of what else I can do. They admit the problem but won't >>>>> take >>>>>> action saying it needs to wait for a maintenance window. Am I out of >>>>>> line >>>>>> insisting that's an unacceptable response to a problem that results >>>>>> in >>>>>> prefix/traffic hijacking? >>>>>> >>>>> >>>>> Try dropping the link entirely. If they still announce your >>>>> addresses, >>>>> bring it back up but report it as emergency down, escalate, and call >>>>> back every 10 minutes until the junior tech understands that it's >>>>> time >>>>> to call and wake up the guy who makes the decision to fix it now. >>>>> >>>>> >>>> >>>> I'm at the tail end here almost 8 hours later since the hijacking >>>> started. >>>> Their NOC is just blowing me off now and they're happy to continue the >>>> hijacking until it's convenient for them to have a maintenance window. >>>> And >>>> that's apparently the final decision. >>>> >>>> ~Seth >>>> >>> >> >> > From marka at isc.org Tue Sep 29 06:08:07 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 29 Sep 2015 16:08:07 +1000 Subject: Security release scheduling In-Reply-To: Your message of "Mon, 28 Sep 2015 21:30:30 -0700." <560A13E6.7060509@nwtime.org> References: <560A13E6.7060509@nwtime.org> Message-ID: <20150929060807.2DC4E38C2F2A@rock.dv.isc.org> In message <560A13E6.7060509 at nwtime.org>, Harlan Stenn writes: > I'm looking for some general "calendar" help to use for our security > release scheduling process. Something that usefully accounts for > clients all over the world. > > By "usefully accounts" I mean that we want to be able to have reasonable > confidence that we're not going to pick a public release date that is a > national holiday for one country, and we're also not going to avoid a > date because it's "let's order pizza" day somewhere else, but the > purpose of the holiday is obscured because of language translation issues. > > I figure this is something others must have solved, and I'm hoping some > folks on this list might be able to offer me some pointers. There's a national holiday basically everyday of the year. http://www.timeanddate.com/holidays/ Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Tue Sep 29 06:15:57 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 29 Sep 2015 02:15:57 -0400 Subject: Prefix hijacking by AS20115 In-Reply-To: <2ceab549584e5e6a4f9c1c6a1d82c30b.squirrel@66.201.44.180> References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <2ceab549584e5e6a4f9c1c6a1d82c30b.squirrel@66.201.44.180> Message-ID: On Tue, Sep 29, 2015 at 2:04 AM, Bob Evans wrote: > > >> On Mon, Sep 28, 2015 at 11:59 PM, Bob Evans >> wrote: >>> That's something I would do. Announce announce and keep adding ports >>> until >>> I hit a 10 Gig port worth of traffic or saw it fixed. Be sure to put in >>> a >>> blackhole route for the prefixes. Try to pick blocks that are as >>> geographically located to your peering routers as possible ...IE in Reno >>> pick the blocks that seem to be near by - like Reno, Tahoe, Sacramento >>> ..... when that batch of customers makes their phones ring all night >>> someone will listen. >>> >> >> that seems like a pretty poor strategy... guaranteed to get you into >> some hot water, I suspect. Keep in mind that the 'noc' at 20115 isn't >> the same thing as the customer-service-center. There's likely little >> to link the 2 things together there :( > > You are right - probably creates more problems than good. > >> >>> Would be nice if our membership organization ARIN ( that we all pay to >>> keep us somewhat organized) had an ability to do something for you.... I >>> never looked into it...i don't know....maybe it does ? >> >> arin does not guarantee 'routability' of netblocks assigned to your org. > > Yep, I was pretty sure of that - but wouldn't it be nice if arin could > have some communication line or at least try. Yes, never any guarantees > really. I'm fairly sure that the arin (or ripe or apnic or...) answer to your question is: "read the contact info in whois... call the stated numbers." pretty sure that's also not going to be super helpful, email the poc's in the peering-db. > bob > >> >>> But, in the mean time I am pretty sure you can document this well and >>> prove your announcements of theirs was due to the fact you couldn't get >>> proper technical attention and needed to desperately before your >>> customers >>> cancel after 8 hours of this. Tomorrow call your lawyers and begin to >>> sue >>> that cable company (did I recognize that ASN as cable TV ? ) for damages >>> this must be causing you in ill-will amongst your customer base. >>> >>> I wonder just how you prove the damage...some equation based on customer >>> calls and complaints together with how many years you have been in >>> business as well as the number of contracts that are coming up for >>> renewal. etc etc. Now that would be interesting to see a formula for >>> that >>> if anyone has been through it. >>> >> >> you COULD find a charter person on-list...there are nine names on the >> attendees list for the upcoming meeting... I imagine peeringdb likely >> has folk listed... gosh it sure does: >> >> >> >> what with their emails and everything. >> >>> Thank You >>> Bob Evans >>> CTO >>> >>> >>> >>> >>>> Start announcing their prefixes? >>>> >>>> Josh Luthman >>>> Office: 937-552-2340 >>>> Direct: 937-552-2343 >>>> 1100 Wayne St >>>> Suite 1337 >>>> Troy, OH 45373 >>>> On Sep 28, 2015 11:09 PM, "Seth Mattinen" wrote: >>>> >>>>> On 9/28/15 18:30, William Herrin wrote: >>>>> >>>>>> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen >>>>>> wrote: >>>>>> >>>>>>> I've got a problem where AS20115 continues to announce prefixes >>>>>>> after >>>>>>> BGP >>>>>>> neighbors were shutdown. They claim it's a wedged BGP process but >>>>>>> aren't >>>>>>> in >>>>>>> any hurry to fix it outside of a maintenance window. >>>>>>> >>>>>> >>>>>> If they weren't lying to you, they'd fix it now. That's not the kind >>>>>> of problem that waits. >>>>>> >>>>>> Thing is: they lied to you. Long ago they "helpfully" programmed >>>>>> their >>>>>> router to announce your route regardless of whether you sent a route >>>>>> to them. They want to wait for a maintenance window to remove that >>>>>> configuration. >>>>>> >>>>>> >>>>>> I'm at a loss of what else I can do. They admit the problem but won't >>>>>> take >>>>>>> action saying it needs to wait for a maintenance window. Am I out of >>>>>>> line >>>>>>> insisting that's an unacceptable response to a problem that results >>>>>>> in >>>>>>> prefix/traffic hijacking? >>>>>>> >>>>>> >>>>>> Try dropping the link entirely. If they still announce your >>>>>> addresses, >>>>>> bring it back up but report it as emergency down, escalate, and call >>>>>> back every 10 minutes until the junior tech understands that it's >>>>>> time >>>>>> to call and wake up the guy who makes the decision to fix it now. >>>>>> >>>>>> >>>>> >>>>> I'm at the tail end here almost 8 hours later since the hijacking >>>>> started. >>>>> Their NOC is just blowing me off now and they're happy to continue the >>>>> hijacking until it's convenient for them to have a maintenance window. >>>>> And >>>>> that's apparently the final decision. >>>>> >>>>> ~Seth >>>>> >>>> >>> >>> >> > > From stenn at nwtime.org Tue Sep 29 07:18:43 2015 From: stenn at nwtime.org (Harlan Stenn) Date: Tue, 29 Sep 2015 00:18:43 -0700 Subject: Security release scheduling In-Reply-To: <20150929060807.2DC4E38C2F2A@rock.dv.isc.org> References: <560A13E6.7060509@nwtime.org> <20150929060807.2DC4E38C2F2A@rock.dv.isc.org> Message-ID: <560A3B53.7050803@nwtime.org> On 9/28/15 11:08 PM, Mark Andrews wrote: > In message <560A13E6.7060509 at nwtime.org>, Harlan Stenn writes: >> I'm looking for some general "calendar" help to use for our security >> release scheduling process. Something that usefully accounts for >> clients all over the world. >> >> By "usefully accounts" I mean that we want to be able to have reasonable >> confidence that we're not going to pick a public release date that is a >> national holiday for one country, and we're also not going to avoid a >> date because it's "let's order pizza" day somewhere else, but the >> purpose of the holiday is obscured because of language translation issues. >> >> I figure this is something others must have solved, and I'm hoping some >> folks on this list might be able to offer me some pointers. > > There's a national holiday basically everyday of the year. > > http://www.timeanddate.com/holidays/ Thanks, Mark! So much for that idea... I guess the best we can hope for is to minimize the impact. -- Harlan Stenn http://networktimefoundation.org - be a member! From mark.tinka at seacom.mu Tue Sep 29 07:23:59 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 Sep 2015 09:23:59 +0200 Subject: Question re session hijacking in dual stack environments w/MacOS In-Reply-To: References: Message-ID: <560A3C8F.4060306@seacom.mu> On 26/Sep/15 16:34, David Hubbard wrote: > > Has anyone run into this? Our users on other platforms don't seem to > have this issue; linux and MS desktops seem to just use v6 if it's > available and v4 if not. I have been tracking down an issue for months where SSH'ing to some devices (which picks IPv6 by default) from my Mac while in the office drops the connection, forcing me to reconnect. It's random; sometimes it happens a lot, sometimes, rarely, other times not at all. I've sort of suspected OS X to be the issue (10.10.5) here. The workaround has been to SSH strictly on IPv4 which is always stable. So it seems to be an issue when the session is carried over IPv6. This only affects OS X. SSH'ing from FreeBSD, for example, on IPv6 is stable. To be honest, I've been a little busy to look deeper into this, but it definitely has something to do with what you describe, I imagine. Mark. From bgreene at senki.org Tue Sep 29 07:39:57 2015 From: bgreene at senki.org (Barry Greene) Date: Tue, 29 Sep 2015 15:39:57 +0800 Subject: Security release scheduling In-Reply-To: <560A13E6.7060509@nwtime.org> References: <560A13E6.7060509@nwtime.org> Message-ID: <157CF300-F751-4798-A82A-88B69C5CE15C@senki.org> > > Hi Harlan, The general principle is look out for the major network lock downs. Some times that is overlap with holidays. Other times it is over financial close months. My personal $.02 is to avoid major vulnerability disclosures in December, during Lunar New Year weeks, during Ramadan, and June. Some would also include August (Euro holidays). But these days there are timers given by the vulnerability finder (or CERT Team) and conference disclosures (security rock stars) that drive the disclosure to a time which is not optimal to the people who have to roll out the remediation. In essence, write a disclose policy, put it on your website, and be open for improvements based on input from your constituents. Do your best. That is all your can do. Barry PS - Let me know if you need help writing the disclosure policy. From stenn at nwtime.org Tue Sep 29 07:57:19 2015 From: stenn at nwtime.org (Harlan Stenn) Date: Tue, 29 Sep 2015 00:57:19 -0700 Subject: Security release scheduling In-Reply-To: <157CF300-F751-4798-A82A-88B69C5CE15C@senki.org> References: <560A13E6.7060509@nwtime.org> <157CF300-F751-4798-A82A-88B69C5CE15C@senki.org> Message-ID: <560A445F.1040605@nwtime.org> Good info, Barry - thanks! I appreciate your offer, too! H -- On 9/29/15 12:39 AM, Barry Greene wrote: >> >> Hi Harlan, > > The general principle is look out for the major network lock downs. Some times that is overlap with holidays. Other times it is over financial close months. > > My personal $.02 is to avoid major vulnerability disclosures in December, during Lunar New Year weeks, during Ramadan, and June. Some would also include August (Euro holidays). > > But these days there are timers given by the vulnerability finder (or CERT Team) and conference disclosures (security rock stars) that drive the disclosure to a time which is not optimal to the people who have to roll out the remediation. > > In essence, write a disclose policy, put it on your website, and be open for improvements based on input from your constituents. Do your best. That is all your can do. > > Barry > > PS - Let me know if you need help writing the disclosure policy. > > > -- Harlan Stenn http://networktimefoundation.org - be a member! From eric at ericheather.com Tue Sep 29 14:10:11 2015 From: eric at ericheather.com (Eric C. Miller) Date: Tue, 29 Sep 2015 14:10:11 +0000 Subject: Hummingbird Networks Optics Message-ID: Does anybody have any experience with Hummingbird Networks optics? Thank you! Eric From jim.rampley at charter.com Tue Sep 29 14:26:48 2015 From: jim.rampley at charter.com (Rampley Jr, Jim F) Date: Tue, 29 Sep 2015 09:26:48 -0500 Subject: Prefix hijacking by AS20115 In-Reply-To: <560A0476.4030904@rollernet.us> References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <560A0476.4030904@rollernet.us> Message-ID: On 9/28/15, 10:24 PM, "NANOG on behalf of Seth Mattinen" wrote: >On 9/28/15 20:19, Martin Hannigan wrote: >> >>Is this related to 104.73.161.0/24? That's ours. :-) >> >>We'll take a look and get back to you. Thanks for caring! >> > > >Yep, that's one of the affected prefixes. > >~Seth Hi Seth, which market was this occurring? Was this already removed? I'm not seeing it this morning. I would like to figure out what went wrong here. We shouldn't be nailing up any static configuration to have caused a situation like this. From mark.tinka at seacom.mu Tue Sep 29 14:37:52 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 Sep 2015 16:37:52 +0200 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <560A0476.4030904@rollernet.us> Message-ID: <560AA240.7010504@seacom.mu> On 29/Sep/15 16:26, Rampley Jr, Jim F wrote: > > Hi Seth, which market was this occurring? Was this already removed? I'm > not seeing it this morning. I would like to figure out what went wrong > here. We shouldn't be nailing up any static configuration to have caused > a situation like this. You'd be surprised how often this happens, especially on the back of a conference rocking into a city/country and the local provider having minimal BGP experience. Once the conference is done, folk leave, and the provider forgets about things - which is not a problem since the conference would have come with its own IP address space. The issue goes unnoticed for 12x months when the conference is trying to route their usual block in some other city/country, and things just seem "strange". Someone remembers the previous year's event, calls up the previous provider, and finds out that the tech. who worked the activation has since left. It's not easy... Many other situations closer to home (i.e., paying customers) where things like this happen, especially if the customer has IP address space but does not do BGP (until they want to or leave to the competition). Blackholing operations that go wrong that folk forget about as well, not to mention other networks that cut themselves off by using public IP address space for their enterprise network. It's not easy at all... Mark. From sethm at rollernet.us Tue Sep 29 14:49:17 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 29 Sep 2015 07:49:17 -0700 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <560A0476.4030904@rollernet.us> Message-ID: <560AA4ED.5060200@rollernet.us> On 9/29/15 7:26 AM, Rampley Jr, Jim F wrote: > > > On 9/28/15, 10:24 PM, "NANOG on behalf of Seth Mattinen" > wrote: > >> On 9/28/15 20:19, Martin Hannigan wrote: >>> >>> Is this related to 104.73.161.0/24? That's ours. :-) >>> >>> We'll take a look and get back to you. Thanks for caring! >>> >> >> >> Yep, that's one of the affected prefixes. >> >> ~Seth > Hi Seth, which market was this occurring? Was this already removed? I'm > not seeing it this morning. I would like to figure out what went wrong > here. We shouldn't be nailing up any static configuration to have caused > a situation like this. > Reno, NV. I do believe they've finally withdrawn this morning (I just woke up, it was a long night). ~Seth From bob at FiberInternetCenter.com Tue Sep 29 15:05:45 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 29 Sep 2015 08:05:45 -0700 Subject: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <560A0476.4030904@rollernet.us> Message-ID: <2f9317cf1d7642af10200d1f0dc2374f.squirrel@66.201.44.180> Nice of you to check Jim. This brings up the old idea - A long time ago I had an INOC phone by PCH.NET - It never rang, as we filter our outbound with detail everywhere we announce. ISPs need to provide us their address list. And the few times I needed to use it , no one ever answered. ( It was a decade ago before NANOG membership.) So after a while I too ignored it. Maybe this was an idea ahead of it's time ? From this painful mishap, it could have been a great solution for NOC Engineers to help each. I find peeringdb often outdated as companies change around and sluggish return call if at all. Most are like a sales line number post. I see now a long list of registered networks in the PCH directory. Are networks actually paying attention and using it. Is it time to take another look ? At midnight in your organization could you get a NOC person with " proper BGP skills and access " to answer and care about a bad announcement ? https://inoc-dba-web.pch.net/inoc-dba/console.cgi?op=show_pubdir&list=org Link above shows lots more networks listed on the INOC-DBA Public Directory: Organizations But have you used it? Did it work for you when you needed it ? Any further comments are appreciated. This seems like a very good proper civil approach - maybe this or something like it ARIN might help promote and endorse as a benefit to the community ? Be nice if with the cash they did something simple like this and got all of us to use it? Special line forwarding ? A Emergency Only NOC App for our phones for just this kind of situation - one that registers a specific ASN and pin code we set on the registration page ? Thank You Bob Evans CTO > > > On 9/28/15, 10:24 PM, "NANOG on behalf of Seth Mattinen" > wrote: > >>On 9/28/15 20:19, Martin Hannigan wrote: >>> >>>Is this related to 104.73.161.0/24? That's ours. :-) >>> >>>We'll take a look and get back to you. Thanks for caring! >>> >> >> >>Yep, that's one of the affected prefixes. >> >>~Seth > Hi Seth, which market was this occurring? Was this already removed? I'm > not seeing it this morning. I would like to figure out what went wrong > here. We shouldn't be nailing up any static configuration to have caused > a situation like this. > > From job at instituut.net Tue Sep 29 15:12:43 2015 From: job at instituut.net (Job Snijders) Date: Tue, 29 Sep 2015 17:12:43 +0200 Subject: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115 In-Reply-To: <2f9317cf1d7642af10200d1f0dc2374f.squirrel@66.201.44.180> References: <2f9317cf1d7642af10200d1f0dc2374f.squirrel@66.201.44.180> Message-ID: <20150929151243.GQ90849@Vurt.local> Hi Bob, On Tue, Sep 29, 2015 at 08:05:45AM -0700, Bob Evans wrote: > This seems like a very good proper civil approach - maybe this or > something like it ARIN might help promote and endorse as a benefit to > the community ? Be nice if with the cash they did something simple > like this and got all of us to use it? Special line forwarding ? A > Emergency Only NOC App for our phones for just this kind of situation > - one that registers a specific ASN and pin code we set on the > registration page ? In this day and age people use IRC or Facebook to quickly get to a friend of a friend of a friend to get to a good contact. Get on with the times :-) Kind regards, Job From bob at FiberInternetCenter.com Tue Sep 29 15:16:38 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 29 Sep 2015 08:16:38 -0700 Subject: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115 In-Reply-To: <20150929151243.GQ90849@Vurt.local> References: <2f9317cf1d7642af10200d1f0dc2374f.squirrel@66.201.44.180> <20150929151243.GQ90849@Vurt.local> Message-ID: <15e5df4e79ad446cb8581c3245e1dd57.squirrel@66.201.44.180> A friend is not someone that allows their company to hijack your prefixes. A friend is one that can get it to stop. Dude - wake up and drink some coffee. Thank You Bob Evans CTO > Hi Bob, > > On Tue, Sep 29, 2015 at 08:05:45AM -0700, Bob Evans wrote: >> This seems like a very good proper civil approach - maybe this or >> something like it ARIN might help promote and endorse as a benefit to >> the community ? Be nice if with the cash they did something simple >> like this and got all of us to use it? Special line forwarding ? A >> Emergency Only NOC App for our phones for just this kind of situation >> - one that registers a specific ASN and pin code we set on the >> registration page ? > > In this day and age people use IRC or Facebook to quickly get to a > friend of a friend of a friend to get to a good contact. Get on with the > times :-) > > Kind regards, > > Job > From bob at FiberInternetCenter.com Tue Sep 29 15:18:50 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 29 Sep 2015 08:18:50 -0700 Subject: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115 In-Reply-To: <15e5df4e79ad446cb8581c3245e1dd57.squirrel@66.201.44.180> References: <2f9317cf1d7642af10200d1f0dc2374f.squirrel@66.201.44.180> <20150929151243.GQ90849@Vurt.local> <15e5df4e79ad446cb8581c3245e1dd57.squirrel@66.201.44.180> Message-ID: I have actually found this NANOG email to be more effective than a chat or mombook public service. We need something more private like that. Thank You Bob Evans CTO > A friend is not someone that allows their company to hijack your prefixes. > A friend is one that can get it to stop. Dude - wake up and drink some > coffee. > > Thank You > Bob Evans > CTO > > > > >> Hi Bob, >> >> On Tue, Sep 29, 2015 at 08:05:45AM -0700, Bob Evans wrote: >>> This seems like a very good proper civil approach - maybe this or >>> something like it ARIN might help promote and endorse as a benefit to >>> the community ? Be nice if with the cash they did something simple >>> like this and got all of us to use it? Special line forwarding ? A >>> Emergency Only NOC App for our phones for just this kind of situation >>> - one that registers a specific ASN and pin code we set on the >>> registration page ? >> >> In this day and age people use IRC or Facebook to quickly get to a >> friend of a friend of a friend to get to a good contact. Get on with the >> times :-) >> >> Kind regards, >> >> Job >> > > > From jim.rampley at charter.com Tue Sep 29 15:18:54 2015 From: jim.rampley at charter.com (Rampley Jr, Jim F) Date: Tue, 29 Sep 2015 10:18:54 -0500 Subject: Prefix hijacking by AS20115 In-Reply-To: <560AA4ED.5060200@rollernet.us> References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <560A0476.4030904@rollernet.us> <560AA4ED.5060200@rollernet.us> Message-ID: On 9/29/15, 9:49 AM, "Seth Mattinen" wrote: >On 9/29/15 7:26 AM, Rampley Jr, Jim F wrote: >> >> >> On 9/28/15, 10:24 PM, "NANOG on behalf of Seth Mattinen" >> wrote: >> >>> On 9/28/15 20:19, Martin Hannigan wrote: >>>> >>>> Is this related to 104.73.161.0/24? That's ours. :-) >>>> >>>> We'll take a look and get back to you. Thanks for caring! >>>> >>> >>> >>> Yep, that's one of the affected prefixes. >>> >>> ~Seth >> Hi Seth, which market was this occurring? Was this already removed? >>I'm >> not seeing it this morning. I would like to figure out what went wrong >> here. We shouldn't be nailing up any static configuration to have >>caused >> a situation like this. >> > > >Reno, NV. I do believe they've finally withdrawn this morning (I just >woke up, it was a long night). > >~Seth This issue was caused by a hung BGP process which was resolved last night. Nothing nefarious. No static configuration nailed up, no BGP highjacking purposely done. ;) From jra at baylink.com Tue Sep 29 15:19:57 2015 From: jra at baylink.com (Jay Ashworth) Date: Tue, 29 Sep 2015 11:19:57 -0400 (EDT) Subject: Do you have INOC-DBA set up? (was: Re: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115) In-Reply-To: <20150929151243.GQ90849@Vurt.local> Message-ID: <29404077.448.1443539997790.JavaMail.root@benjamin.baylink.com> I entirely disagree, Job. The idea of a private tieline network that is connected, by SIP, to a line appearance in the NOC of each AS, and no one else is on it, seems like a fine idea to me. And that was INOC-DBA's original goal, as I understand it: You're having a problem? It's coming from some specific AS? Pick up the phone, mash the red INOC line button, dial the AS number, and you're talking to their NOC. And that's *authenticated*: since it's low enough churn to set up by hand, it's authenticated by humans. Show of hands: who has it set up, correctly, right now? ----- Original Message ----- > From: "Job Snijders" > To: "Bob Evans" > Cc: nanog at nanog.org > Sent: Tuesday, September 29, 2015 11:12:43 AM > Subject: Re: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115 > Hi Bob, > > On Tue, Sep 29, 2015 at 08:05:45AM -0700, Bob Evans wrote: > > This seems like a very good proper civil approach - maybe this or > > something like it ARIN might help promote and endorse as a benefit > > to > > the community ? Be nice if with the cash they did something simple > > like this and got all of us to use it? Special line forwarding ? A > > Emergency Only NOC App for our phones for just this kind of > > situation > > - one that registers a specific ASN and pin code we set on the > > registration page ? > > In this day and age people use IRC or Facebook to quickly get to a > friend of a friend of a friend to get to a good contact. Get on with > the > times :-) > > Kind regards, > > Job -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From royce at techsolvency.com Tue Sep 29 15:31:54 2015 From: royce at techsolvency.com (Royce Williams) Date: Tue, 29 Sep 2015 07:31:54 -0800 Subject: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115 In-Reply-To: <20150929151243.GQ90849@Vurt.local> References: <2f9317cf1d7642af10200d1f0dc2374f.squirrel@66.201.44.180> <20150929151243.GQ90849@Vurt.local> Message-ID: On Tue, Sep 29, 2015 at 7:12 AM, Job Snijders wrote: > > Hi Bob, > > On Tue, Sep 29, 2015 at 08:05:45AM -0700, Bob Evans wrote: > > This seems like a very good proper civil approach - maybe this or > > something like it ARIN might help promote and endorse as a benefit to > > the community ? Be nice if with the cash they did something simple > > like this and got all of us to use it? Special line forwarding ? A > > Emergency Only NOC App for our phones for just this kind of situation > > - one that registers a specific ASN and pin code we set on the > > registration page ? > > In this day and age people use IRC or Facebook to quickly get to a > friend of a friend of a friend to get to a good contact. Get on with the > times :-) This seems lossy and unscriptable to me. There are maxint different flavors of $social, so it's not suitable for escalation, IMO. Also, many people opt out of half of them when they're not on the clock. And, many of them have "I don't know you so I'll bury your message" options, which makes being tickled by a stranger for emergency purposes hard. And their "APIs", so to speak, are constantly shifting. But we already have a reliable, widespread, high-SNR channel: this list. It's the place that people go when they can't get an answer any other way. Email works when many other things are broken. What if all NOCs used their NOC email distro/alias to subscribe, filter for posts containing their own ASes/admin-domains/prefixes, plus the string "problem|issue|etc", and flag them as higher priority. A junior NOCling could check it manually every couple of hours, and maybe a public web archive of the list, in case of filter failures. I would expect most NOCs worth their salt to be monitoring nanog anyway. Why not leverage it? A sibling list could be spun off -- nanog-panic-button? ;) -- if that would be preferable. Royce From nick at foobar.org Tue Sep 29 15:35:45 2015 From: nick at foobar.org (Nick Hilliard) Date: Tue, 29 Sep 2015 16:35:45 +0100 Subject: Do you have INOC-DBA set up? In-Reply-To: <29404077.448.1443539997790.JavaMail.root@benjamin.baylink.com> References: <29404077.448.1443539997790.JavaMail.root@benjamin.baylink.com> Message-ID: <560AAFD1.7070600@foobar.org> On 29/09/2015 16:19, Jay Ashworth wrote: > The idea of a private tieline network that is connected, by SIP, to a line > appearance in the NOC of each AS, and no one else is on it, seems like a > fine idea to me. it's a great idea: I had my inoc-dba phone connected and live for 15 years. I used it exactly once. Nick From sandy at tislabs.com Tue Sep 29 15:36:54 2015 From: sandy at tislabs.com (Sandra Murphy) Date: Tue, 29 Sep 2015 11:36:54 -0400 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> Message-ID: <9A3AB5DB-901B-4AD6-AB1E-8715B433D4FF@tislabs.com> On Sep 28, 2015, at 11:59 PM, Bob Evans wrote: > > Would be nice if our membership organization ARIN ( that we all pay to > keep us somewhat organized) had an ability to do something for you.... I > never looked into it...i don't know....maybe it does ? > No one else has said this, so? RPKI. Which ARIN does do. ?Sandy P.S. The following has numerous points of weirdness. about 104.73.161.0/24, RADB says: route: 104.73.161.0/24 descr: Proxy for Akamai (AS20940) and Roller Networks (AS11170) origin: AS20115 mnt-by: MAINT-CHTR-WD changed: tim.weber at charter.com 20150312 #20:32:27Z source: RADB route: 104.73.161.0/24 descr: Akamai Technologies origin: AS20940 mnt-by: AKAM1-RIPE-MNT changed: unread at ripe.net 20000101 source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** route: 104.64.0.0/10 descr: Akamai origin: AS35994 mnt-by: AKAM1-ALTDB-MNT changed: ablock at akamai.com 20140518 source: ALTDB -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hugo at slabnet.com Tue Sep 29 15:38:03 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 29 Sep 2015 08:38:03 -0700 Subject: Do you have INOC-DBA set up? (was: Re: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115) In-Reply-To: <29404077.448.1443539997790.JavaMail.root@benjamin.baylink.com> References: <20150929151243.GQ90849@Vurt.local> <29404077.448.1443539997790.JavaMail.root@benjamin.baylink.com> Message-ID: <20150929153803.GJ1518@bamboo.slabnet.com> On Tue 2015-Sep-29 11:19:57 -0400, Jay Ashworth wrote: : >Show of hands: who has it set up, correctly, right now? I had this in my to-do, and this thread poked me again to get on with it. Sadly, https://inoc-dba-web.pch.net/inoc-dba/console.cgi?op=new_account gives me: Account sign up is disabled. Please wait for the new system! :'( -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From niels=nanog at bakker.net Tue Sep 29 15:44:32 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 29 Sep 2015 17:44:32 +0200 Subject: Do you have INOC-DBA set up? (was: Re: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115) In-Reply-To: <29404077.448.1443539997790.JavaMail.root@benjamin.baylink.com> References: <20150929151243.GQ90849@Vurt.local> <29404077.448.1443539997790.JavaMail.root@benjamin.baylink.com> Message-ID: <20150929154432.GB3097@excession.tpb.net> * jra at baylink.com (Jay Ashworth) [Tue 29 Sep 2015, 17:31 CEST]: >The idea of a private tieline network that is connected, by SIP, to a line >appearance in the NOC of each AS, and no one else is on it, seems like a >fine idea to me. Until you take into account that SIP doesn't work through many firewalls, that people generally don't give a second thought to timezones, that network engineers generally dislike having to mess with voice systems, etc. etc. 2 out of 3 INOC-DBA calls I ever received were silent on their end (presumably) due to firewalls; the third call was a test. >And that was INOC-DBA's original goal, as I understand it: > >You're having a problem? It's coming from some specific AS? > >Pick up the phone, mash the red INOC line button, dial the AS >number, and you're talking to their NOC. > >And that's *authenticated*: since it's low enough churn to set up >by hand, it's authenticated by humans. In other words, it wasn't secure, it wouldn't scale and churn killed it. >Show of hands: who has it set up, correctly, right now? No. There is nothing I'd do after receiving a phone call that I wouldn't do via email anyway. -- Niels. From sethm at rollernet.us Tue Sep 29 15:51:01 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 29 Sep 2015 08:51:01 -0700 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <560A0476.4030904@rollernet.us> <560AA4ED.5060200@rollernet.us> Message-ID: <560AB365.9040805@rollernet.us> On 9/29/15 8:18 AM, Rampley Jr, Jim F wrote: > > This issue was caused by a hung BGP process which was resolved last night. > Nothing nefarious. No static configuration nailed up, no BGP highjacking > purposely done. ;) > Is there a Cisco bug ID? ~Seth From jra at baylink.com Tue Sep 29 16:09:37 2015 From: jra at baylink.com (Jay Ashworth) Date: Tue, 29 Sep 2015 12:09:37 -0400 (EDT) Subject: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115 In-Reply-To: Message-ID: <14509920.512.1443542976965.JavaMail.root@benjamin.baylink.com> Well, there *is* outages at outages.org... :-) ----- Original Message ----- > From: "Royce Williams" > To: nanog at nanog.org > Sent: Tuesday, September 29, 2015 11:31:54 AM > Subject: Re: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115 > On Tue, Sep 29, 2015 at 7:12 AM, Job Snijders > wrote: > > > > Hi Bob, > > > > On Tue, Sep 29, 2015 at 08:05:45AM -0700, Bob Evans wrote: > > > This seems like a very good proper civil approach - maybe this or > > > something like it ARIN might help promote and endorse as a benefit > > > to > > > the community ? Be nice if with the cash they did something simple > > > like this and got all of us to use it? Special line forwarding ? A > > > Emergency Only NOC App for our phones for just this kind of > > > situation > > > - one that registers a specific ASN and pin code we set on the > > > registration page ? > > > > In this day and age people use IRC or Facebook to quickly get to a > > friend of a friend of a friend to get to a good contact. Get on with > > the > > times :-) > > This seems lossy and unscriptable to me. There are maxint different > flavors of $social, so it's not suitable for escalation, IMO. Also, > many people opt out of half of them when they're not on the clock. > And, many of them have "I don't know you so I'll bury your message" > options, which makes being tickled by a stranger for emergency > purposes hard. And their "APIs", so to speak, are constantly > shifting. > > But we already have a reliable, widespread, high-SNR channel: this > list. It's the place that people go when they can't get an answer any > other way. Email works when many other things are broken. > > What if all NOCs used their NOC email distro/alias to subscribe, > filter for posts containing their own ASes/admin-domains/prefixes, > plus the string "problem|issue|etc", and flag them as higher priority. > A junior NOCling could check it manually every couple of hours, and > maybe a public web archive of the list, in case of filter failures. > > I would expect most NOCs worth their salt to be monitoring nanog > anyway. Why not leverage it? > > A sibling list could be spun off -- nanog-panic-button? ;) -- if that > would be preferable. > > Royce -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From bob at FiberInternetCenter.com Tue Sep 29 16:13:38 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 29 Sep 2015 09:13:38 -0700 Subject: Do you have INOC-DBA set up? (was: Re: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115) In-Reply-To: <20150929154432.GB3097@excession.tpb.net> References: <20150929151243.GQ90849@Vurt.local> <29404077.448.1443539997790.JavaMail.root@benjamin.baylink.com> <20150929154432.GB3097@excession.tpb.net> Message-ID: <7f154e926d4f653ab9c7c7d14a45a433.squirrel@66.201.44.180> Neils, do you actually work at in a NOC operation with BGP operations and policies you can change - a backbone with customers? If not - I would understand why email is fast enough for you. Maybe SIP iNOC phone isn't the right answer - but it seems to work fine everywhere I go. There just has to be a better way of communicating other than posting an email to a board - which isn't focused on a live network emergency. Something that's self filtered by all of us for a specific use. Say....An email/ text might work well or even better than SIP - if we had an APP that noticed a specific key or coded line plus your ASN to then ring my phone with an urgent ring tone.....hence, the idea of an NOC APP for that. Something other than "No I won't do anything different" - an idea or concept something you would embrace for such a moment. The iNOC phone wasn't embraced. Maybe a APP is a better idea than a phone. Thank You Bob Evans CTO > * jra at baylink.com (Jay Ashworth) [Tue 29 Sep 2015, 17:31 CEST]: >>The idea of a private tieline network that is connected, by SIP, to a >> line >>appearance in the NOC of each AS, and no one else is on it, seems like a >>fine idea to me. > > Until you take into account that SIP doesn't work through many > firewalls, that people generally don't give a second thought to > timezones, that network engineers generally dislike having to mess > with voice systems, etc. etc. > > 2 out of 3 INOC-DBA calls I ever received were silent on their end > (presumably) due to firewalls; the third call was a test. > > >>And that was INOC-DBA's original goal, as I understand it: >> >>You're having a problem? It's coming from some specific AS? >> >>Pick up the phone, mash the red INOC line button, dial the AS >>number, and you're talking to their NOC. >> >>And that's *authenticated*: since it's low enough churn to set up >>by hand, it's authenticated by humans. > > In other words, it wasn't secure, it wouldn't scale and churn killed it. > > >>Show of hands: who has it set up, correctly, right now? > > No. There is nothing I'd do after receiving a phone call that I > wouldn't do via email anyway. > > > -- Niels. > From matthew at walster.org Tue Sep 29 17:19:30 2015 From: matthew at walster.org (Matthew Walster) Date: Tue, 29 Sep 2015 18:19:30 +0100 Subject: Do you have INOC-DBA set up? (was: Re: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115) In-Reply-To: <7f154e926d4f653ab9c7c7d14a45a433.squirrel@66.201.44.180> References: <20150929151243.GQ90849@Vurt.local> <29404077.448.1443539997790.JavaMail.root@benjamin.baylink.com> <20150929154432.GB3097@excession.tpb.net> <7f154e926d4f653ab9c7c7d14a45a433.squirrel@66.201.44.180> Message-ID: On 29 September 2015 at 17:13, Bob Evans wrote: > Neils, do you actually work at in a NOC operation with BGP operations and > policies you can change - a backbone with customers? ?"lolz" as the kids say.? > Say....An email/ text might work well or even better than SIP - if we had > an APP that noticed a specific key or coded line plus your ASN to then > ring my phone with an urgent ring tone.....hence, the idea of an NOC APP > for that. > ?This isn't an iPhone developers conference, the answer is very rarely "there's an app for that". The chance of that being integrated with ISP phone systems is slim to none. Email works. When it doesn't IRC works. It has done for a decade, it will for the next decade. Yes, even when the 200 people post to Outages saying "XYZ is down for me, anyone else" or the far more annoying "can someone from XYZ contact me offlist" posts to NANOG. M? From digitallystoned at gmail.com Tue Sep 29 17:29:59 2015 From: digitallystoned at gmail.com (N M) Date: Tue, 29 Sep 2015 12:29:59 -0500 Subject: Prefix hijacking by AS20115 In-Reply-To: <560AB365.9040805@rollernet.us> References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <560A0476.4030904@rollernet.us> <560AA4ED.5060200@rollernet.us> <560AB365.9040805@rollernet.us> Message-ID: If this is anything like what I deal with the aging timer for the bgp session is set to 180s by default. After 2 years I've been unable to get the charter noc to enable bfd on my links to address this issue On Sep 29, 2015 10:59 AM, "Seth Mattinen" wrote: > On 9/29/15 8:18 AM, Rampley Jr, Jim F wrote: > > > >> This issue was caused by a hung BGP process which was resolved last night. >> Nothing nefarious. No static configuration nailed up, no BGP >> highjacking >> purposely done. ;) >> >> > > Is there a Cisco bug ID? > > ~Seth > From morrowc.lists at gmail.com Tue Sep 29 17:53:19 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 29 Sep 2015 13:53:19 -0400 Subject: Prefix hijacking by AS20115 In-Reply-To: References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <560A0476.4030904@rollernet.us> <560AA4ED.5060200@rollernet.us> <560AB365.9040805@rollernet.us> Message-ID: On Tue, Sep 29, 2015 at 1:29 PM, N M wrote: > If this is anything like what I deal with the aging timer for the bgp > session is set to 180s by default. After 2 years I've been unable to get > the charter noc to enable bfd on my links to address this issue because bfd brings it's own special sort of pain... From aaron at wholesaleinternet.net Tue Sep 29 19:35:56 2015 From: aaron at wholesaleinternet.net (Aaron) Date: Tue, 29 Sep 2015 14:35:56 -0500 Subject: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115 In-Reply-To: <2f9317cf1d7642af10200d1f0dc2374f.squirrel@66.201.44.180> References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <560A0476.4030904@rollernet.us> <2f9317cf1d7642af10200d1f0dc2374f.squirrel@66.201.44.180> Message-ID: <560AE81C.4060100@wholesaleinternet.net> We have a big, red rotary phone that sits in our NOC that we have attached to a VoIP box just to use for that. :) On 9/29/2015 10:05 AM, Bob Evans wrote: > Nice of you to check Jim. This brings up the old idea - A long time ago I > had an INOC phone by PCH.NET - It never rang, as we filter our outbound > with detail everywhere we announce. ISPs need to provide us their address > list. > > And the few times I needed to use it , no one ever answered. ( It was a > decade ago before NANOG membership.) So after a while I too ignored it. > Maybe this was an idea ahead of it's time ? From this painful mishap, it > could have been a great solution for NOC Engineers to help each. I find > peeringdb often outdated as companies change around and sluggish return > call if at all. Most are like a sales line number post. > > I see now a long list of registered networks in the PCH directory. Are > networks actually paying attention and using it. Is it time to take > another look ? At midnight in your organization could you get a NOC > person with " proper BGP skills and access " to answer and care about a > bad announcement ? > > https://inoc-dba-web.pch.net/inoc-dba/console.cgi?op=show_pubdir&list=org > Link above shows lots more networks listed on the > INOC-DBA Public Directory: Organizations > > But have you used it? Did it work for you when you needed it ? > Any further comments are appreciated. > > This seems like a very good proper civil approach - maybe this or > something like it ARIN might help promote and endorse as a benefit to the > community ? Be nice if with the cash they did something simple like this > and got all of us to use it? Special line forwarding ? A Emergency Only > NOC App for our phones for just this kind of situation - one that > registers a specific ASN and pin code we set on the registration page ? > > Thank You > Bob Evans > CTO > > > > >> >> On 9/28/15, 10:24 PM, "NANOG on behalf of Seth Mattinen" >> wrote: >> >>> On 9/28/15 20:19, Martin Hannigan wrote: >>>> Is this related to 104.73.161.0/24? That's ours. :-) >>>> >>>> We'll take a look and get back to you. Thanks for caring! >>>> >>> >>> Yep, that's one of the affected prefixes. >>> >>> ~Seth >> Hi Seth, which market was this occurring? Was this already removed? I'm >> not seeing it this morning. I would like to figure out what went wrong >> here. We shouldn't be nailing up any static configuration to have caused >> a situation like this. >> >> > > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From paveldimow at gmail.com Tue Sep 29 20:20:19 2015 From: paveldimow at gmail.com (Pavel Dimow) Date: Tue, 29 Sep 2015 22:20:19 +0200 Subject: SNMP - monitoring large number of devices Message-ID: Hi all, recently I have been tasked with a NMS project. The idea is to pool about 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a one million OID's). Before you say check out some very professional and expensive solutions I would like to know are there any alternatives like open source "snmp framework"? To be more descriptive many of you knows how big is the mess with snmp on cable modem. You always first perform snmp walk in order to discover interfaces and then read the values for those interfaces. As cable modem can bundle more DS channels, one time you can have one and other time you can have N+1 DS channels = interfaces. All in all I don't believe that there is something perfect out there when it comes to tracking huge number of cable modems so I would like to know is there any "snmp framework" that can be exteded and how did you (or would you) solve this problem. Thank you. From khelms at zcorum.com Tue Sep 29 20:26:06 2015 From: khelms at zcorum.com (Scott Helms) Date: Tue, 29 Sep 2015 16:26:06 -0400 Subject: SNMP - monitoring large number of devices In-Reply-To: References: Message-ID: Pavel, AFAIK there are no frameworks that solve, or even come close to solving, this problem. The first thing to learn is how to do asynchronous SNMP calls that will let you send out requests without having to wait for the response. How you do those will vary by the language that you're using. Next, figure out to scale the processing and persisting of the returns and try and learn (without causing an impact) how many simultaneous SNMP requests your CMTSs will deal with while at the same time handling their normal load from customer traffic. BULKGETS are very handy, but they will also cause problems because some platforms limit the max size of the SNMP return. >From my experience building your server side programming to do 50,000 modems in <5 minutes is very doable, but unless your dealing with more than 10 CMTSs you probably can't do it in production without impacting performance. Cisco 10Ks still have absolute caps on the amount of SNMP they will allow and other manufacturers and models do different things that limit what you can do. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Sep 29, 2015 at 4:20 PM, Pavel Dimow wrote: > Hi all, > > recently I have been tasked with a NMS project. The idea is to pool about > 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a > one million OID's). Before you say check out some very professional and > expensive solutions I would like to know are there any alternatives like > open source "snmp framework"? To be more descriptive many of you knows how > big is the mess with snmp on cable modem. You always first perform snmp > walk in order to discover interfaces and then read the values for those > interfaces. As cable modem can bundle more DS channels, one time you can > have one and other time you can have N+1 DS channels = interfaces. All in > all I don't believe that there is something perfect out there when it comes > to tracking huge number of cable modems so I would like to know is there > any "snmp framework" that can be exteded and how did you (or would you) > solve this problem. > > Thank you. > From jared at puck.nether.net Tue Sep 29 20:31:26 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 29 Sep 2015 16:31:26 -0400 Subject: SNMP - monitoring large number of devices In-Reply-To: References: Message-ID: <4C5946D6-AB08-41BD-9DA0-04E472B15093@puck.nether.net> We built our own system for this purpose and just spawn one process per device being polled. This seems to work out OK and many cores can make this work out. You can also just split the workload horizontally across multiple servers. The challenges are as usual how to report from a dataset like that. Many systems exist to distribute workload across the servers. Custom poller is really the way to go here IMHO. It?s not that hard but requires investment to build it and operate it. - Jared > On Sep 29, 2015, at 4:20 PM, Pavel Dimow wrote: > > Hi all, > > recently I have been tasked with a NMS project. The idea is to pool about > 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a > one million OID's). Before you say check out some very professional and > expensive solutions I would like to know are there any alternatives like > open source "snmp framework"? To be more descriptive many of you knows how > big is the mess with snmp on cable modem. You always first perform snmp > walk in order to discover interfaces and then read the values for those > interfaces. As cable modem can bundle more DS channels, one time you can > have one and other time you can have N+1 DS channels = interfaces. All in > all I don't believe that there is something perfect out there when it comes > to tracking huge number of cable modems so I would like to know is there > any "snmp framework" that can be exteded and how did you (or would you) > solve this problem. > > Thank you. From Daniel.Jameson at tdstelecom.com Tue Sep 29 20:32:44 2015 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Tue, 29 Sep 2015 20:32:44 +0000 Subject: SNMP - monitoring large number of devices In-Reply-To: References: Message-ID: Zabbix is probably one of the more robust snmp platform, it's database backed by either postgres, mysql or oracle and scales pretty big. If this is more than a one-time event, you'll need some real horsepower and HDD space to keep all that data. It might be worth writing a custom ruby/python/perl application on a platform that allows a clean fork just prior to the SNMP call it'll allow you to remain in the wait-state for that one snmp thread without blocking the next request, and let you manage the workload of the server by controlling the number of simultaneous forks. -----Original Message----- From: NANOG [mailto:nanog-bounces+daniel.jameson=tdstelecom.com at nanog.org] On Behalf Of Pavel Dimow Sent: Tuesday, September 29, 2015 3:20 PM To: NANOG Subject: SNMP - monitoring large number of devices Hi all, recently I have been tasked with a NMS project. The idea is to pool about 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a one million OID's). Before you say check out some very professional and expensive solutions I would like to know are there any alternatives like open source "snmp framework"? To be more descriptive many of you knows how big is the mess with snmp on cable modem. You always first perform snmp walk in order to discover interfaces and then read the values for those interfaces. As cable modem can bundle more DS channels, one time you can have one and other time you can have N+1 DS channels = interfaces. All in all I don't believe that there is something perfect out there when it comes to tracking huge number of cable modems so I would like to know is there any "snmp framework" that can be exteded and how did you (or would you) solve this problem. Thank you. From dhubbard at dino.hostasaurus.com Tue Sep 29 20:37:19 2015 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 29 Sep 2015 16:37:19 -0400 Subject: How to force rapid ipv6 adoption Message-ID: Had an idea the other day; we just need someone with a lot of cash (google, apple, etc) to buy Netflix and then make all new releases v6-only for the first 48 hours. I bet my lame Brighthouse and Fios service would be v6-enabled before the end of the following week lol. David From dwhite at olp.net Tue Sep 29 20:37:51 2015 From: dwhite at olp.net (Dan White) Date: Tue, 29 Sep 2015 15:37:51 -0500 Subject: SNMP - monitoring large number of devices In-Reply-To: References: Message-ID: <20150929203751.GH3551@dan.olp.net> On 09/29/15?22:20?+0200, Pavel Dimow wrote: >recently I have been tasked with a NMS project. The idea is to pool about >20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a >one million OID's). Before you say check out some very professional and >expensive solutions I would like to know are there any alternatives like >open source "snmp framework"? To be more descriptive many of you knows how >big is the mess with snmp on cable modem. You always first perform snmp >walk in order to discover interfaces and then read the values for those >interfaces. As cable modem can bundle more DS channels, one time you can >have one and other time you can have N+1 DS channels = interfaces. All in >all I don't believe that there is something perfect out there when it comes >to tracking huge number of cable modems so I would like to know is there >any "snmp framework" that can be exteded and how did you (or would you) >solve this problem. I've done about ~60,000 OID queries (over a few dozen devices) per 5 minutes using OpenNMS, which is Java based. At the scale you're looking at, disk I/O would be a major performance issue (if using rrdtool). Google for 'Tuning RRD' for some tips that can make a significant difference. -- Dan White From cb.list6 at gmail.com Tue Sep 29 20:48:35 2015 From: cb.list6 at gmail.com (Ca By) Date: Tue, 29 Sep 2015 13:48:35 -0700 Subject: How to force rapid ipv6 adoption In-Reply-To: References: Message-ID: On Tue, Sep 29, 2015 at 1:37 PM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Had an idea the other day; we just need someone with a lot of cash > (google, apple, etc) to buy Netflix and then make all new releases > v6-only for the first 48 hours. I bet my lame Brighthouse and Fios > service would be v6-enabled before the end of the following week lol. > > David > Yeah, i am sure VZ is going to cry a river that you cannot reach Netflix We already slowed down IPv4 by 10-15%*, i think we can crank it down another 10-20% to punish the Luddites (AWS, Azure, Twitter, Bing, ...) CB * https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board-/ From pete at fiberphone.co.nz Tue Sep 29 20:50:05 2015 From: pete at fiberphone.co.nz (Pete Mundy) Date: Wed, 30 Sep 2015 09:50:05 +1300 Subject: Do you have INOC-DBA set up? (was: Re: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115) In-Reply-To: References: <20150929151243.GQ90849@Vurt.local> <29404077.448.1443539997790.JavaMail.root@benjamin.baylink.com> <20150929154432.GB3097@excession.tpb.net> <7f154e926d4f653ab9c7c7d14a45a433.squirrel@66.201.44.180> Message-ID: <624F2BFE-F3C1-48F2-A6A7-13786D5C4881@fiberphone.co.nz> On 30/09/2015, at 6:19 AM, Matthew Walster wrote: > ?"lolz" as the kids say.? Current stats indicate it's actually only the old-timers that say lolz now days! ;) http://www.huffingtonpost.com/entry/facebook-study-laughter_55c8b148e4b0f1cbf1e5857e Pete From bill at herrin.us Tue Sep 29 20:55:13 2015 From: bill at herrin.us (William Herrin) Date: Tue, 29 Sep 2015 16:55:13 -0400 Subject: SNMP - monitoring large number of devices In-Reply-To: References: Message-ID: On Tue, Sep 29, 2015 at 4:20 PM, Pavel Dimow wrote: > recently I have been tasked with a NMS project. The idea is to pool about > 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a > one million OID's). [...] You always first perform snmp > walk in order to discover interfaces and then read the values for those > interfaces. Hi Pavel, NMS is ever a trade off between collecting the data you need to manage your system and minimizing the impact collection has on the equipment being monitored. You propose to spend somewhere between 2mbps and 10mbps on SNMP queries alone 24/7/365 and then do something with the 10ish terabytes per year of collected data This is less a network monitoring problem and more a big-data map-reduce problem. Doable, although you'll likely have to break the problem up in to a lot of parallel VMs. You'll need a software developer with big data experience. So far as I know there is no off-the-shelf software (commercial or open source) kitted out to facilitate this specific activity. 95% of the software modules needed to create such a thing is available as open source. Frankly, it's probably also not a good idea. Lengthen your intervals, don't collect every piece of information every interval and figure out a way that you don't have to walk the oids every single time. On Tue, Sep 29, 2015 at 4:26 PM, Scott Helms wrote: > From my experience building your server side programming to do 50,000 > modems in <5 minutes is very doable, but unless your dealing with more than > 10 CMTSs you probably can't do it in production without impacting > performance. >From Pavel's question, I infer that he's talking about polling the CPE. He can forget about driving that number of SNMP queries at the CMTS's, regardless of how many he has. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From josh at imaginenetworksllc.com Tue Sep 29 20:55:42 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 29 Sep 2015 16:55:42 -0400 Subject: How to force rapid ipv6 adoption In-Reply-To: References: Message-ID: I think he means new releases are v6 for the first 48 hours...then trickle to v4. Which means that people wanting to see that new release urgently would have to wait two days. Netflix is definitely not the service to do that. Hulu, Amazon or HBO GO maybe. Netflix content tends to be pretty old (apart from their own content, of course). Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Sep 29, 2015 at 4:48 PM, Ca By wrote: > On Tue, Sep 29, 2015 at 1:37 PM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > > > Had an idea the other day; we just need someone with a lot of cash > > (google, apple, etc) to buy Netflix and then make all new releases > > v6-only for the first 48 hours. I bet my lame Brighthouse and Fios > > service would be v6-enabled before the end of the following week lol. > > > > David > > > > Yeah, i am sure VZ is going to cry a river that you cannot reach Netflix > > We already slowed down IPv4 by 10-15%*, i think we can crank it down > another 10-20% to punish the Luddites (AWS, Azure, Twitter, Bing, ...) > > CB > * > > https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board-/ > From dwcarder at wisc.edu Tue Sep 29 21:03:18 2015 From: dwcarder at wisc.edu (Dale W. Carder) Date: Tue, 29 Sep 2015 16:03:18 -0500 Subject: SNMP - monitoring large number of devices In-Reply-To: <20150929203751.GH3551@dan.olp.net> References: <20150929203751.GH3551@dan.olp.net> Message-ID: <20150929210318.GC13869@DOIT-2NW1MRFY-X.doit.wisc.edu> Thus spake Dan White (dwhite at olp.net) on Tue, Sep 29, 2015 at 03:37:51PM -0500: > On 09/29/15?22:20?+0200, Pavel Dimow wrote: > >recently I have been tasked with a NMS project. The idea is to pool about > >20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a > >one million OID's). Before you say check out some very professional and > >expensive solutions I would like to know are there any alternatives like > >open source "snmp framework"? To be more descriptive many of you knows how > >big is the mess with snmp on cable modem. You always first perform snmp > >walk in order to discover interfaces and then read the values for those > >interfaces. As cable modem can bundle more DS channels, one time you can > >have one and other time you can have N+1 DS channels = interfaces. All in > >all I don't believe that there is something perfect out there when it comes > >to tracking huge number of cable modems so I would like to know is there > >any "snmp framework" that can be exteded and how did you (or would you) > >solve this problem. > > I've done about ~60,000 OID queries (over a few dozen devices) per 5 > minutes using OpenNMS, which is Java based. At the scale you're looking at, > disk I/O would be a major performance issue (if using rrdtool). Google for > 'Tuning RRD' for some tips that can make a significant difference. These days all you need is SSD. We have about 800,000 active rrd files (in MRTG, for that matter) on one old server. Otherwise the various techniques we proposed in 2007 are now largely implemented, particularly rrdcached beginning in version 1.4. https://www.usenix.org/legacy/event/lisa07/tech/full_papers/plonka/plonka_html/index.html Dale From nellermann at broadaspect.com Tue Sep 29 21:39:16 2015 From: nellermann at broadaspect.com (Nick Ellermann) Date: Tue, 29 Sep 2015 21:39:16 +0000 Subject: SNMP - monitoring large number of devices In-Reply-To: References: Message-ID: <3c4596b8a45b4b62a035c3c88fe1abcc@exchange.broadaspect.local> Pavel, It's all going to be how you deploy a selected polling system. Most server operating systems are going to struggle with that many transactions in a short period of time no matter the awesomeness of the polling engine. Look for a distributed polling solution. If you can spread the connection load out a bit it may be less of an issue. The worst issue will be populating your solution with that many devices and sensors to go check, look for api or import tool! What do you think the network latency between your polling location or locations to all of the cable modems? Do they respond pretty well with SNMP queries? We use PRTG and its very efficient with SNMP. One of the most efficient SNMP polling engines I have used. My quick math and experience tells me that with a PRTG core server and two or three remote PRTG probes (hardware based) you should be able to hit 6,000 snmp polls a min from each probe. PRTG will automatically attempt a multi get. Go with three probes to be safe and I think you could hit over 50,000 with buffer room. Easy platform, inexpensive compared to other licensed NMS systems. Free trial with unlimited sensors on their website. But their software engineering staff will state that this project would be stretching the design of the system and its focus. Would love to hear what you figure out works best! Sincerely, Nick Ellermann ? CTO & VP Cloud Services BroadAspect ? E: nellermann at broadaspect.com P: 703-297-4639 F: 703-996-4443 ? THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: NANOG [mailto:nanog-bounces+nellermann=broadaspect.com at nanog.org] On Behalf Of Pavel Dimow Sent: Tuesday, September 29, 2015 4:20 PM To: NANOG Subject: SNMP - monitoring large number of devices Hi all, recently I have been tasked with a NMS project. The idea is to pool about 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a one million OID's). Before you say check out some very professional and expensive solutions I would like to know are there any alternatives like open source "snmp framework"? To be more descriptive many of you knows how big is the mess with snmp on cable modem. You always first perform snmp walk in order to discover interfaces and then read the values for those interfaces. As cable modem can bundle more DS channels, one time you can have one and other time you can have N+1 DS channels = interfaces. All in all I don't believe that there is something perfect out there when it comes to tracking huge number of cable modems so I would like to know is there any "snmp framework" that can be exteded and how did you (or would you) solve this problem. Thank you. From blake at ispn.net Tue Sep 29 21:43:48 2015 From: blake at ispn.net (Blake Hudson) Date: Tue, 29 Sep 2015 16:43:48 -0500 Subject: SNMP - monitoring large number of devices In-Reply-To: References: Message-ID: <560B0614.8080007@ispn.net> I'm able to poll a few thousand CMs in a few seconds using perl's Net::SNMP and async calls. 50k seems pretty doable. --Blake Pavel Dimow wrote on 9/29/2015 3:20 PM: > Hi all, > > recently I have been tasked with a NMS project. The idea is to pool about > 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a > one million OID's). Before you say check out some very professional and > expensive solutions I would like to know are there any alternatives like > open source "snmp framework"? To be more descriptive many of you knows how > big is the mess with snmp on cable modem. You always first perform snmp > walk in order to discover interfaces and then read the values for those > interfaces. As cable modem can bundle more DS channels, one time you can > have one and other time you can have N+1 DS channels = interfaces. All in > all I don't believe that there is something perfect out there when it comes > to tracking huge number of cable modems so I would like to know is there > any "snmp framework" that can be exteded and how did you (or would you) > solve this problem. > > Thank you. From bzeeb-lists at lists.zabbadoz.net Tue Sep 29 21:45:32 2015 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue, 29 Sep 2015 21:45:32 +0000 Subject: How to force rapid ipv6 adoption In-Reply-To: References: Message-ID: > On 29 Sep 2015, at 20:48 , Ca By wrote: > > On Tue, Sep 29, 2015 at 1:37 PM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > >> Had an idea the other day; we just need someone with a lot of cash >> (google, apple, etc) to buy Netflix and then make all new releases >> v6-only for the first 48 hours. I bet my lame Brighthouse and Fios >> service would be v6-enabled before the end of the following week lol. >> >> David >> > > Yeah, i am sure VZ is going to cry a river that you cannot reach Netflix > > We already slowed down IPv4 by 10-15%*, i think we can crank it down > another 10-20% to punish the Luddites (AWS, Azure, Twitter, Bing, ...) > > CB > * > https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board-/ Well the good news is that Netflix does IPv6 for video content streaming, the bad news is that the IPv4 ?slow down? (aka baseline) won?t make the video content go slower ;-) And yes, I guess, if we could make AWS more IPv6-ish then Netflix v6only might actually become possible for people who want to. /bz From toddunder at gmail.com Tue Sep 29 23:19:20 2015 From: toddunder at gmail.com (Todd Underwood) Date: Tue, 29 Sep 2015 19:19:20 -0400 Subject: How to force rapid ipv6 adoption In-Reply-To: References: Message-ID: another good idea is to design a migration path to ipv6 so that people using hte internet can also use the ipv6-internet. that would be cool. we should probably think about some migration path other than the pretty obviously implausible "dual stack" silliness before this stuff actually becomes a necessity, otherwise lots of people will end up spinning their wheels trying to figure out how to "convince people" to use a non-internet-connected protocol rather than just keeping on using ipv4. i'll bet some smart people are already on that problem, though. keep me posted! :-) t On Tue, Sep 29, 2015 at 4:37 PM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Had an idea the other day; we just need someone with a lot of cash > (google, apple, etc) to buy Netflix and then make all new releases > v6-only for the first 48 hours. I bet my lame Brighthouse and Fios > service would be v6-enabled before the end of the following week lol. > > David > From Daniel.Jameson at tdstelecom.com Tue Sep 29 23:24:47 2015 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Tue, 29 Sep 2015 23:24:47 +0000 Subject: SNMP - monitoring large number of devices In-Reply-To: <560B0614.8080007@ispn.net> References: <560B0614.8080007@ispn.net> Message-ID: @op, Can you expand a little on the end goal, health, noise mitigation, nms replacement, modem validation? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Blake Hudson Sent: Tuesday, September 29, 2015 4:44 PM To: nanog at nanog.org Subject: Re: SNMP - monitoring large number of devices I'm able to poll a few thousand CMs in a few seconds using perl's Net::SNMP and async calls. 50k seems pretty doable. --Blake Pavel Dimow wrote on 9/29/2015 3:20 PM: > Hi all, > > recently I have been tasked with a NMS project. The idea is to pool > about > 20 OID's from 50k cable modems in less then 5 minutes (yes, I know > it's a one million OID's). Before you say check out some very > professional and expensive solutions I would like to know are there > any alternatives like open source "snmp framework"? To be more > descriptive many of you knows how big is the mess with snmp on cable > modem. You always first perform snmp walk in order to discover > interfaces and then read the values for those interfaces. As cable > modem can bundle more DS channels, one time you can have one and other > time you can have N+1 DS channels = interfaces. All in all I don't > believe that there is something perfect out there when it comes to > tracking huge number of cable modems so I would like to know is there > any "snmp framework" that can be exteded and how did you (or would you) solve this problem. > > Thank you. From bgreene at senki.org Tue Sep 29 23:44:22 2015 From: bgreene at senki.org (Barry Greene) Date: Wed, 30 Sep 2015 07:44:22 +0800 Subject: Security release scheduling In-Reply-To: <560A445F.1040605@nwtime.org> References: <560A13E6.7060509@nwtime.org> <157CF300-F751-4798-A82A-88B69C5CE15C@senki.org> <560A445F.1040605@nwtime.org> Message-ID: <1A8A16F6-E34A-4D2A-B6E6-9FF104D053D4@senki.org> > On Sep 29, 2015, at 3:57 PM, Harlan Stenn wrote: > > Good info, Barry - thanks! > > I appreciate your offer, too! Here is a brain dump: https://www.linkedin.com/pulse/5-principles-vulnerability-disclosure-barry-greene For the people who are not vendors on the list, the post has some good questions to ask your vendors about their vulnerability disclosure processes. From rdrake at direcpath.com Wed Sep 30 03:01:22 2015 From: rdrake at direcpath.com (Robert Drake) Date: Tue, 29 Sep 2015 23:01:22 -0400 Subject: SNMP - monitoring large number of devices In-Reply-To: References: Message-ID: <560B5082.3010606@direcpath.com> OpenNMS has a poller that will do what you want. The problem is figuring out what you wish to collect and how to use it. Most of the time it's not as simple as pointing at the modem and saying go. I've added a few oids for some of the modems we support, just so I can get SNR on them. I don't usually add customer modems directly to monitoring unless I'm tracking a long term problem and want to watch the SNR for that customer for weeks. I monitor our CMTS' with a threshold system that says if number of active modems decreases by around 20 then alert. This can cause false positives with modems migrating between cards, but if you tweak the numbers right it works okay. We also have graphs for signal and other things on each CMTS. Now that I'm thinking about it, I believe I could get away with adding all our modems for SNR, then try to write something to add/remove them and keep it in sync with our provisioning system. I would need to make sure everything was in order so I don't get 400 emails when a site goes down, but it all should be possible. I'm not sure if the I/O would be worth it, but being able to aggregate some of the data and look at SNR across an entire plant would be nice. At one point I had a project to put modems at the tail end of each leg of a plant then monitor them. This is because we don't have monitor-able amplifiers. It never happened though. The truth is that balancing a plant is easy enough once you're used to it, and the extra metrics you might get from doing some of these things isn't worth the long term I/O. We do have other (non-NMS) systems that will poll and get instantaneous results like this for entire plants. That has been very useful. My guess is no matter what system you pick, you will either need to spend a couple of weeks hacking on it or pay someone to implement it. There isn't a turnkey system that does exactly what you want because 99% of network monitoring companies target systems rather than networks (the market is much larger..). If you want to roll your own: https://github.com/tobez/snmp-query-engine I recently discovered this and wanted it years ago. I actually considered stripping the poller out of OpenNMS so there would be a bare-bones poller you could send oids to and get back results. The reason being that almost everyone who does SNMP does a bad job of it and is slow. So, don't start at the library layer and don't write your own thing (unless you have to..). You need asynchronous communication, bulk and gettable support, and you don't want to worry about max PDU size. That's what snmp-query-engine does (maybe.. I've just looked at the tin, I haven't used it) Second note about rolling your own: Skip whisper, rrdtool, mrtg, and any other single-system datacollection. You want 1 million oids or more in 5 minutes? You need SSD for hardware and will probably want to distribute data writes eventually. Research things that make this easier. Cassandra based storage... but nothing good is fully formed. You should still probably begin with OpenTSDB, InfluxDB or another established time series database rather than rolling your own. They have warts but fixing the warts is better than creating new one-use TSDB's with their own flaws. See https://github.com/OpenNMS/newts/wiki/Comparison-of-TSDB On 9/29/2015 4:20 PM, Pavel Dimow wrote: > Hi all, > > recently I have been tasked with a NMS project. The idea is to pool about > 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a > one million OID's). Before you say check out some very professional and > expensive solutions I would like to know are there any alternatives like > open source "snmp framework"? To be more descriptive many of you knows how > big is the mess with snmp on cable modem. You always first perform snmp > walk in order to discover interfaces and then read the values for those > interfaces. As cable modem can bundle more DS channels, one time you can > have one and other time you can have N+1 DS channels = interfaces. All in > all I don't believe that there is something perfect out there when it comes > to tracking huge number of cable modems so I would like to know is there > any "snmp framework" that can be exteded and how did you (or would you) > solve this problem. > > Thank you. > From stetson.blake at datayard.us Tue Sep 29 15:06:59 2015 From: stetson.blake at datayard.us (Stetson Blake) Date: Tue, 29 Sep 2015 15:06:59 +0000 Subject: T1 Availability in Indianapolis Message-ID: <1076bfc4c5e14727b8845323bfde6d9f@exc01.datayard.local> Hey all, I am wondering if anyone has a contact for T1 availability, CLEC or otherwise. I am looking specifically around: Dividend Drive Indianapolis, IN 46241 Please contact me off list Thanks, ? Stetson Blake Network Administrator Voice: (937) 610-3514 Toll-Free: (800) 982-4539 ext. 3514 DataYard 130 West Second St. Suite 250 Dayton, OH 45402 http://datayardworks.com From jtodd at pch.net Tue Sep 29 22:09:30 2015 From: jtodd at pch.net (John Todd) Date: Tue, 29 Sep 2015 15:09:30 -0700 Subject: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115 In-Reply-To: <2f9317cf1d7642af10200d1f0dc2374f.squirrel@66.201.44.180> References: <5609E2F3.9030407@rollernet.us> <560A00BF.4020209@rollernet.us> <560A0476.4030904@rollernet.us> <2f9317cf1d7642af10200d1f0dc2374f.squirrel@66.201.44.180> Message-ID: Since it?s come up on the list and we haven?t given a public update recently, I thought I?d just write a quick note on the state of INOC-DBA. For those who aren?t familiar with it, INOC-DBA is a SIP-based hotline communications system between NOCs and CERTs: https://www.pch.net/services/INOC_DBA https://en.wikipedia.org/wiki/INOC-DBA PCH has been the secretariat for INOC-DBA for the past thirteen years as a function of our not-for-profit purpose, serving network operators. During that time, the INOC-DBA back-end and self-provisioning systems have been completely replaced three times, and we?re currently at work on moving from the SER-driven 3.0 series of releases to a more modern BE7k-driven 4.0 system. Because INOC-DBA has only been intermittently directly grant-funded, sometimes, like now, it is funded entirely out of our overhead budget, so progress can be slow. The consequence is that, in order to make headway on the 4.0 transition, we?ve had to move people off of active support of the old 3.0 self-provisioning system. So, it?s fine for people who are already using it, but there?s not currently a way to create a new user within the 3.0 system, nor for existing users to make significant changes to call routing. ASNs have proven to be a good identifier, allowing network operators to communicate with each other in a way that?s vetted, while avoiding putting PCH in the position of judging who qualifies to join and who doesn't. Whether you know the name of a network, or where it?s located, or even what timezone they?re in, you know them by their ASN. And a hotline system that bypasses directories and receptionists and escalation chains is a quick and low-friction way of reaching someone who has the authority and access to resolve a problem. While email is the most venerable and well-known communication method it is often filtered, missed, or funneled through helpdesks that don?t have sufficient clue, or are stymied by dealing with someone who isn?t one of their own customers. Facebook and general-purpose chat systems are less than ideal as well, as they?re un-vetted and quickly suffer the same fate as email: if they?re paid attention to at all, filters or automated systems are put in place to block the noise. So, a closed network for voice, video, presence and chat has proven to be an immediate, low-noise way for those network operators who choose to use it, to communicate with each other. In the 4.0 system, XMPP chat using the same identifiers in the same closed network is a natural extension and the new feature that, though hardly revolutionary, we?re most looking forward to releasing. The technical issues that were discussed in this thread about NAT/PAT problems are certainly valid, but can be circumvented in a number of different ways, some of which are addressed in our documentation. SIP and RTP can work through NAT if correctly configured in simple circumstances, or in the presence of a NAT-traversal server, such as is included in INOC-DBA. An organization may have multiple INOC-DBA users and opt to have a SIP-capable system at the border of their network with one side facing the public Internet, and one side facing their private network, and which manages call flow and media handling (Asterisk, Freeswitch, or any one of a number of free or commercial SIP PBX-like systems will do this fairly easily; again, there are tutorials in our documentation). This also allows after-hours routing to PSTN lines or to call groups as needed, controlled by a local administrator. We also have considered keeping the media path through our servers, which aids the NAT traversal issue while not precluding local SIP enclaves as described above. One of the things that we struggle with is maintaining an appropriate balance between, on the one hand, keeping the network operations community informed of the status of the system, so they don?t feel compelled to ask on NANOG, versus not pro-actively over-sharing on lists and making a nuisance of ourselves. Admittedly, if the 4.0 transition were going faster, this would be less of an issue. So, we?re glad of the continued interest (particularly in the NANOG community, where INOC-DBA is not as widely used as in, for instance, the LACNIC community), and we apologize for the slow transition to the new 4.0 back-end and self-provisioning system. As always, you can contact us directly about INOC-DBA related stuff on operator at pch.net JT --- John Todd - jtodd at pch.net - +1-415-831-3123 On 29 Sep 2015, at 8:05, Bob Evans wrote: > Nice of you to check Jim. This brings up the old idea - A long time > ago I > had an INOC phone by PCH.NET - It never rang, as we filter our > outbound > with detail everywhere we announce. ISPs need to provide us their > address > list. > > And the few times I needed to use it , no one ever answered. ( It was > a > decade ago before NANOG membership.) So after a while I too ignored > it. > Maybe this was an idea ahead of it's time ? From this painful mishap, > it > could have been a great solution for NOC Engineers to help each. I > find > peeringdb often outdated as companies change around and sluggish > return > call if at all. Most are like a sales line number post. > > I see now a long list of registered networks in the PCH directory. Are > networks actually paying attention and using it. Is it time to take > another look ? At midnight in your organization could you get a NOC > person with " proper BGP skills and access " to answer and care about > a > bad announcement ? > > https://inoc-dba-web.pch.net/inoc-dba/console.cgi?op=show_pubdir&list=org > Link above shows lots more networks listed on the > INOC-DBA Public Directory: Organizations > > But have you used it? Did it work for you when you needed it ? > Any further comments are appreciated. > > This seems like a very good proper civil approach - maybe this or > something like it ARIN might help promote and endorse as a benefit to > the > community ? Be nice if with the cash they did something simple like > this > and got all of us to use it? Special line forwarding ? A Emergency > Only > NOC App for our phones for just this kind of situation - one that > registers a specific ASN and pin code we set on the registration page > ? > > Thank You > Bob Evans > CTO > > [snip] From Joel.Whitcomb at citrix.com Tue Sep 29 23:53:22 2015 From: Joel.Whitcomb at citrix.com (Joel Whitcomb) Date: Tue, 29 Sep 2015 23:53:22 +0000 Subject: SNMP - monitoring large number of devices In-Reply-To: References: Message-ID: <4BB209DB9251014197BCDA979B6B637A054B099C@SJCPEX01CL03.citrite.net> So we have used www.zenoss.org for many years. Individual collectors are easily handling snmp poll rates of 1.5k oids per second(450k per 5m). As zenoss core is open source Its probably worth a look for you. -Joel -----Original Message----- From: NANOG [mailto:nanog-bounces+joel.whitcomb=citrix.com at nanog.org] On Behalf Of Pavel Dimow Sent: Tuesday, September 29, 2015 1:20 PM To: NANOG Subject: SNMP - monitoring large number of devices Hi all, recently I have been tasked with a NMS project. The idea is to pool about 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a one million OID's). Before you say check out some very professional and expensive solutions I would like to know are there any alternatives like open source "snmp framework"? To be more descriptive many of you knows how big is the mess with snmp on cable modem. You always first perform snmp walk in order to discover interfaces and then read the values for those interfaces. As cable modem can bundle more DS channels, one time you can have one and other time you can have N+1 DS channels = interfaces. All in all I don't believe that there is something perfect out there when it comes to tracking huge number of cable modems so I would like to know is there any "snmp framework" that can be exteded and how did you (or would you) solve this problem. Thank you. From tsands at rackspace.com Wed Sep 30 04:18:34 2015 From: tsands at rackspace.com (Tom Sands) Date: Wed, 30 Sep 2015 04:18:34 +0000 Subject: SNMP - monitoring large number of devices In-Reply-To: <4BB209DB9251014197BCDA979B6B637A054B099C@SJCPEX01CL03.citrite.net> References: , <4BB209DB9251014197BCDA979B6B637A054B099C@SJCPEX01CL03.citrite.net> Message-ID: <294D238F-82B9-4230-A25C-8B31BD7D9572@rackspace.com> We have used ZenOss for a number of years at this scale (40k+ devices, at intervals of 1-5 minutes). It is possible to do if you have the hardware and storage performance to throw at it. We used OpenNMS before that and had to change due to scale. During that time we evaluated a number of the big name and big dollar solutions and none of them seemed to scale any better without significantly more hardware costs. That's not to say ZenOss is perfect, we have plenty of headaches too. Sent from my iPhone > On Sep 29, 2015, at 10:40 PM, Joel Whitcomb wrote: > > So we have used www.zenoss.org for many years. Individual collectors are easily handling snmp poll rates of 1.5k oids per second(450k per 5m). As zenoss core is open source Its probably worth a look for you. > > -Joel > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+joel.whitcomb=citrix.com at nanog.org] On Behalf Of Pavel Dimow > Sent: Tuesday, September 29, 2015 1:20 PM > To: NANOG > Subject: SNMP - monitoring large number of devices > > Hi all, > > recently I have been tasked with a NMS project. The idea is to pool about > 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a one million OID's). Before you say check out some very professional and expensive solutions I would like to know are there any alternatives like open source "snmp framework"? To be more descriptive many of you knows how big is the mess with snmp on cable modem. You always first perform snmp walk in order to discover interfaces and then read the values for those interfaces. As cable modem can bundle more DS channels, one time you can have one and other time you can have N+1 DS channels = interfaces. All in all I don't believe that there is something perfect out there when it comes to tracking huge number of cable modems so I would like to know is there any "snmp framework" that can be exteded and how did you (or would you) solve this problem. > > Thank you. From mdavids at forfun.net Wed Sep 30 05:33:37 2015 From: mdavids at forfun.net (Marco Davids) Date: Wed, 30 Sep 2015 07:33:37 +0200 Subject: How to force rapid ipv6 adoption In-Reply-To: References: Message-ID: <560B7431.1040203@forfun.net> Op 29-09-15 om 22:37 schreef David Hubbard: > Had an idea the other day; we just need someone with a lot of cash > (google, apple, etc) to buy Netflix and then make all new releases > v6-only for the first 48 hours. I bet my lame Brighthouse and Fios > service would be v6-enabled before the end of the following week lol. Sounds like a plan, let's do it. -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4239 bytes Desc: S/MIME-cryptografische ondertekening URL: From marka at isc.org Wed Sep 30 05:42:33 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 30 Sep 2015 15:42:33 +1000 Subject: How to force rapid ipv6 adoption In-Reply-To: Your message of "Wed, 30 Sep 2015 07:33:37 +0200." <560B7431.1040203@forfun.net> References: <560B7431.1040203@forfun.net> Message-ID: <20150930054233.22C9938EFCD9@rock.dv.isc.org> Ban the selling of IPv4 only home routers. The continued sale of these devices is just creating a e-waste problem. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ramy.ihashish at gmail.com Wed Sep 30 06:05:18 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Wed, 30 Sep 2015 08:05:18 +0200 Subject: Experience on Wanguard for 'anti' DDOS solutions In-Reply-To: References: Message-ID: Again Fabien, Why didn't you use A10 for both detection and mitigation? Thanks, Ramy On Wed, Aug 12, 2015 at 5:42 PM, Fabien Delmotte wrote: > Hello > > My 2 cents > You can use Wanguard for the detection and A10 for the mitigation, you > have just to play with the API. > > Regards > > Fabien > > > Le 12 ao?t 2015 ? 16:28, Ramy Hashish a ?crit > : > > > >> > >> > >> Date: Tue, 11 Aug 2015 08:14:54 +0200 > >> From: "marcel.duregards at yahoo.fr" > >> To: nanog at nanog.org > >> Subject: Re: Experience on Wanguard for 'anti' DDOS solutions > >> Message-ID: <55C992DE.3020906 at yahoo.fr> > >> Content-Type: text/plain; charset=windows-1252; format=flowed > >> > >> anybody from this impressive list ?: > >> > >> https://www.andrisoft.com/company/customers > >> > >> -- Marcel > >> > >> > >> > > Anybody here compared Wanguard's performance with the DDoS vendors in the > > market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ......)? > > > > Another question, have anybody from the reviewers tested the false > > positives of the box, or experienced any false positive incidents? > > > > Thanks, > > > > Ramy > > From mark.tinka at seacom.mu Wed Sep 30 06:31:53 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 30 Sep 2015 08:31:53 +0200 Subject: How to force rapid ipv6 adoption In-Reply-To: References: Message-ID: <560B81D9.7090602@seacom.mu> On 29/Sep/15 22:55, Josh Luthman wrote: > I think he means new releases are v6 for the first 48 hours...then trickle > to v4. Which means that people wanting to see that new release urgently > would have to wait two days. > > Netflix is definitely not the service to do that. Hulu, Amazon or HBO GO > maybe. Netflix content tends to be pretty old (apart from their own > content, of course). I think this is more "feasible" if Netflix offered a dedicated, 24/7/365 pr0n channel that only streamed on IPv6. If an IPv4-only Netflix subscriber tried to tune to that, they'd get a big fat "IPv6 required to view this FREE content. Please contact your service provider blah blah blah" on their TV screen. That could facilitate a "bottom-up" push; perhaps the only time we'll ever hear customers requesting for IPv6. Leave all the regular programming on IPv4 - we all know what drives Internet traffic anyway :-). Mark. From paveldimow at gmail.com Wed Sep 30 07:43:23 2015 From: paveldimow at gmail.com (Pavel Dimow) Date: Wed, 30 Sep 2015 09:43:23 +0200 Subject: SNMP - monitoring large number of devices In-Reply-To: <294D238F-82B9-4230-A25C-8B31BD7D9572@rackspace.com> References: <4BB209DB9251014197BCDA979B6B637A054B099C@SJCPEX01CL03.citrite.net> <294D238F-82B9-4230-A25C-8B31BD7D9572@rackspace.com> Message-ID: Thank you all for you suggestions, I knew it that NANOG is a perfect place for those kind of questions. I will discuss your comments with my colleagues to see what would be the best solution. Once again thank you all for your valuable suggestions, I hope I will update you soon with some results/test and of course more questions :) On Wed, Sep 30, 2015 at 6:18 AM, Tom Sands wrote: > We have used ZenOss for a number of years at this scale (40k+ devices, at > intervals of 1-5 minutes). It is possible to do if you have the hardware > and storage performance to throw at it. We used OpenNMS before that and had > to change due to scale. During that time we evaluated a number of the big > name and big dollar solutions and none of them seemed to scale any better > without significantly more hardware costs. > That's not to say ZenOss is perfect, we have plenty of headaches too. > > Sent from my iPhone > > > On Sep 29, 2015, at 10:40 PM, Joel Whitcomb > wrote: > > > > So we have used www.zenoss.org for many years. Individual collectors > are easily handling snmp poll rates of 1.5k oids per second(450k per 5m). > As zenoss core is open source Its probably worth a look for you. > > > > -Joel > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces+joel.whitcomb=citrix.com at nanog.org] > On Behalf Of Pavel Dimow > > Sent: Tuesday, September 29, 2015 1:20 PM > > To: NANOG > > Subject: SNMP - monitoring large number of devices > > > > Hi all, > > > > recently I have been tasked with a NMS project. The idea is to pool about > > 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's > a one million OID's). Before you say check out some very professional and > expensive solutions I would like to know are there any alternatives like > open source "snmp framework"? To be more descriptive many of you knows how > big is the mess with snmp on cable modem. You always first perform snmp > walk in order to discover interfaces and then read the values for those > interfaces. As cable modem can bundle more DS channels, one time you can > have one and other time you can have N+1 DS channels = interfaces. All in > all I don't believe that there is something perfect out there when it comes > to tracking huge number of cable modems so I would like to know is there > any "snmp framework" that can be exteded and how did you (or would you) > solve this problem. > > > > Thank you. > From owen at delong.com Wed Sep 30 08:11:29 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 30 Sep 2015 01:11:29 -0700 Subject: How to force rapid ipv6 adoption In-Reply-To: <20150930054233.22C9938EFCD9@rock.dv.isc.org> References: <560B7431.1040203@forfun.net> <20150930054233.22C9938EFCD9@rock.dv.isc.org> Message-ID: <66D9BA1C-5F04-45E8-BAF6-CDEB0771592C@delong.com> s/creating an/exacerbating the/ Owen > On Sep 29, 2015, at 22:42 , Mark Andrews wrote: > > > Ban the selling of IPv4 only home routers. The continued sale of > these devices is just creating a e-waste problem. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From meirea at charterschoolit.com Wed Sep 30 08:32:38 2015 From: meirea at charterschoolit.com (Mario Eirea) Date: Wed, 30 Sep 2015 08:32:38 +0000 Subject: How to force rapid ipv6 adoption In-Reply-To: References: Message-ID: With Netflix people might just dump the service, however, if you change all the social diarrhea sites (Facebook, Twitter, Instagram, etc...) over to v6 only overnight, you either force the net to adopt v6 or people to talk to each other. Either way, it's a win-win. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hubbard Sent: Tuesday, September 29, 2015 4:37 PM To: nanog at nanog.org Subject: How to force rapid ipv6 adoption Had an idea the other day; we just need someone with a lot of cash (google, apple, etc) to buy Netflix and then make all new releases v6-only for the first 48 hours. I bet my lame Brighthouse and Fios service would be v6-enabled before the end of the following week lol. David From colton.conor at gmail.com Wed Sep 30 13:00:33 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 30 Sep 2015 08:00:33 -0500 Subject: SNMP - monitoring large number of devices In-Reply-To: References: <4BB209DB9251014197BCDA979B6B637A054B099C@SJCPEX01CL03.citrite.net> <294D238F-82B9-4230-A25C-8B31BD7D9572@rackspace.com> Message-ID: Check out Science Logic. Their platform is made to scale to these levels. On Wed, Sep 30, 2015 at 2:43 AM, Pavel Dimow wrote: > Thank you all for you suggestions, I knew it that NANOG is a perfect place > for those kind of questions. > I will discuss your comments with my colleagues to see what would be the > best solution. > Once again thank you all for your valuable suggestions, I hope I will > update you soon with some results/test and of course more questions :) > > > On Wed, Sep 30, 2015 at 6:18 AM, Tom Sands wrote: > > > We have used ZenOss for a number of years at this scale (40k+ devices, at > > intervals of 1-5 minutes). It is possible to do if you have the hardware > > and storage performance to throw at it. We used OpenNMS before that and > had > > to change due to scale. During that time we evaluated a number of the big > > name and big dollar solutions and none of them seemed to scale any better > > without significantly more hardware costs. > > That's not to say ZenOss is perfect, we have plenty of headaches too. > > > > Sent from my iPhone > > > > > On Sep 29, 2015, at 10:40 PM, Joel Whitcomb > > wrote: > > > > > > So we have used www.zenoss.org for many years. Individual collectors > > are easily handling snmp poll rates of 1.5k oids per second(450k per 5m). > > As zenoss core is open source Its probably worth a look for you. > > > > > > -Joel > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces+joel.whitcomb=citrix.com at nanog.org] > > On Behalf Of Pavel Dimow > > > Sent: Tuesday, September 29, 2015 1:20 PM > > > To: NANOG > > > Subject: SNMP - monitoring large number of devices > > > > > > Hi all, > > > > > > recently I have been tasked with a NMS project. The idea is to pool > about > > > 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's > > a one million OID's). Before you say check out some very professional and > > expensive solutions I would like to know are there any alternatives like > > open source "snmp framework"? To be more descriptive many of you knows > how > > big is the mess with snmp on cable modem. You always first perform snmp > > walk in order to discover interfaces and then read the values for those > > interfaces. As cable modem can bundle more DS channels, one time you can > > have one and other time you can have N+1 DS channels = interfaces. All in > > all I don't believe that there is something perfect out there when it > comes > > to tracking huge number of cable modems so I would like to know is there > > any "snmp framework" that can be exteded and how did you (or would you) > > solve this problem. > > > > > > Thank you. > > > From maxtul at netassist.ua Wed Sep 30 13:18:48 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 30 Sep 2015 16:18:48 +0300 Subject: Script for NAT timeout detection Message-ID: <560BE138.9080905@netassist.ua> Hello All, I have some devices connected under NAT that is not under my control. Is there some software/script to detect NAT session timeout to adjust keepalives? Thank you! From LudendorffR at rferl.org Wed Sep 30 09:39:43 2015 From: LudendorffR at rferl.org (Ray Ludendorff) Date: Wed, 30 Sep 2015 09:39:43 +0000 Subject: SNMP - monitoring large number of devices In-Reply-To: References: <4BB209DB9251014197BCDA979B6B637A054B099C@SJCPEX01CL03.citrite.net> <294D238F-82B9-4230-A25C-8B31BD7D9572@rackspace.com>, Message-ID: <40CFE2E2-AFE1-45ED-8E5B-85E03B851972@rferl.org> Please try the following/ https://statseeker.com/ Sent from my virtual office On Sep 30, 2015, at 09:44, Pavel Dimow > wrote: Thank you all for you suggestions, I knew it that NANOG is a perfect place for those kind of questions. I will discuss your comments with my colleagues to see what would be the best solution. Once again thank you all for your valuable suggestions, I hope I will update you soon with some results/test and of course more questions :) On Wed, Sep 30, 2015 at 6:18 AM, Tom Sands > wrote: We have used ZenOss for a number of years at this scale (40k+ devices, at intervals of 1-5 minutes). It is possible to do if you have the hardware and storage performance to throw at it. We used OpenNMS before that and had to change due to scale. During that time we evaluated a number of the big name and big dollar solutions and none of them seemed to scale any better without significantly more hardware costs. That's not to say ZenOss is perfect, we have plenty of headaches too. Sent from my iPhone On Sep 29, 2015, at 10:40 PM, Joel Whitcomb > wrote: So we have used www.zenoss.org for many years. Individual collectors are easily handling snmp poll rates of 1.5k oids per second(450k per 5m). As zenoss core is open source Its probably worth a look for you. -Joel -----Original Message----- From: NANOG [mailto:nanog-bounces+joel.whitcomb=citrix.com at nanog.org] On Behalf Of Pavel Dimow Sent: Tuesday, September 29, 2015 1:20 PM To: NANOG > Subject: SNMP - monitoring large number of devices Hi all, recently I have been tasked with a NMS project. The idea is to pool about 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a one million OID's). Before you say check out some very professional and expensive solutions I would like to know are there any alternatives like open source "snmp framework"? To be more descriptive many of you knows how big is the mess with snmp on cable modem. You always first perform snmp walk in order to discover interfaces and then read the values for those interfaces. As cable modem can bundle more DS channels, one time you can have one and other time you can have N+1 DS channels = interfaces. All in all I don't believe that there is something perfect out there when it comes to tracking huge number of cable modems so I would like to know is there any "snmp framework" that can be exteded and how did you (or would you) solve this problem. Thank you. From tobez at tobez.org Wed Sep 30 13:32:00 2015 From: tobez at tobez.org (Anton Berezin) Date: Wed, 30 Sep 2015 15:32:00 +0200 Subject: SNMP - monitoring large number of devices In-Reply-To: References: Message-ID: <20150930133200.GC49828@heechee.tobez.org> Hello, On Tue, Sep 29, 2015 at 10:20:19PM +0200, Pavel Dimow wrote: > recently I have been tasked with a NMS project. The idea is to pool about > 20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a > one million OID's). Before you say check out some very professional and > expensive solutions I would like to know are there any alternatives like > open source "snmp framework"? To be more descriptive many of you knows how > big is the mess with snmp on cable modem. You always first perform snmp > walk in order to discover interfaces and then read the values for those > interfaces. As cable modem can bundle more DS channels, one time you can > have one and other time you can have N+1 DS channels = interfaces. All in > all I don't believe that there is something perfect out there when it comes > to tracking huge number of cable modems so I would like to know is there > any "snmp framework" that can be exteded and how did you (or would you) > solve this problem. You might wish to check out https://github.com/tobez/snmp-query-engine (disclosure: I am the author). Some scripting is needed to instruct it to do the polling and fetch the collecting results. Currently there are only bindings for Perl (https://metacpan.org/pod/Net::SNMP::QueryEngine::AnyEvent), but bindings for other dynamic languages should be pretty straightforward. We routinely use it to collect comparable quantities of OIDs. \Anton. -- Our society can survive even a large amount of irrational regulation. -- John McCarthy From cgrundemann at gmail.com Wed Sep 30 14:41:38 2015 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 30 Sep 2015 10:41:38 -0400 Subject: Quick Update on the North American BCOP Efforts Message-ID: Hail NANOGers! After receiving several off-line inquiries about the status of BCOP in North America I think it's appropriate to send a general announcement here. The biggest news here is that the current NANOG Board of Directors has disbanded the NANOG BCOP Committee. The stated rationale for this decision can be found in the minutes from their 2 February 2015 meeting. https://www.nanog.org/sites/default/files/sites/default/files/BOD-BCOPMinutes_2.2.2015.pdf As you might expect, I find this extremely disappointing. Our reaction has been twofold: 1) We're moving to a new home. You can now find all of the current documents at http://nabcop.org. Everything is moving forward, despite a bit of jostling. Please jump in and get involved! 2) I'm so disappointed by this decision, and the future course of NANOG implied, that I've decided to run for the NANOG Board of Directors. There's a really great slate of candidates running, so whatever your decision, I highly encourage you to really consider your selections. https://www.nanog.org/elections/2015/BoDcandidates If you have any questions at all, please feel free to email me directly, or send them to bcop-support at nabcop.org. See you in Montr?al! Cheers, ~Chris From nanog at ics-il.net Wed Sep 30 15:17:19 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 30 Sep 2015 10:17:19 -0500 (CDT) Subject: Quick Update on the North American BCOP Efforts In-Reply-To: Message-ID: <42456252.16999.1443626280346.JavaMail.mhammett@ThunderFuck> If NANOG isn't developing and publishing BCOPs, what's the point of NANOG other than a mailing list? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Chris Grundemann" To: nanog at nanog.org Sent: Wednesday, September 30, 2015 9:41:38 AM Subject: Quick Update on the North American BCOP Efforts Hail NANOGers! After receiving several off-line inquiries about the status of BCOP in North America I think it's appropriate to send a general announcement here. The biggest news here is that the current NANOG Board of Directors has disbanded the NANOG BCOP Committee. The stated rationale for this decision can be found in the minutes from their 2 February 2015 meeting. https://www.nanog.org/sites/default/files/sites/default/files/BOD-BCOPMinutes_2.2.2015.pdf As you might expect, I find this extremely disappointing. Our reaction has been twofold: 1) We're moving to a new home. You can now find all of the current documents at http://nabcop.org. Everything is moving forward, despite a bit of jostling. Please jump in and get involved! 2) I'm so disappointed by this decision, and the future course of NANOG implied, that I've decided to run for the NANOG Board of Directors. There's a really great slate of candidates running, so whatever your decision, I highly encourage you to really consider your selections. https://www.nanog.org/elections/2015/BoDcandidates If you have any questions at all, please feel free to email me directly, or send them to bcop-support at nabcop.org. See you in Montr?al! Cheers, ~Chris From ops.lists at gmail.com Wed Sep 30 15:25:44 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 30 Sep 2015 20:55:44 +0530 Subject: Quick Update on the North American BCOP Efforts In-Reply-To: <42456252.16999.1443626280346.JavaMail.mhammett@ThunderFuck> References: <42456252.16999.1443626280346.JavaMail.mhammett@ThunderFuck> Message-ID: Late to the party but which best current practices were these and - as the board asked - how much of it reinvents the several other best practice wheels around? --srs > On 30-Sep-2015, at 8:47 PM, Mike Hammett wrote: > > If NANOG isn't developing and publishing BCOPs, what's the point of NANOG other than a mailing list? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Chris Grundemann" > To: nanog at nanog.org > Sent: Wednesday, September 30, 2015 9:41:38 AM > Subject: Quick Update on the North American BCOP Efforts > > Hail NANOGers! > > After receiving several off-line inquiries about the status of BCOP in > North America I think it's appropriate to send a general announcement here. > > The biggest news here is that the current NANOG Board of Directors has > disbanded the NANOG BCOP Committee. The stated rationale for this decision > can be found in the minutes from their 2 February 2015 meeting. > > https://www.nanog.org/sites/default/files/sites/default/files/BOD-BCOPMinutes_2.2.2015.pdf > > As you might expect, I find this extremely disappointing. Our reaction has > been twofold: > > 1) We're moving to a new home. You can now find all of the current > documents at http://nabcop.org. Everything is moving forward, despite a bit > of jostling. Please jump in and get involved! > > 2) I'm so disappointed by this decision, and the future course of NANOG > implied, that I've decided to run for the NANOG Board of Directors. There's > a really great slate of candidates running, so whatever your decision, I > highly encourage you to really consider your selections. > > https://www.nanog.org/elections/2015/BoDcandidates > > If you have any questions at all, please feel free to email me directly, or > send them to bcop-support at nabcop.org. > > See you in Montr?al! > > Cheers, > ~Chris > From cgrundemann at gmail.com Wed Sep 30 15:54:55 2015 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 30 Sep 2015 11:54:55 -0400 Subject: Quick Update on the North American BCOP Efforts In-Reply-To: References: <42456252.16999.1443626280346.JavaMail.mhammett@ThunderFuck> Message-ID: Hi Suresh, I believe all the information you seek is on our wiki: http://nabcop.org. Be sure to look over the list of topics under the "Jump In" heading. To your question about reinventing wheels specifically: There's two aspects to that I believe. The first is that we have no intention to "make work" by duplicating efforts. In cases where the BCOP is already clearly defined and well maintained, we simply want to act as curator - giving network engineers a single place to find the information they need. In other cases, we act as creator - bringing together subject matter experts to draft new documents for community review. The second aspect is that every BCOP must be rooted in existing knowledge. BCOPs are defined by being tried and true methods for dealing with some aspect of modern network operations. These are things that have been presented on and discussed at NANOG. They are things that are "common sense" to the initiated. They are also things that are profound when discovered for the first time. The idea here is to capture what some of us know, vet it, and make it easily available to all of us. Cheers, ~Chris On Wed, Sep 30, 2015 at 11:25 AM, Suresh Ramasubramanian < ops.lists at gmail.com> wrote: > Late to the party but which best current practices were these and - as the > board asked - how much of it reinvents the several other best practice > wheels around? > > --srs > > > On 30-Sep-2015, at 8:47 PM, Mike Hammett wrote: > > > > If NANOG isn't developing and publishing BCOPs, what's the point of > NANOG other than a mailing list? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > ----- Original Message ----- > > > > From: "Chris Grundemann" > > To: nanog at nanog.org > > Sent: Wednesday, September 30, 2015 9:41:38 AM > > Subject: Quick Update on the North American BCOP Efforts > > > > Hail NANOGers! > > > > After receiving several off-line inquiries about the status of BCOP in > > North America I think it's appropriate to send a general announcement > here. > > > > The biggest news here is that the current NANOG Board of Directors has > > disbanded the NANOG BCOP Committee. The stated rationale for this > decision > > can be found in the minutes from their 2 February 2015 meeting. > > > > > https://www.nanog.org/sites/default/files/sites/default/files/BOD-BCOPMinutes_2.2.2015.pdf > > > > As you might expect, I find this extremely disappointing. Our reaction > has > > been twofold: > > > > 1) We're moving to a new home. You can now find all of the current > > documents at http://nabcop.org. Everything is moving forward, despite a > bit > > of jostling. Please jump in and get involved! > > > > 2) I'm so disappointed by this decision, and the future course of NANOG > > implied, that I've decided to run for the NANOG Board of Directors. > There's > > a really great slate of candidates running, so whatever your decision, I > > highly encourage you to really consider your selections. > > > > https://www.nanog.org/elections/2015/BoDcandidates > > > > If you have any questions at all, please feel free to email me directly, > or > > send them to bcop-support at nabcop.org. > > > > See you in Montr?al! > > > > Cheers, > > ~Chris > > > -- @ChrisGrundemann http://chrisgrundemann.com From rdobbins at arbor.net Wed Sep 30 16:10:48 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 30 Sep 2015 11:10:48 -0500 Subject: Quick Update on the North American BCOP Efforts In-Reply-To: <42456252.16999.1443626280346.JavaMail.mhammett@ThunderFuck> References: <42456252.16999.1443626280346.JavaMail.mhammett@ThunderFuck> Message-ID: <2FB764EE-F558-44F7-ADBD-EFDBB3A781F0@arbor.net> On 30 Sep 2015, at 10:17, Mike Hammett wrote: > If NANOG isn't developing and publishing BCOPs, what's the point of > NANOG other than a mailing list? ----------------------------------- Roland Dobbins From bicknell at ufp.org Wed Sep 30 17:39:35 2015 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 30 Sep 2015 10:39:35 -0700 Subject: How to force rapid ipv6 adoption In-Reply-To: References: Message-ID: <20150930173935.GA96551@ussenterprise.ufp.org> In a message written on Tue, Sep 29, 2015 at 04:37:19PM -0400, David Hubbard wrote: > Had an idea the other day; we just need someone with a lot of cash > (google, apple, etc) to buy Netflix and then make all new releases > v6-only for the first 48 hours. I bet my lame Brighthouse and Fios > service would be v6-enabled before the end of the following week lol. If only people were forced to deploy IPv6...like perhaps because they couldn't get any more IPv4 addresses. Maybe we should stop issuing IPv4 addresses? (Did I need to put sarcasam tags around that, I hope not!) -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From Kevin_McElearney at cable.comcast.com Wed Sep 30 19:41:49 2015 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Wed, 30 Sep 2015 19:41:49 +0000 Subject: How to force rapid ipv6 adoption In-Reply-To: References: Message-ID: On 9/29/15, 4:37 PM, "David Hubbard" wrote: >Had an idea the other day; we just need someone with a lot of cash >(google, apple, etc) to buy Netflix and then make all new releases >v6-only for the first 48 hours. I bet my lame Brighthouse and Fios >service would be v6-enabled before the end of the following week lol. This only helps 1/3 of the challenge. Even with most Comcast customers able to obtain IPv6 today and over 70% provisioned with IPv6, less than 20% of the traffic is IPv6. There is still a need to address home device support and content provider adoption. From marco at paesani.it Wed Sep 30 21:24:44 2015 From: marco at paesani.it (Marco Paesani) Date: Wed, 30 Sep 2015 23:24:44 +0200 Subject: Routes leaked by AS393742 via AS16397 Message-ID: Hi, anyboody know this AS ?? Upstream AS3549 Thanks ! Regards -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From baldur.norddahl at gmail.com Wed Sep 30 21:34:34 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 30 Sep 2015 23:34:34 +0200 Subject: How to force rapid ipv6 adoption In-Reply-To: References: Message-ID: On 30 September 2015 at 21:41, McElearney, Kevin < Kevin_McElearney at cable.comcast.com> wrote: > This only helps 1/3 of the challenge. Even with most Comcast customers > able to obtain IPv6 today and over 70% provisioned with IPv6, less than > 20% of the traffic is IPv6. There is still a need to address home device > support and content provider adoption. > We will never get there 100%. There are many sites out there running 100% on autopilot. They will stay IPv4 forever until the server crashes and never comes back online. The same will be true for many homes. People who don't want to change anything. They will keep Windows XP and whatever antique device they use to connect to the internet until the thing catches fire from the accumulated dust. And then they will go on ebay to buy a replacement exactly the same. Remember that people with Windows XP with their ancient version of Internet Explorer already can not access many sites. They don't care. I believe the real goal is to get to a point, where people will accept the more invasive transition technologies such as NAT64, because everything they care about is IPv6 enabled. At some point people will start making IPv6 only sites, because everyone they know have IPv6 access. At that point the internet will split into two - the people that have access to the whole thing (IPv6+IPv4) and the IPv4-only people. Yet a lot of those IPv4-only people will stay IPv4-only even though they know they are missing out on something. Because Gmail and Facebook will always be available on IPv4 and that is all they care about. Regards, Baldur From rwebb at ropeguru.com Wed Sep 30 21:43:40 2015 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 30 Sep 2015 17:43:40 -0400 Subject: Routes leaked by AS393742 via AS16397 In-Reply-To: References: Message-ID: https://ipinfo.io/AS393742 On Wed, 30 Sep 2015 23:24:44 +0200 Marco Paesani wrote: > Hi, > anyboody know this AS ?? > Upstream AS3549 > Thanks ! > Regards > > -- > > Marco Paesani > MPAE Srl > > Skype: mpaesani > Mobile: +39 348 6019349 > Success depends on the right choice ! > Email: marco at paesani.it From hugo at slabnet.com Wed Sep 30 21:59:22 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 30 Sep 2015 14:59:22 -0700 Subject: Routes leaked by AS393742 via AS16397 In-Reply-To: References: Message-ID: <20150930215922.GB21567@bamboo.slabnet.com> On Wed 2015-Sep-30 17:43:40 -0400, Robert Webb wrote: >https://ipinfo.io/AS393742 ...I'm so behind the times; my response would have been: $ finger 393742 at peeringdb.com General Network Information --------------------------- Network Name : Biyort USA Corp Name Aliases : Primary ASN : 393742 Website : http://www.biyort.com IRR AS-SET : Network Type : NSP Approx BGP Prefixes : Traffic Levels : 100-200 Gbps Traffic Ratios : Balanced Geographic Scope : North America Supported Protocols : Coming Soon Looking Glass URL : http://lg.biyort.com Route Server URL : Public Notes : Record Created Date : 2015-01-13 20:24:36 Last Updated Date : 2015-04-03 00:01:07 Peering Policy Information -------------------------- Peering Policy URL : General Policy : Restrictive Location Requirement : Required - International Ratio Requirement : Yes Contract Requirement : Not Required Contact Information ------------------- Role Name E-Mail Phone ---- ---- ------ ----- Public Relations Rene rjesus at biyort.com Technical Daniels daniel at biyort.com NOC Network support at biyort.com Public Peering Information - 5 -------------------------- Exchange Point ASN IP Address Capacity -------------- --- ---------- -------- NDB 393742 198.32.122.118 1000 Mbps NOTA 393742 198.32.125.131 10000 Mbps NOTA 393742 2001:478:124::1131 10000 Mbps PTT-PR 393742 200.219.140.87 10000 Mbps PTT-SP 393742 187.16.220.15 10000 Mbps Private Peering Information --------------------------- Facility Name ASN City Country ------------- --- ---- ------- Cogent Velizy 393742 Vizy Villacoublay FR NTT 393742 San Jose US ...or http://bgp.he.net/AS393742 if it wasn't in peeringdb. -- Hugo > >On Wed, 30 Sep 2015 23:24:44 +0200 > Marco Paesani wrote: >>Hi, >>anyboody know this AS ?? >>Upstream AS3549 >>Thanks ! >>Regards >> >>-- >> >>Marco Paesani >>MPAE Srl >> >>Skype: mpaesani >>Mobile: +39 348 6019349 >>Success depends on the right choice ! >>Email: marco at paesani.it > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From rwebb at ropeguru.com Wed Sep 30 23:03:18 2015 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 30 Sep 2015 19:03:18 -0400 Subject: Routes leaked by AS393742 via AS16397 In-Reply-To: <20150930215922.GB21567@bamboo.slabnet.com> References: <20150930215922.GB21567@bamboo.slabnet.com> Message-ID: Although, you did provide a little more detail. :-) On Wed, 30 Sep 2015 14:59:22 -0700 Hugo Slabbert wrote: > > On Wed 2015-Sep-30 17:43:40 -0400, Robert Webb >wrote: > >>https://ipinfo.io/AS393742 > > ...I'm so behind the times; my response would have been: > > $ finger 393742 at peeringdb.com > > General Network Information > --------------------------- > Network Name : Biyort USA Corp > Name Aliases : > Primary ASN : 393742 > Website : http://www.biyort.com > IRR AS-SET : > Network Type : NSP > Approx BGP Prefixes : > Traffic Levels : 100-200 Gbps > Traffic Ratios : Balanced > Geographic Scope : North America > Supported Protocols : Coming Soon > Looking Glass URL : http://lg.biyort.com > Route Server URL : > Public Notes : > Record Created Date : 2015-01-13 20:24:36 > Last Updated Date : 2015-04-03 00:01:07 > > Peering Policy Information > -------------------------- > Peering Policy URL : > General Policy : Restrictive > Location Requirement : Required - International > Ratio Requirement : Yes > Contract Requirement : Not Required > > Contact Information > ------------------- > > Role Name E-Mail Phone > ---- ---- ------ ----- > Public Relations Rene rjesus at biyort.com > Technical Daniels daniel at biyort.com > NOC Network support at biyort.com > > Public Peering Information - 5 > -------------------------- > > Exchange Point ASN IP Address > Capacity > -------------- --- ---------- > -------- > NDB 393742 198.32.122.118 > 1000 Mbps > NOTA 393742 198.32.125.131 > 10000 Mbps > NOTA 393742 2001:478:124::1131 > 10000 Mbps > PTT-PR 393742 200.219.140.87 > 10000 Mbps > PTT-SP 393742 187.16.220.15 > 10000 Mbps > > Private Peering Information > --------------------------- > >Facility Name ASN City > Country > ------------- --- ---- > ------- > Cogent Velizy 393742 Vizy >Villacoublay FR > NTT 393742 San Jose > US > > ...or http://bgp.he.net/AS393742 if it wasn't in peeringdb. > > -- > Hugo > >> >>On Wed, 30 Sep 2015 23:24:44 +0200 >> Marco Paesani wrote: >>>Hi, >>>anyboody know this AS ?? >>>Upstream AS3549 >>>Thanks ! >>>Regards >>> >>>-- >>> >>>Marco Paesani >>>MPAE Srl >>> >>>Skype: mpaesani >>>Mobile: +39 348 6019349 >>>Success depends on the right choice ! >>>Email: marco at paesani.it >> >>