From sf at lists.esoteric.ca Mon Dec 1 00:19:15 2014 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Sun, 30 Nov 2014 19:19:15 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: Message-ID: <547BB403.40308@lists.esoteric.ca> Hi Clayton, Putting on my TorIX hat, I'll address what you've brought up: 1. We implemented port security because MAC ACL's were not effectively blocking certain types of bad traffic, which was a problem with the hardware in place at the time. As you are certainly aware, getting vendors to work on esoteric problems faced by a small number of their customers can be frustrating. 2. Port security effectively logs rogue MAC's received on the port, which was/is not always the case when certain types of "bad or unwanted traffic are received. This has proven invaluable for trouble-shooting and is very easy to pass along that info to the peer for further investigation without having to begin a separate trouble-shooting process with all parties online and aligned, and hoping the problem reappears. 3. Since we implemented port security, the stability of TorIX has been excellent. No more sudden outages due to peer human error or bad peer architecture. (some of which is mind blowing). 4. If you think the 60 minute lock-down is excessive, bring it up on torix-members and begin a discussion, which we're certainly open to when it will not adversely affect the integrity of the IX. 5. If Netflix was at TorIX, I guarantee you would see traffic shoot through the roof, and that's why we'd welcome NF and others like FB, Edgecast etc. joining TorIX. We are one of the largest IX'es in terms of number of peers in the world after all. Back onto the original topic, a number of peers sell transit over the IX. TorIX does not offer SLA's, but we do not stop peers from maximizing their value of the IX. -- Stephen (volunteer at TorIX) On 2014-11-30 6:51 PM, Clayton wrote: > We peer at TorIX and Equinix. I have to say that despite the fact that > Equnix charges us more for our port, we're getting far more value from it > than TorIX. Around double the traffic, and they don't have silly punative > measures like locking your port if you leak a MAC address other than the > one you registered with them (Equnix filters the MAC, but doesn't apply a > 60 minute port shut down penalty if you leak like TorIX does). > From Jason_Livingood at cable.comcast.com Mon Dec 1 13:22:08 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 1 Dec 2014 13:22:08 +0000 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <547A01E3.1030702@vaxination.ca> References: <54778167.7080808@bogus.com> <84B714C0-D429-4245-96D0-33BFF0D62CF1@steffann.nl> <547A01E3.1030702@vaxination.ca> Message-ID: On 11/29/14, 12:26 PM, "Jean-Francois Mezei" wrote: >However, in the case of SMTP, due to the amount of spam, most ISPs break >"network neutrality" by blocking outbound port 25 for instance Whatever Net Neutrality may mean this week, it is usually intended to allow for reasonable network management practices, including preventing network abuse. In the case of port blocking, it is permissible provided it is disclosed transparently. - Jason From Jason_Livingood at cable.comcast.com Mon Dec 1 13:25:02 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 1 Dec 2014 13:25:02 +0000 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <20141129201745.30066.qmail@ary.lan> References: <20141129201745.30066.qmail@ary.lan> Message-ID: On 11/29/14, 3:17 PM, "John Levine" wrote: >PS: I know enough technical people at Comcast that I would be >extremely surprised if it were Comcast doing this. There's plenty not to >like about the corporation, but the technical staff are quite competent. Thanks, John! I can tell folks here unequivocally that (1) the recent press article on STARTTLS re-writing did *not* involve Comcast and (2) Comcast does not engage in the claimed practice. In fact, we¹re supporters and early deployers of STARTTLS on our own mail service. I do not know how to explain the issue reported on this list. Absent a packet capture it is impossible for me to analyze this further. If anything, I could only imagine it was a misconfiguration someplace, but I have no idea where or in what network element that¹d even be possible. I¹m happy to work with anyone that has more info to try to troubleshoot this. - Jason Livingood Comcast From dave at temk.in Mon Dec 1 14:24:03 2014 From: dave at temk.in (Dave Temkin) Date: Mon, 1 Dec 2014 08:24:03 -0600 Subject: ISPs Behaving Badly: GIGLINX slime was Re: ARIN WHOIS for leads Message-ID: Ressurecting this thread: GIGLINX is still at it. They contacted me on an email that was only ever used for registering an ASN with ARIN. On Wed, Jul 31, 2013 at 9:14 PM, John Curran wrote: > On Jul 31, 2013, at 1:17 PM, Barry Shein wrote: > > > The usual method is to insert "ringers" which would be info which > > points back at non-existant people with valid-looking contact > > information. > > > > If for example they called a phone number, or several, owned by ARIN > > (or a service they employed) asking for James T Kirk or Diana Prince > > then that would be a problem and should be logged. > > There are some interesting non-obvious elements in the database for > such purposes and we do take action when they are triggered. > > FYI, > /John > > John Curran > President and CEO > ARIN > > > > From tim.donahue at gmail.com Mon Dec 1 19:10:16 2014 From: tim.donahue at gmail.com (Tim Donahue) Date: Mon, 1 Dec 2014 14:10:16 -0500 Subject: Postmaster @ charter.net Message-ID: Hi all, Sorry for the noise, but my emails to postmaster at charter.net are getting rejected. Our mail server is being rejected by charter.net for not having a reverse DNS PTR record, but all the publicly available DNS servers I am able to query are resolving the PTR without any errors. If anyone has a direct contact within Charter that they could put me in contact with it would be greatly appreciated. Thanks, Tim Donahue From owen at delong.com Mon Dec 1 19:41:27 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 1 Dec 2014 11:41:27 -0800 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: References: <5460C679.5090005@winterei.se> Message-ID: <6DDF6BF7-2710-4C81-9561-B19B059C18DE@delong.com> > On Nov 10, 2014, at 6:36 PM, Christopher Morrow wrote: > > because a /23 of ipv6 is very large.... :) That’s a good reason not to use a /23, but not a good reason not to use IPv6. > > also, it's hard to use ipv6 when your last miile provider doesn't offer it... > > #fios > No it’s not… #tunnelbroker Owen > On Mon, Nov 10, 2014 at 7:53 PM, Bill Woodcock wrote: >> Why use IPv4 for OOB? Seems a little late in the day for that. >> >> >> -Bill >> >> >>> On Nov 10, 2014, at 15:02, "Christopher Morrow" wrote: >>> >>>> On Mon, Nov 10, 2014 at 9:06 AM, Paul S. wrote: >>>> I'd be doubtful if anyone will feel like offering a /23 with OOB as >>>> justification these days, sadly. >>> >>> why thought? Justification is really about having a use for the ips, >>> right? and if you have 500 servers/network-devices ... then you have >>> justification for a /23 ... it seems to me. >>> >>>> >>>> Good luck nonetheless. >>>> >>>> >>>>> On 11/10/2014 午後 11:00, Ruairi Carroll wrote: >>>>> >>>>> Hey, >>>>> >>>>> VPN setup is not really a viable option (for us) in this scenario. >>>>> Honestly, I'd prefer to just call it done already and have a VPN but due >>>>> to >>>>> certain restraints, we have to go down this route. >>>>> >>>>> /Ruairi >>>>> >>>>>> On 10 November 2014 14:38, Alistair Mackenzie wrote: >>>>>> >>>>>> Couldn't you put a router or VPN system on the single IP they are giving >>>>>> you and use RFC1918 addressing space? >>>>>> >>>>>> OOB doesn't normally justify a /24 let alone a /23. >>>>>> >>>>>> On 10 November 2014 13:18, Ruairi Carroll >>>>>> wrote: >>>>>> >>>>>>> Dear List, >>>>>>> >>>>>>> I've got an upcoming deployment in Equinix (DC10) and I'm struggling to >>>>>>> find a provider who can give me a 100Mbit port (With a commit of about >>>>>>> 5-10Mbit) with a /23 or /24 of public space , for OOB purposes. We had >>>>>>> hoped to use Equinixs services, however they're limiting us to a single >>>>>>> public IP. >>>>>>> >>>>>>> I'm also open to other solutions - xDSL or similar, but emphasis is on >>>>>>> cheap and on-net. >>>>>>> >>>>>>> Cheers >>>>>>> /Ruairi >>>> From owen at delong.com Mon Dec 1 21:43:17 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 1 Dec 2014 13:43:17 -0800 Subject: A case against vendor-locking optical modules In-Reply-To: References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> <1545079773.489926.1416248928171.JavaMail.zimbra@snappytelecom.net> <546A488A.3090400@ceriz.fr> Message-ID: > On Nov 17, 2014, at 12:34 PM, Justin M. Streiner wrote: > > On Mon, 17 Nov 2014, Jérôme Nicolle wrote: > >> Is it unrealistic to hope for enough salesmen pressure on the corporate >> ladder to make such moronic attitude be reversed in the short term ? > > No salesperson is likely to do that for you. They know only to well that eliminating vendor lock-in means they will lose sales on artificially costly optics from $vendor to a lower-cost rival. Less sales = less commission for the affected sales person. > > jms Which is why there is NO Arista gear in my network… They lose sales of costly routers as well as optics to any customer who doesn’t want to promote this behavior. It boils down to how much you want to tolerate/support/encourage this behavior. If you feel strongly like I do that such behavior is aberrant and should be strongly discouraged, then vote with your $$$ and don’t buy from vendors that do that. Let your vendors that you don’t buy from know why they lost the sale. I’ve found that showing a vendor a price-redacted copy of the PO to the other vendor can often lead to changes in the way they approach the next sales cycle. Owen From bmeshier at amherst.com Tue Dec 2 14:00:55 2014 From: bmeshier at amherst.com (Meshier, Brent) Date: Tue, 2 Dec 2014 14:00:55 +0000 Subject: Publix Super Markets, Inc. PUBLIX-S51-11 Message-ID: <68C2CBC977F3E04799DF9C76E938E7090865F60A@DFEXCH2.asglp.com> Can someone from Publix contact me off list? You're dropping traffic from legitimate networks. Brent Meshier | Amherst Holdings, LLC | 5001 Plaza on the Lake, Suite 200, Austin, TX 78746 | T: 512-342-3010 --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication. From corey.touchet at corp.totalserversolutions.com Tue Dec 2 14:57:57 2014 From: corey.touchet at corp.totalserversolutions.com (Corey Touchet) Date: Tue, 2 Dec 2014 14:57:57 +0000 Subject: Google IP Engineering Contact Message-ID: Can someone at Google that has some control over how Google’s system that says an IP is suddenly in Iran please contact me off list ASAP. We can not wait a month for your tool to remove this. Also in the future that tool needs to ping the ip and check the RTT time and compare to well established GEOIP databases before flagging ip’s as not belonging to the country they’re actually in. We had to change our office firewall ip because suddenly Google thought it was in China instead of Georgia a few months back. Corey Touchet Manager Enterprise Infrastructure Total Server Solutions From ttauber at 1-4-5.net Tue Dec 2 20:04:53 2014 From: ttauber at 1-4-5.net (Tony Tauber) Date: Tue, 2 Dec 2014 15:04:53 -0500 Subject: [NANOG-announce] NANOG 63 - San Antonio - Call for Presentations is Open! In-Reply-To: References: Message-ID: Hi folks, I'm writing as a reminder that the NANOG Program Committee is still soliciting proposals for NANOG63. This Friday, December 5th, is when we'd like to have at least an Abstract posted to the PC Tool website. The Abstract needn't be that detailed but then we on the PC can reach out to you and work to help develop your ideas. If it's possible to post some draft slides as well, that would help us further. In either case, don't worry at this point that the submission is finalized or polished; that can come later. We look forward to hearing from you. As always, send questions either to the PC or to me. Thanks, Tony On Mon, Oct 27, 2014 at 5:20 PM, Tony Tauber wrote: > Greetings NANOG Folks, > > It was great to see so many of you (~700) at NANOG 62 in Baltimore. > NANOG will hold its 63rd meeting in San Antonio, TX on February 2-4, 2015, > hosted by CyrusOne. > > The NANOG Program Committee is now seeking proposals for presentations, > panels, tutorials, tracks sessions, and keynote materials for the NANOG 63 > program. We invite presentations highlighting issues relating to technology > already deployed or soon-to-be deployed in the Internet, . Vendors are > encouraged to work with operators to present real-world deployment > experiences with the vendor's products and interoperability. Key dates to > track if you wish to submit a presentation: > > Date Event/Deadline Oct. 27, 2014 CFP Opens for NANOG 63 Dec. 05, 2014 CFP > Deadline #1: Presentation Abstracts Due Dec. 12, 2014 CFP Topic List > Posted Jan. 02, 2015 CFP Deadline #2: Presentation Slides Due Jan. 09, > 2015 Meeting Agenda Published Jan. 30, 2015 Speaker FINAL presentations > to PCTool or speaker-support Feb. 02, 2015 Lightning Talk Submissions > Open (Abstracts Only) > NANOG 63 submissions are welcome on the Program Committee Site > or email me if you have questions. > > See the detailed NANOG63 Call for Presentations > for more > information. > > Let's see each other in San Antonio where, apparently, the typical high > temps in February are 65F/18C. > > Thanks, > > Tony Tauber > Chair, Program Committee > North American Network Operator Group (NANOG) > -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cdaniel at nurve.com.au Tue Dec 2 23:02:31 2014 From: cdaniel at nurve.com.au (Cameron Daniel) Date: Wed, 03 Dec 2014 09:02:31 +1000 Subject: Global Switch Singapore - OOB IP Message-ID: Hi all Realise this may not be the best place to post this, but currently looking for someone in MMR1 in Global Switch SG who can provide a low speed IP link for OOB. Copper hand off, no BGP peering required. Off-list replies welcome Cheers Cameron From owen at delong.com Tue Dec 2 23:42:08 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Dec 2014 15:42:08 -0800 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: Message-ID: <6D02B16B-0DFD-4C9B-899E-8A5EB3486BA9@delong.com> > On Nov 25, 2014, at 10:56 AM, Bill Woodcock wrote: > > > On Nov 25, 2014, at 10:47 AM, Colton Conor wrote: >> I know typically peering exchanges are made for peering traffic between >> providers, but can you buy IP transit from a provider on an exchange? An >> example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple >> providers on the exchange, and buy 5Gbps of IP transit from others on the >> exchange? > > Some IXPs have a rule that explicitly disallows this, others encourage it, most don’t care. I don’t know of any that have a mechanism to enforce a rule prohibiting it. > > PCH’s guidance in the IXP formation process is to avoid creating rules which are, practically, unenforceable. So we generally counsel IXPs against having a rule precluding transit across the switch fabric. That said, a crossconnect is a _much better idea_. > >> Some might ask why not get a cross connect to the provider. It is cheaper >> to buy an port on the exchange (which includes the cross connect to the >> exchange) than buy multiple cross connects. Plus we are planning on getting >> a wave to the exchange, and not having any physical routers or switches at >> the datacenter where the exchange/wave terminates at. Is this possible? > > Yes, it’s possible, but what you describe is a pretty fragile setup. Lots of common points of failure between peering and transit; places where screwing one up would screw both up. If all of this is really tangential to whatever you’re doing, and you don’t mind looking a little out-of-step with best practices, and you don’t mind it all being down at once, any time anything breaks, then it may be a reasonable economy. If you’re planning on actually depending on it, you need to do better engineering, and either spend more money, or allocate your money more conservatively. > > Doing everything the cheapest possible way, regardless of the fragility or complexity, is very short-sighted, and is unlikely to be an economy in the long run. > > -Bill > > > > I’d say that depends… If it’s an equal cost choice, for example, between getting waves to multiple exchanges and peering with multiple providers at each exchange that way vs. putting a router at one exchange and getting cross-connects there, then I would argue that the former is actually more robust. Owen From magicsata at gmail.com Wed Dec 3 02:13:41 2014 From: magicsata at gmail.com (Alistair Mackenzie) Date: Wed, 3 Dec 2014 02:13:41 +0000 Subject: Hibernia/Atrato contacts Message-ID: Hi, Does anyone have a contact for a sales/account manager at Hibernia/Atrato located in the UK timezone or even +1? Please contact me off list with the details. Thanks, Alistair From owen at delong.com Wed Dec 3 02:16:21 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Dec 2014 18:16:21 -0800 Subject: Phasing out of copper In-Reply-To: <547898BB.80002@vaxination.ca> References: <547898BB.80002@vaxination.ca> Message-ID: <8F3258E8-2903-4099-B123-1F7BF128BF0B@delong.com> Depends on your desired outcome and goals. However… I would think that rather than trying to convince regulators that you know better than the incumbents what they intend to do, it makes more sense to explain to regulators why maintaining copper once sufficient FTTP adoption is complete is foolhearty and a waste of money. If you can show that doing so creates unnecessary costs for consumers and doesn’t preserve a meaningfully competitive environment (after all, how can your services that are limited to being delivered over copper possibly compete effectively with FTTP?), I would think that should show the regulators that regardless of what the incumbents are saying, copper’s days as a delivery mechanism are numbered and that meaningful competition in the future requires competitive access to FTTP. Most alarm systems these days simply use a POTS circuit and many are now capable of using IP service via an ethernet port, so the days of requiring a dry copper pair (ULL) for an alarm circuit are numbered. You might be able to make a case (especially in Alberta) for “Farmer Lines” still requiring dry copper pairs, but even that is kind of sketchy these days. If you’re trying to preserve access to dry copper for some reason, perhaps more information about your real goal and the real reasons behind it might help. If you’re trying to remain competitive, then I think access to unbundled fiber services is really where you should focus your efforts. Owen > On Nov 28, 2014, at 7:46 AM, Jean-Francois Mezei wrote: > > Currently in the midst of a CRTC policy hearing in Canada on future of > competition in ISPs. > > Incumbents claim they have no plans to retire their copper plant after > deploying FTTP/FTTH. (strategically to convince regulator that keeping > ISPs on copper is fine and no need to let them access FTTP). > > For my reply I am trying to get more authoritative info to show that > incumbents do have plans to retire the copper plant once enough > customers have migrated to FTTP ( I heard that 80% migration is the > tip-ver where they convert the rest of customers to FTTP to be able to > shutddown the copper). > > Anyone have pointers to documents or experiences that would help me > convince the regulator that incumbents deploy FTTP with eventual goal to > be able to shutdown their old copper instead of perpetually maintaining > both systems ? > > Also being discussed is removing regulations for access to ULL > (unbundled local loops). In areas being upgraded to FTTP, are there > services that really need copper ULLs and do not have an FTTP equivalent > ? (home alarm systems ?). > > > > > When an incumbent states for the record that "retiring copper is not in > their current plans", I know that it means that it isn't in their short > term plans. But I need some evidence of what other telcos do to help > show the incumbent is "spinning". > > Any help appreciated. From jfmezei_nanog at vaxination.ca Wed Dec 3 02:51:39 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 02 Dec 2014 21:51:39 -0500 Subject: Phasing out of copper In-Reply-To: <8F3258E8-2903-4099-B123-1F7BF128BF0B@delong.com> References: <547898BB.80002@vaxination.ca> <8F3258E8-2903-4099-B123-1F7BF128BF0B@delong.com> Message-ID: <547E7ABB.7070408@vaxination.ca> On 14-12-02 21:16, Owen DeLong wrote: > Depends on your desired outcome and goals. However… Context: Canadian incumbents deny to the regulator that they have intentions to turn off copper. (but to shareholders, openly say they will shut it donw, howveer, they plan only to shutdown active equipment and leave copper in the poles. Their fibre is hung off the same steel support line as copper). One reason is that by pretending that copper is here to stay and is competitive, they hope to convicne CRTC that mandating wholesale access to FTTP is not necessary. > > it makes more sense to explain to regulators why maintaining copper once sufficient FTTP adoption > is complete is foolhearty and a waste of money. Yeah, that is the way I am spinning it. (hey, I learn about spin from the best - the canadian incumbents :-) > If you’re trying to preserve access to dry copper for some reason, I am the only one in the whole proceeding who is advocating for the earliest possible widthdrawal fo copper. The earlier they can remove irt, the easier it is for them to justify the investment, and the less reasons they have for preventing access to FTTP. The confirmation from someone else in the thread that Comcast stops selling access to copper once FTTP is up is a good point to make. I am up on Thursday morning. Am second to last to speak, so hopefully I can make a good impression. (this is for round two, first round finished today). From joly at punkcast.com Wed Dec 3 03:23:57 2014 From: joly at punkcast.com (Joly MacFie) Date: Tue, 2 Dec 2014 22:23:57 -0500 Subject: Phasing out of copper In-Reply-To: <547E7ABB.7070408@vaxination.ca> References: <547898BB.80002@vaxination.ca> <8F3258E8-2903-4099-B123-1F7BF128BF0B@delong.com> <547E7ABB.7070408@vaxination.ca> Message-ID: Invoke Kushnick's Law * 'A regulated company will always renege on promises to provide public benefits tomorrow in exchange for regulatory and financial benefits today.'* On Tue, Dec 2, 2014 at 9:51 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 14-12-02 21:16, Owen DeLong wrote: > > Depends on your desired outcome and goals. However… > > Context: Canadian incumbents deny to the regulator that they have > intentions to turn off copper. (but to shareholders, openly say they > will shut it donw, howveer, they plan only to shutdown active equipment > and leave copper in the poles. Their fibre is hung off the same steel > support line as copper). > > One reason is that by pretending that copper is here to stay and is > competitive, they hope to convicne CRTC that mandating wholesale access > to FTTP is not necessary. > > > > > > it makes more sense to explain to regulators why maintaining copper once > sufficient FTTP adoption > > is complete is foolhearty and a waste of money. > > Yeah, that is the way I am spinning it. (hey, I learn about spin from > the best - the canadian incumbents :-) > > > If you’re trying to preserve access to dry copper for some reason, > > I am the only one in the whole proceeding who is advocating for the > earliest possible widthdrawal fo copper. The earlier they can remove > irt, the easier it is for them to justify the investment, and the less > reasons they have for preventing access to FTTP. > > The confirmation from someone else in the thread that Comcast stops > selling access to copper once FTTP is up is a good point to make. > > I am up on Thursday morning. Am second to last to speak, so hopefully I > can make a good impression. (this is for round two, first round finished > today). > -- --------------------------------------------------------------- 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 greg at phaze.org Mon Dec 1 14:36:42 2014 From: greg at phaze.org (Greg Estabrooks) Date: Mon, 01 Dec 2014 10:36:42 -0400 Subject: PeeringDB missing NOC role option? In-Reply-To: <547C7943.8090809@phaze.org> References: <547C7943.8090809@phaze.org> Message-ID: <547C7CFA.3020801@phaze.org> And to answer myself. If you select "Ops." it will display NOC as the role on the regular display page. On 14-12-01 10:20 AM, Greg Estabrooks wrote: > > > Hey All, > > > Has anyone else notice the NOC option missing from their PeeringDB contacts? > > > I went to update our contact to add a NOC contact and it's not in the drop-down of > available roles and I'm wondering if this is a problem with the site or if maybe it's Dependant on another > option I haven't selected? > > Any insight would be most appreciated. > > > > Thanks! > From pavel.odintsov at gmail.com Tue Dec 2 15:42:42 2014 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 2 Dec 2014 19:42:42 +0400 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <547121E5.4050401@gameservers.com> References: <20141122160052.4EB8855000087@freedman.net> <547121E5.4050401@gameservers.com> Message-ID: Hello, folks! Thank you for a very useful feedback! I'm so sorry for my negative vision of netflow :( It's nice protocol but I haven't equpment with ability to generate netflow on wire speed and I use mirror/SPAN instead. I competely redesigned attack-analyzer subsystem and can process sampled data now. I just added sFLOW v5 suport to FastNetMon and you can try it now. In near future I will add netflow v5 support. With sFLOW support my tool can detect attack on 40-100GE links and more! Thanks for sFLOW architecture! :) Thank you! On Sun, Nov 23, 2014 at 2:53 AM, Brian Rak wrote: > > On 11/22/2014 11:18 AM, Denys Fedoryshchenko wrote: >> >> On 2014-11-22 18:00, freedman at freedman.net wrote: >>> >>> We see a lot of Brocade for switching in hosting providers, which makes >>> sFlow easy, of course. >> >> Oh, Brocade, recent experience with ServerIron taught me new lesson, that >> i can't >> do bonding on ports as i want, it has limitations about even/odd port >> numbers and >> etc. >> Most amazing part i just forgot, that i have this ServerIron, and it is a >> place where >> i run DDoS protection (but it works perfectly over "tap" way). Thanks for >> reminding >> about this vendor :) > > > I just hope you're not talking FCX's.... if you upgrade those to 8.x > firmware, you'll lose sflow on the 10gb ports. Once you upgrade, they send > a corrupted sflow packet, and at *far* less then the rate that you > configure. Even if you adjust your parser to compensate for the corrupt > packet, they're still dropping the large majority of samples, making sflow > pretty much useless. > > It's been several months since we reported this, and we're still waiting on > a fix. -- Sincerely yours, Pavel Odintsov From pavel.odintsov at gmail.com Tue Dec 2 22:18:21 2014 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 3 Dec 2014 02:18:21 +0400 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <547121E5.4050401@gameservers.com> References: <20141122160052.4EB8855000087@freedman.net> <547121E5.4050401@gameservers.com> Message-ID: Hello, folks! Thank you for a very useful feedback! I'm so sorry for my negative vision of netflow :( It's nice protocol but I haven't equpment with ability to generate netflow on wire speed and I use mirror/SPAN instead. I competely redesigned attack-analyzer subsystem and can process sampled data now. I just added sFLOW v5 suport to FastNetMon and you can try it now. In near future I will add netflow v5 support. With sFLOW support my tool can detect attack on 40-100GE links and more! Thanks for sFLOW architecture! :) You can check new version here: https://github.com/FastVPSEestiOu/fastnetmon Thank you! On Sun, Nov 23, 2014 at 2:53 AM, Brian Rak wrote: > > On 11/22/2014 11:18 AM, Denys Fedoryshchenko wrote: >> >> On 2014-11-22 18:00, freedman at freedman.net wrote: >>> >>> We see a lot of Brocade for switching in hosting providers, which makes >>> sFlow easy, of course. >> >> Oh, Brocade, recent experience with ServerIron taught me new lesson, that >> i can't >> do bonding on ports as i want, it has limitations about even/odd port >> numbers and >> etc. >> Most amazing part i just forgot, that i have this ServerIron, and it is a >> place where >> i run DDoS protection (but it works perfectly over "tap" way). Thanks for >> reminding >> about this vendor :) > > > I just hope you're not talking FCX's.... if you upgrade those to 8.x > firmware, you'll lose sflow on the 10gb ports. Once you upgrade, they send > a corrupted sflow packet, and at *far* less then the rate that you > configure. Even if you adjust your parser to compensate for the corrupt > packet, they're still dropping the large majority of samples, making sflow > pretty much useless. > > It's been several months since we reported this, and we're still waiting on > a fix. -- Sincerely yours, Pavel Odintsov From rdobbins at arbor.net Wed Dec 3 04:57:26 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 02 Dec 2014 23:57:26 -0500 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <20141122160052.4EB8855000087@freedman.net> <547121E5.4050401@gameservers.com> Message-ID: <5921D86D-0312-414B-A894-59D79A1EFBE0@arbor.net> On 2 Dec 2014, at 17:18, Pavel Odintsov wrote: > In near future I will add netflow v5 support. Good job - you should really go for NetFlow v9 when you can, as it supports IPv6 and MPLS labels. Next would be IPFIX. ----------------------------------- Roland Dobbins From shortdudey123 at gmail.com Wed Dec 3 09:48:25 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 3 Dec 2014 01:48:25 -0800 Subject: Comcast residential DNS contact Message-ID: Can someone from Comcast that works with the customer resolvers ( cdns01.comcast.net / cdns02.comcast.net) please contact me off list? The 01 resolver is sometimes not returning complete results when the DNS query type is set to ANY for $dayjob's domain. -Grant From magicsata at gmail.com Wed Dec 3 09:58:27 2014 From: magicsata at gmail.com (Alistair Mackenzie) Date: Wed, 3 Dec 2014 09:58:27 +0000 Subject: Hibernia/Atrato contacts In-Reply-To: References: Message-ID: Thanks for the information. I've got a few contacts now and will be reaching out to them. On 3 Dec 2014 02:13, "Alistair Mackenzie" wrote: > Hi, > > Does anyone have a contact for a sales/account manager at Hibernia/Atrato > located in the UK timezone or even +1? > > Please contact me off list with the details. > > Thanks, > Alistair > From niels=nanog at bakker.net Wed Dec 3 10:51:13 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 3 Dec 2014 11:51:13 +0100 Subject: Comcast residential DNS contact In-Reply-To: References: Message-ID: <20141203105113.GA43769@excession.tpb.net> * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 10:49 CET]: >Can someone from Comcast that works with the customer resolvers ( >cdns01.comcast.net / cdns02.comcast.net) please contact me off list? >The 01 resolver is sometimes not returning complete results when the >DNS query type is set to ANY for $dayjob's domain. That's how DNS works, yes. -- Niels. From shortdudey123 at gmail.com Wed Dec 3 11:53:17 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 3 Dec 2014 03:53:17 -0800 Subject: Comcast residential DNS contact In-Reply-To: <20141203105113.GA43769@excession.tpb.net> References: <20141203105113.GA43769@excession.tpb.net> Message-ID: <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> Both of Google’s public DNS servers return complete results every time and one of the two comcast ones works fine. If this is working by design, can you provide the RFC with that info? -Grant > On Dec 3, 2014, at 2:51 AM, Niels Bakker wrote: > > * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 10:49 CET]: >> Can someone from Comcast that works with the customer resolvers ( cdns01.comcast.net / cdns02.comcast.net) please contact me off list? The 01 resolver is sometimes not returning complete results when the DNS query type is set to ANY for $dayjob's domain. > > That's how DNS works, yes. > > > -- Niels. From niels=nanog at bakker.net Wed Dec 3 12:04:42 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 3 Dec 2014 13:04:42 +0100 Subject: Comcast residential DNS contact In-Reply-To: <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> Message-ID: <20141203120442.GB43769@excession.tpb.net> * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 12:54 CET]: >Both of Google’s public DNS servers return complete results every >time and one of the two comcast ones works fine. > >If this is working by design, can you provide the RFC with that info? An ANY query will typically return only what's already in the cache. So if you ask for MX records first and then query the same caching resolver for ANY it won't return, say, any TXT records that may be present at the authoritative nameserver. This could be implementation dependent, but Comcast's isn't wrong, and you should not rely on ANY queries returning full data. This has been hashed out to tears in the past, for example when qm**l used to do these queries in an attempt to optimise DNS query volumes and RTT. -- Niels. From clayton at MNSi.Net Wed Dec 3 13:52:38 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Wed, 03 Dec 2014 08:52:38 -0500 Subject: Phasing out of copper In-Reply-To: <547E7ABB.7070408@vaxination.ca> References: <547898BB.80002@vaxination.ca> <8F3258E8-2903-4099-B123-1F7BF128BF0B@delong.com> <547E7ABB.7070408@vaxination.ca> Message-ID: <1417614760_121306@surgemail.mnsi.net> In the same breath, Bell says they want the CRTC to deregulate copper, as it is no longer essential. I know right now, that if ULLs were forborne, we would not have a suitable substitute for our co-locate served customers. In 5 to 10 years, that might be a different story, but today it is not. Bell wants the freedom to deploy fibre networks without mandated wholesale but also wants to de-regulate copper loops while still using them for their own purposes as long as is convenient simply because for 99% of the customers today, DSL speeds are what they choose, and copper loops for now are the most cost effective way to provide those speeds or just plain dialtone. A bit of a have your cake & eat it too attitude, which is exactly what I expect from Bell. At 09:51 PM 02/12/2014, Jean-Francois Mezei wrote: >One reason is that by pretending that copper is here to stay and is >competitive, they hope to convicne CRTC that mandating wholesale access >to FTTP is not necessary. > > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From list at satchell.net Wed Dec 3 14:08:46 2014 From: list at satchell.net (Stephen Satchell) Date: Wed, 03 Dec 2014 06:08:46 -0800 Subject: Comcast residential DNS contact In-Reply-To: <20141203120442.GB43769@excession.tpb.net> References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> Message-ID: <547F196E.3080200@satchell.net> On 12/03/2014 04:04 AM, Niels Bakker wrote: > * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 12:54 CET]: >> Both of Google’s public DNS servers return complete results every time >> and one of the two comcast ones works fine. >> >> If this is working by design, can you provide the RFC with that info? > > An ANY query will typically return only what's already in the cache. So > if you ask for MX records first and then query the same caching resolver > for ANY it won't return, say, any TXT records that may be present at the > authoritative nameserver. > > This could be implementation dependent, but Comcast's isn't wrong, and > you should not rely on ANY queries returning full data. This has been > hashed out to tears in the past, for example when qm**l used to do these > queries in an attempt to optimise DNS query volumes and RTT. At the ISP I consult to, I filter all ANY queries, because they have been used for DNS amplification attacks. From pavel.odintsov at gmail.com Wed Dec 3 14:44:20 2014 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 3 Dec 2014 18:44:20 +0400 Subject: Comcast residential DNS contact In-Reply-To: <547F196E.3080200@satchell.net> References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> Message-ID: Hello! But any other DNS type can be used for DNS amplification. RRL is right solution for amplification issue. I recommend NSD DNS server because it's reliable, has complete support of DNSSEC, IPv6 and RRL. On Wed, Dec 3, 2014 at 5:08 PM, Stephen Satchell wrote: > On 12/03/2014 04:04 AM, Niels Bakker wrote: >> * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 12:54 CET]: >>> Both of Google’s public DNS servers return complete results every time >>> and one of the two comcast ones works fine. >>> >>> If this is working by design, can you provide the RFC with that info? >> >> An ANY query will typically return only what's already in the cache. So >> if you ask for MX records first and then query the same caching resolver >> for ANY it won't return, say, any TXT records that may be present at the >> authoritative nameserver. >> >> This could be implementation dependent, but Comcast's isn't wrong, and >> you should not rely on ANY queries returning full data. This has been >> hashed out to tears in the past, for example when qm**l used to do these >> queries in an attempt to optimise DNS query volumes and RTT. > > At the ISP I consult to, I filter all ANY queries, because they have > been used for DNS amplification attacks. > -- Sincerely yours, Pavel Odintsov From jared at puck.nether.net Wed Dec 3 15:28:29 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 3 Dec 2014 10:28:29 -0500 Subject: Comcast residential DNS contact In-Reply-To: <547F196E.3080200@satchell.net> References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> Message-ID: <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> So have A record queries. Do you filter those as well? Jared Mauch > On Dec 3, 2014, at 9:08 AM, Stephen Satchell wrote: > >> On 12/03/2014 04:04 AM, Niels Bakker wrote: >> * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 12:54 CET]: >>> Both of Google’s public DNS servers return complete results every time >>> and one of the two comcast ones works fine. >>> >>> If this is working by design, can you provide the RFC with that info? >> >> An ANY query will typically return only what's already in the cache. So >> if you ask for MX records first and then query the same caching resolver >> for ANY it won't return, say, any TXT records that may be present at the >> authoritative nameserver. >> >> This could be implementation dependent, but Comcast's isn't wrong, and >> you should not rely on ANY queries returning full data. This has been >> hashed out to tears in the past, for example when qm**l used to do these >> queries in an attempt to optimise DNS query volumes and RTT. > > At the ISP I consult to, I filter all ANY queries, because they have > been used for DNS amplification attacks. From list at satchell.net Wed Dec 3 15:45:48 2014 From: list at satchell.net (Stephen Satchell) Date: Wed, 03 Dec 2014 07:45:48 -0800 Subject: Comcast residential DNS contact In-Reply-To: <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> Message-ID: <547F302C.4060200@satchell.net> No. When I've been victim of DNS amplification attacks, the packet capture showed that the attacker used ANY queries. Legit ANY queries on my recursive servers? Damn few. So I block. Not so on my authoritative servers, where ANY queries on the domains I host zone files for have not caused any problems, for anyone. Another thing I did was slow down the port for my recursive DNS servers to 10 megabits/s. That means that my upstream link can't be saturated by DNS amplification. Oh, and I rate-limit incoming queries to my DNS servers by IP address range -- an attack from one subnet won't affect queries from other parts of the net. Queries from my IP address range have a high cap; J random IP addresses have a lower cap. On 12/03/2014 07:28 AM, Jared Mauch wrote: > So have A record queries. Do you filter those as well? > > Jared Mauch > >> On Dec 3, 2014, at 9:08 AM, Stephen Satchell wrote: >> >>> On 12/03/2014 04:04 AM, Niels Bakker wrote: >>> * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 12:54 CET]: >>>> Both of Google’s public DNS servers return complete results every time >>>> and one of the two comcast ones works fine. >>>> >>>> If this is working by design, can you provide the RFC with that info? >>> >>> An ANY query will typically return only what's already in the cache. So >>> if you ask for MX records first and then query the same caching resolver >>> for ANY it won't return, say, any TXT records that may be present at the >>> authoritative nameserver. >>> >>> This could be implementation dependent, but Comcast's isn't wrong, and >>> you should not rely on ANY queries returning full data. This has been >>> hashed out to tears in the past, for example when qm**l used to do these >>> queries in an attempt to optimise DNS query volumes and RTT. >> >> At the ISP I consult to, I filter all ANY queries, because they have >> been used for DNS amplification attacks. From brak at gameservers.com Wed Dec 3 15:46:49 2014 From: brak at gameservers.com (Brian Rak) Date: Wed, 03 Dec 2014 10:46:49 -0500 Subject: Comcast residential DNS contact In-Reply-To: <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> Message-ID: <547F3069.20602@gameservers.com> Shouldn't everyone be on IPv6 these days anyway ;) On 12/3/2014 10:28 AM, Jared Mauch wrote: > So have A record queries. Do you filter those as well? > > Jared Mauch > >> On Dec 3, 2014, at 9:08 AM, Stephen Satchell wrote: >> >>> On 12/03/2014 04:04 AM, Niels Bakker wrote: >>> * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 12:54 CET]: >>>> Both of Google’s public DNS servers return complete results every time >>>> and one of the two comcast ones works fine. >>>> >>>> If this is working by design, can you provide the RFC with that info? >>> An ANY query will typically return only what's already in the cache. So >>> if you ask for MX records first and then query the same caching resolver >>> for ANY it won't return, say, any TXT records that may be present at the >>> authoritative nameserver. >>> >>> This could be implementation dependent, but Comcast's isn't wrong, and >>> you should not rely on ANY queries returning full data. This has been >>> hashed out to tears in the past, for example when qm**l used to do these >>> queries in an attempt to optimise DNS query volumes and RTT. >> At the ISP I consult to, I filter all ANY queries, because they have >> been used for DNS amplification attacks. From Jason_Livingood at cable.comcast.com Wed Dec 3 16:04:17 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 3 Dec 2014 16:04:17 +0000 Subject: Comcast residential DNS contact In-Reply-To: <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> Message-ID: On 12/3/14, 6:53 AM, "Grant Ridder" wrote: >Both of Google¹s public DNS servers return complete results every time >and one of the two comcast ones works fine. > >If this is working by design, can you provide the RFC with that info? Comparing different resolvers often compares how the different developers of DNS software have chosen to implement the RFCs. I¹m curious what the exact query is. Jason Livingood Comcast PS - I emailed you off-list. From notify.sina at gmail.com Wed Dec 3 16:22:58 2014 From: notify.sina at gmail.com (Notify Me) Date: Wed, 3 Dec 2014 17:22:58 +0100 Subject: How to track DNS resolution sources Message-ID: Hi! I hope I'm wording this correctly. I had a incident at a client site where a DNS record was being spoofed. How does one track down the IP address that's returning the false records ? What tool can one use? Thanks! -- Sent from MetroMail From tshaw at oitc.com Wed Dec 3 16:32:08 2014 From: tshaw at oitc.com (TR Shaw) Date: Wed, 3 Dec 2014 11:32:08 -0500 Subject: How to track DNS resolution sources In-Reply-To: References: Message-ID: On the command line: host spoofed.host.name.com On Dec 3, 2014, at 11:22 AM, Notify Me wrote: > Hi! > > I hope I'm wording this correctly. I had a incident at a client site where > a DNS record was being spoofed. How does one track down the IP address > that's returning the false records ? What tool can one use? > > Thanks! > > > > > -- > Sent from MetroMail From bortzmeyer at nic.fr Wed Dec 3 16:56:23 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 3 Dec 2014 17:56:23 +0100 Subject: How to track DNS resolution sources In-Reply-To: References: Message-ID: <20141203165623.GA13619@laperouse.bortzmeyer.org> On Wed, Dec 03, 2014 at 05:22:58PM +0100, Notify Me wrote a message of 13 lines which said: > I hope I'm wording this correctly. Not really :-) > I had a incident at a client site where a DNS record was being > spoofed. How do you know? What steps did you use to assert this? Answers to these questions would help to understand your problem. > How does one track down the IP address that's returning the false > records ? If it's real DNS spoofing (which I doubt), the source IP address of the poisoner is forged, so it would not help. The main tool to use is dig. Let's assume the name that bothers you is foobar.example.com. Query your local resolver: dig A foobar.example.com Query an external resolver, here Google Public DNS: dig @8.8.4.4 A foobar.example.com Query the authoritative name servers of example.com. First, to find them: dig NS example.com Second, query them (replace the server name by the real one): dig @a.iana-servers.net. A foobar.example.com From maxtul at netassist.ua Wed Dec 3 16:57:03 2014 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 03 Dec 2014 18:57:03 +0200 Subject: Google contact: apps vs IPv6 issue Message-ID: <547F40DF.40603@netassist.ua> Hello! Could someone advice a good contact inside Google? I'm operating a IPv6 tunnel broker http://tb.netassist.ua/ Now there are a number of complaints tunnel broker users can't access Google Apps with the reason "We're sorry, but this service is not available in your country". IPv4 access to same pages from Ukraine is OK, and MaxMind GeoIP replies our IPv6 network we are using in our service is "NetAssist, Ukraine". From bortzmeyer at nic.fr Wed Dec 3 17:02:01 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 3 Dec 2014 18:02:01 +0100 Subject: How to track DNS resolution sources In-Reply-To: References: Message-ID: <20141203170201.GA14013@laperouse.bortzmeyer.org> On Wed, Dec 03, 2014 at 11:32:08AM -0500, TR Shaw wrote a message of 20 lines which said: > On the command line: > > host spoofed.host.name.com Excuse me but it is useless. It tests only the local resolver (which may be unpoisoned). It provides no details that could help to debug the problem (such as the TTL). From jeroen at massar.ch Wed Dec 3 17:27:16 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 03 Dec 2014 18:27:16 +0100 Subject: Google contact: apps vs IPv6 issue In-Reply-To: <547F40DF.40603@netassist.ua> References: <547F40DF.40603@netassist.ua> Message-ID: <547F47F4.4000501@massar.ch> On 2014-12-03 17:57, Max Tulyev wrote: > Hello! > > Could someone advice a good contact inside Google? noc at google.com is where this stuff has to go. They claim to read it (and mostly they do in time). > I'm operating a IPv6 tunnel broker http://tb.netassist.ua/ > > Now there are a number of complaints tunnel broker users can't access > Google Apps with the reason "We're sorry, but this service is not > available in your country". That is likely as your address space has shown users with cookies from a variety of locations not matching where you claim they are coming. Note that Happy Eyeballs causes folks to use IPv4 + IPv6 and thus mismatches are easily caught by sites that care to pay attention to that. > IPv4 access to same pages from Ukraine is OK, and MaxMind GeoIP replies > our IPv6 network we are using in our service is "NetAssist, Ukraine". You might want to implement: http://tools.ietf.org/html/draft-google-self-published-geofeeds-02 See also for a bit more user-sided detail: https://www.sixxs.net/faq/misc/?faq=geolocation Do note that you need to have a good trust factor there for Google to accept the geofeed. Greets, Jeroen From owen at delong.com Wed Dec 3 17:51:14 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Dec 2014 09:51:14 -0800 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <20141129201745.30066.qmail@ary.lan> References: <20141129201745.30066.qmail@ary.lan> Message-ID: There’s a big difference between illegal and civil liability for breech of contract. If I am paying someone for access to the internet, then I expect them not to modify, alter, rewrite, or otherwise interfere with my packets. If they do so, they may not have violated 47 USC 230, but they have certainly failed to provide the service that I am paying for. Owen > On Nov 29, 2014, at 12:17 PM, John Levine wrote: > >> i think of it as an intentional traffic hijack. i would be talking to a >> lawyer. > > If the lawyer says anything other than that 47 USC 230(c)(2)(A) > provides broad immunity for ISP content filtering, even if the filters > sometimes screw up, you need a new lawyer. > > Filtering STARTTLS on port 587 is pretty stupid, but not everything > that's stupid is illegal. > > R's, > John > > PS: I know enough technical people at Comcast that I would be > extremely surprised if it were Comcast doing this. There's plenty not > to like about the corporation, but the technical staff are quite > competent. From owen at delong.com Wed Dec 3 17:48:08 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Dec 2014 09:48:08 -0800 Subject: Transparent hijacking of SMTP submission... In-Reply-To: References: <54778167.7080808@bogus.com> <84B714C0-D429-4245-96D0-33BFF0D62CF1@steffann.nl> <547A01E3.1030702@vaxination.ca> Message-ID: I suspect it isn’t comcast at all. I suspect it is the wifi operator and they happen to use comcast as an upstream. The RDNS points to the public address in front of the wifi. The proxy doing the rewriting is likely behind that. Owen > On Nov 29, 2014, at 10:46 AM, Christopher Morrow wrote: > > backing up a bit in the conversation, perhaps this is just in some > regions of comcastlandia? I don't see this in Northern Virginia... > > $ openssl s_client -starttls smtp -connect my-mailserver.net:587 > CONNECTED(00000003) > depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = > my-mailserver.net, emailAddress = my-emailaddrss.com > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = my-mailsever.net, > emailAddress = my-emailaddress.com > verify error:num=27:certificate not trusted > verify return:1 > depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = > my-mailserver.net, emailAddress = my-emailaddress.com > verify error:num=21:unable to verify the first certificate > verify return:1 > > ... > > Certificate chain > 0 s:/description=kVjtrCL8rUdvd00q/C=US/CN=my-mailserver.net/emailAddress=y-emailaddress.com > i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate > Signing/CN=StartCom Class 1 Primary Intermediate Server CA > > ... > > New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1.2 > Cipher : ECDHE-RSA-AES256-GCM-SHA384 > Session-ID: FC3E47AF2A2A96BF6DE6E11F96B02A0C41A6542864271F2901F09594DE9A48FA > Session-ID-ctx: > Master-Key: > BE7FB76EF5C0A9BA507B175026F73E67080D6442201FDF28F536FA38197A9B1353D644EEAF8D0D264328F94B2EF5742C > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1417286582 > Timeout : 300 (sec) > Verify return code: 21 (unable to verify the first certificate) > --- > 250 DSN > ehlo me > 250-my-mailserver.net > 250-PIPELINING > > > On Sat, Nov 29, 2014 at 12:26 PM, Jean-Francois Mezei > wrote: >> On 14-11-29 11:07, Sander Steffann wrote: >> >>> I am so glad that our Dutch net neutrality laws state that "providers of Internet access services may not hinder or delay any services or applications on the Internet" (unless [...], but those exceptions make sense) >> >> >> However, in the case of SMTP, due to the amount of spam, most ISPs break >> "network neutrality" by blocking outbound port 25 for instance, and >> their SMTP servers will block much incoming emails (spam). However, >> SMTP is a layer or two above the network. But blocking port 25 is at the >> network level. >> >> I have seen wi-fi systems where you ask to connect to 20.21.22.23 port >> 25, and you get connected to 50.51.52.53 port 25. (the ISPs own SMTP >> server). I would rather they just block it than redirect you without >> warning to an SMTP server of their own where they can look and your >> outbound email, pretend to acccept it, and never deliver it. >> >> >> From shortdudey123 at gmail.com Wed Dec 3 17:54:03 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 3 Dec 2014 09:54:03 -0800 Subject: Comcast residential DNS contact In-Reply-To: <547F3069.20602@gameservers.com> References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> <547F3069.20602@gameservers.com> Message-ID: Hi Everyone, Thanks for the replies! After reading them, i am doing some digging into DNS RFC's and haven't found much with respect to ANY queries. Not responding with full results to protect against being used in an attack makes sense. However, I find it odd that only 1 of the 4 anycast servers I tried would institute this. Also, as a side note, i hit all 4 anycast servers on both v4 and v6 with similar results already. -Grant On Wed, Dec 3, 2014 at 7:46 AM, Brian Rak wrote: > Shouldn't everyone be on IPv6 these days anyway ;) > > > On 12/3/2014 10:28 AM, Jared Mauch wrote: > >> So have A record queries. Do you filter those as well? >> >> Jared Mauch >> >> On Dec 3, 2014, at 9:08 AM, Stephen Satchell wrote: >>> >>> On 12/03/2014 04:04 AM, Niels Bakker wrote: >>>> * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 12:54 CET]: >>>> >>>>> Both of Google’s public DNS servers return complete results every time >>>>> and one of the two comcast ones works fine. >>>>> >>>>> If this is working by design, can you provide the RFC with that info? >>>>> >>>> An ANY query will typically return only what's already in the cache. So >>>> if you ask for MX records first and then query the same caching resolver >>>> for ANY it won't return, say, any TXT records that may be present at the >>>> authoritative nameserver. >>>> >>>> This could be implementation dependent, but Comcast's isn't wrong, and >>>> you should not rely on ANY queries returning full data. This has been >>>> hashed out to tears in the past, for example when qm**l used to do these >>>> queries in an attempt to optimise DNS query volumes and RTT. >>>> >>> At the ISP I consult to, I filter all ANY queries, because they have >>> been used for DNS amplification attacks. >>> >> > From jared at puck.nether.net Wed Dec 3 17:58:20 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 3 Dec 2014 12:58:20 -0500 Subject: Comcast residential DNS contact In-Reply-To: <547F302C.4060200@satchell.net> References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> <547F302C.4060200@satchell.net> Message-ID: > On Dec 3, 2014, at 10:45 AM, Stephen Satchell wrote: > > No. When I've been victim of DNS amplification attacks, the packet > capture showed that the attacker used ANY queries. Legit ANY queries on > my recursive servers? Damn few. So I block. Not so on my > authoritative servers, where ANY queries on the domains I host zone > files for have not caused any problems, for anyone. > > Another thing I did was slow down the port for my recursive DNS servers > to 10 megabits/s. That means that my upstream link can't be saturated > by DNS amplification. Oh, and I rate-limit incoming queries to my DNS > servers by IP address range -- an attack from one subnet won't affect > queries from other parts of the net. Queries from my IP address range > have a high cap; J random IP addresses have a lower cap. You should not filter the any queries, perhaps you want to TC=1 them. I created a patch for bind for this purpose. http://puck.nether.net/~jared/bind-9.9.3rc2-tcp-any.patch I’ve seen many of these attacks, they will use MX/TXT/A and other records. You may want to look at some of the public resources for this, e.g.: http://dnsamplificationattacks.blogspot.nl/ is a good one and for the git lovers: https://github.com/smurfmonitor/dns-iptables-rules/blob/master/domain-blacklist.txt or https://github.com/smurfmonitor/dns-iptables-rules/blob/master/domain-blacklist-string.txt - Jared From shortdudey123 at gmail.com Wed Dec 3 18:07:04 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 3 Dec 2014 10:07:04 -0800 Subject: Comcast residential DNS contact In-Reply-To: References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> <547F3069.20602@gameservers.com> Message-ID: Did more digging and found the RFC regarding ANY queries: 3.2.3 - * 255 A request for all records https://www.ietf.org/rfc/rfc1035.txt However Wikipedia (http://en.wikipedia.org/wiki/List_of_DNS_record_types) lists this as a request for "All cached records" instead of "A request for all records" per the RFC. -Grant On Wed, Dec 3, 2014 at 9:54 AM, Grant Ridder wrote: > Hi Everyone, > > Thanks for the replies! After reading them, i am doing some digging into > DNS RFC's and haven't found much with respect to ANY queries. Not > responding with full results to protect against being used in an attack > makes sense. However, I find it odd that only 1 of the 4 anycast servers I > tried would institute this. > > Also, as a side note, i hit all 4 anycast servers on both v4 and v6 with > similar results already. > > -Grant > > On Wed, Dec 3, 2014 at 7:46 AM, Brian Rak wrote: > >> Shouldn't everyone be on IPv6 these days anyway ;) >> >> >> On 12/3/2014 10:28 AM, Jared Mauch wrote: >> >>> So have A record queries. Do you filter those as well? >>> >>> Jared Mauch >>> >>> On Dec 3, 2014, at 9:08 AM, Stephen Satchell wrote: >>>> >>>> On 12/03/2014 04:04 AM, Niels Bakker wrote: >>>>> * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 12:54 CET]: >>>>> >>>>>> Both of Google’s public DNS servers return complete results every time >>>>>> and one of the two comcast ones works fine. >>>>>> >>>>>> If this is working by design, can you provide the RFC with that info? >>>>>> >>>>> An ANY query will typically return only what's already in the cache. >>>>> So >>>>> if you ask for MX records first and then query the same caching >>>>> resolver >>>>> for ANY it won't return, say, any TXT records that may be present at >>>>> the >>>>> authoritative nameserver. >>>>> >>>>> This could be implementation dependent, but Comcast's isn't wrong, and >>>>> you should not rely on ANY queries returning full data. This has been >>>>> hashed out to tears in the past, for example when qm**l used to do >>>>> these >>>>> queries in an attempt to optimise DNS query volumes and RTT. >>>>> >>>> At the ISP I consult to, I filter all ANY queries, because they have >>>> been used for DNS amplification attacks. >>>> >>> >> > From dougb at dougbarton.us Wed Dec 3 18:30:49 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 03 Dec 2014 10:30:49 -0800 Subject: Comcast residential DNS contact In-Reply-To: References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> <547F3069.20602@gameservers.com> Message-ID: <547F56D9.5010304@dougbarton.us> On 12/3/14 10:07 AM, Grant Ridder wrote: > Did more digging and found the RFC regarding ANY queries: > > 3.2.3 - * 255 A request for all records > https://www.ietf.org/rfc/rfc1035.txt When listing URLs for RFCs it's better to use the tools site, as it gives a much better experience: https://tools.ietf.org/html/rfc1035 Meanwhile, the text is correct, but what you're missing is the nuance of authoritative vs. recursive. If you send an ANY query to an authoritative server it is naturally going to send you all of the related records, since it has them all. A recursive (or iterative if you prefer) server only has what it has in the cache, but it will send you "all records" that it has. What this does not imply is that the recursive server will go out and do its own ANY query for the RR you're asking about, unless there is nothing in the cache to start with. There are any number of explanations for why some of the recursive servers you're querying have more records than others. None of them are bugs. :) > However Wikipedia (http://en.wikipedia.org/wiki/List_of_DNS_record_types) > lists this as a request for "All cached records" instead of "A request for > all records" per the RFC. Wikipedia is good for a lot of things, but standards work is not one of them. :) The text above is a good example of why. Doug From johnl at iecc.com Wed Dec 3 18:33:15 2014 From: johnl at iecc.com (John R. Levine) Date: 3 Dec 2014 13:33:15 -0500 Subject: Transparent hijacking of SMTP submission... In-Reply-To: References: <20141129201745.30066.qmail@ary.lan> Message-ID: > There’s a big difference between illegal and civil liability for breech of contract. > > If I am paying someone for access to the internet, then I expect them not to modify, alter, rewrite, or otherwise interfere with my packets. > > If they do so, they may not have violated 47 USC 230, but they have certainly failed to provide the service that I am paying for. Uh huh. Please let us know the case number when you sue, so we can find out howthat pans out. By the way, I see you're a customer of Black Lotus. You might want to review sections 7 and 10 of the terms of service to which you've agreed: https://www.blacklotus.net/terms-of-service/ Your v6 traffic appears to arrive via a tunnel at HE. See sections 9 and 10 here, which you've also agreed to: http://www.he.net/tos.html R's, John From morrowc.lists at gmail.com Wed Dec 3 18:37:06 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 3 Dec 2014 13:37:06 -0500 Subject: Comcast residential DNS contact In-Reply-To: References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> <547F3069.20602@gameservers.com> Message-ID: On Wed, Dec 3, 2014 at 12:54 PM, Grant Ridder wrote: > Hi Everyone, > > Thanks for the replies! After reading them, i am doing some digging into > DNS RFC's and haven't found much with respect to ANY queries. Not > responding with full results to protect against being used in an attack > makes sense. However, I find it odd that only 1 of the 4 anycast servers I > tried would institute this. it's possible (jason hinted at this) that the servers in question are not a homogeneous software set... and have different behaviour being displayed because of that. Also, just because you sent a packet to 4 different ip addresses doesn't mean that they didn't end up on one or some of the same hosts behind loadbalancers/ecmp/etc, right? (so it's not clear you are/can test this properly from your vantage point) -chris (what's a bit concerning is my comcast link's not able to talk to cdns02 at all... over ipv4 at least, v6 works, thankfully I suppose) From asullivan at dyn.com Wed Dec 3 18:39:11 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 3 Dec 2014 13:39:11 -0500 Subject: Comcast residential DNS contact In-Reply-To: References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> <547F3069.20602@gameservers.com> Message-ID: <20141203183910.GL18366@dyn.com> On Wed, Dec 03, 2014 at 10:07:04AM -0800, Grant Ridder wrote: > Did more digging and found the RFC regarding ANY queries: > > 3.2.3 - * 255 A request for all records > https://www.ietf.org/rfc/rfc1035.txt > > However Wikipedia (http://en.wikipedia.org/wiki/List_of_DNS_record_types) > lists this as a request for "All cached records" instead of "A request for > all records" per the RFC. Those two turn out to mean the same thing in the way the DNS community has come to understand the semantics of the * query. A resolver that has a cache is able to answer the query for * by consulting its cache. There is no signal in the DNS that there are records for other RRTYPEs at the same owner name and class, so the resolver is in a position to answer the question, and so it does. Certainly, the authoritative resolver will always give you every record at that owner name and class in the authoritative zone in the event you asked that. Also, you probably want to look at RFC 4592, which considerably expands the treatment of wildcards in the DNS. Best regards, A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From khelms at zcorum.com Wed Dec 3 18:41:49 2014 From: khelms at zcorum.com (Scott Helms) Date: Wed, 3 Dec 2014 13:41:49 -0500 Subject: Comcast residential DNS contact In-Reply-To: References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> <547F3069.20602@gameservers.com> Message-ID: It's also entirely possible that the behavior observed will change because of testing. The more a test looks different from "normal" residential traffic the more likely that it's going to be handled differently. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Wed, Dec 3, 2014 at 1:37 PM, Christopher Morrow wrote: > On Wed, Dec 3, 2014 at 12:54 PM, Grant Ridder > wrote: > > Hi Everyone, > > > > Thanks for the replies! After reading them, i am doing some digging into > > DNS RFC's and haven't found much with respect to ANY queries. Not > > responding with full results to protect against being used in an attack > > makes sense. However, I find it odd that only 1 of the 4 anycast > servers I > > tried would institute this. > > it's possible (jason hinted at this) that the servers in question are > not a homogeneous software set... and have different behaviour being > displayed because of that. > > Also, just because you sent a packet to 4 different ip addresses > doesn't mean that they didn't end up on one or some of the same hosts > behind loadbalancers/ecmp/etc, right? (so it's not clear you are/can > test this properly from your vantage point) > > -chris > > (what's a bit concerning is my comcast link's not able to talk to > cdns02 at all... over ipv4 at least, v6 works, thankfully I suppose) > From wesley.george at twcable.com Wed Dec 3 18:45:40 2014 From: wesley.george at twcable.com (George, Wes) Date: Wed, 3 Dec 2014 13:45:40 -0500 Subject: IPligence contact? Message-ID: if anyone has a live-person contact at geolocation provider IPligence (http://www.ipligence.com/) and can hit me up off-list, I would appreciate it. Thanks, Wesley George Time Warner Cable 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 shortdudey123 at gmail.com Wed Dec 3 19:37:28 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 3 Dec 2014 11:37:28 -0800 Subject: Comcast residential DNS contact In-Reply-To: <547F56D9.5010304@dougbarton.us> References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> <547F3069.20602@gameservers.com> <547F56D9.5010304@dougbarton.us> Message-ID: Ah that makes sense. I am not going to worry about the inconstancy then. Thanks to everyone that replied!! -Grant On Wed, Dec 3, 2014 at 10:30 AM, Doug Barton wrote: > On 12/3/14 10:07 AM, Grant Ridder wrote: > >> Did more digging and found the RFC regarding ANY queries: >> >> 3.2.3 - * 255 A request for all records >> https://www.ietf.org/rfc/rfc1035.txt >> > > When listing URLs for RFCs it's better to use the tools site, as it gives > a much better experience: > > https://tools.ietf.org/html/rfc1035 > > Meanwhile, the text is correct, but what you're missing is the nuance of > authoritative vs. recursive. If you send an ANY query to an authoritative > server it is naturally going to send you all of the related records, since > it has them all. > > A recursive (or iterative if you prefer) server only has what it has in > the cache, but it will send you "all records" that it has. What this does > not imply is that the recursive server will go out and do its own ANY query > for the RR you're asking about, unless there is nothing in the cache to > start with. > > There are any number of explanations for why some of the recursive servers > you're querying have more records than others. None of them are bugs. :) > > However Wikipedia (http://en.wikipedia.org/wiki/List_of_DNS_record_types) >> lists this as a request for "All cached records" instead of "A request for >> all records" per the RFC. >> > > Wikipedia is good for a lot of things, but standards work is not one of > them. :) The text above is a good example of why. > > Doug > > From sfrost at snowman.net Wed Dec 3 20:12:44 2014 From: sfrost at snowman.net (Stephen Frost) Date: Wed, 3 Dec 2014 15:12:44 -0500 Subject: Comcast IPv6 issues..? Message-ID: <20141203201244.GK3342@tamriel.snowman.net> Hey all, Getting delays and seeing some pretty funky routes inside Comcast. All traces start from Ashburn, VA (2001:4830:167b::) and go to Chicago, IL (2610:150:4b0f::). Coming from Occaid/SIXXS (over a tunnel) through HE.net and have seen: Ashburn -> San Jose -> New York -> Chicago ----- 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.955 ms 10.583 ms 10.17 ms 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.726 ms 11.004 ms 9.956 ms 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 10.069 ms 10.674 ms 12.465 ms 6 2001:559::db5 (2001:559::db5) 94.83 ms 95.593 ms 94.768 ms 7 pos-2-2-0-0-cr01.sanjose.ca.ibone.comcast.net (2001:558:0:f58d::1) 96.779 ms 99.591 ms 94.964 ms 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) 89.969 ms 91.143 ms 92.507 ms 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net (2001:558:0:f5b8::2) 97.411 ms 88.731 ms 87.457 ms 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net (2001:558:0:f8cc::2) 87.444 ms 88.756 ms 87.505 ms 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 89.812 ms 88.774 ms 87.558 ms ----- Ashburn -> New York (but with lots of latency..) -> Chicago ----- 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.549 ms 10.652 ms 10.107 ms 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.975 ms 11.044 ms 10.009 ms 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 17.423 ms 11.05 ms 12.27 ms 6 2001:559::db5 (2001:559::db5) 95.197 ms 95.968 ms 94.793 ms 7 he-2-6-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f8d2::1) 105.158 ms 101.428 ms 94.993 ms 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) 89.735 ms 90.266 ms 92.577 ms 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net (2001:558:0:f5b8::2) 89.813 ms 92.963 ms 92.383 ms 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net (2001:558:0:f8cc::2) 87.401 ms 88.15 ms 87.085 ms 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 122.387 ms 124.288 ms 122.409 ms ----- Ashburn -> Chicago -> New York -> Chicago ----- 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.926 ms 10.183 ms 9.978 ms 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.961 ms 11.37 ms 9.973 ms 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 9.95 ms 18.258 ms 9.951 ms 6 2001:559::db5 (2001:559::db5) 94.959 ms 96.413 ms 95.001 ms 7 he-1-10-0-0-cr01.chicago.il.ibone.comcast.net (2001:558:0:f552::1) 92.457 ms 92.964 ms 89.965 ms 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) 89.789 ms 91.291 ms 97.333 ms 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net (2001:558:0:f5b8::2) 87.518 ms 95.961 ms 87.506 ms 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net (2001:558:0:f8cc::2) 87.406 ms 86.414 ms 87.425 ms 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 87.517 ms 86.589 ms 87.506 ms ----- Thoughts? Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From smeuse at mara.org Wed Dec 3 20:34:39 2014 From: smeuse at mara.org (Steve Meuse) Date: Wed, 3 Dec 2014 15:34:39 -0500 Subject: Comcast IPv6 issues..? In-Reply-To: <20141203201244.GK3342@tamriel.snowman.net> References: <20141203201244.GK3342@tamriel.snowman.net> Message-ID: It's likely a reverse DNS error. If you look at the latency, it's within range of the previous hops. -Steve On Wed, Dec 3, 2014 at 3:12 PM, Stephen Frost wrote: > Hey all, > > Getting delays and seeing some pretty funky routes inside Comcast. > All traces start from Ashburn, VA (2001:4830:167b::) and go to > Chicago, IL (2610:150:4b0f::). > > Coming from Occaid/SIXXS (over a tunnel) through HE.net and have seen: > > Ashburn -> San Jose -> New York -> Chicago > ----- > 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.955 ms > 10.583 ms 10.17 ms > 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.726 ms 11.004 ms > 9.956 ms > 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 10.069 > ms 10.674 ms 12.465 ms > 6 2001:559::db5 (2001:559::db5) 94.83 ms 95.593 ms 94.768 ms > 7 pos-2-2-0-0-cr01.sanjose.ca.ibone.comcast.net (2001:558:0:f58d::1) > 96.779 ms 99.591 ms 94.964 ms > 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) > 89.969 ms 91.143 ms 92.507 ms > 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net > (2001:558:0:f5b8::2) 97.411 ms 88.731 ms 87.457 ms > 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net > (2001:558:0:f8cc::2) 87.444 ms 88.756 ms 87.505 ms > 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 89.812 ms 88.774 ms 87.558 > ms > ----- > > Ashburn -> New York (but with lots of latency..) -> Chicago > ----- > 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.549 ms > 10.652 ms 10.107 ms > 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.975 ms 11.044 ms > 10.009 ms > 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 17.423 > ms 11.05 ms 12.27 ms > 6 2001:559::db5 (2001:559::db5) 95.197 ms 95.968 ms 94.793 ms > 7 he-2-6-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f8d2::1) > 105.158 ms 101.428 ms 94.993 ms > 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) > 89.735 ms 90.266 ms 92.577 ms > 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net > (2001:558:0:f5b8::2) 89.813 ms 92.963 ms 92.383 ms > 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net > (2001:558:0:f8cc::2) 87.401 ms 88.15 ms 87.085 ms > 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 122.387 ms 124.288 ms > 122.409 ms > ----- > > Ashburn -> Chicago -> New York -> Chicago > ----- > 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.926 ms > 10.183 ms 9.978 ms > 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.961 ms 11.37 ms > 9.973 ms > 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 9.95 > ms 18.258 ms 9.951 ms > 6 2001:559::db5 (2001:559::db5) 94.959 ms 96.413 ms 95.001 ms > 7 he-1-10-0-0-cr01.chicago.il.ibone.comcast.net (2001:558:0:f552::1) > 92.457 ms 92.964 ms 89.965 ms > 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) > 89.789 ms 91.291 ms 97.333 ms > 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net > (2001:558:0:f5b8::2) 87.518 ms 95.961 ms 87.506 ms > 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net > (2001:558:0:f8cc::2) 87.406 ms 86.414 ms 87.425 ms > 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 87.517 ms 86.589 ms 87.506 > ms > ----- > > Thoughts? > > Thanks, > > Stephen > From sfrost at snowman.net Wed Dec 3 20:40:34 2014 From: sfrost at snowman.net (Stephen Frost) Date: Wed, 3 Dec 2014 15:40:34 -0500 Subject: Comcast IPv6 issues..? In-Reply-To: References: <20141203201244.GK3342@tamriel.snowman.net> Message-ID: <20141203204034.GM3342@tamriel.snowman.net> * Steve Meuse (smeuse at mara.org) wrote: > It's likely a reverse DNS error. If you look at the latency, it's within > range of the previous hops. Still curious that the systems (IPv6 addresses) are changing too.. It's not like it's the same route but just different rDNS results. It's also quite a bit of latency between he.net and Comcast. Also seeing ~20% packet loss to systems in Comcast and ~15% packet loss end-to-end. Certainly seems like there's something unhappy there, but I'll just keep an eye on it. Thanks! Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From smeuse at mara.org Wed Dec 3 21:01:54 2014 From: smeuse at mara.org (Steve Meuse) Date: Wed, 3 Dec 2014 16:01:54 -0500 Subject: Comcast IPv6 issues..? In-Reply-To: <20141203204034.GM3342@tamriel.snowman.net> References: <20141203201244.GK3342@tamriel.snowman.net> <20141203204034.GM3342@tamriel.snowman.net> Message-ID: I will follow-up offline.... -Steve On Wed, Dec 3, 2014 at 3:40 PM, Stephen Frost wrote: > * Steve Meuse (smeuse at mara.org) wrote: > > It's likely a reverse DNS error. If you look at the latency, it's within > > range of the previous hops. > > Still curious that the systems (IPv6 addresses) are changing too.. It's > not like it's the same route but just different rDNS results. It's also > quite a bit of latency between he.net and Comcast. Also seeing ~20% > packet loss to systems in Comcast and ~15% packet loss end-to-end. > Certainly seems like there's something unhappy there, but I'll just keep > an eye on it. > > Thanks! > > Stephen > From owen at delong.com Wed Dec 3 21:00:15 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Dec 2014 13:00:15 -0800 Subject: Transparent hijacking of SMTP submission... In-Reply-To: References: <20141129201745.30066.qmail@ary.lan> Message-ID: > On Dec 1, 2014, at 5:25 AM, Livingood, Jason wrote: > > On 11/29/14, 3:17 PM, "John Levine" wrote: > >> PS: I know enough technical people at Comcast that I would be >> extremely surprised if it were Comcast doing this. There's plenty not to >> like about the corporation, but the technical staff are quite competent. > > Thanks, John! I can tell folks here unequivocally that (1) the recent > press article on STARTTLS re-writing did *not* involve Comcast and (2) > Comcast does not engage in the claimed practice. In fact, weąre supporters > and early deployers of STARTTLS on our own mail service. > > I do not know how to explain the issue reported on this list. Absent a > packet capture it is impossible for me to analyze this further. If > anything, I could only imagine it was a misconfiguration someplace, but I > have no idea where or in what network element thatąd even be possible. Iąm > happy to work with anyone that has more info to try to troubleshoot this. > > - Jason Livingood > Comcast I have encountered similar issues on some hotel networks. Usually, a well meaning, but severely misinformed hotel administrator decides that: 1. People don’t know what they’re doing and configure they’re laptops to use their [corporate|home|usual] mailserver even when they’re on the road, often without authentication. 2. Debugging people’s laptops for them takes a lot of time and reduces customer satisfaction. so 3. Let’s just redirect all port 25/587 to our own local SMTP proxy which can’t possibly support TLS because we don’t have all the right certificates (nor should we), so it won’t announce the STARTLES capability. I don’t know if that’s what happened in this case, because, as you say, without first-hand information and packet-captures, it’s impossible to tell, but I will say that if you intend to use TLS, make sure your MUA REQUIRES TLS, rather than preferring TLS when available (as is default on many MUAs, unfortunately). Owen From teleric-lists at outlook.com Wed Dec 3 17:24:33 2014 From: teleric-lists at outlook.com (teleric team) Date: Wed, 3 Dec 2014 12:24:33 -0500 Subject: How to track DNS resolution sources In-Reply-To: <20141203165623.GA13619@laperouse.bortzmeyer.org> References: , <20141203165623.GA13619@laperouse.bortzmeyer.org> Message-ID: > Date: Wed, 3 Dec 2014 17:56:23 +0100 > From: bortzmeyer at nic.fr > To: notify.sina at gmail.com > Subject: Re: How to track DNS resolution sources > CC: nanog at nanog.org > > On Wed, Dec 03, 2014 at 05:22:58PM +0100, > Notify Me wrote > a message of 13 lines which said: > > > I hope I'm wording this correctly. > > Not really :-) > > > I had a incident at a client site where a DNS record was being > > spoofed. > > How do you know? What steps did you use to assert this? Answers to > these questions would help to understand your problem. > > > How does one track down the IP address that's returning the false > > records ? > > If it's real DNS spoofing (which I doubt), the source IP address of > the poisoner is forged, so it would not help. > > The main tool to use is dig. Let's assume the name that bothers you is > foobar.example.com. Query your local resolver: > > dig A foobar.example.com > > Query an external resolver, here Google Public DNS: > > dig @8.8.4.4 A foobar.example.com > > Query the authoritative name servers of example.com. First, to find them: > > dig NS example.com > > Second, query them (replace the server name by the real one): > > dig @a.iana-servers.net. A foobar.example.com I didn't understand how this will help him identify the poisoner. What an IDS rule will do is check for responding authoritative query IDs for DNS queries never made to that responder, but made for the authoritative server identified as per above (direct NS inquiry). If no IDS is present, BIND logging would allow for identification of authoritative responses and query ID identification. In summary whatever is answered authoritatively by a server other than the NS ones tracked by "dig +trace foobar.examplecom" is the potential poisoner. But if the poisoing is done from an spoofed IP address (spoofing the authoritative IP), well good luck w/ that if the spoofed domain is not DNSSEC aware. From marka at isc.org Thu Dec 4 00:11:33 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 04 Dec 2014 11:11:33 +1100 Subject: Comcast residential DNS contact In-Reply-To: Your message of "Wed, 03 Dec 2014 11:37:28 -0800." References: <20141203105113.GA43769@excession.tpb.net> <7A6352F1-6373-4720-A0AD-6CDFFF47002D@gmail.com> <20141203120442.GB43769@excession.tpb.net> <547F196E.3080200@satchell.net> <1FCB5596-71AA-4D0C-9CBB-CE561898800B@puck.nether.net> <547F3069.20602@gameservers.com> <547F56D9.5010304@dougbarton.us> Message-ID: <20141204001133.1FBA324D27C5@rock.dv.isc.org> DNS Cookies / SIT (DNS Cookies w/o the error code) will also deal with forged traffic. It allows you to identify traffic from a client that you have replied to in the past and to which you can safely send a large response. It lets you sort the wheat from the chaff. https://tools.ietf.org/html/draft-ietf-dnsop-cookies-00 SIT is available in BIND 9.10 (configure --enable-sit) and uses a experiment EDNS OPT code. BIND 9.11 will have DNS Cookies / SIT will on by default with a allocated code point. The only thing is the amount of non EDNS compliance with servers will make this hard to deploy. In theory unknown EDNS options are supposed to be IGNORED (See RFC6891, 6.1.2 Wire Format). This was done to allow you to send a EDNS option without knowing if the other end supported that option safely. http://users.isc.org/~marka/ts/gov.optfail.html Unfortunately there are firewalls that block such queries. There are nameserver implementations that return FORMERR when they see such queries. There are nameserver implementations that return BADVER when they see such queries. There are nameserver implemations that echo back the option. There are also implementations that don't return a EDNS response unless DO=1 is set. If your nameserver / firewall combination fails to properly handle EDNS queries with unknown options can you please fix it. You can test EDNS option handling with the following allocated code points. dig +nsid soa $zone @$server dig +expire soa $zone @$server Experimentatal code point (requires BIND 9.10). dig +sit soa $zone @$server Unallocated code point (requires pre BIND 9.11 code from sources.isc.org). dig +ednsopt=100 soa $zone @$server There are also issues with attempting to use a new EDNS version (this should get BADVERS returned) or setting a new EDNS flag bit (supposed to be ignored). Firewalls also stupidly block these even more so than unknown EDNS options. http://users.isc.org/~marka/ts.html Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From notify.sina at gmail.com Thu Dec 4 14:23:13 2014 From: notify.sina at gmail.com (Notify Me) Date: Thu, 4 Dec 2014 15:23:13 +0100 Subject: How to track DNS resolution sources In-Reply-To: References: Message-ID: Hi Nick and List Yes it's possible. The dud DNS response in some parts of the internet was the public IP address being used by their proxy server. I'm not sure what the proxy is, but it's a windows box. I was going to try to dig trace but by then the poisoning suddenly stopped happening. Any other ideas on how to deal with this ? What can I proactively do in case it happens again? On Thursday, 4 December 2014, Nicholas Oas wrote: > Is it possible that your client site has a helpful firewall that is > performing DNS doctoring? > > http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/dns-alg-nat-doctoring-overview.html > > The first time I encountered this neither myself nor my customer expected > it. We upgraded the firewall and suddenly their external hostname > resolution was coming back with internal IP addresses, as defined by the > firewall's NAT table. > > Note this only really happens with NAT. If the spoofed records are > internal its most likely something else. > > On Wed, Dec 3, 2014 at 11:22 AM, Notify Me > wrote: > >> Hi! >> >> I hope I'm wording this correctly. I had a incident at a client site where >> a DNS record was being spoofed. How does one track down the IP address >> that's returning the false records ? What tool can one use? >> >> Thanks! >> >> >> >> >> -- >> Sent from MetroMail >> > > -- Sent from MetroMail From mail at theo-voss.de Thu Dec 4 13:21:16 2014 From: mail at theo-voss.de (Theo Voss) Date: Thu, 4 Dec 2014 13:21:16 +0000 Subject: DWDM Documentation Message-ID: <40D2CD0E-3518-4CB3-B70A-87FC9ED548C9@theo-voss.de> Hi guys, we, a Berlin / Germany based carrier, are looking for a smart documentation (shelfs, connections, fibers) and visualization tool for our ADVA-based DWDM-enviroment. Do you have any suggestions or hints for me? We’re testing „cableScout“, the only one I found, next week but. Unfortunately it isn’t easy to get any information about such tools! :( Thanks in advance! Best regards, Theo Voss (AS25291) From akg1330 at gmail.com Thu Dec 4 14:57:05 2014 From: akg1330 at gmail.com (Andrew Gallo) Date: Thu, 04 Dec 2014 09:57:05 -0500 Subject: ARIN's RPKI Relying agreement Message-ID: <54807641.9030006@gmail.com> Greetings: In the past few months, I've spoken with, or heard second hand, from a number of organizations that will not or cannot sign ARIN's RPKI Relying Agreement. Acceptance of this agreement is required in order to gain access to ARIN's Trust Anchor Locator (TAL). Given the size and number of these organizations that can't or wont accept the agreement makes me wonder if this is a show stopper that will prevent the adoption of this technology. I've created a quick survey to get an idea of the community's take on this agreement with the idea that if enough organizations indicate it is unacceptable, maybe we can get this agreement changed, or as with other regions, not explicitly required to use the TAL. https://docs.google.com/forms/d/10RLBBpL05n1c_H4unHitlsVqNM3rZI5aXAX8iSBc_Kk/viewform?usp=send_form Thank you. From Valdis.Kletnieks at vt.edu Thu Dec 4 15:04:08 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Dec 2014 10:04:08 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: Your message of "Thu, 04 Dec 2014 09:57:05 -0500." <54807641.9030006@gmail.com> References: <54807641.9030006@gmail.com> Message-ID: <44004.1417705448@turing-police.cc.vt.edu> On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said: > In the past few months, I've spoken with, or heard second hand, from a > number of organizations that will not or cannot sign ARIN's RPKI Relying > Agreement. Do we have a handle on *why* organizations are having issues with the agreement? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Thu Dec 4 15:21:23 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Dec 2014 10:21:23 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <44004.1417705448@turing-police.cc.vt.edu> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> Message-ID: On Thu, Dec 4, 2014 at 10:04 AM, wrote: > On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said: > >> In the past few months, I've spoken with, or heard second hand, from a >> number of organizations that will not or cannot sign ARIN's RPKI Relying >> Agreement. > > Do we have a handle on *why* organizations are having issues with the > agreement? wes outlined some of his reasons here: https://www.nanog.org/sites/default/files/wednesday_george_adventuresinrpki_62.9.pdf michael sinatra did a reasonable coverage as well in a previous nanog meeting (I think?) From morrowc.lists at gmail.com Thu Dec 4 15:23:35 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Dec 2014 10:23:35 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> Message-ID: On Thu, Dec 4, 2014 at 10:21 AM, Christopher Morrow wrote: > On Thu, Dec 4, 2014 at 10:04 AM, wrote: >> On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said: >> >>> In the past few months, I've spoken with, or heard second hand, from a >>> number of organizations that will not or cannot sign ARIN's RPKI Relying >>> Agreement. >> >> Do we have a handle on *why* organizations are having issues with the >> agreement? > > wes outlined some of his reasons here: > https://www.nanog.org/sites/default/files/wednesday_george_adventuresinrpki_62.9.pdf > > michael sinatra did a reasonable coverage as well in a previous nanog > meeting (I think?) also, john curran covers some of the legal indemnification stuff about here: in the video of the slide presentation above. From akg1330 at gmail.com Thu Dec 4 15:35:59 2014 From: akg1330 at gmail.com (Andrew Gallo) Date: Thu, 04 Dec 2014 10:35:59 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <44004.1417705448@turing-police.cc.vt.edu> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> Message-ID: <54807F5F.2080209@gmail.com> Honestly, that's what I'm trying to figure out as well. In my informal conversations, what I got was that lawyers read the agreement, said 'no, we wont sign it' and then dropped it. If specific legal feedback isn't making it back to ARIN, then we need to start providing it, otherwise, the agreement will stand. On 12/4/2014 10:04 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said: > >> In the past few months, I've spoken with, or heard second hand, from a >> number of organizations that will not or cannot sign ARIN's RPKI Relying >> Agreement. > Do we have a handle on *why* organizations are having issues with the > agreement? From woody at pch.net Thu Dec 4 15:51:31 2014 From: woody at pch.net (Bill Woodcock) Date: Thu, 4 Dec 2014 07:51:31 -0800 Subject: ARIN's RPKI Relying agreement In-Reply-To: <54807F5F.2080209@gmail.com> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> Message-ID: <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> > On Dec 4, 2014, at 7:35 AM, Andrew Gallo wrote: > In my informal conversations, what I got was that lawyers read the agreement, said 'no, we wont sign it' and then dropped it. If specific legal feedback isn't making it back to ARIN, then we need to start providing it, All the specific legal feedback I’ve heard is that this is a liability nightmare, and that everyone wants ARIN to take on all the liability, but nobody wants to pay for it. Are you hearing something more useful than that? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cb.list6 at gmail.com Thu Dec 4 15:53:44 2014 From: cb.list6 at gmail.com (Ca By) Date: Thu, 4 Dec 2014 07:53:44 -0800 Subject: ARIN's RPKI Relying agreement In-Reply-To: <54807F5F.2080209@gmail.com> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> Message-ID: On Thu, Dec 4, 2014 at 7:35 AM, Andrew Gallo wrote: > Honestly, that's what I'm trying to figure out as well. In my informal > conversations, what I got was that lawyers read the agreement, said 'no, we > wont sign it' and then dropped it. If specific legal feedback isn't making > it back to ARIN, then we need to start providing it, otherwise, the > agreement will stand. > > > > On 12/4/2014 10:04 AM, Valdis.Kletnieks at vt.edu wrote: > >> On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said: >> >> In the past few months, I've spoken with, or heard second hand, from a >>> number of organizations that will not or cannot sign ARIN's RPKI Relying >>> Agreement. >>> >> Do we have a handle on *why* organizations are having issues with the >> agreement? >> > > They want a pony. From cb.list6 at gmail.com Thu Dec 4 15:55:29 2014 From: cb.list6 at gmail.com (Ca By) Date: Thu, 4 Dec 2014 07:55:29 -0800 Subject: ARIN's RPKI Relying agreement In-Reply-To: <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> Message-ID: On Thu, Dec 4, 2014 at 7:51 AM, Bill Woodcock wrote: > > > On Dec 4, 2014, at 7:35 AM, Andrew Gallo wrote: > > In my informal conversations, what I got was that lawyers read the > agreement, said 'no, we wont sign it' and then dropped it. If specific > legal feedback isn't making it back to ARIN, then we need to start > providing it, > > All the specific legal feedback I’ve heard is that this is a liability > nightmare, and that everyone wants ARIN to take on all the liability, but > nobody wants to pay for it. Are you hearing something more useful than > that? > > -Bill > > > This is the same legal feedback most lawyers will give you about settlement free peering as well. CB From amitchell at isipp.com Thu Dec 4 16:15:36 2014 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 4 Dec 2014 09:15:36 -0700 Subject: Anybody at Amazon AWS? Message-ID: Anybody have a contact at Amazon AWS? I sent in a spam complaint, and got back the below response - while I give them kudos for actually, you know, responding, I'm pretty sure that we can all agree that "sending the same canned message to email addresses scraped off websites" is the very definition of spam, yet somehow the EC2 abuse team seems to consider it a perfectly acceptable explanation - I'd sure love to discuss this with someone with a clue at Amazon AWS --- Our customer has responded to your abuse report and provided the following information "The below emails were sent individually to the recipient using a canned message. There is no automation or mass emailing at all. Our publisher representative personally visited each of the below websites, decided they were right for our service and emailed them individually. The emails are sent through gmail using a web interface to their API. Let me know if you require any additional information. Dwayne" If you are satisfied with the above information, there is no need to respond to this notice. If you are not satisfied, please respond with a clear, succinct reason for dissatisfaction and what results you desire from our customer. We will make every reasonable attempt to work with you and our customer to resolve this matter. Thank you, The EC2 Abuse team --- Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Accreditation & Certification Your mail system + SuretyMail accreditation = delivered to their inbox! http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Author: Section 6 of the Federal CAN-SPAM Act of 2003 Member, California Bar Cyberspace Law Committee Ret. Professor of Law, Lincoln Law School of San Jose https://www.linkedin.com/in/annemitchell 303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell From bill at herrin.us Thu Dec 4 16:22:27 2014 From: bill at herrin.us (William Herrin) Date: Thu, 4 Dec 2014 11:22:27 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> Message-ID: >> On Dec 4, 2014, at 7:35 AM, Andrew Gallo wrote: >> In my informal conversations, what I got was that lawyers read >>the agreement, said 'no, we wont sign it' and then dropped it. If >>specific legal feedback isn't making it back to ARIN, then we >>need to start providing it, Hi Andrew, The short version is that the would-be consumers of the RPKI data want the data published in much the same way that whois data is published. Many of the organizations aren't even in the ARIN region. Virtually any formal contract ARIN is able to offer will be a non-starter for these folks. On Thu, Dec 4, 2014 at 10:51 AM, Bill Woodcock wrote: > All the specific legal feedback I’ve heard is that this is a liability nightmare, > and that everyone wants ARIN to take on all the liability, but nobody > wants to pay for it. Are you hearing something more useful than that? Hi Bill, No, nothing more useful. I've seen a lot of hand waving, but I still have no clue how the publication of RPKI data places ARIN at a different risk than publication of whois data. I think if we could better understand that, we'd be better able assess what the next steps are. Do we beat down ARIN's door and insist they publish the data? Do we pursue the creation of some new organization to manage RPKI, one with intentionally shallow pockets, and ask ARIN to cede the function? Something else? I think we all need a better understanding of the alleged legal issue before we can zero in on what should come next. For sure ARIN's current solution, a contract few will sign, is unsatisfactory. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From clayton at MNSi.Net Thu Dec 4 16:25:12 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Thu, 04 Dec 2014 11:25:12 -0500 Subject: Anybody at Amazon AWS? In-Reply-To: References: Message-ID: <1417710314_132355@surgemail.mnsi.net> Wether the addresses were gleaned using specially trained hedgehogs or by people looking at the sites to target who they're going to SPAM, targeted UCE is still UCE. Apparently AWS doesn't grok that. At 11:15 AM 04/12/2014, Anne P. Mitchell, Esq. wrote: >Anybody have a contact at Amazon AWS? > >I sent in a spam complaint, and got back the below response - while >I give them kudos for actually, you know, responding, I'm pretty >sure that we can all agree that "sending the same canned message to >email addresses scraped off websites" is the very definition of >spam, yet somehow the EC2 abuse team seems to consider it a >perfectly acceptable explanation - I'd sure love to discuss this >with someone with a clue at Amazon AWS >--- > >Our customer has responded to your abuse report and provided the >following information > >"The below emails were sent individually to the recipient using a >canned message. There is no automation or mass emailing at all. Our >publisher representative personally visited each of the below >websites, decided they were right for our service and emailed them >individually. The emails are sent through gmail using a web >interface to their API. > >Let me know if you require any additional information. > >Dwayne" > >If you are satisfied with the above information, there is no need to >respond to this notice. If you are not satisfied, please respond >with a clear, succinct reason for dissatisfaction and what results >you desire from our customer. We will make every reasonable attempt >to work with you and our customer to resolve this matter. > >Thank you, >The EC2 Abuse team > >--- > >Anne > >Anne P. Mitchell, Esq. >CEO/President >ISIPP SuretyMail Email Accreditation & Certification >Your mail system + SuretyMail accreditation = delivered to their inbox! >http://www.SuretyMail.com/ >http://www.SuretyMail.eu/ > >Author: Section 6 of the Federal CAN-SPAM Act of 2003 >Member, California Bar Cyberspace Law Committee >Ret. Professor of Law, Lincoln Law School of San Jose >https://www.linkedin.com/in/annemitchell >303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From jra at baylink.com Thu Dec 4 16:33:48 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 4 Dec 2014 11:33:48 -0500 (EST) Subject: ARIN's RPKI Relying agreement In-Reply-To: Message-ID: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ca By" > On Thu, Dec 4, 2014 at 7:51 AM, Bill Woodcock wrote: > > All the specific legal feedback I’ve heard is that this is a > > liability > > nightmare, and that everyone wants ARIN to take on all the > > liability, but > > nobody wants to pay for it. Are you hearing something more useful > > than that? > This is the same legal feedback most lawyers will give you about > settlement free peering as well. And this delightfully illustrates what IMG's Mark MacCormack is pleased to call "the Terrible Truth About Lawyers", to wit: Lawyers believe that their job is to tell you what not to do. Their *actual job* is to tell where risks lie, so that you can make informed business decisions about which risks to take, and how to allow for them. If you as a businessman believe the lawyers' point of view, though, you will never accomplish anything. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From akg1330 at gmail.com Thu Dec 4 16:33:56 2014 From: akg1330 at gmail.com (Andrew Gallo) Date: Thu, 04 Dec 2014 11:33:56 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> Message-ID: <54808CF4.50101@gmail.com> On 12/4/2014 11:22 AM, William Herrin wrote: >>> On Dec 4, 2014, at 7:35 AM, Andrew Gallo wrote: >>> In my informal conversations, what I got was that lawyers read >>> the agreement, said 'no, we wont sign it' and then dropped it. If >>> specific legal feedback isn't making it back to ARIN, then we >>> need to start providing it, > Hi Andrew, > > The short version is that the would-be consumers of the RPKI data want the > data published in much the same way that whois data is published. Many of > the organizations aren't even in the ARIN region. Virtually any formal > contract ARIN is able to offer will be a non-starter for these folks. Understood and good point. I've heard rumblings of setting up a non-ARIN TAL, though I wonder what the value is in separating RPKI from the registry. Wouldn't this put us in the same position we're in with routing registries (with respect to data quality)? > > On Thu, Dec 4, 2014 at 10:51 AM, Bill Woodcock wrote: >> All the specific legal feedback I’ve heard is that this is a liability > nightmare, >> and that everyone wants ARIN to take on all the liability, but nobody >> wants to pay for it. Are you hearing something more useful than that? > Hi Bill, > > No, nothing more useful. I've seen a lot of hand waving, but I still have > no clue how the publication of RPKI data places ARIN at a different risk > than publication of whois data. I think if we could better understand that, > we'd be better able assess what the next steps are. Do we beat down ARIN's > door and insist they publish the data? Do we pursue the creation of some > new organization to manage RPKI, one with intentionally shallow pockets, > and ask ARIN to cede the function? Something else? I think we all need a > better understanding of the alleged legal issue before we can zero in on > what should come next. > > For sure ARIN's current solution, a contract few will sign, is > unsatisfactory. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > May I solve your unusual networking challenges? > From morrowc.lists at gmail.com Thu Dec 4 16:35:01 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Dec 2014 11:35:01 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> Message-ID: On Thu, Dec 4, 2014 at 11:22 AM, William Herrin wrote: > On Thu, Dec 4, 2014 at 10:51 AM, Bill Woodcock wrote: >> All the specific legal feedback I’ve heard is that this is a liability > nightmare, >> and that everyone wants ARIN to take on all the liability, but nobody >> wants to pay for it. Are you hearing something more useful than that? > No, nothing more useful. I've seen a lot of hand waving, but I still have > no clue how the publication of RPKI data places ARIN at a different risk > than publication of whois data. I think if we could better understand that, (oops, I assumed that the decision to have the rpa implemented in the way it is is due to 'arin counsel') Maybe it would be helpful for the ARIN Counsel to document in a more public way (than the RPA) what the concerns are and how that translates into 'different risk than the publication of whois data' ? > we'd be better able assess what the next steps are. Do we beat down ARIN's > door and insist they publish the data? Do we pursue the creation of some > new organization to manage RPKI, one with intentionally shallow pockets, > and ask ARIN to cede the function? Something else? I think we all need a > better understanding of the alleged legal issue before we can zero in on > what should come next. One of the complaints I've heard is that for out-of-region folk to get the TA details they need to sign the RPA, and potentially be bound by a contract that they can't be bound by anyway... so the process is looked upon as a bit 'foolish' or perhaps: "over-reaching" is the more polite term used. First though I think Bill's point about: "How did we get into this mess? could someone walk us through the process/steps taken to get here?" maybe we zigged when we ought to have zagged? -chris From carlosm3011 at gmail.com Thu Dec 4 17:12:49 2014 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Thu, 04 Dec 2014 15:12:49 -0200 Subject: ARIN's RPKI Relying agreement In-Reply-To: <54808CF4.50101@gmail.com> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <54808CF4.50101@gmail.com> Message-ID: <54809611.2080907@gmail.com> Hello, On 12/4/2014 2:33 PM, Andrew Gallo wrote: > > On 12/4/2014 11:22 AM, William Herrin wrote: > Understood and good point. I've heard rumblings of setting up a > non-ARIN TAL, though I wonder what the value is in separating RPKI from > the registry. Wouldn't this put us in the same position we're in with > routing registries (with respect to data quality)? > Exactly the same. RPKI without the tie-in to the registration database is just another random database, like the dozens that are out there, bound to suffer from exactly the same problems current IRRs suffer. Disclaimer: I work for LACNIC, but in this case, if I was a beggar playing music at subway stations my opinion would be exactly the same. Cheers! Carlos From carlosm3011 at gmail.com Thu Dec 4 17:13:56 2014 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Thu, 04 Dec 2014 15:13:56 -0200 Subject: ARIN's RPKI Relying agreement In-Reply-To: <54808CF4.50101@gmail.com> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <54808CF4.50101@gmail.com> Message-ID: <54809654.3080600@gmail.com> Hello, On 12/4/2014 2:33 PM, Andrew Gallo wrote: > > On 12/4/2014 11:22 AM, William Herrin wrote: > Understood and good point. I've heard rumblings of setting up a > non-ARIN TAL, though I wonder what the value is in separating RPKI from > the registry. Wouldn't this put us in the same position we're in with > routing registries (with respect to data quality)? > Exactly the same. RPKI without the tie-in to the registration database is just another random database, like the dozens that are out there, bound to suffer from exactly the same problems current IRRs suffer. Disclaimer: I work for LACNIC, but in this case, if I was a beggar playing music at subway stations my opinion would be exactly the same. Cheers! Carlos From wesley.george at twcable.com Thu Dec 4 17:32:51 2014 From: wesley.george at twcable.com (George, Wes) Date: Thu, 4 Dec 2014 12:32:51 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <54807F5F.2080209@gmail.com> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> Message-ID: On 12/4/14, 10:35 AM, "Andrew Gallo" wrote: >Honestly, that's what I'm trying to figure out as well. In my informal >conversations, what I got was that lawyers read the agreement, said 'no, >we wont sign it' and then dropped it. If specific legal feedback isn't >making it back to ARIN, then we need to start providing it, otherwise, >the agreement will stand. For my part, I have had discussions with ARIN's internal legal council and other staff about our specific concerns and how to address them, and intend to continue doing so, as I agree that this won't get solved if we just say "unacceptable" and drop the subject. That said, this is harder to manage because it doesn't fall into the existing ARIN policy development process, so the community doesn't have as direct of a voice on changes to the policies. I can't just submit a policy proposal to change how ARIN words its RPA, who is bound by it, and how ARIN provides RPKI services. Those are operational matters, implemented by the staff, governed by the board, who is informed by their legal council and staff. That is part of the reason why I brought some of the issues to the NANOG community, since interaction with ARIN board members and staff is what's necessary to make sure the concerns are addressed, and thus it benefits from wider discussion. I'll try to go through your survey as well. 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 jcurran at arin.net Thu Dec 4 17:39:06 2014 From: jcurran at arin.net (John Curran) Date: Thu, 4 Dec 2014 17:39:06 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> Message-ID: <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> On Dec 4, 2014, at 11:35 AM, Christopher Morrow wrote: > ... > Maybe it would be helpful for the ARIN Counsel to document in a more > public way (than the RPA) what the concerns are and how that > translates into 'different risk than the publication of whois data' ? This is apparently being discussed on two different lists (PPML and NANOG) at the same time, so apologies for the cross-posting... The reason that the RIRs have disclaimer of warranty and indemnification clauses for RPKI services is actually quite simple: despite striving to deliver highly available RPKI services, you are supposed to be using best practices in use of the service, and this include recognizing that failures can occur and such should not result in operation impact (i.e. exactly the opposite of your “my routing decisions are affected and breakage happens” statement in your prior email.) Specifically, your RPKI deployment approach should be following known operational best practices for RPKI, such as those in RFC 7115 / BCP 185, "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)” - “… Local policy using relative preference is suggested to manage the uncertainty associated with a system in early deployment; local policy can be applied to eliminate the threat of unreachability of prefixes due to ill-advised certification policies and/or incorrect certification data. “ Note that the claims that could ensue from an operator failing to follow best practices and then third-parties suffering an major operational outage is likely to be large and extremely protracted, with potential for endangering the registry itself due to the nature of litigation and its requirement to actually go to all the way to trial in order to be able to then introduce evidence and prove that the RPKI services were operating properly at the time of the event. If the RIRs did not seek indemnification for use of the RPKI services, then all of their other registry services could potentially be put at risk due to the need to defend errant litigation, even presuming perfect RPKI service delivery. Undertaking that risk to the other services that everyone else presently rely upon (Whois, reverse DNS) is not reasonable particularly during this time when the RPKI parties are supposed to be deploying via conservative routing preference practices. ARIN does make the expectations very clear and explicit in its agreements, and that is different from the other RIRs. Again, are the other RIR RPKI non-warranty and indemnification clauses equally problematic for you, or is the fact that they are implicitly bound address your concerns? This has come up before on the NANOG mailing list (see attached) but it was unclear if the outcome was an expectation that all RIRs should drop these clauses, or that ARIN should make agreement to them be implicit. Thanks! /John John Curran President and CEO ARIN > === > Begin forwarded message: > > Subject: Re: APNIC RPKI TAL agreement > From: John Curran > Date: October 16, 2014 at 7:30:48 PM EDT > Cc: Wes George , Randy Bush , "Geoff Huston" > To: Michael Sinatra > >> On Oct 16, 2014, at 3:19 PM, Michael Sinatra wrote: >> >> Hi John: >> >> At NANOG 62, you mentioned that APNIC has a similar agreement as ARIN to >> use its trust-anchor locator (TAL), but that it is not a click-through >> agreement like ARIN's. I have searched using basic google-foo for this >> agreement, and have also looked on APNIC's certificate rsync server >> (which also has an HTTP interface) and I can't find it. Can you, or any >> other recipient of this message who is familiar with the APNIC >> agreement, point me in the right direction? >> > Michael - > > Review > wherein there is a limitation of liability and requirement that a recipient of any digital certificate > will indemnify APNIC against any and all claims by third parties for damages of any kind arising > from the use of that certificate. (last two bullets) > > /John > > John Curran > President and CEO > ARIN > === > > From jcurran at arin.net Thu Dec 4 17:53:02 2014 From: jcurran at arin.net (John Curran) Date: Thu, 4 Dec 2014 17:53:02 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> Message-ID: <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> On Dec 4, 2014, at 12:32 PM, George, Wes wrote: > Those are operational matters, implemented by the staff, governed by the > board, who is informed by their legal council and staff. That is part of > the reason why I brought some of the issues to the NANOG community, since > interaction with ARIN board members and staff is what's necessary to make > sure the concerns are addressed, and thus it benefits from wider > discussion. Wes - I am happy to champion the change that you seek (i.e. will get it reviewed by legal and brought before the ARIN Board) but still need clarity on what change you wish to occur - A) Implicit binding to the indemnification/warrant disclaimer clauses (as done by the other RIRs) B) Removal of the indemnification & warranty disclaimer clause I asked this directly during your NANOG presentation, but you did not respond either way. I also noted that your own business customer agreements have the same indemnification & non-warranty clauses (as they are common in nearly all telecommunication and ISP service agreements) - are these now being dropped by TWC in agreements? Thanks! /John John Curran President and CEO ARIN From jared at puck.nether.net Thu Dec 4 18:01:51 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Dec 2014 13:01:51 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> Message-ID: <6451810B-609D-4408-8A08-230739BE38C0@puck.nether.net> > On Dec 4, 2014, at 12:53 PM, John Curran wrote: > > On Dec 4, 2014, at 12:32 PM, George, Wes wrote: >> Those are operational matters, implemented by the staff, governed by the >> board, who is informed by their legal council and staff. That is part of >> the reason why I brought some of the issues to the NANOG community, since >> interaction with ARIN board members and staff is what's necessary to make >> sure the concerns are addressed, and thus it benefits from wider >> discussion. > > Wes - > > I am happy to champion the change that you seek (i.e. will get it reviewed > by legal and brought before the ARIN Board) but still need clarity on what > change you wish to occur - > > A) Implicit binding to the indemnification/warrant disclaimer clauses > (as done by the other RIRs) > > B) Removal of the indemnification & warranty disclaimer clause > > I asked this directly during your NANOG presentation, but you did not respond > either way. I also noted that your own business customer agreements have the > same indemnification & non-warranty clauses (as they are common in nearly all > telecommunication and ISP service agreements) - are these now being dropped > by TWC in agreements? I recall a lengthly discussion about this at the NANOG meeting that occurred after the session. I think there is a very strong emotional thing here where we said to you (which you seem to have forgotten) that option B above would be helpful as it’s already covered by the general registration agreement (which was your assertion). Comparing what you do with Time Warner cable seems like pure hyperbole and an attempt as CEO to inflame community discussion at minimum. - Jared From rs at seastrom.com Thu Dec 4 18:11:29 2014 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 04 Dec 2014 13:11:29 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> (Bill Woodcock's message of "Thu, 4 Dec 2014 07:51:31 -0800") References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> Message-ID: <86vblrjne6.fsf@valhalla.seastrom.com> Bill Woodcock writes: >> On Dec 4, 2014, at 7:35 AM, Andrew Gallo wrote: >> >> In my informal conversations, what I got was that lawyers read the >> agreement, said 'no, we wont sign it' and then dropped it. If >> specific legal feedback isn't making it back to ARIN, then we need >> to start providing it, > > All the specific legal feedback I’ve heard is that this is a > liability nightmare, and that everyone wants ARIN to take on all the > liability, but nobody wants to pay for it. Are you hearing > something more useful than that? The way the RPA is worded, ARIN seems to be attempting to offload all the risk to its member organizations. Anything that ARIN does has some degree of risk associated with it. Twice a year we host parties where alcohol is served. That's a risky endeavor on all sorts of ways - at least we're typically taking buses to and from the event so we aren't driving. I have heard it asserted the board is unwilling for the organization to shoulder even that level of risk as part of providing RPKI. As a board member, can you speak to this? Whether this extreme level of risk aversity is a matter of mistaken priorities (putting the organization itself ahead of accomplishing the organization's mission) or a way of making sure that we stop wasting money on RPKI due to demonstrable non-uptake is left as an exercise to the reader. You can infer from the last statement that I would applaud cutting our losses on RPKI. The quote on slide 23 of Wes' deck about replacing complex stuff like email templates with simple, easy to understand public key crypto was mine. If you can't get people to play ball nicely with client filtering, IRR components, etc. where the bar to entry is low, who can _possibly_ say with a straight face that we can get people to embrace RPKI? To the usual suspects: sorry to call your kid ugly. Don't hate the messenger. -r From jcurran at arin.net Thu Dec 4 18:13:16 2014 From: jcurran at arin.net (John Curran) Date: Thu, 4 Dec 2014 18:13:16 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: <6451810B-609D-4408-8A08-230739BE38C0@puck.nether.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> <6451810B-609D-4408-8A08-230739BE38C0@puck.nether.net> Message-ID: <58802CE8-DC2C-463A-8123-9EBFC719E7ED@arin.net> On Dec 4, 2014, at 1:01 PM, Jared Mauch wrote: >> I am happy to champion the change that you seek (i.e. will get it reviewed >> by legal and brought before the ARIN Board) but still need clarity on what >> change you wish to occur - >> >> A) Implicit binding to the indemnification/warrant disclaimer clauses >> (as done by the other RIRs) >> >> B) Removal of the indemnification & warranty disclaimer clause >> >> I asked this directly during your NANOG presentation, but you did not respond >> either way. I also noted that your own business customer agreements have the >> same indemnification & non-warranty clauses (as they are common in nearly all >> telecommunication and ISP service agreements) - are these now being dropped >> by TWC in agreements? > > I recall a lengthly discussion about this at the NANOG meeting that occurred after > the session. I think there is a very strong emotional thing here where we said to > you (which you seem to have forgotten) that option B above would be helpful as > it’s already covered by the general registration agreement (which was your assertion). Several folks suggested making the RPKI indemnification tie back to the language in the existing RSA (it is not presently but instead done via separate language). However, when I asked Wes about that approach he did not know at the time if that would address TWC's particular concern (hence my reason for following up now via email) > Comparing what you do with Time Warner cable seems like pure hyperbole and an attempt > as CEO to inflame community discussion at minimum. Actually, it is to remind folks that such indemnification language is sought by most ISPs, despite their services being used in a mission critical mode by many customers and despite the ISPs efforts to make their services be highly reliable. (One can easily argue that best practices require multiple connections or service providers, but that is the same with best practices for RPKI use requiring proper preferences to issues with certification data...) /John John Curran President and CEO ARIN From wesley.george at twcable.com Thu Dec 4 18:17:45 2014 From: wesley.george at twcable.com (George, Wes) Date: Thu, 4 Dec 2014 13:17:45 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> References: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> Message-ID: >>On Thu, Dec 4, 2014 at 7:51 AM, Bill Woodcock wrote: > >> > All the specific legal feedback I’ve heard is that this is a >> > liability >> > nightmare, and that everyone wants ARIN to take on all the >> > liability, but >> > nobody wants to pay for it. WG] Has there been any actual discussion about how much "nobody" would have to pay for ARIN (or another party) to fix the balance of liability and provide a proper SLA that led to "no, I don't want to pay for that" responses from those who are expressing the concern, or is this just conjecture on your part? I know that despite being fairly vocal on the matter, I've not been party to any such discussion, though I know that ARIN fees and what services they provide for those fees is an ongoing discussion in other forums. The problem with free services is that often you get what you pay for when it comes to support, warranty, etc. There are plenty of models where you take something free, say FOSS, and then pay someone (Red Hat, ISC) to support it in order to manage the risk associated with putting it in the middle of your business-critical system. It gives you some determinism about what happens when it breaks or you need a feature, and recourse when it goes pear-shaped. I think there's room for discussion around how much an SLA-backed RPKI service might be worth to its potential customers, given its ability to either protect or badly break global routing. On 12/4/14, 11:33 AM, "Jay Ashworth" wrote: >Lawyers believe that their job is to tell you what not to do. > >Their *actual job* is to tell where risks lie, so that you can make >informed business decisions about which risks to take, and how to >allow for them WG] FWIW, I believe that my lawyers did their "actual" job. But as I said in my presentation, the combination of technical fragility and liability risk I incur if it breaks in a way that impacts my customers led me to decide that I'm not yet willing to bet my continued gainful employment on Route Origin Validation working well enough that the benefit of having it outweighs the risks. INAL, YMMV, void where prohibited, caveat lector, of course. Fixing the liability issues certainly removes one barrier to entry, but it's not the only one, and the technical issues are being worked in parallel. Wes George Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jared at puck.nether.net Thu Dec 4 18:19:03 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Dec 2014 13:19:03 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <58802CE8-DC2C-463A-8123-9EBFC719E7ED@arin.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> <6451810B-609D-4408-8A08-230739BE38C0@puck.nether.net> <58802CE8-DC2C-463A-8123-9EBFC719E7ED@arin.net> Message-ID: <057C9BCC-7F92-4559-814F-18B2EAED6A51@puck.nether.net> >> Comparing what you do with Time Warner cable seems like pure hyperbole and an attempt >> as CEO to inflame community discussion at minimum. > > Actually, it is to remind folks that such indemnification language is > sought by most ISPs, despite their services being used in a mission > critical mode by many customers and despite the ISPs efforts to make > their services be highly reliable. > > (One can easily argue that best practices require multiple connections > or service providers, but that is the same with best practices for RPKI > use requiring proper preferences to issues with certification data...) > > /John > > John Curran > President and CEO > ARIN I think your question is fair if you are talking to the TWC CEO, but in this case you are not and it’s disingenuous to pretend otherwise (which you are attempting through your weak straw-man). If ARIN isn’t capable of running RPKI or performing its function, which perhaps we should infer from your talking points, perhaps we should all transfer our resources out of region and dissolve ARIN? I don’t think that would suit the community needs though. I (similar to Rob) have my own concerns about RPKI but do feel that this is an ARIN specific construct/wall that has been raised without action yet from ARIN. The fact that the meeting was 2 months ago and you have not acted/discussed with your counsel says everything I need to know about the situation, your personal motives and your personal desires for the outcomes. I hope it doesn’t represent your employer and that the ARIN Board brings it up with you. - Jared From alexb at ripe.net Thu Dec 4 18:23:11 2014 From: alexb at ripe.net (Alex Band) Date: Thu, 4 Dec 2014 19:23:11 +0100 Subject: ARIN's RPKI Relying agreement In-Reply-To: <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> Message-ID: <8323241A-0938-4969-845C-6DA02A81BD80@ripe.net> > On 4 Dec 2014, at 18:53, John Curran wrote: > > On Dec 4, 2014, at 12:32 PM, George, Wes wrote: >> Those are operational matters, implemented by the staff, governed by the >> board, who is informed by their legal council and staff. That is part of >> the reason why I brought some of the issues to the NANOG community, since >> interaction with ARIN board members and staff is what's necessary to make >> sure the concerns are addressed, and thus it benefits from wider >> discussion. > > Wes - > > I am happy to champion the change that you seek (i.e. will get it reviewed > by legal and brought before the ARIN Board) but still need clarity on what > change you wish to occur - > > A) Implicit binding to the indemnification/warrant disclaimer clauses > (as done by the other RIRs) Some details on this: The RIPE NCC offers an RPKI Validator toolset which includes the Trust Anchors for all the RIR repositories except the one for ARIN. On the download page, there is this statement: "By setting up the RIPE NCC RPKI Validator, you confirm that you have read, understood and agree to the ." Download page: https://www.ripe.net/certification/tools-and-resources T&C: http://www.ripe.net/lir-services/resource-management/certification/legal/ripe-ncc-certification-repository-terms-and-conditions There are instructions to get the ARIN TAL in the readme and UI of the RPKI Validator: - http://localcert.ripe.net:8088 - https://github.com/RIPE-NCC/rpki-validator/blob/master/rpki-validator-app/README.txt#L122 Cheers, Alex From woody at pch.net Thu Dec 4 18:34:46 2014 From: woody at pch.net (Bill Woodcock) Date: Thu, 4 Dec 2014 10:34:46 -0800 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> Message-ID: > On Dec 4, 2014, at 10:17 AM, George, Wes wrote: > WG] Has there been any actual discussion about how much "nobody" would > have to pay for ARIN (or another party) to fix the balance of liability > and provide a proper SLA that led to "no, I don't want to pay for that" > responses from those who are expressing the concern, or is this just > conjecture on your part? I’ve asked a lot of people, “Would you be willing to pay ARIN for RPKI services,” and the answer has always been “no.” Until I get a “yes,” it’s hard to put a number (other than zero) on how the market values RPKI. So, asking how much more risk ARIN is willing to take on seems a little premature. > The problem with free services is that often you get what you pay for when > it comes to support, warranty, etc. Yep. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From wesley.george at twcable.com Thu Dec 4 18:47:48 2014 From: wesley.george at twcable.com (George, Wes) Date: Thu, 4 Dec 2014 13:47:48 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <58802CE8-DC2C-463A-8123-9EBFC719E7ED@arin.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> <6451810B-609D-4408-8A08-230739BE38C0@puck.nether.net> <58802CE8-DC2C-463A-8123-9EBFC719E7ED@arin.net> Message-ID: On 12/4/14, 1:13 PM, "John Curran" wrote: >>>I am happy to champion the change that you seek (i.e. will get it >>>reviewed >>> by legal and brought before the ARIN Board) but still need clarity on >>>what >>> change you wish to occur - >>> >>> A) Implicit binding to the indemnification/warrant disclaimer >>>clauses >>> (as done by the other RIRs) >>> >>> B) Removal of the indemnification & warranty disclaimer clause >>> >>> I asked this directly during your NANOG presentation, but you did not >>>respond >>> either way. WG] I deferred because I am not a lawyer and am not empowered to speak anything more than my opinion on the matter. I believe that the more useful response to your question came during the ARIN members' meeting post-NANOG, where Rob Seastrom suggested at the mic that rather than a bunch of engineers and policy wonks playing armchair lawyer and guessing at what will make the actual lawyers happy, that we should organize a separate meeting involving: - the ARIN board - ARIN legal counsel and other relevant ARIN staff - legal representatives from as many of the operators and others expressing concern over this as appropriate, - along with a few of the technical folks to help deal with the interaction between the technical and the legal and use it to discuss the issues in order to come up with something better. >(One can easily argue that best practices require multiple connections >or service providers, but that is the same with best practices for RPKI >use requiring proper preferences to issues with certification data...) WG] So how would I as an ARIN member go about getting a redundant RPKI provider? I'm uncomfortable being single-homed to ARIN since that seems contrary to best practices. Also: Most SPs provide an SLA to their customers that serves as a balance to contractual liability weasel words. 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 rs at seastrom.com Thu Dec 4 19:11:35 2014 From: rs at seastrom.com (Robert Seastrom) Date: Thu, 4 Dec 2014 14:11:35 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> Message-ID: <1E8005C6-C5E7-4E26-9547-99EF832AAFDC@seastrom.com> On Dec 4, 2014, at 1:34 PM, Bill Woodcock wrote: > >> On Dec 4, 2014, at 10:17 AM, George, Wes wrote: >> WG] Has there been any actual discussion about how much "nobody" would >> have to pay for ARIN (or another party) to fix the balance of liability >> and provide a proper SLA that led to "no, I don't want to pay for that" >> responses from those who are expressing the concern, or is this just >> conjecture on your part? > > I’ve asked a lot of people, “Would you be willing to pay ARIN for RPKI services,” and the answer has always been “no.” Until I get a “yes,” it’s hard to put a number (other than zero) on how the market values RPKI. So, asking how much more risk ARIN is willing to take on seems a little premature. I suspect you would get a similar answer if you asked people "Would you be willing to pay ARIN for whois services" or "would you be willing to pay ARIN for in-addr.arpa services". I've always been under the impression that the fees charged annually to my orgid were in part to cover the costs associated with running the registry, which by definition involves a certain amount of risk. Am I mistaken? -r From woody at pch.net Thu Dec 4 19:17:34 2014 From: woody at pch.net (Bill Woodcock) Date: Thu, 4 Dec 2014 11:17:34 -0800 Subject: ARIN's RPKI Relying agreement In-Reply-To: <1E8005C6-C5E7-4E26-9547-99EF832AAFDC@seastrom.com> References: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> <1E8005C6-C5E7-4E26-9547-99EF832AAFDC@seastrom.com> Message-ID: > On Dec 4, 2014, at 11:11 AM, Robert Seastrom wrote: > I suspect you would get a similar answer if you asked people "Would you be willing to pay ARIN for whois services" or "would you be willing to pay ARIN for in-addr.arpa services”. Actually, since those are relatively inexpensive, I suspect there are plenty of people who’d be willing to cover those costs, if they needed to be paid separately. However... > I've always been under the impression that the fees charged annually to my orgid were in part to cover the costs associated with running the registry, which by definition involves a certain amount of risk. …the RPKI costs are many orders of magnitude higher, and that’s before anyone sues us. So, the question is how much of your fees you want to see going toward RPKI, and how much of that you want to go toward trying to make it functional, versus mitigating the risk when it’s not. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sandy at tislabs.com Thu Dec 4 19:19:01 2014 From: sandy at tislabs.com (Sandra Murphy) Date: Thu, 4 Dec 2014 14:19:01 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> Message-ID: On Dec 4, 2014, at 12:39 PM, John Curran wrote: > On Dec 4, 2014, at 11:35 AM, Christopher Morrow wrote: > > Note that the claims that could ensue from an operator failing to follow best practices > and then third-parties suffering an major operational outage is likely to be large > > Undertaking that risk to the other services that everyone else presently rely upon > (Whois, reverse DNS) is not reasonable Which begs the question for me -- ARIN already operates services that operators rely upon. Why are they different? Does ARIN run no risk of litigation due to some perceived involvement of those services in someone's operational outage? Has there been litigation against ARIN tied to, for example, reverse DNS? Or the IRR? --Sandy -------------- 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 jcurran at arin.net Thu Dec 4 19:19:13 2014 From: jcurran at arin.net (John Curran) Date: Thu, 4 Dec 2014 19:19:13 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: <057C9BCC-7F92-4559-814F-18B2EAED6A51@puck.nether.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> <6451810B-609D-4408-8A08-230739BE38C0@puck.nether.net> <58802CE8-DC2C-463A-8123-9EBFC719E7ED@arin.net> <057C9BCC-7F92-4559-814F-18B2EAED6A51@puck.nether.net> Message-ID: <4E431394-95B4-49BB-8C60-BB2CC307549A@arin.net> On Dec 4, 2014, at 1:19 PM, Jared Mauch wrote: > > I (similar to Rob) have my own concerns about RPKI but do feel that > this is an ARIN specific construct/wall that has been raised without > action yet from ARIN. Jared - Please be specific - are you referring to the indemnification clauses (which are existing in other RIRs as well), the method of agreement, or not having ready access to the TAL, i.e. the click-accept access? > The fact that the meeting was 2 months ago and you have not acted/discussed > with your counsel says everything I need to know about the situation, your > personal motives and your personal desires for the outcomes. I hope it > doesn’t represent your employer and that the ARIN Board brings it up with you. Incorrect. Despite the lack of clarity, we started work on 27 October with both inside and external counsel regarding drafting some updates to the RPKI legal framework. This effort should be ready to be brought to the ARIN Board in January for their consideration, but it would be helpful to have more clarity on the concerns (i.e. is it access to the TAL, or the requirement for explicit agreement to terms and conditions, or the presence of indemnification/warrant-disclaimer language regardless of method of binding) At present, I am working on addressing the TAL access and the explicit agreement concerns that were raised during Wes's NANOG session. These are relatively straightforward to work with counsel and propose to the ARIN Board for their consideration. The issue of indemnification is far more challenging, and hence my reason for asking about the underlying need for such and how folks are handling its presence in other RIR RPKI terms and conditions. Thanks! /John John Curran President and CEO ARIN From Valdis.Kletnieks at vt.edu Thu Dec 4 19:21:41 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Dec 2014 14:21:41 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: Your message of "Thu, 04 Dec 2014 11:17:34 -0800." References: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> <1E8005C6-C5E7-4E26-9547-99EF832AAFDC@seastrom.com> Message-ID: <15650.1417720901@turing-police.cc.vt.edu> On Thu, 04 Dec 2014 11:17:34 -0800, Bill Woodcock said: > the RPKI costs are many orders of magnitude higher Orders of magnitude? Seriously? I can buy it costs 2x or 3x. But an additional 2 or 3 zeros on the price? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From woody at pch.net Thu Dec 4 19:28:42 2014 From: woody at pch.net (Bill Woodcock) Date: Thu, 4 Dec 2014 11:28:42 -0800 Subject: ARIN's RPKI Relying agreement In-Reply-To: <15650.1417720901@turing-police.cc.vt.edu> References: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> <1E8005C6-C5E7-4E26-9547-99EF832AAFDC@seastrom.com> <15650.1417720901@turing-police.cc.vt.edu> Message-ID: <6D5B5048-656D-408A-B975-A9E841D92942@pch.net> > On Dec 4, 2014, at 11:21 AM, Valdis.Kletnieks at vt.edu wrote: > > On Thu, 04 Dec 2014 11:17:34 -0800, Bill Woodcock said: >> the RPKI costs are many orders of magnitude higher > > Orders of magnitude? Seriously? I can buy it costs 2x or 3x. > But an additional 2 or 3 zeros on the price? Yep, that’s why all this is at issue. If it were cheap, and worked, like in-addr or whois, there wouldn’t be an issue, would there? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jared at puck.nether.net Thu Dec 4 19:33:01 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Dec 2014 14:33:01 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <4E431394-95B4-49BB-8C60-BB2CC307549A@arin.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> <6451810B-609D-4408-8A08-230739BE38C0@puck.nether.net> <58802CE8-DC2C-463A-8123-9EBFC719E7ED@arin.net> <057C9BCC-7F92-4559-814F-18B2EAED6A51@puck.nether.net> <4E431394-95B4-49BB-8C60-BB2CC307549A@arin.net> Message-ID: > On Dec 4, 2014, at 2:19 PM, John Curran wrote: > > On Dec 4, 2014, at 1:19 PM, Jared Mauch wrote: >> >> I (similar to Rob) have my own concerns about RPKI but do feel that >> this is an ARIN specific construct/wall that has been raised without >> action yet from ARIN. > > Jared - > > Please be specific - are you referring to the indemnification clauses > (which are existing in other RIRs as well), the method of agreement, > or not having ready access to the TAL, i.e. the click-accept access? I have other technical and administrative concerns which I won’t go into great detail here about. > >> The fact that the meeting was 2 months ago and you have not acted/discussed >> with your counsel says everything I need to know about the situation, your >> personal motives and your personal desires for the outcomes. I hope it >> doesn’t represent your employer and that the ARIN Board brings it up with you. > > Incorrect. Despite the lack of clarity, we started work on 27 October > with both inside and external counsel regarding drafting some updates > to the RPKI legal framework. This effort should be ready to be brought > to the ARIN Board in January for their consideration, but it would be > helpful to have more clarity on the concerns (i.e. is it access to the > TAL, or the requirement for explicit agreement to terms and conditions, > or the presence of indemnification/warrant-disclaimer language regardless > of method of binding) the fact it’s taken 3 months to reach the board is of concern to me for an issue that was raised (prior to the October meeting) by operators, and where you were an active part of the discussion afterwards in the back of the plenary room. While you asked Wes, I certainly felt I was clear in telling you Yes that letting the existing RSA where you claimed also covered this would protect ARIN. If you have not discussed this with counsel since then, that feels to me like something that should have already occurred. Perhaps you are waiting until January though, I don’t know your thought process but it seems that a few months is enough time for it to occur (IMHO). > At present, I am working on addressing the TAL access and the explicit > agreement concerns that were raised during Wes's NANOG session. These > are relatively straightforward to work with counsel and propose to the > ARIN Board for their consideration. The issue of indemnification is far > more challenging, and hence my reason for asking about the underlying > need for such and how folks are handling its presence in other RIR RPKI > terms and conditions. The actions of ARIN here speak volumes to the contempt that we observe towards those desiring to do standards body work on RPKI. This concerns me in my role of obtaining ARIN resources. I also wonder what other ways that ARIN has displeasure in the members that it’s not publicly voicing or making apparent. I’m also willing to accept that I may be sleep deprived, grumpy and that everyone here has hit upon a nerve about the RPA which I see as unresolved. At the last IETF meeting I raised the issue that if this (RPKI) goes poorly in its deployment, here we would just be turning it off if there was some catastrophic protocol or operational issue. People depend upon the internet to work and anything to reduce the reliability of it won’t be widely used. I am hoping that ARIN will be a partner in these activities vs what feels like feet dragging along the way. RPKI/SIDR may not be successful in the long term, but until that outcome is reached, we need ARIN to be part of the community and your leadership here is welcome and necessary. - Jared From akg1330 at gmail.com Thu Dec 4 19:34:13 2014 From: akg1330 at gmail.com (Andrew Gallo) Date: Thu, 4 Dec 2014 14:34:13 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> Message-ID: Am I correct in thinking that the SIDR work going on in the IETF takes the registries out of the real-time processing of route authentication/attestation? Is RPKI a stop-gap while we wait for full path validation? Should we be focusing our energies in that area? On Thu, Dec 4, 2014 at 2:19 PM, Sandra Murphy wrote: > > On Dec 4, 2014, at 12:39 PM, John Curran wrote: > > > On Dec 4, 2014, at 11:35 AM, Christopher Morrow > wrote: > > > > > > Note that the claims that could ensue from an operator failing to follow > best practices > > and then third-parties suffering an major operational outage is likely > to be large > > > > > > Undertaking that risk to the other services that everyone else presently > rely upon > > (Whois, reverse DNS) is not reasonable > > Which begs the question for me -- ARIN already operates services that > operators rely upon. Why are they different? Does ARIN run no risk of > litigation due to some perceived involvement of those services in someone's > operational outage? > > Has there been litigation against ARIN tied to, for example, reverse DNS? > Or the IRR? > > --Sandy > > From wesley.george at twcable.com Thu Dec 4 19:35:04 2014 From: wesley.george at twcable.com (George, Wes) Date: Thu, 4 Dec 2014 14:35:04 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> Message-ID: On 12/4/14, 1:34 PM, "Bill Woodcock" wrote: >I’ve asked a lot of people, “Would you be willing to pay ARIN for RPKI >services,” and the answer has always been “no.” Until I get a “yes,” >it’s hard to put a number (other than zero) on how the market values >RPKI. WG] well, if it wasn't clear from my previous message, you've gotten a yes, but it's a qualified yes, and the timeframe, as well as what I'm paying for, matters. We need to put some daylight between "how the market values RPKI" and "whether RPKI is ready for wide-scale deployment" and "what the market expects from ARIN as a service provider for a critical piece of that system when it's in wide-scale deployment". You can see multiple folks expressing concern about other aspects of RPKI beyond ARIN's RPA and liability. Those problems have to be solved before we can have a real discussion about how the market values RPKI, because prior to that it's simply not ready for wide-scale deployment. Additionally, we have a catch-22 in that most of RPKI's benefit is not realized until there are enough prefixes signed and enough large networks validating signatures and dropping invalid announcements, which means the incentive for early adopters is hard to quantify. In other words, the benefits of deploying RPKI that we have to use to justify the costs, whether it's increased ARIN fees or the hardware, complexity, and headcount costs associated with deploying and maintaining it, cannot be realized yet. So, the only thing I know to do is to make sure that I'm working these issues in parallel so that we don't remove one barrier to entry only to crash into the next one. 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 woody at pch.net Thu Dec 4 19:41:52 2014 From: woody at pch.net (Bill Woodcock) Date: Thu, 4 Dec 2014 11:41:52 -0800 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> <6451810B-609D-4408-8A08-230739BE38C0@puck.nether.net> <58802CE8-DC2C-463A-8123-9EBFC719E7ED@arin.net> <057C9BCC-7F92-4559-814F-18B2EAED6A51@puck.nether.net> <4E431394-95B4-49BB-8C60-BB2CC307549A@arin.net> Message-ID: <2E80E77C-97AC-4F79-8DB6-3A32F545B9E0@pch.net> On Dec 4, 2014, at 11:33 AM, Jared Mauch wrote: > the fact it’s taken 3 months to reach the board is of concern Jared, ARIN is now nine years in to applying thrust to this pig. The board does in fact revisit it with some frequency, since it’s expensive and the primary thing blocking other software development efforts, like ARIN Online functionality and so forth. It has not been ignored for the past three months, and it has not been ignored for the past nine years. The question of what to do about it, however, is no more likely to be resolved right now than it has been at any point in its painful history. Please focus on what we can do about it, rather than on the timeframe. John is doing his job. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Valdis.Kletnieks at vt.edu Thu Dec 4 19:48:49 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Dec 2014 14:48:49 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: Your message of "Thu, 04 Dec 2014 11:28:42 -0800." <6D5B5048-656D-408A-B975-A9E841D92942@pch.net> References: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> <1E8005C6-C5E7-4E26-9547-99EF832AAFDC@seastrom.com> <15650.1417720901@turing-police.cc.vt.edu> <6D5B5048-656D-408A-B975-A9E841D92942@pch.net> Message-ID: <17167.1417722529@turing-police.cc.vt.edu> On Thu, 04 Dec 2014 11:28:42 -0800, Bill Woodcock said: > > On Dec 4, 2014, at 11:21 AM, Valdis.Kletnieks at vt.edu wrote: > > Orders of magnitude? Seriously? I can buy it costs 2x or 3x. > > But an additional 2 or 3 zeros on the price? > Yep, thats why all this is at issue. If it were cheap, and > worked, like in-addr or whois, there wouldn't be an issue, would > there? So why does an RPKI request cost *500 times* as much as (say) a request to assign an address block? Why is it *that* much more expensive to handle? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From wesley.george at twcable.com Thu Dec 4 20:06:02 2014 From: wesley.george at twcable.com (George, Wes) Date: Thu, 4 Dec 2014 15:06:02 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> Message-ID: On 12/4/14, 2:34 PM, "Andrew Gallo" wrote: >Am I correct in thinking that the SIDR work going on in the IETF takes the >registries out of the real-time processing of route >authentication/attestation? WG] no, but they're at least discussing ways of making the dependencies less fragile and more scalable (e.g. Eliminating rsync). > >Is RPKI a stop-gap while we wait for full path validation? Should we be >focusing our energies in that area? WG] Path Validation is a completely separate pig, one which may require significantly more thrust to achieve escape velocity when compared with Origin Validation. Origin Validation isn't a stop gap, as much as it is an incremental step that Path Validation builds on to provide more additional protection that Origin Validation alone cannot provide. They're intended to coexist, not replace. 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 baconzombie at gmail.com Thu Dec 4 20:08:00 2014 From: baconzombie at gmail.com (Bacon Zombie) Date: Thu, 4 Dec 2014 21:08:00 +0100 Subject: Cisco CCNA Training (Udemy Discounted Training) In-Reply-To: References: Message-ID: Anybody got codes valid for December? On 14 Nov 2014 18:07, "Wakefield, Thad M." wrote: > Since there was some interest in the Udemy CCNA training, I'll risk > forwarding these additional discounts: > > Remember that this is ONLY for the month of NOVEMBER! > *** CCNA Course is now $24 with coupon code: THANKS24 > https://www.udemy.com/the-complete-ccna-200-120-course/?couponCode=THANKS24 > *** ROUTING Course is now $14 with coupon code: THANKS14 > > https://www.udemy.com/routing-configuration-router-administration/?couponCode=THANKS14 > *** SWITCHING Course is now $9 with coupon code: THANKS9 > https://www.udemy.com/layer-2-switching-vlans/?couponCode=THANKS9 > *** IPv4 Course is now $9 with coupon code: THANKS9 > > https://www.udemy.com/everything-you-need-to-know-about-ipv4-and-its-configuration/?couponCode=THANKS9 > *** IPv6 Course is now $9 with coupon code: THANKS9 > https://www.udemy.com/the_abcs_of_ipv6/?couponCode=THANKS9 > *** VLANs Course is now $5 with coupon code: THANKS5 > > https://www.udemy.com/overview-of-vlans-access-list-nat-bonus-material/?couponCode=THANKS5 > *** OSPF Course is now $14 with coupon code: THANKS14 > https://www.udemy.com/ospf-breakdown/?couponCode=THANKS14 > *** HEX Course is FREE *** use coupon code: THANKSFREE > > https://www.udemy.com/learn-how-to-do-hex-conversions-in-under-30-seconds/?couponCode=THANKSFREE > > From wesley.george at twcable.com Thu Dec 4 20:10:10 2014 From: wesley.george at twcable.com (George, Wes) Date: Thu, 4 Dec 2014 15:10:10 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> Message-ID: On 12/4/14, 2:19 PM, "Sandra Murphy" wrote: >Which begs the question for me -- ARIN already operates services that >operators rely upon. Why are they different? Does ARIN run no risk of >litigation due to some perceived involvement of those services in >someone's operational outage? WG] I'm hard-pressed to come up with a case where packets stop flowing or flow to the wrong party because whois is down. *Maybe* you can make that case for reverse DNS since lots of anti-spam/anti-spoof relies on forward/reverse DNS agreement, but that doesn't affect routing. RPKI ups the ante considerably. I believe ARIN when they say that the liability risks are higher for this. 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 eric at lumaoptics.net Thu Dec 4 20:13:09 2014 From: eric at lumaoptics.net (Eric Litvin) Date: Thu, 4 Dec 2014 12:13:09 -0800 Subject: Cisco CCNA Training (Udemy Discounted Training) In-Reply-To: References: Message-ID: have some juniper but not cisco. On Thu, Dec 4, 2014 at 12:08 PM, Bacon Zombie wrote: > Anybody got codes valid for December? > On 14 Nov 2014 18:07, "Wakefield, Thad M." > wrote: > > > Since there was some interest in the Udemy CCNA training, I'll risk > > forwarding these additional discounts: > > > > Remember that this is ONLY for the month of NOVEMBER! > > *** CCNA Course is now $24 with coupon code: THANKS24 > > > https://www.udemy.com/the-complete-ccna-200-120-course/?couponCode=THANKS24 > > *** ROUTING Course is now $14 with coupon code: THANKS14 > > > > > https://www.udemy.com/routing-configuration-router-administration/?couponCode=THANKS14 > > *** SWITCHING Course is now $9 with coupon code: THANKS9 > > https://www.udemy.com/layer-2-switching-vlans/?couponCode=THANKS9 > > *** IPv4 Course is now $9 with coupon code: THANKS9 > > > > > https://www.udemy.com/everything-you-need-to-know-about-ipv4-and-its-configuration/?couponCode=THANKS9 > > *** IPv6 Course is now $9 with coupon code: THANKS9 > > https://www.udemy.com/the_abcs_of_ipv6/?couponCode=THANKS9 > > *** VLANs Course is now $5 with coupon code: THANKS5 > > > > > https://www.udemy.com/overview-of-vlans-access-list-nat-bonus-material/?couponCode=THANKS5 > > *** OSPF Course is now $14 with coupon code: THANKS14 > > https://www.udemy.com/ospf-breakdown/?couponCode=THANKS14 > > *** HEX Course is FREE *** use coupon code: THANKSFREE > > > > > https://www.udemy.com/learn-how-to-do-hex-conversions-in-under-30-seconds/?couponCode=THANKSFREE > > > > > -- Eric Litvin President eric at lumaoptics.net Direct: (650)440-4382 Mobile:(*650)996-7270* Fax: (650) 618-1870 From contact at winterei.se Thu Dec 4 20:25:17 2014 From: contact at winterei.se (Paul S.) Date: Fri, 05 Dec 2014 05:25:17 +0900 Subject: Cisco CCNA Training (Udemy Discounted Training) In-Reply-To: References: Message-ID: <5480C32D.6060502@winterei.se> Share them anyway? Juniper's certs have enough demand as well :) On 12/5/2014 午前 05:13, Eric Litvin wrote: > have some juniper but not cisco. > > On Thu, Dec 4, 2014 at 12:08 PM, Bacon Zombie wrote: > >> Anybody got codes valid for December? >> On 14 Nov 2014 18:07, "Wakefield, Thad M." >> wrote: >> >>> Since there was some interest in the Udemy CCNA training, I'll risk >>> forwarding these additional discounts: >>> >>> Remember that this is ONLY for the month of NOVEMBER! >>> *** CCNA Course is now $24 with coupon code: THANKS24 >>> >> https://www.udemy.com/the-complete-ccna-200-120-course/?couponCode=THANKS24 >>> *** ROUTING Course is now $14 with coupon code: THANKS14 >>> >>> >> https://www.udemy.com/routing-configuration-router-administration/?couponCode=THANKS14 >>> *** SWITCHING Course is now $9 with coupon code: THANKS9 >>> https://www.udemy.com/layer-2-switching-vlans/?couponCode=THANKS9 >>> *** IPv4 Course is now $9 with coupon code: THANKS9 >>> >>> >> https://www.udemy.com/everything-you-need-to-know-about-ipv4-and-its-configuration/?couponCode=THANKS9 >>> *** IPv6 Course is now $9 with coupon code: THANKS9 >>> https://www.udemy.com/the_abcs_of_ipv6/?couponCode=THANKS9 >>> *** VLANs Course is now $5 with coupon code: THANKS5 >>> >>> >> https://www.udemy.com/overview-of-vlans-access-list-nat-bonus-material/?couponCode=THANKS5 >>> *** OSPF Course is now $14 with coupon code: THANKS14 >>> https://www.udemy.com/ospf-breakdown/?couponCode=THANKS14 >>> *** HEX Course is FREE *** use coupon code: THANKSFREE >>> >>> >> https://www.udemy.com/learn-how-to-do-hex-conversions-in-under-30-seconds/?couponCode=THANKSFREE >>> > > From teleric-lists at outlook.com Thu Dec 4 20:49:36 2014 From: teleric-lists at outlook.com (Teleric Team) Date: Thu, 4 Dec 2014 15:49:36 -0500 Subject: Anybody at Amazon AWS? In-Reply-To: References: Message-ID: > From: amitchell at isipp.com > Subject: Anybody at Amazon AWS? > Date: Thu, 4 Dec 2014 09:15:36 -0700 > To: nanog at nanog.org > > Anybody have a contact at Amazon AWS? > > I sent in a spam complaint, and got back the below response - while I give them kudos for actually, you know, responding, I'm pretty sure that we can all agree that "sending the same canned message to email addresses scraped off websites" is the very definition of spam, yet somehow the EC2 abuse team seems to consider it a perfectly acceptable explanation - I'd sure love to discuss this with someone with a clue at Amazon AWS Did you try their abuse telephone? +1 (206) 266-2187? Once I needed I had proper services on that number. Anyway I am not sure if your contact will make a difference. As I see the case, honestly, it's you complaining against their customer, and Amazon is profiting from that customer. If you and only you are complaining I don't believe you will be heard. Anyway the customer assumed they sent UCE. But won't assume it was a SPAM. As I see the customer states that a e-mail was sent to an e-mail address you have published as contact e-mail address and therefore, they have contacted you. In a canned way, but if it was a personal e-mail offering you something you don't care about, would you fill an abuse report? Or just ignoring/declining the offer? If I right you a polite message right from my MUA and don't mention your name, treating you pretty much like a generic person I don't know, and offering my services, my curricula, or trying to show you a product I have created myself and believe it might be off your interest, it's certainly UCE but will you complain to my provider stating I was spamming you? Well if it's true tha the sender used gmail (you can check your e-mail headers), pasted your address on their MUA or webmail as a Bcc or something like that, and Gmail didn't block the outgoing message, and you (and maybe 2 or 3 other individuals) didn't like that, I don't think Amazon or Google will find it as abuse of services. Certainly it's not a good practice. Not something nice to do, or to receive. But is that an abuse? I don't think so. Specially of a minimum good practice is in place, just like a an opt-out mechanism or similar. Good luck with that phone call. You will find someone to talk to. But I'm not sure you will find someone to agree with you it's an abuse. > --- > > Our customer has responded to your abuse report and provided the following information > > "The below emails were sent individually to the recipient using a canned message. There is no automation or mass emailing at all. Our publisher representative personally visited each of the below websites, decided they were right for our service and emailed them individually. The emails are sent through gmail using a web interface to their API. > > Let me know if you require any additional information. > > Dwayne" > > If you are satisfied with the above information, there is no need to respond to this notice. If you are not satisfied, please respond with a clear, succinct reason for dissatisfaction and what results you desire from our customer. We will make every reasonable attempt to work with you and our customer to resolve this matter. > > Thank you, > The EC2 Abuse team > > --- > > Anne > > Anne P. Mitchell, Esq. > CEO/President > ISIPP SuretyMail Email Accreditation & Certification > Your mail system + SuretyMail accreditation = delivered to their inbox! > http://www.SuretyMail.com/ > http://www.SuretyMail.eu/ > > Author: Section 6 of the Federal CAN-SPAM Act of 2003 > Member, California Bar Cyberspace Law Committee > Ret. Professor of Law, Lincoln Law School of San Jose > https://www.linkedin.com/in/annemitchell > 303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell > > From woody at pch.net Thu Dec 4 21:00:18 2014 From: woody at pch.net (Bill Woodcock) Date: Thu, 4 Dec 2014 13:00:18 -0800 Subject: ARIN's RPKI Relying agreement In-Reply-To: <17167.1417722529@turing-police.cc.vt.edu> References: <12903612.2219.1417710828202.JavaMail.root@benjamin.baylink.com> <1E8005C6-C5E7-4E26-9547-99EF832AAFDC@seastrom.com> <15650.1417720901@turing-police.cc.vt.edu> <6D5B5048-656D-408A-B975-A9E841D92942@pch.net> <17167.1417722529@turing-police.cc.vt.edu> Message-ID: <80169556-0787-4AC8-8E35-932555D27448@pch.net> This pig is less aerodynamic, and fewer people are pushing. In-addr DNS and whois are simple and well-understood protocols, with many programmer-years of software development behind them. The problem isn't the marginal cost of a single transaction, that might only be one or two orders of magnitude higher. The problem is the overhead cost of trying to force a poorly-architected system into a semblance of production-quality. If you want something that anyone can _actually rely upon_, that's a precursor to doing the incremental transactions. -Bill > On Dec 4, 2014, at 11:49, "Valdis.Kletnieks at vt.edu" wrote: > > On Thu, 04 Dec 2014 11:28:42 -0800, Bill Woodcock said: >>> On Dec 4, 2014, at 11:21 AM, Valdis.Kletnieks at vt.edu wrote: >>> Orders of magnitude? Seriously? I can buy it costs 2x or 3x. >>> But an additional 2 or 3 zeros on the price? > >> Yep, thats why all this is at issue. If it were cheap, and >> worked, like in-addr or whois, there wouldn't be an issue, would >> there? > > So why does an RPKI request cost *500 times* as much as (say) a request > to assign an address block? Why is it *that* much more expensive to handle? > From jared at puck.nether.net Thu Dec 4 21:22:25 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Dec 2014 16:22:25 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <2E80E77C-97AC-4F79-8DB6-3A32F545B9E0@pch.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> <6451810B-609D-4408-8A08-230739BE38C0@puck.nether.net> <58802CE8-DC2C-463A-8123-9EBFC719E7ED@arin.net> <057C9BCC-7F92-4559-814F-18B2EAED6A51@puck.nether.net> <4E431394-95B4-49BB-8C60-BB2CC307549A@arin.net> <2E80E77C-97AC-4F79-8DB6-3A32F545B9E0@pch.net> Message-ID: > On Dec 4, 2014, at 2:41 PM, Bill Woodcock wrote: > > > On Dec 4, 2014, at 11:33 AM, Jared Mauch wrote: >> the fact it’s taken 3 months to reach the board is of concern > > Jared, ARIN is now nine years in to applying thrust to this pig. The board does in fact revisit it with some frequency, since it’s expensive and the primary thing blocking other software development efforts, like ARIN Online functionality and so forth. It has not been ignored for the past three months, and it has not been ignored for the past nine years. The question of what to do about it, however, is no more likely to be resolved right now than it has been at any point in its painful history. > > Please focus on what we can do about it, rather than on the timeframe. John is doing his job. Part of that is collecting the feedback, which it seemed was unheard as more than Wes was part of the discussion. If ARIN has given up on RPKI, it would be helpful if that message were communicated to the community. - Jared From jcurran at arin.net Thu Dec 4 22:43:21 2014 From: jcurran at arin.net (John Curran) Date: Thu, 4 Dec 2014 22:43:21 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <956D6B68-CFED-44C2-A57D-66E7A612F082@arin.net> <6451810B-609D-4408-8A08-230739BE38C0@puck.nether.net> <58802CE8-DC2C-463A-8123-9EBFC719E7ED@arin.net> <057C9BCC-7F92-4559-814F-18B2EAED6A51@puck.nether.net> <4E431394-95B4-49BB-8C60-BB2CC307549A@arin.net> Message-ID: <5894AD9E-11AD-46CC-B2BE-E7BE82C24822@arin.net> On Dec 4, 2014, at 2:33 PM, Jared Mauch wrote: > > the fact it’s taken 3 months to reach the board is of concern to me for an issue > that was raised (prior to the October meeting) by operators, andwhere you > were an active part of the discussion afterwards in the back of the plenary > room. Jared - We kicked off a project to address the concerns within two weeks of ARIN/NANOG, doing so despite not have any clear consensus that providing ready access to the TAL without a click-accept RPA and switching to an implicit service agreement would materially improve things. I guess we could have waited for consensus on indemnification (or no indemnification), but it's not clear whether any consensus will ever emerge on that issue. > While you asked Wes, I certainly felt I was clear in telling you > Yes that letting the existing RSA where you claimed also covered this would > protect ARIN. If you have not discussed this with counsel since then, that > feels to me like something that should have already occurred. Perhaps you > are waiting until January though, I don’t know your thought process but > it seems that a few months is enough time for it to occur (IMHO). Addressing these RPKI issues is important, but there is quite a bit of other activities going on at the same time. Furthermore, revisiting RPKI terms and conditions and the imputed risk definitely requires a face-to-face Board discussion, and January is the first one scheduled after the ARIM Baltimore meeting in October. > The actions of ARIN here speak volumes to the contempt that we observe > towards those desiring to do standards body work on RPKI. This concerns > me in my role of obtaining ARIN resources. I also wonder what other ways > that ARIN has displeasure in the members that it’s not publicly voicing > or making apparent. Jared - Feel free to raise any concerns with the Board if you wish; many (like Bill Woodcock) are on the nanog list, but in any case they all have emails listed here - > I’m also willing to accept that I may be sleep deprived, grumpy and that > everyone here has hit upon a nerve about the RPA which I see as unresolved. Agreed, and work is underway to address. > At the last IETF meeting I raised the issue that if this (RPKI) goes poorly > in its deployment, here we would just be turning it off if there was some > catastrophic protocol or operational issue. People depend upon the internet > to work and anything to reduce the reliability of it won’t be widely used. That's very true, but getting folks to invest time & effort in internal, non-customer facing capabilities is very hard (and doubly so for things still in flux like RPKI.) If it were easy, we'll already have a community all of whom used some form of route filtering, either registry or IRR derived, and payoff from adding RPKI would be nominal... > I am hoping that ARIN will be a partner in these activities vs what feels like > feet dragging along the way. RPKI/SIDR may not be successful in the long > term, but until that outcome is reached, we need ARIN to be part of > the community and your leadership here is welcome and necessary. ARIN is very much part of the RPKI community, including participating in the IETF sidr activities, deploying both hosted and delegated RPKI support, etc. We're actively involved, but also attentive to details, particular when it comes to risk analysis. /John John Curran President and CEO ARIN From rhirst at xkl.com Thu Dec 4 19:15:08 2014 From: rhirst at xkl.com (Roy Hirst) Date: Thu, 04 Dec 2014 11:15:08 -0800 Subject: DWDM Documentation In-Reply-To: <40D2CD0E-3518-4CB3-B70A-87FC9ED548C9@theo-voss.de> References: <40D2CD0E-3518-4CB3-B70A-87FC9ED548C9@theo-voss.de> Message-ID: <5480B2BC.3050108@xkl.com> Replying offline to Theo. Schwer zu finden. Roy *Roy Hirst* | 425-556-5773 | 425-324-0941 cell XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA On 12/4/2014 5:21 AM, Theo Voss wrote: > Hi guys, > > we, a Berlin / Germany based carrier, are looking for a smart documentation (shelfs, connections, fibers) and visualization tool for our ADVA-based DWDM-enviroment. Do you have any suggestions or hints for me? We’re testing „cableScout“, the only one I found, next week but. Unfortunately it isn’t easy to get any information about such tools! :( > > Thanks in advance! > > Best regards, > Theo Voss (AS25291) The information contained in this e-mail message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender at the above e-mail address. From m4rtntns at gmail.com Fri Dec 5 07:32:41 2014 From: m4rtntns at gmail.com (Martin T) Date: Fri, 5 Dec 2014 09:32:41 +0200 Subject: determine relationship between the operators based on import and export statements in aut-num object? In-Reply-To: <20141125.165805.515784595415975214.ww@styx.org> References: <20141125.165805.515784595415975214.ww@styx.org> Message-ID: Hi, thanks! I guess one of the most exhaustive and freely-available route-views data to analyze is from RIPE Routing Information Service project? For example if I would like to analyze a certain prefix announced by a certain AS for time period from 1.11.2014 to 30.11.2014, then I should download route-views data for this period(for rrc_id in {00..14}; do for d in {01..30}; do wget http://data.ris.ripe.net/rrc"$rrc_id"/2014.11/bview.201411"$d".0800.gz; done; done) and anayze this with bgpdump(bgpdump -m bview* | grep -w 65133)? Other option would be to use one of the tools like RIPEstat BGPlay? thanks, Martin On 11/25/14, William Waites wrote: > On Tue, 25 Nov 2014 17:36:47 +0200, Martin T said: > > > Last but not least, maybe there is altogether a more reliable > > way to understand the relationship between the operators than > > aut-num objects(often not updated) in RIR database? > > The first thing to do is look and see if the policy of, e.g. AS65133 > is consistent with what you see there. I suspect you'll find a lot of > mismatches but I don't know if that has been studied systematically, > but it should be simple to do. > > Next, much more data intensive, is trawl through the route views data > and see to what extent the actual updates seen are consistent with the > RIR objects, and also see what (topological, not financial as Valdis > points out) relationships they imply that are not present in the RIR > database. > > -w > From jcurran at arin.net Fri Dec 5 07:34:12 2014 From: jcurran at arin.net (John Curran) Date: Fri, 5 Dec 2014 07:34:12 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> Message-ID: <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> On Dec 4, 2014, at 2:19 PM, Sandra Murphy wrote: > ... > Which begs the question for me -- ARIN already operates services that operators rely upon. Why are they different? Does ARIN run no risk of litigation due to some perceived involvement of those services in someone's operational outage? Sandra - From the discussion over on PPML... Parties are likely to use RPKI services such that (as someone put it recently) - "routing decisions are affected and breakage happens” While such impacts could happen with whois, parties would have to create the linkages themselves, whereas with RPKI it is recognized that the system is designed to provide information for influencing of routing decisions (a major difference, and one that a judge could be made to recognize if some service provider has a prolonged outage due to their own self-inflicted Whois data wrangling into routing filters.) Given the nature of RPKI, it is clear that ARIN needs to engineer the service with full awareness of the potential risks (even though such risks are predominantly the result of parties using RPKI data without appropriate best practices.) We have no problem offering a highly- reliable service; the risk of concern stems from third-parties who suffer major damages and want to assert that it was the result of an ISP’s misusage of ARIN’s RPKI service or ARIN’s RPKI service itself, even if the underlying cause in truth was completely unrelated to ARIN’s RPKI services. Recognize that large harmed parties tend to litigate everyone, with the innocent parties extracting themselves only after lengthy battles, and such battles are very difficult when it comes to proving the proper state of technical service at a given point in time. I hope this helps in outlining some of the significant differences. /John John Curran President and CEO ARIN From randy at psg.com Fri Dec 5 11:38:48 2014 From: randy at psg.com (Randy Bush) Date: Fri, 05 Dec 2014 20:38:48 +0900 Subject: ARIN's RPKI Relying agreement In-Reply-To: <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> Message-ID: i run rtconfig to take irr data and auto-install the fiter in my router i run rpki-rtr to take rpki date and auto-install the fiter in my router and the difference is? you ean we made the second easier and more automatable? well then run the rpki data into the handy dandy roa to irr filter and stuff it up rtconfig. randy From nick at foobar.org Fri Dec 5 11:42:26 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 05 Dec 2014 11:42:26 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> Message-ID: <54819A22.2090509@foobar.org> On 05/12/2014 11:38, Randy Bush wrote: > and the difference is? rpki might work at scale. Nick From randy at psg.com Fri Dec 5 11:47:00 2014 From: randy at psg.com (Randy Bush) Date: Fri, 05 Dec 2014 20:47:00 +0900 Subject: ARIN's RPKI Relying agreement In-Reply-To: <54819A22.2090509@foobar.org> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> <54819A22.2090509@foobar.org> Message-ID: >> and the difference is? > rpki might work at scale. ohhh noooooooooo! fwiw, we had a script set running which took a route views dump, created an ersatz roa set covering the whole table, and fetched it into a small router or two. it got boring, so i am not sure it's still there. if you want, we can probably dig it up and put it on a rpki-rtr port again. may take a few weeks as ENOTIME. randy From m.waehlisch at fu-berlin.de Fri Dec 5 11:59:00 2014 From: m.waehlisch at fu-berlin.de (Matthias Waehlisch) Date: Fri, 5 Dec 2014 12:59:00 +0100 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> <54819A22.2090509@foobar.org> Message-ID: On Fri, 5 Dec 2014, Randy Bush wrote: > >> and the difference is? > > rpki might work at scale. > > ohhh noooooooooo! > > fwiw, we had a script set running which took a route views dump, > created an ersatz roa set covering the whole table, and fetched it > into a small router or two. > which implementation? Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From rs at seastrom.com Fri Dec 5 12:06:33 2014 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 05 Dec 2014 07:06:33 -0500 Subject: CAs with dual stacked CRL/OCSP servers Message-ID: <868uim1et2.fsf@valhalla.seastrom.com> At $DAYJOB, we have some applications that we would like to be all hipster and *actually check* for certificate revocation. I know this is way out there in terms of trendiness and may offend some folks. Difficulty: the clients are running on single stacked IPv6. We have recently been advised by our existing CA that they "do not currently have IPv6 support plan" (sic). OCSP Stapling sounds like it could be a winner here. Unfortunately, the software support is not quite ready yet on the platform on either end of the connection (client or server). So... we're looking around for a vendor that's taken the time to dual stack its servers. Any leads? -r From randy at psg.com Fri Dec 5 12:19:07 2014 From: randy at psg.com (Randy Bush) Date: Fri, 05 Dec 2014 21:19:07 +0900 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> <54819A22.2090509@foobar.org> Message-ID: >> fwiw, we had a script set running which took a route views dump, >> created an ersatz roa set covering the whole table, and fetched it >> into a small router or two. > > which implementation? dragon labs randy From tony at lavanauts.org Fri Dec 5 12:19:46 2014 From: tony at lavanauts.org (Antonio Querubin) Date: Fri, 5 Dec 2014 02:19:46 -1000 (HST) Subject: possible twtelecom routing issue Message-ID: Trying to gather information on a connectivity issue between TW Telecom and a specific government web server. If one of your upstream providers is TW Telecom, could you report back whether you have connectivity to https://safe.amrdec.army.mil. Thanks. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From jcurran at arin.net Fri Dec 5 13:12:46 2014 From: jcurran at arin.net (John Curran) Date: Fri, 5 Dec 2014 13:12:46 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> Message-ID: <7A58BC3F-596F-4029-B7EE-021622A9E4D7@arin.net> On Dec 5, 2014, at 6:38 AM, Randy Bush wrote: > > i run rtconfig to take irr data and auto-install the fiter in my router > > i run rpki-rtr to take rpki date and auto-install the fiter in my router > > and the difference is? Not much - that's very likely why RIPE's IRR terms and conditions require the user to hold harmless, indemnify and defend the RIPE NCC; why registering for RADb requires agreeing to indemnify Merit, etc. Thanks, /John John Curran President and CEO ARIN From bensjoberg at gmail.com Fri Dec 5 14:46:13 2014 From: bensjoberg at gmail.com (Ben Sjoberg) Date: Fri, 5 Dec 2014 08:46:13 -0600 Subject: CAs with dual stacked CRL/OCSP servers In-Reply-To: <868uim1et2.fsf@valhalla.seastrom.com> References: <868uim1et2.fsf@valhalla.seastrom.com> Message-ID: Comodo's the only one I know off the top of my head. AAAA records on both the OCSP and CRL domains. On Fri, Dec 5, 2014 at 6:06 AM, Rob Seastrom wrote: > > At $DAYJOB, we have some applications that we would like to be all > hipster and *actually check* for certificate revocation. I know this > is way out there in terms of trendiness and may offend some folks. > > Difficulty: the clients are running on single stacked IPv6. We have > recently been advised by our existing CA that they "do not currently > have IPv6 support plan" (sic). > > OCSP Stapling sounds like it could be a winner here. Unfortunately, > the software support is not quite ready yet on the platform on either > end of the connection (client or server). > > So... we're looking around for a vendor that's taken the time to dual > stack its servers. > > Any leads? > > -r > From johnstong at westmancom.com Fri Dec 5 16:59:33 2014 From: johnstong at westmancom.com (Graham Johnston) Date: Fri, 5 Dec 2014 16:59:33 +0000 Subject: Juniper MX Sizing Message-ID: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From nick at foobar.org Fri Dec 5 17:00:35 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 05 Dec 2014 17:00:35 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> <54819A22.2090509@foobar.org> Message-ID: <5481E4B3.6010607@foobar.org> On 05/12/2014 11:47, Randy Bush wrote: >>> and the difference is? >> rpki might work at scale. > > ohhh noooooooooo! rtconfig + prefix lists were never going to work at scale, so rpsl based filters were mostly only ever deployed on asn edges rather than dfz core inter-as bgp sessions. This meant that the damage that a bad update might cause would be relatively limited in scope. RPSL's scaling limitations do not apply to rpki, so in theory the scope for causing connectivity problems is a good deal greater. So if e.g. ARIN went offline or signed some broken data which caused Joe's Basement ISP in Lawyerville to go offline globally, you can probably see why ARIN would want to limit its liability. Nick From jason at rice.edu Fri Dec 5 17:08:15 2014 From: jason at rice.edu (Jason Bothe) Date: Fri, 5 Dec 2014 11:08:15 -0600 Subject: Juniper MX Sizing In-Reply-To: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> Message-ID: Graham, We use both the MX240 and MX480 (for 100G) 1800REs. Very happy with this hardware. Jason Bothe, Manager of Networking o +1 713 348 5500 m +1 713 703 3552 jason at rice.edu On 5, Dec 2014, at 10:59 AM, Graham Johnston wrote: > I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. > > For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? > > Thanks, > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. > > From james at freedomnet.co.nz Fri Dec 5 17:27:56 2014 From: james at freedomnet.co.nz (james jones) Date: Fri, 5 Dec 2014 12:27:56 -0500 Subject: Juniper MX Sizing In-Reply-To: References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> Message-ID: If you are looking for small foot print I +1 the 240s. On Fri, Dec 5, 2014 at 12:08 PM, Jason Bothe wrote: > Graham, > > We use both the MX240 and MX480 (for 100G) 1800REs. Very happy with this > hardware. > > Jason Bothe, Manager of Networking > > o +1 713 348 5500 > m +1 713 703 3552 > jason at rice.edu > > > > > On 5, Dec 2014, at 10:59 AM, Graham Johnston > wrote: > > > I am wondering if anyone can provide their real world experience about > sizing Juniper MX routers as it relates to BGP. I am needing a device that > has a mix of layer 2 and 3 features, including MPLS, that will have a very > low port count requirement that will primarily be used at a remote POP site > to connect to the local IX as well as one or two full route transit > providers. The MX104 has what I need from a physical standpoint and a data > plane standpoint, as well as power consumption figures. My only concern is > whether the REs have enough horsepower to churn through the convergence > calculations at a rate that operators in this situation would find > acceptable. I realize that 'acceptable' is a moving target so I would > happily accept feedback from people using them as to how long it takes and > their happiness with the product. > > > > For those of you that deem the MX104 unacceptable in this kind of role > and moved up to the MX240, what RE did you elect to use? > > > > Thanks, > > Graham Johnston > > Network Planner > > Westman Communications Group > > 204.717.2829 > > johnstong at westmancom.com > > P think green; don't print this email. > > > > > > From bblackford at gmail.com Fri Dec 5 17:41:42 2014 From: bblackford at gmail.com (Bill Blackford) Date: Fri, 5 Dec 2014 09:41:42 -0800 Subject: Juniper MX Sizing In-Reply-To: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> Message-ID: If you're looking at scaling passed the mx104, I would consider the mx480 chassis. The price delta between the 240 vs. 480 bare chassis is negligible and you'll get more slots to grow into. Especially, if you have a need to do sampling or anything else that may require a service pic. On Dec 5, 2014 9:02 AM, "Graham Johnston" wrote: > I am wondering if anyone can provide their real world experience about > sizing Juniper MX routers as it relates to BGP. I am needing a device that > has a mix of layer 2 and 3 features, including MPLS, that will have a very > low port count requirement that will primarily be used at a remote POP site > to connect to the local IX as well as one or two full route transit > providers. The MX104 has what I need from a physical standpoint and a data > plane standpoint, as well as power consumption figures. My only concern is > whether the REs have enough horsepower to churn through the convergence > calculations at a rate that operators in this situation would find > acceptable. I realize that 'acceptable' is a moving target so I would > happily accept feedback from people using them as to how long it takes and > their happiness with the product. > > For those of you that deem the MX104 unacceptable in this kind of role and > moved up to the MX240, what RE did you elect to use? > > Thanks, > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. > > From johnstong at westmancom.com Fri Dec 5 17:45:24 2014 From: johnstong at westmancom.com (Graham Johnston) Date: Fri, 5 Dec 2014 17:45:24 +0000 Subject: Juniper MX Sizing In-Reply-To: References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> Message-ID: <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int> Shawn, It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com think green; don't print this email. -----Original Message----- From: Shawn Hsiao [mailto:phsiao at tripadvisor.com] Sent: Friday, December 05, 2014 11:30 AM To: Graham Johnston Cc: nanog at nanog.org Subject: Re: Juniper MX Sizing Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. On Dec 5, 2014, at 11:59 AM, Graham Johnston wrote: > I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. > > For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? > > Thanks, > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. > From cscora at apnic.net Fri Dec 5 18:12:18 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Dec 2014 04:12:18 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201412051812.sB5ICI9d010201@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 06 Dec, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 520622 Prefixes after maximum aggregation: 200696 Deaggregation factor: 2.59 Unique aggregates announced to Internet: 254979 Total ASes present in the Internet Routing Table: 48743 Prefixes per ASN: 10.68 Origin-only ASes present in the Internet Routing Table: 36318 Origin ASes announcing only one prefix: 16308 Transit ASes present in the Internet Routing Table: 6211 Transit-only ASes present in the Internet Routing Table: 173 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 115 Max AS path prepend of ASN ( 55644) 76 Prefixes from unregistered ASNs in the Routing Table: 1627 Unregistered ASNs in the Routing Table: 435 Number of 32-bit ASNs allocated by the RIRs: 8081 Number of 32-bit ASNs visible in the Routing Table: 6214 Prefixes from 32-bit ASNs in the Routing Table: 22182 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 391 Number of addresses announced to Internet: 2713242532 Equivalent to 161 /8s, 184 /16s and 203 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.0 Total number of prefixes smaller than registry allocations: 176926 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 128952 Total APNIC prefixes after maximum aggregation: 37453 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 133506 Unique aggregates announced from the APNIC address blocks: 54196 APNIC Region origin ASes present in the Internet Routing Table: 4996 APNIC Prefixes per ASN: 26.72 APNIC Region origin ASes announcing only one prefix: 1206 APNIC Region transit ASes present in the Internet Routing Table: 858 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 115 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1203 Number of APNIC addresses announced to Internet: 737502080 Equivalent to 43 /8s, 245 /16s and 99 /24s Percentage of available APNIC address space announced: 86.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 171637 Total ARIN prefixes after maximum aggregation: 85626 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 173591 Unique aggregates announced from the ARIN address blocks: 82042 ARIN Region origin ASes present in the Internet Routing Table: 16391 ARIN Prefixes per ASN: 10.59 ARIN Region origin ASes announcing only one prefix: 6082 ARIN Region transit ASes present in the Internet Routing Table: 1705 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 275 Number of ARIN addresses announced to Internet: 1054035680 Equivalent to 62 /8s, 211 /16s and 78 /24s Percentage of available ARIN address space announced: 55.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 126164 Total RIPE prefixes after maximum aggregation: 63682 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 131933 Unique aggregates announced from the RIPE address blocks: 82647 RIPE Region origin ASes present in the Internet Routing Table: 17821 RIPE Prefixes per ASN: 7.40 RIPE Region origin ASes announcing only one prefix: 8170 RIPE Region transit ASes present in the Internet Routing Table: 2933 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3249 Number of RIPE addresses announced to Internet: 692420996 Equivalent to 41 /8s, 69 /16s and 129 /24s Percentage of available RIPE address space announced: 100.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59106 Total LACNIC prefixes after maximum aggregation: 10917 LACNIC Deaggregation factor: 5.41 Prefixes being announced from the LACNIC address blocks: 67896 Unique aggregates announced from the LACNIC address blocks: 30854 LACNIC Region origin ASes present in the Internet Routing Table: 2383 LACNIC Prefixes per ASN: 28.49 LACNIC Region origin ASes announcing only one prefix: 645 LACNIC Region transit ASes present in the Internet Routing Table: 478 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1413 Number of LACNIC addresses announced to Internet: 167362752 Equivalent to 9 /8s, 249 /16s and 192 /24s Percentage of available LACNIC address space announced: 99.8 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: 12442 Total AfriNIC prefixes after maximum aggregation: 2974 AfriNIC Deaggregation factor: 4.18 Prefixes being announced from the AfriNIC address blocks: 13305 Unique aggregates announced from the AfriNIC address blocks: 4888 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 18.10 AfriNIC Region origin ASes announcing only one prefix: 205 AfriNIC Region transit ASes present in the Internet Routing Table: 156 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: 74 Number of AfriNIC addresses announced to Internet: 60203008 Equivalent to 3 /8s, 150 /16s and 160 /24s Percentage of available AfriNIC address space announced: 59.8 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 2956 11585 929 Korea Telecom 17974 2832 904 77 PT Telekomunikasi Indonesia 7545 2481 337 129 TPG Telecom Limited 4755 1922 415 190 TATA Communications formerly 4538 1819 4190 71 China Education and Research 9829 1668 1323 28 National Internet Backbone 9808 1495 6655 17 Guangdong Mobile Communicatio 4808 1440 2210 429 CNCGROUP IP network China169 9583 1365 112 563 Sify Limited 9498 1293 336 97 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 2916 2956 141 Cox Communications Inc. 6389 2892 3688 51 BellSouth.net Inc. 18566 2042 379 183 MegaPath Corporation 20115 1829 1805 469 Charter Communications 4323 1645 1053 411 tw telecom holdings, inc. 6983 1632 867 251 EarthLink, Inc. 30036 1503 312 594 Mediacom Communications Corp 701 1423 11265 703 MCI Communications Services, 22561 1309 411 244 CenturyTel Internet Holdings, 11492 1235 218 540 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 1902 298 359 TELLCOM ILETISIM HIZMETLERI A 20940 1510 590 1116 Akamai International B.V. 8402 1383 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 980 93 73 TOV "Bank-Inform" 8551 900 373 43 Bezeq International-Ltd 6849 833 356 25 JSC "Ukrtelecom" 9198 824 346 32 JSC Kazakhtelecom 6830 816 2339 440 Liberty Global Operations B.V 12479 785 788 94 France Telecom Espana SA 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 3045 494 255 Telmex Colombia S.A. 28573 2295 2121 111 NET Servi�os de Comunica��o S 6147 1815 374 30 Telefonica del Peru S.A.A. 7303 1776 1172 240 Telecom Argentina S.A. 8151 1476 3030 424 Uninet S.A. de C.V. 6503 1228 433 58 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 915 2325 35 Tim Celular S.A. 3816 908 394 147 COLOMBIA TELECOMUNICACIONES S 27947 888 129 50 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1421 958 13 TE-AS 24863 959 284 26 Link Egypt (Link.NET) 36903 443 223 97 Office National des Postes et 36992 376 824 29 ETISALAT MISR 24835 308 144 9 Vodafone Data 37492 294 145 63 Orange Tunisie 3741 249 920 212 Internet Solutions 29571 243 22 17 Cote d'Ivoire Telecom 36947 188 807 13 Telecom Algeria 37457 183 160 4 Telkom SA Ltd. 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 3045 494 255 Telmex Colombia S.A. 4766 2956 11585 929 Korea Telecom 22773 2916 2956 141 Cox Communications Inc. 6389 2892 3688 51 BellSouth.net Inc. 17974 2832 904 77 PT Telekomunikasi Indonesia 7545 2481 337 129 TPG Telecom Limited 28573 2295 2121 111 NET Servi�os de Comunica��o S 18566 2042 379 183 MegaPath Corporation 4755 1922 415 190 TATA Communications formerly 34984 1902 298 359 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2892 2841 BellSouth.net Inc. 22773 2916 2775 Cox Communications Inc. 17974 2832 2755 PT Telekomunikasi Indonesia 7545 2481 2352 TPG Telecom Limited 28573 2295 2184 NET Servi�os de Comunica��o S 4766 2956 2027 Korea Telecom 18566 2042 1859 MegaPath Corporation 6147 1815 1785 Telefonica del Peru S.A.A. 4538 1819 1748 China Education and Research 4755 1922 1732 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 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 198.19.252.0/22 49988 Odnoklassniki Limited Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 27.122.56.0/22 55799 Hostemo Technology Sdn Bhd 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:31 /11:92 /12:263 /13:500 /14:1000 /15:1727 /16:13056 /17:7167 /18:11978 /19:24892 /20:35552 /21:37608 /22:55837 /23:48669 /24:279229 /25:1119 /26:1104 /27:716 /28:16 /29:19 /30:10 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2132 2916 Cox Communications Inc. 18566 1997 2042 MegaPath Corporation 6389 1672 2892 BellSouth.net Inc. 6147 1361 1815 Telefonica del Peru S.A.A. 30036 1349 1503 Mediacom Communications Corp 6983 1310 1632 EarthLink, Inc. 34984 1209 1902 TELLCOM ILETISIM HIZMETLERI A 11492 1180 1235 CABLE ONE, INC. 10620 1078 3045 Telmex Colombia S.A. 8402 1051 1383 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1393 2:675 3:3 4:16 5:1236 6:23 8:766 12:1847 13:5 14:1211 15:17 16:2 17:42 18:21 20:51 23:1027 24:1673 27:1814 31:1417 32:39 33:2 34:5 36:149 37:1849 38:974 39:13 40:224 41:3034 42:277 43:764 44:19 45:85 46:2100 47:30 49:760 50:792 52:12 54:60 55:6 56:6 57:31 58:1158 59:660 60:445 61:1750 62:1311 63:1833 64:4372 65:2279 66:4089 67:2000 68:1043 69:3266 70:894 71:429 72:1983 74:2603 75:321 76:411 77:1343 78:993 79:784 80:1338 81:1291 82:818 83:677 84:669 85:1339 86:441 87:1182 88:511 89:1777 90:139 91:5819 92:797 93:1661 94:1982 95:1344 96:425 97:341 98:1048 99:48 100:68 101:782 103:6233 104:794 105:171 106:190 107:854 108:611 109:1991 110:1052 111:1457 112:729 113:905 114:796 115:1236 116:1263 117:1009 118:1662 119:1373 120:438 121:990 122:2192 123:1700 124:1459 125:1567 128:650 129:390 130:381 131:1006 132:434 133:165 134:326 135:84 136:331 137:300 138:387 139:164 140:226 141:423 142:590 143:447 144:511 145:112 146:715 147:561 148:1054 149:400 150:530 151:569 152:482 153:247 154:285 155:653 156:386 157:334 158:251 159:932 160:338 161:592 162:1821 163:374 164:640 165:672 166:301 167:716 168:1168 169:130 170:1430 171:215 172:60 173:1580 174:709 175:583 176:1563 177:3635 178:2067 179:797 180:1822 181:1693 182:1679 183:527 184:720 185:2467 186:2927 187:1696 188:2004 189:1543 190:7920 191:845 192:7866 193:5575 194:4063 195:3623 196:1670 197:875 198:5365 199:5482 200:6540 201:2956 202:9476 203:8993 204:4678 205:2679 206:3001 207:2971 208:3919 209:3813 210:3466 211:1861 212:2463 213:2214 214:858 215:87 216:5531 217:1726 218:648 219:466 220:1301 221:772 222:454 223:671 End of report From bdflemin at gmail.com Fri Dec 5 20:01:55 2014 From: bdflemin at gmail.com (Brad Fleming) Date: Fri, 5 Dec 2014 14:01:55 -0600 Subject: Juniper MX Sizing In-Reply-To: <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int> Message-ID: Then you should look for something other then the MX104. In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. > On Dec 5, 2014, at 11:45 AM, Graham Johnston wrote: > > Shawn, > > It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. > > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > think green; don't print this email. > > -----Original Message----- > From: Shawn Hsiao [mailto:phsiao at tripadvisor.com] > Sent: Friday, December 05, 2014 11:30 AM > To: Graham Johnston > Cc: nanog at nanog.org > Subject: Re: Juniper MX Sizing > > > Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. > > We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. > > > > On Dec 5, 2014, at 11:59 AM, Graham Johnston wrote: > >> I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. >> >> For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? >> >> Thanks, >> Graham Johnston >> Network Planner >> Westman Communications Group >> 204.717.2829 >> johnstong at westmancom.com >> P think green; don't print this email. >> > From ammar at fastreturn.net Fri Dec 5 20:09:56 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sat, 6 Dec 2014 00:09:56 +0400 Subject: Juniper MX Sizing In-Reply-To: References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int> Message-ID: <3EF9B069-DB9F-42D6-965D-A3CE1FD53711@fastreturn.net> What’s a cheaper alternative to the MX104s? We take a full BGP table and are on the AMS-IX and DE-CIX and are looking for a new router. The MX series looks a bit out of budget but we’re currently looking into the Brocade MLX series. We push under 10Gbps, but we do need 10Gbps routing due to capacity issues during attacks. Sorry for being a bit off-topic here. Ammar This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > On Dec 6, 2014, at 12:01 AM, Brad Fleming wrote: > > Then you should look for something other then the MX104. > > In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. > > We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. > > >> On Dec 5, 2014, at 11:45 AM, Graham Johnston wrote: >> >> Shawn, >> >> It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. >> >> Graham Johnston >> Network Planner >> Westman Communications Group >> 204.717.2829 >> johnstong at westmancom.com >> think green; don't print this email. >> >> -----Original Message----- >> From: Shawn Hsiao [mailto:phsiao at tripadvisor.com] >> Sent: Friday, December 05, 2014 11:30 AM >> To: Graham Johnston >> Cc: nanog at nanog.org >> Subject: Re: Juniper MX Sizing >> >> >> Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. >> >> We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. >> >> >> >> On Dec 5, 2014, at 11:59 AM, Graham Johnston wrote: >> >>> I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. >>> >>> For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? >>> >>> Thanks, >>> Graham Johnston >>> Network Planner >>> Westman Communications Group >>> 204.717.2829 >>> johnstong at westmancom.com >>> P think green; don't print this email. >>> >> > From bdflemin at gmail.com Fri Dec 5 21:10:40 2014 From: bdflemin at gmail.com (Brad Fleming) Date: Fri, 5 Dec 2014 15:10:40 -0600 Subject: Juniper MX Sizing In-Reply-To: References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int> Message-ID: We haven’t received the MX480 gear yet (POs just went in about a week ago). But we tested MX960s with the same RE-S-1800x4 w/ 16GB RAM RIB+FIB convergence time was roughly 45sec. We never worried about getting a super accurate time for the MX960 because even an “eye test” showed it was fast enough for our application and we were much more concerned with other parts of the box. Also, we had inline-flow reporting configured on the MX960. Actually, the MX960’s had a full, production-ready config while the MX104 was tested with a stripped down after we discovered the slow convergence. Once we get some MX480s on the bench I’ll report back. > On Dec 5, 2014, at 2:35 PM, Shawn Hsiao wrote: > > > MX480 is also not instantaneous, so the same problem applies. Brad, do you have the number for MX480 for comparison? > > What we decided was, given both models suffer the same problems, just different duration, we decided to mitigate the problem and not spending the money. > > Thanks. > > > > On Dec 5, 2014, at 3:01 PM, Brad Fleming wrote: > >> Then you should look for something other then the MX104. >> >> In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. >> >> We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. >> >> >>> On Dec 5, 2014, at 11:45 AM, Graham Johnston wrote: >>> >>> Shawn, >>> >>> It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. >>> >>> Graham Johnston >>> Network Planner >>> Westman Communications Group >>> 204.717.2829 >>> johnstong at westmancom.com >>> think green; don't print this email. >>> >>> -----Original Message----- >>> From: Shawn Hsiao [mailto:phsiao at tripadvisor.com] >>> Sent: Friday, December 05, 2014 11:30 AM >>> To: Graham Johnston >>> Cc: nanog at nanog.org >>> Subject: Re: Juniper MX Sizing >>> >>> >>> Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. >>> >>> We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. >>> >>> >>> >>> On Dec 5, 2014, at 11:59 AM, Graham Johnston wrote: >>> >>>> I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. >>>> >>>> For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? >>>> >>>> Thanks, >>>> Graham Johnston >>>> Network Planner >>>> Westman Communications Group >>>> 204.717.2829 >>>> johnstong at westmancom.com >>>> P think green; don't print this email. >>>> >>> >> > From bdflemin at gmail.com Fri Dec 5 21:52:31 2014 From: bdflemin at gmail.com (Brad Fleming) Date: Fri, 5 Dec 2014 15:52:31 -0600 Subject: Juniper MX Sizing In-Reply-To: <3EF9B069-DB9F-42D6-965D-A3CE1FD53711@fastreturn.net> References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int> <3EF9B069-DB9F-42D6-965D-A3CE1FD53711@fastreturn.net> Message-ID: <168CDB82-08FE-4947-95A3-FFD773B06EEB@gmail.com> We have both Brocade CER and XMR (predecessor to the MLXe) in our environment today. We find both platforms attractive from a price and power consumption standpoint. They will both handle the IPv4 and IPv6 unicast routing tables today.* The MLXe with MR2 cards is quite a formidable box; lots of power and pretty light-weight OS (compared to Junos). We found our XMR nodes with original mgmt cards and Gen1 line cards converge pretty quick; we’ve never timed one officially but my gut feeling is RIB+FIB convergence is roughly 45sec assuming your peer is RTT nearby. The CER is a little slower to converge in our experience; however, we have them in non-critical portions of the network so I can’t really attest to their convergence performance. Sorry.. not much in the way of lab readings for our Brocade gear. > On Dec 5, 2014, at 2:09 PM, Ammar Zuberi wrote: > > What’s a cheaper alternative to the MX104s? > > We take a full BGP table and are on the AMS-IX and DE-CIX and are looking for a new router. The MX series looks a bit out of budget but we’re currently looking into the Brocade MLX series. We push under 10Gbps, but we do need 10Gbps routing due to capacity issues during attacks. > > Sorry for being a bit off-topic here. > > Ammar > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > >> On Dec 6, 2014, at 12:01 AM, Brad Fleming > wrote: >> >> Then you should look for something other then the MX104. >> >> In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. >> >> We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. >> >> >>> On Dec 5, 2014, at 11:45 AM, Graham Johnston > wrote: >>> >>> Shawn, >>> >>> It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. >>> >>> Graham Johnston >>> Network Planner >>> Westman Communications Group >>> 204.717.2829 >>> johnstong at westmancom.com >>> think green; don't print this email. >>> >>> -----Original Message----- >>> From: Shawn Hsiao [mailto:phsiao at tripadvisor.com] >>> Sent: Friday, December 05, 2014 11:30 AM >>> To: Graham Johnston >>> Cc: nanog at nanog.org >>> Subject: Re: Juniper MX Sizing >>> >>> >>> Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. >>> >>> We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. >>> >>> >>> >>> On Dec 5, 2014, at 11:59 AM, Graham Johnston wrote: >>> >>>> I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. >>>> >>>> For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? >>>> >>>> Thanks, >>>> Graham Johnston >>>> Network Planner >>>> Westman Communications Group >>>> 204.717.2829 >>>> johnstong at westmancom.com >>>> P think green; don't print this email. >>>> >>> >> > From cidr-report at potaroo.net Fri Dec 5 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Dec 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201412052200.sB5M00q4041048@wattle.apnic.net> This report has been generated at Fri Dec 5 21:14:20 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 28-11-14 525097 291796 29-11-14 525194 291783 30-11-14 524970 291808 01-12-14 525076 291759 02-12-14 525080 292208 03-12-14 524889 288423 04-12-14 525476 289213 05-12-14 525863 289628 AS Summary 49001 Number of ASes in routing system 19687 Number of ASes announcing only one prefix 3045 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120175872 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'). --- 05Dec14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 525895 289649 236246 44.9% All ASes AS6389 2892 92 2800 96.8% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2832 83 2749 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2919 173 2746 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS28573 2291 301 1990 86.9% NET Servi�os de Comunica��o S.A.,BR AS4755 1921 238 1683 87.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2956 1298 1658 56.1% KIXS-AS-KR Korea Telecom,KR AS6147 1815 168 1647 90.7% Telefonica del Peru S.A.A.,PE AS7303 1780 294 1486 83.5% Telecom Argentina S.A.,AR AS10620 3045 1581 1464 48.1% Telmex Colombia S.A.,CO AS9808 1494 58 1436 96.1% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1368 26 1342 98.1% CORBINA-AS OJSC "Vimpelcom",RU AS20115 1830 550 1280 69.9% CHARTER-NET-HKY-NC - Charter Communications,US AS4323 1654 413 1241 75.0% TWTC - tw telecom holdings, inc.,US AS7545 2495 1254 1241 49.7% TPG-INTERNET-AP TPG Telecom Limited,AU AS9498 1293 113 1180 91.3% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2041 868 1173 57.5% MEGAPATH5-US - MegaPath Corporation,US AS6983 1632 485 1147 70.3% ITCDELTA - Earthlink, Inc.,US AS7552 1169 51 1118 95.6% VIETEL-AS-AP Viettel Corporation,VN AS34984 1902 864 1038 54.6% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1310 299 1011 77.2% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS4538 1836 949 887 48.3% ERX-CERNET-BKB China Education and Research Network Center,CN AS38285 981 110 871 88.8% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1182 365 817 69.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS31148 1045 228 817 78.2% FREENET-AS Freenet Ltd.,UA AS8151 1482 679 803 54.2% Uninet S.A. de C.V.,MX AS26615 915 133 782 85.5% Tim Celular S.A.,BR AS18101 955 192 763 79.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS4780 1056 294 762 72.2% SEEDNET Digital United Inc.,TW AS17908 838 93 745 88.9% TCISL Tata Communications,IN Total 51928 12335 39593 76.2% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 27.122.56.0/22 AS55799 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 43.245.196.0/24 AS36352 AS-COLOCROSSING - ColoCrossing,US 43.245.197.0/24 AS55286 SERVER-MANIA - B2 Net Solutions Inc.,US 43.245.198.0/24 AS55799 43.245.199.0/24 AS55799 45.192.0.0/12 AS16637 MTNNS-AS,ZA 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -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.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 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.220.84.0/24 AS5577 ROOT root SA,LU 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 102.122.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 102.168.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 103.1.152.0/22 AS55799 103.1.155.0/24 AS55799 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.10.196.0/24 AS55799 103.10.198.0/24 AS55799 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.124.0/24 AS45355 DIGICELPACIFIC-1-AP Clarendon House,FJ 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 , 103.23.148.0/24 AS13209 , 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.27.144.0/22 AS18097 DCN D.C.N. Corporation,JP 103.241.48.0/22 AS24544 PANGNET-AS-AP Pang International Limited-AS number,HK 103.243.4.0/22 AS24295 AS-PNAPOSK Internap Japan Co.,Ltd.,JP 103.243.12.0/24 AS33047 INSTART - Instart Logic, Inc,US 103.243.13.0/24 AS33047 INSTART - Instart Logic, Inc,US 103.243.14.0/24 AS33047 INSTART - Instart Logic, Inc,US 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.193.157.0/24 AS55799 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 181.118.32.0/19 AS28092 181.199.224.0/19 AS28092 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 186.1.128.0/19 AS28092 186.65.108.0/22 AS22927 Telefonica de Argentina,AR 186.96.96.0/19 AS28092 186.148.160.0/19 AS28092 186.190.224.0/21 AS28092 190.2.208.0/21 AS28092 190.9.48.0/21 AS28092 190.13.80.0/21 AS28092 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.52.0/23 AS14455 SUNGARD-RECOVERY - Sungard Network Solutions, Inc.,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 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.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 198.19.252.0/22 AS49988 ODKL-AS Odnoklassniki Ltd,RU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.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.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 Dec 5 22:00:03 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Dec 2014 22:00:03 GMT Subject: BGP Update Report Message-ID: <201412052200.sB5M0387041064@wattle.apnic.net> BGP Update Report Interval: 27-Nov-14 -to- 04-Dec-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 294408 6.0% 2247.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 289126 5.9% 157.7 -- BSNL-NIB National Internet Backbone,IN 3 - AS3816 89250 1.8% 97.5 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 4 - AS53249 80560 1.6% 40280.0 -- LAWA-AS - Los Angeles World Airport,US 5 - AS28024 55814 1.1% 36.6 -- Nuevatel PCS de Bolivia S.A.,BO 6 - AS10620 46311 0.9% 15.1 -- Telmex Colombia S.A.,CO 7 - AS17974 36080 0.7% 12.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 8 - AS17908 31932 0.7% 38.2 -- TCISL Tata Communications,IN 9 - AS4755 31098 0.6% 16.1 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 10 - AS38197 30497 0.6% 26.7 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 11 - AS28573 27909 0.6% 11.1 -- NET Servi�os de Comunica��o S.A.,BR 12 - AS3 24558 0.5% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 13 - AS8402 23690 0.5% 16.1 -- CORBINA-AS OJSC "Vimpelcom",RU 14 - AS42456 22374 0.5% 1721.1 -- CHMURTZ-AS CHMURTZ SARL,FR 15 - AS28642 22317 0.5% 656.4 -- Contato Internet Ltda EPP,BR 16 - AS23342 22168 0.5% 554.2 -- UNITEDLAYER - Unitedlayer, Inc.,US 17 - AS45899 20830 0.4% 38.3 -- VNPT-AS-VN VNPT Corp,VN 18 - AS14840 20808 0.4% 594.5 -- COMMCORP COMUNICACOES LTDA,BR 19 - AS60725 20449 0.4% 1202.9 -- O3B-AS O3b Limited,JE 20 - AS25003 20156 0.4% 544.8 -- INTERNET_BINAT Internet Binat Ltd,IL TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS53249 80560 1.6% 40280.0 -- LAWA-AS - Los Angeles World Airport,US 2 - AS49317 8207 0.2% 8207.0 -- KSPAB Kallmyra System & Produktion AB,SE 3 - AS3 24558 0.5% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 4 - AS62174 5560 0.1% 5560.0 -- INTERPAN-AS INTERPAN LTD.,BG 5 - AS23752 294408 6.0% 2247.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 6 - AS37487 2218 0.0% 2218.0 -- GUINEANET,GQ 7 - AS47805 5577 0.1% 1859.0 -- MCIT Ministry of Communications and Information,SA 8 - AS42456 22374 0.5% 1721.1 -- CHMURTZ-AS CHMURTZ SARL,FR 9 - AS12521 3411 0.1% 1705.5 -- NOVA_INTERNET_AS12521 Nova Internet Network,ES 10 - AS30944 1468 0.0% 1468.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT 11 - AS3 5798 0.1% 5144.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 12 - AS47680 7193 0.1% 1438.6 -- NHCS EOBO Limited,IE 13 - AS56818 1301 0.0% 1301.0 -- DONGISP-AS Communal Enterprise "Informatization center of local selfgovern institutions Donetsk",UA 14 - AS61708 1216 0.0% 1216.0 -- INFOCAT INFORM�TICA LTDA,BR 15 - AS60725 20449 0.4% 1202.9 -- O3B-AS O3b Limited,JE 16 - AS45606 5419 0.1% 1083.8 -- 17 - AS3 1057 0.0% 1349.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 18 - AS52355 2056 0.0% 1028.0 -- Jalasoft Corp.,BO 19 - AS46999 1014 0.0% 1014.0 -- CREWSBANKCORP - Crews Banking Corporation,US 20 - AS4 9941 0.2% 871.0 -- ISI-AS - University of Southern California,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 149326 2.9% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 143681 2.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 198.140.115.0/24 40292 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 4 - 198.140.114.0/24 40268 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 5 - 130.0.192.0/21 24553 0.5% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 6 - 64.29.130.0/24 22129 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 7 - 192.115.44.0/22 19967 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 8 - 91.226.18.0/24 11142 0.2% AS42456 -- CHMURTZ-AS CHMURTZ SARL,FR 9 - 185.26.155.0/24 11023 0.2% AS60725 -- O3B-AS O3b Limited,JE 10 - 192.58.232.0/24 10526 0.2% AS6629 -- NOAA-AS - NOAA,US 11 - 91.226.18.0/23 10222 0.2% AS42456 -- CHMURTZ-AS CHMURTZ SARL,FR 12 - 42.83.48.0/20 10164 0.2% AS18135 -- BTV BTV Cable television,JP 13 - 162.249.183.0/24 9409 0.2% AS60725 -- O3B-AS O3b Limited,JE 14 - 82.80.10.0/24 9303 0.2% AS8551 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone,IL 15 - 192.36.182.0/24 8207 0.2% AS49317 -- KSPAB Kallmyra System & Produktion AB,SE 16 - 88.87.160.0/19 7129 0.1% AS47680 -- NHCS EOBO Limited,IE 17 - 178.159.229.0/24 6302 0.1% AS43967 -- TEREMKI-AS Teremki LAN LLC,US 18 - 202.41.92.0/24 6205 0.1% AS2697 -- ERX-ERNET-AS Education and Research Network,IN 19 - 109.160.4.0/22 5560 0.1% AS62174 -- INTERPAN-AS INTERPAN LTD.,BG 20 - 91.222.202.0/23 5529 0.1% AS47805 -- MCIT Ministry of Communications and Information,SA 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 youssef at 720.fr Sat Dec 6 00:14:50 2014 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Sat, 6 Dec 2014 01:14:50 +0100 Subject: Juniper MX Sizing In-Reply-To: <168CDB82-08FE-4947-95A3-FFD773B06EEB@gmail.com> References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int> <3EF9B069-DB9F-42D6-965D-A3CE1FD53711@fastreturn.net> <168CDB82-08FE-4947-95A3-FFD773B06EEB@gmail.com> Message-ID: <9B38D070-E77C-4723-A03B-5DDF0147C375@720.fr> Hi, Running MLXe with MR2 and/or CER-RT as MPLS PEs depending on POP size. We also run the later as route reflectors. They behave beautifully when it comes to churning BGP full feeds, convergence is around 30-45s (full RAM). Routing capacity is also amazing. I'm particularly amazed by the CER-RT from a price/performance/footprint perspective. So I would advice it unless the OP has some specific technical requirements (flowspec support, etc.). Best regards. > Le 5 déc. 2014 à 22:52, Brad Fleming a écrit : > > We have both Brocade CER and XMR (predecessor to the MLXe) in our environment today. We find both platforms attractive from a price and power consumption standpoint. They will both handle the IPv4 and IPv6 unicast routing tables today.* The MLXe with MR2 cards is quite a formidable box; lots of power and pretty light-weight OS (compared to Junos). We found our XMR nodes with original mgmt cards and Gen1 line cards converge pretty quick; we’ve never timed one officially but my gut feeling is RIB+FIB convergence is roughly 45sec assuming your peer is RTT nearby. The CER is a little slower to converge in our experience; however, we have them in non-critical portions of the network so I can’t really attest to their convergence performance. Sorry.. not much in the way of lab readings for our Brocade gear. > > > >> On Dec 5, 2014, at 2:09 PM, Ammar Zuberi wrote: >> >> What’s a cheaper alternative to the MX104s? >> >> We take a full BGP table and are on the AMS-IX and DE-CIX and are looking for a new router. The MX series looks a bit out of budget but we’re currently looking into the Brocade MLX series. We push under 10Gbps, but we do need 10Gbps routing due to capacity issues during attacks. >> >> Sorry for being a bit off-topic here. >> >> Ammar >> >> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. >> >>> On Dec 6, 2014, at 12:01 AM, Brad Fleming > wrote: >>> >>> Then you should look for something other then the MX104. >>> >>> In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. >>> >>> We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. >>> >>> >>>> On Dec 5, 2014, at 11:45 AM, Graham Johnston > wrote: >>>> >>>> Shawn, >>>> >>>> It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. >>>> >>>> Graham Johnston >>>> Network Planner >>>> Westman Communications Group >>>> 204.717.2829 >>>> johnstong at westmancom.com >>>> think green; don't print this email. >>>> >>>> -----Original Message----- >>>> From: Shawn Hsiao [mailto:phsiao at tripadvisor.com] >>>> Sent: Friday, December 05, 2014 11:30 AM >>>> To: Graham Johnston >>>> Cc: nanog at nanog.org >>>> Subject: Re: Juniper MX Sizing >>>> >>>> >>>> Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. >>>> >>>> We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. >>>> >>>> >>>> >>>>> On Dec 5, 2014, at 11:59 AM, Graham Johnston wrote: >>>>> >>>>> I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. >>>>> >>>>> For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? >>>>> >>>>> Thanks, >>>>> Graham Johnston >>>>> Network Planner >>>>> Westman Communications Group >>>>> 204.717.2829 >>>>> johnstong at westmancom.com >>>>> P think green; don't print this email. > From lester.vanbrunt at avalara.com Fri Dec 5 17:26:11 2014 From: lester.vanbrunt at avalara.com (Lester VanBrunt) Date: Fri, 5 Dec 2014 17:26:11 +0000 Subject: Cisco CCNA Training (Udemy Discounted Training) In-Reply-To: <5480C32D.6060502@winterei.se> References: <5480C32D.6060502@winterei.se> Message-ID: I would be interested in these as well. On 12/4/14, 12:25 PM, "Paul S." wrote: >Share them anyway? Juniper's certs have enough demand as well :) > >On 12/5/2014 午前 05:13, Eric Litvin wrote: >> have some juniper but not cisco. >> >> On Thu, Dec 4, 2014 at 12:08 PM, Bacon Zombie >>wrote: >> >>> Anybody got codes valid for December? >>> On 14 Nov 2014 18:07, "Wakefield, Thad M." >>> >>> wrote: >>> >>>> Since there was some interest in the Udemy CCNA training, I'll risk >>>> forwarding these additional discounts: >>>> >>>> Remember that this is ONLY for the month of NOVEMBER! >>>> *** CCNA Course is now $24 with coupon code: THANKS24 >>>> >>> >>>https://www.udemy.com/the-complete-ccna-200-120-course/?couponCode=THANK >>>S24 >>>> *** ROUTING Course is now $14 with coupon code: THANKS14 >>>> >>>> >>> >>>https://www.udemy.com/routing-configuration-router-administration/?coupo >>>nCode=THANKS14 >>>> *** SWITCHING Course is now $9 with coupon code: THANKS9 >>>> https://www.udemy.com/layer-2-switching-vlans/?couponCode=THANKS9 >>>> *** IPv4 Course is now $9 with coupon code: THANKS9 >>>> >>>> >>> >>>https://www.udemy.com/everything-you-need-to-know-about-ipv4-and-its-con >>>figuration/?couponCode=THANKS9 >>>> *** IPv6 Course is now $9 with coupon code: THANKS9 >>>> https://www.udemy.com/the_abcs_of_ipv6/?couponCode=THANKS9 >>>> *** VLANs Course is now $5 with coupon code: THANKS5 >>>> >>>> >>> >>>https://www.udemy.com/overview-of-vlans-access-list-nat-bonus-material/? >>>couponCode=THANKS5 >>>> *** OSPF Course is now $14 with coupon code: THANKS14 >>>> https://www.udemy.com/ospf-breakdown/?couponCode=THANKS14 >>>> *** HEX Course is FREE *** use coupon code: THANKSFREE >>>> >>>> >>> >>>https://www.udemy.com/learn-how-to-do-hex-conversions-in-under-30-second >>>s/?couponCode=THANKSFREE >>>> >> >> > From phsiao at tripadvisor.com Fri Dec 5 17:29:47 2014 From: phsiao at tripadvisor.com (Shawn Hsiao) Date: Fri, 5 Dec 2014 17:29:47 +0000 Subject: Juniper MX Sizing In-Reply-To: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> Message-ID: Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. On Dec 5, 2014, at 11:59 AM, Graham Johnston wrote: > I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. > > For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? > > Thanks, > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. > From randy at psg.com Fri Dec 5 18:27:48 2014 From: randy at psg.com (Randy Bush) Date: Sat, 06 Dec 2014 03:27:48 +0900 Subject: ARIN's RPKI Relying agreement In-Reply-To: <5481E4B3.6010607@foobar.org> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> <54819A22.2090509@foobar.org> <5481E4B3.6010607@foobar.org> Message-ID: >>> rpki might work at scale. >> ohhh noooooooooo! > > rtconfig + prefix lists were never going to work at scale, so rpsl based > filters were mostly only ever deployed on asn edges rather than dfz core > inter-as bgp sessions. This meant that the damage that a bad update might > cause would be relatively limited in scope. RPSL's scaling limitations do > not apply to rpki, so in theory the scope for causing connectivity problems > is a good deal greater. So if e.g. ARIN went offline or signed some broken > data which caused Joe's Basement ISP in Lawyerville to go offline globally, > you can probably see why ARIN would want to limit its liability. if it works, it is scary and must be stopped! and arin is doing such a great job of that. -------------- next part -------------- randy From phsiao at tripadvisor.com Fri Dec 5 20:35:23 2014 From: phsiao at tripadvisor.com (Shawn Hsiao) Date: Fri, 5 Dec 2014 20:35:23 +0000 Subject: Juniper MX Sizing In-Reply-To: References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int> <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int> Message-ID: MX480 is also not instantaneous, so the same problem applies. Brad, do you have the number for MX480 for comparison? What we decided was, given both models suffer the same problems, just different duration, we decided to mitigate the problem and not spending the money. Thanks. On Dec 5, 2014, at 3:01 PM, Brad Fleming wrote: > Then you should look for something other then the MX104. > > In our testing an MX104 running Junos 13.3R4 with a single, full feed took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT away and (2) update the FIB with all entries. This performance was observed with single RE and dual RE and without any excess services running. If we added inline-flow sampling to the device full convergence took closer to 5min 45sec in our lab. Efforts to bring the convergence time down (without filtering ingress advertisements) with the assistance of JTAC proved unsuccessful. > > We decided to “bite the bullet” and procure MX480s instead but obviously that’s not possible for everyone. If the MX480 is out of the question a Brocade CER Premium is an option. We have 3 in production and see very attractive convergence times; however, they have a more limited feature set and you’ll want to understand how their FIB memory scales. Apologies, I don’t know the Cisco equivalent from the ASR line these days but I’m sure others on the list could help out. > > >> On Dec 5, 2014, at 11:45 AM, Graham Johnston wrote: >> >> Shawn, >> >> It's more about FIB than RIB as I am concerned about the time it takes until MPCs have updated route information after large scale changes in routes learned via BGP. >> >> Graham Johnston >> Network Planner >> Westman Communications Group >> 204.717.2829 >> johnstong at westmancom.com >> think green; don't print this email. >> >> -----Original Message----- >> From: Shawn Hsiao [mailto:phsiao at tripadvisor.com] >> Sent: Friday, December 05, 2014 11:30 AM >> To: Graham Johnston >> Cc: nanog at nanog.org >> Subject: Re: Juniper MX Sizing >> >> >> Is your sizing concern just for the RIB, or also for FIB to sync up? The latter was a problem for us, but not the former. We also have inline-jflow turned on and that is still a work-in-progress in terms of impacting performance. >> >> We are using MX104 for similar purposes for many months now, and with some tweaks in our procedures and configurations we found it to be acceptable. MX104 may not be able to process routes as fast as MX480, but MX480 is also not instantaneous either so similar risks exist. >> >> >> >> On Dec 5, 2014, at 11:59 AM, Graham Johnston wrote: >> >>> I am wondering if anyone can provide their real world experience about sizing Juniper MX routers as it relates to BGP. I am needing a device that has a mix of layer 2 and 3 features, including MPLS, that will have a very low port count requirement that will primarily be used at a remote POP site to connect to the local IX as well as one or two full route transit providers. The MX104 has what I need from a physical standpoint and a data plane standpoint, as well as power consumption figures. My only concern is whether the REs have enough horsepower to churn through the convergence calculations at a rate that operators in this situation would find acceptable. I realize that 'acceptable' is a moving target so I would happily accept feedback from people using them as to how long it takes and their happiness with the product. >>> >>> For those of you that deem the MX104 unacceptable in this kind of role and moved up to the MX240, what RE did you elect to use? >>> >>> Thanks, >>> Graham Johnston >>> Network Planner >>> Westman Communications Group >>> 204.717.2829 >>> johnstong at westmancom.com >>> P think green; don't print this email. >>> >> > From alexb at ripe.net Sat Dec 6 08:27:52 2014 From: alexb at ripe.net (Alex Band) Date: Sat, 6 Dec 2014 09:27:52 +0100 Subject: ARIN's RPKI Relying agreement In-Reply-To: <5481E4B3.6010607@foobar.org> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> <54819A22.2090509@foobar.org> <5481E4B3.6010607@foobar.org> Message-ID: > On 5 Dec 2014, at 18:00, Nick Hilliard wrote: > > On 05/12/2014 11:47, Randy Bush wrote: >>>> and the difference is? >>> rpki might work at scale. >> >> ohhh noooooooooo! > > So if e.g. ARIN went offline or signed some broken > data which caused Joe's Basement ISP in Lawyerville to go offline globally, > you can probably see why ARIN would want to limit its liability. If ARIN (or another other RIR) went offline or signed broken data, all signed prefixes that previously has the RPKI status "Valid", would fall back to the state "Unknown", as if they were never signed in the first place. The state would NOT be "Invalid". What is the likelihood of Joe's Basement ISP being filtered by anyone because their BGP announcements are RPKI "Unknown", as if they weren't participating in the opt-in system? It seems as if the argumentation is built around "RIR messes up == ISPs go offline", but that isn't a realistic scenario IMO, because no operator in their right mind would drop prefixes with the state "Unknown". You could only realistically do that if all 550,000 Announcements in the DFZ are covered by a ROA. Not soon, if ever. -Alex From saku at ytti.fi Sat Dec 6 09:51:56 2014 From: saku at ytti.fi (Saku Ytti) Date: Sat, 6 Dec 2014 11:51:56 +0200 Subject: A case against vendor-locking optical modules In-Reply-To: <546A3A64.6070705@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> Message-ID: <20141206095156.GB11032@pob.ytti.fi> On (2014-11-17 19:11 +0100), Jérôme Nicolle wrote: > What are other arguments against vendor lock-in ? Is there any argument > FOR such locks (please spare me the support issues, if you can't read > specs and SNMP, you shouldn't even try networking) ? > > Did you ever experience a shift in a vendor's position regarding the use > of compatible modules ? Your points are valid, I actually prefer 3rd party, even if it's more expensive than 1st party, just to have simpler sparing reducing OPEX. On RFP all vendors consistently have replied that they won't forbid using 3rd party optics, and won't deny support contract because of them. They may add that if optic is suspected, we need to replace it to 1st party, before TAC continues to work on a case. 1st party does do more testing on the optics than what we typically do, so some obvious problems will be avoided by buying 1st party. But if you are somewhat careful at sourcing your 3rd party, you should be quite safe. I have two examples of major problems caused by 3rd party. a) one particular optic had slow i2c, vendor polled it more aggressively than it could respond. Vendor polling code didn't handle errors reading from i2c, but instead crashed whole linecard control-plane. Vendor claimed it's not bug, because it didn't happen on their optic. I tried to explain to them, they cannot guarantee that I2C reads won't fail on their own optics, and it's serious problem, but was unable to convince them to fix it. Now I am in possession of good bunch of SFP I can stick to your routers in colo, have them crash, and you won't have any clue why they crashed. b) particular vendor had bug in their SFP microcontroller where after 2**31 1/100 of a seconds had passed, it started to write its uptime to a location where DDM temperature measurements are read. This was obvious from graphs, because it went linearily from -127 ... 127, then jumped back to -127. These optics when seated on Vendor1 caused no problems, when seated on Vendor2 they caused link flapping, even two boxes away! (A-B-C, A having problematic optic, B-C might flap). Coincidentally Vendor2 is same as in case a), they didn't consider this was bug in their code. This was particularly funny, if you rebooted 100 boxes in a maintenance window, then the bug would trigger at same moment after 2**31 1/100th of a second, causing potentially major outage. If you source from bad broker, and you hit issue b), you're screwed, because the broker can't tell you which optic you have are impacted by this issue, because bad brokers don't keep tracks on where they source optics, what serial numbers they are, what parts are inside the optics etc. If you source from 1st party, and you hit issue b), 1st party will be able to tell exactly which serial number range is impacted. But this is also true if you use professional 3rd party. -- ++ytti From saku at ytti.fi Sat Dec 6 10:06:34 2014 From: saku at ytti.fi (Saku Ytti) Date: Sat, 6 Dec 2014 12:06:34 +0200 Subject: 10Gb iPerf kit? In-Reply-To: References: Message-ID: <20141206100634.GC11032@pob.ytti.fi> On (2014-11-10 16:26 -0800), Daniel Rohan wrote: > We're looking for a semi-portable solution to validate 10Gb customer > circuits and hitting walls surrounding PCI lanes and the amount of data > laptops can push via their busses. We'd prefer to not have techs lugging > around server equipment for these tests. Maybe something like EXFO or Anritsu. Spirent and Agilent would be best, but probably too expensive if this is the only use-case. > Anyone out there testing 10gbE with iPerf? If so, what are you using? Not possible on iPerf. Network testing shouldn't be done with TCP, because then you don't know what you're testing, are you testing TCP stack of the host or network? But writing performing UDP software is quite hard. You cannot use UDPSocket like iperf does, it just does not work, you are lucky if you reliably test 1Gbps. I'm not aware of modern performing UDP testing software, which is shame, because it's possible to do today, it won't be portable and will impose specific limitations on what hardware to use, but it'll be fast and will deliver reliable results and quite accurate jitter measurement. -- ++ytti From cra at WPI.EDU Sat Dec 6 13:37:01 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 6 Dec 2014 08:37:01 -0500 Subject: A case against vendor-locking optical modules In-Reply-To: <20141206095156.GB11032@pob.ytti.fi> References: <546A3A64.6070705@ceriz.fr> <20141206095156.GB11032@pob.ytti.fi> Message-ID: <20141206133700.GX7116@angus.ind.WPI.EDU> On Sat, Dec 06, 2014 at 11:51:56AM +0200, Saku Ytti wrote: > a) one particular optic had slow i2c, vendor polled it more aggressively than > it could respond. Vendor polling code didn't handle errors reading from i2c, > but instead crashed whole linecard control-plane. > Vendor claimed it's not bug, because it didn't happen on their optic. I tried > to explain to them, they cannot guarantee that I2C reads won't fail on their > own optics, and it's serious problem, but was unable to convince them to fix > it. > Now I am in possession of good bunch of SFP I can stick to your routers in > colo, have them crash, and you won't have any clue why they crashed. > > b) particular vendor had bug in their SFP microcontroller where after 2**31 > 1/100 of a seconds had passed, it started to write its uptime to a location > where DDM temperature measurements are read. This was obvious from graphs, > because it went linearily from -127 ... 127, then jumped back to -127. > These optics when seated on Vendor1 caused no problems, when seated on Vendor2 > they caused link flapping, even two boxes away! (A-B-C, A having problematic > optic, B-C might flap). Coincidentally Vendor2 is same as in case a), they > didn't consider this was bug in their code. > This was particularly funny, if you rebooted 100 boxes in a maintenance > window, then the bug would trigger at same moment after 2**31 1/100th of a > second, causing potentially major outage. Who is Vendor2? From jcurran at arin.net Sat Dec 6 18:26:05 2014 From: jcurran at arin.net (John Curran) Date: Sat, 6 Dec 2014 18:26:05 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> <35463DFF-E30F-4BA2-B201-FFEF8A328B09@arin.net> <54819A22.2090509@foobar.org> <5481E4B3.6010607@foobar.org> Message-ID: On Dec 6, 2014, at 3:27 AM, Alex Band wrote: > > If ARIN (or another other RIR) went offline or signed broken data, all signed prefixes that previously has the RPKI status "Valid", would fall back to the state "Unknown", as if they were never signed in the first place. The state would NOT be "Invalid". Alex - Depends on the nature of the error... In cases of overclaiming, the current validation algorithm could result in "Invalid". This could happen, for example, if major ISP were to initiate transfer of some number resources to their business unit in another region, and then fail locally to swing to certs with the reduced resource list in a timely manner... All of the remaining prefixes in the existing cert would be deemed "invalid" and that could easily result in some very significant disruption for those validating w/RPKI. (i.e. as noted in ) FYI, /John John Curran President and CEO ARIN From faisal at snappytelecom.net Sat Dec 6 19:27:35 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 6 Dec 2014 19:27:35 +0000 (GMT) Subject: vendor-locking optical modules (Question re: IBM G8124E) In-Reply-To: <20141206133700.GX7116@angus.ind.WPI.EDU> References: <546A3A64.6070705@ceriz.fr> <20141206095156.GB11032@pob.ytti.fi> <20141206133700.GX7116@angus.ind.WPI.EDU> Message-ID: <1692634879.139665.1417894055769.JavaMail.zimbra@snappytelecom.net> Hello, Since we are on the topic of vendor locked optics. Does anyone know if the IBM G8124 TOR Switches have a hidden menu option to over-ride the vendor lock optics ? -------- We are seeing something interesting... we have a couple of these in production networks, apparently one switch will accept only IBM Optics, while the other will accept any.... I am not able to find anything which can explain the different behavior on the two switches. If anyone can offer an insights that would be greatly appreciated. Many Thanks in advance. 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: "Chuck Anderson" > To: nanog at nanog.org > Sent: Saturday, December 6, 2014 8:37:01 AM > Subject: Re: A case against vendor-locking optical modules > > On Sat, Dec 06, 2014 at 11:51:56AM +0200, Saku Ytti wrote: > > a) one particular optic had slow i2c, vendor polled it more aggressively > > than > > it could respond. Vendor polling code didn't handle errors reading from > > i2c, > > but instead crashed whole linecard control-plane. > > Vendor claimed it's not bug, because it didn't happen on their optic. I > > tried > > to explain to them, they cannot guarantee that I2C reads won't fail on > > their > > own optics, and it's serious problem, but was unable to convince them to > > fix > > it. > > Now I am in possession of good bunch of SFP I can stick to your routers in > > colo, have them crash, and you won't have any clue why they crashed. > > > > b) particular vendor had bug in their SFP microcontroller where after 2**31 > > 1/100 of a seconds had passed, it started to write its uptime to a location > > where DDM temperature measurements are read. This was obvious from graphs, > > because it went linearily from -127 ... 127, then jumped back to -127. > > These optics when seated on Vendor1 caused no problems, when seated on > > Vendor2 > > they caused link flapping, even two boxes away! (A-B-C, A having > > problematic > > optic, B-C might flap). Coincidentally Vendor2 is same as in case a), they > > didn't consider this was bug in their code. > > This was particularly funny, if you rebooted 100 boxes in a maintenance > > window, then the bug would trigger at same moment after 2**31 1/100th of a > > second, causing potentially major outage. > > Who is Vendor2? > From pete at fiberphone.co.nz Sat Dec 6 20:24:41 2014 From: pete at fiberphone.co.nz (Pete Mundy) Date: Sun, 7 Dec 2014 09:24:41 +1300 Subject: 10Gb iPerf kit? In-Reply-To: <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net> References: <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net> Message-ID: <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> On 11/11/2014, at 1:35 PM, Randy Carpenter wrote: > I have not tried doing that myself, but the only thing that would even be possible that I know of is thunderbolt. > A new MacBook Pro and one of these maybe: http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html Or one of these ones for dual-10Gbit links (one for out of band management or internet?): http://www.sonnettech.com/product/twin10g.html I haven't tried one myself, but they're relatively cheap (for 10gig) so not that much outlay to grab one and try it (esp if you already have an Apple laptop you can test with). I've done loads of 1Gbit testing using the entry-level MacBook Air and a Thunderbolt Gigabit Ethernet adapter though, and I disagree with Saku's statement of 'You cannot use UDPSocket like iperf does, it just does not work, you are lucky if you reliably test 1Gbps'. I find iperf testing at 1Gbit on Mac Air with Thunderbolt Eth extremely reliable (always 950+mbit/sec TCP on a good network, and easy to push right to the 1gbit limit with UDP. Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4145 bytes Desc: not available URL: From saku at ytti.fi Sun Dec 7 08:48:04 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 7 Dec 2014 10:48:04 +0200 Subject: 10Gb iPerf kit? In-Reply-To: <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> References: <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net> <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> Message-ID: <20141207084804.GA12884@pob.ytti.fi> On (2014-12-07 09:24 +1300), Pete Mundy wrote: Hey, > I've done loads of 1Gbit testing using the entry-level MacBook Air and a Thunderbolt Gigabit Ethernet adapter though, and I disagree with Saku's statement of 'You cannot use UDPSocket like iperf does, it just does not work, you are lucky if you reliably test 1Gbps'. I find iperf testing at 1Gbit on Mac Air with Thunderbolt Eth extremely reliable (always 950+mbit/sec TCP on a good network, and easy to push right to the 1gbit limit with UDP. In my experience majority of people using iperf in UDP mode do not monitor for packet loss. And once they start doing, they notice they can't go very fast. For me 1 packet loss due to host issues is absolutely too much,I need flat 0, and in optimal scenario, I'd get microsecond resolution jitter statistics. Granted I've not tried on OSX, perhaps by default it has deeper buffers for UDP. But on Linux, top of the shelf Cisco UCS server with 10GE interfaces running RHEL, and 1Gbps is simply too much, you'll get packet loss. You can observe the packets arriving, but they'll be registered as UDP errors on 'netstat -s', because your program isn't picking them up fast enough. Things iperf could do to perform better - setsockopt for deeper buffers - recvmmsg to pick up multiple messages with single context switch - raw sockets to reduce overhead But ultimately you're still going to be very far from 10Gbps, which is doable, if you'll use something like DPDK. -- ++ytti From matthew at walster.org Sun Dec 7 11:57:15 2014 From: matthew at walster.org (Matthew Walster) Date: Sun, 7 Dec 2014 19:57:15 +0800 Subject: 10Gb iPerf kit? In-Reply-To: <20141207084804.GA12884@pob.ytti.fi> References: <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net> <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> <20141207084804.GA12884@pob.ytti.fi> Message-ID: I find nuttcp very useful in those situations. Be sure to use one of the recent betas, I have been using 7.2.1 for UDP with excellent results (decent loss stats and jitter calc) http://nuttcp.net/nuttcp/beta/nuttcp-7.2.1.c As I understand it, it's still developed, 7.3.2 is now out. M On 7 Dec 2014 16:49, "Saku Ytti" wrote: > On (2014-12-07 09:24 +1300), Pete Mundy wrote: > > Hey, > > > I've done loads of 1Gbit testing using the entry-level MacBook Air and a > Thunderbolt Gigabit Ethernet adapter though, and I disagree with Saku's > statement of 'You cannot use UDPSocket like iperf does, it just does not > work, you are lucky if you reliably test 1Gbps'. I find iperf testing at > 1Gbit on Mac Air with Thunderbolt Eth extremely reliable (always > 950+mbit/sec TCP on a good network, and easy to push right to the 1gbit > limit with UDP. > > In my experience majority of people using iperf in UDP mode do not monitor > for > packet loss. And once they start doing, they notice they can't go very > fast. > For me 1 packet loss due to host issues is absolutely too much,I need flat > 0, > and in optimal scenario, I'd get microsecond resolution jitter statistics. > > Granted I've not tried on OSX, perhaps by default it has deeper buffers for > UDP. But on Linux, top of the shelf Cisco UCS server with 10GE interfaces > running RHEL, and 1Gbps is simply too much, you'll get packet loss. You can > observe the packets arriving, but they'll be registered as UDP errors on > 'netstat -s', because your program isn't picking them up fast enough. > > Things iperf could do to perform better > - setsockopt for deeper buffers > - recvmmsg to pick up multiple messages with single context switch > - raw sockets to reduce overhead > > But ultimately you're still going to be very far from 10Gbps, which is > doable, > if you'll use something like DPDK. > > -- > ++ytti > From nick at foobar.org Sun Dec 7 12:32:26 2014 From: nick at foobar.org (Nick Hilliard) Date: Sun, 07 Dec 2014 12:32:26 +0000 Subject: 10Gb iPerf kit? In-Reply-To: <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> References: <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net> <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> Message-ID: <548448DA.7090305@foobar.org> On 06/12/2014 20:24, Pete Mundy wrote: > I've done loads of 1Gbit testing using the entry-level MacBook Air and a > Thunderbolt Gigabit Ethernet adapter though, and I disagree with Saku's > statement of 'You cannot use UDPSocket like iperf does, it just does not > work, you are lucky if you reliably test 1Gbps'. I find iperf testing at > 1Gbit on Mac Air with Thunderbolt Eth extremely reliable (always > 950+mbit/sec TCP on a good network, and easy to push right to the 1gbit > limit with UDP. i've found that the tb gigabit ethernet adapter starts dropping udp packets at around 600-650mbit/sec on iperf (mbp, MC976xx/A model). Nick From teleric-lists at outlook.com Sun Dec 7 16:15:27 2014 From: teleric-lists at outlook.com (Teleric Team) Date: Sun, 7 Dec 2014 11:15:27 -0500 Subject: possible twtelecom routing issue In-Reply-To: References: Message-ID: > Date: Fri, 5 Dec 2014 02:19:46 -1000 > From: tony at lavanauts.org > To: nanog at nanog.org > Subject: possible twtelecom routing issue > > Trying to gather information on a connectivity issue between TW Telecom > and a specific government web server. If one of your upstream providers > is TW Telecom, could you report back whether you have connectivity to > https://safe.amrdec.army.mil. Thanks. I can reach it through Level3.Is your TW Telecom routing hops L3 already? Or still legacy?Whats your aspath/hops to destination? > > Antonio Querubin > e-mail: tony at lavanauts.org > xmpp: antonioquerubin at gmail.com From nanog at ics-il.net Sun Dec 7 16:24:49 2014 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 7 Dec 2014 10:24:49 -0600 (CST) Subject: Chicago Amazon In-Reply-To: <18100243.187.1417969256996.JavaMail.mhammett@ThunderFuck> Message-ID: <4973442.209.1417969527755.JavaMail.mhammett@ThunderFuck> Is anyone else seeming issues reaching Amazon through Zayo in Chicago? 8 37 ms 44 ms 27 ms 64.125.204.11.allocated.above.net [64.125.204.11] 9 28 ms 13 ms 44 ms ge-11-1-2.mpr2.ord6.us.above.net [64.125.172.81] 10 28 ms 46 ms 27 ms ae11.cr2.ord2.us.above.net [64.125.22.130] 11 95 ms 34 ms 41 ms ae11.cr1.ord2.us.above.net [64.125.20.245] 12 41 ms 54 ms 34 ms ae4.er1.ord7.us.above.net [64.125.28.50] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. Looks like HE is having difficulty as well. 7 20.243 ms 21.120 ms 19.500 ms 72.21.220.175 205.251.244.93 72.21.220.183 8 97.293 ms 21.906 ms 22.774 ms 205.251.245.242 72.21.222.157 205.251.245.53 9 * * * - 10 * * * - 11 * * * - Well, I guess unless they're dropping ICMP... ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From nanog at ics-il.net Sun Dec 7 16:41:51 2014 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 7 Dec 2014 10:41:51 -0600 (CST) Subject: Chicago Amazon In-Reply-To: <4973442.209.1417969527755.JavaMail.mhammett@ThunderFuck> Message-ID: <20445131.285.1417970550645.JavaMail.mhammett@ThunderFuck> I retract my statement. *sigh* First post in many many years and I'm a putz... ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mike Hammett" To: "North American Network Operators' Group" Sent: Sunday, December 7, 2014 10:24:49 AM Subject: Chicago Amazon Is anyone else seeming issues reaching Amazon through Zayo in Chicago? 8 37 ms 44 ms 27 ms 64.125.204.11.allocated.above.net [64.125.204.11] 9 28 ms 13 ms 44 ms ge-11-1-2.mpr2.ord6.us.above.net [64.125.172.81] 10 28 ms 46 ms 27 ms ae11.cr2.ord2.us.above.net [64.125.22.130] 11 95 ms 34 ms 41 ms ae11.cr1.ord2.us.above.net [64.125.20.245] 12 41 ms 54 ms 34 ms ae4.er1.ord7.us.above.net [64.125.28.50] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. Looks like HE is having difficulty as well. 7 20.243 ms 21.120 ms 19.500 ms 72.21.220.175 205.251.244.93 72.21.220.183 8 97.293 ms 21.906 ms 22.774 ms 205.251.245.242 72.21.222.157 205.251.245.53 9 * * * - 10 * * * - 11 * * * - Well, I guess unless they're dropping ICMP... ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From teleric-lists at outlook.com Sun Dec 7 16:48:47 2014 From: teleric-lists at outlook.com (Teleric Team) Date: Sun, 7 Dec 2014 11:48:47 -0500 Subject: 10Gb iPerf kit? In-Reply-To: <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> References: , <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net>, <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> Message-ID: > From: pete at fiberphone.co.nz > Subject: Re: 10Gb iPerf kit? > Date: Sun, 7 Dec 2014 09:24:41 +1300 > To: nanog at nanog.org > > On 11/11/2014, at 1:35 PM, Randy Carpenter wrote: > > > I have not tried doing that myself, but the only thing that would even be possible that I know of is thunderbolt. > > A new MacBook Pro and one of these maybe: http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html > > Or one of these ones for dual-10Gbit links (one for out of band management or internet?): > > http://www.sonnettech.com/product/twin10g.html > > I haven't tried one myself, but they're relatively cheap (for 10gig) so not that much outlay to grab one and try it (esp if you already have an Apple laptop you can test with). > How would you use it? with iperf still?I don't think you will go nearly close to 14.8Mpps per port this way.Unless you are talking about bandwidth testing with full sized packet frames and low pps rate. I personally tested a 1Gbit/s port over a MBP retina 15 thunderbot gbe with BCM5701 chipset. I had only 220kpps on a single TX flow.Later I tried another adapter with a marvel yukon mini port. Had better pps rate, but nothing beyond 260kpps. > I've done loads of 1Gbit testing using the entry-level MacBook Air and a Thunderbolt Gigabit Ethernet adapter though, and I disagree with Saku's statement of 'You cannot use UDPSocket like iperf does, it just does not work, you are lucky if you reliably test 1Gbps'. I find iperf testing at 1Gbit on Mac Air with Thunderbolt Eth extremely reliable (always 950+mbit/sec TCP on a good network, and easy to push right to the 1gbit limit with UDP. Again, with 64byte packet size? Or are you talking MTU? With MTU size you can try whatever you want and it will seem to be reliable. A wget/ftp download of a 1GB file will provide similar results, but I dont think this is useful anyway since it won't test anything close to rfc2544 or at least an ordinary internet traffic profile with a mix of 600bytes pkg size combined with a lower rate of smaller packets (icmp/udp, ping/dns/ntp/voice/video). I am also interested in a cheap and reliable method to test 10GbE connections. So far I haven't found something I trust. > > Pete > From erik.levinson at uberflip.com Sun Dec 7 17:01:40 2014 From: erik.levinson at uberflip.com (Erik Levinson) Date: Sun, 07 Dec 2014 12:01:40 -0500 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs Message-ID: <548487F4.5000306@uberflip.com> All, Could someone from Google public DNS and from GoDaddy contact me off-list? I'm getting SERVFAIL when trying to resolve any record in any domain whose NSs are pdns01.domaincontrol.com/pdns02.domaincontrol.com/pdns05.domaincontrol.com/pdns06.domaincontrol.com (GoDaddy premium DNS), only when using Google's 8.8.8.8 / 8.8.4.4 resolvers, from multiple locations/networks. Resolution is normal using various other public and non-public resolvers, as well as by querying the authoritative name servers directly. You can look at targetly.co as one example (should be just an A record to 184.168.221.38 but getting SERVFAIL when querying 8.8.8.8). Thanks -- Erik Levinson CTO, Uberflip 416-900-3830 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com From bortzmeyer at nic.fr Sun Dec 7 17:19:22 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 7 Dec 2014 18:19:22 +0100 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs In-Reply-To: <548487F4.5000306@uberflip.com> References: <548487F4.5000306@uberflip.com> Message-ID: <20141207171922.GA32179@sources.org> On Sun, Dec 07, 2014 at 12:01:40PM -0500, Erik Levinson wrote a message of 25 lines which said: > I'm getting SERVFAIL when trying to resolve any record in any domain > whose NSs are pdns01.domaincontrol.com/pdns02.domaincontrol.com/pdns05.domaincontrol.com/pdns06.domaincontrol.com > (GoDaddy premium DNS), only when using Google's 8.8.8.8 / 8.8.4.4 > resolvers, from multiple locations/networks. Since Google Public DNS validates, and Go Daddy supports DNSSEC, it would be useful to test with dig +cd (Checking Disabled) to determine if it is a DNSSEC problem or not. > You can look at targetly.co as one example (should be just an A > record to 184.168.221.38 but getting SERVFAIL when querying > 8.8.8.8). Works for me % dig @8.8.8.8 a targetly.co ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @8.8.8.8 a targetly.co ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4056 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;targetly.co. IN A ;; ANSWER SECTION: targetly.co. 242 IN A 184.168.221.38 ;; Query time: 67 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Dec 7 18:07:58 2014 ;; MSG SIZE rcvd: 56 From math at sizone.org Sun Dec 7 17:43:20 2014 From: math at sizone.org (Ken Chase) Date: Sun, 7 Dec 2014 12:43:20 -0500 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs In-Reply-To: <20141207171922.GA32179@sources.org> References: <548487F4.5000306@uberflip.com> <20141207171922.GA32179@sources.org> Message-ID: <20141207174320.GP24184@sizone.org> Agree on blendive.com and blendedperspectives.com Not sure how to identify which chunk of google is failing, but here's a trace for a nonworking query on the above domains: 5. 209.85.241.127 6. google-public-dns-a.google.com (thru TorIX thus the short path). EC2 east is succesful (but I cant trace easily, client restrictions in place grumble). blendive.com name server pdns04.domaincontrol.com. blendive.com name server pdns03.domaincontrol.com. /kc On Sun, Dec 07, 2014 at 06:19:22PM +0100, Stephane Bortzmeyer said: >On Sun, Dec 07, 2014 at 12:01:40PM -0500, > Erik Levinson wrote > a message of 25 lines which said: > >> I'm getting SERVFAIL when trying to resolve any record in any domain >> whose NSs are pdns01.domaincontrol.com/pdns02.domaincontrol.com/pdns05.domaincontrol.com/pdns06.domaincontrol.com >> (GoDaddy premium DNS), only when using Google's 8.8.8.8 / 8.8.4.4 >> resolvers, from multiple locations/networks. > >Since Google Public DNS validates, and Go Daddy supports DNSSEC, it >would be useful to test with dig +cd (Checking Disabled) to determine >if it is a DNSSEC problem or not. > >> You can look at targetly.co as one example (should be just an A >> record to 184.168.221.38 but getting SERVFAIL when querying >> 8.8.8.8). > >Works for me > >% dig @8.8.8.8 a targetly.co > >; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @8.8.8.8 a targetly.co >; (1 server found) >;; global options: +cmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4056 >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > >;; OPT PSEUDOSECTION: >; EDNS: version: 0, flags: do; udp: 512 >;; QUESTION SECTION: >;targetly.co. IN A > >;; ANSWER SECTION: >targetly.co. 242 IN A 184.168.221.38 > >;; Query time: 67 msec >;; SERVER: 8.8.8.8#53(8.8.8.8) >;; WHEN: Sun Dec 7 18:07:58 2014 >;; MSG SIZE rcvd: 56 > -- Ken Chase - math at sizone.org - Toronto Canada From erik.levinson at uberflip.com Sun Dec 7 17:44:36 2014 From: erik.levinson at uberflip.com (Erik Levinson) Date: Sun, 07 Dec 2014 12:44:36 -0500 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs In-Reply-To: <20141207171922.GA32179@sources.org> References: <548487F4.5000306@uberflip.com> <20141207171922.GA32179@sources.org> Message-ID: <54849204.7050809@uberflip.com> On 07/12/14 12:19 PM, Stephane Bortzmeyer wrote: > > Since Google Public DNS validates, and Go Daddy supports DNSSEC, it > would be useful to test with dig +cd (Checking Disabled) to determine > if it is a DNSSEC problem or not. > Tried, still SERVFAIL. I succeeds with +trace though... >> You can look at targetly.co as one example (should be just an A >> record to 184.168.221.38 but getting SERVFAIL when querying >> 8.8.8.8). > > Works for me > Maybe a geo-specific issue then, which is even more weird, because it's still not working for me from two different ASs, though both in Toronto, and a traceroute makes it appear like they're not hitting the same nodes (but maybe they are). What's even more weird is I can actually resolve one domain, startupong.com, but still not targetly.co and others. -- Erik Levinson CTO, Uberflip 416-900-3830 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com From lyle at lcrcomputer.net Sun Dec 7 17:45:45 2014 From: lyle at lcrcomputer.net (Lyle Giese) Date: Sun, 07 Dec 2014 11:45:45 -0600 Subject: Chicago Amazon In-Reply-To: <4973442.209.1417969527755.JavaMail.mhammett@ThunderFuck> References: <4973442.209.1417969527755.JavaMail.mhammett@ThunderFuck> Message-ID: <54849249.1030103@lcrcomputer.net> Interesting traceroute from Comcast in Chicago: Goes from Chicago to Seattle to New York inside the Comcast network. Lyle Giese LCR Computer Services, Inc. traceroute to www.amazon.com (176.32.98.166), 30 hops max, 40 byte packets using UDP 1 lancomcast.lcrcomputer.com (192.168.250.252) 0.165 ms 0.142 ms 0.139 ms 2 c-98-206-192-1.hsd1.il.comcast.net (98.206.192.1) 9.226 ms 15.067 ms 13.166 ms 3 te-0-3-0-13-sur03.mchenry.il.chicago.comcast.net (68.85.131.5) 12.778 ms 11.690 ms 10.688 ms 4 te-2-3-0-1-ar01.elmhurst.il.chicago.comcast.net (68.86.197.165) 16.734 ms te-2-3-0-0-ar01.elmhurst.il.chicago.comcast.net (69.139.235.109) 16.518 ms te-3-1-ur01.mchenry.il.chicago.comcast.net (68.87.210.61) 19.275 ms 5 he-1-6-0-0-11-cr01.seattle.wa.ibone.comcast.net (68.86.92.33) 18.112 ms 12.269 ms 14.449 ms 6 be-10406-cr01.350ecermak.il.ibone.comcast.net (68.86.84.210) 19.087 ms 18.882 ms 17.678 ms 7 be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225) 35.173 ms 34.970 ms 36.902 ms 8 c-eth-0-2-0-pe04.111eighthave.ny.ibone.comcast.net (68.86.87.98) 34.642 ms 34.394 ms 33.321 ms 9 50.242.148.122 (50.242.148.122) 36.920 ms 35.969 ms 33.625 ms 10 54.240.229.84 (54.240.229.84) 33.564 ms 32.941 ms 36.129 ms 11 54.240.228.186 (54.240.228.186) 43.054 ms 54.240.228.204 (54.240.228.204) 42.900 ms 54.240.228.202 (54.240.228.202) 41.204 ms 12 54.240.229.219 (54.240.229.219) 45.652 ms 54.240.229.221 (54.240.229.221) 45.447 ms 54.240.229.223 (54.240.229.223) 44.213 ms 13 54.240.228.163 (54.240.228.163) 40.113 ms 54.240.228.161 (54.240.228.161) 43.994 ms 54.240.228.181 (54.240.228.181) 43.778 ms 14 205.251.244.99 (205.251.244.99) 43.681 ms 205.251.244.91 (205.251.244.91) 42.487 ms 46.121 ms 15 205.251.245.232 (205.251.245.232) 43.837 ms 43.749 ms 205.251.245.226 (205.251.245.226) 43.723 msOn 12/07/14 10:24, Mike Hammett wrote: > Is anyone else seeming issues reaching Amazon through Zayo in Chicago? > > 8 37 ms 44 ms 27 ms 64.125.204.11.allocated.above.net [64.125.204.11] > 9 28 ms 13 ms 44 ms ge-11-1-2.mpr2.ord6.us.above.net [64.125.172.81] > 10 28 ms 46 ms 27 ms ae11.cr2.ord2.us.above.net [64.125.22.130] > 11 95 ms 34 ms 41 ms ae11.cr1.ord2.us.above.net [64.125.20.245] > 12 41 ms 54 ms 34 ms ae4.er1.ord7.us.above.net [64.125.28.50] > 13 * * * Request timed out. > 14 * * * Request timed out. > 15 * * * Request timed out. > > > > Looks like HE is having difficulty as well. > > 7 20.243 ms 21.120 ms 19.500 ms 72.21.220.175 205.251.244.93 72.21.220.183 > 8 97.293 ms 21.906 ms 22.774 ms 205.251.245.242 72.21.222.157 205.251.245.53 > 9 * * * - > 10 * * * - > 11 * * * - > > > > Well, I guess unless they're dropping ICMP... > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > From rubensk at gmail.com Sun Dec 7 17:51:16 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 7 Dec 2014 15:51:16 -0200 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs In-Reply-To: <54849204.7050809@uberflip.com> References: <548487F4.5000306@uberflip.com> <20141207171922.GA32179@sources.org> <54849204.7050809@uberflip.com> Message-ID: > > Maybe a geo-specific issue then, which is even more weird, because it's > still not working for me from two different ASs, though both in Toronto, > and a traceroute makes it appear like they're not hitting the same nodes > (but maybe they are). > > What's even more weird is I can actually resolve one domain, > startupong.com, but still not targetly.co and others. > > Last time we had weird DNS issues with GoDaddy, it was dependent on the querying IP address due to load-balancing issues on their side. Try issuing queries from even and odd IP addresses to see if that makes any difference. Rubens From math at sizone.org Sun Dec 7 17:58:46 2014 From: math at sizone.org (Ken Chase) Date: Sun, 7 Dec 2014 12:58:46 -0500 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs In-Reply-To: References: <548487F4.5000306@uberflip.com> <20141207171922.GA32179@sources.org> <54849204.7050809@uberflip.com> Message-ID: <20141207175845.GS24184@sizone.org> it just started working properly I think. yes, tested from 6 even and odd ips on 3 different AS's (that all go through Torix though). /kc On Sun, Dec 07, 2014 at 03:51:16PM -0200, Rubens Kuhl said: >> >> Maybe a geo-specific issue then, which is even more weird, because it's >> still not working for me from two different ASs, though both in Toronto, >> and a traceroute makes it appear like they're not hitting the same nodes >> (but maybe they are). >> >> What's even more weird is I can actually resolve one domain, >> startupong.com, but still not targetly.co and others. >> >> >Last time we had weird DNS issues with GoDaddy, it was dependent on the >querying IP address due to load-balancing issues on their side. Try issuing >queries from even and odd IP addresses to see if that makes any difference. > > >Rubens -- Ken Chase - math at sizone.org - Toronto Canada From erik.levinson at uberflip.com Sun Dec 7 18:07:16 2014 From: erik.levinson at uberflip.com (Erik Levinson) Date: Sun, 07 Dec 2014 13:07:16 -0500 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs In-Reply-To: <20141207175845.GS24184@sizone.org> References: <548487F4.5000306@uberflip.com> <20141207171922.GA32179@sources.org> <54849204.7050809@uberflip.com> <20141207175845.GS24184@sizone.org> Message-ID: <54849754.4030501@uberflip.com> Nope, it's just super intermittent now...it resolved once and cached it apparently, but still SERVFAIL most of the time if you try repeatedly... Try uberflip.net too. On 07/12/14 12:58 PM, Ken Chase wrote: > it just started working properly I think. yes, tested from 6 even and odd ips > on 3 different AS's (that all go through Torix though). > > /kc > > > On Sun, Dec 07, 2014 at 03:51:16PM -0200, Rubens Kuhl said: > >> > >> Maybe a geo-specific issue then, which is even more weird, because it's > >> still not working for me from two different ASs, though both in Toronto, > >> and a traceroute makes it appear like they're not hitting the same nodes > >> (but maybe they are). > >> > >> What's even more weird is I can actually resolve one domain, > >> startupong.com, but still not targetly.co and others. > >> > >> > >Last time we had weird DNS issues with GoDaddy, it was dependent on the > >querying IP address due to load-balancing issues on their side. Try issuing > >queries from even and odd IP addresses to see if that makes any difference. > > > > > >Rubens > > -- > Ken Chase - math at sizone.org - Toronto Canada > -- Erik Levinson CTO, Uberflip 416-900-3830 x2009 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com From frnkblk at iname.com Sun Dec 7 18:15:35 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 7 Dec 2014 12:15:35 -0600 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs In-Reply-To: <54849754.4030501@uberflip.com> References: <548487F4.5000306@uberflip.com> <20141207171922.GA32179@sources.org> <54849204.7050809@uberflip.com> <20141207175845.GS24184@sizone.org> <54849754.4030501@uberflip.com> Message-ID: <001c01d01249$cbf29650$63d7c2f0$@iname.com> Just failed for me, too. Traceroute suggests I'm testing against Google in Chicago. 10 27 ms 24 ms 24 ms ae5.cr1.ord2.us.above.net [64.125.30.89] 11 29 ms 49 ms 25 ms ae4.er1.ord7.us.above.net [64.125.28.50] 12 30 ms 25 ms 25 ms 72.14.217.53 13 34 ms 32 ms 26 ms 209.85.243.99 14 26 ms 25 ms 25 ms google-public-dns-a.google.com [8.8.8.8] C:\Users\Frank Bulk>dig @8.8.8.8 a targetly.co ; <<>> DiG 9.8.0-P1 <<>> @8.8.8.8 a targetly.co ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47892 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;targetly.co. IN A ;; Query time: 2077 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Dec 07 12:10:22 2014 ;; MSG SIZE rcvd: 29 C:\Users\Frank Bulk> -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Erik Levinson Sent: Sunday, December 07, 2014 12:07 PM To: Ken Chase; Rubens Kuhl Cc: Nanog Subject: Re: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs Nope, it's just super intermittent now...it resolved once and cached it apparently, but still SERVFAIL most of the time if you try repeatedly... Try uberflip.net too. On 07/12/14 12:58 PM, Ken Chase wrote: > it just started working properly I think. yes, tested from 6 even and odd ips > on 3 different AS's (that all go through Torix though). > > /kc > > > On Sun, Dec 07, 2014 at 03:51:16PM -0200, Rubens Kuhl said: > >> > >> Maybe a geo-specific issue then, which is even more weird, because it's > >> still not working for me from two different ASs, though both in Toronto, > >> and a traceroute makes it appear like they're not hitting the same nodes > >> (but maybe they are). > >> > >> What's even more weird is I can actually resolve one domain, > >> startupong.com, but still not targetly.co and others. > >> > >> > >Last time we had weird DNS issues with GoDaddy, it was dependent on the > >querying IP address due to load-balancing issues on their side. Try issuing > >queries from even and odd IP addresses to see if that makes any difference. > > > > > >Rubens > > -- > Ken Chase - math at sizone.org - Toronto Canada > -- Erik Levinson CTO, Uberflip 416-900-3830 x2009 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com From erik.levinson at uberflip.com Sun Dec 7 18:44:30 2014 From: erik.levinson at uberflip.com (Erik Levinson) Date: Sun, 07 Dec 2014 13:44:30 -0500 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs In-Reply-To: <001c01d01249$cbf29650$63d7c2f0$@iname.com> References: <548487F4.5000306@uberflip.com> <20141207171922.GA32179@sources.org> <54849204.7050809@uberflip.com> <20141207175845.GS24184@sizone.org> <54849754.4030501@uberflip.com> <001c01d01249$cbf29650$63d7c2f0$@iname.com> Message-ID: <5484A00E.5040506@uberflip.com> Heh...when it succeeds for me sometimes now, if I do it repeatedly, I can see two different TTL sets each time, so I know I'm hitting at least two nodes / sets of nodes... One of my traceroutes from 151 Front suggests the node is in the building, as the latency is well under 1ms. On 07/12/14 01:15 PM, Frank Bulk wrote: > Just failed for me, too. Traceroute suggests I'm testing against Google in > Chicago. > > 10 27 ms 24 ms 24 ms ae5.cr1.ord2.us.above.net [64.125.30.89] > 11 29 ms 49 ms 25 ms ae4.er1.ord7.us.above.net [64.125.28.50] > 12 30 ms 25 ms 25 ms 72.14.217.53 > 13 34 ms 32 ms 26 ms 209.85.243.99 > 14 26 ms 25 ms 25 ms google-public-dns-a.google.com [8.8.8.8] > > C:\Users\Frank Bulk>dig @8.8.8.8 a targetly.co > > ; <<>> DiG 9.8.0-P1 <<>> @8.8.8.8 a targetly.co > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47892 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;targetly.co. IN A > > ;; Query time: 2077 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Sun Dec 07 12:10:22 2014 > ;; MSG SIZE rcvd: 29 > > > C:\Users\Frank Bulk> > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Erik Levinson > Sent: Sunday, December 07, 2014 12:07 PM > To: Ken Chase; Rubens Kuhl > Cc: Nanog > Subject: Re: Google public DNS - getting SERVFAIL for any domains delegated > to GoDaddy NSs > > Nope, it's just super intermittent now...it resolved once and cached it > apparently, but still SERVFAIL most of the time if you try repeatedly... > > Try uberflip.net too. > > On 07/12/14 12:58 PM, Ken Chase wrote: >> it just started working properly I think. yes, tested from 6 even and odd > ips >> on 3 different AS's (that all go through Torix though). >> >> /kc >> >> >> On Sun, Dec 07, 2014 at 03:51:16PM -0200, Rubens Kuhl said: >> >> >> >> Maybe a geo-specific issue then, which is even more weird, because > it's >> >> still not working for me from two different ASs, though both in > Toronto, >> >> and a traceroute makes it appear like they're not hitting the same > nodes >> >> (but maybe they are). >> >> >> >> What's even more weird is I can actually resolve one domain, >> >> startupong.com, but still not targetly.co and others. >> >> >> >> >> >Last time we had weird DNS issues with GoDaddy, it was dependent on > the >> >querying IP address due to load-balancing issues on their side. Try > issuing >> >queries from even and odd IP addresses to see if that makes any > difference. >> > >> > >> >Rubens >> >> -- >> Ken Chase - math at sizone.org - Toronto Canada >> > -- Erik Levinson CTO, Uberflip 416-900-3830 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com From jimpop at gmail.com Sun Dec 7 19:24:33 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Sun, 7 Dec 2014 14:24:33 -0500 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs In-Reply-To: <548487F4.5000306@uberflip.com> References: <548487F4.5000306@uberflip.com> Message-ID: On Sun, Dec 7, 2014 at 12:01 PM, Erik Levinson wrote: > All, > > Could someone from Google public DNS and from GoDaddy contact me off-list? > > I'm getting SERVFAIL when trying to resolve any record in any domain whose > NSs are > pdns01.domaincontrol.com/pdns02.domaincontrol.com/pdns05.domaincontrol.com/pdns06.domaincontrol.com > (GoDaddy premium DNS), only when using Google's 8.8.8.8 / 8.8.4.4 resolvers, > from multiple locations/networks. > > Resolution is normal using various other public and non-public resolvers, as > well as by querying the authoritative name servers directly. > > You can look at targetly.co as one example (should be just an A record to > 184.168.221.38 but getting SERVFAIL when querying 8.8.8.8). FWIW, in the past GoDaddy has periodically blocked queries from Google Public DNS infrastructure. Heavily discussed and documented here: https://groups.google.com/forum/#!searchin/public-dns-discuss/godaddy -Jim P. From mkamal at noor.net Sun Dec 7 20:09:51 2014 From: mkamal at noor.net (Mohamed Kamal) Date: Sun, 07 Dec 2014 23:09:51 +0300 Subject: Carrier-grade DDoS Attack mitigation appliance Message-ID: <5484B40F.3010203@noor.net> Have anyone tried any DDoS attack mitigation appliance rather than Arbor PeakFlow TMS? I need it to be carrier-grade in terms of capacity and redundancy, and as far as I know, Arbor is the only product in the market which offers a "clean pipe" volume of traffic, so if the DDoS attack volume is, for example, 1Tbps, they will grant you for example 50Gbps of clean traffic. Anyway, I'm open to other suggestions, and open-source products that can do the same purpose, we have network development team that can work on this. Thanks. -- Mohamed Kamal Core Network Sr. Engineer From ammar at fastreturn.net Sun Dec 7 20:32:51 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Mon, 8 Dec 2014 00:32:51 +0400 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: <5484B40F.3010203@noor.net> References: <5484B40F.3010203@noor.net> Message-ID: Hi, A lot of new vendors have entered the DDoS attack prevention market other than Arbor, I've seen carrier grade devices made by Huawei, NSFocus, RioRey and many others. If you're looking at something software based, I've used Andrisoft WanGuard and would recommend it. Ammar. > On 8 Dec 2014, at 12:09 am, Mohamed Kamal wrote: > > > Have anyone tried any DDoS attack mitigation appliance rather than Arbor PeakFlow TMS? I need it to be carrier-grade in terms of capacity and redundancy, and as far as I know, Arbor is the only product in the market which offers a "clean pipe" volume of traffic, so if the DDoS attack volume is, for example, 1Tbps, they will grant you for example 50Gbps of clean traffic. > > Anyway, I'm open to other suggestions, and open-source products that can do the same purpose, we have network development team that can work on this. > > Thanks. > > -- > Mohamed Kamal > Core Network Sr. Engineer > From jordan-medlen at bisk.com Sun Dec 7 20:33:04 2014 From: jordan-medlen at bisk.com (Jordan Medlen) Date: Sun, 7 Dec 2014 20:33:04 +0000 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: <5484B40F.3010203@noor.net> References: <5484B40F.3010203@noor.net> Message-ID: I've heard good things about the A10 Networks appliances. I have not used them personally, but do use their ADC appliances and they do work well. Jordan Medlen Network Engineer Bisk Education Sent from my iPhone > On Dec 7, 2014, at 15:12, Mohamed Kamal wrote: > > > Have anyone tried any DDoS attack mitigation appliance rather than Arbor PeakFlow TMS? I need it to be carrier-grade in terms of capacity and redundancy, and as far as I know, Arbor is the only product in the market which offers a "clean pipe" volume of traffic, so if the DDoS attack volume is, for example, 1Tbps, they will grant you for example 50Gbps of clean traffic. > > Anyway, I'm open to other suggestions, and open-source products that can do the same purpose, we have network development team that can work on this. > > Thanks. > > -- > Mohamed Kamal > Core Network Sr. Engineer > > From me at staticsafe.ca Sun Dec 7 22:47:30 2014 From: me at staticsafe.ca (staticsafe) Date: Sun, 07 Dec 2014 17:47:30 -0500 Subject: CAs with dual stacked CRL/OCSP servers In-Reply-To: <868uim1et2.fsf@valhalla.seastrom.com> References: <868uim1et2.fsf@valhalla.seastrom.com> Message-ID: <5484D902.4000104@staticsafe.ca> On 12/5/2014 07:06, Rob Seastrom wrote: > > At $DAYJOB, we have some applications that we would like to be all > hipster and *actually check* for certificate revocation. I know this > is way out there in terms of trendiness and may offend some folks. > > Difficulty: the clients are running on single stacked IPv6. We have > recently been advised by our existing CA that they "do not currently > have IPv6 support plan" (sic). > > OCSP Stapling sounds like it could be a winner here. Unfortunately, > the software support is not quite ready yet on the platform on either > end of the connection (client or server). > > So... we're looking around for a vendor that's taken the time to dual > stack its servers. > > Any leads? > > -r > GlobalSign does. ~# host ocsp2.globalsign.com ocsp2.globalsign.com has address 108.162.232.200 ocsp2.globalsign.com has address 108.162.232.202 ocsp2.globalsign.com has address 108.162.232.207 ocsp2.globalsign.com has address 108.162.232.197 ocsp2.globalsign.com has address 108.162.232.198 ocsp2.globalsign.com has address 108.162.232.205 ocsp2.globalsign.com has address 108.162.232.203 ocsp2.globalsign.com has address 108.162.232.199 ocsp2.globalsign.com has address 108.162.232.196 ocsp2.globalsign.com has address 108.162.232.201 ocsp2.globalsign.com has address 108.162.232.204 ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c7 ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c6 ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8cc ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8cd ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c5 ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8ca ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c4 ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8cf ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8cb ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c9 ocsp2.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c8 crl.globalsign.com has address 108.162.232.205 crl.globalsign.com has address 108.162.232.197 crl.globalsign.com has address 108.162.232.203 crl.globalsign.com has address 108.162.232.204 crl.globalsign.com has address 108.162.232.198 crl.globalsign.com has address 108.162.232.200 crl.globalsign.com has address 108.162.232.202 crl.globalsign.com has address 108.162.232.196 crl.globalsign.com has address 108.162.232.201 crl.globalsign.com has address 108.162.232.207 crl.globalsign.com has address 108.162.232.199 crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8ca crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c8 crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8cb crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8cf crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c4 crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c6 crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c9 crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8cc crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8cd crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c5 crl.globalsign.com has IPv6 address 2400:cb00:2048:1::6ca2:e8c7 -- staticsafe https://staticsafe.ca From math at sizone.org Sun Dec 7 22:59:10 2014 From: math at sizone.org (Ken Chase) Date: Sun, 7 Dec 2014 17:59:10 -0500 Subject: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs In-Reply-To: References: <548487F4.5000306@uberflip.com> Message-ID: <20141207225910.GW24184@sizone.org> On Sun, Dec 07, 2014 at 02:24:33PM -0500, Jim Popovitch said: >FWIW, in the past GoDaddy has periodically blocked queries from Google >Public DNS infrastructure. Heavily discussed and documented here: >https://groups.google.com/forum/#!searchin/public-dns-discuss/godaddy from that, if this is to be believed: "GoDaddy's two nameservers ns29.domaincontrol.com and ns30.domaincontrol.com have been blocking Google Public DNS. We contacted GoDaddy and they have lifted the blockage. The issue has resolved." then it's godaddy. Godaddy: comments? /kc -- Ken Chase - math at sizone.org - Toronto Canada From rdobbins at arbor.net Sun Dec 7 23:08:57 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 7 Dec 2014 15:08:57 -0800 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: <5484B40F.3010203@noor.net> References: <5484B40F.3010203@noor.net> Message-ID: <8778797461487429874@unknownmsgid> On Dec 7, 2014, at 12:10 PM, Mohamed Kamal wrote: so if the DDoS attack volume is, for example, 1Tbps, they will grant you for example 50Gbps of clean traffic. Please feel free to contact me off-list if I can assist, as it seems you've been provided with incorrect information. ------------------------------------ Roland Dobbins From akg1330 at gmail.com Mon Dec 8 01:01:01 2014 From: akg1330 at gmail.com (Andrew Gallo) Date: Sun, 7 Dec 2014 20:01:01 -0500 Subject: Followup: Survey results for the ARIN RPA Message-ID: There have been 28 response to the survey I put out last week. The key numbers are: We have read and will not sign the agreement 10 36% We are considering signing the agreement 1 4% We haven't yet read it 5 18% and Our legal staff has reviewed and rejected the agreement. 7 25% We have provided specific legal feedback to ARIN on the agreement. 2 7% I'll draw the obvious conclusion: While not scientific, these numbers, combined with the, well, lively, discussion the past few days show some serious dissatisfaction with the agreement required in order to access, and therefore validate, ROAs in the ARIN region. And there in lies my interest in all of this- there is little value in signing my org's routes if no one is going to validate them. It's a bit of an odd position in that I have a very high interest in what the rest of the community thinks of and how they act with respect to the RPA. In other words, your relationship with ARIN is now of concern to me. Maybe I'm being naively optimistic in thinking that these are solvable problems. From randy at psg.com Mon Dec 8 02:40:23 2014 From: randy at psg.com (Randy Bush) Date: Mon, 08 Dec 2014 11:40:23 +0900 Subject: Followup: Survey results for the ARIN RPA In-Reply-To: References: Message-ID: > And there in lies my interest in all of this- there is little value in > signing my org's routes if no one is going to validate them. It's a bit of > an odd position in that I have a very high interest in what the rest of the > community thinks of and how they act with respect to the RPA. In other > words, your relationship with ARIN is now of concern to me. > > Maybe I'm being naively optimistic in thinking that these are solvable > problems. there is the rest of the world, it is a global internet. the north american influence decreases continuously, some because of growth of the global internet, which is a good thing. some because of noam making itself less and less relevant, as you point out. take a look at http://archive.psg.com://rpki-rollout.jpg kinda tells you what's happening, eh? lacnic has more roll-out than arin, and proportionally it is even more impressive; over 20% of lacnic allocations have roas. and there is ripe, with the sheer numbers. randy From colton.conor at gmail.com Mon Dec 8 03:46:20 2014 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 7 Dec 2014 21:46:20 -0600 Subject: DWDM Documentation In-Reply-To: <5480B2BC.3050108@xkl.com> References: <40D2CD0E-3518-4CB3-B70A-87FC9ED548C9@theo-voss.de> <5480B2BC.3050108@xkl.com> Message-ID: What have you found so far? On Thu, Dec 4, 2014 at 1:15 PM, Roy Hirst wrote: > Replying offline to Theo. Schwer zu finden. > Roy > > *Roy Hirst* | 425-556-5773 | 425-324-0941 cell > XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA > > > On 12/4/2014 5:21 AM, Theo Voss wrote: > >> Hi guys, >> >> we, a Berlin / Germany based carrier, are looking for a smart >> documentation (shelfs, connections, fibers) and visualization tool for our >> ADVA-based DWDM-enviroment. Do you have any suggestions or hints for me? >> We’re testing „cableScout“, the only one I found, next week but. >> Unfortunately it isn’t easy to get any information about such tools! :( >> >> Thanks in advance! >> >> Best regards, >> Theo Voss (AS25291) >> > > > > > The information contained in this e-mail message may be privileged, > confidential and protected from disclosure. > If you are not the intended recipient, any dissemination, distribution or > copying is strictly prohibited. > If you think that you have received this e-mail message in error, please > e-mail the sender at the above e-mail address. > > From jcurran at arin.net Mon Dec 8 05:14:01 2014 From: jcurran at arin.net (John Curran) Date: Mon, 8 Dec 2014 05:14:01 +0000 Subject: Followup: Survey results for the ARIN RPA In-Reply-To: References: Message-ID: On Dec 7, 2014, at 9:40 PM, Randy Bush wrote: > >> And there in lies my interest in all of this- there is little value in >> signing my org's routes if no one is going to validate them. It's a bit of >> an odd position in that I have a very high interest in what the rest of the >> community thinks of and how they act with respect to the RPA. In other >> words, your relationship with ARIN is now of concern to me. >> >> Maybe I'm being naively optimistic in thinking that these are solvable >> problems. > > there is the rest of the world, it is a global internet. the north > american influence decreases continuously, some because of growth of the > global internet, which is a good thing. some because of noam making > itself less and less relevant, as you point out. > > take a look at > > http://archive.psg.com://rpki-rollout.jpg > > kinda tells you what's happening, eh? lacnic has more roll-out than > arin, and proportionally it is even more impressive; over 20% of lacnic > allocations have roas. and there is ripe, with the sheer numbers. One could easily presume the ARIN region RPKI deployment statistics are lower as a result of the RPA situation (and no doubt that it part of the issue), but as noted earlier, it's unlikely to be the full story since we also have a region (APNIC) where RPKI deployment also rather low that and yet does not have these RPA legal entanglements. It was suggested earlier that this may be due to a combination of factors (education, promotion) beyond the RPA legal issues that are now being worked - so that will also need to be addressed once the RPA is resolved. /John John Curran President and CEO ARIN From randy at psg.com Mon Dec 8 05:20:25 2014 From: randy at psg.com (Randy Bush) Date: Mon, 08 Dec 2014 14:20:25 +0900 Subject: Followup: Survey results for the ARIN RPA In-Reply-To: References: Message-ID: > One could easily presume the ARIN region RPKI deployment statistics > are lower as a result of the RPA situation (and no doubt that it part > of the issue), but as noted earlier, it's unlikely to be the full > story since we also have a region (APNIC) where RPKI deployment also > rather low that and yet does not have these RPA legal entanglements. > > It was suggested earlier that this may be due to a combination of > factors (education, promotion) beyond the RPA legal issues that are > now being worked - so that will also need to be addressed once the RPA > is resolved. definitely agree. lacnic and ripe have put effort in their respective communities (yay alex!). heck, ripe even resolved the PI and legacy policy issues so everyone can play (speaking of sick arin legal documents). randy From rhirst at xkl.com Mon Dec 8 16:29:10 2014 From: rhirst at xkl.com (Roy Hirst) Date: Mon, 08 Dec 2014 08:29:10 -0800 Subject: 10Gb iPerf kit? In-Reply-To: References: , <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net>, <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> Message-ID: <5485D1D6.3060104@xkl.com> Can't help with faster adapters, but I believe there are some underlying architectural issues here as to why the speeds are hard to achieve, and why some people can and others maybe can't achieve them. For Carrier Ethernet, I believe most of these are covered in RFC2444 and the related RFC6815. Even with bit speeds up to spec, traffic speeds are impacted non-linearly by customer protocols including the usual suspect, TCP. This is documented in ITU-T Y.1564, clearly enough for simple folk like me. A good example for your corkboard is slide (page) 28 of the excellent 20140409-Tierney-100G-experience-Internet2-Summit.pdf, included as part of a report on 100GE performance test methodologies. Which is how I stumbled across it. Roy *Roy Hirst* | 425-556-5773 | 425-324-0941 cell XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA On 12/7/2014 8:48 AM, Teleric Team wrote: >> From: pete at fiberphone.co.nz >> Subject: Re: 10Gb iPerf kit? >> Date: Sun, 7 Dec 2014 09:24:41 +1300 >> To: nanog at nanog.org >> >> On 11/11/2014, at 1:35 PM, Randy Carpenter wrote: >> >>> I have not tried doing that myself, but the only thing that would even be possible that I know of is thunderbolt. >>> A new MacBook Pro and one of these maybe: http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html >> Or one of these ones for dual-10Gbit links (one for out of band management or internet?): >> >> http://www.sonnettech.com/product/twin10g.html >> >> I haven't tried one myself, but they're relatively cheap (for 10gig) so not that much outlay to grab one and try it (esp if you already have an Apple laptop you can test with). >> > How would you use it? with iperf still?I don't think you will go nearly close to 14.8Mpps per port this way.Unless you are talking about bandwidth testing with full sized packet frames and low pps rate. > I personally tested a 1Gbit/s port over a MBP retina 15 thunderbot gbe with BCM5701 chipset. I had only 220kpps on a single TX flow.Later I tried another adapter with a marvel yukon mini port. Had better pps rate, but nothing beyond 260kpps. > >> I've done loads of 1Gbit testing using the entry-level MacBook Air and a Thunderbolt Gigabit Ethernet adapter though, and I disagree with Saku's statement of 'You cannot use UDPSocket like iperf does, it just does not work, you are lucky if you reliably test 1Gbps'. I find iperf testing at 1Gbit on Mac Air with Thunderbolt Eth extremely reliable (always 950+mbit/sec TCP on a good network, and easy to push right to the 1gbit limit with UDP. > Again, with 64byte packet size? Or are you talking MTU? > With MTU size you can try whatever you want and it will seem to be reliable. A wget/ftp download of a 1GB file will provide similar results, but I dont think this is useful anyway since it won't test anything close to rfc2544 or at least an ordinary internet traffic profile with a mix of 600bytes pkg size combined with a lower rate of smaller packets (icmp/udp, ping/dns/ntp/voice/video). > I am also interested in a cheap and reliable method to test 10GbE connections. So far I haven't found something I trust. >> Pete >> > The information contained in this e-mail message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender at the above e-mail address. From rhirst at xkl.com Mon Dec 8 16:36:51 2014 From: rhirst at xkl.com (Roy Hirst) Date: Mon, 08 Dec 2014 08:36:51 -0800 Subject: 10Gb iPerf kit? In-Reply-To: <5485D1D6.3060104@xkl.com> References: , <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net>, <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> <5485D1D6.3060104@xkl.com> Message-ID: <5485D3A3.7040109@xkl.com> For RFC2444, please read RFC2544, and forgive the spam. *Roy Hirst* | 425-556-5773 | 425-324-0941 cell XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA On 12/8/2014 8:29 AM, Roy Hirst wrote: > Can't help with faster adapters, but I believe there are some > underlying architectural issues here as to why the speeds are hard to > achieve, and why some people can and others maybe can't achieve them. > For Carrier Ethernet, I believe most of these are covered in RFC2444 > and the related RFC6815. Even with bit speeds up to spec, traffic > speeds are impacted non-linearly by customer protocols including the > usual suspect, TCP. This is documented in ITU-T Y.1564, clearly enough > for simple folk like me. A good example for your corkboard is slide > (page) 28 of the excellent > 20140409-Tierney-100G-experience-Internet2-Summit.pdf, included as > part of a report on 100GE performance test methodologies. Which is how > I stumbled across it. > Roy > > *Roy Hirst* | 425-556-5773 | 425-324-0941 cell > XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA > > On 12/7/2014 8:48 AM, Teleric Team wrote: >>> From: pete at fiberphone.co.nz >>> Subject: Re: 10Gb iPerf kit? >>> Date: Sun, 7 Dec 2014 09:24:41 +1300 >>> To: nanog at nanog.org >>> >>> On 11/11/2014, at 1:35 PM, Randy Carpenter >>> wrote: >>> >>>> I have not tried doing that myself, but the only thing that would >>>> even be possible that I know of is thunderbolt. >>>> A new MacBook Pro and one of these maybe: >>>> http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html >>> Or one of these ones for dual-10Gbit links (one for out of band >>> management or internet?): >>> >>> http://www.sonnettech.com/product/twin10g.html >>> >>> I haven't tried one myself, but they're relatively cheap (for 10gig) >>> so not that much outlay to grab one and try it (esp if you already >>> have an Apple laptop you can test with). >>> >> How would you use it? with iperf still?I don't think you will go >> nearly close to 14.8Mpps per port this way.Unless you are talking >> about bandwidth testing with full sized packet frames and low pps rate. >> I personally tested a 1Gbit/s port over a MBP retina 15 thunderbot >> gbe with BCM5701 chipset. I had only 220kpps on a single TX >> flow.Later I tried another adapter with a marvel yukon mini port. Had >> better pps rate, but nothing beyond 260kpps. >> >>> I've done loads of 1Gbit testing using the entry-level MacBook Air >>> and a Thunderbolt Gigabit Ethernet adapter though, and I disagree >>> with Saku's statement of 'You cannot use UDPSocket like iperf does, >>> it just does not work, you are lucky if you reliably test 1Gbps'. I >>> find iperf testing at 1Gbit on Mac Air with Thunderbolt Eth >>> extremely reliable (always 950+mbit/sec TCP on a good network, and >>> easy to push right to the 1gbit limit with UDP. >> Again, with 64byte packet size? Or are you talking MTU? >> With MTU size you can try whatever you want and it will seem to be >> reliable. A wget/ftp download of a 1GB file will provide similar >> results, but I dont think this is useful anyway since it won't test >> anything close to rfc2544 or at least an ordinary internet traffic >> profile with a mix of 600bytes pkg size combined with a lower rate of >> smaller packets (icmp/udp, ping/dns/ntp/voice/video). >> I am also interested in a cheap and reliable method to test 10GbE >> connections. So far I haven't found something I trust. >>> Pete >>> >> > > > > > The information contained in this e-mail message may be privileged, > confidential and protected from disclosure. > If you are not the intended recipient, any dissemination, distribution > or copying is strictly prohibited. > If you think that you have received this e-mail message in error, > please e-mail the sender at the above e-mail address. The information contained in this e-mail message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender at the above e-mail address. From baldur.norddahl at gmail.com Mon Dec 8 17:40:21 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 8 Dec 2014 18:40:21 +0100 Subject: Followup: Survey results for the ARIN RPA In-Reply-To: References: Message-ID: We signed our ROAs but we wont be validating anything from the ARIN region. I believe you will find this to be the norm. The tool provided by RIPE also ignores ARIN by default. Someone will probably tell me that I am being arrogant again, but basically you are asking me to help protect your routes. And you want me to sign something first. I am not going to even read that agreement. I do not believe I am alone in this. Regards Baldur From karsten.elfenbein at gmail.com Mon Dec 8 18:06:32 2014 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Mon, 8 Dec 2014 19:06:32 +0100 Subject: looking for an OTDR Message-ID: Hi, I'm looking for an OTDR. - single and multi mode fibers - good resolution as the the primary area of operation would be in the data center - a low learning curve and simple user interface What OTDRs / manufactures can you recommend? Thanks Karsten From rubensk at gmail.com Mon Dec 8 18:13:52 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 8 Dec 2014 16:13:52 -0200 Subject: Followup: Survey results for the ARIN RPA In-Reply-To: References: Message-ID: > > > One could easily presume the ARIN region RPKI deployment statistics are > lower as a result of the RPA situation (and no doubt that it part of the > issue), but as noted earlier, it's unlikely to be the full story since > we also have a region (APNIC) where RPKI deployment also rather low that > and yet does not have these RPA legal entanglements. > > It was suggested earlier that this may be due to a combination of factors > (education, promotion) beyond the RPA legal issues that are now being > worked - so that will also need to be addressed once the RPA is resolved. > Are the US litigation risks that much higher than other jurisdictions so that ARIN needs to take a different approach than other RIRs ? If they are, perhaps a confederation design instead of centralized one would help scatter those risks ? Rubens From owen at delong.com Mon Dec 8 18:44:25 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Dec 2014 10:44:25 -0800 Subject: looking for an OTDR In-Reply-To: References: Message-ID: If you can afford it, Fluke makes very nice products. The versiv platform has some impressive capabilities and is very easy to use. I have no stake in or relationship to Fluke, just like their stuff. Owen > On Dec 8, 2014, at 10:06 , Karsten Elfenbein wrote: > > Hi, > > I'm looking for an OTDR. > > - single and multi mode fibers > - good resolution as the the primary area of operation would be in the > data center > - a low learning curve and simple user interface > > > What OTDRs / manufactures can you recommend? > > > Thanks > Karsten From jcurran at arin.net Mon Dec 8 19:43:18 2014 From: jcurran at arin.net (John Curran) Date: Mon, 8 Dec 2014 19:43:18 +0000 Subject: Followup: Survey results for the ARIN RPA In-Reply-To: References: Message-ID: <69EB8340-585F-4403-BFF7-BA75D712E054@arin.net> On Dec 8, 2014, at 1:13 PM, Rubens Kuhl > wrote: One could easily presume the ARIN region RPKI deployment statistics are lower as a result of the RPA situation (and no doubt that it part of the issue), but as noted earlier, it's unlikely to be the full story since we also have a region (APNIC) where RPKI deployment also rather low that and yet does not have these RPA legal entanglements. It was suggested earlier that this may be due to a combination of factors (education, promotion) beyond the RPA legal issues that are now being worked - so that will also need to be addressed once the RPA is resolved. Are the US litigation risks that much higher than other jurisdictions so that ARIN needs to take a different approach than other RIRs ? If they are, perhaps a confederation design instead of centralized one would help scatter those risks ? Rubens - It is true that US has an abundance of litigation, and while this doesn't require a different approach than other regions, it does often mean that we're far more conservative in both technical and legal approaches initially. ARIN's RPA is a typical example, in that it has allowed us to rollout the service in a timely manner that would not have otherwise been possible. Now that there is some operational experience, it's possible to review the experience and see if a more relaxed risk posture can be accommodated. FYI /John John Curran President and CEO ARIN From Tony.McKay at RitterCommunications.com Mon Dec 8 18:53:09 2014 From: Tony.McKay at RitterCommunications.com (Tony McKay) Date: Mon, 8 Dec 2014 18:53:09 +0000 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: <5484B40F.3010203@noor.net> References: <5484B40F.3010203@noor.net> Message-ID: <6F2BC9429CDDC6438D1FE460D2258BB401B1994E66@EXCHANGENODE1.ritter.net> Does anyone on list currently use Peakflow SP from Arbor with TMS, and is it truly a carrier grade DDoS detection and mitigation platform? Anyone have any experience with Plixir? Tony McKay Dir. Of Network Operations Office: 870.336.3449 Mobile: 870.243.0058 -The boundary to your comfort zone fades a little each time you cross it. Raise your limits by pushing them. This electronic mail transmission may contain confidential or privileged information. If you believe that you have received this message in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mohamed Kamal Sent: Sunday, December 07, 2014 2:10 PM To: nanog Subject: Carrier-grade DDoS Attack mitigation appliance Have anyone tried any DDoS attack mitigation appliance rather than Arbor PeakFlow TMS? I need it to be carrier-grade in terms of capacity and redundancy, and as far as I know, Arbor is the only product in the market which offers a "clean pipe" volume of traffic, so if the DDoS attack volume is, for example, 1Tbps, they will grant you for example 50Gbps of clean traffic. Anyway, I'm open to other suggestions, and open-source products that can do the same purpose, we have network development team that can work on this. Thanks. -- Mohamed Kamal Core Network Sr. Engineer From ammar at fastreturn.net Mon Dec 8 20:17:09 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Tue, 9 Dec 2014 00:17:09 +0400 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: <6F2BC9429CDDC6438D1FE460D2258BB401B1994E66@EXCHANGENODE1.ritter.net> References: <5484B40F.3010203@noor.net> <6F2BC9429CDDC6438D1FE460D2258BB401B1994E66@EXCHANGENODE1.ritter.net> Message-ID: <63313FDA-EF90-4677-B4AF-DEACE62B7DD0@fastreturn.net> Hi, We’re currently running the Arbor Peakflow SP with the TMS and it works very well for us. Best Regards, Ammar Zuberi FastReturn, Inc Direct Line: +971 50 394 7299 Email: ammar at fastreturn.net This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > On Dec 8, 2014, at 10:53 PM, Tony McKay wrote: > > Does anyone on list currently use Peakflow SP from Arbor with TMS, and is it truly a carrier grade DDoS detection and mitigation platform? Anyone have any experience with Plixir? > > Tony McKay > Dir. Of Network Operations > Office: 870.336.3449 > Mobile: 870.243.0058 > -The boundary to your comfort zone fades a little each time you cross it. Raise your limits by pushing them. > > This electronic mail transmission may contain confidential or privileged information. If you believe that you have received this message in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mohamed Kamal > Sent: Sunday, December 07, 2014 2:10 PM > To: nanog > Subject: Carrier-grade DDoS Attack mitigation appliance > > > Have anyone tried any DDoS attack mitigation appliance rather than Arbor PeakFlow TMS? I need it to be carrier-grade in terms of capacity and redundancy, and as far as I know, Arbor is the only product in the market which offers a "clean pipe" volume of traffic, so if the DDoS attack volume is, for example, 1Tbps, they will grant you for example 50Gbps of clean traffic. > > Anyway, I'm open to other suggestions, and open-source products that can do the same purpose, we have network development team that can work on this. > > Thanks. > > -- > Mohamed Kamal > Core Network Sr. Engineer > From rhirst at xkl.com Mon Dec 8 20:57:24 2014 From: rhirst at xkl.com (Roy Hirst) Date: Mon, 08 Dec 2014 12:57:24 -0800 Subject: DWDM Documentation In-Reply-To: References: <40D2CD0E-3518-4CB3-B70A-87FC9ED548C9@theo-voss.de> <5480B2BC.3050108@xkl.com> Message-ID: <548610B4.5000906@xkl.com> Not found as much as I'd like. I can see an architecture, can see the database and where it lives, but I can't see a data model that works. if the problem is to track "dumb" infrastructure metadata, like port::cableID::cabletray, then I can't get an event (e.g. SNMP) to report a status change, and entropy eats at my data unless I spend people time keeping it up to date. It's not the rendering of racks, it's the quality of the data that's an issue. I don't even know when (if?) this tracking becomes a problem. When is a hardcopy wallchart not enough? At 50 servers? At 500 servers? I saw a while back a finance industry comment that it's config errors, not particularly backhoes, that are a significant source of their down time. So you'd expect some NOC attention on inventorying cableIDs etc., but it's hard to find. Now we are seeing some affordable (100GE at 4x10GE) services popping up, I thought I'd like to see what the future reqs are for these interfaces - more eggs in one basket maybe adds importance. You are yourself, maybe, sitting on a hidden store of use cases for infrastructure manageability? :-) Roy *Roy Hirst* | 425-556-5773 | 425-324-0941 cell XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA On 12/7/2014 7:46 PM, Colton Conor wrote: > What have you found so far? > > On Thu, Dec 4, 2014 at 1:15 PM, Roy Hirst > wrote: > > Replying offline to Theo. Schwer zu finden. > Roy > > *Roy Hirst* | 425-556-5773 | 425-324-0941 > cell > XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA > > > On 12/4/2014 5:21 AM, Theo Voss wrote: > > Hi guys, > > we, a Berlin / Germany based carrier, are looking for a smart > documentation (shelfs, connections, fibers) and visualization > tool for our ADVA-based DWDM-enviroment. Do you have any > suggestions or hints for me? We’re testing „cableScout“, the > only one I found, next week but. Unfortunately it isn’t easy > to get any information about such tools! :( > > Thanks in advance! > > Best regards, > Theo Voss (AS25291) > > > > > > The information contained in this e-mail message may be > privileged, confidential and protected from disclosure. > If you are not the intended recipient, any dissemination, > distribution or copying is strictly prohibited. > If you think that you have received this e-mail message in error, > please e-mail the sender at the above e-mail address. > > The information contained in this e-mail message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender at the above e-mail address. From jschiel at flowtools.net Mon Dec 8 21:38:11 2014 From: jschiel at flowtools.net (John Schiel) Date: Mon, 08 Dec 2014 14:38:11 -0700 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: <6F2BC9429CDDC6438D1FE460D2258BB401B1994E66@EXCHANGENODE1.ritter.net> References: <5484B40F.3010203@noor.net> <6F2BC9429CDDC6438D1FE460D2258BB401B1994E66@EXCHANGENODE1.ritter.net> Message-ID: <54861A43.3070506@flowtools.net> On 12/08/2014 11:53 AM, Tony McKay wrote: > Does anyone on list currently use Peakflow SP from Arbor with TMS, and is it truly a carrier grade DDoS detection and mitigation platform? Anyone have any experience with Plixir? Peakflow SP with the TMS works quite well. Can be very fast once a threat is discovered, depending on how you set up the mitigation. If you use auto mitigate and anycast BGP announcements, you can get a base mitigation going within seconds. Although it works quite well, it can be a bit pricey. I've seen but not yet played with DefensePro from Radware. I thought they also had premise based unit like Arbor's Pravail but I can't be sure on that. --John > > Tony McKay > Dir. Of Network Operations > Office: 870.336.3449 > Mobile: 870.243.0058 > -The boundary to your comfort zone fades a little each time you cross it. Raise your limits by pushing them. > > This electronic mail transmission may contain confidential or privileged information. If you believe that you have received this message in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mohamed Kamal > Sent: Sunday, December 07, 2014 2:10 PM > To: nanog > Subject: Carrier-grade DDoS Attack mitigation appliance > > > Have anyone tried any DDoS attack mitigation appliance rather than Arbor PeakFlow TMS? I need it to be carrier-grade in terms of capacity and redundancy, and as far as I know, Arbor is the only product in the market which offers a "clean pipe" volume of traffic, so if the DDoS attack volume is, for example, 1Tbps, they will grant you for example 50Gbps of clean traffic. > > Anyway, I'm open to other suggestions, and open-source products that can do the same purpose, we have network development team that can work on this. > > Thanks. > > -- > Mohamed Kamal > Core Network Sr. Engineer > From cra at WPI.EDU Mon Dec 8 21:42:39 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 8 Dec 2014 16:42:39 -0500 Subject: DWDM Documentation In-Reply-To: <40D2CD0E-3518-4CB3-B70A-87FC9ED548C9@theo-voss.de> References: <40D2CD0E-3518-4CB3-B70A-87FC9ED548C9@theo-voss.de> Message-ID: <20141208214239.GQ7116@angus.ind.WPI.EDU> On Thu, Dec 04, 2014 at 01:21:16PM +0000, Theo Voss wrote: > Hi guys, > > we, a Berlin / Germany based carrier, are looking for a smart documentation (shelfs, connections, fibers) and visualization tool for our ADVA-based DWDM-enviroment. Do you have any suggestions or hints for me? We’re testing „cableScout“, the only one I found, next week but. Unfortunately it isn’t easy to get any information about such tools! :( > > Thanks in advance! > > Best regards, > Theo Voss (AS25291) We're starting to use PatchManager. It is flexible enough to handle fiber shelves, splices, manholes, etc. as well as theoretically WDM, but we have been focusing on our LAN copper cabling first, so we haven't done much with the fiber plant yet. From marka at isc.org Mon Dec 8 22:46:08 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 09 Dec 2014 09:46:08 +1100 Subject: Followup: Survey results for the ARIN RPA In-Reply-To: Your message of "Mon, 08 Dec 2014 18:40:21 +0100." References: Message-ID: <20141208224608.2C086252507E@rock.dv.isc.org> In message , Baldur Norddahl writes: > We signed our ROAs but we wont be validating anything from the ARIN region. > I believe you will find this to be the norm. The tool provided by RIPE also > ignores ARIN by default. > > Someone will probably tell me that I am being arrogant again, but basically > you are asking me to help protect your routes. And you want me to sign > something first. I am not going to even read that agreement. I do not > believe I am alone in this. Well the tool is designed to prevent you being fooled by people injecting bogus routing information. If you wish to continue to be fooled so be it. If I was running a ISP I wouldn't want to be in the position of explaining why I was accepting bogus routes when I have the way to reject them. The agreement is that if you run the tool and there is a mistake in the data or the servers are not available that you won't sue ARIN for the mistake. Mark > Regards > > Baldur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From baldur.norddahl at gmail.com Mon Dec 8 23:31:44 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 9 Dec 2014 00:31:44 +0100 Subject: Followup: Survey results for the ARIN RPA In-Reply-To: <20141208224608.2C086252507E@rock.dv.isc.org> References: <20141208224608.2C086252507E@rock.dv.isc.org> Message-ID: I care mostly about routes to destinations close to me. If someone steals a route from someone on other side of the world everyone will rightly assume it is the other guys having trouble. Plus we simply do not have much traffic there. On the other hand it adds up for the target if many ISPs around the world is fooled. But that is just my ramblings. I am also warning that the RIPE tool already ignores ARIN. Anyone from RIPE will be ignoring you unless they go out of their way to fix it. My bet is therefore that ARIN is being ignored by many if not most. Regards Baldur Den 08/12/2014 23.46 skrev "Mark Andrews" : > > > In message > , Baldur Norddahl writes: > > We signed our ROAs but we wont be validating anything from the ARIN region. > > I believe you will find this to be the norm. The tool provided by RIPE also > > ignores ARIN by default. > > > > Someone will probably tell me that I am being arrogant again, but basically > > you are asking me to help protect your routes. And you want me to sign > > something first. I am not going to even read that agreement. I do not > > believe I am alone in this. > > Well the tool is designed to prevent you being fooled by people > injecting bogus routing information. If you wish to continue to > be fooled so be it. > > If I was running a ISP I wouldn't want to be in the position of > explaining why I was accepting bogus routes when I have the way to > reject them. > > The agreement is that if you run the tool and there is a mistake > in the data or the servers are not available that you won't sue > ARIN for the mistake. > > Mark > > > Regards > > > > Baldur > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From juniorbsd at gmail.com Mon Dec 8 21:25:50 2014 From: juniorbsd at gmail.com (J. Tozo) Date: Mon, 8 Dec 2014 19:25:50 -0200 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: <63313FDA-EF90-4677-B4AF-DEACE62B7DD0@fastreturn.net> References: <5484B40F.3010203@noor.net> <6F2BC9429CDDC6438D1FE460D2258BB401B1994E66@EXCHANGENODE1.ritter.net> <63313FDA-EF90-4677-B4AF-DEACE62B7DD0@fastreturn.net> Message-ID: We also evaluating another appliance to put in place of Arbor, their "support" outside USA its a joke. On Mon, Dec 8, 2014 at 6:17 PM, Ammar Zuberi wrote: > Hi, > > We're currently running the Arbor Peakflow SP with the TMS and it works > very well for us. > > Best Regards, > > Ammar Zuberi > FastReturn, Inc > > > > > Direct Line: +971 50 394 7299 > Email: ammar at fastreturn.net > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received it by mistake, please let us know by e-mail reply and > delete it from your system; you may not copy this message or disclose its > contents to anyone. Please note that any views or opinions presented in > this email are solely those of the author and do not necessarily represent > those of the company. Finally, the recipient should check this email and > any attachments for the presence of viruses. The company accepts no > liability for any damage caused by any virus transmitted by this email. > > > On Dec 8, 2014, at 10:53 PM, Tony McKay > wrote: > > > > Does anyone on list currently use Peakflow SP from Arbor with TMS, and > is it truly a carrier grade DDoS detection and mitigation platform? Anyone > have any experience with Plixir? > > > > Tony McKay > > Dir. Of Network Operations > > Office: 870.336.3449 > > Mobile: 870.243.0058 > > -The boundary to your comfort zone fades a little each time you cross > it. Raise your limits by pushing them. > > > > This electronic mail transmission may contain confidential or privileged > information. If you believe that you have received this message in error, > please notify the sender by reply transmission and delete the message > without copying or disclosing it. > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mohamed Kamal > > Sent: Sunday, December 07, 2014 2:10 PM > > To: nanog > > Subject: Carrier-grade DDoS Attack mitigation appliance > > > > > > Have anyone tried any DDoS attack mitigation appliance rather than Arbor > PeakFlow TMS? I need it to be carrier-grade in terms of capacity and > redundancy, and as far as I know, Arbor is the only product in the market > which offers a "clean pipe" volume of traffic, so if the DDoS attack volume > is, for example, 1Tbps, they will grant you for example 50Gbps of clean > traffic. > > > > Anyway, I'm open to other suggestions, and open-source products that can > do the same purpose, we have network development team that can work on this. > > > > Thanks. > > > > -- > > Mohamed Kamal > > Core Network Sr. Engineer > > > > -- Grato, Tozo From motamedi at cs.uoregon.edu Mon Dec 8 23:48:21 2014 From: motamedi at cs.uoregon.edu (Reza Motamedi) Date: Mon, 8 Dec 2014 15:48:21 -0800 Subject: What can I infer from "show ip route" and similar BGP commands? Message-ID: Hello NANOG, I’m a researcher and I was trying to understand the data I collected from some BGP Looking Glasses. Basically, I was hoping to see if BGP records can tell me where my university’s provider (AS3701) is peering with its providers. I issued two BGP queries to Level3’s LGs, one in Seattle and one in Amsterdam for my school’s prefix. My strong guess was that our provider (AS3701) peers with Level3 in Seattle. I was hoping to conclude something like this: if the peering occurs in Seattle, the Seattle LG should reveal it, but Amsterdam should not. AS3701 is Nero (Network for Education and Research in Oregon) which I assume is a small regional AS. I don't think Nero peers with Level3 in Amsterdam, however, I get this AS for my next hop even when I issue the command from Amsterdam. On the other hand “car1.Sacramento1” suggests that the peering happens in Sacramento. This result makes me think what I get is from a combination of iBGP and eBGP, which is also apparent from “Internal/External” keywords in the data. My main issue is that the keywords are not always available. In some other LG I just get a next hop IP and an AS path. How can I make sure that the peering information comes from an eBGP peering? I think the next hop IP might be the answer, right? I included the results of the command for both LGs here, hopefully somebody could explain to me ------------------------------------------------- Route results for 128.223.0.0/16 from Amsterdam, Netherlands BGP routing table entry for 128.223.0.0/16 Paths: (2 available, best #1) 3701 3582 AS-path translation: { OREGONUNIV UONET } car1.Sacramento1 (metric 58341) Origin IGP, metric 0, localpref 100, valid, internal, best Community: North_America Lclprf_100 Level3_Customer United_States Sacramento Originator: car1.Sacramento1 3701 3582 AS-path translation: { OREGONUNIV UONET } car1.Sacramento1 (metric 58341) Origin IGP, metric 0, localpref 100, valid, internal Community: North_America Lclprf_100 Level3_Customer United_States Sacramento Originator: car1.Sacramento1 ------------------------------------------------- Route results for 128.223.6.81/16 from Seattle, WA BGP routing table entry for 128.223.0.0/16 Paths: (4 available, best #3) 3701 3582 AS-path translation: { OREGONUNIV UONET } 4.53.150.46 from 4.53.150.46 (ptck-core1-gw.nero.net) Origin IGP, localpref 90, valid, external Community: North_America Lclprf_90 Level3_Customer United_States Seattle Level3:11847 3701 3582, (received-only) AS-path translation: { OREGONUNIV UONET } 4.53.150.46 from 4.53.150.46 (ptck-core1-gw.nero.net) Origin IGP, localpref 100, valid, external Community: Level3:90 3701 3582 AS-path translation: { OREGONUNIV UONET } car1.Sacramento1 (metric 34363) Origin IGP, metric 0, localpref 100, valid, internal, best Community: North_America Lclprf_100 Level3_Customer United_States Sacramento Originator: car1.Sacramento1 3701 3582 AS-path translation: { OREGONUNIV UONET } car1.Sacramento1 (metric 34363) Origin IGP, metric 0, localpref 100, valid, internal Community: North_America Lclprf_100 Level3_Customer United_States Sacramento Originator: car1.Sacramento1 Best Regards Reza Motamedi (R.M) Graduate Research Fellow Computer and Information Science University of Oregon From motamedi at cs.uoregon.edu Tue Dec 9 04:16:35 2014 From: motamedi at cs.uoregon.edu (Reza Motamedi) Date: Tue, 09 Dec 2014 04:16:35 +0000 Subject: What can I infer from "show ip route" and similar BGP commands? References: Message-ID: Thanks Joel for your detailed explanation. It was very informative. I have been using routeviews for sometime, but given that I could get this amount of information from other sources, I decided to give this a try. On another note, do you think there is any value in checking the next hop IP? I have been checking and it looks as if when the IP is in the AS at the head of the AS path, the entry is associated with an iBGP record, right? I just used the ripe stat to map IPs to AS and it always holds when there is an AS for the next hop IP. Thanks again for your input. From pete at fiberphone.co.nz Tue Dec 9 08:01:08 2014 From: pete at fiberphone.co.nz (Pete Mundy) Date: Tue, 9 Dec 2014 21:01:08 +1300 Subject: 10Gb iPerf kit? In-Reply-To: References: , <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net>, <70853923-F3DD-4BB7-ABA3-84BB29B3A455@fiberphone.co.nz> Message-ID: <99251055-B93E-4312-B7FA-EA4AFE118A51@fiberphone.co.nz> On 8/12/2014, at 5:48 AM, Teleric Team wrote: > Again, with 64byte packet size? Or are you talking MTU? You have a very good point. My 1gig tests have always been for throughput rather than pps, and therefore was using MTU sized packets and though would be much less load on the CPU. Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4145 bytes Desc: not available URL: From alexb at ripe.net Tue Dec 9 15:23:09 2014 From: alexb at ripe.net (Alex Band) Date: Tue, 9 Dec 2014 16:23:09 +0100 Subject: Followup: Survey results for the ARIN RPA In-Reply-To: References: <20141208224608.2C086252507E@rock.dv.isc.org> Message-ID: <70B0BA0E-EFF4-4E6D-9BA5-12E22EDFF845@ripe.net> > On 9 Dec 2014, at 00:31, Baldur Norddahl wrote: > > But that is just my ramblings. I am also warning that the RIPE tool already > ignores ARIN. Anyone from RIPE will be ignoring you unless they go out of > their way to fix it. My bet is therefore that ARIN is being ignored by > many if not most. The RIPE NCC RPKI Validator doesn't include the ARIN Trust Anchor Locator because we're not allowed to include in the package. Even though we explicitly explain in the readme and UI how to get it, my experience is that most operators who run the software don't take the steps to download it. I've been responsible for running the RPKI service in the RIPE NCC region for the last five years now. My experience is that education is an extremely important factor. One thing in particular causes a lot of confusion and this is the word "invalid", due to the somewhat confusing terminology used in RPKI, as there are two things that have this term associated with them. They should be clearly separated in this discussion: 1) a certificate or ROA that doesn't pass cryptographic validation for a particular reason, such as expiration, tampering, overclaiming, etc.: "Invalid Certificate", "Invalid ROA" 2) a BGP announcement that is flagged as unauthorised due to a *cryptographically valid* ROA that covers it: "Invalid BGP Announcement" If one of the RIRs make a mistake such as letting the key expire, they cause an outage, or the repository is unavailable due to a ddos attack, this can result in invalid or absent certificates and ROAs. Because invalid ROAs are thrown out by the RPKI Validators, the BGP announcements that are related to those ROAs will have the state "unknown"; and they should NOT be dropped. So in these cases, there will be no reachability problem for the affected ISP. In order for a BGP announcement to get the state RPKI invalid/unauthorised, the repository would have to contain a valid ROA issued from a valid certificate. As ARIN took drastic measures with regards to non-repudiation, you can be certain that this ROA was put there by the legitimate holder of the resources. This is provable by ARIN in a court of law. There are quite some RPKI invalid/unauthorised BGP announcements as a result of valid ROAs: 2,898 of them globally, as I write this. All of them exist because of an explicit, validated statement made by an operator who uses the system. What's important through is that I can't come up with a single scenario where an RPKI invalid/unauthorised BGP announcement would appear because of an *operational mistake* the RIR made. Admittedly though, some ISP may try to hold ARIN accountable for it anyway. It's the USA, after all. :) I'm not trying to downplay the operational complexity of the RPKI system as a whole, but this stuff doesn't break at the drop of a hat, on the contrary. When you start bringing in the delegated model, where operators run their own CA and publish themselves, as well as inter-RIR transfers of resources where operators may desire to have their BGP announcements RPKI valid in a seamless manner, it adds complexity. All of this will require careful planning and a good implementation, but I for one am confident we'll get this sorted as we've gained lots of operational experience in the last four years. In conclusion, the goal is to offer an RPKI service that operators are eager to use, because they think there is value and they trust the RIRs are doing a good job operationally. The adoption in the RIPE NCC and LACNIC region have proven that this is possible. I'm confident the same can be achieved in the ARIN region... Alex Band Product Manager RIPE NCC From jcurran at arin.net Tue Dec 9 16:38:26 2014 From: jcurran at arin.net (John Curran) Date: Tue, 9 Dec 2014 16:38:26 +0000 Subject: Followup: Survey results for the ARIN RPA In-Reply-To: <70B0BA0E-EFF4-4E6D-9BA5-12E22EDFF845@ripe.net> References: <20141208224608.2C086252507E@rock.dv.isc.org> <70B0BA0E-EFF4-4E6D-9BA5-12E22EDFF845@ripe.net> Message-ID: Alex - Thanks for sharing your observations from RPKI deployment in the RIPE region - it's very helpful for those trying to understand how RPKI might affect their operations. :-) Thanks again! /John > On Dec 9, 2014, at 10:23 AM, Alex Band wrote: > > >> On 9 Dec 2014, at 00:31, Baldur Norddahl wrote: >> >> But that is just my ramblings. I am also warning that the RIPE tool already >> ignores ARIN. Anyone from RIPE will be ignoring you unless they go out of >> their way to fix it. My bet is therefore that ARIN is being ignored by >> many if not most. > > The RIPE NCC RPKI Validator doesn't include the ARIN Trust Anchor Locator because we're not allowed to include in the package. Even though we explicitly explain in the readme and UI how to get it, my experience is that most operators who run the software don't take the steps to download it. > > I've been responsible for running the RPKI service in the RIPE NCC region for the last five years now. My experience is that education is an extremely important factor. One thing in particular causes a lot of confusion and this is the word "invalid", due to the somewhat confusing terminology used in RPKI, as there are two things that have this term associated with them. They should be clearly separated in this discussion: > > 1) a certificate or ROA that doesn't pass cryptographic validation for a particular reason, such as expiration, tampering, overclaiming, etc.: "Invalid Certificate", "Invalid ROA" > 2) a BGP announcement that is flagged as unauthorised due to a *cryptographically valid* ROA that covers it: "Invalid BGP Announcement" > > If one of the RIRs make a mistake such as letting the key expire, they cause an outage, or the repository is unavailable due to a ddos attack, this can result in invalid or absent certificates and ROAs. Because invalid ROAs are thrown out by the RPKI Validators, the BGP announcements that are related to those ROAs will have the state "unknown"; and they should NOT be dropped. So in these cases, there will be no reachability problem for the affected ISP. > > In order for a BGP announcement to get the state RPKI invalid/unauthorised, the repository would have to contain a valid ROA issued from a valid certificate. As ARIN took drastic measures with regards to non-repudiation, you can be certain that this ROA was put there by the legitimate holder of the resources. This is provable by ARIN in a court of law. > > There are quite some RPKI invalid/unauthorised BGP announcements as a result of valid ROAs: 2,898 of them globally, as I write this. All of them exist because of an explicit, validated statement made by an operator who uses the system. What's important through is that I can't come up with a single scenario where an RPKI invalid/unauthorised BGP announcement would appear because of an *operational mistake* the RIR made. Admittedly though, some ISP may try to hold ARIN accountable for it anyway. It's the USA, after all. :) > > I'm not trying to downplay the operational complexity of the RPKI system as a whole, but this stuff doesn't break at the drop of a hat, on the contrary. When you start bringing in the delegated model, where operators run their own CA and publish themselves, as well as inter-RIR transfers of resources where operators may desire to have their BGP announcements RPKI valid in a seamless manner, it adds complexity. All of this will require careful planning and a good implementation, but I for one am confident we'll get this sorted as we've gained lots of operational experience in the last four years. > > In conclusion, the goal is to offer an RPKI service that operators are eager to use, because they think there is value and they trust the RIRs are doing a good job operationally. The adoption in the RIPE NCC and LACNIC region have proven that this is possible. I'm confident the same can be achieved in the ARIN region... > > Alex Band > Product Manager > RIPE NCC From zachary.mcgibbon+nanog at gmail.com Tue Dec 9 19:42:01 2014 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Tue, 9 Dec 2014 14:42:01 -0500 Subject: Cisco AnyConnect speed woes! Message-ID: I'm looking for some input on a situation that has been plaguing our new AnyConnect VPN setup. Any input would be valuable, we are at a loss for what the problem is. We recently upgraded our VPN from our old Cisco 3000 VPN concentrators running PPTP and we are now running a pair of Cisco 5545x ASAs in an HA active/standby pair. The big issue we are having is that many of our users are complaining of low speed when connected to the VPN. We have done tons of troubleshooting with Cisco TAC and we still haven't found the root of our problem. Some tests we have done: - We have tested changing MTU values - We have tried all combinations of encryption methods (SSL, TLS, IPSec, L2TP) with similar results - We have switched our active/standby boxes - We have tested on our spare 5545x box - We connected our spare box directly to our ISP with another IP address - We have whitelisted our VPN IP on our shaper (Cisco SCE8000) and our IPS (HP Tipping Point) - We have bypassed our Shaper and our IPS - We made sure that traffic from the routers talking to our ASAs is synchronous, OSPF was configured to load balance but this has been changed by changing the costs on the links to the ASAs - We have verified with our two ISPs that they are not doing any kind of filtering or shaping - We have noticed that in some instances that if a user is on a low speed connection that their VPN speed gets cut by about 1/3. This doesn't seem normal that the VPN would use this much overhead - We do not have the issue when connecting to VPN directly on our own network, only connections from the Internet If you have any ideas on what we could try net, please let me know! - Zachary From Patrick.Darden at p66.com Tue Dec 9 20:02:57 2014 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Tue, 9 Dec 2014 14:02:57 -0600 Subject: Cisco AnyConnect speed woes! In-Reply-To: References: Message-ID: MTU should be automatically managed by the AnyConnect client. With that said, have you done PMTUd (e.g. nmap --script path-mtu from one endpoint to the next)? I'd do a network map, working with your upstream provider, to identify and isolate variables. E.g. to find media changes (wrt MTU changes/mismatches). --start with icmp traceroute --next do a udp traceroute --next do a tcp traceroute --each traceroute will give you a slightly different picture, some hops will respond to one but not another --try a vpn connection from Upstream1 first, to see if it happens there. --try a vpn connection from Upstream2 next, to see if it happens there. --try a vpn connection in reverse from Upstream2, then Upstream1, to see if the speed in one direction, via one or another portal, is faster. --continue to isolate networks, network devices, until you can find the point (e.g. advertisement injector) or process (e.g. MTU LCD or asymmetric routing) which is causing this. --p -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Zachary McGibbon Sent: Tuesday, December 09, 2014 1:42 PM To: NANOG Subject: [EXTERNAL]Cisco AnyConnect speed woes! I'm looking for some input on a situation that has been plaguing our new AnyConnect VPN setup. Any input would be valuable, we are at a loss for what the problem is. We recently upgraded our VPN from our old Cisco 3000 VPN concentrators running PPTP and we are now running a pair of Cisco 5545x ASAs in an HA active/standby pair. The big issue we are having is that many of our users are complaining of low speed when connected to the VPN. We have done tons of troubleshooting with Cisco TAC and we still haven't found the root of our problem. Some tests we have done: - We have tested changing MTU values - We have tried all combinations of encryption methods (SSL, TLS, IPSec, L2TP) with similar results - We have switched our active/standby boxes - We have tested on our spare 5545x box - We connected our spare box directly to our ISP with another IP address - We have whitelisted our VPN IP on our shaper (Cisco SCE8000) and our IPS (HP Tipping Point) - We have bypassed our Shaper and our IPS - We made sure that traffic from the routers talking to our ASAs is synchronous, OSPF was configured to load balance but this has been changed by changing the costs on the links to the ASAs - We have verified with our two ISPs that they are not doing any kind of filtering or shaping - We have noticed that in some instances that if a user is on a low speed connection that their VPN speed gets cut by about 1/3. This doesn't seem normal that the VPN would use this much overhead - We do not have the issue when connecting to VPN directly on our own network, only connections from the Internet If you have any ideas on what we could try net, please let me know! - Zachary From mhuff at ox.com Tue Dec 9 20:03:45 2014 From: mhuff at ox.com (Matthew Huff) Date: Tue, 9 Dec 2014 20:03:45 +0000 Subject: Cisco AnyConnect speed woes! In-Reply-To: References: Message-ID: <244fd40df6074e58b55631b179929227@pur-vm-exch13n1.ox.com> Are you using SSLVpn or IPSEC with anyconnect? I have had more luck with performance with IPSEC than SSLVpn. Also, just because your ISP is saying that they aren't shaping/filtering, doesn't mean they aren't. We had major issues with users using AnyConnect when it was transversing Cogent. We were getting 5-10% packet loss (although the Cisco stats didn't show it), and it was choking on it. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Zachary McGibbon Sent: Tuesday, December 9, 2014 2:42 PM To: NANOG Subject: Cisco AnyConnect speed woes! I'm looking for some input on a situation that has been plaguing our new AnyConnect VPN setup. Any input would be valuable, we are at a loss for what the problem is. We recently upgraded our VPN from our old Cisco 3000 VPN concentrators running PPTP and we are now running a pair of Cisco 5545x ASAs in an HA active/standby pair. The big issue we are having is that many of our users are complaining of low speed when connected to the VPN. We have done tons of troubleshooting with Cisco TAC and we still haven't found the root of our problem. Some tests we have done: - We have tested changing MTU values - We have tried all combinations of encryption methods (SSL, TLS, IPSec, L2TP) with similar results - We have switched our active/standby boxes - We have tested on our spare 5545x box - We connected our spare box directly to our ISP with another IP address - We have whitelisted our VPN IP on our shaper (Cisco SCE8000) and our IPS (HP Tipping Point) - We have bypassed our Shaper and our IPS - We made sure that traffic from the routers talking to our ASAs is synchronous, OSPF was configured to load balance but this has been changed by changing the costs on the links to the ASAs - We have verified with our two ISPs that they are not doing any kind of filtering or shaping - We have noticed that in some instances that if a user is on a low speed connection that their VPN speed gets cut by about 1/3. This doesn't seem normal that the VPN would use this much overhead - We do not have the issue when connecting to VPN directly on our own network, only connections from the Internet If you have any ideas on what we could try net, please let me know! - Zachary From rhirst at xkl.com Tue Dec 9 20:14:12 2014 From: rhirst at xkl.com (Roy Hirst) Date: Tue, 09 Dec 2014 12:14:12 -0800 Subject: Cisco AnyConnect speed woes! In-Reply-To: References: Message-ID: <54875814.5080207@xkl.com> Have you considered user protocol issues, higher up the stack where your NOC investigation can't see them? If TCP is not tuned, and detects TCP packets are dropping due to congestion, it drops (halves?) its transmit rate until all is well again. At a network operator level, you may have the L1 bandwidth ready and willing to tranport all the bits in sight, but just one poor TCP stack (old FTP? old SMB?) in the TCP roundtrip will throttle bits presented way down. I have on my desk here a badly configured example where poor TCP buffering drops throughput to 5% of expected. Well known issue, for IT folks in enterprises. Wireshark etc will easily let you see how fast user traffic is arriving. Just a thought. Roy *Roy Hirst* | 425-556-5773 | 425-324-0941 cell XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA On 12/9/2014 12:02 PM, Darden, Patrick wrote: > MTU should be automatically managed by the AnyConnect client. With that said, have you done PMTUd (e.g. nmap --script path-mtu from one endpoint to the next)? > > I'd do a network map, working with your upstream provider, to identify and isolate variables. E.g. to find media changes (wrt MTU changes/mismatches). > --start with icmp traceroute > --next do a udp traceroute > --next do a tcp traceroute > --each traceroute will give you a slightly different picture, some hops will respond to one but not another > --try a vpn connection from Upstream1 first, to see if it happens there. > --try a vpn connection from Upstream2 next, to see if it happens there. > --try a vpn connection in reverse from Upstream2, then Upstream1, to see if the speed in one direction, via one or another portal, is faster. > --continue to isolate networks, network devices, until you can find the point (e.g. advertisement injector) or process (e.g. MTU LCD or asymmetric routing) which is causing this. > > --p > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Zachary McGibbon > Sent: Tuesday, December 09, 2014 1:42 PM > To: NANOG > Subject: [EXTERNAL]Cisco AnyConnect speed woes! > > I'm looking for some input on a situation that has been plaguing our new AnyConnect VPN setup. Any input would be valuable, we are at a loss for what the problem is. > > We recently upgraded our VPN from our old Cisco 3000 VPN concentrators running PPTP and we are now running a pair of Cisco 5545x ASAs in an HA active/standby pair. > > The big issue we are having is that many of our users are complaining of low speed when connected to the VPN. We have done tons of troubleshooting with Cisco TAC and we still haven't found the root of our problem. > > Some tests we have done: > > - We have tested changing MTU values > - We have tried all combinations of encryption methods (SSL, TLS, IPSec, > L2TP) with similar results > - We have switched our active/standby boxes > - We have tested on our spare 5545x box > - We connected our spare box directly to our ISP with another IP address > - We have whitelisted our VPN IP on our shaper (Cisco SCE8000) and our > IPS (HP Tipping Point) > - We have bypassed our Shaper and our IPS > - We made sure that traffic from the routers talking to our ASAs is > synchronous, OSPF was configured to load balance but this has been changed > by changing the costs on the links to the ASAs > - We have verified with our two ISPs that they are not doing any kind of > filtering or shaping > - We have noticed that in some instances that if a user is on a low > speed connection that their VPN speed gets cut by about 1/3. This doesn't > seem normal that the VPN would use this much overhead > - We do not have the issue when connecting to VPN directly on our own > network, only connections from the Internet > > If you have any ideas on what we could try net, please let me know! > > - Zachary The information contained in this e-mail message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender at the above e-mail address. From zachary.mcgibbon+nanog at gmail.com Tue Dec 9 20:17:50 2014 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Tue, 9 Dec 2014 15:17:50 -0500 Subject: Cisco AnyConnect speed woes! In-Reply-To: <244fd40df6074e58b55631b179929227@pur-vm-exch13n1.ox.com> References: <244fd40df6074e58b55631b179929227@pur-vm-exch13n1.ox.com> Message-ID: We are trying to use SSLVPN (udp 443) and results are really all over the place. Most of our complaints are users connecting on Teksavvy however we haven't been able to reach anyone in their network team to find out if they are doing any filtering or shaping on their side. We don't have a lot of traffic coming through Cogent, most of the users are local here in Montreal on either Bell or Videotron and they traverse through the QIX (www.qix.ca) On Tue, Dec 9, 2014 at 3:03 PM, Matthew Huff wrote: > Are you using SSLVpn or IPSEC with anyconnect? I have had more luck with > performance with IPSEC than SSLVpn. > > Also, just because your ISP is saying that they aren't shaping/filtering, > doesn't mean they aren't. > > We had major issues with users using AnyConnect when it was transversing > Cogent. We were getting 5-10% packet loss (although the Cisco stats didn't > show it), and it was choking on it. > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Zachary McGibbon > Sent: Tuesday, December 9, 2014 2:42 PM > To: NANOG > Subject: Cisco AnyConnect speed woes! > > I'm looking for some input on a situation that has been plaguing our new > AnyConnect VPN setup. Any input would be valuable, we are at a loss for > what the problem is. > > We recently upgraded our VPN from our old Cisco 3000 VPN concentrators > running PPTP and we are now running a pair of Cisco 5545x ASAs in an HA > active/standby pair. > > The big issue we are having is that many of our users are complaining of > low speed when connected to the VPN. We have done tons of troubleshooting > with Cisco TAC and we still haven't found the root of our problem. > > Some tests we have done: > > - We have tested changing MTU values > - We have tried all combinations of encryption methods (SSL, TLS, IPSec, > L2TP) with similar results > - We have switched our active/standby boxes > - We have tested on our spare 5545x box > - We connected our spare box directly to our ISP with another IP address > - We have whitelisted our VPN IP on our shaper (Cisco SCE8000) and our > IPS (HP Tipping Point) > - We have bypassed our Shaper and our IPS > - We made sure that traffic from the routers talking to our ASAs is > synchronous, OSPF was configured to load balance but this has been > changed > by changing the costs on the links to the ASAs > - We have verified with our two ISPs that they are not doing any kind of > filtering or shaping > - We have noticed that in some instances that if a user is on a low > speed connection that their VPN speed gets cut by about 1/3. This > doesn't > seem normal that the VPN would use this much overhead > - We do not have the issue when connecting to VPN directly on our own > network, only connections from the Internet > > If you have any ideas on what we could try net, please let me know! > > - Zachary > From symack at gmail.com Tue Dec 9 21:03:03 2014 From: symack at gmail.com (symack) Date: Tue, 9 Dec 2014 16:03:03 -0500 Subject: Got a call at 4am - RAID Gurus Please Read Message-ID: Server down..... Got to colo at 4:39 and an old IBM X346 node with Serveraid-7k has failed. Opened it up to find a swollen cache battery that has bent the card in three different axis. Separated the battery. (i) Inspect card and plug back in, (ii) reboot, and got (code 2807) Not functioning.... Return to (i) x3 got same result. Dusted her off and let it sit for a while plugged in, rebooted to see if I can get her to write-through mode, disks start spinning. Horay. Plan of action, (and the reason for my post): * Can I change from an active (ie, disks with data) raid 5 to raid 10. There are 4 drives in the unit, and I have two on the shelf that I can plug in. * If so, will I have less of performance impact with RAID 10 + write-thru then RAID 5 + write through * When the new raid card comes in, can I just plug it in without loosing my data? I would: i) RAID 10 ii) Write-thru iii) Replace card The new card is probably coming with a bad battery that would put us kind of in square one. New batteries are 200+ if I can find them. Best case scenario is move it over to RAID 10+Write-thru, and feel less of the performance pinch. Given I can move from RAID 5 to RAID 10 without loosing data. How long to anticipate downtime for this process? Is there heavy sector re-arranging happening here? And the same for write-thru, is it done quick? I'm going to go lay down just for a little white. Thanks in Advance, Nick from Toronto. From Luke.Parrish at Suddenlink.com Tue Dec 9 21:07:55 2014 From: Luke.Parrish at Suddenlink.com (Parrish, Luke) Date: Tue, 9 Dec 2014 21:07:55 +0000 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: References: <5484B40F.3010203@noor.net> <6F2BC9429CDDC6438D1FE460D2258BB401B1994E66@EXCHANGENODE1.ritter.net> <63313FDA-EF90-4677-B4AF-DEACE62B7DD0@fastreturn.net> Message-ID: <10AB04B9CE55DF4AA248C0388F4ED464641E0535@SDLDALPWEMB07.suddenlink.cequel3.com> Switch to Nemo. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of J. Tozo Sent: Monday, December 08, 2014 3:26 PM Cc: nanog Subject: Re: Carrier-grade DDoS Attack mitigation appliance We also evaluating another appliance to put in place of Arbor, their "support" outside USA its a joke. On Mon, Dec 8, 2014 at 6:17 PM, Ammar Zuberi wrote: > Hi, > > We're currently running the Arbor Peakflow SP with the TMS and it > works very well for us. > > Best Regards, > > Ammar Zuberi > FastReturn, Inc > > > > > Direct Line: +971 50 394 7299 > Email: ammar at fastreturn.net > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are addressed. > If you have received it by mistake, please let us know by e-mail reply > and delete it from your system; you may not copy this message or > disclose its contents to anyone. Please note that any views or > opinions presented in this email are solely those of the author and do > not necessarily represent those of the company. Finally, the recipient > should check this email and any attachments for the presence of > viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > > > On Dec 8, 2014, at 10:53 PM, Tony McKay > wrote: > > > > Does anyone on list currently use Peakflow SP from Arbor with TMS, > > and > is it truly a carrier grade DDoS detection and mitigation platform? > Anyone have any experience with Plixir? > > > > Tony McKay > > Dir. Of Network Operations > > Office: 870.336.3449 > > Mobile: 870.243.0058 > > -The boundary to your comfort zone fades a little each time you > > cross > it. Raise your limits by pushing them. > > > > This electronic mail transmission may contain confidential or > > privileged > information. If you believe that you have received this message in > error, please notify the sender by reply transmission and delete the > message without copying or disclosing it. > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mohamed > > Kamal > > Sent: Sunday, December 07, 2014 2:10 PM > > To: nanog > > Subject: Carrier-grade DDoS Attack mitigation appliance > > > > > > Have anyone tried any DDoS attack mitigation appliance rather than > > Arbor > PeakFlow TMS? I need it to be carrier-grade in terms of capacity and > redundancy, and as far as I know, Arbor is the only product in the > market which offers a "clean pipe" volume of traffic, so if the DDoS > attack volume is, for example, 1Tbps, they will grant you for example > 50Gbps of clean traffic. > > > > Anyway, I'm open to other suggestions, and open-source products that > > can > do the same purpose, we have network development team that can work on this. > > > > Thanks. > > > > -- > > Mohamed Kamal > > Core Network Sr. Engineer > > > > -- Grato, Tozo ________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, confidential and/or legally 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 received this in error, please contact the sender and delete the material from all computers. ________________________________ From randy at psg.com Tue Dec 9 22:09:49 2014 From: randy at psg.com (Randy Bush) Date: Wed, 10 Dec 2014 07:09:49 +0900 Subject: route misorigination of the day Message-ID: http://www.bgpmon.net/bgp-hijack-incident-by-syrian-telecommunications-establishment/ thanks andre randy From michael at supermathie.net Tue Dec 9 22:22:59 2014 From: michael at supermathie.net (Michael Brown) Date: Tue, 09 Dec 2014 17:22:59 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: Message-ID: <20141209222259.6742169.43034.17675@supermathie.net> If the serveraid7k cards are LSI and not Adaptec based (I think they are) you should just be able to plug in a new adapter and import the foreign configuration. You do have a good backup, yes? Switching to write-through has already happened (unless you specified WriteBackModeEvenWithNoBBU - not the default) - these (LSI) cards ‎by default only WB when "safe". If WT, RAID10 much better perf. BUT you just can't migrate from R5 to R10 non-destructively. - Michael from Kitchener   Original Message   From: symack Sent: Tuesday, December 9, 2014 16:04 To: nanog at nanog.org Subject: Got a call at 4am - RAID Gurus Please Read Server down..... Got to colo at 4:39 and an old IBM X346 node with Serveraid-7k has failed. Opened it up to find a swollen cache battery that has bent the card in three different axis. Separated the battery. (i) Inspect card and plug back in, (ii) reboot, and got (code 2807) Not functioning.... Return to (i) x3 got same result. Dusted her off and let it sit for a while plugged in, rebooted to see if I can get her to write-through mode, disks start spinning. Horay. Plan of action, (and the reason for my post): * Can I change from an active (ie, disks with data) raid 5 to raid 10. There are 4 drives in the unit, and I have two on the shelf that I can plug in. * If so, will I have less of performance impact with RAID 10 + write-thru then RAID 5 + write through * When the new raid card comes in, can I just plug it in without loosing my data? I would: i) RAID 10 ii) Write-thru iii) Replace card The new card is probably coming with a bad battery that would put us kind of in square one. New batteries are 200+ if I can find them. Best case scenario is move it over to RAID 10+Write-thru, and feel less of the performance pinch. Given I can move from RAID 5 to RAID 10 without loosing data. How long to anticipate downtime for this process? Is there heavy sector re-arranging happening here? And the same for write-thru, is it done quick? I'm going to go lay down just for a little white. Thanks in Advance, Nick from Toronto. From arnold at nipper.de Tue Dec 9 23:21:24 2014 From: arnold at nipper.de (Arnold Nipper) Date: Wed, 10 Dec 2014 00:21:24 +0100 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) Message-ID: <548783F4.8010605@nipper.de> I'm looking for a modular, cost-effective automatic / intelligent fibre optic patch panel. I'm not looking at these photonic x-connects, but really for something which does the patching instead of a technician. TIA Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From aj at jonesy.com.au Tue Dec 9 23:36:38 2014 From: aj at jonesy.com.au (Andrew Jones) Date: Wed, 10 Dec 2014 10:36:38 +1100 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: <548783F4.8010605@nipper.de> References: <548783F4.8010605@nipper.de> Message-ID: http://www.laser2000.de/out/media/glimmerglass_system_100%281%29.pdf On 10.12.2014 10:21, Arnold Nipper wrote: > I'm looking for a modular, cost-effective automatic / intelligent > fibre > optic patch panel. > > I'm not looking at these photonic x-connects, but really for > something > which does the patching instead of a technician. > > > > TIA > Arnold From hmcglinn at gmail.com Tue Dec 9 04:12:04 2014 From: hmcglinn at gmail.com (Hamish McGlinn) Date: Tue, 9 Dec 2014 17:12:04 +1300 Subject: What can I infer from "show ip route" and similar BGP commands? In-Reply-To: References: Message-ID: Hi there, Perhaps this would be easier and help you out: http://bgp.he.net/AS3701#_graph4 Cheers, Hamish On Tue, Dec 9, 2014 at 12:48 PM, Reza Motamedi wrote: > Hello NANOG, > > I’m a researcher and I was trying to understand the data I collected from > some BGP Looking Glasses. Basically, I was hoping to see if BGP records can > tell me where my university’s provider (AS3701) is peering with its > providers. I issued two BGP queries to Level3’s LGs, one in Seattle and one > in Amsterdam for my school’s prefix. My strong guess was that our provider > (AS3701) peers with Level3 in Seattle. I was hoping to conclude something > like this: if the peering occurs in Seattle, the Seattle LG should reveal > it, but Amsterdam should not. > > AS3701 is Nero (Network for Education and Research in Oregon) which I > assume is a small regional AS. I don't think Nero peers with Level3 in > Amsterdam, however, I get this AS for my next hop even when I issue the > command from Amsterdam. On the other hand “car1.Sacramento1” suggests that > the peering happens in Sacramento. > > This result makes me think what I get is from a combination of iBGP and > eBGP, which is also apparent from “Internal/External” keywords in the data. > My main issue is that the keywords are not always available. In some other > LG I just get a next hop IP and an AS path. How can I make sure that the > peering information comes from an eBGP peering? I think the next hop IP > might be the answer, right? > > I included the results of the command for both LGs here, hopefully somebody > could explain to me > > ------------------------------------------------- > > Route results for 128.223.0.0/16 from Amsterdam, Netherlands > > BGP routing table entry for 128.223.0.0/16 > > Paths: (2 available, best #1) > > 3701 3582 > > AS-path translation: { OREGONUNIV UONET } > > car1.Sacramento1 (metric 58341) > > Origin IGP, metric 0, localpref 100, valid, internal, best > > Community: North_America Lclprf_100 Level3_Customer United_States > Sacramento > > Originator: car1.Sacramento1 > > 3701 3582 > > AS-path translation: { OREGONUNIV UONET } > > car1.Sacramento1 (metric 58341) > > Origin IGP, metric 0, localpref 100, valid, internal > > Community: North_America Lclprf_100 Level3_Customer United_States > Sacramento > > Originator: car1.Sacramento1 > > ------------------------------------------------- > > Route results for 128.223.6.81/16 from Seattle, WA > > BGP routing table entry for 128.223.0.0/16 > > Paths: (4 available, best #3) > > 3701 3582 > > AS-path translation: { OREGONUNIV UONET } > > 4.53.150.46 from 4.53.150.46 (ptck-core1-gw.nero.net) > > Origin IGP, localpref 90, valid, external > > Community: North_America Lclprf_90 Level3_Customer United_States Seattle > Level3:11847 > > 3701 3582, (received-only) > > AS-path translation: { OREGONUNIV UONET } > > 4.53.150.46 from 4.53.150.46 (ptck-core1-gw.nero.net) > > Origin IGP, localpref 100, valid, external > > Community: Level3:90 > > 3701 3582 > > AS-path translation: { OREGONUNIV UONET } > > car1.Sacramento1 (metric 34363) > > Origin IGP, metric 0, localpref 100, valid, internal, best > > Community: North_America Lclprf_100 Level3_Customer United_States > Sacramento > > Originator: car1.Sacramento1 > > 3701 3582 > > AS-path translation: { OREGONUNIV UONET } > > car1.Sacramento1 (metric 34363) > > Origin IGP, metric 0, localpref 100, valid, internal > > Community: North_America Lclprf_100 Level3_Customer United_States > Sacramento > > Originator: car1.Sacramento1 > > > Best Regards > Reza Motamedi (R.M) > Graduate Research Fellow > Computer and Information Science > University of Oregon > From arnold at nipper.de Tue Dec 9 23:51:43 2014 From: arnold at nipper.de (Arnold Nipper) Date: Wed, 10 Dec 2014 00:51:43 +0100 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: References: <548783F4.8010605@nipper.de> Message-ID: <54878B0F.1000405@nipper.de> Am 2014-12-10 00:36, schrieb Andrew Jones: > http://www.laser2000.de/out/media/glimmerglass_system_100%281%29.pdf > Thank you, Andrew ... while Glimmerglass is really an exciting and excdellent system, these devices are exactly those photonic cross connects I'm _not_ looking for :9 > On 10.12.2014 10:21, Arnold Nipper wrote: >> I'm looking for a modular, cost-effective automatic / intelligent fibre >> optic patch panel. >> >> I'm not looking at these photonic x-connects, but really for something >> which does the patching instead of a technician. >> Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From matthew at corp.crocker.com Tue Dec 9 23:58:00 2014 From: matthew at corp.crocker.com (Matthew Crocker) Date: Tue, 9 Dec 2014 18:58:00 -0500 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: <54878B0F.1000405@nipper.de> References: <548783F4.8010605@nipper.de> <54878B0F.1000405@nipper.de> Message-ID: Are you looking for a robot to install your fiber jumpers between patch panels? Something like: http://telescent.com/tswitch.php -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com > On Dec 9, 2014, at 6:51 PM, Arnold Nipper wrote: > > Am 2014-12-10 00:36, schrieb Andrew Jones: > >> http://www.laser2000.de/out/media/glimmerglass_system_100%281%29.pdf >> > > Thank you, Andrew ... while Glimmerglass is really an exciting and > excdellent system, these devices are exactly those photonic cross > connects I'm _not_ looking for :9 > >> On 10.12.2014 10:21, Arnold Nipper wrote: >>> I'm looking for a modular, cost-effective automatic / intelligent fibre >>> optic patch panel. >>> >>> I'm not looking at these photonic x-connects, but really for something >>> which does the patching instead of a technician. >>> > > > Arnold > -- > Arnold Nipper / nIPper consulting, Sandhausen, Germany > email: arnold at nipper.de phone: +49 6224 5593407 2 > mobile: +49 172 2650958 fax: +49 6224 5593407 9 > From keefe-af at ethoplex.com Wed Dec 10 00:30:34 2014 From: keefe-af at ethoplex.com (Keefe John) Date: Tue, 09 Dec 2014 18:30:34 -0600 Subject: ASN Domain for rDNS Message-ID: <5487942A.8030009@ethoplex.com> I've been seeing more and more carriers(and even small ISPs) using asXXXX.net as their domain for rDNS on IP space. What are the pros and cons for doing this versus using your primary business domain name? Keefe John From fred at web2objects.com Wed Dec 10 00:35:59 2014 From: fred at web2objects.com (Fred) Date: Wed, 10 Dec 2014 01:35:59 +0100 Subject: ASN Domain for rDNS In-Reply-To: <5487942A.8030009@ethoplex.com> References: <5487942A.8030009@ethoplex.com> Message-ID: <5487956F.9040704@web2objects.com> I'd say this is mostly for whitelabelling reason rather than a technical one? Keefe John: > I've been seeing more and more carriers(and even small ISPs) using > asXXXX.net as their domain for rDNS on IP space. What are the pros and > cons for doing this versus using your primary business domain name? > > Keefe John From zachary.mcgibbon+nanog at gmail.com Wed Dec 10 00:39:00 2014 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Tue, 9 Dec 2014 19:39:00 -0500 Subject: Cisco AnyConnect speed woes! In-Reply-To: <002101d013f8$8e6c6530$ab452f90$@ipnetworks.it> References: <244fd40df6074e58b55631b179929227@pur-vm-exch13n1.ox.com> <002101d013f8$8e6c6530$ab452f90$@ipnetworks.it> Message-ID: Hi Roberto, - We have disabled the DTLS compression feature, this has been verified on the client side that compression says 'None' - We are not using the VPN load balancing feature, the two boxes are running in an active/standby configuration - Yes we are tunnelling all traffic however local lan access is available if the user checks the checkbox in their client - We are inspecting the following: dns preset_dns_map, ftp, h323 h225, h323 ras, rsh, rtsp, esmtp, sqlnet, skinny, sunrpc, xdmcp, sip, netbios, tftp, ip-options, icmp - Jumbo frames are not configured - We are using the following encryption methods: AES128 and 2048 bit certificate - We are running ASA 9.2.2.8 on a 5545X - We are pushing the Anyconnect client version 3.1.05182 Also, I should mention what I mean when we see slow speeds. For example, my internet connection at home is a cable modem with 30mb down, 10mb up. I have done a path mtu discovery to my VPN at work and it is 1500. When I run an iperf to a server at the office without vpn I get about 28mb down, 9.5mb up. When I connect to vpn, the iperf to the same server is about 1.2mb down, and 900k up. This is way too slow! - Zachary On Tue, Dec 9, 2014 at 4:39 PM, Roberto wrote: > > The big issue we are having is that many of our users are complaining of > low speed when connected to the VPN. > Please can you indicate more details ? > > Is it enabled on the ASA the "compression" feature ? > Is it enabled on the ASA the VPN Load Balancing feature ? > Are you using the AnyConnect FULL TUNNEL mode ? > Which are the inspection configured on the ASA for the "remote access" > clients ? > Have you configured the Jumbo MTU on the CISCO ASA interfaces ? > Which encryption are configured on the ASA (are you using Suite B > Algorithms) ? > Which version of ASA are you using ? > Which version of AnyConnect are you using ? > > > Note: > protocols such as L2TP/IPSec are not hardware accelerated -- the IPSec > portion of L2TP/IPSec is hardware-accelerated, but the L2TP portion is not. > Likewise, the SSL portions of SVC and WebVPN use hardware acceleration, > but the application layer protocols are done in software. > > > Best Regards, > > _________________________________ > Roberto Taccon > > e-mail: roberto at ipnetworks.it > mobile: +39 340 4751352 > fax: +39 045 4850850 > skype: roberto.taccon > > -----Messaggio originale----- > Da: NANOG [mailto:nanog-bounces at nanog.org] Per conto di Zachary McGibbon > Inviato: martedì 9 dicembre 2014 21.18 > A: Matthew Huff > Cc: NANOG > Oggetto: Re: Cisco AnyConnect speed woes! > > We are trying to use SSLVPN (udp 443) and results are really all over the > place. Most of our complaints are users connecting on Teksavvy however we > haven't been able to reach anyone in their network team to find out if they > are doing any filtering or shaping on their side. > > We don't have a lot of traffic coming through Cogent, most of the users > are local here in Montreal on either Bell or Videotron and they traverse > through the QIX (www.qix.ca) > > On Tue, Dec 9, 2014 at 3:03 PM, Matthew Huff wrote: > > > Are you using SSLVpn or IPSEC with anyconnect? I have had more luck > > with performance with IPSEC than SSLVpn. > > > > Also, just because your ISP is saying that they aren't > > shaping/filtering, doesn't mean they aren't. > > > > We had major issues with users using AnyConnect when it was > > transversing Cogent. We were getting 5-10% packet loss (although the > > Cisco stats didn't show it), and it was choking on it. > > > > ---- > > Matthew Huff | 1 Manhattanville Rd > > Director of Operations | Purchase, NY 10577 > > OTA Management LLC | Phone: 914-460-4039 > > aim: matthewbhuff | Fax: 914-694-5669 > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Zachary > > McGibbon > > Sent: Tuesday, December 9, 2014 2:42 PM > > To: NANOG > > Subject: Cisco AnyConnect speed woes! > > > > I'm looking for some input on a situation that has been plaguing our > > new AnyConnect VPN setup. Any input would be valuable, we are at a > > loss for what the problem is. > > > > We recently upgraded our VPN from our old Cisco 3000 VPN concentrators > > running PPTP and we are now running a pair of Cisco 5545x ASAs in an > > HA active/standby pair. > > > > The big issue we are having is that many of our users are complaining > > of low speed when connected to the VPN. We have done tons of > > troubleshooting with Cisco TAC and we still haven't found the root of > our problem. > > > > Some tests we have done: > > > > - We have tested changing MTU values > > - We have tried all combinations of encryption methods (SSL, TLS, > IPSec, > > L2TP) with similar results > > - We have switched our active/standby boxes > > - We have tested on our spare 5545x box > > - We connected our spare box directly to our ISP with another IP > address > > - We have whitelisted our VPN IP on our shaper (Cisco SCE8000) and our > > IPS (HP Tipping Point) > > - We have bypassed our Shaper and our IPS > > - We made sure that traffic from the routers talking to our ASAs is > > synchronous, OSPF was configured to load balance but this has been > > changed > > by changing the costs on the links to the ASAs > > - We have verified with our two ISPs that they are not doing any kind > of > > filtering or shaping > > - We have noticed that in some instances that if a user is on a low > > speed connection that their VPN speed gets cut by about 1/3. This > > doesn't > > seem normal that the VPN would use this much overhead > > - We do not have the issue when connecting to VPN directly on our own > > network, only connections from the Internet > > > > If you have any ideas on what we could try net, please let me know! > > > > - Zachary > > > > From maxtul at netassist.ua Wed Dec 10 00:48:14 2014 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 10 Dec 2014 02:48:14 +0200 Subject: ASN Domain for rDNS In-Reply-To: <5487942A.8030009@ethoplex.com> References: <5487942A.8030009@ethoplex.com> Message-ID: <5487984E.9030305@netassist.ua> We use just .as domain, like our 29632.as ;) On 10.12.14 02:30, Keefe John wrote: > I've been seeing more and more carriers(and even small ISPs) using > asXXXX.net as their domain for rDNS on IP space. What are the pros and > cons for doing this versus using your primary business domain name? > > Keefe John > From allenmckinleykitchen at gmail.com Wed Dec 10 01:15:41 2014 From: allenmckinleykitchen at gmail.com (Allen McKinley Kitchen (gmail)) Date: Tue, 9 Dec 2014 20:15:41 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: <20141209222259.6742169.43034.17675@supermathie.net> References: <20141209222259.6742169.43034.17675@supermathie.net> Message-ID: <21EB2277-F8C9-43D8-9E2D-053DD730F617@gmail.com> +1 on the most important statement below, from my point of view: RAID 5 and RAID 10 are totally separate animals and while you can set up a separate RAID 10 array and migrate your data to it (as soon as possible!!!) you cannot migrate from 5 to 10 in place absent some utter magic that I am unaware of. 10 requires more raw drive space but offers significant write performance advantages when correctly configured (which isn't really too difficult). 5 is fine for protection against losing one drive, but 5 requires much more internal processing of writeable data before it begins the writes and, not too long ago, was considered completely inappropriate for applications with high numbers of writes, such as a transactional database. Still, 5 is often used for database systems in casual installations just because it's easy, cheap (relatively) and modern fast boxes are fast enough. Ok, getting down off my RAID soapbox - good luck. ..Allen > On Dec 9, 2014, at 17:22, Michael Brown wrote: > > If the serveraid7k cards are LSI and not Adaptec based (I think they are) you should just be able to plug in a new adapter and import the foreign configuration. > > You do have a good backup, yes? > > Switching to write-through has already happened (unless you specified WriteBackModeEvenWithNoBBU - not the default) - these (LSI) cards ‎by default only WB when "safe". > > If WT, RAID10 much better perf. BUT you just can't migrate from R5 to R10 non-destructively. > > - Michael from Kitchener > Original Message > From: symack > Sent: Tuesday, December 9, 2014 16:04 > To: nanog at nanog.org > Subject: Got a call at 4am - RAID Gurus Please Read > > Server down..... Got to colo at 4:39 and an old IBM X346 node with > Serveraid-7k has failed. Opened it up to find a swollen cache battery that > has bent the card in three different axis. Separated the battery. (i) > Inspect card and plug back in, (ii) reboot, and got (code 2807) Not > functioning.... > Return to (i) x3 got same result. Dusted her off and let it sit for a while > plugged in, rebooted to see if I can get her to write-through mode, disks > start spinning. Horay. > > Plan of action, (and the reason for my post): > > * Can I change from an active (ie, disks with data) raid 5 to raid 10. > There are 4 drives > in the unit, and I have two on the shelf that I can plug in. > * If so, will I have less of performance impact with RAID 10 + write-thru > then RAID 5 + write through > * When the new raid card comes in, can I just plug it in without loosing my > data? I would: > > i) RAID 10 > ii) Write-thru > iii) Replace card > > The new card is probably coming with a bad battery that would put us kind > of in square one. New batteries are 200+ if I can find them. Best case > scenario is move it over to RAID 10+Write-thru, and feel less of the > performance pinch. > > Given I can move from RAID 5 to RAID 10 without loosing data. How long to > anticipate downtime for this process? Is there heavy sector re-arranging > happening here? And the same for write-thru, is it done quick? > > I'm going to go lay down just for a little white. > > Thanks in Advance, > > Nick from Toronto. From damien at supremebytes.com Wed Dec 10 01:18:12 2014 From: damien at supremebytes.com (Damien Burke) Date: Wed, 10 Dec 2014 01:18:12 +0000 Subject: ASN Domain for rDNS In-Reply-To: <5487956F.9040704@web2objects.com> References: <5487942A.8030009@ethoplex.com> <5487956F.9040704@web2objects.com> Message-ID: <2FD50E6D13594B4C93B743BFCF9F528422C3A4F1@exchange-two.sb.local> Honestly, it looks pretty and you can see the ASN in the traceroute from windows/linux standard traceroute commands. I don't think it's for white label as most ASN's have a company name in their WHOIS on ARIN/RIPE/ETC. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Fred Sent: Tuesday, December 09, 2014 4:36 PM To: nanog at nanog.org Subject: Re: ASN Domain for rDNS I'd say this is mostly for whitelabelling reason rather than a technical one? Keefe John: > I've been seeing more and more carriers(and even small ISPs) using > asXXXX.net as their domain for rDNS on IP space. What are the pros > and cons for doing this versus using your primary business domain name? > > Keefe John From detoler at gmail.com Wed Dec 10 03:12:17 2014 From: detoler at gmail.com (Duane Toler) Date: Tue, 9 Dec 2014 22:12:17 -0500 Subject: Contact from Sharktech available? Message-ID: Can someone from Sharktech contact me off list to discuss an NTP flood from your co-lo network? One of my customers has a site being hammered by a few subnets of yours. Thanks!! -- Duane Toler detoler at gmail.com From kate at quadranet.com Wed Dec 10 05:13:27 2014 From: kate at quadranet.com (Kate Gerry) Date: Tue, 9 Dec 2014 21:13:27 -0800 Subject: ASN Domain for rDNS In-Reply-To: <5487956F.9040704@web2objects.com> References: <5487942A.8030009@ethoplex.com> <5487956F.9040704@web2objects.com> Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F601A7F1440B0C@EXCH> Short answer: I just like doing it. Long answer: It allows me to create as many hosts on a segregated domain instead of making my company DNS zone 3000 records long. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Fred Sent: Tuesday, December 09, 2014 4:36 PM To: nanog at nanog.org Subject: Re: ASN Domain for rDNS I'd say this is mostly for whitelabelling reason rather than a technical one? Keefe John: > I've been seeing more and more carriers(and even small ISPs) using > asXXXX.net as their domain for rDNS on IP space. What are the pros > and cons for doing this versus using your primary business domain name? > > Keefe John From arnold at nipper.de Wed Dec 10 05:34:40 2014 From: arnold at nipper.de (Arnold Nipper) Date: Wed, 10 Dec 2014 06:34:40 +0100 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: References: <548783F4.8010605@nipper.de> <54878B0F.1000405@nipper.de> Message-ID: <5487DB70.7010800@nipper.de> Am 2014-12-10 00:58, schrieb Matthew Crocker: > > Are you looking for a robot to install your fiber jumpers between patch panels? > Exactly ... > Something like: http://telescent.com/tswitch.php > ... like this, Matthew. Do you know Telescent systems? > >> On Dec 9, 2014, at 6:51 PM, Arnold Nipper wrote: >> >> Am 2014-12-10 00:36, schrieb Andrew Jones: >> >>> http://www.laser2000.de/out/media/glimmerglass_system_100%281%29.pdf >>> >> >> Thank you, Andrew ... while Glimmerglass is really an exciting and >> excdellent system, these devices are exactly those photonic cross >> connects I'm _not_ looking for :9 >> >>> On 10.12.2014 10:21, Arnold Nipper wrote: >>>> I'm looking for a modular, cost-effective automatic / intelligent fibre >>>> optic patch panel. >>>> >>>> I'm not looking at these photonic x-connects, but really for something >>>> which does the patching instead of a technician. >>>> >> Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From sunyucong at gmail.com Wed Dec 10 06:27:00 2014 From: sunyucong at gmail.com (Yucong Sun) Date: Tue, 9 Dec 2014 22:27:00 -0800 Subject: Charging fee for BGP prefix per /24?! Message-ID: Hi, My recent inquiry to some network provider reveals that they are charging fee for per /24 announced. Obvious that would means they get to charge a lot with little to none efforts on their side. In a world we are charging total bytes transferred instead of bps on uplinks, i can't say I'm surprised that much. But does anyone else had same experience? Did you pay? Is this the new status quo now? Thanks. From tore at fud.no Wed Dec 10 08:20:45 2014 From: tore at fud.no (Tore Anderson) Date: Wed, 10 Dec 2014 09:20:45 +0100 Subject: Charging fee for BGP prefix per /24?! In-Reply-To: References: Message-ID: <20141210092045.40f3df27@envy.fud.no> * Yucong Sun > My recent inquiry to some network provider reveals that they are > charging fee for per /24 announced. Obvious that would means they get > to charge a lot with little to none efforts on their side. > > In a world we are charging total bytes transferred instead of bps on > uplinks, i can't say I'm surprised that much. But does anyone else had > same experience? Did you pay? Is this the new status quo now? Haven't encountered this myself, but putting a price on DFZ routing slots seems like a Good Thing to me. Tore From sunyucong at gmail.com Wed Dec 10 08:40:34 2014 From: sunyucong at gmail.com (Yucong Sun) Date: Wed, 10 Dec 2014 08:40:34 +0000 Subject: Charging fee for BGP prefix per /24?! References: <000001d01452$3ef37200$bcda5600$@at> Message-ID: It is not the same thing though. In my case, they just say we want you to buy our IP, if you don't and want use you own Arin allocated IP blocks through bgp, then we got to charge you anyway! Because why couldn't they? On Wed, Dec 10, 2014, 00:21 Maximilian Baehring wrote: > Europe: It costs 50 euros yearly fee per PI-Space Resource without the > anouncment ppayable via a LIR. They cahreg - in my case - additional 25 > Euros for the financial transaction with Ripe. The cheapest possible > anouncment is via TWO Route-Servers and the minimum required for this is a > VPS (not openVZ which cannot run the routing daemon) Linux-KVM with Quagga! > http://www.openpeering.nl/shoppinglist.shtml - http://www.ripe.net/lir- > services/member-support/info/billing/billing-procedure-and- > fee-schedule-2014 > > mit freundlichem Gru&SZlig; / Yours sincerely > > Maximilian Baehring > Hoelderlinstrasse 4 > 60316 Frankfurt a.M. > Germany > maximilian at baehring.at > Fon: +49 (0)69 17320776 > Fon: +49 (0)176 65605075 > Fon: +49 (0)174 3639226 > Fax: +49 (0)69 67831634 > > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: GnuPG v2 > > mQGiBFRbtw0RBACmtrehmuVpR0EiXlEcdl9AttnGlK7BvVidu+EEJAg8bpnzxZ3G > nGF2Z4LDSnEJid4nDs4ey7lAlkQ0bVozcmutyCvQo2JXNwjtVlMFR3ePuHGcgn6i > 55bFw2aMhth5d//3MoYAXk/PeFH2zZtWwq6WVIYN4YIIPLT/j7nEElndnwCglQHs > jDVQcAGmqZeJBA+j2SwIIjMD/1yy/tq7qyQ2O12+f4mIVLNY6+lTmg9jQu3y0jiw > fT7xKQ3e4YSsYUxZM03Uw8XHL9OqDhKROppx1D0ywSaHzdFi14VBU0B1rv5ZUFbF > IkO06R8dFl8HOoEwaplPtr1e6b17oM0KkLRf15nPi39pmnr8IYtpArQTV83Twmgz > L65vA/47+UZi618F5UafoXqmRPoSnz7Bcfrk84I8WmSDqXY/VqD35DdYFz0pzCY9 > R2wk7ivxfF/cbPSrq9WUqbDGlcso96FlbqWdtPROuQQqepn3giOxDTY5RqhG0M3d > IVdja94U08K7ypbI7pPJbl8fb8wSJ0qHdRvnvx5HnHqXd/uA4LQsTWF4aW1pbGlh > biBCYWVocmluZyA8bWF4aW1pbGlhbkBiYWVocmluZy5hdD6IYwQTEQIAIwUCVFu3 > DQIbAwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEH2oe7epzbrju5cAn3P3 > 0/S+fIMLHYUCDBIpeEl/Cw5uAJ9smUUUHwh2M0SkJAxEmec4mpaDI7kBDQRUW7cN > EAQAkHhbnFMtkJeMbyb9HnlwGRQ8/W2NV4mfHTce/c2ggtionOYcPi1BXBN2Nq/w > knfQDAbnwrSk21xZ//BN8CE570cEGgLAN3ILyvmjXwBtLfKDpe/RYVskjxFgMtQ1 > lz7BiU9MfrVDWKNP1PJPSAAjcWPPgIJVzFjbIrOC1DKeR9sAAwUD/RsSBkJVmfA3 > NnK/vRnZMQ9sgUiXVYblJHXxnCvGVSz6rWRdR3jrQrALYeCkqbGEZAoX7PhLUwG5 > +c+nwhbKgnSI5VkwTxTf5To/sKfGY/ZU7uVKdNT3OG6fon5kSv+1neXD2ekFoD5G > NV2DqzaXq4kjIi3gfgU0PpeMpHyNsyA7iEkEGBECAAkFAlRbtw0CGwwACgkQfah7 > t6nNuuMXqQCZAfBvDdJ/9S8qK6u/yVo6t9cxtpkAn3XJsfNKK4YwRgL68p6eK8uA > +VIJ > =kOqh > -----END PGP PUBLIC KEY BLOCK----- > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+maximilian=baehring.at at nanog.org] On > Behalf Of Yucong Sun > Sent: Mittwoch, 10. Dezember 2014 07:27 > To: NANOG > Subject: Charging fee for BGP prefix per /24?! > > Hi, > > My recent inquiry to some network provider reveals that they are charging > fee for per /24 announced. Obvious that would means they get to charge a > lot with little to none efforts on their side. > > In a world we are charging total bytes transferred instead of bps on > uplinks, i can't say I'm surprised that much. But does anyone else had same > experience? Did you pay? Is this the new status quo now? > > Thanks. > > From sunyucong at gmail.com Wed Dec 10 08:40:35 2014 From: sunyucong at gmail.com (Yucong Sun) Date: Wed, 10 Dec 2014 08:40:35 +0000 Subject: Charging fee for BGP prefix per /24?! References: <20141210092045.40f3df27@envy.fud.no> Message-ID: if that is the intent, they should charge per prefix. Not per /24 eqiv. On Wed, Dec 10, 2014, 00:20 Tore Anderson wrote: > * Yucong Sun > > > My recent inquiry to some network provider reveals that they are > > charging fee for per /24 announced. Obvious that would means they get > > to charge a lot with little to none efforts on their side. > > > > In a world we are charging total bytes transferred instead of bps on > > uplinks, i can't say I'm surprised that much. But does anyone else had > > same experience? Did you pay? Is this the new status quo now? > > Haven't encountered this myself, but putting a price on DFZ routing > slots seems like a Good Thing to me. > > Tore > From seth.mos at dds.nl Wed Dec 10 08:49:57 2014 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 10 Dec 2014 09:49:57 +0100 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: Message-ID: <54880935.7040103@dds.nl> symack schreef op 9-12-2014 22:03: > * Can I change from an active (ie, disks with data) raid 5 to raid 10. > There are 4 drives Dump and restore. I've used Acronis succesfully in the past and today, they have a bootable ISO. Also, if you have the option, they have universal restore so you can restore Windows on another piece of hardware (you provide the drivers). > in the unit, and I have two on the shelf that I can plug in. > * If so, will I have less of performance impact with RAID 10 + write-thru > then RAID 5 + write through Raid10 is the only valid raid format these days. With the disks as big as they get these days it's possible for silent corruption. And with 4TB+ disks that is a real thing. Raid 6 is ok, if you accept rebuilds that take a week, literally. Although the rebuild rate on our 11 disk raid 6 SSD array (2TB) is less then a day. If it accepts sata drives, consider just using SSDs instead. They're just 600 euros for a 800GB drive. (Intel S3500) > Given I can move from RAID 5 to RAID 10 without loosing data. How long to > anticipate downtime for this process? Is there heavy sector re-arranging > happening here? And the same for write-thru, is it done quick? Heavy sectory re-arranging, yes, so just dump and restore, it's faster and more reliable. Also, you then have a working bare metal restore backup. Regards, Seth From stu at spacehopper.org Wed Dec 10 10:32:55 2014 From: stu at spacehopper.org (Stuart Henderson) Date: Wed, 10 Dec 2014 10:32:55 +0000 (UTC) Subject: Got a call at 4am - RAID Gurus Please Read References: Message-ID: On 2014-12-09, symack wrote: > Server down..... Got to colo at 4:39 and an old IBM X346 node with > Serveraid-7k has failed. Opened it up to find a swollen cache battery that > has bent the card in three different axis. > * Can I change from an active (ie, disks with data) raid 5 to raid 10. Even if the hw/firmware supports it, raid level migration is risky enough at the best of times, and totally insane on a known-bad controller. From rubensk at gmail.com Wed Dec 10 11:20:45 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 10 Dec 2014 09:20:45 -0200 Subject: ASN Domain for rDNS In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F601A7F1440B0C@EXCH> References: <5487942A.8030009@ethoplex.com> <5487956F.9040704@web2objects.com> <4B4120B1642DCF48ACA84E4F82C8E1F601A7F1440B0C@EXCH> Message-ID: And considering browsers use domains to define whether to send cookies or not along a request, not having access customers on the same domain of your website is a security benefit. Rubens On Wed, Dec 10, 2014 at 3:13 AM, Kate Gerry wrote: > Short answer: I just like doing it. > > Long answer: It allows me to create as many hosts on a segregated domain > instead of making my company DNS zone 3000 records long. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Fred > Sent: Tuesday, December 09, 2014 4:36 PM > To: nanog at nanog.org > Subject: Re: ASN Domain for rDNS > > I'd say this is mostly for whitelabelling reason rather than a technical > one? > > Keefe John: > > I've been seeing more and more carriers(and even small ISPs) using > > asXXXX.net as their domain for rDNS on IP space. What are the pros > > and cons for doing this versus using your primary business domain name? > > > > Keefe John > From contact at winterei.se Wed Dec 10 11:43:49 2014 From: contact at winterei.se (Paul S.) Date: Wed, 10 Dec 2014 20:43:49 +0900 Subject: ASN Domain for rDNS In-Reply-To: <5487942A.8030009@ethoplex.com> References: <5487942A.8030009@ethoplex.com> Message-ID: <548831F5.9040000@winterei.se> Just been using the .net version of our company domain for router/interface IPs. Also own the AS.com/net and .as though, primarily to not get squatted on. On 12/10/2014 午前 09:30, Keefe John wrote: > I've been seeing more and more carriers(and even small ISPs) using > asXXXX.net as their domain for rDNS on IP space. What are the pros > and cons for doing this versus using your primary business domain name? > > Keefe John From james.braunegg at micron21.com Wed Dec 10 13:08:28 2014 From: james.braunegg at micron21.com (James Braunegg) Date: Wed, 10 Dec 2014 13:08:28 +0000 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: <10AB04B9CE55DF4AA248C0388F4ED464641E0535@SDLDALPWEMB07.suddenlink.cequel3.com> References: <5484B40F.3010203@noor.net> <6F2BC9429CDDC6438D1FE460D2258BB401B1994E66@EXCHANGENODE1.ritter.net> <63313FDA-EF90-4677-B4AF-DEACE62B7DD0@fastreturn.net> <10AB04B9CE55DF4AA248C0388F4ED464641E0535@SDLDALPWEMB07.suddenlink.cequel3.com> Message-ID: Dear All We use a combination of NSFOCUS hardware (ADS, ADS-m and NTA along with A10 Hardware) All of which I highly recommend ! Kindest Regards James Braunegg P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 E: james.braunegg at micron21.com | ABN: 12 109 977 666 W: www.micron21.com/ddos-protection T: @micron21 [Description: Description: Description: Description: M21.jpg] This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Parrish, Luke Sent: Wednesday, December 10, 2014 8:08 AM To: J. Tozo Cc: nanog Subject: RE: Carrier-grade DDoS Attack mitigation appliance Switch to Nemo. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of J. Tozo Sent: Monday, December 08, 2014 3:26 PM Cc: nanog Subject: Re: Carrier-grade DDoS Attack mitigation appliance We also evaluating another appliance to put in place of Arbor, their "support" outside USA its a joke. On Mon, Dec 8, 2014 at 6:17 PM, Ammar Zuberi wrote: > Hi, > > We're currently running the Arbor Peakflow SP with the TMS and it > works very well for us. > > Best Regards, > > Ammar Zuberi > FastReturn, Inc > > > > > Direct Line: +971 50 394 7299 > Email: ammar at fastreturn.net > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are addressed. > If you have received it by mistake, please let us know by e-mail reply > and delete it from your system; you may not copy this message or > disclose its contents to anyone. Please note that any views or > opinions presented in this email are solely those of the author and do > not necessarily represent those of the company. Finally, the recipient > should check this email and any attachments for the presence of > viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > > > On Dec 8, 2014, at 10:53 PM, Tony McKay > wrote: > > > > Does anyone on list currently use Peakflow SP from Arbor with TMS, > > and > is it truly a carrier grade DDoS detection and mitigation platform? > Anyone have any experience with Plixir? > > > > Tony McKay > > Dir. Of Network Operations > > Office: 870.336.3449 > > Mobile: 870.243.0058 > > -The boundary to your comfort zone fades a little each time you > > cross > it. Raise your limits by pushing them. > > > > This electronic mail transmission may contain confidential or > > privileged > information. If you believe that you have received this message in > error, please notify the sender by reply transmission and delete the > message without copying or disclosing it. > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mohamed > > Kamal > > Sent: Sunday, December 07, 2014 2:10 PM > > To: nanog > > Subject: Carrier-grade DDoS Attack mitigation appliance > > > > > > Have anyone tried any DDoS attack mitigation appliance rather than > > Arbor > PeakFlow TMS? I need it to be carrier-grade in terms of capacity and > redundancy, and as far as I know, Arbor is the only product in the > market which offers a "clean pipe" volume of traffic, so if the DDoS > attack volume is, for example, 1Tbps, they will grant you for example > 50Gbps of clean traffic. > > > > Anyway, I'm open to other suggestions, and open-source products that > > can > do the same purpose, we have network development team that can work on this. > > > > Thanks. > > > > -- > > Mohamed Kamal > > Core Network Sr. Engineer > > > > -- Grato, Tozo ________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, confidential and/or legally 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 received this in error, please contact the sender and delete the material from all computers. ________________________________ From rs at seastrom.com Wed Dec 10 13:40:21 2014 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 10 Dec 2014 08:40:21 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: <54880935.7040103@dds.nl> (Seth Mos's message of "Wed, 10 Dec 2014 09:49:57 +0100") References: <54880935.7040103@dds.nl> Message-ID: <86mw6vpqre.fsf@valhalla.seastrom.com> The subject is drifting a bit but I'm going with the flow here: Seth Mos writes: > Raid10 is the only valid raid format these days. With the disks as big > as they get these days it's possible for silent corruption. How do you detect it? A man with two watches is never sure what time it is. Unless you have a filesystem that detects and corrects silent corruption, you're still hosed, you just don't know it yet. RAID10 between the disks in and of itself doesn't help. > And with 4TB+ disks that is a real thing. Raid 6 is ok, if you accept > rebuilds that take a week, literally. Although the rebuild rate on our > 11 disk raid 6 SSD array (2TB) is less then a day. I did a rebuild on a RAIDZ2 vdev recently (made out of 4tb WD reds). It took nowhere near a day let alone a week. Theoretically takes 8-11 hours if the vdev is completely full, proportionately less if it's not, and I was at about 2/3 in use. -r From johnl at iecc.com Wed Dec 10 16:33:38 2014 From: johnl at iecc.com (John Levine) Date: 10 Dec 2014 16:33:38 -0000 Subject: Charging fee for BGP prefix per /24?! In-Reply-To: <20141210092045.40f3df27@envy.fud.no> Message-ID: <20141210163338.14497.qmail@ary.lan> >Haven't encountered this myself, but putting a price on DFZ routing >slots seems like a Good Thing to me. Paid to whom? Yes, it would be nice to put more backpressure on announcements to get the size of the DFZ down. But unless you can figure out how to get the money from the people announcing the routes to the people actually running the backbone routers, fees are just a way for providers to extract more money from their customers. R's, John From ammar at fastreturn.net Wed Dec 10 16:39:48 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Wed, 10 Dec 2014 20:39:48 +0400 Subject: Charging fee for BGP prefix per /24?! In-Reply-To: <20141210163338.14497.qmail@ary.lan> References: <20141210163338.14497.qmail@ary.lan> Message-ID: <4E7A819E-F724-442F-AAF6-2CAEE30C2B68@fastreturn.net> I was once with a provider that charged something stupid like $500 per BGP session. This really isn't that big of a surprise. On 10 Dec 2014, at 8:33 pm, John Levine wrote: >> Haven't encountered this myself, but putting a price on DFZ routing >> slots seems like a Good Thing to me. > > Paid to whom? > > Yes, it would be nice to put more backpressure on announcements to get > the size of the DFZ down. But unless you can figure out how to get > the money from the people announcing the routes to the people actually > running the backbone routers, fees are just a way for providers to > extract more money from their customers. > > R's, > John From jabley at hopcount.ca Wed Dec 10 20:57:05 2014 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 10 Dec 2014 15:57:05 -0500 Subject: ASN Domain for rDNS In-Reply-To: <5487942A.8030009@ethoplex.com> References: <5487942A.8030009@ethoplex.com> Message-ID: <87636BF4-5090-490B-B504-CCCC04BFBD85@hopcount.ca> On 9 Dec 2014, at 19:30, Keefe John wrote: > I've been seeing more and more carriers(and even small ISPs) using asXXXX.net as their domain for rDNS on IP space. What are the pros and cons for doing this versus using your primary business domain name? When you are forced to change your name because of chapter 11, acquisition, rebranding, trademark challenge or a sudden need to distance yourself from previous senior management and their intense hatred of all customers, it's nice not to have to change all your reverse DNS. Joe From javier at advancedmachines.us Wed Dec 10 22:18:49 2014 From: javier at advancedmachines.us (Javier J) Date: Wed, 10 Dec 2014 17:18:49 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: <86mw6vpqre.fsf@valhalla.seastrom.com> References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> Message-ID: I'm just going to chime in here since I recently had to deal with bit-rot affecting a 6TB linux raid5 setup using mdadm (6x 1TB disks) We couldn't rebuild because of 5 URE sectors on one of the other disks in the array after a power / ups issue rebooted our storage box. We are now using ZFS RAIDZ and the question I ask myself is, why wasn't I using ZFS years ago? +1 for ZFS and RAIDZ On Wed, Dec 10, 2014 at 8:40 AM, Rob Seastrom wrote: > > The subject is drifting a bit but I'm going with the flow here: > > Seth Mos writes: > > > Raid10 is the only valid raid format these days. With the disks as big > > as they get these days it's possible for silent corruption. > > How do you detect it? A man with two watches is never sure what time it > is. > > Unless you have a filesystem that detects and corrects silent > corruption, you're still hosed, you just don't know it yet. RAID10 > between the disks in and of itself doesn't help. > > > And with 4TB+ disks that is a real thing. Raid 6 is ok, if you accept > > rebuilds that take a week, literally. Although the rebuild rate on our > > 11 disk raid 6 SSD array (2TB) is less then a day. > > I did a rebuild on a RAIDZ2 vdev recently (made out of 4tb WD reds). > It took nowhere near a day let alone a week. Theoretically takes 8-11 > hours if the vdev is completely full, proportionately less if it's > not, and I was at about 2/3 in use. > > -r > > From jfmezei_nanog at vaxination.ca Wed Dec 10 22:26:58 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 10 Dec 2014 17:26:58 -0500 Subject: Relative cost of ONT and UPS for FTTP Message-ID: <5488C8B2.8010300@vaxination.ca> At recent hearings, I stuck my foot deep into my mouth (as I often do). So I am now tasked to find the relative cost of the ONT/UPS compared to the cost of the FTTP drop to the home (in a Flexnap environment). >From what I had read in the past, the ONT/UPS represent a major portion of the costs to connect a home to an existing Flexnap FTTP system as the drop itself is now dirt cheap to install with unskilled workforce (no need for laser splicing since flexnap is plug and play). I know that the Aussie NBN had considered ditching the UPS to greatly reduce the cost to reduce homes, so I have to hunt down those documents (which predate existing pro-copper govt). Does ayone have numbers for ONT/UPS or could point me to such ? I assume manpower to install the ONT/UPS in homes is a large part of the cost inside the home ? And is there any evidence that the actual drop to the home with Flexnap FTTP is cheaper than a drop using copper from the splice panel on pole to the home ? Any/all information would be helpful. (this is convince the regulator that an independent ISP who buys the ONT/UPS to be used by one of its customers relieves the incumbent telco from a major portion of the cost to connect a home, which, according to telcos, represent 1/3 of total cost of FTTP deployment. From jgreco at ns.sol.net Thu Dec 11 00:07:24 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 10 Dec 2014 18:07:24 -0600 (CST) Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: Message-ID: <201412110007.sBB07O9o063135@aurora.sol.net> > I'm just going to chime in here since I recently had to deal with bit-rot > affecting a 6TB linux raid5 setup using mdadm (6x 1TB disks) > > We couldn't rebuild because of 5 URE sectors on one of the other disks in > the array after a power / ups issue rebooted our storage box. > > We are now using ZFS RAIDZ and the question I ask myself is, why wasn't I > using ZFS years ago? > > +1 for ZFS and RAIDZ I hope you are NOT using RAIDZ. The chances of an error showing up during a resilver is uncomfortably high and there are no automatic tools to fix pool corruption with ZFS. Ideally use RAIDZ2 or RAIDZ3 to provide more appropriate levels of protection. Errors introduced into a pool can cause substantial unrecoverable damage to the pool, so you really want the bitrot detection and correction mechanisms to be working "as designed." ... 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 bedard.phil at gmail.com Thu Dec 11 00:33:07 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 10 Dec 2014 19:33:07 -0500 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: <54878B0F.1000405@nipper.de> References: <548783F4.8010605@nipper.de> <54878B0F.1000405@nipper.de> Message-ID: Curious what the use case is where a photonic or L1 switch wouldn't get the job done? With the robotic system you still need to wire everything up so it's available to be xconnected. FiberZone was another vendor who made robotic patch panels, but I'm not sure they are around anymore. Interesting also Verizon has a patent on automated patch panels, but using very specific mechanics. https://www.google.com/patents/US8175425 Phil On 12/9/14, 11:51 PM, "Arnold Nipper" wrote: >Am 2014-12-10 00:36, schrieb Andrew Jones: > >> http://www.laser2000.de/out/media/glimmerglass_system_100%281%29.pdf >> > >Thank you, Andrew ... while Glimmerglass is really an exciting and >excdellent system, these devices are exactly those photonic cross >connects I'm _not_ looking for :9 > >> On 10.12.2014 10:21, Arnold Nipper wrote: >>> I'm looking for a modular, cost-effective automatic / intelligent fibre >>> optic patch panel. >>> >>> I'm not looking at these photonic x-connects, but really for something >>> which does the patching instead of a technician. >>> > > >Arnold >-- >Arnold Nipper / nIPper consulting, Sandhausen, Germany >email: arnold at nipper.de phone: +49 6224 5593407 2 >mobile: +49 172 2650958 fax: +49 6224 5593407 9 > From joelja at bogus.com Thu Dec 11 01:21:03 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 10 Dec 2014 17:21:03 -0800 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: References: <548783F4.8010605@nipper.de> <54878B0F.1000405@nipper.de> Message-ID: <5488F17F.7030304@bogus.com> On 12/10/14 4:33 PM, Phil Bedard wrote: > Curious what the use case is where a photonic or L1 switch wouldn't get > the job done? > > With the robotic system you still need to wire everything up so it's > available to be xconnected. We've done electromechanical cross connect termination before on a very large scale. http://www.siemens.com/history/pool/newsarchiv/newsmeldungen/20110403_bild_3_fernsprechamt_muenchen-schwabing_458px.jpg those systems typically don't have the capacity to connect 100% of the edges at once. > FiberZone was another vendor who made robotic patch panels, but I'm not > sure they are around anymore. their website is still there, I've never seen an AFM live. > Interesting also Verizon has a patent on automated patch panels, but using > very specific mechanics. > > https://www.google.com/patents/US8175425 > > > > > Phil > > > > > On 12/9/14, 11:51 PM, "Arnold Nipper" wrote: > >> Am 2014-12-10 00:36, schrieb Andrew Jones: >> >>> http://www.laser2000.de/out/media/glimmerglass_system_100%281%29.pdf >>> >> Thank you, Andrew ... while Glimmerglass is really an exciting and >> excdellent system, these devices are exactly those photonic cross >> connects I'm _not_ looking for :9 >> >>> On 10.12.2014 10:21, Arnold Nipper wrote: >>>> I'm looking for a modular, cost-effective automatic / intelligent fibre >>>> optic patch panel. >>>> >>>> I'm not looking at these photonic x-connects, but really for something >>>> which does the patching instead of a technician. >>>> >> >> Arnold >> -- >> Arnold Nipper / nIPper consulting, Sandhausen, Germany >> email: arnold at nipper.de phone: +49 6224 5593407 2 >> mobile: +49 172 2650958 fax: +49 6224 5593407 9 >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 221 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Thu Dec 11 02:25:29 2014 From: randy at psg.com (Randy Bush) Date: Thu, 11 Dec 2014 11:25:29 +0900 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> Message-ID: > We are now using ZFS RAIDZ and the question I ask myself is, why > wasn't I using ZFS years ago? because it is not production on linux, which i have to use because freebsd does not have kvm/ganeti. want zfs very very badly. snif. randy From jeroen at mompl.net Thu Dec 11 02:35:03 2014 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 10 Dec 2014 18:35:03 -0800 Subject: Comcast thinks it ok to install public wifi in your house Message-ID: <548902D7.60406@mompl.net> Why am I not surprised? Whose fault would it be if your comcast installed public wifi would be abused to download illegal material or launch a botnet, to name some random fun one could have on your behalf. :-/ (apologies if this was posted already, couldn't find an email about it on the list) http://www.theregister.co.uk/2014/12/10/disgruntled_customers_lob_sueball_at_comcast_over_public_wifi/ "A mother and daughter are suing Comcast claiming the cable giant's router in their home was offering public Wi-Fi without their permission. Comcast-supplied routers broadcast an encrypted, private wireless network for people at home, plus a non-encrypted network called XfinityWiFi that can be used by nearby subscribers. So if you're passing by a fellow user's home, you can lock onto their public Wi-Fi, log in using your Comcast username and password, and use that home's bandwidth. However, Toyer Grear, 39, and daughter Joycelyn Harris – who live together in Alameda County, California – say they never gave Comcast permission to run a public network from their home cable connection. In a lawsuit [PDF] filed in the northern district of the golden state, the pair accuse the ISP of breaking the Computer Fraud and Abuse Act and two other laws. Grear – a paralegal – and her daughter claim the Xfinity hotspot is an unauthorized intrusion into their private home, places a "vast" burden on electricity bills, opens them up to attacks by hackers, and "degrades" their bandwidth. "Comcast does not, however, obtain the customer's authorization prior to engaging in this use of the customer's equipment and internet service for public, non-household use," the suit claims. "Indeed, without obtaining its customers' authorization for this additional use of their equipment and resources, over which the customer has no control, Comcast has externalized the costs of its national Wi-Fi network onto its customers." The plaintiffs are seeking monetary damages for themselves and on behalf of all Comcast customers nation-wide in their class-action case – the service was rolled out to 20 million customers this year." -- Earthquake Magnitude: 4.8 Date: 2014-12-10 22:10:36.800 UTC Date Local: 2014-12-10 13:10:36 PST Location: 120km W of Panguna, Papua New Guinea Latitude: -6.265; Longitude: 154.4004 Depth: 35 km | e-quake.org From briansupport at hotmail.com Thu Dec 11 01:18:23 2014 From: briansupport at hotmail.com (Brian R) Date: Wed, 10 Dec 2014 17:18:23 -0800 Subject: Relative cost of ONT and UPS for FTTP In-Reply-To: References: <5488C8B2.8010300@vaxination.ca>, <6D831F4EBDCFF1448CEC58FD99A4768F5B931CC2@Exchange-2010.CORP.local>, Message-ID: Jean-Francois, We use the Adtran ONT solutions. The configuration is Adtran TA5000 with an Active Ethernet 24-Port Module (1187561F1) feeding an ONT TA324E (1287737G2) at the customer premise. For power we are using the Cyber Power CSN27U12v-NA3 units. The clam shell we are using to put the ONT in is TA350 ONT NID HSG SPLICE (1187770G1) All of these part numbers should be available on Adtrans website to look up. Brian > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois Mezei > Sent: Wednesday, December 10, 2014 2:27 PM > To: Nanog at nanog.org > Subject: Relative cost of ONT and UPS for FTTP > > At recent hearings, I stuck my foot deep into my mouth (as I often do). > > So I am now tasked to find the relative cost of the ONT/UPS compared to the cost of the FTTP drop to the home (in a Flexnap environment). > > From what I had read in the past, the ONT/UPS represent a major portion of the costs to connect a home to an existing Flexnap FTTP system as the drop itself is now dirt cheap to install with unskilled workforce (no need for laser splicing since flexnap is plug and play). > > I know that the Aussie NBN had considered ditching the UPS to greatly reduce the cost to reduce homes, so I have to hunt down those documents (which predate existing pro-copper govt). > > > Does ayone have numbers for ONT/UPS or could point me to such ? > I assume manpower to install the ONT/UPS in homes is a large part of the cost inside the home ? > > > And is there any evidence that the actual drop to the home with Flexnap FTTP is cheaper than a drop using copper from the splice panel on pole to the home ? > > Any/all information would be helpful. (this is convince the regulator that an independent ISP who buys the ONT/UPS to be used by one of its customers relieves the incumbent telco from a major portion of the cost to connect a home, which, according to telcos, represent 1/3 of total cost of FTTP deployment. > > From w3yni1 at gmail.com Thu Dec 11 02:41:42 2014 From: w3yni1 at gmail.com (Charles Mills) Date: Wed, 10 Dec 2014 21:41:42 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548902D7.60406@mompl.net> References: <548902D7.60406@mompl.net> Message-ID: In the US at least you have to authenticate with your Comcast credentials and not like a traditional open wifi where you can just make up an email and accept the terms of service. I also understand that it is a different IP than the subscriber. Based on this the subscriber should be protected from anyone doing anything illegal and causing the SWAT team to pay a visit. I haven't upgraded my gear though. Now..they are doing this on your electric bill and taking up space (albeit a small amount of it) in your home. Chuck On Wed, Dec 10, 2014 at 9:35 PM, Jeroen van Aart wrote: > Why am I not surprised? > > Whose fault would it be if your comcast installed public wifi would be > abused to download illegal material or launch a botnet, to name some random > fun one could have on your behalf. :-/ > > (apologies if this was posted already, couldn't find an email about it on > the list) > > http://www.theregister.co.uk/2014/12/10/disgruntled_ > customers_lob_sueball_at_comcast_over_public_wifi/ > > "A mother and daughter are suing Comcast claiming the cable giant's router > in their home was offering public Wi-Fi without their permission. > > Comcast-supplied routers broadcast an encrypted, private wireless network > for people at home, plus a non-encrypted network called XfinityWiFi that > can be used by nearby subscribers. So if you're passing by a fellow user's > home, you can lock onto their public Wi-Fi, log in using your Comcast > username and password, and use that home's bandwidth. > > However, Toyer Grear, 39, and daughter Joycelyn Harris – who live together > in Alameda County, California – say they never gave Comcast permission to > run a public network from their home cable connection. > > In a lawsuit [PDF] filed in the northern district of the golden state, the > pair accuse the ISP of breaking the Computer Fraud and Abuse Act and two > other laws. > > Grear – a paralegal – and her daughter claim the Xfinity hotspot is an > unauthorized intrusion into their private home, places a "vast" burden on > electricity bills, opens them up to attacks by hackers, and "degrades" > their bandwidth. > > "Comcast does not, however, obtain the customer's authorization prior to > engaging in this use of the customer's equipment and internet service for > public, non-household use," the suit claims. > > "Indeed, without obtaining its customers' authorization for this > additional use of their equipment and resources, over which the customer > has no control, Comcast has externalized the costs of its national Wi-Fi > network onto its customers." > > The plaintiffs are seeking monetary damages for themselves and on behalf > of all Comcast customers nation-wide in their class-action case – the > service was rolled out to 20 million customers this year." > > -- > Earthquake Magnitude: 4.8 > Date: 2014-12-10 22:10:36.800 UTC > Date Local: 2014-12-10 13:10:36 PST > Location: 120km W of Panguna, Papua New Guinea > Latitude: -6.265; Longitude: 154.4004 > Depth: 35 km | e-quake.org > From bugs at debmi.com Thu Dec 11 02:50:59 2014 From: bugs at debmi.com (Mr Bugs) Date: Wed, 10 Dec 2014 21:50:59 -0500 Subject: Comcast thinks it ok to install public wifi in your house Message-ID: Jeroen, Not that I agree with this practice, I specifically got my own modem because of this (and to have it directly attached to a real router) , however they use a separate DOCSIS and 802.11 channel so if would follow that it would be a separate IP tied to comcast corporate and not the subscriber as well as not taking up your bandwidth. The bandwidth issue seems to be the only thing they can imagine people being worried about and when you complain its the only thing they talk about, making sure you know it wont take up any of your speed or quota. From chk at pobox.com Thu Dec 11 03:19:27 2014 From: chk at pobox.com (Harald Koch) Date: Wed, 10 Dec 2014 22:19:27 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: Message-ID: On 10 December 2014 at 21:50, Mr Bugs wrote: > however they use a separate DOCSIS and 802.11 channel so if would follow > that it would be a separate IP tied to comcast corporate and not the > subscriber as well as not taking up your bandwidth. IIRC there are only three non-overlapping channels on 802.11g and six on 802.11n; I can see more networks than that from my basement. I haven't been keeping up with the technology, but in the ancient of days wasn't the uplink side of DOCSIS also a limited-bandwidth, shared resource? -- Harald From streiner at cluebyfour.org Thu Dec 11 03:45:34 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 10 Dec 2014 22:45:34 -0500 (EST) Subject: Charging fee for BGP prefix per /24?! In-Reply-To: References: <000001d01452$3ef37200$bcda5600$@at> Message-ID: On Wed, 10 Dec 2014, Yucong Sun wrote: > It is not the same thing though. In my case, they just say we want you to > buy our IP, if you don't and want use you own Arin allocated IP blocks > through bgp, then we got to charge you anyway! Are they charging per /24 (assuming IPv4 here...), or per prefix? If they are charging per /24, that seems like a great way to encourage customers to find another provider. If they are charging per prefix, that seems like an interesting way to encourage customers to make sure they aggregate their BGP advertisements as much as possible. jms From bugs at debmi.com Thu Dec 11 03:54:58 2014 From: bugs at debmi.com (Mr Bugs) Date: Wed, 10 Dec 2014 22:54:58 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: Message-ID: Comcast is pushing DOCSIS 3.0 heavily, and the channel allocation and configuration in DOCSIS 3.0 is much more flexible, allowing speed configurations by bonding channels. http://en.wikipedia.org/wiki/DOCSIS But the wifi, this is of course making an already crowded and noisy space much worse. I live in a high density area with people that have wifi, and its nearly useless. My devices that can be wired are, my 4G cell is often faster and more reliable than trying to go 2.4ghz 802.11* on the same cell phone. 5ghz is pretty empty, and I'm about to move to all Asus EA-N66 wifi network on 5ghz. I understand what Comcast is trying to do, but I think it should be an opt-in type of thing instead. On Wed, Dec 10, 2014 at 10:19 PM, Harald Koch wrote: > On 10 December 2014 at 21:50, Mr Bugs wrote: > >> however they use a separate DOCSIS and 802.11 channel so if would follow >> that it would be a separate IP tied to comcast corporate and not the >> subscriber as well as not taking up your bandwidth. > > > > IIRC there are only three non-overlapping channels on 802.11g and six on > 802.11n; I can see more networks than that from my basement. > > I haven't been keeping up with the technology, but in the ancient of days > wasn't the uplink side of DOCSIS also a limited-bandwidth, shared resource? > > -- > Harald > > From bedard.phil at gmail.com Thu Dec 11 03:55:33 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 10 Dec 2014 22:55:33 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: Message-ID: <548915b7.12138c0a.2cae.3bbf@mx.google.com> It won't overlap with the one you are using for yourself on the same device. DOCSIS has service flows with different priorities. I don't know if they are allocating specific channels for it or if it's just a different service flow, but either way it is a lower priority and should not cause contention with regular user traffic. Really it is just the power they seem to be complaining about. Phil -----Original Message----- From: "Harald Koch" Sent: ‎12/‎10/‎2014 10:21 PM To: "Mr Bugs" Cc: "NANOG list" Subject: Re: Comcast thinks it ok to install public wifi in your house On 10 December 2014 at 21:50, Mr Bugs wrote: > however they use a separate DOCSIS and 802.11 channel so if would follow > that it would be a separate IP tied to comcast corporate and not the > subscriber as well as not taking up your bandwidth. IIRC there are only three non-overlapping channels on 802.11g and six on 802.11n; I can see more networks than that from my basement. I haven't been keeping up with the technology, but in the ancient of days wasn't the uplink side of DOCSIS also a limited-bandwidth, shared resource? -- Harald From bugs at debmi.com Thu Dec 11 04:16:10 2014 From: bugs at debmi.com (Mr Bugs) Date: Wed, 10 Dec 2014 23:16:10 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548915b7.12138c0a.2cae.3bbf@mx.google.com> References: <548915b7.12138c0a.2cae.3bbf@mx.google.com> Message-ID: The technical aside, you could make it opt in and let people who opted in use the public network free, and charge people not signed up or not even Comcast customers for profit. This way it makes it feel more like building a community to the consumer rather than big biz pulling one over on the little guy. On Wed, Dec 10, 2014 at 10:55 PM, Phil Bedard wrote: > It won't overlap with the one you are using for yourself on the same > device. > > DOCSIS has service flows with different priorities. I don't know if they > are allocating specific channels for it or if it's just a different service > flow, but either way it is a lower priority and should not cause contention > with regular user traffic. > > Really it is just the power they seem to be complaining about. > > Phil > ------------------------------ > From: Harald Koch > Sent: ‎12/‎10/‎2014 10:21 PM > To: Mr Bugs > Cc: NANOG list > Subject: Re: Comcast thinks it ok to install public wifi in your house > > On 10 December 2014 at 21:50, Mr Bugs wrote: > > > however they use a separate DOCSIS and 802.11 channel so if would follow > > that it would be a separate IP tied to comcast corporate and not the > > subscriber as well as not taking up your bandwidth. > > > > IIRC there are only three non-overlapping channels on 802.11g and six on > 802.11n; I can see more networks than that from my basement. > > I haven't been keeping up with the technology, but in the ancient of days > wasn't the uplink side of DOCSIS also a limited-bandwidth, shared resource? > > -- > Harald > From javier at advancedmachines.us Thu Dec 11 04:18:08 2014 From: javier at advancedmachines.us (Javier J) Date: Wed, 10 Dec 2014 23:18:08 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548902D7.60406@mompl.net> References: <548902D7.60406@mompl.net> Message-ID: In analyzing my neighbors who use comcast (I live in a townhouse and can see many access points) my biggest complaint is the the wifi pollution these comcast router/access-points cause. For each neighbor who has comcast HSI, expect to see 3 SSID with different mac showing up. There is the xfinity one, the customer one, and a blank one broadcasting with similar mac on the same channel. So even if you are just minding your business as a comcast customer watching netflix, someone who hooks into your comcast router can not only kill your wifi throughput but streaming content etc on the same channel, but also piss of your neighbors (me) because of the small channel space in the 2.4GHz range. The 2nd problem I have with this is that I'm pretty sure 99.8% of the people who have comcast and have their new routers have no clue they are paying for essentially running a public hotspot for comcast. Even if you still have to register or pay for it, it's available to the general public without these people knowing about it. On Wed, Dec 10, 2014 at 9:35 PM, Jeroen van Aart wrote: > Why am I not surprised? > > Whose fault would it be if your comcast installed public wifi would be > abused to download illegal material or launch a botnet, to name some random > fun one could have on your behalf. :-/ > > (apologies if this was posted already, couldn't find an email about it on > the list) > > http://www.theregister.co.uk/2014/12/10/disgruntled_ > customers_lob_sueball_at_comcast_over_public_wifi/ > > "A mother and daughter are suing Comcast claiming the cable giant's router > in their home was offering public Wi-Fi without their permission. > > Comcast-supplied routers broadcast an encrypted, private wireless network > for people at home, plus a non-encrypted network called XfinityWiFi that > can be used by nearby subscribers. So if you're passing by a fellow user's > home, you can lock onto their public Wi-Fi, log in using your Comcast > username and password, and use that home's bandwidth. > > However, Toyer Grear, 39, and daughter Joycelyn Harris – who live together > in Alameda County, California – say they never gave Comcast permission to > run a public network from their home cable connection. > > In a lawsuit [PDF] filed in the northern district of the golden state, the > pair accuse the ISP of breaking the Computer Fraud and Abuse Act and two > other laws. > > Grear – a paralegal – and her daughter claim the Xfinity hotspot is an > unauthorized intrusion into their private home, places a "vast" burden on > electricity bills, opens them up to attacks by hackers, and "degrades" > their bandwidth. > > "Comcast does not, however, obtain the customer's authorization prior to > engaging in this use of the customer's equipment and internet service for > public, non-household use," the suit claims. > > "Indeed, without obtaining its customers' authorization for this > additional use of their equipment and resources, over which the customer > has no control, Comcast has externalized the costs of its national Wi-Fi > network onto its customers." > > The plaintiffs are seeking monetary damages for themselves and on behalf > of all Comcast customers nation-wide in their class-action case – the > service was rolled out to 20 million customers this year." > > -- > Earthquake Magnitude: 4.8 > Date: 2014-12-10 22:10:36.800 UTC > Date Local: 2014-12-10 13:10:36 PST > Location: 120km W of Panguna, Papua New Guinea > Latitude: -6.265; Longitude: 154.4004 > Depth: 35 km | e-quake.org > From aj at jonesy.com.au Thu Dec 11 04:18:27 2014 From: aj at jonesy.com.au (Andrew Jones) Date: Thu, 11 Dec 2014 15:18:27 +1100 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548915b7.12138c0a.2cae.3bbf@mx.google.com> References: <548915b7.12138c0a.2cae.3bbf@mx.google.com> Message-ID: <15f7bc5639461081857e674104e6defc@jonesy.com.au> It reads to me like it's not a separate Wi-Fi radio on a different channel, but just an additional SSID being broadcast: http://wifi.comcast.com/faqs.html ctrl+f "Does the new Home Hotspot impact my Internet speeds or data usage?" On 11.12.2014 14:55, Phil Bedard wrote: > It won't overlap with the one you are using for yourself on the same > device. > > DOCSIS has service flows with different priorities. I don't know if > they are allocating specific channels for it or if it's just a > different service flow, but either way it is a lower priority and > should not cause contention with regular user traffic. > > Really it is just the power they seem to be complaining about. > > Phil > > -----Original Message----- > From: "Harald Koch" > Sent: ‎12/‎10/‎2014 10:21 PM > To: "Mr Bugs" > Cc: "NANOG list" > Subject: Re: Comcast thinks it ok to install public wifi in your > house > > On 10 December 2014 at 21:50, Mr Bugs wrote: > >> however they use a separate DOCSIS and 802.11 channel so if would >> follow >> that it would be a separate IP tied to comcast corporate and not the >> subscriber as well as not taking up your bandwidth. > > > > IIRC there are only three non-overlapping channels on 802.11g and six > on > 802.11n; I can see more networks than that from my basement. > > I haven't been keeping up with the technology, but in the ancient of > days > wasn't the uplink side of DOCSIS also a limited-bandwidth, shared > resource? From javier at advancedmachines.us Thu Dec 11 04:39:25 2014 From: javier at advancedmachines.us (Javier J) Date: Wed, 10 Dec 2014 23:39:25 -0500 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: References: <5484B40F.3010203@noor.net> <6F2BC9429CDDC6438D1FE460D2258BB401B1994E66@EXCHANGENODE1.ritter.net> <63313FDA-EF90-4677-B4AF-DEACE62B7DD0@fastreturn.net> <10AB04B9CE55DF4AA248C0388F4ED464641E0535@SDLDALPWEMB07.suddenlink.cequel3.com> Message-ID: What about DDOS protection as a service? is that something that is being offered by more than a few vendors? I know of only one that exists through a friend. They basically start advertising your bgp routes, filter out the junk, and send the good traffic back to you. On Wed, Dec 10, 2014 at 8:08 AM, James Braunegg wrote: > Dear All > > > > We use a combination of NSFOCUS hardware (ADS, ADS-m and NTA along with > A10 Hardware) > > > > All of which I highly recommend ! > > > > Kindest Regards > > > James Braunegg > P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 > E: james.braunegg at micron21.com | > ABN: 12 109 977 666 > W: www.micron21.com/ddos-protection< > http://www.micron21.com/ddos-protection> T: @micron21 > > > [Description: Description: Description: Description: M21.jpg] > This message is intended for the addressee named above. It may contain > privileged or confidential information. If you are not the intended > recipient of this message you must not use, copy, distribute or disclose it > to anyone other than the addressee. If you have received this message in > error please return the message to the sender by replying to it and then > delete the message from your computer. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Parrish, Luke > Sent: Wednesday, December 10, 2014 8:08 AM > To: J. Tozo > Cc: nanog > Subject: RE: Carrier-grade DDoS Attack mitigation appliance > > > > Switch to Nemo. > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of J. Tozo > > Sent: Monday, December 08, 2014 3:26 PM > > Cc: nanog > > Subject: Re: Carrier-grade DDoS Attack mitigation appliance > > > > We also evaluating another appliance to put in place of Arbor, their > "support" outside USA its a joke. > > > > On Mon, Dec 8, 2014 at 6:17 PM, Ammar Zuberi wrote: > > > > > Hi, > > > > > > We're currently running the Arbor Peakflow SP with the TMS and it > > > works very well for us. > > > > > > Best Regards, > > > > > > Ammar Zuberi > > > FastReturn, Inc > > > > > > > > > > > > > > > Direct Line: +971 50 394 7299 > > > Email: ammar at fastreturn.net > > > > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to whom they are > addressed. > > > If you have received it by mistake, please let us know by e-mail reply > > > and delete it from your system; you may not copy this message or > > > disclose its contents to anyone. Please note that any views or > > > opinions presented in this email are solely those of the author and do > > > not necessarily represent those of the company. Finally, the recipient > > > should check this email and any attachments for the presence of > > > viruses. The company accepts no liability for any damage caused by any > virus transmitted by this email. > > > > > > > On Dec 8, 2014, at 10:53 PM, Tony McKay > > > wrote: > > > > > > > > Does anyone on list currently use Peakflow SP from Arbor with TMS, > > > > and > > > is it truly a carrier grade DDoS detection and mitigation platform? > > > Anyone have any experience with Plixir? > > > > > > > > Tony McKay > > > > Dir. Of Network Operations > > > > Office: 870.336.3449 > > > > Mobile: 870.243.0058 > > > > -The boundary to your comfort zone fades a little each time you > > > > cross > > > it. Raise your limits by pushing them. > > > > > > > > This electronic mail transmission may contain confidential or > > > > privileged > > > information. If you believe that you have received this message in > > > error, please notify the sender by reply transmission and delete the > > > message without copying or disclosing it. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mohamed > > > > Kamal > > > > Sent: Sunday, December 07, 2014 2:10 PM > > > > To: nanog > > > > Subject: Carrier-grade DDoS Attack mitigation appliance > > > > > > > > > > > > Have anyone tried any DDoS attack mitigation appliance rather than > > > > Arbor > > > PeakFlow TMS? I need it to be carrier-grade in terms of capacity and > > > redundancy, and as far as I know, Arbor is the only product in the > > > market which offers a "clean pipe" volume of traffic, so if the DDoS > > > attack volume is, for example, 1Tbps, they will grant you for example > > > 50Gbps of clean traffic. > > > > > > > > Anyway, I'm open to other suggestions, and open-source products that > > > > can > > > do the same purpose, we have network development team that can work on > this. > > > > > > > > Thanks. > > > > > > > > -- > > > > Mohamed Kamal > > > > Core Network Sr. Engineer > > > > > > > > > > > > > > > > -- > > Grato, > > > > Tozo > > ________________________________ > > > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain proprietary, confidential and/or > legally 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 > received this in error, please contact the sender and delete the material > from all computers. > > > > ________________________________ > From javier at advancedmachines.us Thu Dec 11 04:47:55 2014 From: javier at advancedmachines.us (Javier J) Date: Wed, 10 Dec 2014 23:47:55 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <15f7bc5639461081857e674104e6defc@jonesy.com.au> References: <548915b7.12138c0a.2cae.3bbf@mx.google.com> <15f7bc5639461081857e674104e6defc@jonesy.com.au> Message-ID: The answer is, if someone is using your hotspot, it does use the same radio and channel your ssid is on. On Wed, Dec 10, 2014 at 11:18 PM, Andrew Jones wrote: > It reads to me like it's not a separate Wi-Fi radio on a different > channel, but just an additional SSID being broadcast: > http://wifi.comcast.com/faqs.html > ctrl+f "Does the new Home Hotspot impact my Internet speeds or data usage?" > > > > > On 11.12.2014 14:55, Phil Bedard wrote: > >> It won't overlap with the one you are using for yourself on the same >> device. >> >> DOCSIS has service flows with different priorities. I don't know if >> they are allocating specific channels for it or if it's just a >> different service flow, but either way it is a lower priority and >> should not cause contention with regular user traffic. >> >> Really it is just the power they seem to be complaining about. >> >> Phil >> >> -----Original Message----- >> From: "Harald Koch" >> Sent: ‎12/‎10/‎2014 10:21 PM >> To: "Mr Bugs" >> Cc: "NANOG list" >> Subject: Re: Comcast thinks it ok to install public wifi in your house >> >> On 10 December 2014 at 21:50, Mr Bugs wrote: >> >> however they use a separate DOCSIS and 802.11 channel so if would follow >>> that it would be a separate IP tied to comcast corporate and not the >>> subscriber as well as not taking up your bandwidth. >>> >> >> >> >> IIRC there are only three non-overlapping channels on 802.11g and six on >> 802.11n; I can see more networks than that from my basement. >> >> I haven't been keeping up with the technology, but in the ancient of days >> wasn't the uplink side of DOCSIS also a limited-bandwidth, shared >> resource? >> > > From contact at winterei.se Thu Dec 11 04:53:08 2014 From: contact at winterei.se (Paul S.) Date: Thu, 11 Dec 2014 10:53:08 +0600 Subject: Carrier-grade DDoS Attack mitigation appliance In-Reply-To: References: <5484B40F.3010203@noor.net> <6F2BC9429CDDC6438D1FE460D2258BB401B1994E66@EXCHANGENODE1.ritter.net> <63313FDA-EF90-4677-B4AF-DEACE62B7DD0@fastreturn.net> <10AB04B9CE55DF4AA248C0388F4ED464641E0535@SDLDALPWEMB07.suddenlink.cequel3.com> Message-ID: <54892334.2040107@winterei.se> Tons of such companies exist; BlackLotus/Staminus/Prolexic/Voxility to name a few within the US. Service provided is usually based on proprietary algorithms that may or may not do what you want it to do, though. On 12/11/2014 10:39 AM, Javier J wrote: > What about DDOS protection as a service? is that something that is being > offered by more than a few vendors? I know of only one that exists through > a friend. > > They basically start advertising your bgp routes, filter out the junk, and > send the good traffic back to you. > > On Wed, Dec 10, 2014 at 8:08 AM, James Braunegg > wrote: >> Dear All >> >> >> >> We use a combination of NSFOCUS hardware (ADS, ADS-m and NTA along with >> A10 Hardware) >> >> >> >> All of which I highly recommend ! >> >> >> >> Kindest Regards >> >> >> James Braunegg >> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 >> E: james.braunegg at micron21.com | >> ABN: 12 109 977 666 >> W: www.micron21.com/ddos-protection< >> http://www.micron21.com/ddos-protection> T: @micron21 >> >> >> [Description: Description: Description: Description: M21.jpg] >> This message is intended for the addressee named above. It may contain >> privileged or confidential information. If you are not the intended >> recipient of this message you must not use, copy, distribute or disclose it >> to anyone other than the addressee. If you have received this message in >> error please return the message to the sender by replying to it and then >> delete the message from your computer. >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Parrish, Luke >> Sent: Wednesday, December 10, 2014 8:08 AM >> To: J. Tozo >> Cc: nanog >> Subject: RE: Carrier-grade DDoS Attack mitigation appliance >> >> >> >> Switch to Nemo. >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of J. Tozo >> >> Sent: Monday, December 08, 2014 3:26 PM >> >> Cc: nanog >> >> Subject: Re: Carrier-grade DDoS Attack mitigation appliance >> >> >> >> We also evaluating another appliance to put in place of Arbor, their >> "support" outside USA its a joke. >> >> >> >> On Mon, Dec 8, 2014 at 6:17 PM, Ammar Zuberi wrote: >> >> >> >>> Hi, >>> We're currently running the Arbor Peakflow SP with the TMS and it >>> works very well for us. >>> Best Regards, >>> Ammar Zuberi >>> FastReturn, Inc >>> Direct Line: +971 50 394 7299 >>> Email: ammar at fastreturn.net >>> This email and any files transmitted with it are confidential and >>> intended solely for the use of the individual or entity to whom they are >> addressed. >> >>> If you have received it by mistake, please let us know by e-mail reply >>> and delete it from your system; you may not copy this message or >>> disclose its contents to anyone. Please note that any views or >>> opinions presented in this email are solely those of the author and do >>> not necessarily represent those of the company. Finally, the recipient >>> should check this email and any attachments for the presence of >>> viruses. The company accepts no liability for any damage caused by any >> virus transmitted by this email. >> >>>> On Dec 8, 2014, at 10:53 PM, Tony McKay >>> wrote: >>>> Does anyone on list currently use Peakflow SP from Arbor with TMS, >>>> and >>> is it truly a carrier grade DDoS detection and mitigation platform? >>> Anyone have any experience with Plixir? >>>> Tony McKay >>>> Dir. Of Network Operations >>>> Office: 870.336.3449 >>>> Mobile: 870.243.0058 >>>> -The boundary to your comfort zone fades a little each time you >>>> cross >>> it. Raise your limits by pushing them. >>>> This electronic mail transmission may contain confidential or >>>> privileged >>> information. If you believe that you have received this message in >>> error, please notify the sender by reply transmission and delete the >>> message without copying or disclosing it. >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mohamed >>>> Kamal >>>> Sent: Sunday, December 07, 2014 2:10 PM >>>> To: nanog >>>> Subject: Carrier-grade DDoS Attack mitigation appliance >>>> Have anyone tried any DDoS attack mitigation appliance rather than >>>> Arbor >>> PeakFlow TMS? I need it to be carrier-grade in terms of capacity and >>> redundancy, and as far as I know, Arbor is the only product in the >>> market which offers a "clean pipe" volume of traffic, so if the DDoS >>> attack volume is, for example, 1Tbps, they will grant you for example >>> 50Gbps of clean traffic. >>>> Anyway, I'm open to other suggestions, and open-source products that >>>> can >>> do the same purpose, we have network development team that can work on >> this. >> >>>> Thanks. >>>> -- >>>> Mohamed Kamal >>>> Core Network Sr. Engineer >> >> >> >> >> -- >> >> Grato, >> >> >> >> Tozo >> >> ________________________________ >> >> >> >> The information transmitted is intended only for the person or entity to >> which it is addressed and may contain proprietary, confidential and/or >> legally 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 >> received this in error, please contact the sender and delete the material >> from all computers. >> >> >> >> ________________________________ >> From jra at baylink.com Thu Dec 11 05:11:07 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 11 Dec 2014 00:11:07 -0500 (EST) Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548902D7.60406@mompl.net> Message-ID: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeroen van Aart" > Comcast-supplied routers broadcast an encrypted, private wireless > network for people at home, plus a non-encrypted network called > XfinityWiFi that can be used by nearby subscribers. So if you're passing > by a fellow user's home, you can lock onto their public Wi-Fi, log in > using your Comcast username and password, and use that home's > bandwidth. Bright House/RoadRunner has been doing this in Tampa Bay for a couple years now -- but they only do it on business installs. It's how the Bright House Wifi and CableWifi SSID services are provisioned. Interestingly, they *do* do it with a separate cablemodem and a tee, and a separate high-power access point; it's not built into the cablemodem provisioned for the business customer proper. So space and power *would* be an issue for these users, though I don't know that anyone's complained. As another commenter noted, you do have to be a subscriber for their auth network to recognize you. I will give them their props: I only had to sign in *once*, last year; their auth controller has recognized my MAC address at every spot I've used since. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From gary.buhrmaster at gmail.com Thu Dec 11 05:39:19 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 11 Dec 2014 05:39:19 +0000 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> Message-ID: On Thu, Dec 11, 2014 at 2:25 AM, Randy Bush wrote: >> We are now using ZFS RAIDZ and the question I ask myself is, why >> wasn't I using ZFS years ago? > > because it is not production on linux, Well, it depends on what you mean by "production". Certainly the ZFS on Linux group has said in some forums that it is "production ready", although I would say that their definition is not exactly the same as what I mean by the term. > which i have to use because > freebsd does not have kvm/ganeti. There is bhyve, and virt-manager can support bhyve in later versions (but is disabled by default as I recall). Not exactly the same, of course. > want zfs very very badly. snif. Anyone who really cares about their data wants ZFS. Some just do not yet know that they (should) want it. There is always Illumos/OnmiOS/SmartOS to consider (depending on your particular requirements) which can do ZFS and KVM. From randy at psg.com Thu Dec 11 06:32:29 2014 From: randy at psg.com (Randy Bush) Date: Thu, 11 Dec 2014 15:32:29 +0900 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> Message-ID: <9A19558A-6DC3-4C5D-B7DD-9AF910645EA2@psg.com> zfs and ganeti -- Phones are not computers and suck for email On December 11, 2014 2:39:19 PM GMT+09:00, Gary Buhrmaster wrote: >On Thu, Dec 11, 2014 at 2:25 AM, Randy Bush wrote: >>> We are now using ZFS RAIDZ and the question I ask myself is, why >>> wasn't I using ZFS years ago? >> >> because it is not production on linux, > >Well, it depends on what you mean by >"production". Certainly the ZFS on Linux >group has said in some forums that it is >"production ready", although I would say >that their definition is not exactly the >same as what I mean by the term. > >> which i have to use because >> freebsd does not have kvm/ganeti. > >There is bhyve, and virt-manager can >support bhyve in later versions (but is >disabled by default as I recall). Not >exactly the same, of course. > >> want zfs very very badly. snif. > >Anyone who really cares about their data >wants ZFS. Some just do not yet know >that they (should) want it. > >There is always Illumos/OnmiOS/SmartOS >to consider (depending on your particular >requirements) which can do ZFS and KVM. From jeroen at massar.ch Thu Dec 11 07:08:31 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Thu, 11 Dec 2014 08:08:31 +0100 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548902D7.60406@mompl.net> References: <548902D7.60406@mompl.net> Message-ID: <548942EF.5040107@massar.ch> On 2014-12-11 03:35, Jeroen van Aart wrote: > Grear – a paralegal – and her daughter claim the Xfinity hotspot is an > unauthorized intrusion into their private home, places a "vast" burden > on electricity bills, opens them up to attacks by hackers, and > "degrades" their bandwidth. LibertyGlobal (basically all cable in Europe) calls this "Wi-Free" description here: http://www.upc-cablecom.ch/en/internet/wi-free/ Uses likely the same trick as Comcast has: - separate DOCSIS channel, thus not on your IP/bandwidth[1] - separate SSID (2.4Ghz channel 1 b/g/n + n is what I have seen) - authenticated by user/pass (thus you are tracked) in the LG case though it is opt-out which means that you go to the "MyUPC" or similar page on their website and turn it off. Turning it off does mean one cannot use that service elsewhere though. As in .ch one either has DSL through Swisscom or Cable through UPC (typically cheaper and faster and one has TV anyway) the latter is almost per building available, thus the spread of this "UPC Wi-Free" is pretty big. Check the map at the bottom, it is rather insane, though I think that map renders where their customers are not where it is enabled. I see 4 different ones just from my office with the imac internal antenna... As most people have pre-paid 4G though I wonder how useful it is that these SSIDs are everywhere. Maybe one could see it as a sneak advertising model though. Primarily it will cause wifi-boxes that auto-select channels to move away from channel 1 (which seems to be the primary one to be used) moving away from that channel, thus meaning that other wifi channels get even more crowded. And likely the Wi-Free ones are not used... They btw did announce this 'feature' by advertising it. Of course few people will understand the impacts as their marketing department does not either and claims 'it does not impact you'... Greets, Jeroen [1] = of course if you have crappy connectivity then it becomes crappier if a channel is taken away From joelja at bogus.com Thu Dec 11 07:11:12 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 10 Dec 2014 23:11:12 -0800 Subject: Charging fee for BGP prefix per /24?! In-Reply-To: References: <000001d01452$3ef37200$bcda5600$@at> Message-ID: <54894390.4060105@bogus.com> On 12/10/14 7:45 PM, Justin M. Streiner wrote: > On Wed, 10 Dec 2014, Yucong Sun wrote: > >> It is not the same thing though. In my case, they just say we want >> you to >> buy our IP, if you don't and want use you own Arin allocated IP blocks >> through bgp, then we got to charge you anyway! > > Are they charging per /24 (assuming IPv4 here...), or per prefix? > > If they are charging per /24, that seems like a great way to encourage > customers to find another provider. > > If they are charging per prefix, that seems like an interesting way to > encourage customers to make sure they aggregate their BGP > advertisements as much as possible. > ISPs in my experience have a fee schedule supported by a model which allows them to recover their expenses plus a nominal profit. If the model doesn't work, in the long run that is a problem that solves itself. At the right scale I have productive leverage against the profit side of that number and also what line items the expenses are lodged against. below that I'm a retail customer and I pick from the best options available to me. > jms > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 221 bytes Desc: OpenPGP digital signature URL: From tom at ninjabadger.net Thu Dec 11 10:16:18 2014 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 11 Dec 2014 10:16:18 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548942EF.5040107@massar.ch> References: <548902D7.60406@mompl.net> <548942EF.5040107@massar.ch> Message-ID: <54896EF2.8030500@ninjabadger.net> On 11/12/14 07:08, Jeroen Massar wrote: > in the LG case though it is opt-out which means that you go to the > "MyUPC" or similar page on their website and turn it off. Turning it off > does mean one cannot use that service elsewhere though. AFAIK, British Telecom do something similar here in the UK. Contribute or no access for you. -- Tom From rs at seastrom.com Thu Dec 11 11:36:31 2014 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 11 Dec 2014 06:36:31 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: (Gary Buhrmaster's message of "Thu, 11 Dec 2014 05:39:19 +0000") References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> Message-ID: <867fxy2zb4.fsf@valhalla.seastrom.com> Gary Buhrmaster writes: > There is always Illumos/OnmiOS/SmartOS > to consider (depending on your particular > requirements) which can do ZFS and KVM. 2.5-year SmartOS user here. Generally speaking pretty good though I have my list of gripes like everything else I touch. -r From hhoffman at ip-solutions.net Thu Dec 11 12:44:13 2014 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Thu, 11 Dec 2014 07:44:13 -0500 Subject: Comcast thinks it ok to install public wifi in your house Message-ID: <20141211124417.A2FEE201CE@pb-smtp1.pobox.com> Or, ya know you could just buy your own cable modem and separate AP. Cheaper then renting from Comcast and gives you the control :-) Cheers, Harry On Dec 10, 2014 9:35 PM, Jeroen van Aart wrote: > > Why am I not surprised? > > Whose fault would it be if your comcast installed public wifi would be > abused to download illegal material or launch a botnet, to name some > random fun one could have on your behalf. :-/ > > (apologies if this was posted already, couldn't find an email about it > on the list) > > http://www.theregister.co.uk/2014/12/10/disgruntled_customers_lob_sueball_at_comcast_over_public_wifi/ > > "A mother and daughter are suing Comcast claiming the cable giant's > router in their home was offering public Wi-Fi without their permission. > > Comcast-supplied routers broadcast an encrypted, private wireless > network for people at home, plus a non-encrypted network called > XfinityWiFi that can be used by nearby subscribers. So if you're passing > by a fellow user's home, you can lock onto their public Wi-Fi, log in > using your Comcast username and password, and use that home's bandwidth. > > However, Toyer Grear, 39, and daughter Joycelyn Harris – who live > together in Alameda County, California – say they never gave Comcast > permission to run a public network from their home cable connection. > > In a lawsuit [PDF] filed in the northern district of the golden state, > the pair accuse the ISP of breaking the Computer Fraud and Abuse Act and > two other laws. > > Grear – a paralegal – and her daughter claim the Xfinity hotspot is an > unauthorized intrusion into their private home, places a "vast" burden > on electricity bills, opens them up to attacks by hackers, and > "degrades" their bandwidth. > > "Comcast does not, however, obtain the customer's authorization prior to > engaging in this use of the customer's equipment and internet service > for public, non-household use," the suit claims. > > "Indeed, without obtaining its customers' authorization for this > additional use of their equipment and resources, over which the customer > has no control, Comcast has externalized the costs of its national Wi-Fi > network onto its customers." > > The plaintiffs are seeking monetary damages for themselves and on behalf > of all Comcast customers nation-wide in their class-action case – the > service was rolled out to 20 million customers this year." > > -- > Earthquake Magnitude: 4.8 > Date: 2014-12-10  22:10:36.800 UTC > Date Local: 2014-12-10 13:10:36 PST > Location: 120km W of Panguna, Papua New Guinea > Latitude: -6.265; Longitude: 154.4004 > Depth: 35 km | e-quake.org From bill at herrin.us Thu Dec 11 13:10:24 2014 From: bill at herrin.us (William Herrin) Date: Thu, 11 Dec 2014 08:10:24 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548902D7.60406@mompl.net> References: <548902D7.60406@mompl.net> Message-ID: On Wed, Dec 10, 2014 at 9:35 PM, Jeroen van Aart wrote: > Whose fault would it be if your comcast installed public wifi would be > abused to download illegal material or launch a botnet, to name some random > fun one could have on your behalf. :-/ Doesn't work that way. Separate authenticated channel. Presents differently from you with a different IP address out on the Internet. What Comcast is stealing is electricity. Pennies per customer times a boatload of customers. theft n. the generic term for all crimes in which a person intentionally and fraudulently takes personal property of another without permission or consent and with the intent to convert it to the taker's use (including potential sale). In many states, if the value of the property taken is low (for example, less than $500) the crime is "petty theft," Unless of course the knucklehead jurisdiction passed a law to allow it. I'm betting they didn't. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From khelms at zcorum.com Thu Dec 11 13:17:19 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 11 Dec 2014 08:17:19 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> Message-ID: Not a law, it's in their updated terms and conditions that no one reads. On Dec 11, 2014 8:12 AM, "William Herrin" wrote: > On Wed, Dec 10, 2014 at 9:35 PM, Jeroen van Aart wrote: > > Whose fault would it be if your comcast installed public wifi would be > > abused to download illegal material or launch a botnet, to name some > random > > fun one could have on your behalf. :-/ > > Doesn't work that way. Separate authenticated channel. Presents > differently from you with a different IP address out on the Internet. > > What Comcast is stealing is electricity. Pennies per customer times a > boatload of customers. > > theft n. the generic term for all crimes in which a person > intentionally and fraudulently takes personal property of another > without permission or consent and with the intent to convert it to the > taker's use (including potential sale). In many states, if the value > of the property taken is low (for example, less than $500) the crime > is "petty theft," > > Unless of course the knucklehead jurisdiction passed a law to allow > it. I'm betting they didn't. > > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > May I solve your unusual networking challenges? > From paradox at nac.net Thu Dec 11 13:53:58 2014 From: paradox at nac.net (Ryan Pavely) Date: Thu, 11 Dec 2014 08:53:58 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548902D7.60406@mompl.net> References: <548902D7.60406@mompl.net> Message-ID: <5489A1F6.7080508@nac.net> http://bgr.com/2014/05/12/cablevision-optimum-modem-wifi-hotspots/ I thought cablevision has been doing this for years. I had a higher level tech at mi casa within the last two years and he suggested their goal was to get enough coverage to start offering CV voip cell phones. "pay a little less, for not guaranteed coverage' Ryan Pavely Net Access http://www.nac.net/ On 12/10/2014 9:35 PM, Jeroen van Aart wrote: > Why am I not surprised? > > Whose fault would it be if your comcast installed public wifi would be abused to download illegal material or launch a botnet, to name some random fun one could have on your behalf. :-/ > > (apologies if this was posted already, couldn't find an email about it on the list) > > http://www.theregister.co.uk/2014/12/10/disgruntled_customers_lob_sueball_at_comcast_over_public_wifi/ > > "A mother and daughter are suing Comcast claiming the cable giant's router in their home was offering public Wi-Fi without their permission. > > Comcast-supplied routers broadcast an encrypted, private wireless network for people at home, plus a non-encrypted network called XfinityWiFi that can be used by nearby subscribers. So if you're passing by a fellow user's home, you can lock onto their public Wi-Fi, log in using your Comcast username and password, and use that home's bandwidth. > > However, Toyer Grear, 39, and daughter Joycelyn Harris – who live together in Alameda County, California – say they never gave Comcast permission to run a public network from their home cable connection. > > In a lawsuit [PDF] filed in the northern district of the golden state, the pair accuse the ISP of breaking the Computer Fraud and Abuse Act and two other laws. > > Grear – a paralegal – and her daughter claim the Xfinity hotspot is an unauthorized intrusion into their private home, places a "vast" burden on electricity bills, opens them up to attacks by hackers, and "degrades" their bandwidth. > > "Comcast does not, however, obtain the customer's authorization prior to engaging in this use of the customer's equipment and internet service for public, non-household use," the suit claims. > > "Indeed, without obtaining its customers' authorization for this additional use of their equipment and resources, over which the customer has no control, Comcast has externalized the costs of its national Wi-Fi network onto its customers." > > The plaintiffs are seeking monetary damages for themselves and on behalf of all Comcast customers nation-wide in their class-action case – the service was rolled out to 20 million customers this year." > From khelms at zcorum.com Thu Dec 11 14:02:29 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 11 Dec 2014 09:02:29 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <5489A1F6.7080508@nac.net> References: <548902D7.60406@mompl.net> <5489A1F6.7080508@nac.net> Message-ID: All of the members of the CableWiFi consortium have been. Bright House Networks, Cox Communications, Optimum, Time Warner Cable and Comcast. http://www.cablewifi.com/ Liberty Global, the largest MSO, also does it and this year announced an agreement with Comcast to allow roaming on each other's WiFi networks, though that is not extended to the other members of CableWiFi at this time. http://corporate.comcast.com/news-information/news-feed/comcast-and-liberty-global-announce-agreement-to-connect-u-s-and-european-wi-fi-networks Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Dec 11, 2014 at 8:53 AM, Ryan Pavely wrote: > http://bgr.com/2014/05/12/cablevision-optimum-modem-wifi-hotspots/ > > I thought cablevision has been doing this for years. > > I had a higher level tech at mi casa within the last two years and he > suggested their goal was to get enough coverage to start offering CV voip > cell phones. "pay a little less, for not guaranteed coverage' > > > > Ryan Pavely > Net Access > http://www.nac.net/ > > On 12/10/2014 9:35 PM, Jeroen van Aart wrote: > >> Why am I not surprised? >> >> Whose fault would it be if your comcast installed public wifi would be >> abused to download illegal material or launch a botnet, to name some random >> fun one could have on your behalf. :-/ >> >> (apologies if this was posted already, couldn't find an email about it on >> the list) >> >> http://www.theregister.co.uk/2014/12/10/disgruntled_ >> customers_lob_sueball_at_comcast_over_public_wifi/ >> >> "A mother and daughter are suing Comcast claiming the cable giant's >> router in their home was offering public Wi-Fi without their permission. >> >> Comcast-supplied routers broadcast an encrypted, private wireless network >> for people at home, plus a non-encrypted network called XfinityWiFi that >> can be used by nearby subscribers. So if you're passing by a fellow user's >> home, you can lock onto their public Wi-Fi, log in using your Comcast >> username and password, and use that home's bandwidth. >> >> However, Toyer Grear, 39, and daughter Joycelyn Harris – who live >> together in Alameda County, California – say they never gave Comcast >> permission to run a public network from their home cable connection. >> >> In a lawsuit [PDF] filed in the northern district of the golden state, >> the pair accuse the ISP of breaking the Computer Fraud and Abuse Act and >> two other laws. >> >> Grear – a paralegal – and her daughter claim the Xfinity hotspot is an >> unauthorized intrusion into their private home, places a "vast" burden on >> electricity bills, opens them up to attacks by hackers, and "degrades" >> their bandwidth. >> >> "Comcast does not, however, obtain the customer's authorization prior to >> engaging in this use of the customer's equipment and internet service for >> public, non-household use," the suit claims. >> >> "Indeed, without obtaining its customers' authorization for this >> additional use of their equipment and resources, over which the customer >> has no control, Comcast has externalized the costs of its national Wi-Fi >> network onto its customers." >> >> The plaintiffs are seeking monetary damages for themselves and on behalf >> of all Comcast customers nation-wide in their class-action case – the >> service was rolled out to 20 million customers this year." >> >> > From tshaw at oitc.com Thu Dec 11 14:23:22 2014 From: tshaw at oitc.com (TR Shaw) Date: Thu, 11 Dec 2014 09:23:22 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <5489A1F6.7080508@nac.net> Message-ID: <74902ECB-07D6-442E-86C6-609717EB290C@oitc.com> Seems to me that they (Bright House Networks, Cox Communications, Optimum, Time Warner Cable and Comcast) are effectively operating a business out of your house and without a business license. I am sure that this is illegal in many towns and many towns would like the revenue. In fact does this put the homeowner at risk since they are effectively supporting a business running out of their house? Tom On Dec 11, 2014, at 9:02 AM, Scott Helms wrote: > All of the members of the CableWiFi consortium have been. > > Bright House Networks, Cox Communications, Optimum, Time Warner Cable and > Comcast. > > http://www.cablewifi.com/ > > Liberty Global, the largest MSO, also does it and this year announced an > agreement with Comcast to allow roaming on each other's WiFi networks, > though that is not extended to the other members of CableWiFi at this time. > > http://corporate.comcast.com/news-information/news-feed/comcast-and-liberty-global-announce-agreement-to-connect-u-s-and-european-wi-fi-networks > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Dec 11, 2014 at 8:53 AM, Ryan Pavely wrote: > >> http://bgr.com/2014/05/12/cablevision-optimum-modem-wifi-hotspots/ >> >> I thought cablevision has been doing this for years. >> >> I had a higher level tech at mi casa within the last two years and he >> suggested their goal was to get enough coverage to start offering CV voip >> cell phones. "pay a little less, for not guaranteed coverage' >> >> >> >> Ryan Pavely >> Net Access >> http://www.nac.net/ >> >> On 12/10/2014 9:35 PM, Jeroen van Aart wrote: >> >>> Why am I not surprised? >>> >>> Whose fault would it be if your comcast installed public wifi would be >>> abused to download illegal material or launch a botnet, to name some random >>> fun one could have on your behalf. :-/ >>> >>> (apologies if this was posted already, couldn't find an email about it on >>> the list) >>> >>> http://www.theregister.co.uk/2014/12/10/disgruntled_ >>> customers_lob_sueball_at_comcast_over_public_wifi/ >>> >>> "A mother and daughter are suing Comcast claiming the cable giant's >>> router in their home was offering public Wi-Fi without their permission. >>> >>> Comcast-supplied routers broadcast an encrypted, private wireless network >>> for people at home, plus a non-encrypted network called XfinityWiFi that >>> can be used by nearby subscribers. So if you're passing by a fellow user's >>> home, you can lock onto their public Wi-Fi, log in using your Comcast >>> username and password, and use that home's bandwidth. >>> >>> However, Toyer Grear, 39, and daughter Joycelyn Harris – who live >>> together in Alameda County, California – say they never gave Comcast >>> permission to run a public network from their home cable connection. >>> >>> In a lawsuit [PDF] filed in the northern district of the golden state, >>> the pair accuse the ISP of breaking the Computer Fraud and Abuse Act and >>> two other laws. >>> >>> Grear – a paralegal – and her daughter claim the Xfinity hotspot is an >>> unauthorized intrusion into their private home, places a "vast" burden on >>> electricity bills, opens them up to attacks by hackers, and "degrades" >>> their bandwidth. >>> >>> "Comcast does not, however, obtain the customer's authorization prior to >>> engaging in this use of the customer's equipment and internet service for >>> public, non-household use," the suit claims. >>> >>> "Indeed, without obtaining its customers' authorization for this >>> additional use of their equipment and resources, over which the customer >>> has no control, Comcast has externalized the costs of its national Wi-Fi >>> network onto its customers." >>> >>> The plaintiffs are seeking monetary damages for themselves and on behalf >>> of all Comcast customers nation-wide in their class-action case – the >>> service was rolled out to 20 million customers this year." >>> >>> >> From Valdis.Kletnieks at vt.edu Thu Dec 11 14:24:10 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 11 Dec 2014 09:24:10 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: Your message of "Thu, 11 Dec 2014 00:11:07 -0500." <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> Message-ID: <30585.1418307850@turing-police.cc.vt.edu> On Thu, 11 Dec 2014 00:11:07 -0500, Jay Ashworth said: > I will give them their props: I only had to sign in *once*, last year; > their auth controller has recognized my MAC address at every spot I've > used since. Actually, that's sort of scary if you think about it too hard. Shared-secret authentication has its flaws, but it still beats shared-nonsecret auth. I really hope it's something on your laptop other than the mac address.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From john-nanog at peachfamily.net Thu Dec 11 14:30:47 2014 From: john-nanog at peachfamily.net (John Peach) Date: Thu, 11 Dec 2014 09:30:47 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <30585.1418307850@turing-police.cc.vt.edu> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> Message-ID: <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> On Thu, 11 Dec 2014 09:24:10 -0500 Valdis.Kletnieks at vt.edu wrote: > On Thu, 11 Dec 2014 00:11:07 -0500, Jay Ashworth said: > > I will give them their props: I only had to sign in *once*, last > > year; their auth controller has recognized my MAC address at every > > spot I've used since. > > Actually, that's sort of scary if you think about it too hard. > Shared-secret authentication has its flaws, but it still beats > shared-nonsecret auth. > > I really hope it's something on your laptop other than the mac > address.... It's not - Cablevision allow you to register devices via their website.... by mac address. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From khelms at zcorum.com Thu Dec 11 14:33:14 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 11 Dec 2014 09:33:14 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <74902ECB-07D6-442E-86C6-609717EB290C@oitc.com> References: <548902D7.60406@mompl.net> <5489A1F6.7080508@nac.net> <74902ECB-07D6-442E-86C6-609717EB290C@oitc.com> Message-ID: Not really, this is much more like the mesh networks that have been put in place by lots of WISPs where every customer is also a relay. It's also comparable to pico cells that many of the LTE operators use to extend coverage. http://en.wikipedia.org/wiki/Mesh_networking http://en.wikipedia.org/wiki/Picocell https://wirelesstelecom.wordpress.com/tag/picocell/ Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Dec 11, 2014 at 9:23 AM, TR Shaw wrote: > Seems to me that they (Bright House Networks, Cox Communications, Optimum, > Time Warner Cable and Comcast) are effectively operating a business out of > your house and without a business license. I am sure that this is illegal > in many towns and many towns would like the revenue. > > In fact does this put the homeowner at risk since they are effectively > supporting a business running out of their house? > > Tom > > On Dec 11, 2014, at 9:02 AM, Scott Helms wrote: > > > All of the members of the CableWiFi consortium have been. > > > > Bright House Networks, Cox Communications, Optimum, Time Warner Cable and > > Comcast. > > > > http://www.cablewifi.com/ > > > > Liberty Global, the largest MSO, also does it and this year announced an > > agreement with Comcast to allow roaming on each other's WiFi networks, > > though that is not extended to the other members of CableWiFi at this > time. > > > > > http://corporate.comcast.com/news-information/news-feed/comcast-and-liberty-global-announce-agreement-to-connect-u-s-and-european-wi-fi-networks > > > > > > Scott Helms > > Vice President of Technology > > ZCorum > > (678) 507-5000 > > -------------------------------- > > http://twitter.com/kscotthelms > > -------------------------------- > > > > On Thu, Dec 11, 2014 at 8:53 AM, Ryan Pavely wrote: > > > >> http://bgr.com/2014/05/12/cablevision-optimum-modem-wifi-hotspots/ > >> > >> I thought cablevision has been doing this for years. > >> > >> I had a higher level tech at mi casa within the last two years and he > >> suggested their goal was to get enough coverage to start offering CV > voip > >> cell phones. "pay a little less, for not guaranteed coverage' > >> > >> > >> > >> Ryan Pavely > >> Net Access > >> http://www.nac.net/ > >> > >> On 12/10/2014 9:35 PM, Jeroen van Aart wrote: > >> > >>> Why am I not surprised? > >>> > >>> Whose fault would it be if your comcast installed public wifi would be > >>> abused to download illegal material or launch a botnet, to name some > random > >>> fun one could have on your behalf. :-/ > >>> > >>> (apologies if this was posted already, couldn't find an email about it > on > >>> the list) > >>> > >>> http://www.theregister.co.uk/2014/12/10/disgruntled_ > >>> customers_lob_sueball_at_comcast_over_public_wifi/ > >>> > >>> "A mother and daughter are suing Comcast claiming the cable giant's > >>> router in their home was offering public Wi-Fi without their > permission. > >>> > >>> Comcast-supplied routers broadcast an encrypted, private wireless > network > >>> for people at home, plus a non-encrypted network called XfinityWiFi > that > >>> can be used by nearby subscribers. So if you're passing by a fellow > user's > >>> home, you can lock onto their public Wi-Fi, log in using your Comcast > >>> username and password, and use that home's bandwidth. > >>> > >>> However, Toyer Grear, 39, and daughter Joycelyn Harris – who live > >>> together in Alameda County, California – say they never gave Comcast > >>> permission to run a public network from their home cable connection. > >>> > >>> In a lawsuit [PDF] filed in the northern district of the golden state, > >>> the pair accuse the ISP of breaking the Computer Fraud and Abuse Act > and > >>> two other laws. > >>> > >>> Grear – a paralegal – and her daughter claim the Xfinity hotspot is an > >>> unauthorized intrusion into their private home, places a "vast" burden > on > >>> electricity bills, opens them up to attacks by hackers, and "degrades" > >>> their bandwidth. > >>> > >>> "Comcast does not, however, obtain the customer's authorization prior > to > >>> engaging in this use of the customer's equipment and internet service > for > >>> public, non-household use," the suit claims. > >>> > >>> "Indeed, without obtaining its customers' authorization for this > >>> additional use of their equipment and resources, over which the > customer > >>> has no control, Comcast has externalized the costs of its national > Wi-Fi > >>> network onto its customers." > >>> > >>> The plaintiffs are seeking monetary damages for themselves and on > behalf > >>> of all Comcast customers nation-wide in their class-action case – the > >>> service was rolled out to 20 million customers this year." > >>> > >>> > >> > > From khelms at zcorum.com Thu Dec 11 14:34:46 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 11 Dec 2014 09:34:46 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <30585.1418307850@turing-police.cc.vt.edu> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> Message-ID: It's very scary, and something I'm doing a paper on. It _is_ just MAC recognition, at least until you try and use a MAC address that's already active somewhere else. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Dec 11, 2014 at 9:24 AM, wrote: > On Thu, 11 Dec 2014 00:11:07 -0500, Jay Ashworth said: > > I will give them their props: I only had to sign in *once*, last year; > > their auth controller has recognized my MAC address at every spot I've > > used since. > > Actually, that's sort of scary if you think about it too hard. > Shared-secret > authentication has its flaws, but it still beats shared-nonsecret auth. > > I really hope it's something on your laptop other than the mac address.... > From khelms at zcorum.com Thu Dec 11 14:37:22 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 11 Dec 2014 09:37:22 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> Message-ID: It is, you only have to log in once and then it remembers your MAC address. Harvesting usable MAC addresses is as trivial as putting up an open access point with the SSIDs xfinitywifi and CableWifi and recording the MAC addresses that connect to it. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Dec 11, 2014 at 9:30 AM, John Peach wrote: > On Thu, 11 Dec 2014 09:24:10 -0500 > Valdis.Kletnieks at vt.edu wrote: > > > On Thu, 11 Dec 2014 00:11:07 -0500, Jay Ashworth said: > > > I will give them their props: I only had to sign in *once*, last > > > year; their auth controller has recognized my MAC address at every > > > spot I've used since. > > > > Actually, that's sort of scary if you think about it too hard. > > Shared-secret authentication has its flaws, but it still beats > > shared-nonsecret auth. > > > > I really hope it's something on your laptop other than the mac > > address.... > > It's not - Cablevision allow you to register devices via their > website.... by mac address. > From john-nanog at peachfamily.net Thu Dec 11 14:46:15 2014 From: john-nanog at peachfamily.net (John Peach) Date: Thu, 11 Dec 2014 09:46:15 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> Message-ID: <20141211094616.1b51d373@jpeach-desktop.anbg.mssm.edu> On Thu, 11 Dec 2014 09:37:22 -0500 Scott Helms wrote: > It is, you only have to log in once and then it remembers your MAC > address. Harvesting usable MAC addresses is as trivial as putting up > an open access point with the SSIDs xfinitywifi and CableWifi and > recording the MAC addresses that connect to it. I was just pointing out that you don't even need to login with the device. Cablevision allow you to register a MAC address on their website. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Dec 11, 2014 at 9:30 AM, John Peach > wrote: > > > On Thu, 11 Dec 2014 09:24:10 -0500 > > Valdis.Kletnieks at vt.edu wrote: > > > > > On Thu, 11 Dec 2014 00:11:07 -0500, Jay Ashworth said: > > > > I will give them their props: I only had to sign in *once*, last > > > > year; their auth controller has recognized my MAC address at > > > > every spot I've used since. > > > > > > Actually, that's sort of scary if you think about it too hard. > > > Shared-secret authentication has its flaws, but it still beats > > > shared-nonsecret auth. > > > > > > I really hope it's something on your laptop other than the mac > > > address.... > > > > It's not - Cablevision allow you to register devices via their > > website.... by mac address. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From khelms at zcorum.com Thu Dec 11 14:48:58 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 11 Dec 2014 09:48:58 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <20141211094616.1b51d373@jpeach-desktop.anbg.mssm.edu> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <20141211094616.1b51d373@jpeach-desktop.anbg.mssm.edu> Message-ID: John, My apologies, I misread your email :) Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Dec 11, 2014 at 9:46 AM, John Peach wrote: > On Thu, 11 Dec 2014 09:37:22 -0500 > Scott Helms wrote: > > > It is, you only have to log in once and then it remembers your MAC > > address. Harvesting usable MAC addresses is as trivial as putting up > > an open access point with the SSIDs xfinitywifi and CableWifi and > > recording the MAC addresses that connect to it. > > I was just pointing out that you don't even need to login with the > device. Cablevision allow you to register a MAC address on their > website. > > > > > > > > Scott Helms > > Vice President of Technology > > ZCorum > > (678) 507-5000 > > -------------------------------- > > http://twitter.com/kscotthelms > > -------------------------------- > > > > On Thu, Dec 11, 2014 at 9:30 AM, John Peach > > wrote: > > > > > On Thu, 11 Dec 2014 09:24:10 -0500 > > > Valdis.Kletnieks at vt.edu wrote: > > > > > > > On Thu, 11 Dec 2014 00:11:07 -0500, Jay Ashworth said: > > > > > I will give them their props: I only had to sign in *once*, last > > > > > year; their auth controller has recognized my MAC address at > > > > > every spot I've used since. > > > > > > > > Actually, that's sort of scary if you think about it too hard. > > > > Shared-secret authentication has its flaws, but it still beats > > > > shared-nonsecret auth. > > > > > > > > I really hope it's something on your laptop other than the mac > > > > address.... > > > > > > It's not - Cablevision allow you to register devices via their > > > website.... by mac address. > > > > From bob at FiberInternetCenter.com Thu Dec 11 15:30:00 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 11 Dec 2014 07:30:00 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> Message-ID: <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> I think it's more than AC power issue....who knows what strength level they program that SSID to work at ? More wifi signal you are exposed to without your knowledge and more...read on. I have Comcast & ATT internet at home...and I have noticed an xfinitywifi ssid at full strength. This tread brought it to my attention. It was not there when installed. Over the last few months, I have noticed on many occasions my attached storage device flashing as it's accessed but never found anything on my LAN using it. So I removed it from my LAN. In addition, I have the blast service 100 meg/sec.. Sites slow down often. The modem's cpu processor and cache is not used just for me as part of my service ! Gee, before bandwidth considerations, that's a bottle neck, isn't it ? Docsis is limited to bandwidth in neighborhoods based on headend and street plant configurations. Why would I, while paying for service want to encourage others to drop in my neighborhood or house to use the wifi - the cpu bandwidth of the wireless device and it's cache ? If you tell me these Docsis modems can do 200 meg/sec I would be surprised. This would explain why I see poor downloads of on-demand movies on directTV. BTW, I founded ISP channel ...the cable modem company before ATT created @Home to compete. So I am very aware of the network devices limitations, cable plant wiring structures and headend physical limitations. However, I have not studied these new Docsis modems. So how do I shut the xfinitywifi SSID? Thank You Bob Evans CTO > On Thu, 11 Dec 2014 09:24:10 -0500 > Valdis.Kletnieks at vt.edu wrote: > >> On Thu, 11 Dec 2014 00:11:07 -0500, Jay Ashworth said: >> > I will give them their props: I only had to sign in *once*, last >> > year; their auth controller has recognized my MAC address at every >> > spot I've used since. >> >> Actually, that's sort of scary if you think about it too hard. >> Shared-secret authentication has its flaws, but it still beats >> shared-nonsecret auth. >> >> I really hope it's something on your laptop other than the mac >> address.... > > It's not - Cablevision allow you to register devices via their > website.... by mac address. > From baconzombie at gmail.com Thu Dec 11 15:55:40 2014 From: baconzombie at gmail.com (Bacon Zombie) Date: Thu, 11 Dec 2014 16:55:40 +0100 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <20141211094616.1b51d373@jpeach-desktop.anbg.mssm.edu> Message-ID: BT in the UK did the same thing a few years ago with a silent firmware upgrade. On 11 Dec 2014 15:51, "Scott Helms" wrote: > John, > > My apologies, I misread your email :) > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Dec 11, 2014 at 9:46 AM, John Peach > wrote: > > > On Thu, 11 Dec 2014 09:37:22 -0500 > > Scott Helms wrote: > > > > > It is, you only have to log in once and then it remembers your MAC > > > address. Harvesting usable MAC addresses is as trivial as putting up > > > an open access point with the SSIDs xfinitywifi and CableWifi and > > > recording the MAC addresses that connect to it. > > > > I was just pointing out that you don't even need to login with the > > device. Cablevision allow you to register a MAC address on their > > website. > > > > > > > > > > > > > Scott Helms > > > Vice President of Technology > > > ZCorum > > > (678) 507-5000 > > > -------------------------------- > > > http://twitter.com/kscotthelms > > > -------------------------------- > > > > > > On Thu, Dec 11, 2014 at 9:30 AM, John Peach > > > wrote: > > > > > > > On Thu, 11 Dec 2014 09:24:10 -0500 > > > > Valdis.Kletnieks at vt.edu wrote: > > > > > > > > > On Thu, 11 Dec 2014 00:11:07 -0500, Jay Ashworth said: > > > > > > I will give them their props: I only had to sign in *once*, last > > > > > > year; their auth controller has recognized my MAC address at > > > > > > every spot I've used since. > > > > > > > > > > Actually, that's sort of scary if you think about it too hard. > > > > > Shared-secret authentication has its flaws, but it still beats > > > > > shared-nonsecret auth. > > > > > > > > > > I really hope it's something on your laptop other than the mac > > > > > address.... > > > > > > > > It's not - Cablevision allow you to register devices via their > > > > website.... by mac address. > > > > > > > From Valdis.Kletnieks at vt.edu Thu Dec 11 16:05:12 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 11 Dec 2014 11:05:12 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: Your message of "Thu, 11 Dec 2014 07:30:00 -0800." <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> Message-ID: <3677.1418313912@turing-police.cc.vt.edu> On Thu, 11 Dec 2014 07:30:00 -0800, "Bob Evans" said: > However, I have not studied these new Docsis modems. So how do I shut the > xfinitywifi SSID? Motorola Surfboard, Netgear WNDR3800, reflash the 3800 with cerowrt. Done. And you get less bufferbloat in the bargain. (Though the 3800 runs into CPU limits around 60mbits/sec - doesn't bother me, as my 20/5 plan is plenty for me except when my cats decide to start binging on funny people videos. But if you've got leads on gear that will still have CPU headroom in the 100-200mbit range, contact Dave Taht. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From baconzombie at gmail.com Thu Dec 11 16:06:25 2014 From: baconzombie at gmail.com (Bacon Zombie) Date: Thu, 11 Dec 2014 17:06:25 +0100 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> Message-ID: Are you running ZFS and RAIDZ on Linux or BSD? On 10 Dec 2014 23:21, "Javier J" wrote: > I'm just going to chime in here since I recently had to deal with bit-rot > affecting a 6TB linux raid5 setup using mdadm (6x 1TB disks) > > We couldn't rebuild because of 5 URE sectors on one of the other disks in > the array after a power / ups issue rebooted our storage box. > > We are now using ZFS RAIDZ and the question I ask myself is, why wasn't I > using ZFS years ago? > > +1 for ZFS and RAIDZ > > > > On Wed, Dec 10, 2014 at 8:40 AM, Rob Seastrom wrote: > > > > > The subject is drifting a bit but I'm going with the flow here: > > > > Seth Mos writes: > > > > > Raid10 is the only valid raid format these days. With the disks as big > > > as they get these days it's possible for silent corruption. > > > > How do you detect it? A man with two watches is never sure what time it > > is. > > > > Unless you have a filesystem that detects and corrects silent > > corruption, you're still hosed, you just don't know it yet. RAID10 > > between the disks in and of itself doesn't help. > > > > > And with 4TB+ disks that is a real thing. Raid 6 is ok, if you accept > > > rebuilds that take a week, literally. Although the rebuild rate on our > > > 11 disk raid 6 SSD array (2TB) is less then a day. > > > > I did a rebuild on a RAIDZ2 vdev recently (made out of 4tb WD reds). > > It took nowhere near a day let alone a week. Theoretically takes 8-11 > > hours if the vdev is completely full, proportionately less if it's > > not, and I was at about 2/3 in use. > > > > -r > > > > > From jeffshultz at sctcweb.com Thu Dec 11 16:30:32 2014 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Thu, 11 Dec 2014 08:30:32 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <3677.1418313912@turing-police.cc.vt.edu> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> <3677.1418313912@turing-police.cc.vt.edu> Message-ID: <5489C6A8.8020807@sctcweb.com> Or you can just call Comcast and ask them to turn it off. Or you could in the past. My in-laws did that when they got their new equipment. I don't know exactly how they found out it was going to be done - possibly inside info due to a relative working for Comcast. On 12/11/2014 8:05 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 11 Dec 2014 07:30:00 -0800, "Bob Evans" said: > >> However, I have not studied these new Docsis modems. So how do I shut the >> xfinitywifi SSID? > > Motorola Surfboard, Netgear WNDR3800, reflash the 3800 with cerowrt. Done. > > And you get less bufferbloat in the bargain. > > (Though the 3800 runs into CPU limits around 60mbits/sec - doesn't bother > me, as my 20/5 plan is plenty for me except when my cats decide to start > binging on funny people videos. But if you've got leads on gear that will > still have CPU headroom in the 100-200mbit range, contact Dave Taht. :) > -- Jeff Shultz From ryan at hack.net Thu Dec 11 17:25:55 2014 From: ryan at hack.net (Ryan Brooks) Date: Thu, 11 Dec 2014 11:25:55 -0600 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> Message-ID: <7BBFB976-E6B2-419A-8DD9-BC7417302D29@hack.net> Zfs on BSD or a Solaris like OS > On Dec 11, 2014, at 10:06 AM, Bacon Zombie wrote: > > Are you running ZFS and RAIDZ on Linux or BSD? >> On 10 Dec 2014 23:21, "Javier J" wrote: >> >> I'm just going to chime in here since I recently had to deal with bit-rot >> affecting a 6TB linux raid5 setup using mdadm (6x 1TB disks) >> >> We couldn't rebuild because of 5 URE sectors on one of the other disks in >> the array after a power / ups issue rebooted our storage box. >> >> We are now using ZFS RAIDZ and the question I ask myself is, why wasn't I >> using ZFS years ago? >> >> +1 for ZFS and RAIDZ >> >> >> >>> On Wed, Dec 10, 2014 at 8:40 AM, Rob Seastrom wrote: >>> >>> >>> The subject is drifting a bit but I'm going with the flow here: >>> >>> Seth Mos writes: >>> >>>> Raid10 is the only valid raid format these days. With the disks as big >>>> as they get these days it's possible for silent corruption. >>> >>> How do you detect it? A man with two watches is never sure what time it >>> is. >>> >>> Unless you have a filesystem that detects and corrects silent >>> corruption, you're still hosed, you just don't know it yet. RAID10 >>> between the disks in and of itself doesn't help. >>> >>>> And with 4TB+ disks that is a real thing. Raid 6 is ok, if you accept >>>> rebuilds that take a week, literally. Although the rebuild rate on our >>>> 11 disk raid 6 SSD array (2TB) is less then a day. >>> >>> I did a rebuild on a RAIDZ2 vdev recently (made out of 4tb WD reds). >>> It took nowhere near a day let alone a week. Theoretically takes 8-11 >>> hours if the vdev is completely full, proportionately less if it's >>> not, and I was at about 2/3 in use. >>> >>> -r >> From Jason_Livingood at cable.comcast.com Thu Dec 11 17:45:28 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 17:45:28 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548902D7.60406@mompl.net> References: <548902D7.60406@mompl.net> Message-ID: On 12/10/14, 9:35 PM, "Jeroen van Aart" wrote: >Why am I not surprised? You¹re a smart guy - don¹t believe everything you read. ;-) >Whose fault would it be if your comcast installed public wifi would be >abused to download illegal material or launch a botnet, to name some >random fun one could have on your behalf. :-/ It would not be your fault. The public SSID has a separate IP address, so the abuse would trace to that. In addition, all access is authenticated on a per user / per device basis. So there is good abuse traceback. >"A mother and daughter are suing Comcast claiming the cable giant¹s >router in their home was offering public Wi-Fi without their permission. Prior to rolling this out in a given market, generally speaking, each customer is notified and provided with detailed opt-out instructions. >So if you're passing by a fellow user's home, you can lock onto their >public Wi-Fi, log in using your Comcast username and password, and use >that home's bandwidth. Not really; separate bandwidth in the DOCSIS network is provisioned for this. >places a "vast² burden on electricity bills The citation refers to a highly unscientific study by a company that looked at a commercial cable modem, in combination with a separate commercial-grade WiFi access point. Putting aside the accuracy of that study, the two pieces of commercial equipment are very different from the single residential WiFi gateway at question here. - Jason Livingood Comcast From jra at baylink.com Thu Dec 11 17:54:09 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 11 Dec 2014 12:54:09 -0500 (EST) Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: Message-ID: <31465177.2731.1418320449440.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > On Thu, Dec 11, 2014 at 9:24 AM, wrote: > > > On Thu, 11 Dec 2014 00:11:07 -0500, Jay Ashworth said: > > > I will give them their props: I only had to sign in *once*, last > > > year; > > > their auth controller has recognized my MAC address at every spot > > > I've > > > used since. > > > > Actually, that's sort of scary if you think about it too hard. > > Shared-secret > > authentication has its flaws, but it still beats shared-nonsecret > > auth. > > > > I really hope it's something on your laptop other than the mac > > address.... > It's very scary, and something I'm doing a paper on. It _is_ just MAC > recognition, at least until you try and use a MAC address that's > already active somewhere else. MAC cloning isn't all *that* common, at least not for that usage. The fact that it is *possible* provides some nice cover in certain circumstances, I would guess. As for "something else on my laptop", I'm not sure what else they could see; I'd be surprised if they could get anything to run on SuSE 12.2. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From Jason_Livingood at cable.comcast.com Thu Dec 11 17:54:43 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 17:54:43 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> Message-ID: On 12/10/14, 9:41 PM, "Charles Mills" > wrote: In the US at least you have to authenticate with your Comcast credentials and not like a traditional open wifi where you can just make up an email and accept the terms of service. I also understand that it is a different IP than the subscriber. Based on this the subscriber should be protected from anyone doing anything illegal and causing the SWAT team to pay a visit. You are absolutely correct. Now..they are doing this on your electric bill and taking up space (albeit a small amount of it) in your home. The blog cited is at http://speedify.com/%20blog/comcast-public-hotspot-cost/. As you can see it uses two separate devices; it is not similar to our residential service. Jason From Jason_Livingood at cable.comcast.com Thu Dec 11 17:59:22 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 17:59:22 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548915b7.12138c0a.2cae.3bbf@mx.google.com> References: <548915b7.12138c0a.2cae.3bbf@mx.google.com> Message-ID: On 12/10/14, 10:55 PM, "Phil Bedard" wrote: >Really it is just the power they seem to be complaining about. And per my other post, the citation was for two separate commercial devices and the commercial WiFi AP being used 24x7. The one customers get is a very, very different residential integrated gateway (and at that I think it unlikely someone would be on the Xfinity WiFi SSID 24x7 at full Tx/Rx rate). Jason From Jason_Livingood at cable.comcast.com Thu Dec 11 18:04:20 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 18:04:20 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> Message-ID: On 12/11/14, 9:37 AM, "Scott Helms" wrote: >It is, you only have to log in once and then it remembers your MAC >address. Right, so user name & password + MAC address. As more devices support things like Passpoint, this will get more sophisticated. Jason From bkain1 at ford.com Thu Dec 11 18:06:33 2014 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Thu, 11 Dec 2014 18:06:33 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> Message-ID: <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> No one who has Comcast, who I've forward this to, knew about this (all US customers). Maybe you can send here the notification Comcast sent out, to your customers. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Livingood, Jason Sent: Thursday, December 11, 2014 12:55 PM To: Charles Mills; Jeroen van Aart Cc: NANOG list Subject: Re: Comcast thinks it ok to install public wifi in your house On 12/10/14, 9:41 PM, "Charles Mills" > wrote: In the US at least you have to authenticate with your Comcast credentials and not like a traditional open wifi where you can just make up an email and accept the terms of service. I also understand that it is a different IP than the subscriber. Based on this the subscriber should be protected from anyone doing anything illegal and causing the SWAT team to pay a visit. You are absolutely correct. Now..they are doing this on your electric bill and taking up space (albeit a small amount of it) in your home. The blog cited is at http://speedify.com/%20blog/comcast-public-hotspot-cost/. As you can see it uses two separate devices; it is not similar to our residential service. Jason From Jason_Livingood at cable.comcast.com Thu Dec 11 18:10:45 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 18:10:45 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <5489C6A8.8020807@sctcweb.com> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> <3677.1418313912@turing-police.cc.vt.edu> <5489C6A8.8020807@sctcweb.com> Message-ID: Here is how you disable it. 1 – Login to the customer portal https://customer.comcast.com/ 2 – Click the “Users & Preferences” tab (see pic @ http://media.bestofmicro.com/4/Z/442115/original/xfinity-how-to-disable-3.jpg) 3 – Click “Manage XFINITY WiFi” (see pic @ http://media.bestofmicro.com/5/0/442116/original/xfinity-how-to-disable-4.jpg) 4 – Select “Disable XFINITY WiFi” and then click “Save" (see pic @ http://media.bestofmicro.com/T/0/442980/gallery/The-Money-SHot_w_600.jpg) Jason On 12/11/14, 11:30 AM, "Jeff Shultz" > wrote: Or you can just call Comcast and ask them to turn it off. Or you could in the past. My in-laws did that when they got their new equipment. I don't know exactly how they found out it was going to be done - possibly inside info due to a relative working for Comcast. On 12/11/2014 8:05 AM, Valdis.Kletnieks at vt.edu wrote: On Thu, 11 Dec 2014 07:30:00 -0800, "Bob Evans" said: However, I have not studied these new Docsis modems. So how do I shut the xfinitywifi SSID? Motorola Surfboard, Netgear WNDR3800, reflash the 3800 with cerowrt. Done. And you get less bufferbloat in the bargain. (Though the 3800 runs into CPU limits around 60mbits/sec - doesn't bother me, as my 20/5 plan is plenty for me except when my cats decide to start binging on funny people videos. But if you've got leads on gear that will still have CPU headroom in the 100-200mbit range, contact Dave Taht. :) -- Jeff Shultz From Valdis.Kletnieks at vt.edu Thu Dec 11 18:12:54 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 11 Dec 2014 13:12:54 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: Your message of "Thu, 11 Dec 2014 18:04:20 +0000." References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> Message-ID: <10570.1418321574@turing-police.cc.vt.edu> On Thu, 11 Dec 2014 18:04:20 +0000, "Livingood, Jason" said: > Right, so user name & password + MAC address. As more devices support > things like Passpoint, this will get more sophisticated. OK, so it *does* do .1x authentication with the name/password, not just mac address. That's a lot less scary.. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From michael.holstein at csuohio.edu Thu Dec 11 18:13:56 2014 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Thu, 11 Dec 2014 18:13:56 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <5489C6A8.8020807@sctcweb.com> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> <3677.1418313912@turing-police.cc.vt.edu>,<5489C6A8.8020807@sctcweb.com> Message-ID: <1418321677919.83801@csuohio.edu> >Or you can just call Comcast and ask them to turn it off. Or you could >in the past. I can see where the pointy-haired types came up with the opt-out idea hoping nobody would notice or care, but at least they make it (fairly) easy : http://wifi.comcast.com/faqs.html 1. Log into your Comcast account page at customer.comcast.com. 2. Click on Users & Preferences. 3. Look for a heading on the page for “Service Address.” Below your address, click the link that reads “Manage Xfinity WiFi.” 4. Click the button for “Disable Xfinity Wifi Home Hotspot.” 5. Click Save Michael Holstein Cleveland State University From nanog at ics-il.net Thu Dec 11 18:14:28 2014 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 11 Dec 2014 12:14:28 -0600 (CST) Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> Message-ID: <3799748.1470.1418321656817.JavaMail.mhammett@ThunderFuck> Have you ever met an intelligent, informed consumer? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Rebecca Kain (.)" To: "Jason Livingood" , "Charles Mills" , "Jeroen van Aart" Cc: "NANOG list" Sent: Thursday, December 11, 2014 12:06:33 PM Subject: RE: Comcast thinks it ok to install public wifi in your house No one who has Comcast, who I've forward this to, knew about this (all US customers). Maybe you can send here the notification Comcast sent out, to your customers. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Livingood, Jason Sent: Thursday, December 11, 2014 12:55 PM To: Charles Mills; Jeroen van Aart Cc: NANOG list Subject: Re: Comcast thinks it ok to install public wifi in your house On 12/10/14, 9:41 PM, "Charles Mills" > wrote: In the US at least you have to authenticate with your Comcast credentials and not like a traditional open wifi where you can just make up an email and accept the terms of service. I also understand that it is a different IP than the subscriber. Based on this the subscriber should be protected from anyone doing anything illegal and causing the SWAT team to pay a visit. You are absolutely correct. Now..they are doing this on your electric bill and taking up space (albeit a small amount of it) in your home. The blog cited is at http://speedify.com/%20blog/comcast-public-hotspot-cost/. As you can see it uses two separate devices; it is not similar to our residential service. Jason From Jason_Livingood at cable.comcast.com Thu Dec 11 18:16:06 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 18:16:06 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> Message-ID: On 12/11/14, 1:06 PM, "Kain, Rebecca (.)" wrote: >No one who has Comcast, who I've forward this to, knew about this (all US >customers). Maybe you can send here the notification Comcast sent out, >to your customers. I emailed you off-list. I am happy to investigate individual cases. The rollout has been happening since probably 2009 or 2010. Jason From bkain1 at ford.com Thu Dec 11 18:16:51 2014 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Thu, 11 Dec 2014 18:16:51 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> Message-ID: <7DB845D64966DC44A1CC592780539B4B01218FA0@nafmbx47.exchange.ford.com> K, thanks -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] Sent: Thursday, December 11, 2014 1:16 PM To: Kain, Rebecca (.) Cc: NANOG list Subject: Re: Comcast thinks it ok to install public wifi in your house On 12/11/14, 1:06 PM, "Kain, Rebecca (.)" wrote: >No one who has Comcast, who I've forward this to, knew about this (all US >customers). Maybe you can send here the notification Comcast sent out, >to your customers. I emailed you off-list. I am happy to investigate individual cases. The rollout has been happening since probably 2009 or 2010. Jason From jfmezei_nanog at vaxination.ca Thu Dec 11 18:43:52 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 11 Dec 2014 13:43:52 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> Message-ID: <5489E5E8.9070208@vaxination.ca> On 14-12-11 12:45, Livingood, Jason wrote: > Not really; separate bandwidth in the DOCSIS network is provisioned for > this. How is this done ? 2 separate modems in same box ? or a single modem which gets 2 separate IPs and applies rate limiting independently on each IP ? BTW, it isn't just the electricity, but also climate control and location which the subscriber provides for free. Comcast need not rent space on poles and need not buy more expensive weatherized equipment that goes outdoors. From rs at seastrom.com Thu Dec 11 18:48:15 2014 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 11 Dec 2014 13:48:15 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: <7BBFB976-E6B2-419A-8DD9-BC7417302D29@hack.net> (Ryan Brooks's message of "Thu, 11 Dec 2014 11:25:55 -0600") References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> <7BBFB976-E6B2-419A-8DD9-BC7417302D29@hack.net> Message-ID: <8661dit440.fsf@valhalla.seastrom.com> +1 on both. Mostly SmartOS, some FreeNAS (which is FreeBSD underneath). -r Ryan Brooks writes: > Zfs on BSD or a Solaris like OS > > >> On Dec 11, 2014, at 10:06 AM, Bacon Zombie wrote: >> >> Are you running ZFS and RAIDZ on Linux or BSD? >>> On 10 Dec 2014 23:21, "Javier J" wrote: >>> >>> I'm just going to chime in here since I recently had to deal with bit-rot >>> affecting a 6TB linux raid5 setup using mdadm (6x 1TB disks) >>> >>> We couldn't rebuild because of 5 URE sectors on one of the other disks in >>> the array after a power / ups issue rebooted our storage box. >>> >>> We are now using ZFS RAIDZ and the question I ask myself is, why wasn't I >>> using ZFS years ago? >>> >>> +1 for ZFS and RAIDZ >>> >>> >>> >>>> On Wed, Dec 10, 2014 at 8:40 AM, Rob Seastrom wrote: >>>> >>>> >>>> The subject is drifting a bit but I'm going with the flow here: >>>> >>>> Seth Mos writes: >>>> >>>>> Raid10 is the only valid raid format these days. With the disks as big >>>>> as they get these days it's possible for silent corruption. >>>> >>>> How do you detect it? A man with two watches is never sure what time it >>>> is. >>>> >>>> Unless you have a filesystem that detects and corrects silent >>>> corruption, you're still hosed, you just don't know it yet. RAID10 >>>> between the disks in and of itself doesn't help. >>>> >>>>> And with 4TB+ disks that is a real thing. Raid 6 is ok, if you accept >>>>> rebuilds that take a week, literally. Although the rebuild rate on our >>>>> 11 disk raid 6 SSD array (2TB) is less then a day. >>>> >>>> I did a rebuild on a RAIDZ2 vdev recently (made out of 4tb WD reds). >>>> It took nowhere near a day let alone a week. Theoretically takes 8-11 >>>> hours if the vdev is completely full, proportionately less if it's >>>> not, and I was at about 2/3 in use. >>>> >>>> -r >>> From Jason_Livingood at cable.comcast.com Thu Dec 11 18:59:12 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 18:59:12 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <5489E5E8.9070208@vaxination.ca> References: <548902D7.60406@mompl.net> <5489E5E8.9070208@vaxination.ca> Message-ID: On 12/11/14, 1:43 PM, "Jean-Francois Mezei" wrote: >How is this done ? > >2 separate modems in same box ? or a single modem which gets 2 separate >IPs and applies rate limiting independently on each IP ? The latter. JL From randy at psg.com Thu Dec 11 19:01:01 2014 From: randy at psg.com (Randy Bush) Date: Fri, 12 Dec 2014 04:01:01 +0900 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> <3677.1418313912@turing-police.cc.vt.edu> <5489C6A8.8020807@sctcweb.com> Message-ID: darn. i shoulda used a comcast cable modem instead of my own so i could provide this service to neighbors. ah well. i do put up a non-wpa ssid, but don't like the non-wpa. randy From wesley.george at twcable.com Thu Dec 11 19:11:02 2014 From: wesley.george at twcable.com (George, Wes) Date: Thu, 11 Dec 2014 14:11:02 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <5489E5E8.9070208@vaxination.ca> References: <548902D7.60406@mompl.net> <5489E5E8.9070208@vaxination.ca> Message-ID: On 12/11/14, 1:43 PM, "Jean-Francois Mezei" wrote: >BTW, it isn't just the electricity, but also climate control and >location which the subscriber provides for free. Comcast need not rent >space on poles and need not buy more expensive weatherized equipment >that goes outdoors. WG] In most cases your second assertion is not accurate, because the one doesn't eliminate the need for the other. The pole/strand/vault mounted and weatherized equipment is also quite a bit more powerful and has external antennas so that it has better range, and likely has had some RF engineering done to provide some reasonable envelope of contiguous coverage between APs. The majority of these home GWs are unlikely to be a real alternative to that sort of deployment for folks walking/driving past your house even in the best case scenario where the AP is optimally located and nearly every home on the block is participating and the houses are very close to one another and to the street. This is still fundamentally the same AP that may or may not have enough signal strength to provide consistent performance in all areas of the inside of a home (dependent on things like the location of the AP, the size & construction of the home, other interference, etc etc). Their intended use is to give access to visitors in your house and/or yard without you needing to set up a dedicated guest network or giving them your wifi password. Wes George Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From morrowc.lists at gmail.com Thu Dec 11 19:24:16 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Dec 2014 14:24:16 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <5489E5E8.9070208@vaxination.ca> Message-ID: On Thu, Dec 11, 2014 at 2:11 PM, George, Wes wrote: > Their intended use is to give > access to visitors in your house and/or yard without you needing to set up > a dedicated guest network or giving them your wifi password. this seems like the key point here... comcast isn't actually benefiting (except perhaps in less calls about: "Someone reconfigured my AP ... now it's all screwy" folk need to relax just a tad, and consider the technical implications here, outside of the conspiracy theories. -chris (where is my tin foil hat? I just know i left it around here somewhere) From dougb at dougbarton.us Thu Dec 11 19:53:56 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 11 Dec 2014 11:53:56 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> Message-ID: <5489F654.9020107@dougbarton.us> On 12/11/14 10:16 AM, Livingood, Jason wrote: > On 12/11/14, 1:06 PM, "Kain, Rebecca (.)" wrote: > > >> No one who has Comcast, who I've forward this to, knew about this (all US >> customers). Maybe you can send here the notification Comcast sent out, >> to your customers. > > I emailed you off-list. I am happy to investigate individual cases. The > rollout has been happening since probably 2009 or 2010. Jason, While that offer is noble, and appreciated, as are your other responses on this thread; personally I would be interested to hear more about how customers were notified. Was there a collateral piece included in their bill? Were they e-mailed? And are we correct in assuming that this is strictly opt-out? And is the report that if you opt out with your account that you are not then able to access the service elsewhere correct? Completely aside from the fact that other services have done something similar, I regard all of this as quite troubling, as it seems others here do as well. Doug From rjoffe at centergate.com Thu Dec 11 20:04:48 2014 From: rjoffe at centergate.com (Rodney Joffe) Date: Thu, 11 Dec 2014 13:04:48 -0700 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> <3677.1418313912@turing-police.cc.vt.edu> <5489C6A8.8020807@sctcweb.com> Message-ID: <2882EE36-6351-4B50-ACFB-85BAD0ECAF1C@centergate.com> Randy, You're spot on. I don't understand this griping. The flip side is that as a(n) happy xfinity customer I get to roam in lots of places around the US (and maybe even abroad), as do all of the xfinity home customers. This isn't a paid service... It's a byproduct of being a cable customer. I'm happy to pay a few pennies a day. The only challenge I see is the issue around wifi congestion. In my DC condo building there are a couple of hundred xfinity cable modem customers, mostly with wifi. However, with a little bit of work with the comcast techs, our neighborhood is pretty happy. Tip of the hat to Jason and Mike O'. > On Dec 11, 2014, at 12:01 PM, Randy Bush wrote: > > darn. i shoulda used a comcast cable modem instead of my own so i could > provide this service to neighbors. ah well. i do put up a non-wpa > ssid, but don't like the non-wpa. > > randy From jfmezei_nanog at vaxination.ca Thu Dec 11 20:06:53 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 11 Dec 2014 15:06:53 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <5489F654.9020107@dougbarton.us> References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> Message-ID: <5489F95D.9090209@vaxination.ca> >From the wired side, since the AP's bandwitdh is separate from the paying customer's, the later really has no complaint to make. Taken to the extreme, yeah, all those APs may end up adding to the load on the coax segment and creating congestion. But somehow I doubt this is a huge issue. One the Wi-Fi side, it all depends on how much capacity on the paying customer's Wi-Fi SSID is reduced by the presence of the Xfinity SSID. I think Comcast should have spun this totally differently. "Guests coming home ?, go to your Comcast web site and enable Xfinity, and they can sign in with their credentials to your Wi-Fi, and won't slow you down or consume your monthly usage limits". This would have been seen as a true service given to consumers instead of being seen as Comcast "stealing" consumer's bandwidth without their consent to serve others. (which is what the perception appears to be) As far as the electricity issue, I have to assume that any alleged additional power consumption would be very minimal compared to a router that has single SSID. The principle may be worth fighting for, but the amounts are not. From randy at psg.com Thu Dec 11 20:22:28 2014 From: randy at psg.com (Randy Bush) Date: Fri, 12 Dec 2014 05:22:28 +0900 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <2882EE36-6351-4B50-ACFB-85BAD0ECAF1C@centergate.com> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> <3677.1418313912@turing-police.cc.vt.edu> <5489C6A8.8020807@sctcweb.com> <2882EE36-6351-4B50-ACFB-85BAD0ECAF1C@centergate.com> Message-ID: note that free.fr does this in france. we both provide and use it there. works out quite well. i guess i should figure out how to use comcast's stateside version. randy From bzs at world.std.com Thu Dec 11 20:25:09 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 11 Dec 2014 15:25:09 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> Message-ID: <21641.64933.650664.76727@world.std.com> From: Randy Bush >> We are now using ZFS RAIDZ and the question I ask myself is, why >> wasn't I using ZFS years ago? > >because it is not production on linux, which i have to use because >freebsd does not have kvm/ganeti. want zfs very very badly. snif. I keep reading zfs vs btrfs articles and...inconclusive. My problem with both is I need quotas, both file and "inode", and both are weaker than ext4 on that, zfs is very weak on this, you can only sort of simulate them. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From dougb at dougbarton.us Thu Dec 11 20:50:23 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 11 Dec 2014 12:50:23 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> Message-ID: <548A038F.8060109@dougbarton.us> That's interesting, thanks for that info, Mike. Jason has a good point in that a lot of the "reporting" on this topic so far has been ill-informed, and I think it's important to understand the truth. Re Rodney and Randy's point about this being blown out of proportion, the thing I'm most concerned about is not the service itself, which is interesting, and has the capability to be a good utilization of resources (as in, a cheap way to provide a beneficial service). My concerns are that apparently customers are not informed about the thing before it gets enabled, and the issue of wifi density that was raised by several people here. If you have an apartment building for example, where a significant majority of the tenants are Comcast customers (cuz in 'murica we loves us some monopolies) I see a lot of strong xfinity signals stomping on an already crowded 2.4 G spectrum. So just to be clear, I'm not being critical at this point, I'm simply interested in separating the facts from the hype. Doug On 12/11/14 12:42 PM, Mike wrote: > Doug, > > I use my own router at home, so I opted out, and I can use the service without issue. > > Mike > >> On Dec 11, 2014, at 2:53 PM, Doug Barton wrote: >> >>> On 12/11/14 10:16 AM, Livingood, Jason wrote: >>> On 12/11/14, 1:06 PM, "Kain, Rebecca (.)" wrote: >>> >>> >>>> No one who has Comcast, who I've forward this to, knew about this (all US >>>> customers). Maybe you can send here the notification Comcast sent out, >>>> to your customers. >>> >>> I emailed you off-list. I am happy to investigate individual cases. The >>> rollout has been happening since probably 2009 or 2010. >> >> Jason, >> >> While that offer is noble, and appreciated, as are your other responses on this thread; personally I would be interested to hear more about how customers were notified. Was there a collateral piece included in their bill? Were they e-mailed? >> >> And are we correct in assuming that this is strictly opt-out? And is the report that if you opt out with your account that you are not then able to access the service elsewhere correct? >> >> Completely aside from the fact that other services have done something similar, I regard all of this as quite troubling, as it seems others here do as well. >> >> Doug >> >> From jra at baylink.com Thu Dec 11 20:53:37 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 11 Dec 2014 15:53:37 -0500 (EST) Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <10570.1418321574@turing-police.cc.vt.edu> Message-ID: <10672062.2857.1418331217378.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Thu, 11 Dec 2014 18:04:20 +0000, "Livingood, Jason" said: > > > Right, so user name & password + MAC address. As more devices > > support things like Passpoint, this will get more sophisticated. > > OK, so it *does* do .1x authentication with the name/password, not > just mac address. That's a lot less scary.. :) Well, if we're still talking about Bright House customer wifi, the user/pass auth is only on the first connection, and it's in-band. Any device can associate to any of their APs, you just don't get anywhere until you auth the first time, after which it just looks like open wifi to you. So I don't think it is .1x; that won't even let you associate if you can't authenticate, will it? Or do I misunderstand .1x/.11? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jmkeller at houseofzen.org Thu Dec 11 20:55:09 2014 From: jmkeller at houseofzen.org (James Michael Keller) Date: Thu, 11 Dec 2014 15:55:09 -0500 Subject: Cisco AnyConnect speed woes! In-Reply-To: References: Message-ID: <548A04AD.9020404@houseofzen.org> On 12/09/2014 02:42 PM, Zachary McGibbon wrote: > I'm looking for some input on a situation that has been plaguing our new > AnyConnect VPN setup. Any input would be valuable, we are at a loss for > what the problem is. > > We recently upgraded our VPN from our old Cisco 3000 VPN concentrators > running PPTP and we are now running a pair of Cisco 5545x ASAs in an HA > active/standby pair. > > The big issue we are having is that many of our users are complaining of > low speed when connected to the VPN. We have done tons of troubleshooting > with Cisco TAC and we still haven't found the root of our problem. > > Some tests we have done: > > - We have tested changing MTU values > - We have tried all combinations of encryption methods (SSL, TLS, IPSec, > L2TP) with similar results > - We have switched our active/standby boxes > - We have tested on our spare 5545x box > - We connected our spare box directly to our ISP with another IP address > - We have whitelisted our VPN IP on our shaper (Cisco SCE8000) and our > IPS (HP Tipping Point) > - We have bypassed our Shaper and our IPS > - We made sure that traffic from the routers talking to our ASAs is > synchronous, OSPF was configured to load balance but this has been changed > by changing the costs on the links to the ASAs > - We have verified with our two ISPs that they are not doing any kind of > filtering or shaping > - We have noticed that in some instances that if a user is on a low > speed connection that their VPN speed gets cut by about 1/3. This doesn't > seem normal that the VPN would use this much overhead > - We do not have the issue when connecting to VPN directly on our own > network, only connections from the Internet > > If you have any ideas on what we could try net, please let me know! > > - Zachary What OS builds? At one point the code had an 8 packet hard coded window per tcp flow, which capped ssl over tcp window size to about 5mbps depending on RTT. Recent 8 branches raised this to something more reasonable that capped around 20 mbps. DTLS over udp and IPSEC tunnels did not have this issue. -- -James From jra at baylink.com Thu Dec 11 20:58:08 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 11 Dec 2014 15:58:08 -0500 (EST) Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: Message-ID: <5629297.2859.1418331488210.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Christopher Morrow" > On Thu, Dec 11, 2014 at 2:11 PM, George, Wes > wrote: > > Their intended use is to give > > access to visitors in your house and/or yard without you needing to > > set up > > a dedicated guest network or giving them your wifi password. > > this seems like the key point here... comcast isn't actually > benefiting (except perhaps in less calls about: "Someone reconfigured > my AP ... now it's all screwy" > > folk need to relax just a tad, and consider the technical implications > here, outside of the conspiracy theories. Alas, I cannot accept George's assertion (which is quite a different thing from my thinking it's a conspiracy): In residential areas (non-multi-unit), this is only going to help out *Comcast subscribers*. If you have random visitors over, it won't help them, as they can't get authed to the service. Unless you give them your credentials, at which point they can use it everywhere, not just at your house. And it doesn't let you help your neighbors for the same reason: if they have their own creds for it, then they don't need your AP since they have one. No, I'm having a hard time figuring out what the use case *is* for this service as deployed against *residential* hardware, myself... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From Jason_Livingood at cable.comcast.com Thu Dec 11 21:13:22 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 21:13:22 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <5489F654.9020107@dougbarton.us> References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> Message-ID: On 12/11/14, 2:53 PM, "Doug Barton" wrote: >While that offer is noble, and appreciated, as are your other responses >on this thread; personally I would be interested to hear more about how >customers were notified. Was there a collateral piece included in their >bill? Were they e-mailed? It is a range of tactics. Depending on where someone lives there were traditional media tactics to raise awareness. For example, where I am in Philadelphia I saw video ads in the new SEPTA regional rail trains, saw it printed on on monthly rail passes, and shown on small billboards in stations. I get an electronic bill personally but I would guess people with printed bills very likely got something inside the bill given the other tactics employed. I do know emails were sent regionally (probably 2009 - 2014) as the network went live. This explained the monthly stories in the press, as the news cycle seemed to rediscover this every time we rolled it out further. If you became a customer after it was rolled out, it was a key aspect of marketing to prospective customers (such as on our website) so probably hard to miss. >And are we correct in assuming that this is strictly opt-out? >And is the report that if you opt out with your account that you are not >then able to access the service elsewhere correct? I¹m not 100% sure. I think it is the case that you can use it even if you disable it on your own AP. Jason From alh-ietf at tndh.net Thu Dec 11 21:15:19 2014 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 11 Dec 2014 13:15:19 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> Message-ID: <009a01d01587$9164b950$b42e2bf0$@tndh.net> > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bob Evans > Sent: Thursday, December 11, 2014 7:30 AM > To: nanog at nanog.org > Subject: Re: Comcast thinks it ok to install public wifi in your house > > > I think it's more than AC power issue....who knows what strength level they > program that SSID to work at ? More wifi signal you are exposed to without > your knowledge and more...read on. > The CPU would be running the idle loop if it wasn't handling these packets, so power consumption outside the RF transmitter is irrelevant. Given it is a part-15 consumer device, you can assume no more than 100mw on the signal level. Assume someone lights that up 24x7x365.25 ... (an unrealistic continuous broadcast from a source on the wired side, but for a worst case back-of-the-envelope calculation it is close enough). The transmitter is not going to be 100% efficient, so let's pick 33% to make the calculation easier to follow. .3 W x 24 hrs = 7.2 Whrs/day 7.2Whrs/day x $.00011/Whr*= $.000792/day $.000792/day x 365.25 days/yr = $.289278/yr *YMMV based on the local rate per kWhr. So for any realistic local kWhr rate in the coverage area, the result is less than $1/yr. This case is arguing a substantial burden has been imposed as the result of consuming "vastly more electricity", but any realistic use of that additional signal over an entire year is less than the cost of a stamp used to mail in just one month's bill payment. The lawyers in this case need a substantial fine for abusing the court system. Tony From owen at delong.com Thu Dec 11 21:14:26 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Dec 2014 13:14:26 -0800 Subject: Charging fee for BGP prefix per /24?! In-Reply-To: <54894390.4060105@bogus.com> References: <000001d01452$3ef37200$bcda5600$@at> <54894390.4060105@bogus.com> Message-ID: <5209E7D8-8C92-4A26-A88E-FF4AE0AD7EA6@delong.com> > On Dec 10, 2014, at 23:11 , joel jaeggli wrote: > > On 12/10/14 7:45 PM, Justin M. Streiner wrote: >> On Wed, 10 Dec 2014, Yucong Sun wrote: >> >>> It is not the same thing though. In my case, they just say we want >>> you to >>> buy our IP, if you don't and want use you own Arin allocated IP blocks >>> through bgp, then we got to charge you anyway! >> >> Are they charging per /24 (assuming IPv4 here...), or per prefix? >> >> If they are charging per /24, that seems like a great way to encourage >> customers to find another provider. >> >> If they are charging per prefix, that seems like an interesting way to >> encourage customers to make sure they aggregate their BGP >> advertisements as much as possible. >> > ISPs in my experience have a fee schedule supported by a model which > allows them to recover their expenses plus a nominal profit. If the > model doesn't work, in the long run that is a problem that solves > itself. At the right scale I have productive leverage against the profit > side of that number and also what line items the expenses are lodged > against. below that I'm a retail customer and I pick from the best > options available to me. >> jms >> > > To me this sounds like they are trying to encourage their customers to accept IP addresses from them in order to bolster their utilization for purposes of hoarding addresses. I would expect that they will later reverse these "incentives" to attempt to reclaim the space in order to avoid having to go to the transfer market for more space. I would consider such behavior highly unethical at best, but my sense of ethics may not be shared by all. I'm sure some of the Randians on this list will tell me that this is some proper and good way for the economy to work. Free market, blah blah. Owen From rhirst at xkl.com Thu Dec 11 21:18:03 2014 From: rhirst at xkl.com (Roy Hirst) Date: Thu, 11 Dec 2014 13:18:03 -0800 Subject: Cisco AnyConnect speed woes! In-Reply-To: <548A04AD.9020404@houseofzen.org> References: <548A04AD.9020404@houseofzen.org> Message-ID: <548A0A0B.4040300@xkl.com> Confidently based on no knowledge at all - *Roy Hirst* | 425-556-5773 | 425-324-0941 cell XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA >> - We have noticed that in some instances that if a user is on a low >> speed connection that their VPN speed gets cut by about 1/3. >> This doesn't >> seem normal that the VPN would use this much overhead No, sure, but are you sure that congestion is not dropping a packet somewhere in the end-to-end? If you offend TCP it will likely cut the sender's packet transmit rate, even if the "possible" VPN rate is much higher. >> - We do not have the issue when connecting to VPN directly on our >> own >> network, only connections from the Internet Internet would mean maybe a proxy or firewall then, with too-small buffers or an old-time TCP/IP stack? Just a thought. >> >> If you have any ideas on what we could try net, please let me know! >> >> - Zachary > > What OS builds? At one point the code had an 8 packet hard coded > window per tcp flow, which capped ssl over tcp window size to about > 5mbps depending on RTT. Recent 8 branches raised this to something > more reasonable that capped around 20 mbps. DTLS over udp and IPSEC > tunnels did not have this issue. UDP traffic does not have this problem but TCP does? Hmmm... > > > > The information contained in this e-mail message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender at the above e-mail address. From joelja at bogus.com Thu Dec 11 21:20:22 2014 From: joelja at bogus.com (joel jaeggli) Date: Thu, 11 Dec 2014 13:20:22 -0800 Subject: Charging fee for BGP prefix per /24?! In-Reply-To: <5209E7D8-8C92-4A26-A88E-FF4AE0AD7EA6@delong.com> References: <000001d01452$3ef37200$bcda5600$@at> <54894390.4060105@bogus.com> <5209E7D8-8C92-4A26-A88E-FF4AE0AD7EA6@delong.com> Message-ID: <548A0A96.5080004@bogus.com> On 12/11/14 1:14 PM, Owen DeLong wrote: >> On Dec 10, 2014, at 23:11 , joel jaeggli wrote: >> >> On 12/10/14 7:45 PM, Justin M. Streiner wrote: >>> On Wed, 10 Dec 2014, Yucong Sun wrote: >>> >>>> It is not the same thing though. In my case, they just say we want >>>> you to >>>> buy our IP, if you don't and want use you own Arin allocated IP blocks >>>> through bgp, then we got to charge you anyway! >>> Are they charging per /24 (assuming IPv4 here...), or per prefix? >>> >>> If they are charging per /24, that seems like a great way to encourage >>> customers to find another provider. >>> >>> If they are charging per prefix, that seems like an interesting way to >>> encourage customers to make sure they aggregate their BGP >>> advertisements as much as possible. >>> >> ISPs in my experience have a fee schedule supported by a model which >> allows them to recover their expenses plus a nominal profit. If the >> model doesn't work, in the long run that is a problem that solves >> itself. At the right scale I have productive leverage against the profit >> side of that number and also what line items the expenses are lodged >> against. below that I'm a retail customer and I pick from the best >> options available to me. >>> jms >>> >> > To me this sounds like they are trying to encourage their customers to accept IP addresses from them in order to bolster their utilization for purposes of hoarding addresses. I would expect that they will later reverse these "incentives" to attempt to reclaim the space in order to avoid having to go to the transfer market for more space. > > I would consider such behavior highly unethical at best, but my sense of ethics may not be shared by all. I'm sure some of the Randians on this list will tell me that this is some proper and good way for the economy to work. Free market, blah blah. I think it's a really good idea to not engage in business with people whose behavior strikes you as bad. > > > Owen > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 221 bytes Desc: OpenPGP digital signature URL: From Jason_Livingood at cable.comcast.com Thu Dec 11 21:26:21 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 21:26:21 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <2882EE36-6351-4B50-ACFB-85BAD0ECAF1C@centergate.com> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> <3677.1418313912@turing-police.cc.vt.edu> <5489C6A8.8020807@sctcweb.com> <2882EE36-6351-4B50-ACFB-85BAD0ECAF1C@centergate.com> Message-ID: On 12/11/14, 3:04 PM, "Rodney Joffe" wrote: >The flip side is that as a(n) happy xfinity customer I get to roam in >lots of places around the US (and maybe even abroad), as do all of the >xfinity home customers. Outside of the U.S., a customer can use the WiFi networks operated by Liberty Global. As of September 2014, Liberty Global had over 2.5 million home spots under the "Wi-Free" and ³WifiSpots" names (SSIDs) in various countries in Europe, including Belgium, the Netherlands, Ireland, Poland and Switzerland. I expect more international roaming agreements in the future - which can save a lot of money compared to using international data roaming via 4G LTE, etc. >The only challenge I see is the issue around wifi congestion. In my DC >condo building there are a couple of hundred xfinity cable modem >customers, mostly with wifi. Unlicensed WiFi is being taking to interesting new levels of scale around the world. As it does, new technical solutions will certainly be called for, including stuff like Œradio resource management¹ that can make APs aware of neighbors and collectively adjust power levels and channels to operate as an efficient whole. >From my standpoint, I want IP everywhere and I much prefer unlicensed spectrum to licensed. :-) Jason From Jason_Livingood at cable.comcast.com Thu Dec 11 21:34:03 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 21:34:03 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <5489F95D.9090209@vaxination.ca> References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <5489F95D.9090209@vaxination.ca> Message-ID: On 12/11/14, 3:06 PM, "Jean-Francois Mezei" wrote: >I think Comcast should have spun this totally differently. Well, I think we probably did. But apparently all it takes is one lawsuit filed in California and an article in The Register to really make an impact. ;-) Then again, the tech press doesn¹t really get clicks by saying ³cool new service could help you connect to the Internet wherever you are, and puppies are cute too². Jason From larrysheldon at cox.net Thu Dec 11 21:34:36 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 11 Dec 2014 15:34:36 -0600 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> Message-ID: <548A0DEC.4060200@cox.net> On 12/11/2014 07:10, William Herrin wrote: > What Comcast is stealing is electricity. Pennies per customer times a > boatload of customers. .....and floorspace, physical security, air conditioning, and all sorts of labor overheads. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From Jason_Livingood at cable.comcast.com Thu Dec 11 21:41:24 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 21:41:24 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548A038F.8060109@dougbarton.us> References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: On 12/11/14, 3:50 PM, "Doug Barton" > wrote: That's interesting, thanks for that info, Mike. Jason has a good point in that a lot of the "reporting" on this topic so far has been ill-informed... What else is new? ;-) It’s frustrating where I sit but sometimes reporters don’t like when facts get in the way of a good story. It comes with the territory, so I’m used to it. I see a lot of strong xfinity signals stomping on an already crowded 2.4 G spectrum. Fair point. But 2.4GHz was a bit of a mess before we came along with this service. 5GHz is a lot better and we were one of many companies in favor of the recent FCC decision to expand unlicensed 5GHz spectrum. See http://arstechnica.com/information-technology/2014/03/more-wi-fi-is-better-fcc-expands-use-of-5-ghz-spectrum/ So just to be clear, I'm not being critical at this point, I'm simply interested in separating the facts from the hype. No worries! :-) Jason From Jason_Livingood at cable.comcast.com Thu Dec 11 21:44:04 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 21:44:04 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <5629297.2859.1418331488210.JavaMail.root@benjamin.baylink.com> References: <5629297.2859.1418331488210.JavaMail.root@benjamin.baylink.com> Message-ID: On 12/11/14, 3:58 PM, "Jay Ashworth" wrote: >No, I'm having a hard time figuring out what the use case *is* for this >service as deployed against *residential* hardware, myself... Well, the great thing about the marketplace is that if it ultimately does not prove useful and of some value then it¹ll eventually go away. :-) Jason From jfmezei_nanog at vaxination.ca Thu Dec 11 21:45:39 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 11 Dec 2014 16:45:39 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: <548A1083.90104@vaxination.ca> Mr Livingood: Out of curiosity, had Comcast decided to use an "opt-in" instead of "opt-out" method, did your marketing dept have any idea of percentage of customer base who would have opted in ? Secondly, at a more technical level: In a MDU with a whole bunch of Comcast subscribers, could one router be able to detect existence of strong Xfinity signals and not enable its own ? This would reduce crowding of Wi-Fi spectrum. I take it such a feature would require special programming/firmware by modem/router manufacturer ? From shortdudey123 at gmail.com Thu Dec 11 21:47:38 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 11 Dec 2014 13:47:38 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <5629297.2859.1418331488210.JavaMail.root@benjamin.baylink.com> Message-ID: I think it may have already been slightly mentioned, but any reason why this is not being rolled out on a separate radio than the private customer facing one? Even if the bandwidth out to the internet is separated with DOCSIS channels, you are still using the same radio and one user streaming a large amount of data could bog down the radio. I have seen 1 or 2 clients destroy speed and cause large amounts (adding 100+ms) of latency for all clients connected to the same radio. -Grant On Thu, Dec 11, 2014 at 1:44 PM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > On 12/11/14, 3:58 PM, "Jay Ashworth" wrote: > > >No, I'm having a hard time figuring out what the use case *is* for this > >service as deployed against *residential* hardware, myself... > > Well, the great thing about the marketplace is that if it ultimately does > not prove useful and of some value then it¹ll eventually go away. :-) > > Jason > > From Curtis.Parish at mtsu.edu Thu Dec 11 21:42:06 2014 From: Curtis.Parish at mtsu.edu (Curtis L. Parish) Date: Thu, 11 Dec 2014 21:42:06 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> Message-ID: <848A0CCBF45ABC49B103A3733FA46C5066DF70@MTEXMBC01.fsa.mtsu.edu> On the converse side I live in a neighborhood that has quite a bit of distance between houses yet I can still a couple of neighborhood SSIDs. If one of their guests hops on to my Xfinity Wifi it is going to be with a weak signal. Their weak signal is going to drag down the performance of the wireless network for all the users on the access point. Comcast enabled the Xfinity Wifi on my modem and I had a five month battle with them to trying to get it turned off. Comcast kept telling me I did not have a wireless gateway and I must be seeing my neighbors signal. They never could fix their records so they sent me a new modem. A month later I got a letter saying they were turning on the Xfinity Wifi. This time I was able to log in and turn it off. curtis Curtis Parish Senior Network Engineer Middle Tennessee State University >In analyzing my neighbors who use comcast (I live in a townhouse and can see many access points) my biggest complaint is the the wifi pollution these comcast >router/access-points cause. From larrysheldon at cox.net Thu Dec 11 21:50:33 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 11 Dec 2014 15:50:33 -0600 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> Message-ID: <548A11A9.6060707@cox.net> On 12/11/2014 11:54, Livingood, Jason wrote: > Now..they are doing this on your electric bill and taking up space > (albeit a small amount of it) in your home. Tell me I need a tin-foil hat if you like, but in the current news there is reason to believe that the risk is real and actual that the police with their hot-shot-super-sniffer determine that your house is the source of a pedophile database operation supplying the neighborhood weirdos, and come around at 3 SM and shoot your dogs, lob a grenade into the baby's crib and eventually burn your house and wife down. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From owen at delong.com Thu Dec 11 21:54:08 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Dec 2014 13:54:08 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548902D7.60406@mompl.net> References: <548902D7.60406@mompl.net> Message-ID: <1610C6AD-85AB-4B7F-838D-B9B19FD400BE@delong.com> While I generally support the lawsuit, I have to question "a vast burden on their electric bill". Does an 802.11 transmitter that was already being used to support their own WiFi network that they are paying for really consume vastly more electricity to support a second SSID? In my experience, that claim is hard to fathom. Owen > On Dec 10, 2014, at 18:35 , Jeroen van Aart wrote: > > Why am I not surprised? > > Whose fault would it be if your comcast installed public wifi would be abused to download illegal material or launch a botnet, to name some random fun one could have on your behalf. :-/ > > (apologies if this was posted already, couldn't find an email about it on the list) > > http://www.theregister.co.uk/2014/12/10/disgruntled_customers_lob_sueball_at_comcast_over_public_wifi/ > > "A mother and daughter are suing Comcast claiming the cable giant's router in their home was offering public Wi-Fi without their permission. > > Comcast-supplied routers broadcast an encrypted, private wireless network for people at home, plus a non-encrypted network called XfinityWiFi that can be used by nearby subscribers. So if you're passing by a fellow user's home, you can lock onto their public Wi-Fi, log in using your Comcast username and password, and use that home's bandwidth. > > However, Toyer Grear, 39, and daughter Joycelyn Harris – who live together in Alameda County, California – say they never gave Comcast permission to run a public network from their home cable connection. > > In a lawsuit [PDF] filed in the northern district of the golden state, the pair accuse the ISP of breaking the Computer Fraud and Abuse Act and two other laws. > > Grear – a paralegal – and her daughter claim the Xfinity hotspot is an unauthorized intrusion into their private home, places a "vast" burden on electricity bills, opens them up to attacks by hackers, and "degrades" their bandwidth. > > "Comcast does not, however, obtain the customer's authorization prior to engaging in this use of the customer's equipment and internet service for public, non-household use," the suit claims. > > "Indeed, without obtaining its customers' authorization for this additional use of their equipment and resources, over which the customer has no control, Comcast has externalized the costs of its national Wi-Fi network onto its customers." > > The plaintiffs are seeking monetary damages for themselves and on behalf of all Comcast customers nation-wide in their class-action case – the service was rolled out to 20 million customers this year." > > -- > Earthquake Magnitude: 4.8 > Date: 2014-12-10 22:10:36.800 UTC > Date Local: 2014-12-10 13:10:36 PST > Location: 120km W of Panguna, Papua New Guinea > Latitude: -6.265; Longitude: 154.4004 > Depth: 35 km | e-quake.org From rs at seastrom.com Thu Dec 11 21:57:47 2014 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 11 Dec 2014 16:57:47 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: <21641.64933.650664.76727@world.std.com> (Barry Shein's message of "Thu, 11 Dec 2014 15:25:09 -0500") References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> <21641.64933.650664.76727@world.std.com> Message-ID: <86r3w5luhw.fsf@valhalla.seastrom.com> Barry Shein writes: > From: Randy Bush >>> We are now using ZFS RAIDZ and the question I ask myself is, why >>> wasn't I using ZFS years ago? >> >>because it is not production on linux, which i have to use because >>freebsd does not have kvm/ganeti. want zfs very very badly. snif. > > I keep reading zfs vs btrfs articles and...inconclusive. > > My problem with both is I need quotas, both file and "inode", and both > are weaker than ext4 on that, zfs is very weak on this, you can only > sort of simulate them. By file, you mean "disk space used"? By whom and where? Quotas and reservations on a per-dataset basis are pretty darned well supported in ZFS. As for inodes, well, since there isn't really such a thing as an inode in ZFS... what exactly are you trying to do here? -r From josh at imaginenetworksllc.com Thu Dec 11 21:57:54 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 11 Dec 2014 16:57:54 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <1610C6AD-85AB-4B7F-838D-B9B19FD400BE@delong.com> References: <548902D7.60406@mompl.net> <1610C6AD-85AB-4B7F-838D-B9B19FD400BE@delong.com> Message-ID: I would have to expect they're doing a virtual SSID which means 0 additional wattage. Worst case scenario it adds another radio of less than 5 watts of which is absolutely negligible if you're able to afford cable Internet service. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Dec 11, 2014 at 4:54 PM, Owen DeLong wrote: > While I generally support the lawsuit, I have to question "a vast burden > on their electric bill". > > Does an 802.11 transmitter that was already being used to support their > own WiFi network that they are paying for really consume vastly more > electricity to support a second SSID? In my experience, that claim is hard > to fathom. > > Owen > > > On Dec 10, 2014, at 18:35 , Jeroen van Aart wrote: > > > > Why am I not surprised? > > > > Whose fault would it be if your comcast installed public wifi would be > abused to download illegal material or launch a botnet, to name some random > fun one could have on your behalf. :-/ > > > > (apologies if this was posted already, couldn't find an email about it > on the list) > > > > > http://www.theregister.co.uk/2014/12/10/disgruntled_customers_lob_sueball_at_comcast_over_public_wifi/ > > > > "A mother and daughter are suing Comcast claiming the cable giant's > router in their home was offering public Wi-Fi without their permission. > > > > Comcast-supplied routers broadcast an encrypted, private wireless > network for people at home, plus a non-encrypted network called XfinityWiFi > that can be used by nearby subscribers. So if you're passing by a fellow > user's home, you can lock onto their public Wi-Fi, log in using your > Comcast username and password, and use that home's bandwidth. > > > > However, Toyer Grear, 39, and daughter Joycelyn Harris – who live > together in Alameda County, California – say they never gave Comcast > permission to run a public network from their home cable connection. > > > > In a lawsuit [PDF] filed in the northern district of the golden state, > the pair accuse the ISP of breaking the Computer Fraud and Abuse Act and > two other laws. > > > > Grear – a paralegal – and her daughter claim the Xfinity hotspot is an > unauthorized intrusion into their private home, places a "vast" burden on > electricity bills, opens them up to attacks by hackers, and "degrades" > their bandwidth. > > > > "Comcast does not, however, obtain the customer's authorization prior to > engaging in this use of the customer's equipment and internet service for > public, non-household use," the suit claims. > > > > "Indeed, without obtaining its customers' authorization for this > additional use of their equipment and resources, over which the customer > has no control, Comcast has externalized the costs of its national Wi-Fi > network onto its customers." > > > > The plaintiffs are seeking monetary damages for themselves and on behalf > of all Comcast customers nation-wide in their class-action case – the > service was rolled out to 20 million customers this year." > > > > -- > > Earthquake Magnitude: 4.8 > > Date: 2014-12-10 22:10:36.800 UTC > > Date Local: 2014-12-10 13:10:36 PST > > Location: 120km W of Panguna, Papua New Guinea > > Latitude: -6.265; Longitude: 154.4004 > > Depth: 35 km | e-quake.org > > From Jason_Livingood at cable.comcast.com Thu Dec 11 22:02:29 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 22:02:29 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <5629297.2859.1418331488210.JavaMail.root@benjamin.baylink.com> Message-ID: On 12/11/14, 4:47 PM, "Grant Ridder" > wrote: I think it may have already been slightly mentioned, but any reason why this is not being rolled out on a separate radio than the private customer facing one? Even if the bandwidth out to the internet is separated with DOCSIS channels, you are still using the same radio and one user streaming a large amount of data could bog down the radio. I have seen 1 or 2 clients destroy speed and cause large amounts (adding 100+ms) of latency for all clients connected to the same radio. The latest device (called an XB3, see http://corporate.comcast.com/comcast-voices/the-technology-behind-the-industrys-fastest-wireless-gateway) does have multiple radios. I’m not sure what the pros and cons are of dedicating individual radios to different SSIDs rather than letting some logic in the WiFi chipset and radios determine that stuff more dynamically. That’s probably best asked of a WiFi chipset engineer at Cisco or Qualcomm. Jason >From the URL above: By Jill Formichella, Director, Home Network Product Development, Comcast Cable in Internet Comcast’s new Xfinity Wireless Gateway, the DPC3941T, features the latest industry technology to provide superior performance and make it the fastest on the market. The DCP3941T features cutting edge 802.11ac Wi-Fi technology, a high power 3x3MIMO design with 3 spatial streams that can provide up to 1.3 Gbps of raw throughput, 80 MHz wide Wi-Fi channel support, and 256-QAM modulation. All of this means that the Comcast Gateway can provide increased range and wireless throughput. Third party lab tests demonstrated more than 700 Mbps of actual throughput, providing the fastest speeds for our customers and beating our competitors and many high-end retail products. Antenna Design After numerous design evaluations, the high power Wi-Fi antennas in the DPC3941T were positioned optimally to produce the most efficient gain patterns to offer the best performance. Fine-tuned calibration of EIRP helps to provide better range and throughput compared to other Wireless Gateways. Performance Tuning Our gateways are tested at Allion Engineering Services, a 3rd party Wi-Fi certification facility, as well as in our partners’ labs to constantly evaluate and improve the Gateway’s performance. Anechoic chamber based tests provide good insight into the Gateway’s maximum capabilities; controlled interference is injected on to Wi-Fi channels to evaluate gateway performance in congested and interference prone environments. Tests are also conducted in various test houses to measure performance in a real-world environment. Test results include RSSI Heatmaps showing coverage of the Wi-Fi signal, average throughput across multiple locations and rate vs. range (chamber tests). Finally the gateway is tested against our formalAcceptance Test Plan, which includes interoperability testing with popular consumer electronics, and then our devices are tested with real Comcast customers to ensure excellent performance in a variety of different conditions. Close collaboration with Cisco & Qualcomm Atheros Comcast collaborated closely with Cisco and Qualcomm Atheros from the early design stages to ensure the DPC3941T has the best Wi-Fi and antenna design and solid performance. The DPC3941T is the first Comcast device to support an 802.11ac high power amplifier solution boosting power by 3dB at the higher MCS rates. Also featured in the 3941T, which the previous Wireless Gateway 2 did not have, is a higher power Atom based CPU from Intel and an additional 512MB RAM to help future proof the device. From jeroen at massar.ch Thu Dec 11 22:06:36 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Thu, 11 Dec 2014 23:06:36 +0100 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <10570.1418321574@turing-police.cc.vt.edu> References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <10570.1418321574@turing-police.cc.vt.edu> Message-ID: <548A156C.3050206@massar.ch> On 2014-12-11 19:12, Valdis.Kletnieks at vt.edu wrote: > On Thu, 11 Dec 2014 18:04:20 +0000, "Livingood, Jason" said: > >> Right, so user name & password + MAC address. As more devices support >> things like Passpoint, this will get more sophisticated. > > OK, so it *does* do .1x authentication with the name/password, not just > mac address. That's a lot less scary.. :) It is WPA2-Enterprise (AES) even. Which is a reasonably ok Settings for Windows 8 for Windows are at: http://www.upc-cablecom.ch/content/dam/www-upc-cablecom-ch/Support/wifi-spots/steps/windows8/Anleitung%20Wi-Free_Windows%208_0714_e.pdf or platforms can be found at: http://www.upc-cablecom.ch/en/internet/wi-free/ As it is a thing crossing both Comcast + LibertyGlobal (and one can thus use Comcast logins on LG Wi-Free and vice versa...), I can only guess it is the exact same thing. Still, from a radio perspective and the spectrum being pretty full already, I don't like it a bit. Greets, Jeroen From jason at lixfeld.ca Thu Dec 11 22:08:16 2014 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 11 Dec 2014 17:08:16 -0500 Subject: Private ASNs in the wild Message-ID: I just fat fingered a regex that was intented to show how many private ASNs we’re using on our network for various things. The results of the fat fingers showed that there are an astronomical number of private ASNs in the wild. I checked the CIDR report, and those ASNs are shown there in a specific Bogon ASN report, but I’m surprised that as far as I can recall, there haven’t been any efforts made by the good netizens around these parts to bring awareness to this issue. Do we feel that it’s not that big of a deal? Have we not really been paying attention? Some other reason this seems to be a rather muted topic? From Jason_Livingood at cable.comcast.com Thu Dec 11 22:08:51 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 22:08:51 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548A1083.90104@vaxination.ca> References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> <548A1083.90104@vaxination.ca> Message-ID: On 12/11/14, 4:45 PM, "Jean-Francois Mezei" > wrote: Mr Livingood: Out of curiosity, had Comcast decided to use an "opt-in" instead of "opt-out" method, did your marketing dept have any idea of percentage of customer base who would have opted in ? No idea - I was just on the technical execution side of the project in the early phases. Behavioral economics would suggest that opt-in rates are almost always lower than opt-out. http://ozankocak.com/2011/01/18/dan-ariely-and-behavioral-economics-part–i/ . I suspect many tech companies have adopted similar views on opting in or out. Secondly, at a more technical level: In a MDU with a whole bunch of Comcast subscribers, could one router be able to detect existence of strong Xfinity signals and not enable its own ? This would reduce crowding of Wi-Fi spectrum. I take it such a feature would require special rogramming/firmware by modem/router manufacturer ? This is definitely specialized software logic and on the frontier of work called radio resource management. I am sure most WiFi chipsets have simple aspects of this built in but some companies are working on new technology & tools in this area for unlicensed spectrum like WiFi. Jason From rwebb at ropeguru.com Thu Dec 11 22:09:48 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Thu, 11 Dec 2014 17:09:48 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> Message-ID: Many read, but what choice do they have. In many cases Comcast is the only game in town and it is either agree, or have no "real" internet access at all. I am one that has opposed the auto opt-in of this setup. The main reason is that Comcast wants up to foot the bill for power and space for their benefit. While, yes, it is very minimal, what's good for the goose is good for the gander. By that I mean why shouldn't we be able to nickel and dime them like they do to us. We pay for internet access and they want to charge us for access AND to lease equipment. Yeah, sure, if you are a residential user or a business class user without a static ip, then you can go out and purchase your own device. But if you have BCI with static IP's then you are screwed. I have the 50/10 BCI with 5 static IP's and then I have to pay an additional $12.95 per month just for the crappy SMC device. If I remember correctly, residential pays $8.95 per month. Equipment should be included in the cost of the service, and always was in the past. But yet, Comcast has decided to nickel and dime us to death for everything, not just modem rentals. Robert On Thu, 11 Dec 2014 08:17:19 -0500 Scott Helms wrote: > Not a law, it's in their updated terms and conditions that no one >reads. > On Dec 11, 2014 8:12 AM, "William Herrin" wrote: > >> On Wed, Dec 10, 2014 at 9:35 PM, Jeroen van Aart >>wrote: >> > Whose fault would it be if your comcast installed public wifi >>would be >> > abused to download illegal material or launch a botnet, to name >>some >> random >> > fun one could have on your behalf. :-/ >> >> Doesn't work that way. Separate authenticated channel. Presents >> differently from you with a different IP address out on the >>Internet. >> >> What Comcast is stealing is electricity. Pennies per customer times >>a >> boatload of customers. >> >> theft n. the generic term for all crimes in which a person >> intentionally and fraudulently takes personal property of another >> without permission or consent and with the intent to convert it to >>the >> taker's use (including potential sale). In many states, if the value >> of the property taken is low (for example, less than $500) the crime >> is "petty theft," >> >> Unless of course the knucklehead jurisdiction passed a law to allow >> it. I'm betting they didn't. >> >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Owner, Dirtside Systems ......... Web: >> May I solve your unusual networking challenges? >> From jfbeam at gmail.com Thu Dec 11 22:19:44 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 11 Dec 2014 17:19:44 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: On Thu, 11 Dec 2014 16:41:24 -0500, Livingood, Jason wrote: > ...But 2.4GHz was a bit of a mess before we came along with this service. So, knowing the house is on fire, you bring a can of gas to put it out. You aren't f'ing helping. Of course, since Comcast didn't spring for separate radios, it'll be riding what ever channel the customer's WiFi is using. Thus, interfering with *their* use of WiFi. From josh at imaginenetworksllc.com Thu Dec 11 22:26:37 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 11 Dec 2014 17:26:37 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: Not correct. If it's on one radio it's using the same RF space it was before, just with a virtual SSID. Just like the atheros or Ruckus stuff - it's the same RF space with an additional BSSID bridged to a different software bridge or pseudo interface. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Dec 11, 2014 at 5:19 PM, Ricky Beam wrote: > On Thu, 11 Dec 2014 16:41:24 -0500, Livingood, Jason < > Jason_Livingood at cable.comcast.com> wrote: > >> ...But 2.4GHz was a bit of a mess before we came along with this service. >> > > So, knowing the house is on fire, you bring a can of gas to put it out. > You aren't f'ing helping. > > Of course, since Comcast didn't spring for separate radios, it'll be > riding what ever channel the customer's WiFi is using. Thus, interfering > with *their* use of WiFi. > From jra at baylink.com Thu Dec 11 22:29:30 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 11 Dec 2014 17:29:30 -0500 (EST) Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548A0DEC.4060200@cox.net> Message-ID: <8111093.2889.1418336970688.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Larry Sheldon" > On 12/11/2014 07:10, William Herrin wrote: > > > What Comcast is stealing is electricity. Pennies per customer times > > a boatload of customers. > > .....and floorspace, physical security, air conditioning, and all > sorts of labor overheads. Nope; at that stage, Larry, you're makin it up. In the particular case we're talking about here, Comcast -- who are not my favorite people by any means -- have *enabled a feature built into the terminal device they're provisioning*. It *might* increase the overall power consumption of that device by as much as 5-10 Wh/*month*. The increase in A/C won't register on the chart. Physical security is no different than it was otherwise: none. And floorspace and labor? It is, as they say, to laugh. If we want to diss Comcast, let us not descend to things they *are not* doing; there are plenty of dissable things they *are* doing. Cheers, -- jr 'credibility: it matters' a -- 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 spencerg at frii.net Thu Dec 11 22:32:06 2014 From: spencerg at frii.net (Spencer Gaw) Date: Thu, 11 Dec 2014 15:32:06 -0700 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: <548A1B66.2020900@frii.net> Your reading comprehension could use some work: "The latest device (called an XB3, see http://corporate.comcast.com/comcast-voices/the-technology-behind-the-industrys-fastest-wireless-gateway) does have multiple radios" Regards, SG On 12/11/2014 3:19 PM, Ricky Beam wrote: > On Thu, 11 Dec 2014 16:41:24 -0500, Livingood, Jason > wrote: >> ...But 2.4GHz was a bit of a mess before we came along with this >> service. > > So, knowing the house is on fire, you bring a can of gas to put it > out. You aren't f'ing helping. > > Of course, since Comcast didn't spring for separate radios, it'll be > riding what ever channel the customer's WiFi is using. Thus, > interfering with *their* use of WiFi. From jra at baylink.com Thu Dec 11 22:42:16 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 11 Dec 2014 17:42:16 -0500 (EST) Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <1610C6AD-85AB-4B7F-838D-B9B19FD400BE@delong.com> Message-ID: <31917603.2893.1418337736448.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > Does an 802.11 transmitter that was already being used to support > their own WiFi network that they are paying for really consume vastly > more electricity to support a second SSID? In my experience, that > claim is hard to fathom. If popular, the radio might have a higher transmit duty cycle, but as I suggest in another post, maybe watthours per month. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From tim.upthegrove at gmail.com Thu Dec 11 21:37:22 2014 From: tim.upthegrove at gmail.com (Tim Upthegrove) Date: Thu, 11 Dec 2014 16:37:22 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548A038F.8060109@dougbarton.us> References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: On Thu, Dec 11, 2014 at 3:50 PM, Doug Barton wrote: > > My concerns are that apparently customers are not informed about the thing > before it gets enabled, and the issue of wifi density that was raised by > several people here. If you have an apartment building for example, where a > significant majority of the tenants are Comcast customers (cuz in 'murica > we loves us some monopolies) I see a lot of strong xfinity signals stomping > on an already crowded 2.4 G spectrum. > > So just to be clear, I'm not being critical at this point, I'm simply > interested in separating the facts from the hype. > Here is an additional data point that can hopefully satisfy your curiosity. TL;DR: In my experience, Comcast appeared to hide the fact that they are running this new wifi service by using my device, and they pushed the idea of upgrading my router by saying it would improve uplink speeds (which may be true). IF you find out that the XFINITY wifi service will be running on your device, then it is not hard to disable it. I received an email from Comcast that they were offering a free upgraded wifi router for my home. Here is a snippet from the email: """ At Comcast, we're constantly improving our Internet network. For you, that means access to faster in-home WiFi speeds, more bandwidth, and more coverage for your whole home. With all of these technology advancements, devices need to be upgraded in order to fully maximize our service offerings. Recently, we increased the speeds of some of our popular Internet tiers at no additional cost to you. Our records indicate that your cable modem needs to be upgraded in order to ensure you're getting the most out of your XFINITY® Internet service. To ensure you're receiving the full benefits included with your service, we want to replace your existing modem with a Wireless Gateway free of charge. """ The rest of the email is instructions and contact information for customer service. I didn't really pay attention to much else (e.g. separate emails or marketing campaigns), but why not mention that by installing this new device, I would be enabling the XFINITY wifi service in this email? At the time, I kept wondering what the real incentive was for Comcast to send me anything for free. The first step of the provided instructions in the email was a link, which I assumed would walk me through some steps to sign up. I think that brought be to a login screen, so I logged in. As soon as I did that, I was notified that my new device was on its way. All I really wanted was more information, so this annoyed me quite a bit. After I received the device, I decided to give it a try. Before I did, I researched a bit online and figured out that they were planning on offering the XFINITY wifi service from my device. The management interface for the device is a bit limited. It was annoying enough that I *wanted* to go back to my old setup, but it was not annoying enough for me to actually jump through the hoops I'd have to go through to actually carry that out. I agree that the XFINITY wifi service in it of itself is not a bad thing, but I personally didn't want to run it on my device. I agree with folks saying it is easy to opt out. Instructions for disabling the public connection were easy to find and simple to perform. I am comfortable with my current situation, but the whole process left me with a distrust of clicking any link that Comcast provides me in the future when the email says "ACTION REQUIRED" in the subject. As a consumer, I personally felt that I had been misled, but I was glad that the opt-out process was simple. -- Tim Upthegrove From marka at isc.org Thu Dec 11 22:44:39 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 12 Dec 2014 09:44:39 +1100 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: Your message of "Thu, 11 Dec 2014 17:09:48 -0500." References: <548902D7.60406@mompl.net> Message-ID: <20141211224439.A9269254D3DD@rock.dv.isc.org> In message , "Robert Webb" writes: > Many read, but what choice do they have. In many cases Comcast is the only > game in town and it is either agree, or have no "real" internet access at > all. > > I am one that has opposed the auto opt-in of this setup. The main reason is > that Comcast wants up to foot the bill for power A couple of cents a year on top of what you are paying to run the WiFi modem for yourself. > and space for their benefit. What space? It is the WiFi modem you are already using. Unless it requires a seperate external aerial I don't see any extra space. Even if it does require a seperate external aerial it is highly unlikely that you would be using the space the aerial occupies anyway. > While, yes, it is very minimal, what's good for the goose is good > for the gander. By that I mean why shouldn't we be able to nickel and dime > them like they do to us. We pay for internet access and they want to charge > us for access AND to lease equipment. Yeah, sure, if you are a residential > user or a business class user without a static ip, then you can go out and > purchase your own device. But if you have BCI with static IP's then you are > screwed. I have the 50/10 BCI with 5 static IP's and then I have to pay an > additional $12.95 per month just for the crappy SMC device. If I remember > correctly, residential pays $8.95 per month. > > Equipment should be included in the cost of the service, and always was in > the past. But yet, Comcast has decided to nickel and dime us to death for > everything, not just modem rentals. > > Robert > > On Thu, 11 Dec 2014 08:17:19 -0500 > Scott Helms wrote: > > Not a law, it's in their updated terms and conditions that no one > >reads. > > On Dec 11, 2014 8:12 AM, "William Herrin" wrote: > > > >> On Wed, Dec 10, 2014 at 9:35 PM, Jeroen van Aart > >>wrote: > >> > Whose fault would it be if your comcast installed public wifi > >>would be > >> > abused to download illegal material or launch a botnet, to name > >>some > >> random > >> > fun one could have on your behalf. :-/ > >> > >> Doesn't work that way. Separate authenticated channel. Presents > >> differently from you with a different IP address out on the > >>Internet. > >> > >> What Comcast is stealing is electricity. Pennies per customer times > >>a > >> boatload of customers. > >> > >> theft n. the generic term for all crimes in which a person > >> intentionally and fraudulently takes personal property of another > >> without permission or consent and with the intent to convert it to > >>the > >> taker's use (including potential sale). In many states, if the value > >> of the property taken is low (for example, less than $500) the crime > >> is "petty theft," > >> > >> Unless of course the knucklehead jurisdiction passed a law to allow > >> it. I'm betting they didn't. > >> > >> > >> Regards, > >> Bill Herrin > >> > >> > >> -- > >> William Herrin ................ herrin at dirtside.com bill at herrin.us > >> Owner, Dirtside Systems ......... Web: > >> May I solve your unusual networking challenges? > >> > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Jason_Livingood at cable.comcast.com Thu Dec 11 22:46:24 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 11 Dec 2014 22:46:24 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: On 12/11/14, 5:19 PM, "Ricky Beam" wrote: >On Thu, 11 Dec 2014 16:41:24 -0500, Livingood, Jason > wrote: >> ...But 2.4GHz was a bit of a mess before we came along with this >>service. > >So, knowing the house is on fire, you bring a can of gas to put it out. >You aren't f'ing helping. I think that¹s a bit overblown but respect your opinion. But as you know a massive amount of consumer electronics and whatnot if WiFi-enabled. By this logic they are all dumping gas on the fire as well. Jason From jfmezei_nanog at vaxination.ca Thu Dec 11 22:54:11 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 11 Dec 2014 17:54:11 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: <548A2093.6010503@vaxination.ca> On 14-12-11 16:37, Tim Upthegrove wrote: > At the > time, I kept wondering what the real incentive was for Comcast to send me > anything for free. It pays to move customer with old DOCSIS-2 modems to DOCSIS 3 ones as they will even out usage on multiple channels instead of congesting the one channel used by DOCSIS-2 modems. Similarly, **if** a cableco has moved to 8 channel DOCSIS on the coax, it may cost less to send new 8 channel capable modems to customers compared to all the node splits they would need due to congestion on the 4 channels. OR It may have just been marketing to deploy that Xfinity wi-fi thing, thinking it would be seen as a marketing advantage for Comcast instead of the marketing liability it has become. From jfbeam at gmail.com Thu Dec 11 22:54:44 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 11 Dec 2014 17:54:44 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: On Thu, 11 Dec 2014 17:26:37 -0500, Josh Luthman wrote: > Not correct. If it's on one radio it's using the same RF space it was > before, just with a virtual SSID. Just like the atheros or Ruckus stuff > it's the same RF space with an additional BSSID bridged to a different > software bridge or pseudo interface. It's an either/or... they have their own radio, thus adding to an already congested RF arena, or they ride the same channel as the customer, thus consuming (degrading) their wifi bandwidth. (bring an 802.11b device to the part if you want to see just how ugly that can get.) From ml at kenweb.org Thu Dec 11 22:55:26 2014 From: ml at kenweb.org (ML) Date: Thu, 11 Dec 2014 17:55:26 -0500 Subject: Private ASNs in the wild In-Reply-To: References: Message-ID: <548A20DE.5070901@kenweb.org> I had resurrected a similar thread last year: http://www.gossamer-threads.com/lists/nanog/users/123155 There are sloppy networks out there. If it was a big enough problem all you'd need is a few key networks drop those prefixes and we'd have a...slightly less sloppy Internet? On 12/11/2014 5:08 PM, Jason Lixfeld wrote: > I just fat fingered a regex that was intented to show how many private ASNs we’re using on our network for various things. The results of the fat fingers showed that there are an astronomical number of private ASNs in the wild. I checked the CIDR report, and those ASNs are shown there in a specific Bogon ASN report, but I’m surprised that as far as I can recall, there haven’t been any efforts made by the good netizens around these parts to bring awareness to this issue. > > Do we feel that it’s not that big of a deal? Have we not really been paying attention? Some other reason this seems to be a rather muted topic? From jeffshultz at sctcweb.com Thu Dec 11 22:57:38 2014 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Thu, 11 Dec 2014 14:57:38 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: <548A2162.5040105@sctcweb.com> On 12/11/2014 2:46 PM, Livingood, Jason wrote: > On 12/11/14, 5:19 PM, "Ricky Beam" wrote: > > >> On Thu, 11 Dec 2014 16:41:24 -0500, Livingood, Jason >> wrote: >>> ...But 2.4GHz was a bit of a mess before we came along with this >>> service. >> >> So, knowing the house is on fire, you bring a can of gas to put it out. >> You aren't f'ing helping. > > I think that¹s a bit overblown but respect your opinion. But as you know a > massive amount of consumer electronics and whatnot if WiFi-enabled. By > this logic they are all dumping gas on the fire as well. > > Jason > I think it's pretty obvious that 2.4Ghz is becoming the new 900Mhz - a place you don't want to be. 5Ghz, here we come! -- Jeff Shultz From jfmezei_nanog at vaxination.ca Thu Dec 11 23:01:20 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 11 Dec 2014 18:01:20 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <20141211224439.A9269254D3DD@rock.dv.isc.org> References: <548902D7.60406@mompl.net> <20141211224439.A9269254D3DD@rock.dv.isc.org> Message-ID: <548A2240.7090504@vaxination.ca> On 14-12-11 17:44, Mark Andrews wrote: > What space? It is the WiFi modem you are already using. Unless > it requires a seperate external aerial I don't see any extra space. Matter of principle. Comcast are using space/power/shelter in your home to create a service which they market for their own benefit. ATM companies have to pay rent to place a standalone ATM in a convenience store or shopping mall. Now, had Comcast pitched it as the Wi-Fi benefiting YOU because your freinds you use their Comcast credentials to access your Wi-Fi, then customers would not see this as Comcast using your hardware for its own benefit. But pitching the service as allowing strangers on the street to use your router has huge perception problem, even if the hardware implementation doesn't really impact you. Consider how differently the service would be perceived if: Comcast had announced you get $3.00 rebate per month to enable Xfinity on your account. An opt-in with financial incentive would have had far greater success and positive media than what they are getting now. From jfbeam at gmail.com Thu Dec 11 23:04:44 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 11 Dec 2014 18:04:44 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> <548A1083.90104@vaxination.ca> Message-ID: On Thu, 11 Dec 2014 17:08:51 -0500, Livingood, Jason wrote: > ... Behavioral economics would suggest that opt-in rates are almost > always lower than opt-out. There's two ways to look at it: a) Everyone knows about it. Few would bother to opt-in, many would bother to opt-out. b) Few ("no one") knows about it. Few will (can) opt-in to service they aren't aware of. Likewise, how does one opt-out if they don't know about it. (FTR, the last one is what's going on here. It's relatively unknown, and many are apparently opting out as soon as they a) hear about it, and b) learn *how* to opt-out. But, yes, there are those too lazy to bother.) > This is definitely specialized software logic and on the frontier of > work called radio resource management. Not really. It's just a simple scan of the channels looking for any xfinity wifi *BEFORE* blindly enabling the service. Yes, it's more work than the built-into-the-chipset automatic channel selection. But if the service has it's own radio, it's lame not to do this. From jfbeam at gmail.com Thu Dec 11 23:09:44 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 11 Dec 2014 18:09:44 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548A1B66.2020900@frii.net> References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> <548A1B66.2020900@frii.net> Message-ID: On Thu, 11 Dec 2014 17:32:06 -0500, Spencer Gaw wrote: > Your reading comprehension could use some work: That was post *AFTER* my comment. And it doesn't say the xfinity service is running on its own dedicated radio, just that it has more than one radio in it -- which it would having ac (5ghz only) and b/g/n capability. From marka at isc.org Thu Dec 11 23:10:32 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 12 Dec 2014 10:10:32 +1100 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: Your message of "Thu, 11 Dec 2014 18:01:20 -0500." <548A2240.7090504@vaxination.ca> References: <548902D7.60406@mompl.net> <20141211224439.A9269254D3DD@rock.dv.isc.org> <548A2240.7090504@vaxination.ca> Message-ID: <20141211231032.C06F2254DBF8@rock.dv.isc.org> In message <548A2240.7090504 at vaxination.ca>, Jean-Francois Mezei writes: > On 14-12-11 17:44, Mark Andrews wrote: > > > What space? It is the WiFi modem you are already using. Unless > > it requires a seperate external aerial I don't see any extra space. > > Matter of principle. Comcast are using space/power/shelter in your home > to create a service which they market for their own benefit. ATM > companies have to pay rent to place a standalone ATM in a convenience > store or shopping mall. This is not a standalone device. This is a virtual device which you control whether it is on or off. > Now, had Comcast pitched it as the Wi-Fi benefiting YOU because your > freinds you use their Comcast credentials to access your Wi-Fi, then > customers would not see this as Comcast using your hardware for its own > benefit. They do. Your friends don't even need to be Comcast customers. That said allowing the home owner to remove the time limits for their guests would make this similar to the home owner having a Guest SSID. > But pitching the service as allowing strangers on the street to use your > router has huge perception problem, even if the hardware implementation > doesn't really impact you. > > Consider how differently the service would be perceived if: > > Comcast had announced you get $3.00 rebate per month to enable Xfinity > on your account. An opt-in with financial incentive would have had far > greater success and positive media than what they are getting now. > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jfbeam at gmail.com Thu Dec 11 23:19:44 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 11 Dec 2014 18:19:44 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: On Thu, 11 Dec 2014 17:46:24 -0500, Livingood, Jason wrote: > By this logic they are all dumping gas on the fire as well. I'm not denying it's a big fire. But adding additional 2.4Ghz radios Is. Not. Helping. Because "everything else is" is not a reason for one of the largest companies in the country to be so self-serving. (Of course, *everyone* expects this sort of behavior from cableco's -- and telcos.) From jra at baylink.com Thu Dec 11 23:30:50 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 11 Dec 2014 18:30:50 -0500 (EST) Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <20141211231032.C06F2254DBF8@rock.dv.isc.org> Message-ID: <19950282.2897.1418340650252.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" > > Now, had Comcast pitched it as the Wi-Fi benefiting YOU because your > > freinds you use their Comcast credentials to access your Wi-Fi, then > > customers would not see this as Comcast using your hardware for its > > own > > benefit. > > They do. Your friends don't even need to be Comcast customers. They do? They don't? That's not the assumption that's been being made here... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From larrysheldon at cox.net Thu Dec 11 23:33:44 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 11 Dec 2014 17:33:44 -0600 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: Message-ID: <548A29D8.9070309@cox.net> On 12/11/2014 16:29, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Larry Sheldon" > >> On 12/11/2014 07:10, William Herrin wrote: >> >>> What Comcast is stealing is electricity. Pennies per customer times >>> a boatload of customers. >> >> .....and floorspace, physical security, air conditioning, and all >> sorts of labor overheads. > > Nope; at that stage, Larry, you're makin it up. > > In the particular case we're talking about here, Comcast -- who are not my > favorite people by any means -- have *enabled a feature built into the > terminal device they're provisioning*. It *might* increase the overall > power consumption of that device by as much as 5-10 Wh/*month*. The > increase in A/C won't register on the chart. Physical security is no different > than it was otherwise: none. And floorspace and labor? It is, as they say, > to laugh. > > If we want to diss Comcast, let us not descend to things they *are not* doing; > there are plenty of dissable things they *are* doing. Do me a favor and re-write your message from the standpoint of what the "provider" would have to pay for if they were not extorting the customers. You don't need to respond unless that changes your thinking. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From marka at isc.org Thu Dec 11 23:40:38 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 12 Dec 2014 10:40:38 +1100 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: Your message of "Thu, 11 Dec 2014 18:30:50 -0500." <19950282.2897.1418340650252.JavaMail.root@benjamin.baylink.com> References: <19950282.2897.1418340650252.JavaMail.root@benjamin.baylink.com> Message-ID: <20141211234038.A21F9254E4BA@rock.dv.isc.org> In message <19950282.2897.1418340650252.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > > > Now, had Comcast pitched it as the Wi-Fi benefiting YOU because your > > > freinds you use their Comcast credentials to access your Wi-Fi, then > > > customers would not see this as Comcast using your hardware for its > > > own > > > benefit. > > > > They do. Your friends don't even need to be Comcast customers. > > They do? They don't? That's not the assumption that's been being made > here... Read the FAQ link posted earlier. This was also posted on /. where non customers were using the service in the middle of nowhere. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From khelms at zcorum.com Thu Dec 11 23:42:37 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 11 Dec 2014 18:42:37 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548A29D8.9070309@cox.net> References: <548A29D8.9070309@cox.net> Message-ID: Perhaps we should balance that against what a subscriber might pay for bandwidth while away from home, especially in Europe. On Dec 11, 2014 6:35 PM, "Larry Sheldon" wrote: > On 12/11/2014 16:29, Jay Ashworth wrote: > >> ----- Original Message ----- >> >>> From: "Larry Sheldon" >>> >> >> On 12/11/2014 07:10, William Herrin wrote: >>> >>> What Comcast is stealing is electricity. Pennies per customer times >>>> a boatload of customers. >>>> >>> >>> .....and floorspace, physical security, air conditioning, and all >>> sorts of labor overheads. >>> >> >> Nope; at that stage, Larry, you're makin it up. >> >> In the particular case we're talking about here, Comcast -- who are not my >> favorite people by any means -- have *enabled a feature built into the >> terminal device they're provisioning*. It *might* increase the overall >> power consumption of that device by as much as 5-10 Wh/*month*. The >> increase in A/C won't register on the chart. Physical security is no >> different >> than it was otherwise: none. And floorspace and labor? It is, as they >> say, >> to laugh. >> >> If we want to diss Comcast, let us not descend to things they *are not* >> doing; >> there are plenty of dissable things they *are* doing. >> > > Do me a favor and re-write your message from the standpoint of what the > "provider" would have to pay for if they were not extorting the customers. > You don't need to respond unless that changes your thinking. > > -- > The unique Characteristics of System Administrators: > > The fact that they are infallible; and, > > The fact that they learn from their mistakes. > > > Quis custodiet ipsos custodes > From alvarezp at alvarezp.ods.org Thu Dec 11 23:53:28 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Thu, 11 Dec 2014 15:53:28 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> Message-ID: <548A2E78.1050208@alvarezp.ods.org> On 10/12/14 18:41, Charles Mills wrote: > In the US at least you have to authenticate with your Comcast credentials > and not like a traditional open wifi where you can just make up an email > and accept the terms of service. I also understand that it is a different > IP than the subscriber. Based on this the subscriber should be protected > from anyone doing anything illegal and causing the SWAT team to pay a > visit. I haven't upgraded my gear though. > > Now..they are doing this on your electric bill and taking up space (albeit > a small amount of it) in your home. Even if that weren't the problem, using third-party premises to host services without authorization is illegal (or should be). Also, using installed devices for purposes other than the receiving the service. Best regards. From Jason_Livingood at cable.comcast.com Fri Dec 12 00:32:52 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 12 Dec 2014 00:32:52 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: On 12/11/14, 4:37 PM, "Tim Upthegrove" wrote: >I received an email from Comcast that they were offering a free upgraded >wifi router for my home. Yes, since the main service tier doubled from 25 Mbps to 50 Mbps (some went to 105 Mbps) that means DOCSIS 2.0 devices were no longer up to the task. If you got an email like that you had a D2.0 device and needed a D3.0 device. A side benefit is the device either now or very soon supports native dual stack. Jason From owen at delong.com Fri Dec 12 00:33:03 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Dec 2014 16:33:03 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548A2E78.1050208@alvarezp.ods.org> References: <548902D7.60406@mompl.net> <548A2E78.1050208@alvarezp.ods.org> Message-ID: <1DB4C29D-6C9A-41F6-951C-5E5BA0D36CBC@delong.com> This thread is out of control... I will attempt to summarize the salient points in hopes we can stop arguing about inaccurate minutiae. I don't like the way Comcast went about doing what they are doing, but I do like the general idea... Reasonably ubiquitous free WiFi for your subscribers when they are away from their home location is not a bad idea. The way Comcast has gone about it is a bit underhanded and sneaky. The flaws in their plan are not technical, they are ethical and communication-oriented in nature. To wit: There's nothing wrong with Comcast adding a separate SSID with dedicated upstream bandwidth on a WAP I rent from them[1]. There's no theft of power, as the amount of additional power used is imperceptible, if any. There's no theft of space, climate control, or other overhead as this is performed by existing CPE. There's probably no legal liability being transferred by this to the subscriber. In short, the only thing really truly wrong with this scenario is that Comcast is using equipment that the subscriber should have exclusive control over (they are renting it, so while Comcast retains ownership, they have relinquished most rights of control to the "tenant") how the device is used. As I see it, there are a couple of ways Comcast could have made this an entirely voluntary (opt-in) program and communicated it to their customers positively and achieved a high compliance rate. Unfortunately, in an action worthy of their title as "America's worst company", instead of positively communicating with their customers and seeking cooperation and permission to build out something cool for everyone, they instead simply inflicted this service on chosen subscribers without notice, warning, or permission. In short, Comcast's biggest real failure here is the failure to ask permission from the subscriber before doing this on equipment the subscriber should control. Arguing that some obscure phrase in updated ToS documents that nobody ever reads permits this may keep Comcast from losing a law suit (though I hope not), but it certainly won't improve their standing in the court of public opinion. OTOH, Comcast seems to consider the court of public opinion mostly irrelevant or they would be trying to find ways not to retain their title as "America's worst company". I will say that my reaction to this, if Comcast had done it to me would be quite different depending on how it was executed... Scenario A: Positive outcome CC "Mr. DeLong, we would like to replace your existing cablemodem with a DOCSIS 3.0 unit and give you faster service for free. However, the catch is that we want to put up an additional 2.4Ghz WiFi SSID on the WAP built into the modem that will use separate cable channels (i.e. won't affect your bandwidth) that our other subscribers can use once they authenticate when they are in range. Would you mind if we did that?" ME "Well, since I currently own my modem, and it's already DOCSIS 3, I don't want to give up any of my existing functionality and I have no desire to start paying rental fees. If you can provide the new one without monthly fees and it will do everything my current one does (e.g. operating in transparent bridge mode), then I don't see any reason why not." Scenario B: Class Action? CC "" ME -- Discovers Xfinity WiFi SSID and wonders "WTF is this?" -- Tracks down source of SSID and discovers CC Modem in my garage is doing this. -- Calls Comcast "WTF?" CC "blah blah blah, updated ToS, you agreed, blah blah" ME Starts calling lawyers ======== Unfortunately, it seems to me that Comcast (and apparently other Cable WiFi assn. members) have chosen Scenario B. Very unfortunate, considering how much easier and more productive scenario A could be. Owen From larrysheldon at cox.net Fri Dec 12 00:51:53 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 11 Dec 2014 18:51:53 -0600 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548A29D8.9070309@cox.net> Message-ID: <548A3C29.2020903@cox.net> On 12/11/2014 17:42, Scott Helms wrote: > Perhaps we should balance that against what a subscriber might pay for > bandwidth while away from home, especially in Europe. Why would that interest me--I have no interest in traveling anywhere. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From khelms at zcorum.com Fri Dec 12 01:04:30 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 11 Dec 2014 20:04:30 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <548A3C29.2020903@cox.net> References: <548A29D8.9070309@cox.net> <548A3C29.2020903@cox.net> Message-ID: Your chances of traveling somewhere ate probably several orders of magnitude higher than Comcast being interested in paid hosting in your house :) On Dec 11, 2014 6:53 PM, "Larry Sheldon" wrote: > On 12/11/2014 17:42, Scott Helms wrote: > >> Perhaps we should balance that against what a subscriber might pay for >> bandwidth while away from home, especially in Europe. >> > > Why would that interest me--I have no interest in traveling anywhere. > > > -- > The unique Characteristics of System Administrators: > > The fact that they are infallible; and, > > The fact that they learn from their mistakes. > > > Quis custodiet ipsos custodes > From dennis at justipit.com Fri Dec 12 01:08:17 2014 From: dennis at justipit.com (=?utf-8?B?ZGVubmlzQGp1c3RpcGl0LmNvbQ==?=) Date: Thu, 11 Dec 2014 20:08:17 -0500 Subject: =?utf-8?B?UmU6IENhcnJpZXItZ3JhZGUgRERvUyBBdHRhY2sgbWl0aWdhdGlvbiBhcHBsaWFu?= =?utf-8?B?Y2U=?= Message-ID: Yes. The industry is undergoing a shift from cloud or premise based ddos appliance to a hybrid model where some or all (premise gear and cloud scrubbing) of the solution is offered as a service. Equipment vendors such as Radware & Arbor offer either directly or through partnerships also seeing the cloud scrubbing providers to offer premise gear. Sent from my Sprint phone. ----- Reply message ----- From: "Javier J" To: "James Braunegg" Cc: "nanog" Subject: Carrier-grade DDoS Attack mitigation appliance Date: Wed, Dec 10, 2014 11:39 PM What about DDOS protection as a service? is that something that is being offered by more than a few vendors? I know of only one that exists through a friend. They basically start advertising your bgp routes, filter out the junk, and send the good traffic back to you. On Wed, Dec 10, 2014 at 8:08 AM, James Braunegg wrote: > Dear All > > > > We use a combination of NSFOCUS hardware (ADS, ADS-m and NTA along with > A10 Hardware) > > > > All of which I highly recommend ! > > > > Kindest Regards > > > James Braunegg > P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 > E: james.braunegg at micron21.com | > ABN: 12 109 977 666 > W: www.micron21.com/ddos-protection< > http://www.micron21.com/ddos-protection> T: @micron21 > > > [Description: Description: Description: Description: M21.jpg] > This message is intended for the addressee named above. It may contain > privileged or confidential information. If you are not the intended > recipient of this message you must not use, copy, distribute or disclose it > to anyone other than the addressee. If you have received this message in > error please return the message to the sender by replying to it and then > delete the message from your computer. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Parrish, Luke > Sent: Wednesday, December 10, 2014 8:08 AM > To: J. Tozo > Cc: nanog > Subject: RE: Carrier-grade DDoS Attack mitigation appliance > > > > Switch to Nemo. > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of J. Tozo > > Sent: Monday, December 08, 2014 3:26 PM > > Cc: nanog > > Subject: Re: Carrier-grade DDoS Attack mitigation appliance > > > > We also evaluating another appliance to put in place of Arbor, their > "support" outside USA its a joke. > > > > On Mon, Dec 8, 2014 at 6:17 PM, Ammar Zuberi wrote: > > > > > Hi, > > > > > > We're currently running the Arbor Peakflow SP with the TMS and it > > > works very well for us. > > > > > > Best Regards, > > > > > > Ammar Zuberi > > > FastReturn, Inc > > > > > > > > > > > > > > > Direct Line: +971 50 394 7299 > > > Email: ammar at fastreturn.net > > > > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to whom they are > addressed. > > > If you have received it by mistake, please let us know by e-mail reply > > > and delete it from your system; you may not copy this message or > > > disclose its contents to anyone. Please note that any views or > > > opinions presented in this email are solely those of the author and do > > > not necessarily represent those of the company. Finally, the recipient > > > should check this email and any attachments for the presence of > > > viruses. The company accepts no liability for any damage caused by any > virus transmitted by this email. > > > > > > > On Dec 8, 2014, at 10:53 PM, Tony McKay > > > wrote: > > > > > > > > Does anyone on list currently use Peakflow SP from Arbor with TMS, > > > > and > > > is it truly a carrier grade DDoS detection and mitigation platform? > > > Anyone have any experience with Plixir? > > > > > > > > Tony McKay > > > > Dir. Of Network Operations > > > > Office: 870.336.3449 > > > > Mobile: 870.243.0058 > > > > -The boundary to your comfort zone fades a little each time you > > > > cross > > > it. Raise your limits by pushing them. > > > > > > > > This electronic mail transmission may contain confidential or > > > > privileged > > > information. If you believe that you have received this message in > > > error, please notify the sender by reply transmission and delete the > > > message without copying or disclosing it. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mohamed > > > > Kamal > > > > Sent: Sunday, December 07, 2014 2:10 PM > > > > To: nanog > > > > Subject: Carrier-grade DDoS Attack mitigation appliance > > > > > > > > > > > > Have anyone tried any DDoS attack mitigation appliance rather than > > > > Arbor > > > PeakFlow TMS? I need it to be carrier-grade in terms of capacity and > > > redundancy, and as far as I know, Arbor is the only product in the > > > market which offers a "clean pipe" volume of traffic, so if the DDoS > > > attack volume is, for example, 1Tbps, they will grant you for example > > > 50Gbps of clean traffic. > > > > > > > > Anyway, I'm open to other suggestions, and open-source products that > > > > can > > > do the same purpose, we have network development team that can work on > this. > > > > > > > > Thanks. > > > > > > > > -- > > > > Mohamed Kamal > > > > Core Network Sr. Engineer > > > > > > > > > > > > > > > > -- > > Grato, > > > > Tozo > > ________________________________ > > > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain proprietary, confidential and/or > legally 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 > received this in error, please contact the sender and delete the material > from all computers. > > > > ________________________________ > From wesley.george at twcable.com Fri Dec 12 01:09:44 2014 From: wesley.george at twcable.com (George, Wes) Date: Thu, 11 Dec 2014 20:09:44 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <5629297.2859.1418331488210.JavaMail.root@benjamin.baylink.com> References: <5629297.2859.1418331488210.JavaMail.root@benjamin.baylink.com> Message-ID: On 12/11/14, 3:58 PM, "Jay Ashworth" wrote: >Alas, I cannot accept George's assertion WG] well, perhaps you can accept Wes's assertion instead. ;-) >In residential areas (non-multi-unit), >this is only going to help out *Comcast subscribers*. If you have random >visitors over, it won't help them, as they can't get authed to the >service. WG] Given an average Comcast service area, there is a nonzero chance that visitors are Comcast customers as well. Given that there are multiple such service areas, to the tune of 19M+ subs, this is true even if the visitors aren't local. The chances go up if the AP will accept roaming credentials from customers of other members of the Cable Wifi initiative (though I am not sure that this is the case on the resi APs). >And it doesn't let you help your neighbors for the same reason: if they >have their own creds for it, then they don't need your AP since they have >one. WG] unless they're over visiting you and would like to use WiFi to avoid using metered (or slow, or both) mobile data, or your AP's signal happens to be stronger from that one corner of their house/yard than theirs, or theirs has had its magic smoke released, or... > >No, I'm having a hard time figuring out what the use case *is* for this >service >as deployed against *residential* hardware, myself... WG] it's a feature or additional service that can be offered to customers to use if they find it useful (or not if they don't), done with the capabilities of the existing hardware, so the bar for "use case" is pretty low. Wes (not) George Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From matthew at matthew.at Fri Dec 12 01:10:23 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 11 Dec 2014 17:10:23 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <1DB4C29D-6C9A-41F6-951C-5E5BA0D36CBC@delong.com> References: <548902D7.60406@mompl.net> <548A2E78.1050208@alvarezp.ods.org> <1DB4C29D-6C9A-41F6-951C-5E5BA0D36CBC@delong.com> Message-ID: <0C148C8B-5713-4E7E-9624-640123DDA446@matthew.at> Lots of other good reasons to oppose this (Comcast customers parking in your driveway to get the service, etc.) What would you tell AT&T if they installed a coin phone at every residential outside demarc? Matthew Kaufman (Sent from my iPhone) > On Dec 11, 2014, at 4:33 PM, Owen DeLong wrote: > > This thread is out of control... I will attempt to summarize the salient points in hopes we can stop arguing about inaccurate minutiae. > > I don't like the way Comcast went about doing what they are doing, but I do like the general idea... > > Reasonably ubiquitous free WiFi for your subscribers when they are away from their home location is not a bad idea. > > The way Comcast has gone about it is a bit underhanded and sneaky. The flaws in their plan are not technical, they are ethical and communication-oriented in nature. > > To wit: > There's nothing wrong with Comcast adding a separate SSID with dedicated upstream bandwidth on a WAP I rent from them[1]. > There's no theft of power, as the amount of additional power used is imperceptible, if any. > There's no theft of space, climate control, or other overhead as this is performed by existing CPE. > There's probably no legal liability being transferred by this to the subscriber. > > In short, the only thing really truly wrong with this scenario is that Comcast is using equipment that the subscriber should have exclusive control over (they are renting it, so while Comcast retains ownership, they have relinquished most rights of control to the "tenant") how the device is used. > > As I see it, there are a couple of ways Comcast could have made this an entirely voluntary (opt-in) program and communicated it to their customers positively and achieved a high compliance rate. Unfortunately, in an action worthy of their title as "America's worst company", instead of positively communicating with their customers and seeking cooperation and permission to build out something cool for everyone, they instead simply inflicted this service on chosen subscribers without notice, warning, or permission. > > In short, Comcast's biggest real failure here is the failure to ask permission from the subscriber before doing this on equipment the subscriber should control. > > Arguing that some obscure phrase in updated ToS documents that nobody ever reads permits this may keep Comcast from losing a law suit (though I hope not), but it certainly won't improve their standing in the court of public opinion. OTOH, Comcast seems to consider the court of public opinion mostly irrelevant or they would be trying to find ways not to retain their title as "America's worst company". > > I will say that my reaction to this, if Comcast had done it to me would be quite different depending on how it was executed... > > > Scenario A: Positive outcome > > CC "Mr. DeLong, we would like to replace your existing cablemodem with a DOCSIS 3.0 unit and give you faster service > for free. However, the catch is that we want to put up an additional 2.4Ghz WiFi SSID on the WAP built into the modem > that will use separate cable channels (i.e. won't affect your bandwidth) that our other subscribers can use once they > authenticate when they are in range. Would you mind if we did that?" > > ME "Well, since I currently own my modem, and it's already DOCSIS 3, I don't want to give up any of my existing functionality > and I have no desire to start paying rental fees. If you can provide the new one without monthly fees and it will do everything > my current one does (e.g. operating in transparent bridge mode), then I don't see any reason why not." > > > Scenario B: Class Action? > > CC "" > > ME -- Discovers Xfinity WiFi SSID and wonders "WTF is this?" > -- Tracks down source of SSID and discovers CC Modem in my garage is doing this. > -- Calls Comcast "WTF?" > > CC "blah blah blah, updated ToS, you agreed, blah blah" > > ME Starts calling lawyers > > ======== > > Unfortunately, it seems to me that Comcast (and apparently other Cable WiFi assn. members) have chosen Scenario B. Very unfortunate, considering how much easier and more productive scenario A could be. > > Owen > From jfbeam at gmail.com Fri Dec 12 01:39:46 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 11 Dec 2014 20:39:46 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <1DB4C29D-6C9A-41F6-951C-5E5BA0D36CBC@delong.com> References: <548902D7.60406@mompl.net> <548A2E78.1050208@alvarezp.ods.org> <1DB4C29D-6C9A-41F6-951C-5E5BA0D36CBC@delong.com> Message-ID: On Thu, 11 Dec 2014 19:33:03 -0500, Owen DeLong wrote: > In short, the only thing really truly wrong with this scenario is that > Comcast is using equipment that the subscriber should have exclusive > control over (they are renting it, so while Comcast retains ownership, > they have relinquished most rights of control to the "tenant") how the > device is used. Except every ISP (pretty much universally) thinks the modem/router is theirs and they can, therefore, do whatever they flippin' please with it. In some markets (not necessarily comcast), they lock down the router to the point the customer can't even access it; every single change has to go through them. (AT&T Uverse... you can change anything you want, with sufficient access (i.e. telnet), but the mothership can (and will) undo your changes pretty much instantly -- "apply" triggers a CWMP event.) From mysidia at gmail.com Fri Dec 12 02:31:15 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 11 Dec 2014 20:31:15 -0600 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: <54880935.7040103@dds.nl> References: <54880935.7040103@dds.nl> Message-ID: As for conversion between RAID levels; usually dump and restore are your best bet. Even if your controller HBA supports a RAID level migration; for a small array hosted in a server, dump and restore is your least risky bet for successful execution; you really need to dump anyways, even on a controller that supports clever RAID level migrations (The ServeRaid does not fall into this category), there is the possibility that the operation fails, leading to data loss, so backup first. On Wed, Dec 10, 2014 at 2:49 AM, Seth Mos wrote: > symack schreef op 9-12-2014 22:03: [snip] > Raid10 is the only valid raid format these days. With the disks as big > as they get these days it's possible for silent corruption. No! Mistake. It depends. RAID6, RAID60, RAID-DP, RAIDZ3, and a few others are perfectly valid RAID formats, with sufficient sparing. You get fewer extra average random write IOPS per spindle, but better survivability, particularly in the event of simultaneous double failures or even a simultaneous triple-failure or simultaneous quadruple failure (with appropriate RAID group sizing), which are not necessarily as rare as one might intuitively expect. And silent corruption can be addressed partially via surface scanning and built-in ECC on the hard drives, then also (for Non-SATA SAS/FC drives), the decent array subsystems low-level formatted disks with larger sector size at the time of initialization and slip in additional error correction data within each chunk's metadata, so silent corruption or bit-flipping isn't necessarily so silent on a decent piece of storage equipment. If you need to have a configuration less than 12 disk drives, where you require good performance for many small random reads and writes, and only cheap controllers are an option, then yeah you probably need Raid10, but not always. In case you have a storage chassis with 16 disk drives, an integrated RAID controller, a solid 1 to 2gb NVRAM cache and a few gigabytes read cache, then RAID6 or RAID60, or (maybe) even RAID50 could be a solid option for a wide number of use cases. You really just need to calculate an upper bound on the right number of spindles spread over the right number of host ports for the workload adjusted based on which RAID level you pick with sufficient cache (taking into account the caching policy and including a sufficiently large safety factor to encompass inherent uncertainties in spindle performance and the level of variability for your specific overall workload). -- -JH From bzs at world.std.com Fri Dec 12 03:05:30 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 11 Dec 2014 22:05:30 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: <86r3w5luhw.fsf@valhalla.seastrom.com> References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> <21641.64933.650664.76727@world.std.com> <86r3w5luhw.fsf@valhalla.seastrom.com> Message-ID: <21642.23418.504433.250404@world.std.com> Disk space by uid (by group is a plus but not critical), like BSD and EXTn. And the reason I put "inode" in quotes was to indicate that they may not (certainly not) be called inodes but an upper limit to the total number of files and directories, typically to stop a runaway script or certain malicious or grossly irresponsible behavior. >From my reading the closest you can get to disk space quotas in ZFS is by limiting on a per directory (dataset, mount) basis which is similar but different. On December 11, 2014 at 16:57 rs at seastrom.com (Rob Seastrom) wrote: > > Barry Shein writes: > > > From: Randy Bush > >>> We are now using ZFS RAIDZ and the question I ask myself is, why > >>> wasn't I using ZFS years ago? > >> > >>because it is not production on linux, which i have to use because > >>freebsd does not have kvm/ganeti. want zfs very very badly. snif. > > > > I keep reading zfs vs btrfs articles and...inconclusive. > > > > My problem with both is I need quotas, both file and "inode", and both > > are weaker than ext4 on that, zfs is very weak on this, you can only > > sort of simulate them. > > By file, you mean "disk space used"? By whom and where? Quotas and > reservations on a per-dataset basis are pretty darned well supported > in ZFS. As for inodes, well, since there isn't really such a thing as > an inode in ZFS... what exactly are you trying to do here? > > -r -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From mysidia at gmail.com Fri Dec 12 03:29:31 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 11 Dec 2014 21:29:31 -0600 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: <21642.23418.504433.250404@world.std.com> References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> <21641.64933.650664.76727@world.std.com> <86r3w5luhw.fsf@valhalla.seastrom.com> <21642.23418.504433.250404@world.std.com> Message-ID: On Thu, Dec 11, 2014 at 9:05 PM, Barry Shein wrote: [snip] > From my reading the closest you can get to disk space quotas in ZFS is > by limiting on a per directory (dataset, mount) basis which is similar > but different. This is the normal type of quota within ZFS. it is applied to a dataset and limits the size of the dataset, such as home/username. You can have as many datasets ("filesystems") as you like (within practical limits), which is probably the way to go in regards to home directories. But another option is zfs set groupquota at groupname=100GB example1/blah zfs set userquota at user1=200MB example1/blah This would be available on the Solaris implementation. I am not 100% certain that this is available under the BSD implementations, even if QUOTA is enabled in your kernel config. In the past.... the BSD implementation of ZFS never seemed to be as stable, functional, or performant as the OpenSolaris/Illumos version. -- -JH From khelms at zcorum.com Fri Dec 12 03:37:18 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 11 Dec 2014 22:37:18 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <0C148C8B-5713-4E7E-9624-640123DDA446@matthew.at> References: <548902D7.60406@mompl.net> <548A2E78.1050208@alvarezp.ods.org> <1DB4C29D-6C9A-41F6-951C-5E5BA0D36CBC@delong.com> <0C148C8B-5713-4E7E-9624-640123DDA446@matthew.at> Message-ID: Seriously, I mean the availability of WiFi coming from your house clearly trumps trespassing laws. On Dec 11, 2014 8:16 PM, "Matthew Kaufman" wrote: > Lots of other good reasons to oppose this (Comcast customers parking in > your driveway to get the service, etc.) > > What would you tell AT&T if they installed a coin phone at every > residential outside demarc? > > Matthew Kaufman > > (Sent from my iPhone) > > > On Dec 11, 2014, at 4:33 PM, Owen DeLong wrote: > > > > This thread is out of control... I will attempt to summarize the salient > points in hopes we can stop arguing about inaccurate minutiae. > > > > I don't like the way Comcast went about doing what they are doing, but I > do like the general idea... > > > > Reasonably ubiquitous free WiFi for your subscribers when they are away > from their home location is not a bad idea. > > > > The way Comcast has gone about it is a bit underhanded and sneaky. The > flaws in their plan are not technical, they are ethical and > communication-oriented in nature. > > > > To wit: > > There's nothing wrong with Comcast adding a separate SSID with > dedicated upstream bandwidth on a WAP I rent from them[1]. > > There's no theft of power, as the amount of additional power used is > imperceptible, if any. > > There's no theft of space, climate control, or other overhead as this > is performed by existing CPE. > > There's probably no legal liability being transferred by this to the > subscriber. > > > > In short, the only thing really truly wrong with this scenario is that > Comcast is using equipment that the subscriber should have exclusive > control over (they are renting it, so while Comcast retains ownership, they > have relinquished most rights of control to the "tenant") how the device is > used. > > > > As I see it, there are a couple of ways Comcast could have made this an > entirely voluntary (opt-in) program and communicated it to their customers > positively and achieved a high compliance rate. Unfortunately, in an action > worthy of their title as "America's worst company", instead of positively > communicating with their customers and seeking cooperation and permission > to build out something cool for everyone, they instead simply inflicted > this service on chosen subscribers without notice, warning, or permission. > > > > In short, Comcast's biggest real failure here is the failure to ask > permission from the subscriber before doing this on equipment the > subscriber should control. > > > > Arguing that some obscure phrase in updated ToS documents that nobody > ever reads permits this may keep Comcast from losing a law suit (though I > hope not), but it certainly won't improve their standing in the court of > public opinion. OTOH, Comcast seems to consider the court of public opinion > mostly irrelevant or they would be trying to find ways not to retain their > title as "America's worst company". > > > > I will say that my reaction to this, if Comcast had done it to me would > be quite different depending on how it was executed... > > > > > > Scenario A: Positive outcome > > > > CC "Mr. DeLong, we would like to replace your existing cablemodem > with a DOCSIS 3.0 unit and give you faster service > > for free. However, the catch is that we want to put up an additional > 2.4Ghz WiFi SSID on the WAP built into the modem > > that will use separate cable channels (i.e. won't affect your > bandwidth) that our other subscribers can use once they > > authenticate when they are in range. Would you mind if we did that?" > > > > ME "Well, since I currently own my modem, and it's already DOCSIS 3, > I don't want to give up any of my existing functionality > > and I have no desire to start paying rental fees. If you can provide > the new one without monthly fees and it will do everything > > my current one does (e.g. operating in transparent bridge mode), then > I don't see any reason why not." > > > > > > Scenario B: Class Action? > > > > CC "" > > > > ME -- Discovers Xfinity WiFi SSID and wonders "WTF is this?" > > -- Tracks down source of SSID and discovers CC Modem in my garage is > doing this. > > -- Calls Comcast "WTF?" > > > > CC "blah blah blah, updated ToS, you agreed, blah blah" > > > > ME Starts calling lawyers > > > > ======== > > > > Unfortunately, it seems to me that Comcast (and apparently other Cable > WiFi assn. members) have chosen Scenario B. Very unfortunate, considering > how much easier and more productive scenario A could be. > > > > Owen > > > From khelms at zcorum.com Fri Dec 12 03:45:02 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 11 Dec 2014 22:45:02 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <548A2E78.1050208@alvarezp.ods.org> <1DB4C29D-6C9A-41F6-951C-5E5BA0D36CBC@delong.com> Message-ID: In this case, they do own the modems. I am not aware of any case where they do this to customer owned gear. On Dec 11, 2014 8:41 PM, "Ricky Beam" wrote: > On Thu, 11 Dec 2014 19:33:03 -0500, Owen DeLong wrote: > > In short, the only thing really truly wrong with this scenario is that >> Comcast is using equipment that the subscriber should have exclusive >> control over (they are renting it, so while Comcast retains ownership, they >> have relinquished most rights of control to the "tenant") how the device is >> used. >> > > Except every ISP (pretty much universally) thinks the modem/router is > theirs and they can, therefore, do whatever they flippin' please with it. > In some markets (not necessarily comcast), they lock down the router to the > point the customer can't even access it; every single change has to go > through them. > > (AT&T Uverse... you can change anything you want, with sufficient access > (i.e. telnet), but the mothership can (and will) undo your changes pretty > much instantly -- "apply" triggers a CWMP event.) > From jlewis at lewis.org Fri Dec 12 03:46:50 2014 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 11 Dec 2014 22:46:50 -0500 (EST) Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> <21641.64933.650664.76727@world.std.com> <86r3w5luhw.fsf@valhalla.seastrom.com> <21642.23418.504433.250404@world.std.com> Message-ID: On Thu, 11 Dec 2014, Jimmy Hess wrote: > I am not 100% certain that this is available under the BSD implementations, > even if QUOTA is enabled in your kernel config. > > In the past.... the BSD implementation of ZFS never seemed to be as > stable, functional, or performant as the OpenSolaris/Illumos version. That's a scary low bar for comparison. OpenSolaris (or even Solaris 11), ZFS, Stable. Pick one. Maybe two. Three? Yeah right. Anyone who's used it hard, under heavy load, should understand. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From javier at advancedmachines.us Fri Dec 12 06:07:19 2014 From: javier at advancedmachines.us (Javier J) Date: Fri, 12 Dec 2014 01:07:19 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> Message-ID: Hey guys, I am running it on freeBSD. (nas4free) It's my understanding that when a resilver happens in a zpool, only the data that has actually been written to the disks gets used, not the whole array like traditional raid5 does, reading even empty blocks. I know I should be using RAIDZ2 for this size array, but I have daily backups off of this array and also this is a lab, not a production environment. In a production environment I would use raidz2 or raidz3. The bottom line is even just Raidz1 is way better than any RAID5 hardware/software solution I have come across. 1 disk with ZFS can survive 1/8 of the disk becoming destroyed apparently. ZFS itself has many protections against data corruption. Also I have scheduled a zpool scrub to run twice a week (to detect bitrot before it happens.) Anyway. I have been using linux raid since it has been available and I ask myself, why haven't I used ZFS seriously before now. - J On Thu, Dec 11, 2014 at 11:06 AM, Bacon Zombie wrote: > Are you running ZFS and RAIDZ on Linux or BSD? > On 10 Dec 2014 23:21, "Javier J" wrote: > >> I'm just going to chime in here since I recently had to deal with bit-rot >> affecting a 6TB linux raid5 setup using mdadm (6x 1TB disks) >> >> We couldn't rebuild because of 5 URE sectors on one of the other disks in >> the array after a power / ups issue rebooted our storage box. >> >> We are now using ZFS RAIDZ and the question I ask myself is, why wasn't I >> using ZFS years ago? >> >> +1 for ZFS and RAIDZ >> >> >> >> On Wed, Dec 10, 2014 at 8:40 AM, Rob Seastrom wrote: >> >> > >> > The subject is drifting a bit but I'm going with the flow here: >> > >> > Seth Mos writes: >> > >> > > Raid10 is the only valid raid format these days. With the disks as big >> > > as they get these days it's possible for silent corruption. >> > >> > How do you detect it? A man with two watches is never sure what time it >> > is. >> > >> > Unless you have a filesystem that detects and corrects silent >> > corruption, you're still hosed, you just don't know it yet. RAID10 >> > between the disks in and of itself doesn't help. >> > >> > > And with 4TB+ disks that is a real thing. Raid 6 is ok, if you accept >> > > rebuilds that take a week, literally. Although the rebuild rate on our >> > > 11 disk raid 6 SSD array (2TB) is less then a day. >> > >> > I did a rebuild on a RAIDZ2 vdev recently (made out of 4tb WD reds). >> > It took nowhere near a day let alone a week. Theoretically takes 8-11 >> > hours if the vdev is completely full, proportionately less if it's >> > not, and I was at about 2/3 in use. >> > >> > -r >> > >> > >> > From javier at advancedmachines.us Fri Dec 12 06:33:38 2014 From: javier at advancedmachines.us (Javier J) Date: Fri, 12 Dec 2014 01:33:38 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: Jason, I hope you are Livin' Good. On a serious note. What stops someone from going down to the center of town, launching a little wifi SSID named xfinitywifi and collecting your customers usernames and passwords? Also, don't you think there is something just morally wrong with the fact that your customers don't know they are providing a public access point out of their homes by just being comcast HSI customers? I am all for wifi everywhere, but this isn't the way to do it. http://i.imgur.com/R3xCpZO.png Pic is related, one of those access points isn't owned by Comcast. On Thu, Dec 11, 2014 at 7:32 PM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > On 12/11/14, 4:37 PM, "Tim Upthegrove" wrote: > > >I received an email from Comcast that they were offering a free upgraded > >wifi router for my home. > > Yes, since the main service tier doubled from 25 Mbps to 50 Mbps (some > went to 105 Mbps) that means DOCSIS 2.0 devices were no longer up to the > task. If you got an email like that you had a D2.0 device and needed a > D3.0 device. A side benefit is the device either now or very soon supports > native dual stack. > > Jason > > From daniel.karrenberg at ripe.net Fri Dec 12 11:37:17 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 12 Dec 2014 12:37:17 +0100 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <7585057.2707.1418274667707.JavaMail.root@benjamin.baylink.com> <30585.1418307850@turing-police.cc.vt.edu> <20141211093047.7bc5474d@jpeach-desktop.anbg.mssm.edu> <8abfcc8eaaaf3a462fc25cfe627e3293.squirrel@66.201.44.180> <3677.1418313912@turing-police.cc.vt.edu> <5489C6A8.8020807@sctcweb.com> <2882EE36-6351-4B50-ACFB-85BAD0ECAF1C@centergate.com> Message-ID: <548AD36D.1060603@ripe.net> On 11.12.14 21:22 , Randy Bush wrote: > note that free.fr does this in france. we both provide and use it > there. works out quite well. Another data point: several cable broadband providers do this in NL. My personal experience is with Ziggo. Imho they do it right: - opt-in, at least when I joined as an early adopter - you do get roaming privileges yourself if you opt-in - full WPA authentication - each customer has their individual authentication info - back-haul is via a separate DOCSIS connection - no leakage - no bandwidth loss on your subscription - no liability for what roamers do This to me is acceptable. In practice I have turned it off by default on my phone and I rarely roam as 3G/4G charges are also reasonable. I found it to be annoying when quality varies as it roams from 3G to Wifi and Wifi to Wifi. But I do manually turn it on occasionally when stationary and doing a lot of data. Daniel From rs at seastrom.com Fri Dec 12 12:01:50 2014 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 12 Dec 2014 07:01:50 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: (Jon Lewis's message of "Thu, 11 Dec 2014 22:46:50 -0500 (EST)") References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> <21641.64933.650664.76727@world.std.com> <86r3w5luhw.fsf@valhalla.seastrom.com> <21642.23418.504433.250404@world.std.com> Message-ID: <86iohh5b69.fsf@valhalla.seastrom.com> Jon Lewis writes: > OpenSolaris (or even Solaris 11), ZFS, Stable. Pick one. Maybe > two. Three? Yeah right. Anyone who's used it hard, under heavy load, > should understand. The most recent release of OpenSolaris was over 5 years ago. You're working from (extremely) dated information. The current FOSS Solaris ecosystem forked when Oracle brought stuff back in-house. Significant development has happened over the intervening half-decade. Anyone who's using Nexentastor (or hosted in Joyent Cloud) is getting all three (supra). -r From Jason_Livingood at cable.comcast.com Fri Dec 12 13:36:16 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 12 Dec 2014 13:36:16 +0000 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: On 12/12/14, 1:33 AM, "Javier J" > wrote: Also, don't you think there is something just morally wrong with the fact that your customers don't know they are providing a public access point out of their homes by just being comcast HSI customers? I am all for wifi everywhere, but this isn't the way to do it. What I think is that no matter what, someone will find something wrong with anything we choose to do. I also think this thread has become a bit absurd. Jason From rsk at gsp.org Fri Dec 12 14:43:59 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 12 Dec 2014 09:43:59 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: <1DB4C29D-6C9A-41F6-951C-5E5BA0D36CBC@delong.com> References: <548902D7.60406@mompl.net> <548A2E78.1050208@alvarezp.ods.org> <1DB4C29D-6C9A-41F6-951C-5E5BA0D36CBC@delong.com> Message-ID: <20141212144359.GA8826@gsp.org> On Thu, Dec 11, 2014 at 04:33:03PM -0800, Owen DeLong wrote: > This thread is out of control... I will attempt to summarize the > salient points in hopes we can stop arguing about inaccurate minutiae. I concur with this summary and will add this: It's a pity that the resources which went into this rollout were not instead applied to deal with a problem that's now a decade old: large-scale spamming sourced from botted systems on Comcast's network. Despite Comcast's "we take the spam problem seriously" statements circa 2004, spam continues to flow from Comcast-operated networks at a high rate... as it has for ten years. See, for reference: http://news.cnet.com/2100-1034_3-5218178.html I wonder how this change will affect that problem. ---rsk From wesley.george at twcable.com Fri Dec 12 16:45:54 2014 From: wesley.george at twcable.com (George, Wes) Date: Fri, 12 Dec 2014 11:45:54 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: On 12/12/14, 1:33 AM, "Javier J" wrote: >What stops someone from going down to the center of town, launching a >little wifi SSID named xfinitywifi and collecting your customers usernames >and passwords? WG] nothing. But then again, the same argument can be made for *any* wireless network that does authentication via a portal, because it becomes a standard phishing spoof problem that is dependent on how well you imitate the portal in question. Not really a comcast-specific problem, though this blog demonstrates exactly what you suggest: https://blog.logrhythm.com/security/xfinity-pineapple/ Hotspot 2.0 is intended to help with this problem to some extent. http://www.cisco.com/c/en/us/solutions/collateral/service-provider/service- provider-wi-fi/white_paper_c11-649337.html Wes George 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 bzs at world.std.com Fri Dec 12 17:57:43 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 12 Dec 2014 12:57:43 -0500 Subject: Got a call at 4am - RAID Gurus Please Read In-Reply-To: References: <54880935.7040103@dds.nl> <86mw6vpqre.fsf@valhalla.seastrom.com> <21641.64933.650664.76727@world.std.com> <86r3w5luhw.fsf@valhalla.seastrom.com> <21642.23418.504433.250404@world.std.com> Message-ID: <21643.11415.274079.791084@world.std.com> That might be close enough. I need to set up a test system and play around with zfs and btrfs. Thanks. On December 11, 2014 at 21:29 mysidia at gmail.com (Jimmy Hess) wrote: > On Thu, Dec 11, 2014 at 9:05 PM, Barry Shein wrote: > [snip] > > From my reading the closest you can get to disk space quotas in ZFS is > > by limiting on a per directory (dataset, mount) basis which is similar > > but different. > > This is the normal type of quota within ZFS. it is applied to a > dataset and limits the size of the dataset, such as > home/username. > You can have as many datasets ("filesystems") as you like (within > practical limits), which is probably the way to go in regards to home > directories. > > But another option is > > zfs set groupquota at groupname=100GB example1/blah > zfs set userquota at user1=200MB example1/blah > > This would be available on the Solaris implementation. > > > I am not 100% certain that this is available under the BSD implementations, > even if QUOTA is enabled in your kernel config. > > In the past.... the BSD implementation of ZFS never seemed to be as > stable, functional, or performant as the OpenSolaris/Illumos version. > > -- > -JH -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From cscora at apnic.net Fri Dec 12 18:12:13 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Dec 2014 04:12:13 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201412121812.sBCICD93012991@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 13 Dec, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 523481 Prefixes after maximum aggregation: 201299 Deaggregation factor: 2.60 Unique aggregates announced to Internet: 255547 Total ASes present in the Internet Routing Table: 48830 Prefixes per ASN: 10.72 Origin-only ASes present in the Internet Routing Table: 36379 Origin ASes announcing only one prefix: 16320 Transit ASes present in the Internet Routing Table: 6187 Transit-only ASes present in the Internet Routing Table: 172 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 100 Max AS path prepend of ASN ( 55644) 93 Prefixes from unregistered ASNs in the Routing Table: 1631 Unregistered ASNs in the Routing Table: 430 Number of 32-bit ASNs allocated by the RIRs: 8142 Number of 32-bit ASNs visible in the Routing Table: 6264 Prefixes from 32-bit ASNs in the Routing Table: 22488 Number of bogon 32-bit ASNs visible in the Routing Table: 7 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 406 Number of addresses announced to Internet: 2715334500 Equivalent to 161 /8s, 216 /16s and 183 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.0 Total number of prefixes smaller than registry allocations: 177479 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 128957 Total APNIC prefixes after maximum aggregation: 37484 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 133610 Unique aggregates announced from the APNIC address blocks: 54387 APNIC Region origin ASes present in the Internet Routing Table: 5009 APNIC Prefixes per ASN: 26.67 APNIC Region origin ASes announcing only one prefix: 1216 APNIC Region transit ASes present in the Internet Routing Table: 853 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 100 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1211 Number of APNIC addresses announced to Internet: 738767936 Equivalent to 44 /8s, 8 /16s and 180 /24s Percentage of available APNIC address space announced: 86.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: 173986 Total ARIN prefixes after maximum aggregation: 86173 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 175863 Unique aggregates announced from the ARIN address blocks: 82172 ARIN Region origin ASes present in the Internet Routing Table: 16408 ARIN Prefixes per ASN: 10.72 ARIN Region origin ASes announcing only one prefix: 6075 ARIN Region transit ASes present in the Internet Routing Table: 1711 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 290 Number of ARIN addresses announced to Internet: 1054644192 Equivalent to 62 /8s, 220 /16s and 151 /24s Percentage of available ARIN address space announced: 55.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 126399 Total RIPE prefixes after maximum aggregation: 63747 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 132300 Unique aggregates announced from the RIPE address blocks: 82743 RIPE Region origin ASes present in the Internet Routing Table: 17824 RIPE Prefixes per ASN: 7.42 RIPE Region origin ASes announcing only one prefix: 8183 RIPE Region transit ASes present in the Internet Routing Table: 2919 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3260 Number of RIPE addresses announced to Internet: 692278148 Equivalent to 41 /8s, 67 /16s and 83 /24s Percentage of available RIPE address space announced: 100.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59085 Total LACNIC prefixes after maximum aggregation: 10879 LACNIC Deaggregation factor: 5.43 Prefixes being announced from the LACNIC address blocks: 67965 Unique aggregates announced from the LACNIC address blocks: 30977 LACNIC Region origin ASes present in the Internet Routing Table: 2388 LACNIC Prefixes per ASN: 28.46 LACNIC Region origin ASes announcing only one prefix: 638 LACNIC Region transit ASes present in the Internet Routing Table: 476 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1424 Number of LACNIC addresses announced to Internet: 167471296 Equivalent to 9 /8s, 251 /16s and 104 /24s Percentage of available LACNIC address space announced: 99.8 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: 12432 Total AfriNIC prefixes after maximum aggregation: 2972 AfriNIC Deaggregation factor: 4.18 Prefixes being announced from the AfriNIC address blocks: 13337 Unique aggregates announced from the AfriNIC address blocks: 4901 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 18.15 AfriNIC Region origin ASes announcing only one prefix: 208 AfriNIC Region transit ASes present in the Internet Routing Table: 151 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: 79 Number of AfriNIC addresses announced to Internet: 60186624 Equivalent to 3 /8s, 150 /16s and 96 /24s Percentage of available AfriNIC address space announced: 59.8 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 2953 11585 929 Korea Telecom 17974 2834 904 77 PT Telekomunikasi Indonesia 7545 2488 337 129 TPG Telecom Limited 4755 1923 416 191 TATA Communications formerly 4538 1816 4190 71 China Education and Research 9829 1662 1323 28 National Internet Backbone 9808 1496 6719 19 Guangdong Mobile Communicatio 4808 1443 2209 426 CNCGROUP IP network China169 9583 1366 112 564 Sify Limited 9498 1294 336 97 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 2922 2956 141 Cox Communications Inc. 6389 2892 3688 51 BellSouth.net Inc. 3356 2552 10684 471 Level 3 Communications, Inc. 18566 2042 379 183 MegaPath Corporation 20115 1838 1817 452 Charter Communications 4323 1639 1054 410 tw telecom holdings, inc. 6983 1625 867 245 EarthLink, Inc. 30036 1505 311 591 Mediacom Communications Corp 701 1418 11265 698 MCI Communications Services, 22561 1317 411 244 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 1907 298 358 TELLCOM ILETISIM HIZMETLERI A 20940 1530 598 1133 Akamai International B.V. 8402 1420 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 997 95 60 TOV "Bank-Inform" 8551 898 373 43 Bezeq International-Ltd 6849 833 356 25 JSC "Ukrtelecom" 9198 831 349 26 JSC Kazakhtelecom 6830 821 2340 442 Liberty Global Operations B.V 12479 800 789 95 France Telecom Espana SA 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 3059 496 224 Telmex Colombia S.A. 28573 2295 2119 112 NET Servi�os de Comunica��o S 6147 1807 374 30 Telefonica del Peru S.A.A. 7303 1777 1172 241 Telecom Argentina S.A. 8151 1485 3034 428 Uninet S.A. de C.V. 6503 1229 433 58 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 918 2325 35 Tim Celular S.A. 3816 909 394 147 COLOMBIA TELECOMUNICACIONES S 27947 886 129 50 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1429 958 13 TE-AS 24863 951 284 26 Link Egypt (Link.NET) 36903 456 230 95 Office National des Postes et 36992 382 824 29 ETISALAT MISR 24835 308 144 9 Vodafone Data 37492 282 133 65 Orange Tunisie 3741 250 921 213 Internet Solutions 29571 235 21 12 Cote d'Ivoire Telecom 37457 194 160 4 Telkom SA Ltd. 36947 187 807 13 Telecom Algeria 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 3059 496 224 Telmex Colombia S.A. 4766 2953 11585 929 Korea Telecom 22773 2922 2956 141 Cox Communications Inc. 6389 2892 3688 51 BellSouth.net Inc. 17974 2834 904 77 PT Telekomunikasi Indonesia 3356 2552 10684 471 Level 3 Communications, Inc. 7545 2488 337 129 TPG Telecom Limited 28573 2295 2119 112 NET Servi�os de Comunica��o S 18566 2042 379 183 MegaPath Corporation 4755 1923 416 191 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2892 2841 BellSouth.net Inc. 22773 2922 2781 Cox Communications Inc. 17974 2834 2757 PT Telekomunikasi Indonesia 7545 2488 2359 TPG Telecom Limited 28573 2295 2183 NET Servi�os de Comunica��o S 3356 2552 2081 Level 3 Communications, Inc. 4766 2953 2024 Korea Telecom 18566 2042 1859 MegaPath Corporation 6147 1807 1777 Telefonica del Peru S.A.A. 4538 1816 1745 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 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 27.122.56.0/22 55799 Hostemo Technology Sdn Bhd 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:31 /11:92 /12:263 /13:501 /14:999 /15:1728 /16:13061 /17:7168 /18:11975 /19:24950 /20:35533 /21:38034 /22:56252 /23:49150 /24:280755 /25:1107 /26:1091 /27:708 /28:16 /29:19 /30:11 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2137 2922 Cox Communications Inc. 18566 1997 2042 MegaPath Corporation 6389 1672 2892 BellSouth.net Inc. 6147 1352 1807 Telefonica del Peru S.A.A. 30036 1352 1505 Mediacom Communications Corp 6983 1312 1625 EarthLink, Inc. 34984 1214 1907 TELLCOM ILETISIM HIZMETLERI A 11492 1126 1183 CABLE ONE, INC. 10620 1086 3059 Telmex Colombia S.A. 8402 1085 1420 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1394 2:676 3:3 4:95 5:1222 6:21 8:1402 12:1842 13:5 14:1208 15:17 16:2 17:42 18:21 20:51 23:1056 24:1662 27:1805 31:1420 32:39 33:2 34:5 36:150 37:1849 38:977 39:13 40:224 41:3035 42:281 43:774 44:20 45:83 46:2105 47:31 49:771 50:788 52:12 54:59 55:6 56:6 57:31 58:1157 59:662 60:448 61:1746 62:1308 63:1871 64:4411 65:2281 66:4092 67:2024 68:1046 69:3262 70:918 71:429 72:1974 74:2608 75:323 76:408 77:1348 78:1026 79:782 80:1321 81:1286 82:811 83:675 84:670 85:1303 86:430 87:1192 88:512 89:1814 90:139 91:5842 92:800 93:1658 94:1977 95:1353 96:422 97:338 98:1048 99:48 100:69 101:787 103:6293 104:822 105:186 106:194 107:873 108:612 109:2011 110:1060 111:1448 112:736 113:896 114:798 115:1236 116:1275 117:1013 118:1667 119:1370 120:420 121:990 122:2203 123:1703 124:1454 125:1568 128:654 129:384 130:384 131:1017 132:437 133:165 134:333 135:85 136:331 137:297 138:388 139:170 140:228 141:423 142:587 143:441 144:510 145:112 146:701 147:563 148:1029 149:407 150:534 151:587 152:474 153:248 154:294 155:654 156:389 157:333 158:252 159:920 160:366 161:615 162:1826 163:379 164:640 165:667 166:307 167:735 168:1161 169:130 170:1421 171:222 172:51 173:1580 174:710 175:592 176:1550 177:3666 178:2089 179:801 180:1824 181:1700 182:1705 183:530 184:723 185:2490 186:2954 187:1679 188:2000 189:1533 190:7929 191:855 192:7893 193:5565 194:4065 195:3631 196:1692 197:862 198:5398 199:5493 200:6538 201:2981 202:9461 203:8992 204:4689 205:2704 206:2995 207:2978 208:3914 209:3858 210:3484 211:1863 212:2495 213:2244 214:862 215:71 216:5571 217:1748 218:652 219:466 220:1303 221:774 222:457 223:643 End of report From eric.sieg at gmail.com Fri Dec 12 19:30:13 2014 From: eric.sieg at gmail.com (Eric Sieg) Date: Fri, 12 Dec 2014 14:30:13 -0500 Subject: Looking for a Telus contact Message-ID: From owen at delong.com Fri Dec 12 20:51:43 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 12 Dec 2014 12:51:43 -0800 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <548A2E78.1050208@alvarezp.ods.org> <1DB4C29D-6C9A-41F6-951C-5E5BA0D36CBC@delong.com> Message-ID: <4DF0FF9E-2F9B-44A6-BD79-2988199A58F0@delong.com> > On Dec 11, 2014, at 17:39 , Ricky Beam wrote: > > On Thu, 11 Dec 2014 19:33:03 -0500, Owen DeLong wrote: > >> In short, the only thing really truly wrong with this scenario is that Comcast is using equipment that the subscriber should have exclusive control over (they are renting it, so while Comcast retains ownership, they have relinquished most rights of control to the "tenant") how the device is used. > > Except every ISP (pretty much universally) thinks the modem/router is theirs and they can, therefore, do whatever they flippin' please with it. In some markets (not necessarily comcast), they lock down the router to the point the customer can't even access it; every single change has to go through them. The fact that a mythology is widely believed does not make it true. > > (AT&T Uverse... you can change anything you want, with sufficient access (i.e. telnet), but the mothership can (and will) undo your changes pretty much instantly -- "apply" triggers a CWMP event.) I have no doubt that AT&T is equally slimey to Comcast, especially in this regard. I stand by my statement that if you are paying monthly for rental of the modem, then you have the right to exclusive use of the modem, just as when you rent an apartment, the landlord cannot use it for storage or put other people in there at his whim. Owen From cmcintosh33 at gmail.com Fri Dec 12 20:58:07 2014 From: cmcintosh33 at gmail.com (Colin McIntosh) Date: Fri, 12 Dec 2014 20:58:07 +0000 Subject: Looking for piece of undersea cable Message-ID: Hey all, I'm looking for a piece of undersea cable to use for educational purposes and was hoping somebody would have a section they can part with. Doesn't need to be a big piece, really any size will work. I can pay for shipping and the cable, if needed. Thanks! -Colin From javier at advancedmachines.us Fri Dec 12 21:09:35 2014 From: javier at advancedmachines.us (Javier J) Date: Fri, 12 Dec 2014 16:09:35 -0500 Subject: Looking for piece of undersea cable In-Reply-To: References: Message-ID: I would also love to have a section of one just for the heck of it in my office. On Fri, Dec 12, 2014 at 3:58 PM, Colin McIntosh wrote: > > Hey all, > > I'm looking for a piece of undersea cable to use for educational purposes > and was hoping somebody would have a section they can part with. Doesn't > need to be a big piece, really any size will work. I can pay for shipping > and the cable, if needed. > > Thanks! > -Colin > From jhellenthal at dataix.net Fri Dec 12 21:11:31 2014 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Fri, 12 Dec 2014 15:11:31 -0600 Subject: Looking for piece of undersea cable In-Reply-To: References: Message-ID: <7A5A0C36-C8C5-45FE-A906-9DE63DC38B70@dataix.net> Tanzania looks to have a peace they wouldn’t miss … grab your scuba gear we’ll go swimming :-) > On Dec 12, 2014, at 14:58, Colin McIntosh wrote: > > Hey all, > > I'm looking for a piece of undersea cable to use for educational purposes > and was hoping somebody would have a section they can part with. Doesn't > need to be a big piece, really any size will work. I can pay for shipping > and the cable, if needed. > > Thanks! > -Colin -- Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal at DataIX.net JJH48-ARIN From jhellenthal at dataix.net Fri Dec 12 21:13:01 2014 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Fri, 12 Dec 2014 15:13:01 -0600 Subject: Looking for piece of undersea cable In-Reply-To: <7A5A0C36-C8C5-45FE-A906-9DE63DC38B70@dataix.net> References: <7A5A0C36-C8C5-45FE-A906-9DE63DC38B70@dataix.net> Message-ID: <57A95304-CAD6-4058-8A6C-EE34FF21D4A6@dataix.net> http://www.submarinecablemap.com/ > On Dec 12, 2014, at 15:11, Jason Hellenthal wrote: > > Tanzania looks to have a peace they wouldn’t miss … grab your scuba gear we’ll go swimming :-) > >> On Dec 12, 2014, at 14:58, Colin McIntosh wrote: >> >> Hey all, >> >> I'm looking for a piece of undersea cable to use for educational purposes >> and was hoping somebody would have a section they can part with. Doesn't >> need to be a big piece, really any size will work. I can pay for shipping >> and the cable, if needed. >> >> Thanks! >> -Colin > > -- > Jason Hellenthal > Mobile: +1 (616) 953-0176 > jhellenthal at DataIX.net > JJH48-ARIN > -- Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal at DataIX.net JJH48-ARIN From surfer at mauigateway.com Fri Dec 12 21:38:26 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 12 Dec 2014 13:38:26 -0800 Subject: Looking for piece of undersea cable Message-ID: <20141212133826.80F3155A@m0048141.ppops.net> > On Dec 12, 2014, at 14:58, Colin McIntosh wrote: > I'm looking for a piece of undersea cable to use for > educational purposes and was hoping somebody would > have a section they can part with. Doesn't need to be > a big piece, really any size will work. I can pay for > shipping and the cable, if needed. --------------------------------------------------- --- jhellenthal at dataix.net wrote: From: Jason Hellenthal Tanzania looks to have a peace they wouldn’t miss … grab your scuba gear we’ll go swimming :-) --------------------------------------------------- How would you upload your scuba (and surfing) pictures from the Seychelles islands to the internet if that piece were to go away? ;-) scott From mfidelman at meetinghouse.net Fri Dec 12 21:56:22 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 12 Dec 2014 16:56:22 -0500 Subject: Looking for piece of undersea cable In-Reply-To: <20141212133826.80F3155A@m0048141.ppops.net> References: <20141212133826.80F3155A@m0048141.ppops.net> Message-ID: <548B6486.1020708@meetinghouse.net> Scott Weeks wrote: > >> On Dec 12, 2014, at 14:58, Colin McIntosh wrote: >> I'm looking for a piece of undersea cable to use for >> educational purposes and was hoping somebody would >> have a section they can part with. Doesn't need to be >> a big piece, really any size will work. I can pay for >> shipping and the cable, if needed. > --------------------------------------------------- > > > --- jhellenthal at dataix.net wrote: > From: Jason Hellenthal > > Tanzania looks to have a peace they wouldn’t miss … > grab your scuba gear we’ll go swimming :-) > --------------------------------------------------- > > > How would you upload your scuba (and surfing) pictures > from the Seychelles islands to the internet if that > piece were to go away? ;-) > > As much as I'd like to join that expedition, you could just call up one of the vendors listed here, and see if they'll send you a sample: http://www.submarinecablesystems.com/default.asp.pg-CableSuppliers Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From cidr-report at potaroo.net Fri Dec 12 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Dec 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201412122200.sBCM00rq026337@wattle.apnic.net> This report has been generated at Fri Dec 12 21:14:23 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 05-12-14 525863 289663 06-12-14 526067 289726 07-12-14 525945 289925 08-12-14 526124 290169 09-12-14 526217 290391 10-12-14 526306 291641 11-12-14 528778 291637 12-12-14 528724 291929 AS Summary 49095 Number of ASes in routing system 19731 Number of ASes announcing only one prefix 3070 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120184320 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'). --- 12Dec14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 528824 291869 236955 44.8% All ASes AS6389 2892 98 2794 96.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2925 173 2752 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2834 83 2751 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS28573 2276 300 1976 86.8% NET Servi�os de Comunica��o S.A.,BR AS3356 2620 824 1796 68.5% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2954 1298 1656 56.1% KIXS-AS-KR Korea Telecom,KR AS6147 1809 169 1640 90.7% Telefonica del Peru S.A.A.,PE AS4755 1923 291 1632 84.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7303 1775 291 1484 83.6% Telecom Argentina S.A.,AR AS10620 3070 1591 1479 48.2% Telmex Colombia S.A.,CO AS9808 1495 53 1442 96.5% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1400 25 1375 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS20115 1842 534 1308 71.0% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2503 1263 1240 49.5% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1646 412 1234 75.0% TWTC - tw telecom holdings, inc.,US AS9498 1294 113 1181 91.3% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2041 868 1173 57.5% MEGAPATH5-US - MegaPath Corporation,US AS6983 1625 482 1143 70.3% ITCDELTA - Earthlink, Inc.,US AS7552 1168 51 1117 95.6% VIETEL-AS-AP Viettel Corporation,VN AS34984 1908 868 1040 54.5% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1318 366 952 72.2% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS38285 983 113 870 88.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1834 974 860 46.9% ERX-CERNET-BKB China Education and Research Network Center,CN AS24560 1183 365 818 69.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS8151 1491 691 800 53.7% Uninet S.A. de C.V.,MX AS26615 918 120 798 86.9% Tim Celular S.A.,BR AS31148 1045 254 791 75.7% FREENET-AS Freenet Ltd.,UA AS4780 1063 300 763 71.8% SEEDNET Digital United Inc.,TW AS18101 956 193 763 79.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN Total 53790 13246 40544 75.4% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 27.122.56.0/22 AS55799 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 43.226.20.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 43.226.21.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 43.226.22.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 43.226.23.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 43.245.196.0/24 AS36352 AS-COLOCROSSING - ColoCrossing,US 43.245.197.0/24 AS55286 SERVER-MANIA - B2 Net Solutions Inc.,US 43.245.198.0/24 AS55799 43.245.199.0/24 AS55799 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -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.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 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.220.84.0/24 AS5577 ROOT root SA,LU 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 102.5.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 102.59.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 102.198.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 103.1.152.0/22 AS55799 103.1.155.0/24 AS55799 103.10.196.0/24 AS55799 103.10.198.0/24 AS55799 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.124.0/24 AS45355 DIGICELPACIFIC-1-AP Clarendon House,FJ 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.27.144.0/22 AS18097 DCN D.C.N. Corporation,JP 103.45.68.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 103.45.69.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 103.45.70.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 103.45.71.0/24 AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 103.243.12.0/24 AS33047 INSTART - Instart Logic, Inc,US 103.243.13.0/24 AS33047 INSTART - Instart Logic, Inc,US 103.243.14.0/24 AS33047 INSTART - Instart Logic, Inc,US 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 104.241.128.0/18 AS30236 CRONOMAGIC-1 - Cronomagic Canada Inc.,CA 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.193.157.0/24 AS55799 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 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 151.216.128.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM",RU 151.216.192.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM",RU 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 181.118.32.0/19 AS28092 181.199.224.0/19 AS28092 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 186.1.128.0/19 AS28092 186.65.108.0/22 AS22927 Telefonica de Argentina,AR 186.96.96.0/19 AS28092 186.148.160.0/19 AS28092 186.190.224.0/21 AS28092 190.2.208.0/21 AS28092 190.9.48.0/21 AS28092 190.13.80.0/21 AS28092 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.52.0/23 AS14455 SUNGARD-RECOVERY - Sungard Network Solutions, Inc.,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 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.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.82.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.237.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.140.183.0/24 AS36011 -Reserved AS-,ZZ 198.140.184.0/24 AS36011 -Reserved AS-,ZZ 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.53.208.0/23 AS17157 -Reserved AS-,ZZ 206.53.211.0/24 AS17157 -Reserved AS-,ZZ 206.53.212.0/24 AS17157 -Reserved AS-,ZZ 206.53.213.0/24 AS17157 -Reserved AS-,ZZ 206.53.214.0/23 AS17157 -Reserved AS-,ZZ 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.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.117.240.0/21 AS17157 -Reserved AS-,ZZ 216.117.248.0/22 AS17157 -Reserved AS-,ZZ 216.117.252.0/23 AS17157 -Reserved AS-,ZZ 216.117.254.0/24 AS17157 -Reserved AS-,ZZ 216.117.255.0/24 AS17157 -Reserved AS-,ZZ 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Dec 12 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Dec 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201412122200.sBCM011n026351@wattle.apnic.net> BGP Update Report Interval: 04-Dec-14 -to- 11-Dec-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 288110 6.9% 2718.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 186798 4.5% 121.9 -- BSNL-NIB National Internet Backbone,IN 3 - AS53249 82446 2.0% 41223.0 -- LAWA-AS - Los Angeles World Airport,US 4 - AS10620 43138 1.0% 20.7 -- Telmex Colombia S.A.,CO 5 - AS27738 38868 0.9% 49.8 -- Ecuadortelecom S.A.,EC 6 - AS28573 27826 0.7% 12.4 -- NET Servi�os de Comunica��o S.A.,BR 7 - AS8402 25027 0.6% 84.3 -- CORBINA-AS OJSC "Vimpelcom",RU 8 - AS3 24868 0.6% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 9 - AS60725 24212 0.6% 4035.3 -- O3B-AS O3b Limited,JE 10 - AS36903 23907 0.6% 60.8 -- MT-MPLS,MA 11 - AS48159 22450 0.5% 66.2 -- TIC-AS Telecommunication Infrastructure Company,IR 12 - AS23342 21957 0.5% 21957.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 13 - AS38197 21924 0.5% 26.2 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 14 - AS34984 21884 0.5% 13.3 -- TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR 15 - AS24863 20594 0.5% 34.8 -- LINKdotNET-AS,EG 16 - AS11054 20372 0.5% 814.9 -- LIVEPERSON - LivePerson, Inc.,US 17 - AS3816 20244 0.5% 36.6 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 18 - AS45899 20102 0.5% 56.5 -- VNPT-AS-VN VNPT Corp,VN 19 - AS25003 19862 0.5% 536.8 -- INTERNET_BINAT Internet Binat Ltd,IL 20 - AS4538 17361 0.4% 2.9 -- ERX-CERNET-BKB China Education and Research Network Center,CN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS53249 82446 2.0% 41223.0 -- LAWA-AS - Los Angeles World Airport,US 2 - AS23342 21957 0.5% 21957.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 3 - AS49317 9804 0.2% 9804.0 -- KSPAB Kallmyra System & Produktion AB,SE 4 - AS3 24868 0.6% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 5 - AS62174 5695 0.1% 5695.0 -- INTERPAN-AS INTERPAN LTD.,BG 6 - AS18135 10572 0.2% 5286.0 -- BTV BTV Cable television,JP 7 - AS47680 9238 0.2% 4619.0 -- NHCS EOBO Limited,IE 8 - AS60725 24212 0.6% 4035.3 -- O3B-AS O3b Limited,JE 9 - AS60737 7262 0.2% 3631.0 -- NEURONESIT NEURONESIT,FR 10 - AS21280 3360 0.1% 3360.0 -- SWIFTGLOBAL-AS,KE 11 - AS56636 2724 0.1% 2724.0 -- ASVEDARU VEDA Ltd.,RU 12 - AS23752 288110 6.9% 2718.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 13 - AS11728 1665 0.0% 1665.0 -- INTERNETXT - Internet Exchange Technology, Inc.,US 14 - AS3 1638 0.0% 174.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 15 - AS33721 1619 0.0% 1619.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 16 - AS6 1583 0.0% 173.0 -- BULL-HN - Bull HN Information Systems Inc.,US 17 - AS30944 1394 0.0% 1394.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT 18 - AS24167 4166 0.1% 1388.7 -- ASGCNET Academia Sinica Grid Computing Center,TW 19 - AS59743 1253 0.0% 1253.0 -- ELITEHOSTING Angelo Kreikamp trading as Elitehosting,NL 20 - AS11865 2398 0.1% 1199.0 -- G222UV2D21EWD27U76VUWHD7V1FH8HT6HE6W7W12 - STERLING SAVINGS,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 144976 3.4% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 142141 3.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 198.140.115.0/24 41244 0.9% AS53249 -- LAWA-AS - Los Angeles World Airport,US 4 - 198.140.114.0/24 41202 0.9% AS53249 -- LAWA-AS - Los Angeles World Airport,US 5 - 130.0.192.0/21 24852 0.6% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 6 - 64.29.130.0/24 21958 0.5% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY 7 - 192.115.44.0/22 19797 0.5% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 8 - 185.26.155.0/24 12116 0.3% AS60725 -- O3B-AS O3b Limited,JE 9 - 162.249.183.0/24 12047 0.3% AS60725 -- O3B-AS O3b Limited,JE 10 - 192.58.232.0/24 10733 0.2% AS6629 -- NOAA-AS - NOAA,US 11 - 42.83.48.0/20 10555 0.2% AS18135 -- BTV BTV Cable television,JP 12 - 192.36.182.0/24 9804 0.2% AS49317 -- KSPAB Kallmyra System & Produktion AB,SE 13 - 88.87.160.0/19 9224 0.2% AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY AS47680 -- NHCS EOBO Limited,IE 14 - 202.41.92.0/24 6642 0.1% AS2697 -- ERX-ERNET-AS Education and Research Network,IN AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY 15 - 109.160.4.0/22 5695 0.1% AS62174 -- INTERPAN-AS INTERPAN LTD.,BG 16 - 41.228.37.0/24 5402 0.1% AS37693 -- TUNISIANA,TN 17 - 199.187.118.0/24 4571 0.1% AS11054 -- LIVEPERSON - LivePerson, Inc.,US 18 - 148.208.146.0/24 4047 0.1% AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY AS8151 -- Uninet S.A. de C.V.,MX 19 - 84.205.66.0/24 4004 0.1% AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC),EU 20 - 202.141.142.0/24 3850 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 arnold at nipper.de Fri Dec 12 23:33:25 2014 From: arnold at nipper.de (Arnold Nipper) Date: Sat, 13 Dec 2014 00:33:25 +0100 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: References: <548783F4.8010605@nipper.de> <54878B0F.1000405@nipper.de> Message-ID: <548B7B45.9090609@nipper.de> On 11.12.2014 01:33, Phil Bedard wrote: > Curious what the use case is where a photonic or L1 switch wouldn't get > the job done? > Just a matter of costs, Phil. Of course a photonic switch would also do th job. But I neither need the speed of switching over nor all the other features a photonic switch offers. Makes sense? Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Fri Dec 12 23:41:37 2014 From: randy at psg.com (Randy Bush) Date: Fri, 12 Dec 2014 18:41:37 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: > Also, don't you think there is something just morally wrong if folk wish to indulge in hyperbole, could they at least not confuse morals with ethics? randy From javier at advancedmachines.us Sat Dec 13 01:37:09 2014 From: javier at advancedmachines.us (Javier J) Date: Fri, 12 Dec 2014 20:37:09 -0500 Subject: Comcast thinks it ok to install public wifi in your house In-Reply-To: References: <548902D7.60406@mompl.net> <7DB845D64966DC44A1CC592780539B4B01218F4A@nafmbx47.exchange.ford.com> <5489F654.9020107@dougbarton.us> <548A038F.8060109@dougbarton.us> Message-ID: Arguing over semantics are we now? http://www.diffen.com/difference/Ethics_vs_Morals On Fri, Dec 12, 2014 at 6:41 PM, Randy Bush wrote: > > > Also, don't you think there is something just morally wrong > > if folk wish to indulge in hyperbole, could they at least not confuse > morals with ethics? > > randy > From jfmezei_nanog at vaxination.ca Sat Dec 13 01:40:17 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 12 Dec 2014 20:40:17 -0500 Subject: Relative cost of ONT and UPS for FTTP In-Reply-To: <5488C8B2.8010300@vaxination.ca> References: <5488C8B2.8010300@vaxination.ca> Message-ID: <548B9901.30903@vaxination.ca> Thanks to everyone who provided some valuable info in my query. based on a number of responses and some documents my buddy mr Google found for me, the cost for the drop to home including CPE ranges between $650 to $800. But most of those have full "bundle" deployments that include TV service. From markjr at easydns.com Sat Dec 13 02:47:04 2014 From: markjr at easydns.com (Mark E. Jeftovic) Date: Fri, 12 Dec 2014 21:47:04 -0500 Subject: resolver ops: please refresh gov.on.ca Message-ID: <548BA8A8.7090303@easydns.com> All resolver nameserver operators, if you could refresh your caches for gov.on.ca There has been an incident where the government of ontario nameservers were briefly hijacked We will post details to follow in the meantime, if you can refresh your caches, the proper records should be: ens2.gov.on.ca 204.41.4.240 ens1.gov.on.ca 204.41.8.240 thank you all - mark -- Mark E. Jeftovic Founder & CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com From markjr at easydns.com Sat Dec 13 13:21:31 2014 From: markjr at easydns.com (Mark E. Jeftovic) Date: Sat, 13 Dec 2014 08:21:31 -0500 Subject: DNS ops: please refresh gov.on.ca and ontario.ca Message-ID: <548C3D5B.40509@easydns.com> Hello all, Earlier I sent out a request for resolver operators to refresh their cache for gov.on.ca (thank you to all who did). Can you also make sure you refresh ontario.ca? Correct IP for www.gov.on.ca is 54.208.81.96 Correct IPs for gov.on.ca nameservers are: Name servers: ens1.gov.on.ca 204.41.8.240 ens2.gov.on.ca 204.41.4.240 Correct IP for ontario.ca is 54.208.81.96 Thank you all. - mark -- Mark E. Jeftovic Founder & CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com From cfillekes at gmail.com Sun Dec 14 13:55:15 2014 From: cfillekes at gmail.com (C. A. Fillekes) Date: Sun, 14 Dec 2014 08:55:15 -0500 Subject: Looking for piece of undersea cable In-Reply-To: References: Message-ID: Great excuse for taking long walks at the beach, even in the cold. I used to see great snarls of cable on the beach when I was growing up on Long Island -- and later learned that I was looking at the history of transatlantic communication. Bring a hacksaw. On Fri, Dec 12, 2014 at 3:58 PM, Colin McIntosh wrote: > > Hey all, > > I'm looking for a piece of undersea cable to use for educational purposes > and was hoping somebody would have a section they can part with. Doesn't > need to be a big piece, really any size will work. I can pay for shipping > and the cable, if needed. > > Thanks! > -Colin > From morrowc.lists at gmail.com Sun Dec 14 16:16:20 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 14 Dec 2014 11:16:20 -0500 Subject: Looking for piece of undersea cable In-Reply-To: References: Message-ID: Don't most folk get this with a cargo ship and an anchor? On Sun, Dec 14, 2014 at 8:55 AM, C. A. Fillekes wrote: > Great excuse for taking long walks at the beach, even in the cold. I used > to see great snarls of cable on the beach when I was growing up on Long > Island -- and later learned that I was looking at the history of > transatlantic communication. Bring a hacksaw. > > On Fri, Dec 12, 2014 at 3:58 PM, Colin McIntosh > wrote: >> >> Hey all, >> >> I'm looking for a piece of undersea cable to use for educational purposes >> and was hoping somebody would have a section they can part with. Doesn't >> need to be a big piece, really any size will work. I can pay for shipping >> and the cable, if needed. >> >> Thanks! >> -Colin >> From jra at baylink.com Sun Dec 14 16:21:20 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 14 Dec 2014 11:21:20 -0500 (EST) Subject: Relative cost of ONT and UPS for FTTP In-Reply-To: <548B9901.30903@vaxination.ca> Message-ID: <21165938.0.1418574080579.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jean-Francois Mezei" > Thanks to everyone who provided some valuable info in my query. based > on a number of responses and some documents my buddy mr Google found > for me, the cost for the drop to home including CPE ranges between $650 to > $800. But most of those have full "bundle" deployments that include TV > service. I didn't realize that was what you were looking for; that's about the numbers I got 2 years ago for a 12,000 passing 100% deployment over a 3 sq mi city. There was a lot of good information in those threads if you're contemplating doing this from scratch; look for a couple threads started by me in late 2012; July or on, I think. Can't remember the titles, but they oughtta stick out. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From randy at psg.com Sun Dec 14 16:34:44 2014 From: randy at psg.com (Randy Bush) Date: Sun, 14 Dec 2014 11:34:44 -0500 Subject: Looking for piece of undersea cable In-Reply-To: References: Message-ID: >> Great excuse for taking long walks at the beach, even in the cold. I used >> to see great snarls of cable on the beach when I was growing up on Long >> Island -- and later learned that I was looking at the history of >> transatlantic communication. Bring a hacksaw. > Don't most folk get this with a cargo ship and an anchor? too expensive. use a fishing boat. From jfmezei_nanog at vaxination.ca Sun Dec 14 19:40:32 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 14 Dec 2014 14:40:32 -0500 Subject: Relative cost of ONT and UPS for FTTP In-Reply-To: <21165938.0.1418574080579.JavaMail.root@benjamin.baylink.com> References: <21165938.0.1418574080579.JavaMail.root@benjamin.baylink.com> Message-ID: <548DE7B0.20607@vaxination.ca> On 14-12-14 11:21, Jay Ashworth wrote: > I didn't realize that was what you were looking for; that's about the > numbers I got 2 years ago for a 12,000 passing 100% deployment over a > 3 sq mi city. There was a lot of good information in those threads if > you're contemplating doing this from scratch; This was part of a year long process to evaluate the future of wholesale access to last mile in Canada (independent ISPs using incumbent last mile), and in particular whether FTTP should be included in the regulation. Incumbents made arguments that the drop to the home represents 1/3 of the total FTTP investment, and I had to break that down to show that if ISPs pay for the CPE, it represents a significant portion of investment. (Incumbents argue that ISPs ride on their coat-tails and never share risk/investment, as well as the standard "we'll stop investing if you force wholesale" which is also used by AT&T/Verizon in USA. This hearing had enough spin to make anyone's head dizzy :-( From carlos at race.com Mon Dec 15 06:45:16 2014 From: carlos at race.com (Carlos Alcantar) Date: Mon, 15 Dec 2014 06:45:16 +0000 Subject: Relative cost of ONT and UPS for FTTP In-Reply-To: <548DE7B0.20607@vaxination.ca> References: <21165938.0.1418574080579.JavaMail.root@benjamin.baylink.com> <548DE7B0.20607@vaxination.ca> Message-ID: I can only speak on the building we have / are doing I don¹t know that I would say the ont represents 1/3 of the cost. The construction side of things can get fairly costly getting the plant to the point where you could just use opti taps. I¹m not going to say this is everywhere but with new wind loading regulations for poles and some cities trying to use our construction as a way to pay for there streets to get fixed, yes we have been asked to install wheel chair accessible sidewalks and re pave an entire block when we wanted to bore 100 ft on a block that spanned 1000ft and 4 lanes wide. That killed that deal. We have also had the pleasure of working with cities and counties that work with us to get the permits approved which has always been a nice treat. I don¹t think there is a formula every situation can be extremely different. Just my 2 cents. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.comI d On 12/14/14, 11:40 AM, "Jean-Francois Mezei" wrote: >On 14-12-14 11:21, Jay Ashworth wrote: > >> I didn't realize that was what you were looking for; that's about the >> numbers I got 2 years ago for a 12,000 passing 100% deployment over a >> 3 sq mi city. There was a lot of good information in those threads if >> you're contemplating doing this from scratch; > >This was part of a year long process to evaluate the future of wholesale >access to last mile in Canada (independent ISPs using incumbent last >mile), and in particular whether FTTP should be included in the >regulation. > >Incumbents made arguments that the drop to the home represents 1/3 of >the total FTTP investment, and I had to break that down to show that if >ISPs pay for the CPE, it represents a significant portion of investment. >(Incumbents argue that ISPs ride on their coat-tails and never share >risk/investment, as well as the standard "we'll stop investing if you >force wholesale" which is also used by AT&T/Verizon in USA. > >This hearing had enough spin to make anyone's head dizzy :-( > From Peter.teStrake at tradingscreen.com Mon Dec 15 10:50:07 2014 From: Peter.teStrake at tradingscreen.com (Peter teStrake) Date: Mon, 15 Dec 2014 10:50:07 +0000 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: <5488F17F.7030304@bogus.com> Message-ID: Hi Arnold, I have recently been talking to these guys ( https://www.metamako.com/use-cases/ ) about intelligent cross connect management within our data centers. Maybe this would work for you, and probably less complicated than a robot. Cheers Pete On 11/12/2014 09:21, "joel jaeggli" wrote: >On 12/10/14 4:33 PM, Phil Bedard wrote: >> Curious what the use case is where a photonic or L1 switch wouldn't get >> the job done? >> >> With the robotic system you still need to wire everything up so it's >> available to be xconnected. > >We've done electromechanical cross connect termination before on a very >large scale. > >http://www.siemens.com/history/pool/newsarchiv/newsmeldungen/20110403_bild >_3_fernsprechamt_muenchen-schwabing_458px.jpg > >those systems typically don't have the capacity to connect 100% of the >edges at once. > >> FiberZone was another vendor who made robotic patch panels, but I'm not >> sure they are around anymore. >their website is still there, I've never seen an AFM live. >> Interesting also Verizon has a patent on automated patch panels, but >>using >> very specific mechanics. >> >> https://www.google.com/patents/US8175425 >> >> >> >> >> Phil >> >> >> >> >> On 12/9/14, 11:51 PM, "Arnold Nipper" wrote: >> >>> Am 2014-12-10 00:36, schrieb Andrew Jones: >>> >>>> http://www.laser2000.de/out/media/glimmerglass_system_100%281%29.pdf >>>> >>> Thank you, Andrew ... while Glimmerglass is really an exciting and >>> excdellent system, these devices are exactly those photonic cross >>> connects I'm _not_ looking for :9 >>> >>>> On 10.12.2014 10:21, Arnold Nipper wrote: >>>>> I'm looking for a modular, cost-effective automatic / intelligent >>>>>fibre >>>>> optic patch panel. >>>>> >>>>> I'm not looking at these photonic x-connects, but really for >>>>>something >>>>> which does the patching instead of a technician. >>>>> >>> >>> Arnold >>> -- >>> Arnold Nipper / nIPper consulting, Sandhausen, Germany >>> email: arnold at nipper.de phone: +49 6224 5593407 2 >>> mobile: +49 172 2650958 fax: +49 6224 5593407 9 >>> > > From ammar at fastreturn.net Mon Dec 15 11:02:40 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Mon, 15 Dec 2014 15:02:40 +0400 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: References: Message-ID: <71F867DB-EFBB-436B-8F9D-888996BC085D@fastreturn.net> Doesn't the MetaMako device do exactly the same thing as the Glimmerglass photonic switch? Ammar > On 15 Dec 2014, at 2:50 pm, Peter teStrake wrote: > > Hi Arnold, > > I have recently been talking to these guys ( > https://www.metamako.com/use-cases/ ) about intelligent cross connect > management within our data centers. > > Maybe this would work for you, and probably less complicated than a robot. > > Cheers > Pete > > > > >> On 11/12/2014 09:21, "joel jaeggli" wrote: >> >>> On 12/10/14 4:33 PM, Phil Bedard wrote: >>> Curious what the use case is where a photonic or L1 switch wouldn't get >>> the job done? >>> >>> With the robotic system you still need to wire everything up so it's >>> available to be xconnected. >> >> We've done electromechanical cross connect termination before on a very >> large scale. >> >> http://www.siemens.com/history/pool/newsarchiv/newsmeldungen/20110403_bild >> _3_fernsprechamt_muenchen-schwabing_458px.jpg >> >> those systems typically don't have the capacity to connect 100% of the >> edges at once. >> >>> FiberZone was another vendor who made robotic patch panels, but I'm not >>> sure they are around anymore. >> their website is still there, I've never seen an AFM live. >>> Interesting also Verizon has a patent on automated patch panels, but >>> using >>> very specific mechanics. >>> >>> https://www.google.com/patents/US8175425 >>> >>> >>> >>> >>> Phil >>> >>> >>> >>> >>>> On 12/9/14, 11:51 PM, "Arnold Nipper" wrote: >>>> >>>> Am 2014-12-10 00:36, schrieb Andrew Jones: >>>> >>>>> http://www.laser2000.de/out/media/glimmerglass_system_100%281%29.pdf >>>> Thank you, Andrew ... while Glimmerglass is really an exciting and >>>> excdellent system, these devices are exactly those photonic cross >>>> connects I'm _not_ looking for :9 >>>> >>>>>> On 10.12.2014 10:21, Arnold Nipper wrote: >>>>>> I'm looking for a modular, cost-effective automatic / intelligent >>>>>> fibre >>>>>> optic patch panel. >>>>>> >>>>>> I'm not looking at these photonic x-connects, but really for >>>>>> something >>>>>> which does the patching instead of a technician. >>>> >>>> Arnold >>>> -- >>>> Arnold Nipper / nIPper consulting, Sandhausen, Germany >>>> email: arnold at nipper.de phone: +49 6224 5593407 2 >>>> mobile: +49 172 2650958 fax: +49 6224 5593407 9 > From Peter.teStrake at tradingscreen.com Mon Dec 15 12:17:39 2014 From: Peter.teStrake at tradingscreen.com (Peter teStrake) Date: Mon, 15 Dec 2014 12:17:39 +0000 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: <71F867DB-EFBB-436B-8F9D-888996BC085D@fastreturn.net> References: , <71F867DB-EFBB-436B-8F9D-888996BC085D@fastreturn.net> Message-ID: <6A37CAD3-D623-4969-8882-BEE6D4A1029C@tradingscreen.com> Actually you are right Ammar, it does look similar so maybe not appropriate in this situation. Automated cross connects are one of the challenges they are looking to address so it would be interesting to understand why this would not work. -Pete Sent from my iPhone > On 15 Dec 2014, at 11:02, Ammar Zuberi wrote: > > Doesn't the MetaMako device do exactly the same thing as the Glimmerglass photonic switch? > > Ammar > >> On 15 Dec 2014, at 2:50 pm, Peter teStrake wrote: >> >> Hi Arnold, >> >> I have recently been talking to these guys ( >> https://www.metamako.com/use-cases/ ) about intelligent cross connect >> management within our data centers. >> >> Maybe this would work for you, and probably less complicated than a robot. >> >> Cheers >> Pete >> >> >> >> >>>> On 11/12/2014 09:21, "joel jaeggli" wrote: >>>> >>>> On 12/10/14 4:33 PM, Phil Bedard wrote: >>>> Curious what the use case is where a photonic or L1 switch wouldn't get >>>> the job done? >>>> >>>> With the robotic system you still need to wire everything up so it's >>>> available to be xconnected. >>> >>> We've done electromechanical cross connect termination before on a very >>> large scale. >>> >>> http://www.siemens.com/history/pool/newsarchiv/newsmeldungen/20110403_bild >>> _3_fernsprechamt_muenchen-schwabing_458px.jpg >>> >>> those systems typically don't have the capacity to connect 100% of the >>> edges at once. >>> >>>> FiberZone was another vendor who made robotic patch panels, but I'm not >>>> sure they are around anymore. >>> their website is still there, I've never seen an AFM live. >>>> Interesting also Verizon has a patent on automated patch panels, but >>>> using >>>> very specific mechanics. >>>> >>>> https://www.google.com/patents/US8175425 >>>> >>>> >>>> >>>> >>>> Phil >>>> >>>> >>>> >>>> >>>>> On 12/9/14, 11:51 PM, "Arnold Nipper" wrote: >>>>> >>>>> Am 2014-12-10 00:36, schrieb Andrew Jones: >>>>> >>>>>> http://www.laser2000.de/out/media/glimmerglass_system_100%281%29.pdf >>>>> Thank you, Andrew ... while Glimmerglass is really an exciting and >>>>> excdellent system, these devices are exactly those photonic cross >>>>> connects I'm _not_ looking for :9 >>>>> >>>>>>> On 10.12.2014 10:21, Arnold Nipper wrote: >>>>>>> I'm looking for a modular, cost-effective automatic / intelligent >>>>>>> fibre >>>>>>> optic patch panel. >>>>>>> >>>>>>> I'm not looking at these photonic x-connects, but really for >>>>>>> something >>>>>>> which does the patching instead of a technician. >>>>> >>>>> Arnold >>>>> -- >>>>> Arnold Nipper / nIPper consulting, Sandhausen, Germany >>>>> email: arnold at nipper.de phone: +49 6224 5593407 2 >>>>> mobile: +49 172 2650958 fax: +49 6224 5593407 9 >> From cfillekes at gmail.com Mon Dec 15 12:36:14 2014 From: cfillekes at gmail.com (C. A. Fillekes) Date: Mon, 15 Dec 2014 07:36:14 -0500 Subject: Looking for piece of undersea cable In-Reply-To: <548EB524.1020500@hibernianetworks.com> References: <548EB524.1020500@hibernianetworks.com> Message-ID: No, silly! These are the wrecked ones, those great balls of twisted-up frayed cable that wash up on the beach. Not a live wire! They're kind of haunting and atmospheric -- but should be able to get a good slice out of them somewhere. On Mon, Dec 15, 2014 at 5:17 AM, Jeroen Wunnink | Hibernia Networks < jeroen.wunnink at hibernianetworks.com> wrote: > > And rubber gloves if you don't want to die, there's a few thousand volts > of DC current on these things ;-) > > > > On 14/12/14 14:55, C. A. Fillekes wrote: > >> Bring a hacksaw >> > > > -- > > 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 bedard.phil at gmail.com Mon Dec 15 12:42:28 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Mon, 15 Dec 2014 07:42:28 -0500 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer0) In-Reply-To: <548B7B45.9090609@nipper.de> References: <548783F4.8010605@nipper.de> <54878B0F.1000405@nipper.de> <548B7B45.9090609@nipper.de> Message-ID: <548ed749.c388e00a.13da.5ae9@mx.google.com> Those photonic switches are getting cheaper because a ton of people make them now and the components aren't really very expensive. Of course the cost is relative, and I don't know what an electromechanical switch might cost. Glimmerglass, Calient, Polatis were some of the early ones but I've seen a bunch of vendors with 192/384 systems. Phil -----Original Message----- From: "Arnold Nipper" Sent: ‎12/‎12/‎2014 6:33 PM To: "Phil Bedard" ; "nanog at nanog.org" Subject: Re: automatic / intelligent fiber optic patch panel (iow SDN @ layer0) On 11.12.2014 01:33, Phil Bedard wrote: > Curious what the use case is where a photonic or L1 switch wouldn't get > the job done? > Just a matter of costs, Phil. Of course a photonic switch would also do th job. But I neither need the speed of switching over nor all the other features a photonic switch offers. Makes sense? Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 From joshbaird at gmail.com Mon Dec 15 18:07:25 2014 From: joshbaird at gmail.com (Josh Baird) Date: Mon, 15 Dec 2014 13:07:25 -0500 Subject: Anyone from 10796 (TWC)? Message-ID: Hi, Could someone from 10796 please contact me off-list? I'm looking for some assistance with problems between 7018 and 10796 that is affecting customers on my network. Thanks, Josh From jmkeller at houseofzen.org Tue Dec 16 02:01:56 2014 From: jmkeller at houseofzen.org (James Michael Keller) Date: Mon, 15 Dec 2014 21:01:56 -0500 Subject: Cisco AnyConnect speed woes! In-Reply-To: <548A0A0B.4040300@xkl.com> References: <548A04AD.9020404@houseofzen.org> <548A0A0B.4040300@xkl.com> Message-ID: <548F9294.1090804@houseofzen.org> On 12/11/2014 04:18 PM, Roy Hirst wrote: > Confidently based on no knowledge at all - > > *Roy Hirst* | 425-556-5773 | 425-324-0941 cell > XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA > > >>> - We have noticed that in some instances that if a user is on a low >>> speed connection that their VPN speed gets cut by about 1/3. >>> This doesn't >>> seem normal that the VPN would use this much overhead > No, sure, but are you sure that congestion is not dropping a packet > somewhere in the end-to-end? If you offend TCP it will likely cut the > sender's packet transmit rate, even if the "possible" VPN rate is much > higher. >>> - We do not have the issue when connecting to VPN directly on >>> our own >>> network, only connections from the Internet > Internet would mean maybe a proxy or firewall then, with too-small > buffers or an old-time TCP/IP stack? Just a thought. >>> >>> If you have any ideas on what we could try net, please let me know! >>> >>> - Zachary >> >> What OS builds? At one point the code had an 8 packet hard coded >> window per tcp flow, which capped ssl over tcp window size to about >> 5mbps depending on RTT. Recent 8 branches raised this to >> something more reasonable that capped around 20 mbps. DTLS over udp >> and IPSEC tunnels did not have this issue. > UDP traffic does not have this problem but TCP does? Hmmm... >> UDP transport with DTLS or IPSEC in UDP Encapsulation doesn't need to deal with tcp window size scaling and the associated packet buffers. -James From rvandolson at esri.com Tue Dec 16 02:45:52 2014 From: rvandolson at esri.com (Ray Van Dolson) Date: Mon, 15 Dec 2014 18:45:52 -0800 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater Message-ID: <20141216024552.GA26200@esri.com> Hi all; Looking to improve cell reception for mixed ATT/Verizon users on the first floor of one of our buildings. Starting to dig into this and coming across items like this one at Amazon[1], but thought some of you out there might have recommendations for something that has worked well for you and has been reliable. Am in a position to run cable from the roof to the floor in question. Thanks, Ray [1] http://www.amazon.com/Wilson-Electronics-Indoor-Cellular-Booster/dp/B00IWW9AB8/ref=lp_2407782011_1_1?s=wireless&ie=UTF8&qid=1418671553&sr=1-1 From josh at imaginenetworksllc.com Tue Dec 16 02:53:22 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 15 Dec 2014 21:53:22 -0500 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <20141216024552.GA26200@esri.com> References: <20141216024552.GA26200@esri.com> Message-ID: Call Wilson. Explain what you want you do. They'll give you a product number. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Dec 15, 2014 9:46 PM, "Ray Van Dolson" wrote: > Hi all; > > Looking to improve cell reception for mixed ATT/Verizon users on the > first floor of one of our buildings. > > Starting to dig into this and coming across items like this one at > Amazon[1], but thought some of you out there might have recommendations > for something that has worked well for you and has been reliable. > > Am in a position to run cable from the roof to the floor in question. > > Thanks, > Ray > > [1] > http://www.amazon.com/Wilson-Electronics-Indoor-Cellular-Booster/dp/B00IWW9AB8/ref=lp_2407782011_1_1?s=wireless&ie=UTF8&qid=1418671553&sr=1-1 > From johnl at iecc.com Tue Dec 16 02:54:11 2014 From: johnl at iecc.com (John Levine) Date: 16 Dec 2014 02:54:11 -0000 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <20141216024552.GA26200@esri.com> Message-ID: <20141216025411.3707.qmail@ary.lan> In article <20141216024552.GA26200 at esri.com> you write: >Hi all; > >Looking to improve cell reception for mixed ATT/Verizon users on the >first floor of one of our buildings. > >Starting to dig into this and coming across items like this one at >Amazon[1], but thought some of you out there might have recommendations >for something that has worked well for you and has been reliable. The Wilson equipment has a good reputation. Assuming you have good Internet service, you might also consider femtocells, which are small cellular base stations that use your Internet service as backhaul. Verizon: http://www.verizonwireless.com/accessories/samsung-network-extender-scs-2u01/ AT&T: http://www.att.com/att/microcell/ R's, John From ammar at fastreturn.net Tue Dec 16 02:59:13 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Tue, 16 Dec 2014 06:59:13 +0400 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <20141216025411.3707.qmail@ary.lan> References: <20141216025411.3707.qmail@ary.lan> Message-ID: <40C6463F-E48B-4A2A-96C5-4C6E43122DCF@fastreturn.net> Hi, Although this might not apply to you in the US, anyone else thinking about trying this might want to check up on possible legal backlash from using one of these devices. I know you can't legally use one of these in Dubai. Ammar > On 16 Dec 2014, at 6:54 am, John Levine wrote: > > In article <20141216024552.GA26200 at esri.com> you write: >> Hi all; >> >> Looking to improve cell reception for mixed ATT/Verizon users on the >> first floor of one of our buildings. >> >> Starting to dig into this and coming across items like this one at >> Amazon[1], but thought some of you out there might have recommendations >> for something that has worked well for you and has been reliable. > > The Wilson equipment has a good reputation. > > Assuming you have good Internet service, you might also consider > femtocells, which are small cellular base stations that use your > Internet service as backhaul. > > Verizon: http://www.verizonwireless.com/accessories/samsung-network-extender-scs-2u01/ > > AT&T: http://www.att.com/att/microcell/ > > R's, > John From matthew at matthew.at Tue Dec 16 03:07:44 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 15 Dec 2014 19:07:44 -0800 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <40C6463F-E48B-4A2A-96C5-4C6E43122DCF@fastreturn.net> References: <20141216025411.3707.qmail@ary.lan> <40C6463F-E48B-4A2A-96C5-4C6E43122DCF@fastreturn.net> Message-ID: http://wireless.fcc.gov/signal-boosters/faq.html Matthew Kaufman (Sent from my iPhone) > On Dec 15, 2014, at 6:59 PM, Ammar Zuberi wrote: > > Hi, > > Although this might not apply to you in the US, anyone else thinking about trying this might want to check up on possible legal backlash from using one of these devices. I know you can't legally use one of these in Dubai. > > Ammar > >> On 16 Dec 2014, at 6:54 am, John Levine wrote: >> >> In article <20141216024552.GA26200 at esri.com> you write: >>> Hi all; >>> >>> Looking to improve cell reception for mixed ATT/Verizon users on the >>> first floor of one of our buildings. >>> >>> Starting to dig into this and coming across items like this one at >>> Amazon[1], but thought some of you out there might have recommendations >>> for something that has worked well for you and has been reliable. >> >> The Wilson equipment has a good reputation. >> >> Assuming you have good Internet service, you might also consider >> femtocells, which are small cellular base stations that use your >> Internet service as backhaul. >> >> Verizon: http://www.verizonwireless.com/accessories/samsung-network-extender-scs-2u01/ >> >> AT&T: http://www.att.com/att/microcell/ >> >> R's, >> John From johnl at iecc.com Tue Dec 16 03:08:17 2014 From: johnl at iecc.com (John R. Levine) Date: 15 Dec 2014 22:08:17 -0500 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <40C6463F-E48B-4A2A-96C5-4C6E43122DCF@fastreturn.net> References: <20141216025411.3707.qmail@ary.lan> <40C6463F-E48B-4A2A-96C5-4C6E43122DCF@fastreturn.net> Message-ID: > Although this might not apply to you in the US, anyone else thinking about trying this might want to check up on possible legal backlash from using one of these devices. I know you can't legally use one of these in Dubai. These are sold by the carriers and are completely legal here. >> On 16 Dec 2014, at 6:54 am, John Levine wrote: >> >> In article <20141216024552.GA26200 at esri.com> you write: >>> Hi all; >>> >>> Looking to improve cell reception for mixed ATT/Verizon users on the >>> first floor of one of our buildings. >>> >>> Starting to dig into this and coming across items like this one at >>> Amazon[1], but thought some of you out there might have recommendations >>> for something that has worked well for you and has been reliable. >> >> The Wilson equipment has a good reputation. >> >> Assuming you have good Internet service, you might also consider >> femtocells, which are small cellular base stations that use your >> Internet service as backhaul. >> >> Verizon: http://www.verizonwireless.com/accessories/samsung-network-extender-scs-2u01/ >> >> AT&T: http://www.att.com/att/microcell/ >> >> R's, >> John > From ryan at deadfrog.net Tue Dec 16 03:14:33 2014 From: ryan at deadfrog.net (Ryan Wilkins) Date: Mon, 15 Dec 2014 22:14:33 -0500 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <40C6463F-E48B-4A2A-96C5-4C6E43122DCF@fastreturn.net> References: <20141216025411.3707.qmail@ary.lan> <40C6463F-E48B-4A2A-96C5-4C6E43122DCF@fastreturn.net> Message-ID: > On Dec 15, 2014, at 9:59 PM, Ammar Zuberi wrote: > > Although this might not apply to you in the US, anyone else thinking about trying this might want to check up on possible legal backlash from using one of these devices. I know you can't legally use one of these in Dubai. They’re legal in the US as long as they’re registered with the carrier and meet the new regulations for intelligent cellular repeaters. There were some new laws regarding these repeaters that went into effect earlier this year, I think around April. A Cel-Fi repeater that I used to own did a nifty thing by scanning for and amplifying only the signals belonging to the carrier the repeater was programmed for rather than doing a full band repeat of everyone. I got rid of the Cel-Fi when I upgraded to the iPhone 5S which has WiFi calling available on it. It works quite well and no need for the repeater any more. Best, Ryan Wilkins From colton.conor at gmail.com Tue Dec 16 13:45:14 2014 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 16 Dec 2014 07:45:14 -0600 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216025411.3707.qmail@ary.lan> <40C6463F-E48B-4A2A-96C5-4C6E43122DCF@fastreturn.net> Message-ID: Wilson is the way to go. They have a couple of products not on their website that only certified installers can sell that are even higher powered. Works with all 4 4G carriers at once. On Mon, Dec 15, 2014 at 9:14 PM, Ryan Wilkins wrote: > > > > On Dec 15, 2014, at 9:59 PM, Ammar Zuberi wrote: > > > > Although this might not apply to you in the US, anyone else thinking > about trying this might want to check up on possible legal backlash from > using one of these devices. I know you can't legally use one of these in > Dubai. > > They’re legal in the US as long as they’re registered with the carrier and > meet the new regulations for intelligent cellular repeaters. There were > some new laws regarding these repeaters that went into effect earlier this > year, I think around April. > > A Cel-Fi repeater that I used to own did a nifty thing by scanning for and > amplifying only the signals belonging to the carrier the repeater was > programmed for rather than doing a full band repeat of everyone. I got rid > of the Cel-Fi when I upgraded to the iPhone 5S which has WiFi calling > available on it. It works quite well and no need for the repeater any more. > > Best, > Ryan Wilkins > > > From patrick.sumby at sohonet.com Tue Dec 16 15:08:31 2014 From: patrick.sumby at sohonet.com (Patrick Sumby) Date: Tue, 16 Dec 2014 15:08:31 +0000 Subject: AT&T - XO Peering (AS7018 and AS2828) Message-ID: <54904AEF.506@sohonet.com> Hi, Please could someone from ATT and/or XO contact me off list to discuss some issues we've been seeing on a link between AS7018 and AS2828. Thanks Pat -- --- Patrick Sumby Director of Global Engineering Sohonet From zachary.mcgibbon+nanog at gmail.com Tue Dec 16 15:30:01 2014 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Tue, 16 Dec 2014 10:30:01 -0500 Subject: Cisco AnyConnect speed woes! In-Reply-To: References: <244fd40df6074e58b55631b179929227@pur-vm-exch13n1.ox.com> <002101d013f8$8e6c6530$ab452f90$@ipnetworks.it> Message-ID: We seem to have narrowed down the problem to our Cisco SCE packet shaper. It seems to be misclassifying about 15-20% of the DTLS traffic into encrypted bittorrent and since we have shaping rules in place to limit torrent traffic, this was causing the issue. To resolve the issue, we put the IP of our VPN ASA into a different package on the SCE and did not apply any shaping rules to it. We are still monitoring to be sure but we are quite confident this was the issue. So note to anyone out there using a shaper and has a DTLS VPN behind it, check your classifications or whitelist your VPN box! - Zachary On Tue, Dec 9, 2014 at 7:39 PM, Zachary McGibbon < zachary.mcgibbon+nanog at gmail.com> wrote: > > Hi Roberto, > > - We have disabled the DTLS compression feature, this has been verified on > the client side that compression says 'None' > - We are not using the VPN load balancing feature, the two boxes are > running in an active/standby configuration > - Yes we are tunnelling all traffic however local lan access is available > if the user checks the checkbox in their client > - We are inspecting the following: > dns preset_dns_map, ftp, h323 h225, h323 ras, rsh, rtsp, esmtp, sqlnet, > skinny, sunrpc, xdmcp, sip, netbios, tftp, ip-options, icmp > - Jumbo frames are not configured > - We are using the following encryption methods: AES128 and 2048 bit > certificate > - We are running ASA 9.2.2.8 on a 5545X > - We are pushing the Anyconnect client version 3.1.05182 > > Also, I should mention what I mean when we see slow speeds. For example, > my internet connection at home is a cable modem with 30mb down, 10mb up. I > have done a path mtu discovery to my VPN at work and it is 1500. When I > run an iperf to a server at the office without vpn I get about 28mb down, > 9.5mb up. When I connect to vpn, the iperf to the same server is about > 1.2mb down, and 900k up. This is way too slow! > > - Zachary > > On Tue, Dec 9, 2014 at 4:39 PM, Roberto wrote: > >> > The big issue we are having is that many of our users are complaining >> of low speed when connected to the VPN. >> Please can you indicate more details ? >> >> Is it enabled on the ASA the "compression" feature ? >> Is it enabled on the ASA the VPN Load Balancing feature ? >> Are you using the AnyConnect FULL TUNNEL mode ? >> Which are the inspection configured on the ASA for the "remote access" >> clients ? >> Have you configured the Jumbo MTU on the CISCO ASA interfaces ? >> Which encryption are configured on the ASA (are you using Suite B >> Algorithms) ? >> Which version of ASA are you using ? >> Which version of AnyConnect are you using ? >> >> >> Note: >> protocols such as L2TP/IPSec are not hardware accelerated -- the IPSec >> portion of L2TP/IPSec is hardware-accelerated, but the L2TP portion is not. >> Likewise, the SSL portions of SVC and WebVPN use hardware acceleration, >> but the application layer protocols are done in software. >> >> >> Best Regards, >> >> _________________________________ >> Roberto Taccon >> >> e-mail: roberto at ipnetworks.it >> mobile: +39 340 4751352 >> fax: +39 045 4850850 >> skype: roberto.taccon >> >> -----Messaggio originale----- >> Da: NANOG [mailto:nanog-bounces at nanog.org] Per conto di Zachary McGibbon >> Inviato: martedì 9 dicembre 2014 21.18 >> A: Matthew Huff >> Cc: NANOG >> Oggetto: Re: Cisco AnyConnect speed woes! >> >> We are trying to use SSLVPN (udp 443) and results are really all over the >> place. Most of our complaints are users connecting on Teksavvy however we >> haven't been able to reach anyone in their network team to find out if they >> are doing any filtering or shaping on their side. >> >> We don't have a lot of traffic coming through Cogent, most of the users >> are local here in Montreal on either Bell or Videotron and they traverse >> through the QIX (www.qix.ca) >> >> On Tue, Dec 9, 2014 at 3:03 PM, Matthew Huff wrote: >> >> > Are you using SSLVpn or IPSEC with anyconnect? I have had more luck >> > with performance with IPSEC than SSLVpn. >> > >> > Also, just because your ISP is saying that they aren't >> > shaping/filtering, doesn't mean they aren't. >> > >> > We had major issues with users using AnyConnect when it was >> > transversing Cogent. We were getting 5-10% packet loss (although the >> > Cisco stats didn't show it), and it was choking on it. >> > >> > ---- >> > Matthew Huff | 1 Manhattanville Rd >> > Director of Operations | Purchase, NY 10577 >> > OTA Management LLC | Phone: 914-460-4039 >> > aim: matthewbhuff | Fax: 914-694-5669 >> > >> > -----Original Message----- >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Zachary >> > McGibbon >> > Sent: Tuesday, December 9, 2014 2:42 PM >> > To: NANOG >> > Subject: Cisco AnyConnect speed woes! >> > >> > I'm looking for some input on a situation that has been plaguing our >> > new AnyConnect VPN setup. Any input would be valuable, we are at a >> > loss for what the problem is. >> > >> > We recently upgraded our VPN from our old Cisco 3000 VPN concentrators >> > running PPTP and we are now running a pair of Cisco 5545x ASAs in an >> > HA active/standby pair. >> > >> > The big issue we are having is that many of our users are complaining >> > of low speed when connected to the VPN. We have done tons of >> > troubleshooting with Cisco TAC and we still haven't found the root of >> our problem. >> > >> > Some tests we have done: >> > >> > - We have tested changing MTU values >> > - We have tried all combinations of encryption methods (SSL, TLS, >> IPSec, >> > L2TP) with similar results >> > - We have switched our active/standby boxes >> > - We have tested on our spare 5545x box >> > - We connected our spare box directly to our ISP with another IP >> address >> > - We have whitelisted our VPN IP on our shaper (Cisco SCE8000) and >> our >> > IPS (HP Tipping Point) >> > - We have bypassed our Shaper and our IPS >> > - We made sure that traffic from the routers talking to our ASAs is >> > synchronous, OSPF was configured to load balance but this has been >> > changed >> > by changing the costs on the links to the ASAs >> > - We have verified with our two ISPs that they are not doing any >> kind of >> > filtering or shaping >> > - We have noticed that in some instances that if a user is on a low >> > speed connection that their VPN speed gets cut by about 1/3. This >> > doesn't >> > seem normal that the VPN would use this much overhead >> > - We do not have the issue when connecting to VPN directly on our own >> > network, only connections from the Internet >> > >> > If you have any ideas on what we could try net, please let me know! >> > >> > - Zachary >> > >> >> > From jason at lixfeld.ca Tue Dec 16 16:32:40 2014 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 16 Dec 2014 11:32:40 -0500 Subject: Is there a case for storm control and/or unknown traffic flood control in 'protected' bridge-domain? Message-ID: Greetings, Conceptually, a layer 2 port that is configured for either port protect mode (a’la Cisco 2950 vintage), UNI port-type (a’la Cisco ME3400 vintage) or EVC + split-horizon (a’la ME3600 vintage) should negate any requirement for features such as storm control or unknown traffic flood control to be configured in conjunction with either of those port modes. In theory then, either of the three aforementioned configuration modes would prevent any and all cross-talk between ports, in the same bridge-domain, notwithstanding traffic hitting the ‘trusted’ port, be it the trunk or uplink port, SVI, routed BD or whatever name your hardware uses to define that trusted port. Assuming that’s an accurate theory, is there a case that I might be missing where one would need to use storm control or unknown traffic flood control in this sort of environment? From baldur.norddahl at gmail.com Tue Dec 16 17:27:23 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 16 Dec 2014 18:27:23 +0100 Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: References: Message-ID: Hi, Zhone reversed their stance on this and put everything on finding a fix. Now we have a working firmware that moves data at line speed with no need to put limits on downloads. Everyone are happy now. The 2301 with new firmware is performing as expected and seems like a good product for our needs. Baldur From alex at corp.nac.net Tue Dec 16 17:32:40 2014 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 16 Dec 2014 17:32:40 +0000 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <20141216025411.3707.qmail@ary.lan> References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> Message-ID: These work well, I have an ATT in my house. However, in a broad deployment (like in a datacenter with lots of discreet visitors) it is pointless, because ATT requires registration of any phone connected and it is limited to 10. I just with Wifi calling was ubiquitous. > Assuming you have good Internet service, you might also consider femtocells, > which are small cellular base stations that use your Internet service as backhaul. > > Verizon: http://www.verizonwireless.com/accessories/samsung-network- > extender-scs-2u01/ From morrowc.lists at gmail.com Tue Dec 16 17:35:22 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 16 Dec 2014 12:35:22 -0500 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> Message-ID: On Tue, Dec 16, 2014 at 12:32 PM, Alex Rubenstein wrote: > > I just with Wifi calling was ubiquitous. isn't it in every android phone since ~1yr ago? From josh at imaginenetworksllc.com Tue Dec 16 17:44:16 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 16 Dec 2014 12:44:16 -0500 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> Message-ID: Definitely not. My Droid Maxx on VZW does not do Wifi calling. I have yet to see Wifi calls (excluding SIP clients and such) on any phone around here. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Dec 16, 2014 at 12:35 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Tue, Dec 16, 2014 at 12:32 PM, Alex Rubenstein > wrote: > > > > I just with Wifi calling was ubiquitous. > > isn't it in every android phone since ~1yr ago? > From streiner at cluebyfour.org Tue Dec 16 17:49:55 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 16 Dec 2014 12:49:55 -0500 (EST) Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: References: Message-ID: On Tue, 16 Dec 2014, Baldur Norddahl wrote: > Zhone reversed their stance on this and put everything on finding a fix. > Now we have a working firmware that moves data at line speed with no need > to put limits on downloads. Everyone are happy now. The 2301 with new > firmware is performing as expected and seems like a good product for our > needs. Good to see they came around. I take it they did not elaborate on their sudden change of heart? jms From johnl at iecc.com Tue Dec 16 17:52:51 2014 From: johnl at iecc.com (John R. Levine) Date: 16 Dec 2014 12:52:51 -0500 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> Message-ID: >> I just with Wifi calling was ubiquitous. > > isn't it in every android phone since ~1yr ago? Yes, but it works poorly when walking the dog. R's, John From trejrco at gmail.com Tue Dec 16 18:02:15 2014 From: trejrco at gmail.com (TJ) Date: Tue, 16 Dec 2014 18:02:15 +0000 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> Message-ID: Hangouts Dialer gets you VOIP calls, whether WiFi or Cellular data is in use ... albeit from your GVoice#, not native/telco number. /TJ On Tue Dec 16 2014 at 12:55:49 PM John R. Levine wrote: > >> I just with Wifi calling was ubiquitous. > > > > isn't it in every android phone since ~1yr ago? > > Yes, but it works poorly when walking the dog. > > R's, > John > From nanog at ics-il.net Tue Dec 16 18:04:39 2014 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 16 Dec 2014 12:04:39 -0600 (CST) Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: Message-ID: <19540907.6853.1418753105749.JavaMail.mhammett@ThunderFuck> Unless your native number is your GV number. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "TJ" To: "John R. Levine" , "Christopher Morrow" Cc: "Alex Rubenstein" , nanog at nanog.org Sent: Tuesday, December 16, 2014 12:02:15 PM Subject: Re: OT - Verizon/ATT Cell/4G Signal Booster/Repeater Hangouts Dialer gets you VOIP calls, whether WiFi or Cellular data is in use ... albeit from your GVoice#, not native/telco number. /TJ On Tue Dec 16 2014 at 12:55:49 PM John R. Levine wrote: > >> I just with Wifi calling was ubiquitous. > > > > isn't it in every android phone since ~1yr ago? > > Yes, but it works poorly when walking the dog. > > R's, > John > From jschiel at flowtools.net Tue Dec 16 18:27:38 2014 From: jschiel at flowtools.net (John Schiel) Date: Tue, 16 Dec 2014 11:27:38 -0700 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <20141216024552.GA26200@esri.com> References: <20141216024552.GA26200@esri.com> Message-ID: <5490799A.9070109@flowtools.net> On 12/15/2014 07:45 PM, Ray Van Dolson wrote: One thing you might also want to consider are any calls you make to 911 whilst using a repeater. I use a repeater supplied by T-Mobile and they made it very clear, and I had to specifically acknowledge a statement, that using such a repeater takes away from emergency services being able to find out where you are if you make a 911 call from your mobile. Some may refer to this as a feature, depending on how much tin foil you have laying about, but the users of such device may need to be warned about emergency calls. They'll need to be able to describe where they are to the responding sirens. --John > Hi all; > > Looking to improve cell reception for mixed ATT/Verizon users on the > first floor of one of our buildings. > > Starting to dig into this and coming across items like this one at > Amazon[1], but thought some of you out there might have recommendations > for something that has worked well for you and has been reliable. > > Am in a position to run cable from the roof to the floor in question. > > Thanks, > Ray > > [1] http://www.amazon.com/Wilson-Electronics-Indoor-Cellular-Booster/dp/B00IWW9AB8/ref=lp_2407782011_1_1?s=wireless&ie=UTF8&qid=1418671553&sr=1-1 From morrowc.lists at gmail.com Tue Dec 16 19:19:53 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 16 Dec 2014 14:19:53 -0500 Subject: ARIN's RPKI Relying agreement In-Reply-To: <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net> Message-ID: zombie-thread! On Thu, Dec 4, 2014 at 12:39 PM, John Curran wrote: > t (i.e. exactly the opposite of your “my routing decisions are affected > and breakage happens” statement in your prior email.) the discussion in the thread was interesting, sometimes a bit more personal than was required and at times devoid of useful data... but I did want to point out one thing, I didn't say the quoted section, at least not in this thread... thanks john for hanging in for the discussion... -chris From baldur.norddahl at gmail.com Tue Dec 16 19:29:38 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 16 Dec 2014 20:29:38 +0100 Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: References: Message-ID: No, but I would say that they were afraid they might not be able to fix the problem and somebody in the sales organization misstepped. Our reseller went the extra mile for us and managed to escalate the issue all the way to the CTO level. Apparently it was not an easy problem to fix. The problem would be with the chipset. Our reseller found a competing product that used the same chipset, and they had the same problem. Only the competing product would be stable at 950 Mbps instead of the 750 Mbps we had on the Zhone product. We agreed with Zhone that if they could tune it to 950 Mbps, we could live with that as "good enough". But in the end they actually managed to fix it completely, so now the Zhone product is line speed and the competing product is not. Learning from this, I would recommend everyone considering a GPON product based on a new chipset, to test how it performs when downloading at line speed, especially if the source is a 10 Gbps enabled server. There is apparently a bad chipset out there, that requires careful tuning for it to perform to spec. Even if you are not selling gigabit, there are microbursts that could cause trouble. Our speedtests now looks like this: http://www.speedtest.net/my-result/3962524900 - this is good as in reality the speedtest is what people are buying... Regards, Baldur On 16 December 2014 at 18:49, Justin M. Streiner wrote: > On Tue, 16 Dec 2014, Baldur Norddahl wrote: > > Zhone reversed their stance on this and put everything on finding a fix. >> Now we have a working firmware that moves data at line speed with no need >> to put limits on downloads. Everyone are happy now. The 2301 with new >> firmware is performing as expected and seems like a good product for our >> needs. >> > > Good to see they came around. I take it they did not elaborate on their > sudden change of heart? > > jms > From mhuff at ox.com Tue Dec 16 19:38:06 2014 From: mhuff at ox.com (Matthew Huff) Date: Tue, 16 Dec 2014 19:38:06 +0000 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <5490799A.9070109@flowtools.net> References: <20141216024552.GA26200@esri.com> <5490799A.9070109@flowtools.net> Message-ID: <89dd38485c524cfb89da448d4e99415c@pur-vm-exch13n2.ox.com> Be careful about the new rules that were put into place in the spring. My experience is that resellers are still promoting "consumer" devices for use in commercial buildings which is now a no-no. Under the new regulation, consumer devices are to be used only for individuals in their home, car, RV, boat, etc.. Industrial signal boosters are the only allowed non-grandfathered devices to be used in buildings. They have to be installed by certified installers and require a FCC license under the new regulations. The new fines are steep at $100,000 an instance, so the wireless providers really have a hold of the FCC. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Schiel Sent: Tuesday, December 16, 2014 1:28 PM To: nanog at nanog.org Subject: Re: OT - Verizon/ATT Cell/4G Signal Booster/Repeater On 12/15/2014 07:45 PM, Ray Van Dolson wrote: One thing you might also want to consider are any calls you make to 911 whilst using a repeater. I use a repeater supplied by T-Mobile and they made it very clear, and I had to specifically acknowledge a statement, that using such a repeater takes away from emergency services being able to find out where you are if you make a 911 call from your mobile. Some may refer to this as a feature, depending on how much tin foil you have laying about, but the users of such device may need to be warned about emergency calls. They'll need to be able to describe where they are to the responding sirens. --John > Hi all; > > Looking to improve cell reception for mixed ATT/Verizon users on the > first floor of one of our buildings. > > Starting to dig into this and coming across items like this one at > Amazon[1], but thought some of you out there might have recommendations > for something that has worked well for you and has been reliable. > > Am in a position to run cable from the roof to the floor in question. > > Thanks, > Ray > > [1] http://www.amazon.com/Wilson-Electronics-Indoor-Cellular-Booster/dp/B00IWW9AB8/ref=lp_2407782011_1_1?s=wireless&ie=UTF8&qid=1418671553&sr=1-1 From jcurran at arin.net Tue Dec 16 19:43:18 2014 From: jcurran at arin.net (John Curran) Date: Tue, 16 Dec 2014 19:43:18 +0000 Subject: ARIN's RPKI Relying agreement In-Reply-To: References: <54807641.9030006@gmail.com> <44004.1417705448@turing-police.cc.vt.edu> <54807F5F.2080209@gmail.com> <3CC31BD8-B3B0-414B-859B-9B9829B13987@pch.net> <9A6EAE25-767C-42D4-9F04-D843B8028B1A@arin.net>, Message-ID: <42B78C4F-BA03-4106-8A3C-09CAD70B277F@arin.net> > On Dec 16, 2014, at 2:19 PM, Christopher Morrow wrote: > > zombie-thread! > >> On Thu, Dec 4, 2014 at 12:39 PM, John Curran wrote: >> t (i.e. exactly the opposite of your “my routing decisions are affected >> and breakage happens” statement in your prior email.) > > the discussion in the thread was interesting, sometimes a bit more > personal than was required and at times devoid of useful data... but I > did want to point out one thing, I didn't say the quoted section, at > least not in this thread... Ah, yes... "breakage happens" was another gentleman over on PPML (and apologies for any confusion!) > thanks john for hanging in for the discussion... Thanks to everyone for the important feedback (even if somewhat pointed at times... :-) /John John Curran President and CEO ARIN From cb.list6 at gmail.com Tue Dec 16 20:46:00 2014 From: cb.list6 at gmail.com (Ca By) Date: Tue, 16 Dec 2014 12:46:00 -0800 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> Message-ID: On Tuesday, December 16, 2014, Christopher Morrow wrote: > On Tue, Dec 16, 2014 at 12:32 PM, Alex Rubenstein > wrote: > > > > I just with Wifi calling was ubiquitous. > > isn't it in every android phone since ~1yr ago? > For some usa mobile providers nearly every android phone supports wifi calling... And iPhone6 too. For anyone doing VoLTE, VoWiFi should be a slam dunk. CB From mhuff at ox.com Tue Dec 16 20:57:07 2014 From: mhuff at ox.com (Matthew Huff) Date: Tue, 16 Dec 2014 20:57:07 +0000 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> Message-ID: <602dce3d13dc4c71940c26b733317e5e@pur-vm-exch13n2.ox.com> If your users are all using the latest models... great We still have people using flip phones... We had to shut down our legacy signal booster when a provider sent us a cease and desist letter. We are still looking for a replacement solution that meets the new code. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ca By Sent: Tuesday, December 16, 2014 3:46 PM To: Christopher Morrow Cc: John Levine; Alex Rubenstein; nanog at nanog.org Subject: Re: OT - Verizon/ATT Cell/4G Signal Booster/Repeater On Tuesday, December 16, 2014, Christopher Morrow wrote: > On Tue, Dec 16, 2014 at 12:32 PM, Alex Rubenstein > wrote: > > > > I just with Wifi calling was ubiquitous. > > isn't it in every android phone since ~1yr ago? > For some usa mobile providers nearly every android phone supports wifi calling... And iPhone6 too. For anyone doing VoLTE, VoWiFi should be a slam dunk. CB From alex at corp.nac.net Tue Dec 16 21:11:39 2014 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 16 Dec 2014 21:11:39 +0000 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <602dce3d13dc4c71940c26b733317e5e@pur-vm-exch13n2.ox.com> References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> <602dce3d13dc4c71940c26b733317e5e@pur-vm-exch13n2.ox.com> Message-ID: > > On Tue, Dec 16, 2014 at 12:32 PM, Alex Rubenstein > > wrote: > > > > > > I just with Wifi calling was ubiquitous. > > > > isn't it in every android phone since ~1yr ago? Perhaps they are, but AT&T and Verizon don't allow it, because they are terrible. From brandon at burn.net Wed Dec 17 02:50:27 2014 From: brandon at burn.net (Brandon Applegate) Date: Tue, 16 Dec 2014 21:50:27 -0500 Subject: Anyone from Cloudflare ? (IPv6 issue) Message-ID: <04D5A773-DCED-4BE2-B614-2987A5D13BE6@burn.net> Anyone from Cloudflare able/willing to contact me off list to troubleshoot a very frustrating and intermittent IPv6 connectivity issue ? I have plenty of data points, multiple test systems (Testing from 2 working ASes, and the 1 AS in question that’s broken). Otherwise - if anyone could share a way to get to clue @Cloudflare I would greatly appreciate it. I put a request in through the web support front door, but I got back about what I expected. Thanks. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 830B 4802 1DD4 F4F9 63FE B966 C0A7 189E 9EC0 3A74 "SH1-0151. This is the serial number, of our orbital gun." -------------- 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 ag4ve.us at gmail.com Wed Dec 17 10:20:09 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 17 Dec 2014 05:20:09 -0500 Subject: Fwd: malware.watch rdns In-Reply-To: References: Message-ID: I asked on this on another list I'm on and didn't get any reply, so I figured I might have better luck here Anyone know what malware.watch. is doing? Below is basically everything I could find: http://www.robtex.net/en/advisory/dns/watch/malware/ssl-scanning-015/ They've got a web page, but nothing there: % curl -I malware.watch HTTP/1.1 200 OK Date: Thu, 13 Nov 2014 19:17:29 GMT Content-Type: text/html Connection: keep-alive Set-Cookie: __cfduid= da37b063f68032dfe5adc07ae35fe27031415906249; expires=Fri, 13-Nov-15 19:17:29 GMT; path=/; domain=.malware.watch; HttpOnly X-Frame-Options: sameorigin Server: cloudflare-nginx CF-RAY: 188d4f4cd3cb0eeb-EWR What I saw was ssl-scanning-###.malware.watch, so after that curl I figured I'd start by blowing up their dns :) % printf '%03d\n' {0..999} | while read f; do dig=$(dig "ssl-scanning-${f}.malware.watch" +short); if [ -n "$dig" ]; then echo "$f: $dig"; fi; done ~ swlap1 015: 85.17.239.155 016: 104.200.21.140 017: 195.154.114.206 (It was pointed out to me this could be more easily written as: dig +noall +ans ssl-scanning-{000..999}.malware.watch) So they only have three in that block, on is in the Netherlands, the other is Linode (US), and the last is French: 8 21.28 ms as4436-1-c.111eighthave.ny.ibone.comcast.net (173.167.57.162) 9 17.01 ms vlan-75.ar2.ewr1.us.as4436.gtt.net (69.31.34.129) 10 15.73 ms as13335.xe-7-0-3.ar2.ewr1.us.as4436.gtt.net (69.31.95.70) 11 15.85 ms 104.28.19.47 7 10.07 ms he-1-15-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.85.70) 8 9.58 ms ae15.bbr02.eq01.wdc02.networklayer.com (75.149.228.94) 9 10.98 ms ae7.bbr01.eq01.wdc02.networklayer.com (173.192.18.194) 10 23.08 ms ae0.bbr01.tl01.atl01.networklayer.com (173.192.18.153) 11 43.01 ms ae13.bbr02.eq01.dal03.networklayer.com (173.192.18.134) 12 43.02 ms po32.dsr02.dllstx3.networklayer.com (173.192.18.231) 13 44.33 ms po32.dsr02.dllstx2.networklayer.com (70.87.255.70) 14 50.71 ms po2.car01.dllstx2.networklayer.com (70.87.254.78) 15 41.94 ms router1-dal.linode.com (67.18.7.90) 16 42.63 ms li799-140.members.linode.com (104.200.21.140) 7 11.36 ms he-0-13-0-1-pe04.ashburn.va.ibone.comcast.net (68.86.87.142) 8 10.95 ms xe-7-0-2.was10.ip4.gtt.net (77.67.71.193) 9 87.79 ms xe-4-2-0.par22.ip4.gtt.net (89.149.182.98) 10 87.80 ms online-gw.ip4.gtt.net (46.33.93.90) 11 91.82 ms 49e-s46-1-a9k1.dc3.poneytelecom.eu (195.154.1.77) 12 88.27 ms ssl-scanning-017.malware.watch (195.154.114.206) From tom at ninjabadger.net Wed Dec 17 10:28:38 2014 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 17 Dec 2014 10:28:38 +0000 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer 0) In-Reply-To: <6A37CAD3-D623-4969-8882-BEE6D4A1029C@tradingscreen.com> References: , <71F867DB-EFBB-436B-8F9D-888996BC085D@fastreturn.net> <6A37CAD3-D623-4969-8882-BEE6D4A1029C@tradingscreen.com> Message-ID: <54915AD6.8090707@ninjabadger.net> On 15/12/14 12:17, Peter teStrake wrote: > Automated cross connects are one of the challenges they are looking > to address so it would be interesting to understand why this would > not work. Aren't all of these photonic switches active devices? i.e. Lose power and your light disappears. The robotic device linked earlier in the thread, specifically states that all you lose in the event of a power outage is the ability to make changes. -- Tom From bedard.phil at gmail.com Wed Dec 17 13:35:27 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 17 Dec 2014 08:35:27 -0500 Subject: automatic / intelligent fiber optic patch panel (iow SDN @ layer0) In-Reply-To: <54915AD6.8090707@ninjabadger.net> References: , <71F867DB-EFBB-436B-8F9D-888996BC085D@fastreturn.net> <6A37CAD3-D623-4969-8882-BEE6D4A1029C@tradingscreen.com> <54915AD6.8090707@ninjabadger.net> Message-ID: <549186aa.c388e00a.5b7f.ffff81a1@mx.google.com> Not for basic xconnect, they use MEMS arrays (mirrors). You need power to change things and some do offer more advanced stuff like VOA, protection, etc requiring power. Phil -----Original Message----- From: "Tom Hill" Sent: ‎12/‎17/‎2014 5:30 AM To: "nanog at nanog.org" Subject: Re: automatic / intelligent fiber optic patch panel (iow SDN @ layer0) On 15/12/14 12:17, Peter teStrake wrote: > Automated cross connects are one of the challenges they are looking > to address so it would be interesting to understand why this would > not work. Aren't all of these photonic switches active devices? i.e. Lose power and your light disappears. The robotic device linked earlier in the thread, specifically states that all you lose in the event of a power outage is the ability to make changes. -- Tom From alessandro.ratti at gmail.com Wed Dec 17 14:14:34 2014 From: alessandro.ratti at gmail.com (Alessandro Ratti) Date: Wed, 17 Dec 2014 15:14:34 +0100 Subject: Issue to reach AS3269 through AS6762 Message-ID: Hi guys, is there anyone from Telecom Italia that should contact me offlist? Thanks -- Alessandro Ratti From di at egihosting.com Wed Dec 17 20:39:44 2014 From: di at egihosting.com (Di Li) Date: Wed, 17 Dec 2014 12:39:44 -0800 Subject: Anyone from Nike.com Message-ID: Anyone from Nike.com willing to contact me off list to troubleshooting some IP space blocking issues -- Thanks, Di From leah.reveliotty at virginamerica.com Wed Dec 17 21:47:33 2014 From: leah.reveliotty at virginamerica.com (Leah Reveliotty) Date: Wed, 17 Dec 2014 13:47:33 -0800 Subject: Level3 to Savvis/CenturyLink problems? In-Reply-To: 6802d58cf9e04ed289db486333f1e6ba@mail.gmail.com References: 6802d58cf9e04ed289db486333f1e6ba@mail.gmail.com Message-ID: <561dba60b32dca63e047ce8fd1f611ff@mail.gmail.com> We have an MPLS backbone from Level3 and are experiencing issues between two of our San Francisco Bay Area locations – namely our HQ in Burlingame, CA and our Savvis/CenturyLink Data Center in Santa Clara, CA. Ping response times between these 2 sites are within the normal range, but our Applications are timing out. We’ve obviously done a ton of troubleshooting on the Application side of things, but everything points back to a circuit issue and after a lot of testing we are scratching our heads trying to narrow down this issue. So I wanted to post to this list to see if anyone else has noticed issues with their Level3 circuits in the Bay Area over the last 2 days as well? Thanks for your feedback! Regards, Leah From joelja at bogus.com Thu Dec 18 06:08:12 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 17 Dec 2014 22:08:12 -0800 Subject: Looking for a contact at Magix as9506 or someone at singtel who has insight into the operation of 9506 Message-ID: <54926F4C.2090508@bogus.com> We're have a little bit of trouble reaching your customers with a prefix advertised in SIN and there's little or no visibility from the 9506 vantage point. Thanks in Advance. Joel (as54113) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 221 bytes Desc: OpenPGP digital signature URL: From teleric-lists at outlook.com Thu Dec 18 14:14:56 2014 From: teleric-lists at outlook.com (Teleric Team) Date: Thu, 18 Dec 2014 09:14:56 -0500 Subject: Level3 to Savvis/CenturyLink problems? In-Reply-To: <561dba60b32dca63e047ce8fd1f611ff@mail.gmail.com> References: 6802d58cf9e04ed289db486333f1e6ba@mail.gmail.com, <561dba60b32dca63e047ce8fd1f611ff@mail.gmail.com> Message-ID: > From: leah.reveliotty at virginamerica.com > Date: Wed, 17 Dec 2014 13:47:33 -0800 > Subject: Level3 to Savvis/CenturyLink problems? > To: nanog at nanog.org > > We have an MPLS backbone from Level3 and are experiencing issues between > two of our San Francisco Bay Area locations – namely our HQ in Burlingame, > CA and our Savvis/CenturyLink Data Center in Santa Clara, CA. Ping > response times between these 2 sites are within the normal range, but our > Applications are timing out. We’ve obviously done a ton of troubleshooting > on the Application side of things, but everything points back to a circuit > issue and after a lot of testing we are scratching our heads trying to > narrow down this issue. So I wanted to post to this list to see if anyone > else has noticed issues with their Level3 circuits in the Bay Area over the > last 2 days as well? Hello Leah, Yes and no, not anymore. >From Monday to Wed we had bad connectivity from LA to Sacramento, but different from your scenario, ping had a good latency but package loss was noticeable. After 2 days of phone chattery we managed someone to skip San Jose, San Francisco and the whole SF Bay area, routing us via Fresno-Modesto to reach Sacramento. Latency increased a bit but overall quality was restored. So yes, somehow I can confirm there's something going on with apparent isolated issues on Bay Area, specially near San Jose. Seems isolated because from what I noticed on phone it was "only me". And now you. > > > > Thanks for your feedback! > > Regards, Leah From james at freedomnet.co.nz Thu Dec 18 16:02:00 2014 From: james at freedomnet.co.nz (james jones) Date: Thu, 18 Dec 2014 16:02:00 +0000 Subject: Netscaler Help Message-ID: Are there any netscaler experts out there? Please contact me off list. From nanog at ics-il.net Thu Dec 18 17:52:14 2014 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 18 Dec 2014 11:52:14 -0600 (CST) Subject: IXes and AS length In-Reply-To: <1498205.7720.1418924517202.JavaMail.mhammett@ThunderFuck> Message-ID: <6724294.7790.1418925177535.JavaMail.mhammett@ThunderFuck> So I just found out that the IX we're looking to hook up with (Equinix) doesn't allow downstream ASes. How does that functionally work? Stepping outside my ISP for a moment, I know a building owner with several buildings that provides Internet to his tenants. He's getting an AS so he can have upstream diversity. Unless carrier A or ISP B have direct private peering with whomever (Amazon, NetFlix, Google, FaceBook, etc., etc.), that building owner doesn't have a route to those services? They can't utilize carrier A or ISP B's public peering connection? How can that possibly bee with with every ISP being required to have their own physical presence on the exchange? That's just not practical. I understand not having parallel ASNs (advertising both ASN A and ASN B separately) from a sales perspective, but I don't understand ASN A advertising directly on the IX, but not allowing ASN A's downstream customers of ASNs B, C, D and E. Am I wrong or is this just an Equinix thing? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From clayton at MNSi.Net Thu Dec 18 17:55:22 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Thu, 18 Dec 2014 12:55:22 -0500 Subject: IXes and AS length In-Reply-To: <6724294.7790.1418925177535.JavaMail.mhammett@ThunderFuck> References: <1498205.7720.1418924517202.JavaMail.mhammett@ThunderFuck> <6724294.7790.1418925177535.JavaMail.mhammett@ThunderFuck> Message-ID: <1418925323_245759@surgemail.mnsi.net> I'm not sure how they can do that. Equinix is Layer 2 - your peering parameters are between you and your peer? At 12:52 PM 18/12/2014, Mike Hammett wrote: >So I just found out that the IX we're looking to hook up with >(Equinix) doesn't allow downstream ASes. How does that functionally work? > >Stepping outside my ISP for a moment, I know a building owner with >several buildings that provides Internet to his tenants. He's >getting an AS so he can have upstream diversity. Unless carrier A or >ISP B have direct private peering with whomever (Amazon, NetFlix, >Google, FaceBook, etc., etc.), that building owner doesn't have a >route to those services? They can't utilize carrier A or ISP B's >public peering connection? How can that possibly bee with with every >ISP being required to have their own physical presence on the >exchange? That's just not practical. > >I understand not having parallel ASNs (advertising both ASN A and >ASN B separately) from a sales perspective, but I don't understand >ASN A advertising directly on the IX, but not allowing ASN A's >downstream customers of ASNs B, C, D and E. > >Am I wrong or is this just an Equinix thing? > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From woody at pch.net Thu Dec 18 18:00:16 2014 From: woody at pch.net (Bill Woodcock) Date: Thu, 18 Dec 2014 10:00:16 -0800 Subject: IXes and AS length In-Reply-To: <6724294.7790.1418925177535.JavaMail.mhammett@ThunderFuck> References: <6724294.7790.1418925177535.JavaMail.mhammett@ThunderFuck> Message-ID: I believe you have misunderstood Equinix's policy. I believe the generally-applied policy is that you may not have multiple MAC addresses on the same physical port, which typically means that you can't easily peer using multiple ASes directly on the exchange switch fabric. If you believe that this doesn't answer your question, please quote the Equinix language that you're looking at, so we can help you better. -Bill > On Dec 18, 2014, at 9:53, "Mike Hammett" wrote: > > So I just found out that the IX we're looking to hook up with (Equinix) doesn't allow downstream ASes. How does that functionally work? > > Stepping outside my ISP for a moment, I know a building owner with several buildings that provides Internet to his tenants. He's getting an AS so he can have upstream diversity. Unless carrier A or ISP B have direct private peering with whomever (Amazon, NetFlix, Google, FaceBook, etc., etc.), that building owner doesn't have a route to those services? They can't utilize carrier A or ISP B's public peering connection? How can that possibly bee with with every ISP being required to have their own physical presence on the exchange? That's just not practical. > > I understand not having parallel ASNs (advertising both ASN A and ASN B separately) from a sales perspective, but I don't understand ASN A advertising directly on the IX, but not allowing ASN A's downstream customers of ASNs B, C, D and E. > > Am I wrong or is this just an Equinix thing? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com From ammar at fastreturn.net Thu Dec 18 18:00:37 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Thu, 18 Dec 2014 22:00:37 +0400 Subject: IXes and AS length In-Reply-To: <1418925323_245759@surgemail.mnsi.net> References: <1498205.7720.1418924517202.JavaMail.mhammett@ThunderFuck> <6724294.7790.1418925177535.JavaMail.mhammett@ThunderFuck> <1418925323_245759@surgemail.mnsi.net> Message-ID: <383D101D-B8DB-4EA9-910C-68687E2337DC@fastreturn.net> That’s exactly what I was thinking… Equinix doesn’t really have anything to do with that part of the peering ecology. > On Dec 18, 2014, at 9:55 PM, Clayton Zekelman wrote: > > > > I'm not sure how they can do that. Equinix is Layer 2 - your peering parameters are between you and your peer? > > > > At 12:52 PM 18/12/2014, Mike Hammett wrote: >> So I just found out that the IX we're looking to hook up with (Equinix) doesn't allow downstream ASes. How does that functionally work? >> >> Stepping outside my ISP for a moment, I know a building owner with several buildings that provides Internet to his tenants. He's getting an AS so he can have upstream diversity. Unless carrier A or ISP B have direct private peering with whomever (Amazon, NetFlix, Google, FaceBook, etc., etc.), that building owner doesn't have a route to those services? They can't utilize carrier A or ISP B's public peering connection? How can that possibly bee with with every ISP being required to have their own physical presence on the exchange? That's just not practical. >> >> I understand not having parallel ASNs (advertising both ASN A and ASN B separately) from a sales perspective, but I don't understand ASN A advertising directly on the IX, but not allowing ASN A's downstream customers of ASNs B, C, D and E. >> >> Am I wrong or is this just an Equinix thing? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com > > --- > > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 3363 Tecumseh Rd. E > Windsor, Ontario > N8W 1H4 > > tel. 519-985-8410 > fax. 519-985-8409 From JHarris at viewpost.com Thu Dec 18 20:43:27 2014 From: JHarris at viewpost.com (Justin Harris) Date: Thu, 18 Dec 2014 20:43:27 +0000 Subject: Is there a Lexis Nexis contact (AS14182) hanging out on this list? Message-ID: <7B6F53B49666B340987D203042C385272DFB83AE@USGAVEX05.vpcorp.local> If so please contact me off list. Having connectivity issues from AS36694 to AS14182. Thanks! Justin Harris Network Engineer t 407.949.0081 c 407.718.3919 Viewpost.com Viewpost(tm) See business better.(tm) 2600 Lucien Way, Suite 100 Maitland, FL 32751 Electronic Privacy Notice: Use of email is inherently insecure. Confidential information, including account information, and personally identifiable information, should not be transmitted via email, or email attachment. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). The information contained in this message is private and confidential, may contain legally protected information and may be subject to one or more non-disclosure agreements, or federal and state regulations. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately destroy all copies and the original message. Thank you in advance for your cooperation. From jfmezei_nanog at vaxination.ca Thu Dec 18 22:55:08 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 18 Dec 2014 17:55:08 -0500 Subject: Multicast and switches Message-ID: <54935B4C.9060803@vaxination.ca> In Bell Canada territory, on the copper, Bell uses 2 VLANs , 35 for data, and I think 36 for IPTV service. Multicast is of course enabled on VLAN 36 and on the IPTV aggregation network back up to the video servers which is separate from the data services. VLAN 35 is set to aggregate to the BRAS router somewhere upstream. Currently, independent ISP traffic is separated at the BRAS and PPPoE packets reach the ISP premises from BRAS via L2TP links. Multicast cannot be handled by this service. One of the proposals is to have ISPs connect at the CO directly into the switch feeding the DSLAMs. ISPs think that they can then do multicast without needing Bell's intervention. My concern is with ISP traffic still needing to pass through at least Bell 2 switches and the DSLAMs before reaching the end user. If ISPs pass through this equipment via a differerent VLAN (lets call it 37), would it just be a simple deal of telling those switches and VLAN to "enable multicast" on that VLAN, or would it require careful configurations to enable specific multicast IPs etc ? Would switches and DSLAMs handle multicast on separate VLANs as totally separate realms so that one need not worry about the other using same multicast IPs ? Or is this untested territory since there nobody ever tried this ? (I assume that on the Australian NBN, NBNCo would assign separate IP ranges to different IPtv providers and traffic would be handled as a single multicast system). From list-nanog at dragon.net Thu Dec 18 23:55:58 2014 From: list-nanog at dragon.net (Paul Ebersman) Date: Thu, 18 Dec 2014 16:55:58 -0700 Subject: Subject: Call for Presentations - DNS-OARC Spring Workshop, May 2015 Message-ID: <20141218235558.7F130E1EB63@fafnir.remote.dragon.net> Apologies if you are on multiple lists and see multiple copies of this email. ------------- The next OARC Spring Workshop will take place in Amsterdam on May 9th and 10th, the weekend before RIPE70. OARC is requesting proposals for presentations, with a preference for DDoS attack reports and mitigation techniques. Reports and field stories can cover DNS-based DDoS attacks, attacks to DNS infrastructure or side effects suffered by cache resolver operators. This workshop intends to build from previous strong OARC workshops, where operational content and research is welcome. Presentations from DNS operators are particularly welcome, as well as from DNS researchers. All DNS-related subjects are accepted, introduction to new tools, visualizations, DNSSEC and novel uses of the DNS. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. Adopting practice from other conferences, a timeslot for lighting talks will be available for short presentations (5 to 10 minutes). Workshop Milestones * 18 December 2014, Call for Presentations posted * 8 January 2015, Open for submissions * 5 March 2015, Deadline for submission * 26 March 2015, Final Program published * 7 May 2015, Final deadline for slideset submission Details for abstract submission will be published here: https://indico.dns-oarc.net//conferenceCFA.py?confId=21 The workshop will be organized on different tracks, depending on the topics and the timing of each presentation. If you are interested in a lightning talk, let us know at the time of submission. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via if you have questions or concerns. Sebastian Castro, for the OARC Programme Committee OARC is also seeking sponsorship for this workshop, please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ------------- From clapidus at gmail.com Fri Dec 19 02:00:37 2014 From: clapidus at gmail.com (Claudio Lapidus) Date: Thu, 18 Dec 2014 23:00:37 -0300 Subject: Inmarsat contact Message-ID: Hello people, Does anyone knows someone at Inmarsat? I need to get in contact with a tech over there. thanks in advance, cl. From diotonante at gmail.com Fri Dec 19 10:09:26 2014 From: diotonante at gmail.com (Davide Davini) Date: Fri, 19 Dec 2014 11:09:26 +0100 Subject: Issue to reach AS3269 through AS6762 In-Reply-To: References: Message-ID: <5493F956.4060500@gmail.com> On 17/12/2014 15:14, Alessandro Ratti wrote: > Hi guys, > is there anyone from Telecom Italia that should contact me offlist? There is an open thread on ITNOG if you care to join n. Some seem to think it is a byproduct of TI de-peering policy. My 2 [euro] cents, Davide Davini From jcurran at arin.net Fri Dec 19 17:39:31 2014 From: jcurran at arin.net (John Curran) Date: Fri, 19 Dec 2014 17:39:31 +0000 Subject: CRISP Draft Proposal Now Available (IANA Stewardship Transition) In-Reply-To: <54944F97.7080201@arin.net> References: <54944F97.7080201@arin.net> Message-ID: <0E12164D-00B0-4FAE-85E8-9A98F3620257@arin.net> FYI - The IANA administers the unallocated portions of the various Internet number resource pools, and there is a proposal to transition stewardship for the IANA from the USG to the global Internet community. There is a request for proposals on how to best accomplish this transition, and the RIRs convened the Consolidated RIR IANA Stewardship Proposal (CRISP) team to prepare a response for the Internet number resources portion. The draft Proposal is now available for review and public comment, as noted in the attached message. FYI, /John John Curran President and CEO CEO Begin forwarded message: From: ARIN > Date: December 19, 2014 at 11:17:27 AM EST To: > Subject: [arin-announce] CRISP Draft Proposal Now Available This message is reposted on behalf of the NRO and the CRISP Team: The first draft of the Internet numbers community's response to the Request For Proposals issued by the IANA Stewardship Coordination Group (ICG) is now published. This draft has been prepared by the Consolidated RIR IANA Stewardship Proposal (CRISP) team, and we are now seeking feedback on this draft from the global community. Draft proposal: https://www.nro.net/crisp-proposal-first-draft The deadline for providing feedback is 5 January 2015 How to engage in discussions: All global discussions the CRISP team will consider as community feedback will be conducted on the > mailing list. Subscription to the global mailing list: https://www.nro.net/mailman/listinfo/ianaxfer Key points: ICANN to continue as an operator of the IANA function Exchange SLA with ICANN as the IANA function operator on number resources Review Committee with representatives from each RIR region Key dates: First draft published: 19 Dec 2014 First draft comments close: 5 Jan 2015 Second draft to be published: 8 Jan 2015 Second draft comments close: 12 Jan 2015 Final proposal to be sent to ICG: 15 Jan 2015 References: Discussions by CRISP Team Details of all the CRISP team's work to date, including recordings, minutes and agendas of all CRISP teleconferences and a public archive of the internal CRISP team mailing list, are available at: https://nro.net/crisp-team All CRISP team discussions are open to observers. Other links: ICG request for proposals: https://www.icann.org/news/announcement-3-2014-09-03-en The IANA Stewardship Transition Discussion in each RIR region: https://www.nro.net/timeline-engagement Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From cscora at apnic.net Fri Dec 19 18:11:41 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Dec 2014 04:11:41 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201412191811.sBJIBfQB021859@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 20 Dec, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 524220 Prefixes after maximum aggregation: 201371 Deaggregation factor: 2.60 Unique aggregates announced to Internet: 256071 Total ASes present in the Internet Routing Table: 48913 Prefixes per ASN: 10.72 Origin-only ASes present in the Internet Routing Table: 36386 Origin ASes announcing only one prefix: 16306 Transit ASes present in the Internet Routing Table: 6197 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: 100 Max AS path prepend of ASN ( 55644) 93 Prefixes from unregistered ASNs in the Routing Table: 1677 Unregistered ASNs in the Routing Table: 432 Number of 32-bit ASNs allocated by the RIRs: 8219 Number of 32-bit ASNs visible in the Routing Table: 6330 Prefixes from 32-bit ASNs in the Routing Table: 22772 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 395 Number of addresses announced to Internet: 2718041476 Equivalent to 162 /8s, 2 /16s and 5 /24s Percentage of available address space announced: 73.4 Percentage of allocated address space announced: 73.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.0 Total number of prefixes smaller than registry allocations: 177575 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 129144 Total APNIC prefixes after maximum aggregation: 37575 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 133907 Unique aggregates announced from the APNIC address blocks: 54644 APNIC Region origin ASes present in the Internet Routing Table: 5013 APNIC Prefixes per ASN: 26.71 APNIC Region origin ASes announcing only one prefix: 1221 APNIC Region transit ASes present in the Internet Routing Table: 866 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 100 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1224 Number of APNIC addresses announced to Internet: 740360512 Equivalent to 44 /8s, 33 /16s and 1 /24s Percentage of available APNIC address space announced: 86.5 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: 174011 Total ARIN prefixes after maximum aggregation: 86159 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 175923 Unique aggregates announced from the ARIN address blocks: 82214 ARIN Region origin ASes present in the Internet Routing Table: 16417 ARIN Prefixes per ASN: 10.72 ARIN Region origin ASes announcing only one prefix: 6072 ARIN Region transit ASes present in the Internet Routing Table: 1716 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 297 Number of ARIN addresses announced to Internet: 1055256832 Equivalent to 62 /8s, 229 /16s and 241 /24s Percentage of available ARIN address space announced: 55.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 126519 Total RIPE prefixes after maximum aggregation: 63782 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 132509 Unique aggregates announced from the RIPE address blocks: 82863 RIPE Region origin ASes present in the Internet Routing Table: 17833 RIPE Prefixes per ASN: 7.43 RIPE Region origin ASes announcing only one prefix: 8170 RIPE Region transit ASes present in the Internet Routing Table: 2916 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3290 Number of RIPE addresses announced to Internet: 692263300 Equivalent to 41 /8s, 67 /16s and 25 /24s Percentage of available RIPE address space announced: 100.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59090 Total LACNIC prefixes after maximum aggregation: 10834 LACNIC Deaggregation factor: 5.45 Prefixes being announced from the LACNIC address blocks: 68023 Unique aggregates announced from the LACNIC address blocks: 31066 LACNIC Region origin ASes present in the Internet Routing Table: 2389 LACNIC Prefixes per ASN: 28.47 LACNIC Region origin ASes announcing only one prefix: 636 LACNIC Region transit ASes present in the Internet Routing Table: 479 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1439 Number of LACNIC addresses announced to Internet: 167190976 Equivalent to 9 /8s, 247 /16s and 33 /24s Percentage of available LACNIC address space announced: 99.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: 12547 Total AfriNIC prefixes after maximum aggregation: 2977 AfriNIC Deaggregation factor: 4.21 Prefixes being announced from the AfriNIC address blocks: 13463 Unique aggregates announced from the AfriNIC address blocks: 4928 AfriNIC Region origin ASes present in the Internet Routing Table: 732 AfriNIC Prefixes per ASN: 18.39 AfriNIC Region origin ASes announcing only one prefix: 207 AfriNIC Region transit ASes present in the Internet Routing Table: 148 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: 80 Number of AfriNIC addresses announced to Internet: 60860416 Equivalent to 3 /8s, 160 /16s and 168 /24s Percentage of available AfriNIC address space announced: 60.5 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 2917 11581 926 Korea Telecom 17974 2822 904 77 PT Telekomunikasi Indonesia 7545 2489 336 128 TPG Telecom Limited 4755 1922 416 189 TATA Communications formerly 4538 1765 4190 71 China Education and Research 9829 1666 1323 28 National Internet Backbone 9808 1509 6719 19 Guangdong Mobile Communicatio 4808 1459 2226 430 CNCGROUP IP network China169 9583 1315 106 537 Sify Limited 9498 1296 336 97 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 2921 2956 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2553 10700 473 Level 3 Communications, Inc. 18566 2042 379 183 MegaPath Corporation 20115 1852 1824 444 Charter Communications 4323 1634 1054 408 tw telecom holdings, inc. 6983 1623 867 245 EarthLink, Inc. 30036 1507 311 583 Mediacom Communications Corp 701 1412 11262 696 MCI Communications Services, 22561 1317 411 244 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 1922 299 355 TELLCOM ILETISIM HIZMETLERI A 20940 1525 592 1128 Akamai International B.V. 8402 1443 544 15 OJSC "Vimpelcom" 13188 1033 97 52 TOV "Bank-Inform" 31148 1030 45 21 Freenet Ltd. 8551 898 373 43 Bezeq International-Ltd 6830 821 2340 442 Liberty Global Operations B.V 9198 820 349 26 JSC Kazakhtelecom 12479 814 794 85 France Telecom Espana SA 6849 733 356 25 JSC "Ukrtelecom" 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 3072 499 206 Telmex Colombia S.A. 28573 2307 2124 114 NET Servi�os de Comunica��o S 6147 1805 374 30 Telefonica del Peru S.A.A. 7303 1771 1172 237 Telecom Argentina S.A. 8151 1486 3042 430 Uninet S.A. de C.V. 6503 1229 433 58 Axtel, S.A.B. de C.V. 7738 1000 1882 42 Telemar Norte Leste S.A. 26615 914 2325 35 Tim Celular S.A. 3816 910 394 147 COLOMBIA TELECOMUNICACIONES S 27947 889 129 50 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1436 958 13 TE-AS 24863 947 284 26 Link Egypt (Link.NET) 36903 456 230 95 Office National des Postes et 36992 392 824 31 ETISALAT MISR 37492 346 145 64 Orange Tunisie 24835 308 144 9 Vodafone Data 3741 250 921 213 Internet Solutions 29571 235 21 12 Cote d'Ivoire Telecom 37457 195 160 4 Telkom SA Ltd. 36947 192 807 13 Telecom Algeria 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 3072 499 206 Telmex Colombia S.A. 22773 2921 2956 141 Cox Communications Inc. 4766 2917 11581 926 Korea Telecom 6389 2891 3688 51 BellSouth.net Inc. 17974 2822 904 77 PT Telekomunikasi Indonesia 3356 2553 10700 473 Level 3 Communications, Inc. 7545 2489 336 128 TPG Telecom Limited 28573 2307 2124 114 NET Servi�os de Comunica��o S 18566 2042 379 183 MegaPath Corporation 4755 1922 416 189 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2891 2840 BellSouth.net Inc. 22773 2921 2780 Cox Communications Inc. 17974 2822 2745 PT Telekomunikasi Indonesia 7545 2489 2361 TPG Telecom Limited 28573 2307 2193 NET Servi�os de Comunica��o S 3356 2553 2080 Level 3 Communications, Inc. 4766 2917 1991 Korea Telecom 18566 2042 1859 MegaPath Corporation 6147 1805 1775 Telefonica del Peru S.A.A. 4755 1922 1733 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:31 /11:92 /12:265 /13:502 /14:997 /15:1727 /16:13044 /17:7166 /18:11976 /19:24867 /20:35621 /21:38079 /22:56391 /23:49288 /24:281203 /25:1102 /26:1091 /27:698 /28:17 /29:16 /30:10 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2137 2921 Cox Communications Inc. 18566 1997 2042 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1354 1507 Mediacom Communications Corp 6147 1350 1805 Telefonica del Peru S.A.A. 6983 1310 1623 EarthLink, Inc. 34984 1229 1922 TELLCOM ILETISIM HIZMETLERI A 11492 1116 1175 CABLE ONE, INC. 8402 1108 1443 OJSC "Vimpelcom" 10620 1086 3072 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1408 2:670 3:3 4:95 5:1200 6:21 8:1403 11:1 12:1839 13:5 14:1210 15:17 16:2 17:45 18:21 20:51 23:1054 24:1656 27:1830 31:1445 32:39 33:2 34:5 36:146 37:1872 38:971 39:13 40:226 41:3084 42:286 43:785 44:21 45:84 46:2092 47:31 49:780 50:791 52:12 54:60 55:7 56:8 57:31 58:1104 59:661 60:449 61:1737 62:1313 63:1869 64:4403 65:2264 66:4064 67:2014 68:1041 69:3230 70:903 71:429 72:1953 74:2623 75:325 76:410 77:1355 78:1056 79:783 80:1325 81:1294 82:812 83:634 84:673 85:1327 86:429 87:1210 88:519 89:1817 90:139 91:5854 92:802 93:1669 94:1999 95:1383 96:422 97:337 98:1041 99:48 100:69 101:789 103:6331 104:861 105:183 106:194 107:890 108:612 109:2039 110:1060 111:1458 112:744 113:888 114:803 115:1238 116:1275 117:1003 118:1665 119:1364 120:430 121:1000 122:2202 123:1707 124:1466 125:1573 128:642 129:374 130:382 131:1053 132:434 133:167 134:385 135:87 136:330 137:299 138:385 139:171 140:224 141:422 142:620 143:438 144:505 145:112 146:677 147:566 148:1062 149:405 150:536 151:579 152:469 153:248 154:294 155:658 156:387 157:332 158:264 159:945 160:368 161:628 162:1839 163:377 164:641 165:669 166:320 167:718 168:1158 169:131 170:1426 171:223 172:51 173:1581 174:703 175:590 176:1549 177:3713 178:2109 179:810 180:1840 181:1689 182:1685 183:530 184:722 185:2562 186:2933 187:1664 188:2010 189:1545 190:7917 191:859 192:7948 193:5562 194:4070 195:3630 196:1699 197:865 198:5400 199:5495 200:6509 201:2948 202:9466 203:8969 204:4691 205:2709 206:2990 207:2968 208:3913 209:3846 210:3500 211:1861 212:2489 213:2248 214:843 215:73 216:5544 217:1764 218:651 219:467 220:1303 221:778 222:459 223:647 End of report From justin at ryburn.org Fri Dec 19 21:18:57 2014 From: justin at ryburn.org (Justin Ryburn) Date: Fri, 19 Dec 2014 15:18:57 -0600 Subject: BGP Flowspec Survey Message-ID: <1ED7BB6C-C641-4F2D-8B0D-AA83FCC3CEAC@ryburn.org> Hey Everyone, I am looking to get feedback from the community on BGP Flowspec for an upcoming presentation... https://www.surveymonkey.com/s/RZYQ23S Feel free to forward this to any contacts you may have that are not on the NANOG list. Obviously, the more response I get, the more accurate the data will be. Let me know if you have any questions. Thanks, -Justin .................................... Justin Ryburn Senior Systems Engineer Juniper Networks From cidr-report at potaroo.net Fri Dec 19 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Dec 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201412192200.sBJM00ID040448@wattle.apnic.net> This report has been generated at Fri Dec 19 21:14:21 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 12-12-14 528724 291879 13-12-14 528772 291750 14-12-14 528706 292095 15-12-14 528899 292005 16-12-14 529090 291868 17-12-14 528967 291870 18-12-14 529244 292723 19-12-14 529745 292686 AS Summary 49196 Number of ASes in routing system 19749 Number of ASes announcing only one prefix 3072 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120184320 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'). --- 19Dec14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 529770 292680 237090 44.8% All ASes AS6389 2891 100 2791 96.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2923 173 2750 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2822 77 2745 97.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS28573 2313 304 2009 86.9% NET Servi�os de Comunica��o S.A.,BR AS3356 2621 823 1798 68.6% LEVEL3 - Level 3 Communications, Inc.,US AS6147 1805 169 1636 90.6% Telefonica del Peru S.A.A.,PE AS4766 2918 1293 1625 55.7% KIXS-AS-KR Korea Telecom,KR AS4755 1921 338 1583 82.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7303 1775 291 1484 83.6% Telecom Argentina S.A.,AR AS10620 3072 1594 1478 48.1% Telmex Colombia S.A.,CO AS9808 1508 56 1452 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1425 26 1399 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS20115 1853 526 1327 71.6% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2504 1260 1244 49.7% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1641 410 1231 75.0% TWTC - tw telecom holdings, inc.,US AS9498 1295 113 1182 91.3% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2041 868 1173 57.5% MEGAPATH5-US - MegaPath Corporation,US AS6983 1623 489 1134 69.9% ITCDELTA - Earthlink, Inc.,US AS7552 1112 52 1060 95.3% VIETEL-AS-AP Viettel Corporation,VN AS34984 1922 866 1056 54.9% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1317 351 966 73.3% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS31148 1041 162 879 84.4% FREENET-AS Freenet Ltd.,UA AS38285 983 113 870 88.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1782 937 845 47.4% ERX-CERNET-BKB China Education and Research Network Center,CN AS24560 1176 369 807 68.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS8151 1491 690 801 53.7% Uninet S.A. de C.V.,MX AS26615 914 137 777 85.0% Tim Celular S.A.,BR AS4780 1067 299 768 72.0% SEEDNET Digital United Inc.,TW AS18101 957 194 763 79.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN Total 53713 13164 40549 75.5% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 43.245.196.0/24 AS36352 AS-COLOCROSSING - ColoCrossing,US 43.245.197.0/24 AS55286 SERVER-MANIA - B2 Net Solutions Inc.,US 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 64.247.224.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 69.2.64.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 69.172.0.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 72.12.0.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 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.220.84.0/24 AS5577 ROOT root SA,LU 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 102.49.0.0/16 AS20150 SKY-CAPITAL Sky Capital Investments Ltd.,DE 102.68.0.0/16 AS20150 SKY-CAPITAL Sky Capital Investments Ltd.,DE 102.98.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 102.156.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 102.160.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 103.1.155.0/24 AS55799 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.124.0/24 AS45355 DIGICELPACIFIC-1-AP Clarendon House,FJ 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.27.144.0/22 AS18097 DCN D.C.N. Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 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 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 151.216.128.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM",RU 151.216.192.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM",RU 154.254.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.211.192.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 186.65.108.0/22 AS22927 Telefonica de Argentina,AR 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.52.0/23 AS14455 SUNGARD-RECOVERY - Sungard Network Solutions, Inc.,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 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.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.80.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 196.109.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.53.208.0/23 AS17157 -Reserved AS-,ZZ 206.53.211.0/24 AS17157 -Reserved AS-,ZZ 206.53.212.0/24 AS17157 -Reserved AS-,ZZ 206.53.213.0/24 AS17157 -Reserved AS-,ZZ 206.53.214.0/23 AS17157 -Reserved AS-,ZZ 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.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 208.115.0.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 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.159.32.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.83.224.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 216.107.64.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 216.117.240.0/21 AS17157 -Reserved AS-,ZZ 216.117.248.0/22 AS17157 -Reserved AS-,ZZ 216.117.252.0/23 AS17157 -Reserved AS-,ZZ 216.117.254.0/24 AS17157 -Reserved AS-,ZZ 216.117.255.0/24 AS17157 -Reserved AS-,ZZ 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.219.0.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 216.231.96.0/19 AS7029 WINDSTREAM - Windstream Communications 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 Dec 19 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Dec 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201412192200.sBJM01U0040462@wattle.apnic.net> BGP Update Report Interval: 11-Dec-14 -to- 18-Dec-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 286594 6.4% 3048.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 236515 5.3% 154.6 -- BSNL-NIB National Internet Backbone,IN 3 - AS53249 78884 1.8% 39442.0 -- LAWA-AS - Los Angeles World Airport,US 4 - AS23966 69837 1.6% 232.0 -- LDN-AS-PK LINKdotNET Telecom Limited,PK 5 - AS10620 36640 0.8% 13.2 -- Telmex Colombia S.A.,CO 6 - AS51964 34641 0.8% 202.6 -- ORANGE-BUSINESS-SERVICES-IPSN-ASN Equant Inc.,FR 7 - AS60725 34124 0.8% 4874.9 -- O3B-AS O3b Limited,JE 8 - AS48159 30854 0.7% 95.2 -- TIC-AS Telecommunication Infrastructure Company,IR 9 - AS28024 29748 0.7% 19.3 -- Nuevatel PCS de Bolivia S.A.,BO 10 - AS3 29713 0.7% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 11 - AS1659 29121 0.7% 549.5 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 12 - AS25374 28547 0.6% 198.2 -- ESCOMBG-AS ESCOM Ltd. - Haskovo,BG 13 - AS17974 27947 0.6% 13.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 14 - AS36947 27018 0.6% 162.8 -- ALGTEL-AS,DZ 15 - AS8402 24899 0.6% 81.4 -- CORBINA-AS OJSC "Vimpelcom",RU 16 - AS45899 24358 0.5% 55.2 -- VNPT-AS-VN VNPT Corp,VN 17 - AS23693 23069 0.5% 228.4 -- TELKOMSEL-ASN-ID PT. Telekomunikasi Selular,ID 18 - AS45595 22214 0.5% 104.3 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited,PK 19 - AS23342 22033 0.5% 22033.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 20 - AS46258 21652 0.5% 3093.1 -- ESC3 - Region III Education Service Center,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS53249 78884 1.8% 39442.0 -- LAWA-AS - Los Angeles World Airport,US 2 - AS23342 22033 0.5% 22033.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 3 - AS3 12207 0.3% 4929.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 4 - AS3 29713 0.7% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 5 - AS18135 9276 0.2% 9276.0 -- BTV BTV Cable television,JP 6 - AS47680 9116 0.2% 9116.0 -- NHCS EOBO Limited,IE 7 - AS61039 6194 0.1% 6194.0 -- ZMZ OAO ZMZ,RU 8 - AS62174 5563 0.1% 5563.0 -- INTERPAN-AS INTERPAN LTD.,BG 9 - AS11865 4981 0.1% 4981.0 -- G222UV2D21EWD27U76VUWHD7V1FH8HT6HE6W7W12 - STERLING SAVINGS,US 10 - AS60725 34124 0.8% 4874.9 -- O3B-AS O3b Limited,JE 11 - AS33721 4123 0.1% 4123.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 12 - AS60737 6666 0.1% 3333.0 -- NEURONESIT NEURONESIT,FR 13 - AS4 3140 0.1% 1412.0 -- ISI-AS - University of Southern California,US 14 - AS46258 21652 0.5% 3093.1 -- ESC3 - Region III Education Service Center,US 15 - AS23752 286594 6.4% 3048.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 16 - AS31860 3016 0.1% 3016.0 -- MACKAY-SHIELDS - MacKay Shields LLC,US 17 - AS41330 2475 0.1% 2475.0 -- STEKGSM-AS Closed Joint Stock Company Yeniseytelecom,RU 18 - AS56636 1990 0.0% 1990.0 -- ASVEDARU VEDA Ltd.,RU 19 - AS3 1780 0.0% 174.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 20 - AS49317 1654 0.0% 1654.0 -- KSPAB Kallmyra System & Produktion AB,SE TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 143030 3.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 142515 3.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 198.140.115.0/24 39450 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 4 - 198.140.114.0/24 39434 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 5 - 130.0.192.0/21 29711 0.6% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 6 - 64.29.130.0/24 22033 0.5% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 7 - 41.221.20.0/24 20990 0.5% AS36947 -- ALGTEL-AS,DZ 8 - 192.115.44.0/22 19718 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 9 - 185.26.155.0/24 17385 0.4% AS60725 -- O3B-AS O3b Limited,JE 10 - 162.249.183.0/24 16673 0.4% AS60725 -- O3B-AS O3b Limited,JE 11 - 185.51.20.0/24 12207 0.3% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 12 - 192.58.232.0/24 10547 0.2% AS6629 -- NOAA-AS - NOAA,US 13 - 42.83.48.0/20 9276 0.2% AS18135 -- BTV BTV Cable television,JP 14 - 88.87.160.0/19 9116 0.2% AS47680 -- NHCS EOBO Limited,IE 15 - 202.41.92.0/24 6837 0.1% AS2697 -- ERX-ERNET-AS Education and Research Network,IN 16 - 91.235.169.0/24 6194 0.1% AS61039 -- ZMZ OAO ZMZ,RU 17 - 109.160.4.0/22 5563 0.1% AS62174 -- INTERPAN-AS INTERPAN LTD.,BG 18 - 72.165.240.0/24 4981 0.1% AS11865 -- G222UV2D21EWD27U76VUWHD7V1FH8HT6HE6W7W12 - STERLING SAVINGS,US 19 - 199.187.118.0/24 4286 0.1% AS11054 -- LIVEPERSON - LivePerson, Inc.,US 20 - 84.205.66.0/24 4131 0.1% AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC),EU 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 jra at baylink.com Fri Dec 19 22:54:03 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 19 Dec 2014 17:54:03 -0500 (EST) Subject: Ars breaks Misfortune Cookie vulnerability news to public Message-ID: <918173.514.1419029643163.JavaMail.root@benjamin.baylink.com> While the flaw is 12 years old and the fix 9, the article suggests that firmware for consumer routers may yet be being built with the vulnerable webserver code baked in. If you are responsible for lots of eyeballs you might want to look at this. http://arstechnica.com/security/2014/12/12-million-home-and-business-routers-vulnerable-to-critical-hijacking-hack/ Have a nice Christmas weekend. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From javier at advancedmachines.us Fri Dec 19 23:49:53 2014 From: javier at advancedmachines.us (Javier J) Date: Fri, 19 Dec 2014 18:49:53 -0500 Subject: Ars breaks Misfortune Cookie vulnerability news to public In-Reply-To: <918173.514.1419029643163.JavaMail.root@benjamin.baylink.com> References: <918173.514.1419029643163.JavaMail.root@benjamin.baylink.com> Message-ID: Glad I'm using a freebsd based routing solution. On Dec 19, 2014 5:54 PM, "Jay Ashworth" wrote: > While the flaw is 12 years old and the fix 9, the article suggests that > firmware for consumer routers may yet be being built with the vulnerable > webserver code baked in. > > If you are responsible for lots of eyeballs you might want to look at this. > > > http://arstechnica.com/security/2014/12/12-million-home-and-business-routers-vulnerable-to-critical-hijacking-hack/ > > Have a nice Christmas weekend. :-) > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > From eric-list at truenet.com Sat Dec 20 00:47:10 2014 From: eric-list at truenet.com (Eric Tykwinski) Date: Fri, 19 Dec 2014 19:47:10 -0500 Subject: Ars breaks Misfortune Cookie vulnerability news to public In-Reply-To: <918173.514.1419029643163.JavaMail.root@benjamin.baylink.com> References: <918173.514.1419029643163.JavaMail.root@benjamin.baylink.com> Message-ID: Here’s the thing I don’t get… You have X provider supplying routers with vulnerable firmware that have remote support (TR-069) enabled. Why would Check Point not at least name and shame, instead of trying to market their security? I know the hack is old, but grandma isn’t probably up to date on the latest firmware that should have been upgrade through TR-069. I’m honestly more upset with the reporting than the normal residential cpe didn’t get upgraded. But yeah, Happy Holidays everyone... Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 > On Dec 19, 2014, at 5:54 PM, Jay Ashworth wrote: > > While the flaw is 12 years old and the fix 9, the article suggests that > firmware for consumer routers may yet be being built with the vulnerable > webserver code baked in. > > If you are responsible for lots of eyeballs you might want to look at this. > > http://arstechnica.com/security/2014/12/12-million-home-and-business-routers-vulnerable-to-critical-hijacking-hack/ > > Have a nice Christmas weekend. :-) > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From math at sizone.org Sat Dec 20 00:51:09 2014 From: math at sizone.org (Ken Chase) Date: Fri, 19 Dec 2014 19:51:09 -0500 Subject: Ars breaks Misfortune Cookie vulnerability news to public In-Reply-To: References: <918173.514.1419029643163.JavaMail.root@benjamin.baylink.com> Message-ID: <20141220005109.GT23692@sizone.org> 19:25 <@andrewTO> http://mis.fortunecook.ie/misfortune-cookie-suspected-vulnerable.pdf has a list of potentially vulnerable devices 19:25 <@math> andrewTO at opensrs++ /kc -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From niels=nanog at bakker.net Sat Dec 20 01:01:15 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 20 Dec 2014 02:01:15 +0100 Subject: Ars breaks Misfortune Cookie vulnerability news to public In-Reply-To: References: <918173.514.1419029643163.JavaMail.root@benjamin.baylink.com> Message-ID: <20141220010115.GA5744@excession.tpb.net> * javier at advancedmachines.us (Javier J) [Sat 20 Dec 2014, 00:50 CET]: >Glad I'm using a freebsd based routing solution. Time to update that one too: https://ics-cert.us-cert.gov/advisories/ICSA-14-353-01 -- Niels. From frnkblk at iname.com Sat Dec 20 03:18:06 2014 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 19 Dec 2014 21:18:06 -0600 Subject: Ars breaks Misfortune Cookie vulnerability news to public In-Reply-To: References: <918173.514.1419029643163.JavaMail.root@benjamin.baylink.com> Message-ID: <000001d01c03$92c10fb0$b8432f10$@iname.com> On what basis do you assume that there is TR-069 support in these routers? And even if there is, that the service provider manages them via TR-069? Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Tykwinski Sent: Friday, December 19, 2014 6:47 PM To: Jay Ashworth Cc: NANOG Subject: Re: Ars breaks Misfortune Cookie vulnerability news to public Here’s the thing I don’t get… You have X provider supplying routers with vulnerable firmware that have remote support (TR-069) enabled. Why would Check Point not at least name and shame, instead of trying to market their security? I know the hack is old, but grandma isn’t probably up to date on the latest firmware that should have been upgrade through TR-069. I’m honestly more upset with the reporting than the normal residential cpe didn’t get upgraded. But yeah, Happy Holidays everyone... Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 > On Dec 19, 2014, at 5:54 PM, Jay Ashworth wrote: > > While the flaw is 12 years old and the fix 9, the article suggests that > firmware for consumer routers may yet be being built with the vulnerable > webserver code baked in. > > If you are responsible for lots of eyeballs you might want to look at this. > > http://arstechnica.com/security/2014/12/12-million-home-and-business-routers-vulnerable-to-critical-hijacking-hack/ > > Have a nice Christmas weekend. :-) > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From javier at advancedmachines.us Sat Dec 20 04:28:30 2014 From: javier at advancedmachines.us (Javier J) Date: Fri, 19 Dec 2014 23:28:30 -0500 Subject: Ars breaks Misfortune Cookie vulnerability news to public In-Reply-To: <20141220010115.GA5744@excession.tpb.net> References: <918173.514.1419029643163.JavaMail.root@benjamin.baylink.com> <20141220010115.GA5744@excession.tpb.net> Message-ID: Haha, yeah I spoke too soon. Happy Holidays. Also has anyone looked at the list of devices / vendors that are using that software? https://www.allegrosoft.com/about-allegro-software#tabs-896-0-4 Did the vendors know their vendor was giving them buggy software? What is the test for this vuln? On Fri, Dec 19, 2014 at 8:01 PM, Niels Bakker wrote: > * javier at advancedmachines.us (Javier J) [Sat 20 Dec 2014, 00:50 CET]: > >> Glad I'm using a freebsd based routing solution. >> > > Time to update that one too: https://ics-cert.us-cert.gov/ > advisories/ICSA-14-353-01 > > > -- Niels. > From javier at advancedmachines.us Sat Dec 20 04:30:39 2014 From: javier at advancedmachines.us (Javier J) Date: Fri, 19 Dec 2014 23:30:39 -0500 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> <602dce3d13dc4c71940c26b733317e5e@pur-vm-exch13n2.ox.com> Message-ID: Add T-mobile LTE and to that list. I need one. On Tue, Dec 16, 2014 at 4:11 PM, Alex Rubenstein wrote: > > > On Tue, Dec 16, 2014 at 12:32 PM, Alex Rubenstein > > > wrote: > > > > > > > > I just with Wifi calling was ubiquitous. > > > > > > isn't it in every android phone since ~1yr ago? > > Perhaps they are, but AT&T and Verizon don't allow it, because they are > terrible. > > > From dougb at dougbarton.us Sat Dec 20 21:58:29 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 20 Dec 2014 13:58:29 -0800 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> <602dce3d13dc4c71940c26b733317e5e@pur-vm-exch13n2.ox.com> Message-ID: <5495F105.5050102@dougbarton.us> On 12/19/14 8:30 PM, Javier J wrote: > Add T-mobile LTE and to that list. > > I need one. I'm using wifi calling on my T-mobile device now and then 'just 'cuz', and it works a treat. Usually my cell coverage is excellent, but I'm sure that someday I'll be in a spot where I need it, so I want to keep exercising that path occasionally. :) FWIW, Doug (Usually I wouldn't bother speaking about a specific vendor, especially one that's arguably off-topic, but given the historical scuzziness of most of the mobile vendors, and what T-mobile is doing now to improve the situation; albeit with occasionally distasteful marketing theatrics, I thought it worth mentioning ...) From miguel at rackforce.com Fri Dec 19 19:16:17 2014 From: miguel at rackforce.com (Miguel Hernandez) Date: Fri, 19 Dec 2014 11:16:17 -0800 (PST) Subject: Fibre optic patch cables in Toronto area In-Reply-To: <1746871966.11790335.1419016429514.JavaMail.zimbra@rackforce.com> References: <1746871966.11790335.1419016429514.JavaMail.zimbra@rackforce.com> Message-ID: <1408147347.11790683.1419016577235.JavaMail.zimbra@rackforce.com> Hello list, I'm looking to source some various fibre patch cables (LC to SC, 1-2M lengths) in the Toronto, Ontario area. Could you please point me to some shops were we could drop by to pick them up? Thanks! Miguel Hernandez From michael at supermathie.net Sat Dec 20 23:30:45 2014 From: michael at supermathie.net (Michael Brown) Date: Sat, 20 Dec 2014 18:30:45 -0500 Subject: Fibre optic patch cables in Toronto area In-Reply-To: <1408147347.11790683.1419016577235.JavaMail.zimbra@rackforce.com> References: <1746871966.11790335.1419016429514.JavaMail.zimbra@rackforce.com> <1408147347.11790683.1419016577235.JavaMail.zimbra@rackforce.com> Message-ID: <20141220233045.6611091.59395.18198@supermathie.net> ‎At this time of day? Or in general? In general there's Ingram Micro (distributor) whom we use, not sure what retail outlets would carry them. You could try Sayal Electronics, that'd be a good bet. M.‎   Original Message   From: Miguel Hernandez Sent: Saturday, December 20, 2014 17:03 To: nanog at nanog.org Subject: Fibre optic patch cables in Toronto area Hello list, I'm looking to source some various fibre patch cables (LC to SC, 1-2M lengths) in the Toronto, Ontario area. Could you please point me to some shops were we could drop by to pick them up? Thanks! Miguel Hernandez From javier at advancedmachines.us Sun Dec 21 07:51:30 2014 From: javier at advancedmachines.us (Javier J) Date: Sun, 21 Dec 2014 02:51:30 -0500 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <5495F105.5050102@dougbarton.us> References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> <602dce3d13dc4c71940c26b733317e5e@pur-vm-exch13n2.ox.com> <5495F105.5050102@dougbarton.us> Message-ID: I used to use it too, but then I started with the nexus line of phones and guess what? gone. Because its a custom android implementation in their version of android but the Nexus is pure android untouched by t-mo. Not switching from my nexus 5 anytime soon and if I did I would probably get the 6. T-mo really should release it as an app of some kind. On Sat, Dec 20, 2014 at 4:58 PM, Doug Barton wrote: > On 12/19/14 8:30 PM, Javier J wrote: > >> Add T-mobile LTE and to that list. >> >> I need one. >> > > I'm using wifi calling on my T-mobile device now and then 'just 'cuz', and > it works a treat. Usually my cell coverage is excellent, but I'm sure that > someday I'll be in a spot where I need it, so I want to keep exercising > that path occasionally. :) > > FWIW, > > Doug > > (Usually I wouldn't bother speaking about a specific vendor, especially > one that's arguably off-topic, but given the historical scuzziness of most > of the mobile vendors, and what T-mobile is doing now to improve the > situation; albeit with occasionally distasteful marketing theatrics, I > thought it worth mentioning ...) > From javier at advancedmachines.us Sun Dec 21 10:15:18 2014 From: javier at advancedmachines.us (Javier J) Date: Sun, 21 Dec 2014 05:15:18 -0500 Subject: jack in the box ssl cert Message-ID: can someone let them know they are having a bad day? https://www.jackinthebox.com/ From pavel.odintsov at gmail.com Sun Dec 21 11:38:21 2014 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Sun, 21 Dec 2014 15:38:21 +0400 Subject: jack in the box ssl cert In-Reply-To: References: Message-ID: Wow! Nice burgers! On Sun, Dec 21, 2014 at 1:15 PM, Javier J wrote: > can someone let them know they are having a bad day? > > https://www.jackinthebox.com/ -- Sincerely yours, Pavel Odintsov From tshaw at oitc.com Sun Dec 21 12:39:13 2014 From: tshaw at oitc.com (TR Shaw) Date: Sun, 21 Dec 2014 07:39:13 -0500 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <5495F105.5050102@dougbarton.us> References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> <602dce3d13dc4c71940c26b733317e5e@pur-vm-exch13n2.ox.com> <5495F105.5050102@dougbarton.us> Message-ID: On Dec 20, 2014, at 4:58 PM, Doug Barton wrote: > On 12/19/14 8:30 PM, Javier J wrote: >> Add T-mobile LTE and to that list. >> >> I need one. > > I'm using wifi calling on my T-mobile device now and then 'just 'cuz', and it works a treat. Usually my cell coverage is excellent, but I'm sure that someday I'll be in a spot where I need it, so I want to keep exercising that path occasionally. :) > > FWIW, > > Doug > > (Usually I wouldn't bother speaking about a specific vendor, especially one that's arguably off-topic, but given the historical scuzziness of most of the mobile vendors, and what T-mobile is doing now to improve the situation; albeit with occasionally distasteful marketing theatrics, I thought it worth mentioning ...) Doug, Just a question on T-Mobile and wifi. If you are traveling to a roaming country will wifi calls to #s back home be treated as non roaming calls? Tom From jared at puck.nether.net Sun Dec 21 13:19:55 2014 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 21 Dec 2014 08:19:55 -0500 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> <602dce3d13dc4c71940c26b733317e5e@pur-vm-exch13n2.ox.com> <5495F105.5050102@dougbarton.us> Message-ID: That is my understanding. Wifi calling is treated as on-net "home" calling. Jared Mauch > On Dec 21, 2014, at 7:39 AM, TR Shaw wrote: > > >> On Dec 20, 2014, at 4:58 PM, Doug Barton wrote: >> >>> On 12/19/14 8:30 PM, Javier J wrote: >>> Add T-mobile LTE and to that list. >>> >>> I need one. >> >> I'm using wifi calling on my T-mobile device now and then 'just 'cuz', and it works a treat. Usually my cell coverage is excellent, but I'm sure that someday I'll be in a spot where I need it, so I want to keep exercising that path occasionally. :) >> >> FWIW, >> >> Doug >> >> (Usually I wouldn't bother speaking about a specific vendor, especially one that's arguably off-topic, but given the historical scuzziness of most of the mobile vendors, and what T-mobile is doing now to improve the situation; albeit with occasionally distasteful marketing theatrics, I thought it worth mentioning ...) > > Doug, > > Just a question on T-Mobile and wifi. If you are traveling to a roaming country will wifi calls to #s back home be treated as non roaming calls? > > Tom > From clayton at MNSi.Net Sun Dec 21 15:11:48 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Sun, 21 Dec 2014 10:11:48 -0500 Subject: jack in the box ssl cert In-Reply-To: References: Message-ID: <1419174710_264095@surgemail.mnsi.net> A different kind of malady than they're familiar with.... http://en.wikipedia.org/wiki/Jack_in_the_Box#E._coli_outbreak At 06:38 AM 21/12/2014, Pavel Odintsov wrote: >Wow! Nice burgers! > >On Sun, Dec 21, 2014 at 1:15 PM, Javier J wrote: > > can someone let them know they are having a bad day? > > > > https://www.jackinthebox.com/ > > > >-- >Sincerely yours, Pavel Odintsov --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From cb.list6 at gmail.com Sun Dec 21 15:44:08 2014 From: cb.list6 at gmail.com (Ca By) Date: Sun, 21 Dec 2014 07:44:08 -0800 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> <602dce3d13dc4c71940c26b733317e5e@pur-vm-exch13n2.ox.com> <5495F105.5050102@dougbarton.us> Message-ID: On Sunday, December 21, 2014, Jared Mauch wrote: > That is my understanding. Wifi calling is treated as on-net "home" calling. > > Jared Mauch > > Confirmed. Same for text messages. I have used in asia, south america, and Europe. Just works. For me this was a killer feature while traveling.... Or being in my basement. But i think the free* International data roaming in most countries now takes the cake CB *speed is 2g-ish Ps. I am not impartial > > On Dec 21, 2014, at 7:39 AM, TR Shaw > > wrote: > > > > > >> On Dec 20, 2014, at 4:58 PM, Doug Barton > wrote: > >> > >>> On 12/19/14 8:30 PM, Javier J wrote: > >>> Add T-mobile LTE and to that list. > >>> > >>> I need one. > >> > >> I'm using wifi calling on my T-mobile device now and then 'just 'cuz', > and it works a treat. Usually my cell coverage is excellent, but I'm sure > that someday I'll be in a spot where I need it, so I want to keep > exercising that path occasionally. :) > >> > >> FWIW, > >> > >> Doug > >> > >> (Usually I wouldn't bother speaking about a specific vendor, especially > one that's arguably off-topic, but given the historical scuzziness of most > of the mobile vendors, and what T-mobile is doing now to improve the > situation; albeit with occasionally distasteful marketing theatrics, I > thought it worth mentioning ...) > > > > Doug, > > > > Just a question on T-Mobile and wifi. If you are traveling to a roaming > country will wifi calls to #s back home be treated as non roaming calls? > > > > Tom > > > From stephen at sprunk.org Sun Dec 21 18:10:24 2014 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 21 Dec 2014 12:10:24 -0600 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <5490799A.9070109@flowtools.net> References: <20141216024552.GA26200@esri.com> <5490799A.9070109@flowtools.net> Message-ID: <54970D10.6010907@sprunk.org> On 16-Dec-14 12:27, John Schiel wrote: > One thing you might also want to consider are any calls you make to > 911 whilst using a repeater. > > I use a repeater supplied by T-Mobile and they made it very clear, and > I had to specifically acknowledge a statement, that using such a > repeater takes away from emergency services being able to find out > where you are if you make a 911 call from your mobile. > > Some may refer to this as a feature, depending on how much tin foil > you have laying about, but the users of such device may need to be > warned about emergency calls. They'll need to be able to describe > where they are to the responding sirens. With any reasonably modern phone, wouldn't this problem only apply to areas where GPS isn't available (e.g. basements) and the system tries to fall back to using tower triangulation? AIUI, part of the registration process's purpose is to give a default location for your new "tower" so that emergency responders at least know where to start looking if no better location information is available, e.g. because the caller can't speak or is disoriented. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2394 bytes Desc: S/MIME Cryptographic Signature URL: From johnl at iecc.com Sun Dec 21 20:45:42 2014 From: johnl at iecc.com (John Levine) Date: 21 Dec 2014 20:45:42 -0000 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: Message-ID: <20141221204542.20817.qmail@ary.lan> >For me this was a killer feature while traveling.... Or being in my >basement. But i think the free* International data roaming in most >countries now takes the cake These days, if you have a smartphone with wifi, there are plenty of apps that will provide VoIP calling without needing any help from the carrier. If you use Google Voice, it's not hard to make everything look like one phone number. I agree that T-Mo's international data roaming is still a very good deal, though. Too bad T-Mo's coverage here in the US is so poor. R's, John From jra at baylink.com Sun Dec 21 23:43:27 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 21 Dec 2014 18:43:27 -0500 (EST) Subject: They have the Internet in North Korea now? Message-ID: <28934400.538.1419205407818.JavaMail.root@benjamin.baylink.com> Well, kind of: https://nknetobserver.github.io/ Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From javier at advancedmachines.us Mon Dec 22 00:13:37 2014 From: javier at advancedmachines.us (Javier J) Date: Sun, 21 Dec 2014 19:13:37 -0500 Subject: They have the Internet in North Korea now? In-Reply-To: <28934400.538.1419205407818.JavaMail.root@benjamin.baylink.com> References: <28934400.538.1419205407818.JavaMail.root@benjamin.baylink.com> Message-ID: This blog is gold. Pure gold. On Sun, Dec 21, 2014 at 6:43 PM, Jay Ashworth wrote: > Well, kind of: > > https://nknetobserver.github.io/ > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > From javier at advancedmachines.us Mon Dec 22 01:23:00 2014 From: javier at advancedmachines.us (Javier J) Date: Sun, 21 Dec 2014 20:23:00 -0500 Subject: Internet Service Providers in Bogota Colombia. Message-ID: My apologies in advance If there is a better list, please let me know. I will be traveling to Bogota, Colombia for a few weeks in the spring and a family member who is working there on a contract (where I will be staying) has crappy internet. I want to kill 2 birds with one stone. Make sure I have reliable internet and improve what they have. I'm just not sure what options are available there. I speak the language just not familiar with the options. Any help would be greatly appreciated. From javier at advancedmachines.us Mon Dec 22 01:24:36 2014 From: javier at advancedmachines.us (Javier J) Date: Sun, 21 Dec 2014 20:24:36 -0500 Subject: in-case anyone is interested, the pirate flag flies again. Message-ID: http://www.thepiratebay.se/ From chaim.rieger at gmail.com Mon Dec 22 01:29:21 2014 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Sun, 21 Dec 2014 17:29:21 -0800 Subject: in-case anyone is interested, the pirate flag flies again. In-Reply-To: References: Message-ID: <549773F1.9090907@gmail.com> On 12/21/2014 5:24 PM, Javier J wrote: > http://www.thepiratebay.se/ Hear Hear From rubensk at gmail.com Mon Dec 22 01:37:37 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 21 Dec 2014 23:37:37 -0200 Subject: Internet Service Providers in Bogota Colombia. In-Reply-To: References: Message-ID: It's very likely that your family member has either ETB (local city-owned access) or Telmex Colombia. Both players have multiple technology options (ADSL and WiMAX for both, coax and fiber for Telmex Colombia), so besides replacing one for the other, it might be possible to improve access by using a different technology from the same vendor already in place. Knowing which technology options are available from each vendor at where you will be will probably be key in defining a way forward. Rubens On Sun, Dec 21, 2014 at 11:23 PM, Javier J wrote: > My apologies in advance If there is a better list, please let me know. > > I will be traveling to Bogota, Colombia for a few weeks in the spring and a > family member who is working there on a contract (where I will be staying) > has crappy internet. I want to kill 2 birds with one stone. Make sure I > have reliable internet and improve what they have. I'm just not sure what > options are available there. > > I speak the language just not familiar with the options. > > Any help would be greatly appreciated. > From mfidelman at meetinghouse.net Mon Dec 22 02:16:04 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 21 Dec 2014 21:16:04 -0500 Subject: in-case anyone is interested, the pirate flag flies again. In-Reply-To: <549773F1.9090907@gmail.com> References: <549773F1.9090907@gmail.com> Message-ID: <54977EE4.1000901@meetinghouse.net> Chaim Rieger wrote: > On 12/21/2014 5:24 PM, Javier J wrote: >> http://www.thepiratebay.se/ > Hear Hear Shouldn't that be: Yaaarrrrrr -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Mon Dec 22 02:28:58 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 21 Dec 2014 21:28:58 -0500 Subject: in-case anyone is interested, the pirate flag flies again. In-Reply-To: References: Message-ID: <549781EA.4080704@meetinghouse.net> Javier J wrote: > http://www.thepiratebay.se/ Doesn't seem to be reachable, though. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From javier at advancedmachines.us Mon Dec 22 09:13:42 2014 From: javier at advancedmachines.us (Javier J) Date: Mon, 22 Dec 2014 04:13:42 -0500 Subject: How our young colleagues are being educated.... Message-ID: Dear NANOG Members, It has come to my attention, that higher learning institutions in North America are doing our young future colleagues a disservice. I recently ran into a student of Southern New Hampshire University enrolled in the Networking/Telecom Management course and was shocked by what I learned. Not only are they skimming over new technologies such as BGP, MPLS and the fundamentals of TCP/IP that run the internet and the networks of the world, they were focusing on ATM , Frame Relay and other technologies that are on their way out the door and will probably be extinct by the time this student graduates. They are teaching classful routing and skimming over CIDR. Is this indicative of the state of our education system as a whole? How is it this student doesn't know about OSPF and has never heard of RIP? If your network hardware is so old you need a crossover cable, it's time to upgrade. In this case, it’s time to upgrade our education system. I didn't write this email on the sole experience of my conversation with one student, I wrote this email because I have noticed a pattern emerging over the years with other university students at other schools across the country. It’s just the countless times I have crossed paths with a young IT professional and was literally in shock listening to the things they were being taught. Teaching old technologies instead of teaching what is currently being used benefits no one. Teaching classful and skipping CIDR is another thing that really gets my blood boiling. Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? What about unicast and multicast? I confirmed with one student half way through their studies that they were not properly taught how DNS works, and had no clue what the term “root servers” meant. Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not by us, then by whom? How can we fix this? From mansaxel at besserwisser.org Mon Dec 22 10:24:35 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 22 Dec 2014 11:24:35 +0100 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: <20141222102435.GB7897@besserwisser.org> Subject: How our young colleagues are being educated.... Date: Mon, Dec 22, 2014 at 04:13:42AM -0500 Quoting Javier J (javier at advancedmachines.us): > Dear NANOG Members, > > It has come to my attention, that higher learning institutions in North > America are doing our young future colleagues a disservice. Yes. Although, as long as they don't teach people that _every_ router does NAT, we'll be fine. > Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? At the university I taught, yes. But that is in Europe, on the Royal Institute of Technology in Stockholm, Sweden, for 3rd year in a MsC programme in EE, Physics or CS. I am seeing similar cluelessness at smaller proto-universities in Sweden, where they have bought a branded course. Lots of Flame Delay. And EIGRP. Branded course. Our trainee that came out of that did prove to be highly trainable, though. > What about unicast and multicast? I confirmed with one student half way > through their studies that they were not properly taught how DNS works, and > had no clue what the term “root servers” meant. Multicast, check. DNS, check. > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not > by us, then by whom? How can we fix this? People who enter academentia in networking, especially to teach at rural colleges, tend to freeze in time and stick to whatever fad was "in" when they were young. Especially ATM is popular, since it has, for all its uselessness, a nice theoretical undercarriage and stands on the shoulders of decades of telco style "Warum einfach wenns auch kompliziert geht?" (you will have to translate that yourself, it's German and describes engineering well) In Sweden, universities (where tuition is 0 for all citizens and can be made 0 for all citizens of the EU) the universities have a third task besides undergraduate production and research, and that is to interact with greater society. The key to good education that fulfils the needs of society is to ensure the interaction is two-way. Each course, get a industry lecturer in for at least one lecture. This, if chosen well, will make it impossible to teach Flame Delay in 2014. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 We have DIFFERENT amounts of HAIR -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From daniel.crompton at gmail.com Mon Dec 22 11:53:06 2014 From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=) Date: Mon, 22 Dec 2014 12:53:06 +0100 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: *shameless plug* Usually not a topic for this list, and together with two co-founders we started an online university last to address some of the issues we saw with higher education. We currently have approval from the state of Vermont to give college credit, credits earned through Oplerno courses are transferable to other institutions of higher learning at the discretion of the receiving institution. If you think that this subject should be addressed at a college level and are interested in teaching it you are welcome to apply as a faculty member to teach an improved course. Kindest regards, Daniël Oplerno is built upon empowering faculty and students -- Daniël W. Crompton http://specialbrands.net/ On 22 December 2014 at 10:13, Javier J wrote: > > Dear NANOG Members, > > It has come to my attention, that higher learning institutions in North > America are doing our young future colleagues a disservice. > > I recently ran into a student of Southern New Hampshire University enrolled > in the Networking/Telecom Management course and was shocked by what I > learned. > > Not only are they skimming over new technologies such as BGP, MPLS and the > fundamentals of TCP/IP that run the internet and the networks of the world, > they were focusing on ATM , Frame Relay and other technologies that are on > their way out the door and will probably be extinct by the time this > student graduates. They are teaching classful routing and skimming over > CIDR. Is this indicative of the state of our education system as a whole? > How is it this student doesn't know about OSPF and has never heard of RIP? > > If your network hardware is so old you need a crossover cable, it's time to > upgrade. In this case, it’s time to upgrade our education system. > > I didn't write this email on the sole experience of my conversation with > one student, I wrote this email because I have noticed a pattern emerging > over the years with other university students at other schools across the > country. It’s just the countless times I have crossed paths with a young IT > professional and was literally in shock listening to the things they were > being taught. Teaching old technologies instead of teaching what is > currently being used benefits no one. Teaching classful and skipping CIDR > is another thing that really gets my blood boiling. > > Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? > > What about unicast and multicast? I confirmed with one student half way > through their studies that they were not properly taught how DNS works, and > had no clue what the term “root servers” meant. > > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not > by us, then by whom? How can we fix this? > From bill at herrin.us Mon Dec 22 11:53:31 2014 From: bill at herrin.us (William Herrin) Date: Mon, 22 Dec 2014 06:53:31 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: On Mon, Dec 22, 2014 at 4:13 AM, Javier J wrote: > I recently ran into a student of Southern New Hampshire University enrolled > in the Networking/Telecom Management course and was shocked by what I > learned. > > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not > by us, then by whom? How can we fix this? SNHU offers -online- bachelor's and master's degrees in such well known programs as "IT Management" and "Information Security." You can even pick whether you want a Bachelor of Arts or a Bachelor of Science. It's a -degree mill-. What level of quality did you expect in the coursework? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From refresh.lsong at gmail.com Mon Dec 22 13:30:15 2014 From: refresh.lsong at gmail.com (Song Li) Date: Mon, 22 Dec 2014 21:30:15 +0800 Subject: Is there list of IXPs (containing the information of the AS# of the IXP) Message-ID: <54981CE7.1090505@gmail.com> Hi everyone, I'm searching for a list of IXPS which contains the information of the ASN of the IXP. Some resources are good: https://prefix.pch.net/applications/ixpdir/?show_active_only=0&sort=traffic&order=desc https://www.telegeography.com/products/internet-exchange-directory/profiles-by-name/index.html but they do not contain the AS# of the IXP. Can anybody help me? Thanks! Best! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From jeroen at massar.ch Mon Dec 22 13:50:45 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 22 Dec 2014 14:50:45 +0100 Subject: Is there list of IXPs (containing the information of the AS# of the IXP) In-Reply-To: <54981CE7.1090505@gmail.com> References: <54981CE7.1090505@gmail.com> Message-ID: <549821B5.1080002@massar.ch> On 2014-12-22 14:30, Song Li wrote: > Hi everyone, > > I'm searching for a list of IXPS which contains the information of the > ASN of the IXP. Some resources are good: > > https://prefix.pch.net/applications/ixpdir/?show_active_only=0&sort=traffic&order=desc > > https://www.telegeography.com/products/internet-exchange-directory/profiles-by-name/index.html > > > but they do not contain the AS# of the IXP. Can anybody help me? IXs themselves do not have ASNs, as they are Layer 2 providers. The prefixes used for the peering fabric might be part of some ASN though (eg AMS-IX uses 1200). Check http://www.peeringdb.com for most likely the info you are really looking for. Greets, Jeroen From randy at psg.com Mon Dec 22 13:51:34 2014 From: randy at psg.com (Randy Bush) Date: Mon, 22 Dec 2014 08:51:34 -0500 Subject: Is there list of IXPs (containing the information of the AS# of the IXP) In-Reply-To: <54981CE7.1090505@gmail.com> References: <54981CE7.1090505@gmail.com> Message-ID: > I'm searching for a list of IXPS which contains the information of the > ASN of the IXP. the best source is https://www.peeringdb.com/ [ i was amused to find CIX (http://www.cix.org/, the one which used to be in the bay) still in my ix bookmarks. ] randy From nfiumarelli at lacnic.net Mon Dec 22 11:55:03 2014 From: nfiumarelli at lacnic.net (=?UTF-8?B?Tmljb2zDoXM=?=) Date: Mon, 22 Dec 2014 09:55:03 -0200 Subject: in-case anyone is interested, the pirate flag flies again. In-Reply-To: <549781EA.4080704@meetinghouse.net> References: <549781EA.4080704@meetinghouse.net> Message-ID: <54980697.2000207@lacnic.net> You could try this one: https://thepiratebay.cr/ El 22/12/14 00:28, Miles Fidelman escribió: > Javier J wrote: >> http://www.thepiratebay.se/ > > Doesn't seem to be reachable, though. > From niels=nanog at bakker.net Mon Dec 22 14:24:12 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 22 Dec 2014 15:24:12 +0100 Subject: Is there list of IXPs (containing the information of the AS# of the IXP) In-Reply-To: References: <54981CE7.1090505@gmail.com> Message-ID: <20141222142411.GB5744@excession.tpb.net> >>I'm searching for a list of IXPS which contains the information of >>the ASN of the IXP. * randy at psg.com (Randy Bush) [Mon 22 Dec 2014, 14:54 CET]: >the best source is https://www.peeringdb.com/ It's not. Let's take an example, AMS-IX: https://www.peeringdb.com/private/exchange_view.php?id=26 That record doesn't say AS1200 anywhere. You'll have to search for "Amsterdam Internet Exchange" to find AS1200; a search for "AMS-IX" will lead you only to its route server ASN. There is no way to filter participants by IXP as "Network Type" doesn't offer that option. Euro-IX will give you most serious IXPs globally. For example, https://www.euro-ix.net/ixps/2-AMS-IX#network is AMS-IX's entry and it lists all pertinent information. -- Niels. From nick at foobar.org Mon Dec 22 14:26:18 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 22 Dec 2014 14:26:18 +0000 Subject: Is there list of IXPs (containing the information of the AS# of the IXP) In-Reply-To: <549821B5.1080002@massar.ch> References: <54981CE7.1090505@gmail.com> <549821B5.1080002@massar.ch> Message-ID: <54982A0A.4020007@foobar.org> On 22/12/2014 13:50, Jeroen Massar wrote: > IXs themselves do not have ASNs, as they are Layer 2 providers. most modern IXPs will have an ASN for their route server, and possibly a separate asn for their mgmt infrastructure. Not sure how useful the mgmt ASN is, although most IXPs will paradoxically include this on their list of members. Nick From refresh.lsong at gmail.com Mon Dec 22 14:45:06 2014 From: refresh.lsong at gmail.com (Song Li) Date: Mon, 22 Dec 2014 22:45:06 +0800 Subject: Is there list of IXPs (containing the information of the AS# of the IXP) In-Reply-To: <54982A0A.4020007@foobar.org> References: <54981CE7.1090505@gmail.com> <549821B5.1080002@massar.ch> <54982A0A.4020007@foobar.org> Message-ID: <54982E72.8040804@gmail.com> 在 2014/12/22 22:26, Nick Hilliard 写道: > On 22/12/2014 13:50, Jeroen Massar wrote: >> IXs themselves do not have ASNs, as they are Layer 2 providers. > > most modern IXPs will have an ASN for their route server, and possibly a > separate asn for their mgmt infrastructure. > > Not sure how useful the mgmt ASN is, although most IXPs will paradoxically > include this on their list of members. > > Nick > > Thanks for your help! I studied all the AS-Path in the routing table (from routeviews and RIPE), and found that some ASN of IXPs were included in some AS-Path. I think that under normal circumstances they should not appear in the AS-Path, hence i want to filter out them. Best! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From Casey.Baranoski at rci.rogers.com Mon Dec 22 14:45:16 2014 From: Casey.Baranoski at rci.rogers.com (Casey Baranoski) Date: Mon, 22 Dec 2014 14:45:16 +0000 Subject: Fibre optic patch cables in Toronto area In-Reply-To: <20141220233045.6611091.59395.18198@supermathie.net> References: <1746871966.11790335.1419016429514.JavaMail.zimbra@rackforce.com> <1408147347.11790683.1419016577235.JavaMail.zimbra@rackforce.com> <20141220233045.6611091.59395.18198@supermathie.net> Message-ID: +1 for Sayal. They've got a few locations, depending on where you are in the GTA. http://www.sayal.com/zinc/zinc_contactus.asp#TOR -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael Brown Sent: Saturday, December 20, 2014 6:31 PM To: Miguel Hernandez; nanog at nanog.org Subject: Re: Fibre optic patch cables in Toronto area ‎At this time of day? Or in general? In general there's Ingram Micro (distributor) whom we use, not sure what retail outlets would carry them. You could try Sayal Electronics, that'd be a good bet. M.‎ Original Message From: Miguel Hernandez Sent: Saturday, December 20, 2014 17:03 To: nanog at nanog.org Subject: Fibre optic patch cables in Toronto area Hello list, I'm looking to source some various fibre patch cables (LC to SC, 1-2M lengths) in the Toronto, Ontario area. Could you please point me to some shops were we could drop by to pick them up? Thanks! Miguel Hernandez ________________________________ This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice Ce message est confidentiel. Notre transmission et réception de courriels se fait strictement suivant les modalités énoncées dans l’avis publié à www.rogers.com/aviscourriel ________________________________ From niels=nanog at bakker.net Mon Dec 22 14:50:00 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 22 Dec 2014 15:50:00 +0100 Subject: Is there list of IXPs (containing the information of the AS# of the IXP) In-Reply-To: <54982A0A.4020007@foobar.org> References: <54981CE7.1090505@gmail.com> <549821B5.1080002@massar.ch> <54982A0A.4020007@foobar.org> Message-ID: <20141222145000.GC5744@excession.tpb.net> * nick at foobar.org (Nick Hilliard) [Mon 22 Dec 2014, 15:28 CET]: >Not sure how useful the mgmt ASN is, although most IXPs will >paradoxically include this on their list of members. As long as they don't count it for their total connected parties statistics, I'm good with it being included in the list, to help people find missing or since-disconnected peers at the IXP in an automated fashion. -- Niels. From jeroen at massar.ch Mon Dec 22 14:52:07 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 22 Dec 2014 15:52:07 +0100 Subject: Is there list of IXPs (containing the information of the AS# of the IXP) In-Reply-To: <54982E72.8040804@gmail.com> References: <54981CE7.1090505@gmail.com> <549821B5.1080002@massar.ch> <54982A0A.4020007@foobar.org> <54982E72.8040804@gmail.com> Message-ID: <54983017.2090202@massar.ch> On 2014-12-22 15:45, Song Li wrote: > 在 2014/12/22 22:26, Nick Hilliard 写道: >> On 22/12/2014 13:50, Jeroen Massar wrote: >>> IXs themselves do not have ASNs, as they are Layer 2 providers. >> >> most modern IXPs will have an ASN for their route server, and possibly a >> separate asn for their mgmt infrastructure. >> >> Not sure how useful the mgmt ASN is, although most IXPs will >> paradoxically >> include this on their list of members. >> >> Nick >> >> > Thanks for your help! > > I studied all the AS-Path in the routing table (from routeviews and > RIPE), and found that some ASN of IXPs were included in some AS-Path. You are likely seeing IP addresses from the peering LAN, which typically have addresses that are under the ASN from an IX. Quite a few IXes state that the peering prefixes should not be announced world-wide. > I think that under normal circumstances they should not appear in the > AS-Path, hence i want to filter out them. "Filtering them out" will have fun results when a valid ICMP is being returned. Something about "Packet Too Big"... What is the reason for thinking you need to filter these? Greets, Jeroen From kauto at huopio.fi Mon Dec 22 15:03:33 2014 From: kauto at huopio.fi (Kauto Huopio) Date: Mon, 22 Dec 2014 17:03:33 +0200 Subject: Fibre optic patch cables in Toronto area In-Reply-To: References: <1746871966.11790335.1419016429514.JavaMail.zimbra@rackforce.com> <1408147347.11790683.1419016577235.JavaMail.zimbra@rackforce.com> <20141220233045.6611091.59395.18198@supermathie.net> Message-ID: It would be handy to have a list of shops in major cities that stock standard network components available at odd hours. For Helsinki, Finland I can recommend Verkkokauppa.com kiosk - the whole stock of a Fry's -size outlet is available through a 24/7 kiosk at the ground floor. Orders over 200 euros have to be paid in their webstore, but you can do that with a terminal in the lobby. :) Yes, you *can* buy 10 4T disks at 4.30 am and there is no markup on regular daytime prices whatsoever. --Kauto On Mon, Dec 22, 2014 at 4:45 PM, Casey Baranoski wrote: > +1 for Sayal. They've got a few locations, depending on where you are in the GTA. http://www.sayal.com/zinc/zinc_contactus.asp#TOR > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael Brown > Sent: Saturday, December 20, 2014 6:31 PM > To: Miguel Hernandez; nanog at nanog.org > Subject: Re: Fibre optic patch cables in Toronto area > > ‎At this time of day? > > Or in general? > > In general there's Ingram Micro (distributor) whom we use, not sure what retail outlets would carry them. > > You could try Sayal Electronics, that'd be a good bet. > > M.‎ > Original Message > From: Miguel Hernandez > Sent: Saturday, December 20, 2014 17:03 > To: nanog at nanog.org > Subject: Fibre optic patch cables in Toronto area > > Hello list, > > I'm looking to source some various fibre patch cables (LC to SC, 1-2M lengths) in the Toronto, Ontario area. > > > Could you please point me to some shops were we could drop by to pick them up? > > > > Thanks! > > Miguel Hernandez > > > > > ________________________________ > This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice > > > > Ce message est confidentiel. Notre transmission et réception de courriels se fait strictement suivant les modalités énoncées dans l’avis publié à www.rogers.com/aviscourriel > ________________________________ -- Kauto Huopio - kauto at huopio.fi From mshaw at fairpoint.com Mon Dec 22 15:09:21 2014 From: mshaw at fairpoint.com (Shaw, Matthew) Date: Mon, 22 Dec 2014 15:09:21 +0000 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: <457F9455036417428963A59E3B38874183550DBC@0NH1C2P10.fairpoint.com> Thankfully only about 30 minutes north of SNHU is my alma mater, the New Hampshire Technical Institute, a technical school which is fairly well known (locally at least) for its nursing, electrical engineering, and IT programs. The school's invested in a modern lab with a dozen or so equipment pods and borrows elements from the Cisco Net Academy program as well. They offer CCNP related courses every few years dependent on interest and just last year started a VMWare VCP program. We did touch on those old technologies, which to some degree do still exist in the area, but also covered all the good stuff too. I'm under the impression SNHU has a couple programs it's good at, but to Mr. Herrin's point IT isn't one of them. It's fairly common to see IT folks around here go to NHTI for skills and an AS, and then SNHU or others to fill in the checkboxes for a semi related BS. The alternative is typically a more expensive school in and around Boston. As far as the larger issue is concerned Javier, I believe it's a cultural problem where we're still encouraging our high school graduates to attend 4 year programs no matter what. The demand is still incredibly high (as is the resulting price!) for even not so great programs like the one in question. Unfortunately if potential attendees don't do their research to find out how graduates of the programs they're considering are doing in the real world, they'll end up like this. Matthew Shaw -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin Sent: Monday, December 22, 2014 6:54 AM To: Javier J Cc: nanog at nanog.org Subject: Re: How our young colleagues are being educated.... On Mon, Dec 22, 2014 at 4:13 AM, Javier J wrote: > I recently ran into a student of Southern New Hampshire University > enrolled in the Networking/Telecom Management course and was shocked > by what I learned. > > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if > not by us, then by whom? How can we fix this? SNHU offers -online- bachelor's and master's degrees in such well known programs as "IT Management" and "Information Security." You can even pick whether you want a Bachelor of Arts or a Bachelor of Science. It's a -degree mill-. What level of quality did you expect in the coursework? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media. From jra at baylink.com Mon Dec 22 15:25:05 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 22 Dec 2014 10:25:05 -0500 (EST) Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: <54970D10.6010907@sprunk.org> Message-ID: <31661381.552.1419261905873.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Stephen Sprunk" > On 16-Dec-14 12:27, John Schiel wrote: > > One thing you might also want to consider are any calls you make to > > 911 whilst using a repeater. > > > > I use a repeater supplied by T-Mobile and they made it very clear, > > and > > I had to specifically acknowledge a statement, that using such a > > repeater takes away from emergency services being able to find out > > where you are if you make a 911 call from your mobile. > > > > Some may refer to this as a feature, depending on how much tin foil > > you have laying about, but the users of such device may need to be > > warned about emergency calls. They'll need to be able to describe > > where they are to the responding sirens. > > With any reasonably modern phone, wouldn't this problem only apply to > areas where GPS isn't available (e.g. basements) and the system tries > to fall back to using tower triangulation? > > AIUI, part of the registration process's purpose is to give a default > location for your new "tower" so that emergency responders at least > know where to start looking if no better location information is available, > e.g. because the caller can't speak or is disoriented. A friend of mine has a Sprint Airave picocell in her house, and it came with an external GPS antenna; if the cell can't lock a GPS position, it doesn't come online for calls. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From tarko at lanparty.ee Mon Dec 22 15:27:00 2014 From: tarko at lanparty.ee (Tarko Tikan) Date: Mon, 22 Dec 2014 17:27:00 +0200 Subject: Estonian IPv6 deployment report Message-ID: <54983844.8010007@lanparty.ee> hey, Some time ago, many people noticed rapid IPv6 deployment growth in Estonia (from 0% to 5% in 4 weeks). We at 3249/Elion/Estonian Telecom were behind this, other operators don't have any serious IPv6 deployments at the moment. We rolled out v6 to everyone (both business and residential customers) with last-gen CPE, there was no hop-in our hop-out program - aim was to do it perfectly and without customers even noticing. I'm happy to say that we achieved this goal :) To satisfy general interest, I promised small (somehow it turned out longer than I expected) technical writeup how we enabled v6 for our subscribers. If you have any other questions, feel free to ask and I do my best to answer them. You can also skip the technical content and there are some statistics below. Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is deployed in shared service vlans. IPv6 traffic shares vlan with IPv4. Service vlans are transported over MPLS metro network using pseudowires and terminated in geo-clustered Alcatel 7750 BNG routers. Each subscriber is allocated up to 4 mixed v4 and v6 IP hosts. For v4 we are using the usual DHCP, for IPv6 we are using DHCPv6 with IA_PD only, no IA_NA is provided. Unfortunately DHCPv6 provides no way to signal IPv6 default-route thus we have to fall back to RA for default-route. RA does not include any on-link prefixes or DNS information. RAs are L2 unicasted to CPE MAC so no other CPE in service vlan picks up those RAs. To ensure rapid switchover between BNG routers, we are signalling virtual link-local address as default-route. We are using ALU internal DHCP/DHCPv6 servers to allocate leases but we also signal IP information from radius (in such case BNG "fakes" DHCP server) for static IP customers. Provided IPv6 prefix is always /56 and we keep the old lease for 24h even if the CPE is turned off (actual lease time is 30min). Unfortunately, IPv6 LDRA is not available on most of our access platforms so we have to rely on IPv4 session information for authentication. This linking is done in the radius server during subscriber authentication (excellent radiator + quite awful SQL queries :) - if subscriber has IPv4 session (that has been authenticated using DHCP opt82), same MAC address is allowed to have IPv6 session on exactly the same virtual BNG port. IPv4 and v6 session are both tied to same subscriber and share shapers, QOS etc. We were able to enable IPv6 only on our last-gen Inteno CPEs. They run modified OpenWrt and because it's linux - everything is possible :) In CPE, /56 is divided up to /64s, first one is currently reserved but we will configure it on loopback interface and use it for CPE management. Second /64 is configured on LAN and third is configured on public wifi SSID (if you choose to enable this option). In the LAN, IPv6 config is provided by RAs, we also support RDNSS and stateless DHCPv6 for DNS. There is also ingress IPv6 firewall in the CPE and configuration is modifiable by user. To make deployment as smooth as possible, we rolled out IPv6 capable CPE software first. Then, during the BNG platform refresh, we deployed L2 ACLs that dropped all IPv6 traffic based on 0x86dd ethertype. We then deployed IPv6 config to all BNGs and could verify everything before single v6 lease was handed out to the subscribers. Then, interface by interface, we replaced L2 ACL with one that only allowed 0x86dd for certain, supported, OUIs. This is the current situation and we are investigating ways to support 3rd party CPEs - main problem is unreliable IPv6 config in CPEs. Many don't enable DHCPv6 (or enable NA but no PD) but still pick up default-route from RA and happily signal it to LAN. Some others hammer our BNGs with NA request every 0.1 seconds etc. As statistics go, there are 30000+ active IPv6 subscribers (almost 15% of our customer base, based on our public numbers), 81% of them have have at least one IPv6 enabled device in the LAN, 70% have more than one. Most IPv6 traffic is generated by Google+Youtube, Facebook and Akamai. Not bad for a country with 1.3M people. Next up: mobile network :) -- tarko From pavel.odintsov at gmail.com Mon Dec 22 15:33:33 2014 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 22 Dec 2014 19:33:33 +0400 Subject: Estonian IPv6 deployment report In-Reply-To: <54983844.8010007@lanparty.ee> References: <54983844.8010007@lanparty.ee> Message-ID: Hello, folks! Tere from your customer FastVPS Eesti OU/AS198068! :) On Mon, Dec 22, 2014 at 6:27 PM, Tarko Tikan wrote: > hey, > > Some time ago, many people noticed rapid IPv6 deployment growth in Estonia > (from 0% to 5% in 4 weeks). We at 3249/Elion/Estonian Telecom were behind > this, other operators don't have any serious IPv6 deployments at the moment. > We rolled out v6 to everyone (both business and residential customers) with > last-gen CPE, there was no hop-in our hop-out program - aim was to do it > perfectly and without customers even noticing. I'm happy to say that we > achieved this goal :) > > To satisfy general interest, I promised small (somehow it turned out longer > than I expected) technical writeup how we enabled v6 for our subscribers. If > you have any other questions, feel free to ask and I do my best to answer > them. You can also skip the technical content and there are some statistics > below. > > > Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is > deployed in shared service vlans. IPv6 traffic shares vlan with IPv4. > > Service vlans are transported over MPLS metro network using pseudowires and > terminated in geo-clustered Alcatel 7750 BNG routers. > > Each subscriber is allocated up to 4 mixed v4 and v6 IP hosts. For v4 we are > using the usual DHCP, for IPv6 we are using DHCPv6 with IA_PD only, no IA_NA > is provided. Unfortunately DHCPv6 provides no way to signal IPv6 > default-route thus we have to fall back to RA for default-route. RA does not > include any on-link prefixes or DNS information. RAs are L2 unicasted to CPE > MAC so no other CPE in service vlan picks up those RAs. To ensure rapid > switchover between BNG routers, we are signalling virtual link-local address > as default-route. > > We are using ALU internal DHCP/DHCPv6 servers to allocate leases but we also > signal IP information from radius (in such case BNG "fakes" DHCP server) for > static IP customers. Provided IPv6 prefix is always /56 and we keep the old > lease for 24h even if the CPE is turned off (actual lease time is 30min). > > Unfortunately, IPv6 LDRA is not available on most of our access platforms so > we have to rely on IPv4 session information for authentication. This linking > is done in the radius server during subscriber authentication (excellent > radiator + quite awful SQL queries :) - if subscriber has IPv4 session (that > has been authenticated using DHCP opt82), same MAC address is allowed to > have IPv6 session on exactly the same virtual BNG port. IPv4 and v6 session > are both tied to same subscriber and share shapers, QOS etc. > > We were able to enable IPv6 only on our last-gen Inteno CPEs. They run > modified OpenWrt and because it's linux - everything is possible :) > > In CPE, /56 is divided up to /64s, first one is currently reserved but we > will configure it on loopback interface and use it for CPE management. > Second /64 is configured on LAN and third is configured on public wifi SSID > (if you choose to enable this option). > > In the LAN, IPv6 config is provided by RAs, we also support RDNSS and > stateless DHCPv6 for DNS. There is also ingress IPv6 firewall in the CPE and > configuration is modifiable by user. > > To make deployment as smooth as possible, we rolled out IPv6 capable CPE > software first. Then, during the BNG platform refresh, we deployed L2 ACLs > that dropped all IPv6 traffic based on 0x86dd ethertype. We then deployed > IPv6 config to all BNGs and could verify everything before single v6 lease > was handed out to the subscribers. > > Then, interface by interface, we replaced L2 ACL with one that only allowed > 0x86dd for certain, supported, OUIs. This is the current situation and we > are investigating ways to support 3rd party CPEs - main problem is > unreliable IPv6 config in CPEs. Many don't enable DHCPv6 (or enable NA but > no PD) but still pick up default-route from RA and happily signal it to LAN. > Some others hammer our BNGs with NA request every 0.1 seconds etc. > > > As statistics go, there are 30000+ active IPv6 subscribers (almost 15% of > our customer base, based on our public numbers), 81% of them have have at > least one IPv6 enabled device in the LAN, 70% have more than one. Most IPv6 > traffic is generated by Google+Youtube, Facebook and Akamai. Not bad for a > country with 1.3M people. > > Next up: mobile network :) > > -- > tarko -- Sincerely yours, Pavel Odintsov From alex at corp.nac.net Mon Dec 22 15:58:38 2014 From: alex at corp.nac.net (Alex Rubenstein) Date: Mon, 22 Dec 2014 15:58:38 +0000 Subject: OT - Verizon/ATT Cell/4G Signal Booster/Repeater In-Reply-To: References: <20141216024552.GA26200@esri.com> <20141216025411.3707.qmail@ary.lan> <602dce3d13dc4c71940c26b733317e5e@pur-vm-exch13n2.ox.com> <5495F105.5050102@dougbarton.us> Message-ID: <0d54d95062d24f9d9f9d67dc188f2d49@exch2013-1.hq.nac.net> Correct. I've used T-Mo WiFi calling in numerous countries on three continents, and they are all treated as is you are in your 'home' country. > That is my understanding. Wifi calling is treated as on-net "home" calling. > > Just a question on T-Mobile and wifi. If you are traveling to a roaming country > will wifi calls to #s back home be treated as non roaming calls? > > > > Tom > > From nick at foobar.org Mon Dec 22 15:59:55 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 22 Dec 2014 15:59:55 +0000 Subject: Is there list of IXPs (containing the information of the AS# of the IXP) In-Reply-To: <20141222145000.GC5744@excession.tpb.net> References: <54981CE7.1090505@gmail.com> <549821B5.1080002@massar.ch> <54982A0A.4020007@foobar.org> <20141222145000.GC5744@excession.tpb.net> Message-ID: <54983FFB.5060006@foobar.org> On 22/12/2014 14:50, Niels Bakker wrote: > As long as they don't count it for their total connected parties > statistics, I'm good with it being included in the list, to help > people find missing or since-disconnected peers at the IXP in an > automated fashion. it is inappropriate to include it in the number of connected parties, but there's no problem including the IXP ASN in the list of connected parties so long as it's made clear that they're not standard IXP participants. Nick From Valdis.Kletnieks at vt.edu Mon Dec 22 16:11:38 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Dec 2014 11:11:38 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: Your message of "Mon, 22 Dec 2014 04:13:42 -0500." References: Message-ID: <154147.1419264698@turing-police.cc.vt.edu> On Mon, 22 Dec 2014 04:13:42 -0500, Javier J said: > student graduates. They are teaching classful routing and skimming over > CIDR. Is this indicative of the state of our education system as a whole? Did the standard packaged Cisco curriculum finally drop mention of "Class A/B/C" and go CIDR? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Mon Dec 22 17:08:26 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 22 Dec 2014 12:08:26 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: On Mon, Dec 22, 2014 at 4:13 AM, Javier J wrote: > Not only are they skimming over new technologies such as BGP, MPLS and the > fundamentals of TCP/IP that run the internet and the networks of the world, > they were focusing on ATM , Frame Relay and other technologies that are on > their way out the door and will probably be extinct by the time this These sound like 'standard enterprise networking technologies' (still, yes some other options are coming around, but .. there's still a shed-load of atm/frame wan stuff to be bought, and really the 'mpls' for enterprises is gussied up frame/atm without per-site ptp link management at each site, no knowledge of MPLS is required on the enterprise side of the connection) > student graduates. They are teaching classful routing and skimming over > CIDR. Is this indicative of the state of our education system as a whole? > How is it this student doesn't know about OSPF and has never heard of RIP? enterprise people hide in 10/8 ... why would they need to care about /26 or 27 ? everythign in their world is a /24. > If your network hardware is so old you need a crossover cable, it's time to > upgrade. In this case, it’s time to upgrade our education system. but, the cross-over cable means my network gear still works and I don't have to spend on replacement gear (yet). Remember, enterprise network. > I didn't write this email on the sole experience of my conversation with > one student, I wrote this email because I have noticed a pattern emerging > over the years with other university students at other schools across the > country. It’s just the countless times I have crossed paths with a young IT > professional and was literally in shock listening to the things they were > being taught. Teaching old technologies instead of teaching what is > currently being used benefits no one. Teaching classful and skipping CIDR > is another thing that really gets my blood boiling. you must require a large cooling vat then. > Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? enterprise networking... the name of the degree says enough to know what's going to come out of the program :( > What about unicast and multicast? I confirmed with one student half way > through their studies that they were not properly taught how DNS works, and > had no clue what the term “root servers” meant. > > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not > by us, then by whom? How can we fix this? you are getting a bit ranty, if you keep in mind the target of the coursework (enterprise people) then basically nothing in your mail is shocking. From sunyucong at gmail.com Mon Dec 22 17:26:45 2014 From: sunyucong at gmail.com (Yucong Sun) Date: Mon, 22 Dec 2014 09:26:45 -0800 Subject: in-case anyone is interested, the pirate flag flies again. In-Reply-To: <54980697.2000207@lacnic.net> References: <549781EA.4080704@meetinghouse.net> <54980697.2000207@lacnic.net> Message-ID: CR one is fake, isn't it? On Mon, Dec 22, 2014 at 3:55 AM, Nicolás wrote: > You could try this one: > https://thepiratebay.cr/ > > El 22/12/14 00:28, Miles Fidelman escribió: >> Javier J wrote: >>> http://www.thepiratebay.se/ >> >> Doesn't seem to be reachable, though. >> > From josh at imaginenetworksllc.com Mon Dec 22 17:33:10 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 22 Dec 2014 12:33:10 -0500 Subject: in-case anyone is interested, the pirate flag flies again. In-Reply-To: References: <549781EA.4080704@meetinghouse.net> <54980697.2000207@lacnic.net> Message-ID: They're all mirrors (old backups) besides thepiratebay.se Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Dec 22, 2014 at 12:26 PM, Yucong Sun wrote: > > CR one is fake, isn't it? > > On Mon, Dec 22, 2014 at 3:55 AM, Nicolás wrote: > > You could try this one: > > https://thepiratebay.cr/ > > > > El 22/12/14 00:28, Miles Fidelman escribió: > >> Javier J wrote: > >>> http://www.thepiratebay.se/ > >> > >> Doesn't seem to be reachable, though. > >> > > > From alessandro.martins at gmail.com Mon Dec 22 18:00:42 2014 From: alessandro.martins at gmail.com (Alessandro Martins) Date: Mon, 22 Dec 2014 16:00:42 -0200 Subject: Internet Service Providers in Bogota Colombia. In-Reply-To: References: Message-ID: As Rubens said, ETB and Telmex Comlombia/Claro are the biggest players in Colombia. Other good options are Internexa, Level3 and Telefónica. Thanks, Alessandro Martins -- Alessandro Martins On Sun, Dec 21, 2014 at 11:37 PM, Rubens Kuhl wrote: > It's very likely that your family member has either ETB (local city-owned > access) or Telmex Colombia. Both players have multiple technology options > (ADSL and WiMAX for both, coax and fiber for Telmex Colombia), so besides > replacing one for the other, it might be possible to improve access by > using a different technology from the same vendor already in place. > > Knowing which technology options are available from each vendor at where > you will be will probably be key in defining a way forward. > > > Rubens > > > > On Sun, Dec 21, 2014 at 11:23 PM, Javier J > wrote: > > > My apologies in advance If there is a better list, please let me know. > > > > I will be traveling to Bogota, Colombia for a few weeks in the spring > and a > > family member who is working there on a contract (where I will be > staying) > > has crappy internet. I want to kill 2 birds with one stone. Make sure I > > have reliable internet and improve what they have. I'm just not sure what > > options are available there. > > > > I speak the language just not familiar with the options. > > > > Any help would be greatly appreciated. > > > From fw at deneb.enyo.de Mon Dec 22 19:15:06 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 22 Dec 2014 20:15:06 +0100 Subject: How our young colleagues are being educated.... In-Reply-To: <154147.1419264698@turing-police.cc.vt.edu> (Valdis Kletnieks's message of "Mon, 22 Dec 2014 11:11:38 -0500") References: <154147.1419264698@turing-police.cc.vt.edu> Message-ID: <87ioh3a43p.fsf@mid.deneb.enyo.de> * Valdis Kletnieks: > On Mon, 22 Dec 2014 04:13:42 -0500, Javier J said: > >> student graduates. They are teaching classful routing and skimming over >> CIDR. Is this indicative of the state of our education system as a whole? > > Did the standard packaged Cisco curriculum finally drop mention of > "Class A/B/C" and go CIDR? Has the output format been changed so that you do not know about address classes anymore? From lists at sadiqs.com Mon Dec 22 18:22:45 2014 From: lists at sadiqs.com (Sadiq Saif) Date: Mon, 22 Dec 2014 13:22:45 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: <154147.1419264698@turing-police.cc.vt.edu> References: <154147.1419264698@turing-police.cc.vt.edu> Message-ID: <54986175.6010504@sadiqs.com> On 12/22/2014 11:11, Valdis.Kletnieks at vt.edu wrote: > Did the standard packaged Cisco curriculum finally drop mention of > "Class A/B/C" and go CIDR? For the most part yes. They still reference it for historical purposes but otherwise it is all VLSM/CIDR. -- Sadiq Saif From math at sizone.org Mon Dec 22 20:31:52 2014 From: math at sizone.org (Ken Chase) Date: Mon, 22 Dec 2014 15:31:52 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: <54986175.6010504@sadiqs.com> References: <154147.1419264698@turing-police.cc.vt.edu> <54986175.6010504@sadiqs.com> Message-ID: <20141222203152.GD23692@sizone.org> Learning how to do CIDR math is a major core component of the coursework? Im thinking that this is about a 30 minute module in the material, once you know binary, powers of 2 and some addition and subtraction (all of which is taught in most schools by when, first year highschool?) you should be done with it. Why is CIDR such an important coursework component? Or is it just a shibboleth to filter out people who cant do simple gradeschool math in their heads or just memorize the subnets (there's only 7.. I've only used supernets twice in the last 10 years..) (I admit I slow down a little when I do wildcard netmasks, but other than that.. ?) I heard tales of kids (ie under 25) learning partial differential equations in university or college as well (which I myself had trouble with but eventually got, at least long enough to write the exam!) so why is the mathematics/symbolics manipulation bar set so low in modern courses in any sci/tech stream? /kc On Mon, Dec 22, 2014 at 01:22:45PM -0500, Sadiq Saif said: >On 12/22/2014 11:11, Valdis.Kletnieks at vt.edu wrote: >> Did the standard packaged Cisco curriculum finally drop mention of >> "Class A/B/C" and go CIDR? > >For the most part yes. They still reference it for historical purposes >but otherwise it is all VLSM/CIDR. > >-- >Sadiq Saif -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From Valdis.Kletnieks at vt.edu Mon Dec 22 23:02:09 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Dec 2014 18:02:09 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: Your message of "Mon, 22 Dec 2014 15:31:52 -0500." <20141222203152.GD23692@sizone.org> References: <154147.1419264698@turing-police.cc.vt.edu> <54986175.6010504@sadiqs.com> <20141222203152.GD23692@sizone.org> Message-ID: <173669.1419289329@turing-police.cc.vt.edu> On Mon, 22 Dec 2014 15:31:52 -0500, Ken Chase said: > Why is CIDR such an important coursework component? Or is it just a shibboleth It's partially like a brown M&M backstage at a Van Halen concert - if their coursework was so pitifully out of date it wasn't covered, you better start wondering what *else* is lacking. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From javier at advancedmachines.us Tue Dec 23 00:05:02 2014 From: javier at advancedmachines.us (Javier J) Date: Mon, 22 Dec 2014 19:05:02 -0500 Subject: Internet Service Providers in Bogota Colombia. In-Reply-To: References: Message-ID: Thanks guys, I appreciate the info greatly. Happy Holidays and a Happy New Year. On Mon, Dec 22, 2014 at 1:00 PM, Alessandro Martins < alessandro.martins at gmail.com> wrote: > As Rubens said, ETB and Telmex Comlombia/Claro are the biggest players in > Colombia. > > Other good options are Internexa, Level3 and Telefónica. > > Thanks, > > Alessandro Martins > > -- > Alessandro Martins > > On Sun, Dec 21, 2014 at 11:37 PM, Rubens Kuhl wrote: > >> It's very likely that your family member has either ETB (local city-owned >> access) or Telmex Colombia. Both players have multiple technology options >> (ADSL and WiMAX for both, coax and fiber for Telmex Colombia), so besides >> replacing one for the other, it might be possible to improve access by >> using a different technology from the same vendor already in place. >> >> Knowing which technology options are available from each vendor at where >> you will be will probably be key in defining a way forward. >> >> >> Rubens >> >> >> >> On Sun, Dec 21, 2014 at 11:23 PM, Javier J >> wrote: >> >> > My apologies in advance If there is a better list, please let me know. >> > >> > I will be traveling to Bogota, Colombia for a few weeks in the spring >> and a >> > family member who is working there on a contract (where I will be >> staying) >> > has crappy internet. I want to kill 2 birds with one stone. Make sure I >> > have reliable internet and improve what they have. I'm just not sure >> what >> > options are available there. >> > >> > I speak the language just not familiar with the options. >> > >> > Any help would be greatly appreciated. >> > >> > > From sebastian.abt at h-da.de Mon Dec 22 21:43:22 2014 From: sebastian.abt at h-da.de (Abt, Sebastian) Date: Mon, 22 Dec 2014 21:43:22 +0000 Subject: CfP - Survey on Internet Routing Security Message-ID: <745DAE50-0BAF-4C2C-B38F-2CA70F72A23B@h-da.de> Dear NANOG. Right to the year’s end I’d like to share the CfP below with you and ask for your participation. The aim of this survey is to better understand what the operational community thinks about the state of Internet routing security (read: BGP security), associated risks and tentative solutions (IRR-based prefix filtering, RPKI origin validation). I regard the outcome as highly interesting and am looking forward to it. I would also appreciate you sharing the CfP via any relevant channel if you think it’s worth it. Every vote counts in order to be able to capture a complete view of the community’s mindset. Thanks and all the best, sebastian +----------------------- Call for Participation -----------------------+ | Survey on Internet Routing Security | +----------------------------------------------------------------------+ | opened from 15.12.14 - 09.01.15 | +----------------> https://www.dasec.h-da.de/survey/ <-----------------+ Prefix hijacking is a well-known problem of Internet routing. As of today, a technique typically deployed to counter prefix hijacking is strict IRR-based peer filtering. However, strict filtering may be challenging for various reasons and, hence, is unfortunately not entirely applied. To improve Internet routing security and to overcome challenges of strict IRR-based peer filtering, RPKI has been proposed. Currently, RPKI origin validation is supported by most RIRs and modern router operating systems. However, recent statistics show that only a limited number of ASes actually deploy RPKI in any form. With this survey, we aim at identifying issues and problems with IRR- based filtering and RPKI from the operational community's point of view and try to quantify the number of ASes actively participating in RPKI. Your input is highly appreciated! Participating in the survey should not take longer than 10 minutes and is completely anonymous. Aggregated results of this survey will be published on the da/sec - Biometrics and Internet Security Research Group’s website [1]. If you have any questions in advance, please do not hesitate to get in touch with Sebastian Abt Thank you for your participation! [1] https://www.dasec.h-da.de/ +----------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4793 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Tue Dec 23 02:05:24 2014 From: Valdis.Kletnieks at vt.edu (Valdis Kletnieks) Date: Mon, 22 Dec 2014 21:05:24 -0500 Subject: North Korean internet goes dark (yes, they had one) Message-ID: <181396.1419300324@turing-police.cc.vt.edu> Any of you guys want to fess up? :) http://www.msnbc.com/the-ed-show/watch/north-koreas-internet-goes-dark-376097859903 (Yes, I know, they're saying it's a DDoS, not a routing hack...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From javier at advancedmachines.us Tue Dec 23 04:16:23 2014 From: javier at advancedmachines.us (Javier J) Date: Mon, 22 Dec 2014 23:16:23 -0500 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: <181396.1419300324@turing-police.cc.vt.edu> References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: But I can ping them. https://nknetobserver.github.io/ And what would it matter if its offline, they already block their population. What exactly is offline? On Mon, Dec 22, 2014 at 9:05 PM, Valdis Kletnieks wrote: > Any of you guys want to fess up? :) > > > http://www.msnbc.com/the-ed-show/watch/north-koreas-internet-goes-dark-376097859903 > > (Yes, I know, they're saying it's a DDoS, not a routing hack...) > From marshall.eubanks at gmail.com Tue Dec 23 06:02:56 2014 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Tue, 23 Dec 2014 01:02:56 -0500 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: On Mon, Dec 22, 2014 at 11:16 PM, Javier J wrote: > But I can ping them. > > https://nknetobserver.github.io/ > > And what would it matter if its offline, they already block their > population. What exactly is offline? > The Kim of the moment, the elite, a few journalists, and the like. And, assuming they actually did the exploit in country and didn't outsource it to the Chaos Computer Club (or whomever), their crack team of Sony takedown hackers. There is a separate, inside DPRK only, network for the hoi polloi. Regards Marshall > > On Mon, Dec 22, 2014 at 9:05 PM, Valdis Kletnieks > > wrote: > > > Any of you guys want to fess up? :) > > > > > > > http://www.msnbc.com/the-ed-show/watch/north-koreas-internet-goes-dark-376097859903 > > > > (Yes, I know, they're saying it's a DDoS, not a routing hack...) > > > From kkinkaid at usgs.gov Tue Dec 23 15:38:02 2014 From: kkinkaid at usgs.gov (Kinkaid, Kyle) Date: Tue, 23 Dec 2014 07:38:02 -0800 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: In addition to my "9 to 5" job of network engineer, I teach evening courses at a US community college (for you non-USers, it's a place for the first 2-years of post-secondary education, typically before proceeding to a full 4-year university). The community college I work at participates in the Cisco Academy program which trains students to get specific Cisco certifications like CCNA, CCNP, CCNA Security. I feel like the Cisco Academy program does a pretty good job at training the students and and addresses many of the issues you found with education in US. Without knowing for sure, your description sounds like that of a "traditional" 4-year university curriculum. The Cisco Academy program focuses on being up-to-date (revisions happen every 4 years or so) and emphasizes working with (preferably physical) routers and switches from day one. I've found 4-year universities, if they have networking courses at all, cover too much theoretical material, emphasize legacy technologies, and are updated only when they must. Further, when in front of students, I always try and relate the material to either what they have experienced in their professional lives (if they are already working) or to what I see in my job regular. I try and keep the students focused on what's practical and only discuss theory and abstract ideas when necessary. I might not be able to do that if I was a professor at a 4-year university, having worked hard on a Ph.D. then on getting tenure. I think it's important to seek to be educated at schools and seek to hire from schools where the instructors have copious practical experience and, preferably, experience which is concurrent with their teaching experience. That will hopefully get you a corps of workers who are better prepared for a job from day one. Just my 2 cents. P.S. This is not to denigrate the value of a Ph.D. or academia. My mentor in my network engineering career has a Ph.D. in Mathematics and having that high-level education was a boon to his being able to understand difficult networking concepts. On Mon, Dec 22, 2014 at 1:13 AM, Javier J wrote: > Dear NANOG Members, > > It has come to my attention, that higher learning institutions in North > America are doing our young future colleagues a disservice. > > I recently ran into a student of Southern New Hampshire University enrolled > in the Networking/Telecom Management course and was shocked by what I > learned. > > Not only are they skimming over new technologies such as BGP, MPLS and the > fundamentals of TCP/IP that run the internet and the networks of the world, > they were focusing on ATM , Frame Relay and other technologies that are on > their way out the door and will probably be extinct by the time this > student graduates. They are teaching classful routing and skimming over > CIDR. Is this indicative of the state of our education system as a whole? > How is it this student doesn't know about OSPF and has never heard of RIP? > > If your network hardware is so old you need a crossover cable, it's time to > upgrade. In this case, it’s time to upgrade our education system. > > I didn't write this email on the sole experience of my conversation with > one student, I wrote this email because I have noticed a pattern emerging > over the years with other university students at other schools across the > country. It’s just the countless times I have crossed paths with a young IT > professional and was literally in shock listening to the things they were > being taught. Teaching old technologies instead of teaching what is > currently being used benefits no one. Teaching classful and skipping CIDR > is another thing that really gets my blood boiling. > > Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? > > What about unicast and multicast? I confirmed with one student half way > through their studies that they were not properly taught how DNS works, and > had no clue what the term “root servers” meant. > > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not > by us, then by whom? How can we fix this? > From marshall.eubanks at gmail.com Tue Dec 23 16:46:15 2014 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Tue, 23 Dec 2014 11:46:15 -0500 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: On Tue, Dec 23, 2014 at 1:02 AM, Marshall Eubanks < marshall.eubanks at gmail.com> wrote: > > > On Mon, Dec 22, 2014 at 11:16 PM, Javier J > wrote: > >> But I can ping them. >> >> https://nknetobserver.github.io/ >> >> And what would it matter if its offline, they already block their >> population. What exactly is offline? >> > > The Kim of the moment, the elite, a few journalists, and the like. And, > assuming they actually did the exploit in country and didn't outsource it > to the Chaos Computer Club (or whomever), their crack team of Sony takedown > hackers. > > There is a separate, inside DPRK only, network for the hoi polloi. > > Regards > Marshall > > >> >> On Mon, Dec 22, 2014 at 9:05 PM, Valdis Kletnieks < >> Valdis.Kletnieks at vt.edu> >> wrote: >> >> > Any of you guys want to fess up? :) >> > >> > >> > >> http://www.msnbc.com/the-ed-show/watch/north-koreas-internet-goes-dark-376097859903 >> > >> > (Yes, I know, they're saying it's a DDoS, not a routing hack...) >> > >> > > The DPRK Internet is apparently back. http://www.bbc.com/news/world-asia-30584093 I suspect its absence was much more interesting that its presence will be. I am reminded that the Chaos Computer Club has done a lot of good work for electronic freedom. I was remembering events (perhaps unfairly) from decades ago, did not mean to cast any aspersions on their current activities, and am sorry if that offended anyone. Regards Marshall Eubanks From joe at nethead.com Tue Dec 23 17:38:26 2014 From: joe at nethead.com (Joe Hamelin) Date: Tue, 23 Dec 2014 09:38:26 -0800 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: <181396.1419300324@turing-police.cc.vt.edu> References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: On Mon, Dec 22, 2014 at 6:05 PM, Valdis Kletnieks wrote: > Any of you guys want to fess up? :) > > > http://www.msnbc.com/the-ed-show/watch/north-koreas-internet-goes-dark-376097859903 > > (Yes, I know, they're saying it's a DDoS, not a routing hack...) I was hoping that everyone just put 175.45.176.0/22 in their bogon list. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From pavel.odintsov at gmail.com Tue Dec 23 18:16:37 2014 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 23 Dec 2014 22:16:37 +0400 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: Why you suggest it? On Tue, Dec 23, 2014 at 8:38 PM, Joe Hamelin wrote: > On Mon, Dec 22, 2014 at 6:05 PM, Valdis Kletnieks > wrote: > >> Any of you guys want to fess up? :) >> >> >> http://www.msnbc.com/the-ed-show/watch/north-koreas-internet-goes-dark-376097859903 >> >> (Yes, I know, they're saying it's a DDoS, not a routing hack...) > > > I was hoping that everyone just put 175.45.176.0/22 in their bogon list. > > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 -- Sincerely yours, Pavel Odintsov From bohn at adelphi.edu Tue Dec 23 19:40:45 2014 From: bohn at adelphi.edu (Dennis Bohn) Date: Tue, 23 Dec 2014 14:40:45 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: <20141222203152.GD23692@sizone.org> References: <154147.1419264698@turing-police.cc.vt.edu> <54986175.6010504@sadiqs.com> <20141222203152.GD23692@sizone.org> Message-ID: On Mon, Dec 22, 2014 at 3:31 PM, Ken Chase wrote: > Learning how to do CIDR math is a major core component of the coursework? > Im > thinking that this is about a 30 minute module in the material, once you > know > binary, powers of 2 and some addition and subtraction (all of which is > taught > in most schools by when, first year highschool?) you should be done with > it. So... just finished up teaching a network course because the Math/Comp Sci dept had lost professors I can tell you it was really tough getting across the idea of four bytes of dotted decimal from binary and THEN subnet masks and getting the students THEN to convert to CIDR. Many glazed eyeballs. We asked some of the students who had taken the network class in prior years and it was true that they learned very little of the things we consider basic, as Javier mentioned. The profs seemed to have been focusing on programming more than neworking per se, even tho the book they were using covered the technology as well as socket programming. We covered all of the things in Javier's initial rant and more, like the principles of TCP congestion control and the history of packet switching. It was fun being able to let them in on some real world things, like say the sinking feeling of making a change in a network and then the phone starts ringing off the hook :-) Unfortunately, this was likely a one-time deal that the students got to really learn a couple of things about networking. Dennis Bohn > Adelphi University > From javier at advancedmachines.us Tue Dec 23 19:53:15 2014 From: javier at advancedmachines.us (Javier J) Date: Tue, 23 Dec 2014 14:53:15 -0500 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: What would be the point in blocking them? They don't even have electricity in the country, what would I worry about coming out of their IP block that wouldn't be more interesting than dangerous. Pretty obvious if it was really them behind the Sony hack, it was outsourced. http://www.standupamericaus.org/sua/wp-content/uploads/2013/03/North-Korea-at-night.jpg On Tue, Dec 23, 2014 at 12:38 PM, Joe Hamelin wrote: > On Mon, Dec 22, 2014 at 6:05 PM, Valdis Kletnieks > > wrote: > > > Any of you guys want to fess up? :) > > > > > > > http://www.msnbc.com/the-ed-show/watch/north-koreas-internet-goes-dark-376097859903 > > > > (Yes, I know, they're saying it's a DDoS, not a routing hack...) > > > I was hoping that everyone just put 175.45.176.0/22 in their bogon list. > > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From landonstewart at gmail.com Tue Dec 23 20:00:04 2014 From: landonstewart at gmail.com (Landon Stewart) Date: Tue, 23 Dec 2014 12:00:04 -0800 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: > On Dec 23, 2014, at 11:53 AM, Javier J wrote: > > What would be the point in blocking them? They don't even have electricity > in the country, what would I worry about coming out of their IP block that > wouldn't be more interesting than dangerous. Pretty obvious if it was > really them behind the Sony hack, it was outsourced. For the few elite that do have Internet in DPRK it would be 1) a big inconvenience which would annoy them a lot and 2) they have to transmit what they want attacked to the outsourced crew (whoever they might be) somehow. I doubt the outsourced group has a fax#. -------------- 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 mattkarney at quadax.com Tue Dec 23 15:58:14 2014 From: mattkarney at quadax.com (Matt Karney) Date: Tue, 23 Dec 2014 15:58:14 +0000 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: I've gone through the CNA (Cisco Networking Academy) program at a US college and got a 4 year Bachelors of Science from there. The program took me through CCNP level courses and prepared me well for taking the CCNP level certs. They also touched on a broad swath of technology from monitoring systems (namely MRTG and PRTG), to wireless, to audio/video basics, etc. And it follows the CCNP (and CCNA for those level courses). So when those change, like they did a few years ago from the 4 test to 3 test versions the curriculum was modified accordingly. Now yes there is some emphasis on a lot of "older" technologies, but they don't know where your career will go. So while I probably won't run into frame relay much, I could. And how routing protocols work in that environment are not the same as Ethernet based topologies. The largest issue I found with my program I went through was that it simply was very arbitrary and isolated from what the real world is. And part of that is that they taught based off the Cisco courses. But it would have been nice to have some classes that were more real world interactions of how things work. For example, BGP communities or AS prepending were not touched in the courses. Or how video/voice is done in the real world (nobody really does a CLI phone system in Cisco VoIP phones which is what we were using). And we never touched Nexus stuff, which was still new at the time to be fair. We also learned on PIX firewalls and only had a few ASA's. But overall it gave a fairly good foundation to build on, which was the point for me. I believe that networking is more akin to a trade than standard 4 year program in a business degree. Every situation, career, environment does things differently. Whereas accounting is going to be pretty much the same anywhere, just with some different applications used potentially. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kinkaid, Kyle Sent: Tuesday, December 23, 2014 10:38 AM To: Javier J Cc: nanog at nanog.org Subject: Re: How our young colleagues are being educated.... In addition to my "9 to 5" job of network engineer, I teach evening courses at a US community college (for you non-USers, it's a place for the first 2-years of post-secondary education, typically before proceeding to a full 4-year university). The community college I work at participates in the Cisco Academy program which trains students to get specific Cisco certifications like CCNA, CCNP, CCNA Security. I feel like the Cisco Academy program does a pretty good job at training the students and and addresses many of the issues you found with education in US. Without knowing for sure, your description sounds like that of a "traditional" 4-year university curriculum. The Cisco Academy program focuses on being up-to-date (revisions happen every 4 years or so) and emphasizes working with (preferably physical) routers and switches from day one. I've found 4-year universities, if they have networking courses at all, cover too much theoretical material, emphasize legacy technologies, and are updated only when they must. Further, when in front of students, I always try and relate the material to either what they have experienced in their professional lives (if they are already working) or to what I see in my job regular. I try and keep the students focused on what's practical and only discuss theory and abstract ideas when necessary. I might not be able to do that if I was a professor at a 4-year university, having worked hard on a Ph.D. then on getting tenure. I think it's important to seek to be educated at schools and seek to hire from schools where the instructors have copious practical experience and, preferably, experience which is concurrent with their teaching experience. That will hopefully get you a corps of workers who are better prepared for a job from day one. Just my 2 cents. P.S. This is not to denigrate the value of a Ph.D. or academia. My mentor in my network engineering career has a Ph.D. in Mathematics and having that high-level education was a boon to his being able to understand difficult networking concepts. On Mon, Dec 22, 2014 at 1:13 AM, Javier J wrote: > Dear NANOG Members, > > It has come to my attention, that higher learning institutions in > North America are doing our young future colleagues a disservice. > > I recently ran into a student of Southern New Hampshire University > enrolled in the Networking/Telecom Management course and was shocked > by what I learned. > > Not only are they skimming over new technologies such as BGP, MPLS and > the fundamentals of TCP/IP that run the internet and the networks of > the world, they were focusing on ATM , Frame Relay and other > technologies that are on their way out the door and will probably be > extinct by the time this student graduates. They are teaching classful > routing and skimming over CIDR. Is this indicative of the state of our education system as a whole? > How is it this student doesn't know about OSPF and has never heard of RIP? > > If your network hardware is so old you need a crossover cable, it's > time to upgrade. In this case, it’s time to upgrade our education system. > > I didn't write this email on the sole experience of my conversation > with one student, I wrote this email because I have noticed a pattern > emerging over the years with other university students at other > schools across the country. It’s just the countless times I have > crossed paths with a young IT professional and was literally in shock > listening to the things they were being taught. Teaching old > technologies instead of teaching what is currently being used benefits > no one. Teaching classful and skipping CIDR is another thing that really gets my blood boiling. > > Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? > > What about unicast and multicast? I confirmed with one student half > way through their studies that they were not properly taught how DNS > works, and had no clue what the term “root servers” meant. > > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if > not by us, then by whom? How can we fix this? > From nanog at ics-il.net Tue Dec 23 20:29:37 2014 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 23 Dec 2014 14:29:37 -0600 (CST) Subject: How our young colleagues are being educated.... In-Reply-To: Message-ID: <22379702.407.1419366608762.JavaMail.mhammett@ThunderFuck> When I took my CCNA a bit over ten years ago, it was terribly out of date. That said, I beleive I was the last class to go through on that version. The next one added OSPF and some other things. At the time, though, Ethernet belonged within a building. If you were wanting to connect multiple buildings together, bust out those T1s. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Kyle Kinkaid" To: "Javier J" Cc: nanog at nanog.org Sent: Tuesday, December 23, 2014 9:38:02 AM Subject: Re: How our young colleagues are being educated.... In addition to my "9 to 5" job of network engineer, I teach evening courses at a US community college (for you non-USers, it's a place for the first 2-years of post-secondary education, typically before proceeding to a full 4-year university). The community college I work at participates in the Cisco Academy program which trains students to get specific Cisco certifications like CCNA, CCNP, CCNA Security. I feel like the Cisco Academy program does a pretty good job at training the students and and addresses many of the issues you found with education in US. Without knowing for sure, your description sounds like that of a "traditional" 4-year university curriculum. The Cisco Academy program focuses on being up-to-date (revisions happen every 4 years or so) and emphasizes working with (preferably physical) routers and switches from day one. I've found 4-year universities, if they have networking courses at all, cover too much theoretical material, emphasize legacy technologies, and are updated only when they must. Further, when in front of students, I always try and relate the material to either what they have experienced in their professional lives (if they are already working) or to what I see in my job regular. I try and keep the students focused on what's practical and only discuss theory and abstract ideas when necessary. I might not be able to do that if I was a professor at a 4-year university, having worked hard on a Ph.D. then on getting tenure. I think it's important to seek to be educated at schools and seek to hire from schools where the instructors have copious practical experience and, preferably, experience which is concurrent with their teaching experience. That will hopefully get you a corps of workers who are better prepared for a job from day one. Just my 2 cents. P.S. This is not to denigrate the value of a Ph.D. or academia. My mentor in my network engineering career has a Ph.D. in Mathematics and having that high-level education was a boon to his being able to understand difficult networking concepts. On Mon, Dec 22, 2014 at 1:13 AM, Javier J wrote: > Dear NANOG Members, > > It has come to my attention, that higher learning institutions in North > America are doing our young future colleagues a disservice. > > I recently ran into a student of Southern New Hampshire University enrolled > in the Networking/Telecom Management course and was shocked by what I > learned. > > Not only are they skimming over new technologies such as BGP, MPLS and the > fundamentals of TCP/IP that run the internet and the networks of the world, > they were focusing on ATM , Frame Relay and other technologies that are on > their way out the door and will probably be extinct by the time this > student graduates. They are teaching classful routing and skimming over > CIDR. Is this indicative of the state of our education system as a whole? > How is it this student doesn't know about OSPF and has never heard of RIP? > > If your network hardware is so old you need a crossover cable, it's time to > upgrade. In this case, it’s time to upgrade our education system. > > I didn't write this email on the sole experience of my conversation with > one student, I wrote this email because I have noticed a pattern emerging > over the years with other university students at other schools across the > country. It’s just the countless times I have crossed paths with a young IT > professional and was literally in shock listening to the things they were > being taught. Teaching old technologies instead of teaching what is > currently being used benefits no one. Teaching classful and skipping CIDR > is another thing that really gets my blood boiling. > > Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? > > What about unicast and multicast? I confirmed with one student half way > through their studies that they were not properly taught how DNS works, and > had no clue what the term “root servers” meant. > > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not > by us, then by whom? How can we fix this? > From randy at psg.com Tue Dec 23 20:40:04 2014 From: randy at psg.com (Randy Bush) Date: Tue, 23 Dec 2014 15:40:04 -0500 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: > I was hoping that everyone just put 175.45.176.0/22 in their bogon list. why? is it something despicable such as the dee cee propaganda engine? randy From joelja at bogus.com Tue Dec 23 20:53:55 2014 From: joelja at bogus.com (joel jaeggli) Date: Tue, 23 Dec 2014 12:53:55 -0800 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: <5499D663.6080603@bogus.com> On 12/23/14 12:40 PM, Randy Bush wrote: >> I was hoping that everyone just put 175.45.176.0/22 in their bogon list. > why? is it something despicable such as the dee cee propaganda engine? Because poorly targeted prefix filtering works so well for spam and ddos... except that it doesn't. > randy > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 221 bytes Desc: OpenPGP digital signature URL: From edlewis.subscriber at cox.net Tue Dec 23 21:14:00 2014 From: edlewis.subscriber at cox.net (Edward Lewis) Date: Tue, 23 Dec 2014 16:14:00 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: <22379702.407.1419366608762.JavaMail.mhammett@ThunderFuck> References: <22379702.407.1419366608762.JavaMail.mhammett@ThunderFuck> Message-ID: Last time I taught, I lectured (senior-level 3-credit elective) on calculating the efficiency of Ethernet and why it was no good above 10Mbps. On Dec 23, 2014, at 15:29, Mike Hammett wrote: > At the time, though, Ethernet belonged within a building. If you were wanting to connect multiple buildings together, bust out those T1s. Fortunately for society, I *stopped* teaching in 1998. Hope it was soon enough. From svoll.voip at gmail.com Tue Dec 23 21:21:55 2014 From: svoll.voip at gmail.com (Scott Voll) Date: Tue, 23 Dec 2014 13:21:55 -0800 Subject: How our young colleagues are being educated.... In-Reply-To: <22379702.407.1419366608762.JavaMail.mhammett@ThunderFuck> References: <22379702.407.1419366608762.JavaMail.mhammett@ThunderFuck> Message-ID: I will agree with most of the others that took the Cisco academy courses at the local community college. it all depends on the instructor. My 1st year was taught in the evenings by a full time Network Engineer. Best 3 terms I had. The problem was that year two was taught be a bunch of old guys that used to teach electronics and DB classes. So everything the old DB guy taught was how the network was like a DB. I think that getting real world teachers are the only way to fix it. unfortunately the program went away as the CC could not pay for new hardware...... Scott On Tue, Dec 23, 2014 at 12:29 PM, Mike Hammett wrote: > When I took my CCNA a bit over ten years ago, it was terribly out of date. > That said, I beleive I was the last class to go through on that version. > The next one added OSPF and some other things. > > At the time, though, Ethernet belonged within a building. If you were > wanting to connect multiple buildings together, bust out those T1s. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Kyle Kinkaid" > To: "Javier J" > Cc: nanog at nanog.org > Sent: Tuesday, December 23, 2014 9:38:02 AM > Subject: Re: How our young colleagues are being educated.... > > In addition to my "9 to 5" job of network engineer, I teach evening courses > at a US community college (for you non-USers, it's a place for the first > 2-years of post-secondary education, typically before proceeding to a full > 4-year university). The community college I work at participates in the > Cisco Academy program which trains students to get specific Cisco > certifications like CCNA, CCNP, CCNA Security. > > I feel like the Cisco Academy program does a pretty good job at training > the students and and addresses many of the issues you found with education > in US. Without knowing for sure, your description sounds like that of a > "traditional" 4-year university curriculum. The Cisco Academy program > focuses on being up-to-date (revisions happen every 4 years or so) and > emphasizes working with (preferably physical) routers and switches from day > one. I've found 4-year universities, if they have networking courses at > all, cover too much theoretical material, emphasize legacy technologies, > and are updated only when they must. > > Further, when in front of students, I always try and relate the material to > either what they have experienced in their professional lives (if they are > already working) or to what I see in my job regular. I try and keep the > students focused on what's practical and only discuss theory and abstract > ideas when necessary. I might not be able to do that if I was a professor > at a 4-year university, having worked hard on a Ph.D. then on getting > tenure. I think it's important to seek to be educated at schools and seek > to hire from schools where the instructors have copious practical > experience and, preferably, experience which is concurrent with their > teaching experience. That will hopefully get you a corps of workers who > are better prepared for a job from day one. > > Just my 2 cents. > > P.S. This is not to denigrate the value of a Ph.D. or academia. My mentor > in my network engineering career has a Ph.D. in Mathematics and having that > high-level education was a boon to his being able to understand difficult > networking concepts. > > On Mon, Dec 22, 2014 at 1:13 AM, Javier J > wrote: > > > Dear NANOG Members, > > > > It has come to my attention, that higher learning institutions in North > > America are doing our young future colleagues a disservice. > > > > I recently ran into a student of Southern New Hampshire University > enrolled > > in the Networking/Telecom Management course and was shocked by what I > > learned. > > > > Not only are they skimming over new technologies such as BGP, MPLS and > the > > fundamentals of TCP/IP that run the internet and the networks of the > world, > > they were focusing on ATM , Frame Relay and other technologies that are > on > > their way out the door and will probably be extinct by the time this > > student graduates. They are teaching classful routing and skimming over > > CIDR. Is this indicative of the state of our education system as a whole? > > How is it this student doesn't know about OSPF and has never heard of > RIP? > > > > If your network hardware is so old you need a crossover cable, it's time > to > > upgrade. In this case, it’s time to upgrade our education system. > > > > I didn't write this email on the sole experience of my conversation with > > one student, I wrote this email because I have noticed a pattern emerging > > over the years with other university students at other schools across the > > country. It’s just the countless times I have crossed paths with a young > IT > > professional and was literally in shock listening to the things they were > > being taught. Teaching old technologies instead of teaching what is > > currently being used benefits no one. Teaching classful and skipping CIDR > > is another thing that really gets my blood boiling. > > > > Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? > > > > What about unicast and multicast? I confirmed with one student half way > > through their studies that they were not properly taught how DNS works, > and > > had no clue what the term “root servers” meant. > > > > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if > not > > by us, then by whom? How can we fix this? > > > > From bedard.phil at gmail.com Tue Dec 23 21:30:25 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 23 Dec 2014 16:30:25 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: <5499df15.705c8c0a.a4fa.10e3@mx.google.com> Yes when I took "networks" as part of my CS degree 12 years ago most of it was socket programming and had very little to do with infrastructure management. I don't think that has changed much talking to recent graduates. Phil -----Original Message----- From: "Kinkaid, Kyle" Sent: ‎12/‎23/‎2014 10:40 AM To: "Javier J" Cc: "nanog at nanog.org" Subject: Re: How our young colleagues are being educated.... In addition to my "9 to 5" job of network engineer, I teach evening courses at a US community college (for you non-USers, it's a place for the first 2-years of post-secondary education, typically before proceeding to a full 4-year university). The community college I work at participates in the Cisco Academy program which trains students to get specific Cisco certifications like CCNA, CCNP, CCNA Security. I feel like the Cisco Academy program does a pretty good job at training the students and and addresses many of the issues you found with education in US. Without knowing for sure, your description sounds like that of a "traditional" 4-year university curriculum. The Cisco Academy program focuses on being up-to-date (revisions happen every 4 years or so) and emphasizes working with (preferably physical) routers and switches from day one. I've found 4-year universities, if they have networking courses at all, cover too much theoretical material, emphasize legacy technologies, and are updated only when they must. Further, when in front of students, I always try and relate the material to either what they have experienced in their professional lives (if they are already working) or to what I see in my job regular. I try and keep the students focused on what's practical and only discuss theory and abstract ideas when necessary. I might not be able to do that if I was a professor at a 4-year university, having worked hard on a Ph.D. then on getting tenure. I think it's important to seek to be educated at schools and seek to hire from schools where the instructors have copious practical experience and, preferably, experience which is concurrent with their teaching experience. That will hopefully get you a corps of workers who are better prepared for a job from day one. Just my 2 cents. P.S. This is not to denigrate the value of a Ph.D. or academia. My mentor in my network engineering career has a Ph.D. in Mathematics and having that high-level education was a boon to his being able to understand difficult networking concepts. On Mon, Dec 22, 2014 at 1:13 AM, Javier J wrote: > Dear NANOG Members, > > It has come to my attention, that higher learning institutions in North > America are doing our young future colleagues a disservice. > > I recently ran into a student of Southern New Hampshire University enrolled > in the Networking/Telecom Management course and was shocked by what I > learned. > > Not only are they skimming over new technologies such as BGP, MPLS and the > fundamentals of TCP/IP that run the internet and the networks of the world, > they were focusing on ATM , Frame Relay and other technologies that are on > their way out the door and will probably be extinct by the time this > student graduates. They are teaching classful routing and skimming over > CIDR. Is this indicative of the state of our education system as a whole? > How is it this student doesn't know about OSPF and has never heard of RIP? > > If your network hardware is so old you need a crossover cable, it's time to > upgrade. In this case, it’s time to upgrade our education system. > > I didn't write this email on the sole experience of my conversation with > one student, I wrote this email because I have noticed a pattern emerging > over the years with other university students at other schools across the > country. It’s just the countless times I have crossed paths with a young IT > professional and was literally in shock listening to the things they were > being taught. Teaching old technologies instead of teaching what is > currently being used benefits no one. Teaching classful and skipping CIDR > is another thing that really gets my blood boiling. > > Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? > > What about unicast and multicast? I confirmed with one student half way > through their studies that they were not properly taught how DNS works, and > had no clue what the term “root servers” meant. > > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not > by us, then by whom? How can we fix this? > From jfmezei_nanog at vaxination.ca Wed Dec 24 09:16:00 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 24 Dec 2014 04:16:00 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: <549A8450.6070209@vaxination.ca> On 14-12-22 04:13, Javier J wrote: > Not only are they skimming over new technologies such as BGP, MPLS and the > fundamentals of TCP/IP that run the internet and the networks of the world, > they were focusing on ATM , Frame Relay and other technologies that are on > their way out My first reaction: teacher is former telco/bell labs/lucent worker and thus his own experience slanted with the old tech telcos were swayed to by telco vendors to make them incompatible with the new competition called Cisco (back then). From swm at emanon.com Wed Dec 24 16:40:48 2014 From: swm at emanon.com (Scott Morris) Date: Wed, 24 Dec 2014 11:40:48 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: References: <154147.1419264698@turing-police.cc.vt.edu> <54986175.6010504@sadiqs.com> <20141222203152.GD23692@sizone.org> Message-ID: All networking courses SHOULD have some version of binary in them. Too many things rely on it to be skipped. Yes, in the real world we have shortcuts. But when those shortcuts become the only thing everyone knows, bad things may be left to happen. Besides, if one can¹t do binary, how can they be expected to understand hex? AnywayŠ Good these things are here, but one thing I will point out is that there is a distinct difference with people glazing over because they don¹t understand something versus the fact that something is truly boring. There¹s nothing sexy about binary. But that doesn¹t mean it can¹t be fun! So if the classes are Death by Powerpoint (which is very typical in academia it seems), then I can certainly understand the aversion that students would have to that. Amazingly enough, for a skill that everyone SHOULD understand, I find a tremendous number of people who don¹t. And for something that¹s boring and nobody wants to learn, I have LOTS of people sign up for various sessions I do at certain vendor¹s trade shows on that very subject. So someplace there¹s a disparity in there. Now, as a side, one problem that I often have with various academic-based courses is that the people who teach them often don¹t have enough real-world experience (or not current anyway) in order to pass along any benefit in that matter. There are many things that need to be addressed at this level within the higher-education arena, and I¹m sure it¹s not just related to networking subjects! Scott -----Original Message----- From: Dennis Bohn Date: Tuesday, December 23, 2014 at 2:40 PM To: Ken Chase Cc: Subject: Re: How our young colleagues are being educated.... >On Mon, Dec 22, 2014 at 3:31 PM, Ken Chase wrote: > >> Learning how to do CIDR math is a major core component of the >>coursework? >> Im >> thinking that this is about a 30 minute module in the material, once you >> know >> binary, powers of 2 and some addition and subtraction (all of which is >> taught >> in most schools by when, first year highschool?) you should be done with >> it. > > >So... just finished up teaching a network course because the Math/Comp Sci >dept had lost professors I can tell you it was really tough getting >across >the idea of four bytes of dotted decimal from binary and THEN subnet >masks >and getting the students THEN to convert to CIDR. Many glazed eyeballs. > >We asked some of the students who had taken the network class in prior >years and it was true that they learned very little of the things we >consider basic, as Javier mentioned. The profs seemed to have been >focusing on programming more than neworking per se, even tho the book they >were using covered the technology as well as socket programming. We >covered all of the things in Javier's initial rant and more, like the >principles of TCP congestion control and the history of packet switching. > >It was fun being able to let them in on some real world things, like say >the sinking feeling of making a change in a network and then the phone >starts ringing off the hook :-) Unfortunately, this was likely a >one-time deal that the students got to really learn a couple of things >about networking. > > >Dennis Bohn >> Adelphi University >> From stu at actusa.net Wed Dec 24 17:29:12 2014 From: stu at actusa.net (Stuart Sheldon) Date: Wed, 24 Dec 2014 09:29:12 -0800 Subject: Time Warner Caching Issue Message-ID: <549AF7E8.8040407@actusa.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Could someone at Time Warner flush the cache for callutheran.edu. It looks like one of your servers is holding the cache... > outlook.callutheran.edu Server: dns-cac-lb-01.rr.com Address: 209.18.47.61 Non-authoritative answer: Name: outlook.callutheran.edu Address: 199.107.196.194 > outlook.callutheran.edu Server: dns-cac-lb-01.rr.com Address: 209.18.47.61 Non-authoritative answer: Name: outlook.callutheran.edu Address: 199.107.196.41 > outlook.callutheran.edu Server: dns-cac-lb-01.rr.com Address: 209.18.47.61 Non-authoritative answer: Name: outlook.callutheran.edu Address: 199.107.196.194 Thanks in advance for any help you can render. Stu Stuart Sheldon ACT USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJUmvfoAAoJEFKVLITDJSGSRnAP+wbfXga8gQ73yurhz188M5JD qKkaVf/4h5uUEMFiJ1lDHbw7mKaHKkYJvPwIk9XuJ1jofXUXakKF1fnbeuYx90ya f+1yjU17z7urIbfQsSZBYJaHbhSu73tDq8VUnAg8cXYcc2PHXE8NbSoYrVEnpqlO qSq1g7fWTr1SHvtAXziFLmbSWuUk5vg/DDXn/6GhfZREXxAKXRQmqZRngMSGmWwu ABg4Kdsoj8SBTVKygADCmQ58mz38fo5BrYXj6B+TPkp1j9LjOyavEhlIzg23NQds zbxH/EdrFig0r6eai4LSxUgePJMAdaYdFPeIMfVYfCsQLvFmDGDszwsp1otK7y7e HWLM8JNH0xKJdqxstwsKN/nsCsTiFExP9ZIskDW875jCteDAKNIdOy69s3uN8Xou f36pCFc2QuTEw+7t8Sk8zJwscr83/JEKBCXWpGmSox4/NpaQOcvrpcmSDqEashUN owgQ+ii9nW/5OKoRKWrAS44yPMIKKwHCcRHGUc2RSFgIDbDnFLubhNjbaAslYXWh yNImUWTzvCjKji16QXmICX9lLzXfRdUGkm2eE8hRsOd+fbi4g8ezkc07tDzolnDp iTfOySpP8vW10IQlCOjNx1JC+RBrfnkSFg9MmBo3t9I5B8tNAAmKKNH3Av75LPiN GGVucS/CXt1BlznEtzIg =Laer -----END PGP SIGNATURE----- From math at sizone.org Wed Dec 24 18:27:13 2014 From: math at sizone.org (Ken Chase) Date: Wed, 24 Dec 2014 13:27:13 -0500 Subject: merry xmas Message-ID: <20141224182713.GQ23692@sizone.org> (mtr|lft|traceroute) xmas.futile.net /kc -- Ken Chase - Toronto Canada From bruns at 2mbit.com Wed Dec 24 18:36:55 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 24 Dec 2014 11:36:55 -0700 Subject: merry xmas In-Reply-To: <20141224182713.GQ23692@sizone.org> References: <20141224182713.GQ23692@sizone.org> Message-ID: <549B07C7.1070009@2mbit.com> On 12/24/14 11:27 AM, Ken Chase wrote: > (mtr|lft|traceroute) xmas.futile.net > It's a good thing we don't have an IPv4 address shortage going on, gotta use all that extra IP space for something! But honestly, cute and a nice touch. I just get this twitch in my neck when I see stuff like that - same twitch I get when I rdns scan a subnet used for IRC vanity host names. Force of habit I guess. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jeroen at massar.ch Wed Dec 24 18:38:18 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 24 Dec 2014 19:38:18 +0100 Subject: merry xmas In-Reply-To: <20141224182713.GQ23692@sizone.org> References: <20141224182713.GQ23692@sizone.org> Message-ID: <549B081A.6000308@massar.ch> On 2014-12-24 19:27, Ken Chase wrote: > (mtr|lft|traceroute) xmas.futile.net Welcome to the end of 2014. If you are going to do a silly traceroute thing that has been done thousands of times before, at least use this new fangled thing called: IPv6 Here is the Wikipedia page for you to get started on it: http://en.wikipedia.org/wiki/IPv6 Thank you for wasting IPv4 space btw, that way IPv6 has to be there earlier, and as you don't have IPv6 yet, good luck with your business ;) Greets, Jeroen From royce at techsolvency.com Wed Dec 24 18:41:03 2014 From: royce at techsolvency.com (Royce Williams) Date: Wed, 24 Dec 2014 09:41:03 -0900 Subject: merry xmas In-Reply-To: <20141224182713.GQ23692@sizone.org> References: <20141224182713.GQ23692@sizone.org> Message-ID: On Wed, Dec 24, 2014 at 9:27 AM, Ken Chase wrote: > > (mtr|lft|traceroute) xmas.futile.net And be sure to crank up the max hops a little higher than 100. Royce From royce at techsolvency.com Wed Dec 24 18:56:04 2014 From: royce at techsolvency.com (Royce Williams) Date: Wed, 24 Dec 2014 09:56:04 -0900 Subject: merry xmas In-Reply-To: <549B081A.6000308@massar.ch> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> Message-ID: On Wed, Dec 24, 2014 at 9:38 AM, Jeroen Massar wrote: > > On 2014-12-24 19:27, Ken Chase wrote: > > (mtr|lft|traceroute) xmas.futile.net > > Welcome to the end of 2014. > > If you are going to do a silly traceroute thing that has been done > thousands of times before, at least use this new fangled thing called: > > IPv6 > > Here is the Wikipedia page for you to get started on it: > http://en.wikipedia.org/wiki/IPv6 > > Thank you for wasting IPv4 space btw, that way IPv6 has to be there > earlier, and as you don't have IPv6 yet, good luck with your business ;) > Maybe it's conspicuous consumption. http://en.wikipedia.org/wiki/Handicap_principle Royce From Valdis.Kletnieks at vt.edu Wed Dec 24 19:06:37 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 24 Dec 2014 14:06:37 -0500 Subject: merry xmas In-Reply-To: Your message of "Wed, 24 Dec 2014 19:38:18 +0100." <549B081A.6000308@massar.ch> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> Message-ID: <79476.1419447997@turing-police.cc.vt.edu> On Wed, 24 Dec 2014 19:38:18 +0100, Jeroen Massar said: > Thank you for wasting IPv4 space btw, that way IPv6 has to be there > earlier, and as you don't have IPv6 yet, good luck with your business ;) Feeling a tad grinchly, are we? :) 'whois 82.133.91.0' reports this: % Information related to '82.133.0.0/17AS9105' route: 82.133.0.0/17 descr: Tiscali UK Limited Feel free to explain how we can *sanely* reclaim a single /24 from a /17 without it looking like a hijacking. Now, *that* would be a really nice holiday gift to the net. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From math at sizone.org Wed Dec 24 19:21:53 2014 From: math at sizone.org (Ken Chase) Date: Wed, 24 Dec 2014 14:21:53 -0500 Subject: merry xmas In-Reply-To: <549B081A.6000308@massar.ch> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> Message-ID: <20141224192153.GS23692@sizone.org> On Wed, Dec 24, 2014 at 07:38:18PM +0100, Jeroen Massar said: >Welcome to the end of 2014. Yes, I know, fakeroute has been around a while (so has das blinkenlights, but I still find both cute. Though it has been a longwhile since anyone forwarded me DECWARS... /* fakeroute (c) 1996 Julian Assange */ /kc -- Ken Chase - Toronto CANADA From guillaume at ironie.org Wed Dec 24 08:44:47 2014 From: guillaume at ironie.org (Guillaume Tournat) Date: Wed, 24 Dec 2014 09:44:47 +0100 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: <98D345B1-53FF-4853-B9CD-37C50BF879F3@ironie.org> You have listened Fox news for too long, being convinced that US are the good, and any others are evil. Dont you? > Le 23 déc. 2014 à 21:00, Landon Stewart a écrit : > > For the few elite that do have Internet in DPRK it would be 1) a big inconvenience which would annoy them a lot and 2) they have to transmit what they want attacked to the outsourced crew (whoever they might be) somehow. I doubt the outsourced group has a fax#. From theodore at ciscodude.net Wed Dec 24 19:40:34 2014 From: theodore at ciscodude.net (Theodore Baschak) Date: Wed, 24 Dec 2014 13:40:34 -0600 Subject: merry xmas In-Reply-To: <549B081A.6000308@massar.ch> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> Message-ID: <6930CE1B-5F28-4C77-8F01-2B791698E87F@ciscodude.net> > On 24 Dec 2014, at 12:38, Jeroen Massar wrote: > > On 2014-12-24 19:27, Ken Chase wrote: >> (mtr|lft|traceroute) xmas.futile.net > > Welcome to the end of 2014. > > If you are going to do a silly traceroute thing that has been done > thousands of times before, at least use this new fangled thing called: > > IPv6 > > Here is the Wikipedia page for you to get started on it: > http://en.wikipedia.org/wiki/IPv6 > > Thank you for wasting IPv4 space btw, that way IPv6 has to be there > earlier, and as you don't have IPv6 yet, good luck with your business ;) > > Greets, > Jeroen > For anyone who wishes to implement a Holiday Message for us IPv6 folks, Job Snijders has this code online: https://github.com/job/ipv6-traceroute-faker Just needs Linux, Python, and a /64 routed to it. -- Theo Baschak BOFH excuse #411: Traffic jam on the Information Superhighway. From louisperoot at mygb.eu Wed Dec 24 20:27:05 2014 From: louisperoot at mygb.eu (Louis) Date: Wed, 24 Dec 2014 21:27:05 +0100 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: <549B2199.9020104@mygb.eu> As a student I feel particularly concerned about this. Le 22/12/2014 10:13, Javier J a écrit : > Not only are they skimming over new technologies such as BGP, MPLS and the > fundamentals of TCP/IP that run the internet and the networks of the world, > they were focusing on ATM , Frame Relay and other technologies that are on > their way out the door and will probably be extinct by the time this > student graduates. They are teaching classful routing and skimming over > CIDR. Is this indicative of the state of our education system as a whole? > How is it this student doesn't know about OSPF and has never heard of RIP? On the point about learning "ancient" technologies like X.25, I strongly believe it's not useless when put in comparison with newer ones . The purpose of some protocols depends on their environment at a specific time. IMHO, the evolution that resulted SPDY shows how TCP *was* relevant when you had lots of noise on the line (back-off algorithms). Furthermore, getting to know the past is the best way to avoid perpetrating the same mistakes all over. Eventually providing bases and theory of a simple communication (channeling, OSI model, error-correction, etc.). The administration's opinion is not to get hands on the latest technology (mostly pushed by companies) since it can be valueless tomorrow. On the other hand, people have to be very careful not keeping the rusty engine working. I never knew if one of my teacher was aware of the existence of CIDR notation, meanwhile he taught us about IPv6 (sadly not as a turning point with IPv4 exhaustion but more like a fancy feature). On other courses, it ended with VxLAN, LTE and multicast. I agree that SDN is becoming inevitable and is showing the tip of its nose. In my experience, I've never waited courses to understand DNS or BGP (yet they gave me strong roots thereafter). I'm also one of the few to attend networking conferences. I get a glance at a more political than technical view of what will be the future Internet, not taught in class. I believe lots students aren't aware of theses events, of the resources, and would be very interested : they just need a little boost. Some others, as anywhere, won't be very implicated going deeper than the courses. So, even if they had the latest knowledge, I don't think it would be so much more beneficial. In lab we get the opportunity to configure on high-end material. Our subjects are sometimes very restrictive, not helping to see past the few commands, not involving "creative" things like seeing everyone a an independent network, routing through some... One of my disappointments is we only work on a unique brand. I don't think we should go over a cheaper manufacturer (removing a somewhat "precious" experience on the famous one) but we should be given alternatives, the equivalent of pseudo-code : the router is only a mean to achieve : how does a Linux construct the BGP command comparing to Cisco... From jeroen at massar.ch Wed Dec 24 20:35:30 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 24 Dec 2014 21:35:30 +0100 Subject: merry xmas In-Reply-To: <79476.1419447997@turing-police.cc.vt.edu> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> <79476.1419447997@turing-police.cc.vt.edu> Message-ID: <549B2392.1080701@massar.ch> On 2014-12-24 20:06, Valdis.Kletnieks at vt.edu wrote: > On Wed, 24 Dec 2014 19:38:18 +0100, Jeroen Massar said: > >> Thank you for wasting IPv4 space btw, that way IPv6 has to be there >> earlier, and as you don't have IPv6 yet, good luck with your business ;) > > Feeling a tad grinchly, are we? :) > > 'whois 82.133.91.0' reports this: > > % Information related to '82.133.0.0/17AS9105' > > route: 82.133.0.0/17 > descr: Tiscali UK Limited > > Feel free to explain how we can *sanely* reclaim a single /24 from a /17 > without it looking like a hijacking. Why would one bother with IPv4? Just start using IPv6, that IPv4 stuff will disappear over the next few decades by itself. > Now, *that* would be a really nice holiday gift to the net. A /17 would only last a few moments, not worth the effort of recovering it. Though indeed the reason why CGNs are being deployed is so that the business parts of the same company can charge extra for public IPv4s. On 2014-12-24 20:21, Ken Chase wrote: > On Wed, Dec 24, 2014 at 07:38:18PM +0100, Jeroen Massar said: > > >Welcome to the end of 2014. > > Yes, I know, fakeroute has been around a while (so has das > blinkenlights, but I still find both cute. the BOFH jadedness> > > Though it has been a longwhile since anyone forwarded me DECWARS... > > /* fakeroute (c) 1996 Julian Assange */ Interesting, I did remember rotorouter[1] and check the below url for what the reply to that was, the above one. Funny, seems that mr.Assange did something semi-useful with computers back then *wink* ;) That trick does not help in setting the reverses though as one does not control them; though one could possibly find all the 'sentences' in reverses around the net and reorder them into something coherent... Greets, Jeroen [1] http://www.shmoo.com/mail/bugtraq/aug98/msg00110.html From Valdis.Kletnieks at vt.edu Wed Dec 24 21:00:36 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 24 Dec 2014 16:00:36 -0500 Subject: merry xmas In-Reply-To: Your message of "Wed, 24 Dec 2014 21:35:30 +0100." <549B2392.1080701@massar.ch> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> <79476.1419447997@turing-police.cc.vt.edu> <549B2392.1080701@massar.ch> Message-ID: <83685.1419454836@turing-police.cc.vt.edu> On Wed, 24 Dec 2014 21:35:30 +0100, Jeroen Massar said: > On 2014-12-24 20:06, Valdis.Kletnieks at vt.edu wrote: > > Feel free to explain how we can *sanely* reclaim a single /24 from a /17 > > without it looking like a hijacking. > > Why would one bother with IPv4? Well then, the waste of a /24 doesn't *actually* matter then, does it? :) > Just start using IPv6, that IPv4 stuff will disappear over the next few > decades by itself. (And I *did* "just start using IPv6" - I helped my employer put it in production *last century*. Glad to see the rest of the world finally catch up. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From eyeronic.design at gmail.com Wed Dec 24 21:05:01 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Wed, 24 Dec 2014 13:05:01 -0800 Subject: merry xmas In-Reply-To: <549B2392.1080701@massar.ch> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> <79476.1419447997@turing-police.cc.vt.edu> <549B2392.1080701@massar.ch> Message-ID: *grumble grumble bah humbug grumble grumble splat* On Wed, Dec 24, 2014 at 12:35 PM, Jeroen Massar wrote: > On 2014-12-24 20:06, Valdis.Kletnieks at vt.edu wrote: >> On Wed, 24 Dec 2014 19:38:18 +0100, Jeroen Massar said: >> >>> Thank you for wasting IPv4 space btw, that way IPv6 has to be there >>> earlier, and as you don't have IPv6 yet, good luck with your business ;) >> >> Feeling a tad grinchly, are we? :) >> >> 'whois 82.133.91.0' reports this: >> >> % Information related to '82.133.0.0/17AS9105' >> >> route: 82.133.0.0/17 >> descr: Tiscali UK Limited >> >> Feel free to explain how we can *sanely* reclaim a single /24 from a /17 >> without it looking like a hijacking. > > Why would one bother with IPv4? > > Just start using IPv6, that IPv4 stuff will disappear over the next few > decades by itself. > >> Now, *that* would be a really nice holiday gift to the net. > > A /17 would only last a few moments, not worth the effort of recovering > it. Though indeed the reason why CGNs are being deployed is so that the > business parts of the same company can charge extra for public IPv4s. > > > On 2014-12-24 20:21, Ken Chase wrote: >> On Wed, Dec 24, 2014 at 07:38:18PM +0100, Jeroen Massar said: >> >> >Welcome to the end of 2014. >> >> Yes, I know, fakeroute has been around a while (so has das >> blinkenlights, but I still find both cute. > the BOFH jadedness> >> >> Though it has been a longwhile since anyone forwarded me DECWARS... >> >> /* fakeroute (c) 1996 Julian Assange */ > > Interesting, I did remember rotorouter[1] and check the below url for > what the reply to that was, the above one. Funny, seems that mr.Assange > did something semi-useful with computers back then *wink* ;) > > That trick does not help in setting the reverses though as one does not > control them; though one could possibly find all the 'sentences' in > reverses around the net and reorder them into something coherent... > > Greets, > Jeroen > > [1] http://www.shmoo.com/mail/bugtraq/aug98/msg00110.html > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From jamann at mt.gov Wed Dec 24 20:46:14 2014 From: jamann at mt.gov (Mann, Jason) Date: Wed, 24 Dec 2014 20:46:14 +0000 Subject: merry xmas In-Reply-To: <549B2392.1080701@massar.ch> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> <79476.1419447997@turing-police.cc.vt.edu> <549B2392.1080701@massar.ch> Message-ID: <8E594056E7C55C4F996A8A380A5FB6F32CEA928A@doaisd5237.state.mt.ads> Merry Christmas to everyone and happy New Year!! -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jeroen Massar Sent: Wednesday, December 24, 2014 1:36 PM To: Valdis.Kletnieks at vt.edu Cc: nanog at nanog.org Subject: Re: merry xmas On 2014-12-24 20:06, Valdis.Kletnieks at vt.edu wrote: > On Wed, 24 Dec 2014 19:38:18 +0100, Jeroen Massar said: > >> Thank you for wasting IPv4 space btw, that way IPv6 has to be there >> earlier, and as you don't have IPv6 yet, good luck with your business >> ;) > > Feeling a tad grinchly, are we? :) > > 'whois 82.133.91.0' reports this: > > % Information related to '82.133.0.0/17AS9105' > > route: 82.133.0.0/17 > descr: Tiscali UK Limited > > Feel free to explain how we can *sanely* reclaim a single /24 from a > /17 without it looking like a hijacking. Why would one bother with IPv4? Just start using IPv6, that IPv4 stuff will disappear over the next few decades by itself. > Now, *that* would be a really nice holiday gift to the net. A /17 would only last a few moments, not worth the effort of recovering it. Though indeed the reason why CGNs are being deployed is so that the business parts of the same company can charge extra for public IPv4s. On 2014-12-24 20:21, Ken Chase wrote: > On Wed, Dec 24, 2014 at 07:38:18PM +0100, Jeroen Massar said: > > >Welcome to the end of 2014. > > Yes, I know, fakeroute has been around a while (so has das > blinkenlights, but I still find both cute. jadedness> > > Though it has been a longwhile since anyone forwarded me DECWARS... > > /* fakeroute (c) 1996 Julian Assange */ Interesting, I did remember rotorouter[1] and check the below url for what the reply to that was, the above one. Funny, seems that mr.Assange did something semi-useful with computers back then *wink* ;) That trick does not help in setting the reverses though as one does not control them; though one could possibly find all the 'sentences' in reverses around the net and reorder them into something coherent... Greets, Jeroen [1] http://www.shmoo.com/mail/bugtraq/aug98/msg00110.html From jfmezei_nanog at vaxination.ca Wed Dec 24 21:38:31 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 24 Dec 2014 16:38:31 -0500 Subject: merry xmas In-Reply-To: <20141224182713.GQ23692@sizone.org> References: <20141224182713.GQ23692@sizone.org> Message-ID: <549B3257.6070802@vaxination.ca> On 14-12-24 13:27, Ken Chase wrote: > (mtr|lft|traceroute) xmas.futile.net This one uses only 1 IPv4, so can't be accused of wasting half of internet address space :-) http://http://www.vaxination.ca/temp/train.gif This is an old 1980s ASCII art from VMS that ran on VT220s, digitally restored to animated Gif. (script to slowly dump content to xterm, while quicktime is recording the screen, then off to Adobe Premiere for cropping, scaling, and of course, giving it the CRT look by making it amber text of black background :-) A flash version was also created by twitter: https://twitter.com/jfmezei/status/547300803779002368/photo/1 From sam at vis.nu Wed Dec 24 21:55:21 2014 From: sam at vis.nu (Sam Mulvey) Date: Wed, 24 Dec 2014 13:55:21 -0800 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: References: <181396.1419300324@turing-police.cc.vt.edu> Message-ID: <549B3649.4020401@vis.nu> On 12/22/14 20:16, Javier J wrote: > But I can ping them. > > https://nknetobserver.github.io/ > > And what would it matter if its offline, they already block their > population. What exactly is offline? I seem to recall that they also had some space on a Japanese network. I can't hit the Naenara website, which is the DPRK intranet-- that might be what they're talking about. -Sam From kmedcalf at dessus.com Wed Dec 24 23:26:01 2014 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 24 Dec 2014 16:26:01 -0700 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: Message-ID: <102a60f842e16c4f9c4c971c4a02ae2c@mail.dessus.com> >> What would be the point in blocking them? They don't even have >> electricity in the country, what would I worry about coming out >> of their IP block that wouldn't be more interesting than dangerous. >> Pretty obvious if it was really them behind the Sony hack, it >> was outsourced. >For the few elite that do have Internet in DPRK it would be 1) a big >inconvenience which would annoy them a lot and 2) they have to transmit >what they want attacked to the outsourced crew (whoever they might be) >somehow. I doubt the outsourced group has a fax#. I am pretty sure that they have fax machines in Washington Dee Cee. --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. From lists at sadiqs.com Thu Dec 25 01:01:25 2014 From: lists at sadiqs.com (Sadiq Saif) Date: Wed, 24 Dec 2014 20:01:25 -0500 Subject: merry xmas In-Reply-To: <6930CE1B-5F28-4C77-8F01-2B791698E87F@ciscodude.net> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> <6930CE1B-5F28-4C77-8F01-2B791698E87F@ciscodude.net> Message-ID: <549B61E5.5060409@sadiqs.com> On 12/24/2014 14:40, Theodore Baschak wrote: > For anyone who wishes to implement a Holiday Message for us IPv6 folks, > Job Snijders has this code online: > https://github.com/job/ipv6-traceroute-faker > > Just needs Linux, Python, and a /64 routed to it. > Been trying to get this running but I get this error: TypeError: do_callback() takes exactly 1 argument (2 given) Not sure where it is getting the second argument. Any ideas? -- Sadiq Saif https://staticsafe.ca From lists at sadiqs.com Thu Dec 25 01:05:19 2014 From: lists at sadiqs.com (Sadiq Saif) Date: Wed, 24 Dec 2014 20:05:19 -0500 Subject: merry xmas In-Reply-To: <549B61E5.5060409@sadiqs.com> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> <6930CE1B-5F28-4C77-8F01-2B791698E87F@ciscodude.net> <549B61E5.5060409@sadiqs.com> Message-ID: <549B62CF.4050500@sadiqs.com> On 12/24/2014 20:01, Sadiq Saif wrote: > Been trying to get this running but I get this error: > TypeError: do_callback() takes exactly 1 argument (2 given) > > Not sure where it is getting the second argument. Any ideas? > To clarify, I am running Python 2.7.6 (default, Mar 22 2014, 22:59:56) on Ubuntu 14.04. -- Sadiq Saif https://staticsafe.ca From ammar at fastreturn.net Thu Dec 25 01:06:30 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Thu, 25 Dec 2014 05:06:30 +0400 Subject: merry xmas In-Reply-To: <549B61E5.5060409@sadiqs.com> References: <20141224182713.GQ23692@sizone.org> <549B081A.6000308@massar.ch> <6930CE1B-5F28-4C77-8F01-2B791698E87F@ciscodude.net> <549B61E5.5060409@sadiqs.com> Message-ID: At least you’re only having problems with the IPv6 version, I’ve spent about an hour trying to get the IPv4 version of fakeroute working and I just can’t. I even tried a few different ones. Does anyone have a version that works? I have some fun things I’d like to do with it ;) Ammar. > On Dec 25, 2014, at 5:01 AM, Sadiq Saif wrote: > > On 12/24/2014 14:40, Theodore Baschak wrote: >> For anyone who wishes to implement a Holiday Message for us IPv6 folks, >> Job Snijders has this code online: >> https://github.com/job/ipv6-traceroute-faker >> >> Just needs Linux, Python, and a /64 routed to it. >> > > Been trying to get this running but I get this error: > TypeError: do_callback() takes exactly 1 argument (2 given) > > Not sure where it is getting the second argument. Any ideas? > > -- > Sadiq Saif > https://staticsafe.ca From lists at sadiqs.com Thu Dec 25 01:52:03 2014 From: lists at sadiqs.com (Sadiq Saif) Date: Wed, 24 Dec 2014 20:52:03 -0500 Subject: merry xmas In-Reply-To: <20141224182713.GQ23692@sizone.org> References: <20141224182713.GQ23692@sizone.org> Message-ID: <549B6DC3.9050503@sadiqs.com> On 12/24/2014 13:27, Ken Chase wrote: > (mtr|lft|traceroute) xmas.futile.net > > /kc > -- > Ken Chase - Toronto Canada > Here is the IPv6 version: mtr xmas.asininetech.org Thanks to all the people who helped with the bit of python debugging. :) -- Sadiq Saif https://staticsafe.ca From lists at sadiqs.com Thu Dec 25 02:22:06 2014 From: lists at sadiqs.com (Sadiq Saif) Date: Wed, 24 Dec 2014 21:22:06 -0500 Subject: merry xmas In-Reply-To: <549B6DC3.9050503@sadiqs.com> References: <20141224182713.GQ23692@sizone.org> <549B6DC3.9050503@sadiqs.com> Message-ID: <549B74CE.6070002@sadiqs.com> On 12/24/2014 20:52, Sadiq Saif wrote: > > Here is the IPv6 version: > mtr xmas.asininetech.org > > Thanks to all the people who helped with the bit of python debugging. > :) > For those using traceroute6, try with the -I flag. -- Sadiq Saif https://staticsafe.ca From mawatari at jpix.ad.jp Thu Dec 25 08:46:27 2014 From: mawatari at jpix.ad.jp (MAWATARI Masataka) Date: Thu, 25 Dec 2014 17:46:27 +0900 Subject: IPv6 survey (JANOG 35 IPv6 session) Message-ID: <20141225174627.E0C3.8FE1F57E@jpix.ad.jp> Hi all, JANOG will have a session "Why don't we want to deploy IPv6?" in JANOG 35 meeting next month. It will focus on IPv6 deployment of the contents providers in Japan. To help us make this session better, we carry out a questionnaire survey to the service providers. It would be great if you could fill out the following questionnaire: https://www.janog.gr.jp/meeting/janog35/program/ipv6/ipv6_form_en/ Your co-operation will be appreciated. We will make a good use out of the survey information in order to improve this session. We'll update you with more details about JANOG 35 meeting through the following page. http://www.janog.gr.jp/en/index.php?JANOG35_Meeting Happy Holidays! -- Japan Internet Exchange MAWATARI Masataka From mgreco at fusethree.com Thu Dec 25 12:00:29 2014 From: mgreco at fusethree.com (mgreco at fusethree.com) Date: Thu, 25 Dec 2014 04:00:29 -0800 Subject: AutoReply: NANOG Digest, Vol 83, Issue 25 Message-ID: <950e7ebc-da80-4fb6-97ab-b8479ade0b6e@F3-EX1.fusethree.com> -------------------------------- [Insert your auto response here] -------------------------------- Michael Greco mgreco at fusethree.com | www.fusethree.com 916-484-1780 | 888-245-5565 FUSE3 Communications 11630 Fair Oaks Blvd Fair Oaks, CA 95628 The information transmitted, including attachments, is intended only for the person(s) 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 received this in error please contact the sender and destroy any copies of this information. From mansaxel at besserwisser.org Thu Dec 25 18:39:35 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 25 Dec 2014 19:39:35 +0100 Subject: How our young colleagues are being educated.... In-Reply-To: References: <154147.1419264698@turing-police.cc.vt.edu> <54986175.6010504@sadiqs.com> <20141222203152.GD23692@sizone.org> Message-ID: <20141225183934.GA8631@besserwisser.org> Subject: Re: How our young colleagues are being educated.... Date: Wed, Dec 24, 2014 at 11:40:48AM -0500 Quoting Scott Morris (swm at emanon.com): > Now, as a side, one problem that I often have with various academic-based > courses is that the people who teach them often don¹t have enough > real-world experience (or not current anyway) in order to pass along any > benefit in that matter. There are many things that need to be addressed > at this level within the higher-education arena, and I¹m sure it¹s not > just related to networking subjects! When I did teaching, it was as an employee hired to do network ops first and academic stuff a definite second. I'm still not qualified to even apply to the courses I taught, but I did get nice evaluations; simply because what we taught was very connected to the NREN we ran. Thus we could pick examples from Actual Reality and make the binary -> hex conversions relevant. I'm thinking that network operations and design today is a field much like workshop toolroom knowledge was back before CAD/CAM; there is a solid and long scientific backing to what is done, in materials science, maths, etc; the machines used are products from elevated precision and experience centres, but still, you can't get them to do anything useful without a well balanced theoretical background coupled to solid hands-on experience. The rookie and the engineer from the construction dept. will both need training to be useful and non-lethal in that environment, even if the engineer can design a successful lathe. The rôle of network courses in academia, then, is a lot like looking out for the programmer with the soldering iron. People who know how things ought to work in theory are quite likely to be dangerous in practice. (and don't get me started on studio sound engineers in live sound...) It might be though, that I've simply been watching Keith Fenner on Youtube too many late nights. (That is a recommendation, btw.) -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Uh-oh!! I forgot to submit to COMPULSORY URINALYSIS! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mike at mikejones.in Fri Dec 26 00:06:46 2014 From: mike at mikejones.in (Mike Jones) Date: Fri, 26 Dec 2014 00:06:46 +0000 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: I am a university student that has just completed the first term of the first year of a Computer Systems and Networks course. Apart from a really out of place MATH module that did trig but not binary, it has been reasonably well run so far. The binary is covered in a different module, just not maths. The worst part of the course is actually the core networking module, which is based on Cisco material. The cisco material is HORRIBLE! those awkward "book" page things with the stupid higherarchical menu. As for the content.. a scalable network is one you can add hosts to, so what's a non-scalable network? will the building collapse if i plug my laptop in? As I have been following NANOG for years I do notice a lot of mistakes or "over-simplifications" that show a clear distinction between the theory in the university books and the reality on nanog, and demonstrate the lecturers lack of real world exposure. As a simple example, in IPv4 the goal is to conserve IP addresses therefore on point to point links you use a /30 which only wastes 50% of the address space. In the real world - /31's? but a /31 is impossible I hear the lecturers say... The entire campus is not only IPv4-only, but on the wifi network they actually assign globally routable addresses, then block protocol 41, so windows configures broken 6to4! Working IPv6 connectivity would at least expose students to it a little and let them play with it... Amoung the things I have heard so far: MAC Addresses are unique, IP fragments should be blocked for security reasons, and the OSI model only has 7 layers to worry about. All theoretically correct. All wrong. - Mike Jones On 22 December 2014 at 09:13, Javier J wrote: > Dear NANOG Members, > > It has come to my attention, that higher learning institutions in North > America are doing our young future colleagues a disservice. > > I recently ran into a student of Southern New Hampshire University enrolled > in the Networking/Telecom Management course and was shocked by what I > learned. > > Not only are they skimming over new technologies such as BGP, MPLS and the > fundamentals of TCP/IP that run the internet and the networks of the world, > they were focusing on ATM , Frame Relay and other technologies that are on > their way out the door and will probably be extinct by the time this > student graduates. They are teaching classful routing and skimming over > CIDR. Is this indicative of the state of our education system as a whole? > How is it this student doesn't know about OSPF and has never heard of RIP? > > If your network hardware is so old you need a crossover cable, it's time to > upgrade. In this case, it’s time to upgrade our education system. > > I didn't write this email on the sole experience of my conversation with > one student, I wrote this email because I have noticed a pattern emerging > over the years with other university students at other schools across the > country. It’s just the countless times I have crossed paths with a young IT > professional and was literally in shock listening to the things they were > being taught. Teaching old technologies instead of teaching what is > currently being used benefits no one. Teaching classful and skipping CIDR > is another thing that really gets my blood boiling. > > Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? > > What about unicast and multicast? I confirmed with one student half way > through their studies that they were not properly taught how DNS works, and > had no clue what the term “root servers” meant. > > Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not > by us, then by whom? How can we fix this? From mfidelman at meetinghouse.net Fri Dec 26 00:21:34 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 25 Dec 2014 19:21:34 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: <549CAA0E.5080406@meetinghouse.net> Cisco as the basis of networking material? Does nobody use Comer, Stallings, or Tannenbaum as basic texts anymore? Miles Fidelman Mike Jones wrote: > I am a university student that has just completed the first term of > the first year of a Computer Systems and Networks course. Apart from a > really out of place MATH module that did trig but not binary, it has > been reasonably well run so far. The binary is covered in a different > module, just not maths. The worst part of the course is actually the > core networking module, which is based on Cisco material. The cisco > material is HORRIBLE! those awkward "book" page things with the stupid > higherarchical menu. As for the content.. a scalable network is one > you can add hosts to, so what's a non-scalable network? will the > building collapse if i plug my laptop in? > > As I have been following NANOG for years I do notice a lot of mistakes > or "over-simplifications" that show a clear distinction between the > theory in the university books and the reality on nanog, and > demonstrate the lecturers lack of real world exposure. As a simple > example, in IPv4 the goal is to conserve IP addresses therefore on > point to point links you use a /30 which only wastes 50% of the > address space. In the real world - /31's? but a /31 is impossible I > hear the lecturers say... > > The entire campus is not only IPv4-only, but on the wifi network they > actually assign globally routable addresses, then block protocol 41, > so windows configures broken 6to4! Working IPv6 connectivity would at > least expose students to it a little and let them play with it... > > Amoung the things I have heard so far: MAC Addresses are unique, IP > fragments should be blocked for security reasons, and the OSI model > only has 7 layers to worry about. All theoretically correct. All > wrong. > - Mike Jones > > > On 22 December 2014 at 09:13, Javier J wrote: >> Dear NANOG Members, >> >> It has come to my attention, that higher learning institutions in North >> America are doing our young future colleagues a disservice. >> >> I recently ran into a student of Southern New Hampshire University enrolled >> in the Networking/Telecom Management course and was shocked by what I >> learned. >> >> Not only are they skimming over new technologies such as BGP, MPLS and the >> fundamentals of TCP/IP that run the internet and the networks of the world, >> they were focusing on ATM , Frame Relay and other technologies that are on >> their way out the door and will probably be extinct by the time this >> student graduates. They are teaching classful routing and skimming over >> CIDR. Is this indicative of the state of our education system as a whole? >> How is it this student doesn't know about OSPF and has never heard of RIP? >> >> If your network hardware is so old you need a crossover cable, it's time to >> upgrade. In this case, it’s time to upgrade our education system. >> >> I didn't write this email on the sole experience of my conversation with >> one student, I wrote this email because I have noticed a pattern emerging >> over the years with other university students at other schools across the >> country. It’s just the countless times I have crossed paths with a young IT >> professional and was literally in shock listening to the things they were >> being taught. Teaching old technologies instead of teaching what is >> currently being used benefits no one. Teaching classful and skipping CIDR >> is another thing that really gets my blood boiling. >> >> Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? >> >> What about unicast and multicast? I confirmed with one student half way >> through their studies that they were not properly taught how DNS works, and >> had no clue what the term “root servers” meant. >> >> Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not >> by us, then by whom? How can we fix this? -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From larrysheldon at cox.net Fri Dec 26 02:03:33 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 25 Dec 2014 20:03:33 -0600 Subject: AutoReply: NANOG Digest, Vol 83, Issue 25 In-Reply-To: References: Message-ID: <549CC1F5.8030708@cox.net> On 12/25/2014 06:00, mgreco at fusethree.com wrote: > -------------------------------- [Insert your auto response here] > -------------------------------- > > > Michael Greco mgreco at fusethree.com | www.fusethree.com 916-484-1780 | > 888-245-5565 > > FUSE3 Communications 11630 Fair Oaks Blvd Fair Oaks, CA 95628 > > The information transmitted, including attachments, is intended only > for the person(s) 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 received this in error please contact > the sender and destroy any copies of this information. Perfection in auto responder implementation! Absolutely no extractable useful information, and poorly punctuated dross to boot. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From shortdudey123 at gmail.com Fri Dec 26 02:13:01 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 25 Dec 2014 20:13:01 -0600 Subject: How our young colleagues are being educated.... In-Reply-To: <549CAA0E.5080406@meetinghouse.net> References: <549CAA0E.5080406@meetinghouse.net> Message-ID: I used Stallings a couple years ago. Cisco is not the basis of networking. It is the basis for TCP/IP. -Grant On Thu, Dec 25, 2014 at 6:21 PM, Miles Fidelman wrote: > Cisco as the basis of networking material? Does nobody use Comer, > Stallings, or Tannenbaum as basic texts anymore? > > Miles Fidelman > > > Mike Jones wrote: > >> I am a university student that has just completed the first term of >> the first year of a Computer Systems and Networks course. Apart from a >> really out of place MATH module that did trig but not binary, it has >> been reasonably well run so far. The binary is covered in a different >> module, just not maths. The worst part of the course is actually the >> core networking module, which is based on Cisco material. The cisco >> material is HORRIBLE! those awkward "book" page things with the stupid >> higherarchical menu. As for the content.. a scalable network is one >> you can add hosts to, so what's a non-scalable network? will the >> building collapse if i plug my laptop in? >> >> As I have been following NANOG for years I do notice a lot of mistakes >> or "over-simplifications" that show a clear distinction between the >> theory in the university books and the reality on nanog, and >> demonstrate the lecturers lack of real world exposure. As a simple >> example, in IPv4 the goal is to conserve IP addresses therefore on >> point to point links you use a /30 which only wastes 50% of the >> address space. In the real world - /31's? but a /31 is impossible I >> hear the lecturers say... >> >> The entire campus is not only IPv4-only, but on the wifi network they >> actually assign globally routable addresses, then block protocol 41, >> so windows configures broken 6to4! Working IPv6 connectivity would at >> least expose students to it a little and let them play with it... >> >> Amoung the things I have heard so far: MAC Addresses are unique, IP >> fragments should be blocked for security reasons, and the OSI model >> only has 7 layers to worry about. All theoretically correct. All >> wrong. >> - Mike Jones >> >> >> On 22 December 2014 at 09:13, Javier J >> wrote: >> >>> Dear NANOG Members, >>> >>> It has come to my attention, that higher learning institutions in North >>> America are doing our young future colleagues a disservice. >>> >>> I recently ran into a student of Southern New Hampshire University >>> enrolled >>> in the Networking/Telecom Management course and was shocked by what I >>> learned. >>> >>> Not only are they skimming over new technologies such as BGP, MPLS and >>> the >>> fundamentals of TCP/IP that run the internet and the networks of the >>> world, >>> they were focusing on ATM , Frame Relay and other technologies that are >>> on >>> their way out the door and will probably be extinct by the time this >>> student graduates. They are teaching classful routing and skimming over >>> CIDR. Is this indicative of the state of our education system as a whole? >>> How is it this student doesn't know about OSPF and has never heard of >>> RIP? >>> >>> If your network hardware is so old you need a crossover cable, it's time >>> to >>> upgrade. In this case, it’s time to upgrade our education system. >>> >>> I didn't write this email on the sole experience of my conversation with >>> one student, I wrote this email because I have noticed a pattern emerging >>> over the years with other university students at other schools across the >>> country. It’s just the countless times I have crossed paths with a young >>> IT >>> professional and was literally in shock listening to the things they were >>> being taught. Teaching old technologies instead of teaching what is >>> currently being used benefits no one. Teaching classful and skipping CIDR >>> is another thing that really gets my blood boiling. >>> >>> Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? >>> >>> What about unicast and multicast? I confirmed with one student half way >>> through their studies that they were not properly taught how DNS works, >>> and >>> had no clue what the term “root servers” meant. >>> >>> Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if >>> not >>> by us, then by whom? How can we fix this? >>> >> > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > From mfidelman at meetinghouse.net Fri Dec 26 03:48:34 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 25 Dec 2014 22:48:34 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: References: <549CAA0E.5080406@meetinghouse.net> Message-ID: <549CDA92.4030507@meetinghouse.net> Well... to be accurate, and just a tad pedantic, the basis for TCP/IP is: "A Protocol for Packet Network Intercommunication," Vinton G. Cerf & Robert E. Kahn, IEEE Trans on Comms, Vol Com-22, No 5 May 1974 Miles Fidelman Grant Ridder wrote: > I used Stallings a couple years ago. Cisco is not the basis of > networking. It is the basis for TCP/IP. > > -Grant > > On Thu, Dec 25, 2014 at 6:21 PM, Miles Fidelman > > wrote: > > Cisco as the basis of networking material? Does nobody use Comer, > Stallings, or Tannenbaum as basic texts anymore? > > Miles Fidelman > > > Mike Jones wrote: > > I am a university student that has just completed the first > term of > the first year of a Computer Systems and Networks course. > Apart from a > really out of place MATH module that did trig but not binary, > it has > been reasonably well run so far. The binary is covered in a > different > module, just not maths. The worst part of the course is > actually the > core networking module, which is based on Cisco material. The > cisco > material is HORRIBLE! those awkward "book" page things with > the stupid > higherarchical menu. As for the content.. a scalable network > is one > you can add hosts to, so what's a non-scalable network? will the > building collapse if i plug my laptop in? > > As I have been following NANOG for years I do notice a lot of > mistakes > or "over-simplifications" that show a clear distinction > between the > theory in the university books and the reality on nanog, and > demonstrate the lecturers lack of real world exposure. As a simple > example, in IPv4 the goal is to conserve IP addresses therefore on > point to point links you use a /30 which only wastes 50% of the > address space. In the real world - /31's? but a /31 is > impossible I > hear the lecturers say... > > The entire campus is not only IPv4-only, but on the wifi > network they > actually assign globally routable addresses, then block > protocol 41, > so windows configures broken 6to4! Working IPv6 connectivity > would at > least expose students to it a little and let them play with it... > > Amoung the things I have heard so far: MAC Addresses are > unique, IP > fragments should be blocked for security reasons, and the OSI > model > only has 7 layers to worry about. All theoretically correct. All > wrong. > - Mike Jones > > > On 22 December 2014 at 09:13, Javier J > > wrote: > > Dear NANOG Members, > > It has come to my attention, that higher learning > institutions in North > America are doing our young future colleagues a disservice. > > I recently ran into a student of Southern New Hampshire > University enrolled > in the Networking/Telecom Management course and was > shocked by what I > learned. > > Not only are they skimming over new technologies such as > BGP, MPLS and the > fundamentals of TCP/IP that run the internet and the > networks of the world, > they were focusing on ATM , Frame Relay and other > technologies that are on > their way out the door and will probably be extinct by the > time this > student graduates. They are teaching classful routing and > skimming over > CIDR. Is this indicative of the state of our education > system as a whole? > How is it this student doesn't know about OSPF and has > never heard of RIP? > > If your network hardware is so old you need a crossover > cable, it's time to > upgrade. In this case, it’s time to upgrade our education > system. > > I didn't write this email on the sole experience of my > conversation with > one student, I wrote this email because I have noticed a > pattern emerging > over the years with other university students at other > schools across the > country. It’s just the countless times I have crossed > paths with a young IT > professional and was literally in shock listening to the > things they were > being taught. Teaching old technologies instead of > teaching what is > currently being used benefits no one. Teaching classful > and skipping CIDR > is another thing that really gets my blood boiling. > > Are colleges teaching what an RFC is? Are colleges > teaching what IPv6 is? > > What about unicast and multicast? I confirmed with one > student half way > through their studies that they were not properly taught > how DNS works, and > had no clue what the term “root servers” meant. > > Am I crazy? Am I ranting? Doesn't this need to be > addressed? …..and if not > by us, then by whom? How can we fix this? > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Fri Dec 26 04:01:22 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 25 Dec 2014 23:01:22 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: <481369245.827665.1419559528744.JavaMail.yahoo@jws100169.mail.ne1.yahoo.com> References: <549CAA0E.5080406@meetinghouse.net> <481369245.827665.1419559528744.JavaMail.yahoo@jws100169.mail.ne1.yahoo.com> Message-ID: <549CDD92.4050801@meetinghouse.net> FYI, just checked, and, Comer's "Internetworking with TCP/IP" seems to be in its 6th edition, published 2013 Stallings' "Data and Computer Communications" seems to be in its 10th edition, also 2013 Tannenbaum's "Computer Networks" seems to be in its 5th edition, published 2010 So... all still pretty current. (My personal copies are just a bit more dated, first editions that probably do qualify as "historical references," along with my old standby - the "DDN Protocol Handbook," complete with the MIL-STD versions of some classic RFPs :-) Cheers, Miles Randy wrote: > Interesting that you mention Tannenbaum - was required as part of my grad school coursework eons ago - provided me with the foundation for everything else to come. > > Perhaps it does not apply anymore; but learning to troubleshoot a call across an X.75 telnet gateway at DNIC 3106 gave me practical experience. > > Historical references in a nutshell; even in today's coursework IMO are still relevant. > > ./Randy > > > > ----- Original Message ----- > From: Miles Fidelman > To: > Cc: "nanog at nanog.org" > Sent: Thursday, December 25, 2014 4:21 PM > Subject: Re: How our young colleagues are being educated.... > > Cisco as the basis of networking material? Does nobody use Comer, > Stallings, or Tannenbaum as basic texts anymore? > > Miles Fidelman > > Mike Jones wrote: >> I am a university student that has just completed the first term of >> the first year of a Computer Systems and Networks course. Apart from a >> really out of place MATH module that did trig but not binary, it has >> been reasonably well run so far. The binary is covered in a different >> module, just not maths. The worst part of the course is actually the >> core networking module, which is based on Cisco material. The cisco >> material is HORRIBLE! those awkward "book" page things with the stupid >> higherarchical menu. As for the content.. a scalable network is one >> you can add hosts to, so what's a non-scalable network? will the >> building collapse if i plug my laptop in? >> >> As I have been following NANOG for years I do notice a lot of mistakes >> or "over-simplifications" that show a clear distinction between the >> theory in the university books and the reality on nanog, and >> demonstrate the lecturers lack of real world exposure. As a simple >> example, in IPv4 the goal is to conserve IP addresses therefore on >> point to point links you use a /30 which only wastes 50% of the >> address space. In the real world - /31's? but a /31 is impossible I >> hear the lecturers say... >> >> The entire campus is not only IPv4-only, but on the wifi network they >> actually assign globally routable addresses, then block protocol 41, >> so windows configures broken 6to4! Working IPv6 connectivity would at >> least expose students to it a little and let them play with it... >> >> Amoung the things I have heard so far: MAC Addresses are unique, IP >> fragments should be blocked for security reasons, and the OSI model >> only has 7 layers to worry about. All theoretically correct. All >> wrong. >> - Mike Jones >> >> >> On 22 December 2014 at 09:13, Javier J wrote: >>> Dear NANOG Members, >>> >>> It has come to my attention, that higher learning institutions in North >>> America are doing our young future colleagues a disservice. >>> >>> I recently ran into a student of Southern New Hampshire University enrolled >>> in the Networking/Telecom Management course and was shocked by what I >>> learned. >>> >>> Not only are they skimming over new technologies such as BGP, MPLS and the >>> fundamentals of TCP/IP that run the internet and the networks of the world, >>> they were focusing on ATM , Frame Relay and other technologies that are on >>> their way out the door and will probably be extinct by the time this >>> student graduates. They are teaching classful routing and skimming over >>> CIDR. Is this indicative of the state of our education system as a whole? >>> How is it this student doesn't know about OSPF and has never heard of RIP? >>> >>> If your network hardware is so old you need a crossover cable, it's time to >>> upgrade. In this case, it’s time to upgrade our education system. >>> >>> I didn't write this email on the sole experience of my conversation with >>> one student, I wrote this email because I have noticed a pattern emerging >>> over the years with other university students at other schools across the >>> country. It’s just the countless times I have crossed paths with a young IT >>> professional and was literally in shock listening to the things they were >>> being taught. Teaching old technologies instead of teaching what is >>> currently being used benefits no one. Teaching classful and skipping CIDR >>> is another thing that really gets my blood boiling. >>> >>> Are colleges teaching what an RFC is? Are colleges teaching what IPv6 is? >>> >>> What about unicast and multicast? I confirmed with one student half way >>> through their studies that they were not properly taught how DNS works, and >>> had no clue what the term “root servers” meant. >>> >>> Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and if not >>> by us, then by whom? How can we fix this? > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From admin at coldnorthadmin.com Fri Dec 26 03:33:42 2014 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Thu, 25 Dec 2014 22:33:42 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: <549CAA0E.5080406@meetinghouse.net> References: <549CAA0E.5080406@meetinghouse.net> Message-ID: <549CD716.30405@coldnorthadmin.com> The Cisco "Networking Academy" program was used throughout my "CEGEP"(End of high-school/first college year equivalent in the US) education in Quebec. There was no deviation from the course work and the aim was to get the student CCNA certified at the end. On 12/25/2014 7:21 PM, Miles Fidelman wrote: > Cisco as the basis of networking material? Does nobody use Comer, > Stallings, or Tannenbaum as basic texts anymore? > > Miles Fidelman > > Mike Jones wrote: >> I am a university student that has just completed the first term of >> the first year of a Computer Systems and Networks course. Apart from a >> really out of place MATH module that did trig but not binary, it has >> been reasonably well run so far. The binary is covered in a different >> module, just not maths. The worst part of the course is actually the >> core networking module, which is based on Cisco material. The cisco >> material is HORRIBLE! those awkward "book" page things with the stupid >> higherarchical menu. As for the content.. a scalable network is one >> you can add hosts to, so what's a non-scalable network? will the >> building collapse if i plug my laptop in? >> >> As I have been following NANOG for years I do notice a lot of mistakes >> or "over-simplifications" that show a clear distinction between the >> theory in the university books and the reality on nanog, and >> demonstrate the lecturers lack of real world exposure. As a simple >> example, in IPv4 the goal is to conserve IP addresses therefore on >> point to point links you use a /30 which only wastes 50% of the >> address space. In the real world - /31's? but a /31 is impossible I >> hear the lecturers say... >> >> The entire campus is not only IPv4-only, but on the wifi network they >> actually assign globally routable addresses, then block protocol 41, >> so windows configures broken 6to4! Working IPv6 connectivity would at >> least expose students to it a little and let them play with it... >> >> Amoung the things I have heard so far: MAC Addresses are unique, IP >> fragments should be blocked for security reasons, and the OSI model >> only has 7 layers to worry about. All theoretically correct. All >> wrong. >> - Mike Jones >> >> >> On 22 December 2014 at 09:13, Javier J >> wrote: >>> Dear NANOG Members, >>> >>> It has come to my attention, that higher learning institutions in North >>> America are doing our young future colleagues a disservice. >>> >>> I recently ran into a student of Southern New Hampshire University >>> enrolled >>> in the Networking/Telecom Management course and was shocked by what I >>> learned. >>> >>> Not only are they skimming over new technologies such as BGP, MPLS >>> and the >>> fundamentals of TCP/IP that run the internet and the networks of the >>> world, >>> they were focusing on ATM , Frame Relay and other technologies that >>> are on >>> their way out the door and will probably be extinct by the time this >>> student graduates. They are teaching classful routing and skimming over >>> CIDR. Is this indicative of the state of our education system as a >>> whole? >>> How is it this student doesn't know about OSPF and has never heard >>> of RIP? >>> >>> If your network hardware is so old you need a crossover cable, it's >>> time to >>> upgrade. In this case, it’s time to upgrade our education system. >>> >>> I didn't write this email on the sole experience of my conversation >>> with >>> one student, I wrote this email because I have noticed a pattern >>> emerging >>> over the years with other university students at other schools >>> across the >>> country. It’s just the countless times I have crossed paths with a >>> young IT >>> professional and was literally in shock listening to the things they >>> were >>> being taught. Teaching old technologies instead of teaching what is >>> currently being used benefits no one. Teaching classful and skipping >>> CIDR >>> is another thing that really gets my blood boiling. >>> >>> Are colleges teaching what an RFC is? Are colleges teaching what >>> IPv6 is? >>> >>> What about unicast and multicast? I confirmed with one student half way >>> through their studies that they were not properly taught how DNS >>> works, and >>> had no clue what the term “root servers” meant. >>> >>> Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and >>> if not >>> by us, then by whom? How can we fix this? > > From ahebert at pubnix.net Fri Dec 26 04:42:45 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 25 Dec 2014 23:42:45 -0500 (EST) Subject: How our young colleagues are being educated.... In-Reply-To: <549CD716.30405@coldnorthadmin.com> References: <549CAA0E.5080406@meetinghouse.net> <549CD716.30405@coldnorthadmin.com> Message-ID: <61943.64.235.216.13.1419568965.squirrel@mail.pubnix.net> Well let start with: Happy Holidays. In my line of work anyone with a CCNA get put at the bottom of the pile =D We're looking for proactive associates and found that applicants which present themselves as a CCNA engineer foremost are only just that: Someone that could follow the course and bother to pass it. Best deal is to get Cisco 1000V image (or GNS) and a Virtual Server (about $600 used with 72G of RAM lately, and you do not need huge amount of disks) and start making test beds for real world needs. The only drawback is that you may make the interviewer worried about his own job =D Good luck. > The Cisco "Networking Academy" program was used throughout my > "CEGEP"(End of high-school/first college year equivalent in the US) > education in Quebec. There was no deviation from the course work and the > aim was to get the student CCNA certified at the end. > > On 12/25/2014 7:21 PM, Miles Fidelman wrote: >> Cisco as the basis of networking material? Does nobody use Comer, >> Stallings, or Tannenbaum as basic texts anymore? >> >> Miles Fidelman >> >> Mike Jones wrote: >>> I am a university student that has just completed the first term of >>> the first year of a Computer Systems and Networks course. Apart from a >>> really out of place MATH module that did trig but not binary, it has >>> been reasonably well run so far. The binary is covered in a different >>> module, just not maths. The worst part of the course is actually the >>> core networking module, which is based on Cisco material. The cisco >>> material is HORRIBLE! those awkward "book" page things with the stupid >>> higherarchical menu. As for the content.. a scalable network is one >>> you can add hosts to, so what's a non-scalable network? will the >>> building collapse if i plug my laptop in? >>> >>> As I have been following NANOG for years I do notice a lot of mistakes >>> or "over-simplifications" that show a clear distinction between the >>> theory in the university books and the reality on nanog, and >>> demonstrate the lecturers lack of real world exposure. As a simple >>> example, in IPv4 the goal is to conserve IP addresses therefore on >>> point to point links you use a /30 which only wastes 50% of the >>> address space. In the real world - /31's? but a /31 is impossible I >>> hear the lecturers say... >>> >>> The entire campus is not only IPv4-only, but on the wifi network they >>> actually assign globally routable addresses, then block protocol 41, >>> so windows configures broken 6to4! Working IPv6 connectivity would at >>> least expose students to it a little and let them play with it... >>> >>> Amoung the things I have heard so far: MAC Addresses are unique, IP >>> fragments should be blocked for security reasons, and the OSI model >>> only has 7 layers to worry about. All theoretically correct. All >>> wrong. >>> - Mike Jones >>> >>> >>> On 22 December 2014 at 09:13, Javier J >>> wrote: >>>> Dear NANOG Members, >>>> >>>> It has come to my attention, that higher learning institutions in >>>> North >>>> America are doing our young future colleagues a disservice. >>>> >>>> I recently ran into a student of Southern New Hampshire University >>>> enrolled >>>> in the Networking/Telecom Management course and was shocked by what I >>>> learned. >>>> >>>> Not only are they skimming over new technologies such as BGP, MPLS >>>> and the >>>> fundamentals of TCP/IP that run the internet and the networks of the >>>> world, >>>> they were focusing on ATM , Frame Relay and other technologies that >>>> are on >>>> their way out the door and will probably be extinct by the time this >>>> student graduates. They are teaching classful routing and skimming >>>> over >>>> CIDR. Is this indicative of the state of our education system as a >>>> whole? >>>> How is it this student doesn't know about OSPF and has never heard >>>> of RIP? >>>> >>>> If your network hardware is so old you need a crossover cable, it's >>>> time to >>>> upgrade. In this case, it’s time to upgrade our education system. >>>> >>>> I didn't write this email on the sole experience of my conversation >>>> with >>>> one student, I wrote this email because I have noticed a pattern >>>> emerging >>>> over the years with other university students at other schools >>>> across the >>>> country. It’s just the countless times I have crossed paths with a >>>> young IT >>>> professional and was literally in shock listening to the things they >>>> were >>>> being taught. Teaching old technologies instead of teaching what is >>>> currently being used benefits no one. Teaching classful and skipping >>>> CIDR >>>> is another thing that really gets my blood boiling. >>>> >>>> Are colleges teaching what an RFC is? Are colleges teaching what >>>> IPv6 is? >>>> >>>> What about unicast and multicast? I confirmed with one student half >>>> way >>>> through their studies that they were not properly taught how DNS >>>> works, and >>>> had no clue what the term “root servers” meant. >>>> >>>> Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and >>>> if not >>>> by us, then by whom? How can we fix this? >> >> > > From admin at coldnorthadmin.com Fri Dec 26 04:49:21 2014 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Thu, 25 Dec 2014 23:49:21 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: <61943.64.235.216.13.1419568965.squirrel@mail.pubnix.net> References: <549CAA0E.5080406@meetinghouse.net> <549CD716.30405@coldnorthadmin.com> <61943.64.235.216.13.1419568965.squirrel@mail.pubnix.net> Message-ID: <549CE8D1.9040605@coldnorthadmin.com> Merry Christmas! (Even if slightly late...) I absolutely agree. The certification by itself doesn't prove much beyond a passing interest in networking and an ability to retain a fair amount of information. I suspect it's mostly a question of creating some kind of standard to judge applicants. It's also worth mentioning that I bet that many HR departments are actively hunting for keywords such as certifications acronyms. It was just a bit sad to see the certification itself as the "real" goal of the program. Cheers! On 12/25/2014 11:42 PM, Alain Hebert wrote: > Well let start with: Happy Holidays. > > In my line of work anyone with a CCNA get put at the bottom of the pile =D > > We're looking for proactive associates and found that applicants which > present themselves as a CCNA engineer foremost are only just that: Someone > that could follow the course and bother to pass it. > > Best deal is to get Cisco 1000V image (or GNS) and a Virtual Server (about > $600 used with 72G of RAM lately, and you do not need huge amount of > disks) and start making test beds for real world needs. > > The only drawback is that you may make the interviewer worried about his > own job =D > > Good luck. > >> The Cisco "Networking Academy" program was used throughout my >> "CEGEP"(End of high-school/first college year equivalent in the US) >> education in Quebec. There was no deviation from the course work and the >> aim was to get the student CCNA certified at the end. >> >> On 12/25/2014 7:21 PM, Miles Fidelman wrote: >>> Cisco as the basis of networking material? Does nobody use Comer, >>> Stallings, or Tannenbaum as basic texts anymore? >>> >>> Miles Fidelman >>> >>> Mike Jones wrote: >>>> I am a university student that has just completed the first term of >>>> the first year of a Computer Systems and Networks course. Apart from a >>>> really out of place MATH module that did trig but not binary, it has >>>> been reasonably well run so far. The binary is covered in a different >>>> module, just not maths. The worst part of the course is actually the >>>> core networking module, which is based on Cisco material. The cisco >>>> material is HORRIBLE! those awkward "book" page things with the stupid >>>> higherarchical menu. As for the content.. a scalable network is one >>>> you can add hosts to, so what's a non-scalable network? will the >>>> building collapse if i plug my laptop in? >>>> >>>> As I have been following NANOG for years I do notice a lot of mistakes >>>> or "over-simplifications" that show a clear distinction between the >>>> theory in the university books and the reality on nanog, and >>>> demonstrate the lecturers lack of real world exposure. As a simple >>>> example, in IPv4 the goal is to conserve IP addresses therefore on >>>> point to point links you use a /30 which only wastes 50% of the >>>> address space. In the real world - /31's? but a /31 is impossible I >>>> hear the lecturers say... >>>> >>>> The entire campus is not only IPv4-only, but on the wifi network they >>>> actually assign globally routable addresses, then block protocol 41, >>>> so windows configures broken 6to4! Working IPv6 connectivity would at >>>> least expose students to it a little and let them play with it... >>>> >>>> Amoung the things I have heard so far: MAC Addresses are unique, IP >>>> fragments should be blocked for security reasons, and the OSI model >>>> only has 7 layers to worry about. All theoretically correct. All >>>> wrong. >>>> - Mike Jones >>>> >>>> >>>> On 22 December 2014 at 09:13, Javier J >>>> wrote: >>>>> Dear NANOG Members, >>>>> >>>>> It has come to my attention, that higher learning institutions in >>>>> North >>>>> America are doing our young future colleagues a disservice. >>>>> >>>>> I recently ran into a student of Southern New Hampshire University >>>>> enrolled >>>>> in the Networking/Telecom Management course and was shocked by what I >>>>> learned. >>>>> >>>>> Not only are they skimming over new technologies such as BGP, MPLS >>>>> and the >>>>> fundamentals of TCP/IP that run the internet and the networks of the >>>>> world, >>>>> they were focusing on ATM , Frame Relay and other technologies that >>>>> are on >>>>> their way out the door and will probably be extinct by the time this >>>>> student graduates. They are teaching classful routing and skimming >>>>> over >>>>> CIDR. Is this indicative of the state of our education system as a >>>>> whole? >>>>> How is it this student doesn't know about OSPF and has never heard >>>>> of RIP? >>>>> >>>>> If your network hardware is so old you need a crossover cable, it's >>>>> time to >>>>> upgrade. In this case, it’s time to upgrade our education system. >>>>> >>>>> I didn't write this email on the sole experience of my conversation >>>>> with >>>>> one student, I wrote this email because I have noticed a pattern >>>>> emerging >>>>> over the years with other university students at other schools >>>>> across the >>>>> country. It’s just the countless times I have crossed paths with a >>>>> young IT >>>>> professional and was literally in shock listening to the things they >>>>> were >>>>> being taught. Teaching old technologies instead of teaching what is >>>>> currently being used benefits no one. Teaching classful and skipping >>>>> CIDR >>>>> is another thing that really gets my blood boiling. >>>>> >>>>> Are colleges teaching what an RFC is? Are colleges teaching what >>>>> IPv6 is? >>>>> >>>>> What about unicast and multicast? I confirmed with one student half >>>>> way >>>>> through their studies that they were not properly taught how DNS >>>>> works, and >>>>> had no clue what the term “root servers” meant. >>>>> >>>>> Am I crazy? Am I ranting? Doesn't this need to be addressed? …..and >>>>> if not >>>>> by us, then by whom? How can we fix this? >>> >> > From bill at herrin.us Fri Dec 26 07:56:40 2014 From: bill at herrin.us (William Herrin) Date: Fri, 26 Dec 2014 02:56:40 -0500 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: On Thu, Dec 25, 2014 at 7:06 PM, Mike Jones wrote: > As for the content.. a scalable network is one > you can add hosts to, so what's a non-scalable network? will the > building collapse if i plug my laptop in? Hi Mike, A few starting points for interesting insight: https://bill.herrin.us/network/bgpcost.html According to the estimate, it costs about $8000/year (pennies here and pennies there, they add up) to add a single multihomed network to the Internet before you even consider the bytes sent and received. There are around 500,000 such networks. If 10,000,000 such networks were required, we would have difficulty building routers that could work. Indeed, in the 90's the Internet's 50,000ish networks caught up to and nearly exceeded the routers we were capable of building. We came close to having to triage by cutting networks off the Internet. That's an example of something that scales poorly. On the other hand, adding a DNS zone costs $10/year or less. We could add a billion or a trillion more and it might add a few million dollars total to the cost of a few root and TLD name servers. The DNS scales well. > As I have been following NANOG for years I do notice a lot of mistakes > or "over-simplifications" that show a clear distinction between the > theory in the university books and the reality on nanog, and > demonstrate the lecturers lack of real world exposure. As a simple > example, in IPv4 the goal is to conserve IP addresses therefore on > point to point links you use a /30 which only wastes 50% of the > address space. In the real world - /31's? but a /31 is impossible I > hear the lecturers say... In the real world you often assign a /32 to a loopback address on each router and make all of the serial interfaces borrow that address (ip unnumbered in Cisco parlance) which wastes no addresses. With non-point to point links there are other tricks you can play to avoid wasting more addresses than strictly necessary. > Amoung the things I have heard so far: MAC Addresses are unique, Except when they're not. The 802.3 standard is ambiguous about whether a MAC address should be unique per interface or unique per host. Sun (now Oracle) took the latter view and assigned the same MAC address to every Ethernet port on a particular host leading to hideously confused Ethernet switches. The ambiguity even creeps into Linux. Unless the behavior is overridden with a sysctl, Linux will happily answer an arp request on eth0 for an IP address that lives on eth1. > IP fragments should be blocked for security reasons, Not a smart move, IMO. In a stateful firewall (e.g. NAT) let the firewall reassemble the packets. In a stateless firewall, block the first fragment only, and only if it's too short for whatever filtering you intend to apply. Any first fragment that's not an attack will be at least a few hundred bytes long. Also, pity the fool who blocks ICMP because he breaks TCP at the same time. Path MTU discovery requires ICMP destination unreachable messages to function. TCP will screech to a halt every time it attempts to send a packet larger than the path MTU until the host receives the ICMP notification. > and the OSI model > only has 7 layers to worry about. All theoretically correct. All > wrong. Not exactly. The OSI layers exhibit a basically correct understanding of packet networks. They just don't stack so neatly as the authors expected. In particular, we keep finding excuses to stack additional layer 2's and 3's on top of underlying layer 2's and 3's. We give this names like "MPLS" and "VPN." Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From mansaxel at besserwisser.org Fri Dec 26 09:35:53 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 26 Dec 2014 10:35:53 +0100 Subject: How our young colleagues are being educated.... In-Reply-To: References: Message-ID: <20141226093552.GB8631@besserwisser.org> Subject: Re: How our young colleagues are being educated.... Date: Fri, Dec 26, 2014 at 02:56:40AM -0500 Quoting William Herrin (bill at herrin.us): > In the real world you often assign a /32 to a loopback address on each > router and make all of the serial interfaces borrow that address (ip > unnumbered in Cisco parlance) which wastes no addresses. Why would you want to waste 79228162514264337593543950336 addresses on a loopback? More seriously, why does this discussion only briefly mention IPv6? Every client comes with it (aggressvely) enabled -- it is there despite the fat / happy parts of the networking community sitting on their legacy space and laughing at Asia. I've had, as mentioned earlier, a "cisco graduate" as intern and then colleague for a year now. He's a fast learner, and that was needed. No v6. Not much MPLS. No ISIS. Barely eBGP. No iBGP, especially not in conjunction with a link-state IGP. Lots of RIP, Flame Delay and EIGRP. There are two problems; * The academic community is either outdated or married to a vendor-specific course -- and that marriage is not very academic, IMNSHO. Academia must be vendor agnostic. * The vendor courses are too enterprisey, and an outdated enterprise at that. There is no course in "running a sensible chunk of the Internet". And this in a world where the largest innovation the last 5 years is abstraction (as in virtualisation and to some extent SDN). Not in protocols. Should be reasonably easy to keep up. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 So this is what it feels like to be potato salad -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mgreco at fusethree.com Fri Dec 26 12:00:29 2014 From: mgreco at fusethree.com (mgreco at fusethree.com) Date: Fri, 26 Dec 2014 04:00:29 -0800 Subject: AutoReply: NANOG Digest, Vol 83, Issue 26 Message-ID: <0118b4f1-aa86-40b1-9177-bfe58a653719@F3-EX1.fusethree.com> -------------------------------- [Insert your auto response here] -------------------------------- Michael Greco mgreco at fusethree.com | www.fusethree.com 916-484-1780 | 888-245-5565 FUSE3 Communications 11630 Fair Oaks Blvd Fair Oaks, CA 95628 The information transmitted, including attachments, is intended only for the person(s) 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 received this in error please contact the sender and destroy any copies of this information. From cscora at apnic.net Fri Dec 26 18:11:43 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Dec 2014 04:11:43 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201412261811.sBQIBhif011148@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 27 Dec, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 524268 Prefixes after maximum aggregation: 201685 Deaggregation factor: 2.60 Unique aggregates announced to Internet: 256512 Total ASes present in the Internet Routing Table: 48941 Prefixes per ASN: 10.71 Origin-only ASes present in the Internet Routing Table: 36363 Origin ASes announcing only one prefix: 16284 Transit ASes present in the Internet Routing Table: 6207 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: 100 Max AS path prepend of ASN ( 55644) 93 Prefixes from unregistered ASNs in the Routing Table: 1667 Unregistered ASNs in the Routing Table: 424 Number of 32-bit ASNs allocated by the RIRs: 8281 Number of 32-bit ASNs visible in the Routing Table: 6371 Prefixes from 32-bit ASNs in the Routing Table: 22956 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 375 Number of addresses announced to Internet: 2718222148 Equivalent to 162 /8s, 4 /16s and 199 /24s Percentage of available address space announced: 73.4 Percentage of allocated address space announced: 73.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.0 Total number of prefixes smaller than registry allocations: 177212 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 129011 Total APNIC prefixes after maximum aggregation: 37668 APNIC Deaggregation factor: 3.42 Prefixes being announced from the APNIC address blocks: 133863 Unique aggregates announced from the APNIC address blocks: 54835 APNIC Region origin ASes present in the Internet Routing Table: 5007 APNIC Prefixes per ASN: 26.74 APNIC Region origin ASes announcing only one prefix: 1211 APNIC Region transit ASes present in the Internet Routing Table: 864 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 100 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1229 Number of APNIC addresses announced to Internet: 740474432 Equivalent to 44 /8s, 34 /16s and 190 /24s Percentage of available APNIC address space announced: 86.5 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: 174104 Total ARIN prefixes after maximum aggregation: 86239 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 175987 Unique aggregates announced from the ARIN address blocks: 82335 ARIN Region origin ASes present in the Internet Routing Table: 16407 ARIN Prefixes per ASN: 10.73 ARIN Region origin ASes announcing only one prefix: 6062 ARIN Region transit ASes present in the Internet Routing Table: 1712 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 304 Number of ARIN addresses announced to Internet: 1055216640 Equivalent to 62 /8s, 229 /16s and 84 /24s Percentage of available ARIN address space announced: 55.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 126324 Total RIPE prefixes after maximum aggregation: 63838 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 132358 Unique aggregates announced from the RIPE address blocks: 82961 RIPE Region origin ASes present in the Internet Routing Table: 17833 RIPE Prefixes per ASN: 7.42 RIPE Region origin ASes announcing only one prefix: 8168 RIPE Region transit ASes present in the Internet Routing Table: 2926 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3308 Number of RIPE addresses announced to Internet: 692283268 Equivalent to 41 /8s, 67 /16s and 103 /24s Percentage of available RIPE address space announced: 100.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59207 Total LACNIC prefixes after maximum aggregation: 10930 LACNIC Deaggregation factor: 5.42 Prefixes being announced from the LACNIC address blocks: 68225 Unique aggregates announced from the LACNIC address blocks: 31110 LACNIC Region origin ASes present in the Internet Routing Table: 2397 LACNIC Prefixes per ASN: 28.46 LACNIC Region origin ASes announcing only one prefix: 640 LACNIC Region transit ASes present in the Internet Routing Table: 478 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1449 Number of LACNIC addresses announced to Internet: 167563136 Equivalent to 9 /8s, 252 /16s and 207 /24s Percentage of available LACNIC address space announced: 99.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: 12515 Total AfriNIC prefixes after maximum aggregation: 2966 AfriNIC Deaggregation factor: 4.22 Prefixes being announced from the AfriNIC address blocks: 13460 Unique aggregates announced from the AfriNIC address blocks: 4935 AfriNIC Region origin ASes present in the Internet Routing Table: 730 AfriNIC Prefixes per ASN: 18.44 AfriNIC Region origin ASes announcing only one prefix: 203 AfriNIC Region transit ASes present in the Internet Routing Table: 151 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: 81 Number of AfriNIC addresses announced to Internet: 60850176 Equivalent to 3 /8s, 160 /16s and 128 /24s Percentage of available AfriNIC address space announced: 60.4 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 2894 11579 923 Korea Telecom 17974 2822 904 77 PT Telekomunikasi Indonesia 7545 2490 336 128 TPG Telecom Limited 4755 1926 418 190 TATA Communications formerly 4538 1759 4190 71 China Education and Research 9829 1658 1319 45 National Internet Backbone 9808 1511 6719 19 Guangdong Mobile Communicatio 4808 1452 2211 431 CNCGROUP IP network China169 9583 1315 106 537 Sify Limited 9498 1300 336 97 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 2918 2955 141 Cox Communications Inc. 6389 2877 3688 51 BellSouth.net Inc. 3356 2552 10700 473 Level 3 Communications, Inc. 18566 2042 379 183 MegaPath Corporation 20115 1855 1825 445 Charter Communications 4323 1636 1054 409 tw telecom holdings, inc. 6983 1624 867 245 EarthLink, Inc. 30036 1510 311 579 Mediacom Communications Corp 701 1412 11262 696 MCI Communications Services, 22561 1317 411 244 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 1921 299 354 TELLCOM ILETISIM HIZMETLERI A 20940 1527 593 1128 Akamai International B.V. 8402 1436 544 15 OJSC "Vimpelcom" 31148 1037 45 21 Freenet Ltd. 13188 1036 97 54 TOV "Bank-Inform" 8551 903 373 48 Bezeq International-Ltd 9198 838 349 26 JSC Kazakhtelecom 6830 820 2339 441 Liberty Global Operations B.V 12479 817 794 85 France Telecom Espana SA 9121 599 1693 22 Turk Telekomunikasyon Anonim 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 3062 497 234 Telmex Colombia S.A. 28573 2314 2120 123 NET Servi�os de Comunica��o S 6147 1801 374 30 Telefonica del Peru S.A.A. 7303 1771 1172 237 Telecom Argentina S.A. 8151 1479 3025 430 Uninet S.A. de C.V. 6503 1229 433 58 Axtel, S.A.B. de C.V. 7738 1000 1882 42 Telemar Norte Leste S.A. 26615 930 2325 35 Tim Celular S.A. 3816 911 396 148 COLOMBIA TELECOMUNICACIONES S 27947 889 129 50 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1469 958 13 TE-AS 24863 953 284 26 Link Egypt (Link.NET) 36903 456 230 95 Office National des Postes et 36992 394 847 23 ETISALAT MISR 37492 347 145 64 Orange Tunisie 24835 308 144 9 Vodafone Data 3741 250 921 213 Internet Solutions 29571 234 21 12 Cote d'Ivoire Telecom 37457 198 160 4 Telkom SA Ltd. 36947 194 807 13 Telecom Algeria 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 3062 497 234 Telmex Colombia S.A. 22773 2918 2955 141 Cox Communications Inc. 4766 2894 11579 923 Korea Telecom 6389 2877 3688 51 BellSouth.net Inc. 17974 2822 904 77 PT Telekomunikasi Indonesia 3356 2552 10700 473 Level 3 Communications, Inc. 7545 2490 336 128 TPG Telecom Limited 28573 2314 2120 123 NET Servi�os de Comunica��o S 18566 2042 379 183 MegaPath Corporation 4755 1926 418 190 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2877 2826 BellSouth.net Inc. 22773 2918 2777 Cox Communications Inc. 17974 2822 2745 PT Telekomunikasi Indonesia 7545 2490 2362 TPG Telecom Limited 28573 2314 2191 NET Servi�os de Comunica��o S 3356 2552 2079 Level 3 Communications, Inc. 4766 2894 1971 Korea Telecom 18566 2042 1859 MegaPath Corporation 6147 1801 1771 Telefonica del Peru S.A.A. 4755 1926 1736 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:31 /11:92 /12:265 /13:502 /14:1000 /15:1729 /16:13039 /17:7176 /18:11993 /19:25003 /20:35618 /21:38148 /22:56402 /23:48993 /24:281326 /25:1094 /26:1089 /27:686 /28:17 /29:18 /30:10 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2133 2918 Cox Communications Inc. 18566 1997 2042 MegaPath Corporation 6389 1666 2877 BellSouth.net Inc. 30036 1356 1510 Mediacom Communications Corp 6147 1345 1801 Telefonica del Peru S.A.A. 6983 1311 1624 EarthLink, Inc. 34984 1229 1921 TELLCOM ILETISIM HIZMETLERI A 11492 1116 1175 CABLE ONE, INC. 8402 1099 1436 OJSC "Vimpelcom" 10620 1086 3062 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1414 2:671 3:3 4:95 5:1213 6:21 8:1398 11:1 12:1835 13:4 14:1210 15:17 16:2 17:45 18:21 20:51 23:1059 24:1661 27:1838 31:1467 32:39 33:2 34:5 35:1 36:146 37:1861 38:970 39:13 40:226 41:2972 42:287 43:817 44:21 45:84 46:2126 47:32 49:778 50:792 52:12 54:60 55:8 56:8 57:31 58:1092 59:659 60:450 61:1720 62:1314 63:1887 64:4401 65:2258 66:4070 67:2013 68:1044 69:3238 70:904 71:428 72:1959 74:2600 75:324 76:410 77:1353 78:1045 79:786 80:1324 81:1293 82:811 83:682 84:675 85:1325 86:431 87:1218 88:516 89:1840 90:139 91:5850 92:797 93:1682 94:1985 95:1400 96:421 97:338 98:1044 99:48 100:69 101:788 103:6369 104:899 105:187 106:194 107:890 108:612 109:2055 110:1051 111:1446 112:731 113:897 114:802 115:1236 116:1287 117:1022 118:1666 119:1366 120:430 121:994 122:2196 123:1707 124:1466 125:1521 128:642 129:360 130:382 131:1072 132:440 133:167 134:388 135:87 136:329 137:298 138:383 139:173 140:224 141:418 142:621 143:437 144:507 145:111 146:683 147:563 148:1063 149:407 150:532 151:586 152:470 153:247 154:292 155:659 156:390 157:333 158:264 159:960 160:368 161:629 162:1858 163:371 164:649 165:671 166:320 167:708 168:1165 169:132 170:1426 171:221 172:50 173:1575 174:702 175:595 176:1563 177:3703 178:2104 179:812 180:1838 181:1687 182:1688 183:530 184:727 185:2581 186:2952 187:1689 188:2010 189:1549 190:7885 191:848 192:7955 193:5561 194:4064 195:3627 196:1683 197:873 198:5400 199:5499 200:6520 201:2945 202:9453 203:8998 204:4661 205:2708 206:2991 207:2969 208:3903 209:3846 210:3477 211:1836 212:2542 213:2248 214:830 215:73 216:5541 217:1760 218:649 219:466 220:1301 221:776 222:458 223:647 End of report From cidr-report at potaroo.net Fri Dec 26 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Dec 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201412262200.sBQM00QY075120@wattle.apnic.net> This report has been generated at Fri Dec 26 21:14:48 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 19-12-14 529745 292796 20-12-14 529795 292693 21-12-14 529756 292947 22-12-14 530026 293073 23-12-14 529733 293155 24-12-14 529579 293380 25-12-14 529736 293407 26-12-14 529668 293513 AS Summary 49205 Number of ASes in routing system 19720 Number of ASes announcing only one prefix 3062 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120338432 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'). --- 26Dec14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 529740 293520 236220 44.6% All ASes AS6389 2877 100 2777 96.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2920 172 2748 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2822 77 2745 97.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS28573 2317 306 2011 86.8% NET Servi�os de Comunica��o S.A.,BR AS3356 2619 791 1828 69.8% LEVEL3 - Level 3 Communications, Inc.,US AS6147 1800 170 1630 90.6% Telefonica del Peru S.A.A.,PE AS4766 2894 1287 1607 55.5% KIXS-AS-KR Korea Telecom,KR AS4755 1925 338 1587 82.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7303 1775 291 1484 83.6% Telecom Argentina S.A.,AR AS10620 3062 1589 1473 48.1% Telmex Colombia S.A.,CO AS9808 1510 56 1454 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1422 27 1395 98.1% CORBINA-AS OJSC "Vimpelcom",RU AS20115 1856 527 1329 71.6% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2504 1260 1244 49.7% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1642 411 1231 75.0% TWTC - tw telecom holdings, inc.,US AS9498 1300 113 1187 91.3% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2041 868 1173 57.5% MEGAPATH5-US - MegaPath Corporation,US AS6983 1624 500 1124 69.2% ITCDELTA - Earthlink, Inc.,US AS7552 1112 54 1058 95.1% VIETEL-AS-AP Viettel Corporation,VN AS34984 1922 864 1058 55.0% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1317 354 963 73.1% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 113 870 88.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS31148 1045 190 855 81.8% FREENET-AS Freenet Ltd.,UA AS4538 1776 931 845 47.6% ERX-CERNET-BKB China Education and Research Network Center,CN AS8151 1489 682 807 54.2% Uninet S.A. de C.V.,MX AS24560 1177 372 805 68.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS26615 931 141 790 84.9% Tim Celular S.A.,BR AS4780 1062 294 768 72.3% SEEDNET Digital United Inc.,TW AS18101 954 194 760 79.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN Total 53678 13156 40522 75.5% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 43.245.196.0/24 AS36352 AS-COLOCROSSING - ColoCrossing,US 43.245.197.0/24 AS55286 SERVER-MANIA - B2 Net Solutions Inc.,US 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 64.247.224.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 69.2.64.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 69.172.0.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 72.12.0.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 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.220.84.0/24 AS5577 ROOT root SA,LU 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 102.193.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 103.1.155.0/24 AS55799 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.124.0/24 AS45355 DIGICELPACIFIC-1-AP Clarendon House,FJ 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 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 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 151.216.128.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM",RU 151.216.192.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM",RU 154.171.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 154.197.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.211.192.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 186.65.108.0/22 AS22927 Telefonica de Argentina,AR 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.52.0/23 AS14455 SUNGARD-RECOVERY - Sungard Network Solutions, Inc.,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS3322 -Reserved AS-,ZZ 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.75.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.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 208.115.0.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 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.159.32.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.83.224.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 216.107.64.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.219.0.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 216.231.96.0/19 AS7029 WINDSTREAM - Windstream Communications 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 Dec 26 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Dec 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201412262200.sBQM0216075137@wattle.apnic.net> BGP Update Report Interval: 18-Dec-14 -to- 25-Dec-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 285221 6.6% 2396.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS13105 221252 5.1% 14750.1 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 3 - AS9829 209788 4.8% 186.5 -- BSNL-NIB National Internet Backbone,IN 4 - AS8888 138139 3.2% 12558.1 -- RUSERVICE-LLC-AS LLC RU-service,RU 5 - AS53249 79760 1.8% 39880.0 -- LAWA-AS - Los Angeles World Airport,US 6 - AS36947 70946 1.6% 375.4 -- ALGTEL-AS,DZ 7 - AS23966 44701 1.0% 148.5 -- LDN-AS-PK LINKdotNET Telecom Limited,PK 8 - AS3 42707 1.0% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 9 - AS1659 37890 0.9% 411.8 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 10 - AS51964 35764 0.8% 209.1 -- ORANGE-BUSINESS-SERVICES-IPSN-ASN Equant Inc.,FR 11 - AS3816 34487 0.8% 72.3 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 12 - AS60725 32463 0.8% 8115.8 -- O3B-AS O3b Limited,JE 13 - AS9583 31705 0.7% 24.8 -- SIFY-AS-IN Sify Limited,IN 14 - AS45899 27702 0.6% 65.2 -- VNPT-AS-VN VNPT Corp,VN 15 - AS48159 27145 0.6% 90.8 -- TIC-AS Telecommunication Infrastructure Company,IR 16 - AS28642 26402 0.6% 754.3 -- Contato Internet Ltda EPP,BR 17 - AS65001 25674 0.6% 4279.0 -- -Private Use AS-,ZZ 18 - AS14840 23700 0.6% 718.2 -- COMMCORP COMUNICACOES LTDA,BR 19 - AS8402 21722 0.5% 76.2 -- CORBINA-AS OJSC "Vimpelcom",RU 20 - AS11054 20884 0.5% 870.2 -- LIVEPERSON - LivePerson, Inc.,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3 42707 1.0% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 2 - AS53249 79760 1.8% 39880.0 -- LAWA-AS - Los Angeles World Airport,US 3 - AS61039 16545 0.4% 16545.0 -- ZMZ OAO ZMZ,RU 4 - AS13105 221252 5.1% 14750.1 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 5 - AS8888 138139 3.2% 12558.1 -- RUSERVICE-LLC-AS LLC RU-service,RU 6 - AS18135 10104 0.2% 10104.0 -- BTV BTV Cable television,JP 7 - AS25003 20154 0.5% 10077.0 -- INTERNET_BINAT Internet Binat Ltd,IL 8 - AS60725 32463 0.8% 8115.8 -- O3B-AS O3b Limited,JE 9 - AS62174 5329 0.1% 5329.0 -- INTERPAN-AS INTERPAN LTD.,BG 10 - AS47364 5263 0.1% 5263.0 -- PLANSEE-AS Plansee Group Service GmbH,AT 11 - AS33721 4321 0.1% 4321.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 12 - AS65001 25674 0.6% 4279.0 -- -Private Use AS-,ZZ 13 - AS60737 7227 0.2% 3613.5 -- NEURONESIT NEURONESIT,FR 14 - AS29152 6471 0.1% 3235.5 -- DECKNET-AS DECKNET,FR 15 - AS31860 2772 0.1% 2772.0 -- MACKAY-SHIELDS - MacKay Shields LLC,US 16 - AS58252 2624 0.1% 2624.0 -- ASN-RINGLOUD Netuity Limited,GB 17 - AS23752 285221 6.6% 2396.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 18 - AS30114 2275 0.1% 2275.0 -- TRANSCOM-ES - Transcom Enhanced Services, LLC,US 19 - AS58032 2147 0.1% 2147.0 -- FORTUNAT-AS Private Join Stock Company "FORTUNAT",UA 20 - AS47680 9926 0.2% 1985.2 -- NHCS EOBO Limited,IE TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 143244 3.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 140087 3.1% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 212.22.80.0/24 69118 1.5% AS8888 -- RUSERVICE-LLC-AS LLC RU-service,RU 4 - 212.22.94.0/24 68995 1.5% AS8888 -- RUSERVICE-LLC-AS LLC RU-service,RU 5 - 41.221.20.0/24 65717 1.4% AS36947 -- ALGTEL-AS,DZ 6 - 82.118.158.0/23 45162 1.0% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 7 - 82.118.146.0/23 44764 1.0% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 8 - 95.171.242.0/23 44080 1.0% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 9 - 95.171.242.0/24 43615 1.0% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 10 - 95.171.236.0/23 43560 1.0% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 11 - 130.0.192.0/21 42707 0.9% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 12 - 198.140.114.0/24 39900 0.9% AS53249 -- LAWA-AS - Los Angeles World Airport,US 13 - 198.140.115.0/24 39860 0.9% AS53249 -- LAWA-AS - Los Angeles World Airport,US 14 - 182.50.246.0/24 29019 0.6% AS45786 -- HTSNET-AS-ID HTSNET - ISP,ID AS65001 -- -Private Use AS-,ZZ 15 - 192.115.44.0/22 20153 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 16 - 64.29.130.0/24 19608 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 17 - 91.235.169.0/24 16545 0.4% AS61039 -- ZMZ OAO ZMZ,RU 18 - 185.26.155.0/24 16440 0.4% AS60725 -- O3B-AS O3b Limited,JE 19 - 162.249.183.0/24 15964 0.3% AS60725 -- O3B-AS O3b Limited,JE 20 - 192.58.232.0/24 10692 0.2% AS6629 -- NOAA-AS - NOAA,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From youssef at 720.fr Fri Dec 26 22:48:59 2014 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Fri, 26 Dec 2014 23:48:59 +0100 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact Message-ID: Hello, If someone from IAM peering team is watching, could he please get in touch OFF-list please ? Best regards. -- Youssef BENGELLOUN-ZAHR From clayton at mnsi.net Fri Dec 26 23:46:45 2014 From: clayton at mnsi.net (Clayton Zekelman) Date: Fri, 26 Dec 2014 18:46:45 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: References: Message-ID: What if the peering team member is a she? Should she not contact you if so? Sent from my iPhone > On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr wrote: > > Hello, > > If someone from IAM peering team is watching, could he please get in touch > OFF-list please ? > > Best regards. > > -- > Youssef BENGELLOUN-ZAHR From c at starbs.net Sat Dec 27 02:57:09 2014 From: c at starbs.net (Michael Banks) Date: Sat, 27 Dec 2014 02:57:09 +0000 Subject: Cloudflare NOC Contact Message-ID: <549E2005.6090801@starbs.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looking for a contact at Cloudflare, ideally a direct number. Their public facing number doesn't appear to be doing any good. We have some issues with NSs flapping back and forth. We'll need a reconcile to attempt to sort it out. Cheers - -- Michael 'Chip' Banks, DevOps Engineer +44 (0) 800 808 5666 / hi at itschip.com https://itschip.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUniABAAoJECmtHuzK0gIXdrIH/RW6p+v7twJ9NrF72mM+fV+Q UlSVZV2ySRbO+/ND7vpAyME40ASi6IfTi8VLWM3Lf21u7THkQolDBIzjGBYfQrjG bWXb77Opwpv54djTbiz8WvFaAY5Bp66WhD2WbCAp5cN7q1yiH52gOMpY6hxcst7T WF6Ll2UBPIrUKBcGlSO6qeFiRAAfjhdgfeFGrcStdKIJVXmyOTSKAlHGPQBWtHSM NyTp2iQOb/6cuUrxZo2UVTbSFE4AKEK4pEcp2uH4sBFVScoF9H08T0igPEa5Oco6 WbkzmmYOOyIh4niUfzS/fTUKW/r8Y47/cihgu1z4CkGgycZTtWklk6Sq+0nbwX4= =6H5h -----END PGP SIGNATURE----- From anders at abundo.se Sat Dec 27 16:15:13 2014 From: anders at abundo.se (=?UTF-8?B?QW5kZXJzIEzDtndpbmdlcg==?=) Date: Sat, 27 Dec 2014 17:15:13 +0100 Subject: Estonian IPv6 deployment report In-Reply-To: <54983844.8010007@lanparty.ee> References: <54983844.8010007@lanparty.ee> Message-ID: <549EDB11.2040807@abundo.se> On 2014-12-22 16:27, Tarko Tikan wrote: > Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is > deployed in shared service vlans. IPv6 traffic shares vlan with IPv4. How do you protect customers from each other? There are many nasty IPv6 attacks you can do when on a shared VLAN. /Anders From tarko at lanparty.ee Sat Dec 27 16:27:08 2014 From: tarko at lanparty.ee (Tarko Tikan) Date: Sat, 27 Dec 2014 18:27:08 +0200 Subject: Estonian IPv6 deployment report In-Reply-To: <549EDB11.2040807@abundo.se> References: <54983844.8010007@lanparty.ee> <549EDB11.2040807@abundo.se> Message-ID: <549EDDDC.9090609@lanparty.ee> hey, > How do you protect customers from each other? > > There are many nasty IPv6 attacks you can do when on a shared VLAN. Split-horizon (switchport protected in Cisco world). Customers can't send packets directly to each other, all communication has to go via BNG router. Obviously we protect L2 as well like limiting number of MACs per customers, make sure BNG MAC cannot be learned from customer ports etc. We don't use any L3 (both v4 and v6) inspection in ANs, everything happens in BNG. It's actually much better and logical for v6 as it is for v4. In v4 world you have to implement proxy-arp, in v6 world there is no need for customers to send packets to each others link-local WAN addresses and packets sent to PD addresses are by default routed via BNG. -- tarko From erey at ernw.de Sat Dec 27 16:37:33 2014 From: erey at ernw.de (Enno Rey) Date: Sat, 27 Dec 2014 17:37:33 +0100 Subject: Estonian IPv6 deployment report In-Reply-To: <549EDB11.2040807@abundo.se> References: <54983844.8010007@lanparty.ee> <549EDB11.2040807@abundo.se> Message-ID: <20141227163733.GI33692@ernw.de> Hi, On Sat, Dec 27, 2014 at 05:15:13PM +0100, Anders L??winger wrote: > On 2014-12-22 16:27, Tarko Tikan wrote: > > > Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is > > deployed in shared service vlans. IPv6 traffic shares vlan with IPv4. > > How do you protect customers from each other? > > There are many nasty IPv6 attacks you can do when on a shared VLAN. true, but some (most) of them only apply in networks where multicasting/ND is fully supported which is not necessarily the case in the above type of networks. and, from what I understand, in their scenario RAs are not sent to link-local scope all nodes (ff02::1), so that would eliminate another attack vector (depending on the actual processing of RAs on the CPEs). best Enno > > /Anders > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From bedard.phil at gmail.com Sat Dec 27 16:41:55 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Sat, 27 Dec 2014 11:41:55 -0500 Subject: Estonian IPv6 deployment report In-Reply-To: <549EDB11.2040807@abundo.se> References: <54983844.8010007@lanparty.ee> <549EDB11.2040807@abundo.se> Message-ID: <549ee15e.aa5c8c0a.237e.242a@mx.google.com> The access boxes and BNG typically have protection mechanisms in place. Also even though customers are in a shared VLAN and IP subnet they aren't typically on the same broadcast domain. In the case of active Ethernet you use things like private Vlans or other access controls. Phil -----Original Message----- From: "Anders Löwinger" Sent: ‎12/‎27/‎2014 11:17 AM To: "nanog at nanog.org" Subject: Re: Estonian IPv6 deployment report On 2014-12-22 16:27, Tarko Tikan wrote: > Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is > deployed in shared service vlans. IPv6 traffic shares vlan with IPv4. How do you protect customers from each other? There are many nasty IPv6 attacks you can do when on a shared VLAN. /Anders From nanog at ics-il.net Sat Dec 27 18:00:10 2014 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 27 Dec 2014 12:00:10 -0600 (CST) Subject: Shapefiles, KMZs, etc. In-Reply-To: <26026337.7570.1419703209245.JavaMail.mhammett@ThunderFuck> Message-ID: <4595644.7574.1419703212068.JavaMail.mhammett@ThunderFuck> I am looking for shapefiles, KMZs, etc. for networks primarily in the Midwest, but really throughout the area that is the scope of this list. I am a small ISP that just happens to know more than your average ISP about where people are and how to use GIS tools. I use them to help other ISPs find transport and they may come in handy for some start-up IX work I'm involved with. They would not go public and I would be willing to sign NDAs to get them. I have gotten several form public sources, but I may not have gotten all of the public ones and I have some (but still only a few) private ones. Thank you. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From javier at advancedmachines.us Sat Dec 27 18:47:58 2014 From: javier at advancedmachines.us (Javier J) Date: Sat, 27 Dec 2014 13:47:58 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: References: Message-ID: What if they don't identify as a he or a she? On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman wrote: > What if the peering team member is a she? Should she not contact you if > so? > > Sent from my iPhone > > > On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr > wrote: > > > > Hello, > > > > If someone from IAM peering team is watching, could he please get in > touch > > OFF-list please ? > > > > Best regards. > > > > -- > > Youssef BENGELLOUN-ZAHR > From javier at advancedmachines.us Sat Dec 27 18:49:22 2014 From: javier at advancedmachines.us (Javier J) Date: Sat, 27 Dec 2014 13:49:22 -0500 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: <102a60f842e16c4f9c4c971c4a02ae2c@mail.dessus.com> References: <102a60f842e16c4f9c4c971c4a02ae2c@mail.dessus.com> Message-ID: Looks like it is still going on. you can make this stuff up: ""Obama always goes reckless in words and deeds like a monkey in a tropical forest,"" http://arstechnica.com/tech-policy/2014/12/north-korea-suffers-another-internet-outage-hurls-racial-slur-at-pres-obama/ On Wed, Dec 24, 2014 at 6:26 PM, Keith Medcalf wrote: > >> What would be the point in blocking them? They don't even have > >> electricity in the country, what would I worry about coming out > >> of their IP block that wouldn't be more interesting than dangerous. > >> Pretty obvious if it was really them behind the Sony hack, it > >> was outsourced. > > >For the few elite that do have Internet in DPRK it would be 1) a big > >inconvenience which would annoy them a lot and 2) they have to transmit > >what they want attacked to the outsourced crew (whoever they might be) > >somehow. I doubt the outsourced group has a fax#. > > I am pretty sure that they have fax machines in Washington Dee Cee. > > --- > Theory is when you know everything but nothing works. Practice is when > everything works but no one knows why. Sometimes theory and practice are > combined: nothing works and no one knows why. > > > > > > From clayton at mnsi.net Sat Dec 27 19:35:03 2014 From: clayton at mnsi.net (Clayton Zekelman) Date: Sat, 27 Dec 2014 14:35:03 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: References: Message-ID: That is why the better pronoun choice would have been 'you', not 'he' or 'she'. Sent from my iPhone > On Dec 27, 2014, at 1:47 PM, Javier J wrote: > > What if they don't identify as a he or a she? > >> On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman wrote: >> What if the peering team member is a she? Should she not contact you if so? >> >> Sent from my iPhone >> >> > On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr wrote: >> > >> > Hello, >> > >> > If someone from IAM peering team is watching, could he please get in touch >> > OFF-list please ? >> > >> > Best regards. >> > >> > -- >> > Youssef BENGELLOUN-ZAHR > From fw at deneb.enyo.de Sat Dec 27 20:48:01 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 27 Dec 2014 21:48:01 +0100 Subject: Anyone from Cloudflare ? (IPv6 issue) References: <04D5A773-DCED-4BE2-B614-2987A5D13BE6@burn.net> Message-ID: <87oaqo95vi.fsf@mid.deneb.enyo.de> * Brandon Applegate: > Otherwise - if anyone could share a way to get to clue @Cloudflare I > would greatly appreciate it. I put a request in through the web > support front door, but I got back about what I expected. Did you receive a reply? I tried to notify security@ about some issue, but never heard back from them. From baconzombie at gmail.com Sat Dec 27 21:12:49 2014 From: baconzombie at gmail.com (Bacon Zombie) Date: Sat, 27 Dec 2014 22:12:49 +0100 Subject: North Korean internet goes dark (yes, they had one) In-Reply-To: References: <102a60f842e16c4f9c4c971c4a02ae2c@mail.dessus.com> Message-ID: CCC would not do anything pro-NK. On 27 December 2014 at 19:49, Javier J wrote: > Looks like it is still going on. > > you can make this stuff up: > > ""Obama always goes reckless in words and deeds like a monkey in a tropical > forest,"" > > > http://arstechnica.com/tech-policy/2014/12/north-korea-suffers-another-internet-outage-hurls-racial-slur-at-pres-obama/ > > On Wed, Dec 24, 2014 at 6:26 PM, Keith Medcalf > wrote: > > > >> What would be the point in blocking them? They don't even have > > >> electricity in the country, what would I worry about coming out > > >> of their IP block that wouldn't be more interesting than dangerous. > > >> Pretty obvious if it was really them behind the Sony hack, it > > >> was outsourced. > > > > >For the few elite that do have Internet in DPRK it would be 1) a big > > >inconvenience which would annoy them a lot and 2) they have to transmit > > >what they want attacked to the outsourced crew (whoever they might be) > > >somehow. I doubt the outsourced group has a fax#. > > > > I am pretty sure that they have fax machines in Washington Dee Cee. > > > > --- > > Theory is when you know everything but nothing works. Practice is when > > everything works but no one knows why. Sometimes theory and practice are > > combined: nothing works and no one knows why. > > > > > > > > > > > > > -- BaconZombie 55:55:44:44:4C:52:4C:52:42:41 LOAD "*",8,1 From bzs at world.std.com Sat Dec 27 21:20:41 2014 From: bzs at world.std.com (Barry Shein) Date: Sat, 27 Dec 2014 16:20:41 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: References: Message-ID: <21663.8873.620908.943963@world.std.com> May I share some clue? The OP is probably not a native speaker of English. You don't play PC language games with people who you aren't *certain* are native speakers of English. Why? Because if you do I will show up at your door! I dunno, just don't do it, it's rude and stupid, imagine if you were trying to post in your college Arabic or French or whatever and got hit with subtleties like this instead of a simple answer. -b On December 27, 2014 at 14:35 clayton at mnsi.net (Clayton Zekelman) wrote: > > That is why the better pronoun choice would have been 'you', not 'he' or 'she'. > > Sent from my iPhone > > > On Dec 27, 2014, at 1:47 PM, Javier J wrote: > > > > What if they don't identify as a he or a she? > > > >> On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman wrote: > >> What if the peering team member is a she? Should she not contact you if so? > >> > >> Sent from my iPhone > >> > >> > On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr wrote: > >> > > >> > Hello, > >> > > >> > If someone from IAM peering team is watching, could he please get in touch > >> > OFF-list please ? > >> > > >> > Best regards. > >> > > >> > -- > >> > Youssef BENGELLOUN-ZAHR > > From youssef at 720.fr Sat Dec 27 21:36:17 2014 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Sat, 27 Dec 2014 22:36:17 +0100 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: <21663.8873.620908.943963@world.std.com> References: <21663.8873.620908.943963@world.std.com> Message-ID: Hello, Let me (the OP) put an end to this : - I'm certainly not a native english speaker, but my english level is good enough to make myself clear / understandable. @Barry : No offense taken ;-) - Maybe this he/she false debate all started with an "honnest/innocent" mistake. I do not care about / pay attention / give importance about the gender of my fellow estimed networking pairs. @Clayton : Really, all I've asked for when I sent the initial email was a peering contact. Nothing more, nothing less. PERIOD ;-) Now that AS6713 has been publitized (more than they haven't asked for), maybe someone overthere will finally ping back ! After all, it's Xmas, you never know what santa can bring along with him. Wish you all a happy holiday season. Best regards. > Le 27 déc. 2014 à 22:20, Barry Shein a écrit : > > > May I share some clue? > > The OP is probably not a native speaker of English. > > You don't play PC language games with people who you aren't *certain* > are native speakers of English. > > Why? Because if you do I will show up at your door! > > I dunno, just don't do it, it's rude and stupid, imagine if you were > trying to post in your college Arabic or French or whatever and got > hit with subtleties like this instead of a simple answer. > > -b > > >> On December 27, 2014 at 14:35 clayton at mnsi.net (Clayton Zekelman) wrote: >> >> That is why the better pronoun choice would have been 'you', not 'he' or 'she'. >> >> Sent from my iPhone >> >>> On Dec 27, 2014, at 1:47 PM, Javier J wrote: >>> >>> What if they don't identify as a he or a she? >>> >>>> On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman wrote: >>>> What if the peering team member is a she? Should she not contact you if so? >>>> >>>> Sent from my iPhone >>>> >>>>> On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr wrote: >>>>> >>>>> Hello, >>>>> >>>>> If someone from IAM peering team is watching, could he please get in touch >>>>> OFF-list please ? >>>>> >>>>> Best regards. >>>>> >>>>> -- >>>>> Youssef BENGELLOUN-ZAHR >>> From clayton at mnsi.net Sat Dec 27 21:41:34 2014 From: clayton at mnsi.net (Clayton Zekelman) Date: Sat, 27 Dec 2014 16:41:34 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: <21663.8873.620908.943963@world.std.com> References: <21663.8873.620908.943963@world.std.com> Message-ID: Can I share a clue with you? This is a North American English language list. Threatening to show up at someone's door is a pretty douchebag way to make a point. What next? A rumble in the school parking lot at 3:45? The person who taught me about BGP in 1995 worked for a large international carrier at the time, and told me the story of how network technicians in the Middle East would refuse to talk to HER because she couldn't possibly know what SHE was talking about. That story of sexism has stuck with me since then. If it was a language mistake, then I educated the OP on the reason to use the right pronoun. If it was sexism, then I called him out on his bullshit. Either way Barry, if you want to come to my door, be my guest, but it will be at that moment you realize what a huge mistake you made. Sent from my iPhone > On Dec 27, 2014, at 4:20 PM, Barry Shein wrote: > > > May I share some clue? > > The OP is probably not a native speaker of English. > > You don't play PC language games with people who you aren't *certain* > are native speakers of English. > > Why? Because if you do I will show up at your door! > > I dunno, just don't do it, it's rude and stupid, imagine if you were > trying to post in your college Arabic or French or whatever and got > hit with subtleties like this instead of a simple answer. > > -b > > >> On December 27, 2014 at 14:35 clayton at mnsi.net (Clayton Zekelman) wrote: >> >> That is why the better pronoun choice would have been 'you', not 'he' or 'she'. >> >> Sent from my iPhone >> >>> On Dec 27, 2014, at 1:47 PM, Javier J wrote: >>> >>> What if they don't identify as a he or a she? >>> >>>> On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman wrote: >>>> What if the peering team member is a she? Should she not contact you if so? >>>> >>>> Sent from my iPhone >>>> >>>>> On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr wrote: >>>>> >>>>> Hello, >>>>> >>>>> If someone from IAM peering team is watching, could he please get in touch >>>>> OFF-list please ? >>>>> >>>>> Best regards. >>>>> >>>>> -- >>>>> Youssef BENGELLOUN-ZAHR >>> From bill at herrin.us Sat Dec 27 21:47:04 2014 From: bill at herrin.us (William Herrin) Date: Sat, 27 Dec 2014 16:47:04 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: References: Message-ID: On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman wrote: > What if the peering team member is a she? Then it's probably a good thing that the English language has no gender-neutral third person singular pronoun appropriate for referencing a human being. Conventionally, the otherwise male pronoun "he" is used to refer to any individual whose gender is not known to the speaker. It offers no insult unless the recipient is looking for an excuse. The "what if he's a she" crack was stale when I was still in diapers and the pedantic follow on discussion about what the gender neutral pronoun should be is just as tedious. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From Grzegorz at Janoszka.pl Sat Dec 27 21:52:35 2014 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Sat, 27 Dec 2014 22:52:35 +0100 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: References: Message-ID: <549F2A23.1010900@Janoszka.pl> Isn't it better actually to use they? https://en.wikipedia.org/wiki/Singular_they -- Grzegorz Janoszka On 2014-12-27 20:35, Clayton Zekelman wrote: > > That is why the better pronoun choice would have been 'you', not 'he' or 'she'. > > Sent from my iPhone > >> On Dec 27, 2014, at 1:47 PM, Javier J wrote: >> >> What if they don't identify as a he or a she? >> >>> On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman wrote: >>> What if the peering team member is a she? Should she not contact you if so? >>> >>> Sent from my iPhone >>> >>>> On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr wrote: >>>> >>>> Hello, >>>> >>>> If someone from IAM peering team is watching, could he please get in touch >>>> OFF-list please ? >>>> >>>> Best regards. >>>> >>>> -- >>>> Youssef BENGELLOUN-ZAHR >> From josh at imaginenetworksllc.com Sat Dec 27 21:53:39 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sat, 27 Dec 2014 16:53:39 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: <549F2A23.1010900@Janoszka.pl> References: <549F2A23.1010900@Janoszka.pl> Message-ID: Just drop it guys...please? :) Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Dec 27, 2014 4:52 PM, "Grzegorz Janoszka" wrote: > > Isn't it better actually to use they? > > https://en.wikipedia.org/wiki/Singular_they > > -- > Grzegorz Janoszka > > > On 2014-12-27 20:35, Clayton Zekelman wrote: > >> >> That is why the better pronoun choice would have been 'you', not 'he' or >> 'she'. >> >> Sent from my iPhone >> >> On Dec 27, 2014, at 1:47 PM, Javier J >>> wrote: >>> >>> What if they don't identify as a he or a she? >>> >>> On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman >>>> wrote: >>>> What if the peering team member is a she? Should she not contact you >>>> if so? >>>> >>>> Sent from my iPhone >>>> >>>> On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> If someone from IAM peering team is watching, could he please get in >>>>> touch >>>>> OFF-list please ? >>>>> >>>>> Best regards. >>>>> >>>>> -- >>>>> Youssef BENGELLOUN-ZAHR >>>>> >>>> >>> From bill at herrin.us Sat Dec 27 21:54:29 2014 From: bill at herrin.us (William Herrin) Date: Sat, 27 Dec 2014 16:54:29 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: <549F2A23.1010900@Janoszka.pl> References: <549F2A23.1010900@Janoszka.pl> Message-ID: On Sat, Dec 27, 2014 at 4:52 PM, Grzegorz Janoszka wrote: > https://en.wikipedia.org/wiki/Singular_they https://en.wikipedia.org/wiki/Gender-specific_and_gender-neutral_pronouns#Generic_he To whom it may concern, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From akennykant at gmail.com Sat Dec 27 22:54:56 2014 From: akennykant at gmail.com (Kenny Kant) Date: Sat, 27 Dec 2014 16:54:56 -0600 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: References: Message-ID: <88E211D7-5C5C-43CE-A974-6DDED84EB517@gmail.com> Poor form Clayton. This type of response is not helpful or constructive. Kenny Sent from my iPhone > On Dec 26, 2014, at 5:46 PM, Clayton Zekelman wrote: > > What if the peering team member is a she? Should she not contact you if so? > > Sent from my iPhone > >> On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr wrote: >> >> Hello, >> >> If someone from IAM peering team is watching, could he please get in touch >> OFF-list please ? >> >> Best regards. >> >> -- >> Youssef BENGELLOUN-ZAHR From clayton at mnsi.net Sat Dec 27 23:05:06 2014 From: clayton at mnsi.net (Clayton Zekelman) Date: Sat, 27 Dec 2014 18:05:06 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: <549F2A23.1010900@Janoszka.pl> References: <549F2A23.1010900@Janoszka.pl> Message-ID: That would work too! Sent from my iPhone > On Dec 27, 2014, at 4:52 PM, Grzegorz Janoszka wrote: > > > Isn't it better actually to use they? > > https://en.wikipedia.org/wiki/Singular_they > > -- > Grzegorz Janoszka > > >> On 2014-12-27 20:35, Clayton Zekelman wrote: >> >> That is why the better pronoun choice would have been 'you', not 'he' or 'she'. >> >> Sent from my iPhone >> >>> On Dec 27, 2014, at 1:47 PM, Javier J wrote: >>> >>> What if they don't identify as a he or a she? >>> >>>> On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman wrote: >>>> What if the peering team member is a she? Should she not contact you if so? >>>> >>>> Sent from my iPhone >>>> >>>>> On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr wrote: >>>>> >>>>> Hello, >>>>> >>>>> If someone from IAM peering team is watching, could he please get in touch >>>>> OFF-list please ? >>>>> >>>>> Best regards. >>>>> >>>>> -- >>>>> Youssef BENGELLOUN-ZAHR >>> From brandon at burn.net Sun Dec 28 00:34:14 2014 From: brandon at burn.net (Brandon Applegate) Date: Sat, 27 Dec 2014 19:34:14 -0500 Subject: Anyone from Cloudflare ? (IPv6 issue) In-Reply-To: <87oaqo95vi.fsf@mid.deneb.enyo.de> References: <04D5A773-DCED-4BE2-B614-2987A5D13BE6@burn.net> <87oaqo95vi.fsf@mid.deneb.enyo.de> Message-ID: > On Dec 27, 2014, at 3:48 PM, Florian Weimer wrote: > > * Brandon Applegate: > >> Otherwise - if anyone could share a way to get to clue @Cloudflare I >> would greatly appreciate it. I put a request in through the web >> support front door, but I got back about what I expected. > > Did you receive a reply? > > I tried to notify security@ about some issue, but never heard back > from them. I did - I worked with some Cloudflare guys offlist and they made some (hopefully temporary) BGP path tweaks to route around where we think the trouble is buried. So kudos to them. If you want - let me know 1:1 and I can let you know who I worked with, although I’m not sure they are security focused. -------------- 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 darqchild at darqchild.com Sat Dec 27 21:07:46 2014 From: darqchild at darqchild.com (Meagan) Date: Sat, 27 Dec 2014 16:07:46 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: References: Message-ID: Singular They! :D > On Dec 27, 2014, at 2:35 PM, Clayton Zekelman wrote: > > > That is why the better pronoun choice would have been 'you', not 'he' or 'she'. > > Sent from my iPhone > >> On Dec 27, 2014, at 1:47 PM, Javier J wrote: >> >> What if they don't identify as a he or a she? >> >>> On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman wrote: >>> What if the peering team member is a she? Should she not contact you if so? >>> >>> Sent from my iPhone >>> >>>> On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr wrote: >>>> >>>> Hello, >>>> >>>> If someone from IAM peering team is watching, could he please get in touch >>>> OFF-list please ? >>>> >>>> Best regards. >>>> >>>> -- >>>> Youssef BENGELLOUN-ZAHR > > !DSPAM:549f0a5f299111688636950! > From faisal at snappytelecom.net Sun Dec 28 01:50:57 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sun, 28 Dec 2014 01:50:57 +0000 (GMT) Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: References: Message-ID: <528297914.394529.1419731456991.JavaMail.zimbra@snappytelecom.net> How about Queens English ... Oyi ! Or the American Spoken English ... Yo ! or Spanglish... Oyime ? Give it up.... ! next we will be discussing how to write emails in dots and dashes ! :) 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: "Meagan" > To: "Clayton Zekelman" > Cc: nanog at nanog.org > Sent: Saturday, December 27, 2014 4:07:46 PM > Subject: Re: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact > > Singular They! :D > > > On Dec 27, 2014, at 2:35 PM, Clayton Zekelman wrote: > > > > > > That is why the better pronoun choice would have been 'you', not 'he' or > > 'she'. > > > > Sent from my iPhone > > > >> On Dec 27, 2014, at 1:47 PM, Javier J wrote: > >> > >> What if they don't identify as a he or a she? > >> > >>> On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman > >>> wrote: > >>> What if the peering team member is a she? Should she not contact you if > >>> so? > >>> > >>> Sent from my iPhone > >>> > >>>> On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr > >>>> wrote: > >>>> > >>>> Hello, > >>>> > >>>> If someone from IAM peering team is watching, could he please get in > >>>> touch > >>>> OFF-list please ? > >>>> > >>>> Best regards. > >>>> > >>>> -- > >>>> Youssef BENGELLOUN-ZAHR > > > > !DSPAM:549f0a5f299111688636950! > > > From javier at advancedmachines.us Sun Dec 28 02:59:09 2014 From: javier at advancedmachines.us (Javier J) Date: Sat, 27 Dec 2014 21:59:09 -0500 Subject: Shapefiles, KMZs, etc. In-Reply-To: <4595644.7574.1419703212068.JavaMail.mhammett@ThunderFuck> References: <26026337.7570.1419703209245.JavaMail.mhammett@ThunderFuck> <4595644.7574.1419703212068.JavaMail.mhammett@ThunderFuck> Message-ID: If you have KMZ files you have compiled from public sources, can you make them available? This would be very useful to have for project I work on from time to time. On Sat, Dec 27, 2014 at 1:00 PM, Mike Hammett wrote: > I am looking for shapefiles, KMZs, etc. for networks primarily in the > Midwest, but really throughout the area that is the scope of this list. I > am a small ISP that just happens to know more than your average ISP about > where people are and how to use GIS tools. I use them to help other ISPs > find transport and they may come in handy for some start-up IX work I'm > involved with. They would not go public and I would be willing to sign NDAs > to get them. I have gotten several form public sources, but I may not have > gotten all of the public ones and I have some (but still only a few) > private ones. > > Thank you. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > From Valdis.Kletnieks at vt.edu Sun Dec 28 03:13:38 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 27 Dec 2014 22:13:38 -0500 Subject: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact In-Reply-To: Your message of "Sun, 28 Dec 2014 01:50:57 +0000." <528297914.394529.1419731456991.JavaMail.zimbra@snappytelecom.net> References: <528297914.394529.1419731456991.JavaMail.zimbra@snappytelecom.net> Message-ID: <60540.1419736418@turing-police.cc.vt.edu> On Sun, 28 Dec 2014 01:50:57 +0000, Faisal Imtiaz said: > Give it up.... ! next we will be discussing how to write emails in dots and > dashes ! Somebody would *still* find a way to misinterpret it. When I ran a Scouting event for the district a few years ago, I had each competition station give the teams coded clues where the next station was. At one station, the clue was a length of surveyor's twine with knots in it. They had to figure out that overhand knots were dots, and figure eights were dashes, and then decode it with the morse code chart they had acquired along the way. As $DEITY is my witness, I never considered the possibility they'd start at the wrong end of the string.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanog at ics-il.net Sun Dec 28 04:27:13 2014 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 27 Dec 2014 22:27:13 -0600 (CST) Subject: Shapefiles, KMZs, etc. In-Reply-To: Message-ID: <5415638.8048.1419740836373.JavaMail.mhammett@ThunderFuck> I'll make sure that Telecom Ramblings gets all public sources I find. They would also have links to maps that aren't in a spatial format ie: PDFs, interactive web sites, etc. I'm looking for spatially enabled maps so I can see them all on the same screen, turn layers on and off, measure builds, and other GIS type work. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Javier J" To: "Mike Hammett" Cc: "NANOG list" Sent: Saturday, December 27, 2014 8:59:09 PM Subject: Re: Shapefiles, KMZs, etc. If you have KMZ files you have compiled from public sources, can you make them available? This would be very useful to have for project I work on from time to time. On Sat, Dec 27, 2014 at 1:00 PM, Mike Hammett < nanog at ics-il.net > wrote: I am looking for shapefiles, KMZs, etc. for networks primarily in the Midwest, but really throughout the area that is the scope of this list. I am a small ISP that just happens to know more than your average ISP about where people are and how to use GIS tools. I use them to help other ISPs find transport and they may come in handy for some start-up IX work I'm involved with. They would not go public and I would be willing to sign NDAs to get them. I have gotten several form public sources, but I may not have gotten all of the public ones and I have some (but still only a few) private ones. Thank you. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From anders at abundo.se Sun Dec 28 10:57:18 2014 From: anders at abundo.se (=?UTF-8?B?QW5kZXJzIEzDtndpbmdlcg==?=) Date: Sun, 28 Dec 2014 11:57:18 +0100 Subject: Estonian IPv6 deployment report In-Reply-To: <549EDDDC.9090609@lanparty.ee> References: <54983844.8010007@lanparty.ee> <549EDB11.2040807@abundo.se> <549EDDDC.9090609@lanparty.ee> Message-ID: <549FE20E.5080603@abundo.se> On 2014-12-27 17:27, Tarko Tikan wrote: > Split-horizon (switchport protected in Cisco world). Customers can't send > packets directly to each other, all communication has to go via BNG router. > Obviously we protect L2 as well like limiting number of MACs per customers, > make sure BNG MAC cannot be learned from customer ports etc. We don't use > any L3 (both v4 and v6) inspection in ANs, everything happens in BNG. Ok seems simple enough. I assume you have a star-network below the BNG? Ie no rings or similar in the access network? /Anders From anders at abundo.se Sun Dec 28 11:01:57 2014 From: anders at abundo.se (=?windows-1252?Q?Anders_L=F6winger?=) Date: Sun, 28 Dec 2014 12:01:57 +0100 Subject: Estonian IPv6 deployment report In-Reply-To: <20141227163733.GI33692@ernw.de> References: <54983844.8010007@lanparty.ee> <549EDB11.2040807@abundo.se> <20141227163733.GI33692@ernw.de> Message-ID: <549FE325.30907@abundo.se> On 2014-12-27 17:37, Enno Rey wrote: > true, but some (most) of them only apply in networks where multicasting/ND is fully supported which is not necessarily the case in the above type of networks. Yes. I'm aware of the various types of solutions for security in IPv6 with shared VLANs. I was curious of what solution they used. > and, from what I understand, in their scenario RAs are not sent to link-local scope all nodes (ff02::1), so that would eliminate another attack vector (depending on the actual processing of RAs on the CPEs). In P2P-Eth you can always remove the CPE and connect your hacker PC instead, and then start to inject RAs. Depending on the network this will be handled or not. Now it sounds they have a good solution in place, no L2 between customer ports. /Anders From tarko at lanparty.ee Sun Dec 28 16:16:17 2014 From: tarko at lanparty.ee (Tarko Tikan) Date: Sun, 28 Dec 2014 18:16:17 +0200 Subject: Estonian IPv6 deployment report In-Reply-To: <549FE20E.5080603@abundo.se> References: <54983844.8010007@lanparty.ee> <549EDB11.2040807@abundo.se> <549EDDDC.9090609@lanparty.ee> <549FE20E.5080603@abundo.se> Message-ID: <54A02CD1.8050205@lanparty.ee> hey, > I assume you have a star-network below the BNG? Ie no rings or similar in the > access network? Most of our network below BNG is MPLS, so no, it's not a star per say. But as PWs are point-to-point, you are technically correct. Below MPLS there is some ethernet too and this is all strictly star/tree. I would encourage everyone to push MPLS as close to customer as possible, this makes redundancy, BNG placement etc. all much easier as you can use IGP/MPLS + PWs. -- tarko From mpetach at netflight.com Sun Dec 28 20:20:15 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 28 Dec 2014 12:20:15 -0800 Subject: merry xmas In-Reply-To: <549B74CE.6070002@sadiqs.com> References: <20141224182713.GQ23692@sizone.org> <549B6DC3.9050503@sadiqs.com> <549B74CE.6070002@sadiqs.com> Message-ID: On Wed, Dec 24, 2014 at 6:22 PM, Sadiq Saif wrote: > On 12/24/2014 20:52, Sadiq Saif wrote: > > > > Here is the IPv6 version: > > mtr xmas.asininetech.org > > > > Thanks to all the people who helped with the bit of python debugging. > > :) > > > > For those using traceroute6, try with the -I flag. > What is this supposed -l flag? Linux traceroute6 doesn't seem to have a -l flag: mpetach at mintyHP:~> traceroute6 -l xmas.asininetech.org traceroute6: invalid option -- 'l' Usage: traceroute6 [-dnrvV] [-m max_ttl] [-p port#] [-q nqueries] [-s src_addr] [-t tos] [-w wait] host [data size] mpetach at mintyHP:~> mpetach at mintyHP:~> traceroute6 -V traceroute6 utility, iputils-sss20101006 mpetach at mintyHP:~> mpetach at mintyHP:~> traceroute6 -m 255 xmas.asininetech.org traceroute to xmas.asininetech.org (2620:98:4000:c::ffff) from 2001:1868:217:4::131, 255 hops max, 24 byte packets 1 2001:1868:217:4::1 (2001:1868:217:4::1) 0.811 ms 0.744 ms 0.631 ms 2 s4-0-0-4.core2.eqx.layer42.net (2001:1868:1:9::8) 4.588 ms 4.476 ms 4.473 ms 3 ge2-48.core1.sv1.layer42.net (2001:1868::312) 5.78 ms 4.821 ms 4.745 ms 4 xe0-0-0-0.core3.sv1.layer42.net (2001:1868::377) 5.231 ms 4.949 ms 4.937 ms 5 sjo-bb1-link.telia.net (2001:2000:3080:33::1) 4.722 ms 4.73 ms 4.734 ms 6 level3-ic-157355-sjo-bb1.c.telia.net (2001:2000:3080:646::2) 4.749 ms 4.785 ms 4.727 ms 7 vl-70.edge1.SanJose1.Level3.net (2001:1900:1a:6::8) 5.63 ms 5.335 ms 5.289 ms 8 vl-4045.edge5.LosAngeles.Level3.net (2001:1900:4:1::62) 15.256 ms 16.173 ms 15.337 ms 9 vl-90.edge2.LosAngeles9.Level3.net (2001:1900:12:4::e) 28.647 ms 15.227 ms 15.299 ms 10 PCCW-GLOBAL.edge2.LosAngeles9.Level3.net (2001:1900:2100::1e5a) 16.187 ms 15.763 ms 15.821 ms 11 * * * 12 2400:8800:7f04:15::2 (2400:8800:7f04:15::2) 45.747 ms 45.725 ms 45.808 ms 13 2602:ffe8:100::2 (2602:ffe8:100::2) 49.072 ms 49.008 ms 48.727 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * *^C mpetach at mintyHP:~> IPv6...it's cute to play with, but not quite ready for prime time yet. :/ Matt From lists at sadiqs.com Sun Dec 28 21:58:45 2014 From: lists at sadiqs.com (Sadiq Saif) Date: Sun, 28 Dec 2014 16:58:45 -0500 Subject: merry xmas In-Reply-To: References: <20141224182713.GQ23692@sizone.org> <549B6DC3.9050503@sadiqs.com> <549B74CE.6070002@sadiqs.com> Message-ID: <54A07D15.7040701@sadiqs.com> On 12/28/2014 15:20, Matthew Petach wrote: > > What is this supposed -l flag? Linux traceroute6 > doesn't seem to have a -l flag: > It seems your version of traceroute6 is too old for the -I option. It is present in the version in Debian Wheezy. traceroute6 -V Modern traceroute for Linux, version 2.0.18, Jun 30 2012 The little Python script also ran out of memory it seems and was killed by the OS, which is why the traceroute fails otherwise. OSError: [Errno 12] Cannot allocate memory Processing at most 50 events Killed -- Sadiq Saif https://staticsafe.ca From rdrake at direcpath.com Sun Dec 28 23:02:49 2014 From: rdrake at direcpath.com (Robert Drake) Date: Sun, 28 Dec 2014 18:02:49 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> Message-ID: <54A08C19.2090307@direcpath.com> Picking back up where this left off last year, because I apparently only work on TACACS during the holidays :) On 12/30/2013 7:28 PM, Jimmy Hess wrote: > Even 5 seconds extra for each command may hinder operators, to the extent > it would be intolerable; shell commands should run almost > instantaneously.... this is not a GUI, with an hourglass. Real-time > responsiveness in a shell is crucial --- which remote auth should not > change. Sometimes operators paste a buffer with a fair number of > commands, not expecting a second delay between each command --- a > repeated delay, may also break a pasted sequence. > > It is very possible for two of three auth servers to be unreachable, in > case of a network break, but that isn't necessary. The "response > timeout" might be 5 seconds, but in reality, there are cases where you > would wait longer, and that is tragic, since there are some obvious > alternative approaches that would have had results that would be more > 'friendly' to the interactive user. > > (Like remembering which server is working for a while, or remembering > that all servers are down -- for a while, and having a 50ms timeout, > with all servers queried in parallel, instead of a 5 seconds timeout) I think this needs to be part of the specification. I'm sure the reason they didn't do parallel queries was because of both network and CPU load back when the protocol was drafted. But it might be good to have local caching of authentication so that can happen even when servers are down or slow. Authorization could be updated to send the permissions to the router for local handling. Then if the server dies while a session is open only accounting would be affected. That does increase the vendors/implementors work but it might be doable in phases and with partial support with the clients and servers negotiating what is possible. The biggest drawback to making things like this better is you don't gain much except during outages and if you increase complexity too much you make it wide open for bugs. Maybe there is a simpler solution that keeps you happy about redundancy but doesn't increase complexity that much (possibly anycast tacacs, but the session basis of the protocol has always made that not feasible). It's possible that one of the L4 protocols Saku Ytti mentioned, QUIC or MinimaLT would address these problems too. It's possible that if we did the transport with BEEP it would also provide this, but I'm reading the docs and I don't think it goes that far in terms of connection assurance. > -- > -JH > So, here is my TACACS RFC christmas list: 1. underlying crypto 2. ssh host key authentication - having the router ask tacacs for an authorized_keys list for rdrake. I'm willing to let this go because many vendors are finding ways to do key distribution, but I'd still like to have a standard (https://code.google.com/p/openssh-lpk/ for how to do this over LDAP in UNIX) 3. authentication and authorization caching and/or something else From morrowc.lists at gmail.com Mon Dec 29 03:21:46 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 28 Dec 2014 22:21:46 -0500 Subject: The state of TACACS+ In-Reply-To: <54A08C19.2090307@direcpath.com> References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: On Sun, Dec 28, 2014 at 6:02 PM, Robert Drake wrote: > Picking back up where this left off last year, because I apparently only > work on TACACS during the holidays :) avoiding relatives? :) > > > On 12/30/2013 7:28 PM, Jimmy Hess wrote: >> >> Even 5 seconds extra for each command may hinder operators, to the extent >> it would be intolerable; shell commands should run almost >> instantaneously.... this is not a GUI, with an hourglass. Real-time >> responsiveness in a shell is crucial --- which remote auth should not >> change. Sometimes operators paste a buffer with a fair number of >> commands, not expecting a second delay between each command --- a >> repeated delay, may also break a pasted sequence. >> >> It is very possible for two of three auth servers to be unreachable, in >> case of a network break, but that isn't necessary. The "response >> timeout" might be 5 seconds, but in reality, there are cases where you >> would wait longer, and that is tragic, since there are some obvious >> alternative approaches that would have had results that would be more >> 'friendly' to the interactive user. >> >> (Like remembering which server is working for a while, or remembering >> that all servers are down -- for a while, and having a 50ms timeout, >> with all servers queried in parallel, instead of a 5 seconds timeout) > > I think this needs to be part of the specification. > > I'm sure the reason they didn't do parallel queries was because of both > network and CPU load back when the protocol was drafted. But it might be > good to have local caching of authentication so that can happen even when > servers are down or slow. Authorization could be updated to send the > permissions to the router for local handling. Then if the server dies while > a session is open only accounting would be affected. Juniper, at least, does the authorization cache on the device trick... (or really scoping of commands/areas a user is permitted via a local cache file in /var/tmp) > > That does increase the vendors/implementors work but it might be doable in > phases and with partial support with the clients and servers negotiating > what is possible. The biggest drawback to making things like this better is > you don't gain much except during outages and if you increase complexity too > much you make it wide open for bugs. and I wonder what percentage of 'users' a vendor has actually USE tac+ (or even radius). I bet it's shockingly low... > Maybe there is a simpler solution that keeps you happy about redundancy but > doesn't increase complexity that much (possibly anycast tacacs, but the > session basis of the protocol has always made that not feasible). It's does it really? :) > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or MinimaLT > would address these problems too. It's possible that if we did the > transport with BEEP it would also provide this, but I'm reading the docs and > I don't think it goes that far in terms of connection assurance. > > So, here is my TACACS RFC christmas list: > > 1. underlying crypto juniper, cisco, arista, sun, linux, freebsd still can't get TCP-AO working... they don't all have ssl libraries in their "os" either... Getting to some answer other than: "F-it, put it i clear text" for new protocols on routers really is a bit painful... not to mention ITARs sorts of problems that arise. -chris > 2. ssh host key authentication - having the router ask tacacs for an > authorized_keys list for rdrake. I'm willing to let this go because many > vendors are finding ways to do key distribution, but I'd still like to have > a standard (https://code.google.com/p/openssh-lpk/ for how to do this over > LDAP in UNIX) > 3. authentication and authorization caching and/or something else From chaim.rieger at gmail.com Mon Dec 29 03:26:47 2014 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Sun, 28 Dec 2014 19:26:47 -0800 Subject: Twitter contact Message-ID: Seems that your devices are set one year ahead. That is all From marshall.eubanks at gmail.com Mon Dec 29 03:49:19 2014 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Sun, 28 Dec 2014 22:49:19 -0500 Subject: Twitter contact In-Reply-To: References: Message-ID: Twitter being twitter, there is no shortage of reports of this. http://www.neowin.net/news/twitter-bug-makes-tweets-look-old-wont-let-some-users-sign-in On Sun, Dec 28, 2014 at 10:26 PM, Chaim Rieger wrote: > Seems that your devices are set one year ahead. > > That is all > From stephen.carter at gltgc.org Mon Dec 29 03:44:48 2014 From: stephen.carter at gltgc.org (Stephen R. Carter) Date: Mon, 29 Dec 2014 03:44:48 +0000 Subject: Charter ARP Leak Message-ID: Hello, I recently swapped out a home router for a SRX at home. Any charter techs able to take a look at the following? It looks like I am seeing some arp broadcast leaks towards my home router. Here is a small excerpt I am seeing. 06:04:04.760869 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1 06:04:04.761950 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1 06:04:04.765870 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 96.36.45.180 tell 96.36.44.1 06:04:04.802309 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 68.188.219.125 tell 68.188.218.1 06:04:04.847125 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 71.89.171.238 tell 71.89.168.1 06:04:04.873828 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 24.247.247.159 tell 24.247.247.1 06:04:04.879921 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 71.89.171.68 tell 71.89.168.1 06:04:04.890323 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 96.36.45.161 tell 96.36.44.1 06:04:04.896711 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 66.227.246.238 tell 66.227.240.1 06:04:04.901874 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 24.247.247.205 tell 24.247.247.1 06:04:04.938238 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 66.227.241.137 tell 66.227.240.1 06:04:04.965508 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 71.89.171.119 tell 71.89.168.1 06:04:04.973382 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 66.227.247.55 tell 66.227.240.1 Stephen Carter | IT Systems Administrator | Gun Lake Tribal Gaming Commission 1123 129th Avenue, Wayland, MI 49348 Phone 269.792.1773 [cid:image001.png at 01CF83DD.3875D090]
The information contained in this electronic transmission (email) is confidential information and may be subject to attorney/client privilege. It is intended only for the use of the individual or entity named above. ANY DISTRIBUTION OR COPYING OF THIS MESSAGE IS PROHIBITED, except by the intended recipient. Attempts to intercept this message are in violation of 18 U.S.C. 2511(1) of the Electronic Communications Privacy Act (ECPA), which subjects the interceptor to fines, imprisonment and/or civil damages. From mysidia at gmail.com Mon Dec 29 06:38:12 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 29 Dec 2014 00:38:12 -0600 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: On Sun, Dec 28, 2014 at 9:21 PM, Christopher Morrow wrote: > On Sun, Dec 28, 2014 at 6:02 PM, Robert Drake wrote: [snip] > Juniper, at least, does the authorization cache on the device trick... That seems nice... > and I wonder what percentage of 'users' a vendor has actually USE tac+ > (or even radius). I bet it's shockingly low... Well, the percentage of users doing per-command authorization is probably much lower than the percentage simply using Tac+ for login authentication and accounting only or accounting and exec authorization. What happens in this case in terms of failure handling is probably OK for the common scenario. For many use cases it should probably be a workable tradeoff to simply have AAA server reply with the shell:priv-lvl=1 or shell:priv-lvl=10, and make the choice to authorize commands locally by customizing which commands different privilege level numbers have, and make sure all devices have the same scheme; limiting AAA usage to once per shell. The cases where that's no solution, are most likely PCI or other higher security environments where the usability problems with TACACS+ failover simply have to be accepted, use a dedicated OOB network for AAA servers, and a HA clustered pair of AAA servers dedicated to each and every site --- sharing a virtual service IP address. >> So, here is my TACACS RFC christmas list: >> 1. underlying crypto RADIUS over TCP and DIAMETER have underlying crypto. Rfc6613: TLS or IPsec transport is shown as mandatory for RADIUS over TCP. > Getting to some answer other than: "F-it, put it i clear text" for new > protocols on routers really is a bit painful... not to mention ITARs > sorts of problems that arise. The average cheap-o smartphone ships with a TLS library; I think it's safe to say your router should have one. They shouldn't have too many problems... after all, this type of equipment already includes SSH protocol. So why not have an option for setting up a SSH session to tunnel authentication requests over? > -chris > >> 2. ssh host key authentication - having the router ask tacacs for an >> authorized_keys list for rdrake. I'm willing to let this go because many I would be content for them to just support OpenSSH CA certificate-based authorization of a user's SSH key. If the key is signed by a trusted SSH CA, valid and not expired, and the session would be valid according to the certificate, then they can authenticate using one of their listed principals. Authenticate using key signed by valid certificate as first factor, perform second factor authentication against Kerberos server, authorize against LDAP or Tacacs server. >> vendors are finding ways to do key distribution, but I'd still like to have >> a standard (https://code.google.com/p/openssh-lpk/ for how to do this over >> LDAP in UNIX) SSSD is handling this on Redhat. It's probably best to consider that how to use an "openssh public ssh key" is specific to the OpenSSH application. It makes sense that if the public key is for use with GPG/PGP to authenticate, etc, then the LDAP attribute should be something different, again specific to the application and the key format that application uses. http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/user-keys.html AuthorizedKeysCommand or PubKeyAgent is used on the openssh server. But within the single-signon daemon SSSD-Ldap; the LDAP attribute for a user object's SSH key is a configurable setting. Within the IPA LDAP schema, there is an added ipaSshPubKey user attribute. I think this as close as you get to a 'standard' for now. dn: cn=schema add:attributeTypes: ( 2.16.840.1.113730.3.8.11.31 NAME 'ipaSshPubKey' DESC 'SSH public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'IPA v3' ) add:objectClasses: ( 2.16.840.1.113730.3.8.12.11 NAME 'ipaSshGroupOfPubKeys' ABSTRACT MAY ipaSshPubKey X-ORIGIN 'IPA v3' ) add:objectClasses: ( 2.16.840.1.113730.3.8.12.12 NAME 'ipaSshUser' SUP ipaSshGroupOfPubKeys AUXILIARY X-ORIGIN 'IPA v3' ) add:objectClasses ( 2.16.840.1.113730.3.8.12.13 NAME 'ipaSshHost' SUP ipaSshGroupOfPubKeys AUXILIARY X-ORIGIN 'IPA v3' ) >> 3. authentication and authorization caching and/or something else -- -JH From randy at psg.com Mon Dec 29 07:25:56 2014 From: randy at psg.com (Randy Bush) Date: Mon, 29 Dec 2014 16:25:56 +0900 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: > Rfc6613: TLS or IPsec transport is shown as mandatory for RADIUS over TCP. sweet. can you ref conforming implementations? randy From colton.conor at gmail.com Mon Dec 29 15:15:25 2014 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 29 Dec 2014 09:15:25 -0600 Subject: The state of TACACS+ In-Reply-To: <54A08C19.2090307@direcpath.com> References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: We are able to implement TACAS+. It is my understanding this a fairly old protocol, so are you saying there are numerous bugs that still need to be fixed? A question I have is TACAS+ is usually hosted on a server, and networking devices are configured to reach out to the server for authentication. My question is what happens if the device can't reach the server if the devices network connection is offline? Our goal with TACAS+ is to not have any default/saved passwords. Every employee will have their own username and password. That way if an employee gets hired/fired, we can enable or disable their account. We are trying to avoid having any organization wide or network wide default username or password. Is this possible? Do the devices keep of log of the last successful username/password combinations that worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake wrote: > Picking back up where this left off last year, because I apparently only > work on TACACS during the holidays :) > > > On 12/30/2013 7:28 PM, Jimmy Hess wrote: > >> Even 5 seconds extra for each command may hinder operators, to the extent >> it would be intolerable; shell commands should run almost >> instantaneously.... this is not a GUI, with an hourglass. Real-time >> responsiveness in a shell is crucial --- which remote auth should not >> change. Sometimes operators paste a buffer with a fair number of >> commands, not expecting a second delay between each command --- a >> repeated delay, may also break a pasted sequence. >> >> It is very possible for two of three auth servers to be unreachable, in >> case of a network break, but that isn't necessary. The "response >> timeout" might be 5 seconds, but in reality, there are cases where you >> would wait longer, and that is tragic, since there are some obvious >> alternative approaches that would have had results that would be more >> 'friendly' to the interactive user. >> >> (Like remembering which server is working for a while, or remembering >> that all servers are down -- for a while, and having a 50ms timeout, >> with all servers queried in parallel, instead of a 5 seconds timeout) >> > I think this needs to be part of the specification. > > I'm sure the reason they didn't do parallel queries was because of both > network and CPU load back when the protocol was drafted. But it might be > good to have local caching of authentication so that can happen even when > servers are down or slow. Authorization could be updated to send the > permissions to the router for local handling. Then if the server dies while > a session is open only accounting would be affected. > > That does increase the vendors/implementors work but it might be doable in > phases and with partial support with the clients and servers negotiating > what is possible. The biggest drawback to making things like this better > is you don't gain much except during outages and if you increase complexity > too much you make it wide open for bugs. > > Maybe there is a simpler solution that keeps you happy about redundancy > but doesn't increase complexity that much (possibly anycast tacacs, but the > session basis of the protocol has always made that not feasible). It's > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or MinimaLT > would address these problems too. It's possible that if we did the > transport with BEEP it would also provide this, but I'm reading the docs > and I don't think it goes that far in terms of connection assurance. > >> -- >> -JH >> >> > So, here is my TACACS RFC christmas list: > > 1. underlying crypto > 2. ssh host key authentication - having the router ask tacacs for an > authorized_keys list for rdrake. I'm willing to let this go because many > vendors are finding ways to do key distribution, but I'd still like to have > a standard (https://code.google.com/p/openssh-lpk/ for how to do this > over LDAP in UNIX) > 3. authentication and authorization caching and/or something else > > From khelms at zcorum.com Mon Dec 29 15:22:51 2014 From: khelms at zcorum.com (Scott Helms) Date: Mon, 29 Dec 2014 10:22:51 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: Colton, Yes, that's the 'normal' way of setting it up. Basically you still have to configure a root user, but that user name and password is kept locked up and only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure that the fail safe password can't be accessed without having several people engaged so it can't be used without many people knowing. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor wrote: > We are able to implement TACAS+. It is my understanding this a fairly old > protocol, so are you saying there are numerous bugs that still need to be > fixed? > > A question I have is TACAS+ is usually hosted on a server, and networking > devices are configured to reach out to the server for authentication. My > question is what happens if the device can't reach the server if the > devices network connection is offline? Our goal with TACAS+ is to not have > any default/saved passwords. Every employee will have their own username > and password. That way if an employee gets hired/fired, we can enable or > disable their account. We are trying to avoid having any organization wide > or network wide default username or password. Is this possible? Do the > devices keep of log of the last successful username/password combinations > that worked incase the device goes offline? > > On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake > wrote: > > > Picking back up where this left off last year, because I apparently only > > work on TACACS during the holidays :) > > > > > > On 12/30/2013 7:28 PM, Jimmy Hess wrote: > > > >> Even 5 seconds extra for each command may hinder operators, to the > extent > >> it would be intolerable; shell commands should run almost > >> instantaneously.... this is not a GUI, with an hourglass. Real-time > >> responsiveness in a shell is crucial --- which remote auth should not > >> change. Sometimes operators paste a buffer with a fair number of > >> commands, not expecting a second delay between each command --- a > >> repeated delay, may also break a pasted sequence. > >> > >> It is very possible for two of three auth servers to be unreachable, in > >> case of a network break, but that isn't necessary. The "response > >> timeout" might be 5 seconds, but in reality, there are cases where you > >> would wait longer, and that is tragic, since there are some obvious > >> alternative approaches that would have had results that would be more > >> 'friendly' to the interactive user. > >> > >> (Like remembering which server is working for a while, or remembering > >> that all servers are down -- for a while, and having a 50ms timeout, > >> with all servers queried in parallel, instead of a 5 seconds timeout) > >> > > I think this needs to be part of the specification. > > > > I'm sure the reason they didn't do parallel queries was because of both > > network and CPU load back when the protocol was drafted. But it might be > > good to have local caching of authentication so that can happen even when > > servers are down or slow. Authorization could be updated to send the > > permissions to the router for local handling. Then if the server dies > while > > a session is open only accounting would be affected. > > > > That does increase the vendors/implementors work but it might be doable > in > > phases and with partial support with the clients and servers negotiating > > what is possible. The biggest drawback to making things like this better > > is you don't gain much except during outages and if you increase > complexity > > too much you make it wide open for bugs. > > > > Maybe there is a simpler solution that keeps you happy about redundancy > > but doesn't increase complexity that much (possibly anycast tacacs, but > the > > session basis of the protocol has always made that not feasible). It's > > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or > MinimaLT > > would address these problems too. It's possible that if we did the > > transport with BEEP it would also provide this, but I'm reading the docs > > and I don't think it goes that far in terms of connection assurance. > > > >> -- > >> -JH > >> > >> > > So, here is my TACACS RFC christmas list: > > > > 1. underlying crypto > > 2. ssh host key authentication - having the router ask tacacs for an > > authorized_keys list for rdrake. I'm willing to let this go because many > > vendors are finding ways to do key distribution, but I'd still like to > have > > a standard (https://code.google.com/p/openssh-lpk/ for how to do this > > over LDAP in UNIX) > > 3. authentication and authorization caching and/or something else > > > > > From colton.conor at gmail.com Mon Dec 29 15:32:51 2014 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 29 Dec 2014 09:32:51 -0600 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: Scott, Thanks for the response. How do you make sure the failsafe and/or root password that is stored in the device incase remote auth fails can't be accessed without having several employees engaged? Are there any mechanisms for doing so? My fear would be we would hire an outsourced tech. After a certain amount of time we would have to let this part timer go, and would disabled his or her username and password in TACAS. However, if that tech still knows the root password they could still remotely login to our network and cause havoc. The thought of having to change the root password on hundreds of devices doesn't sound appealing either every time an employee is let go. To make matters worse we are using an outsourced firm for some network management, so the case of hiring and firing is fairly consistent. On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms wrote: > Colton, > > Yes, that's the 'normal' way of setting it up. Basically you still have > to configure a root user, but that user name and password is kept locked up > and only accessed in case of catastrophic failure of the remote > authentication system. An important note is to make sure that the fail > safe password can't be accessed without having several people engaged so it > can't be used without many people knowing. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor > wrote: > >> We are able to implement TACAS+. It is my understanding this a fairly old >> protocol, so are you saying there are numerous bugs that still need to be >> fixed? >> >> A question I have is TACAS+ is usually hosted on a server, and networking >> devices are configured to reach out to the server for authentication. My >> question is what happens if the device can't reach the server if the >> devices network connection is offline? Our goal with TACAS+ is to not have >> any default/saved passwords. Every employee will have their own username >> and password. That way if an employee gets hired/fired, we can enable or >> disable their account. We are trying to avoid having any organization wide >> or network wide default username or password. Is this possible? Do the >> devices keep of log of the last successful username/password combinations >> that worked incase the device goes offline? >> >> On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake >> wrote: >> >> > Picking back up where this left off last year, because I apparently only >> > work on TACACS during the holidays :) >> > >> > >> > On 12/30/2013 7:28 PM, Jimmy Hess wrote: >> > >> >> Even 5 seconds extra for each command may hinder operators, to the >> extent >> >> it would be intolerable; shell commands should run almost >> >> instantaneously.... this is not a GUI, with an hourglass. Real-time >> >> responsiveness in a shell is crucial --- which remote auth should not >> >> change. Sometimes operators paste a buffer with a fair number of >> >> commands, not expecting a second delay between each command --- a >> >> repeated delay, may also break a pasted sequence. >> >> >> >> It is very possible for two of three auth servers to be unreachable, >> in >> >> case of a network break, but that isn't necessary. The "response >> >> timeout" might be 5 seconds, but in reality, there are cases where >> you >> >> would wait longer, and that is tragic, since there are some obvious >> >> alternative approaches that would have had results that would be more >> >> 'friendly' to the interactive user. >> >> >> >> (Like remembering which server is working for a while, or remembering >> >> that all servers are down -- for a while, and having a 50ms timeout, >> >> with all servers queried in parallel, instead of a 5 seconds >> timeout) >> >> >> > I think this needs to be part of the specification. >> > >> > I'm sure the reason they didn't do parallel queries was because of both >> > network and CPU load back when the protocol was drafted. But it might >> be >> > good to have local caching of authentication so that can happen even >> when >> > servers are down or slow. Authorization could be updated to send the >> > permissions to the router for local handling. Then if the server dies >> while >> > a session is open only accounting would be affected. >> > >> > That does increase the vendors/implementors work but it might be doable >> in >> > phases and with partial support with the clients and servers negotiating >> > what is possible. The biggest drawback to making things like this >> better >> > is you don't gain much except during outages and if you increase >> complexity >> > too much you make it wide open for bugs. >> > >> > Maybe there is a simpler solution that keeps you happy about redundancy >> > but doesn't increase complexity that much (possibly anycast tacacs, but >> the >> > session basis of the protocol has always made that not feasible). It's >> > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or >> MinimaLT >> > would address these problems too. It's possible that if we did the >> > transport with BEEP it would also provide this, but I'm reading the docs >> > and I don't think it goes that far in terms of connection assurance. >> > >> >> -- >> >> -JH >> >> >> >> >> > So, here is my TACACS RFC christmas list: >> > >> > 1. underlying crypto >> > 2. ssh host key authentication - having the router ask tacacs for an >> > authorized_keys list for rdrake. I'm willing to let this go because >> many >> > vendors are finding ways to do key distribution, but I'd still like to >> have >> > a standard (https://code.google.com/p/openssh-lpk/ for how to do this >> > over LDAP in UNIX) >> > 3. authentication and authorization caching and/or something else >> > >> > >> > > From joseph.snyder at gmail.com Mon Dec 29 15:45:11 2014 From: joseph.snyder at gmail.com (joseph.snyder at gmail.com) Date: Mon, 29 Dec 2014 10:45:11 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: <5DD16D65-6628-41E4-81D3-C6EC676C353D@gmail.com> Change the root when any senior person leaves. It shouldn't be known to a large set of staff members. During the bubble burst rifs we were changing them on 40k+ devices every week. Make sure you verify the pass before disconnecting the login acct making the change. Also make sure you understand the AAA process well when trying to do this so that you don't lock yourself out. On December 29, 2014 10:32:51 AM EST, Colton Conor wrote: >Scott, > >Thanks for the response. How do you make sure the failsafe and/or root >password that is stored in the device incase remote auth fails can't be >accessed without having several employees engaged? Are there any >mechanisms >for doing so? > >My fear would be we would hire an outsourced tech. After a certain >amount >of time we would have to let this part timer go, and would disabled his >or >her username and password in TACAS. However, if that tech still knows >the >root password they could still remotely login to our network and cause >havoc. The thought of having to change the root password on hundreds of >devices doesn't sound appealing either every time an employee is let >go. To >make matters worse we are using an outsourced firm for some network >management, so the case of hiring and firing is fairly consistent. > >On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms wrote: > >> Colton, >> >> Yes, that's the 'normal' way of setting it up. Basically you still >have >> to configure a root user, but that user name and password is kept >locked up >> and only accessed in case of catastrophic failure of the remote >> authentication system. An important note is to make sure that the >fail >> safe password can't be accessed without having several people engaged >so it >> can't be used without many people knowing. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor > >> wrote: >> >>> We are able to implement TACAS+. It is my understanding this a >fairly old >>> protocol, so are you saying there are numerous bugs that still need >to be >>> fixed? >>> >>> A question I have is TACAS+ is usually hosted on a server, and >networking >>> devices are configured to reach out to the server for >authentication. My >>> question is what happens if the device can't reach the server if the >>> devices network connection is offline? Our goal with TACAS+ is to >not have >>> any default/saved passwords. Every employee will have their own >username >>> and password. That way if an employee gets hired/fired, we can >enable or >>> disable their account. We are trying to avoid having any >organization wide >>> or network wide default username or password. Is this possible? Do >the >>> devices keep of log of the last successful username/password >combinations >>> that worked incase the device goes offline? >>> >>> On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake >>> wrote: >>> >>> > Picking back up where this left off last year, because I >apparently only >>> > work on TACACS during the holidays :) >>> > >>> > >>> > On 12/30/2013 7:28 PM, Jimmy Hess wrote: >>> > >>> >> Even 5 seconds extra for each command may hinder operators, to >the >>> extent >>> >> it would be intolerable; shell commands should run almost >>> >> instantaneously.... this is not a GUI, with an hourglass. >Real-time >>> >> responsiveness in a shell is crucial --- which remote auth should >not >>> >> change. Sometimes operators paste a buffer with a fair number >of >>> >> commands, not expecting a second delay between each command --- >a >>> >> repeated delay, may also break a pasted sequence. >>> >> >>> >> It is very possible for two of three auth servers to be >unreachable, >>> in >>> >> case of a network break, but that isn't necessary. The >"response >>> >> timeout" might be 5 seconds, but in reality, there are cases >where >>> you >>> >> would wait longer, and that is tragic, since there are some >obvious >>> >> alternative approaches that would have had results that would be >more >>> >> 'friendly' to the interactive user. >>> >> >>> >> (Like remembering which server is working for a while, or >remembering >>> >> that all servers are down -- for a while, and having a 50ms >timeout, >>> >> with all servers queried in parallel, instead of a 5 seconds >>> timeout) >>> >> >>> > I think this needs to be part of the specification. >>> > >>> > I'm sure the reason they didn't do parallel queries was because of >both >>> > network and CPU load back when the protocol was drafted. But it >might >>> be >>> > good to have local caching of authentication so that can happen >even >>> when >>> > servers are down or slow. Authorization could be updated to send >the >>> > permissions to the router for local handling. Then if the server >dies >>> while >>> > a session is open only accounting would be affected. >>> > >>> > That does increase the vendors/implementors work but it might be >doable >>> in >>> > phases and with partial support with the clients and servers >negotiating >>> > what is possible. The biggest drawback to making things like this >>> better >>> > is you don't gain much except during outages and if you increase >>> complexity >>> > too much you make it wide open for bugs. >>> > >>> > Maybe there is a simpler solution that keeps you happy about >redundancy >>> > but doesn't increase complexity that much (possibly anycast >tacacs, but >>> the >>> > session basis of the protocol has always made that not feasible). >It's >>> > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or >>> MinimaLT >>> > would address these problems too. It's possible that if we did >the >>> > transport with BEEP it would also provide this, but I'm reading >the docs >>> > and I don't think it goes that far in terms of connection >assurance. >>> > >>> >> -- >>> >> -JH >>> >> >>> >> >>> > So, here is my TACACS RFC christmas list: >>> > >>> > 1. underlying crypto >>> > 2. ssh host key authentication - having the router ask tacacs for >an >>> > authorized_keys list for rdrake. I'm willing to let this go >because >>> many >>> > vendors are finding ways to do key distribution, but I'd still >like to >>> have >>> > a standard (https://code.google.com/p/openssh-lpk/ for how to do >this >>> > over LDAP in UNIX) >>> > 3. authentication and authorization caching and/or something else >>> > >>> > >>> >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From jared at puck.Nether.net Mon Dec 29 15:45:49 2014 From: jared at puck.Nether.net (Jared Mauch) Date: Mon, 29 Dec 2014 10:45:49 -0500 Subject: The state of TACACS+ In-Reply-To: References: <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: <20141229154549.GE9897@puck.nether.net> On Mon, Dec 29, 2014 at 09:32:51AM -0600, Colton Conor wrote: > Scott, > > Thanks for the response. How do you make sure the failsafe and/or root > password that is stored in the device incase remote auth fails can't be > accessed without having several employees engaged? Are there any mechanisms > for doing so? Yes, this is possible as you can prevent the last resort username being used by having your AAA try tacacs+ first and having a non-overlapping username so it's rejected if t+ is operational. You should use username blah secret magic vs password as well to leverage md5 vs the reversable process. > My fear would be we would hire an outsourced tech. After a certain amount > of time we would have to let this part timer go, and would disabled his or > her username and password in TACAS. However, if that tech still knows the > root password they could still remotely login to our network and cause > havoc. The thought of having to change the root password on hundreds of > devices doesn't sound appealing either every time an employee is let go. To > make matters worse we are using an outsourced firm for some network > management, so the case of hiring and firing is fairly consistent. You can automate the login/change with scripting leveraging the clogin tool part of rancid. If you have a proper inventory of these devices and they are in rancid, it's easy to do clogin -x /tmp/commands `cat routerlist` - Jared > On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms wrote: > > > Colton, > > > > Yes, that's the 'normal' way of setting it up. Basically you still have > > to configure a root user, but that user name and password is kept locked up > > and only accessed in case of catastrophic failure of the remote > > authentication system. An important note is to make sure that the fail > > safe password can't be accessed without having several people engaged so it > > can't be used without many people knowing. > > > > > > Scott Helms > > Vice President of Technology > > ZCorum > > (678) 507-5000 > > -------------------------------- > > http://twitter.com/kscotthelms > > -------------------------------- > > > > On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor > > wrote: > > > >> We are able to implement TACAS+. It is my understanding this a fairly old > >> protocol, so are you saying there are numerous bugs that still need to be > >> fixed? > >> > >> A question I have is TACAS+ is usually hosted on a server, and networking > >> devices are configured to reach out to the server for authentication. My > >> question is what happens if the device can't reach the server if the > >> devices network connection is offline? Our goal with TACAS+ is to not have > >> any default/saved passwords. Every employee will have their own username > >> and password. That way if an employee gets hired/fired, we can enable or > >> disable their account. We are trying to avoid having any organization wide > >> or network wide default username or password. Is this possible? Do the > >> devices keep of log of the last successful username/password combinations > >> that worked incase the device goes offline? > >> > >> On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake > >> wrote: > >> > >> > Picking back up where this left off last year, because I apparently only > >> > work on TACACS during the holidays :) > >> > > >> > > >> > On 12/30/2013 7:28 PM, Jimmy Hess wrote: > >> > > >> >> Even 5 seconds extra for each command may hinder operators, to the > >> extent > >> >> it would be intolerable; shell commands should run almost > >> >> instantaneously.... this is not a GUI, with an hourglass. Real-time > >> >> responsiveness in a shell is crucial --- which remote auth should not > >> >> change. Sometimes operators paste a buffer with a fair number of > >> >> commands, not expecting a second delay between each command --- a > >> >> repeated delay, may also break a pasted sequence. > >> >> > >> >> It is very possible for two of three auth servers to be unreachable, > >> in > >> >> case of a network break, but that isn't necessary. The "response > >> >> timeout" might be 5 seconds, but in reality, there are cases where > >> you > >> >> would wait longer, and that is tragic, since there are some obvious > >> >> alternative approaches that would have had results that would be more > >> >> 'friendly' to the interactive user. > >> >> > >> >> (Like remembering which server is working for a while, or remembering > >> >> that all servers are down -- for a while, and having a 50ms timeout, > >> >> with all servers queried in parallel, instead of a 5 seconds > >> timeout) > >> >> > >> > I think this needs to be part of the specification. > >> > > >> > I'm sure the reason they didn't do parallel queries was because of both > >> > network and CPU load back when the protocol was drafted. But it might > >> be > >> > good to have local caching of authentication so that can happen even > >> when > >> > servers are down or slow. Authorization could be updated to send the > >> > permissions to the router for local handling. Then if the server dies > >> while > >> > a session is open only accounting would be affected. > >> > > >> > That does increase the vendors/implementors work but it might be doable > >> in > >> > phases and with partial support with the clients and servers negotiating > >> > what is possible. The biggest drawback to making things like this > >> better > >> > is you don't gain much except during outages and if you increase > >> complexity > >> > too much you make it wide open for bugs. > >> > > >> > Maybe there is a simpler solution that keeps you happy about redundancy > >> > but doesn't increase complexity that much (possibly anycast tacacs, but > >> the > >> > session basis of the protocol has always made that not feasible). It's > >> > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or > >> MinimaLT > >> > would address these problems too. It's possible that if we did the > >> > transport with BEEP it would also provide this, but I'm reading the docs > >> > and I don't think it goes that far in terms of connection assurance. > >> > > >> >> -- > >> >> -JH > >> >> > >> >> > >> > So, here is my TACACS RFC christmas list: > >> > > >> > 1. underlying crypto > >> > 2. ssh host key authentication - having the router ask tacacs for an > >> > authorized_keys list for rdrake. I'm willing to let this go because > >> many > >> > vendors are finding ways to do key distribution, but I'd still like to > >> have > >> > a standard (https://code.google.com/p/openssh-lpk/ for how to do this > >> > over LDAP in UNIX) > >> > 3. authentication and authorization caching and/or something else > >> > > >> > > >> > > > > -- 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 khelms at zcorum.com Mon Dec 29 15:56:19 2014 From: khelms at zcorum.com (Scott Helms) Date: Mon, 29 Dec 2014 10:56:19 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: Colton, The best thing is to create the password with a random generator so it's impossible for most people to memorize in a short amount of time. It should be ~14 characters long with mixed cases, numbers, and special characters. That password should be tested once and then put in an envelope that is put in a safe. For all new routers/switches the encrypted form can be pasted in. The envelope should be pretty much impossible to open without it being obvious. You can get even more paranoid/security conscious and put the envelope in a safe deposit box, which would log and tape anyone retrieving it, but that keeps you from getting to the password if you need it when the bank isn't open. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor wrote: > Scott, > > Thanks for the response. How do you make sure the failsafe and/or root > password that is stored in the device incase remote auth fails can't be > accessed without having several employees engaged? Are there any mechanisms > for doing so? > > My fear would be we would hire an outsourced tech. After a certain amount > of time we would have to let this part timer go, and would disabled his or > her username and password in TACAS. However, if that tech still knows the > root password they could still remotely login to our network and cause > havoc. The thought of having to change the root password on hundreds of > devices doesn't sound appealing either every time an employee is let go. To > make matters worse we are using an outsourced firm for some network > management, so the case of hiring and firing is fairly consistent. > > On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms wrote: > >> Colton, >> >> Yes, that's the 'normal' way of setting it up. Basically you still have >> to configure a root user, but that user name and password is kept locked up >> and only accessed in case of catastrophic failure of the remote >> authentication system. An important note is to make sure that the fail >> safe password can't be accessed without having several people engaged so it >> can't be used without many people knowing. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor >> wrote: >> >>> We are able to implement TACAS+. It is my understanding this a fairly old >>> protocol, so are you saying there are numerous bugs that still need to be >>> fixed? >>> >>> A question I have is TACAS+ is usually hosted on a server, and networking >>> devices are configured to reach out to the server for authentication. My >>> question is what happens if the device can't reach the server if the >>> devices network connection is offline? Our goal with TACAS+ is to not >>> have >>> any default/saved passwords. Every employee will have their own username >>> and password. That way if an employee gets hired/fired, we can enable or >>> disable their account. We are trying to avoid having any organization >>> wide >>> or network wide default username or password. Is this possible? Do the >>> devices keep of log of the last successful username/password combinations >>> that worked incase the device goes offline? >>> >>> On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake >>> wrote: >>> >>> > Picking back up where this left off last year, because I apparently >>> only >>> > work on TACACS during the holidays :) >>> > >>> > >>> > On 12/30/2013 7:28 PM, Jimmy Hess wrote: >>> > >>> >> Even 5 seconds extra for each command may hinder operators, to the >>> extent >>> >> it would be intolerable; shell commands should run almost >>> >> instantaneously.... this is not a GUI, with an hourglass. Real-time >>> >> responsiveness in a shell is crucial --- which remote auth should not >>> >> change. Sometimes operators paste a buffer with a fair number of >>> >> commands, not expecting a second delay between each command --- a >>> >> repeated delay, may also break a pasted sequence. >>> >> >>> >> It is very possible for two of three auth servers to be unreachable, >>> in >>> >> case of a network break, but that isn't necessary. The "response >>> >> timeout" might be 5 seconds, but in reality, there are cases where >>> you >>> >> would wait longer, and that is tragic, since there are some >>> obvious >>> >> alternative approaches that would have had results that would be more >>> >> 'friendly' to the interactive user. >>> >> >>> >> (Like remembering which server is working for a while, or >>> remembering >>> >> that all servers are down -- for a while, and having a 50ms >>> timeout, >>> >> with all servers queried in parallel, instead of a 5 seconds >>> timeout) >>> >> >>> > I think this needs to be part of the specification. >>> > >>> > I'm sure the reason they didn't do parallel queries was because of both >>> > network and CPU load back when the protocol was drafted. But it might >>> be >>> > good to have local caching of authentication so that can happen even >>> when >>> > servers are down or slow. Authorization could be updated to send the >>> > permissions to the router for local handling. Then if the server dies >>> while >>> > a session is open only accounting would be affected. >>> > >>> > That does increase the vendors/implementors work but it might be >>> doable in >>> > phases and with partial support with the clients and servers >>> negotiating >>> > what is possible. The biggest drawback to making things like this >>> better >>> > is you don't gain much except during outages and if you increase >>> complexity >>> > too much you make it wide open for bugs. >>> > >>> > Maybe there is a simpler solution that keeps you happy about redundancy >>> > but doesn't increase complexity that much (possibly anycast tacacs, >>> but the >>> > session basis of the protocol has always made that not feasible). It's >>> > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or >>> MinimaLT >>> > would address these problems too. It's possible that if we did the >>> > transport with BEEP it would also provide this, but I'm reading the >>> docs >>> > and I don't think it goes that far in terms of connection assurance. >>> > >>> >> -- >>> >> -JH >>> >> >>> >> >>> > So, here is my TACACS RFC christmas list: >>> > >>> > 1. underlying crypto >>> > 2. ssh host key authentication - having the router ask tacacs for an >>> > authorized_keys list for rdrake. I'm willing to let this go because >>> many >>> > vendors are finding ways to do key distribution, but I'd still like to >>> have >>> > a standard (https://code.google.com/p/openssh-lpk/ for how to do this >>> > over LDAP in UNIX) >>> > 3. authentication and authorization caching and/or something else >>> > >>> > >>> >> >> > From rdrake at direcpath.com Mon Dec 29 16:06:08 2014 From: rdrake at direcpath.com (Robert Drake) Date: Mon, 29 Dec 2014 11:06:08 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: <54A17BF0.6070508@direcpath.com> On 12/29/2014 10:32 AM, Colton Conor wrote: > My fear would be we would hire an outsourced tech. After a certain > amount of time we would have to let this part timer go, and would > disabled his or her username and password in TACAS. However, if that > tech still knows the root password they could still remotely login to > our network and cause havoc. The thought of having to change the root > password on hundreds of devices doesn't sound appealing either every > time an employee is let go. To make matters worse we are using an > outsourced firm for some network management, so the case of hiring and > firing is fairly consistent. > You can setup your aaa in most devices so tacacs+ is allowed first and the local password is only usable if tacacs+ is unreachable. In that case, even if you fire someone you can just remove them from tacacs and they can't get in. At that point you will want to do a global password change of the local password since it's compromised, but it's not an immediate concern. You should also have access lists or firewall rules on all your devices which only allow login from specific locations. If you fire someone then you remove their access to that location (their VPN credentials, username and password for UNIX login, etc), which also makes it harder for them to log back into your network even if they know the local device password. From berry at gadsdenst.org Mon Dec 29 16:19:18 2014 From: berry at gadsdenst.org (Berry Mobley) Date: Mon, 29 Dec 2014 11:19:18 -0500 Subject: The state of TACACS+ In-Reply-To: <54A17BF0.6070508@direcpath.com> References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> <54A17BF0.6070508@direcpath.com> Message-ID: At 11:06 AM 12/29/2014, you wrote: >On 12/29/2014 10:32 AM, Colton Conor wrote: >>My fear would be we would hire an outsourced tech. After a certain >>amount of time we would have to let this part timer go, and would >>disabled his or her username and password in TACAS. However, if >>that tech still knows the root password they could still remotely >>login to our network and cause havoc. The thought of having to >>change the root password on hundreds of devices doesn't sound >>appealing either every time an employee is let go. To make matters >>worse we are using an outsourced firm for some network management, >>so the case of hiring and firing is fairly consistent. >You can setup your aaa in most devices so tacacs+ is allowed first >and the local password is only usable if tacacs+ is unreachable. In >that case, even if you fire someone you can just remove them from >tacacs and they can't get in. > >At that point you will want to do a global password change of the >local password since it's compromised, but it's not an immediate concern. > >You should also have access lists or firewall rules on all your >devices which only allow login from specific locations. If you fire >someone then you remove their access to that location (their VPN >credentials, username and password for UNIX login, etc), which also >makes it harder for them to log back into your network even if they >know the local device password. Umm...what do you guys do when the network is down? All of our engineers know the 'default' username/pw - but it is not usable unless the AAA server is unreachable. I don't know of a way we could do circuit troubleshooting with that password locked up in a safe somewhere. Yes, it's a pain to change when people leave - but it would be a much larger pain to do deployments without it, I think. Berry From Valdis.Kletnieks at vt.edu Mon Dec 29 16:49:48 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 29 Dec 2014 11:49:48 -0500 Subject: Charter ARP Leak In-Reply-To: Your message of "Mon, 29 Dec 2014 03:44:48 +0000." References: Message-ID: <150444.1419871788@turing-police.cc.vt.edu> On Mon, 29 Dec 2014 03:44:48 +0000, "Stephen R. Carter" said: > Here is a small excerpt I am seeing. > > 06:04:04.760869 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1 > 06:04:04.761950 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1 The interesting thing is that they're all .1 addresses. It's almost as if the one broadcast domain has at least 7 different address spaces on it. I've long seen similar in Comcast country. My CPE router has an upstream interface: ge00 Link encap:Ethernet HWaddr 10:0D:7F:64:CA:0C inet addr:73.171.123.11 Bcast:73.171.123.255 Mask:255.255.254.0 but yet I see a continual background flux of 6-8 arp requests a second, mostly from what appear to be routers for other subnets: # cpdump -i ge00 -n arp -c 2000 | awk '{print $7}' | sort | uniq -c tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ge00, link-type EN10MB (Ethernet), capture size 65535 bytes 2000 packets captured 2012 packets received by filter 0 packets dropped by kernel 38 100.93.216.1, 16 184.121.18.1, 18 184.126.32.1, 36 24.127.42.1, 34 24.127.50.1, 20 24.131.5.1, 18 50.134.17.1, 17 50.134.55.1, 37 50.134.64.1, 91 50.218.88.1, 142 50.220.88.1, 298 71.197.0.1, 183 71.62.120.1, 81 71.63.61.1, 167 73.171.122.1, (my putative upstream router) 1 73.171.123.11, (my box timed out its arp entry for upstream) 131 73.171.77.1, 511 73.31.150.1, 157 73.31.41.1, 3 96.120.18.205, I've annotated the 2 lines I *expected* to see... The other odd part is that of 20 sources, only 7 appear to have PTR entries.... When I first noticed this and mentioned it to somebody, they responded "Forget it, Jake. It's Chinatown". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From rdrake at direcpath.com Mon Dec 29 17:00:48 2014 From: rdrake at direcpath.com (Robert Drake) Date: Mon, 29 Dec 2014 12:00:48 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: <54A188C0.1020303@direcpath.com> On 12/28/2014 10:21 PM, Christopher Morrow wrote: > and I wonder what percentage of 'users' a vendor has actually USE tac+ > (or even radius). I bet it's shockingly low... true.. even in large-ish environments centralized authentication presents problems and can have a limited merit. Up to some arbitrary size, nobody really can be bothered unless some business case comes up like splitting responsibilities between groups. Accounting is probably the best early reason to turn it on in small networks. Being able to see who made a change makes it easier to figure out why. >> Maybe there is a simpler solution that keeps you happy about redundancy but >> doesn't increase complexity that much (possibly anycast tacacs, but the >> session basis of the protocol has always made that not feasible). It's > does it really? :) Well, the chance of two geographically close servers getting load-balanced made it not feasible for us to do. Not to mention the fact that we had only two tacacs servers and the use-case for anycasting wasn't worth the hassle of implementation. > juniper, cisco, arista, sun, linux, freebsd still can't get TCP-AO working... > they don't all have ssl libraries in their "os" either... With it being a TCP extension, my guess is that it's harder to find someone at those companies willing to change things inside the kernel because it's used by too many people, and if nobody is asking for it then they don't want to build it just to advertise they're first to market. Even the ISP's who probably asked for it ultimately don't put money on getting it done because the engineer who says they need it still doesn't turn down the new chassis that lacks support. The money is all flowing through the hardware guys now and if it's not directly related to moving packets quickly then they don't care. > > Getting to some answer other than: "F-it, put it i clear text" for new > protocols on routers really is a bit painful... not to mention ITARs > sorts of problems that arise. Now you're making me depressed. :) The question is should we be trying to move things along or just leave it as it is? There are certainly more important things on everyone's TODO list right now, but I'd rather the vendors have an open ticket in their queue saying "secure-tacacs+-rfc unimplemented" rather than letting them off the hook. > > -chris Robert From linuxbrad at gmail.com Mon Dec 29 11:53:12 2014 From: linuxbrad at gmail.com (Brad Hein) Date: Mon, 29 Dec 2014 06:53:12 -0500 Subject: Charter ARP Leak In-Reply-To: References: Message-ID: This is normal for a cable modem network. These are broadcast packets so they get delivered to everybody on that node. ARP uses layer-2 broadcast to ask for the owner of a given IP to respond with its MAC so that subsequent communication with that IP can be addressed directly. [sent from mobile device] On Dec 29, 2014 12:15 AM, "Stephen R. Carter" wrote: > Hello, > > I recently swapped out a home router for a SRX at home. Any charter techs > able to take a look at the following? It looks like I am seeing some arp > broadcast leaks towards my home router. > > Here is a small excerpt I am seeing. > > 06:04:04.760869 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1 > 06:04:04.761950 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1 > 06:04:04.765870 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 96.36.45.180 tell 96.36.44.1 > 06:04:04.802309 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 68.188.219.125 tell 68.188.218.1 > 06:04:04.847125 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 71.89.171.238 tell 71.89.168.1 > 06:04:04.873828 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 24.247.247.159 tell 24.247.247.1 > 06:04:04.879921 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 71.89.171.68 tell 71.89.168.1 > 06:04:04.890323 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 96.36.45.161 tell 96.36.44.1 > 06:04:04.896711 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 66.227.246.238 tell 66.227.240.1 > 06:04:04.901874 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 24.247.247.205 tell 24.247.247.1 > 06:04:04.938238 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 66.227.241.137 tell 66.227.240.1 > 06:04:04.965508 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 71.89.171.119 tell 71.89.168.1 > 06:04:04.973382 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 66.227.247.55 tell 66.227.240.1 > > Stephen Carter | IT Systems Administrator | Gun Lake Tribal Gaming > Commission > 1123 129th Avenue, Wayland, MI 49348 > Phone 269.792.1773 > [cid:image001.png at 01CF83DD.3875D090] > > > >
The information contained > in this electronic transmission (email) is confidential information and may > be subject to attorney/client privilege. It is intended only for the use of > the individual or entity named above. ANY DISTRIBUTION OR COPYING OF THIS > MESSAGE IS PROHIBITED, except by the intended recipient. Attempts to > intercept this message are in violation of 18 U.S.C. 2511(1) of the > Electronic Communications Privacy Act (ECPA), which subjects the > interceptor to fines, imprisonment and/or civil damages. > > From Michael.Douglas at IEEE.org Mon Dec 29 15:38:32 2014 From: Michael.Douglas at IEEE.org (Michael Douglas) Date: Mon, 29 Dec 2014 10:38:32 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: In the Cisco world the AAA config is typically set up to try tacacs first, and local accounts second. The local account is only usable if tacacs is unavailable. Knowledge of the local username/password does not equate to full time access with that credential. Also, you would usually filter the incoming SSH sessions to only permit a particular management IP range; the local credential, or tacacs credential, shouldn't be usable from any arbitrary network. On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor wrote: > Scott, > > Thanks for the response. How do you make sure the failsafe and/or root > password that is stored in the device incase remote auth fails can't be > accessed without having several employees engaged? Are there any mechanisms > for doing so? > > My fear would be we would hire an outsourced tech. After a certain amount > of time we would have to let this part timer go, and would disabled his or > her username and password in TACAS. However, if that tech still knows the > root password they could still remotely login to our network and cause > havoc. The thought of having to change the root password on hundreds of > devices doesn't sound appealing either every time an employee is let go. To > make matters worse we are using an outsourced firm for some network > management, so the case of hiring and firing is fairly consistent. > > On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms wrote: > > > Colton, > > > > Yes, that's the 'normal' way of setting it up. Basically you still have > > to configure a root user, but that user name and password is kept locked > up > > and only accessed in case of catastrophic failure of the remote > > authentication system. An important note is to make sure that the fail > > safe password can't be accessed without having several people engaged so > it > > can't be used without many people knowing. > > > > > > Scott Helms > > Vice President of Technology > > ZCorum > > (678) 507-5000 > > -------------------------------- > > http://twitter.com/kscotthelms > > -------------------------------- > > > > On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor > > wrote: > > > >> We are able to implement TACAS+. It is my understanding this a fairly > old > >> protocol, so are you saying there are numerous bugs that still need to > be > >> fixed? > >> > >> A question I have is TACAS+ is usually hosted on a server, and > networking > >> devices are configured to reach out to the server for authentication. My > >> question is what happens if the device can't reach the server if the > >> devices network connection is offline? Our goal with TACAS+ is to not > have > >> any default/saved passwords. Every employee will have their own username > >> and password. That way if an employee gets hired/fired, we can enable or > >> disable their account. We are trying to avoid having any organization > wide > >> or network wide default username or password. Is this possible? Do the > >> devices keep of log of the last successful username/password > combinations > >> that worked incase the device goes offline? > >> > >> On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake > >> wrote: > >> > >> > Picking back up where this left off last year, because I apparently > only > >> > work on TACACS during the holidays :) > >> > > >> > > >> > On 12/30/2013 7:28 PM, Jimmy Hess wrote: > >> > > >> >> Even 5 seconds extra for each command may hinder operators, to the > >> extent > >> >> it would be intolerable; shell commands should run almost > >> >> instantaneously.... this is not a GUI, with an hourglass. > Real-time > >> >> responsiveness in a shell is crucial --- which remote auth should not > >> >> change. Sometimes operators paste a buffer with a fair number of > >> >> commands, not expecting a second delay between each command --- a > >> >> repeated delay, may also break a pasted sequence. > >> >> > >> >> It is very possible for two of three auth servers to be unreachable, > >> in > >> >> case of a network break, but that isn't necessary. The "response > >> >> timeout" might be 5 seconds, but in reality, there are cases where > >> you > >> >> would wait longer, and that is tragic, since there are some > obvious > >> >> alternative approaches that would have had results that would be > more > >> >> 'friendly' to the interactive user. > >> >> > >> >> (Like remembering which server is working for a while, or > remembering > >> >> that all servers are down -- for a while, and having a 50ms > timeout, > >> >> with all servers queried in parallel, instead of a 5 seconds > >> timeout) > >> >> > >> > I think this needs to be part of the specification. > >> > > >> > I'm sure the reason they didn't do parallel queries was because of > both > >> > network and CPU load back when the protocol was drafted. But it might > >> be > >> > good to have local caching of authentication so that can happen even > >> when > >> > servers are down or slow. Authorization could be updated to send the > >> > permissions to the router for local handling. Then if the server dies > >> while > >> > a session is open only accounting would be affected. > >> > > >> > That does increase the vendors/implementors work but it might be > doable > >> in > >> > phases and with partial support with the clients and servers > negotiating > >> > what is possible. The biggest drawback to making things like this > >> better > >> > is you don't gain much except during outages and if you increase > >> complexity > >> > too much you make it wide open for bugs. > >> > > >> > Maybe there is a simpler solution that keeps you happy about > redundancy > >> > but doesn't increase complexity that much (possibly anycast tacacs, > but > >> the > >> > session basis of the protocol has always made that not feasible). > It's > >> > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or > >> MinimaLT > >> > would address these problems too. It's possible that if we did the > >> > transport with BEEP it would also provide this, but I'm reading the > docs > >> > and I don't think it goes that far in terms of connection assurance. > >> > > >> >> -- > >> >> -JH > >> >> > >> >> > >> > So, here is my TACACS RFC christmas list: > >> > > >> > 1. underlying crypto > >> > 2. ssh host key authentication - having the router ask tacacs for an > >> > authorized_keys list for rdrake. I'm willing to let this go because > >> many > >> > vendors are finding ways to do key distribution, but I'd still like to > >> have > >> > a standard (https://code.google.com/p/openssh-lpk/ for how to do this > >> > over LDAP in UNIX) > >> > 3. authentication and authorization caching and/or something else > >> > > >> > > >> > > > > > From jim.rampley at charter.com Mon Dec 29 17:12:34 2014 From: jim.rampley at charter.com (Rampley Jr, Jim F) Date: Mon, 29 Dec 2014 11:12:34 -0600 Subject: Charter ARP Leak In-Reply-To: <150444.1419871788@turing-police.cc.vt.edu> References: <150444.1419871788@turing-police.cc.vt.edu> Message-ID: On 12/29/14, 10:49 AM, "Valdis.Kletnieks at vt.edu" wrote: >On Mon, 29 Dec 2014 03:44:48 +0000, "Stephen R. Carter" said: >> Here is a small excerpt I am seeing. >> >> 06:04:04.760869 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype >>ARP (0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1 >> 06:04:04.761950 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype >>ARP (0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1 > >The interesting thing is that they're all .1 addresses. It's almost as if >the one broadcast domain has at least 7 different address spaces on it. Valdis, you are correct. What your seeing is caused by multiple IP blocks being assigned to the same CMTS interface. From jra at baylink.com Mon Dec 29 17:27:04 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 29 Dec 2014 12:27:04 -0500 (EST) Subject: Charter ARP Leak In-Reply-To: Message-ID: <28388313.750.1419874023962.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Rampley Jr, Jim F" > On 12/29/14, 10:49 AM, "Valdis.Kletnieks at vt.edu" > > wrote: > > >On Mon, 29 Dec 2014 03:44:48 +0000, "Stephen R. Carter" said: > >> Here is a small excerpt I am seeing. > >> > >> 06:04:04.760869 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype > >>ARP (0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1 > >> 06:04:04.761950 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype > >>ARP (0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1 > > > >The interesting thing is that they're all .1 addresses. It's almost > >as if > >the one broadcast domain has at least 7 different address spaces on > >it. > > Valdis, you are correct. What your seeing is caused by multiple IP > blocks being assigned to the same CMTS interface. Am I incorrect, though, in believing that ARP packets should only be visible within a broadcast domain, and that because of that, they should not be being passed through a cablemodem attached to such a CMTS interface unless they're within the IP network in which that interface lives (which is probably not 0/0)? This sounds like a firmware bug in either the CMTS or the cablemodem. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From colton.conor at gmail.com Mon Dec 29 17:28:10 2014 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 29 Dec 2014 11:28:10 -0600 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: Glad to know you can make local access only work if TACAS+ isn't available. However, that still doesn't prevent the employee who know the local username and password to unplug the device from the network, and the use the local password to get in. Still better than our current setup of having one default username and password that everyone knows. On Mon, Dec 29, 2014 at 9:38 AM, Michael Douglas wrote: > In the Cisco world the AAA config is typically set up to try tacacs first, > and local accounts second. The local account is only usable if tacacs is > unavailable. Knowledge of the local username/password does not equate to > full time access with that credential. Also, you would usually filter the > incoming SSH sessions to only permit a particular management IP range; the > local credential, or tacacs credential, shouldn't be usable from any > arbitrary network. > > On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor > wrote: > > > Scott, > > > > Thanks for the response. How do you make sure the failsafe and/or root > > password that is stored in the device incase remote auth fails can't be > > accessed without having several employees engaged? Are there any > mechanisms > > for doing so? > > > > My fear would be we would hire an outsourced tech. After a certain amount > > of time we would have to let this part timer go, and would disabled his > or > > her username and password in TACAS. However, if that tech still knows the > > root password they could still remotely login to our network and cause > > havoc. The thought of having to change the root password on hundreds of > > devices doesn't sound appealing either every time an employee is let go. > To > > make matters worse we are using an outsourced firm for some network > > management, so the case of hiring and firing is fairly consistent. > > > > On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms wrote: > > > > > Colton, > > > > > > Yes, that's the 'normal' way of setting it up. Basically you still > have > > > to configure a root user, but that user name and password is kept > locked > > up > > > and only accessed in case of catastrophic failure of the remote > > > authentication system. An important note is to make sure that the fail > > > safe password can't be accessed without having several people engaged > so > > it > > > can't be used without many people knowing. > > > > > > > > > Scott Helms > > > Vice President of Technology > > > ZCorum > > > (678) 507-5000 > > > -------------------------------- > > > http://twitter.com/kscotthelms > > > -------------------------------- > > > > > > On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor > > > > wrote: > > > > > >> We are able to implement TACAS+. It is my understanding this a fairly > > old > > >> protocol, so are you saying there are numerous bugs that still need to > > be > > >> fixed? > > >> > > >> A question I have is TACAS+ is usually hosted on a server, and > > networking > > >> devices are configured to reach out to the server for authentication. > My > > >> question is what happens if the device can't reach the server if the > > >> devices network connection is offline? Our goal with TACAS+ is to not > > have > > >> any default/saved passwords. Every employee will have their own > username > > >> and password. That way if an employee gets hired/fired, we can enable > or > > >> disable their account. We are trying to avoid having any organization > > wide > > >> or network wide default username or password. Is this possible? Do the > > >> devices keep of log of the last successful username/password > > combinations > > >> that worked incase the device goes offline? > > >> > > >> On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake > > >> wrote: > > >> > > >> > Picking back up where this left off last year, because I apparently > > only > > >> > work on TACACS during the holidays :) > > >> > > > >> > > > >> > On 12/30/2013 7:28 PM, Jimmy Hess wrote: > > >> > > > >> >> Even 5 seconds extra for each command may hinder operators, to the > > >> extent > > >> >> it would be intolerable; shell commands should run almost > > >> >> instantaneously.... this is not a GUI, with an hourglass. > > Real-time > > >> >> responsiveness in a shell is crucial --- which remote auth should > not > > >> >> change. Sometimes operators paste a buffer with a fair number of > > >> >> commands, not expecting a second delay between each command --- a > > >> >> repeated delay, may also break a pasted sequence. > > >> >> > > >> >> It is very possible for two of three auth servers to be > unreachable, > > >> in > > >> >> case of a network break, but that isn't necessary. The > "response > > >> >> timeout" might be 5 seconds, but in reality, there are cases > where > > >> you > > >> >> would wait longer, and that is tragic, since there are some > > obvious > > >> >> alternative approaches that would have had results that would be > > more > > >> >> 'friendly' to the interactive user. > > >> >> > > >> >> (Like remembering which server is working for a while, or > > remembering > > >> >> that all servers are down -- for a while, and having a 50ms > > timeout, > > >> >> with all servers queried in parallel, instead of a 5 seconds > > >> timeout) > > >> >> > > >> > I think this needs to be part of the specification. > > >> > > > >> > I'm sure the reason they didn't do parallel queries was because of > > both > > >> > network and CPU load back when the protocol was drafted. But it > might > > >> be > > >> > good to have local caching of authentication so that can happen even > > >> when > > >> > servers are down or slow. Authorization could be updated to send > the > > >> > permissions to the router for local handling. Then if the server > dies > > >> while > > >> > a session is open only accounting would be affected. > > >> > > > >> > That does increase the vendors/implementors work but it might be > > doable > > >> in > > >> > phases and with partial support with the clients and servers > > negotiating > > >> > what is possible. The biggest drawback to making things like this > > >> better > > >> > is you don't gain much except during outages and if you increase > > >> complexity > > >> > too much you make it wide open for bugs. > > >> > > > >> > Maybe there is a simpler solution that keeps you happy about > > redundancy > > >> > but doesn't increase complexity that much (possibly anycast tacacs, > > but > > >> the > > >> > session basis of the protocol has always made that not feasible). > > It's > > >> > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or > > >> MinimaLT > > >> > would address these problems too. It's possible that if we did the > > >> > transport with BEEP it would also provide this, but I'm reading the > > docs > > >> > and I don't think it goes that far in terms of connection assurance. > > >> > > > >> >> -- > > >> >> -JH > > >> >> > > >> >> > > >> > So, here is my TACACS RFC christmas list: > > >> > > > >> > 1. underlying crypto > > >> > 2. ssh host key authentication - having the router ask tacacs for > an > > >> > authorized_keys list for rdrake. I'm willing to let this go because > > >> many > > >> > vendors are finding ways to do key distribution, but I'd still like > to > > >> have > > >> > a standard (https://code.google.com/p/openssh-lpk/ for how to do > this > > >> > over LDAP in UNIX) > > >> > 3. authentication and authorization caching and/or something else > > >> > > > >> > > > >> > > > > > > > > > From rbf at rbfnet.com Mon Dec 29 17:35:42 2014 From: rbf at rbfnet.com (Brett Frankenberger) Date: Mon, 29 Dec 2014 11:35:42 -0600 Subject: Charter ARP Leak In-Reply-To: <28388313.750.1419874023962.JavaMail.root@benjamin.baylink.com> References: <28388313.750.1419874023962.JavaMail.root@benjamin.baylink.com> Message-ID: <20141229173542.GA4704@panix.com> On Mon, Dec 29, 2014 at 12:27:04PM -0500, Jay Ashworth wrote: > > > > Valdis, you are correct. What your seeing is caused by multiple IP > > blocks being assigned to the same CMTS interface. > > Am I incorrect, though, in believing that ARP packets should only be visible > within a broadcast domain, broadcast domain != subnet > and that because of that, they should not be > being passed through a cablemodem attached to such a CMTS interface unless > they're within the IP network in which that interface lives (which is > probably not 0/0)? > > This sounds like a firmware bug in either the CMTS or the cablemodem. int ethernet 0/0 ip address 10.0.0.1 255.255.0.0 ip address 11.0.0.1 255.255.0.0 secondary ip address 12.0.0.1 255.255.0.0 secondary The broadcast domain will have ARP broadcasts for all three subnets. Doing it over a CMTS doesn't change that. -- Brett From jra at baylink.com Mon Dec 29 17:51:04 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 29 Dec 2014 12:51:04 -0500 (EST) Subject: Charter ARP Leak In-Reply-To: <20141229173542.GA4704@panix.com> Message-ID: <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brett Frankenberger" > On Mon, Dec 29, 2014 at 12:27:04PM -0500, Jay Ashworth wrote: > > > > > > Valdis, you are correct. What your seeing is caused by multiple IP > > > blocks being assigned to the same CMTS interface. > > > > Am I incorrect, though, in believing that ARP packets should only be > > visible > > within a broadcast domain, > > broadcast domain != subnet Yeah; I didn't use the right term. That's why my networks are small. :-) > > and that because of that, they should not be > > being passed through a cablemodem attached to such a CMTS interface > > unless > > they're within the IP network in which that interface lives (which > > is > > probably not 0/0)? > > > > This sounds like a firmware bug in either the CMTS or the > > cablemodem. > > int ethernet 0/0 > ip address 10.0.0.1 255.255.0.0 > ip address 11.0.0.1 255.255.0.0 secondary > ip address 12.0.0.1 255.255.0.0 secondary > > The broadcast domain will have ARP broadcasts for all three subnets. > > Doing it over a CMTS doesn't change that. Ok. But the interface to which the cablemodem is attached, in the general single-DHCP-IP case, is a /24, is it not? The example Valdis posted had 5 or 6 different /24s from all over the v4 address space; that seems exceptionally sloppy routing... I have seen ARP-traffic-not-for-me come through a cablemodem in the past as well, but it was *uniformly* for the /24 in which my modem's address lived that day. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jared at puck.Nether.net Mon Dec 29 17:52:33 2014 From: jared at puck.Nether.net (Jared Mauch) Date: Mon, 29 Dec 2014 12:52:33 -0500 Subject: Charter ARP Leak In-Reply-To: References: <150444.1419871788@turing-police.cc.vt.edu> Message-ID: <20141229175233.GG9897@puck.nether.net> On Mon, Dec 29, 2014 at 11:12:34AM -0600, Rampley Jr, Jim F wrote: > On 12/29/14, 10:49 AM, "Valdis.Kletnieks at vt.edu" > wrote: > > >On Mon, 29 Dec 2014 03:44:48 +0000, "Stephen R. Carter" said: > >> Here is a small excerpt I am seeing. > >> > >> 06:04:04.760869 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype > >>ARP (0x0806), length 60: arp who-has 97.85.59.219 tell 97.85.58.1 > >> 06:04:04.761950 In 00:21:a0:fb:53:d9 > ff:ff:ff:ff:ff:ff, ethertype > >>ARP (0x0806), length 60: arp who-has 75.135.155.27 tell 75.135.152.1 > > > >The interesting thing is that they're all .1 addresses. It's almost as if > >the one broadcast domain has at least 7 different address spaces on it. > > Valdis, you are correct. What your seeing is caused by multiple IP blocks > being assigned to the same CMTS interface. I would be way more interested in seeing the NDP entries than the ARP entries. - 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 david at davidcoulson.net Mon Dec 29 17:56:36 2014 From: david at davidcoulson.net (David Coulson) Date: Mon, 29 Dec 2014 12:56:36 -0500 Subject: Charter ARP Leak In-Reply-To: <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> References: <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> Message-ID: <54A195D4.4000503@davidcoulson.net> On 12/29/14, 12:51 PM, Jay Ashworth wrote: > Ok. But the interface to which the cablemodem is attached, in the general > single-DHCP-IP case, is a /24, is it not? I'm on TWC. The IP address I get from them is on a /20. 104.230.32.0/20 dev eth7 proto kernel scope link src 104.230.32.x > > The example Valdis posted had 5 or 6 different /24s from all over the v4 > address space; that seems exceptionally sloppy routing... fw-1:/root # tcpdump -ni eth7 arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth7, link-type EN10MB (Ethernet), capture size 65535 bytes 12:54:21.354278 ARP, Request who-has 173.89.105.161 tell 173.89.96.1, length 46 12:54:21.355881 ARP, Request who-has 104.230.27.232 tell 104.230.0.1, length 46 We all knows it's easier to add another secondary IP to the interface and add a new DHCP scope than to try to expand a subnet. Not sure I understand what all the excitement is about? From cboyd at gizmopartners.com Mon Dec 29 18:05:33 2014 From: cboyd at gizmopartners.com (Chris Boyd) Date: Mon, 29 Dec 2014 12:05:33 -0600 Subject: Charter ARP Leak In-Reply-To: <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> References: <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> Message-ID: > On Dec 29, 2014, at 11:51 AM, Jay Ashworth wrote: > > Ok. But the interface to which the cablemodem is attached, in the general > single-DHCP-IP case, is a /24, is it not? No, I've seen multiple IPv4 /21s assigned to a single customer interface on a CMTS. The newer CMTS are beastly large boxes. > The example Valdis posted had 5 or 6 different /24s from all over the v4 > address space; that seems exceptionally sloppy routing... It's just the nature of having multiple secondary IP addresses on the same RF interface facing the customers > I have seen ARP-traffic-not-for-me come through a cablemodem in the past as > well, but it was *uniformly* for the /24 in which my modem's address lived > that day. Cable modems are typically bridges (at least the ones that Work Right, IMHO), so it makes sense that you'll see all layer 2 broadcasts. If you live in a small enough town, or have business class service on your modem, you may only see a smaller or single subnet. On the residential side in a larger town you'll see lots of layer 2 stuff. --Chris From bedard.phil at gmail.com Mon Dec 29 18:22:38 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Mon, 29 Dec 2014 13:22:38 -0500 Subject: Charter ARP Leak In-Reply-To: <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> References: <20141229173542.GA4704@panix.com> <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> Message-ID: <54a19c07.5479e00a.7f5b.7e6e@mx.google.com> The CM is just a bridge for that traffic. It has a management IP assigned to it by the provider but that's a different network so to speak. Phil -----Original Message----- From: "Jay Ashworth" Sent: ‎12/‎29/‎2014 12:52 PM To: "NANOG" Subject: Re: Charter ARP Leak ----- Original Message ----- > From: "Brett Frankenberger" > On Mon, Dec 29, 2014 at 12:27:04PM -0500, Jay Ashworth wrote: > > > > > > Valdis, you are correct. What your seeing is caused by multiple IP > > > blocks being assigned to the same CMTS interface. > > > > Am I incorrect, though, in believing that ARP packets should only be > > visible > > within a broadcast domain, > > broadcast domain != subnet Yeah; I didn't use the right term. That's why my networks are small. :-) > > and that because of that, they should not be > > being passed through a cablemodem attached to such a CMTS interface > > unless > > they're within the IP network in which that interface lives (which > > is > > probably not 0/0)? > > > > This sounds like a firmware bug in either the CMTS or the > > cablemodem. > > int ethernet 0/0 > ip address 10.0.0.1 255.255.0.0 > ip address 11.0.0.1 255.255.0.0 secondary > ip address 12.0.0.1 255.255.0.0 secondary > > The broadcast domain will have ARP broadcasts for all three subnets. > > Doing it over a CMTS doesn't change that. Ok. But the interface to which the cablemodem is attached, in the general single-DHCP-IP case, is a /24, is it not? The example Valdis posted had 5 or 6 different /24s from all over the v4 address space; that seems exceptionally sloppy routing... I have seen ARP-traffic-not-for-me come through a cablemodem in the past as well, but it was *uniformly* for the /24 in which my modem's address lived that day. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From Michael.Douglas at IEEE.org Mon Dec 29 18:38:36 2014 From: Michael.Douglas at IEEE.org (Michael Douglas) Date: Mon, 29 Dec 2014 13:38:36 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: If someone has physical access to a Cisco router they can initiate a password recovery; tacacs vs local account doesn't matter at that point. On Mon, Dec 29, 2014 at 12:28 PM, Colton Conor wrote: > Glad to know you can make local access only work if TACAS+ isn't > available. However, that still doesn't prevent the employee who know the > local username and password to unplug the device from the network, and the > use the local password to get in. Still better than our current setup of > having one default username and password that everyone knows. > > > From jra at baylink.com Mon Dec 29 19:23:56 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 29 Dec 2014 14:23:56 -0500 (EST) Subject: Charter ARP Leak In-Reply-To: <54A195D4.4000503@davidcoulson.net> Message-ID: <17490863.756.1419881036436.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "David Coulson" > We all knows it's easier to add another secondary IP to the interface > and add a new DHCP scope than to try to expand a subnet. >From an intermediate routing standpoint, though, it would be easier to add an *adjacent* block, not one halfway across the address space, no? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From corey.touchet at corp.totalserversolutions.com Mon Dec 29 22:41:45 2014 From: corey.touchet at corp.totalserversolutions.com (Corey Touchet) Date: Mon, 29 Dec 2014 22:41:45 +0000 Subject: Charter ARP Leak In-Reply-To: <54A195D4.4000503@davidcoulson.net> References: <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> <54A195D4.4000503@davidcoulson.net> Message-ID: <0F11A49202723141A08215952768DA36D31A001E@ORD2MBX05F.mex05.mlsrvr.com> We'll I would for one be very interested if the 8 ARP packets a second count against the caps. Given len of 46 or 60 is not much, but that's about a gig of traffic almost assuming 8 of those a second happen(and my cold medicine addled mind is working). I'm sure it's not just that when it comes to garbage received on your interface either. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Coulson Sent: Monday, December 29, 2014 12:57 PM To: nanog at nanog.org Subject: Re: Charter ARP Leak Not sure I understand what all the excitement is about? From raphael.timothy at gmail.com Mon Dec 29 23:35:49 2014 From: raphael.timothy at gmail.com (Tim Raphael) Date: Tue, 30 Dec 2014 07:35:49 +0800 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: Making the TACAC+ server unavailable is fairly easy - a small LAN-based DDoS would do it, or a firewall rule change somewhere in the middle. Either would cause the router to failover to it's local account. - this is based on the fact that said attacker has some sort of access previously and wanted to elevate their privileges. On Tue, Dec 30, 2014 at 2:38 AM, Michael Douglas wrote: > If someone has physical access to a Cisco router they can initiate a > password recovery; tacacs vs local account doesn't matter at that point. > > On Mon, Dec 29, 2014 at 12:28 PM, Colton Conor > wrote: > > > Glad to know you can make local access only work if TACAS+ isn't > > available. However, that still doesn't prevent the employee who know the > > local username and password to unplug the device from the network, and > the > > use the local password to get in. Still better than our current setup of > > having one default username and password that everyone knows. > > > > > > > From larrysheldon at cox.net Tue Dec 30 01:21:28 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 29 Dec 2014 19:21:28 -0600 Subject: Charter ARP Leak In-Reply-To: References: <28388313.750.1419874023962.JavaMail.root@benjamin.baylink.com> Message-ID: <54A1FE18.6050100@cox.net> On 12/29/2014 11:35, Brett Frankenberger wrote: > On Mon, Dec 29, 2014 at 12:27:04PM -0500, Jay Ashworth wrote: >>> >>> Valdis, you are correct. What your seeing is caused by multiple IP >>> blocks being assigned to the same CMTS interface. >> >> Am I incorrect, though, in believing that ARP packets should only be visible >> within a broadcast domain, > > broadcast domain != subnet It surprises me that in this day and age, in a forum like this that has an active thread about kids being taught archaic concepts, we see language like "broadcast domain != subnet" and a perceived need to explain it. [no longer germane material deleted to reduce excess baggage charges] > int ethernet 0/0 > ip address 10.0.0.1 255.255.0.0 > ip address 11.0.0.1 255.255.0.0 secondary > ip address 12.0.0.1 255.255.0.0 secondary > > The broadcast domain will have ARP broadcasts for all three subnets. This are not "subnets"! They are IP addresses in three different IP networks. > Doing it over a CMTS doesn't change that. Communication here perceived as hostile is apologized-for. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From jhellenthal at dataix.net Tue Dec 30 01:38:07 2014 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 29 Dec 2014 19:38:07 -0600 Subject: Charter ARP Leak In-Reply-To: <54A1FE18.6050100@cox.net> References: <28388313.750.1419874023962.JavaMail.root@benjamin.baylink.com> <54A1FE18.6050100@cox.net> Message-ID: Well sure they are subnets :-) of 0.0.0.0/4 range: 0.0.0.0 > 15.255.255.255 range b10: 0 > 268435455 range b16: 0x0 > 0xfffffff hosts: 268435456 prefixlen: 4 mask: 240.0.0.0 Doubt anyone should ever describe them as such unless they own all that space though. May God rest their soul if they do. > On Dec 29, 2014, at 19:21, Larry Sheldon wrote: > > On 12/29/2014 11:35, Brett Frankenberger wrote: >> On Mon, Dec 29, 2014 at 12:27:04PM -0500, Jay Ashworth wrote: >>>> >>>> Valdis, you are correct. What your seeing is caused by multiple IP >>>> blocks being assigned to the same CMTS interface. >>> >>> Am I incorrect, though, in believing that ARP packets should only be visible >>> within a broadcast domain, >> >> broadcast domain != subnet > > It surprises me that in this day and age, in a forum like this that has an active thread about kids being taught archaic concepts, we see language like "broadcast domain != subnet" and a perceived need to explain it. > > [no longer germane material deleted to reduce excess baggage charges] > >> int ethernet 0/0 >> ip address 10.0.0.1 255.255.0.0 >> ip address 11.0.0.1 255.255.0.0 secondary >> ip address 12.0.0.1 255.255.0.0 secondary >> >> The broadcast domain will have ARP broadcasts for all three subnets. > > This are not "subnets"! They are IP addresses in three different IP networks. > >> Doing it over a CMTS doesn't change that. > > Communication here perceived as hostile is apologized-for. > > > -- > The unique Characteristics of System Administrators: > > The fact that they are infallible; and, > > The fact that they learn from their mistakes. > > > Quis custodiet ipsos custodes -- Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal at DataIX.net JJH48-ARIN From jfbeam at gmail.com Tue Dec 30 04:32:40 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 29 Dec 2014 23:32:40 -0500 Subject: Charter ARP Leak In-Reply-To: <0F11A49202723141A08215952768DA36D31A001E@ORD2MBX05F.mex05.mlsrvr.com> References: <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> <54A195D4.4000503@davidcoulson.net> <0F11A49202723141A08215952768DA36D31A001E@ORD2MBX05F.mex05.mlsrvr.com> Message-ID: On Mon, 29 Dec 2014 17:41:45 -0500, Corey Touchet wrote: > We'll I would for one be very interested if the 8 ARP packets a second > count against the caps. Depends on where and what counters they probe. I would assume they look at "unicast" fields, so it wouldn't counted. (of course, *I* would use netflow accounting, but I care about my data being accurate.) --Ricky From larrysheldon at cox.net Tue Dec 30 04:47:48 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 29 Dec 2014 22:47:48 -0600 Subject: Charter ARP Leak In-Reply-To: References: <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> <54A195D4.4000503@davidcoulson.net> <0F11A49202723141A08215952768DA36D31A001E@ORD2MBX05F.mex05.mlsrvr.com> Message-ID: <54A22E74.5080803@cox.net> On 12/29/2014 22:32, Ricky Beam wrote: > On Mon, 29 Dec 2014 17:41:45 -0500, Corey Touchet > wrote: > >> We'll I would for one be very interested if the 8 ARP packets a second >> count against the caps. > > Depends on where and what counters they probe. I would assume they look > at "unicast" fields, so it wouldn't counted. (of course, *I* would use > netflow accounting, but I care about my data being accurate.) I probably should know--what kind of packets get counted? All? TCP & UDP? ICMP? BDU's? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From hannigan at gmail.com Tue Dec 30 05:00:28 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 30 Dec 2014 00:00:28 -0500 Subject: Shapefiles, KMZs, etc. In-Reply-To: <5415638.8048.1419740836373.JavaMail.mhammett@ThunderFuck> References: <5415638.8048.1419740836373.JavaMail.mhammett@ThunderFuck> Message-ID: I like the idea of building on the Telecom Ramblings micro site: http://www.telecomramblings.com/metro-fiber-maps/ Don't forget Greg's Cablemaps, the awesome undersea archive and the gold standard of how to do this IMHO: http://www.cablemap.info/ Best, -M< On Sat, Dec 27, 2014 at 11:27 PM, Mike Hammett wrote: > I'll make sure that Telecom Ramblings gets all public sources I find. They > would also have links to maps that aren't in a spatial format ie: PDFs, > interactive web sites, etc. I'm looking for spatially enabled maps so I can > see them all on the same screen, turn layers on and off, measure builds, > and other GIS type work. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Javier J" > To: "Mike Hammett" > Cc: "NANOG list" > Sent: Saturday, December 27, 2014 8:59:09 PM > Subject: Re: Shapefiles, KMZs, etc. > > > If you have KMZ files you have compiled from public sources, can you make > them available? > > > This would be very useful to have for project I work on from time to time. > > > On Sat, Dec 27, 2014 at 1:00 PM, Mike Hammett < nanog at ics-il.net > wrote: > > > I am looking for shapefiles, KMZs, etc. for networks primarily in the > Midwest, but really throughout the area that is the scope of this list. I > am a small ISP that just happens to know more than your average ISP about > where people are and how to use GIS tools. I use them to help other ISPs > find transport and they may come in handy for some start-up IX work I'm > involved with. They would not go public and I would be willing to sign NDAs > to get them. I have gotten several form public sources, but I may not have > gotten all of the public ones and I have some (but still only a few) > private ones. > > Thank you. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > > > From bedard.phil at gmail.com Tue Dec 30 05:13:02 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 30 Dec 2014 00:13:02 -0500 Subject: Charter ARP Leak In-Reply-To: References: <11705148.752.1419875464156.JavaMail.root@benjamin.baylink.com> <54A195D4.4000503@davidcoulson.net> <0F11A49202723141A08215952768DA36D31A001E@ORD2MBX05F.mex05.mlsrvr.com> Message-ID: <54a2347a.4d97e00a.0a07.6932@mx.google.com> They generally use IPDR on the CMTS for accounting, and I don't believe it counts ARP. Phil -----Original Message----- From: "Ricky Beam" Sent: ‎12/‎29/‎2014 11:34 PM To: "Corey Touchet" Cc: "nanog at nanog.org" Subject: Re: Charter ARP Leak On Mon, 29 Dec 2014 17:41:45 -0500, Corey Touchet wrote: > We'll I would for one be very interested if the 8 ARP packets a second > count against the caps. Depends on where and what counters they probe. I would assume they look at "unicast" fields, so it wouldn't counted. (of course, *I* would use netflow accounting, but I care about my data being accurate.) --Ricky From emille at abccomm.com Mon Dec 29 19:13:52 2014 From: emille at abccomm.com (emille at abccomm.com) Date: Mon, 29 Dec 2014 11:13:52 -0800 Subject: The state of TACACS+ Message-ID: <2addc6320bb9a5c1fbd498a0bb47add0@abccomm.com> I've long since deleted the OP's message, but figured I would share our experiences having been using TACACS+ with our Cisco hardware for a couple of years. Originally deployed for the need and want of controlling multiple users across several devices, and to safely control 3rd party read, or reverse-telnet access to the very few nodes that may need it, without needing to mess around with parser views on every device. To that end it's worked just fine without complaint. Note: We're using shrubbery.net's tac_plus. The per-command authorization does slow some nodes down slightly, but nothing as severe as a few seconds each It does work out to about 1 command per (1000ms / Node to AAA RTT) as you'd expect. Eg; The worst I've seen on a ~200ms link, copy/paste lump-of-config will work out to about the expected 4-5 commands/second. Devices running v15 seem to speed this up somehow, not sure if they multiplex commands under the hood, or if I'm just crazy. I've never looked into it that closely for lack of interest and time. There is a stupid gotcha when dealing with the command authorization in the TACACS configuration. If you permit 'johndoe' a 'show ip bgp .*', and he is also a member of a group with subsequent show commands, the show commands in the 'group' config block are completely ignored. This makes some scenarios tricky. We utilize a local root, unprivileged user with unique credentials across each device. It's possible to configure Cisco's AAA to prevent the local user login while AAA is up / reachable. Generally, we are of the opinion that if our nodes cannot reach the AAA server, we have bigger problems that would necessitate a senior administrator with access to the local root user credentials anyway. Otherwise, a TACACS server can be setup in literally minutes and the configuration required is minuscule and easy to backup safely. A note on the local root user. By far and away, the worst possible scenario is not AAA going down / becoming entirely unreachable, but instead when experiencing network instability. Having experienced this scenario for a few very frustrating hours, the experience is along the lines of; - Enter a pile of commands. Some fail (wile AAA is briefly up), some succeed (while AAA is down). - Swear at your console, and repeat until the problem(s) are resolved. Our workaround was; Add your backup / root user with full privileges to your TACACS backend, with _no_ password. This denies them access when AAA is running as there is no password to authenticate against, but prevents "Authorization failed!" when the AAA server is briefly available in the middle of your diags / trying to resolve the connectivity problem. For the Unix admins; The TACACS binary itself, is awful - It has no status exit codes. The process cannot be monitored or controlled safely by way of something like DJB's daemontools, even with the fg_helper hack - at least I've not managed to succeed to date and have given up. To that end, we have a hacked together script to assist with safely reloading configs and such that parses stdout and stderr to decide what to do. Eg; trying to gracefully restart TACACS with a broken config will cause the daemon to exit - not awesome. All that said, I have heard a lot of praise from an enterprise in my neck of the woods who shelled out for Cisco's TACACS+ VM Appliance. If you have the money it's supposedly worth it especially for the AD hooks. I hope this provides some insight to those that may need it. ________________________________________ From: NANOG [nanog-bounces at nanog.org] On Behalf Of Colton Conor [colton.conor at gmail.com] Sent: Monday, December 29, 2014 9:28 AM To: Michael Douglas Cc: NANOG Subject: Re: The state of TACACS+ Glad to know you can make local access only work if TACAS+ isn't available. However, that still doesn't prevent the employee who know the local username and password to unplug the device from the network, and the use the local password to get in. Still better than our current setup of having one default username and password that everyone knows. On Mon, Dec 29, 2014 at 9:38 AM, Michael Douglas wrote: > In the Cisco world the AAA config is typically set up to try tacacs > first, > and local accounts second. The local account is only usable if > tacacs is > unavailable. Knowledge of the local username/password does not > equate to > full time access with that credential. Also, you would usually > filter the > incoming SSH sessions to only permit a particular management IP > range; the > local credential, or tacacs credential, shouldn't be usable from any > arbitrary network. > > On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor > > wrote: > > > Scott, > > > > Thanks for the response. How do you make sure the failsafe and/or > root > > password that is stored in the device incase remote auth fails > can't be > > accessed without having several employees engaged? Are there any > mechanisms > > for doing so? > > > > My fear would be we would hire an outsourced tech. After a certain > amount > > of time we would have to let this part timer go, and would disabled > his > or > > her username and password in TACAS. However, if that tech still > knows the > > root password they could still remotely login to our network and > cause > > havoc. The thought of having to change the root password on > hundreds of > > devices doesn't sound appealing either every time an employee is > let go. > To > > make matters worse we are using an outsourced firm for some network > > management, so the case of hiring and firing is fairly consistent. > > > > On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms > wrote: > > > > > Colton, > > > > > > Yes, that's the 'normal' way of setting it up. Basically you > still > have > > > to configure a root user, but that user name and password is kept > locked > > up > > > and only accessed in case of catastrophic failure of the remote > > > authentication system. An important note is to make sure that > the fail > > > safe password can't be accessed without having several people > engaged > so > > it > > > can't be used without many people knowing. > > > > > > > > > Scott Helms > > > Vice President of Technology > > > ZCorum > > > (678) 507-5000 > > > -------------------------------- > > > http://twitter.com/kscotthelms > > > -------------------------------- > > > > > > On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor > > > > > wrote: > > > > > >> We are able to implement TACAS+. It is my understanding this a > fairly > > old > > >> protocol, so are you saying there are numerous bugs that still > need to > > be > > >> fixed? > > >> > > >> A question I have is TACAS+ is usually hosted on a server, and > > networking > > >> devices are configured to reach out to the server for > authentication. > My > > >> question is what happens if the device can't reach the server if > the > > >> devices network connection is offline? Our goal with TACAS+ is > to not > > have > > >> any default/saved passwords. Every employee will have their own > username > > >> and password. That way if an employee gets hired/fired, we can > enable > or > > >> disable their account. We are trying to avoid having any > organization > > wide > > >> or network wide default username or password. Is this possible? > Do the > > >> devices keep of log of the last successful username/password > > combinations > > >> that worked incase the device goes offline? > > >> > > >> On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake > > > >> wrote: > > >> > > >> > Picking back up where this left off last year, because I > apparently > > only > > >> > work on TACACS during the holidays :) > > >> > > > >> > > > >> > On 12/30/2013 7:28 PM, Jimmy Hess wrote: > > >> > > > >> >> Even 5 seconds extra for each command may hinder operators, > to the > > >> extent > > >> >> it would be intolerable; shell commands should run almost > > >> >> instantaneously.... this is not a GUI, with an hourglass. > > Real-time > > >> >> responsiveness in a shell is crucial --- which remote auth > should > not > > >> >> change. Sometimes operators paste a buffer with a fair > number of > > >> >> commands, not expecting a second delay between each command > --- a > > >> >> repeated delay, may also break a pasted sequence. > > >> >> > > >> >> It is very possible for two of three auth servers to be > unreachable, > > >> in > > >> >> case of a network break, but that isn't necessary. The > "response > > >> >> timeout" might be 5 seconds, but in reality, there are > cases > where > > >> you > > >> >> would wait longer, and that is tragic, since there are > some > > obvious > > >> >> alternative approaches that would have had results that > would be > > more > > >> >> 'friendly' to the interactive user. > > >> >> > > >> >> (Like remembering which server is working for a while, or > > remembering > > >> >> that all servers are down -- for a while, and having a 50ms > > timeout, > > >> >> with all servers queried in parallel, instead of a 5 > seconds > > >> timeout) > > >> >> > > >> > I think this needs to be part of the specification. > > >> > > > >> > I'm sure the reason they didn't do parallel queries was > because of > > both > > >> > network and CPU load back when the protocol was drafted. But > it > might > > >> be > > >> > good to have local caching of authentication so that can > happen even > > >> when > > >> > servers are down or slow. Authorization could be updated to > send > the > > >> > permissions to the router for local handling. Then if the > server > dies > > >> while > > >> > a session is open only accounting would be affected. > > >> > > > >> > That does increase the vendors/implementors work but it might > be > > doable > > >> in > > >> > phases and with partial support with the clients and servers > > negotiating > > >> > what is possible. The biggest drawback to making things like > this > > >> better > > >> > is you don't gain much except during outages and if you > increase > > >> complexity > > >> > too much you make it wide open for bugs. > > >> > > > >> > Maybe there is a simpler solution that keeps you happy about > > redundancy > > >> > but doesn't increase complexity that much (possibly anycast > tacacs, > > but > > >> the > > >> > session basis of the protocol has always made that not > feasible). > > It's > > >> > possible that one of the L4 protocols Saku Ytti mentioned, > QUIC or > > >> MinimaLT > > >> > would address these problems too. It's possible that if we > did the > > >> > transport with BEEP it would also provide this, but I'm > reading the > > docs > > >> > and I don't think it goes that far in terms of connection > assurance. > > >> > > > >> >> -- > > >> >> -JH > > >> >> > > >> >> > > >> > So, here is my TACACS RFC christmas list: > > >> > > > >> > 1. underlying crypto > > >> > 2. ssh host key authentication - having the router ask tacacs > for > an > > >> > authorized_keys list for rdrake. I'm willing to let this go > because > > >> many > > >> > vendors are finding ways to do key distribution, but I'd still > like > to > > >> have > > >> > a standard (https://code.google.com/p/openssh-lpk/ for how to > do > this > > >> > over LDAP in UNIX) > > >> > 3. authentication and authorization caching and/or something > else > > >> > > > >> > > > >> > > > > > > > > > From nanog at ics-il.net Tue Dec 30 12:27:45 2014 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 30 Dec 2014 06:27:45 -0600 (CST) Subject: Shapefiles, KMZs, etc. In-Reply-To: Message-ID: <23195659.12729.1419942467228.JavaMail.mhammett@ThunderFuck> I think thus far I've send Rob 30 moves\adds\changes for public sources. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Martin Hannigan" To: "Mike Hammett" Cc: "NANOG list" Sent: Monday, December 29, 2014 11:00:28 PM Subject: Re: Shapefiles, KMZs, etc. I like the idea of building on the Telecom Ramblings micro site: http://www.telecomramblings.com/metro-fiber-maps/ Don't forget Greg's Cablemaps, the awesome undersea archive and the gold standard of how to do this IMHO: http://www.cablemap.info/ Best, -M< On Sat, Dec 27, 2014 at 11:27 PM, Mike Hammett < nanog at ics-il.net > wrote: I'll make sure that Telecom Ramblings gets all public sources I find. They would also have links to maps that aren't in a spatial format ie: PDFs, interactive web sites, etc. I'm looking for spatially enabled maps so I can see them all on the same screen, turn layers on and off, measure builds, and other GIS type work. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Javier J" < javier at advancedmachines.us > To: "Mike Hammett" < nanog at ics-il.net > Cc: "NANOG list" < nanog at nanog.org > Sent: Saturday, December 27, 2014 8:59:09 PM Subject: Re: Shapefiles, KMZs, etc. If you have KMZ files you have compiled from public sources, can you make them available? This would be very useful to have for project I work on from time to time. On Sat, Dec 27, 2014 at 1:00 PM, Mike Hammett < nanog at ics-il.net > wrote: I am looking for shapefiles, KMZs, etc. for networks primarily in the Midwest, but really throughout the area that is the scope of this list. I am a small ISP that just happens to know more than your average ISP about where people are and how to use GIS tools. I use them to help other ISPs find transport and they may come in handy for some start-up IX work I'm involved with. They would not go public and I would be willing to sign NDAs to get them. I have gotten several form public sources, but I may not have gotten all of the public ones and I have some (but still only a few) private ones. Thank you. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From skeeve+nanog at eintellegonetworks.com Tue Dec 30 15:05:04 2014 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Wed, 31 Dec 2014 02:05:04 +1100 Subject: Google GCI API Message-ID: Hi all. I've searched high and low on cloud.google.com looking for the Good Cloud Platform Carrier Internet API specifications. Does anyone know where I could find them? Replied Off-list thanks! ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve at eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve experts360: https://expert360.com/profile/d54a9 twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering From brian.cruze at verizon.com Tue Dec 30 21:21:41 2014 From: brian.cruze at verizon.com (Cruze, Brian A) Date: Tue, 30 Dec 2014 16:21:41 -0500 Subject: Homestead.com DNS contact In-Reply-To: References: Message-ID: Looking for someone clueful who's responsible for the below nameservers at Homestead: meeney.homestead.com. eeney.homestead.com. Contact off list please. Danke... From notify at marcinkurek.com Wed Dec 31 12:08:15 2014 From: notify at marcinkurek.com (Marcin Kurek) Date: Wed, 31 Dec 2014 13:08:15 +0100 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A3E6C7.7070406@gmail.com> References: <54A3E6C7.7070406@gmail.com> Message-ID: <54A3E72F.20801@marcinkurek.com> Hi everyone, I'm reading Randy's Zhang BGP Design and Implementation and I found following guidelines about designing RR-based MPLS VPN architecture: - Partition RRs - Move RRs out of the forwarding path - Use a high-end processor with maximum memory - Use peer groups - Tune RR routers for improved performance. Since the book is a bit outdated (2004) I'm curious if these rules still apply to modern SP networks. What would be the reasoning behind keeping RRs out of the forwarding path? Is it only a matter of performance and stability? Thanks, Marcin From cb.list6 at gmail.com Wed Dec 31 12:15:40 2014 From: cb.list6 at gmail.com (Ca By) Date: Wed, 31 Dec 2014 04:15:40 -0800 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A3E72F.20801@marcinkurek.com> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> Message-ID: On Wednesday, December 31, 2014, Marcin Kurek wrote: > Hi everyone, > > I'm reading Randy's Zhang BGP Design and Implementation and I found > following guidelines about designing RR-based MPLS VPN architecture: > - Partition RRs > - Move RRs out of the forwarding path > - Use a high-end processor with maximum memory > - Use peer groups > - Tune RR routers for improved performance. > > Since the book is a bit outdated (2004) I'm curious if these rules still > apply to modern SP networks. > What would be the reasoning behind keeping RRs out of the forwarding path? > Is it only a matter of performance and stability? > > Thanks, > Marcin > Correct, these ideas are MOSTLY rooted in old school router limitations. Ymmv. Look for facts in the replies you get, not unsubstantiated opinions. There is no technical reason to have a bgp rr out of path on a hardware based forwarding router that has sufficient control plane capacity to run bgp. CB From nick at foobar.org Wed Dec 31 13:09:40 2014 From: nick at foobar.org (Nick Hilliard) Date: Wed, 31 Dec 2014 13:09:40 +0000 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A3E72F.20801@marcinkurek.com> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> Message-ID: <54A3F594.1090504@foobar.org> On 31/12/2014 12:08, Marcin Kurek wrote: > I'm reading Randy's Zhang BGP Design and Implementation and I found > following guidelines about designing RR-based MPLS VPN architecture: > - Partition RRs > - Move RRs out of the forwarding path > - Use a high-end processor with maximum memory > - Use peer groups > - Tune RR routers for improved performance. > > Since the book is a bit outdated (2004) I'm curious if these rules still > apply to modern SP networks. arguably more so now than ever, but you can always run RRs inline in the forwarding path if you want to. Taking RRs out of the forwarding plane means that you can keep your overall routing architecture simpler and more consistent, and adding/removing different forwarding hardware means that you don't really need to do much with the RR configuration. The larger router vendors all have virtualised RR implementations these days (XRv/CSR1k, vRR, AlcaLu, etc), which means that you can get to run your RRs on standard x86 hardware platforms using normal hypervisors. This wasn't the case in 2004. The pricing and licensing for virtual RR images from the normal vendors hasn't settled down into workable models yet but that's only a matter of time, particularly given that open source routing stacks are going to start seriously impinging on this market segment in the next couple of years. Nick From welisson at conectcor.com.br Wed Dec 31 13:22:54 2014 From: welisson at conectcor.com.br (Welisson) Date: Wed, 31 Dec 2014 11:22:54 -0200 Subject: Contact domain messagelabs.com Message-ID: <54A3F8AE.80900@conectcor.com.br> Hello Guys, So, is there anyone responsible by domain messagelabs.com here at list? I'm trying contact them , but no successful. Tks and Happy Holidays Welisson Tomé From clay584 at gmail.com Wed Dec 31 03:39:39 2014 From: clay584 at gmail.com (Clay Curtis) Date: Tue, 30 Dec 2014 22:39:39 -0500 Subject: The state of TACACS+ Message-ID: Far too much discussion on this IMO. If you're that paranoid about it, just use the nuclear launch keys approach. Create the local account password, split it, give half of it to one party, half to the other. Then two separate parties must be engaged to use the account. Done. Sincerely, Clay Curtis ------------------------------------------------------------------------------------ Glad to know you can make local access only work if TACAS+ isn't available. However, that still doesn't prevent the employee who know the local username and password to unplug the device from the network, and the use the local password to get in. Still better than our current setup of having one default username and password that everyone knows. On Mon, Dec 29, 2014 at 9:38 AM, Michael Douglas wrote: > In the Cisco world the AAA config is typically set up to try tacacs > first, > and local accounts second. The local account is only usable if > tacacs is > unavailable. Knowledge of the local username/password does not > equate to > full time access with that credential. Also, you would usually > filter the > incoming SSH sessions to only permit a particular management IP > range; the > local credential, or tacacs credential, shouldn't be usable from any > arbitrary network. > > On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor > > wrote: > > > Scott, > > > > Thanks for the response. How do you make sure the failsafe and/or > root > > password that is stored in the device incase remote auth fails > can't be > > accessed without having several employees engaged? Are there any > mechanisms > > for doing so? > > > > My fear would be we would hire an outsourced tech. After a certain > amount > > of time we would have to let this part timer go, and would disabled > his > or > > her username and password in TACAS. However, if that tech still > knows the > > root password they could still remotely login to our network and > cause > > havoc. The thought of having to change the root password on > hundreds of > > devices doesn't sound appealing either every time an employee is > let go. > To > > make matters worse we are using an outsourced firm for some network > > management, so the case of hiring and firing is fairly consistent. > > > > On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms > wrote: > > > > > Colton, > > > > > > Yes, that's the 'normal' way of setting it up. Basically you > still > have > > > to configure a root user, but that user name and password is kept > locked > > up > > > and only accessed in case of catastrophic failure of the remote > > > authentication system. An important note is to make sure that > the fail > > > safe password can't be accessed without having several people > engaged > so > > it > > > can't be used without many people knowing. > > > > > > > > > Scott Helms > > > Vice President of Technology > > > ZCorum > > > (678) 507-5000 > > > -------------------------------- > > > http://twitter.com/kscotthelms > > > -------------------------------- > > > > > > On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor > > > > > wrote: > > > > > >> We are able to implement TACAS+. It is my understanding this a > fairly > > old > > >> protocol, so are you saying there are numerous bugs that still > need to > > be > > >> fixed? > > >> > > >> A question I have is TACAS+ is usually hosted on a server, and > > networking > > >> devices are configured to reach out to the server for > authentication. > My > > >> question is what happens if the device can't reach the server if > the > > >> devices network connection is offline? Our goal with TACAS+ is > to not > > have > > >> any default/saved passwords. Every employee will have their own > username > > >> and password. That way if an employee gets hired/fired, we can > enable > or > > >> disable their account. We are trying to avoid having any > organization > > wide > > >> or network wide default username or password. Is this possible? > Do the > > >> devices keep of log of the last successful username/password > > combinations > > >> that worked incase the device goes offline? > > >> > > >> On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake > > > >> wrote: > > >> > > >> > Picking back up where this left off last year, because I > apparently > > only > > >> > work on TACACS during the holidays :) > > >> > > > >> > > > >> > On 12/30/2013 7:28 PM, Jimmy Hess wrote: > > >> > > > >> >> Even 5 seconds extra for each command may hinder operators, > to the > > >> extent > > >> >> it would be intolerable; shell commands should run almost > > >> >> instantaneously.... this is not a GUI, with an hourglass. > > Real-time > > >> >> responsiveness in a shell is crucial --- which remote auth > should > not > > >> >> change. Sometimes operators paste a buffer with a fair > number of > > >> >> commands, not expecti... From joelja at bogus.com Wed Dec 31 16:01:55 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 31 Dec 2014 08:01:55 -0800 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A3E72F.20801@marcinkurek.com> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> Message-ID: <54A41DF3.3030402@bogus.com> On 12/31/14 4:08 AM, Marcin Kurek wrote: > Hi everyone, > > I'm reading Randy's Zhang BGP Design and Implementation and I found > following guidelines about designing RR-based MPLS VPN architecture: > - Partition RRs > - Move RRs out of the forwarding path I'd find it odd if the RR were the nexthop for any signficant traffic, in recent deployments I've done there's no fib to speak of excepting igp routes installed on the RR itself. > - Use a high-end processor with maximum memory bgp addpath kicked up the memory requirements of the RR considerably when we deployed it. > - Use peer groups > - Tune RR routers for improved performance. > > Since the book is a bit outdated (2004) I'm curious if these rules > still apply to modern SP networks. > What would be the reasoning behind keeping RRs out of the forwarding > path? Is it only a matter of performance and stability? > > Thanks, > Marcin > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 221 bytes Desc: OpenPGP digital signature URL: From cra at WPI.EDU Wed Dec 31 17:05:40 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 31 Dec 2014 12:05:40 -0500 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A3E72F.20801@marcinkurek.com> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> Message-ID: <20141231170539.GL18618@angus.ind.WPI.EDU> On Wed, Dec 31, 2014 at 01:08:15PM +0100, Marcin Kurek wrote: > Hi everyone, > > I'm reading Randy's Zhang BGP Design and Implementation and I found > following guidelines about designing RR-based MPLS VPN architecture: > - Partition RRs > - Move RRs out of the forwarding path > - Use a high-end processor with maximum memory > - Use peer groups > - Tune RR routers for improved performance. > > Since the book is a bit outdated (2004) I'm curious if these rules > still apply to modern SP networks. > What would be the reasoning behind keeping RRs out of the forwarding > path? Is it only a matter of performance and stability? When they say "move RRs out of the forwarding path", they could mean "don't force all traffic through the RRs". These are two different things. Naive configurations could end up causing all VPN traffic to go through the RRs (e.g. setting next-hop-self on all reflected routes) whereas more correct configurations don't do that--but there may be some traffic that natrually flows through the same routers that are the RRs, via an MPLS LSP for example. That latter is fine in many cases, the former is not. E.g. I would argue that a P-router can be an RR if desired. From saku at ytti.fi Wed Dec 31 17:49:39 2014 From: saku at ytti.fi (Saku Ytti) Date: Wed, 31 Dec 2014 19:49:39 +0200 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <20141231170539.GL18618@angus.ind.WPI.EDU> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> <20141231170539.GL18618@angus.ind.WPI.EDU> Message-ID: <20141231174939.GA7481@pob.ytti.fi> On (2014-12-31 12:05 -0500), Chuck Anderson wrote: Hey, > are the RRs, via an MPLS LSP for example. That latter is fine in many > cases, the former is not. E.g. I would argue that a P-router can be > an RR if desired. There is no compelling advantage. No budget is too thin for 3 gray NPE-G1, if they are, maybe network engineers without borders can help you. There are some compelling disadvantages, my current and previous employer both have experienced VPN AFI BGP UPDATE crashing whole box (infact whole cluster of 3 VPN reflectors, at once). Trying to achieve 0 outages is silly and impossible, reducing outage impact is often simple and cheap, sometimes not done, when only failure modes considered are physical (HW, fibre, electricity...) failures, rather than the more common modes (pilot and software). -- ++ytti From jeff.tantsura at ericsson.com Wed Dec 31 19:14:46 2014 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Wed, 31 Dec 2014 19:14:46 +0000 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <20141231170539.GL18618@angus.ind.WPI.EDU> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com>,<20141231170539.GL18618@angus.ind.WPI.EDU> Message-ID: <694A65FF-37EC-40F5-921F-377E88AA6BCF@ericsson.com> Hi, Right, one is when besides forwarding packets a router also functioning as a RR, another - when RR sets NH to itself and hence forces all the traffic to pass thru the router in fast path. Keep in mind - some architectures, such as seamless MPLS would require a RR to be in the fast path. There are some other cases where it could be a requirement. I'd advice to look into vRR space - price/performance looks quite good. Wrt open source implementations - if you are looking into relatively basic feature set (v4/v6 unicast/vpn) reliability is not of main concern and of course- there are hands and brains to support it - could be a viable approach. Might you be looking into more complex feature set - EVPN, BGP-LS, FS, enhanced route refresh, etc, highly optimized code wrt update rate/ number of peers supported - most probably you'd end up with a commercial implementation. Hope this helps Regards, Jeff > On Dec 31, 2014, at 9:08 AM, Chuck Anderson wrote: > >> On Wed, Dec 31, 2014 at 01:08:15PM +0100, Marcin Kurek wrote: >> Hi everyone, >> >> I'm reading Randy's Zhang BGP Design and Implementation and I found >> following guidelines about designing RR-based MPLS VPN architecture: >> - Partition RRs >> - Move RRs out of the forwarding path >> - Use a high-end processor with maximum memory >> - Use peer groups >> - Tune RR routers for improved performance. >> >> Since the book is a bit outdated (2004) I'm curious if these rules >> still apply to modern SP networks. >> What would be the reasoning behind keeping RRs out of the forwarding >> path? Is it only a matter of performance and stability? > > When they say "move RRs out of the forwarding path", they could mean > "don't force all traffic through the RRs". These are two different > things. Naive configurations could end up causing all VPN traffic to > go through the RRs (e.g. setting next-hop-self on all reflected > routes) whereas more correct configurations don't do that--but there > may be some traffic that natrually flows through the same routers that > are the RRs, via an MPLS LSP for example. That latter is fine in many > cases, the former is not. E.g. I would argue that a P-router can be > an RR if desired.