From joelja at bogus.com Mon Feb 1 06:17:39 2016 From: joelja at bogus.com (joel jaeggli) Date: Sun, 31 Jan 2016 22:17:39 -0800 Subject: Dear Windstream engineers In-Reply-To: <005C3894-72C9-4B38-81A2-76235BE9A8B4@ipifony.com> References: <56AC4139.4030107@cbcast.com> <005C3894-72C9-4B38-81A2-76235BE9A8B4@ipifony.com> Message-ID: <56AEF883.7080802@bogus.com> On 1/30/16 2:29 PM, Matthew D. Hardeman wrote: > You offer this service to your customers, don?t you? ;-) source based RTBH requires urpf, which while generally available may have practical limitations on implementation. > Seriously, it?s a good question. Most IP transit providers offering BGP services do offer RTBH. > >> On Jan 29, 2016, at 10:51 PM, George Skorup wrote: >> >> Why doesn't Windstream have RTBH for their BGP customers? It cannot be impossible to implement. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From saku at ytti.fi Mon Feb 1 09:08:51 2016 From: saku at ytti.fi (Saku Ytti) Date: Mon, 1 Feb 2016 11:08:51 +0200 Subject: Dear Windstream engineers In-Reply-To: <56AEF883.7080802@bogus.com> References: <56AC4139.4030107@cbcast.com> <005C3894-72C9-4B38-81A2-76235BE9A8B4@ipifony.com> <56AEF883.7080802@bogus.com> Message-ID: On 1 February 2016 at 08:17, joel jaeggli wrote: Hey, > source based RTBH requires urpf, which while generally available may > have practical limitations on implementation. I'd say uRPF/loose is one way to do it on some platforms. In JunOS for longest time it was not possible, and in default config it still is not, as source route pointing to null does not fail uRPF/loose check. However JunOS has had ~always SCU (I compare it to QPPB in CSCO) which can be used to implement source based RTBH, without use of uRPF. It likely out-performs uRPF/loose massively, as you don't have to do two LPM lookups. -- ++ytti From Michael.Hoyt at windstream.com Mon Feb 1 01:08:26 2016 From: Michael.Hoyt at windstream.com (Hoyt, Michael) Date: Mon, 1 Feb 2016 01:08:26 +0000 Subject: Dear Windstream engineers Message-ID: <5C75E6F641662342843DD2F28FA76958194E3C81@CWWAPP477.windstream.com> Yes, of course Windstream supports RTBH, we have a standard community and have had for years, depending on which legacy AS you connect with us the tag you would have been given might be different. Our current AS7029 standard for RTBH is to tag your route(s) with 4506 and we will black hole the tagged route at our edge. As you know Windstream (like many ISP's) is a collection of legacy AS's, we have merged all our legacy AS's into one and now operate as only AS7029 but you might still be peering as a customer with us using one of our 12 former AS's, such as Paetec AS1785, as we employed the alias knob to integrate our AS's to not have to "touch" every BGP customer, this is pretty standard practice as we work on consolidating our IP Networks. We have been and continue to work through our standardization of our BGP policy and have not yet reached all of the thousands of BGP speaking customers. We have been working with our Product, Sales and Sales Engineering organizations to get the word out to our customers about our *new* standard communities and policies and the fact that ultimately we would like all our BGP customers to peer with AS7029 and convert from using one of the many legacy AS's we operated under. Please contact me directly (Michael.Hoyt at windstream.com) and/or Paul Thompson (paul.thompson at windstream.com) and we can involve your account team and work with any Windstream BGP customer to ensure you can tag your routes with our new standards and receive your desired route propagation results. Thanks, Mike Hoyt VP, IP Engineering Windstream Communications ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. From maxtul at netassist.ua Mon Feb 1 12:48:43 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 1 Feb 2016 14:48:43 +0200 Subject: Team Cymru BGP bogon status ??? In-Reply-To: References: Message-ID: <56AF542B.5030303@netassist.ua> Looks good for me too (Ukraine/Kiev). But no IPv6, only IPv4. Is it a bug or a feature? ;) On 31.01.16 19:23, Tom Storey wrote: > Working just fine from Virgin Media. > > On 31 January 2016 at 17:19, Daniel Corbe wrote: >>> On Jan 31, 2016, at 11:44 AM, Matthew Huff wrote: >>> >>> Starting around 7:17 am EST, we lost our IPv4 & IPv6 BGP connections to Cymru. We have two connections in both IPv4 and IPv6 on both of our two routers. On each router one connection is stuck in active, the other providing 0 prefixes. I can?t get to http://www.team-cymru.org from either work or home. Anyone know what?s up? >> >> Their website appears to be down as well. I?m guessing network outage? Maybe something more sinister? >> >> > From trelane at trelane.net Tue Feb 2 03:25:03 2016 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 1 Feb 2016 22:25:03 -0500 Subject: Ongoing AT&T Wireless (LTE) IPv6 Reachability Issues Message-ID: I attempted to use normal channels today at AT&T (enduser support) to address a reachability issue with AT&T Wireless to http://jimtest.delong.com. This left AT&T's enduser support utterly befuddled. Sadly, this is still the company that famously claimed ""We don't support reaching web sites over IP". Since I'm paying for the entire Internet, and not half of it, and enduser support is too ignorant to understand the problem, I'm wondering if someone here can tell me when AT&T Wireless intends to fix their LTE network since ARIN is out of IPv4 address space. Shame on you AT&T Wireless. Both T-Mobile and Verizon support IPv6. Andrew From ESundberg at nitelusa.com Tue Feb 2 04:34:57 2016 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Tue, 2 Feb 2016 04:34:57 +0000 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <1449532297.20094.44.camel@karl> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> Message-ID: <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> Just some follow up on this one. I have also posed in the C-NSP list Yes you do need to have this kit to have serial console, No a normal USB-DB9 Console adapters do not work. Here are some pictures of the ASR920 Console kit A920-CONS-KIT-S The Adapter Plugs in the Top Left USB Console Port and we have it wired up to a Perle IOLAN SCS48C console server using a rollover cable. Here are some pictures of it, since I can only find a brief mention of it in all the cisco docs. http://imgur.com/a/w8clL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Karl Auer Sent: Monday, December 07, 2015 5:52 PM To: nanog at nanog.org Subject: Re: Devices with only USB console port - Need a Console Server Solution On Mon, 2015-12-07 at 15:23 -0800, Dylan Ambauen wrote: > Any USB to serial converter will probably do it. The OP is looking to integrate a device with a console server. "Any converter" would be a mistake. You can get these things for two dollars, but you get what you pay for. Maybe seek suggestions here as to converters others have used with success, the main criteria for success being robustness, reliability and build quality. Personally in this situation I would get the approved, vendor supplied, genuine part. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From morrowc.lists at gmail.com Tue Feb 2 04:56:55 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Feb 2016 23:56:55 -0500 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> Message-ID: seems like a total improvement.... swapping 1 well known, simple cable for 2... hurray progress? On Mon, Feb 1, 2016 at 11:34 PM, Erik Sundberg wrote: > Just some follow up on this one. I have also posed in the C-NSP list > > Yes you do need to have this kit to have serial console, No a normal USB-DB9 Console adapters do not work. > > Here are some pictures of the ASR920 Console kit A920-CONS-KIT-S > > The Adapter Plugs in the Top Left USB Console Port and we have it wired up to a Perle IOLAN SCS48C console server using a rollover cable. > > Here are some pictures of it, since I can only find a brief mention of it in all the cisco docs. > > http://imgur.com/a/w8clL > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Karl Auer > Sent: Monday, December 07, 2015 5:52 PM > To: nanog at nanog.org > Subject: Re: Devices with only USB console port - Need a Console Server Solution > > On Mon, 2015-12-07 at 15:23 -0800, Dylan Ambauen wrote: >> Any USB to serial converter will probably do it. > > The OP is looking to integrate a device with a console server. "Any converter" would be a mistake. You can get these things for two dollars, but you get what you pay for. > > Maybe seek suggestions here as to converters others have used with success, the main criteria for success being robustness, reliability and build quality. > > Personally in this situation I would get the approved, vendor supplied, genuine part. > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 > > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From bjorn at mork.no Tue Feb 2 10:02:10 2016 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 02 Feb 2016 11:02:10 +0100 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> (Erik Sundberg's message of "Tue, 2 Feb 2016 04:34:57 +0000") References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> Message-ID: <87mvrj77ml.fsf@nemi.mork.no> Erik Sundberg writes: > Just some follow up on this one. I have also posed in the C-NSP list > > Yes you do need to have this kit to have serial console, No a normal > USB-DB9 Console adapters do not work. Which could be because the driver for that particular Console adapters is missing. Or even that the driver is there, but recognizing specific Cisco device IDs only. As you are probably aware, there are no standard USB-DB9 Console adapters. They are all vendor specific. But the cloning industry has created a few semi-standards based on specific chipsets. > Here are some pictures of the ASR920 Console kit A920-CONS-KIT-S No inside pictures :) Assuming that this is really an USB device, and that the console port is really an USB host port, it would be useful to know the USB decriptors of the device. You wouldn't be willing to connect it to a Linux PC and run "lsusb -vd", would you? Bj?rn From bjorn at mork.no Tue Feb 2 10:16:14 2016 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 02 Feb 2016 11:16:14 +0100 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: (Christopher Morrow's message of "Mon, 1 Feb 2016 23:56:55 -0500") References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> Message-ID: <87io2776z5.fsf@nemi.mork.no> Christopher Morrow writes: > seems like a total improvement.... swapping 1 well known, simple cable for 2... > > hurray progress? The USB port is probably cheaper than anything else. And it gives them more flexibility. No need for both an RS232 and Ethernet console port. The USB port can be both, depending only on driver/application support on the router. And you have other options as well. Wifi console maybe? Or a direct USB-USB cable (with the necessary logic to appear as a device to both ends). It is also possible to create USB only console servers, if the market wants that. Avoiding two RS232 conversions per console port will save enough capacitors to run a Tesla. Whether these alternatives become available is of course up to Cisco. You do need the driver and application support on the router. Time will show what they come up with. Bj?rn From ESundberg at nitelusa.com Tue Feb 2 11:13:15 2016 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Tue, 2 Feb 2016 11:13:15 +0000 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <87io2776z5.fsf@nemi.mork.no> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> <87io2776z5.fsf@nemi.mork.no> Message-ID: <495D0934DA46854A9CA758393724D5902D7476F6@NI-MAIL02.nii.ads> Here are the pictures again. http://imgur.com/a/w8clL -----Original Message----- From: Bj?rn Mork [mailto:bjorn at mork.no] Sent: Tuesday, February 02, 2016 4:16 AM To: Christopher Morrow Cc: Erik Sundberg ; nanog at nanog.org Subject: Re: Devices with only USB console port - Need a Console Server Solution Christopher Morrow writes: > seems like a total improvement.... swapping 1 well known, simple cable for 2... > > hurray progress? The USB port is probably cheaper than anything else. And it gives them more flexibility. No need for both an RS232 and Ethernet console port. The USB port can be both, depending only on driver/application support on the router. And you have other options as well. Wifi console maybe? Or a direct USB-USB cable (with the necessary logic to appear as a device to both ends). It is also possible to create USB only console servers, if the market wants that. Avoiding two RS232 conversions per console port will save enough capacitors to run a Tesla. Whether these alternatives become available is of course up to Cisco. You do need the driver and application support on the router. Time will show what they come up with. Bj?rn ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From colton.conor at gmail.com Tue Feb 2 13:42:08 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 2 Feb 2016 07:42:08 -0600 Subject: Cable Operator List Message-ID: Are there any mailing lists out there dedicated for cable/MSO type operators? From dcorbe at hammerfiber.com Tue Feb 2 13:48:06 2016 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 2 Feb 2016 08:48:06 -0500 Subject: Cable Operator List In-Reply-To: References: Message-ID: > On Feb 2, 2016, at 8:42 AM, Colton Conor wrote: > > Are there any mailing lists out there dedicated for cable/MSO type > operators? > I'm curious about this too. I?m not a cable operator (in that I haven?t successfully registered for a cable franchise yet) but I do operate a docsis network and I?ve successfully negotiated the treacherous waters of obtaining and providing content to my users. I?m still a bit green behind the ears but I could probably offer some measure of assistance if you have a specific question. -Daniel From bhatton at htva.net Tue Feb 2 13:53:36 2016 From: bhatton at htva.net (Benjamin Hatton) Date: Tue, 2 Feb 2016 08:53:36 -0500 Subject: Cable Operator List In-Reply-To: References: Message-ID: The Cable TV List (http://cabletvlist.com/) doesn't get much traffic, but it does have some quality people on it that can answer most CATV questions. It is heavily weighted on the TV side, so most things are related to transport gear, IRDs, and distribution equipment. I am unaware of any DOCSIS specific mailing lists, but if anyone out there does know of one I would like to know about it as well. On Tue, Feb 2, 2016 at 8:48 AM, Daniel Corbe wrote: > > > On Feb 2, 2016, at 8:42 AM, Colton Conor wrote: > > > > Are there any mailing lists out there dedicated for cable/MSO type > > operators? > > > > I'm curious about this too. > > I?m not a cable operator (in that I haven?t successfully registered for a > cable franchise yet) but I do operate a docsis network and I?ve > successfully negotiated the treacherous waters of obtaining and providing > content to my users. > > I?m still a bit green behind the ears but I could probably offer some > measure of assistance if you have a specific question. > > -Daniel > > -- *Ben Hatton* Network Engineer Haefele TV Inc. bhatton at htva.net www.htva.net From aplato at coldwater.org Tue Feb 2 13:58:49 2016 From: aplato at coldwater.org (Art Plato) Date: Tue, 2 Feb 2016 08:58:49 -0500 (EST) Subject: Cable Operator List In-Reply-To: References: Message-ID: <1377894.153.1454421531755.JavaMail.art@DQT6ZQ1> Don't believe they have a mailing list, but this is a good source for technical issues on the modem/cmts side. Very helpful forum. Pulled me out of the weeds a couple of times. www.docsis.org. ----- Original Message ----- From: "Benjamin Hatton" To: nanog at nanog.org Sent: Tuesday, February 2, 2016 8:53:36 AM Subject: Re: Cable Operator List The Cable TV List (http://cabletvlist.com/) doesn't get much traffic, but it does have some quality people on it that can answer most CATV questions. It is heavily weighted on the TV side, so most things are related to transport gear, IRDs, and distribution equipment. I am unaware of any DOCSIS specific mailing lists, but if anyone out there does know of one I would like to know about it as well. On Tue, Feb 2, 2016 at 8:48 AM, Daniel Corbe wrote: > > > On Feb 2, 2016, at 8:42 AM, Colton Conor wrote: > > > > Are there any mailing lists out there dedicated for cable/MSO type > > operators? > > > > I'm curious about this too. > > I?m not a cable operator (in that I haven?t successfully registered for a > cable franchise yet) but I do operate a docsis network and I?ve > successfully negotiated the treacherous waters of obtaining and providing > content to my users. > > I?m still a bit green behind the ears but I could probably offer some > measure of assistance if you have a specific question. > > -Daniel > > -- *Ben Hatton* Network Engineer Haefele TV Inc. bhatton at htva.net www.htva.net From colton.conor at gmail.com Tue Feb 2 14:00:26 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 2 Feb 2016 08:00:26 -0600 Subject: Cable Operator List In-Reply-To: References: Message-ID: Well, maybe NANOG's not a bad place for this post then! I would like to know more about the data-only side of CMTS systems, and who the main vendors are. We have MDU properties where there is either old inside CAT3 phone wire, or coaxial cable. We have looked and are very familiar with the multiple technologies that work over phone lines namely VDSL2 and G.FAST. However, using the coaxial cable seems to be a much better solution than using the phone wires. So I am looking for compacts, low cost CMTS systems. Based on the specs, I am looking for something at least DOCSIS 3.0 capable, with at least 16X4 output. Something with the ability to upgrade to software upgrade to DOCSIS 3.1 would be nice, but I doubt that would be a low cost solution. Whats out there for small operators that don't want a large chassis based system to feed an entire town with. So far I have found the http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to retail for under $5000. On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe wrote: > > > On Feb 2, 2016, at 8:42 AM, Colton Conor wrote: > > > > Are there any mailing lists out there dedicated for cable/MSO type > > operators? > > > > I'm curious about this too. > > I?m not a cable operator (in that I haven?t successfully registered for a > cable franchise yet) but I do operate a docsis network and I?ve > successfully negotiated the treacherous waters of obtaining and providing > content to my users. > > I?m still a bit green behind the ears but I could probably offer some > measure of assistance if you have a specific question. > > -Daniel > > From johnstong at westmancom.com Tue Feb 2 14:01:53 2016 From: johnstong at westmancom.com (Graham Johnston) Date: Tue, 2 Feb 2016 14:01:53 +0000 Subject: Cable Operator List In-Reply-To: References: Message-ID: <49EE1A35457387418410F97564A3752B01894003B5@MSG6.westman.int> Those that are SCTE members have access to the SCTE mailing list. Like the comments about the CableTV list, it is often focused on plant/transport/RF more than Docsis but there are good DOCSIS knowledgeable people on the list too that answer questions. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com ??think green; don't print this email. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor Sent: Tuesday, February 02, 2016 7:42 AM To: NANOG Subject: Cable Operator List Are there any mailing lists out there dedicated for cable/MSO type operators? From jared at puck.Nether.net Tue Feb 2 14:03:38 2016 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 2 Feb 2016 09:03:38 -0500 Subject: Cable Operator List In-Reply-To: References: Message-ID: <20160202140338.GF25581@puck.nether.net> On Tue, Feb 02, 2016 at 08:53:36AM -0500, Benjamin Hatton wrote: > The Cable TV List (http://cabletvlist.com/) doesn't get much traffic, but > it does have some quality people on it that can answer most CATV > questions. It is heavily weighted on the TV side, so most things are > related to transport gear, IRDs, and distribution equipment. I am unaware > of any DOCSIS specific mailing lists, but if anyone out there does know of > one I would like to know about it as well. In the past I was asked to create the cisco-ubr list to cover some of these types of things. https://puck.nether.net/pipermail/cisco-ubr/ I can create a catv or similar list easily. good name suggestions welcome. - 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 jared at puck.Nether.net Tue Feb 2 14:11:48 2016 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 2 Feb 2016 09:11:48 -0500 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> Message-ID: <20160202141148.GG25581@puck.nether.net> On Mon, Dec 07, 2015 at 10:15:28PM +0000, Erik Sundberg wrote: > We have one of these nice new and fancy Cisco ASR920-24SZ, just realized it doesn't have an RJ45 Console port only USB. When we deploy devices at our pop we wire the console port to a terminal\console server, well that doesn't work for a usb console device. > > So what is everyone doing for out of band management via the console when it's a usb only device? > Is there something I am missing? Likely not. I've seen most equipment makers start to ignore serial console. The default these appears to be moving to a uBoot/PXE style network setup where you push an image and such via TFTP/DHCP into the device. > Is there a console server for USB? I've not seen one show up, but there are other devices like this which the DIY industry has started to build: http://freetserv.github.io/ I have a side business i'm tinkering with and these are open source hardware. If there is interest, I'd be willing to build these in volume and drive the cost down. It would not be difficult to do a giant USB hub that was similar. > Does cisco make an USB to RJ45 Jack adapter? Yes, but I'm always concerned about what boot messages are lost or things you can't quite do properly (like send break, etc) to get into the device as you're waiting for the USB to initalize, driver to present to OS, etc.. Maybe they spent more time thinking about this than I am aware, but it's something I've not had a proper solution explained to me for. - 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 johnstong at westmancom.com Tue Feb 2 14:12:12 2016 From: johnstong at westmancom.com (Graham Johnston) Date: Tue, 2 Feb 2016 14:12:12 +0000 Subject: Cable Operator List In-Reply-To: References: Message-ID: <49EE1A35457387418410F97564A3752B01894003FC@MSG6.westman.int> Colton, It really depends on what features you are after. I've demo'd one of the small 1/2RU C-DOCSIS CMTSs, and they certainly work. For us though it was a non-starter as we needed support for DSG and it didn't have it. If all you are after is basic internet connectivity there is Pico Digital, Vecima, Sumavision, as well as others. Many of the C-DOCSIS CMTSs seem either only support, or are more often meant to support layer 2 operations where the routing happens upstream from the CMTS. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com ??think green; don't print this email. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor Sent: Tuesday, February 02, 2016 8:00 AM To: Daniel Corbe Cc: NANOG Subject: Re: Cable Operator List Well, maybe NANOG's not a bad place for this post then! I would like to know more about the data-only side of CMTS systems, and who the main vendors are. We have MDU properties where there is either old inside CAT3 phone wire, or coaxial cable. We have looked and are very familiar with the multiple technologies that work over phone lines namely VDSL2 and G.FAST. However, using the coaxial cable seems to be a much better solution than using the phone wires. So I am looking for compacts, low cost CMTS systems. Based on the specs, I am looking for something at least DOCSIS 3.0 capable, with at least 16X4 output. Something with the ability to upgrade to software upgrade to DOCSIS 3.1 would be nice, but I doubt that would be a low cost solution. Whats out there for small operators that don't want a large chassis based system to feed an entire town with. So far I have found the http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to retail for under $5000. On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe wrote: > > > On Feb 2, 2016, at 8:42 AM, Colton Conor wrote: > > > > Are there any mailing lists out there dedicated for cable/MSO type > > operators? > > > > I'm curious about this too. > > I?m not a cable operator (in that I haven?t successfully registered for a > cable franchise yet) but I do operate a docsis network and I?ve > successfully negotiated the treacherous waters of obtaining and providing > content to my users. > > I?m still a bit green behind the ears but I could probably offer some > measure of assistance if you have a specific question. > > -Daniel > > From dcorbe at hammerfiber.com Tue Feb 2 14:17:41 2016 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 2 Feb 2016 09:17:41 -0500 Subject: Cable Operator List In-Reply-To: References: Message-ID: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> Hey Colton, We?re using small 16 channel CMTS systems for residential MDUs and colocating them directly on premise inside of wiring closets and then connecting them by metro ethernet. We?ve had great successes so far with this model. There?s lots of CMTS vendors. There?s tons of used Motorola BSR 64Ks on the market, but be aware of the lack of useful IPv6 features (like prefix delegation) in older software releases. If you buy a box and want to run 7.x or 8.x, you?ll need to relicense your downstream and upstream channels at some additional arbitrary fixed cost. I?m personally fond of these things: http://picodigital.com/product-details.php?ID=miniCMTS200a You can only bond 16 channels together max though because that?s all the box supports and you can?t bond across boxes; however, these things are less than 4 grand if you buy them in bulk so they?re really fucking easy to just spam everywhere. Blonder Tongue makes a pizza-box style CMTS too: http://www.blondertongue.com/shop-by-department/catv/ip-over-coax/docsis/euro-docsis/ As does Harmonics: http://harmonicinc.com/product/cable-edge/nsg-exo All three are based on the same chipset, so the real differentiation is price and firmware features. Then there?s Cisco. The UBR is a popular platform. And pretty soon there?s going to be a glut of UBR10Ks on the Market because Comcast is busy ripping their UBRs out of production because they?re upgrading their cable plant to the CBR platform. Then the Arris C4, if you have deep pockets, is a modern version of the BSR: http://www.arris.com/products/c4-cmts/ > On Feb 2, 2016, at 9:00 AM, Colton Conor wrote: > > Well, maybe NANOG's not a bad place for this post then! I would like to know more about the data-only side of CMTS systems, and who the main vendors are. > > We have MDU properties where there is either old inside CAT3 phone wire, or coaxial cable. We have looked and are very familiar with the multiple technologies that work over phone lines namely VDSL2 and G.FAST. However, using the coaxial cable seems to be a much better solution than using the phone wires. > > So I am looking for compacts, low cost CMTS systems. Based on the specs, I am looking for something at least DOCSIS 3.0 capable, with at least 16X4 output. Something with the ability to upgrade to software upgrade to DOCSIS 3.1 would be nice, but I doubt that would be a low cost solution. > > Whats out there for small operators that don't want a large chassis based system to feed an entire town with. > > So far I have found the http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to retail for under $5000. > > > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe wrote: > > > On Feb 2, 2016, at 8:42 AM, Colton Conor wrote: > > > > Are there any mailing lists out there dedicated for cable/MSO type > > operators? > > > > I'm curious about this too. > > I?m not a cable operator (in that I haven?t successfully registered for a cable franchise yet) but I do operate a docsis network and I?ve successfully negotiated the treacherous waters of obtaining and providing content to my users. > > I?m still a bit green behind the ears but I could probably offer some measure of assistance if you have a specific question. > > -Daniel > > From nick at foobar.org Tue Feb 2 14:26:14 2016 From: nick at foobar.org (Nick Hilliard) Date: Tue, 02 Feb 2016 14:26:14 +0000 Subject: Cable Operator List In-Reply-To: <20160202140338.GF25581@puck.nether.net> References: <20160202140338.GF25581@puck.nether.net> Message-ID: <56B0BC86.5070705@foobar.org> Jared Mauch wrote: > I can create a catv or similar list easily. good name > suggestions welcome. "There are only two hard things in Computer Science: cache invalidation and naming things". docsis-nsp? Nick From chaim.rieger at gmail.com Tue Feb 2 14:43:13 2016 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Tue, 2 Feb 2016 06:43:13 -0800 Subject: Cogent issues ? Message-ID: <5410DFE5-1000-4561-AFD9-487E4E0B8799@gmail.com> Having difficulty reaching various Cogent colos, in the US. (Atlanta, LA, DC). From jared at puck.Nether.net Tue Feb 2 14:51:13 2016 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 2 Feb 2016 09:51:13 -0500 Subject: Cable Operator List In-Reply-To: <56B0BC86.5070705@foobar.org> References: <20160202140338.GF25581@puck.nether.net> <56B0BC86.5070705@foobar.org> Message-ID: <20160202145113.GH25581@puck.nether.net> On Tue, Feb 02, 2016 at 02:26:14PM +0000, Nick Hilliard wrote: > Jared Mauch wrote: > > I can create a catv or similar list easily. good name > > suggestions welcome. > > "There are only two hard things in Computer Science: cache invalidation > and naming things". https://xkcd.com/910/ > docsis-nsp? Done. https://puck.nether.net/mailman/listinfo/docsis-nsp - 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 kraig at enguity.com Tue Feb 2 15:02:55 2016 From: kraig at enguity.com (Kraig Beahn) Date: Tue, 2 Feb 2016 10:02:55 -0500 Subject: Cogent issues ? In-Reply-To: <5410DFE5-1000-4561-AFD9-487E4E0B8799@gmail.com> References: <5410DFE5-1000-4561-AFD9-487E4E0B8799@gmail.com> Message-ID: We have test facilities, specifically in the Cogent Atlanta Colo - and are not seeing any reachability issues at this point. Tested via Cogent from alternate networks. Will keep an eye on it tho... On Tue, Feb 2, 2016 at 9:43 AM, Chaim Rieger wrote: > Having difficulty reaching various Cogent colos, in the US. (Atlanta, LA, > DC). From chaim.rieger at gmail.com Tue Feb 2 15:10:51 2016 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Tue, 2 Feb 2016 07:10:51 -0800 Subject: Cogent issues ? In-Reply-To: References: <5410DFE5-1000-4561-AFD9-487E4E0B8799@gmail.com> Message-ID: <4D1DC5DB-DAED-4D28-8A0F-D96065A22D3F@gmail.com> All seems well now AS51307 was unable to reach into cogent for about 7-10 minutes. > On Feb 2, 2016, at 7:02 AM, Kraig Beahn wrote: > > We have test facilities, specifically in the Cogent Atlanta Colo - and are not seeing any reachability issues at this point. Tested via Cogent from alternate networks. > > Will keep an eye on it tho... > > > > > > On Tue, Feb 2, 2016 at 9:43 AM, Chaim Rieger > wrote: > Having difficulty reaching various Cogent colos, in the US. (Atlanta, LA, DC). > From colton.conor at gmail.com Tue Feb 2 15:43:37 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 2 Feb 2016 09:43:37 -0600 Subject: Cable Operator List In-Reply-To: <49EE1A35457387418410F97564A3752B01894003FC@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B01894003FC@MSG6.westman.int> Message-ID: Graham, What is DSG? Yes, I am really looking for a CMTS to perform layer 2 just as our DSLAMs and GPON do today. All layer 3 will be upstream. I would want to handle DHCP upstream, but have the CMTS insert Option 82 if that is a feature. Not sure what specific CMTS stuff you need. On Tue, Feb 2, 2016 at 8:12 AM, Graham Johnston wrote: > Colton, > > It really depends on what features you are after. I've demo'd one of the > small 1/2RU C-DOCSIS CMTSs, and they certainly work. For us though it was > a non-starter as we needed support for DSG and it didn't have it. If all > you are after is basic internet connectivity there is Pico Digital, Vecima, > Sumavision, as well as others. Many of the C-DOCSIS CMTSs seem either only > support, or are more often meant to support layer 2 operations where the > routing happens upstream from the CMTS. > > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > ??think green; don't print this email. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor > Sent: Tuesday, February 02, 2016 8:00 AM > To: Daniel Corbe > Cc: NANOG > Subject: Re: Cable Operator List > > Well, maybe NANOG's not a bad place for this post then! I would like to > know more about the data-only side of CMTS systems, and who the main > vendors are. > > We have MDU properties where there is either old inside CAT3 phone wire, or > coaxial cable. We have looked and are very familiar with the multiple > technologies that work over phone lines namely VDSL2 and G.FAST. However, > using the coaxial cable seems to be a much better solution than using the > phone wires. > > So I am looking for compacts, low cost CMTS systems. Based on the specs, I > am looking for something at least DOCSIS 3.0 capable, with at least 16X4 > output. Something with the ability to upgrade to software upgrade to DOCSIS > 3.1 would be nice, but I doubt that would be a low cost solution. > > Whats out there for small operators that don't want a large chassis based > system to feed an entire town with. > > So far I have found the > http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to > retail for under $5000. > > > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe > wrote: > > > > > > On Feb 2, 2016, at 8:42 AM, Colton Conor > wrote: > > > > > > Are there any mailing lists out there dedicated for cable/MSO type > > > operators? > > > > > > > I'm curious about this too. > > > > I?m not a cable operator (in that I haven?t successfully registered for a > > cable franchise yet) but I do operate a docsis network and I?ve > > successfully negotiated the treacherous waters of obtaining and providing > > content to my users. > > > > I?m still a bit green behind the ears but I could probably offer some > > measure of assistance if you have a specific question. > > > > -Daniel > > > > > From colton.conor at gmail.com Tue Feb 2 15:47:53 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 2 Feb 2016 09:47:53 -0600 Subject: Cable Operator List In-Reply-To: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> Message-ID: Daniel, Thanks for the wealth of information. What kind of speeds are you offering? How many customers are you putting on one of these boxes? What modems are you using? I would honestly perfer something that was hardened for outdoor use. Think garden style apartments. What is the best for something like that? Comparing DOCIS 3 to VDSL2, the modems and CMTS appear to be more cost effective per customer. G.FAST I have not seen pricing on, but I expect it to be more than VDSL2. Any reasons not to use EURO DOCSIS in the USA? Looks like it offers more speeds by using fatter channels. We don't plan on offering TV, but even if we did couldn't we just start the channels at a higher range, and still use EURO DOCSIS? On Tue, Feb 2, 2016 at 8:17 AM, Daniel Corbe wrote: > Hey Colton, > > We?re using small 16 channel CMTS systems for residential MDUs and > colocating them directly on premise inside of wiring closets and then > connecting them by metro ethernet. We?ve had great successes so far with > this model. > > There?s lots of CMTS vendors. > > There?s tons of used Motorola BSR 64Ks on the market, but be aware of the > lack of useful IPv6 features (like prefix delegation) in older software > releases. If you buy a box and want to run 7.x or 8.x, you?ll need to > relicense your downstream and upstream channels at some additional > arbitrary fixed cost. > > I?m personally fond of these things: > > http://picodigital.com/product-details.php?ID=miniCMTS200a > > You can only bond 16 channels together max though because that?s all the > box supports and you can?t bond across boxes; however, these things are > less than 4 grand if you buy them in bulk so they?re really fucking easy to > just spam everywhere. > > Blonder Tongue makes a pizza-box style CMTS too: > > > http://www.blondertongue.com/shop-by-department/catv/ip-over-coax/docsis/euro-docsis/ > > As does Harmonics: > > http://harmonicinc.com/product/cable-edge/nsg-exo > > All three are based on the same chipset, so the real differentiation is > price and firmware features. > > Then there?s Cisco. > > The UBR is a popular platform. And pretty soon there?s going to be a glut > of UBR10Ks on the Market because Comcast is busy ripping their UBRs out of > production because they?re upgrading their cable plant to the CBR platform. > > Then the Arris C4, if you have deep pockets, is a modern version of the > BSR: > > http://www.arris.com/products/c4-cmts/ > > > > On Feb 2, 2016, at 9:00 AM, Colton Conor wrote: > > > > Well, maybe NANOG's not a bad place for this post then! I would like to > know more about the data-only side of CMTS systems, and who the main > vendors are. > > > > We have MDU properties where there is either old inside CAT3 phone wire, > or coaxial cable. We have looked and are very familiar with the multiple > technologies that work over phone lines namely VDSL2 and G.FAST. However, > using the coaxial cable seems to be a much better solution than using the > phone wires. > > > > So I am looking for compacts, low cost CMTS systems. Based on the specs, > I am looking for something at least DOCSIS 3.0 capable, with at least 16X4 > output. Something with the ability to upgrade to software upgrade to DOCSIS > 3.1 would be nice, but I doubt that would be a low cost solution. > > > > Whats out there for small operators that don't want a large chassis > based system to feed an entire town with. > > > > So far I have found the > http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to > retail for under $5000. > > > > > > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe > wrote: > > > > > On Feb 2, 2016, at 8:42 AM, Colton Conor > wrote: > > > > > > Are there any mailing lists out there dedicated for cable/MSO type > > > operators? > > > > > > > I'm curious about this too. > > > > I?m not a cable operator (in that I haven?t successfully registered for > a cable franchise yet) but I do operate a docsis network and I?ve > successfully negotiated the treacherous waters of obtaining and providing > content to my users. > > > > I?m still a bit green behind the ears but I could probably offer some > measure of assistance if you have a specific question. > > > > -Daniel > > > > > > From khelms at zcorum.com Tue Feb 2 15:58:39 2016 From: khelms at zcorum.com (Scott Helms) Date: Tue, 2 Feb 2016 10:58:39 -0500 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> Message-ID: The biggest reason to not do EuroDOCSIS is logistics and dealing with various TAC organizations versus a pretty small increase in per channel performance (but not per hertz). I'd pretty strongly recommend against it, just because you're going to run into issues ranging from buying modems, to dealing with node vendors, to finding people who can do basic stuff like plant balancing. You wouldn't think it would matter, but it throws people off to see that extra channel bandwidth. My 2 cents, buy CMTS/CCAP gear that's upgradeable to D3.1, ie CBR8, E6000, or the big Casa unit, for the time being shoot for 24 channel downstream bonding groups (24 * ~37mbps - overhead) which yields about 740 mbps usable. That's plenty for most nodes, especially since you're not offering video you can have many bonding groups since channel space isn't a problem. Scott Helms Chief Technology Officer ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Feb 2, 2016 at 10:47 AM, Colton Conor wrote: > Daniel, > > Thanks for the wealth of information. What kind of speeds are you offering? > How many customers are you putting on one of these boxes? What modems are > you using? > > I would honestly perfer something that was hardened for outdoor use. Think > garden style apartments. What is the best for something like that? > > Comparing DOCIS 3 to VDSL2, the modems and CMTS appear to be more cost > effective per customer. G.FAST I have not seen pricing on, but I expect it > to be more than VDSL2. > > Any reasons not to use EURO DOCSIS in the USA? Looks like it offers more > speeds by using fatter channels. We don't plan on offering TV, but even if > we did couldn't we just start the channels at a higher range, and still use > EURO DOCSIS? > > On Tue, Feb 2, 2016 at 8:17 AM, Daniel Corbe > wrote: > > > Hey Colton, > > > > We?re using small 16 channel CMTS systems for residential MDUs and > > colocating them directly on premise inside of wiring closets and then > > connecting them by metro ethernet. We?ve had great successes so far with > > this model. > > > > There?s lots of CMTS vendors. > > > > There?s tons of used Motorola BSR 64Ks on the market, but be aware of the > > lack of useful IPv6 features (like prefix delegation) in older software > > releases. If you buy a box and want to run 7.x or 8.x, you?ll need to > > relicense your downstream and upstream channels at some additional > > arbitrary fixed cost. > > > > I?m personally fond of these things: > > > > http://picodigital.com/product-details.php?ID=miniCMTS200a > > > > You can only bond 16 channels together max though because that?s all the > > box supports and you can?t bond across boxes; however, these things are > > less than 4 grand if you buy them in bulk so they?re really fucking easy > to > > just spam everywhere. > > > > Blonder Tongue makes a pizza-box style CMTS too: > > > > > > > http://www.blondertongue.com/shop-by-department/catv/ip-over-coax/docsis/euro-docsis/ > > > > As does Harmonics: > > > > http://harmonicinc.com/product/cable-edge/nsg-exo > > > > All three are based on the same chipset, so the real differentiation is > > price and firmware features. > > > > Then there?s Cisco. > > > > The UBR is a popular platform. And pretty soon there?s going to be a > glut > > of UBR10Ks on the Market because Comcast is busy ripping their UBRs out > of > > production because they?re upgrading their cable plant to the CBR > platform. > > > > Then the Arris C4, if you have deep pockets, is a modern version of the > > BSR: > > > > http://www.arris.com/products/c4-cmts/ > > > > > > > On Feb 2, 2016, at 9:00 AM, Colton Conor > wrote: > > > > > > Well, maybe NANOG's not a bad place for this post then! I would like to > > know more about the data-only side of CMTS systems, and who the main > > vendors are. > > > > > > We have MDU properties where there is either old inside CAT3 phone > wire, > > or coaxial cable. We have looked and are very familiar with the multiple > > technologies that work over phone lines namely VDSL2 and G.FAST. However, > > using the coaxial cable seems to be a much better solution than using the > > phone wires. > > > > > > So I am looking for compacts, low cost CMTS systems. Based on the > specs, > > I am looking for something at least DOCSIS 3.0 capable, with at least > 16X4 > > output. Something with the ability to upgrade to software upgrade to > DOCSIS > > 3.1 would be nice, but I doubt that would be a low cost solution. > > > > > > Whats out there for small operators that don't want a large chassis > > based system to feed an entire town with. > > > > > > So far I have found the > > http://picodigital.com/product-details.php?ID=miniCMTS200a which seems > to > > retail for under $5000. > > > > > > > > > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe > > wrote: > > > > > > > On Feb 2, 2016, at 8:42 AM, Colton Conor > > wrote: > > > > > > > > Are there any mailing lists out there dedicated for cable/MSO type > > > > operators? > > > > > > > > > > I'm curious about this too. > > > > > > I?m not a cable operator (in that I haven?t successfully registered for > > a cable franchise yet) but I do operate a docsis network and I?ve > > successfully negotiated the treacherous waters of obtaining and providing > > content to my users. > > > > > > I?m still a bit green behind the ears but I could probably offer some > > measure of assistance if you have a specific question. > > > > > > -Daniel > > > > > > > > > > > From khelms at zcorum.com Tue Feb 2 16:03:16 2016 From: khelms at zcorum.com (Scott Helms) Date: Tue, 2 Feb 2016 11:03:16 -0500 Subject: Cable Operator List In-Reply-To: References: <49EE1A35457387418410F97564A3752B01894003FC@MSG6.westman.int> Message-ID: Colton, You're only going to find very small, old, or not certified (usually still very small) CMTSs that only do layer 2. All of the major vendors are doing layer 3 because we've found out over time that not doing it is more problematic. Having said that, if you're looking for a more ONT/DSLAM type of install there is a new type of CMTSs that look at lot like traditional telco DLC/BLC deployments. https://intx15.ncta.com/wp-content/uploads/2015/05/17-Remote-PHY.pdf The remote PHY+MAC boxes are basically mini-CMTSs and they typically rely on something upstream handling layer 3. The remote PHY boxes are different as they don't even do a complete layer 2 and instead forward DOCSIS frames back to a centralized CMTS/CCAP. Scott Helms Chief Technology Officer ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Feb 2, 2016 at 10:43 AM, Colton Conor wrote: > Graham, > > What is DSG? Yes, I am really looking for a CMTS to perform layer 2 just as > our DSLAMs and GPON do today. All layer 3 will be upstream. I would want to > handle DHCP upstream, but have the CMTS insert Option 82 if that is a > feature. Not sure what specific CMTS stuff you need. > > On Tue, Feb 2, 2016 at 8:12 AM, Graham Johnston > wrote: > > > Colton, > > > > It really depends on what features you are after. I've demo'd one of the > > small 1/2RU C-DOCSIS CMTSs, and they certainly work. For us though it > was > > a non-starter as we needed support for DSG and it didn't have it. If all > > you are after is basic internet connectivity there is Pico Digital, > Vecima, > > Sumavision, as well as others. Many of the C-DOCSIS CMTSs seem either > only > > support, or are more often meant to support layer 2 operations where the > > routing happens upstream from the CMTS. > > > > Graham Johnston > > Network Planner > > Westman Communications Group > > 204.717.2829 > > johnstong at westmancom.com > > ??think green; don't print this email. > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor > > Sent: Tuesday, February 02, 2016 8:00 AM > > To: Daniel Corbe > > Cc: NANOG > > Subject: Re: Cable Operator List > > > > Well, maybe NANOG's not a bad place for this post then! I would like to > > know more about the data-only side of CMTS systems, and who the main > > vendors are. > > > > We have MDU properties where there is either old inside CAT3 phone wire, > or > > coaxial cable. We have looked and are very familiar with the multiple > > technologies that work over phone lines namely VDSL2 and G.FAST. However, > > using the coaxial cable seems to be a much better solution than using the > > phone wires. > > > > So I am looking for compacts, low cost CMTS systems. Based on the specs, > I > > am looking for something at least DOCSIS 3.0 capable, with at least 16X4 > > output. Something with the ability to upgrade to software upgrade to > DOCSIS > > 3.1 would be nice, but I doubt that would be a low cost solution. > > > > Whats out there for small operators that don't want a large chassis based > > system to feed an entire town with. > > > > So far I have found the > > http://picodigital.com/product-details.php?ID=miniCMTS200a which seems > to > > retail for under $5000. > > > > > > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe > > wrote: > > > > > > > > > On Feb 2, 2016, at 8:42 AM, Colton Conor > > wrote: > > > > > > > > Are there any mailing lists out there dedicated for cable/MSO type > > > > operators? > > > > > > > > > > I'm curious about this too. > > > > > > I?m not a cable operator (in that I haven?t successfully registered > for a > > > cable franchise yet) but I do operate a docsis network and I?ve > > > successfully negotiated the treacherous waters of obtaining and > providing > > > content to my users. > > > > > > I?m still a bit green behind the ears but I could probably offer some > > > measure of assistance if you have a specific question. > > > > > > -Daniel > > > > > > > > > From dcorbe at hammerfiber.com Tue Feb 2 16:08:45 2016 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 2 Feb 2016 11:08:45 -0500 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> Message-ID: <01D9311C-36A5-4514-AB19-B5D092720ABE@hammerfiber.com> In-line below. -Daniel > On Feb 2, 2016, at 10:47 AM, Colton Conor wrote: > > Daniel, > > Thanks for the wealth of information. What kind of speeds are you offering? How many customers are you putting on one of these boxes? What modems are you using? We?re using Arris modems because we have the least amount of signal-related issues with them. We?ve had to drop to 64qam because portions of our network runs over the air and we run into SNR issues at 256qam on the downstream. This is important because it basically halves our available bandwidth. I quoted some figures below based strictly on channel width but the reality of our situation is we see about half those numbers. We don?t cap our users. Every modem on the network can bond all 16 channels if it?s capable and it wants to. We?ve got one plan. Which means they can burst as high as they want within reason. Every month we?re in contact with the top talkers in each sector and we ask them to curb their bandwidth usage. With this model we get about 50 to 75 users to every 16 channel CMTS we deploy. In a 200 unit apartment building, we?d deploy 4 to 6 boxes. On a 2000 user airbox station, we?d deploy about 20 of them. There?s also one more consideration. Our TV service is IPTV. Since we?re not pumping DVB-C or DVB-S signal down the cable, we?ve got nearly a full Ghz of spectrum with which to use for DOCSIS channels. This gives us a lot of flexibility to just add additional CMTS when we begin to run into capacity issues. > > I would honestly perfer something that was hardened for outdoor use. Think garden style apartments. What is the best for something like that? I?m sure someone somewhere makes an environmentally hardened CMTS but I?m not currently aware of any at the moment. Most of my equipment sits in wiring closets. > Any reasons not to use EURO DOCSIS in the USA? Looks like it offers more speeds by using fatter channels. We don't plan on offering TV, but even if we did couldn't we just start the channels at a higher range, and still use EURO DOCSIS? EuroDOCSIS would be a better option if you?re looking to maximize bits per hertz and have enough spectrum to play with. You get 8Mhz channels for 6Mhz channels which means at 16 channels you?ll get 800Mbit/sec to a modem instead of 640Mbit. > > On Tue, Feb 2, 2016 at 8:17 AM, Daniel Corbe wrote: > Hey Colton, > > We?re using small 16 channel CMTS systems for residential MDUs and colocating them directly on premise inside of wiring closets and then connecting them by metro ethernet. We?ve had great successes so far with this model. > > There?s lots of CMTS vendors. > > There?s tons of used Motorola BSR 64Ks on the market, but be aware of the lack of useful IPv6 features (like prefix delegation) in older software releases. If you buy a box and want to run 7.x or 8.x, you?ll need to relicense your downstream and upstream channels at some additional arbitrary fixed cost. > > I?m personally fond of these things: > > http://picodigital.com/product-details.php?ID=miniCMTS200a > > You can only bond 16 channels together max though because that?s all the box supports and you can?t bond across boxes; however, these things are less than 4 grand if you buy them in bulk so they?re really fucking easy to just spam everywhere. > > Blonder Tongue makes a pizza-box style CMTS too: > > http://www.blondertongue.com/shop-by-department/catv/ip-over-coax/docsis/euro-docsis/ > > As does Harmonics: > > http://harmonicinc.com/product/cable-edge/nsg-exo > > All three are based on the same chipset, so the real differentiation is price and firmware features. > > Then there?s Cisco. > > The UBR is a popular platform. And pretty soon there?s going to be a glut of UBR10Ks on the Market because Comcast is busy ripping their UBRs out of production because they?re upgrading their cable plant to the CBR platform. > > Then the Arris C4, if you have deep pockets, is a modern version of the BSR: > > http://www.arris.com/products/c4-cmts/ > > > > On Feb 2, 2016, at 9:00 AM, Colton Conor wrote: > > > > Well, maybe NANOG's not a bad place for this post then! I would like to know more about the data-only side of CMTS systems, and who the main vendors are. > > > > We have MDU properties where there is either old inside CAT3 phone wire, or coaxial cable. We have looked and are very familiar with the multiple technologies that work over phone lines namely VDSL2 and G.FAST. However, using the coaxial cable seems to be a much better solution than using the phone wires. > > > > So I am looking for compacts, low cost CMTS systems. Based on the specs, I am looking for something at least DOCSIS 3.0 capable, with at least 16X4 output. Something with the ability to upgrade to software upgrade to DOCSIS 3.1 would be nice, but I doubt that would be a low cost solution. > > > > Whats out there for small operators that don't want a large chassis based system to feed an entire town with. > > > > So far I have found the http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to retail for under $5000. > > > > > > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe wrote: > > > > > On Feb 2, 2016, at 8:42 AM, Colton Conor wrote: > > > > > > Are there any mailing lists out there dedicated for cable/MSO type > > > operators? > > > > > > > I'm curious about this too. > > > > I?m not a cable operator (in that I haven?t successfully registered for a cable franchise yet) but I do operate a docsis network and I?ve successfully negotiated the treacherous waters of obtaining and providing content to my users. > > > > I?m still a bit green behind the ears but I could probably offer some measure of assistance if you have a specific question. > > > > -Daniel > > > > > > From nick at foobar.org Tue Feb 2 16:12:45 2016 From: nick at foobar.org (Nick Hilliard) Date: Tue, 02 Feb 2016 16:12:45 +0000 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> Message-ID: <56B0D57D.6070107@foobar.org> Scott Helms wrote: > My 2 cents, buy CMTS/CCAP gear that's upgradeable to D3.1, ie CBR8, E6000, > or the big Casa unit, for the time being shoot for 24 channel downstream > bonding groups (24 * ~37mbps - overhead) which yields about 740 mbps > usable. the good thing about eurodocsis is that it gives you a full 1gig usable if you're bonding over 24 channels. There's a natural residential performance plateau at 1G because 10G NICs haven't really made it to the consumer level yet, which means that if you want to hand off > 1gbit, things become more expensive and/or more complicated. Nick From edwin.mallette at gmail.com Tue Feb 2 16:14:27 2016 From: edwin.mallette at gmail.com (Edwin Mallette) Date: Tue, 02 Feb 2016 11:14:27 -0500 Subject: Cable Operator List In-Reply-To: References: <49EE1A35457387418410F97564A3752B01894003FC@MSG6.westman.int> Message-ID: Hi Colton, For what it sounds like you?re really looking for, a remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) would probably be the good fit for your application. This is certainly not an endorsement, as we haven?t used any remote MAC-PHY devices today. There are a couple players pouring money into products that haven?t really been mentioned yet... 1) Huawei - which initially brought a mini CMTS to market (D3.0, 16x4.) Some C-DOCSIS stuff, so may be feature poor but it doesn?t sound like you really need the boatload of features that are in a classic full-size CMTS anyway. Not sure what?s going on with their D3.1 remote MAC-PHY general availability is either. 2) Gainspeed - D3.0/D3.1 product (not sure about where the generally availability of their product lines are) but if you happen to be a Juniper customer, they partner with Gainspeed so it can be easy to get engaged with them. Ed On 2/2/16, 11:03 AM, "NANOG on behalf of Scott Helms" wrote: >Colton, > >You're only going to find very small, old, or not certified (usually still >very small) CMTSs that only do layer 2. All of the major vendors are >doing >layer 3 because we've found out over time that not doing it is more >problematic. Having said that, if you're looking for a more ONT/DSLAM >type >of install there is a new type of CMTSs that look at lot like traditional >telco DLC/BLC deployments. > >https://intx15.ncta.com/wp-content/uploads/2015/05/17-Remote-PHY.pdf > >The remote PHY+MAC boxes are basically mini-CMTSs and they typically rely >on something upstream handling layer 3. The remote PHY boxes are >different >as they don't even do a complete layer 2 and instead forward DOCSIS frames >back to a centralized CMTS/CCAP. > > > >Scott Helms >Chief Technology Officer >ZCorum >(678) 507-5000 >-------------------------------- >http://twitter.com/kscotthelms >-------------------------------- > >On Tue, Feb 2, 2016 at 10:43 AM, Colton Conor >wrote: > >> Graham, >> >> What is DSG? Yes, I am really looking for a CMTS to perform layer 2 >>just as >> our DSLAMs and GPON do today. All layer 3 will be upstream. I would >>want to >> handle DHCP upstream, but have the CMTS insert Option 82 if that is a >> feature. Not sure what specific CMTS stuff you need. >> >> On Tue, Feb 2, 2016 at 8:12 AM, Graham Johnston >> >> wrote: >> >> > Colton, >> > >> > It really depends on what features you are after. I've demo'd one of >>the >> > small 1/2RU C-DOCSIS CMTSs, and they certainly work. For us though it >> was >> > a non-starter as we needed support for DSG and it didn't have it. If >>all >> > you are after is basic internet connectivity there is Pico Digital, >> Vecima, >> > Sumavision, as well as others. Many of the C-DOCSIS CMTSs seem either >> only >> > support, or are more often meant to support layer 2 operations where >>the >> > routing happens upstream from the CMTS. >> > >> > Graham Johnston >> > Network Planner >> > Westman Communications Group >> > 204.717.2829 >> > johnstong at westmancom.com >> > ??think green; don't print this email. >> > >> > >> > -----Original Message----- >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor >> > Sent: Tuesday, February 02, 2016 8:00 AM >> > To: Daniel Corbe >> > Cc: NANOG >> > Subject: Re: Cable Operator List >> > >> > Well, maybe NANOG's not a bad place for this post then! I would like >>to >> > know more about the data-only side of CMTS systems, and who the main >> > vendors are. >> > >> > We have MDU properties where there is either old inside CAT3 phone >>wire, >> or >> > coaxial cable. We have looked and are very familiar with the multiple >> > technologies that work over phone lines namely VDSL2 and G.FAST. >>However, >> > using the coaxial cable seems to be a much better solution than using >>the >> > phone wires. >> > >> > So I am looking for compacts, low cost CMTS systems. Based on the >>specs, >> I >> > am looking for something at least DOCSIS 3.0 capable, with at least >>16X4 >> > output. Something with the ability to upgrade to software upgrade to >> DOCSIS >> > 3.1 would be nice, but I doubt that would be a low cost solution. >> > >> > Whats out there for small operators that don't want a large chassis >>based >> > system to feed an entire town with. >> > >> > So far I have found the >> > http://picodigital.com/product-details.php?ID=miniCMTS200a which seems >> to >> > retail for under $5000. >> > >> > >> > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe >> > wrote: >> > >> > > >> > > > On Feb 2, 2016, at 8:42 AM, Colton Conor >> > wrote: >> > > > >> > > > Are there any mailing lists out there dedicated for cable/MSO type >> > > > operators? >> > > > >> > > >> > > I'm curious about this too. >> > > >> > > I?m not a cable operator (in that I haven?t successfully registered >> for a >> > > cable franchise yet) but I do operate a docsis network and I?ve >> > > successfully negotiated the treacherous waters of obtaining and >> providing >> > > content to my users. >> > > >> > > I?m still a bit green behind the ears but I could probably offer >>some >> > > measure of assistance if you have a specific question. >> > > >> > > -Daniel >> > > >> > > >> > >> From khelms at zcorum.com Tue Feb 2 16:18:31 2016 From: khelms at zcorum.com (Scott Helms) Date: Tue, 2 Feb 2016 11:18:31 -0500 Subject: Cable Operator List In-Reply-To: <56B0D57D.6070107@foobar.org> References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> Message-ID: Nick, That very small upside for an extreme downside. Trying to hire someone to work on your system with Euro channelization, not to mention buying amplifiers and passives is a huge PITA. I have customers in Europe who decided to do US DOCSIS and they universally wish they had used the local "flavor". Scott Helms Chief Technology Officer ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Feb 2, 2016 at 11:12 AM, Nick Hilliard wrote: > Scott Helms wrote: > > My 2 cents, buy CMTS/CCAP gear that's upgradeable to D3.1, ie CBR8, > E6000, > > or the big Casa unit, for the time being shoot for 24 channel downstream > > bonding groups (24 * ~37mbps - overhead) which yields about 740 mbps > > usable. > > the good thing about eurodocsis is that it gives you a full 1gig usable > if you're bonding over 24 channels. There's a natural residential > performance plateau at 1G because 10G NICs haven't really made it to the > consumer level yet, which means that if you want to hand off > 1gbit, > things become more expensive and/or more complicated. > > Nick > From askoorb+nanog at gmail.com Tue Feb 2 16:21:25 2016 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Tue, 2 Feb 2016 16:21:25 +0000 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> Message-ID: Hi, On 2 February 2016 at 15:47, Colton Conor wrote: > I would honestly perfer something that was hardened for outdoor use. Think > garden style apartments. What is the best for something like that? It depends where you are going to be deploying these things, northern New York state? Arizona? There's a reason curbside cabinets exist. > > Comparing DOCIS 3 to VDSL2, the modems and CMTS appear to be more cost > effective per customer. G.FAST I have not seen pricing on, but I expect it > to be more than VDSL2. > > Any reasons not to use EURO DOCSIS in the USA? Looks like it offers more > speeds by using fatter channels. We don't plan on offering TV, but even if > we did couldn't we just start the channels at a higher range, and still use > EURO DOCSIS? > In the UK, half the country is using EURODOCSIS, half DOCSIS (historical reasons - the original companies had different ideas. I know that Liberty Global - who bought them all - can't wait for the new 3.1 standard where there will be no difference). One problem with using the 'wrong' one is simply around signal leakage. What happens when some fool leaves an unterminated bit of coax lying around? What frequencies is this new areal broadcasting on? Remember, even if the customer is the one who unterminates the cable it's still your problem to detect and fix. You will need to get EURODOCSIS equipment (including CPE) that: -Works on 110v (the EU uses 230v) -Has an FCC sticker rather than a CE sticker -Isn't going to break any FCC rules if used in EURODOCSIS mode -Has support available in North America The key differences are summarised at https://www.excentis.com/blog/differences-between-us-docsis-and-eurodocsis-and-will-docsis-31-eliminate-them. There a a lot more to it than the channel width! On a separate note, remember that G.FAST is extremely sensitive to dodgy wiring and line length. If the local loop length length gets near 500 yards you will be lucky to hit 150Mbps down. Over 500 yards and you will be lucky to hold sync outside of a lab. Alex From Patrick.Darden at p66.com Tue Feb 2 16:25:03 2016 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Tue, 2 Feb 2016 16:25:03 +0000 Subject: RedSeal Off List Message-ID: <192e6977f4da4fadb85eadc5ed0f6cc1@BRTEXMB02.phillips66.net> Could someone from RedSeal contact me off list please? (I think the CTO was a regular on NANOG 2 years ago?) Thanks, --Patrick Darden From Valdis.Kletnieks at vt.edu Tue Feb 2 16:45:33 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 02 Feb 2016 11:45:33 -0500 Subject: Cable Operator List In-Reply-To: <56B0BC86.5070705@foobar.org> References: <20160202140338.GF25581@puck.nether.net> <56B0BC86.5070705@foobar.org> Message-ID: <8646.1454431533@turing-police.cc.vt.edu> On Tue, 02 Feb 2016 14:26:14 +0000, Nick Hilliard said: > Jared Mauch wrote: > > I can create a catv or similar list easily. good name > > suggestions welcome. > > "There are only two hard things in Computer Science: cache invalidation > and naming things". They're only hard because all *other* problems in CS are solved by adding a layer of redirection.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nick at foobar.org Tue Feb 2 17:02:23 2016 From: nick at foobar.org (Nick Hilliard) Date: Tue, 02 Feb 2016 17:02:23 +0000 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> Message-ID: <56B0E11F.60805@foobar.org> Scott Helms wrote: > That very small upside for an extreme downside.Trying to hire someone > to work on your system with Euro channelization, not to mention buying > amplifiers and passives is a huge PITA. ... if your plant is in the US. > I have customers in Europe who > decided to do US DOCSIS and they universally wish they had used the > local "flavor". as you say, eurodocsis works well in europe. 3.1 will be a major improvement when it materialises. Nick From khelms at zcorum.com Tue Feb 2 17:24:38 2016 From: khelms at zcorum.com (Scott Helms) Date: Tue, 2 Feb 2016 12:24:38 -0500 Subject: Cable Operator List In-Reply-To: <56B0E11F.60805@foobar.org> References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: Nick, Absolutely, if your plant is in Europe or one of the other areas (lots of Africa and the middle East is like that) that adopted EuroDOCSIS I'd agree wholeheartedly. I didn't see Colton say where they're located, but all North America is the US flavor so that's what I assume on NANOG. That being said, the best thing that seldom gets mentioned about D3.1 is getting us to unified channelization. Scott Helms wrote: > That very small upside for an extreme downside.Trying to hire someone > to work on your system with Euro channelization, not to mention buying > amplifiers and passives is a huge PITA. ... if your plant is in the US. > I have customers in Europe who > decided to do US DOCSIS and they universally wish they had used the > local "flavor". as you say, eurodocsis works well in europe. 3.1 will be a major improvement when it materialises. Nick From colton.conor at gmail.com Tue Feb 2 18:24:19 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 2 Feb 2016 12:24:19 -0600 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: Yes, we are in the USA. So based on everyones recommendations, I am going to stay far away from EURODOCSIS. I was told be a vendor that Arris and other USA FCC certified cable modems could easily be flashed to EURODOCIS mode, so I did not think the CPE side was that big of a deal (is that even true). I was not aware that there were so many differences besides just the channel width. So, assuming we are talking about DOCSIS only (and not EURODOCSIS), what do you recommend? I like the idea of being able to upgrade to 3.1, but not sure if there are any small systems capable of this? By small I mean something that could feed less than 100 units, and be economical to do. Cable has the advantage of cheap modems, so it's really the CMTS side. Please remember I am only interested in data internet services over this plant. Something that works for garden style layouts where I can bring fiber or coaxial to the side of a garden townhome that has between 4 to 16 units inside of it. The reason I requested a harden outdoor unit is that most all of the garden style properties have both the phone and coaxial drops on the outside of the building. There is no central closet or room. Plus we are in the south, so hardened for the heat exposure makes sense. A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like what I want. I will check into Huawei and Gainspeed. Who else makes these? On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms wrote: > Nick, > > Absolutely, if your plant is in Europe or one of the other areas (lots of > Africa and the middle East is like that) that adopted EuroDOCSIS I'd agree > wholeheartedly. I didn't see Colton say where they're located, but all > North America is the US flavor so that's what I assume on NANOG. > > That being said, the best thing that seldom gets mentioned about D3.1 is > getting us to unified channelization. > Scott Helms wrote: > > That very small upside for an extreme downside.Trying to hire someone > > to work on your system with Euro channelization, not to mention buying > > amplifiers and passives is a huge PITA. > > ... if your plant is in the US. > > > I have customers in Europe who > > decided to do US DOCSIS and they universally wish they had used the > > local "flavor". > > as you say, eurodocsis works well in europe. > > 3.1 will be a major improvement when it materialises. > > Nick > From khelms at zcorum.com Tue Feb 2 18:49:36 2016 From: khelms at zcorum.com (Scott Helms) Date: Tue, 2 Feb 2016 13:49:36 -0500 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: On Tue, Feb 2, 2016 at 1:24 PM, Colton Conor wrote: > Yes, we are in the USA. So based on everyones recommendations, I am going > to stay far away from EURODOCSIS. I was told be a vendor that Arris and > other USA FCC certified cable modems could easily be flashed to EURODOCIS > mode, so I did not think the CPE side was that big of a deal (is that even > true). I was not aware that there were so many differences besides just the > channel width. > I wish this were the case, it would make my life easier. The problem is that there is a diplex filter that prevents the upstream burst from being heard by the downstream receiver and for cost purposes all the D3 and earlier modems have fixed filters. What that means is that a EuroDOCSIS modem can (sometimes) be flashed to use 6MHz channels, but the reverse is NOT true. In any case we don't recommend using Euro modems that are flashed to US standards in production (nor do the vendors) because you'll see much more upstream leakage. > > So, assuming we are talking about DOCSIS only (and not EURODOCSIS), what > do you recommend? I like the idea of being able to upgrade to 3.1, but not > sure if there are any small systems capable of this? By small I mean > something that could feed less than 100 units, and be economical to do. > Cable has the advantage of cheap modems, so it's really the CMTS side. > In that case I'd definitely go with a remote MAC+PHY. That's the only way you're going to get a good price point and decent performance unless you want to use the secondary market, which actually isn't a bad idea right now. A used 7225 with 8x8 blades is pretty cheap, but it's centralized CMTS that would cover ~3k subs. > > Please remember I am only interested in data internet services over this > plant. Something that works for garden style layouts where I can bring > fiber or coaxial to the side of a garden townhome that has between 4 to 16 > units inside of it. The reason I requested a harden outdoor unit is that > most all of the garden style properties have both the phone > and coaxial drops on the outside of the building. There is no central > closet or room. Plus we are in the south, so hardened for the > heat exposure makes sense. > > A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like what > I want. I will check into Huawei and Gainspeed. Who else makes these? > In no particular order, Arris is or will be, Teleste (Euro vendor trying to break into the US), Sumavision, Altera, and ton more I can't remember. Come to one of the SCTE shows (it's in Philadelphia this year) if you want to be deluged with them :) > > > > > > On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms wrote: > >> Nick, >> >> Absolutely, if your plant is in Europe or one of the other areas (lots of >> Africa and the middle East is like that) that adopted EuroDOCSIS I'd agree >> wholeheartedly. I didn't see Colton say where they're located, but all >> North America is the US flavor so that's what I assume on NANOG. >> >> That being said, the best thing that seldom gets mentioned about D3.1 is >> getting us to unified channelization. >> Scott Helms wrote: >> > That very small upside for an extreme downside.Trying to hire someone >> > to work on your system with Euro channelization, not to mention buying >> > amplifiers and passives is a huge PITA. >> >> ... if your plant is in the US. >> >> > I have customers in Europe who >> > decided to do US DOCSIS and they universally wish they had used the >> > local "flavor". >> >> as you say, eurodocsis works well in europe. >> >> 3.1 will be a major improvement when it materialises. >> >> Nick >> > > From ktims at stargate.ca Tue Feb 2 20:06:38 2016 From: ktims at stargate.ca (Keenan Tims) Date: Tue, 2 Feb 2016 12:06:38 -0800 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <87mvrj77ml.fsf@nemi.mork.no> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> <87mvrj77ml.fsf@nemi.mork.no> Message-ID: <56B10C4E.4030700@stargate.ca> On 2016-02-02 02:02, Bj?rn Mork wrote: > As you are probably aware, there are no standard > USB-DB9 Console adapters. They are all vendor specific. But the > cloning industry has created a few semi-standards based on specific > chipsets. This is not strictly true. There is a Communications Device Class (CDC ACM) defined by the USB-IF that covers basic serial devices and most OSs (even Windows! Though it does require a .inf file anyway) include a driver for it. A rumour I heard recently was that its lack of popularity was a result of Microsoft and Intel not wanting device developers to ignore the advantages of USB and just use CDC to continue using their old-school RS232 protocols for mice or whatever. There are also some good reasons not to use it, such as flow control, strict timing, higher data rates, and added features available with custom chipsets, but it's just fine for a serial console. Exar, Microchip and others make simple and cheap USB-UART chips using CDC ACM, and it's a very common application example for USB microcontrollers. USB console ports are just adding complexity where it offers no advantage. KISS. Keenan From peterl at standingwave.org Tue Feb 2 20:27:23 2016 From: peterl at standingwave.org (Peter Loron) Date: Tue, 02 Feb 2016 12:27:23 -0800 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <20160202141148.GG25581@puck.nether.net> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <20160202141148.GG25581@puck.nether.net> Message-ID: <352c97684c585a53001049942d7492ea@standingwave.org> A possible alternative, although probably not one you'd want to leave in place permanently: http://www.get-console.com/airconsole/ -Pete On 2016-02-02 06:11, Jared Mauch wrote: > On Mon, Dec 07, 2015 at 10:15:28PM +0000, Erik Sundberg wrote: >> We have one of these nice new and fancy Cisco ASR920-24SZ, just >> realized it doesn't have an RJ45 Console port only USB. When we deploy >> devices at our pop we wire the console port to a terminal\console >> server, well that doesn't work for a usb console device. >> >> So what is everyone doing for out of band management via the console >> when it's a usb only device? >> Is there something I am missing? > > Likely not. I've seen most equipment makers start to ignore serial > console. > The default these appears to be moving to a uBoot/PXE style network > setup > where you push an image and such via TFTP/DHCP into the device. > >> Is there a console server for USB? > > I've not seen one show up, but there are other devices like this > which the DIY industry has started to build: > > http://freetserv.github.io/ > > I have a side business i'm tinkering with and these are open source > hardware. If there is interest, I'd be willing to build these in > volume and > drive the cost down. > > It would not be difficult to do a giant USB hub that was similar. > >> Does cisco make an USB to RJ45 Jack adapter? > > Yes, but I'm always concerned about what boot messages are lost > or things you can't quite do properly (like send break, etc) to get > into > the device as you're waiting for the USB to initalize, driver to > present > to OS, etc.. Maybe they spent more time thinking about this than I > am aware, but it's something I've not had a proper solution explained > to me > for. > > - Jared From colton.conor at gmail.com Tue Feb 2 20:31:37 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 2 Feb 2016 14:31:37 -0600 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: Is a remote MAC+PHY the same thing as a Distributed Converged Cable Access Platform (D-CCAP) solution like Huawei is pushing? Is DOCSIS 3.1 even out, or am I looking for something that does not exist yet? Are these remote MAC+PHY devices in the under 10K price range that these smaller all in one CMTS platforms are? On Tue, Feb 2, 2016 at 12:49 PM, Scott Helms wrote: > > > > > On Tue, Feb 2, 2016 at 1:24 PM, Colton Conor > wrote: > >> Yes, we are in the USA. So based on everyones recommendations, I am going >> to stay far away from EURODOCSIS. I was told be a vendor that Arris and >> other USA FCC certified cable modems could easily be flashed to EURODOCIS >> mode, so I did not think the CPE side was that big of a deal (is that even >> true). I was not aware that there were so many differences besides just the >> channel width. >> > > I wish this were the case, it would make my life easier. The problem is > that there is a diplex filter that prevents the upstream burst from being > heard by the downstream receiver and for cost purposes all the D3 and > earlier modems have fixed filters. What that means is that a EuroDOCSIS > modem can (sometimes) be flashed to use 6MHz channels, but the reverse is > NOT true. In any case we don't recommend using Euro modems that are > flashed to US standards in production (nor do the vendors) because you'll > see much more upstream leakage. > > >> >> So, assuming we are talking about DOCSIS only (and not EURODOCSIS), what >> do you recommend? I like the idea of being able to upgrade to 3.1, but not >> sure if there are any small systems capable of this? By small I mean >> something that could feed less than 100 units, and be economical to do. >> Cable has the advantage of cheap modems, so it's really the CMTS side. >> > > In that case I'd definitely go with a remote MAC+PHY. That's the only way > you're going to get a good price point and decent performance unless you > want to use the secondary market, which actually isn't a bad idea right > now. A used 7225 with 8x8 blades is pretty cheap, but it's centralized > CMTS that would cover ~3k subs. > >> >> Please remember I am only interested in data internet services over this >> plant. Something that works for garden style layouts where I can bring >> fiber or coaxial to the side of a garden townhome that has between 4 to 16 >> units inside of it. The reason I requested a harden outdoor unit is that >> most all of the garden style properties have both the phone >> and coaxial drops on the outside of the building. There is no central >> closet or room. Plus we are in the south, so hardened for the >> heat exposure makes sense. >> >> A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like what >> I want. I will check into Huawei and Gainspeed. Who else makes these? >> > > In no particular order, Arris is or will be, Teleste (Euro vendor trying > to break into the US), Sumavision, Altera, and ton more I can't remember. > Come to one of the SCTE shows (it's in Philadelphia this year) if you want > to be deluged with them :) > >> >> >> >> >> >> On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms wrote: >> >>> Nick, >>> >>> Absolutely, if your plant is in Europe or one of the other areas (lots >>> of Africa and the middle East is like that) that adopted EuroDOCSIS I'd >>> agree wholeheartedly. I didn't see Colton say where they're located, but >>> all North America is the US flavor so that's what I assume on NANOG. >>> >>> That being said, the best thing that seldom gets mentioned about D3.1 is >>> getting us to unified channelization. >>> Scott Helms wrote: >>> > That very small upside for an extreme downside.Trying to hire someone >>> > to work on your system with Euro channelization, not to mention buying >>> > amplifiers and passives is a huge PITA. >>> >>> ... if your plant is in the US. >>> >>> > I have customers in Europe who >>> > decided to do US DOCSIS and they universally wish they had used the >>> > local "flavor". >>> >>> as you say, eurodocsis works well in europe. >>> >>> 3.1 will be a major improvement when it materialises. >>> >>> Nick >>> >> >> > From johnstong at westmancom.com Tue Feb 2 20:33:05 2016 From: johnstong at westmancom.com (Graham Johnston) Date: Tue, 2 Feb 2016 20:33:05 +0000 Subject: Cable Operator List In-Reply-To: References: <49EE1A35457387418410F97564A3752B01894003FC@MSG6.westman.int> Message-ID: <49EE1A35457387418410F97564A3752B0189401624@MSG6.westman.int> DSG=Docsis Set-Top Gateway. It is a more modern implementation of the command and control communications path that tradition video set-top boxes used. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From: Colton Conor [mailto:colton.conor at gmail.com] Sent: Tuesday, February 02, 2016 9:44 AM To: Graham Johnston Cc: NANOG Subject: Re: Cable Operator List Graham, What is DSG? Yes, I am really looking for a CMTS to perform layer 2 just as our DSLAMs and GPON do today. All layer 3 will be upstream. I would want to handle DHCP upstream, but have the CMTS insert Option 82 if that is a feature. Not sure what specific CMTS stuff you need. On Tue, Feb 2, 2016 at 8:12 AM, Graham Johnston > wrote: Colton, It really depends on what features you are after. I've demo'd one of the small 1/2RU C-DOCSIS CMTSs, and they certainly work. For us though it was a non-starter as we needed support for DSG and it didn't have it. If all you are after is basic internet connectivity there is Pico Digital, Vecima, Sumavision, as well as others. Many of the C-DOCSIS CMTSs seem either only support, or are more often meant to support layer 2 operations where the routing happens upstream from the CMTS. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com ? think green; don't print this email. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor Sent: Tuesday, February 02, 2016 8:00 AM To: Daniel Corbe Cc: NANOG Subject: Re: Cable Operator List Well, maybe NANOG's not a bad place for this post then! I would like to know more about the data-only side of CMTS systems, and who the main vendors are. We have MDU properties where there is either old inside CAT3 phone wire, or coaxial cable. We have looked and are very familiar with the multiple technologies that work over phone lines namely VDSL2 and G.FAST. However, using the coaxial cable seems to be a much better solution than using the phone wires. So I am looking for compacts, low cost CMTS systems. Based on the specs, I am looking for something at least DOCSIS 3.0 capable, with at least 16X4 output. Something with the ability to upgrade to software upgrade to DOCSIS 3.1 would be nice, but I doubt that would be a low cost solution. Whats out there for small operators that don't want a large chassis based system to feed an entire town with. So far I have found the http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to retail for under $5000. On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe > wrote: > > > On Feb 2, 2016, at 8:42 AM, Colton Conor > wrote: > > > > Are there any mailing lists out there dedicated for cable/MSO type > > operators? > > > > I'm curious about this too. > > I?m not a cable operator (in that I haven?t successfully registered for a > cable franchise yet) but I do operate a docsis network and I?ve > successfully negotiated the treacherous waters of obtaining and providing > content to my users. > > I?m still a bit green behind the ears but I could probably offer some > measure of assistance if you have a specific question. > > -Daniel > > From khelms at zcorum.com Tue Feb 2 20:44:14 2016 From: khelms at zcorum.com (Scott Helms) Date: Tue, 2 Feb 2016 15:44:14 -0500 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: Colton, D3.1 gear is just coming online right now. If you're going to go with the smaller PHY+MAC approach I'd just make sure the company has plans to update their boxes to 3.1 in a decent (your judgement) amount of time. Don't expect any 3.0 box to be software upgradeable to 3.1, the hardware is quite different. The PHY+MAC boxes are _generally_ < $10k and some are talking about ~6k. All the vendors we've listed so far have plans for 3.1, but I don't have a timeline for any of them. Right now the market is still trying to decide how modular CMTS will be rolled out, remote PHY, remote MAC+PHY, or a combination. For example, Cisco is (for the moment) betting that remote PHY economics will be compelling for the larger operators, while Arris is doing both approaches. Scott Helms Chief Technology Officer ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Feb 2, 2016 at 3:31 PM, Colton Conor wrote: > Is a remote MAC+PHY the same thing as a Distributed Converged Cable > Access Platform (D-CCAP) solution like Huawei is pushing? Is DOCSIS 3.1 > even out, or am I looking for something that does not exist yet? > > Are these remote MAC+PHY devices in the under 10K price range that these > smaller all in one CMTS platforms are? > > On Tue, Feb 2, 2016 at 12:49 PM, Scott Helms wrote: > >> >> >> >> >> On Tue, Feb 2, 2016 at 1:24 PM, Colton Conor >> wrote: >> >>> Yes, we are in the USA. So based on everyones recommendations, I am >>> going to stay far away from EURODOCSIS. I was told be a vendor that >>> Arris and other USA FCC certified cable modems could easily be flashed to >>> EURODOCIS mode, so I did not think the CPE side was that big of a deal (is >>> that even true). I was not aware that there were so many differences >>> besides just the channel width. >>> >> >> I wish this were the case, it would make my life easier. The problem is >> that there is a diplex filter that prevents the upstream burst from being >> heard by the downstream receiver and for cost purposes all the D3 and >> earlier modems have fixed filters. What that means is that a EuroDOCSIS >> modem can (sometimes) be flashed to use 6MHz channels, but the reverse is >> NOT true. In any case we don't recommend using Euro modems that are >> flashed to US standards in production (nor do the vendors) because you'll >> see much more upstream leakage. >> >> >>> >>> So, assuming we are talking about DOCSIS only (and not EURODOCSIS), what >>> do you recommend? I like the idea of being able to upgrade to 3.1, but not >>> sure if there are any small systems capable of this? By small I mean >>> something that could feed less than 100 units, and be economical to do. >>> Cable has the advantage of cheap modems, so it's really the CMTS side. >>> >> >> In that case I'd definitely go with a remote MAC+PHY. That's the only >> way you're going to get a good price point and decent performance unless >> you want to use the secondary market, which actually isn't a bad idea right >> now. A used 7225 with 8x8 blades is pretty cheap, but it's centralized >> CMTS that would cover ~3k subs. >> >>> >>> Please remember I am only interested in data internet services over this >>> plant. Something that works for garden style layouts where I can bring >>> fiber or coaxial to the side of a garden townhome that has between 4 to 16 >>> units inside of it. The reason I requested a harden outdoor unit is that >>> most all of the garden style properties have both the phone >>> and coaxial drops on the outside of the building. There is no central >>> closet or room. Plus we are in the south, so hardened for the >>> heat exposure makes sense. >>> >>> A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like >>> what I want. I will check into Huawei and Gainspeed. Who else makes these? >>> >> >> In no particular order, Arris is or will be, Teleste (Euro vendor trying >> to break into the US), Sumavision, Altera, and ton more I can't remember. >> Come to one of the SCTE shows (it's in Philadelphia this year) if you want >> to be deluged with them :) >> >>> >>> >>> >>> >>> >>> On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms wrote: >>> >>>> Nick, >>>> >>>> Absolutely, if your plant is in Europe or one of the other areas (lots >>>> of Africa and the middle East is like that) that adopted EuroDOCSIS I'd >>>> agree wholeheartedly. I didn't see Colton say where they're located, but >>>> all North America is the US flavor so that's what I assume on NANOG. >>>> >>>> That being said, the best thing that seldom gets mentioned about D3.1 >>>> is getting us to unified channelization. >>>> Scott Helms wrote: >>>> > That very small upside for an extreme downside.Trying to hire someone >>>> > to work on your system with Euro channelization, not to mention buying >>>> > amplifiers and passives is a huge PITA. >>>> >>>> ... if your plant is in the US. >>>> >>>> > I have customers in Europe who >>>> > decided to do US DOCSIS and they universally wish they had used the >>>> > local "flavor". >>>> >>>> as you say, eurodocsis works well in europe. >>>> >>>> 3.1 will be a major improvement when it materialises. >>>> >>>> Nick >>>> >>> >>> >> > From bill at herrin.us Tue Feb 2 20:56:05 2016 From: bill at herrin.us (William Herrin) Date: Tue, 2 Feb 2016 15:56:05 -0500 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <20160202141148.GG25581@puck.nether.net> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <20160202141148.GG25581@puck.nether.net> Message-ID: On Tue, Feb 2, 2016 at 9:11 AM, Jared Mauch wrote: > Yes, but I'm always concerned about what boot messages are lost > or things you can't quite do properly (like send break, etc) to get into > the device as you're waiting for the USB to initalize, driver to present > to OS, etc.. Maybe they spent more time thinking about this than I > am aware, but it's something I've not had a proper solution explained to me > for. Hi Jared, Like all USB to serial adapters, the the USB port on the router is powered by the laptop or whatever device it's plugged in to. It initializes and is ready before you turn the router on. I have not had any problems sending a serial break via USB-to-serial adapters. Have you? You can get a server in a shallow-depth 1U case with a solid state drive just as readily as a serial console server. Add USB ports and hubs. This gives you a Linux box on site (handy for troubleshooting) and might simplify your cabling (put USB hubs beside a bank of devices and run only one cable back to the server). A little bit of scripting with the hotplug system will let you associate the USB device using a given serial number with whatever name you care to give it, which might also simplify documentation for which router is plugged in where. As for why they made the change... EIA-232 serial ports are becoming rare. Not much uses them any more and it has become hard to find a laptop with one built in. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From davidbass570 at gmail.com Tue Feb 2 21:03:39 2016 From: davidbass570 at gmail.com (David Bass) Date: Tue, 2 Feb 2016 16:03:39 -0500 Subject: Low density Juniper (or alternative) Edge Message-ID: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> Looking to see what others are using out there as an alternative to a Cisco ME3600X? Also, what other vendors out there are playing in this space? Need a full MPLS stack. From jared at puck.nether.net Tue Feb 2 21:12:16 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 2 Feb 2016 16:12:16 -0500 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <20160202141148.GG25581@puck.nether.net> Message-ID: <22C2CD51-039D-4622-A01B-B051A5BFECD8@puck.nether.net> > On Feb 2, 2016, at 3:56 PM, William Herrin wrote: > > On Tue, Feb 2, 2016 at 9:11 AM, Jared Mauch wrote: >> Yes, but I'm always concerned about what boot messages are lost >> or things you can't quite do properly (like send break, etc) to get into >> the device as you're waiting for the USB to initalize, driver to present >> to OS, etc.. Maybe they spent more time thinking about this than I >> am aware, but it's something I've not had a proper solution explained to me >> for. > > Hi Jared, > > Like all USB to serial adapters, the the USB port on the router is > powered by the laptop or whatever device it's plugged in to. It > initializes and is ready before you turn the router on. > > I have not had any problems sending a serial break via USB-to-serial > adapters. Have you? Yes. I?ve had a lot of issues with various USB serial devices and proper support. There?s a lot of cheap windows only hardware out there. > You can get a server in a shallow-depth 1U case with a solid state > drive just as readily as a serial console server. Add USB ports and > hubs. This gives you a Linux box on site (handy for troubleshooting) > and might simplify your cabling (put USB hubs beside a bank of devices > and run only one cable back to the server). A little bit of scripting > with the hotplug system will let you associate the USB device using a > given serial number with whatever name you care to give it, which > might also simplify documentation for which router is plugged in > where. If you look at a modern router, eg: ASR9922, you have at least 4 serial ports that need to be connected. Adding a server per router gets expensive quickly, not to include keeping the right kvm/vmware -> vm mapping in place for the work. > As for why they made the change... EIA-232 serial ports are becoming > rare. Not much uses them any more and it has become hard to find a > laptop with one built in. Like I said, that?s why we?ve seen things like that CERN open hardware solution come into play. It?s cheaper than your above mentioned server and has more robust support for the ?industry standard? RJ45 pinout. - Jared From george at cbcast.com Tue Feb 2 21:16:20 2016 From: george at cbcast.com (George Skorup) Date: Tue, 2 Feb 2016 15:16:20 -0600 Subject: Windstream RTBH Message-ID: <56B11CA4.3080206@cbcast.com> Just wanted to follow up on this. The RTBH community is 7029:4507. After some route filter adjustments on their side (to accept a /32 advertisement from us), we're now good to go. Thanks to everyone that helped us get this sorted out. George From jerome at ceriz.fr Tue Feb 2 22:19:36 2016 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Tue, 2 Feb 2016 23:19:36 +0100 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> Message-ID: <56B12B78.5060402@ceriz.fr> Hi David, Le 02/02/2016 22:03, David Bass a ?crit : > Looking to see what others are using out there as an alternative to a Cisco ME3600X? I'd rather use the ASR920, the ME3600X is too deep to fit in some PoPs. It also has a higher 10G port count. Alternatively, on low cost deployments, I used Mikrotik CCR1016-12S-1S+. Lower density, though. For higher 10G density, I like the Juniper EX4550. But when you have to stick to a limited number of vendors, I guess you could consider the Catalyst 6840 line. Never had one to play with, though. I'm currently evaluating another alternative : the Nokia-Alcatel-Lucent ISAM 7360FX chassis (4 to 16 slots) with either P2P (36 client lines per slot) or PON (up to 16 ports/slot), and a Mikrotik CCR1072 right behind to encapsulate L2 circuits. It's, by far, the denser and cheapest way to provide more than a few hundred 100M-1Gbps circuits per PoP. Best regards, -- J?r?me Nicolle From nick at foobar.org Tue Feb 2 22:25:41 2016 From: nick at foobar.org (Nick Hilliard) Date: Tue, 02 Feb 2016 22:25:41 +0000 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> Message-ID: <56B12CE5.50407@foobar.org> David Bass wrote: > Looking to see what others are using out there as an alternative to a > Cisco ME3600X? Also, what other vendors out there are playing in this > space? > > Need a full MPLS stack. Features, speed, price: choose 2. Wait, you said MPLS: choose 1.5. Nick From baldur.norddahl at gmail.com Tue Feb 2 22:35:21 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 2 Feb 2016 23:35:21 +0100 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> Message-ID: Hi, The ZTE 5900E series has a full MPLS stack and is solid hardware. Much cheaper than Cisco and Juniper. http://wwwen.zte.com.cn/en/products/bearer/data_communication/ethernet_switch/201309/t20130917_405917.html Regards, Baldur On 2 February 2016 at 22:03, David Bass wrote: > Looking to see what others are using out there as an alternative to a > Cisco ME3600X? Also, what other vendors out there are playing in this space? > > Need a full MPLS stack. From colton.conor at gmail.com Tue Feb 2 22:38:41 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 2 Feb 2016 16:38:41 -0600 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <56B12B78.5060402@ceriz.fr> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <56B12B78.5060402@ceriz.fr> Message-ID: Jerome, We use some of the 7360's, but not the Mikrotik. Why not use ALU's CPE devices if using the 7360? On Tue, Feb 2, 2016 at 4:19 PM, J?r?me Nicolle wrote: > Hi David, > > Le 02/02/2016 22:03, David Bass a ?crit : > > Looking to see what others are using out there as an alternative to a > Cisco ME3600X? > > I'd rather use the ASR920, the ME3600X is too deep to fit in some PoPs. > It also has a higher 10G port count. > > Alternatively, on low cost deployments, I used Mikrotik CCR1016-12S-1S+. > Lower density, though. > > For higher 10G density, I like the Juniper EX4550. But when you have to > stick to a limited number of vendors, I guess you could consider the > Catalyst 6840 line. Never had one to play with, though. > > I'm currently evaluating another alternative : the Nokia-Alcatel-Lucent > ISAM 7360FX chassis (4 to 16 slots) with either P2P (36 client lines per > slot) or PON (up to 16 ports/slot), and a Mikrotik CCR1072 right behind > to encapsulate L2 circuits. It's, by far, the denser and cheapest way to > provide more than a few hundred 100M-1Gbps circuits per PoP. > > Best regards, > > -- > J?r?me Nicolle > From dspataro at corp.nac.net Tue Feb 2 22:08:37 2016 From: dspataro at corp.nac.net (Dan Spataro) Date: Tue, 2 Feb 2016 22:08:37 +0000 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> Message-ID: <6441f7bd68304968afd3dd7fefcac0fa@exch2013-1.hq.nac.net> Depending on your interpretation of full MPLS stack, you can look into the Brocade CES. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Bass Sent: Tuesday, February 2, 2016 4:04 PM To: nanog at nanog.org Subject: Low density Juniper (or alternative) Edge Looking to see what others are using out there as an alternative to a Cisco ME3600X? Also, what other vendors out there are playing in this space? Need a full MPLS stack. From jerome at ceriz.fr Tue Feb 2 23:50:26 2016 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Wed, 3 Feb 2016 00:50:26 +0100 Subject: Low density Juniper (or alternative) Edge In-Reply-To: References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <56B12B78.5060402@ceriz.fr> Message-ID: <56B140C2.8000106@ceriz.fr> Le 02/02/2016 23:38, Colton Conor a ?crit : > We use some of the 7360's, but not the Mikrotik. Why not use ALU's CPE > devices if using the 7360? I'd use ALU's ONTs (there's now a SFP GPON stick available too) or RGWs on the client side, the Mikrotik here is the PE router, because ALU's FANT-F card lacks EoMPLS/ATOM/VPLS/E-VPN capabilities. I only use QinQ on its 4*10Gbps uplink ports. Any 80Gbps capable PE router would be fine, though. I choose the Mikrotik CRR1072 for its price and density. -- J?r?me Nicolle From davidbass570 at gmail.com Wed Feb 3 00:01:02 2016 From: davidbass570 at gmail.com (David Bass) Date: Tue, 2 Feb 2016 19:01:02 -0500 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <56B12B78.5060402@ceriz.fr> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <56B12B78.5060402@ceriz.fr> Message-ID: <60FCBFCE-23A2-4116-B116-07EA678C36E0@gmail.com> Thanks to all that have replied! Yes, I just started looking at the ASR9xx series of routers as well...seems like a likely alternative if we go with Cisco. > On Feb 2, 2016, at 5:19 PM, J?r?me Nicolle wrote: > > Hi David, > > Le 02/02/2016 22:03, David Bass a ?crit : >> Looking to see what others are using out there as an alternative to a Cisco ME3600X? > > I'd rather use the ASR920, the ME3600X is too deep to fit in some PoPs. > It also has a higher 10G port count. > > Alternatively, on low cost deployments, I used Mikrotik CCR1016-12S-1S+. > Lower density, though. > > For higher 10G density, I like the Juniper EX4550. But when you have to > stick to a limited number of vendors, I guess you could consider the > Catalyst 6840 line. Never had one to play with, though. > > I'm currently evaluating another alternative : the Nokia-Alcatel-Lucent > ISAM 7360FX chassis (4 to 16 slots) with either P2P (36 client lines per > slot) or PON (up to 16 ports/slot), and a Mikrotik CCR1072 right behind > to encapsulate L2 circuits. It's, by far, the denser and cheapest way to > provide more than a few hundred 100M-1Gbps circuits per PoP. > > Best regards, > > -- > J?r?me Nicolle From Michael.Hoyt at windstream.com Wed Feb 3 00:17:57 2016 From: Michael.Hoyt at windstream.com (Hoyt, Michael) Date: Wed, 3 Feb 2016 00:17:57 +0000 Subject: Windstream RTBH Message-ID: <5C75E6F641662342843DD2F28FA76958194ECCEB@CWWAPP477.windstream.com> Thanks George and sorry about the typo, our correct RTBH community is 7029:4507. If you are a Windstream BGP customer and need our material on our communities please contact your account team. Additionally, as in George's case, we found his BGP configuration was incorrect and we were not accepting /32 routes. If you experience any issue using any of our communities (no export, etc..) please open a ticket with the Windstream Enterprise Repair Center (ERC). Thanks, -Mike --Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of George Skorup Sent: Tuesday, February 02, 2016 2:16 PM To: nanog at nanog.org Subject: Windstream RTBH Just wanted to follow up on this. The RTBH community is 7029:4507. After some route filter adjustments on their side (to accept a /32 advertisement from us), we're now good to go. Thanks to everyone that helped us get this sorted out. George ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. From rdrake at direcpath.com Wed Feb 3 01:03:22 2016 From: rdrake at direcpath.com (Robert Drake) Date: Tue, 2 Feb 2016 20:03:22 -0500 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <87mvrj77ml.fsf@nemi.mork.no> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> <87mvrj77ml.fsf@nemi.mork.no> Message-ID: <56B151DA.1060405@direcpath.com> On 2/2/2016 5:02 AM, Bj?rn Mork wrote: > > No inside pictures :) > > Assuming that this is really an USB device, and that the console port is > really an USB host port, it would be useful to know the USB decriptors > of the device. You wouldn't be willing to connect it to a Linux PC and > run "lsusb -vd", would you? I'm inconveniently consoled into one via a combination of remote desktop into windows -- linux console on a virtual machine -- screen /dev/ttyACM0. Because of this posting lsusb -vd is taxing. Linux has full support for the device. It sees it as cdc_acm. The vendor id is 0x04e2 (Exar Corp). Product ID is 0x1410. I've got two connected right now. This is in our lab and the windows box is temporary. Our intention is to use a raspberry pi for the terminal server. I'm obviously not in front of it, but I'm wondering if they can be enumerated by something other than when they were plugged in. That's my biggest hurdle for making a console server for them.. how to figure out what router is connected to which USB port after a reboot, or someone getting unpluggy with cables. > > Bj?rn > Robert From morrowc.lists at gmail.com Wed Feb 3 01:25:45 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Feb 2016 20:25:45 -0500 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <352c97684c585a53001049942d7492ea@standingwave.org> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <20160202141148.GG25581@puck.nether.net> <352c97684c585a53001049942d7492ea@standingwave.org> Message-ID: The airconsole's are cute ... but not really practical. I happened to get a chip computer (getchip.com ?) and turned it into a console server I can get to over the net ... at least at home and equinix. it's also 'cute' but not really practical... it is only 9 USD though, so there's that. I'm really unclear why USB for console is 'a thing' for large gear... 9600 is plenty fast for typing, 115200 is acceptable (in a pinch) for code upgrades... (icky, yes, but...) I wonder if you can x-modem over the usb... and at what rate. I also do wonder about jared's problem of: "hey so I need to hit break to fix this gear during reboot.... oops! driver not loaded yet!" On Tue, Feb 2, 2016 at 3:27 PM, Peter Loron wrote: > A possible alternative, although probably not one you'd want to leave in > place permanently: > > http://www.get-console.com/airconsole/ > > -Pete > > > On 2016-02-02 06:11, Jared Mauch wrote: >> >> On Mon, Dec 07, 2015 at 10:15:28PM +0000, Erik Sundberg wrote: >>> >>> We have one of these nice new and fancy Cisco ASR920-24SZ, just realized >>> it doesn't have an RJ45 Console port only USB. When we deploy devices at our >>> pop we wire the console port to a terminal\console server, well that doesn't >>> work for a usb console device. >>> >>> So what is everyone doing for out of band management via the console when >>> it's a usb only device? >>> Is there something I am missing? >> >> >> Likely not. I've seen most equipment makers start to ignore >> serial console. >> The default these appears to be moving to a uBoot/PXE style network setup >> where you push an image and such via TFTP/DHCP into the device. >> >>> Is there a console server for USB? >> >> >> I've not seen one show up, but there are other devices like this >> which the DIY industry has started to build: >> >> http://freetserv.github.io/ >> >> I have a side business i'm tinkering with and these are open >> source >> hardware. If there is interest, I'd be willing to build these in volume >> and >> drive the cost down. >> >> It would not be difficult to do a giant USB hub that was similar. >> >>> Does cisco make an USB to RJ45 Jack adapter? >> >> >> Yes, but I'm always concerned about what boot messages are lost >> or things you can't quite do properly (like send break, etc) to get into >> the device as you're waiting for the USB to initalize, driver to present >> to OS, etc.. Maybe they spent more time thinking about this than I >> am aware, but it's something I've not had a proper solution explained to >> me >> for. >> >> - Jared From dovid at telecurve.com Wed Feb 3 02:33:21 2016 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 3 Feb 2016 02:33:21 +0000 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <56B151DA.1060405@direcpath.com> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> <87mvrj77ml.fsf@nemi.mork.no> <56B151DA.1060405@direcpath.com> Message-ID: <2088031896-1454466802-cardhu_decombobulator_blackberry.rim.net-2032550800-@b11.c1.bise6.blackberry> Why not use udev rules so the ports are persistent? I did that on a pi that I was using as an ice cast box. Based on the usb audio port on reboots I know which device is which stream. Regards, Dovid -----Original Message----- From: Robert Drake Sender: "NANOG" Date: Tue, 2 Feb 2016 20:03:22 To: Subject: Re: Devices with only USB console port - Need a Console Server Solution On 2/2/2016 5:02 AM, Bj?rn Mork wrote: > > No inside pictures :) > > Assuming that this is really an USB device, and that the console port is > really an USB host port, it would be useful to know the USB decriptors > of the device. You wouldn't be willing to connect it to a Linux PC and > run "lsusb -vd", would you? I'm inconveniently consoled into one via a combination of remote desktop into windows -- linux console on a virtual machine -- screen /dev/ttyACM0. Because of this posting lsusb -vd is taxing. Linux has full support for the device. It sees it as cdc_acm. The vendor id is 0x04e2 (Exar Corp). Product ID is 0x1410. I've got two connected right now. This is in our lab and the windows box is temporary. Our intention is to use a raspberry pi for the terminal server. I'm obviously not in front of it, but I'm wondering if they can be enumerated by something other than when they were plugged in. That's my biggest hurdle for making a console server for them.. how to figure out what router is connected to which USB port after a reboot, or someone getting unpluggy with cables. > > Bj?rn > Robert From j at arpa.com Wed Feb 3 03:16:46 2016 From: j at arpa.com (jamie rishaw) Date: Tue, 2 Feb 2016 21:16:46 -0600 Subject: Cable Operator List In-Reply-To: References: <49EE1A35457387418410F97564A3752B01894003FC@MSG6.westman.int> Message-ID: 56k's for everyone! Lets bring the #OldInternet back! On Tue, Feb 2, 2016 at 10:03 AM, Scott Helms wrote: > Colton, > > You're only going to find very small, old, or not certified (usually still > very small) CMTSs that only do layer 2. All of the major vendors are doing > layer 3 because we've found out over time that not doing it is more > problematic. Having said that, if you're looking for a more ONT/DSLAM type > of install there is a new type of CMTSs that look at lot like traditional > telco DLC/BLC deployments. > > https://intx15.ncta.com/wp-content/uploads/2015/05/17-Remote-PHY.pdf > > The remote PHY+MAC boxes are basically mini-CMTSs and they typically rely > on something upstream handling layer 3. The remote PHY boxes are different > as they don't even do a complete layer 2 and instead forward DOCSIS frames > back to a centralized CMTS/CCAP. > > > > Scott Helms > Chief Technology Officer > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Tue, Feb 2, 2016 at 10:43 AM, Colton Conor > wrote: > > > Graham, > > > > What is DSG? Yes, I am really looking for a CMTS to perform layer 2 just > as > > our DSLAMs and GPON do today. All layer 3 will be upstream. I would want > to > > handle DHCP upstream, but have the CMTS insert Option 82 if that is a > > feature. Not sure what specific CMTS stuff you need. > > > > On Tue, Feb 2, 2016 at 8:12 AM, Graham Johnston < > johnstong at westmancom.com> > > wrote: > > > > > Colton, > > > > > > It really depends on what features you are after. I've demo'd one of > the > > > small 1/2RU C-DOCSIS CMTSs, and they certainly work. For us though it > > was > > > a non-starter as we needed support for DSG and it didn't have it. If > all > > > you are after is basic internet connectivity there is Pico Digital, > > Vecima, > > > Sumavision, as well as others. Many of the C-DOCSIS CMTSs seem either > > only > > > support, or are more often meant to support layer 2 operations where > the > > > routing happens upstream from the CMTS. > > > > > > Graham Johnston > > > Network Planner > > > Westman Communications Group > > > 204.717.2829 > > > johnstong at westmancom.com > > > ??think green; don't print this email. > > > > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor > > > Sent: Tuesday, February 02, 2016 8:00 AM > > > To: Daniel Corbe > > > Cc: NANOG > > > Subject: Re: Cable Operator List > > > > > > Well, maybe NANOG's not a bad place for this post then! I would like to > > > know more about the data-only side of CMTS systems, and who the main > > > vendors are. > > > > > > We have MDU properties where there is either old inside CAT3 phone > wire, > > or > > > coaxial cable. We have looked and are very familiar with the multiple > > > technologies that work over phone lines namely VDSL2 and G.FAST. > However, > > > using the coaxial cable seems to be a much better solution than using > the > > > phone wires. > > > > > > So I am looking for compacts, low cost CMTS systems. Based on the > specs, > > I > > > am looking for something at least DOCSIS 3.0 capable, with at least > 16X4 > > > output. Something with the ability to upgrade to software upgrade to > > DOCSIS > > > 3.1 would be nice, but I doubt that would be a low cost solution. > > > > > > Whats out there for small operators that don't want a large chassis > based > > > system to feed an entire town with. > > > > > > So far I have found the > > > http://picodigital.com/product-details.php?ID=miniCMTS200a which seems > > to > > > retail for under $5000. > > > > > > > > > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe > > > wrote: > > > > > > > > > > > > On Feb 2, 2016, at 8:42 AM, Colton Conor > > > wrote: > > > > > > > > > > Are there any mailing lists out there dedicated for cable/MSO type > > > > > operators? > > > > > > > > > > > > > I'm curious about this too. > > > > > > > > I?m not a cable operator (in that I haven?t successfully registered > > for a > > > > cable franchise yet) but I do operate a docsis network and I?ve > > > > successfully negotiated the treacherous waters of obtaining and > > providing > > > > content to my users. > > > > > > > > I?m still a bit green behind the ears but I could probably offer some > > > > measure of assistance if you have a specific question. > > > > > > > > -Daniel > > > > > > > > > > > > > > -- // jamie rishaw // "*My religion is very simple. My religion is kindness."* - the 14th Dalai Lama; ?????????????????? From frnkblk at iname.com Wed Feb 3 05:07:48 2016 From: frnkblk at iname.com (frnkblk at iname.com) Date: Tue, 2 Feb 2016 23:07:48 -0600 Subject: Cable Operator List In-Reply-To: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> Message-ID: <005e01d15e40$d4584e90$7d08ebb0$@iname.com> If you need density along the Arris line, skip the C4 and go straight to the E6000. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Corbe Sent: Tuesday, February 02, 2016 8:18 AM To: Colton Conor Cc: NANOG Subject: Re: Cable Operator List Hey Colton, We?re using small 16 channel CMTS systems for residential MDUs and colocating them directly on premise inside of wiring closets and then connecting them by metro ethernet. We?ve had great successes so far with this model. There?s lots of CMTS vendors. There?s tons of used Motorola BSR 64Ks on the market, but be aware of the lack of useful IPv6 features (like prefix delegation) in older software releases. If you buy a box and want to run 7.x or 8.x, you?ll need to relicense your downstream and upstream channels at some additional arbitrary fixed cost. I?m personally fond of these things: http://picodigital.com/product-details.php?ID=miniCMTS200a You can only bond 16 channels together max though because that?s all the box supports and you can?t bond across boxes; however, these things are less than 4 grand if you buy them in bulk so they?re really fucking easy to just spam everywhere. Blonder Tongue makes a pizza-box style CMTS too: http://www.blondertongue.com/shop-by-department/catv/ip-over-coax/docsis/euro-docsis/ As does Harmonics: http://harmonicinc.com/product/cable-edge/nsg-exo All three are based on the same chipset, so the real differentiation is price and firmware features. Then there?s Cisco. The UBR is a popular platform. And pretty soon there?s going to be a glut of UBR10Ks on the Market because Comcast is busy ripping their UBRs out of production because they?re upgrading their cable plant to the CBR platform. Then the Arris C4, if you have deep pockets, is a modern version of the BSR: http://www.arris.com/products/c4-cmts/ > On Feb 2, 2016, at 9:00 AM, Colton Conor wrote: > > Well, maybe NANOG's not a bad place for this post then! I would like to know more about the data-only side of CMTS systems, and who the main vendors are. > > We have MDU properties where there is either old inside CAT3 phone wire, or coaxial cable. We have looked and are very familiar with the multiple technologies that work over phone lines namely VDSL2 and G.FAST. However, using the coaxial cable seems to be a much better solution than using the phone wires. > > So I am looking for compacts, low cost CMTS systems. Based on the specs, I am looking for something at least DOCSIS 3.0 capable, with at least 16X4 output. Something with the ability to upgrade to software upgrade to DOCSIS 3.1 would be nice, but I doubt that would be a low cost solution. > > Whats out there for small operators that don't want a large chassis based system to feed an entire town with. > > So far I have found the http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to retail for under $5000. > > > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe wrote: > > > On Feb 2, 2016, at 8:42 AM, Colton Conor wrote: > > > > Are there any mailing lists out there dedicated for cable/MSO type > > operators? > > > > I'm curious about this too. > > I?m not a cable operator (in that I haven?t successfully registered for a cable franchise yet) but I do operate a docsis network and I?ve successfully negotiated the treacherous waters of obtaining and providing content to my users. > > I?m still a bit green behind the ears but I could probably offer some measure of assistance if you have a specific question. > > -Daniel > > From grizz at 20c.com Wed Feb 3 05:09:16 2016 From: grizz at 20c.com (Matt Griswold) Date: Wed, 3 Feb 2016 05:09:16 +0000 Subject: NANOG66 Coding BOF Message-ID: <20160203050916.30392da3@x0r> NANOG66 will premiere a Coding BOF, which will feature some tutorials and general open discussion for people to show how they've implemented code to various interfaces in the real world. I have most of the time scheduled already, but can still make some room so if anyone is interested presenting anything or has other ideas for topics let me know off list. Cheers From ESundberg at nitelusa.com Wed Feb 3 07:18:57 2016 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Wed, 3 Feb 2016 07:18:57 +0000 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <2088031896-1454466802-cardhu_decombobulator_blackberry.rim.net-2032550800-@b11.c1.bise6.blackberry> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> <87mvrj77ml.fsf@nemi.mork.no> <56B151DA.1060405@direcpath.com> <2088031896-1454466802-cardhu_decombobulator_blackberry.rim.net-2032550800-@b11.c1.bise6.blackberry> Message-ID: <495D0934DA46854A9CA758393724D5902D74A527@NI-MAIL02.nii.ads> Digi has something called USB Anywhere. http://www.digi.com/products/usb-and-serial-connectivity/usb-over-ip-hubs/anywhereusb However I would like to limit the amount of equipment we deploy at a pop, the majority of our pop's don't have servers... Just Routers, Switches, Console Servers, and your other Network Hardware. The problem with USB is you can only wire a USB 2.0 Cable up to 15' (Per Google).... And you have to purchase a cable premade. Where as with a Serial Console you can go around 100', not to mention about just about everyone has a crimper, rj45 ends, and cat5 cable, to run and make cables as needed. Assuming something is broke...With USB let's say you rely on remote hands to do a lot of work in the colo's. First they need to find a *Working Laptop*, then you have to walk the tech through downloading the drivers and installing them on there laptop. Hoping they have permissions to install software on there laptops. Plus if it's really broke and you get no output, you will never be sure if it's USB related or not. Where as serial it's just going to work, and it's easy to test to see if it's working on not by hooking up to anothere device. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender Sent: Tuesday, February 02, 2016 8:33 PM To: Robert Drake ; NANOG ; nanog at nanog.org Subject: Re: Devices with only USB console port - Need a Console Server Solution Why not use udev rules so the ports are persistent? I did that on a pi that I was using as an ice cast box. Based on the usb audio port on reboots I know which device is which stream. Regards, Dovid -----Original Message----- From: Robert Drake Sender: "NANOG" Date: Tue, 2 Feb 2016 20:03:22 To: Subject: Re: Devices with only USB console port - Need a Console Server Solution On 2/2/2016 5:02 AM, Bj?rn Mork wrote: > > No inside pictures :) > > Assuming that this is really an USB device, and that the console port is > really an USB host port, it would be useful to know the USB decriptors > of the device. You wouldn't be willing to connect it to a Linux PC and > run "lsusb -vd", would you? I'm inconveniently consoled into one via a combination of remote desktop into windows -- linux console on a virtual machine -- screen /dev/ttyACM0. Because of this posting lsusb -vd is taxing. Linux has full support for the device. It sees it as cdc_acm. The vendor id is 0x04e2 (Exar Corp). Product ID is 0x1410. I've got two connected right now. This is in our lab and the windows box is temporary. Our intention is to use a raspberry pi for the terminal server. I'm obviously not in front of it, but I'm wondering if they can be enumerated by something other than when they were plugged in. That's my biggest hurdle for making a console server for them.. how to figure out what router is connected to which USB port after a reboot, or someone getting unpluggy with cables. > > Bj?rn > Robert ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From nick at foobar.org Wed Feb 3 07:58:38 2016 From: nick at foobar.org (Nick Hilliard) Date: Wed, 03 Feb 2016 07:58:38 +0000 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> Message-ID: <56B1B32E.4030609@foobar.org> David Bass wrote: > Looking to see what others are using out there as an alternative to a > Cisco ME3600X? Also, what other vendors out there are playing in this > space? > > Need a full MPLS stack. Before choosing a box, you need to figure out: - how many ports you need, and of what speed - how much you're prepared to pay - how much rack real estate you're ok about dedicating per box - what sort of mpls features you need (vpls / l2vpn-pw / l3vpn / 6pe / 6vpe, etc) - whether rich qos is a requirement - whether you're ever going to need good quality LAG / ECMP support on the platform - what vendor software you're happy to work with - whether you're ok with per port licensing Typically the features that fall by the wayside first are: reasonable port buffers, qos knobs and decent lag/ecmp hashing support for mpls packets. The qos/port buffers tend to be more of a problem on the 10G platforms, but you didn't state whether you were interested in 1G or 10G, or how many ports you were looking for per box. E.g. the production evolution for the me3600 is the asr920, which is better is most aspects except for shared buffer space. This means that the me3600 has better qos support, if deeper buffers are what's important. OTOH, if you need to do fine-grained qos based on ACLs or ports, then this platform isn't for you. Most smaller mpls boxes don't load balance well over LAGs or ECMP because they lack the ability to inspect deep into the packet to get enough flow-aware entropy together to build a reasonable hash. If all your PE devices support flow-aware transport (rfc6391), you're fine, but very few smaller mpls boxes support this feature. If 10G is a requirement, then you need to make a choice between one of the merchant chipsets (e.g. broadcom trident range) and vendor specific chipsets. Many of the larger vendors support the merchant chipsets these days for 10G access, but feature support can be varied. E.g. some devices don't support vpls and never will. Some are a bit behind on product development and don't yet support features like l3vpn or 6PE or 6VPE, even though they are roadmapped. Nick From dcorbe at hammerfiber.com Wed Feb 3 10:54:47 2016 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Wed, 3 Feb 2016 05:54:47 -0500 Subject: as24748 Message-ID: <96B63F40-2CBB-416A-8554-D5803BC2EA65@hammerfiber.com> Can anyone venture a guess as to what this might be about? http://irrexplorer.nlnog.net/search/AS24748:AS-THINX Why would my ASN be part of a foreign AS-SET? Is this something I need to worry about? My gut reaction is to reach out to ripe. From colton.conor at gmail.com Wed Feb 3 14:26:12 2016 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 3 Feb 2016 08:26:12 -0600 Subject: Cable Operator List In-Reply-To: <005e01d15e40$d4584e90$7d08ebb0$@iname.com> References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <005e01d15e40$d4584e90$7d08ebb0$@iname.com> Message-ID: Frank, Thanks for the advice, but I am looking for a low density, low cost solution. I have found some G.HN briges that are made from MDU enviroments, and seem cheaper than a small CMTS system. Anyone have expierence with G.HN? On Tue, Feb 2, 2016 at 11:07 PM, wrote: > If you need density along the Arris line, skip the C4 and go straight to > the E6000. > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Corbe > Sent: Tuesday, February 02, 2016 8:18 AM > To: Colton Conor > Cc: NANOG > Subject: Re: Cable Operator List > > Hey Colton, > > We?re using small 16 channel CMTS systems for residential MDUs and > colocating them directly on premise inside of wiring closets and then > connecting them by metro ethernet. We?ve had great successes so far with > this model. > > There?s lots of CMTS vendors. > > There?s tons of used Motorola BSR 64Ks on the market, but be aware of the > lack of useful IPv6 features (like prefix delegation) in older software > releases. If you buy a box and want to run 7.x or 8.x, you?ll need to > relicense your downstream and upstream channels at some additional > arbitrary fixed cost. > > I?m personally fond of these things: > > http://picodigital.com/product-details.php?ID=miniCMTS200a > > You can only bond 16 channels together max though because that?s all the > box supports and you can?t bond across boxes; however, these things are > less than 4 grand if you buy them in bulk so they?re really fucking easy to > just spam everywhere. > > Blonder Tongue makes a pizza-box style CMTS too: > > > http://www.blondertongue.com/shop-by-department/catv/ip-over-coax/docsis/euro-docsis/ > > As does Harmonics: > > http://harmonicinc.com/product/cable-edge/nsg-exo > > All three are based on the same chipset, so the real differentiation is > price and firmware features. > > Then there?s Cisco. > > The UBR is a popular platform. And pretty soon there?s going to be a glut > of UBR10Ks on the Market because Comcast is busy ripping their UBRs out of > production because they?re upgrading their cable plant to the CBR platform. > > Then the Arris C4, if you have deep pockets, is a modern version of the > BSR: > > http://www.arris.com/products/c4-cmts/ > > > > On Feb 2, 2016, at 9:00 AM, Colton Conor wrote: > > > > Well, maybe NANOG's not a bad place for this post then! I would like to > know more about the data-only side of CMTS systems, and who the main > vendors are. > > > > We have MDU properties where there is either old inside CAT3 phone wire, > or coaxial cable. We have looked and are very familiar with the multiple > technologies that work over phone lines namely VDSL2 and G.FAST. However, > using the coaxial cable seems to be a much better solution than using the > phone wires. > > > > So I am looking for compacts, low cost CMTS systems. Based on the specs, > I am looking for something at least DOCSIS 3.0 capable, with at least 16X4 > output. Something with the ability to upgrade to software upgrade to DOCSIS > 3.1 would be nice, but I doubt that would be a low cost solution. > > > > Whats out there for small operators that don't want a large chassis > based system to feed an entire town with. > > > > So far I have found the > http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to > retail for under $5000. > > > > > > On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe > wrote: > > > > > On Feb 2, 2016, at 8:42 AM, Colton Conor > wrote: > > > > > > Are there any mailing lists out there dedicated for cable/MSO type > > > operators? > > > > > > > I'm curious about this too. > > > > I?m not a cable operator (in that I haven?t successfully registered for > a cable franchise yet) but I do operate a docsis network and I?ve > successfully negotiated the treacherous waters of obtaining and providing > content to my users. > > > > I?m still a bit green behind the ears but I could probably offer some > measure of assistance if you have a specific question. > > > > -Daniel > > > > > > > > From colton.conor at gmail.com Wed Feb 3 14:34:43 2016 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 3 Feb 2016 08:34:43 -0600 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <56B1B32E.4030609@foobar.org> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <56B1B32E.4030609@foobar.org> Message-ID: I see Cisco and Juniper mentioned here, but what about all the smart NID companies out there? I found these of MEF list: Accedian, Altera, BTI Systems, Ciena (Nasdaq: CIEN ), Cisco (Nasdaq: CSCO ), Cyan, FibroLAN, Huawei, Infinera (Nasdaq: INFN ), Juniper Networks (NYSE: JNPR ), MRV, Omnitron, Overture, PT Inovacao, Pulsecom, RAD Data Communications, Telco Systems, Tellabs (Nasdaq: TLAB ), Transition Networks and Transmode. Some of these guys focus what seems like exclusively on ethernet NID devices, and most all are MEF certified. Does anyone use the above vendors NIDs? On Wed, Feb 3, 2016 at 1:58 AM, Nick Hilliard wrote: > David Bass wrote: > > Looking to see what others are using out there as an alternative to a > > Cisco ME3600X? Also, what other vendors out there are playing in this > > space? > > > > Need a full MPLS stack. > > Before choosing a box, you need to figure out: > > - how many ports you need, and of what speed > - how much you're prepared to pay > - how much rack real estate you're ok about dedicating per box > - what sort of mpls features you need (vpls / l2vpn-pw / l3vpn / 6pe / > 6vpe, etc) > - whether rich qos is a requirement > - whether you're ever going to need good quality LAG / ECMP support on > the platform > - what vendor software you're happy to work with > - whether you're ok with per port licensing > > Typically the features that fall by the wayside first are: reasonable > port buffers, qos knobs and decent lag/ecmp hashing support for mpls > packets. The qos/port buffers tend to be more of a problem on the 10G > platforms, but you didn't state whether you were interested in 1G or > 10G, or how many ports you were looking for per box. > > E.g. the production evolution for the me3600 is the asr920, which is > better is most aspects except for shared buffer space. This means that > the me3600 has better qos support, if deeper buffers are what's > important. OTOH, if you need to do fine-grained qos based on ACLs or > ports, then this platform isn't for you. > > Most smaller mpls boxes don't load balance well over LAGs or ECMP > because they lack the ability to inspect deep into the packet to get > enough flow-aware entropy together to build a reasonable hash. If all > your PE devices support flow-aware transport (rfc6391), you're fine, but > very few smaller mpls boxes support this feature. > > If 10G is a requirement, then you need to make a choice between one of > the merchant chipsets (e.g. broadcom trident range) and vendor specific > chipsets. Many of the larger vendors support the merchant chipsets > these days for 10G access, but feature support can be varied. E.g. some > devices don't support vpls and never will. Some are a bit behind on > product development and don't yet support features like l3vpn or 6PE or > 6VPE, even though they are roadmapped. > > Nick > From shawnl at up.net Wed Feb 3 15:12:42 2016 From: shawnl at up.net (Shawn L) Date: Wed, 3 Feb 2016 10:12:42 -0500 (EST) Subject: =?utf-8?Q?Re=3A_Low_density_Juniper_=28or_alternative=29_Edge?= In-Reply-To: References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <56B1B32E.4030609@foobar.org> Message-ID: <1454512362.691730553@upnet.mymailsrvr.com> We use the Accedian Metro Nid in places. They work well, but are layer 2 only -- at least the ones we got. -----Original Message----- From: "Colton Conor" Sent: Wednesday, February 3, 2016 9:34am To: "Nick Hilliard" Cc: "NANOG" Subject: Re: Low density Juniper (or alternative) Edge I see Cisco and Juniper mentioned here, but what about all the smart NID companies out there? I found these of MEF list: Accedian, Altera, BTI Systems, Ciena (Nasdaq: CIEN ), Cisco (Nasdaq: CSCO ), Cyan, FibroLAN, Huawei, Infinera (Nasdaq: INFN ), Juniper Networks (NYSE: JNPR ), MRV, Omnitron, Overture, PT Inovacao, Pulsecom, RAD Data Communications, Telco Systems, Tellabs (Nasdaq: TLAB ), Transition Networks and Transmode. Some of these guys focus what seems like exclusively on ethernet NID devices, and most all are MEF certified. Does anyone use the above vendors NIDs? On Wed, Feb 3, 2016 at 1:58 AM, Nick Hilliard wrote: > David Bass wrote: > > Looking to see what others are using out there as an alternative to a > > Cisco ME3600X? Also, what other vendors out there are playing in this > > space? > > > > Need a full MPLS stack. > > Before choosing a box, you need to figure out: > > - how many ports you need, and of what speed > - how much you're prepared to pay > - how much rack real estate you're ok about dedicating per box > - what sort of mpls features you need (vpls / l2vpn-pw / l3vpn / 6pe / > 6vpe, etc) > - whether rich qos is a requirement > - whether you're ever going to need good quality LAG / ECMP support on > the platform > - what vendor software you're happy to work with > - whether you're ok with per port licensing > > Typically the features that fall by the wayside first are: reasonable > port buffers, qos knobs and decent lag/ecmp hashing support for mpls > packets. The qos/port buffers tend to be more of a problem on the 10G > platforms, but you didn't state whether you were interested in 1G or > 10G, or how many ports you were looking for per box. > > E.g. the production evolution for the me3600 is the asr920, which is > better is most aspects except for shared buffer space. This means that > the me3600 has better qos support, if deeper buffers are what's > important. OTOH, if you need to do fine-grained qos based on ACLs or > ports, then this platform isn't for you. > > Most smaller mpls boxes don't load balance well over LAGs or ECMP > because they lack the ability to inspect deep into the packet to get > enough flow-aware entropy together to build a reasonable hash. If all > your PE devices support flow-aware transport (rfc6391), you're fine, but > very few smaller mpls boxes support this feature. > > If 10G is a requirement, then you need to make a choice between one of > the merchant chipsets (e.g. broadcom trident range) and vendor specific > chipsets. Many of the larger vendors support the merchant chipsets > these days for 10G access, but feature support can be varied. E.g. some > devices don't support vpls and never will. Some are a bit behind on > product development and don't yet support features like l3vpn or 6PE or > 6VPE, even though they are roadmapped. > > Nick > From morrowc.lists at gmail.com Wed Feb 3 15:48:56 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 3 Feb 2016 10:48:56 -0500 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: <495D0934DA46854A9CA758393724D5902D74A527@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> <87mvrj77ml.fsf@nemi.mork.no> <56B151DA.1060405@direcpath.com> <2088031896-1454466802-cardhu_decombobulator_blackberry.rim.net-2032550800-@b11.c1.bise6.blackberry> <495D0934DA46854A9CA758393724D5902D74A527@NI-MAIL02.nii.ads> Message-ID: On Wed, Feb 3, 2016 at 2:18 AM, Erik Sundberg wrote: > Digi has something called USB Anywhere. http://www.digi.com/products/usb-and-serial-connectivity/usb-over-ip-hubs/anywhereusb > #fail "COMING SOON: Security features, such as SSL and SNMPv3" :( "Creates systems redundancy and increases security" unless you consider ssl and snmpv3 security relevant I guess? Also of interest: "10/100 Mb switched Ethernet" I hope your local-in-pop switch gear has 10/100/1000 and not just 1000 ports. This may be more problematic as the future progresses... (you can't get 100mbps ports on a qfx if I recall correctly, for example) > However I would like to limit the amount of equipment we deploy at a pop, the majority of our pop's don't have servers... Just Routers, Switches, Console Servers, and your other Network Hardware. > 'console server' is, in one view of the world, now 'usb console server' ... > The problem with USB is you can only wire a USB 2.0 Cable up to 15' (Per Google).... And you have to purchase a cable premade. > this is a fairly salient point :( If I don't have a console server in each rack (or pair of racks) but as a row element, now I have significantly shorter row length before I can't console anymore. > Where as with a Serial Console you can go around 100', not to mention about just about everyone has a crimper, rj45 ends, and cat5 cable, to run and make cables as needed. > maybe the ubiquity of usb consoles will drive this i the right direction as well? > Assuming something is broke...With USB let's say you rely on remote hands to do a lot of work in the colo's. First they need to find a *Working Laptop*, then you have to walk the tech through downloading the drivers and installing them on there laptop. Hoping they have permissions to install software on there laptops. Plus if it's really broke and you get no output, you will never be sure if it's USB related or not. Where as serial it's just going to work, and it's easy to test to see if it's working on not by hooking up to another device. > my guess is that most / all tech's have a usb-serial dongle at this point, because who's laptop has serial ports anymore natively onboard? mostly you're outlining 'operational practices and norms are not accounted for yet in the usb-console design' right? which either is: 1) get out and write procedures/documentation for how this all should work 2) call back to 2005 and demand no usb in consoles on network equipment I don't think 2 is feasible :( but 1 sure is... Also, it's sort of funny to me that servers don't seem to be going this route? > > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender > Sent: Tuesday, February 02, 2016 8:33 PM > To: Robert Drake ; NANOG ; nanog at nanog.org > Subject: Re: Devices with only USB console port - Need a Console Server Solution > > Why not use udev rules so the ports are persistent? I did that on a pi that I was using as an ice cast box. Based on the usb audio port on reboots I know which device is which stream. > > > Regards, > > Dovid > > -----Original Message----- > From: Robert Drake > Sender: "NANOG" Date: Tue, 2 Feb 2016 20:03:22 > To: > Subject: Re: Devices with only USB console port - Need a Console Server Solution > > > On 2/2/2016 5:02 AM, Bj?rn Mork wrote: >> >> No inside pictures :) >> >> Assuming that this is really an USB device, and that the console port is >> really an USB host port, it would be useful to know the USB decriptors >> of the device. You wouldn't be willing to connect it to a Linux PC and >> run "lsusb -vd", would you? > I'm inconveniently consoled into one via a combination of remote desktop > into windows -- linux console on a virtual machine -- screen > /dev/ttyACM0. Because of this posting lsusb -vd is taxing. > > Linux has full support for the device. It sees it as cdc_acm. > > The vendor id is 0x04e2 (Exar Corp). Product ID is 0x1410. I've got > two connected right now. This is in our lab and the windows box is > temporary. Our intention is to use a raspberry pi for the terminal server. > > I'm obviously not in front of it, but I'm wondering if they can be > enumerated by something other than when they were plugged in. That's my > biggest hurdle for making a console server for them.. how to figure out > what router is connected to which USB port after a reboot, or someone > getting unpluggy with cables. > >> >> Bj?rn >> > > Robert > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From mfidelman at meetinghouse.net Wed Feb 3 16:00:41 2016 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 3 Feb 2016 11:00:41 -0500 Subject: Devices with only USB console port - Need a Console Server Solution In-Reply-To: References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads> <1449532297.20094.44.camel@karl> <495D0934DA46854A9CA758393724D5902D746CFF@NI-MAIL02.nii.ads> <87mvrj77ml.fsf@nemi.mork.no> <56B151DA.1060405@direcpath.com> <2088031896-1454466802-cardhu_decombobulator_blackberry.rim.net-2032550800-@b11.c1.bise6.blackberry> <495D0934DA46854A9CA758393724D5902D74A527@NI-MAIL02.nii.ads> Message-ID: <56B22429.5050101@meetinghouse.net> Lantronix makes some serial_port-to-IP remote management devices, as well as KVM-over-IP. Some of them support USB interfaces. Be warned - you probably want to run these through a VPN gatway (most of these things are built on old versions of embedded linux - there have been compromises - the same applies to IPMI boards - been bit by this personally). Miles Fidelman On 2/3/16 10:48 AM, Christopher Morrow wrote: > On Wed, Feb 3, 2016 at 2:18 AM, Erik Sundberg wrote: >> Digi has something called USB Anywhere. http://www.digi.com/products/usb-and-serial-connectivity/usb-over-ip-hubs/anywhereusb >> > #fail > "COMING SOON: Security features, such as SSL and SNMPv3" > > :( > > "Creates systems redundancy and increases security" > > unless you consider ssl and snmpv3 security relevant I guess? Also of interest: > "10/100 Mb switched Ethernet" I hope your local-in-pop switch gear > has 10/100/1000 and not just 1000 ports. This may be more problematic > as the future progresses... (you can't get 100mbps ports on a qfx if I > recall correctly, for example) > >> However I would like to limit the amount of equipment we deploy at a pop, the majority of our pop's don't have servers... Just Routers, Switches, Console Servers, and your other Network Hardware. >> > 'console server' is, in one view of the world, now 'usb console server' ... > >> The problem with USB is you can only wire a USB 2.0 Cable up to 15' (Per Google).... And you have to purchase a cable premade. >> > this is a fairly salient point :( If I don't have a console server in > each rack (or pair of racks) but as a row element, now I have > significantly shorter row length before I can't console anymore. > >> Where as with a Serial Console you can go around 100', not to mention about just about everyone has a crimper, rj45 ends, and cat5 cable, to run and make cables as needed. >> > maybe the ubiquity of usb consoles will drive this i the right > direction as well? > >> Assuming something is broke...With USB let's say you rely on remote hands to do a lot of work in the colo's. First they need to find a *Working Laptop*, then you have to walk the tech through downloading the drivers and installing them on there laptop. Hoping they have permissions to install software on there laptops. Plus if it's really broke and you get no output, you will never be sure if it's USB related or not. Where as serial it's just going to work, and it's easy to test to see if it's working on not by hooking up to another device. >> > my guess is that most / all tech's have a usb-serial dongle at this > point, because who's laptop has serial ports anymore natively onboard? > > mostly you're outlining 'operational practices and norms are not > accounted for yet in the usb-console design' right? which either is: > 1) get out and write procedures/documentation for how this all should work > 2) call back to 2005 and demand no usb in consoles on network equipment > > I don't think 2 is feasible :( but 1 sure is... Also, it's sort of > funny to me that servers don't seem to be going this route? > > >> >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dovid Bender >> Sent: Tuesday, February 02, 2016 8:33 PM >> To: Robert Drake ; NANOG ; nanog at nanog.org >> Subject: Re: Devices with only USB console port - Need a Console Server Solution >> >> Why not use udev rules so the ports are persistent? I did that on a pi that I was using as an ice cast box. Based on the usb audio port on reboots I know which device is which stream. >> >> >> Regards, >> >> Dovid >> >> -----Original Message----- >> From: Robert Drake >> Sender: "NANOG" Date: Tue, 2 Feb 2016 20:03:22 >> To: >> Subject: Re: Devices with only USB console port - Need a Console Server Solution >> >> >> On 2/2/2016 5:02 AM, Bj?rn Mork wrote: >>> No inside pictures :) >>> >>> Assuming that this is really an USB device, and that the console port is >>> really an USB host port, it would be useful to know the USB decriptors >>> of the device. You wouldn't be willing to connect it to a Linux PC and >>> run "lsusb -vd", would you? >> I'm inconveniently consoled into one via a combination of remote desktop >> into windows -- linux console on a virtual machine -- screen >> /dev/ttyACM0. Because of this posting lsusb -vd is taxing. >> >> Linux has full support for the device. It sees it as cdc_acm. >> >> The vendor id is 0x04e2 (Exar Corp). Product ID is 0x1410. I've got >> two connected right now. This is in our lab and the windows box is >> temporary. Our intention is to use a raspberry pi for the terminal server. >> >> I'm obviously not in front of it, but I'm wondering if they can be >> enumerated by something other than when they were plugged in. That's my >> biggest hurdle for making a console server for them.. how to figure out >> what router is connected to which USB port after a reboot, or someone >> getting unpluggy with cables. >> >>> Bj?rn >>> >> Robert >> >> ________________________________ >> >> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From wilhelm at ripe.net Wed Feb 3 18:39:22 2016 From: wilhelm at ripe.net (Rene Wilhelm) Date: Wed, 3 Feb 2016 19:39:22 +0100 Subject: as24748 In-Reply-To: <96B63F40-2CBB-416A-8554-D5803BC2EA65@hammerfiber.com> References: <96B63F40-2CBB-416A-8554-D5803BC2EA65@hammerfiber.com> Message-ID: <56B2495A.5070902@ripe.net> Hi, On 2/3/16 11:54 AM, Daniel Corbe wrote: > Can anyone venture a guess as to what this might be about? > > http://irrexplorer.nlnog.net/search/AS24748:AS-THINX > > Why would my ASN be part of a foreign AS-SET? Is this something I need to worry about? My gut reaction is to reach out to ripe. > You can see the full AS-SET object here https://apps.db.ripe.net/search/query.html?searchtext=AS24748:AS-THINX&types=as-set&bflag=true&source=RIPE#resultsAnchor or via traditional whois: whois -h whois.ripe.net AS24748:AS-THINX as-set: AS24748:AS-THINX descr: ASes advertised to IX/peerings members: AS1, AS2, AS3, AS4, AS5 members: AS6, AS10, AS13, AS16, AS17 [ 6795 lines deleted ] members: AS1973394, AS2262647, AS2629023, AS5111197, AS5114372 remarks: 33995 tech-c: ATMA2-RIPE admin-c: ATMA1-RIPE mnt-by: ATMAN-MNT created: 2013-12-11T05:06:03Z last-modified: 2016-02-02T05:07:39Z source: RIPE # Filtered For more details what this is about it's best to reach out to the folk at ATMAN, noc at atman.pl -- Rene From lists+nanog at brumund.ca Wed Feb 3 20:19:24 2016 From: lists+nanog at brumund.ca (Karl Brumund) Date: Wed, 3 Feb 2016 15:19:24 -0500 Subject: NANOG66 hotel - extra room? Message-ID: Any chance anybody has a spare room they are planning to cancel? If so, please contact me off list. Thank you, ...karl From manager at monmouth.com Wed Feb 3 21:59:53 2016 From: manager at monmouth.com (Mark Stevens) Date: Wed, 3 Feb 2016 16:59:53 -0500 Subject: Neustar CNAME storage issues In-Reply-To: References: Message-ID: <56B27859.8060504@monmouth.com> If someone from Neustar reads this, can you please contact me off list in regards to your CNAM service which has issues? Thanks Mark From m4rtntns at gmail.com Thu Feb 4 11:14:36 2016 From: m4rtntns at gmail.com (Martin T) Date: Thu, 4 Feb 2016 13:14:36 +0200 Subject: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters Message-ID: Hi, am I correct that ISPs (in RIPE region), who update their BGP prefix filters automatically, ask their IP transit customer or peering partner to provide their "route"/"route6" object(s) or "as-set" object in order to find all the prefixes which they should accept? If the IP transit customer or peering partner provides an "as-set", then ISP needs to ensure that this "as-set" belongs to this IP transit customer or peering partner because there is no automatic authentication for this, i.e. anybody can create an "as-set" object to database with random "members" attributes? This is opposite to "route"/"route6" objects which follow a strict authentication scheme. In addition, in case of "as-set", an ISP needs to recursively find all the AS numbers from "members" attributes because "as-set" can include other "as-sets"? Quite a lot of question, but I would simply like to be sure that I understand this correctly. thanks, Martin From htj at nordu.net Thu Feb 4 11:58:54 2016 From: htj at nordu.net (Henrik Thostrup Jensen) Date: Thu, 4 Feb 2016 12:58:54 +0100 (CET) Subject: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters In-Reply-To: References: Message-ID: Hi Martin On Thu, 4 Feb 2016, Martin T wrote: > am I correct that ISPs (in RIPE region), who update their BGP prefix > filters automatically, ask their IP transit customer or peering > partner to provide their "route"/"route6" object(s) or "as-set" object > in order to find all the prefixes which they should accept? This is a common practice to do. Both within and outside the RIPE region. For bigger networks, prefix lists become somewhat unwieldy, and one can then use as-path filters instead. Use a prefix limit with this. Typically you use a tool (bgpq3) to generate the prefix lists. > If the IP transit customer or peering partner provides an "as-set", then > ISP needs to ensure that this "as-set" belongs to this IP transit > customer or peering partner because there is no automatic authentication > for this, i.e. anybody can create an "as-set" object to database with > random "members" attributes? I don't know the procedure for creating as-sets, maybe someone else can chip in. > This is opposite to "route"/"route6" objects which follow a strict > authentication scheme. I believe this differs depending on the irrd software/operator. > In addition, in case of "as-set", an ISP needs to recursively find all > the AS numbers from "members" attributes because "as-set" can include > other "as-sets"? Some irrd servers, can expand this automatically (I think). But seriously, use a tool for this. > Quite a lot of question, but I would simply like to be sure that I > understand this correctly. There are basically two abstractions: 1. as-set. Can contain other as-sets or as numbers. 2. prefixes are registered to an as-number. Remember that there are multiple IRR servers, and they mirror each other. Use http://irrexplorer.nlnog.net/ to play around a bit :-). Best regards, Henrik Henrik Thostrup Jensen Software Developer, NORDUnet From pavel.odintsov at gmail.com Thu Feb 4 12:13:48 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Thu, 4 Feb 2016 15:13:48 +0300 Subject: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters In-Reply-To: References: Message-ID: Hello! You could check awesome project for this purposes: http://www.stableit.ru/2015/06/generate-bgp-filters-with-bgpq3.html It's authored by Russian carrier RETN.net. On Thu, Feb 4, 2016 at 2:58 PM, Henrik Thostrup Jensen wrote: > Hi Martin > > On Thu, 4 Feb 2016, Martin T wrote: > >> am I correct that ISPs (in RIPE region), who update their BGP prefix >> filters automatically, ask their IP transit customer or peering >> partner to provide their "route"/"route6" object(s) or "as-set" object >> in order to find all the prefixes which they should accept? > > > This is a common practice to do. Both within and outside the RIPE region. > For bigger networks, prefix lists become somewhat unwieldy, and one can then > use as-path filters instead. Use a prefix limit with this. > > Typically you use a tool (bgpq3) to generate the prefix lists. > >> If the IP transit customer or peering partner provides an "as-set", then >> ISP needs to ensure that this "as-set" belongs to this IP transit customer >> or peering partner because there is no automatic authentication for this, >> i.e. anybody can create an "as-set" object to database with random "members" >> attributes? > > > I don't know the procedure for creating as-sets, maybe someone else can chip > in. > >> This is opposite to "route"/"route6" objects which follow a strict >> authentication scheme. > > > I believe this differs depending on the irrd software/operator. > >> In addition, in case of "as-set", an ISP needs to recursively find all the >> AS numbers from "members" attributes because "as-set" can include other >> "as-sets"? > > > Some irrd servers, can expand this automatically (I think). But seriously, > use a tool for this. > >> Quite a lot of question, but I would simply like to be sure that I >> understand this correctly. > > > There are basically two abstractions: > > 1. as-set. Can contain other as-sets or as numbers. > 2. prefixes are registered to an as-number. > > Remember that there are multiple IRR servers, and they mirror each other. > > Use http://irrexplorer.nlnog.net/ to play around a bit :-). > > > Best regards, Henrik > > Henrik Thostrup Jensen > Software Developer, NORDUnet > > -- Sincerely yours, Pavel Odintsov From edugas at unknowndevice.ca Thu Feb 4 14:58:29 2016 From: edugas at unknowndevice.ca (Eric Dugas) Date: Thu, 4 Feb 2016 09:58:29 -0500 Subject: Local last-mile providers in Manhattan Message-ID: Hi NANOG, I'm searching for last-mile providers in Manhattan (near the Holland tunnel) to provide a 100Mbps and 1Gbps EPL to 60 Hudson. I would like to avoid the bigger players as much as possible. Thanks Eric From jared at puck.nether.net Thu Feb 4 16:32:54 2016 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Feb 2016 11:32:54 -0500 Subject: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters In-Reply-To: References: Message-ID: <02887B31-4BBD-4175-97DF-AA62708706CC@puck.nether.net> > On Feb 4, 2016, at 6:58 AM, Henrik Thostrup Jensen wrote: > >> In addition, in case of "as-set", an ISP needs to recursively find all the AS numbers from "members" attributes because "as-set" can include other "as-sets"? > > Some irrd servers, can expand this automatically (I think). But seriously, use a tool for this. > >> Quite a lot of question, but I would simply like to be sure that I understand this correctly. > > There are basically two abstractions: > > 1. as-set. Can contain other as-sets or as numbers. > 2. prefixes are registered to an as-number. > > Remember that there are multiple IRR servers, and they mirror each other. > > Use http://irrexplorer.nlnog.net/ to play around a bit :-). > Yes. We record the customer ASN and the AS-SET for each AFI (v4|v6) and expand these and push updated lists to devices daily or on demand based on customer need. You should be able to build off any of the mirrored IRRds out there as they all mirror each other, often with minimal lag (5-30 minutes). The days of fetching via FTP once a day are long gone and a relic of the past. I recommend using AS-PATH combined with prefix filters to keep your pants on. Rejecting things like networks you may get transit from from customers, and peers helps avoid feeding my route leak system. http://puck.nether.net/bgp/leakinfo.cgi You should also not be using any IOS devices for BGP as documented in CSCuq14541 where they leak the full table. - Jared From randy at psg.com Thu Feb 4 16:40:36 2016 From: randy at psg.com (Randy Bush) Date: Thu, 04 Feb 2016 17:40:36 +0100 Subject: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters In-Reply-To: <02887B31-4BBD-4175-97DF-AA62708706CC@puck.nether.net> References: <02887B31-4BBD-4175-97DF-AA62708706CC@puck.nether.net> Message-ID: > We record the customer ASN and the AS-SET for each AFI (v4|v6) and > expand these and push updated lists to devices daily or on demand > based on customer need. do you trust the state of the acl on the router and only send a delta, or do you send the whole acl? randy From jared at puck.Nether.net Thu Feb 4 16:43:32 2016 From: jared at puck.Nether.net (Jared Mauch) Date: Thu, 4 Feb 2016 11:43:32 -0500 Subject: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters In-Reply-To: References: <02887B31-4BBD-4175-97DF-AA62708706CC@puck.nether.net> Message-ID: <20160204164332.GA10101@puck.nether.net> On Thu, Feb 04, 2016 at 05:40:36PM +0100, Randy Bush wrote: > > We record the customer ASN and the AS-SET for each AFI (v4|v6) and > > expand these and push updated lists to devices daily or on demand > > based on customer need. > > do you trust the state of the acl on the router and only send a delta, > or do you send the whole acl? We send the whole ACL. (infact, we send the full router config each time). - 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 randy at psg.com Thu Feb 4 16:52:54 2016 From: randy at psg.com (Randy Bush) Date: Thu, 04 Feb 2016 17:52:54 +0100 Subject: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters In-Reply-To: <20160204164332.GA10101@puck.nether.net> References: <02887B31-4BBD-4175-97DF-AA62708706CC@puck.nether.net> <20160204164332.GA10101@puck.nether.net> Message-ID: >>> We record the customer ASN and the AS-SET for each AFI (v4|v6) and >>> expand these and push updated lists to devices daily or on demand >>> based on customer need. >> >> do you trust the state of the acl on the router and only send a delta, >> or do you send the whole acl? > > We send the whole ACL. > > (infact, we send the full router config each time). i bet that scales well. though i would not trust the router either. randy From oliver.d at prodege.com Thu Feb 4 00:25:18 2016 From: oliver.d at prodege.com (Oliver Ddin) Date: Wed, 3 Feb 2016 16:25:18 -0800 Subject: Fwd: Pretty Please Flush your DNS? In-Reply-To: <000601d15ee1$e9e7f340$bdb7d9c0$@prodege.com> References: <000601d15ee1$e9e7f340$bdb7d9c0$@prodege.com> Message-ID: Hey Folks, If you're a network operator running caching DNS servers and you're a charitable sort, could you pretty please flush records for swagbucks.com? We unfortunately had a 24h NXDOMAIN caching time and we're now in a spot of trouble since we were temporarily returning NXDOMAIN for our www. record. Many Thanks and facepalms, Oliver. From prt at prt.org Thu Feb 4 11:34:03 2016 From: prt at prt.org (Paul Thornton) Date: Thu, 4 Feb 2016 11:34:03 +0000 Subject: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters In-Reply-To: References: Message-ID: <56B3372B.9020008@prt.org> On 04/02/2016 11:14, Martin T wrote: > Hi, > > am I correct that ISPs (in RIPE region), who update their BGP prefix > filters automatically, ask their IP transit customer or peering > partner to provide their "route"/"route6" object(s) or "as-set" object > in order to find all the prefixes which they should accept? If the IP > transit customer or peering partner provides an "as-set", then ISP > needs to ensure that this "as-set" belongs to this IP transit customer > or peering partner because there is no automatic authentication for > this, i.e. anybody can create an "as-set" object to database with > random "members" attributes? This is opposite to "route"/"route6" > objects which follow a strict authentication scheme. In addition, in > case of "as-set", an ISP needs to recursively find all the AS numbers > from "members" attributes because "as-set" can include other > "as-sets"? Quite a lot of question, but I would simply like to be sure > that I understand this correctly. Yes you do. Typically, you'll tell the transit provider something like "We are AS23456 announcing AS-STUFF" at order time so they know what to look up. What then happens is they have something that does the following as either a semi-automatic or fully automatic process: 1) Iterate through AS-STUFF to get a unique list of AS numbers that are involved. 2) Go through this list of ASes, doing an inverse lookup of route or route6 objects with an origin of those ASes. 3) Create filter list from the above list. The route/route6 objects actually have very weak authentication for out-of-RIPE-region prefixes. For example, if I want to add a route object for ARIN prefix originating from my RIPE-region AS, there is a dummy maintainer to make this possible. This is currently subject to somewhat of a debate on the mailing lists because of the obvious abuse vector, and there are cases where this has been used to help "legitimise" address space hijacks. Unfortunately it is hard to simultaneously allow legitimate unauthenticated use without allowing abusive route objects. Which is why there is a lot of head-scratching here; I don't have an answer to that one. Paul. From jared at puck.Nether.net Thu Feb 4 16:58:42 2016 From: jared at puck.Nether.net (Jared Mauch) Date: Thu, 4 Feb 2016 11:58:42 -0500 Subject: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters In-Reply-To: References: <02887B31-4BBD-4175-97DF-AA62708706CC@puck.nether.net> <20160204164332.GA10101@puck.nether.net> Message-ID: <20160204165842.GA11610@puck.nether.net> On Thu, Feb 04, 2016 at 05:52:54PM +0100, Randy Bush wrote: > >>> We record the customer ASN and the AS-SET for each AFI (v4|v6) and > >>> expand these and push updated lists to devices daily or on demand > >>> based on customer need. > >> > >> do you trust the state of the acl on the router and only send a delta, > >> or do you send the whole acl? > > > > We send the whole ACL. > > > > (infact, we send the full router config each time). > > i bet that scales well. though i would not trust the router either. it works well enough, software bugs aside. much better than wondering what state a device is in. our customer migration team was able to use this toolization to move over 200 discrete interfaces in one night without error recently. having the proper tooling and inventory of customers is key here. when turning up the first few customers, i get having a manual process but the ROI on automation is well worth it. there's many variations of this graphic out there but it's important when justifying why you have a network engineer who can also code and do more than one thing: http://www.geeksaresexy.net/2012/01/05/geeks-vs-non-geeks-picture/ there's also this related item, you do have to maintain it: https://xkcd.com/1319/ if you avoid feature creep the tools can be done properly. I've seen many a project delayed by someone trying to wedge something in, or alter a schema from one that works to one that is more technically pure and make it harder to do work. you must also have the culture that works with the tools, it can't be the one tool that $powerUser operates, it has to be part of the busines process. - 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 jcurran at arin.net Thu Feb 4 20:15:29 2016 From: jcurran at arin.net (John Curran) Date: Thu, 4 Feb 2016 20:15:29 +0000 Subject: Change re ARIN RPKI Relying Party TAL access In-Reply-To: <56B3AC5E.8070305@arin.net> References: <56B3AC5E.8070305@arin.net> Message-ID: <378804E8-D587-403C-A1EB-CAD4A987E32F@arin.net> NANOGers - One of the concerns raised at a previous NANOG was with respect to the need for an RPKI relying parties to explicitly accept ARIN's relying party agreement (RPA) - note that this has now been changed (per the attached announcement) Wile the RPA terms remain the same, it is no longer necessary to click-accept and provide an email in order to access ARIN's trust anchor locator (TAL). FYI, /John Begin forwarded message: From: ARIN > Date: February 4, 2016 at 2:54:06 PM EST To: > Subject: [arin-announce] RPKI Relying Party Update In response to community feedback, entities wishing to become relying parties and utilize ARIN's Trust Anchor Locator (TAL) and Resource Public Key Infrastructure (RPKI) repository information will no longer be required to "click to accept" ARIN's Relying Party Agreement (RPA) before doing so. Please note that access to and usage of ARIN's TAL and RPKI repository data remains equally subject to the terms of the RPA. To access the TAL, visit: www.arin.net/resources/rpki/tal.html Regards, John Curran President & CEO American Registry for Internet Numbers From holbor at sonss.net Fri Feb 5 04:13:58 2016 From: holbor at sonss.net (Richard Holbo) Date: Thu, 4 Feb 2016 20:13:58 -0800 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: I'm in the middle of pulling some Cisco 7246VXR-UBR's (antiques) and replacing them with the Huawei D-CMTS devices. From what I understand of your needs, the Huawei devices will do what you are looking for. We are running 8x4, but can upgrade the licenses to 24x4 if we need the bandwidth, although at that point you will be more limited by the gig uplink. I'm designing them to not serve more than 250 customers per cmts and they are running a single vlan on the cable side back to an ISC DHCP server with very simple config files served via tftp. This allows me to group the CMTS's for reasonably efficient use of IP. Have not done IP6 on these yet, but will fairly soon. They are actually designed to run as a ONT from the Huawei OLT (GPON), but will also accept a standard SFP and run off ethernet (that's how I'm doing it). Compared to the other small CMTS's I looked at these are hard to beat. they are Hardened and can be mounted anywhere. The config to do what I'm using them for is really simple (I'm a big believer in KISS). Have had some in service for a few months now with no issues. I've used some 24 port VDSL switches in the past for MDU's and may actually pull some of those and use these where there is RG6 house wiring as they support a LOT more management than any of the smaller DSLAMS I've looked at. In this configuration I can easily support 100mbit service on DOCSIS 3, and my unlimited modems will speedtest all the way to 280mbs. FWIW /rh On Tue, Feb 2, 2016 at 10:24 AM, Colton Conor wrote: > Yes, we are in the USA. So based on everyones recommendations, I am going > to stay far away from EURODOCSIS. I was told be a vendor that Arris and > other USA FCC certified cable modems could easily be flashed to EURODOCIS > mode, so I did not think the CPE side was that big of a deal (is that even > true). I was not aware that there were so many differences besides just the > channel width. > > So, assuming we are talking about DOCSIS only (and not EURODOCSIS), what do > you recommend? I like the idea of being able to upgrade to 3.1, but not > sure if there are any small systems capable of this? By small I mean > something that could feed less than 100 units, and be economical to do. > Cable has the advantage of cheap modems, so it's really the CMTS side. > > Please remember I am only interested in data internet services over this > plant. Something that works for garden style layouts where I can bring > fiber or coaxial to the side of a garden townhome that has between 4 to 16 > units inside of it. The reason I requested a harden outdoor unit is that > most all of the garden style properties have both the phone > and coaxial drops on the outside of the building. There is no central > closet or room. Plus we are in the south, so hardened for the > heat exposure makes sense. > > A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like what I > want. I will check into Huawei and Gainspeed. Who else makes these? > > > > > On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms wrote: > > > Nick, > > > > Absolutely, if your plant is in Europe or one of the other areas (lots of > > Africa and the middle East is like that) that adopted EuroDOCSIS I'd > agree > > wholeheartedly. I didn't see Colton say where they're located, but all > > North America is the US flavor so that's what I assume on NANOG. > > > > That being said, the best thing that seldom gets mentioned about D3.1 is > > getting us to unified channelization. > > Scott Helms wrote: > > > That very small upside for an extreme downside.Trying to hire someone > > > to work on your system with Euro channelization, not to mention buying > > > amplifiers and passives is a huge PITA. > > > > ... if your plant is in the US. > > > > > I have customers in Europe who > > > decided to do US DOCSIS and they universally wish they had used the > > > local "flavor". > > > > as you say, eurodocsis works well in europe. > > > > 3.1 will be a major improvement when it materialises. > > > > Nick > > > From khomyakov.andrey at gmail.com Fri Feb 5 16:36:51 2016 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Fri, 5 Feb 2016 11:36:51 -0500 Subject: Arista optics In-Reply-To: References: <3D04BF89-912D-4FD7-9FFF-BD800B3798DD@thrashyour.com> Message-ID: We are having good luck with optics from OSI Hardware for Cisco, Juniper and Arista. They even had presence at NANOG65. I recommend. --Andrey On Wed, Jan 27, 2016 at 11:38 AM, J Crowe wrote: > *edit* be aware that if you are on the latest code revision 4.15.x that > you may have to manually reseat the flexoptics SFPs for them to work --- > this is after you reboot/reload the switch. > > On Wed, Jan 27, 2016 at 8:30 AM, J Crowe wrote: > > > If you are going to be using Flexoptics copper SFPs, be aware that if you > > are on the latest code revision 4.15.x that you may have to manually > reseat > > the flexoptics SFPs for them to work. I have run into this issue recently > > in our lab. I can confirm that if you use 4.14.x that you will not have > to > > reseat them. > > > > Thanks > > Joe Crowe > > > > On Tue, Jan 26, 2016 at 3:10 PM, Colton Conor > > wrote: > > > >> Who are you referring to David? Are you mentioning flexoptix? Is for are > >> are saying I can recode a fiberstore sfp using a flexoptics programmer? > >> > >> On Mon, Jan 25, 2016 at 8:28 PM, David Lucey > >> wrote: > >> > >> > They used to lock in, but optics have gotten so competitive that they > >> > aren't pushing it anymore. They have a list of optics they interop > >> with, > >> > and will give you an unlock code with your order. > >> > > >> > Cheers, > >> > David > >> > > >> > > >> > --- > >> > Keys mashed on a very tiny keyboard. > >> > > >> > > On Jan 20, 2016, at 08:55, John Kinsella > wrote: > >> > > > >> > > Last I heard, EOS locks out non-Arista optics by default. You have > to > >> > contact support for instructions to enable 3rd party modules. > >> > > > >> > > I?m running all Arista cables/optics - at the point when we ordered > >> the > >> > pricing was competitive with 3rd party, but that was several years ago > >> and > >> > the vendor was hungry. > >> > > > >> > > John > >> > > > >> > >> On Jan 20, 2016, at 8:39 AM, Alex Forster > >> wrote: > >> > >> > >> > >> Hi everyone! > >> > >> > >> > >> I'm trying to get buy-in to go with Arista for some new > >> infrastructure, > >> > but the Arista optics just aren't in the ballpark for us at > >> > "proof-of-concept" volume. In Cisco-land, we've had great success > using > >> > Finisar optics, and they've been an easy "sell" to management since > many > >> > Cisco optics are just rebranded Finisar's. > >> > >> > >> > >> The relevant Arista optics I'm looking at are QSFP-100G-LR4 and > >> > SFP-10G-LR. Does anybody know what supplier(s) manufacture these > optics > >> for > >> > Arista? Alternatively, does anyone have any experience using > third-party > >> > comparable optics (especially the 100G) in the battlefield? > >> > >> > >> > >> Since optics sales are pretty cut-throat, I do ask that you > disclose > >> if > >> > you have a financial interest in any of your suggestions. > >> > >> > >> > >> Thanks! > >> > >> > >> > >> Alex Forster > >> > > > >> > > >> > > > > > From job at instituut.net Fri Feb 5 16:44:32 2016 From: job at instituut.net (Job Snijders) Date: Fri, 5 Feb 2016 17:44:32 +0100 Subject: Change re ARIN RPKI Relying Party TAL access In-Reply-To: <378804E8-D587-403C-A1EB-CAD4A987E32F@arin.net> References: <56B3AC5E.8070305@arin.net> <378804E8-D587-403C-A1EB-CAD4A987E32F@arin.net> Message-ID: <20160205164432.GI1192@57.rev.meerval.net> Dear John, On Thu, Feb 04, 2016 at 08:15:29PM +0000, John Curran wrote: > One of the concerns raised at a previous NANOG was with respect to the > need for an RPKI relying parties to explicitly accept ARIN's relying > party agreement (RPA) - note that this has now been changed (per the > attached announcement) > > Wile the RPA terms remain the same, it is no longer necessary to > click-accept and provide an email in order to access ARIN's trust > anchor locator (TAL). Can you explain in layman terms what the legal consequences of this change are? Kind regards, Job From cscora at apnic.net Fri Feb 5 18:11:18 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Feb 2016 04:11:18 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201602051811.u15IBIEt032399@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 Feb, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 579829 Prefixes after maximum aggregation (per Origin AS): 214286 Deaggregation factor: 2.71 Unique aggregates announced (without unneeded subnets): 283493 Total ASes present in the Internet Routing Table: 52687 Prefixes per ASN: 11.01 Origin-only ASes present in the Internet Routing Table: 36566 Origin ASes announcing only one prefix: 15809 Transit ASes present in the Internet Routing Table: 6420 Transit-only ASes present in the Internet Routing Table: 167 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 40 Max AS path prepend of ASN ( 40285) 34 Prefixes from unregistered ASNs in the Routing Table: 1025 Unregistered ASNs in the Routing Table: 366 Number of 32-bit ASNs allocated by the RIRs: 12626 Number of 32-bit ASNs visible in the Routing Table: 9701 Prefixes from 32-bit ASNs in the Routing Table: 37199 Number of bogon 32-bit ASNs visible in the Routing Table: 15 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 426 Number of addresses announced to Internet: 2803186500 Equivalent to 167 /8s, 21 /16s and 59 /24s Percentage of available address space announced: 75.7 Percentage of allocated address space announced: 75.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.0 Total number of prefixes smaller than registry allocations: 190503 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 148486 Total APNIC prefixes after maximum aggregation: 40921 APNIC Deaggregation factor: 3.63 Prefixes being announced from the APNIC address blocks: 157427 Unique aggregates announced from the APNIC address blocks: 63676 APNIC Region origin ASes present in the Internet Routing Table: 5133 APNIC Prefixes per ASN: 30.67 APNIC Region origin ASes announcing only one prefix: 1186 APNIC Region transit ASes present in the Internet Routing Table: 900 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1850 Number of APNIC addresses announced to Internet: 751833732 Equivalent to 44 /8s, 208 /16s and 18 /24s Percentage of available APNIC address space announced: 87.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 179072 Total ARIN prefixes after maximum aggregation: 88754 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 183681 Unique aggregates announced from the ARIN address blocks: 87066 ARIN Region origin ASes present in the Internet Routing Table: 16412 ARIN Prefixes per ASN: 11.19 ARIN Region origin ASes announcing only one prefix: 5897 ARIN Region transit ASes present in the Internet Routing Table: 1706 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 37 Number of ARIN region 32-bit ASNs visible in the Routing Table: 987 Number of ARIN addresses announced to Internet: 1101651264 Equivalent to 65 /8s, 169 /16s and 221 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 139378 Total RIPE prefixes after maximum aggregation: 69396 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 147515 Unique aggregates announced from the RIPE address blocks: 91400 RIPE Region origin ASes present in the Internet Routing Table: 18044 RIPE Prefixes per ASN: 8.18 RIPE Region origin ASes announcing only one prefix: 7942 RIPE Region transit ASes present in the Internet Routing Table: 3023 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4425 Number of RIPE addresses announced to Internet: 702822272 Equivalent to 41 /8s, 228 /16s and 55 /24s Percentage of available RIPE address space announced: 102.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 61311 Total LACNIC prefixes after maximum aggregation: 11995 LACNIC Deaggregation factor: 5.11 Prefixes being announced from the LACNIC address blocks: 74693 Unique aggregates announced from the LACNIC address blocks: 34773 LACNIC Region origin ASes present in the Internet Routing Table: 2467 LACNIC Prefixes per ASN: 30.28 LACNIC Region origin ASes announcing only one prefix: 590 LACNIC Region transit ASes present in the Internet Routing Table: 546 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2256 Number of LACNIC addresses announced to Internet: 170714368 Equivalent to 10 /8s, 44 /16s and 229 /24s Percentage of available LACNIC address space announced: 101.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: 14306 Total AfriNIC prefixes after maximum aggregation: 3180 AfriNIC Deaggregation factor: 4.50 Prefixes being announced from the AfriNIC address blocks: 16087 Unique aggregates announced from the AfriNIC address blocks: 6214 AfriNIC Region origin ASes present in the Internet Routing Table: 738 AfriNIC Prefixes per ASN: 21.80 AfriNIC Region origin ASes announcing only one prefix: 194 AfriNIC Region transit ASes present in the Internet Routing Table: 170 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 183 Number of AfriNIC addresses announced to Internet: 75766272 Equivalent to 4 /8s, 132 /16s and 26 /24s Percentage of available AfriNIC address space announced: 75.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5594 4192 76 China Education and Research 4766 3129 11144 1101 Korea Telecom 7545 3048 347 165 TPG Telecom Limited 17974 2874 914 96 PT Telekomunikasi Indonesia 9829 2330 1438 396 National Internet Backbone 4755 2081 432 237 TATA Communications formerly 9808 1837 8717 29 Guangdong Mobile Communicatio 4808 1619 2281 513 CNCGROUP IP network China169 9583 1516 121 560 Sify Limited 17488 1451 232 227 Hathway IP Over Cable Interne 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 3302 2949 149 Cox Communications Inc. 6389 2412 3687 42 BellSouth.net Inc. 18566 2210 394 278 MegaPath Corporation 20115 1909 1914 411 Charter Communications 6983 1699 849 238 EarthLink, Inc. 30036 1677 334 327 Mediacom Communications Corp 4323 1586 1023 395 tw telecom holdings, inc. 209 1471 4340 1234 Qwest Communications Company, 701 1393 11453 661 MCI Communications Services, 11492 1249 237 601 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 39891 2515 135 9 SaudiNet, Saudi Telecom Compa 20940 2355 926 1680 Akamai International B.V. 34984 1945 322 414 TELLCOM ILETISIM HIZMETLERI A 8551 1224 376 53 Bezeq International-Ltd 8402 1150 544 15 OJSC "Vimpelcom" 12479 1141 982 75 France Telecom Espana SA 13188 1077 97 78 TOV "Bank-Inform" 31148 1041 47 41 Freenet Ltd. 9198 910 352 24 JSC Kazakhtelecom 6830 893 2712 463 Liberty Global Operations B.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3429 542 139 Telmex Colombia S.A. 8151 2179 3391 526 Uninet S.A. de C.V. 7303 1589 943 243 Telecom Argentina S.A. 11830 1437 366 25 Instituto Costarricense de El 6503 1396 437 56 Axtel, S.A.B. de C.V. 6147 1038 377 27 Telefonica del Peru S.A.A. 28573 1037 2171 155 NET Servi?os de Comunica??o S 7738 994 1882 41 Telemar Norte Leste S.A. 26615 992 2325 34 Tim Celular S.A. 3816 987 479 182 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1342 1472 15 TE-AS 24863 1126 401 28 Link Egypt (Link.NET) 37611 597 40 46 Afrihost-Brevis Computer Serv 36903 552 278 103 Office National des Postes et 36992 453 1235 28 ETISALAT MISR 37492 358 215 64 Orange Tunisie 24835 332 146 12 Vodafone Data 29571 266 21 12 Cote d'Ivoire Telecom 37054 254 20 7 Data Telecom Service 2018 225 323 73 TENET (The UNINET Project) Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5594 4192 76 China Education and Research 10620 3429 542 139 Telmex Colombia S.A. 22773 3302 2949 149 Cox Communications Inc. 4766 3129 11144 1101 Korea Telecom 7545 3048 347 165 TPG Telecom Limited 17974 2874 914 96 PT Telekomunikasi Indonesia 39891 2515 135 9 SaudiNet, Saudi Telecom Compa 6389 2412 3687 42 BellSouth.net Inc. 20940 2355 926 1680 Akamai International B.V. 9829 2330 1438 396 National Internet Backbone Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3429 3290 Telmex Colombia S.A. 22773 3302 3153 Cox Communications Inc. 7545 3048 2883 TPG Telecom Limited 17974 2874 2778 PT Telekomunikasi Indonesia 39891 2515 2506 SaudiNet, Saudi Telecom Compa 6389 2412 2370 BellSouth.net Inc. 4766 3129 2028 Korea Telecom 9829 2330 1934 National Internet Backbone 18566 2210 1932 MegaPath Corporation 4755 2081 1844 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 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. 17033 UNALLOCATED 12.3.33.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 23.249.144.0/21 40430 colo4jax, LLC 23.249.152.0/21 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 37.46.10.0/23 36351 SoftLayer Technologies Inc. 37.46.14.0/24 36351 SoftLayer Technologies Inc. 37.46.15.0/24 36351 SoftLayer Technologies Inc. 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:101 /12:265 /13:510 /14:1018 /15:1751 /16:12962 /17:7466 /18:12578 /19:25687 /20:38019 /21:39893 /22:64306 /23:55295 /24:318342 /25:541 /26:573 /27:396 /28:15 /29:16 /30:9 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2482 3302 Cox Communications Inc. 39891 2472 2515 SaudiNet, Saudi Telecom Compa 18566 2112 2210 MegaPath Corporation 6389 1531 2412 BellSouth.net Inc. 30036 1493 1677 Mediacom Communications Corp 6983 1343 1699 EarthLink, Inc. 10620 1310 3429 Telmex Colombia S.A. 34984 1232 1945 TELLCOM ILETISIM HIZMETLERI A 11492 1157 1249 CABLE ONE, INC. 31148 960 1041 Freenet Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1601 2:727 4:19 5:2086 6:26 8:907 12:1789 13:34 14:1590 15:23 16:2 17:58 18:20 20:48 22:1 23:1364 24:1739 27:2228 31:1723 32:54 33:2 34:2 35:4 36:212 37:2328 38:1162 39:23 40:81 41:3107 42:370 43:1667 44:41 45:1644 46:2396 47:67 49:1114 50:844 51:3 52:40 54:138 55:5 56:6 57:44 58:1475 59:855 60:543 61:1779 62:1427 63:1908 64:4440 65:2178 66:4079 67:2080 68:1100 69:3293 70:1044 71:463 72:1981 74:2542 75:358 76:420 77:1319 78:1275 79:799 80:1304 81:1361 82:869 83:670 84:794 85:1580 86:465 87:1040 88:547 89:1916 90:163 91:6020 92:863 93:2319 94:2279 95:2258 96:472 97:352 98:946 99:45 100:68 101:888 103:9584 104:2225 105:98 106:380 107:1131 108:651 109:2113 110:1247 111:1608 112:940 113:1199 114:1111 115:1616 116:1520 117:1402 118:2008 119:1542 120:511 121:1165 122:2261 123:1991 124:1602 125:1747 128:700 129:361 130:423 131:1286 132:598 133:173 134:448 135:120 136:347 137:330 138:1662 139:199 140:248 141:472 142:625 143:825 144:581 145:150 146:830 147:592 148:1470 149:456 150:648 151:825 152:592 153:268 154:559 155:896 156:462 157:425 158:343 159:1082 160:420 161:741 162:2263 163:524 164:721 165:1102 166:313 167:988 168:1474 169:585 170:1493 171:251 172:416 173:1610 174:712 175:857 176:1516 177:3934 178:2227 179:1078 180:2086 181:1639 182:1925 183:679 184:791 185:5632 186:3047 187:1951 188:2061 189:1754 190:7597 191:1254 192:8860 193:5724 194:4332 195:3707 196:1640 197:1313 198:5504 199:5561 200:6841 201:3692 202:9996 203:9376 204:4589 205:2712 206:2977 207:3038 208:4031 209:3893 210:3782 211:2005 212:2558 213:2153 214:825 215:72 216:5702 217:1878 218:740 219:560 220:1639 221:847 222:672 223:918 End of report From colton.conor at gmail.com Fri Feb 5 18:28:41 2016 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 5 Feb 2016 12:28:41 -0600 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: Richard, Thanks for the information on these. Do you mind me asking what is a ballpark for these devices? From what I have read/heard, the Huawei D-CMTS was a 16x4 unit software upgradeable to 32x4 I thought. Is the one you have software upgradeable to 32x4? Are these DOCSIS 3.1 capable. Better yet, what does DOCSIS 3.1 or pre- DOCSIS 3.1 mean? On Thu, Feb 4, 2016 at 10:13 PM, Richard Holbo wrote: > I'm in the middle of pulling some Cisco 7246VXR-UBR's (antiques) and > replacing them with the Huawei D-CMTS devices. From what I understand of > your needs, the Huawei devices will do what you are looking for. We are > running 8x4, but can upgrade the licenses to 24x4 if we need the bandwidth, > although at that point you will be more limited by the gig uplink. I'm > designing them to not serve more than 250 customers per cmts and they are > running a single vlan on the cable side back to an ISC DHCP server with > very simple config files served via tftp. This allows me to group the > CMTS's for reasonably efficient use of IP. Have not done IP6 on these yet, > but will fairly soon. > They are actually designed to run as a ONT from the Huawei OLT (GPON), but > will also accept a standard SFP and run off ethernet (that's how I'm doing > it). Compared to the other small CMTS's I looked at these are hard to > beat. they are Hardened and can be mounted anywhere. The config to do what > I'm using them for is really simple (I'm a big believer in KISS). Have had > some in service for a few months now with no issues. > > I've used some 24 port VDSL switches in the past for MDU's and may > actually pull some of those and use these where there is RG6 house wiring > as they support a LOT more management than any of the smaller DSLAMS I've > looked at. > > In this configuration I can easily support 100mbit service on DOCSIS 3, > and my unlimited modems will speedtest all the way to 280mbs. > > > FWIW > > /rh > > On Tue, Feb 2, 2016 at 10:24 AM, Colton Conor > wrote: > >> Yes, we are in the USA. So based on everyones recommendations, I am going >> to stay far away from EURODOCSIS. I was told be a vendor that Arris and >> other USA FCC certified cable modems could easily be flashed to EURODOCIS >> mode, so I did not think the CPE side was that big of a deal (is that even >> true). I was not aware that there were so many differences besides just >> the >> channel width. >> >> So, assuming we are talking about DOCSIS only (and not EURODOCSIS), what >> do >> you recommend? I like the idea of being able to upgrade to 3.1, but not >> sure if there are any small systems capable of this? By small I mean >> something that could feed less than 100 units, and be economical to do. >> Cable has the advantage of cheap modems, so it's really the CMTS side. >> >> Please remember I am only interested in data internet services over this >> plant. Something that works for garden style layouts where I can bring >> fiber or coaxial to the side of a garden townhome that has between 4 to 16 >> units inside of it. The reason I requested a harden outdoor unit is that >> most all of the garden style properties have both the phone >> and coaxial drops on the outside of the building. There is no central >> closet or room. Plus we are in the south, so hardened for the >> heat exposure makes sense. >> >> A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like what I >> want. I will check into Huawei and Gainspeed. Who else makes these? >> >> >> >> >> On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms wrote: >> >> > Nick, >> > >> > Absolutely, if your plant is in Europe or one of the other areas (lots >> of >> > Africa and the middle East is like that) that adopted EuroDOCSIS I'd >> agree >> > wholeheartedly. I didn't see Colton say where they're located, but all >> > North America is the US flavor so that's what I assume on NANOG. >> > >> > That being said, the best thing that seldom gets mentioned about D3.1 is >> > getting us to unified channelization. >> > Scott Helms wrote: >> > > That very small upside for an extreme downside.Trying to hire someone >> > > to work on your system with Euro channelization, not to mention buying >> > > amplifiers and passives is a huge PITA. >> > >> > ... if your plant is in the US. >> > >> > > I have customers in Europe who >> > > decided to do US DOCSIS and they universally wish they had used the >> > > local "flavor". >> > >> > as you say, eurodocsis works well in europe. >> > >> > 3.1 will be a major improvement when it materialises. >> > >> > Nick >> > >> > > From jcurran at arin.net Fri Feb 5 18:27:57 2016 From: jcurran at arin.net (John Curran) Date: Fri, 5 Feb 2016 18:27:57 +0000 Subject: Change re ARIN RPKI Relying Party TAL access In-Reply-To: <20160205164432.GI1192@57.rev.meerval.net> References: <56B3AC5E.8070305@arin.net> <378804E8-D587-403C-A1EB-CAD4A987E32F@arin.net> <20160205164432.GI1192@57.rev.meerval.net> Message-ID: <14AAAD03-B18E-4028-84DC-75C0DD15FB1B@arin.net> On Feb 5, 2016, at 8:44 AM, Job Snijders wrote: > > Dear John, > > On Thu, Feb 04, 2016 at 08:15:29PM +0000, John Curran wrote: >> One of the concerns raised at a previous NANOG was with respect to the >> need for an RPKI relying parties to explicitly accept ARIN's relying >> party agreement (RPA) - note that this has now been changed (per the >> attached announcement) >> >> Wile the RPA terms remain the same, it is no longer necessary to >> click-accept and provide an email in order to access ARIN's trust >> anchor locator (TAL). > > Can you explain in layman terms what the legal consequences of this > change are? Job - As I noted, the Relying Party Agreement terms and conditions remain the same - we have simply eliminated the requirement for explicit agreement to it thru entry of your email and click-to-accept. We do not expect there is any legal consequences for relying parties as result of this change [1], only a question of convenience of access to the TAL as sought by the community. Thanks! /John John Curran President and CEO ARIN [1] The world of assenting to agreement terms is an interesting legal topic, and others may argue that changing from click-to-accept to binding by usage is material; such is the nature of legal matters. From bill at herrin.us Fri Feb 5 18:52:02 2016 From: bill at herrin.us (William Herrin) Date: Fri, 5 Feb 2016 13:52:02 -0500 Subject: Change re ARIN RPKI Relying Party TAL access In-Reply-To: <20160205164432.GI1192@57.rev.meerval.net> References: <56B3AC5E.8070305@arin.net> <378804E8-D587-403C-A1EB-CAD4A987E32F@arin.net> <20160205164432.GI1192@57.rev.meerval.net> Message-ID: On Fri, Feb 5, 2016 at 11:44 AM, Job Snijders wrote: > Can you explain in layman terms what the legal consequences of this > change are? Hi Job, In layman's terms, the difference is that you're now free to deal with the RPKI TAL the same way you deal with the legal issues surrounding access to ARIN's public whois data -- by ignoring them but not being so dumb as to sue ARIN if something goes wrong. Note that I am not a lawyer, this is not legal advice and no lawyer will ever tell you to ignore legal ramifications even when practically speaking that's the correct thing to do. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jcurran at arin.net Fri Feb 5 19:24:40 2016 From: jcurran at arin.net (John Curran) Date: Fri, 5 Feb 2016 19:24:40 +0000 Subject: Change re ARIN RPKI Relying Party TAL access In-Reply-To: References: <56B3AC5E.8070305@arin.net> <378804E8-D587-403C-A1EB-CAD4A987E32F@arin.net> <20160205164432.GI1192@57.rev.meerval.net> Message-ID: <103F1B8C-4B80-4C67-991D-AF177CD832A5@arin.net> On Feb 5, 2016, at 10:52 AM, William Herrin wrote: > > On Fri, Feb 5, 2016 at 11:44 AM, Job Snijders wrote: >> Can you explain in layman terms what the legal consequences of this >> change are? > > Hi Job, > > In layman's terms, the difference is that you're now free to deal with > the RPKI TAL the same way you deal with the legal issues surrounding > access to ARIN's public whois data -- by ignoring them but not being > so dumb as to sue ARIN if something goes wrong. > > Note that I am not a lawyer, this is not legal advice and no lawyer > will ever tell you to ignore legal ramifications even when practically > speaking that's the correct thing to do. Bill - Note that we do send notices and follow up when we receive reports of egregious violations of the Whois terms of use, and will do similar for violation of the RPA terms of use. The terms don?t generally get in the way of what operators want to do, but I?d like to think that?s more of alignment of expectations rather than folks completely ?ignoring them?. Thanks, /John John Curran President and CEO ARIN From fgont at si6networks.com Fri Feb 5 21:08:10 2016 From: fgont at si6networks.com (Fernando Gont) Date: Fri, 5 Feb 2016 18:08:10 -0300 Subject: IETF I-D: "Operational Implications of IPv6 Packets with Extension Headers" Message-ID: <56B50F3A.6090401@si6networks.com> Folks, We have revised our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers". The I-D is available at: Your feedback will be appreciated. If possible, please send your comments to: and CC . P.S.: You can find a number of pointers to articles and other related work on this topic here: Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From cameron at jferdinands.com Sat Feb 6 10:39:14 2016 From: cameron at jferdinands.com (Cameron Ferdinands) Date: Sat, 06 Feb 2016 10:39:14 +0000 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <6441f7bd68304968afd3dd7fefcac0fa@exch2013-1.hq.nac.net> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <6441f7bd68304968afd3dd7fefcac0fa@exch2013-1.hq.nac.net> Message-ID: If you need high-er density 10GE. Consider an Juniper ACX5048. Great edge box, MPLS features, it's essentially just a QFX with repartitioned CAM / some tricks to get the most out of the Trident II chipset. Won't do a bunch of things, so make sure it's exactly what you need or you'll burn yourself YMMV. On Wed, Feb 3, 2016 at 9:50 AM Dan Spataro wrote: > Depending on your interpretation of full MPLS stack, you can look into the > Brocade CES. > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Bass > Sent: Tuesday, February 2, 2016 4:04 PM > To: nanog at nanog.org > Subject: Low density Juniper (or alternative) Edge > > Looking to see what others are using out there as an alternative to a > Cisco ME3600X? Also, what other vendors out there are playing in this space? > > Need a full MPLS stack. > From davidbass570 at gmail.com Sat Feb 6 18:48:07 2016 From: davidbass570 at gmail.com (David Bass) Date: Sat, 6 Feb 2016 13:48:07 -0500 Subject: Low density Juniper (or alternative) Edge In-Reply-To: References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <6441f7bd68304968afd3dd7fefcac0fa@exch2013-1.hq.nac.net> Message-ID: <9D3A0B3C-0440-4E7E-AE0B-56D6653BEFA0@gmail.com> Thanks for all the insight everyone...very helpful discussion! Has anyone see the SRX deployed in these situations? We have been talking to Juniper about the ACX, and they seem to be pushing it as a Metro E, or in situations where you don't need a lot of features (like a L2 agg point for wireless). > On Feb 6, 2016, at 5:39 AM, Cameron Ferdinands wrote: > > If you need high-er density 10GE. Consider an Juniper ACX5048. > > Great edge box, MPLS features, it's essentially just a QFX with repartitioned CAM / some tricks to get the most out of the Trident II chipset. > > Won't do a bunch of things, so make sure it's exactly what you need or you'll burn yourself YMMV. > >> On Wed, Feb 3, 2016 at 9:50 AM Dan Spataro wrote: >> Depending on your interpretation of full MPLS stack, you can look into the Brocade CES. >> >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Bass >> Sent: Tuesday, February 2, 2016 4:04 PM >> To: nanog at nanog.org >> Subject: Low density Juniper (or alternative) Edge >> >> Looking to see what others are using out there as an alternative to a Cisco ME3600X? Also, what other vendors out there are playing in this space? >> >> Need a full MPLS stack. From josh at kyneticwifi.com Sat Feb 6 18:55:01 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sat, 6 Feb 2016 12:55:01 -0600 Subject: Low density Juniper (or alternative) Edge In-Reply-To: References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <6441f7bd68304968afd3dd7fefcac0fa@exch2013-1.hq.nac.net> Message-ID: Why not consider an EX4500? On Feb 6, 2016 12:24 PM, "Cameron Ferdinands" wrote: > If you need high-er density 10GE. Consider an Juniper ACX5048. > > Great edge box, MPLS features, it's essentially just a QFX with > repartitioned CAM / some tricks to get the most out of the Trident II > chipset. > > Won't do a bunch of things, so make sure it's exactly what you need or > you'll burn yourself YMMV. > > On Wed, Feb 3, 2016 at 9:50 AM Dan Spataro wrote: > > > Depending on your interpretation of full MPLS stack, you can look into > the > > Brocade CES. > > > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Bass > > Sent: Tuesday, February 2, 2016 4:04 PM > > To: nanog at nanog.org > > Subject: Low density Juniper (or alternative) Edge > > > > Looking to see what others are using out there as an alternative to a > > Cisco ME3600X? Also, what other vendors out there are playing in this > space? > > > > Need a full MPLS stack. > > > From davidbass570 at gmail.com Sat Feb 6 21:38:51 2016 From: davidbass570 at gmail.com (David Bass) Date: Sat, 6 Feb 2016 16:38:51 -0500 Subject: Low density Juniper (or alternative) Edge In-Reply-To: References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <6441f7bd68304968afd3dd7fefcac0fa@exch2013-1.hq.nac.net> Message-ID: <87D4D4CF-59C7-48CB-AFC3-3BEADB53C8CF@gmail.com> Yeah, on the list...well the 4600 is since it's somewhat the replacement to the 4500/4550. > On Feb 6, 2016, at 1:55 PM, Josh Reynolds wrote: > > Why not consider an EX4500? > >> On Feb 6, 2016 12:24 PM, "Cameron Ferdinands" wrote: >> If you need high-er density 10GE. Consider an Juniper ACX5048. >> >> Great edge box, MPLS features, it's essentially just a QFX with >> repartitioned CAM / some tricks to get the most out of the Trident II >> chipset. >> >> Won't do a bunch of things, so make sure it's exactly what you need or >> you'll burn yourself YMMV. >> >> On Wed, Feb 3, 2016 at 9:50 AM Dan Spataro wrote: >> >> > Depending on your interpretation of full MPLS stack, you can look into the >> > Brocade CES. >> > >> > >> > >> > >> > -----Original Message----- >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Bass >> > Sent: Tuesday, February 2, 2016 4:04 PM >> > To: nanog at nanog.org >> > Subject: Low density Juniper (or alternative) Edge >> > >> > Looking to see what others are using out there as an alternative to a >> > Cisco ME3600X? Also, what other vendors out there are playing in this space? >> > >> > Need a full MPLS stack. >> > From josh at kyneticwifi.com Sat Feb 6 21:41:50 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sat, 6 Feb 2016 15:41:50 -0600 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <87D4D4CF-59C7-48CB-AFC3-3BEADB53C8CF@gmail.com> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <6441f7bd68304968afd3dd7fefcac0fa@exch2013-1.hq.nac.net> <87D4D4CF-59C7-48CB-AFC3-3BEADB53C8CF@gmail.com> Message-ID: Newer, more expensive, more bugs. 4500 is cheap on the secondary market. On Feb 6, 2016 3:38 PM, "David Bass" wrote: > Yeah, on the list...well the 4600 is since it's somewhat the replacement > to the 4500/4550. > > On Feb 6, 2016, at 1:55 PM, Josh Reynolds wrote: > > Why not consider an EX4500? > On Feb 6, 2016 12:24 PM, "Cameron Ferdinands" > wrote: > >> If you need high-er density 10GE. Consider an Juniper ACX5048. >> >> Great edge box, MPLS features, it's essentially just a QFX with >> repartitioned CAM / some tricks to get the most out of the Trident II >> chipset. >> >> Won't do a bunch of things, so make sure it's exactly what you need or >> you'll burn yourself YMMV. >> >> On Wed, Feb 3, 2016 at 9:50 AM Dan Spataro wrote: >> >> > Depending on your interpretation of full MPLS stack, you can look into >> the >> > Brocade CES. >> > >> > >> > >> > >> > -----Original Message----- >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Bass >> > Sent: Tuesday, February 2, 2016 4:04 PM >> > To: nanog at nanog.org >> > Subject: Low density Juniper (or alternative) Edge >> > >> > Looking to see what others are using out there as an alternative to a >> > Cisco ME3600X? Also, what other vendors out there are playing in this >> space? >> > >> > Need a full MPLS stack. >> > >> > From nanog at ics-il.net Sat Feb 6 21:45:44 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 6 Feb 2016 15:45:44 -0600 (CST) Subject: Low density Juniper (or alternative) Edge In-Reply-To: Message-ID: <305347326.4957.1454795141865.JavaMail.mhammett@ThunderFuck> I encourage my competitors to scoff at the secondary market. :-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Josh Reynolds" To: "David Bass" Cc: "Cameron Ferdinands" , nanog at nanog.org Sent: Saturday, February 6, 2016 3:41:50 PM Subject: Re: Low density Juniper (or alternative) Edge Newer, more expensive, more bugs. 4500 is cheap on the secondary market. On Feb 6, 2016 3:38 PM, "David Bass" wrote: > Yeah, on the list...well the 4600 is since it's somewhat the replacement > to the 4500/4550. > > On Feb 6, 2016, at 1:55 PM, Josh Reynolds wrote: > > Why not consider an EX4500? > On Feb 6, 2016 12:24 PM, "Cameron Ferdinands" > wrote: > >> If you need high-er density 10GE. Consider an Juniper ACX5048. >> >> Great edge box, MPLS features, it's essentially just a QFX with >> repartitioned CAM / some tricks to get the most out of the Trident II >> chipset. >> >> Won't do a bunch of things, so make sure it's exactly what you need or >> you'll burn yourself YMMV. >> >> On Wed, Feb 3, 2016 at 9:50 AM Dan Spataro wrote: >> >> > Depending on your interpretation of full MPLS stack, you can look into >> the >> > Brocade CES. >> > >> > >> > >> > >> > -----Original Message----- >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Bass >> > Sent: Tuesday, February 2, 2016 4:04 PM >> > To: nanog at nanog.org >> > Subject: Low density Juniper (or alternative) Edge >> > >> > Looking to see what others are using out there as an alternative to a >> > Cisco ME3600X? Also, what other vendors out there are playing in this >> space? >> > >> > Need a full MPLS stack. >> > >> > From randy at psg.com Sun Feb 7 02:14:03 2016 From: randy at psg.com (Randy Bush) Date: Sat, 06 Feb 2016 18:14:03 -0800 Subject: shy north american roas Message-ID: question from a lazy person for a research project. in the arin rpki instance, is it easy to withdraw a roa? randy From lists at sadiqs.com Sun Feb 7 15:42:10 2016 From: lists at sadiqs.com (Sadiq Saif) Date: Sun, 7 Feb 2016 10:42:10 -0500 Subject: shy north american roas In-Reply-To: References: Message-ID: <56B765D2.4000308@sadiqs.com> On 2/6/2016 21:14, Randy Bush wrote: > question from a lazy person for a research project. in the arin rpki > instance, is it easy to withdraw a roa? > > randy > Yes, it is one button titled "Remove ROA" under Organization Data -> Manage RPKI. Additionally: ROA removals may take up to 12 hours to be reflected in ARIN's RPKI repository. -- Sadiq Saif (AS393949) https://staticsafe.ca From lists+nanog at brumund.ca Sun Feb 7 19:43:24 2016 From: lists+nanog at brumund.ca (Karl Brumund) Date: Sun, 7 Feb 2016 14:43:24 -0500 Subject: Arista optics In-Reply-To: References: Message-ID: On Wed, Jan 20, 2016 at 11:39 AM, Alex Forster wrote: > Hi everyone! > > I'm trying to get buy-in to go with Arista for some new infrastructure, > but the Arista optics just aren't in the ballpark for us at > "proof-of-concept" volume. In Cisco-land, we've had great success using > Finisar optics, and they've been an easy "sell" to management since many > Cisco optics are just rebranded Finisar's. > > The relevant Arista optics I'm looking at are QSFP-100G-LR4 and > SFP-10G-LR. Does anybody know what supplier(s) manufacture these optics for > Arista? Alternatively, does anyone have any experience using third-party > comparable optics (especially the 100G) in the battlefield? > > No 100G experience, but Flexoptix has been very helpful and accommodating. Particularly with issues we had with 10G and certain server NICs. Best support I've ever seen for optics in $jobs. ...karl > Since optics sales are pretty cut-throat, I do ask that you disclose if > you have a financial interest in any of your suggestions. > > Thanks! > > Alex Forster > From eric at lumaoptics.net Mon Feb 8 02:35:35 2016 From: eric at lumaoptics.net (Eric Litvin) Date: Sun, 7 Feb 2016 18:35:35 -0800 Subject: [Attendee] Running In-Reply-To: <49F12FE0-BA99-475B-8DEA-637290870BDE@addrex.net> References: <49F12FE0-BA99-475B-8DEA-637290870BDE@addrex.net> Message-ID: <94D9C5C1-5C83-4C45-98CC-5BD0C87752AE@lumaoptics.net> I'm thinking about a 4 or 5 pm tomorrow, then early am tues and weds. If the harbor run is too drab, I hear sunset cliffs is a great place for a trail run (10km). Eric Sent from my iPhone > On Feb 7, 2016, at 6:27 PM, Peter Thimmesch wrote: > > > > Regards, > > Peter > > On Feb 7, 2016, at 6:25 PM, Castillo, Elliott wrote: > >> I'm in. Say when. >> >> Sent from my iPhone >> >> On Feb 7, 2016, at 5:27 PM, Nico CARTRON wrote: >> >>> Hello fellow NANOGers, >>> >>> I bet there must be some runners over here - I just ran this morning and the route from the Marina to downtown San Diego is really nice, >>> so was wondering if there were folks who?d like to run one of the 3 next (early) mornings? >>> >>> >>> Cheers, >>> >>> -- >>> Nico CARTRON >>> EfficientIP >>> Mobile: +33.6.45.45.91.98 >>> _______________________________________________ >>> Attendee mailing list >>> Attendee at mailman.nanog.org >>> http://mailman.nanog.org/mailman/listinfo/attendee >> _______________________________________________ >> Attendee mailing list >> Attendee at mailman.nanog.org >> http://mailman.nanog.org/mailman/listinfo/attendee > _______________________________________________ > Attendee mailing list > Attendee at mailman.nanog.org > http://mailman.nanog.org/mailman/listinfo/attendee From david at alleyit.com Sat Feb 6 23:20:42 2016 From: david at alleyit.com (Sheahan, David) Date: Sat, 6 Feb 2016 23:20:42 +0000 Subject: Local last-mile providers in Manhattan Message-ID: <7980ff4174034d1fb0483c0b98080ade@NJ1-EXCH1.alleyit.com> Try Erik at 1st Point Communications, https://www.1pcom.net/ ... highly recommended... -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Douglas Sent: Thursday, February 4, 2016 8:58 AM To: nanog at nanog.org Subject: Local last-mile providers in Manhattan Hi NANOG, I'm searching for last-mile providers in Manhattan (near the Holland tunnel) to provide a 100Mbps and 1Gbps EPL to 60 Hudson. I would like to avoid the bigger players as much as possible. Thanks Eric From george.herbert at gmail.com Mon Feb 8 05:42:00 2016 From: george.herbert at gmail.com (George Herbert) Date: Sun, 7 Feb 2016 21:42:00 -0800 Subject: Sonatel? Message-ID: <88FBF55B-101A-4D83-815D-9FB976BCD58C@gmail.com> https://bgpstream.com/event/19524 Second Sonatel hijack in last half hour-ish. Anyone on NANOG?... George William Herbert Sent from my iPhone From vwittkop at nanog.org Tue Feb 9 02:13:23 2016 From: vwittkop at nanog.org (Valerie Wittkop) Date: Mon, 8 Feb 2016 18:13:23 -0800 Subject: [NANOG-announce] Nominations for 2016 NANOG Committees Message-ID: Sent on behalf of the Executive Director Greetings NANOG Colleagues, If you missed the nominations deadline for the Program Committee or Communications Committee, this is your chance to still submit. If you, or someone you know, would make a great candidate for a NANOG Committee, please send the name and email address to elections at nanog.org no later than 1pm Pacific, Tuesday, February 9. We will make sure the nominee receives the candidate form and is included in the 2016 Committee Appointment Process. Should there be any questions, please send a message to elections at nanog.org. Sincerely, Betty Burke NANOG Executive Director 2864 Carpenter Rd. Suite 100 Ann Arbor, MI 48108 Tel: +1 866 902 1336 -- Valerie Wittkop NANOG Program Director +1.866.902.1336, Ext. 103 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From mdyer at development-group.net Mon Feb 8 23:14:06 2016 From: mdyer at development-group.net (Mitch Dyer) Date: Mon, 8 Feb 2016 23:14:06 +0000 Subject: UDP Amplification DDoS - Help! Message-ID: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> Hello, Hoping someone can point me in the right direction here, even just confirming my suspicions would be incredibly helpful. A little bit of background: I have a customer I'm working with that is downstream of a 1Gb link that is experiencing multiple DDoS attacks on a daily basis. Through several captures I've seen what appear to be a mixture of SSDP and DNS amplification attacks (though not at the same time). The attack itself seems to target the PAT address associated with a specific site, if we change the PAT address for the site, the attack targets the new address at the next occurance. We've tried setting up captures and logging inside the network to determine if the SSDP/DNS request originate within the network but that does not appear to be the case. We've reached out for some assistance from the upstream carrier but they've only been able to enforce a 24-hour block. I'm hoping someone with some experience on this topic would be able to shed some light on a better way to attack this or would be willing to confirm that we are simply SOL without prolonged assistance from the upstream carrier. Thanks in advance for any insight. Mitch From mike.lyon at gmail.com Tue Feb 9 02:50:51 2016 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Mon, 8 Feb 2016 18:50:51 -0800 Subject: UDP Amplification DDoS - Help! In-Reply-To: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> References: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> Message-ID: <1B1BE967-20BE-4955-BFA5-7F6E053EE8FB@gmail.com> Oodles of devices downstream of the 1G? Does the 1G terminate into a router or firewall? Sounds like there is a compromised host downstream of the 1G that is reporting back it's source IP and that is why changing the IP doesn't help. If you look at the PAT table, any oddities? Good luck! -Mike > On Feb 8, 2016, at 15:14, Mitch Dyer wrote: > > Hello, > > Hoping someone can point me in the right direction here, even just confirming my suspicions would be incredibly helpful. > > A little bit of background: I have a customer I'm working with that is downstream of a 1Gb link that is experiencing multiple DDoS attacks on a daily basis. Through several captures I've seen what appear to be a mixture of SSDP and DNS amplification attacks (though not at the same time). The attack itself seems to target the PAT address associated with a specific site, if we change the PAT address for the site, the attack targets the new address at the next occurance. We've tried setting up captures and logging inside the network to determine if the SSDP/DNS request originate within the network but that does not appear to be the case. > > We've reached out for some assistance from the upstream carrier but they've only been able to enforce a 24-hour block. > > I'm hoping someone with some experience on this topic would be able to shed some light on a better way to attack this or would be willing to confirm that we are simply SOL without prolonged assistance from the upstream carrier. > > Thanks in advance for any insight. > > Mitch > From rdobbins at arbor.net Tue Feb 9 02:54:10 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 09 Feb 2016 09:54:10 +0700 Subject: UDP Amplification DDoS - Help! In-Reply-To: <1B1BE967-20BE-4955-BFA5-7F6E053EE8FB@gmail.com> References: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> <1B1BE967-20BE-4955-BFA5-7F6E053EE8FB@gmail.com> Message-ID: <9F30A851-1315-4D7E-8884-8889AD1F9275@arbor.net> On 9 Feb 2016, at 9:50, mike.lyon at gmail.com wrote: > Sounds like there is a compromised host downstream of the 1G that is > reporting back it's source IP and that is why changing the IP doesn't > help. It's much more likely that the attacker is just following the DNS changes. ----------------------------------- Roland Dobbins From faisal at snappytelecom.net Tue Feb 9 02:55:58 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 9 Feb 2016 02:55:58 +0000 (GMT) Subject: UDP Amplification DDoS - Help! In-Reply-To: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> References: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> Message-ID: <1416724727.2271082.1454986558469.JavaMail.zimbra@snappytelecom.net> Not quite sure what kind of info / confirmation you are looking for... There are lots of articles (do a google search) on this topic as well as mitigation ... e.g. http://blog.nexusguard.com/ssdp-ddos-attacks/ & https://tools.ietf.org/html/bcp38 Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Mitch Dyer" > To: "nanog list" > Sent: Monday, February 8, 2016 6:14:06 PM > Subject: UDP Amplification DDoS - Help! > Hello, > > Hoping someone can point me in the right direction here, even just confirming my > suspicions would be incredibly helpful. > > A little bit of background: I have a customer I'm working with that is > downstream of a 1Gb link that is experiencing multiple DDoS attacks on a daily > basis. Through several captures I've seen what appear to be a mixture of SSDP > and DNS amplification attacks (though not at the same time). The attack itself > seems to target the PAT address associated with a specific site, if we change > the PAT address for the site, the attack targets the new address at the next > occurance. We've tried setting up captures and logging inside the network to > determine if the SSDP/DNS request originate within the network but that does > not appear to be the case. > > We've reached out for some assistance from the upstream carrier but they've only > been able to enforce a 24-hour block. > > I'm hoping someone with some experience on this topic would be able to shed some > light on a better way to attack this or would be willing to confirm that we are > simply SOL without prolonged assistance from the upstream carrier. > > Thanks in advance for any insight. > > Mitch From rdobbins at arbor.net Tue Feb 9 02:57:37 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 09 Feb 2016 09:57:37 +0700 Subject: UDP Amplification DDoS - Help! In-Reply-To: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> References: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> Message-ID: On 9 Feb 2016, at 6:14, Mitch Dyer wrote: > I'm hoping someone with some experience on this topic would be able to > shed some light on a better way to attack this or would be willing to > confirm that we are simply SOL without prolonged assistance from the > upstream carrier. Take a look at this .pdf preso: Who's the upstream? Is it the sole upstream You may well not be speaking to the right folks there, the ones who can provide assistance. Also note that there are multiple overlay MSSPs who can potentially help, as well, apart from the immediate upstream. ----------------------------------- Roland Dobbins From jtin at akamai.com Tue Feb 9 02:58:27 2016 From: jtin at akamai.com (Tin, James) Date: Tue, 9 Feb 2016 02:58:27 +0000 Subject: UDP Amplification DDoS - Help! In-Reply-To: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> References: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> Message-ID: Hi Mitch. My colleagues in the US dealt with something like this and I have dealt with something similar to this in Australia. Does your customer happen to be a school district? In our cases it turned out to be students buying Ddos as a service and targeting the address which comes up when they go to www.whatismyip.com. So the attack would constantly change and follow the network when there was an IP block put in place at the upstream. In my opinion, there are a few options to this: 1)The best solution is to use a comprehensive cloud based Ddos mitigation solution. 2) Use a cgnat to dynamically map to different external addresses and change them dynamically when there is a Ddos, while putting he used addresses in a black hole. 3) Another could be to use an external proxy service where you proxy your outbound requests to. So they will eventually become the target. However this moves the problem elsewhere and still exposes you to Ddos if they know your Cpe address. 4) In combination with this, you can perform incident response check your logs, turn on authentication, so you know when users are browsing for whatismyip and Ddos attack services. Sent from my iPhone James Tin APJ Principle Enterprise Security Architect Akamai Technologies +61 466 961 555 Level 7, 76 Berry St, North Sydney Australia 2060 On 9 Feb 2016, at 13:27, Mitch Dyer > wrote: Hello, Hoping someone can point me in the right direction here, even just confirming my suspicions would be incredibly helpful. A little bit of background: I have a customer I'm working with that is downstream of a 1Gb link that is experiencing multiple DDoS attacks on a daily basis. Through several captures I've seen what appear to be a mixture of SSDP and DNS amplification attacks (though not at the same time). The attack itself seems to target the PAT address associated with a specific site, if we change the PAT address for the site, the attack targets the new address at the next occurance. We've tried setting up captures and logging inside the network to determine if the SSDP/DNS request originate within the network but that does not appear to be the case. We've reached out for some assistance from the upstream carrier but they've only been able to enforce a 24-hour block. I'm hoping someone with some experience on this topic would be able to shed some light on a better way to attack this or would be willing to confirm that we are simply SOL without prolonged assistance from the upstream carrier. Thanks in advance for any insight. Mitch From trelane at trelane.net Tue Feb 9 02:58:52 2016 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 8 Feb 2016 21:58:52 -0500 Subject: UDP Amplification DDoS - Help! In-Reply-To: <1416724727.2271082.1454986558469.JavaMail.zimbra@snappytelecom.net> References: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> <1416724727.2271082.1454986558469.JavaMail.zimbra@snappytelecom.net> Message-ID: use a CDN provider or AWS ELBs or something to absorb the attacks? On Mon, Feb 8, 2016 at 9:55 PM, Faisal Imtiaz wrote: > Not quite sure what kind of info / confirmation you are looking for... > > There are lots of articles (do a google search) on this topic as well as mitigation ... > > e.g. > > http://blog.nexusguard.com/ssdp-ddos-attacks/ > > & > https://tools.ietf.org/html/bcp38 > > Regards > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- >> From: "Mitch Dyer" >> To: "nanog list" >> Sent: Monday, February 8, 2016 6:14:06 PM >> Subject: UDP Amplification DDoS - Help! > >> Hello, >> >> Hoping someone can point me in the right direction here, even just confirming my >> suspicions would be incredibly helpful. >> >> A little bit of background: I have a customer I'm working with that is >> downstream of a 1Gb link that is experiencing multiple DDoS attacks on a daily >> basis. Through several captures I've seen what appear to be a mixture of SSDP >> and DNS amplification attacks (though not at the same time). The attack itself >> seems to target the PAT address associated with a specific site, if we change >> the PAT address for the site, the attack targets the new address at the next >> occurance. We've tried setting up captures and logging inside the network to >> determine if the SSDP/DNS request originate within the network but that does >> not appear to be the case. >> >> We've reached out for some assistance from the upstream carrier but they've only >> been able to enforce a 24-hour block. >> >> I'm hoping someone with some experience on this topic would be able to shed some >> light on a better way to attack this or would be willing to confirm that we are >> simply SOL without prolonged assistance from the upstream carrier. >> >> Thanks in advance for any insight. >> >> Mitch From pkranz at unwiredltd.com Tue Feb 9 03:10:31 2016 From: pkranz at unwiredltd.com (Peter Kranz) Date: Mon, 8 Feb 2016 19:10:31 -0800 Subject: UDP Amplification DDoS - Help! In-Reply-To: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> References: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> Message-ID: <04ac01d162e7$6fe28a60$4fa79f20$@unwiredltd.com> You haven't indicated what the actual inbound attack volume is. If it's something your network core can handle, you can block the attack fingerprint upstream so it does not reach the 1Gb link. If it's UDP amplification chances are you can create a firewall rule. -PK From rubensk at gmail.com Tue Feb 9 03:14:55 2016 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 9 Feb 2016 01:14:55 -0200 Subject: UDP Amplification DDoS - Help! In-Reply-To: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> References: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> Message-ID: 1. Move the website to DDoS-resistant reverse proxy like Cloudflare or Incapsula, using its current IP address; won't make much of a difference as attacker will go back to attacking the last known IP address. 2. Change the site IP address and only update it at the reverse proxy provider, not at any DNS record whatsoever. This should do the trick unless attacker starts a full-range CIDR block attack, at which point your next escalation path is GRE-based DDoS providers like, but not limited to, Black Lotus. Rubens On Mon, Feb 8, 2016 at 9:14 PM, Mitch Dyer wrote: > Hello, > > Hoping someone can point me in the right direction here, even just > confirming my suspicions would be incredibly helpful. > > A little bit of background: I have a customer I'm working with that is > downstream of a 1Gb link that is experiencing multiple DDoS attacks on a > daily basis. Through several captures I've seen what appear to be a mixture > of SSDP and DNS amplification attacks (though not at the same time). The > attack itself seems to target the PAT address associated with a specific > site, if we change the PAT address for the site, the attack targets the new > address at the next occurance. We've tried setting up captures and logging > inside the network to determine if the SSDP/DNS request originate within > the network but that does not appear to be the case. > > We've reached out for some assistance from the upstream carrier but > they've only been able to enforce a 24-hour block. > > I'm hoping someone with some experience on this topic would be able to > shed some light on a better way to attack this or would be willing to > confirm that we are simply SOL without prolonged assistance from the > upstream carrier. > > Thanks in advance for any insight. > > Mitch > > From karsten.elfenbein at gmail.com Tue Feb 9 10:29:07 2016 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Tue, 9 Feb 2016 11:29:07 +0100 Subject: UDP Amplification DDoS - Help! In-Reply-To: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> References: <10e6b56b34b74f7a86cc7117555de973@AWS-EX01.devgru.local> Message-ID: You could use multiple PAT addresses to find the source of information for the attacker and to reduce the impact by filtering/QOS. TCP connections PAT IP1 (block UDP before going to the 1G line) UDP connections PAT IP2 webservers connecting to api hosts - PAT IP3 webservers remaining connections - PAT IP4 Karsten 2016-02-09 0:14 GMT+01:00 Mitch Dyer : > Hello, > > Hoping someone can point me in the right direction here, even just confirming my suspicions would be incredibly helpful. > > A little bit of background: I have a customer I'm working with that is downstream of a 1Gb link that is experiencing multiple DDoS attacks on a daily basis. Through several captures I've seen what appear to be a mixture of SSDP and DNS amplification attacks (though not at the same time). The attack itself seems to target the PAT address associated with a specific site, if we change the PAT address for the site, the attack targets the new address at the next occurance. We've tried setting up captures and logging inside the network to determine if the SSDP/DNS request originate within the network but that does not appear to be the case. > > We've reached out for some assistance from the upstream carrier but they've only been able to enforce a 24-hour block. > > I'm hoping someone with some experience on this topic would be able to shed some light on a better way to attack this or would be willing to confirm that we are simply SOL without prolonged assistance from the upstream carrier. > > Thanks in advance for any insight. > > Mitch > From colton.conor at gmail.com Tue Feb 9 20:20:07 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 9 Feb 2016 14:20:07 -0600 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: Scott, Have any idea which exact vendors and model numbers are within this price range? So far I have just found mini CMTS systems like the Pico and Harmonic's. Both of these are a 16x4 configuration, but no mention of remote MAC+PHY nor DOSIS 3.1. Then their is Huawei's solution, but still I think that's more based on C-DOCSIS. Searching the vendors websites you recommended show no results for remote MAC+PHY in a small format. On Tue, Feb 2, 2016 at 2:44 PM, Scott Helms wrote: > Colton, > > D3.1 gear is just coming online right now. If you're going to go with the > smaller PHY+MAC approach I'd just make sure the company has plans to update > their boxes to 3.1 in a decent (your judgement) amount of time. Don't > expect any 3.0 box to be software upgradeable to 3.1, the hardware is quite > different. The PHY+MAC boxes are _generally_ < $10k and some are talking > about ~6k. > > All the vendors we've listed so far have plans for 3.1, but I don't have a > timeline for any of them. Right now the market is still trying to decide > how modular CMTS will be rolled out, remote PHY, remote MAC+PHY, or a > combination. For example, Cisco is (for the moment) betting that remote > PHY economics will be compelling for the larger operators, while Arris is > doing both approaches. > > > Scott Helms > Chief Technology Officer > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Tue, Feb 2, 2016 at 3:31 PM, Colton Conor > wrote: > >> Is a remote MAC+PHY the same thing as a Distributed Converged Cable >> Access Platform (D-CCAP) solution like Huawei is pushing? Is DOCSIS 3.1 >> even out, or am I looking for something that does not exist yet? >> >> Are these remote MAC+PHY devices in the under 10K price range that these >> smaller all in one CMTS platforms are? >> >> On Tue, Feb 2, 2016 at 12:49 PM, Scott Helms wrote: >> >>> >>> >>> >>> >>> On Tue, Feb 2, 2016 at 1:24 PM, Colton Conor >>> wrote: >>> >>>> Yes, we are in the USA. So based on everyones recommendations, I am >>>> going to stay far away from EURODOCSIS. I was told be a vendor that >>>> Arris and other USA FCC certified cable modems could easily be flashed to >>>> EURODOCIS mode, so I did not think the CPE side was that big of a deal (is >>>> that even true). I was not aware that there were so many differences >>>> besides just the channel width. >>>> >>> >>> I wish this were the case, it would make my life easier. The problem is >>> that there is a diplex filter that prevents the upstream burst from being >>> heard by the downstream receiver and for cost purposes all the D3 and >>> earlier modems have fixed filters. What that means is that a EuroDOCSIS >>> modem can (sometimes) be flashed to use 6MHz channels, but the reverse is >>> NOT true. In any case we don't recommend using Euro modems that are >>> flashed to US standards in production (nor do the vendors) because you'll >>> see much more upstream leakage. >>> >>> >>>> >>>> So, assuming we are talking about DOCSIS only (and not EURODOCSIS), >>>> what do you recommend? I like the idea of being able to upgrade to 3.1, but >>>> not sure if there are any small systems capable of this? By small I mean >>>> something that could feed less than 100 units, and be economical to do. >>>> Cable has the advantage of cheap modems, so it's really the CMTS side. >>>> >>> >>> In that case I'd definitely go with a remote MAC+PHY. That's the only >>> way you're going to get a good price point and decent performance unless >>> you want to use the secondary market, which actually isn't a bad idea right >>> now. A used 7225 with 8x8 blades is pretty cheap, but it's centralized >>> CMTS that would cover ~3k subs. >>> >>>> >>>> Please remember I am only interested in data internet services over >>>> this plant. Something that works for garden style layouts where I can bring >>>> fiber or coaxial to the side of a garden townhome that has between 4 to 16 >>>> units inside of it. The reason I requested a harden outdoor unit is that >>>> most all of the garden style properties have both the phone >>>> and coaxial drops on the outside of the building. There is no central >>>> closet or room. Plus we are in the south, so hardened for the >>>> heat exposure makes sense. >>>> >>>> A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like >>>> what I want. I will check into Huawei and Gainspeed. Who else makes these? >>>> >>> >>> In no particular order, Arris is or will be, Teleste (Euro vendor trying >>> to break into the US), Sumavision, Altera, and ton more I can't remember. >>> Come to one of the SCTE shows (it's in Philadelphia this year) if you want >>> to be deluged with them :) >>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms wrote: >>>> >>>>> Nick, >>>>> >>>>> Absolutely, if your plant is in Europe or one of the other areas (lots >>>>> of Africa and the middle East is like that) that adopted EuroDOCSIS I'd >>>>> agree wholeheartedly. I didn't see Colton say where they're located, but >>>>> all North America is the US flavor so that's what I assume on NANOG. >>>>> >>>>> That being said, the best thing that seldom gets mentioned about D3.1 >>>>> is getting us to unified channelization. >>>>> Scott Helms wrote: >>>>> > That very small upside for an extreme downside.Trying to hire someone >>>>> > to work on your system with Euro channelization, not to mention >>>>> buying >>>>> > amplifiers and passives is a huge PITA. >>>>> >>>>> ... if your plant is in the US. >>>>> >>>>> > I have customers in Europe who >>>>> > decided to do US DOCSIS and they universally wish they had used the >>>>> > local "flavor". >>>>> >>>>> as you say, eurodocsis works well in europe. >>>>> >>>>> 3.1 will be a major improvement when it materialises. >>>>> >>>>> Nick >>>>> >>>> >>>> >>> >> > From colton.conor at gmail.com Tue Feb 9 20:32:58 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 9 Feb 2016 14:32:58 -0600 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: Yes, I looked at CASA, but their small unit is the C1G, which is an 8x8 max DOCSIS 3.0 unit. Plus they want a high price point, almost quadruple what a 16X4 Pico Digital or Harmonic's unit cost. Not seeing the value or specs there to justify it. On Tue, Feb 9, 2016 at 2:26 PM, Steven Shalita wrote: > Have you looked at Casa Systems? They some smaller density MDU stuff. > > -Steve > > Sent from my iPhone. Please excuse any errors. > > > On Feb 9, 2016, at 12:20 PM, Colton Conor > wrote: > > > > Scott, > > > > Have any idea which exact vendors and model numbers are within this price > > range? So far I have just found mini CMTS systems like the Pico and > > Harmonic's. Both of these are a 16x4 configuration, but no mention of > > remote MAC+PHY nor DOSIS 3.1. Then their is Huawei's solution, but still > I > > think that's more based on C-DOCSIS. Searching the vendors websites you > > recommended show no results for remote MAC+PHY in a small format. > > > >> On Tue, Feb 2, 2016 at 2:44 PM, Scott Helms wrote: > >> > >> Colton, > >> > >> D3.1 gear is just coming online right now. If you're going to go with > the > >> smaller PHY+MAC approach I'd just make sure the company has plans to > update > >> their boxes to 3.1 in a decent (your judgement) amount of time. Don't > >> expect any 3.0 box to be software upgradeable to 3.1, the hardware is > quite > >> different. The PHY+MAC boxes are _generally_ < $10k and some are > talking > >> about ~6k. > >> > >> All the vendors we've listed so far have plans for 3.1, but I don't > have a > >> timeline for any of them. Right now the market is still trying to > decide > >> how modular CMTS will be rolled out, remote PHY, remote MAC+PHY, or a > >> combination. For example, Cisco is (for the moment) betting that remote > >> PHY economics will be compelling for the larger operators, while Arris > is > >> doing both approaches. > >> > >> > >> Scott Helms > >> Chief Technology Officer > >> ZCorum > >> (678) 507-5000 > >> -------------------------------- > >> http://twitter.com/kscotthelms > >> -------------------------------- > >> > >> On Tue, Feb 2, 2016 at 3:31 PM, Colton Conor > >> wrote: > >> > >>> Is a remote MAC+PHY the same thing as a Distributed Converged Cable > >>> Access Platform (D-CCAP) solution like Huawei is pushing? Is DOCSIS 3.1 > >>> even out, or am I looking for something that does not exist yet? > >>> > >>> Are these remote MAC+PHY devices in the under 10K price range that > these > >>> smaller all in one CMTS platforms are? > >>> > >>>> On Tue, Feb 2, 2016 at 12:49 PM, Scott Helms > wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Tue, Feb 2, 2016 at 1:24 PM, Colton Conor > >>>> wrote: > >>>> > >>>>> Yes, we are in the USA. So based on everyones recommendations, I am > >>>>> going to stay far away from EURODOCSIS. I was told be a vendor that > >>>>> Arris and other USA FCC certified cable modems could easily be > flashed to > >>>>> EURODOCIS mode, so I did not think the CPE side was that big of a > deal (is > >>>>> that even true). I was not aware that there were so many differences > >>>>> besides just the channel width. > >>>> > >>>> I wish this were the case, it would make my life easier. The problem > is > >>>> that there is a diplex filter that prevents the upstream burst from > being > >>>> heard by the downstream receiver and for cost purposes all the D3 and > >>>> earlier modems have fixed filters. What that means is that a > EuroDOCSIS > >>>> modem can (sometimes) be flashed to use 6MHz channels, but the > reverse is > >>>> NOT true. In any case we don't recommend using Euro modems that are > >>>> flashed to US standards in production (nor do the vendors) because > you'll > >>>> see much more upstream leakage. > >>>> > >>>> > >>>>> > >>>>> So, assuming we are talking about DOCSIS only (and not EURODOCSIS), > >>>>> what do you recommend? I like the idea of being able to upgrade to > 3.1, but > >>>>> not sure if there are any small systems capable of this? By small I > mean > >>>>> something that could feed less than 100 units, and be economical to > do. > >>>>> Cable has the advantage of cheap modems, so it's really the CMTS > side. > >>>> > >>>> In that case I'd definitely go with a remote MAC+PHY. That's the only > >>>> way you're going to get a good price point and decent performance > unless > >>>> you want to use the secondary market, which actually isn't a bad idea > right > >>>> now. A used 7225 with 8x8 blades is pretty cheap, but it's > centralized > >>>> CMTS that would cover ~3k subs. > >>>> > >>>>> > >>>>> Please remember I am only interested in data internet services over > >>>>> this plant. Something that works for garden style layouts where I > can bring > >>>>> fiber or coaxial to the side of a garden townhome that has between 4 > to 16 > >>>>> units inside of it. The reason I requested a harden outdoor unit is > that > >>>>> most all of the garden style properties have both the phone > >>>>> and coaxial drops on the outside of the building. There is no central > >>>>> closet or room. Plus we are in the south, so hardened for the > >>>>> heat exposure makes sense. > >>>>> > >>>>> A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like > >>>>> what I want. I will check into Huawei and Gainspeed. Who else makes > these? > >>>> > >>>> In no particular order, Arris is or will be, Teleste (Euro vendor > trying > >>>> to break into the US), Sumavision, Altera, and ton more I can't > remember. > >>>> Come to one of the SCTE shows (it's in Philadelphia this year) if you > want > >>>> to be deluged with them :) > >>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms > wrote: > >>>>>> > >>>>>> Nick, > >>>>>> > >>>>>> Absolutely, if your plant is in Europe or one of the other areas > (lots > >>>>>> of Africa and the middle East is like that) that adopted EuroDOCSIS > I'd > >>>>>> agree wholeheartedly. I didn't see Colton say where they're > located, but > >>>>>> all North America is the US flavor so that's what I assume on NANOG. > >>>>>> > >>>>>> That being said, the best thing that seldom gets mentioned about > D3.1 > >>>>>> is getting us to unified channelization. > >>>>>> Scott Helms wrote: > >>>>>>> That very small upside for an extreme downside.Trying to hire > someone > >>>>>>> to work on your system with Euro channelization, not to mention > >>>>>> buying > >>>>>>> amplifiers and passives is a huge PITA. > >>>>>> > >>>>>> ... if your plant is in the US. > >>>>>> > >>>>>>> I have customers in Europe who > >>>>>>> decided to do US DOCSIS and they universally wish they had used the > >>>>>>> local "flavor". > >>>>>> > >>>>>> as you say, eurodocsis works well in europe. > >>>>>> > >>>>>> 3.1 will be a major improvement when it materialises. > >>>>>> > >>>>>> Nick > >> > From khelms at zcorum.com Tue Feb 9 21:37:27 2016 From: khelms at zcorum.com (Scott Helms) Date: Tue, 9 Feb 2016 16:37:27 -0500 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: Colton, Huawai has one, but I can't find the product page on their site off hand. Here's one from Sumavision: http://en.sumavision.com/product.asp?pageID=28&ID=712 Harmonic's small form factor CMTS is remote PHY+MAC (at least the strand mounted version is) but keep in mind that they've been primarily selling those boxes (especially the indoor version) to MDU operators that don't really have out side plant so they don't market it that way. Casa is working with Teleste on remote PHY (I don't think it's got full layer 2 in it). Gainspeed also has a solution: http://www.gainspeed.com/our-solution/gainspeeds-virtual-ccap-architecture/ Also, keep in mind that no one is going to be yelling about D3.1 until they have the capability and none of the CCAPs do today. As painful as it is you're probably going to have to talk to some sales folks to get the most up to date info. Scott Helms Chief Technology Officer ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Feb 9, 2016 at 3:20 PM, Colton Conor wrote: > Scott, > > Have any idea which exact vendors and model numbers are within this price > range? So far I have just found mini CMTS systems like the Pico and > Harmonic's. Both of these are a 16x4 configuration, but no mention of > remote MAC+PHY nor DOSIS 3.1. Then their is Huawei's solution, but still I > think that's more based on C-DOCSIS. Searching the vendors websites you > recommended show no results for remote MAC+PHY in a small format. > > On Tue, Feb 2, 2016 at 2:44 PM, Scott Helms wrote: > >> Colton, >> >> D3.1 gear is just coming online right now. If you're going to go with >> the smaller PHY+MAC approach I'd just make sure the company has plans to >> update their boxes to 3.1 in a decent (your judgement) amount of time. >> Don't expect any 3.0 box to be software upgradeable to 3.1, the hardware is >> quite different. The PHY+MAC boxes are _generally_ < $10k and some are >> talking about ~6k. >> >> All the vendors we've listed so far have plans for 3.1, but I don't have >> a timeline for any of them. Right now the market is still trying to decide >> how modular CMTS will be rolled out, remote PHY, remote MAC+PHY, or a >> combination. For example, Cisco is (for the moment) betting that remote >> PHY economics will be compelling for the larger operators, while Arris is >> doing both approaches. >> >> >> Scott Helms >> Chief Technology Officer >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Tue, Feb 2, 2016 at 3:31 PM, Colton Conor >> wrote: >> >>> Is a remote MAC+PHY the same thing as a Distributed Converged Cable >>> Access Platform (D-CCAP) solution like Huawei is pushing? Is DOCSIS 3.1 >>> even out, or am I looking for something that does not exist yet? >>> >>> Are these remote MAC+PHY devices in the under 10K price range that >>> these smaller all in one CMTS platforms are? >>> >>> On Tue, Feb 2, 2016 at 12:49 PM, Scott Helms wrote: >>> >>>> >>>> >>>> >>>> >>>> On Tue, Feb 2, 2016 at 1:24 PM, Colton Conor >>>> wrote: >>>> >>>>> Yes, we are in the USA. So based on everyones recommendations, I am >>>>> going to stay far away from EURODOCSIS. I was told be a vendor that >>>>> Arris and other USA FCC certified cable modems could easily be flashed to >>>>> EURODOCIS mode, so I did not think the CPE side was that big of a deal (is >>>>> that even true). I was not aware that there were so many differences >>>>> besides just the channel width. >>>>> >>>> >>>> I wish this were the case, it would make my life easier. The problem >>>> is that there is a diplex filter that prevents the upstream burst from >>>> being heard by the downstream receiver and for cost purposes all the D3 and >>>> earlier modems have fixed filters. What that means is that a EuroDOCSIS >>>> modem can (sometimes) be flashed to use 6MHz channels, but the reverse is >>>> NOT true. In any case we don't recommend using Euro modems that are >>>> flashed to US standards in production (nor do the vendors) because you'll >>>> see much more upstream leakage. >>>> >>>> >>>>> >>>>> So, assuming we are talking about DOCSIS only (and not EURODOCSIS), >>>>> what do you recommend? I like the idea of being able to upgrade to 3.1, but >>>>> not sure if there are any small systems capable of this? By small I mean >>>>> something that could feed less than 100 units, and be economical to do. >>>>> Cable has the advantage of cheap modems, so it's really the CMTS side. >>>>> >>>> >>>> In that case I'd definitely go with a remote MAC+PHY. That's the only >>>> way you're going to get a good price point and decent performance unless >>>> you want to use the secondary market, which actually isn't a bad idea right >>>> now. A used 7225 with 8x8 blades is pretty cheap, but it's centralized >>>> CMTS that would cover ~3k subs. >>>> >>>>> >>>>> Please remember I am only interested in data internet services over >>>>> this plant. Something that works for garden style layouts where I can bring >>>>> fiber or coaxial to the side of a garden townhome that has between 4 to 16 >>>>> units inside of it. The reason I requested a harden outdoor unit is that >>>>> most all of the garden style properties have both the phone >>>>> and coaxial drops on the outside of the building. There is no central >>>>> closet or room. Plus we are in the south, so hardened for the >>>>> heat exposure makes sense. >>>>> >>>>> A remote MAC-PHY (or pre remote MAC-PHY, ala mini CMTS) sounds like >>>>> what I want. I will check into Huawei and Gainspeed. Who else makes these? >>>>> >>>> >>>> In no particular order, Arris is or will be, Teleste (Euro vendor >>>> trying to break into the US), Sumavision, Altera, and ton more I can't >>>> remember. Come to one of the SCTE shows (it's in Philadelphia this year) >>>> if you want to be deluged with them :) >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Feb 2, 2016 at 11:24 AM, Scott Helms >>>>> wrote: >>>>> >>>>>> Nick, >>>>>> >>>>>> Absolutely, if your plant is in Europe or one of the other areas >>>>>> (lots of Africa and the middle East is like that) that adopted EuroDOCSIS >>>>>> I'd agree wholeheartedly. I didn't see Colton say where they're located, >>>>>> but all North America is the US flavor so that's what I assume on NANOG. >>>>>> >>>>>> That being said, the best thing that seldom gets mentioned about D3.1 >>>>>> is getting us to unified channelization. >>>>>> Scott Helms wrote: >>>>>> > That very small upside for an extreme downside.Trying to hire >>>>>> someone >>>>>> > to work on your system with Euro channelization, not to mention >>>>>> buying >>>>>> > amplifiers and passives is a huge PITA. >>>>>> >>>>>> ... if your plant is in the US. >>>>>> >>>>>> > I have customers in Europe who >>>>>> > decided to do US DOCSIS and they universally wish they had used the >>>>>> > local "flavor". >>>>>> >>>>>> as you say, eurodocsis works well in europe. >>>>>> >>>>>> 3.1 will be a major improvement when it materialises. >>>>>> >>>>>> Nick >>>>>> >>>>> >>>>> >>>> >>> >> > From colton.conor at gmail.com Wed Feb 10 00:48:20 2016 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 9 Feb 2016 18:48:20 -0600 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: Scott, I was able to find the Huawie solution: http://www.huawei.com/ucmf/groups/public/documents/webasset/hw_415387.pdf Looks like its 32x4 capable today, and software upgradeable to DOCSIS 3.1 which is nice. Appears to also have a 10G uplink port on it. Seems like the best solution tech spec wise I have seen so far. And probably cheap too! The Sumavision one you linked to seems to be a 16X4 version, but future improved to 32 channels DS and 10 channels US. Future improved to DOCSIS 3.1 Not sure if that means the hardware is already capable and just a software upgrade or what. I assume the Harmonic box you are mentioning is the is the NSG Exo: http://harmonicinc.com/product/cable-edge/nsg-exo According to specs its only a 16x4 unit today. I don't think you can upgrade to greater than 16x4 since there is only a gig-e uplink. I see no mention of DOCSIS 3.1. The stand (outdoor version) seems to be the same as the indoor. The indoor version of the NSG EXO spec wise looks identical to the PICO Digital miniCMTS200a. According to Daniel Corbe these two units use the same chipset (along with the Blonder Tongue CMTS: http://www.blondertongue.com/shop-by-department/catv/ip-over-coax/docsis/euro-docsis/) Based on pricing I have seen so far, the Pico is the cheapest. Harmonic is a little more, and Blonder Tongue is a bit more than Harmonic. Out of these three I would assume Harmonic is the most reputable? I have not heard anything back from gainspeed. Based on the info on their website, I am not positive they have an actual product released yet. Not mentioned so far are Arris and Cisco. Any idea if either of these vendors has a small and low cost model? From khelms at zcorum.com Wed Feb 10 00:50:44 2016 From: khelms at zcorum.com (Scott Helms) Date: Tue, 9 Feb 2016 19:50:44 -0500 Subject: Cable Operator List In-Reply-To: References: <9546F2FD-7A91-4F78-9B62-7207763B1B38@hammerfiber.com> <56B0D57D.6070107@foobar.org> <56B0E11F.60805@foobar.org> Message-ID: Colton, Arris has plans to release a remote PHY+MAC box but I don't think they have released anything but their plans. John Chapman said last year at SCTE that Cisco was going down the remote PHY only path because they think that will be the most cost effective way for large MSOs to deploy MHAv2. Scott Helms Chief Technology Officer ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Feb 9, 2016 at 7:48 PM, Colton Conor wrote: > Scott, > > I was able to find the Huawie solution: > http://www.huawei.com/ucmf/groups/public/documents/webasset/hw_415387.pdf > Looks like its 32x4 capable today, and software upgradeable to DOCSIS 3.1 > which is nice. Appears to also have a 10G uplink port on it. Seems like the > best solution tech spec wise I have seen so far. And probably cheap too! > > The Sumavision one you linked to seems to be a 16X4 version, but future > improved to 32 channels DS and 10 channels US. Future improved to DOCSIS > 3.1 Not sure if that means the hardware is already capable and just a > software upgrade or what. > > I assume the Harmonic box you are mentioning is the is the NSG Exo: > http://harmonicinc.com/product/cable-edge/nsg-exo According to specs its > only a 16x4 unit today. I don't think you can upgrade to greater than 16x4 > since there is only a gig-e uplink. I see no mention of DOCSIS 3.1. The > stand (outdoor version) seems to be the same as the indoor. > > The indoor version of the NSG EXO spec wise looks identical to the PICO > Digital miniCMTS200a. According to Daniel Corbe these two units use the > same chipset (along with the Blonder Tongue CMTS: > http://www.blondertongue.com/shop-by-department/catv/ip-over-coax/docsis/euro-docsis/) > Based on pricing I have seen so far, the Pico is the cheapest. Harmonic is > a little more, and Blonder Tongue is a bit more than Harmonic. Out of these > three I would assume Harmonic is the most reputable? > > I have not heard anything back from gainspeed. Based on the info on their > website, I am not positive they have an actual product released yet. > > Not mentioned so far are Arris and Cisco. Any idea if either of these > vendors has a small and low cost model? > From nanog at ics-il.net Wed Feb 10 14:59:08 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 10 Feb 2016 08:59:08 -0600 (CST) Subject: Shared cabinet "security" In-Reply-To: <1091104950.546.1455115391869.JavaMail.mhammett@ThunderFuck> Message-ID: <1767618948.585.1455116296142.JavaMail.mhammett@ThunderFuck> I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From josh at kyneticwifi.com Wed Feb 10 15:22:56 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Wed, 10 Feb 2016 09:22:56 -0600 Subject: Shared cabinet "security" In-Reply-To: <1767618948.585.1455116296142.JavaMail.mhammett@ThunderFuck> References: <1091104950.546.1455115391869.JavaMail.mhammett@ThunderFuck> <1767618948.585.1455116296142.JavaMail.mhammett@ThunderFuck> Message-ID: Segmented cabinets with outlets inside each space? On Feb 10, 2016 9:01 AM, "Mike Hammett" wrote: > I say "security" because I know that in a shared space, nothing is > completely secure. I also know that with enough intent, someone will > accomplish whatever they set out to do regarding breaking something of > someone else's. My concern is mainly towards mitigation of accidents. This > could even apply to a certain degree to things within your own space and > your own careless techs > > If you have multiple entities in a shared space, how can you mitigate the > chances of someone doing something (assuming accidentally) to disrupt your > operations? I'm thinking accidentally unplug the wrong power cord, patch > cord, etc. Accidentally power off or reboot the wrong device. > > Obviously labels are an easy way to point out to someone that's looking at > the right place at the right time. Some devices have a cage around the > power cord, but some do not. > > Any sort of mesh panels you could put on the front\rear of your gear that > you would mount with the same rack screw that holds your gear in? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From nanog at ics-il.net Wed Feb 10 15:32:21 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 10 Feb 2016 09:32:21 -0600 (CST) Subject: Shared cabinet "security" In-Reply-To: Message-ID: <10831667.634.1455118283114.JavaMail.mhammett@ThunderFuck> Not feasible when you're in someone else's datacenter. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Josh Reynolds" To: "Mike Hammett" Cc: "NANOG" Sent: Wednesday, February 10, 2016 9:22:56 AM Subject: Re: Shared cabinet "security" Segmented cabinets with outlets inside each space? On Feb 10, 2016 9:01 AM, "Mike Hammett" < nanog at ics-il.net > wrote: I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From lists at sadiqs.com Wed Feb 10 20:36:46 2016 From: lists at sadiqs.com (Sadiq Saif) Date: Wed, 10 Feb 2016 15:36:46 -0500 Subject: Fwd: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability In-Reply-To: <201602100806.9.asa@psirt.cisco.com> References: <201602100806.9.asa@psirt.cisco.com> Message-ID: <56BB9F5E.5080500@sadiqs.com> Update your ASAs folks, this is a critical one. -------- Forwarded Message -------- Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability Date: Wed, 10 Feb 2016 08:06:51 -0800 From: Cisco Systems Product Security Incident Response Team Reply-To: psirt at cisco.com To: cisco-nsp at puck.nether.net CC: psirt at cisco.com Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability Advisory ID: cisco-sa-20160210-asa-ike Revision 1.0 For Public Release 2016 February 10 16:00 GMT (UTC) +--------------------------------------------------------------------- Summary ======= A vulnerability in the Internet Key Exchange (IKE) version 1 (v1) and IKE version 2 (v2) code of Cisco ASA Software could allow an unauthenticated, remote attacker to cause a reload of the affected system or to remotely execute code. The vulnerability is due to a buffer overflow in the affected code area. An attacker could exploit this vulnerability by sending crafted UDP packets to the affected system. An exploit could allow the attacker to execute arbitrary code and obtain full control of the system or to cause a reload of the affected system. Note: Only traffic directed to the affected system can be used to exploit this vulnerability. This vulnerability affects systems configured in routed firewall mode only and in single or multiple context mode. This vulnerability can be triggered by IPv4 and IPv6 traffic. Cisco has released software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From patrick at ianai.net Wed Feb 10 23:34:33 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 10 Feb 2016 18:34:33 -0500 Subject: PCH Peering Paper Message-ID: I quoted a PCH peering paper at the Peering Track. (Not violating rules, talking about myself.) The paper is: https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011.pdf I said ?99.97%? of all peering sessions have nothing behind them more than a ?handshake? or an email. It seems I was in error. Mea Culpa. The number in the paper, on page one is, 99.52%. Hopefully everyone will read the paper, and perhaps help create better data. -- TTFN, patrick From drohan at gmail.com Thu Feb 11 01:02:58 2016 From: drohan at gmail.com (Daniel Rohan) Date: Wed, 10 Feb 2016 17:02:58 -0800 Subject: Fiber to the home specialists/consultants? Message-ID: Can anyone point me at a firm that does or consults on FTTH from a technical *and* business perspective? Off-list responses would be appreciated. Thanks, Dan From jhaustin at gmail.com Thu Feb 11 01:14:51 2016 From: jhaustin at gmail.com (Jeremy Austin) Date: Thu, 11 Feb 2016 01:14:51 +0000 Subject: Fiber to the home specialists/consultants? In-Reply-To: References: Message-ID: Ditto. On Wed, Feb 10, 2016 at 4:04 PM Daniel Rohan wrote: > Can anyone point me at a firm that does or consults on FTTH from a > technical *and* business perspective? > > Off-list responses would be appreciated. > > Thanks, > > Dan > From dgolding at gmail.com Thu Feb 11 02:27:22 2016 From: dgolding at gmail.com (Daniel Golding) Date: Thu, 11 Feb 2016 02:27:22 +0000 Subject: [NANOG-announce] Communications Committee Message-ID: Greetings NANOG Colleagues, The Board has completed the Communications Committee selection process for 2016. We are pleased to announce the two-year term appointment of Judy de Dios and Michelle Pierce to the Communications Committee. We also want to thank and recognize Randy Epstein for his service on the CC. In the coming weeks, the new Communications Committee will hold its first meeting and select a Chair and a Vice-Chair. Sincerely, Daniel Golding Chairman, NANOG Board of Directors -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From hugge at nordu.net Wed Feb 10 23:48:31 2016 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Thu, 11 Feb 2016 00:48:31 +0100 Subject: PCH Peering Paper In-Reply-To: References: Message-ID: <56BBCC4F.9060304@nordu.net> On 11/02/16 00:34, Patrick W. Gilmore wrote: > I quoted a PCH peering paper at the Peering Track. (Not violating rules, talking about myself.) > > The paper is: > https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011.pdf > > I said ?99.97%? of all peering sessions have nothing behind them more than a ?handshake? or an email. It seems I was in error. Mea Culpa. > > The number in the paper, on page one is, 99.52%. > > Hopefully everyone will read the paper, and perhaps help create better data. > Well, how about crowdsourcing some data? 3145 eBGP settlement-free peering-sessions (v4 and v6 combined) in US and EU. 350k routes recieved over SFI peering. 1 Written contract in EU for SFI 1 Written contract in US for SFI R&E Sector -- Apparently not a peering coordinator. Fredrik "hugge" Korsb?ck AS2603 From paras at protrafsolutions.com Thu Feb 11 03:07:21 2016 From: paras at protrafsolutions.com (Paras Jha) Date: Wed, 10 Feb 2016 22:07:21 -0500 Subject: Looking for GTT contact Message-ID: Hello, Can a rep for GTT contact me off-list? I tried twice using their website, but nobody has gotten back to me for a few days now. Thanks in advance! From adrian.minta at gmail.com Thu Feb 11 13:53:15 2016 From: adrian.minta at gmail.com (Adrian M) Date: Thu, 11 Feb 2016 15:53:15 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability In-Reply-To: <56BB9F5E.5080500@sadiqs.com> References: <201602100806.9.asa@psirt.cisco.com> <56BB9F5E.5080500@sadiqs.com> Message-ID: Be careful, It appears that something is broken with ARP on this release. We have no ARP on lan interface, and somebody else has a similar problem: https://www.reddit.com/r/networking/comments/433kqx/cisco_asa_not_recording_an_arp_entry/ On Wed, Feb 10, 2016 at 10:36 PM, Sadiq Saif wrote: > Update your ASAs folks, this is a critical one. > > > -------- Forwarded Message -------- > Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and > IKEv2 Buffer Overflow Vulnerability > Date: Wed, 10 Feb 2016 08:06:51 -0800 > From: Cisco Systems Product Security Incident Response Team > > Reply-To: psirt at cisco.com > To: cisco-nsp at puck.nether.net > CC: psirt at cisco.com > > Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer > Overflow Vulnerability > > Advisory ID: cisco-sa-20160210-asa-ike > > Revision 1.0 > > For Public Release 2016 February 10 16:00 GMT (UTC) > > +--------------------------------------------------------------------- > > > Summary > ======= > > A vulnerability in the Internet Key Exchange (IKE) version 1 (v1) and > IKE version 2 (v2) code of Cisco ASA Software could allow an > unauthenticated, remote attacker to cause a reload of the affected > system or to remotely execute code. > > The vulnerability is due to a buffer overflow in the affected code area. > An attacker could exploit this vulnerability by sending crafted UDP > packets to the affected system. An exploit could allow the attacker to > execute arbitrary code and obtain full control of the system or to cause > a reload of the affected system. > > Note: Only traffic directed to the affected system can be used to > exploit this vulnerability. This vulnerability affects systems > configured in routed firewall mode only and in single or multiple > context mode. This vulnerability can be triggered by IPv4 and IPv6 traffic. > > Cisco has released software updates that address this vulnerability. > This advisory is available at the following link: > > http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike > > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > From fkittred at gwi.net Thu Feb 11 14:28:32 2016 From: fkittred at gwi.net (Fletcher Kittredge) Date: Thu, 11 Feb 2016 09:28:32 -0500 Subject: Fiber to the home specialists/consultants? In-Reply-To: References: Message-ID: Since two asked: Tilson On Wed, Feb 10, 2016 at 8:14 PM, Jeremy Austin wrote: > Ditto. > On Wed, Feb 10, 2016 at 4:04 PM Daniel Rohan wrote: > > > Can anyone point me at a firm that does or consults on FTTH from a > > technical *and* business perspective? > > > > Off-list responses would be appreciated. > > > > Thanks, > > > > Dan > > > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From andrew.a at aware.co.th Thu Feb 11 14:35:51 2016 From: andrew.a at aware.co.th (Andrew (Andy) Ashley) Date: Thu, 11 Feb 2016 14:35:51 +0000 Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability In-Reply-To: References: <201602100806.9.asa@psirt.cisco.com> <56BB9F5E.5080500@sadiqs.com> Message-ID: <25A124C1-70FD-42BF-A920-0051A05D0D83@aware.co.th> Is a control-plane ACL to limit isakmp traffic (UDP/500) to an affected ASA from desired sources enough to mitigate this attack, until upgrades can be performed? Regards, Andrew Ashley -----Original Message----- From: NANOG on behalf of Adrian M Date: Thursday, 11 February 2016 at 15:53 To: "nanog at nanog.org" Subject: Re: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability >Be careful, It appears that something is broken with ARP on this release. >We have no ARP on lan interface, and somebody else has a similar problem: >https://www.reddit.com/r/networking/comments/433kqx/cisco_asa_not_recording_an_arp_entry/ > > > >On Wed, Feb 10, 2016 at 10:36 PM, Sadiq Saif wrote: > >> Update your ASAs folks, this is a critical one. >> >> >> -------- Forwarded Message -------- >> Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and >> IKEv2 Buffer Overflow Vulnerability >> Date: Wed, 10 Feb 2016 08:06:51 -0800 >> From: Cisco Systems Product Security Incident Response Team >> >> Reply-To: psirt at cisco.com >> To: cisco-nsp at puck.nether.net >> CC: psirt at cisco.com >> >> Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer >> Overflow Vulnerability >> >> Advisory ID: cisco-sa-20160210-asa-ike >> >> Revision 1.0 >> >> For Public Release 2016 February 10 16:00 GMT (UTC) >> >> +--------------------------------------------------------------------- >> >> >> Summary >> ======= >> >> A vulnerability in the Internet Key Exchange (IKE) version 1 (v1) and >> IKE version 2 (v2) code of Cisco ASA Software could allow an >> unauthenticated, remote attacker to cause a reload of the affected >> system or to remotely execute code. >> >> The vulnerability is due to a buffer overflow in the affected code area. >> An attacker could exploit this vulnerability by sending crafted UDP >> packets to the affected system. An exploit could allow the attacker to >> execute arbitrary code and obtain full control of the system or to cause >> a reload of the affected system. >> >> Note: Only traffic directed to the affected system can be used to >> exploit this vulnerability. This vulnerability affects systems >> configured in routed firewall mode only and in single or multiple >> context mode. This vulnerability can be triggered by IPv4 and IPv6 traffic. >> >> Cisco has released software updates that address this vulnerability. >> This advisory is available at the following link: >> >> http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike >> >> >> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5830 bytes Desc: not available URL: From dwcarder at wisc.edu Thu Feb 11 18:06:08 2016 From: dwcarder at wisc.edu (Dale W. Carder) Date: Thu, 11 Feb 2016 12:06:08 -0600 Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability In-Reply-To: <25A124C1-70FD-42BF-A920-0051A05D0D83@aware.co.th> References: <201602100806.9.asa@psirt.cisco.com> <56BB9F5E.5080500@sadiqs.com> <25A124C1-70FD-42BF-A920-0051A05D0D83@aware.co.th> Message-ID: <20160211180608.GC15156@DOIT-2NW1MRFY-X.doit.wisc.edu> Thus spake Andrew (Andy) Ashley (andrew.a at aware.co.th) on Thu, Feb 11, 2016 at 02:35:51PM +0000: > Is a control-plane ACL to limit isakmp traffic (UDP/500) to an affected ASA from desired sources enough to mitigate this attack, until upgrades can be performed? It's worth noting that is not listed as a workaround (they typically use branding like "infrastructure acl's" or some such) to mitigate it on the affected box. Upstream, yes that would seem to be intuitive. Perhaps because you are corrupting the heap with fragments you are outside of where the ACL is applied? Dale From dgolding at gmail.com Thu Feb 11 21:01:42 2016 From: dgolding at gmail.com (Daniel Golding) Date: Thu, 11 Feb 2016 21:01:42 +0000 Subject: [NANOG-announce] NANOG PC Appointments for 2016-2017 Message-ID: Greetings NANOG Colleagues, The NANOG Board of Directors has completed the Program Committee selection process. This year, 18 members submitted their candidacies for 7 available positions. We want to thank each and every candidate for considering this important service to our community. We are pleased to announce the two-year term appointment of Kevin Blumberg, Anna Claiborne, Steve Plote, Steve Schecter, Benson Schliesser, Jesse Sowell, and Chris Woodfield to the Program Committee. We also want to thank and recognize the contribution of Greg Hankins, Manish Karir, Michael Sinatra, and Tony Tauber for their service on the Program Committee, which concluded at the San Diego NANOG meeting. In the coming weeks, the new Program Committee will hold its first meeting and select a Chair and a Vice-Chair. Sincerely, Daniel Golding Chairman, NANOG Board of Directors -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From frnkblk at iname.com Thu Feb 11 21:51:37 2016 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 11 Feb 2016 15:51:37 -0600 Subject: Automated alarm notification Message-ID: <001c01d16516$6202c690$260853b0$@iname.com> Is anyone aware of software, or perhaps a service, that will take SNMP traps, properly parse them, and perform the appropriate call outs based on certain content, after waiting 5 or 10 minutes for any alarms that don't clear? I looked at PagerDuty, but they don't do any SNMP trap parsing, and nothing with set/clear. Frank From jk at ip-clear.de Thu Feb 11 21:58:08 2016 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Thu, 11 Feb 2016 22:58:08 +0100 Subject: Automated alarm notification In-Reply-To: <001c01d16516$6202c690$260853b0$@iname.com> References: <001c01d16516$6202c690$260853b0$@iname.com> Message-ID: Hi, you could use snmptt with an Exec-Command (SendMail, SMS, ?) or define it as a passive service alert in Nagios / Icinga / $YourMonitoring. J?rg On 11 Feb 2016, at 22:51, Frank Bulk wrote: > Is anyone aware of software, or perhaps a service, that will take SNMP > traps, properly parse them, and perform the appropriate call outs > based on > certain content, after waiting 5 or 10 minutes for any alarms that > don't > clear? > > I looked at PagerDuty, but they don't do any SNMP trap parsing, and > nothing > with set/clear. > > Frank From josh at zevlag.com Thu Feb 11 21:58:43 2016 From: josh at zevlag.com (Josh Galvez) Date: Thu, 11 Feb 2016 14:58:43 -0700 Subject: Automated alarm notification In-Reply-To: <001c01d16516$6202c690$260853b0$@iname.com> References: <001c01d16516$6202c690$260853b0$@iname.com> Message-ID: I've used Zabbix, Nagios, etc to handle receiving and parsing traps, set/clear etc. Then have them send a trap (or via email to script that sends a trap) to SIPShout to actually generate the callout. It's worked well. -Josh On Thu, Feb 11, 2016 at 2:51 PM, Frank Bulk wrote: > Is anyone aware of software, or perhaps a service, that will take SNMP > traps, properly parse them, and perform the appropriate call outs based on > certain content, after waiting 5 or 10 minutes for any alarms that don't > clear? > > I looked at PagerDuty, but they don't do any SNMP trap parsing, and nothing > with set/clear. > > Frank > > From jna at retina.net Thu Feb 11 23:23:40 2016 From: jna at retina.net (John Adams) Date: Thu, 11 Feb 2016 15:23:40 -0800 Subject: Automated alarm notification In-Reply-To: <001c01d16516$6202c690$260853b0$@iname.com> References: <001c01d16516$6202c690$260853b0$@iname.com> Message-ID: datadog will do this without issue, and if you have a small number of hosts it's nearly free. -j On Thu, Feb 11, 2016 at 1:51 PM, Frank Bulk wrote: > Is anyone aware of software, or perhaps a service, that will take SNMP > traps, properly parse them, and perform the appropriate call outs based on > certain content, after waiting 5 or 10 minutes for any alarms that don't > clear? > > I looked at PagerDuty, but they don't do any SNMP trap parsing, and nothing > with set/clear. > > Frank > > From oliver.oboyle at gmail.com Fri Feb 12 02:44:38 2016 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 11 Feb 2016 21:44:38 -0500 Subject: Automated alarm notification In-Reply-To: References: <001c01d16516$6202c690$260853b0$@iname.com> Message-ID: Check_MK over OMD. Good event parsing capabilities. Easy to set up, nagios core but rewritten app for much better performance. Multisite master/slave capabilities +++. Free or supported. Your pick. On Feb 11, 2016 9:26 PM, "John Adams" wrote: > datadog will do this without issue, and if you have a small number of hosts > it's nearly free. > > -j > > > On Thu, Feb 11, 2016 at 1:51 PM, Frank Bulk wrote: > > > Is anyone aware of software, or perhaps a service, that will take SNMP > > traps, properly parse them, and perform the appropriate call outs based > on > > certain content, after waiting 5 or 10 minutes for any alarms that don't > > clear? > > > > I looked at PagerDuty, but they don't do any SNMP trap parsing, and > nothing > > with set/clear. > > > > Frank > > > > > From admin at marcoteixeira.com Fri Feb 12 09:34:15 2016 From: admin at marcoteixeira.com (Marco Teixeira) Date: Fri, 12 Feb 2016 09:34:15 +0000 Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability In-Reply-To: <20160211180608.GC15156@DOIT-2NW1MRFY-X.doit.wisc.edu> References: <201602100806.9.asa@psirt.cisco.com> <56BB9F5E.5080500@sadiqs.com> <25A124C1-70FD-42BF-A920-0051A05D0D83@aware.co.th> <20160211180608.GC15156@DOIT-2NW1MRFY-X.doit.wisc.edu> Message-ID: Hi, First, understand how it's done, then maybe you can think of something. https://blog.exodusintel.com/2016/02/10/firewall-hacking/ If you are stopping IKE with ACL's, you probably need to address NAT-T as well (udp:4500). But if you are doing that, you probably don't need IKE active at the ASA, so just disabling it all together will probably do the trick.? --- Best regards ?M? arco Teixeira --- On Thu, Feb 11, 2016 at 6:06 PM, Dale W. Carder wrote: > Thus spake Andrew (Andy) Ashley (andrew.a at aware.co.th) on Thu, Feb 11, > 2016 at 02:35:51PM +0000: > > Is a control-plane ACL to limit isakmp traffic (UDP/500) to an affected > ASA from desired sources enough to mitigate this attack, until upgrades can > be performed? > > It's worth noting that is not listed as a workaround (they typically use > branding like "infrastructure acl's" or some such) to mitigate it on the > affected box. Upstream, yes that would seem to be intuitive. > > Perhaps because you are corrupting the heap with fragments you are > outside of where the ACL is applied? > > Dale > From spedersen.lists at gmail.com Fri Feb 12 14:56:07 2016 From: spedersen.lists at gmail.com (Sean) Date: Fri, 12 Feb 2016 07:56:07 -0700 Subject: Shared cabinet "security" In-Reply-To: <1767618948.585.1455116296142.JavaMail.mhammett@ThunderFuck> References: <1091104950.546.1455115391869.JavaMail.mhammett@ThunderFuck> <1767618948.585.1455116296142.JavaMail.mhammett@ThunderFuck> Message-ID: <880CB40F-704A-420F-AB9A-41F33CEF1F03@gmail.com> Some examples from where I work: - Open space, but your own cabinet. We have open areas where there are rows of half and full cabinets where customers can rent space. That cabinet space is theirs, but they?re in the open and anyone can get to the physical cabinet. While in general the cabinets are secure, they could still be broken in to. One could also disconnect power from the overhead junction boxes, or cut the fiber/copper feed going into the cabinets. - Caged space. Your cabinets are inside a locked cage. You can choose to have a ?ceiling? installed if you think someone is going to squirrel their way up the walls. The whole area is locked, no one else can get in. Unless they crawl under the floor! Access to power and data lines are only available inside the cage. - Completely isolated space. We have a few customers that have paid to build literal walls around their leased space, giving them a completely isolated data center within a data center. Probably the most secure from the customer?s perspective, as they can and have employed their own man-traps, security systems, surveillance, etc. on top of our own. - Module space. We have fully-enclosed modules that are RFID card access only. Half or whole modules can be leased. Similar to a caged space, but completely sealed and self-contained. Some of them are shared space, so the same potential issues in the first bullet apply. On top of this, the data center is carded, man-trapped, iris-scanner?d, video-surveilled, etc. No lasers or pressure-sensitive plates. These are just examples to illustrate some of the different levels of access someone else might have to another entity?s gear. I?d be curious to hear examples of cases where malicious activity took place within a data center, one customer to another. On 2/10/16, 7:59 AM, "NANOG on behalf of Mike Hammett" wrote: >I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs > >If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. > >Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. > >Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com From phil at vampire-slayers.com Fri Feb 12 02:27:11 2016 From: phil at vampire-slayers.com (Phil Clarke) Date: Fri, 12 Feb 2016 02:27:11 +0000 Subject: Automated alarm notification In-Reply-To: <001c01d16516$6202c690$260853b0$@iname.com> References: <001c01d16516$6202c690$260853b0$@iname.com> Message-ID: <75A49575-B4D3-45B6-99DC-2ADD9769A66E@vampire-slayers.com> > On 11 Feb 2016, at 21:51, Frank Bulk wrote: > > Is anyone aware of software, or perhaps a service, that will take SNMP > traps, properly parse them, and perform the appropriate call outs based on > certain content, after waiting 5 or 10 minutes for any alarms that don't > clear? Where I currently work we use CastleRock SNMPc and feed alarms based off certain trap conditions/time events into another bit of software called EasyCall which then sends out SMS messages to the engineers; however both are Windows based only. $Job-1 used Nagios to parse the traps and send SMS from a mobile phone directly connected to the server after the conditions were met. From Jason_Livingood at comcast.com Fri Feb 12 14:47:16 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Fri, 12 Feb 2016 14:47:16 +0000 Subject: PCH Peering Paper In-Reply-To: References: Message-ID: How does it look when you examine it by not the count of sessions or links but by the volume of overall data? I wonder if it may change a little like 50% of the volume of traffic is covered by a handshake. (I made 50% up - could be any percentage.) Jason >On 2/10/16, 6:34 PM, "NANOG on behalf of Patrick W. Gilmore" > wrote: > >>I quoted a PCH peering paper at the Peering Track. (Not violating rules, >>talking about myself.) >> >>The paper is: >> https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2 >>0 >>11.pdf >> >>I said ?99.97%? of all peering sessions have nothing behind them more >>than a ?handshake? or an email. It seems I was in error. Mea Culpa. >> >>The number in the paper, on page one is, 99.52%. >> >>Hopefully everyone will read the paper, and perhaps help create better >>data. >> >>-- >>TTFN, >>patrick >> >> > From dcasey at phs.org Fri Feb 12 15:52:48 2016 From: dcasey at phs.org (Casey, David) Date: Fri, 12 Feb 2016 15:52:48 +0000 Subject: Automated alarm notification In-Reply-To: References: <001c01d16516$6202c690$260853b0$@iname.com> Message-ID: We've been using Statseeker for some time now. It costs but it's been well worth the investment as a monitoring solution with the ability to parse incoming syslog messages and generate alerts. David Casey, CCNP Network Engineer 3 Presbyterian Healthcare Services Albuquerque, New Mexico Office: 505-923-6995 Cell: 505-903-1797 Pager: 505-939-1293 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Oliver O'Boyle Sent: Thursday, February 11, 2016 7:45 PM To: John Adams Cc: North American Network Operators' Group Subject: Re: Automated alarm notification Check_MK over OMD. Good event parsing capabilities. Easy to set up, nagios core but rewritten app for much better performance. Multisite master/slave capabilities +++. Free or supported. Your pick. On Feb 11, 2016 9:26 PM, "John Adams" wrote: > datadog will do this without issue, and if you have a small number of > hosts it's nearly free. > > -j > > > On Thu, Feb 11, 2016 at 1:51 PM, Frank Bulk wrote: > > > Is anyone aware of software, or perhaps a service, that will take > > SNMP traps, properly parse them, and perform the appropriate call > > outs based > on > > certain content, after waiting 5 or 10 minutes for any alarms that > > don't clear? > > > > I looked at PagerDuty, but they don't do any SNMP trap parsing, and > nothing > > with set/clear. > > > > Frank > > > > > ============================================ *-*-*- PRESBYTERIAN_HEALTHCARE_SERVICES_DISCLAIMER -*-*-* This message originates from Presbyterian Healthcare Services or one of its affiliated organizations. It contains information, which may be confidential or privileged, and is intended only for the individual or entity named above. It is prohibited for anyone else to disclose, copy, distribute or use the contents of this message. All personal messages express views solely of the sender, which are not to be attributed to Presbyterian Healthcare Services or any of its affiliated organizations, and may not be distributed without this disclaimer. If you received this message in error, please notify us immediately at info at phs.org. If you would like more information about Presbyterian Healthcare Services please visit our web site http://www.phs.org ============================================ From Jason_Livingood at comcast.com Fri Feb 12 15:55:59 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Fri, 12 Feb 2016 15:55:59 +0000 Subject: PCH Peering Paper In-Reply-To: References: Message-ID: How does it look when you examine it by not the count of sessions or links but by the volume of overall data? I wonder if it may change a little like 50% of the volume of traffic is covered by a handshake. (I made 50% up - could be any percentage.) Jason PS - My email address has changed and I?m trying to send a 3rd time. Apologies if they all suddenly post to the list as duplicates! :-) >On 2/10/16, 6:34 PM, "NANOG on behalf of Patrick W. Gilmore" > wrote: > >>I quoted a PCH peering paper at the Peering Track. (Not violating rules, >>talking about myself.) >> >>The paper is: >> https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2 >>0 >>11.pdf >> >>I said ?99.97%? of all peering sessions have nothing behind them more >>than a ?handshake? or an email. It seems I was in error. Mea Culpa. >> >>The number in the paper, on page one is, 99.52%. >> >>Hopefully everyone will read the paper, and perhaps help create better >>data. >> >>-- >>TTFN, >>patrick >> >> > From jra at baylink.com Fri Feb 12 16:49:21 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 12 Feb 2016 16:49:21 +0000 (UTC) Subject: Shared cabinet "security" In-Reply-To: <1767618948.585.1455116296142.JavaMail.mhammett@ThunderFuck> References: <1767618948.585.1455116296142.JavaMail.mhammett@ThunderFuck> Message-ID: <644938707.186337.1455295761155.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Mike Hammett" > > If you have multiple entities in a shared space, how can you mitigate the > chances of someone doing something (assuming accidentally) to disrupt your > operations? I'm thinking accidentally unplug the wrong power cord, patch cord, > etc. Accidentally power off or reboot the wrong device. > > Any sort of mesh panels you could put on the front\rear of your gear that you > would mount with the same rack screw that holds your gear in? Yup; a standard rack item for audio installs; they go over equalizers and the like. You shouldn't have any trouble finding them in 1U and 2U, maybe larger. 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 cscora at apnic.net Fri Feb 12 18:10:28 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Feb 2016 04:10:28 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201602121810.u1CIASss030464@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 Feb, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 581824 Prefixes after maximum aggregation (per Origin AS): 214337 Deaggregation factor: 2.71 Unique aggregates announced (without unneeded subnets): 284114 Total ASes present in the Internet Routing Table: 52719 Prefixes per ASN: 11.04 Origin-only ASes present in the Internet Routing Table: 36572 Origin ASes announcing only one prefix: 15807 Transit ASes present in the Internet Routing Table: 6405 Transit-only ASes present in the Internet Routing Table: 167 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 40 Max AS path prepend of ASN ( 40285) 34 Prefixes from unregistered ASNs in the Routing Table: 1054 Unregistered ASNs in the Routing Table: 384 Number of 32-bit ASNs allocated by the RIRs: 12696 Number of 32-bit ASNs visible in the Routing Table: 9742 Prefixes from 32-bit ASNs in the Routing Table: 37429 Number of bogon 32-bit ASNs visible in the Routing Table: 15 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 424 Number of addresses announced to Internet: 2803803204 Equivalent to 167 /8s, 30 /16s and 164 /24s Percentage of available address space announced: 75.7 Percentage of allocated address space announced: 75.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.0 Total number of prefixes smaller than registry allocations: 191360 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 149013 Total APNIC prefixes after maximum aggregation: 40951 APNIC Deaggregation factor: 3.64 Prefixes being announced from the APNIC address blocks: 158134 Unique aggregates announced from the APNIC address blocks: 64047 APNIC Region origin ASes present in the Internet Routing Table: 5129 APNIC Prefixes per ASN: 30.83 APNIC Region origin ASes announcing only one prefix: 1174 APNIC Region transit ASes present in the Internet Routing Table: 900 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1850 Number of APNIC addresses announced to Internet: 751867524 Equivalent to 44 /8s, 208 /16s and 150 /24s Percentage of available APNIC address space announced: 87.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 179133 Total ARIN prefixes after maximum aggregation: 88591 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 183852 Unique aggregates announced from the ARIN address blocks: 87082 ARIN Region origin ASes present in the Internet Routing Table: 16412 ARIN Prefixes per ASN: 11.20 ARIN Region origin ASes announcing only one prefix: 5905 ARIN Region transit ASes present in the Internet Routing Table: 1697 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 37 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1005 Number of ARIN addresses announced to Internet: 1101768512 Equivalent to 65 /8s, 171 /16s and 167 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 140206 Total RIPE prefixes after maximum aggregation: 69514 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 148360 Unique aggregates announced from the RIPE address blocks: 91537 RIPE Region origin ASes present in the Internet Routing Table: 18049 RIPE Prefixes per ASN: 8.22 RIPE Region origin ASes announcing only one prefix: 7952 RIPE Region transit ASes present in the Internet Routing Table: 3017 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4444 Number of RIPE addresses announced to Internet: 702807424 Equivalent to 41 /8s, 227 /16s and 253 /24s Percentage of available RIPE address space announced: 102.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 61377 Total LACNIC prefixes after maximum aggregation: 12042 LACNIC Deaggregation factor: 5.10 Prefixes being announced from the LACNIC address blocks: 74732 Unique aggregates announced from the LACNIC address blocks: 34869 LACNIC Region origin ASes present in the Internet Routing Table: 2456 LACNIC Prefixes per ASN: 30.43 LACNIC Region origin ASes announcing only one prefix: 584 LACNIC Region transit ASes present in the Internet Routing Table: 546 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2254 Number of LACNIC addresses announced to Internet: 170650112 Equivalent to 10 /8s, 43 /16s and 234 /24s Percentage of available LACNIC address space announced: 101.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: 14514 Total AfriNIC prefixes after maximum aggregation: 3198 AfriNIC Deaggregation factor: 4.54 Prefixes being announced from the AfriNIC address blocks: 16322 Unique aggregates announced from the AfriNIC address blocks: 6218 AfriNIC Region origin ASes present in the Internet Routing Table: 738 AfriNIC Prefixes per ASN: 22.12 AfriNIC Region origin ASes announcing only one prefix: 192 AfriNIC Region transit ASes present in the Internet Routing Table: 171 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 189 Number of AfriNIC addresses announced to Internet: 76293888 Equivalent to 4 /8s, 140 /16s and 39 /24s Percentage of available AfriNIC address space announced: 75.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 4538 5594 4192 76 China Education and Research 4766 3130 11127 1103 Korea Telecom 7545 3054 350 175 TPG Telecom Limited 17974 2885 914 96 PT Telekomunikasi Indonesia 9829 2354 1444 411 National Internet Backbone 4755 2084 432 237 TATA Communications formerly 9808 1837 8717 29 Guangdong Mobile Communicatio 4808 1619 2281 513 CNCGROUP IP network China169 9583 1517 121 560 Sify Limited 17488 1437 229 234 Hathway IP Over Cable Interne 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 3295 2948 147 Cox Communications Inc. 6389 2412 3687 42 BellSouth.net Inc. 18566 2214 394 278 MegaPath Corporation 20115 1909 1914 411 Charter Communications 6983 1697 849 237 EarthLink, Inc. 30036 1697 339 289 Mediacom Communications Corp 4323 1589 1023 395 tw telecom holdings, inc. 209 1475 4340 1236 Qwest Communications Company, 701 1393 11453 661 MCI Communications Services, 11492 1245 232 602 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 39891 2515 135 9 SaudiNet, Saudi Telecom Compa 20940 2410 938 1724 Akamai International B.V. 34984 1948 322 417 TELLCOM ILETISIM HIZMETLERI A 8551 1226 376 53 Bezeq International-Ltd 8402 1152 544 15 OJSC "Vimpelcom" 12479 1142 982 75 France Telecom Espana SA 13188 1077 97 78 TOV "Bank-Inform" 31148 1041 47 41 Freenet Ltd. 9198 954 352 24 JSC Kazakhtelecom 6830 892 2712 462 Liberty Global Operations B.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3427 541 155 Telmex Colombia S.A. 8151 2174 3388 521 Uninet S.A. de C.V. 7303 1590 943 244 Telecom Argentina S.A. 11830 1439 366 25 Instituto Costarricense de El 6503 1435 453 57 Axtel, S.A.B. de C.V. 28573 1042 2173 156 NET Servi?os de Comunica??o S 6147 1027 377 27 Telefonica del Peru S.A.A. 7738 994 1882 41 Telemar Norte Leste S.A. 26615 992 2325 34 Tim Celular S.A. 3816 987 479 182 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1416 1472 15 TE-AS 24863 1192 402 39 Link Egypt (Link.NET) 37611 608 41 45 Afrihost-Brevis Computer Serv 36903 552 278 103 Office National des Postes et 36992 484 1235 28 ETISALAT MISR 37492 356 215 64 Orange Tunisie 24835 332 146 12 Vodafone Data 29571 264 21 11 Cote d'Ivoire Telecom 37054 254 20 7 Data Telecom Service 2018 237 323 73 TENET (The UNINET Project) Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5594 4192 76 China Education and Research 10620 3427 541 155 Telmex Colombia S.A. 22773 3295 2948 147 Cox Communications Inc. 4766 3130 11127 1103 Korea Telecom 7545 3054 350 175 TPG Telecom Limited 17974 2885 914 96 PT Telekomunikasi Indonesia 39891 2515 135 9 SaudiNet, Saudi Telecom Compa 6389 2412 3687 42 BellSouth.net Inc. 20940 2410 938 1724 Akamai International B.V. 9829 2354 1444 411 National Internet Backbone Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3427 3272 Telmex Colombia S.A. 22773 3295 3148 Cox Communications Inc. 7545 3054 2879 TPG Telecom Limited 17974 2885 2789 PT Telekomunikasi Indonesia 39891 2515 2506 SaudiNet, Saudi Telecom Compa 6389 2412 2370 BellSouth.net Inc. 4766 3130 2027 Korea Telecom 9829 2354 1943 National Internet Backbone 18566 2214 1936 MegaPath Corporation 4755 2084 1847 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 65001 PRIVATE 5.143.176.0/20 15468 OJSC Rostelecom 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 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 23.249.144.0/21 40430 colo4jax, LLC 23.249.152.0/21 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 37.46.10.0/23 36351 SoftLayer Technologies Inc. 37.46.14.0/24 36351 SoftLayer Technologies Inc. 37.46.15.0/24 36351 SoftLayer Technologies Inc. 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:101 /12:265 /13:510 /14:1016 /15:1747 /16:12963 /17:7473 /18:12564 /19:25689 /20:38058 /21:39949 /22:64484 /23:55439 /24:319911 /25:548 /26:576 /27:404 /28:16 /29:16 /30:9 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2480 3295 Cox Communications Inc. 39891 2472 2515 SaudiNet, Saudi Telecom Compa 18566 2116 2214 MegaPath Corporation 6389 1531 2412 BellSouth.net Inc. 30036 1512 1697 Mediacom Communications Corp 6983 1342 1697 EarthLink, Inc. 10620 1312 3427 Telmex Colombia S.A. 34984 1235 1948 TELLCOM ILETISIM HIZMETLERI A 11492 1154 1245 CABLE ONE, INC. 31148 960 1041 Freenet Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1596 2:839 4:19 5:2099 6:26 8:906 12:1786 13:34 14:1620 15:23 16:2 17:58 18:20 20:48 23:1363 24:1735 27:2230 31:1744 32:54 33:2 34:2 35:4 36:214 37:2349 38:1173 39:23 40:82 41:3167 42:382 43:1676 44:41 45:1655 46:2411 47:68 49:1120 50:844 51:3 52:64 54:156 55:5 56:6 57:44 58:1485 59:857 60:541 61:1779 62:1438 63:1895 64:4449 65:2177 66:4093 67:2081 68:1102 69:3284 70:1042 71:463 72:1979 74:2544 75:359 76:420 77:1313 78:1277 79:825 80:1312 81:1361 82:883 83:668 84:799 85:1578 86:474 87:1040 88:557 89:1934 90:163 91:6041 92:846 93:2326 94:2351 95:2281 96:470 97:352 98:945 99:45 100:68 101:891 103:9659 104:2227 105:99 106:387 107:1131 108:651 109:2189 110:1257 111:1608 112:941 113:1210 114:1110 115:1625 116:1522 117:1401 118:2010 119:1555 120:510 121:1168 122:2263 123:1998 124:1607 125:1752 128:739 129:363 130:425 131:1286 132:607 133:173 134:449 135:121 136:349 137:325 138:1674 139:198 140:249 141:471 142:625 143:814 144:591 145:151 146:834 147:599 148:1473 149:459 150:648 151:823 152:593 153:270 154:567 155:901 156:469 157:422 158:346 159:1082 160:422 161:741 162:2266 163:526 164:722 165:1109 166:313 167:1002 168:1470 169:592 170:1496 171:251 172:447 173:1617 174:718 175:852 176:1517 177:3944 178:2230 179:1050 180:2082 181:1642 182:1934 183:679 184:786 185:5657 186:3014 187:1971 188:2064 189:1771 190:7634 191:1245 192:8870 193:5722 194:4331 195:3720 196:1650 197:1359 198:5504 199:5550 200:6866 201:3707 202:10105 203:9520 204:4597 205:2695 206:2968 207:3030 208:4030 209:3874 210:3916 211:2007 212:2649 213:2135 214:823 215:72 216:5704 217:1908 218:741 219:560 220:1640 221:848 222:673 223:916 End of report From maxtul at netassist.ua Fri Feb 12 15:54:03 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Fri, 12 Feb 2016 17:54:03 +0200 Subject: algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters In-Reply-To: References: Message-ID: <56BE001B.1010200@netassist.ua> Hi Martin, well, not only as-set and route. Assuming only legitimate owner of inetnum and aut-num have passwords for mntner from that objects can modify their RIPE DB objects and can create routes. So to create a route object, you have to have access for inetnum and aut-num objects (that can be different passwords and owners in general). Then, you state in your aut-num import and export to some upstream. To do that, you have to use your password, of course. Then, your upstream modifying it's aut-num stating import your asn from you and export your asn to it's upstream... and so on. So it is possible to provide full chain of trust inside RIPE region that way. As-sets is only the way to let manage a lot of downstreams' ASNs more easy. Many of ISPs using it, there is some software like RETN made, to build prefix list to your downstreams automatically. And it works. There is three problems: first, it is only RIPE region specific. You can't do that with ARIN nets for example. Second, it is RIPE-dependent. So we depend on RIPE DB when do routing. In some cases it can make some harm. Third, if someone steal or "recover" RIPE DB password from some inetnum - he can easy do a hijack through system uses RIPE DB filtering. On 04.02.16 13:14, Martin T wrote: > Hi, > > am I correct that ISPs (in RIPE region), who update their BGP prefix > filters automatically, ask their IP transit customer or peering > partner to provide their "route"/"route6" object(s) or "as-set" object > in order to find all the prefixes which they should accept? If the IP > transit customer or peering partner provides an "as-set", then ISP > needs to ensure that this "as-set" belongs to this IP transit customer > or peering partner because there is no automatic authentication for > this, i.e. anybody can create an "as-set" object to database with > random "members" attributes? This is opposite to "route"/"route6" > objects which follow a strict authentication scheme. In addition, in > case of "as-set", an ISP needs to recursively find all the AS numbers > from "members" attributes because "as-set" can include other > "as-sets"? Quite a lot of question, but I would simply like to be sure > that I understand this correctly. > > > thanks, > Martin > From nanog at ics-il.net Fri Feb 12 20:53:17 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 12 Feb 2016 14:53:17 -0600 (CST) Subject: Shared cabinet "security" In-Reply-To: <1767618948.585.1455116296142.JavaMail.mhammett@ThunderFuck> Message-ID: <331349420.4934.1455310393124.JavaMail.mhammett@ThunderFuck> I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. Financial penalty from the violator to the victim if there?s an uh oh? I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "North American Network Operators' Group" Sent: Wednesday, February 10, 2016 8:59:08 AM Subject: Shared cabinet "security" I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From nanog at ics-il.net Fri Feb 12 20:58:27 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 12 Feb 2016 14:58:27 -0600 (CST) Subject: Shared cabinet "security" In-Reply-To: <331349420.4934.1455310393124.JavaMail.mhammett@ThunderFuck> Message-ID: <1174560157.4947.1455310705910.JavaMail.mhammett@ThunderFuck> That moment when you hit send and remember a couple things? Of course labeling of the cables. Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "North American Network Operators' Group" Sent: Friday, February 12, 2016 2:53:17 PM Subject: Re: Shared cabinet "security" I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. Financial penalty from the violator to the victim if there?s an uh oh? I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "North American Network Operators' Group" Sent: Wednesday, February 10, 2016 8:59:08 AM Subject: Shared cabinet "security" I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From omonnig at gmail.com Fri Feb 12 21:30:21 2016 From: omonnig at gmail.com (Otto Monnig) Date: Fri, 12 Feb 2016 15:30:21 -0600 Subject: Shared cabinet "security" In-Reply-To: <1174560157.4947.1455310705910.JavaMail.mhammett@ThunderFuck> References: <1174560157.4947.1455310705910.JavaMail.mhammett@ThunderFuck> Message-ID: Mistake prevention is the key. Neatness counts. Label everything - cubicle, equipment, cables using high quality labels that won?t fall off. Use a meaningful labeling scheme. Label both sides of the equipment with letters large enough for everyone to read. Color coding is nice until you have dim lighting or a color-blind tech. Separate power and data for the wired stuff. EMI leakage is real. Secure power cords to the equipment. Secure cables to PDU so they don?t fall out when bumped. Secure the cables for ?wall wart? power supplies so that they do mot loosen. Learned this the hard way after plugs vibrated or ?fell? out. If you have issues with others pugging into your power, use electrical outlet blocker plugs (baby proofing supplies) and mark them as if the outlet is broken. Secure your data cables so that they do not block the heat exhaust of the equipment. Use cable boots to prevent damage to cable clips, and to prevent tugging on other cables when making changes. Don?t bend cables beyond the minimum bend radius. You?re only as safe as the most dangerous technician that is allowed into the space. -- Otto Monnig CTO KTG IP, LLC omonnig at gmail.com > On Feb 12, 2016, at 2:58 PM, Mike Hammett wrote: > > > That moment when you hit send and remember a couple things? > > Of course labeling of the cables. > > Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > To: "North American Network Operators' Group" > Sent: Friday, February 12, 2016 2:53:17 PM > Subject: Re: Shared cabinet "security" > > > I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). > http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx > > It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf > > I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. > > I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. > > I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. > > I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. > > Financial penalty from the violator to the victim if there?s an uh oh? > > I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > To: "North American Network Operators' Group" > Sent: Wednesday, February 10, 2016 8:59:08 AM > Subject: Shared cabinet "security" > > I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs > > If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. > > Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. > > Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From bevan at slattery.net.au Fri Feb 12 22:44:34 2016 From: bevan at slattery.net.au (Bevan Slattery) Date: Sat, 13 Feb 2016 08:44:34 +1000 Subject: Shared cabinet "security" In-Reply-To: <1174560157.4947.1455310705910.JavaMail.mhammett@ThunderFuck> References: <1174560157.4947.1455310705910.JavaMail.mhammett@ThunderFuck> Message-ID: In a past life we worked with our supplier to create physically separate sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable path for interconnects to the meet-me-room and connection to power supplies. Can be done and I think there are now rack suppliers that do this as standard. Been out of DC space for a few years now. [b] > On 13 Feb 2016, at 6:58 AM, Mike Hammett wrote: > > > That moment when you hit send and remember a couple things? > > Of course labeling of the cables. > > Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > To: "North American Network Operators' Group" > Sent: Friday, February 12, 2016 2:53:17 PM > Subject: Re: Shared cabinet "security" > > > I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). > http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx > > It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf > > I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. > > I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. > > I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. > > I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. > > Financial penalty from the violator to the victim if there?s an uh oh? > > I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > To: "North American Network Operators' Group" > Sent: Wednesday, February 10, 2016 8:59:08 AM > Subject: Shared cabinet "security" > > I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs > > If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. > > Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. > > Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From bedard.phil at gmail.com Sat Feb 13 00:39:44 2016 From: bedard.phil at gmail.com (Phil Bedard) Date: Fri, 12 Feb 2016 19:39:44 -0500 Subject: PCH Peering Paper In-Reply-To: References: Message-ID: <56be7b64.c7d20d0a.2857.0327@mx.google.com> I was going to ask the same thing, since even for settlement free peering between large content providers and eyeball networks there are written agreements in place. I would have no clue on the volume percentage but it's not going to be near 99%. Phil From: Livingood, Jason Sent: Friday, February 12, 2016 11:41 AM To: North American Operators' Group Subject: re: PCH Peering Paper How does it look when you examine it by not the count of sessions or links but by the volume of overall data? I wonder if it may change a little like 50% of the volume of traffic is covered by a handshake. (I made 50% up - could be any percentage.) Jason PS - My email address has changed and I?m trying to send a 3rd time. Apologies if they all suddenly post to the list as duplicates! :-) >On 2/10/16, 6:34 PM, "NANOG on behalf of Patrick W. Gilmore" > wrote: > >>I quoted a PCH peering paper at the Peering Track. (Not violating rules, >>talking about myself.) >> >>The paper is: >> https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2 >>0 >>11.pdf >> >>I said ?99.97%? of all peering sessions have nothing behind them more >>than a ?handshake? or an email. It seems I was in error. Mea Culpa. >> >>The number in the paper, on page one is, 99.52%. >> >>Hopefully everyone will read the paper, and perhaps help create better >>data. >> >>-- >>TTFN, >>patrick >> >> > From niels=nanog at bakker.net Sat Feb 13 01:56:14 2016 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 13 Feb 2016 02:56:14 +0100 Subject: PCH Peering Paper In-Reply-To: <56be7b64.c7d20d0a.2857.0327@mx.google.com> References: <56be7b64.c7d20d0a.2857.0327@mx.google.com> Message-ID: <20160213015614.GL3097@excession.tpb.net> * bedard.phil at gmail.com (Phil Bedard) [Sat 13 Feb 2016, 01:40 CET]: >I was going to ask the same thing, since even for settlement free >peering between large content providers and eyeball networks there >are written agreements in place. I would have no clue on the volume >percentage but it's not going to be near 99%. It's much closer to 99% than to 50%, though. -- Niels. From nanog at ics-il.net Sat Feb 13 02:58:52 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 12 Feb 2016 20:58:52 -0600 (CST) Subject: Shared cabinet "security" In-Reply-To: Message-ID: <942200992.5161.1455332327631.JavaMail.mhammett@ThunderFuck> There are more options when you're not just using someone else's datacenter. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Bevan Slattery" To: "Mike Hammett" Cc: "North American Network Operators' Group" Sent: Friday, February 12, 2016 4:44:34 PM Subject: Re: Shared cabinet "security" In a past life we worked with our supplier to create physically separate sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable path for interconnects to the meet-me-room and connection to power supplies. Can be done and I think there are now rack suppliers that do this as standard. Been out of DC space for a few years now. [b] > On 13 Feb 2016, at 6:58 AM, Mike Hammett wrote: > > > That moment when you hit send and remember a couple things? > > Of course labeling of the cables. > > Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > To: "North American Network Operators' Group" > Sent: Friday, February 12, 2016 2:53:17 PM > Subject: Re: Shared cabinet "security" > > > I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). > http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx > > It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf > > I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. > > I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. > > I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. > > I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. > > Financial penalty from the violator to the victim if there?s an uh oh? > > I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" > To: "North American Network Operators' Group" > Sent: Wednesday, February 10, 2016 8:59:08 AM > Subject: Shared cabinet "security" > > I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs > > If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. > > Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. > > Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From bevan at slattery.net.au Sat Feb 13 08:36:34 2016 From: bevan at slattery.net.au (Bevan Slattery) Date: Sat, 13 Feb 2016 18:36:34 +1000 Subject: Shared cabinet "security" In-Reply-To: <942200992.5161.1455332327631.JavaMail.mhammett@ThunderFuck> References: <942200992.5161.1455332327631.JavaMail.mhammett@ThunderFuck> Message-ID: <006ABF2D-1558-4781-A160-4B96CEAD81B5@slattery.net.au> Sorry. I'm not sure I get from which angle you are coming at this from. Happy to clarify for you and anyone interested if you can help me out here. Cheers [b] > On 13 Feb 2016, at 12:58 PM, Mike Hammett wrote: > > There are more options when you're not just using someone else's datacenter. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From: "Bevan Slattery" > To: "Mike Hammett" > Cc: "North American Network Operators' Group" > Sent: Friday, February 12, 2016 4:44:34 PM > Subject: Re: Shared cabinet "security" > > In a past life we worked with our supplier to create physically separate sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable path for interconnects to the meet-me-room and connection to power supplies. > > Can be done and I think there are now rack suppliers that do this as standard. Been out of DC space for a few years now. > > [b] > > > On 13 Feb 2016, at 6:58 AM, Mike Hammett wrote: > > > > > > That moment when you hit send and remember a couple things? > > > > Of course labeling of the cables. > > > > Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Mike Hammett" > > To: "North American Network Operators' Group" > > Sent: Friday, February 12, 2016 2:53:17 PM > > Subject: Re: Shared cabinet "security" > > > > > > I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). > > http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx > > > > It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf > > > > I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. > > > > I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. > > > > I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. > > > > I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. > > > > Financial penalty from the violator to the victim if there?s an uh oh? > > > > I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Mike Hammett" > > To: "North American Network Operators' Group" > > Sent: Wednesday, February 10, 2016 8:59:08 AM > > Subject: Shared cabinet "security" > > > > I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs > > > > If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. > > > > Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. > > > > Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > > From chris at aperturefiber.com Sat Feb 13 12:24:45 2016 From: chris at aperturefiber.com (Chris Garrett) Date: Sat, 13 Feb 2016 07:24:45 -0500 Subject: Xfinity stale DNS Message-ID: An inadvertent DNS change was made on one of our domains yesterday. While the rest of the ISP world seems to be working correctly after propagation for the fix, I can not get Comcast / Xfinity to clear the stale records. Anyone have suggestions or experience in moving them along? From joe at nethead.com Sat Feb 13 06:22:02 2016 From: joe at nethead.com (Joe Hamelin) Date: Fri, 12 Feb 2016 22:22:02 -0800 Subject: Shared cabinet "security" In-Reply-To: <942200992.5161.1455332327631.JavaMail.mhammett@ThunderFuck> References: <942200992.5161.1455332327631.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, Feb 12, 2016 at 6:58 PM, Mike Hammett wrote: > There are more options when you're not just using someone else's > datacenter. Indeed, paying for and maintaining your own generator and UPS system, digging up streets for diverse network paths if you can get a CLEC to play with you, twenty-four hour security and personnel logging, buying and installing your own environmental conditioning. All just for a half rack of kit. Please, tell me about those options. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 > From nanog at ics-il.net Sat Feb 13 14:05:43 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 13 Feb 2016 08:05:43 -0600 (CST) Subject: Shared cabinet "security" In-Reply-To: <006ABF2D-1558-4781-A160-4B96CEAD81B5@slattery.net.au> Message-ID: <1782786436.5403.1455372341540.JavaMail.mhammett@ThunderFuck> Getting a cabinet in someone else's datacenter (Equinix, Coresite, Telx, etc.) and having sub-tenants. Most networks aren't going to need more than a handful of U in a datacenter, but the more significant the datacenter, the less likely they are to provide partial cabinets... which makes no sense. Sure, some networks need large chassis routers chewing up 10U - 20U, but there are far more networks that need routers that take up 1U, 2U, something like that. For many networks, the sheer cost of the space in the datacenter doubles their overall cost per megabit. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Bevan Slattery" To: "Mike Hammett" Cc: "North American Network Operators' Group" Sent: Saturday, February 13, 2016 2:36:34 AM Subject: Re: Shared cabinet "security" Sorry. I'm not sure I get from which angle you are coming at this from. Happy to clarify for you and anyone interested if you can help me out here. Cheers [b] On 13 Feb 2016, at 12:58 PM, Mike Hammett < nanog at ics-il.net > wrote: There are more options when you're not just using someone else's datacenter. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Bevan Slattery" < bevan at slattery.net.au > To: "Mike Hammett" < nanog at ics-il.net > Cc: "North American Network Operators' Group" < nanog at nanog.org > Sent: Friday, February 12, 2016 4:44:34 PM Subject: Re: Shared cabinet "security" In a past life we worked with our supplier to create physically separate sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable path for interconnects to the meet-me-room and connection to power supplies. Can be done and I think there are now rack suppliers that do this as standard. Been out of DC space for a few years now. [b] > On 13 Feb 2016, at 6:58 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > That moment when you hit send and remember a couple things? > > Of course labeling of the cables. > > Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" < nanog at ics-il.net > > To: "North American Network Operators' Group" < nanog at nanog.org > > Sent: Friday, February 12, 2016 2:53:17 PM > Subject: Re: Shared cabinet "security" > > > I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). > http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx > > It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf > > I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. > > I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. > > I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. > > I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. > > Financial penalty from the violator to the victim if there?s an uh oh? > > I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" < nanog at ics-il.net > > To: "North American Network Operators' Group" < nanog at nanog.org > > Sent: Wednesday, February 10, 2016 8:59:08 AM > Subject: Shared cabinet "security" > > I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs > > If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. > > Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. > > Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From chris at aperturefiber.com Sat Feb 13 14:39:59 2016 From: chris at aperturefiber.com (Chris Garrett) Date: Sat, 13 Feb 2016 09:39:59 -0500 Subject: Xfinity stale DNS In-Reply-To: References: Message-ID: This was sorted in record time. Thank you both very much! > On Feb 13, 2016, at 7:26 AM, Chris Garrett wrote: > > An inadvertent DNS change was made on one of our domains yesterday. While the rest of the ISP world seems to be working correctly after propagation for the fix, I can not get Comcast / Xfinity to clear the stale records. > > Anyone have suggestions or experience in moving them along? > > From nanog at ics-il.net Sat Feb 13 16:25:20 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 13 Feb 2016 10:25:20 -0600 (CST) Subject: Shared cabinet "security" In-Reply-To: Message-ID: <1035275523.5529.1455380718965.JavaMail.mhammett@ThunderFuck> Right, but that doesn't limit one's ability (intentional or not) to pull out the wrong power cord or smack someone's loosely ran cables, etc. We're sorting out some standards now and I think it'll largely involve color coding, wire looms, horizontal cable management and a "cabinet practices" document defining standards for use in the cabinet. This is meant to protect customers from themselves and each other. IE: Someone is removing a power cable and the pull the wrong one out of the PDU. Maybe they pull the right one out of the PDU, but it's wrapped around someone else's power cable and theirs gets pulled out along the way. Stuff like that. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Greg Sowell" To: "Mike Hammett" Cc: "NANOG list" Sent: Saturday, February 13, 2016 10:16:17 AM Subject: Re: Shared cabinet "security" Mike, I've seen people use shelves to segregate cabinets. I've seen some that screw from both sides and eat very little space. Greg On Feb 13, 2016 8:07 AM, "Mike Hammett" < nanog at ics-il.net > wrote: Getting a cabinet in someone else's datacenter (Equinix, Coresite, Telx, etc.) and having sub-tenants. Most networks aren't going to need more than a handful of U in a datacenter, but the more significant the datacenter, the less likely they are to provide partial cabinets... which makes no sense. Sure, some networks need large chassis routers chewing up 10U - 20U, but there are far more networks that need routers that take up 1U, 2U, something like that. For many networks, the sheer cost of the space in the datacenter doubles their overall cost per megabit. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Bevan Slattery" < bevan at slattery.net.au > To: "Mike Hammett" < nanog at ics-il.net > Cc: "North American Network Operators' Group" < nanog at nanog.org > Sent: Saturday, February 13, 2016 2:36:34 AM Subject: Re: Shared cabinet "security" Sorry. I'm not sure I get from which angle you are coming at this from. Happy to clarify for you and anyone interested if you can help me out here. Cheers [b] On 13 Feb 2016, at 12:58 PM, Mike Hammett < nanog at ics-il.net > wrote: There are more options when you're not just using someone else's datacenter. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Bevan Slattery" < bevan at slattery.net.au > To: "Mike Hammett" < nanog at ics-il.net > Cc: "North American Network Operators' Group" < nanog at nanog.org > Sent: Friday, February 12, 2016 4:44:34 PM Subject: Re: Shared cabinet "security" In a past life we worked with our supplier to create physically separate sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable path for interconnects to the meet-me-room and connection to power supplies. Can be done and I think there are now rack suppliers that do this as standard. Been out of DC space for a few years now. [b] > On 13 Feb 2016, at 6:58 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > That moment when you hit send and remember a couple things? > > Of course labeling of the cables. > > Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" < nanog at ics-il.net > > To: "North American Network Operators' Group" < nanog at nanog.org > > Sent: Friday, February 12, 2016 2:53:17 PM > Subject: Re: Shared cabinet "security" > > > I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). > http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx > > It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf > > I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. > > I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. > > I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. > > I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. > > Financial penalty from the violator to the victim if there?s an uh oh? > > I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mike Hammett" < nanog at ics-il.net > > To: "North American Network Operators' Group" < nanog at nanog.org > > Sent: Wednesday, February 10, 2016 8:59:08 AM > Subject: Shared cabinet "security" > > I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs > > If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. > > Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. > > Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From jason at unlimitednet.us Sat Feb 13 16:30:21 2016 From: jason at unlimitednet.us (Jason Canady) Date: Sat, 13 Feb 2016 11:30:21 -0500 Subject: Shared cabinet "security" In-Reply-To: <1035275523.5529.1455380718965.JavaMail.mhammett@ThunderFuck> References: <1035275523.5529.1455380718965.JavaMail.mhammett@ThunderFuck> Message-ID: <56BF5A1D.8070904@unlimitednet.us> Mike, Are you leasing a full cabinet and sub-leasing out portions of it? Not sure how you can define what other customers do, unless they're your customers. Split cabinets are ideal, as you the sections are compartmentalized. -- Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure www.unlimitednet.us jason at unlimitednet.us twitter: @unlimitednet On 2/13/16 11:25 AM, Mike Hammett wrote: > Right, but that doesn't limit one's ability (intentional or not) to pull out the wrong power cord or smack someone's loosely ran cables, etc. We're sorting out some standards now and I think it'll largely involve color coding, wire looms, horizontal cable management and a "cabinet practices" document defining standards for use in the cabinet. This is meant to protect customers from themselves and each other. > > IE: Someone is removing a power cable and the pull the wrong one out of the PDU. Maybe they pull the right one out of the PDU, but it's wrapped around someone else's power cable and theirs gets pulled out along the way. Stuff like that. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Greg Sowell" > To: "Mike Hammett" > Cc: "NANOG list" > Sent: Saturday, February 13, 2016 10:16:17 AM > Subject: Re: Shared cabinet "security" > > > Mike, > I've seen people use shelves to segregate cabinets. I've seen some that screw from both sides and eat very little space. > Greg > On Feb 13, 2016 8:07 AM, "Mike Hammett" < nanog at ics-il.net > wrote: > > > Getting a cabinet in someone else's datacenter (Equinix, Coresite, Telx, etc.) and having sub-tenants. Most networks aren't going to need more than a handful of U in a datacenter, but the more significant the datacenter, the less likely they are to provide partial cabinets... which makes no sense. Sure, some networks need large chassis routers chewing up 10U - 20U, but there are far more networks that need routers that take up 1U, 2U, something like that. For many networks, the sheer cost of the space in the datacenter doubles their overall cost per megabit. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Bevan Slattery" < bevan at slattery.net.au > > To: "Mike Hammett" < nanog at ics-il.net > > Cc: "North American Network Operators' Group" < nanog at nanog.org > > Sent: Saturday, February 13, 2016 2:36:34 AM > Subject: Re: Shared cabinet "security" > > > Sorry. I'm not sure I get from which angle you are coming at this from. Happy to clarify for you and anyone interested if you can help me out here. > > > Cheers > > [b] > > On 13 Feb 2016, at 12:58 PM, Mike Hammett < nanog at ics-il.net > wrote: > > > > > > There are more options when you're not just using someone else's datacenter. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Bevan Slattery" < bevan at slattery.net.au > > To: "Mike Hammett" < nanog at ics-il.net > > Cc: "North American Network Operators' Group" < nanog at nanog.org > > Sent: Friday, February 12, 2016 4:44:34 PM > Subject: Re: Shared cabinet "security" > > In a past life we worked with our supplier to create physically separate sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable path for interconnects to the meet-me-room and connection to power supplies. > > Can be done and I think there are now rack suppliers that do this as standard. Been out of DC space for a few years now. > > [b] > >> On 13 Feb 2016, at 6:58 AM, Mike Hammett < nanog at ics-il.net > wrote: >> >> >> That moment when you hit send and remember a couple things? >> >> Of course labeling of the cables. >> >> Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Mike Hammett" < nanog at ics-il.net > >> To: "North American Network Operators' Group" < nanog at nanog.org > >> Sent: Friday, February 12, 2016 2:53:17 PM >> Subject: Re: Shared cabinet "security" >> >> >> I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). >> http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx >> >> It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf >> >> I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. >> >> I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. >> >> I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. >> >> I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. >> >> Financial penalty from the violator to the victim if there?s an uh oh? >> >> I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Mike Hammett" < nanog at ics-il.net > >> To: "North American Network Operators' Group" < nanog at nanog.org > >> Sent: Wednesday, February 10, 2016 8:59:08 AM >> Subject: Shared cabinet "security" >> >> I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs >> >> If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. >> >> Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. >> >> Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> > > > > > > From nanog at ics-il.net Sat Feb 13 16:35:10 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 13 Feb 2016 10:35:10 -0600 (CST) Subject: Shared cabinet "security" In-Reply-To: <56BF5A1D.8070904@unlimitednet.us> Message-ID: <349167765.5542.1455381310308.JavaMail.mhammett@ThunderFuck> AFAIK, there's no way to securely compartmentalize someone else's rack, which is why I've been going down this road. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jason Canady" To: nanog at nanog.org Sent: Saturday, February 13, 2016 10:30:21 AM Subject: Re: Shared cabinet "security" Mike, Are you leasing a full cabinet and sub-leasing out portions of it? Not sure how you can define what other customers do, unless they're your customers. Split cabinets are ideal, as you the sections are compartmentalized. -- Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure www.unlimitednet.us jason at unlimitednet.us twitter: @unlimitednet On 2/13/16 11:25 AM, Mike Hammett wrote: > Right, but that doesn't limit one's ability (intentional or not) to pull out the wrong power cord or smack someone's loosely ran cables, etc. We're sorting out some standards now and I think it'll largely involve color coding, wire looms, horizontal cable management and a "cabinet practices" document defining standards for use in the cabinet. This is meant to protect customers from themselves and each other. > > IE: Someone is removing a power cable and the pull the wrong one out of the PDU. Maybe they pull the right one out of the PDU, but it's wrapped around someone else's power cable and theirs gets pulled out along the way. Stuff like that. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Greg Sowell" > To: "Mike Hammett" > Cc: "NANOG list" > Sent: Saturday, February 13, 2016 10:16:17 AM > Subject: Re: Shared cabinet "security" > > > Mike, > I've seen people use shelves to segregate cabinets. I've seen some that screw from both sides and eat very little space. > Greg > On Feb 13, 2016 8:07 AM, "Mike Hammett" < nanog at ics-il.net > wrote: > > > Getting a cabinet in someone else's datacenter (Equinix, Coresite, Telx, etc.) and having sub-tenants. Most networks aren't going to need more than a handful of U in a datacenter, but the more significant the datacenter, the less likely they are to provide partial cabinets... which makes no sense. Sure, some networks need large chassis routers chewing up 10U - 20U, but there are far more networks that need routers that take up 1U, 2U, something like that. For many networks, the sheer cost of the space in the datacenter doubles their overall cost per megabit. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Bevan Slattery" < bevan at slattery.net.au > > To: "Mike Hammett" < nanog at ics-il.net > > Cc: "North American Network Operators' Group" < nanog at nanog.org > > Sent: Saturday, February 13, 2016 2:36:34 AM > Subject: Re: Shared cabinet "security" > > > Sorry. I'm not sure I get from which angle you are coming at this from. Happy to clarify for you and anyone interested if you can help me out here. > > > Cheers > > [b] > > On 13 Feb 2016, at 12:58 PM, Mike Hammett < nanog at ics-il.net > wrote: > > > > > > There are more options when you're not just using someone else's datacenter. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Bevan Slattery" < bevan at slattery.net.au > > To: "Mike Hammett" < nanog at ics-il.net > > Cc: "North American Network Operators' Group" < nanog at nanog.org > > Sent: Friday, February 12, 2016 4:44:34 PM > Subject: Re: Shared cabinet "security" > > In a past life we worked with our supplier to create physically separate sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable path for interconnects to the meet-me-room and connection to power supplies. > > Can be done and I think there are now rack suppliers that do this as standard. Been out of DC space for a few years now. > > [b] > >> On 13 Feb 2016, at 6:58 AM, Mike Hammett < nanog at ics-il.net > wrote: >> >> >> That moment when you hit send and remember a couple things? >> >> Of course labeling of the cables. >> >> Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Mike Hammett" < nanog at ics-il.net > >> To: "North American Network Operators' Group" < nanog at nanog.org > >> Sent: Friday, February 12, 2016 2:53:17 PM >> Subject: Re: Shared cabinet "security" >> >> >> I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). >> http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx >> >> It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf >> >> I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. >> >> I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. >> >> I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. >> >> I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. >> >> Financial penalty from the violator to the victim if there?s an uh oh? >> >> I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Mike Hammett" < nanog at ics-il.net > >> To: "North American Network Operators' Group" < nanog at nanog.org > >> Sent: Wednesday, February 10, 2016 8:59:08 AM >> Subject: Shared cabinet "security" >> >> I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs >> >> If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. >> >> Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. >> >> Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> > > > > > > From frnkblk at iname.com Sat Feb 13 21:35:16 2016 From: frnkblk at iname.com (frnkblk at iname.com) Date: Sat, 13 Feb 2016 15:35:16 -0600 Subject: Automated alarm notification In-Reply-To: References: <001c01d16516$6202c690$260853b0$@iname.com> Message-ID: <000001d166a6$70298ab0$507ca010$@iname.com> Thanks, but I don?t see that datadog can ingests SNMP traps ? can you point me in the right direction? Frank From: John Adams [mailto:jna at retina.net] Sent: Thursday, February 11, 2016 5:24 PM To: Frank Bulk Cc: nanog at nanog.org list Subject: Re: Automated alarm notification datadog will do this without issue, and if you have a small number of hosts it's nearly free. -j On Thu, Feb 11, 2016 at 1:51 PM, Frank Bulk > wrote: Is anyone aware of software, or perhaps a service, that will take SNMP traps, properly parse them, and perform the appropriate call outs based on certain content, after waiting 5 or 10 minutes for any alarms that don't clear? I looked at PagerDuty, but they don't do any SNMP trap parsing, and nothing with set/clear. Frank From greg at gregsowell.com Sat Feb 13 16:16:17 2016 From: greg at gregsowell.com (Greg Sowell) Date: Sat, 13 Feb 2016 10:16:17 -0600 Subject: Shared cabinet "security" In-Reply-To: <1782786436.5403.1455372341540.JavaMail.mhammett@ThunderFuck> References: <006ABF2D-1558-4781-A160-4B96CEAD81B5@slattery.net.au> <1782786436.5403.1455372341540.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, I've seen people use shelves to segregate cabinets. I've seen some that screw from both sides and eat very little space. Greg On Feb 13, 2016 8:07 AM, "Mike Hammett" wrote: > Getting a cabinet in someone else's datacenter (Equinix, Coresite, Telx, > etc.) and having sub-tenants. Most networks aren't going to need more than > a handful of U in a datacenter, but the more significant the datacenter, > the less likely they are to provide partial cabinets... which makes no > sense. Sure, some networks need large chassis routers chewing up 10U - 20U, > but there are far more networks that need routers that take up 1U, 2U, > something like that. For many networks, the sheer cost of the space in the > datacenter doubles their overall cost per megabit. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Bevan Slattery" > To: "Mike Hammett" > Cc: "North American Network Operators' Group" > Sent: Saturday, February 13, 2016 2:36:34 AM > Subject: Re: Shared cabinet "security" > > > Sorry. I'm not sure I get from which angle you are coming at this from. > Happy to clarify for you and anyone interested if you can help me out here. > > > Cheers > > [b] > > On 13 Feb 2016, at 12:58 PM, Mike Hammett < nanog at ics-il.net > wrote: > > > > > > There are more options when you're not just using someone else's > datacenter. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Bevan Slattery" < bevan at slattery.net.au > > To: "Mike Hammett" < nanog at ics-il.net > > Cc: "North American Network Operators' Group" < nanog at nanog.org > > Sent: Friday, February 12, 2016 4:44:34 PM > Subject: Re: Shared cabinet "security" > > In a past life we worked with our supplier to create physically separate > sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable > path for interconnects to the meet-me-room and connection to power supplies. > > Can be done and I think there are now rack suppliers that do this as > standard. Been out of DC space for a few years now. > > [b] > > > On 13 Feb 2016, at 6:58 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > > > > That moment when you hit send and remember a couple things? > > > > Of course labeling of the cables. > > > > Maybe colored wire loom for fiber and DACs in the vertical spaces to go > along with the previously mentioned color scheme? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Mike Hammett" < nanog at ics-il.net > > > To: "North American Network Operators' Group" < nanog at nanog.org > > > Sent: Friday, February 12, 2016 2:53:17 PM > > Subject: Re: Shared cabinet "security" > > > > > > I am finding a bunch of covers for the front. I do wish they stuck out > more than an inch (like two). > > > http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx > > > > It looks like these guys stick out 1.5?. That may be workable? > http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf > > > > I guess those covers are really only useful for servers. That really > wouldn?t work with a switch\router. Switches and routers are going to be > the bulk of what we?re dealing with. > > > > I am finding locking power cables, but that seems to be specific to the > PDU you?re using as it requires the other half of the lock on the PDU. > > > > I did come across colored power cords. I wonder with some enforced cable > management, colored power cables, etc. we would have ?good enough?? You get > some 1U or 2U cable organizers, require cables to be secured to the > management, vertical cables in shared spaces are bound together by > customer, color of Velcro matches color of the power cord? Blue customer, > green customer, red customer, etc. Could do the cat6 patch cables that way > too, but that gets lost when moving to glass or DACs. > > > > I thought about a web cam that would record anyone coming into the > cabinet, but Equinix doesn?t really allow pictures in their facilities, so > that?s not going to fly. Door contacts should be helpful for an audit log > of at least when the doors were opened or closed. > > > > Financial penalty from the violator to the victim if there?s an uh oh? > > > > I?m not trying to save someone from themselves. I?m not trying to lock > the whole thing down. Just trying to prevent mistakes in a shared space. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Mike Hammett" < nanog at ics-il.net > > > To: "North American Network Operators' Group" < nanog at nanog.org > > > Sent: Wednesday, February 10, 2016 8:59:08 AM > > Subject: Shared cabinet "security" > > > > I say "security" because I know that in a shared space, nothing is > completely secure. I also know that with enough intent, someone will > accomplish whatever they set out to do regarding breaking something of > someone else's. My concern is mainly towards mitigation of accidents. This > could even apply to a certain degree to things within your own space and > your own careless techs > > > > If you have multiple entities in a shared space, how can you mitigate > the chances of someone doing something (assuming accidentally) to disrupt > your operations? I'm thinking accidentally unplug the wrong power cord, > patch cord, etc. Accidentally power off or reboot the wrong device. > > > > Obviously labels are an easy way to point out to someone that's looking > at the right place at the right time. Some devices have a cage around the > power cord, but some do not. > > > > Any sort of mesh panels you could put on the front\rear of your gear > that you would mount with the same rack screw that holds your gear in? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > > > > > > From jared at compuwizz.net Sat Feb 13 20:12:53 2016 From: jared at compuwizz.net (Jared Geiger) Date: Sat, 13 Feb 2016 12:12:53 -0800 Subject: NTT Charles Message-ID: So who is this Charles fellow in the NTT reverse DNS? ge-102-0-0-0.happy-trails-Charles.r05.asbnva02.us.bb.gin.ntt.net ae-10.happy-trails-Charles.r22.asbnva02.us.bb.gin.ntt.net ae-5.happy-trails-Charles.r25.nycmny01.us.bb.gin.ntt.net ae-2.happy-trails-Charles.r08.nycmny01.us.bb.gin.ntt.net ae-7.happy-trails-Charles.r00.lsanca07.us.bb.gin.ntt.net From rekoil at semihuman.com Sun Feb 14 00:33:04 2016 From: rekoil at semihuman.com (Chris Woodfield) Date: Sat, 13 Feb 2016 16:33:04 -0800 Subject: Shared cabinet "security" In-Reply-To: <942200992.5161.1455332327631.JavaMail.mhammett@ThunderFuck> References: <942200992.5161.1455332327631.JavaMail.mhammett@ThunderFuck> Message-ID: <4F06A3E4-6771-48BC-804F-4302CB8EE9DA@semihuman.com> I've seen colos sell half-racks where both the top and bottoms of the racks have their own cabinet doors. It's not a common thing though. -C > On Feb 12, 2016, at 18:58, Mike Hammett wrote: > > There are more options when you're not just using someone else's datacenter. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Bevan Slattery" > To: "Mike Hammett" > Cc: "North American Network Operators' Group" > Sent: Friday, February 12, 2016 4:44:34 PM > Subject: Re: Shared cabinet "security" > > In a past life we worked with our supplier to create physically separate sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable path for interconnects to the meet-me-room and connection to power supplies. > > Can be done and I think there are now rack suppliers that do this as standard. Been out of DC space for a few years now. > > [b] > >> On 13 Feb 2016, at 6:58 AM, Mike Hammett wrote: >> >> >> That moment when you hit send and remember a couple things? >> >> Of course labeling of the cables. >> >> Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Mike Hammett" >> To: "North American Network Operators' Group" >> Sent: Friday, February 12, 2016 2:53:17 PM >> Subject: Re: Shared cabinet "security" >> >> >> I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). >> http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx >> >> It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf >> >> I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. >> >> I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. >> >> I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. >> >> I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. >> >> Financial penalty from the violator to the victim if there?s an uh oh? >> >> I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Mike Hammett" >> To: "North American Network Operators' Group" >> Sent: Wednesday, February 10, 2016 8:59:08 AM >> Subject: Shared cabinet "security" >> >> I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs >> >> If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. >> >> Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. >> >> Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com > From dorian at blackrose.org Sun Feb 14 11:25:01 2016 From: dorian at blackrose.org (Dorian Kim) Date: Sun, 14 Feb 2016 06:25:01 -0500 Subject: NTT Charles In-Reply-To: References: Message-ID: <363B09D2-A293-48BA-99C9-B18F01AF52A0@blackrose.org> AS2914 has a tradition of bidding farewell to technical team members who move on via router dns record . Charles was one of our NOC engineers. IIRC, we stole this idea from the vBNS team back in the 90s. -dorian > On Feb 13, 2016, at 3:12 PM, Jared Geiger wrote: > > So who is this Charles fellow in the NTT reverse DNS? > > ge-102-0-0-0.happy-trails-Charles.r05.asbnva02.us.bb.gin.ntt.net > > ae-10.happy-trails-Charles.r22.asbnva02.us.bb.gin.ntt.net > > ae-5.happy-trails-Charles.r25.nycmny01.us.bb.gin.ntt.net > > ae-2.happy-trails-Charles.r08.nycmny01.us.bb.gin.ntt.net > > ae-7.happy-trails-Charles.r00.lsanca07.us.bb.gin.ntt.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4115 bytes Desc: not available URL: From tknchris at gmail.com Sun Feb 14 13:44:41 2016 From: tknchris at gmail.com (chris) Date: Sun, 14 Feb 2016 08:44:41 -0500 Subject: Shared cabinet "security" In-Reply-To: <4F06A3E4-6771-48BC-804F-4302CB8EE9DA@semihuman.com> References: <942200992.5161.1455332327631.JavaMail.mhammett@ThunderFuck> <4F06A3E4-6771-48BC-804F-4302CB8EE9DA@semihuman.com> Message-ID: ive seen a bunch of places that use these for shared colo and they seem to work pretty well https://www.racksolutions.com/colocation-cabinet.html chris On Sat, Feb 13, 2016 at 7:33 PM, Chris Woodfield wrote: > I've seen colos sell half-racks where both the top and bottoms of the > racks have their own cabinet doors. It's not a common thing though. > > -C > > > On Feb 12, 2016, at 18:58, Mike Hammett wrote: > > > > There are more options when you're not just using someone else's > datacenter. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Bevan Slattery" > > To: "Mike Hammett" > > Cc: "North American Network Operators' Group" > > Sent: Friday, February 12, 2016 4:44:34 PM > > Subject: Re: Shared cabinet "security" > > > > In a past life we worked with our supplier to create physically separate > sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable > path for interconnects to the meet-me-room and connection to power supplies. > > > > Can be done and I think there are now rack suppliers that do this as > standard. Been out of DC space for a few years now. > > > > [b] > > > >> On 13 Feb 2016, at 6:58 AM, Mike Hammett wrote: > >> > >> > >> That moment when you hit send and remember a couple things? > >> > >> Of course labeling of the cables. > >> > >> Maybe colored wire loom for fiber and DACs in the vertical spaces to go > along with the previously mentioned color scheme? > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> Midwest-IX > >> http://www.midwest-ix.com > >> > >> ----- Original Message ----- > >> > >> From: "Mike Hammett" > >> To: "North American Network Operators' Group" > >> Sent: Friday, February 12, 2016 2:53:17 PM > >> Subject: Re: Shared cabinet "security" > >> > >> > >> I am finding a bunch of covers for the front. I do wish they stuck out > more than an inch (like two). > >> > http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx > >> > >> It looks like these guys stick out 1.5?. That may be workable? > http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf > >> > >> I guess those covers are really only useful for servers. That really > wouldn?t work with a switch\router. Switches and routers are going to be > the bulk of what we?re dealing with. > >> > >> I am finding locking power cables, but that seems to be specific to the > PDU you?re using as it requires the other half of the lock on the PDU. > >> > >> I did come across colored power cords. I wonder with some enforced > cable management, colored power cables, etc. we would have ?good enough?? > You get some 1U or 2U cable organizers, require cables to be secured to the > management, vertical cables in shared spaces are bound together by > customer, color of Velcro matches color of the power cord? Blue customer, > green customer, red customer, etc. Could do the cat6 patch cables that way > too, but that gets lost when moving to glass or DACs. > >> > >> I thought about a web cam that would record anyone coming into the > cabinet, but Equinix doesn?t really allow pictures in their facilities, so > that?s not going to fly. Door contacts should be helpful for an audit log > of at least when the doors were opened or closed. > >> > >> Financial penalty from the violator to the victim if there?s an uh oh? > >> > >> I?m not trying to save someone from themselves. I?m not trying to lock > the whole thing down. Just trying to prevent mistakes in a shared space. > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> Midwest-IX > >> http://www.midwest-ix.com > >> > >> ----- Original Message ----- > >> > >> From: "Mike Hammett" > >> To: "North American Network Operators' Group" > >> Sent: Wednesday, February 10, 2016 8:59:08 AM > >> Subject: Shared cabinet "security" > >> > >> I say "security" because I know that in a shared space, nothing is > completely secure. I also know that with enough intent, someone will > accomplish whatever they set out to do regarding breaking something of > someone else's. My concern is mainly towards mitigation of accidents. This > could even apply to a certain degree to things within your own space and > your own careless techs > >> > >> If you have multiple entities in a shared space, how can you mitigate > the chances of someone doing something (assuming accidentally) to disrupt > your operations? I'm thinking accidentally unplug the wrong power cord, > patch cord, etc. Accidentally power off or reboot the wrong device. > >> > >> Obviously labels are an easy way to point out to someone that's looking > at the right place at the right time. Some devices have a cage around the > power cord, but some do not. > >> > >> Any sort of mesh panels you could put on the front\rear of your gear > that you would mount with the same rack screw that holds your gear in? > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> Midwest-IX > >> http://www.midwest-ix.com > > > From nanog at ics-il.net Sun Feb 14 13:48:57 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 14 Feb 2016 07:48:57 -0600 (CST) Subject: Shared cabinet "security" In-Reply-To: <4F06A3E4-6771-48BC-804F-4302CB8EE9DA@semihuman.com> Message-ID: <62829699.5938.1455457733186.JavaMail.mhammett@ThunderFuck> *nods* I've seen half and third cabinet designs employed in a couple datacenters. I've seen product sheets for quarter and sixth rack (with the sixth introduced in this thread). To me, those seem like ideal cabinets to put in MMRs, which traditionally have full cabinets. By count of networks, there are far more networks that employ routers smaller than say 4U than there are ones that use larger than say 12U. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Chris Woodfield" To: "Mike Hammett" Cc: "Bevan Slattery" , "North American Network Operators' Group" Sent: Saturday, February 13, 2016 6:33:04 PM Subject: Re: Shared cabinet "security" I've seen colos sell half-racks where both the top and bottoms of the racks have their own cabinet doors. It's not a common thing though. -C > On Feb 12, 2016, at 18:58, Mike Hammett wrote: > > There are more options when you're not just using someone else's datacenter. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Bevan Slattery" > To: "Mike Hammett" > Cc: "North American Network Operators' Group" > Sent: Friday, February 12, 2016 4:44:34 PM > Subject: Re: Shared cabinet "security" > > In a past life we worked with our supplier to create physically separate sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable path for interconnects to the meet-me-room and connection to power supplies. > > Can be done and I think there are now rack suppliers that do this as standard. Been out of DC space for a few years now. > > [b] > >> On 13 Feb 2016, at 6:58 AM, Mike Hammett wrote: >> >> >> That moment when you hit send and remember a couple things? >> >> Of course labeling of the cables. >> >> Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Mike Hammett" >> To: "North American Network Operators' Group" >> Sent: Friday, February 12, 2016 2:53:17 PM >> Subject: Re: Shared cabinet "security" >> >> >> I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). >> http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx >> >> It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf >> >> I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. >> >> I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. >> >> I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. >> >> I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. >> >> Financial penalty from the violator to the victim if there?s an uh oh? >> >> I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Mike Hammett" >> To: "North American Network Operators' Group" >> Sent: Wednesday, February 10, 2016 8:59:08 AM >> Subject: Shared cabinet "security" >> >> I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs >> >> If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. >> >> Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. >> >> Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com > From tom at ninjabadger.net Sun Feb 14 20:41:46 2016 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 14 Feb 2016 20:41:46 +0000 Subject: NTT Charles In-Reply-To: References: Message-ID: <56C0E68A.3040307@ninjabadger.net> On 13/02/16 20:12, Jared Geiger wrote: > ge-102-0-0-0.happy-trails-Charles.r05.asbnva02.us.bb.gin.ntt.net *pictures Charles falling off of a building in slow motion* -- Tom From jvanoppen at spectrumnet.us Mon Feb 15 03:51:22 2016 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Mon, 15 Feb 2016 03:51:22 +0000 Subject: NTT Charles In-Reply-To: <363B09D2-A293-48BA-99C9-B18F01AF52A0@blackrose.org> References: <363B09D2-A293-48BA-99C9-B18F01AF52A0@blackrose.org> Message-ID: That is awesome! -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dorian Kim Sent: Sunday, February 14, 2016 3:25 AM To: Jared Geiger Cc: nanog at nanog.org Subject: Re: NTT Charles AS2914 has a tradition of bidding farewell to technical team members who move on via router dns record . Charles was one of our NOC engineers. IIRC, we stole this idea from the vBNS team back in the 90s. -dorian > On Feb 13, 2016, at 3:12 PM, Jared Geiger wrote: > > So who is this Charles fellow in the NTT reverse DNS? > > ge-102-0-0-0.happy-trails-Charles.r05.asbnva02.us.bb.gin.ntt.net > > ae-10.happy-trails-Charles.r22.asbnva02.us.bb.gin.ntt.net > > ae-5.happy-trails-Charles.r25.nycmny01.us.bb.gin.ntt.net > > ae-2.happy-trails-Charles.r08.nycmny01.us.bb.gin.ntt.net > > ae-7.happy-trails-Charles.r00.lsanca07.us.bb.gin.ntt.net From me at anuragbhatia.com Mon Feb 15 08:52:31 2016 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 15 Feb 2016 14:22:31 +0530 Subject: NTT Charles In-Reply-To: <363B09D2-A293-48BA-99C9-B18F01AF52A0@blackrose.org> References: <363B09D2-A293-48BA-99C9-B18F01AF52A0@blackrose.org> Message-ID: Very interesting. For how long does the record stays? :) On Sun, Feb 14, 2016 at 4:55 PM, Dorian Kim wrote: > AS2914 has a tradition of bidding farewell to technical team members who > move on via router dns record . Charles was one of our NOC engineers. > > IIRC, we stole this idea from the vBNS team back in the 90s. > > -dorian > > > > On Feb 13, 2016, at 3:12 PM, Jared Geiger wrote: > > > > So who is this Charles fellow in the NTT reverse DNS? > > > > ge-102-0-0-0.happy-trails-Charles.r05.asbnva02.us.bb.gin.ntt.net > > > > ae-10.happy-trails-Charles.r22.asbnva02.us.bb.gin.ntt.net > > > > ae-5.happy-trails-Charles.r25.nycmny01.us.bb.gin.ntt.net > > > > ae-2.happy-trails-Charles.r08.nycmny01.us.bb.gin.ntt.net > > > > ae-7.happy-trails-Charles.r00.lsanca07.us.bb.gin.ntt.net > > -- Anurag Bhatia anuragbhatia.com From job at instituut.net Mon Feb 15 09:05:18 2016 From: job at instituut.net (Job Snijders) Date: Mon, 15 Feb 2016 10:05:18 +0100 Subject: NTT Charles In-Reply-To: References: <363B09D2-A293-48BA-99C9-B18F01AF52A0@blackrose.org> Message-ID: <20160215090518.GP8233@Vurt.local> On Mon, Feb 15, 2016 at 02:22:31PM +0530, Anurag Bhatia wrote: > Very interesting. For how long does the record stays? :) For about a day. Kind regards, Job From adrian.minta at gmail.com Mon Feb 15 09:05:45 2016 From: adrian.minta at gmail.com (Adrian M) Date: Mon, 15 Feb 2016 11:05:45 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability In-Reply-To: References: <201602100806.9.asa@psirt.cisco.com> <56BB9F5E.5080500@sadiqs.com> Message-ID: Solved ! "Disable Proxy ARP" must be checked on NAT bypass rules (former nat 0). On Thu, Feb 11, 2016 at 3:53 PM, Adrian M wrote: > Be careful, It appears that something is broken with ARP on this release. > We have no ARP on lan interface, and somebody else has a similar problem: > > https://www.reddit.com/r/networking/comments/433kqx/cisco_asa_not_recording_an_arp_entry/ > > > > On Wed, Feb 10, 2016 at 10:36 PM, Sadiq Saif wrote: > >> Update your ASAs folks, this is a critical one. >> >> >> -------- Forwarded Message -------- >> Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and >> IKEv2 Buffer Overflow Vulnerability >> Date: Wed, 10 Feb 2016 08:06:51 -0800 >> From: Cisco Systems Product Security Incident Response Team >> >> Reply-To: psirt at cisco.com >> To: cisco-nsp at puck.nether.net >> CC: psirt at cisco.com >> >> Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer >> Overflow Vulnerability >> >> Advisory ID: cisco-sa-20160210-asa-ike >> >> Revision 1.0 >> >> For Public Release 2016 February 10 16:00 GMT (UTC) >> >> +--------------------------------------------------------------------- >> >> >> Summary >> ======= >> >> A vulnerability in the Internet Key Exchange (IKE) version 1 (v1) and >> IKE version 2 (v2) code of Cisco ASA Software could allow an >> unauthenticated, remote attacker to cause a reload of the affected >> system or to remotely execute code. >> >> The vulnerability is due to a buffer overflow in the affected code area. >> An attacker could exploit this vulnerability by sending crafted UDP >> packets to the affected system. An exploit could allow the attacker to >> execute arbitrary code and obtain full control of the system or to cause >> a reload of the affected system. >> >> Note: Only traffic directed to the affected system can be used to >> exploit this vulnerability. This vulnerability affects systems >> configured in routed firewall mode only and in single or multiple >> context mode. This vulnerability can be triggered by IPv4 and IPv6 >> traffic. >> >> Cisco has released software updates that address this vulnerability. >> This advisory is available at the following link: >> >> http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike >> >> >> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> >> > From adrian.minta at gmail.com Mon Feb 15 12:16:13 2016 From: adrian.minta at gmail.com (Adrian M) Date: Mon, 15 Feb 2016 14:16:13 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability In-Reply-To: <009001d167e6$d0f0dc40$72d294c0$@ipnetworks.it> References: <201602100806.9.asa@psirt.cisco.com> <56BB9F5E.5080500@sadiqs.com> <009001d167e6$d0f0dc40$72d294c0$@ipnetworks.it> Message-ID: In previous release 9.1(6) this line was ok: nat (inside,outside) source static obj-1.0.0.36_32 obj-1.0.0.36_32 destination static obj-1.0.0.36_32 obj-1.0.0.36_32 In 9.1.(7) wasn't working anymore, so the solution was to add *no-proxy-arp *at the end: nat (inside,outside) source static obj-1.0.0.36_32 obj-1.0.0.36_32 destination static obj-1.0.0.36_32 obj-1.0.0.36_32 *no-proxy-arp* On Mon, Feb 15, 2016 at 1:48 PM, Roberto wrote: > Hello, > > > > excuse me for this direct email: but about the > https://www.reddit.com/r/networking/comments/433kqx/cisco_asa_not_recording_an_arp_entry/ > > > > " > > upgraded from 9.0(5) to 9.1(7) > > " > > > > Solved ! > > "Disable Proxy ARP" must be checked on NAT bypass rules (former nat 0). > > > > > > > > are you indicating for example > > that previously on 9.0(5) was: > > nat (inside,outside) source static obj-1.0.0.36_32 obj-1.0.0.36_32 > destination static obj-1.0.0.36_32 obj-1.0.0.36_32 route-lookup > > > > and now on 9.1(7) is: > > nat (inside,outside) source static obj-1.0.0.36_32 obj-1.0.0.36_32 > destination static obj-1.0.0.36_32 obj-1.0.0.36_32 *no-proxy-arp* > route-lookup > > > > > > > > > > > > > > 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 Adrian M > Inviato: luned? 15 febbraio 2016 10.06 > A: nanog at nanog.org > Oggetto: Re: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and > IKEv2 Buffer Overflow Vulnerability > > > > Solved ! > > "Disable Proxy ARP" must be checked on NAT bypass rules (former nat 0). > > > > On Thu, Feb 11, 2016 at 3:53 PM, Adrian M wrote: > > > > > Be careful, It appears that something is broken with ARP on this release. > > > We have no ARP on lan interface, and somebody else has a similar problem: > > > > > > https://www.reddit.com/r/networking/comments/433kqx/cisco_asa_not_reco > > > rding_an_arp_entry/ > > > > > > > > > > > > On Wed, Feb 10, 2016 at 10:36 PM, Sadiq Saif wrote: > > > > > >> Update your ASAs folks, this is a critical one. > > >> > > >> > > >> -------- Forwarded Message -------- > > >> Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 > > >> and > > >> IKEv2 Buffer Overflow Vulnerability > > >> Date: Wed, 10 Feb 2016 08:06:51 -0800 > > >> From: Cisco Systems Product Security Incident Response Team > > >> > > >> Reply-To: psirt at cisco.com > > >> To: cisco-nsp at puck.nether.net > > >> CC: psirt at cisco.com > > >> > > >> Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer > > >> Overflow Vulnerability > > >> > > >> Advisory ID: cisco-sa-20160210-asa-ike > > >> > > >> Revision 1.0 > > >> > > >> For Public Release 2016 February 10 16:00 GMT (UTC) > > >> > > >> +-------------------------------------------------------------------- > > >> +- > > >> > > >> > > >> Summary > > >> ======= > > >> > > >> A vulnerability in the Internet Key Exchange (IKE) version 1 (v1) and > > >> IKE version 2 (v2) code of Cisco ASA Software could allow an > > >> unauthenticated, remote attacker to cause a reload of the affected > > >> system or to remotely execute code. > > >> > > >> The vulnerability is due to a buffer overflow in the affected code area. > > >> An attacker could exploit this vulnerability by sending crafted UDP > > >> packets to the affected system. An exploit could allow the attacker > > >> to execute arbitrary code and obtain full control of the system or to > > >> cause a reload of the affected system. > > >> > > >> Note: Only traffic directed to the affected system can be used to > > >> exploit this vulnerability. This vulnerability affects systems > > >> configured in routed firewall mode only and in single or multiple > > >> context mode. This vulnerability can be triggered by IPv4 and IPv6 > > >> traffic. > > >> > > >> Cisco has released software updates that address this vulnerability. > > >> This advisory is available at the following link: > > >> > > >> http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/ > > >> cisco-sa-20160210-asa-ike > > >> > > >> > > >> > > >> _______________________________________________ > > >> cisco-nsp mailing list cisco-nsp at puck.nether.net > > >> https://puck.nether.net/mailman/listinfo/cisco-nsp > > >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > >> > > >> > > >> > > > > From rdrake at direcpath.com Mon Feb 15 13:00:48 2016 From: rdrake at direcpath.com (Robert Drake) Date: Mon, 15 Feb 2016 08:00:48 -0500 Subject: Automated alarm notification In-Reply-To: <001c01d16516$6202c690$260853b0$@iname.com> References: <001c01d16516$6202c690$260853b0$@iname.com> Message-ID: <38531eb9-fc0c-48c1-bae8-d58a33ff2eb3@direcpath.com> OpenNMS has direct support for SNMP traps and multistage alerting. It's a pain in the ass to setup (depending on what you're doing*) but it's free and very high performance. * if all your MIBS are already supported then 90% of the work is done and it's not so bad. Just setup multistage alerts for 5 and 10 minute intervals depending on if something clears or if someone responds to the alert. They support lots of alert types. SMTP, SMS, voice call, a few ticketing systems, XMPP, twitter and probably more. On 2/11/2016 4:51 PM, Frank Bulk wrote: > Is anyone aware of software, or perhaps a service, that will take SNMP > traps, properly parse them, and perform the appropriate call outs based on > certain content, after waiting 5 or 10 minutes for any alarms that don't > clear? > > I looked at PagerDuty, but they don't do any SNMP trap parsing, and nothing > with set/clear. > > Frank > From rnicklas at verizon.net Sun Feb 14 19:02:07 2016 From: rnicklas at verizon.net (Randolph Nicklas) Date: Sun, 14 Feb 2016 14:02:07 -0500 Subject: NTT Charles In-Reply-To: <363B09D2-A293-48BA-99C9-B18F01AF52A0@blackrose.org> References: <363B09D2-A293-48BA-99C9-B18F01AF52A0@blackrose.org> Message-ID: <4300FC06-8DB8-41D4-BEB6-569CDEAA35A8@verizon.net> vBNS team--I remember them. Randy > On Feb 14, 2016, at 06:25, Dorian Kim wrote: > > AS2914 has a tradition of bidding farewell to technical team members who > move on via router dns record . Charles was one of our NOC engineers. > > IIRC, we stole this idea from the vBNS team back in the 90s. > > -dorian > > >> On Feb 13, 2016, at 3:12 PM, Jared Geiger wrote: >> >> So who is this Charles fellow in the NTT reverse DNS? >> >> ge-102-0-0-0.happy-trails-Charles.r05.asbnva02.us.bb.gin.ntt.net >> >> ae-10.happy-trails-Charles.r22.asbnva02.us.bb.gin.ntt.net >> >> ae-5.happy-trails-Charles.r25.nycmny01.us.bb.gin.ntt.net >> >> ae-2.happy-trails-Charles.r08.nycmny01.us.bb.gin.ntt.net >> >> ae-7.happy-trails-Charles.r00.lsanca07.us.bb.gin.ntt.net > From a.harrowell at gmail.com Mon Feb 15 10:22:37 2016 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Mon, 15 Feb 2016 10:22:37 +0000 Subject: Fiber to the home specialists/consultants? In-Reply-To: References: Message-ID: Diffraction? (i.e. Benoit Felten's company) http://www.diffractionanalysis.com/services/what-we-do On Thu, Feb 11, 2016 at 2:28 PM, Fletcher Kittredge wrote: > Since two asked: Tilson > > > On Wed, Feb 10, 2016 at 8:14 PM, Jeremy Austin wrote: > > > Ditto. > > On Wed, Feb 10, 2016 at 4:04 PM Daniel Rohan wrote: > > > > > Can anyone point me at a firm that does or consults on FTTH from a > > > technical *and* business perspective? > > > > > > Off-list responses would be appreciated. > > > > > > Thanks, > > > > > > Dan > > > > > > > > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 > From ahebert at pubnix.net Mon Feb 15 16:12:12 2016 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 15 Feb 2016 11:12:12 -0500 Subject: Shared cabinet "security" In-Reply-To: <62829699.5938.1455457733186.JavaMail.mhammett@ThunderFuck> References: <62829699.5938.1455457733186.JavaMail.mhammett@ThunderFuck> Message-ID: <56C1F8DC.9000301@pubnix.net> Well In Montreal, QC, CA... You can get Room, Cage, Full, 1/2, 1/4 or 1/8th from Metro Optic. You lose about 1U for the physical separation, but when you only need a few U's for a pair of routers... They also have connections with a local rack maker that can make you whatever you need. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 02/14/16 08:48, Mike Hammett wrote: > *nods* I've seen half and third cabinet designs employed in a couple datacenters. I've seen product sheets for quarter and sixth rack (with the sixth introduced in this thread). > > To me, those seem like ideal cabinets to put in MMRs, which traditionally have full cabinets. By count of networks, there are far more networks that employ routers smaller than say 4U than there are ones that use larger than say 12U. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Chris Woodfield" > To: "Mike Hammett" > Cc: "Bevan Slattery" , "North American Network Operators' Group" > Sent: Saturday, February 13, 2016 6:33:04 PM > Subject: Re: Shared cabinet "security" > > I've seen colos sell half-racks where both the top and bottoms of the racks have their own cabinet doors. It's not a common thing though. > > -C > >> On Feb 12, 2016, at 18:58, Mike Hammett wrote: >> >> There are more options when you're not just using someone else's datacenter. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Bevan Slattery" >> To: "Mike Hammett" >> Cc: "North American Network Operators' Group" >> Sent: Friday, February 12, 2016 4:44:34 PM >> Subject: Re: Shared cabinet "security" >> >> In a past life we worked with our supplier to create physically separate sub-enclosures.1/2 and 1/3. Able to build in a separate and secure cable path for interconnects to the meet-me-room and connection to power supplies. >> >> Can be done and I think there are now rack suppliers that do this as standard. Been out of DC space for a few years now. >> >> [b] >> >>> On 13 Feb 2016, at 6:58 AM, Mike Hammett wrote: >>> >>> >>> That moment when you hit send and remember a couple things? >>> >>> Of course labeling of the cables. >>> >>> Maybe colored wire loom for fiber and DACs in the vertical spaces to go along with the previously mentioned color scheme? >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> ----- Original Message ----- >>> >>> From: "Mike Hammett" >>> To: "North American Network Operators' Group" >>> Sent: Friday, February 12, 2016 2:53:17 PM >>> Subject: Re: Shared cabinet "security" >>> >>> >>> I am finding a bunch of covers for the front. I do wish they stuck out more than an inch (like two). >>> http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx >>> >>> It looks like these guys stick out 1.5?. That may be workable? http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf >>> >>> I guess those covers are really only useful for servers. That really wouldn?t work with a switch\router. Switches and routers are going to be the bulk of what we?re dealing with. >>> >>> I am finding locking power cables, but that seems to be specific to the PDU you?re using as it requires the other half of the lock on the PDU. >>> >>> I did come across colored power cords. I wonder with some enforced cable management, colored power cables, etc. we would have ?good enough?? You get some 1U or 2U cable organizers, require cables to be secured to the management, vertical cables in shared spaces are bound together by customer, color of Velcro matches color of the power cord? Blue customer, green customer, red customer, etc. Could do the cat6 patch cables that way too, but that gets lost when moving to glass or DACs. >>> >>> I thought about a web cam that would record anyone coming into the cabinet, but Equinix doesn?t really allow pictures in their facilities, so that?s not going to fly. Door contacts should be helpful for an audit log of at least when the doors were opened or closed. >>> >>> Financial penalty from the violator to the victim if there?s an uh oh? >>> >>> I?m not trying to save someone from themselves. I?m not trying to lock the whole thing down. Just trying to prevent mistakes in a shared space. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> ----- Original Message ----- >>> >>> From: "Mike Hammett" >>> To: "North American Network Operators' Group" >>> Sent: Wednesday, February 10, 2016 8:59:08 AM >>> Subject: Shared cabinet "security" >>> >>> I say "security" because I know that in a shared space, nothing is completely secure. I also know that with enough intent, someone will accomplish whatever they set out to do regarding breaking something of someone else's. My concern is mainly towards mitigation of accidents. This could even apply to a certain degree to things within your own space and your own careless techs >>> >>> If you have multiple entities in a shared space, how can you mitigate the chances of someone doing something (assuming accidentally) to disrupt your operations? I'm thinking accidentally unplug the wrong power cord, patch cord, etc. Accidentally power off or reboot the wrong device. >>> >>> Obviously labels are an easy way to point out to someone that's looking at the right place at the right time. Some devices have a cage around the power cord, but some do not. >>> >>> Any sort of mesh panels you could put on the front\rear of your gear that you would mount with the same rack screw that holds your gear in? >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com > From jayhanke at gmail.com Mon Feb 15 22:06:44 2016 From: jayhanke at gmail.com (Jay Hanke) Date: Mon, 15 Feb 2016 16:06:44 -0600 Subject: Mellanox 100GE switches Message-ID: Does anyone have experiences they can share regarding the Mellanox 100GE Ethernet switches? Thanks! Jay From lists at eitanadler.com Mon Feb 15 17:15:30 2016 From: lists at eitanadler.com (Eitan Adler) Date: Mon, 15 Feb 2016 09:15:30 -0800 Subject: Automated alarm notification In-Reply-To: <001c01d16516$6202c690$260853b0$@iname.com> References: <001c01d16516$6202c690$260853b0$@iname.com> Message-ID: On 11 February 2016 at 13:51, Frank Bulk wrote: > Is anyone aware of software, or perhaps a service, that will take SNMP > traps, properly parse them, and perform the appropriate call outs based on > certain content, after waiting 5 or 10 minutes for any alarms that don't > clear? > > I looked at PagerDuty, but they don't do any SNMP trap parsing, and nothing > with set/clear. https://github.com/dropbox/trapperkeeper ? -- Eitan Adler From Jason_Livingood at comcast.com Tue Feb 16 14:49:41 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Tue, 16 Feb 2016 14:49:41 +0000 Subject: PCH Peering Paper In-Reply-To: <20160213015614.GL3097@excession.tpb.net> References: <56be7b64.c7d20d0a.2857.0327@mx.google.com> <20160213015614.GL3097@excession.tpb.net> Message-ID: On 2/12/16, 8:56 PM, "NANOG on behalf of Niels Bakker" wrote: >* bedard.phil at gmail.com (Phil Bedard) [Sat 13 Feb 2016, 01:40 CET]: >>I was going to ask the same thing, since even for settlement free >>peering between large content providers and eyeball networks there >>are written agreements in place. I would have no clue on the volume >>percentage but it's not going to be near 99%. > >It's much closer to 99% than to 50%, though. Any reference on that? I?m wondering who (if anyone) is formally measuring / tracking this and seeing the exact trend over time. Thanks Jason From patrick at ianai.net Tue Feb 16 15:31:07 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 16 Feb 2016 10:31:07 -0500 Subject: PCH Peering Paper In-Reply-To: References: <56be7b64.c7d20d0a.2857.0327@mx.google.com> <20160213015614.GL3097@excession.tpb.net> Message-ID: <9D59779E-4694-4355-B1A6-45A2622B9B79@ianai.net> On Feb 16, 2016, at 9:49 AM, Livingood, Jason wrote: > On 2/12/16, 8:56 PM, "NANOG on behalf of Niels Bakker" > wrote: >> * bedard.phil at gmail.com (Phil Bedard) [Sat 13 Feb 2016, 01:40 CET]: >>> I was going to ask the same thing, since even for settlement free >>> peering between large content providers and eyeball networks there >>> are written agreements in place. I would have no clue on the volume >>> percentage but it's not going to be near 99%. >> >> It's much closer to 99% than to 50%, though. > > Any reference on that? I?m wondering who (if anyone) is formally measuring > / tracking this and seeing the exact trend over time. Niels is in a position to know what his network does. You are in a position to know what your network does. My guess is Comcast requires a contract with everyone, meaning your peering bits are mostly (all?) contracted. I know Akamai does not require a contract, and will only sign if the other side requires it. (This is not a secret.) My guess is they have a lot more un-contracted peering bits than Comcast. However, let?s look at the basic premise here. A handful of networks (50? 100? 200?) on the Internet require contracts with everyone. And if we are being honest with each other, about 5 of those are legacy ?backbone? networks which have not been purchased by a broadband network. The rest are broadband networks guarding their monopoly positions. (Interestingly, broadband networks without monopoly positions to guard do not require contracts.) The other many 1000s of networks do not require contracts to peer. The premise above therefore devolves to: Since most of the traffic is to those networks, then most of the bits flow over contracted peerings. Perhaps ?most? can be argued, but obviously a significant portion of all peering bits flow over contracted sessions. Hopefully we can all agree on that. And let?s also agree there are reasons to have contracts. Peering can require a great deal of time, effort, and money. Peering can require contracts with transport providers, equipment suppliers, colocation facilities, etc. I?m not saying everyone should have a contract for everything. I?m just saying there are good and valid reasons for them, at least sometimes. But saying ?most bits flow over contracts? is not the end of the story. First, look at the three content ?networks? with the most traffic - Google, Netflix, Akamai. All will peer without contracts. All peer at IXes. In fact, all are happy to exchange traffic without even an email to the other network (i.e. route-server peerings). Since these three networks are some of the largest (the largest?) on the planet, it is clear that volume alone does not create the requirement for a contract. Also, let?s take the bottom 10K peering networks. They will not get peering with Comcast, DT, CT, Telstra, FT, etc. Meaning pretty much all their peering bits are over un-contracted sessions. The rest is transit. I guess you could say the bits sent over transit will eventually hit a contracted peering session, since the people in the core contract their sessions. But does that matter to the small guys? In summary, lots of bits flow over contracted peering sessions. But more sessions are not contracted. And lots of bits flow over those non-contracted sessions. Going back to my original post, I was trying to show there are plenty of jobs for peering people who will rarely or even never sign a contract. Plus this is a great place to learn things like capacity planning, BGP, and other technologies required to do peering well. If you are good, you can learn the commercial underpinnings of peering. Then if you are lucky enough to score a job with a legacy ?tier one? which still thinks it is relevant, or a monopolistic broadband company, you can learn contracts after the fact. :) -- TTFN, patrick From tom.kac at gmail.com Tue Feb 16 17:10:00 2016 From: tom.kac at gmail.com (Tom Kacprzynski) Date: Tue, 16 Feb 2016 11:10:00 -0600 Subject: Call for Presentations - CHI-NOG 06 (May 12th) Message-ID: *Call for Presentations* CHI-NOG 06 - (Chicago Network Operators Group) May 12th 2016, Chicago, IL The Chicago Network Operators Group (CHI-NOG) is a vendor neutral organization. Our goal is to create a regional community of network professionals by presenting the latest technology trends, enabling collaboration and providing networking opportunities. CHI-NOG will be hosting its sixth annual conference May 12th, 2016 in downtown Chicago. For more information please see http://chinog.org. The CHI-NOG Program Committee is seeking proposals for presentations on relevant networking technologies with a focus on the following topics: * Network Automation/ DevOps * Interconnection/Peering/Cloud Exchanges * Low Latency Networks/Financial Networks * Network Security * Internet Monitoring * Advanced BGP/MPLS Technologies * Software Defined Networking * Cloud Networking Technologies * Network Operation * Academic Research in Networking and Related Infrastructure Fields * Open Source Networking Tools * Optical Networking/Data Center Interconnect * Data Center Fabric * Wireless * IPv6 *Session Format* Each presentation is 30 minutes, which includes a questions and answers. The duration can be extended per individual request to 60 minutes and will be considered by the program committee. Presentations should not contain any marketing material and should avoid discussion of commercial products but rather focus on the underlying technology. *Key Dates* * Presentation Abstract Submission Deadline ------------------- 3/15/16 * Abstract Selection ---------------------------------------------------- 3/18/16 * Presentation Full Slides Submission Deadline ----------------- 4/15/16 * Final Selection --------------------------------------------------------- 4/29/16 * Conference ------------------------------------------------------------- 5/12/16 *Submission* Please submit presentation?s abstract proposal by filling out the submission form at http://chinog.org/meetings/chi-nog-06/abstract-submission/ . Once your presentation is selected please provide the program committee with your photo and a short bio for web publication. All accepted speakers will receive complimentary tickets to the conference. The program committee is looking forward to your submission and attendance at the conference. From stl at wiredrive.com Tue Feb 16 20:48:33 2016 From: stl at wiredrive.com (Scott Larson) Date: Tue, 16 Feb 2016 12:48:33 -0800 Subject: Mellanox 100GE switches In-Reply-To: References: Message-ID: Have these even hit the channel? We have their previous gen 40/56G gear deployed which has worked really well so I've been interested in the 100G since the announcement last year but the vendors I'd typically be buying from have only relayed that they're not currently able to get one into my hands. They don't even show up in the Mellanox store. *[image: userimage]Scott Larson[image: los angeles] Lead Systems Administrator[image: wdlogo] [image: linkedin] [image: facebook] [image: twitter] [image: instagram] T 310 823 8238 x1106 <310%20823%208238%20x1106> | M 310 904 8818 <310%20904%208818>* On Mon, Feb 15, 2016 at 2:06 PM, Jay Hanke wrote: > Does anyone have experiences they can share regarding the Mellanox > 100GE Ethernet switches? > > Thanks! > > Jay > From fred at web2objects.com Wed Feb 17 16:15:14 2016 From: fred at web2objects.com (Fred Hollis) Date: Wed, 17 Feb 2016 17:15:14 +0100 Subject: Cogent <=> Google Peering issue Message-ID: <56C49C92.1080607@web2objects.com> Anyone else aware of it? From toddunder at gmail.com Wed Feb 17 16:35:38 2016 From: toddunder at gmail.com (Todd Underwood) Date: Wed, 17 Feb 2016 11:35:38 -0500 Subject: Cogent <=> Google Peering issue In-Reply-To: <56C49C92.1080607@web2objects.com> References: <56C49C92.1080607@web2objects.com> Message-ID: Can you scope "issue" with any facts or data? T On Feb 17, 2016 11:16, "Fred Hollis" wrote: > Anyone else aware of it? > From niels=nanog at bakker.net Wed Feb 17 16:45:48 2016 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 17 Feb 2016 17:45:48 +0100 Subject: Cogent <=> Google Peering issue In-Reply-To: References: <56C49C92.1080607@web2objects.com> Message-ID: <20160217164548.GM3097@excession.tpb.net> I googled cogent peering and the first result opened fine -- Niels. * toddunder at gmail.com (Todd Underwood) [Wed 17 Feb 2016, 17:36 CET]: >Can you scope "issue" with any facts or data? > >T >On Feb 17, 2016 11:16, "Fred Hollis" wrote: > >>Anyone else aware of it? >> From nick at foobar.org Wed Feb 17 16:50:34 2016 From: nick at foobar.org (Nick Hilliard) Date: Wed, 17 Feb 2016 16:50:34 +0000 Subject: Cogent <=> Google Peering issue In-Reply-To: References: <56C49C92.1080607@web2objects.com> Message-ID: <56C4A4DA.7030803@foobar.org> Todd Underwood wrote: > Can you scope "issue" with any facts or data? are facts or data strictly necessary on the nanog mailing list? Nick > T > On Feb 17, 2016 11:16, "Fred Hollis" wrote: > >> Anyone else aware of it? >> From deleskie at gmail.com Wed Feb 17 16:54:16 2016 From: deleskie at gmail.com (jim deleskie) Date: Wed, 17 Feb 2016 12:54:16 -0400 Subject: Cogent <=> Google Peering issue In-Reply-To: <56C4A4DA.7030803@foobar.org> References: <56C49C92.1080607@web2objects.com> <56C4A4DA.7030803@foobar.org> Message-ID: They haven't been since at least the mid 90's :) On Wed, Feb 17, 2016 at 12:50 PM, Nick Hilliard wrote: > Todd Underwood wrote: > > Can you scope "issue" with any facts or data? > > are facts or data strictly necessary on the nanog mailing list? > > Nick > > > T > > On Feb 17, 2016 11:16, "Fred Hollis" wrote: > > > >> Anyone else aware of it? > >> > > From toddunder at gmail.com Wed Feb 17 17:29:15 2016 From: toddunder at gmail.com (Todd Underwood) Date: Wed, 17 Feb 2016 12:29:15 -0500 Subject: Cogent <=> Google Peering issue In-Reply-To: References: <56C49C92.1080607@web2objects.com> <56C4A4DA.7030803@foobar.org> Message-ID: let me try to be more concrete and helpful: lots of people who work at google *and* at cogent are on this list. none of them are doing anything to look at anything right now b/c there are no facts in evidence yet. if you want help with something or want to verify something, provide a time, a date, a path, a fact, a traceroute, a flow, a log entry a clue. cheers, t On Wed, Feb 17, 2016 at 11:54 AM, jim deleskie wrote: > They haven't been since at least the mid 90's :) > > On Wed, Feb 17, 2016 at 12:50 PM, Nick Hilliard wrote: >> >> Todd Underwood wrote: >> > Can you scope "issue" with any facts or data? >> >> are facts or data strictly necessary on the nanog mailing list? >> >> Nick >> >> > T >> > On Feb 17, 2016 11:16, "Fred Hollis" wrote: >> > >> >> Anyone else aware of it? >> >> >> > From greg.whynott at gmail.com Tue Feb 16 20:04:55 2016 From: greg.whynott at gmail.com (greg whynott) Date: Tue, 16 Feb 2016 15:04:55 -0500 Subject: RBL resource to check entire netblock Message-ID: Hello, I am wanting to purchase a /22 from one of the online auction sites (Hilco). Before we move ahead with it I wanted to check the history of IPs within the allocation. I find many sites where you can enter 1 IP to do a check but they don't seem to accept subnets to check. Are you aware of any services which could tell us if a /22 is clean or not? my google foo is weak. thank you, greg From shocksofmighty at gmail.com Wed Feb 17 01:54:31 2016 From: shocksofmighty at gmail.com (Paul Paukstelis) Date: Tue, 16 Feb 2016 20:54:31 -0500 Subject: Verizon Fios, WashDC gateway problem Message-ID: <56C3D2D7.7060109@gmail.com> Apologies for a post as a non-expert, but it was suggested that I see if any Verizon techs are reading here and to solicit opinions on fixing a peculiar problem. I noticed about a month ago that all upload traffic from my home router (Fios) to a specific work machine was extremely slow. I first thought it was an issue with the destination NIC, or something with the university gateway. I had normal upload speeds to other destination machines in the same building on the same subnet, etc. Eventually, I swapped IPs on the two machines, and found that the problem had to do with routing to a specific IP, not the destination machine itself. I confirmed first with wireshark that there was packet loss resulting in constant TCP Fast Retransmits when uploading to the affected host IP. traceroute showed that the affected and unaffected traffic went through different Verizon gateways (G1-7-3-5.WASHDC-LCR-22.verizon-gni.net and G0-10-3-4.WASHDC-LCR-21.verizon-gni.net, respectively; I've ultimately found that four different gateways are used depending on the destination IP). mtr confirmed consistent 10% packet loss at G1-7-3-5.WASHDC-LCR-22.verizon-gni.net. This tells me that there is clearly a problem with this device, but I have yet to be able to convince Verizon there is a problem. I thought I might just VPN around it, but as luck would have it the university VPN IP gets routed through the bad gateway. This has to be impacting a significant number of Fios customers in the DC/MD area. 25% of all upload traffic (assuming a normal distribution of destination IPs) gets routed through this bad device. Any thoughts on how to get in touch with someone from Verizon that can help with this or any specific ideas on what this problem might be which I can try to pass along? Thanks. From tecabu at gmail.com Wed Feb 17 07:38:28 2016 From: tecabu at gmail.com (Techs_Maru) Date: Wed, 17 Feb 2016 16:38:28 +0900 Subject: libero.it email admin contact Message-ID: Hi folks, Now, can not sent mail to libero.it by RBL. I requests to removal from blacklist.... I want to contact libero.it mail adminis. or Anyone knows request form? From morrowc.lists at gmail.com Wed Feb 17 18:07:46 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 17 Feb 2016 13:07:46 -0500 Subject: Cogent <=> Google Peering issue In-Reply-To: References: <56C49C92.1080607@web2objects.com> <56C4A4DA.7030803@foobar.org> Message-ID: On Wed, Feb 17, 2016 at 12:29 PM, Todd Underwood wrote: > let me try to be more concrete and helpful: > > lots of people who work at google *and* at cogent are on this list. > none of them are doing anything to look at anything right now b/c > there are no facts in evidence yet. > happy to help or find a local person to help ... > if you want help with something or want to verify something, provide a > time, a date, a path, a fact, a traceroute, a flow, a log entry a > clue. > if there's more data :( > cheers, > > t > > On Wed, Feb 17, 2016 at 11:54 AM, jim deleskie wrote: >> They haven't been since at least the mid 90's :) >> >> On Wed, Feb 17, 2016 at 12:50 PM, Nick Hilliard wrote: >>> >>> Todd Underwood wrote: >>> > Can you scope "issue" with any facts or data? >>> >>> are facts or data strictly necessary on the nanog mailing list? >>> >>> Nick >>> >>> > T >>> > On Feb 17, 2016 11:16, "Fred Hollis" wrote: >>> > >>> >> Anyone else aware of it? >>> >> >>> >> From bernd.spiess at ip-it.com Wed Feb 17 18:25:27 2016 From: bernd.spiess at ip-it.com (Bernd Spiess) Date: Wed, 17 Feb 2016 18:25:27 +0000 Subject: AW: RBL resource to check entire netblock In-Reply-To: References: Message-ID: <6b3ffd9949784e80a0733dd690e66ca2@exchange.ip-it.com> > I find many sites where you can enter 1 IP to > do a check but they don't seem to accept subnets to check. Maybe this is a help? https://www.senderbase.org/ Bernd -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5411 bytes Desc: not available URL: From greg.whynott at gmail.com Wed Feb 17 18:34:22 2016 From: greg.whynott at gmail.com (greg whynott) Date: Wed, 17 Feb 2016 13:34:22 -0500 Subject: RBL resource to check entire netblock In-Reply-To: <6b3ffd9949784e80a0733dd690e66ca2@exchange.ip-it.com> References: <6b3ffd9949784e80a0733dd690e66ca2@exchange.ip-it.com> Message-ID: Thank you everyone for the responses, I now have about 10 options to look at due to the many replies. greg On Wed, Feb 17, 2016 at 1:25 PM, Bernd Spiess wrote: > > I find many sites where you can enter 1 IP to > > do a check but they don't seem to accept subnets to check. > > Maybe this is a help? > https://www.senderbase.org/ > > Bernd > From ralvarado at anycast.cl Wed Feb 17 18:32:27 2016 From: ralvarado at anycast.cl (Roberto Alvarado) Date: Wed, 17 Feb 2016 15:32:27 -0300 Subject: RBL resource to check entire netblock In-Reply-To: <6b3ffd9949784e80a0733dd690e66ca2@exchange.ip-it.com> References: <6b3ffd9949784e80a0733dd690e66ca2@exchange.ip-it.com> Message-ID: <63B58448-7F9C-4BE0-86F7-6AA5D5D107E0@anycast.cl> You can try this script: https://github.com/DjinnS/check-rbl -i,--ip The IP or subnet to check I?m using it to check my subnets Roberto > On Feb 17, 2016, at 15:25, Bernd Spiess wrote: > >> I find many sites where you can enter 1 IP to >> do a check but they don't seem to accept subnets to check. > > Maybe this is a help? > https://www.senderbase.org/ > > Bernd From shocksofmighty at gmail.com Wed Feb 17 19:35:07 2016 From: shocksofmighty at gmail.com (Paul Paukstelis) Date: Wed, 17 Feb 2016 14:35:07 -0500 Subject: Verizon Fios, WashDC gateway problem In-Reply-To: References: <56C3D2D7.7060109@gmail.com> Message-ID: <56C4CB6B.1070705@gmail.com> I avoided posting traceroute initially after reading the FAQ, but this seems like a case where it can help in diagnostics. Loss starts at the affected device (hop 3) and persists. See mtr report for affected and unaffected gateways: Host Loss% Snt Last Avg Best Wrst StDev 1. Wireless_Broadband_Router.home 0.0% 673 0.5 0.5 0.4 0.6 0.0 2. L100.WASHDC-VFTTP-123.verizon-gni.net 0.0% 673 6.5 8.1 3.7 90.1 9.6 3. G1-7-3-5.WASHDC-LCR-22.verizon-gni.net 11.2% 673 8.2 8.7 5.1 15.8 1.6 4. ??? 5. 0.ae4.BR2.IAD8.ALTER.NET 10.4% 673 9.0 8.0 5.4 22.1 1.4 6. be3018.ccr41.iad02.atlas.cogentco.com 10.3% 673 7.1 8.2 5.9 15.3 1.2 7. 38.122.63.54 12.3% 673 7.0 8.4 6.2 29.3 2.8 8. ae3-asbnvacyj41.lightower.net 9.4% 672 7.1 8.3 5.8 32.0 2.2 9. 172.85.52.94.lightower.net 10.7% 672 10.0 9.6 7.5 14.3 1.0 10. te1-4.css-fw-r1.net.umd.edu 11.0% 672 12.2 14.8 7.6 287.2 27.2 11. gi6-6.ptx-core-r1.net.umd.edu 7.9% 672 10.5 11.0 7.8 340.5 15.2 12. gi3-2.ptx-dual-r1.net.umd.edu 9.7% 672 11.9 13.1 8.3 265.6 14.3 13. 129.2.168.3 12.6% 672 11.2 10.9 8.5 188.4 7.7 Host Loss% Snt Last Avg Best Wrst StDev 1. Wireless_Broadband_Router.home 0.0% 287 0.5 0.5 0.5 1.2 0.1 2. L100.WASHDC-VFTTP-123.verizon-gni.net 0.0% 287 6.6 14.9 3.7 148.3 22.8 3. G0-10-3-4.WASHDC-LCR-21.verizon-gni.ne 0.0% 287 9.4 14.9 5.3 97.2 19.1 4. ??? 5. 0.ae3.BR2.IAD8.ALTER.NET 0.0% 287 7.8 13.6 5.7 93.6 17.7 6. be3018.ccr41.iad02.atlas.cogentco.com 0.0% 287 8.1 14.0 6.0 94.1 18.5 7. 38.122.63.54 0.0% 287 9.7 15.5 6.0 97.1 19.1 8. ae3-asbnvacyj41.lightower.net 0.0% 287 9.4 16.4 5.9 95.7 19.6 9. 172.85.52.94.lightower.net 0.0% 287 9.1 19.0 7.7 99.7 22.6 10. te1-4.css-fw-r1.net.umd.edu 0.0% 287 9.4 23.9 7.7 269.8 35.7 11. gi6-6.ptx-core-r1.net.umd.edu 0.0% 287 10.7 18.2 8.2 100.4 20.6 12. gi3-2.ptx-dual-r1.net.umd.edu 0.0% 287 12.2 20.5 8.5 172.2 23.7 13. 129.2.168.2 0.0% 287 11.1 16.4 7.7 95.8 19.3 On 02/17/2016 02:14 PM, chris wrote: > packet loss in the middle of the path means nothing if you have no > loss at the destination. do you see packet loss on the last mtr hop > which is your destination machine? > > On Tue, Feb 16, 2016 at 8:54 PM, Paul Paukstelis > > wrote: > > Apologies for a post as a non-expert, but it was suggested that I > see if any Verizon techs are reading here and to solicit opinions > on fixing a peculiar problem. > > I noticed about a month ago that all upload traffic from my home > router (Fios) to a specific work machine was extremely slow. I > first thought it was an issue with the destination NIC, or > something with the university gateway. I had normal upload speeds > to other destination machines in the same building on the same > subnet, etc. Eventually, I swapped IPs on the two machines, and > found that the problem had to do with routing to a specific IP, > not the destination machine itself. I confirmed first with > wireshark that there was packet loss resulting in constant TCP > Fast Retransmits when uploading to the affected host IP. > traceroute showed that the affected and unaffected traffic went > through different Verizon gateways > (G1-7-3-5.WASHDC-LCR-22.verizon-gni.net > and > G0-10-3-4.WASHDC-LCR-21.verizon-gni.net > , respectively; > I've ultimately found that four different gateways are used > depending on the destination IP). mtr confirmed consistent 10% > packet loss at G1-7-3-5.WASHDC-LCR-22.verizon-gni.net > . This tells me > that there is clearly a problem with this device, but I have yet > to be able to convince Verizon there is a problem. I thought I > might just VPN around it, but as luck would have it the university > VPN IP gets routed through the bad gateway. This has to be > impacting a significant number of Fios customers in the DC/MD > area. 25% of all upload traffic (assuming a normal distribution of > destination IPs) gets routed through this bad device. > > Any thoughts on how to get in touch with someone from Verizon that > can help with this or any specific ideas on what this problem > might be which I can try to pass along? > > Thanks. > > From randy at psg.com Wed Feb 17 20:45:53 2016 From: randy at psg.com (Randy Bush) Date: Thu, 18 Feb 2016 09:45:53 +1300 Subject: Cogent <=> Google Peering issue In-Reply-To: References: <56C49C92.1080607@web2objects.com> <56C4A4DA.7030803@foobar.org> Message-ID: > if there's more data :( randpkt -t bgp - From octalnanog at alvarezp.org Wed Feb 17 20:47:56 2016 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Wed, 17 Feb 2016 12:47:56 -0800 Subject: Looking for docs on "A" RR duality of functions Message-ID: <56C4DC7C.9070209@alvarezp.org> Hi. Do you know if there are any docs (RFC, drafts, independent...) that study the tricks being done with the A/AAAA RRs? What I mean is that it is currently being used not only to resolve the IP address of a hostname, but for load-balancing as well, the case being that the hostname is not just a "host"-name anymore, but a "service"-name (?) so to speak. I'd like to know if somebody else has gone deeper into this and if there are related documents on the matter. Thanks. From I.Smith at F5.com Wed Feb 17 21:10:13 2016 From: I.Smith at F5.com (Ian Smith) Date: Wed, 17 Feb 2016 21:10:13 +0000 Subject: Looking for docs on "A" RR duality of functions In-Reply-To: <56C4DC7C.9070209@alvarezp.org> References: <56C4DC7C.9070209@alvarezp.org> Message-ID: <4468f3a3e9174e8da3604b66e07a4679@SEAEXCHMBX04.olympus.F5Net.com> Is rfc7553 what you are looking for? https://www.rfc-editor.org/info/rfc7553 From maxtul at netassist.ua Wed Feb 17 21:35:23 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 17 Feb 2016 23:35:23 +0200 Subject: Cogent <=> Google Peering issue In-Reply-To: <56C49C92.1080607@web2objects.com> References: <56C49C92.1080607@web2objects.com> Message-ID: <56C4E79B.8060908@netassist.ua> If my telepathy still works fine and I understood your question well - then the answer is "NO, that is not a global well-known issue" ;) On 17.02.16 18:15, Fred Hollis wrote: > Anyone else aware of it? > From owen at delong.com Wed Feb 17 22:04:24 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Feb 2016 14:04:24 -0800 Subject: PCH Peering Paper In-Reply-To: <9D59779E-4694-4355-B1A6-45A2622B9B79@ianai.net> References: <56be7b64.c7d20d0a.2857.0327@mx.google.com> <20160213015614.GL3097@excession.tpb.net> <9D59779E-4694-4355-B1A6-45A2622B9B79@ianai.net> Message-ID: <83521751-AA40-49CF-91C6-FF92A41C7342@delong.com> > The premise above therefore devolves to: Since most of the traffic is to those networks, then most of the bits flow over contracted peerings. > > Perhaps ?most? can be argued, but obviously a significant portion of all peering bits flow over contracted sessions. Hopefully we can all agree on that. There?s greater complexity here, however? Many of the bits that flow flow over several networks between their source and destination. Likely the vast majority of bits traverse at least 3 autonomous systems in the process. So when you want to count traffic that went over a non-contract peering session vs. traffic that went over a contract peering session, how do you count traffic that traverses some of each? Owen From woody at pch.net Wed Feb 17 22:09:49 2016 From: woody at pch.net (Bill Woodcock) Date: Wed, 17 Feb 2016 14:09:49 -0800 Subject: PCH Peering Paper In-Reply-To: <83521751-AA40-49CF-91C6-FF92A41C7342@delong.com> References: <56be7b64.c7d20d0a.2857.0327@mx.google.com> <20160213015614.GL3097@excession.tpb.net> <9D59779E-4694-4355-B1A6-45A2622B9B79@ianai.net> <83521751-AA40-49CF-91C6-FF92A41C7342@delong.com> Message-ID: Each bit traverses only one peering session, however, at the "top of its trajectory" to use a physical metaphor. The uphill and downhill sides are all transit. -Bill > On Feb 17, 2016, at 14:06, Owen DeLong wrote: > > >> The premise above therefore devolves to: Since most of the traffic is to those networks, then most of the bits flow over contracted peerings. >> >> Perhaps ?most? can be argued, but obviously a significant portion of all peering bits flow over contracted sessions. Hopefully we can all agree on that. > > There?s greater complexity here, however? > > Many of the bits that flow flow over several networks between their source and destination. Likely the vast majority of bits traverse at least 3 autonomous systems in the process. > > So when you want to count traffic that went over a non-contract peering session vs. traffic that went over a contract peering session, how do you count traffic that traverses some of each? > > Owen > From patrick at ianai.net Wed Feb 17 22:47:28 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 17 Feb 2016 17:47:28 -0500 Subject: PCH Peering Paper In-Reply-To: <83521751-AA40-49CF-91C6-FF92A41C7342@delong.com> References: <56be7b64.c7d20d0a.2857.0327@mx.google.com> <20160213015614.GL3097@excession.tpb.net> <9D59779E-4694-4355-B1A6-45A2622B9B79@ianai.net> <83521751-AA40-49CF-91C6-FF92A41C7342@delong.com> Message-ID: <95AE3303-50B2-4C2B-9795-E86EEE71B6FA@ianai.net> > On Feb 17, 2016, at 5:04 PM, Owen DeLong wrote: > > >> The premise above therefore devolves to: Since most of the traffic is to those networks, then most of the bits flow over contracted peerings. >> >> Perhaps ?most? can be argued, but obviously a significant portion of all peering bits flow over contracted sessions. Hopefully we can all agree on that. > > There?s greater complexity here, however? > > Many of the bits that flow flow over several networks between their source and destination. Likely the vast majority of bits traverse at least 3 autonomous systems in the process. > > So when you want to count traffic that went over a non-contract peering session vs. traffic that went over a contract peering session, how do you count traffic that traverses some of each? Lower in my post: On Feb 16, 2016, at 10:31 AM, Patrick W. Gilmore wrote: > I guess you could say the bits sent over transit will eventually hit a contracted peering session, since the people in the core contract their sessions. But does that matter to the small guys? -- TTFN, patrick From nanog at ics-il.net Wed Feb 17 23:09:46 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 17 Feb 2016 17:09:46 -0600 (CST) Subject: Equinix Chicago Cross COnnects In-Reply-To: <987903879.3142.1455750379860.JavaMail.mhammett@ThunderFuck> Message-ID: <2010464513.3152.1455750583864.JavaMail.mhammett@ThunderFuck> Yes, another post in this ballpark. I am remembering someone telling me that cross connects from CH3 (Elk Grove Village) to CH1, CH2 or CH4 were not raw glass, but some sort of transport. I lose the details, whether it was wave transport, MPLS or something. I remember the speed of the connection mattering. My Equinix rep tells me that there is no difference from one to the other. I take that to mean that I could put my own wave system on the glass and be fine. I just have a very hard time believing them, based on what I remember and the fact that they've giving me a 25 - 30 mile pair of glass for $350/month. I was hoping to see if anyone else had any experience in this department. Equinix Cermak apparently today has zero available cabinets of any kind in CH1, CH2 or CH4. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From owen at delong.com Thu Feb 18 00:18:53 2016 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Feb 2016 16:18:53 -0800 Subject: PCH Peering Paper In-Reply-To: References: <56be7b64.c7d20d0a.2857.0327@mx.google.com> <20160213015614.GL3097@excession.tpb.net> <9D59779E-4694-4355-B1A6-45A2622B9B79@ianai.net> <83521751-AA40-49CF-91C6-FF92A41C7342@delong.com> Message-ID: <17E253F6-31B9-4394-8DB9-2A3B29D11FE4@delong.com> This assumes that there are no cooperatives providing settlement free peering which includes both peer and transit routes. Owen > On Feb 17, 2016, at 14:09 , Bill Woodcock wrote: > > Each bit traverses only one peering session, however, at the "top of its trajectory" to use a physical metaphor. The uphill and downhill sides are all transit. > > > -Bill > > >> On Feb 17, 2016, at 14:06, Owen DeLong wrote: >> >> >>> The premise above therefore devolves to: Since most of the traffic is to those networks, then most of the bits flow over contracted peerings. >>> >>> Perhaps ?most? can be argued, but obviously a significant portion of all peering bits flow over contracted sessions. Hopefully we can all agree on that. >> >> There?s greater complexity here, however? >> >> Many of the bits that flow flow over several networks between their source and destination. Likely the vast majority of bits traverse at least 3 autonomous systems in the process. >> >> So when you want to count traffic that went over a non-contract peering session vs. traffic that went over a contract peering session, how do you count traffic that traverses some of each? >> >> Owen >> From damien at supremebytes.com Thu Feb 18 06:01:44 2016 From: damien at supremebytes.com (Damien Burke) Date: Thu, 18 Feb 2016 06:01:44 +0000 Subject: Cogent <=> Google Peering issue In-Reply-To: <56C4E79B.8060908@netassist.ua> References: <56C49C92.1080607@web2objects.com> <56C4E79B.8060908@netassist.ua> Message-ID: <2FD50E6D13594B4C93B743BFCF9F52843D0B047B@EXCH01.sb.local> I am currently having a issue with cogent and google over ipv6. My traceroute seems to hit cogent, Verizon, and then just dies. I have a case open with both and each tells me the other is working on it. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev Sent: Wednesday, February 17, 2016 1:35 PM To: nanog at nanog.org Subject: Re: Cogent <=> Google Peering issue If my telepathy still works fine and I understood your question well - then the answer is "NO, that is not a global well-known issue" ;) On 17.02.16 18:15, Fred Hollis wrote: > Anyone else aware of it? > From fred at web2objects.com Thu Feb 18 06:24:34 2016 From: fred at web2objects.com (Fred Hollis) Date: Thu, 18 Feb 2016 07:24:34 +0100 Subject: Cogent <=> Google Peering issue In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F52843D0B047B@EXCH01.sb.local> References: <56C49C92.1080607@web2objects.com> <56C4E79B.8060908@netassist.ua> <2FD50E6D13594B4C93B743BFCF9F52843D0B047B@EXCH01.sb.local> Message-ID: <56C563A2.5090902@web2objects.com> Yes, it's a global Cogent problem. We are in contact with them as well and were told that they're aware of that but can't do anything about it on their own. > Dear Cogent Customer, > > Cogent NOC team has been working with Verizon as well as Google to assist with resolving the issue. After further investigation there is no issue on the Cogent network which is causing the issue that you are seeing. Currently we have asked for Google and Verizon to work together to assist with resolving the issue which has been isolated to their end of the spectrum. > > As you can see, this issue is beyond Cogent control nevertheless, we continue pushing to get it resolve. We will provide you with further updates as they arise. I am getting a "Destination unreachable" from their closest router. We did rerouting through a different carrier, so not a big problem for us, but still annoying. > # ping6 ipv6.google.com > PING ipv6.google.com(dfw06s47-in-x0e.1e100.net) 56 data bytes > From te0-0-0-1.rcr12.sea03.atlas.cogentco.com icmp_seq=1 Destination > unreachable: No route On 18.02.2016 at 07:01 Damien Burke wrote: > I am currently having a issue with cogent and google over ipv6. My traceroute seems to hit cogent, Verizon, and then just dies. > > I have a case open with both and each tells me the other is working on it. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev > Sent: Wednesday, February 17, 2016 1:35 PM > To: nanog at nanog.org > Subject: Re: Cogent <=> Google Peering issue > > If my telepathy still works fine and I understood your question well - then the answer is "NO, that is not a global well-known issue" ;) > > On 17.02.16 18:15, Fred Hollis wrote: >> Anyone else aware of it? >> > From damien at supremebytes.com Thu Feb 18 07:50:17 2016 From: damien at supremebytes.com (Damien Burke) Date: Thu, 18 Feb 2016 07:50:17 +0000 Subject: Cogent <=> Google Peering issue In-Reply-To: <56C563A2.5090902@web2objects.com> References: <56C49C92.1080607@web2objects.com> <56C4E79B.8060908@netassist.ua> <2FD50E6D13594B4C93B743BFCF9F52843D0B047B@EXCH01.sb.local> <56C563A2.5090902@web2objects.com> Message-ID: <2FD50E6D13594B4C93B743BFCF9F52843D0B162C@EXCH01.sb.local> Cogent, Can you stop peering with Verizon in the meantime? Please? D: -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Fred Hollis Sent: Wednesday, February 17, 2016 10:25 PM To: nanog at nanog.org Subject: Re: Cogent <=> Google Peering issue Yes, it's a global Cogent problem. We are in contact with them as well and were told that they're aware of that but can't do anything about it on their own. > Dear Cogent Customer, > > Cogent NOC team has been working with Verizon as well as Google to assist with resolving the issue. After further investigation there is no issue on the Cogent network which is causing the issue that you are seeing. Currently we have asked for Google and Verizon to work together to assist with resolving the issue which has been isolated to their end of the spectrum. > > As you can see, this issue is beyond Cogent control nevertheless, we continue pushing to get it resolve. We will provide you with further updates as they arise. I am getting a "Destination unreachable" from their closest router. We did rerouting through a different carrier, so not a big problem for us, but still annoying. > # ping6 ipv6.google.com > PING ipv6.google.com(dfw06s47-in-x0e.1e100.net) 56 data bytes > From te0-0-0-1.rcr12.sea03.atlas.cogentco.com icmp_seq=1 > Destination > unreachable: No route On 18.02.2016 at 07:01 Damien Burke wrote: > I am currently having a issue with cogent and google over ipv6. My traceroute seems to hit cogent, Verizon, and then just dies. > > I have a case open with both and each tells me the other is working on it. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Tulyev > Sent: Wednesday, February 17, 2016 1:35 PM > To: nanog at nanog.org > Subject: Re: Cogent <=> Google Peering issue > > If my telepathy still works fine and I understood your question well - > then the answer is "NO, that is not a global well-known issue" ;) > > On 17.02.16 18:15, Fred Hollis wrote: >> Anyone else aware of it? >> > From colton.conor at gmail.com Thu Feb 18 13:45:24 2016 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 18 Feb 2016 07:45:24 -0600 Subject: Cisco ASR9010 vs Juniper MX960 Message-ID: I would like opinions of the differences between these two platforms if possible. I was going to buy a used Juniper MX960 Router MX960-PREMIUM2-AC-ECM with 2 x RE-S-1800X4-16G and 3 x SCBE-MX-S. Then I was going to load this up with a couple of older DPCE-R-4XGE-XFP 4x10GE DPC Enhanced cards. Now Cisco has offered me a new ASR9010 with dual ASR9K Route Switch Processor with 440G/slot Fabric and 6GB, and two 4X10GE / 16X1G Combo Linecard, Packet Transport Optimized for about the same price as the used Juniper. The only catch is the Cisco's support and warranty looks very expensive per year, but that's hard to compare since a used Juniper has zero support and warranty included. If these were both brand new with support and warranty which would you choose? If it were the used Juniper vs new Cisco which would you choose? I know Juniper makes newer MIC cards that probably better compete with these Cisco cards, but that is not option due to price. New, Juniper wants to sell me a MX104 for the same price that I can get this Cisco ASR9010. I think that is a no brainer to go with the ASR at that point. I asked for new pricing on a MX240/480/960, but that was not even close to the ASR9010 numbers. I can also buy two ASR 9001's for the same price and as the single ASR9010. From jason at rice.edu Thu Feb 18 13:55:44 2016 From: jason at rice.edu (Jason Bothe) Date: Thu, 18 Feb 2016 07:55:44 -0600 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: References: Message-ID: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> We have both and they?re both great boxes, however it?s sort of embarrassing that the ASR9k still can?t do virtualized routing, ie. logical-systems. Not sure if thats a deal breaker for you but just thought you?d like to beware. We also find OS configurations on the Juniper much easier than the cumbersome XR OS that the Cisco runs. The 9k does however get a huge win with the ability to apply a ?pie? or software patch while staying in service vs requiring a reload. Either way, I don?t think you?ll go wrong. J~ Jason Bothe, Manager of Networking Rice University o +1 713 348 5500 m +1 713 703 3552 jason at rice.edu > On 18, Feb 2016, at 7:45 AM, Colton Conor wrote: > > I would like opinions of the differences between these two platforms if > possible. > > I was going to buy a used Juniper MX960 Router MX960-PREMIUM2-AC-ECM with > 2 x RE-S-1800X4-16G and 3 x SCBE-MX-S. Then I was going to load this up > with a couple of older DPCE-R-4XGE-XFP 4x10GE DPC Enhanced cards. > > Now Cisco has offered me a new ASR9010 with dual ASR9K Route Switch > Processor with 440G/slot Fabric and 6GB, and two 4X10GE / 16X1G Combo > Linecard, Packet Transport Optimized for about the same price as the used > Juniper. The only catch is the Cisco's support and warranty looks > very expensive per year, but that's hard to compare since a used Juniper > has zero support and warranty included. > > > If these were both brand new with support and warranty which would you > choose? If it were the used Juniper vs new Cisco which would you choose? > > I know Juniper makes newer MIC cards that probably better compete with > these Cisco cards, but that is not option due to price. > > New, Juniper wants to sell me a MX104 for the same price that I can get > this Cisco ASR9010. I think that is a no brainer to go with the ASR at that > point. I asked for new pricing on a MX240/480/960, but that was not even > close to the ASR9010 numbers. > > I can also buy two ASR 9001's for the same price and as the single ASR9010. > From josh at kyneticwifi.com Thu Feb 18 13:59:36 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 18 Feb 2016 07:59:36 -0600 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> References: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> Message-ID: With GRES, can't you simply set the master RE as backup, apply firmware, then switch back to master and upgrade the backup RE? On Feb 18, 2016 7:57 AM, "Jason Bothe" wrote: > We have both and they?re both great boxes, however it?s sort of > embarrassing that the ASR9k still can?t do virtualized routing, ie. > logical-systems. Not sure if thats a deal breaker for you but just thought > you?d like to beware. We also find OS configurations on the Juniper much > easier than the cumbersome XR OS that the Cisco runs. The 9k does however > get a huge win with the ability to apply a ?pie? or software patch while > staying in service vs requiring a reload. Either way, I don?t think > you?ll go wrong. > > > J~ > > > Jason Bothe, Manager of Networking > Rice University > o +1 713 348 5500 > m +1 713 703 3552 > jason at rice.edu > > > On 18, Feb 2016, at 7:45 AM, Colton Conor > wrote: > > > > I would like opinions of the differences between these two platforms if > > possible. > > > > I was going to buy a used Juniper MX960 Router MX960-PREMIUM2-AC-ECM with > > 2 x RE-S-1800X4-16G and 3 x SCBE-MX-S. Then I was going to load this up > > with a couple of older DPCE-R-4XGE-XFP 4x10GE DPC Enhanced cards. > > > > Now Cisco has offered me a new ASR9010 with dual ASR9K Route Switch > > Processor with 440G/slot Fabric and 6GB, and two 4X10GE / 16X1G Combo > > Linecard, Packet Transport Optimized for about the same price as the used > > Juniper. The only catch is the Cisco's support and warranty looks > > very expensive per year, but that's hard to compare since a used Juniper > > has zero support and warranty included. > > > > > > If these were both brand new with support and warranty which would you > > choose? If it were the used Juniper vs new Cisco which would you choose? > > > > I know Juniper makes newer MIC cards that probably better compete with > > these Cisco cards, but that is not option due to price. > > > > New, Juniper wants to sell me a MX104 for the same price that I can get > > this Cisco ASR9010. I think that is a no brainer to go with the ASR at > that > > point. I asked for new pricing on a MX240/480/960, but that was not even > > close to the ASR9010 numbers. > > > > I can also buy two ASR 9001's for the same price and as the single > ASR9010. > > > > From jason at rice.edu Thu Feb 18 14:04:44 2016 From: jason at rice.edu (Jason Bothe) Date: Thu, 18 Feb 2016 08:04:44 -0600 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: References: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> Message-ID: We have run into issues with GRES, and I think its an issue with the RE we have. I don?t actually perform the tasks so it may or may not be as big of an issue as I initially stated. Jason Bothe, Manager of Networking Rice University o +1 713 348 5500 m +1 713 703 3552 jason at rice.edu > On 18, Feb 2016, at 7:59 AM, Josh Reynolds wrote: > > With GRES, can't you simply set the master RE as backup, apply firmware, then switch back to master and upgrade the backup RE? > > On Feb 18, 2016 7:57 AM, "Jason Bothe" > wrote: > We have both and they?re both great boxes, however it?s sort of embarrassing that the ASR9k still can?t do virtualized routing, ie. logical-systems. Not sure if thats a deal breaker for you but just thought you?d like to beware. We also find OS configurations on the Juniper much easier than the cumbersome XR OS that the Cisco runs. The 9k does however get a huge win with the ability to apply a ?pie? or software patch while staying in service vs requiring a reload. Either way, I don?t think you?ll go wrong. > > > J~ > > > Jason Bothe, Manager of Networking > Rice University > o +1 713 348 5500 > m +1 713 703 3552 > jason at rice.edu > > > On 18, Feb 2016, at 7:45 AM, Colton Conor > wrote: > > > > I would like opinions of the differences between these two platforms if > > possible. > > > > I was going to buy a used Juniper MX960 Router MX960-PREMIUM2-AC-ECM with > > 2 x RE-S-1800X4-16G and 3 x SCBE-MX-S. Then I was going to load this up > > with a couple of older DPCE-R-4XGE-XFP 4x10GE DPC Enhanced cards. > > > > Now Cisco has offered me a new ASR9010 with dual ASR9K Route Switch > > Processor with 440G/slot Fabric and 6GB, and two 4X10GE / 16X1G Combo > > Linecard, Packet Transport Optimized for about the same price as the used > > Juniper. The only catch is the Cisco's support and warranty looks > > very expensive per year, but that's hard to compare since a used Juniper > > has zero support and warranty included. > > > > > > If these were both brand new with support and warranty which would you > > choose? If it were the used Juniper vs new Cisco which would you choose? > > > > I know Juniper makes newer MIC cards that probably better compete with > > these Cisco cards, but that is not option due to price. > > > > New, Juniper wants to sell me a MX104 for the same price that I can get > > this Cisco ASR9010. I think that is a no brainer to go with the ASR at that > > point. I asked for new pricing on a MX240/480/960, but that was not even > > close to the ASR9010 numbers. > > > > I can also buy two ASR 9001's for the same price and as the single ASR9010. > > > From josh at kyneticwifi.com Thu Feb 18 14:09:05 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 18 Feb 2016 08:09:05 -0600 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: References: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> Message-ID: Yeah, you might look into that. We're about to put 3 x MX960s in service and with GRES and NSR we are not dropping traffic when taking the master RE down. On Feb 18, 2016 8:05 AM, "Jason Bothe" wrote: > We have run into issues with GRES, and I think its an issue with the RE we > have. I don?t actually perform the tasks so it may or may not be as big of > an issue as I initially stated. > > > > Jason Bothe, Manager of Networking > Rice University > o +1 713 348 5500 > m +1 713 703 3552 > jason at rice.edu > > On 18, Feb 2016, at 7:59 AM, Josh Reynolds wrote: > > With GRES, can't you simply set the master RE as backup, apply firmware, > then switch back to master and upgrade the backup RE? > On Feb 18, 2016 7:57 AM, "Jason Bothe" wrote: > >> We have both and they?re both great boxes, however it?s sort of >> embarrassing that the ASR9k still can?t do virtualized routing, ie. >> logical-systems. Not sure if thats a deal breaker for you but just thought >> you?d like to beware. We also find OS configurations on the Juniper much >> easier than the cumbersome XR OS that the Cisco runs. The 9k does however >> get a huge win with the ability to apply a ?pie? or software patch while >> staying in service vs requiring a reload. Either way, I don?t think >> you?ll go wrong. >> >> >> J~ >> >> >> Jason Bothe, Manager of Networking >> Rice University >> o +1 713 348 5500 >> m +1 713 703 3552 >> jason at rice.edu > ason at rice.edu> >> > On 18, Feb 2016, at 7:45 AM, Colton Conor >> wrote: >> > >> > I would like opinions of the differences between these two platforms if >> > possible. >> > >> > I was going to buy a used Juniper MX960 Router MX960-PREMIUM2-AC-ECM >> with >> > 2 x RE-S-1800X4-16G and 3 x SCBE-MX-S. Then I was going to load this up >> > with a couple of older DPCE-R-4XGE-XFP 4x10GE DPC Enhanced cards. >> > >> > Now Cisco has offered me a new ASR9010 with dual ASR9K Route Switch >> > Processor with 440G/slot Fabric and 6GB, and two 4X10GE / 16X1G Combo >> > Linecard, Packet Transport Optimized for about the same price as the >> used >> > Juniper. The only catch is the Cisco's support and warranty looks >> > very expensive per year, but that's hard to compare since a used Juniper >> > has zero support and warranty included. >> > >> > >> > If these were both brand new with support and warranty which would you >> > choose? If it were the used Juniper vs new Cisco which would you choose? >> > >> > I know Juniper makes newer MIC cards that probably better compete with >> > these Cisco cards, but that is not option due to price. >> > >> > New, Juniper wants to sell me a MX104 for the same price that I can get >> > this Cisco ASR9010. I think that is a no brainer to go with the ASR at >> that >> > point. I asked for new pricing on a MX240/480/960, but that was not even >> > close to the ASR9010 numbers. >> > >> > I can also buy two ASR 9001's for the same price and as the single >> ASR9010. >> > >> >> > From jra at baylink.com Thu Feb 18 14:40:28 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 18 Feb 2016 14:40:28 +0000 (UTC) Subject: Congrats to SMB! Message-ID: <925215556.201290.1455806428844.JavaMail.zimbra@baylink.com> Let me be, apparently, the first to extend congratulations to long time NANOGer, Columbia CS professor, security researcher, and co-inventor of Usenet -- does anybody remember Usenet? :-) -- Steven M. Bellovin, who, it was announced yesterday, has become the first actual, y'know, technical person appointed to the Privacy and Civil Liberties Oversight Board, the White House organization formed over a decade ago to oversee the NSA in light of its bulk data collection activities WRT US citizens. A Wired piece, with Steve's new resume photo, is here: http://www.wired.com/2016/02/the-presidents-nsa-advisory-board-finally-gets-a-tech-expert/ and Steve's altogether excellent blog, which I read way too infrequently, is here: https://www.cs.columbia.edu/~smb/blog/control/ Steve always has interesting stuff to say; it's nice to know that now... well, there's no way I can phrase this compliment without being accidentally insulting. So I'll shut up now. :-) == Steve's latest book is the second edition of _Firewalls And Internet Security: Repelling the Wily Hacker_; more info including links to buy are here: http://www.wilyhacker.com/ For poor but smart people, note that there's a link there to the full text of the first edition; while much of it has been overrun by events, there's still a lot of good material there. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Thu Feb 18 14:44:55 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 18 Feb 2016 14:44:55 +0000 (UTC) Subject: Eyeball Networks and DNS (was: Re: Xfinity stale DNS) In-Reply-To: References: Message-ID: <1993603000.201301.1455806695384.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Chris Garrett" > An inadvertent DNS change was made on one of our domains yesterday. While the > rest of the ISP world seems to be working correctly after propagation for the > fix, I can not get Comcast / Xfinity to clear the stale records. > > Anyone have suggestions or experience in moving them along? This has been a not altogether infrequent request for a couple decades, all the way back to the time when I was the one who got bit in 96, and a *phone call to NetSol* was the prescription. :-) But -- especially in a world where the people who operate eyeball network DNS customer resolver servers hold the shape of the Internet in their hands, and have been known to monkey with it (by, eg, flooring TTLs on records to times much longer than you set, simply to reduce their own machine load) -- am I the only one who thinks that it might be time for a more formal solution to this problem? Certainly the technology isn't *that* hard to manage/deploy/invent at this late date... 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 saku at ytti.fi Thu Feb 18 14:46:07 2016 From: saku at ytti.fi (Saku Ytti) Date: Thu, 18 Feb 2016 16:46:07 +0200 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: References: Message-ID: On 18 February 2016 at 15:45, Colton Conor wrote: Hey, > I would like opinions of the differences between these two platforms if > possible. Summary, I think MX is better HW and SW right now. Warning, rant incoming. I liked ASR9k lot more before I needed to run it. On paper IOS-XR is superior to JunOS, JunOS is old fashioned non-pre-emptive, run-to-completion. In theory this is most efficient way to run code, but in practice it means programmer needs to be hyper aware how long any bit of code they are writing may execute, if they get it wrong, and don't yield manually, simple things like parsing community list while doing commit may cause IGP flap. IOS-XR otoh has multiple processes scheduled either by QNX or Linux, which means programmer does need to be so careful, Linux can pre-empt the process and run something more important. However, with this distribution comes problem of IPC, sharing-state in fast and economical manner, and I believe IOS-XR has dropped the ball here, I don't know if it's even possible to solve today, it is probably a very hard problem. This is just speculation, but I feel like Cisco underestimated the problem, and instead of rethinking infrastructure, they are duplicating state in efforts to keep performance acceptable, as IPC cannot be made fast enough. All this adds complexity which adds bugs. So in practice, I believe JunOS to be currently the better system. But IOS-XR 6 may show some light behind the tunnel, unsure yet. (Isn't this always the case, in two years time, everything will be great) For hardware, ASR9k have trident and typhoon generation, which are Israeli EZChip (since acquired) NPUs, and now tomahawk which is completely different NPU. Juniper MX has DPCE and Trio, from microcode POV both have two generations, but you can't buy anymore DPCE it's very old, so all MX systems really are Trio only, which means JNPR only needs to develope features once for single NPU generation. Cisco needs to do it twice and operator needs to learn two platforms to troubleshoot, and there is feature disparity with troubleshooting commands. I also believe that Trio NPU is better NPU than EZchip or the one in Typhoon, they atypically have succeeded doing all lookups (FIB and ALC) in RLDRAM, instead of TCAM which is easier to pull off but more expensive. Trio can do more in HW, like fragmentation, can look deeper in packet. Lot of flexibility is exposed to operator, like ability to arbitrary firewall filters by checking specific bit-positions. For multicast ASR9k is better, as it can replicate in fabric, where as in MX replication is done by linecard, either binary or unary. But this really is relevant unless you actually have large volume of multicast replicated to many ports. For troubleshooting/instrumentation, for some things MX is better, like packet-via-dmem capture for all transit packets is god-sent. But ASR9k has far more NPU counters for various drop/punt/limit conditions, which most can be capture (at cost of stopping forwarding for a moment). Most of the stuff in ASR9k is very new or just coming, while MX has had sufficient instrumentation for years. ASR9k team is focusing on this and lot of good stuff is in pipeline, which may make ASR9k instrumentation better on the long run. IOS-XR does not have any guaranteed machine parseable presentation of data, in JunOS every command can be outputted as high quality XML. In IOS-XR this is rarely possible, and even when it is, there is no strong relation CLI, and often the actual output is just single string-blob, so using it is no better than screee-scraping. JunOS inherently will have this XML, much like TimOS would inherently have SNMP presentation of data. I don't imagine this being solved any time soon, because it's very fundamental infrastructure issue. What is our truth source? Truth source should be single presentation, out of which both CLI/XML/YANG is extracted, so that there simply is no possibility of de-sync. Lot of the stuff Cisco wanted to solve from Classic IOS are actually worse in IOS-XR. Software management is worse, yeah you have SMUs but managing them is a nightmare and most of them are reload or routign flap anyhow, so it does not really help you. I actually prefer managing Classic IOS software than XR. Most of the time we need to upgrade, we need to do it because HW isn't supported. JunOS has figured this out correctly as well, by having hardware abstraction layer they can in-service add 'JAM' or new support for new hardware, without changing the software. For control-plane protection IOS-XR has pretty solid idea in 'LPTS', the platform should know what is to be punted and what not, so why not automatically program ACLs and policers for that stuff. It works somewhat well, better than JunOS out-of-the-box. But for operator who knows what they are doing, JunOS can be protected much, much better. 'LPTS' only has single policer for specific traffic-class, like 'BGP-known', if this is offended, all BGP suffer. Where as JunOS has multiple levels of policers, aggregate policer, which is same as IOS-XR, but there are also 'subscriber' level (L4 keys), 'ifl' level and 'ifd' level. So even if single BGP neighbour flloods you tons of frames, you can still have all other BGP sessions protected by having the misbehaving BGP neighbour limited in its IFD, IFL or Sub level. If I could get classicIOS with commit and RPL, I'd run that rather than XR right now. For MX you might want to ping account team about MX2008, which will (IMHO) replace MX960 RSN. Main advantage on top of supporting newer MPCs is that you don't have mid-plane, fabrics are connected to LC's directly, so you never need to upgrade chassis to support higher rate SERDES in future. -- ++ytti From royce at techsolvency.com Thu Feb 18 15:07:28 2016 From: royce at techsolvency.com (Royce Williams) Date: Thu, 18 Feb 2016 06:07:28 -0900 Subject: Congrats to SMB! In-Reply-To: <925215556.201290.1455806428844.JavaMail.zimbra@baylink.com> References: <925215556.201290.1455806428844.JavaMail.zimbra@baylink.com> Message-ID: On Thu, Feb 18, 2016 at 5:40 AM, Jay R. Ashworth wrote: > Let me be, apparently, the first to extend congratulations to long time > NANOGer, Columbia CS professor, security researcher, and co-inventor of > Usenet -- does anybody remember Usenet? :-) -- Steven M. Bellovin, who, > it was announced yesterday, has become the first actual, y'know, technical > person appointed to the Privacy and Civil Liberties Oversight Board, the > White House organization formed over a decade ago to oversee the NSA in > light of its bulk data collection activities WRT US citizens. Hear, hear! [snip] > Steve's latest book is the second edition of _Firewalls And Internet Security: > Repelling the Wily Hacker_; more info including links to buy are here: > > http://www.wilyhacker.com/ > > For poor but smart people, note that there's a link there to the full text of the > first edition; while much of it has been overrun by events, there's still a lot of > good material there. Minor correction: Steve's latest book is _Thinking Security_ (Nov 2015). Pretty great so far. Royce From nick at foobar.org Thu Feb 18 15:51:05 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 18 Feb 2016 15:51:05 +0000 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> References: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> Message-ID: <56C5E869.7030406@foobar.org> Jason Bothe wrote: > The 9k does however get a huge win with the ability to apply a ?pie? > or software patch while staying in service vs requiring a reload. SMUs are often "hitless", which is to say, "hitless" with scary quotes. What this means in practice is that the SMU itself might be hitless but it will depend on 47 other SMUs, thereby almost guaranteeing some form of reload. Also, restarting processes is "hitless" (e.g. restarting bgpd, ospfd, etc) or shutting down interfaces. E.g.: CSCuo47663: "Hitless/Optional SMU,aigp metric different in RIB & BGP table". This will restart the bgp process. CSCus26923: "traffic from SIP700 to 9000v is dropped when a link to 9000v flaps". Release notes state that the issue is not service impacting, then "After the SMU installation , we need to apply shut/noshut of the problematic interface to trigger the hardware programming." Wuh?? In other words, "hitless" does not mean "not service impacting". Nick From jared at puck.nether.net Thu Feb 18 15:55:00 2016 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 18 Feb 2016 10:55:00 -0500 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: <56C5E869.7030406@foobar.org> References: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> <56C5E869.7030406@foobar.org> Message-ID: > On Feb 18, 2016, at 10:51 AM, Nick Hilliard wrote: > > In other words, "hitless" does not mean "not service impacting". I would assume any SMU impacts traffic and requires a reboot or a line card reset. There are types of SMUs that touch low level parts and require a reboot, in which case I?ve often told Cisco they should just rev the release number. Solving SMU dependencies is sometimes impossible. Right now the 5.3.3 SMU set posted on CCO can?t be installed with any of their automation/tools. We are waiting for Cisco to provide a fix. I?m not holding my breath. - Jared From davidbass570 at gmail.com Thu Feb 18 16:19:02 2016 From: davidbass570 at gmail.com (David Bass) Date: Thu, 18 Feb 2016 11:19:02 -0500 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: <56C5E869.7030406@foobar.org> References: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> <56C5E869.7030406@foobar.org> Message-ID: <1FD1D92F-CD59-40C7-926B-CF58C7708895@gmail.com> I don't think I'd trust any vendor's "ISSU" to be completely without impact...been more of a marketing term from my experience... > On Feb 18, 2016, at 10:51 AM, Nick Hilliard wrote: > > Jason Bothe wrote: >> The 9k does however get a huge win with the ability to apply a ?pie? >> or software patch while staying in service vs requiring a reload. > > SMUs are often "hitless", which is to say, "hitless" with scary quotes. > What this means in practice is that the SMU itself might be hitless but > it will depend on 47 other SMUs, thereby almost guaranteeing some form > of reload. Also, restarting processes is "hitless" (e.g. restarting > bgpd, ospfd, etc) or shutting down interfaces. > > E.g.: > > CSCuo47663: "Hitless/Optional SMU,aigp metric different in RIB & BGP > table". This will restart the bgp process. > > CSCus26923: "traffic from SIP700 to 9000v is dropped when a link to > 9000v flaps". Release notes state that the issue is not service > impacting, then "After the SMU installation , we need to apply > shut/noshut of the problematic interface to trigger the hardware > programming." Wuh?? > > In other words, "hitless" does not mean "not service impacting". > > Nick From greg.whynott at gmail.com Thu Feb 18 17:46:52 2016 From: greg.whynott at gmail.com (greg whynott) Date: Thu, 18 Feb 2016 12:46:52 -0500 Subject: RBL resource to check entire netblock In-Reply-To: <63B58448-7F9C-4BE0-86F7-6AA5D5D107E0@anycast.cl> References: <6b3ffd9949784e80a0733dd690e66ca2@exchange.ip-it.com> <63B58448-7F9C-4BE0-86F7-6AA5D5D107E0@anycast.cl> Message-ID: Team NANOG, I will summarize once I get to looking at things. This isn't an immediate need but with that said I expect to start on it next week. I may not evaluate all of them but what I do try I will share. My next challenge is finding a router that will forward on 4 x 1 gig interfaces (2 inside 2 outside) for less than 30k... -greg On Wed, Feb 17, 2016 at 1:32 PM, Roberto Alvarado wrote: > You can try this script: > > https://github.com/DjinnS/check-rbl > > > -i,--ip The IP or subnet to check > > I?m using it to check my subnets > > > Roberto > > > > > > > On Feb 17, 2016, at 15:25, Bernd Spiess wrote: > > > >> I find many sites where you can enter 1 IP to > >> do a check but they don't seem to accept subnets to check. > > > > Maybe this is a help? > > https://www.senderbase.org/ > > > > Bernd > > From dcorbe at hammerfiber.com Thu Feb 18 20:15:02 2016 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Thu, 18 Feb 2016 15:15:02 -0500 Subject: -48DC electrical supply Message-ID: <55E23926-D465-4C65-B8AB-B2FF2BFC608A@hammerfiber.com> Where do you guys get your supplies (wire, connectors, tools) for -48VDC stuff? From SNaslund at medline.com Thu Feb 18 20:21:03 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 18 Feb 2016 20:21:03 +0000 Subject: -48DC electrical supply In-Reply-To: <55E23926-D465-4C65-B8AB-B2FF2BFC608A@hammerfiber.com> References: <55E23926-D465-4C65-B8AB-B2FF2BFC608A@hammerfiber.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C9BFEEF7@MUNPRDMBXA1.medline.com> Graybar electric or Anixter. They can supply any of that stuff. There is not much specific about -48 VDC, just copper lugs, taps, and wire of the correct type and gage and you should be good to go. For tools from those suppliers I recommend both Amp and Thomas & Betts as reputable. The tooling is costly but mil-spec stuff often is and is often required for central office work. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Corbe Sent: Thursday, February 18, 2016 2:15 PM To: NANOG Subject: -48DC electrical supply Where do you guys get your supplies (wire, connectors, tools) for -48VDC stuff? From bob at FiberInternetCenter.com Thu Feb 18 20:22:28 2016 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 18 Feb 2016 12:22:28 -0800 Subject: -48DC electrical supply In-Reply-To: <55E23926-D465-4C65-B8AB-B2FF2BFC608A@hammerfiber.com> References: <55E23926-D465-4C65-B8AB-B2FF2BFC608A@hammerfiber.com> Message-ID: I use auto parts stores, if the current isn't much. Your typical thick gauge battery cable can carry quite a bit and auto part stores are everywhere. Thank You Bob Evans CTO > Where do you guys get your supplies (wire, connectors, tools) for -48VDC > stuff? > > From joshbaird at gmail.com Thu Feb 18 20:22:51 2016 From: joshbaird at gmail.com (Josh Baird) Date: Thu, 18 Feb 2016 14:22:51 -0600 Subject: -48DC electrical supply In-Reply-To: <55E23926-D465-4C65-B8AB-B2FF2BFC608A@hammerfiber.com> References: <55E23926-D465-4C65-B8AB-B2FF2BFC608A@hammerfiber.com> Message-ID: For DC 'stuff' in general (wires, fuses, distribution, etc), I use alliedelectronics.com. On Thu, Feb 18, 2016 at 2:15 PM, Daniel Corbe wrote: > Where do you guys get your supplies (wire, connectors, tools) for -48VDC > stuff? > > From jason at rice.edu Thu Feb 18 21:59:17 2016 From: jason at rice.edu (Jason Bothe) Date: Thu, 18 Feb 2016 15:59:17 -0600 Subject: -48DC electrical supply In-Reply-To: <55E23926-D465-4C65-B8AB-B2FF2BFC608A@hammerfiber.com> References: <55E23926-D465-4C65-B8AB-B2FF2BFC608A@hammerfiber.com> Message-ID: <3F36D0E4-A498-46C4-83CA-CD4722453CF3@rice.edu> Make sure you get wire rated for 90?C at a minimum. Telcoflex or cobra wire is good. Jason Bothe, Manager of Networking Rice University o +1 713 348 5500 m +1 713 703 3552 Sent from mobile > On Feb 18, 2016, at 14:15, Daniel Corbe wrote: > > Where do you guys get your supplies (wire, connectors, tools) for -48VDC stuff? > > From morrowc.lists at gmail.com Thu Feb 18 22:34:24 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Feb 2016 17:34:24 -0500 Subject: RBL resource to check entire netblock In-Reply-To: References: <6b3ffd9949784e80a0733dd690e66ca2@exchange.ip-it.com> <63B58448-7F9C-4BE0-86F7-6AA5D5D107E0@anycast.cl> Message-ID: On Thu, Feb 18, 2016 at 12:46 PM, greg whynott wrote: > Team NANOG, > > I will summarize once I get to looking at things. This isn't an immediate > need but with that said I expect to start on it next week. I may not > evaluate all of them but what I do try I will share. > > My next challenge is finding a router that will forward on 4 x 1 gig > interfaces (2 inside 2 outside) for less than 30k... > Ubiquiti Networks ERPro8. 349 from your friendly amazon dealer... buy 2 so you have a spare. > -greg > > > > On Wed, Feb 17, 2016 at 1:32 PM, Roberto Alvarado > wrote: > >> You can try this script: >> >> https://github.com/DjinnS/check-rbl >> >> >> -i,--ip The IP or subnet to check >> >> I?m using it to check my subnets >> >> >> Roberto >> >> >> >> >> >> > On Feb 17, 2016, at 15:25, Bernd Spiess wrote: >> > >> >> I find many sites where you can enter 1 IP to >> >> do a check but they don't seem to accept subnets to check. >> > >> > Maybe this is a help? >> > https://www.senderbase.org/ >> > >> > Bernd >> >> From eric.oosting at gmail.com Thu Feb 18 22:36:41 2016 From: eric.oosting at gmail.com (Eric Oosting) Date: Thu, 18 Feb 2016 17:36:41 -0500 Subject: RBL resource to check entire netblock In-Reply-To: References: <6b3ffd9949784e80a0733dd690e66ca2@exchange.ip-it.com> <63B58448-7F9C-4BE0-86F7-6AA5D5D107E0@anycast.cl> Message-ID: On Thu, Feb 18, 2016 at 12:46 PM, greg whynott wrote: > Team NANOG, > > I will summarize once I get to looking at things. This isn't an immediate > need but with that said I expect to start on it next week. I may not > evaluate all of them but what I do try I will share. > > My next challenge is finding a router that will forward on 4 x 1 gig > interfaces (2 inside 2 outside) for less than 30k... > Without knowing much about your requirements I can say that the edgerouter pro from ubiquiti doesn't suck, and is fantastic for the price. Cheap enough to self spare, and -e > > -greg > > > > On Wed, Feb 17, 2016 at 1:32 PM, Roberto Alvarado > wrote: > > > You can try this script: > > > > https://github.com/DjinnS/check-rbl > > > > > > -i,--ip The IP or subnet to check > > > > I?m using it to check my subnets > > > > > > Roberto > > > > > > > > > > > > > On Feb 17, 2016, at 15:25, Bernd Spiess > wrote: > > > > > >> I find many sites where you can enter 1 IP to > > >> do a check but they don't seem to accept subnets to check. > > > > > > Maybe this is a help? > > > https://www.senderbase.org/ > > > > > > Bernd > > > > > From marka at isc.org Thu Feb 18 23:17:03 2016 From: marka at isc.org (Mark Andrews) Date: Fri, 19 Feb 2016 10:17:03 +1100 Subject: Eyeball Networks and DNS (was: Re: Xfinity stale DNS) In-Reply-To: Your message of "Thu, 18 Feb 2016 14:44:55 -0000." <1993603000.201301.1455806695384.JavaMail.zimbra@baylink.com> References: <1993603000.201301.1455806695384.JavaMail.zimbra@baylink.com> Message-ID: <20160218231703.E871542AF0D1@rock.dv.isc.org> We define a new DNS opcode FLUSH and a EDNS FLUSH option. The recursive server send a FLUSH option with a 64 bit cookie computed from a client secret, the server address and zone the QNAME is being looked up in. The answering server stores these along with arrival address provided they arrive over TCP or with a valid EDNS Server Cookie flushing them after X seconds or on a LRU basis if they are consuming too many resources. Answers to this query are also capped at X seconds. This means there has been a 3 way handshake to get put onto the list initially. A server can only flush namespace it has returned answers for. When a flush needs to occur a FLUSH message with the namespace to be flushed is sent to each server in the list with the EDNS FLUSH option that was recorded using the source address address recorded with it. If the EDNS FLUSH option verifies (stripping labels to get the matching domain name used to generate the cookie) then the server flushes the namespace and generates downstream FLUSH messages using its list of clients. Mark In message <1993603000.201301.1455806695384.JavaMail.zimbra at baylink.com>, "Jay R. Ashworth" writes: > ----- Original Message ----- > > From: "Chris Garrett" > > > An inadvertent DNS change was made on one of our domains yesterday. While t > he > > rest of the ISP world seems to be working correctly after propagation for t > he > > fix, I can not get Comcast / Xfinity to clear the stale records. > > > > Anyone have suggestions or experience in moving them along? > > This has been a not altogether infrequent request for a couple decades, > all the way back to the time when I was the one who got bit in 96, and a > *phone call to NetSol* was the prescription. :-) > > But -- especially in a world where the people who operate eyeball network > DNS customer resolver servers hold the shape of the Internet in their hands, > and have been known to monkey with it (by, eg, flooring TTLs on records to > times much longer than you set, simply to reduce their own machine load) -- > am I the only one who thinks that it might be time for a more formal solution > to this problem? > > Certainly the technology isn't *that* hard to manage/deploy/invent at this > late date... > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DI > I > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 127 > 4 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From courtneysmith at comcast.net Fri Feb 19 01:31:06 2016 From: courtneysmith at comcast.net (courtneysmith at comcast.net) Date: Fri, 19 Feb 2016 01:31:06 +0000 (UTC) Subject: Documentation on generating IOS-XR prefix and as path sets with rtconfig In-Reply-To: <1175574063.1298310.1455845316077.JavaMail.zimbra@comcast.net> Message-ID: <1720251475.1299237.1455845466667.JavaMail.zimbra@comcast.net> Can anyone point me to examples of using rtconfig to generate IOS-XR configs? Specifically prefix and as-path sets. My Google skills are coming up short. The man page for rtconfig does not mention IOS-XR but it is supposedly supported. I get no farther than 'rtconfig -config ciscoxr'. Thanks. From job at instituut.net Fri Feb 19 06:39:40 2016 From: job at instituut.net (Job Snijders) Date: Fri, 19 Feb 2016 07:39:40 +0100 Subject: Documentation on generating IOS-XR prefix and as path sets with rtconfig In-Reply-To: <1720251475.1299237.1455845466667.JavaMail.zimbra@comcast.net> References: <1175574063.1298310.1455845316077.JavaMail.zimbra@comcast.net> <1720251475.1299237.1455845466667.JavaMail.zimbra@comcast.net> Message-ID: <20160219063940.GH8233@Vurt.local> On Fri, Feb 19, 2016 at 01:31:06AM +0000, courtneysmith at comcast.net wrote: > Can anyone point me to examples of using rtconfig to generate IOS-XR > configs? Specifically prefix and as-path sets. My Google skills are > coming up short. The man page for rtconfig does not mention IOS-XR but > it is supposedly supported. I get no farther than 'rtconfig -config > ciscoxr'. I suggest you look at bgpq3 [1] instead, bgpq3 has support for IOS XR prefix-sets & as-path-sets. You could look into using napalm [2] to upload the resulting configurations to your routers. Kind regards, Job [1]: https://github.com/snar/bgpq3 [2]: https://github.com/napalm-automation/napalm From randy at psg.com Fri Feb 19 08:15:21 2016 From: randy at psg.com (Randy Bush) Date: Fri, 19 Feb 2016 21:15:21 +1300 Subject: Documentation on generating IOS-XR prefix and as path sets with rtconfig In-Reply-To: <20160219063940.GH8233@Vurt.local> References: <1175574063.1298310.1455845316077.JavaMail.zimbra@comcast.net> <1720251475.1299237.1455845466667.JavaMail.zimbra@comcast.net> <20160219063940.GH8233@Vurt.local> Message-ID: >> Can anyone point me to examples of using rtconfig to generate IOS-XR >> configs? > I suggest you look at bgpq3 [1] instead, bgpq3 has support for IOS XR > prefix-sets & as-path-sets. rtconfig does a bit more than prefix and as-path sets. the op may not like the functional gap. but i agree, bgpq3 is bitchin' randy From nick at foobar.org Fri Feb 19 13:44:56 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 19 Feb 2016 13:44:56 +0000 Subject: Documentation on generating IOS-XR prefix and as path sets with rtconfig In-Reply-To: <1720251475.1299237.1455845466667.JavaMail.zimbra@comcast.net> References: <1720251475.1299237.1455845466667.JavaMail.zimbra@comcast.net> Message-ID: <56C71C58.8080104@foobar.org> courtneysmith at comcast.net wrote: > Can anyone point me to examples of using rtconfig to generate IOS-XR > configs? Specifically prefix and as-path sets. My Google skills are > coming up short. The man page for rtconfig does not mention IOS-XR > but it is supposedly supported. I get no farther than 'rtconfig > -config ciscoxr'. there's some support in the git master for irrtoolset (https://github.com/irrtoolset/irrtoolset) for XR config in rtconfig. It's been tested by at least one person. If your main use case is handling prefix lists, you would be much better off using BGPQ3. This tool is far superior to irrtoolset for handling prefix lists and will output to json which means that you can import the data directly into any scripting language you like rather than having to deal with the limited syntax supported by rtconfig. Nick From cscora at apnic.net Fri Feb 19 18:11:16 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Feb 2016 04:11:16 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201602191811.u1JIBGds025527@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 Feb, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 583532 Prefixes after maximum aggregation (per Origin AS): 214790 Deaggregation factor: 2.72 Unique aggregates announced (without unneeded subnets): 284652 Total ASes present in the Internet Routing Table: 52842 Prefixes per ASN: 11.04 Origin-only ASes present in the Internet Routing Table: 36589 Origin ASes announcing only one prefix: 15801 Transit ASes present in the Internet Routing Table: 6414 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 40 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 1035 Unregistered ASNs in the Routing Table: 384 Number of 32-bit ASNs allocated by the RIRs: 12764 Number of 32-bit ASNs visible in the Routing Table: 9839 Prefixes from 32-bit ASNs in the Routing Table: 38235 Number of bogon 32-bit ASNs visible in the Routing Table: 408 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 403 Number of addresses announced to Internet: 2804172612 Equivalent to 167 /8s, 36 /16s and 71 /24s Percentage of available address space announced: 75.7 Percentage of allocated address space announced: 75.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.0 Total number of prefixes smaller than registry allocations: 192117 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 149631 Total APNIC prefixes after maximum aggregation: 41099 APNIC Deaggregation factor: 3.64 Prefixes being announced from the APNIC address blocks: 158901 Unique aggregates announced from the APNIC address blocks: 64226 APNIC Region origin ASes present in the Internet Routing Table: 5137 APNIC Prefixes per ASN: 30.93 APNIC Region origin ASes announcing only one prefix: 1178 APNIC Region transit ASes present in the Internet Routing Table: 901 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1870 Number of APNIC addresses announced to Internet: 751381380 Equivalent to 44 /8s, 201 /16s and 43 /24s Percentage of available APNIC address space announced: 87.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-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: 178824 Total ARIN prefixes after maximum aggregation: 88813 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 183967 Unique aggregates announced from the ARIN address blocks: 87171 ARIN Region origin ASes present in the Internet Routing Table: 16417 ARIN Prefixes per ASN: 11.21 ARIN Region origin ASes announcing only one prefix: 5894 ARIN Region transit ASes present in the Internet Routing Table: 1702 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 37 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1019 Number of ARIN addresses announced to Internet: 1101870912 Equivalent to 65 /8s, 173 /16s and 55 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 140657 Total RIPE prefixes after maximum aggregation: 69507 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 148984 Unique aggregates announced from the RIPE address blocks: 91707 RIPE Region origin ASes present in the Internet Routing Table: 18052 RIPE Prefixes per ASN: 8.25 RIPE Region origin ASes announcing only one prefix: 7953 RIPE Region transit ASes present in the Internet Routing Table: 3020 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4479 Number of RIPE addresses announced to Internet: 702726784 Equivalent to 41 /8s, 226 /16s and 194 /24s Percentage of available RIPE address space announced: 102.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 61411 Total LACNIC prefixes after maximum aggregation: 12129 LACNIC Deaggregation factor: 5.06 Prefixes being announced from the LACNIC address blocks: 74868 Unique aggregates announced from the LACNIC address blocks: 34972 LACNIC Region origin ASes present in the Internet Routing Table: 2461 LACNIC Prefixes per ASN: 30.42 LACNIC Region origin ASes announcing only one prefix: 582 LACNIC Region transit ASes present in the Internet Routing Table: 541 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2280 Number of LACNIC addresses announced to Internet: 170776064 Equivalent to 10 /8s, 45 /16s and 214 /24s Percentage of available LACNIC address space announced: 101.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: 14621 Total AfriNIC prefixes after maximum aggregation: 3201 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 16409 Unique aggregates announced from the AfriNIC address blocks: 6216 AfriNIC Region origin ASes present in the Internet Routing Table: 742 AfriNIC Prefixes per ASN: 22.11 AfriNIC Region origin ASes announcing only one prefix: 194 AfriNIC Region transit ASes present in the Internet Routing Table: 175 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 191 Number of AfriNIC addresses announced to Internet: 76979712 Equivalent to 4 /8s, 150 /16s and 158 /24s Percentage of available AfriNIC address space announced: 76.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 4538 5595 4192 76 China Education and Research 7545 3128 350 177 TPG Telecom Limited 4766 3120 11127 1101 Korea Telecom 17974 2891 914 96 PT Telekomunikasi Indonesia 9829 2378 1447 423 National Internet Backbone 4755 2087 432 240 TATA Communications formerly 9808 1837 8717 30 Guangdong Mobile Communicatio 4808 1625 2284 518 CNCGROUP IP network China169 45899 1576 1076 190 VNNIC 9583 1521 121 557 Sify Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3288 2948 147 Cox Communications Inc. 6389 2412 3687 42 BellSouth.net Inc. 18566 2211 394 276 MegaPath Corporation 20115 1912 1917 407 Charter Communications 30036 1709 340 270 Mediacom Communications Corp 6983 1695 849 236 EarthLink, Inc. 4323 1588 1023 393 tw telecom holdings, inc. 209 1484 4487 1203 Qwest Communications Company, 701 1394 11453 662 MCI Communications Services, 11492 1259 236 586 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 39891 2515 135 9 SaudiNet, Saudi Telecom Compa 20940 2383 924 1707 Akamai International B.V. 34984 1945 322 414 TELLCOM ILETISIM HIZMETLERI A 8551 1226 376 53 Bezeq International-Ltd 6849 1179 355 21 JSC "Ukrtelecom" 8402 1141 544 15 OJSC "Vimpelcom" 12479 1137 979 76 France Telecom Espana SA 13188 1078 98 78 TOV "Bank-Inform" 31148 1041 47 41 Freenet Ltd. 9198 963 352 25 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3428 540 152 Telmex Colombia S.A. 8151 2172 3389 519 Uninet S.A. de C.V. 7303 1588 944 240 Telecom Argentina S.A. 11830 1439 366 25 Instituto Costarricense de El 6503 1433 437 56 Axtel, S.A.B. de C.V. 28573 1041 2177 155 NET Servi?os de Comunica??o S 6147 1036 377 27 Telefonica del Peru S.A.A. 7738 994 1882 41 Telemar Norte Leste S.A. 26615 994 2325 34 Tim Celular S.A. 3816 984 477 191 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1419 1472 15 TE-AS 24863 1198 402 35 Link Egypt (Link.NET) 37611 626 42 44 Afrihost-Brevis Computer Serv 36903 584 294 104 Office National des Postes et 36992 500 1235 28 ETISALAT MISR 37492 356 215 64 Orange Tunisie 24835 332 146 12 Vodafone Data 29571 265 21 11 Cote d'Ivoire Telecom 2018 250 327 74 TENET (The UNINET Project) 3741 222 837 183 Internet Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5595 4192 76 China Education and Research 10620 3428 540 152 Telmex Colombia S.A. 22773 3288 2948 147 Cox Communications Inc. 7545 3128 350 177 TPG Telecom Limited 4766 3120 11127 1101 Korea Telecom 17974 2891 914 96 PT Telekomunikasi Indonesia 39891 2515 135 9 SaudiNet, Saudi Telecom Compa 6389 2412 3687 42 BellSouth.net Inc. 20940 2383 924 1707 Akamai International B.V. 9829 2378 1447 423 National Internet Backbone Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3428 3276 Telmex Colombia S.A. 22773 3288 3141 Cox Communications Inc. 7545 3128 2951 TPG Telecom Limited 17974 2891 2795 PT Telekomunikasi Indonesia 39891 2515 2506 SaudiNet, Saudi Telecom Compa 6389 2412 2370 BellSouth.net Inc. 4766 3120 2019 Korea Telecom 9829 2378 1955 National Internet Backbone 18566 2211 1935 MegaPath Corporation 4755 2087 1847 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 65001 PRIVATE 5.143.176.0/20 15468 OJSC Rostelecom 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 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 37.46.10.0/23 36351 SoftLayer Technologies Inc. 37.46.14.0/24 36351 SoftLayer Technologies Inc. 37.46.15.0/24 36351 SoftLayer Technologies Inc. 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:101 /12:266 /13:511 /14:1024 /15:1757 /16:12978 /17:7498 /18:12597 /19:25653 /20:37979 /21:40029 /22:64785 /23:55905 /24:320773 /25:550 /26:586 /27:406 /28:18 /29:16 /30:13 /31:0 /32:22 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2473 3288 Cox Communications Inc. 39891 2472 2515 SaudiNet, Saudi Telecom Compa 18566 2113 2211 MegaPath Corporation 6389 1531 2412 BellSouth.net Inc. 30036 1524 1709 Mediacom Communications Corp 6983 1341 1695 EarthLink, Inc. 10620 1315 3428 Telmex Colombia S.A. 34984 1234 1945 TELLCOM ILETISIM HIZMETLERI A 11492 1168 1259 CABLE ONE, INC. 6849 997 1179 JSC "Ukrtelecom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1604 2:745 4:19 5:2104 6:27 8:908 12:1787 13:36 14:1650 15:23 16:2 17:68 18:20 20:46 23:1372 24:1739 27:2233 31:1731 32:54 33:2 34:2 35:4 36:227 37:2364 38:1176 39:23 40:85 41:3181 42:384 43:1670 44:41 45:1663 46:2409 47:68 49:1124 50:847 51:3 52:68 54:181 55:3 56:6 57:44 58:1498 59:856 60:557 61:1780 62:1444 63:1908 64:4459 65:2176 66:4082 67:2080 68:1104 69:3295 70:1041 71:464 72:1980 74:2541 75:357 76:421 77:1332 78:1284 79:830 80:1316 81:1366 82:883 83:669 84:801 85:1579 86:465 87:1042 88:564 89:1931 90:166 91:6025 92:849 93:2319 94:2362 95:2288 96:471 97:351 98:953 99:45 100:68 101:926 103:9746 104:2236 105:99 106:391 107:1130 108:651 109:2158 110:1258 111:1628 112:940 113:1257 114:1110 115:1667 116:1522 117:1404 118:2014 119:1562 120:511 121:1166 122:2233 123:2015 124:1616 125:1753 128:716 129:366 130:426 131:1259 132:598 133:173 134:449 135:122 136:351 137:335 138:1699 139:199 140:251 141:474 142:630 143:838 144:594 145:160 146:836 147:594 148:1473 149:462 150:648 151:824 152:598 153:270 154:583 155:904 156:469 157:424 158:343 159:1093 160:421 161:720 162:2272 163:528 164:728 165:1113 166:312 167:1004 168:1501 169:601 170:1490 171:255 172:437 173:1636 174:718 175:855 176:1517 177:3993 178:2228 179:1070 180:2084 181:1658 182:1935 183:680 184:787 185:5749 186:3057 187:1993 188:2076 189:1791 190:7650 191:1254 192:8863 193:5722 194:4351 195:3733 196:1656 197:1319 198:5489 199:5580 200:6806 201:3714 202:10110 203:9551 204:4594 205:2691 206:2973 207:3044 208:4031 209:3875 210:3939 211:2009 212:2646 213:2162 214:811 215:72 216:5712 217:1911 218:741 219:562 220:1646 221:850 222:677 223:921 End of report From rcarpen at network1.net Fri Feb 19 19:17:58 2016 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 19 Feb 2016 14:17:58 -0500 (EST) Subject: Anyone from Verizon/MCI/UUNet ? Message-ID: <1013696733.488017.1455909478128.JavaMail.zimbra@network1.net> We have a netblock that was assigned to us out of 65.192.0.0/11 a long time ago. It has not been used in nearly a decade and still looks to be assigned to us. I'd love to see it reclaimed and reused by someone who needs it. Please contact me off list. thanks, -Randy From tknchris at gmail.com Fri Feb 19 19:23:13 2016 From: tknchris at gmail.com (chris) Date: Fri, 19 Feb 2016 14:23:13 -0500 Subject: Anyone from Verizon/MCI/UUNet ? In-Reply-To: <1013696733.488017.1455909478128.JavaMail.zimbra@network1.net> References: <1013696733.488017.1455909478128.JavaMail.zimbra@network1.net> Message-ID: Would be great to see a variation of the hoarders tv show where we track down hoarders of ipv4 :) Chris On Feb 19, 2016 2:19 PM, "Randy Carpenter" wrote: > > We have a netblock that was assigned to us out of 65.192.0.0/11 a long > time ago. It has not been used in nearly a decade and still looks to be > assigned to us. I'd love to see it reclaimed and reused by someone who > needs it. Please contact me off list. > > thanks, > -Randy > From ray at orsiniit.com Fri Feb 19 19:31:32 2016 From: ray at orsiniit.com (Ray Orsini) Date: Fri, 19 Feb 2016 14:31:32 -0500 Subject: Anyone from Verizon/MCI/UUNet ? In-Reply-To: References: <1013696733.488017.1455909478128.JavaMail.zimbra@network1.net> Message-ID: I'd watch that show! Regards, Ray Orsini ? CEO Orsini IT, LLC ? Technology Consultants VOICE ?DATA ? BANDWIDTH ? SECURITY ? SUPPORT P: 305.967.6756 x1009 E: ray at orsiniit.com TF: 844.OIT.VOIP 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016 http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View Your Tickets -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of chris Sent: Friday, February 19, 2016 2:23 PM To: Randy Carpenter Cc: NANOG list Subject: Re: Anyone from Verizon/MCI/UUNet ? Would be great to see a variation of the hoarders tv show where we track down hoarders of ipv4 :) Chris On Feb 19, 2016 2:19 PM, "Randy Carpenter" wrote: > > We have a netblock that was assigned to us out of 65.192.0.0/11 a long > time ago. It has not been used in nearly a decade and still looks to > be assigned to us. I'd love to see it reclaimed and reused by someone > who needs it. Please contact me off list. > > thanks, > -Randy > From rcarpen at network1.net Fri Feb 19 19:33:37 2016 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 19 Feb 2016 14:33:37 -0500 (EST) Subject: Anyone from Verizon/MCI/UUNet ? In-Reply-To: References: <1013696733.488017.1455909478128.JavaMail.zimbra@network1.net> Message-ID: <640187221.488046.1455910417387.JavaMail.zimbra@network1.net> :-) I've tried to give this back before, but always have hit dead ends in trying to contact the proper people. The fact that it has gone through several administrative changes doesn't help that. I do wonder how much space is out there that is unused, unwanted, but unreclaimed by upstream providers. thanks, -Randy ----- On Feb 19, 2016, at 2:23 PM, chris tknchris at gmail.com wrote: > Would be great to see a variation of the hoarders tv show where we track > down hoarders of ipv4 :) > > Chris > On Feb 19, 2016 2:19 PM, "Randy Carpenter" wrote: > >> >> We have a netblock that was assigned to us out of 65.192.0.0/11 a long >> time ago. It has not been used in nearly a decade and still looks to be >> assigned to us. I'd love to see it reclaimed and reused by someone who >> needs it. Please contact me off list. >> >> thanks, >> -Randy From Steve.Mikulasik at civeo.com Fri Feb 19 19:39:28 2016 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Fri, 19 Feb 2016 19:39:28 +0000 Subject: Anyone from Verizon/MCI/UUNet ? In-Reply-To: <1013696733.488017.1455909478128.JavaMail.zimbra@network1.net> References: <1013696733.488017.1455909478128.JavaMail.zimbra@network1.net> Message-ID: Make sure it goes to a good home where it will be well taken care of. Maybe visit it from time to time, it is hard to give up a good IP block :) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Carpenter Sent: Friday, February 19, 2016 12:18 PM To: NANOG list Subject: Anyone from Verizon/MCI/UUNet ? We have a netblock that was assigned to us out of http://65.192.0.0/11 a long time ago. It has not been used in nearly a decade and still looks to be assigned to us. I'd love to see it reclaimed and reused by someone who needs it. Please contact me off list. thanks, -Randy From rcarpen at network1.net Fri Feb 19 19:46:00 2016 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 19 Feb 2016 14:46:00 -0500 (EST) Subject: Anyone from Verizon/MCI/UUNet ? In-Reply-To: References: <1013696733.488017.1455909478128.JavaMail.zimbra@network1.net> Message-ID: <571422261.488095.1455911160248.JavaMail.zimbra@network1.net> Maybe if I tried to sell it to the highest bidder (particularly someone who has no need for it), it would raise the attention of someone... thanks, -Randy ----- On Feb 19, 2016, at 2:39 PM, Steve Mikulasik Steve.Mikulasik at civeo.com wrote: > Make sure it goes to a good home where it will be well taken care of. Maybe > visit it from time to time, it is hard to give up a good IP block :) > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Carpenter > Sent: Friday, February 19, 2016 12:18 PM > To: NANOG list > Subject: Anyone from Verizon/MCI/UUNet ? > > > We have a netblock that was assigned to us out of http://65.192.0.0/11 a long > time ago. It has not been used in nearly a decade and still looks to be > assigned to us. I'd love to see it reclaimed and reused by someone who needs > it. Please contact me off list. > > thanks, > -Randy From faisal at snappytelecom.net Fri Feb 19 20:27:59 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 19 Feb 2016 20:27:59 +0000 (GMT) Subject: Softlayer / Blocking Cuba IP's ? Message-ID: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> Hello All, This is a shout out to Softlayer Network Admin / Policy folks... We just went thru a painful process to find out that Softlayer has recently decided to block Cuba IP Address Space....(on their cloud services). I am not a politician, nor any kind of a policy expert, However I have a ?questions for the SoftLayer folks... On What basis, legal requirement, logic, ?have they taken on the responsibility to implement such a Block ? Considering the fact that such a block was just put in place about a week ago ? Last time I checked, blocking any part of the world is not part of any legal requirements on any Global Service Provider ? other than a 'company policy' ? Also, the Last time I checked the US Cuba relations are getting better not worse! Would love to know what was the reasoning behind such action ! Thank you. Faisal Imtiaz Snappy Internet & Telecom From collin at averysmallbird.com Fri Feb 19 21:04:00 2016 From: collin at averysmallbird.com (Collin Anderson) Date: Fri, 19 Feb 2016 16:04:00 -0500 Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> Message-ID: Being as Softlayer is owned by IBM and headquartered in Virginia, they are pretty bound by U.S. sanctions policy, although this is obviously overcompliance. Essentially if there was to be a prohibited customer and a threat of enforcement, they want to be able to say they took extreme steps to prevent use of their network in those countries. This is also unfortunately a common sanctions compliance practice by service providers -- GoDaddy had done so for years until recently and Google continues to for GAE and GCE. Apparently Softlayer's network change was put into place a couple of weeks ago, and covers all the comprehensively sanctioned countries -- Iran, Cuba, Syria, North Korea and Sudan (should block Crimea as well in that case). It's not clear that their customers know they are blocked from something like 150 million potential users, and you are right, in fact the Cuba sanctions regulations were modified last month to expand authorizations on such transaction. It's extremely counterproductive and in direct contradiction to well established policy on Internet access in sanctioned countries. On Fri, Feb 19, 2016 at 3:27 PM, Faisal Imtiaz wrote: > > Hello All, > > This is a shout out to Softlayer Network Admin / Policy folks... > > We just went thru a painful process to find out that Softlayer has > recently decided to block Cuba IP Address Space....(on their cloud > services). > > I am not a politician, nor any kind of a policy expert, However I have a > questions for the SoftLayer folks... > > On What basis, legal requirement, logic, have they taken on the > responsibility to implement such a Block ? > > Considering the fact that such a block was just put in place about a week > ago ? > Last time I checked, blocking any part of the world is not part of any > legal requirements on any Global Service Provider ? other than a 'company > policy' ? > > Also, the Last time I checked the US Cuba relations are getting better not > worse! > > Would love to know what was the reasoning behind such action ! > > Thank you. > > Faisal Imtiaz > Snappy Internet & Telecom > -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. From nanog at ics-il.net Fri Feb 19 21:11:38 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 19 Feb 2016 15:11:38 -0600 (CST) Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> Message-ID: <983819455.3887.1455916294225.JavaMail.mhammett@ThunderFuck> http://www.datacenterknowledge.com/archives/2016/02/11/ibm-softlayer-blocks-services-iran-us-lifts-sanctions/ This is likely the same situation. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Faisal Imtiaz" To: "nanog list" Sent: Friday, February 19, 2016 2:27:59 PM Subject: Softlayer / Blocking Cuba IP's ? Hello All, This is a shout out to Softlayer Network Admin / Policy folks... We just went thru a painful process to find out that Softlayer has recently decided to block Cuba IP Address Space....(on their cloud services). I am not a politician, nor any kind of a policy expert, However I have a questions for the SoftLayer folks... On What basis, legal requirement, logic, have they taken on the responsibility to implement such a Block ? Considering the fact that such a block was just put in place about a week ago ? Last time I checked, blocking any part of the world is not part of any legal requirements on any Global Service Provider ? other than a 'company policy' ? Also, the Last time I checked the US Cuba relations are getting better not worse! Would love to know what was the reasoning behind such action ! Thank you. Faisal Imtiaz Snappy Internet & Telecom From faisal at snappytelecom.net Fri Feb 19 21:39:41 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 19 Feb 2016 21:39:41 +0000 (GMT) Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> Message-ID: <1570980303.2419260.1455917981357.JavaMail.zimbra@snappytelecom.net> Yep, this is a classic case of Corporate Stupidity, "We don't want to deal with any possibility of an exposure, so we are going to take a self initiated actions to make our network becomes a cordoned off island'.... Oops, the fact that we are a communications service provider where such rules don't apply seems to get lost since no one wants to stick their neck out or use some brain cells for thinking things thru.. Anyhow, for those who are wondering how this has a trickle down affect !.... Well our customer is one of the few licensed charter flight operators to Cuba... There has to be information exchange in regards to these flights and passengers before the they are allowed to travel/ take off etc etc... So, out of the blue, after years and years of everything working, suddenly emails flowing thru spam filtering service hosted on Softlayer Cloud, totally blocked any / all emails from Cuba from coming thru... We just spent last 10 days tracking everything down .... !!!!!! Happy Friday to everyone ! Faisal Imtiaz Snappy Internet & Telecom > From: "Collin Anderson" > To: "Faisal Imtiaz" > Cc: "nanog list" > Sent: Friday, February 19, 2016 4:04:00 PM > Subject: Re: Softlayer / Blocking Cuba IP's ? > Being as Softlayer is owned by IBM and headquartered in Virginia, they are > pretty bound by U.S. sanctions policy, although this is obviously > overcompliance. Essentially if there was to be a prohibited customer and a > threat of enforcement, they want to be able to say they took extreme steps to > prevent use of their network in those countries. > This is also unfortunately a common sanctions compliance practice by service > providers -- GoDaddy had done so for years until recently and Google continues > to for GAE and GCE. Apparently Softlayer's network change was put into place a > couple of weeks ago, and covers all the comprehensively sanctioned countries -- > Iran, Cuba, Syria, North Korea and Sudan (should block Crimea as well in that > case). > It's not clear that their customers know they are blocked from something like > 150 million potential users, and you are right, in fact the Cuba sanctions > regulations were modified last month to expand authorizations on such > transaction. It's extremely counterproductive and in direct contradiction to > well established policy on Internet access in sanctioned countries. > On Fri, Feb 19, 2016 at 3:27 PM, Faisal Imtiaz < faisal at snappytelecom.net > > wrote: >> Hello All, >> This is a shout out to Softlayer Network Admin / Policy folks... >> We just went thru a painful process to find out that Softlayer has recently >> decided to block Cuba IP Address Space....(on their cloud services). >> I am not a politician, nor any kind of a policy expert, However I have a >> questions for the SoftLayer folks... >> On What basis, legal requirement, logic, have they taken on the responsibility >> to implement such a Block ? >> Considering the fact that such a block was just put in place about a week ago ? >> Last time I checked, blocking any part of the world is not part of any legal >> requirements on any Global Service Provider ? other than a 'company policy' ? >> Also, the Last time I checked the US Cuba relations are getting better not >> worse! >> Would love to know what was the reasoning behind such action ! >> Thank you. >> Faisal Imtiaz >> Snappy Internet & Telecom > -- > Collin David Anderson > averysmallbird.com | @cda | Washington, D.C. From collin at averysmallbird.com Fri Feb 19 21:48:53 2016 From: collin at averysmallbird.com (Collin Anderson) Date: Fri, 19 Feb 2016 16:48:53 -0500 Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <1570980303.2419260.1455917981357.JavaMail.zimbra@snappytelecom.net> References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> <1570980303.2419260.1455917981357.JavaMail.zimbra@snappytelecom.net> Message-ID: On Fri, Feb 19, 2016 at 4:39 PM, Faisal Imtiaz wrote: > So, out of the blue, after years and years of everything working, suddenly > emails flowing thru spam filtering service hosted on Softlayer Cloud, > totally blocked any / all emails from Cuba from coming thru... We just > spent last 10 days tracking everything down .... > That's a terrible mess, and vividly illustrates how such poor compliance decision-making clobbers a policy that the U.S. is attempting to promote (both Internet and flights). Protecting Internet access in sanctioned countries has been a longtime advocacy project of mine, and something that from a legal perspective there has been pretty considerable success on. These sorts of case studies are helpful, so please feel free to drop a note if such issues arise in the future. -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. From faisal at snappytelecom.net Fri Feb 19 23:21:00 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 19 Feb 2016 23:21:00 +0000 (GMT) Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> Message-ID: <140657994.2420389.1455924060661.JavaMail.zimbra@snappytelecom.net> Ola Carlos, I am very familiar with Govt. instituted restrictions, and yes, people always find ways to get around it. I cannot speak for the Cuban Gov. nor for the US Gov. as to what they decide to do and when. What was/is irksome about Softlayer's decision is the following:- 1) Unilateral implementation of a restricted policy without any notification. 2) The broad stroke implementation of a Gov Policy that does not apply to the communication service they applied the policy to. i.e. As much as we all dislike Dictatorial Behavior, and we fully recognize Softlayer is a Private Entity, who can exercise it's right to act Dictatorially, Such behavior in the overall community (Internet) is frowned upon and (as it should) have a long term negative affect to business. Saludos. 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 > From: "Carlos A. Carnero Delgado" > To: "Faisal Imtiaz" > Cc: "nanog list" > Sent: Friday, February 19, 2016 6:08:42 PM > Subject: Re: Softlayer / Blocking Cuba IP's ? > Hi, > (disclaimer: I'm Cuban national, living in Cuba, and a long time lurker in this > great list) > 2016-02-19 15:27 GMT-05:00 Faisal Imtiaz < faisal at snappytelecom.net > : >> Considering the fact that such a block was just put in place about a week ago ? >> Last time I checked, blocking any part of the world is not part of any legal >> requirements on any Global Service Provider ? other than a 'company policy' ? > Being denied access to services, as a Cuban national, is something that we've > all experienced here and we (sadly) have come to accept it as a fact of life. > Sometimes we resort to proxies/VPNs in order to conceal our origin -- and by a > similar token, sometimes, our destination ;). > However, there are a couple of things that have made me wondering how arbitrary > decisions can be. I think sometimes it just boils down to specific provider > policies that try to (maybe rightfully) cover their bottoms in the light of the > law. For instance, I can't hide the fact that I have access to Gmail; but at > the same time there are many Google properties and services than I can't. There > are many companies, global companies, that I can't access, and others are open > to us which are, paradoxically, completely based on the US and under US law > (won't name them publicly to avoid potential damage). > Any way, I'm going back to lurk mode. However, feel free to ask anything, on- of > offlist. And I thank you all for this wonderful resource. > Carlos. From frnkblk at iname.com Sat Feb 20 00:57:27 2016 From: frnkblk at iname.com (frnkblk at iname.com) Date: Fri, 19 Feb 2016 18:57:27 -0600 Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <140657994.2420389.1455924060661.JavaMail.zimbra@snappytelecom.net> References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> <140657994.2420389.1455924060661.JavaMail.zimbra@snappytelecom.net> Message-ID: <001901d16b79$ac32cbc0$04986340$@iname.com> Official statement here: https://knowledgelayer.softlayer.com/faq/softlayer-network-wide-ip-blocking Frank -----Original Message----- From: NANOG [mailto:nanog-bounces+frnkblk=iname.com at nanog.org] On Behalf Of Faisal Imtiaz Sent: Friday, February 19, 2016 5:21 PM To: Carlos A. Carnero Delgado Cc: nanog list Subject: Re: Softlayer / Blocking Cuba IP's ? Ola Carlos, I am very familiar with Govt. instituted restrictions, and yes, people always find ways to get around it. I cannot speak for the Cuban Gov. nor for the US Gov. as to what they decide to do and when. What was/is irksome about Softlayer's decision is the following:- 1) Unilateral implementation of a restricted policy without any notification. 2) The broad stroke implementation of a Gov Policy that does not apply to the communication service they applied the policy to. i.e. As much as we all dislike Dictatorial Behavior, and we fully recognize Softlayer is a Private Entity, who can exercise it's right to act Dictatorially, Such behavior in the overall community (Internet) is frowned upon and (as it should) have a long term negative affect to business. Saludos. 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 > From: "Carlos A. Carnero Delgado" > To: "Faisal Imtiaz" > Cc: "nanog list" > Sent: Friday, February 19, 2016 6:08:42 PM > Subject: Re: Softlayer / Blocking Cuba IP's ? > Hi, > (disclaimer: I'm Cuban national, living in Cuba, and a long time lurker in this > great list) > 2016-02-19 15:27 GMT-05:00 Faisal Imtiaz < faisal at snappytelecom.net > : >> Considering the fact that such a block was just put in place about a week ago ? >> Last time I checked, blocking any part of the world is not part of any legal >> requirements on any Global Service Provider ? other than a 'company policy' ? > Being denied access to services, as a Cuban national, is something that we've > all experienced here and we (sadly) have come to accept it as a fact of life. > Sometimes we resort to proxies/VPNs in order to conceal our origin -- and by a > similar token, sometimes, our destination ;). > However, there are a couple of things that have made me wondering how arbitrary > decisions can be. I think sometimes it just boils down to specific provider > policies that try to (maybe rightfully) cover their bottoms in the light of the > law. For instance, I can't hide the fact that I have access to Gmail; but at > the same time there are many Google properties and services than I can't. There > are many companies, global companies, that I can't access, and others are open > to us which are, paradoxically, completely based on the US and under US law > (won't name them publicly to avoid potential damage). > Any way, I'm going back to lurk mode. However, feel free to ask anything, on- of > offlist. And I thank you all for this wonderful resource. > Carlos. From faisal at snappytelecom.net Sat Feb 20 02:49:22 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 20 Feb 2016 02:49:22 +0000 (GMT) Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <001901d16b79$ac32cbc0$04986340$@iname.com> References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> <140657994.2420389.1455924060661.JavaMail.zimbra@snappytelecom.net> <001901d16b79$ac32cbc0$04986340$@iname.com> Message-ID: <221300378.2422605.1455936562621.JavaMail.zimbra@snappytelecom.net> Thanks, But this just exasperates their Stupidity and in-correct assumption that somehow allowing internet communications is equal to doing business with these countries. They need to get better legal advisers, may be people who can think and actually understand what is the internet... so that they know the difference.... (in their own words) The United States prohibits most commercial transactions........ Tcp/IP connections are NOT COMMERCIAL TRANSACTIONS !!! So what are we going to see from them next .. A Posted Policy at the Entrance to the DataCenter " Due to US Economic Sanctions.. We will not allow entry to people who speak Spanish (Cuba),Farsi (Iran), Korean, and Arabic (Sudan) but if you are Sudanese and speak Dinka, you will be allowed" Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Frank Bulk" > To: "Faisal Imtiaz" > Cc: "nanog list" > Sent: Friday, February 19, 2016 7:57:27 PM > Subject: RE: Softlayer / Blocking Cuba IP's ? > Official statement here: > https://knowledgelayer.softlayer.com/faq/softlayer-network-wide-ip-blocking > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+frnkblk=iname.com at nanog.org] On Behalf Of > Faisal Imtiaz > Sent: Friday, February 19, 2016 5:21 PM > To: Carlos A. Carnero Delgado > Cc: nanog list > Subject: Re: Softlayer / Blocking Cuba IP's ? > > Ola Carlos, > > I am very familiar with Govt. instituted restrictions, and yes, people always > find ways to get around it. I cannot speak for the Cuban Gov. nor for the US > Gov. as to what they decide to do and when. > > What was/is irksome about Softlayer's decision is the following:- > > 1) Unilateral implementation of a restricted policy without any notification. > > 2) The broad stroke implementation of a Gov Policy that does not apply to the > communication service they applied the policy to. > > i.e. As much as we all dislike Dictatorial Behavior, and we fully recognize > Softlayer is a Private Entity, who can exercise it's right to act > Dictatorially, Such behavior in the overall community (Internet) is frowned > upon and (as it should) have a long term negative affect to business. > > Saludos. > > 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 > >> From: "Carlos A. Carnero Delgado" >> To: "Faisal Imtiaz" >> Cc: "nanog list" >> Sent: Friday, February 19, 2016 6:08:42 PM >> Subject: Re: Softlayer / Blocking Cuba IP's ? > >> Hi, > >> (disclaimer: I'm Cuban national, living in Cuba, and a long time lurker in this >> great list) > >> 2016-02-19 15:27 GMT-05:00 Faisal Imtiaz < faisal at snappytelecom.net > : > >>> Considering the fact that such a block was just put in place about a week ago ? >>> Last time I checked, blocking any part of the world is not part of any legal >>> requirements on any Global Service Provider ? other than a 'company policy' ? > >> Being denied access to services, as a Cuban national, is something that we've >> all experienced here and we (sadly) have come to accept it as a fact of life. >> Sometimes we resort to proxies/VPNs in order to conceal our origin -- and by a >> similar token, sometimes, our destination ;). > >> However, there are a couple of things that have made me wondering how arbitrary >> decisions can be. I think sometimes it just boils down to specific provider >> policies that try to (maybe rightfully) cover their bottoms in the light of the >> law. For instance, I can't hide the fact that I have access to Gmail; but at >> the same time there are many Google properties and services than I can't. There >> are many companies, global companies, that I can't access, and others are open >> to us which are, paradoxically, completely based on the US and under US law >> (won't name them publicly to avoid potential damage). > >> Any way, I'm going back to lurk mode. However, feel free to ask anything, on- of >> offlist. And I thank you all for this wonderful resource. > > Carlos. From tony at wicks.co.nz Sat Feb 20 03:18:15 2016 From: tony at wicks.co.nz (Tony Wicks) Date: Sat, 20 Feb 2016 16:18:15 +1300 Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <221300378.2422605.1455936562621.JavaMail.zimbra@snappytelecom.net> References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> <140657994.2420389.1455924060661.JavaMail.zimbra@snappytelecom.net> <001901d16b79$ac32cbc0$04986340$@iname.com> <221300378.2422605.1455936562621.JavaMail.zimbra@snappytelecom.net> Message-ID: <003b01d16b8d$56ee3eb0$04cabc10$@wicks.co.nz> > >Cc: nanog list >Subject: Re: Softlayer / Blocking Cuba IP's ? > I had a couple of VM's (personal mail/web hosting) with a provider who used Softlayer for transit. About a month ago Softlayer (without any notice or warning) blocked all outgoing port 25 at multipole datacentres for this provider. It took the hosting provider half a day to work out what had happened. Needless to say as much as I liked the company I had to move my hosts elsewhere (they did refund me to their credit). It seems that someone at Softlayer is extremely aggressive on their blocking policies to the point of making their service unusable. I would highly recommend the community votes with its wallet when it comes to these turkeys. From yang.yu.list at gmail.com Sat Feb 20 08:37:03 2016 From: yang.yu.list at gmail.com (Yang Yu) Date: Sat, 20 Feb 2016 02:37:03 -0600 Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <003b01d16b8d$56ee3eb0$04cabc10$@wicks.co.nz> References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> <140657994.2420389.1455924060661.JavaMail.zimbra@snappytelecom.net> <001901d16b79$ac32cbc0$04986340$@iname.com> <221300378.2422605.1455936562621.JavaMail.zimbra@snappytelecom.net> <003b01d16b8d$56ee3eb0$04cabc10$@wicks.co.nz> Message-ID: On Fri, Feb 19, 2016 at 9:18 PM, Tony Wicks wrote: > I had a couple of VM's (personal mail/web hosting) with a provider who used Softlayer for transit. About a month ago Softlayer (without any notice or warning) blocked all outgoing port 25 at multipole datacentres for this provider. It took the hosting provider half a day to work out what had happened. Needless to say as much as I liked the company I had to move my hosts elsewhere (they did refund me to their credit). It seems that someone at Softlayer is extremely aggressive on their blocking policies to the point of making their service unusable. I would highly recommend the community votes with its wallet when it comes to these turkeys. > http://knowledgelayer.softlayer.com/content/outbound-email-port-25 The announcement supposedly came out sometime late last year. "We offer a trusted third party email relay service from SendGrid for those customers who need to be able to send outbound email from their domains or applications." It seems some indirect customers were not informed of it until it went into effect on Feb 1, 2016. For me the monitoring service on port 25 stopped working. From s+Mailinglisten.nanog at sloc.de Sat Feb 20 12:08:23 2016 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Sat, 20 Feb 2016 13:08:23 +0100 Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> Message-ID: <56C85737.6070606@sloc.de> Yep, see here https://drive.google.com/file/d/0B5kLBHCcFJjFREtoMWtzMXljWXc/view?usp=sharing No prefix responds. Best, Sebastian Am 19.02.2016 um 21:27 schrieb Faisal Imtiaz: > Hello All, > > This is a shout out to Softlayer Network Admin / Policy folks... > > We just went thru a painful process to find out that Softlayer has recently decided to block Cuba IP Address Space....(on their cloud services). > > I am not a politician, nor any kind of a policy expert, However I have a questions for the SoftLayer folks... > > On What basis, legal requirement, logic, have they taken on the responsibility to implement such a Block ? > > Considering the fact that such a block was just put in place about a week ago ? > Last time I checked, blocking any part of the world is not part of any legal requirements on any Global Service Provider ? other than a 'company policy' ? > > Also, the Last time I checked the US Cuba relations are getting better not worse! > > Would love to know what was the reasoning behind such action ! > > Thank you. > > Faisal Imtiaz > Snappy Internet & Telecom From mkamal at noor.net Sat Feb 20 15:11:04 2016 From: mkamal at noor.net (Mohamed Kamal) Date: Sat, 20 Feb 2016 17:11:04 +0200 Subject: Cisco's IOS-XE and PCEP implementation In-Reply-To: <55255206.2010606@noor.net> References: <55196012.9050508@noor.net> <55219036.2080403@noor.net> <5524F0C3.3020704@noor.net> <55252903.71518c0a.03cc.55c8@mx.google.com> <55255206.2010606@noor.net> Message-ID: <56C88208.6050205@noor.net> Just to follow-up; Cisco has offered segment-routing and entropy label use starting from 3.16/3.17 respectively. Do Cisco see the 1k platform as an enterprise router?! Am I the only one here that assume that BGP-LS and PCEP support in the XE platforms is a must now after releasing the SR support? Mohamed Kamal Core Network Sr. Engineer On 4/8/2015 6:06 PM, Mohamed Kamal wrote: > Yes, indeed! Things like VPLS, full-features ESI and PCEP exist on > IOS-XR but not IOS and IOS-XE! > > ISSU and HA operates differently between IOS-XE and NX-OS! > > Their claim is not even logical, the ASR1k is supporting 600 TE tunnels > head-end, and up-to 10k midpoint! So, if I had an average of 30 ASR1k in > the edge, each with 500 TE, there will be over 15000 TE tunnels in the > core which will be creating a need for automatic tool such as NorthStar > of Juniper! > > Mohamed Kamal > Core Network Sr. Engineer > > On 4/8/2015 4:11 PM, Phil Bedard wrote: >> One of the downsides to having four (at least) different control plane >> operating systems across your product lines. >> >> Phil >> ------------------------------------------------------------------------ >> From: Mohamed Kamal >> Sent: ?4/?8/?2015 5:13 AM >> To: NANOG >> Subject: Re: Cisco's IOS-XE and PCEP implementation >> >> Here is Cisco's reply! >> >> ?Given PCEP?s main use-case is inter-area TE tunnels (or SDN controller in >> TE environment) and ASR1K is not marketed for TE, support is unlikely? >> >> What is .. "not marketed for TE"?! >> >> All in all, I don't mind replacing them with some cheaper, powerful, >> flexible and SDN-ready juniper MX that are marketed for TE. >> >> Mohamed Kamal >> Core Network Sr. Engineer >> >> On 4/5/2015 10:42 PM, Mohamed Kamal wrote: >>>> and hence being implemented on IOS-XR within the Cisco environment >> today >>> I disagree! .. Engineering is all about optimization, and using an ASR1k >>> (which is being marketed as an "edge/PE router") in my edge doesn't mean >>> that my network is not a "high-scale environment", it does mean that it >>> fits my needs in this location, where other IOS-XR (ASR9k) fits in >> others. >>> Plus, PCEP is no magic, Juniper's MX series starting from the vMX is >>> supporting PCEP. They didn't claim that, a "higher-scale environment" is >>> being required for this. >>> >>>> the demand for online calculation has increased - either due to >> dependencies for new TE path-instantiating protocols (e.g., SR), or >> more complex constraints that cannot be well met by offline >> calculation or CSPF >>> That's why PCEP support should be added to the road-map in the near >> future. >>> Mohamed Kamal >>> Core Network Sr. Engineer >>> >>> On 4/5/2015 8:33 PM, Rob Shakir wrote: >>>> On 30 March 2015 at 15:42:59, Mohamed Kamal (mkamal at noor.net) wrote: >>>>> I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till >> now?! >>>>> Should I be getting a 9k/CRS on the edge to implement an automatic >> tool >>>>> to build MPLS-TE tunnels! >>>> In general, PCE(P) implementations have been limited. IMHO the last >> 10 years of RSVP-TE management has generally been done with auto-mesh >> tools, or in-house driven offline path calculation tools (e.g., WANDL, >> Cariden, Aria?). >>>> As such, the demand for online calculation has increased - either >> due to dependencies for new TE path-instantiating protocols (e.g., >> SR), or more complex constraints that cannot be well met by offline >> calculation or CSPF (e.g., path-diversity with disjoint head-end PEs). >> This demand is mainly coming in higher-scale environments - and hence >> being implemented on IOS-XR within the Cisco environment today. I >> expect this is why IOS-XE is lagging. There are certainly requests for >> support - but as Mark says, you?ll need to interface with your account >> team to figure out when code will be available for your platform. >>>> As to whether you should buy an IOS XR device for your edge, I?m >> not sure what kind of logic would mean that device selection is solely >> based on PCEP support :-). I would certainly look more into the >> existing ?automatic? tools, and possibilities for offline calculation >> in the interim period. >>>> r. >>>> > From baconzombie at gmail.com Sat Feb 20 15:39:43 2016 From: baconzombie at gmail.com (Bacon Zombie) Date: Sat, 20 Feb 2016 16:39:43 +0100 Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> <140657994.2420389.1455924060661.JavaMail.zimbra@snappytelecom.net> <001901d16b79$ac32cbc0$04986340$@iname.com> <221300378.2422605.1455936562621.JavaMail.zimbra@snappytelecom.net> <003b01d16b8d$56ee3eb0$04cabc10$@wicks.co.nz> Message-ID: They have not blocked port 25 on their "legacy" EU Servers. On 20 Feb 2016 9:39 am, "Yang Yu" wrote: > On Fri, Feb 19, 2016 at 9:18 PM, Tony Wicks wrote: > > I had a couple of VM's (personal mail/web hosting) with a provider who > used Softlayer for transit. About a month ago Softlayer (without any notice > or warning) blocked all outgoing port 25 at multipole datacentres for this > provider. It took the hosting provider half a day to work out what had > happened. Needless to say as much as I liked the company I had to move my > hosts elsewhere (they did refund me to their credit). It seems that someone > at Softlayer is extremely aggressive on their blocking policies to the > point of making their service unusable. I would highly recommend the > community votes with its wallet when it comes to these turkeys. > > > > http://knowledgelayer.softlayer.com/content/outbound-email-port-25 > > The announcement supposedly came out sometime late last year. > "We offer a trusted third party email relay service from SendGrid for > those customers who need to be able to send outbound email from their > domains or applications." > > It seems some indirect customers were not informed of it until it went > into effect on Feb 1, 2016. For me the monitoring service on port 25 > stopped working. > From vireak.ouk at gmail.com Thu Feb 18 04:36:28 2016 From: vireak.ouk at gmail.com (Vireak Ouk) Date: Thu, 18 Feb 2016 11:36:28 +0700 Subject: Agoda GeoIP issue Message-ID: Greetings from Cambodia Could anyone from Agoda contact me off-list? It's regarding some discrepancies of Agoda rates which could be caused by GeoIP isse. We had tried to report via the normal means but to no avail. Thanks in advance. Vireak From nanog at wjp.net Fri Feb 19 10:30:25 2016 From: nanog at wjp.net (nanog) Date: Fri, 19 Feb 2016 03:30:25 -0700 Subject: Remote hands mailing lists? Message-ID: <56C6EEC1.5040609@wjp.net> Sorry if this off-topic. Are there any mailing lists/forums/websites that independent techs can post availability for remote hands work? I just got let go from my company and am looking for anyone who needs remote hands work in Phoenix. Server/wiring/fiber/dwdm/design/button-pushing/consulting/etc. Thanks- and apologies again if this isn't on-topic. b From carloscarnero at gmail.com Fri Feb 19 23:08:42 2016 From: carloscarnero at gmail.com (Carlos A. Carnero Delgado) Date: Fri, 19 Feb 2016 18:08:42 -0500 Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> Message-ID: Hi, (disclaimer: I'm Cuban national, living in Cuba, and a long time lurker in this great list) 2016-02-19 15:27 GMT-05:00 Faisal Imtiaz : > Considering the fact that such a block was just put in place about a week > ago ? > Last time I checked, blocking any part of the world is not part of any > legal requirements on any Global Service Provider ? other than a 'company > policy' ? > Being denied access to services, as a Cuban national, is something that we've all experienced here and we (sadly) have come to accept it as a fact of life. Sometimes we resort to proxies/VPNs in order to conceal our origin -- and by a similar token, sometimes, our destination ;). However, there are a couple of things that have made me wondering how arbitrary decisions can be. I think sometimes it just boils down to specific provider policies that try to (maybe rightfully) cover their bottoms in the light of the law. For instance, I can't hide the fact that I have access to Gmail; but at the same time there are many Google properties and services than I can't. There are many companies, global companies, that I can't access, and others are open to us which are, paradoxically, completely based on the US and under US law (won't name them publicly to avoid potential damage). Any way, I'm going back to lurk mode. However, feel free to ask anything, on- of offlist. And I thank you all for this wonderful resource. Carlos. From morrowc.lists at gmail.com Sun Feb 21 02:31:39 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 20 Feb 2016 21:31:39 -0500 Subject: Remote hands mailing lists? In-Reply-To: <56C6EEC1.5040609@wjp.net> References: <56C6EEC1.5040609@wjp.net> Message-ID: I think (though I don't see much traffic on it): newhere at snausages.com works like this. On Fri, Feb 19, 2016 at 5:30 AM, nanog wrote: > Sorry if this off-topic. > > Are there any mailing lists/forums/websites that independent techs can post > availability for remote hands work? > > I just got let go from my company and am looking for anyone who needs remote > hands work in Phoenix. > Server/wiring/fiber/dwdm/design/button-pushing/consulting/etc. > > Thanks- and apologies again if this isn't on-topic. > > b From dcorbe at hammerfiber.com Sun Feb 21 06:54:50 2016 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Sun, 21 Feb 2016 01:54:50 -0500 Subject: Remote hands mailing lists? In-Reply-To: References: <56C6EEC1.5040609@wjp.net> Message-ID: <938F0D01-1396-4122-8978-A503AC69D931@hammerfiber.com> You may also want to try some places where content providers and content creators gather like webhostingtalk because there?s often small operators and individuals there trying to get their names known who may appreciate picking up extra work. > On Feb 20, 2016, at 9:31 PM, Christopher Morrow wrote: > > I think (though I don't see much traffic on it): > > newhere at snausages.com > > works like this. > > On Fri, Feb 19, 2016 at 5:30 AM, nanog wrote: >> Sorry if this off-topic. >> >> Are there any mailing lists/forums/websites that independent techs can post >> availability for remote hands work? >> >> I just got let go from my company and am looking for anyone who needs remote >> hands work in Phoenix. >> Server/wiring/fiber/dwdm/design/button-pushing/consulting/etc. >> >> Thanks- and apologies again if this isn't on-topic. >> >> b > From maxtul at netassist.ua Sun Feb 21 11:16:27 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 21 Feb 2016 13:16:27 +0200 Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <001901d16b79$ac32cbc0$04986340$@iname.com> References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> <140657994.2420389.1455924060661.JavaMail.zimbra@snappytelecom.net> <001901d16b79$ac32cbc0$04986340$@iname.com> Message-ID: <56C99C8B.1030103@netassist.ua> Why Crimea still not in the list? On 20.02.16 02:57, frnkblk at iname.com wrote: > Official statement here: https://knowledgelayer.softlayer.com/faq/softlayer-network-wide-ip-blocking > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+frnkblk=iname.com at nanog.org] On Behalf Of Faisal Imtiaz > Sent: Friday, February 19, 2016 5:21 PM > To: Carlos A. Carnero Delgado > Cc: nanog list > Subject: Re: Softlayer / Blocking Cuba IP's ? > > Ola Carlos, > > I am very familiar with Govt. instituted restrictions, and yes, people always find ways to get around it. I cannot speak for the Cuban Gov. nor for the US Gov. as to what they decide to do and when. > > What was/is irksome about Softlayer's decision is the following:- > > 1) Unilateral implementation of a restricted policy without any notification. > > 2) The broad stroke implementation of a Gov Policy that does not apply to the communication service they applied the policy to. > > i.e. As much as we all dislike Dictatorial Behavior, and we fully recognize Softlayer is a Private Entity, who can exercise it's right to act Dictatorially, Such behavior in the overall community (Internet) is frowned upon and (as it should) have a long term negative affect to business. > > Saludos. > > 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 > >> From: "Carlos A. Carnero Delgado" >> To: "Faisal Imtiaz" >> Cc: "nanog list" >> Sent: Friday, February 19, 2016 6:08:42 PM >> Subject: Re: Softlayer / Blocking Cuba IP's ? > >> Hi, > >> (disclaimer: I'm Cuban national, living in Cuba, and a long time lurker in this >> great list) > >> 2016-02-19 15:27 GMT-05:00 Faisal Imtiaz < faisal at snappytelecom.net > : > >>> Considering the fact that such a block was just put in place about a week ago ? >>> Last time I checked, blocking any part of the world is not part of any legal >>> requirements on any Global Service Provider ? other than a 'company policy' ? > >> Being denied access to services, as a Cuban national, is something that we've >> all experienced here and we (sadly) have come to accept it as a fact of life. >> Sometimes we resort to proxies/VPNs in order to conceal our origin -- and by a >> similar token, sometimes, our destination ;). > >> However, there are a couple of things that have made me wondering how arbitrary >> decisions can be. I think sometimes it just boils down to specific provider >> policies that try to (maybe rightfully) cover their bottoms in the light of the >> law. For instance, I can't hide the fact that I have access to Gmail; but at >> the same time there are many Google properties and services than I can't. There >> are many companies, global companies, that I can't access, and others are open >> to us which are, paradoxically, completely based on the US and under US law >> (won't name them publicly to avoid potential damage). > >> Any way, I'm going back to lurk mode. However, feel free to ask anything, on- of >> offlist. And I thank you all for this wonderful resource. >> Carlos. > > > From pavel.odintsov at gmail.com Sun Feb 21 11:45:38 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Sun, 21 Feb 2016 14:45:38 +0300 Subject: Softlayer / Blocking Cuba IP's ? In-Reply-To: <56C99C8B.1030103@netassist.ua> References: <1507585240.2418598.1455913679871.JavaMail.zimbra@snappytelecom.net> <140657994.2420389.1455924060661.JavaMail.zimbra@snappytelecom.net> <001901d16b79$ac32cbc0$04986340$@iname.com> <56C99C8B.1030103@netassist.ua> Message-ID: Hello! I have other question. Why somebody exists in this list? Nobody should be in this block list actually. If you ban some country because this country is bad (so really? One countries are worse than other, really? Who care in this evaluations? Some yet another "smart" government?) If you ask for block somebody you are becoming the worst person on the Whole Earth. This songs really like Internet Nazism. Just imagine world where you should drop all packets from martians because your government thinks they are stupid. Songs like Orwell 1984. Not so perfect way. >From my point if view nobody should block North Korea, Cuba or definitely Crimea because Internet is not is the politic game field. It's way to communicate. Both bad and good people could use it and nobody should care about "who can". On Sun, Feb 21, 2016 at 2:16 PM, Max Tulyev wrote: > Why Crimea still not in the list? > > On 20.02.16 02:57, frnkblk at iname.com wrote: >> Official statement here: https://knowledgelayer.softlayer.com/faq/softlayer-network-wide-ip-blocking >> >> Frank >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces+frnkblk=iname.com at nanog.org] On Behalf Of Faisal Imtiaz >> Sent: Friday, February 19, 2016 5:21 PM >> To: Carlos A. Carnero Delgado >> Cc: nanog list >> Subject: Re: Softlayer / Blocking Cuba IP's ? >> >> Ola Carlos, >> >> I am very familiar with Govt. instituted restrictions, and yes, people always find ways to get around it. I cannot speak for the Cuban Gov. nor for the US Gov. as to what they decide to do and when. >> >> What was/is irksome about Softlayer's decision is the following:- >> >> 1) Unilateral implementation of a restricted policy without any notification. >> >> 2) The broad stroke implementation of a Gov Policy that does not apply to the communication service they applied the policy to. >> >> i.e. As much as we all dislike Dictatorial Behavior, and we fully recognize Softlayer is a Private Entity, who can exercise it's right to act Dictatorially, Such behavior in the overall community (Internet) is frowned upon and (as it should) have a long term negative affect to business. >> >> Saludos. >> >> 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 >> >>> From: "Carlos A. Carnero Delgado" >>> To: "Faisal Imtiaz" >>> Cc: "nanog list" >>> Sent: Friday, February 19, 2016 6:08:42 PM >>> Subject: Re: Softlayer / Blocking Cuba IP's ? >> >>> Hi, >> >>> (disclaimer: I'm Cuban national, living in Cuba, and a long time lurker in this >>> great list) >> >>> 2016-02-19 15:27 GMT-05:00 Faisal Imtiaz < faisal at snappytelecom.net > : >> >>>> Considering the fact that such a block was just put in place about a week ago ? >>>> Last time I checked, blocking any part of the world is not part of any legal >>>> requirements on any Global Service Provider ? other than a 'company policy' ? >> >>> Being denied access to services, as a Cuban national, is something that we've >>> all experienced here and we (sadly) have come to accept it as a fact of life. >>> Sometimes we resort to proxies/VPNs in order to conceal our origin -- and by a >>> similar token, sometimes, our destination ;). >> >>> However, there are a couple of things that have made me wondering how arbitrary >>> decisions can be. I think sometimes it just boils down to specific provider >>> policies that try to (maybe rightfully) cover their bottoms in the light of the >>> law. For instance, I can't hide the fact that I have access to Gmail; but at >>> the same time there are many Google properties and services than I can't. There >>> are many companies, global companies, that I can't access, and others are open >>> to us which are, paradoxically, completely based on the US and under US law >>> (won't name them publicly to avoid potential damage). >> >>> Any way, I'm going back to lurk mode. However, feel free to ask anything, on- of >>> offlist. And I thank you all for this wonderful resource. >>> Carlos. >> >> >> > -- Sincerely yours, Pavel Odintsov From joe at nethead.com Sun Feb 21 09:49:05 2016 From: joe at nethead.com (Joe Hamelin) Date: Sun, 21 Feb 2016 01:49:05 -0800 Subject: Remote hands mailing lists? In-Reply-To: <938F0D01-1396-4122-8978-A503AC69D931@hammerfiber.com> References: <56C6EEC1.5040609@wjp.net> <938F0D01-1396-4122-8978-A503AC69D931@hammerfiber.com> Message-ID: Check with colo brokers like Stratcore too. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 On Sat, Feb 20, 2016 at 10:54 PM, Daniel Corbe wrote: > You may also want to try some places where content providers and content > creators gather like webhostingtalk because there?s often small operators > and individuals there trying to get their names known who may appreciate > picking up extra work. > > > On Feb 20, 2016, at 9:31 PM, Christopher Morrow > wrote: > > > > I think (though I don't see much traffic on it): > > > > newhere at snausages.com > > > > works like this. > > > > On Fri, Feb 19, 2016 at 5:30 AM, nanog wrote: > >> Sorry if this off-topic. > >> > >> Are there any mailing lists/forums/websites that independent techs can > post > >> availability for remote hands work? > >> > >> I just got let go from my company and am looking for anyone who needs > remote > >> hands work in Phoenix. > >> Server/wiring/fiber/dwdm/design/button-pushing/consulting/etc. > >> > >> Thanks- and apologies again if this isn't on-topic. > >> > >> b > > > > From jerome at ceriz.fr Mon Feb 22 10:03:07 2016 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Mon, 22 Feb 2016 11:03:07 +0100 Subject: About inetnum "ownership" Message-ID: <56CADCDB.2000905@ceriz.fr> Hi, How come we've had an inetnum market in place whereas an inetnum cannot have a market value ? It's my understanding that the IP adress space is nothing but numbers and that RIR/LIRs are only responsible for the uniqueness of allocations and assignements, that is, a transfer of liability over a shared and common immaterial resource, between community members. I'm wondering how did we made "Temporary and conditionnal liabality transfer" a synonym of "perpetual and inconditional usufruct transfer". May you please enlight me ? Thanks ! -- J?r?me Nicolle +33 6 19 31 27 14 From rdrake at direcpath.com Mon Feb 22 15:22:56 2016 From: rdrake at direcpath.com (Robert Drake) Date: Mon, 22 Feb 2016 10:22:56 -0500 Subject: About inetnum "ownership" In-Reply-To: <56CADCDB.2000905@ceriz.fr> References: <56CADCDB.2000905@ceriz.fr> Message-ID: <0cbe2933-f5b8-e88a-b417-b838feef985a@direcpath.com> On 2/22/2016 5:03 AM, J?r?me Nicolle wrote: > I'm wondering how did we made "Temporary and conditionnal liabality > transfer" a synonym of "perpetual and inconditional usufruct transfer". > > May you please enlight me ? There are always ways around the system. I suspect what has happened is that IRR's require that a company hold addresses but they have provisions for companies to be sold or change names. So the IP address brokers probably sell a "business" with the IP address block. It might be simpler than that. I don't know what the loopholes are but I'm sure some lawyers have read through all the documents and found a way. I imagine it's never been tested in court because proving the system is being exploited would be hard, and the parties with a vested interest probably don't have the resources to make a fight of it. > > Thanks ! > > -- J?r?me Nicolle +33 6 19 31 27 14 Thanks, Robert From matthew at matthew.at Mon Feb 22 15:57:59 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 22 Feb 2016 07:57:59 -0800 Subject: About inetnum "ownership" In-Reply-To: <56CADCDB.2000905@ceriz.fr> References: <56CADCDB.2000905@ceriz.fr> Message-ID: <52D06627-A948-4145-9C39-19E1266DEFC4@matthew.at> How come we have real property "ownership"? It is nothing but a record of invisible boundary lines on the surface of the earth, despite the earth and its land area being a shared resource for its animal and plant inhabitants. Matthew Kaufman (Sent from my iPhone) > On Feb 22, 2016, at 2:03 AM, J?r?me Nicolle wrote: > > Hi, > > How come we've had an inetnum market in place whereas an inetnum cannot > have a market value ? > > It's my understanding that the IP adress space is nothing but numbers > and that RIR/LIRs are only responsible for the uniqueness of allocations > and assignements, that is, a transfer of liability over a shared and > common immaterial resource, between community members. > > I'm wondering how did we made "Temporary and conditionnal liabality > transfer" a synonym of "perpetual and inconditional usufruct transfer". > > May you please enlight me ? > > Thanks ! > > -- > J?r?me Nicolle > +33 6 19 31 27 14 From josh at imaginenetworksllc.com Mon Feb 22 16:46:07 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 22 Feb 2016 11:46:07 -0500 Subject: Frontier Dayton area outage Message-ID: Juniper router is failing, down for the second time this morning at the moment. Master ticket msi 163523an tier 2 is actively looking now Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 From SNaslund at medline.com Mon Feb 22 16:48:23 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 22 Feb 2016 16:48:23 +0000 Subject: About inetnum "ownership" In-Reply-To: <52D06627-A948-4145-9C39-19E1266DEFC4@matthew.at> References: <56CADCDB.2000905@ceriz.fr> <52D06627-A948-4145-9C39-19E1266DEFC4@matthew.at> Message-ID: <9578293AE169674F9A048B2BC9A081B401C9C011CE@MUNPRDMBXA1.medline.com> Simple to answer. 1. Address space is finite in size, therefore in the V4 space more people want addresses than there is available space. Hence it has value because demand exceeds supply. 2. Managing address space allocations is not a zero cost effort, therefore the RIRs charge a price for that. Anything that costs money to acquire presumably has value. Steven Naslund Chicago IL > On Feb 22, 2016, at 2:03 AM, J?r?me Nicolle wrote: > > Hi, > > How come we've had an inetnum market in place whereas an inetnum > cannot have a market value ? > > It's my understanding that the IP adress space is nothing but numbers > and that RIR/LIRs are only responsible for the uniqueness of > allocations and assignements, that is, a transfer of liability over a > shared and common immaterial resource, between community members. > > I'm wondering how did we made "Temporary and conditionnal liabality > transfer" a synonym of "perpetual and inconditional usufruct transfer". > > May you please enlight me ? > > Thanks ! > > -- > J?r?me Nicolle > +33 6 19 31 27 14 From josh at imaginenetworksllc.com Mon Feb 22 16:49:28 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 22 Feb 2016 11:49:28 -0500 Subject: Frontier Dayton area outage In-Reply-To: References: Message-ID: Back up 11:48 EST for now Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Feb 22, 2016 at 11:46 AM, Josh Luthman wrote: > Juniper router is failing, down for the second time this morning at the > moment. > > Master ticket msi 163523an tier 2 is actively looking now > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > From SNaslund at medline.com Mon Feb 22 16:50:43 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 22 Feb 2016 16:50:43 +0000 Subject: About inetnum "ownership" References: <56CADCDB.2000905@ceriz.fr> <52D06627-A948-4145-9C39-19E1266DEFC4@matthew.at> Message-ID: <9578293AE169674F9A048B2BC9A081B401C9C011E0@MUNPRDMBXA1.medline.com> Oh, and I forgot to add...the number in and of itself does not have a value. The right to use that number within the Internet connected network is what has value. Steven Naslund Chicago IL Simple to answer. 1. Address space is finite in size, therefore in the V4 space more people want addresses than there is available space. Hence it has value because demand exceeds supply. 2. Managing address space allocations is not a zero cost effort, therefore the RIRs charge a price for that. Anything that costs money to acquire presumably has value. Steven Naslund Chicago IL > On Feb 22, 2016, at 2:03 AM, J?r?me Nicolle wrote: > > Hi, > > How come we've had an inetnum market in place whereas an inetnum > cannot have a market value ? > > It's my understanding that the IP adress space is nothing but numbers > and that RIR/LIRs are only responsible for the uniqueness of > allocations and assignements, that is, a transfer of liability over a > shared and common immaterial resource, between community members. > > I'm wondering how did we made "Temporary and conditionnal liabality > transfer" a synonym of "perpetual and inconditional usufruct transfer". > > May you please enlight me ? > > Thanks ! > > -- > J?r?me Nicolle > +33 6 19 31 27 14 From bill at herrin.us Mon Feb 22 16:57:12 2016 From: bill at herrin.us (William Herrin) Date: Mon, 22 Feb 2016 11:57:12 -0500 Subject: About inetnum "ownership" In-Reply-To: <56CADCDB.2000905@ceriz.fr> References: <56CADCDB.2000905@ceriz.fr> Message-ID: On Mon, Feb 22, 2016 at 5:03 AM, J?r?me Nicolle wrote: > It's my understanding that the IP adress space is nothing but numbers > and that RIR/LIRs are only responsible for the uniqueness of allocations > and assignements, that is, a transfer of liability over a shared and > common immaterial resource, between community members. Hi J?r?me, The short version is this: IP addresses are property. A few people get really bent out of shape if you say that IP addresses are property. And while extant, the legal precedent for IP addresses as property isn't as strong as might be nice. So, we mostly pay lip service to the folks who still want to claim that IP addresses are just integers even as we treat IP addresses like property. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From m4rtntns at gmail.com Tue Feb 23 00:06:59 2016 From: m4rtntns at gmail.com (Martin T) Date: Tue, 23 Feb 2016 02:06:59 +0200 Subject: common checks performed when passing on an IPv4 PA allocation from one end-customer to another In-Reply-To: References: <9D5C3AF1-B726-4344-912B-0AFF5849AE9B@gt86car.org.uk> Message-ID: In general, are there any other similar databases to DNSBL(used for fighting against spam) system? For example lets say that some institution holds a public database of IP addresses of web-servers which (regularly) serve malware and anyone can check if their IP addresses are listed there. Or for example public database of IP addresses of botnet members. The reason I ask is the same- I would like to be 100% sure that when I hand out a range of IPv4 addresses, which were previously used by some other customer, then those addresses were not abused in any way and new customer will not have any trouble with those addresses. thanks, Martin On Tue, Apr 28, 2015 at 4:23 PM, Martin T wrote: > Colin, > > this is a good idea, but in this case the network I am interested in > does not have a RIPE Atlas probe. > > > regards, > Martin > > On 4/28/15, Colin Johnston wrote: >> >> >> >>> On 28 Apr 2015, at 10:32, Martin T wrote: >>> >>> Hi, >>> >>> as far as I know, some large US Internet companies like Google, >>> Facebook or Amazon restrict access to some services for certain >>> regions like Crimea or countries like Iran or North Korea. Do they >>> rely on services like MaxMind? Or do they use some other method to >>> check the geographical location of IP address? If yes, then is there >>> an API to check if an address is allowed to use Google, Facebook, etc >>> services or not? >>> >> >> you could use ripe atlas selecting nodes in countries you require and >> destination facbook/google/amazon servers and check results >> >> Colin >> >> From JJaritsch at anexia-it.com Tue Feb 23 11:50:36 2016 From: JJaritsch at anexia-it.com (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Tue, 23 Feb 2016 11:50:36 +0000 Subject: Netflix spam after open connect appliance upgrade Message-ID: <8d84daf8e9d8485fb276b7bae7d9dfb2@anx-i-dag02.anx.local> Anyone else receiving update/upgrade notifications (after an open connect appliance upgrade) more than one time? cdn-noc at netflix.com is not responding so I try to reach someone from Netflix via NANOG ... if there's someone reading my message please contact me offlist. Thanks & best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: JJaritsch at anexia-it.com Web: http://www.anexia-it.com Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 From lorell at hathcock.org Tue Feb 23 13:12:23 2016 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 23 Feb 2016 07:12:23 -0600 Subject: APC vs UPC? Message-ID: <35EF9A4B-B9A1-485C-A8FA-06B5236B511E@hathcock.org> NANOGians: APC wins! My real question is surrounding the connection on the SFPs themselves. In general terms are the LC connectors on SFPs considered UPC or APC? If the answer is UPC and if I am inheriting and/or building a network of single mode fiber with APC SC connectors, then is the best practice to use LC UPC to SC APC fiber jumpers? If so, can anyone point me to a source for said jumpers that is (1) quick and (2) good? Any thoughts on the same idea of mismatched fiber jumpers connector types to use on OLMs and OLSs? OTDRs? The concern here is to use the best possible fiber connector types (e.g. APC or UPC) when connecting lasers to my OSP fiber which uses APC with consideration to the optimal connector type for the laser transceiver. My thoughts are to use fiber jumpers with UPC connectors on the laser side with APC on and throughout the OSP, but if it should be purely APC everywhere, then that is what I need to know. Thanks! Lorell Hathcock From baldur.norddahl at gmail.com Tue Feb 23 13:24:55 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 23 Feb 2016 14:24:55 +0100 Subject: APC vs UPC? In-Reply-To: <35EF9A4B-B9A1-485C-A8FA-06B5236B511E@hathcock.org> References: <35EF9A4B-B9A1-485C-A8FA-06B5236B511E@hathcock.org> Message-ID: Hi SFP modules will generally have UPC connectors. You therefore need to use cables with UPC at one end and APC at the other end. If you use a APC-APC cable you will have 3-6 dB of optical loss. If it is a short connection and you are out of correct cables, it will usually work. On longer connections you need the extra power budget. As to where to buy, I will suggest fiberstore.com. Regards, Baldur On 23 February 2016 at 14:12, Lorell Hathcock wrote: > NANOGians: > > APC wins! > > My real question is surrounding the connection on the SFPs themselves. > > In general terms are the LC connectors on SFPs considered UPC or APC? > > If the answer is UPC and if I am inheriting and/or building a network of > single mode fiber with APC SC connectors, then is the best practice to use > LC UPC to SC APC fiber jumpers? > > If so, can anyone point me to a source for said jumpers that is (1) quick > and (2) good? > > Any thoughts on the same idea of mismatched fiber jumpers connector types > to use on OLMs and OLSs? OTDRs? The concern here is to use the best > possible fiber connector types (e.g. APC or UPC) when connecting lasers to > my OSP fiber which uses APC with consideration to the optimal connector > type for the laser transceiver. > > My thoughts are to use fiber jumpers with UPC connectors on the laser side > with APC on and throughout the OSP, but if it should be purely APC > everywhere, then that is what I need to know. > > Thanks! > > Lorell Hathcock From Daniel.Jameson at tdstelecom.com Tue Feb 23 14:40:01 2016 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Tue, 23 Feb 2016 14:40:01 +0000 Subject: APC vs UPC? In-Reply-To: <35EF9A4B-B9A1-485C-A8FA-06B5236B511E@hathcock.org> References: <35EF9A4B-B9A1-485C-A8FA-06B5236B511E@hathcock.org> Message-ID: Most SFP/XFP have upc connectors until you get above 5(ish) db of power, then you'll start to see APC and/or E2000 connections. You'll end up using a hybrid jumper (APC one end, UPS on the other). If you're looking for quality jumpers look at Clearfield or Corning. ADC makes tracelite jumpers that illuminate if that's part of your need. You should only see a .1-.2 db increase in loss for an APC connecter vs a UPC connector. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell Hathcock Sent: Tuesday, February 23, 2016 7:12 AM To: nanog at nanog.org Subject: APC vs UPC? NANOGians: APC wins! My real question is surrounding the connection on the SFPs themselves. In general terms are the LC connectors on SFPs considered UPC or APC? If the answer is UPC and if I am inheriting and/or building a network of single mode fiber with APC SC connectors, then is the best practice to use LC UPC to SC APC fiber jumpers? If so, can anyone point me to a source for said jumpers that is (1) quick and (2) good? Any thoughts on the same idea of mismatched fiber jumpers connector types to use on OLMs and OLSs? OTDRs? The concern here is to use the best possible fiber connector types (e.g. APC or UPC) when connecting lasers to my OSP fiber which uses APC with consideration to the optimal connector type for the laser transceiver. My thoughts are to use fiber jumpers with UPC connectors on the laser side with APC on and throughout the OSP, but if it should be purely APC everywhere, then that is what I need to know. Thanks! Lorell Hathcock From jason.iannone at gmail.com Tue Feb 23 15:39:19 2016 From: jason.iannone at gmail.com (Jason Iannone) Date: Tue, 23 Feb 2016 08:39:19 -0700 Subject: BGP MVPN RFC6513, Section 10 Message-ID: Hi all, I'm having trouble interpreting under what circumstance section 10 of BGP MVPN comes into play. The way I read this section, upon the receipt of PIM/IGMP Join to (*,G) the Receiver Site PE does not signal Type 6 or Type 7 Joins until a Type 5 Source Active route is received from a Sender Site PE. If Section 10 assumes the use of ASM groups in the VPN, why develop a Type 6 Shared Tree Join A-D route for unknown sources? What are the practical minimum Juniper configurations to support Section 10 for ASM and (*,G) PIM Join when the PE doesn't know a source? CE1---PE1,C-RP-----P-----PE2---CE2 Sender Site-------------------Receiver Site 1. CE1 has no active source 2. CE2 forwards PIM Join (*,G) to PE2 toward PE1,C-RP 3. PE2 eats PIM Join, maintains (*,G) state 4. CE1 generates Register messages to PE1 5. PE1 originates Type 5 (S,G) 6. PE2 receives Type 5 (S,G) 7. PE2 verifies existing (*,G) state 8. PE2 advertises Type 7 Join (S,G) 9. PE2 does PMSI and P-Tunnel attachment 10. PE1 receives (S,G) from PE2 11. PE1 adds PMSI to downstream interfaces 12. Multicast flow end to end 13. Achievement unlocked! I'm least sure about steps 2 & 3. Comprehension challenged, Jason From niels=nanog at bakker.net Wed Feb 24 12:55:13 2016 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 24 Feb 2016 13:55:13 +0100 Subject: APC vs UPC? In-Reply-To: References: <35EF9A4B-B9A1-485C-A8FA-06B5236B511E@hathcock.org> Message-ID: <20160224125513.GA66966@excession.tpb.net> * baldur.norddahl at gmail.com (Baldur Norddahl) [Tue 23 Feb 2016, 14:25 CET]: >SFP modules will generally have UPC connectors. You therefore need >to use cables with UPC at one end and APC at the other end. > >If you use a APC-APC cable you will have 3-6 dB of optical loss. If >it is a short connection and you are out of correct cables, it will >usually work. Don't connect APC to UPC. You will damage the fiber. -- Niels. From jwbensley at gmail.com Wed Feb 24 16:12:20 2016 From: jwbensley at gmail.com (James Bensley) Date: Wed, 24 Feb 2016 16:12:20 +0000 Subject: SunGard On List? Message-ID: Hi All, Any SunGard on list? Having a path issue from multiple ISPs in the UK. Cheers, James. From johnl at iecc.com Wed Feb 24 17:08:30 2016 From: johnl at iecc.com (John Levine) Date: 24 Feb 2016 17:08:30 -0000 Subject: SIP strangeness on T-W cable ? Message-ID: <20160224170830.33382.qmail@ary.lan> Today I am unable to connect to my usual SIP servers from my T-W cable account. I've tried two Sipura terminal adapters and the softphone in Jitsi, and I can't connect to either callcentric.com or voipdiscount.com, and the network connection is otherwise looking normal. The SIP providers are up, if I call my callcentric number from the other line it goes to voicemail as you'd expect. Anyone else seeing SIP wierdness on T-W today? R's, John From ian.clark at dreamhost.com Wed Feb 24 18:24:46 2016 From: ian.clark at dreamhost.com (Ian Clark) Date: Wed, 24 Feb 2016 10:24:46 -0800 Subject: Cogent & Google IPv6 Message-ID: Anyone know what's actually going on here? We received the following information from the two of them, and this just started a week or so ago. *From Cogent, the transit provider for a branch office of ours:* Dear Cogent Customer, Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach. Google uses transit providers to announce their IPv4 routes to Cogent. At this time however, Google has chosen not to announce their IPv6 routes to Cogent through transit providers. We apologize for any inconvenience this may cause you and will notify you if there is an update to the situation. *From Google (re: Cogent):* Unfortunately it seems that your transit provider does not have IPv6 connectivity with Google. We suggest you ask your transit provider to look for alternatives to interconnect with us. Google maintains an open interconnect policy for IPv6 and welcomes any network to peer with us for access via IPv6 (and IPv4). For those networks that aren't able, or chose not to peer with Google via IPv6, they are able to reach us through any of a large number of transit providers. For more information in how to peer directly with Google please visit https://peering.google.com -- Ian Clark Lead Network Engineer DreamHost From damien at supremebytes.com Wed Feb 24 19:43:18 2016 From: damien at supremebytes.com (Damien Burke) Date: Wed, 24 Feb 2016 19:43:18 +0000 Subject: Cogent & Google IPv6 In-Reply-To: References: Message-ID: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> Not sure. I got the same thing today as well. Is this some kind of ipv6 war? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark Sent: Wednesday, February 24, 2016 10:25 AM To: NANOG Subject: Cogent & Google IPv6 Anyone know what's actually going on here? We received the following information from the two of them, and this just started a week or so ago. *From Cogent, the transit provider for a branch office of ours:* Dear Cogent Customer, Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach. Google uses transit providers to announce their IPv4 routes to Cogent. At this time however, Google has chosen not to announce their IPv6 routes to Cogent through transit providers. We apologize for any inconvenience this may cause you and will notify you if there is an update to the situation. *From Google (re: Cogent):* Unfortunately it seems that your transit provider does not have IPv6 connectivity with Google. We suggest you ask your transit provider to look for alternatives to interconnect with us. Google maintains an open interconnect policy for IPv6 and welcomes any network to peer with us for access via IPv6 (and IPv4). For those networks that aren't able, or chose not to peer with Google via IPv6, they are able to reach us through any of a large number of transit providers. For more information in how to peer directly with Google please visit https://peering.google.com -- Ian Clark Lead Network Engineer DreamHost From mhoppes at indigowireless.com Wed Feb 24 19:46:56 2016 From: mhoppes at indigowireless.com (Matt Hoppes) Date: Wed, 24 Feb 2016 14:46:56 -0500 Subject: Cogent & Google IPv6 In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> References: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> Message-ID: <56CE08B0.2080103@indigowireless.com> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, shouldn't the traffic flow out to one of their peer points where another peer DOES peer with Google IPv6 and get you in? Isn't that how the Internet is suppose to work? On 2/24/16 2:43 PM, Damien Burke wrote: > Not sure. I got the same thing today as well. > > Is this some kind of ipv6 war? > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark > Sent: Wednesday, February 24, 2016 10:25 AM > To: NANOG > Subject: Cogent & Google IPv6 > > Anyone know what's actually going on here? We received the following information from the two of them, and this just started a week or so ago. > > > *From Cogent, the transit provider for a branch office of ours:* > > Dear Cogent Customer, > > Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach. > > Google uses transit providers to announce their IPv4 routes to Cogent. > > At this time however, Google has chosen not to announce their IPv6 routes to Cogent through transit providers. > > We apologize for any inconvenience this may cause you and will notify you if there is an update to the situation. > > > > *From Google (re: Cogent):* > > Unfortunately it seems that your transit provider does not have IPv6 connectivity with Google. We suggest you ask your transit provider to look for alternatives to interconnect with us. > > Google maintains an open interconnect policy for IPv6 and welcomes any network to peer with us for access via IPv6 (and IPv4). For those networks that aren't able, or chose not to peer with Google via IPv6, they are able to reach us through any of a large number of transit providers. > > For more information in how to peer directly with Google please visit https://peering.google.com > > > -- > Ian Clark > Lead Network Engineer > DreamHost > From maxtul at netassist.ua Wed Feb 24 19:53:07 2016 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 24 Feb 2016 21:53:07 +0200 Subject: Cogent & Google IPv6 In-Reply-To: <56CE08B0.2080103@indigowireless.com> References: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> <56CE08B0.2080103@indigowireless.com> Message-ID: <56CE0A23.2030206@netassist.ua> If you connected to Internet ONLY through Cogent - there is no other way. If you have another upstreams - Google should be reachable. On 24.02.16 21:46, Matt Hoppes wrote: > Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, > shouldn't the traffic flow out to one of their peer points where another > peer DOES peer with Google IPv6 and get you in? > > Isn't that how the Internet is suppose to work? > > > On 2/24/16 2:43 PM, Damien Burke wrote: >> Not sure. I got the same thing today as well. >> >> Is this some kind of ipv6 war? >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark >> Sent: Wednesday, February 24, 2016 10:25 AM >> To: NANOG >> Subject: Cogent & Google IPv6 >> >> Anyone know what's actually going on here? We received the following >> information from the two of them, and this just started a week or so ago. >> >> >> *From Cogent, the transit provider for a branch office of ours:* >> >> Dear Cogent Customer, >> >> Thank you for contacting Cogent Customer Support for information about >> the Google IPv6 addresses you are unable to reach. >> >> Google uses transit providers to announce their IPv4 routes to Cogent. >> >> At this time however, Google has chosen not to announce their IPv6 >> routes to Cogent through transit providers. >> >> We apologize for any inconvenience this may cause you and will notify >> you if there is an update to the situation. >> >> >> >> *From Google (re: Cogent):* >> >> Unfortunately it seems that your transit provider does not have IPv6 >> connectivity with Google. We suggest you ask your transit provider to >> look for alternatives to interconnect with us. >> >> Google maintains an open interconnect policy for IPv6 and welcomes any >> network to peer with us for access via IPv6 (and IPv4). For those >> networks that aren't able, or chose not to peer with Google via IPv6, >> they are able to reach us through any of a large number of transit >> providers. >> >> For more information in how to peer directly with Google please visit >> https://peering.google.com >> >> >> -- >> Ian Clark >> Lead Network Engineer >> DreamHost >> > From patrick at ianai.net Wed Feb 24 20:04:02 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 24 Feb 2016 15:04:02 -0500 Subject: Cogent & Google IPv6 In-Reply-To: <56CE0A23.2030206@netassist.ua> References: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> <56CE08B0.2080103@indigowireless.com> <56CE0A23.2030206@netassist.ua> Message-ID: <5247A258-D6E1-4F50-9EC2-E324ACCDEF3B@ianai.net> To answer Matt?s question, NO. Assume Cogent peers with NTT. Assume Google peers with NTT. NTT has very good v6 connectivity (not an assumption). Cogent cannot send a packet to NTT and say ?please hand this to Google?. Nor can Google hand a packet to NTT with a destination of Cogent. Under this scenario, NTT is not being paid by Cogent or Google. Why would they take a packet from one and give it to the other? -- TTFN, patrick > On Feb 24, 2016, at 2:53 PM, Max Tulyev wrote: > > If you connected to Internet ONLY through Cogent - there is no other > way. If you have another upstreams - Google should be reachable. > > On 24.02.16 21:46, Matt Hoppes wrote: >> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, >> shouldn't the traffic flow out to one of their peer points where another >> peer DOES peer with Google IPv6 and get you in? >> >> Isn't that how the Internet is suppose to work? >> >> >> On 2/24/16 2:43 PM, Damien Burke wrote: >>> Not sure. I got the same thing today as well. >>> >>> Is this some kind of ipv6 war? >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark >>> Sent: Wednesday, February 24, 2016 10:25 AM >>> To: NANOG >>> Subject: Cogent & Google IPv6 >>> >>> Anyone know what's actually going on here? We received the following >>> information from the two of them, and this just started a week or so ago. >>> >>> >>> *From Cogent, the transit provider for a branch office of ours:* >>> >>> Dear Cogent Customer, >>> >>> Thank you for contacting Cogent Customer Support for information about >>> the Google IPv6 addresses you are unable to reach. >>> >>> Google uses transit providers to announce their IPv4 routes to Cogent. >>> >>> At this time however, Google has chosen not to announce their IPv6 >>> routes to Cogent through transit providers. >>> >>> We apologize for any inconvenience this may cause you and will notify >>> you if there is an update to the situation. >>> >>> >>> >>> *From Google (re: Cogent):* >>> >>> Unfortunately it seems that your transit provider does not have IPv6 >>> connectivity with Google. We suggest you ask your transit provider to >>> look for alternatives to interconnect with us. >>> >>> Google maintains an open interconnect policy for IPv6 and welcomes any >>> network to peer with us for access via IPv6 (and IPv4). For those >>> networks that aren't able, or chose not to peer with Google via IPv6, >>> they are able to reach us through any of a large number of transit >>> providers. >>> >>> For more information in how to peer directly with Google please visit >>> https://peering.google.com >>> >>> >>> -- >>> Ian Clark >>> Lead Network Engineer >>> DreamHost >>> >> From baldur.norddahl at gmail.com Wed Feb 24 20:08:57 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 24 Feb 2016 21:08:57 +0100 Subject: Cogent & Google IPv6 In-Reply-To: <56CE08B0.2080103@indigowireless.com> References: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> <56CE08B0.2080103@indigowireless.com> Message-ID: This is Google saying that Google does not want to pay for traffic to Cogent. If Cogent wants to exchange any traffic with Google, Cogent is invited to peer directly with Google. Of course Cogent refuses. And now Cogent is not only missing the part of IPv6 internet that is Hurricane Electric single homed but also everything Google. Why does Cogent refuse? They used to deliver this traffic on free peering with another tier 1 provider. Now they are asked to deliver the same traffic for the same price (free) on a direct peering session. They won't because Cogent believes Google should pay for this traffic. That another Cogent customer already paid for the traffic does not matter. They want double dipping or nothing. So nothing it is. Seems to me that if you are serious about IPv6 you can not use Cogent as your primary or secondary transit provider. You can use them as your third if you want to. Regards, Baldur On 24 February 2016 at 20:46, Matt Hoppes wrote: > Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, > shouldn't the traffic flow out to one of their peer points where another > peer DOES peer with Google IPv6 and get you in? > > Isn't that how the Internet is suppose to work? > > > On 2/24/16 2:43 PM, Damien Burke wrote: > >> Not sure. I got the same thing today as well. >> >> Is this some kind of ipv6 war? >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark >> Sent: Wednesday, February 24, 2016 10:25 AM >> To: NANOG >> Subject: Cogent & Google IPv6 >> >> Anyone know what's actually going on here? We received the following >> information from the two of them, and this just started a week or so ago. >> >> >> *From Cogent, the transit provider for a branch office of ours:* >> >> Dear Cogent Customer, >> >> Thank you for contacting Cogent Customer Support for information about >> the Google IPv6 addresses you are unable to reach. >> >> Google uses transit providers to announce their IPv4 routes to Cogent. >> >> At this time however, Google has chosen not to announce their IPv6 routes >> to Cogent through transit providers. >> >> We apologize for any inconvenience this may cause you and will notify you >> if there is an update to the situation. >> >> >> >> *From Google (re: Cogent):* >> >> Unfortunately it seems that your transit provider does not have IPv6 >> connectivity with Google. We suggest you ask your transit provider to look >> for alternatives to interconnect with us. >> >> Google maintains an open interconnect policy for IPv6 and welcomes any >> network to peer with us for access via IPv6 (and IPv4). For those networks >> that aren't able, or chose not to peer with Google via IPv6, they are able >> to reach us through any of a large number of transit providers. >> >> For more information in how to peer directly with Google please visit >> https://peering.google.com >> >> >> -- >> Ian Clark >> Lead Network Engineer >> DreamHost >> >> From patrick at ianai.net Wed Feb 24 20:12:07 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 24 Feb 2016 15:12:07 -0500 Subject: Cogent & Google IPv6 In-Reply-To: References: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> <56CE08B0.2080103@indigowireless.com> Message-ID: <321616AE-EC19-4DD7-9A2D-02378ED73D5B@ianai.net> Are HE & Google the new L3 & FT? Nah, L3 would never have baked Cogent a cake. :) Shall we start a pool? Only problem is, should the pool be ?who will disconnect from Cogent next?? or ?when will Cogent blink?? I?m voting for the former. -- TTFN, patrick > On Feb 24, 2016, at 3:08 PM, Baldur Norddahl wrote: > > This is Google saying that Google does not want to pay for traffic to > Cogent. If Cogent wants to exchange any traffic with Google, Cogent is > invited to peer directly with Google. Of course Cogent refuses. And now > Cogent is not only missing the part of IPv6 internet that is Hurricane > Electric single homed but also everything Google. > > Why does Cogent refuse? They used to deliver this traffic on free peering > with another tier 1 provider. Now they are asked to deliver the same > traffic for the same price (free) on a direct peering session. They won't > because Cogent believes Google should pay for this traffic. That another > Cogent customer already paid for the traffic does not matter. They want > double dipping or nothing. So nothing it is. > > Seems to me that if you are serious about IPv6 you can not use Cogent as > your primary or secondary transit provider. You can use them as your third > if you want to. > > Regards, > > Baldur > > > > On 24 February 2016 at 20:46, Matt Hoppes > wrote: > >> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, >> shouldn't the traffic flow out to one of their peer points where another >> peer DOES peer with Google IPv6 and get you in? >> >> Isn't that how the Internet is suppose to work? >> >> >> On 2/24/16 2:43 PM, Damien Burke wrote: >> >>> Not sure. I got the same thing today as well. >>> >>> Is this some kind of ipv6 war? >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark >>> Sent: Wednesday, February 24, 2016 10:25 AM >>> To: NANOG >>> Subject: Cogent & Google IPv6 >>> >>> Anyone know what's actually going on here? We received the following >>> information from the two of them, and this just started a week or so ago. >>> >>> >>> *From Cogent, the transit provider for a branch office of ours:* >>> >>> Dear Cogent Customer, >>> >>> Thank you for contacting Cogent Customer Support for information about >>> the Google IPv6 addresses you are unable to reach. >>> >>> Google uses transit providers to announce their IPv4 routes to Cogent. >>> >>> At this time however, Google has chosen not to announce their IPv6 routes >>> to Cogent through transit providers. >>> >>> We apologize for any inconvenience this may cause you and will notify you >>> if there is an update to the situation. >>> >>> >>> >>> *From Google (re: Cogent):* >>> >>> Unfortunately it seems that your transit provider does not have IPv6 >>> connectivity with Google. We suggest you ask your transit provider to look >>> for alternatives to interconnect with us. >>> >>> Google maintains an open interconnect policy for IPv6 and welcomes any >>> network to peer with us for access via IPv6 (and IPv4). For those networks >>> that aren't able, or chose not to peer with Google via IPv6, they are able >>> to reach us through any of a large number of transit providers. >>> >>> For more information in how to peer directly with Google please visit >>> https://peering.google.com >>> >>> >>> -- >>> Ian Clark >>> Lead Network Engineer >>> DreamHost >>> >>> From nanog at ics-il.net Wed Feb 24 20:16:20 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 24 Feb 2016 14:16:20 -0600 (CST) Subject: Cogent & Google IPv6 In-Reply-To: <321616AE-EC19-4DD7-9A2D-02378ED73D5B@ianai.net> Message-ID: <511753352.11048.1456344975867.JavaMail.mhammett@ThunderFuck> Whomever hurts the most will blink first. I don't really care who that is. I have no ill will towards "double dipping". Either they do or they don't offer the desired connectivity and I'm moving on. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Wednesday, February 24, 2016 2:12:07 PM Subject: Re: Cogent & Google IPv6 Are HE & Google the new L3 & FT? Nah, L3 would never have baked Cogent a cake. :) Shall we start a pool? Only problem is, should the pool be ?who will disconnect from Cogent next?? or ?when will Cogent blink?? I?m voting for the former. -- TTFN, patrick > On Feb 24, 2016, at 3:08 PM, Baldur Norddahl wrote: > > This is Google saying that Google does not want to pay for traffic to > Cogent. If Cogent wants to exchange any traffic with Google, Cogent is > invited to peer directly with Google. Of course Cogent refuses. And now > Cogent is not only missing the part of IPv6 internet that is Hurricane > Electric single homed but also everything Google. > > Why does Cogent refuse? They used to deliver this traffic on free peering > with another tier 1 provider. Now they are asked to deliver the same > traffic for the same price (free) on a direct peering session. They won't > because Cogent believes Google should pay for this traffic. That another > Cogent customer already paid for the traffic does not matter. They want > double dipping or nothing. So nothing it is. > > Seems to me that if you are serious about IPv6 you can not use Cogent as > your primary or secondary transit provider. You can use them as your third > if you want to. > > Regards, > > Baldur > > > > On 24 February 2016 at 20:46, Matt Hoppes > wrote: > >> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, >> shouldn't the traffic flow out to one of their peer points where another >> peer DOES peer with Google IPv6 and get you in? >> >> Isn't that how the Internet is suppose to work? >> >> >> On 2/24/16 2:43 PM, Damien Burke wrote: >> >>> Not sure. I got the same thing today as well. >>> >>> Is this some kind of ipv6 war? >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark >>> Sent: Wednesday, February 24, 2016 10:25 AM >>> To: NANOG >>> Subject: Cogent & Google IPv6 >>> >>> Anyone know what's actually going on here? We received the following >>> information from the two of them, and this just started a week or so ago. >>> >>> >>> *From Cogent, the transit provider for a branch office of ours:* >>> >>> Dear Cogent Customer, >>> >>> Thank you for contacting Cogent Customer Support for information about >>> the Google IPv6 addresses you are unable to reach. >>> >>> Google uses transit providers to announce their IPv4 routes to Cogent. >>> >>> At this time however, Google has chosen not to announce their IPv6 routes >>> to Cogent through transit providers. >>> >>> We apologize for any inconvenience this may cause you and will notify you >>> if there is an update to the situation. >>> >>> >>> >>> *From Google (re: Cogent):* >>> >>> Unfortunately it seems that your transit provider does not have IPv6 >>> connectivity with Google. We suggest you ask your transit provider to look >>> for alternatives to interconnect with us. >>> >>> Google maintains an open interconnect policy for IPv6 and welcomes any >>> network to peer with us for access via IPv6 (and IPv4). For those networks >>> that aren't able, or chose not to peer with Google via IPv6, they are able >>> to reach us through any of a large number of transit providers. >>> >>> For more information in how to peer directly with Google please visit >>> https://peering.google.com >>> >>> >>> -- >>> Ian Clark >>> Lead Network Engineer >>> DreamHost >>> >>> From jfbeam at gmail.com Wed Feb 24 20:18:24 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 24 Feb 2016 15:18:24 -0500 Subject: Cogent & Google IPv6 In-Reply-To: <56CE08B0.2080103@indigowireless.com> References: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> <56CE08B0.2080103@indigowireless.com> Message-ID: On Wed, 24 Feb 2016 14:46:56 -0500, Matt Hoppes wrote: > Isn't that how the Internet is suppose to work? Perhaps. But that's not how *Cogent* works. They have a very idiotic view of "Tier 1". They have no transit connections with anyone; someone is paying them for every prefix they accept. Translation: No one in their right mind does business with Cogent. From damien at supremebytes.com Wed Feb 24 20:19:37 2016 From: damien at supremebytes.com (Damien Burke) Date: Wed, 24 Feb 2016 20:19:37 +0000 Subject: Cogent & Google IPv6 In-Reply-To: <321616AE-EC19-4DD7-9A2D-02378ED73D5B@ianai.net> References: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> <56CE08B0.2080103@indigowireless.com> <321616AE-EC19-4DD7-9A2D-02378ED73D5B@ianai.net> Message-ID: <2FD50E6D13594B4C93B743BFCF9F52843D0D0C1E@EXCH01.sb.local> I have already shut down peering with cogent over ipv6 entirely (two weeks ago) over this issue. Cogent needs to get it together and work it out. Google is our overlord - you cannot refuse them. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Patrick W. Gilmore Sent: Wednesday, February 24, 2016 12:12 PM To: NANOG list Subject: Re: Cogent & Google IPv6 Are HE & Google the new L3 & FT? Nah, L3 would never have baked Cogent a cake. :) Shall we start a pool? Only problem is, should the pool be ?who will disconnect from Cogent next?? or ?when will Cogent blink?? I?m voting for the former. -- TTFN, patrick > On Feb 24, 2016, at 3:08 PM, Baldur Norddahl wrote: > > This is Google saying that Google does not want to pay for traffic to > Cogent. If Cogent wants to exchange any traffic with Google, Cogent is > invited to peer directly with Google. Of course Cogent refuses. And > now Cogent is not only missing the part of IPv6 internet that is > Hurricane Electric single homed but also everything Google. > > Why does Cogent refuse? They used to deliver this traffic on free > peering with another tier 1 provider. Now they are asked to deliver > the same traffic for the same price (free) on a direct peering > session. They won't because Cogent believes Google should pay for this > traffic. That another Cogent customer already paid for the traffic > does not matter. They want double dipping or nothing. So nothing it is. > > Seems to me that if you are serious about IPv6 you can not use Cogent > as your primary or secondary transit provider. You can use them as > your third if you want to. > > Regards, > > Baldur > > > > On 24 February 2016 at 20:46, Matt Hoppes > wrote: > >> Correct me if I'm wrong, but if Cogent isn't peering with Google >> IPv6, shouldn't the traffic flow out to one of their peer points >> where another peer DOES peer with Google IPv6 and get you in? >> >> Isn't that how the Internet is suppose to work? >> >> >> On 2/24/16 2:43 PM, Damien Burke wrote: >> >>> Not sure. I got the same thing today as well. >>> >>> Is this some kind of ipv6 war? >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark >>> Sent: Wednesday, February 24, 2016 10:25 AM >>> To: NANOG >>> Subject: Cogent & Google IPv6 >>> >>> Anyone know what's actually going on here? We received the >>> following information from the two of them, and this just started a week or so ago. >>> >>> >>> *From Cogent, the transit provider for a branch office of ours:* >>> >>> Dear Cogent Customer, >>> >>> Thank you for contacting Cogent Customer Support for information >>> about the Google IPv6 addresses you are unable to reach. >>> >>> Google uses transit providers to announce their IPv4 routes to Cogent. >>> >>> At this time however, Google has chosen not to announce their IPv6 >>> routes to Cogent through transit providers. >>> >>> We apologize for any inconvenience this may cause you and will >>> notify you if there is an update to the situation. >>> >>> >>> >>> *From Google (re: Cogent):* >>> >>> Unfortunately it seems that your transit provider does not have IPv6 >>> connectivity with Google. We suggest you ask your transit provider >>> to look for alternatives to interconnect with us. >>> >>> Google maintains an open interconnect policy for IPv6 and welcomes >>> any network to peer with us for access via IPv6 (and IPv4). For >>> those networks that aren't able, or chose not to peer with Google >>> via IPv6, they are able to reach us through any of a large number of transit providers. >>> >>> For more information in how to peer directly with Google please >>> visit https://peering.google.com >>> >>> >>> -- >>> Ian Clark >>> Lead Network Engineer >>> DreamHost >>> >>> From nanog at ics-il.net Wed Feb 24 20:26:36 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 24 Feb 2016 14:26:36 -0600 (CST) Subject: Cogent & Google IPv6 In-Reply-To: Message-ID: <1906151786.11094.1456345593687.JavaMail.mhammett@ThunderFuck> Isn't that how "Tier 1s" have always operated? Like, always? Customers or peers with peers subject to various requirements. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ricky Beam" To: "Matt Hoppes" Cc: "NANOG" Sent: Wednesday, February 24, 2016 2:18:24 PM Subject: Re: Cogent & Google IPv6 On Wed, 24 Feb 2016 14:46:56 -0500, Matt Hoppes wrote: > Isn't that how the Internet is suppose to work? Perhaps. But that's not how *Cogent* works. They have a very idiotic view of "Tier 1". They have no transit connections with anyone; someone is paying them for every prefix they accept. Translation: No one in their right mind does business with Cogent. From patrick at ianai.net Wed Feb 24 20:27:21 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 24 Feb 2016 15:27:21 -0500 Subject: Cogent & Google IPv6 In-Reply-To: <511753352.11048.1456344975867.JavaMail.mhammett@ThunderFuck> References: <511753352.11048.1456344975867.JavaMail.mhammett@ThunderFuck> Message-ID: <91CDF434-22A2-47C6-9CD9-EF269A0F7156@ianai.net> Agreed on all points. ?Double dipping? is not morally abhorrent, or even slightly slimy. However, Cogent customers paid Cogent to connect to The Internet, not ?The other networks that are paying Cogent?. So in this case, if I had to make a choice of which provider to drop, I?d stick with Google. (I do not have to make such a decision.) One could claim the same about HE vs. Cogent. However, I?m still going to give the nod to the people saying ?we are happy to connect? over the people who say ?pay me to connect?. Obviously a lot of details I?m glossing over, but HE does have, IMHO, a good argument for v6 peering with Cogent. Doesn?t mean either is ?wrong", just that is how I would vote with my wallet if I had to make the choice. (Again, I do not.) So when FB does the same thing, when Comcast does the same thing, when Apple does the same thing, when ?. When will Cogent feel enough pain to relent? Or will this simply delay the full implementation of IPv6 even more, and Cogent won?t notice because everyone falls back to v4? -- TTFN, patrick > On Feb 24, 2016, at 3:16 PM, Mike Hammett wrote: > > Whomever hurts the most will blink first. I don't really care who that is. I have no ill will towards "double dipping". Either they do or they don't offer the desired connectivity and I'm moving on. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Wednesday, February 24, 2016 2:12:07 PM > Subject: Re: Cogent & Google IPv6 > > Are HE & Google the new L3 & FT? > > Nah, L3 would never have baked Cogent a cake. :) > > Shall we start a pool? Only problem is, should the pool be ?who will disconnect from Cogent next?? or ?when will Cogent blink?? I?m voting for the former. > > -- > TTFN, > patrick > >> On Feb 24, 2016, at 3:08 PM, Baldur Norddahl wrote: >> >> This is Google saying that Google does not want to pay for traffic to >> Cogent. If Cogent wants to exchange any traffic with Google, Cogent is >> invited to peer directly with Google. Of course Cogent refuses. And now >> Cogent is not only missing the part of IPv6 internet that is Hurricane >> Electric single homed but also everything Google. >> >> Why does Cogent refuse? They used to deliver this traffic on free peering >> with another tier 1 provider. Now they are asked to deliver the same >> traffic for the same price (free) on a direct peering session. They won't >> because Cogent believes Google should pay for this traffic. That another >> Cogent customer already paid for the traffic does not matter. They want >> double dipping or nothing. So nothing it is. >> >> Seems to me that if you are serious about IPv6 you can not use Cogent as >> your primary or secondary transit provider. You can use them as your third >> if you want to. >> >> Regards, >> >> Baldur >> >> >> >> On 24 February 2016 at 20:46, Matt Hoppes >> wrote: >> >>> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, >>> shouldn't the traffic flow out to one of their peer points where another >>> peer DOES peer with Google IPv6 and get you in? >>> >>> Isn't that how the Internet is suppose to work? >>> >>> >>> On 2/24/16 2:43 PM, Damien Burke wrote: >>> >>>> Not sure. I got the same thing today as well. >>>> >>>> Is this some kind of ipv6 war? >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark >>>> Sent: Wednesday, February 24, 2016 10:25 AM >>>> To: NANOG >>>> Subject: Cogent & Google IPv6 >>>> >>>> Anyone know what's actually going on here? We received the following >>>> information from the two of them, and this just started a week or so ago. >>>> >>>> >>>> *From Cogent, the transit provider for a branch office of ours:* >>>> >>>> Dear Cogent Customer, >>>> >>>> Thank you for contacting Cogent Customer Support for information about >>>> the Google IPv6 addresses you are unable to reach. >>>> >>>> Google uses transit providers to announce their IPv4 routes to Cogent. >>>> >>>> At this time however, Google has chosen not to announce their IPv6 routes >>>> to Cogent through transit providers. >>>> >>>> We apologize for any inconvenience this may cause you and will notify you >>>> if there is an update to the situation. >>>> >>>> >>>> >>>> *From Google (re: Cogent):* >>>> >>>> Unfortunately it seems that your transit provider does not have IPv6 >>>> connectivity with Google. We suggest you ask your transit provider to look >>>> for alternatives to interconnect with us. >>>> >>>> Google maintains an open interconnect policy for IPv6 and welcomes any >>>> network to peer with us for access via IPv6 (and IPv4). For those networks >>>> that aren't able, or chose not to peer with Google via IPv6, they are able >>>> to reach us through any of a large number of transit providers. >>>> >>>> For more information in how to peer directly with Google please visit >>>> https://peering.google.com >>>> >>>> >>>> -- >>>> Ian Clark >>>> Lead Network Engineer >>>> DreamHost >>>> >>>> > From patrick at ianai.net Wed Feb 24 20:48:22 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 24 Feb 2016 15:48:22 -0500 Subject: Cogent & Google IPv6 In-Reply-To: <1906151786.11094.1456345593687.JavaMail.mhammett@ThunderFuck> References: <1906151786.11094.1456345593687.JavaMail.mhammett@ThunderFuck> Message-ID: ?Tier One? used to mean SFI or customer downstream to every prefix on the ?Net. Today it is more like ?transit free?, since some ?tier one? providers have paid peering. And Ricky is wrong, the vast majority of prefixes Cogent routes have zero dollars behind them. Cogent gets paid by customers, not peers. (At least not the big ones.) -- TTFN, patrick > On Feb 24, 2016, at 3:26 PM, Mike Hammett wrote: > > Isn't that how "Tier 1s" have always operated? Like, always? Customers or peers with peers subject to various requirements. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Ricky Beam" > To: "Matt Hoppes" > Cc: "NANOG" > Sent: Wednesday, February 24, 2016 2:18:24 PM > Subject: Re: Cogent & Google IPv6 > > On Wed, 24 Feb 2016 14:46:56 -0500, Matt Hoppes > wrote: >> Isn't that how the Internet is suppose to work? > > Perhaps. But that's not how *Cogent* works. They have a very idiotic view > of "Tier 1". They have no transit connections with anyone; someone is > paying them for every prefix they accept. > > Translation: No one in their right mind does business with Cogent. From nanog at ics-il.net Wed Feb 24 21:02:09 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 24 Feb 2016 15:02:09 -0600 (CST) Subject: Cogent & Google IPv6 In-Reply-To: <91CDF434-22A2-47C6-9CD9-EF269A0F7156@ianai.net> Message-ID: <1469681630.11137.1456347727250.JavaMail.mhammett@ThunderFuck> *nods* and everything is pros and cons. In one's situation, does Cogent have enough pros to overcome the cons? Same for HE or any other carrier. If I get full tables (v4 and b6) from multiple networks and\or I peer with the networks that are missing from a particular provider's offering, I may very well not give a darn about it being missing. I may never have even used it in the first place. If whatever advantages to me outweigh that loss, so be it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Wednesday, February 24, 2016 2:27:21 PM Subject: Re: Cogent & Google IPv6 Agreed on all points. ?Double dipping? is not morally abhorrent, or even slightly slimy. However, Cogent customers paid Cogent to connect to The Internet, not ?The other networks that are paying Cogent?. So in this case, if I had to make a choice of which provider to drop, I?d stick with Google. (I do not have to make such a decision.) One could claim the same about HE vs. Cogent. However, I?m still going to give the nod to the people saying ?we are happy to connect? over the people who say ?pay me to connect?. Obviously a lot of details I?m glossing over, but HE does have, IMHO, a good argument for v6 peering with Cogent. Doesn?t mean either is ?wrong", just that is how I would vote with my wallet if I had to make the choice. (Again, I do not.) So when FB does the same thing, when Comcast does the same thing, when Apple does the same thing, when ?. When will Cogent feel enough pain to relent? Or will this simply delay the full implementation of IPv6 even more, and Cogent won?t notice because everyone falls back to v4? -- TTFN, patrick > On Feb 24, 2016, at 3:16 PM, Mike Hammett wrote: > > Whomever hurts the most will blink first. I don't really care who that is. I have no ill will towards "double dipping". Either they do or they don't offer the desired connectivity and I'm moving on. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Wednesday, February 24, 2016 2:12:07 PM > Subject: Re: Cogent & Google IPv6 > > Are HE & Google the new L3 & FT? > > Nah, L3 would never have baked Cogent a cake. :) > > Shall we start a pool? Only problem is, should the pool be ?who will disconnect from Cogent next?? or ?when will Cogent blink?? I?m voting for the former. > > -- > TTFN, > patrick > >> On Feb 24, 2016, at 3:08 PM, Baldur Norddahl wrote: >> >> This is Google saying that Google does not want to pay for traffic to >> Cogent. If Cogent wants to exchange any traffic with Google, Cogent is >> invited to peer directly with Google. Of course Cogent refuses. And now >> Cogent is not only missing the part of IPv6 internet that is Hurricane >> Electric single homed but also everything Google. >> >> Why does Cogent refuse? They used to deliver this traffic on free peering >> with another tier 1 provider. Now they are asked to deliver the same >> traffic for the same price (free) on a direct peering session. They won't >> because Cogent believes Google should pay for this traffic. That another >> Cogent customer already paid for the traffic does not matter. They want >> double dipping or nothing. So nothing it is. >> >> Seems to me that if you are serious about IPv6 you can not use Cogent as >> your primary or secondary transit provider. You can use them as your third >> if you want to. >> >> Regards, >> >> Baldur >> >> >> >> On 24 February 2016 at 20:46, Matt Hoppes >> wrote: >> >>> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, >>> shouldn't the traffic flow out to one of their peer points where another >>> peer DOES peer with Google IPv6 and get you in? >>> >>> Isn't that how the Internet is suppose to work? >>> >>> >>> On 2/24/16 2:43 PM, Damien Burke wrote: >>> >>>> Not sure. I got the same thing today as well. >>>> >>>> Is this some kind of ipv6 war? >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark >>>> Sent: Wednesday, February 24, 2016 10:25 AM >>>> To: NANOG >>>> Subject: Cogent & Google IPv6 >>>> >>>> Anyone know what's actually going on here? We received the following >>>> information from the two of them, and this just started a week or so ago. >>>> >>>> >>>> *From Cogent, the transit provider for a branch office of ours:* >>>> >>>> Dear Cogent Customer, >>>> >>>> Thank you for contacting Cogent Customer Support for information about >>>> the Google IPv6 addresses you are unable to reach. >>>> >>>> Google uses transit providers to announce their IPv4 routes to Cogent. >>>> >>>> At this time however, Google has chosen not to announce their IPv6 routes >>>> to Cogent through transit providers. >>>> >>>> We apologize for any inconvenience this may cause you and will notify you >>>> if there is an update to the situation. >>>> >>>> >>>> >>>> *From Google (re: Cogent):* >>>> >>>> Unfortunately it seems that your transit provider does not have IPv6 >>>> connectivity with Google. We suggest you ask your transit provider to look >>>> for alternatives to interconnect with us. >>>> >>>> Google maintains an open interconnect policy for IPv6 and welcomes any >>>> network to peer with us for access via IPv6 (and IPv4). For those networks >>>> that aren't able, or chose not to peer with Google via IPv6, they are able >>>> to reach us through any of a large number of transit providers. >>>> >>>> For more information in how to peer directly with Google please visit >>>> https://peering.google.com >>>> >>>> >>>> -- >>>> Ian Clark >>>> Lead Network Engineer >>>> DreamHost >>>> >>>> > From paras at protrafsolutions.com Wed Feb 24 21:37:20 2016 From: paras at protrafsolutions.com (Paras Jha) Date: Wed, 24 Feb 2016 16:37:20 -0500 Subject: Cogent & Google IPv6 In-Reply-To: <1469681630.11137.1456347727250.JavaMail.mhammett@ThunderFuck> References: <91CDF434-22A2-47C6-9CD9-EF269A0F7156@ianai.net> <1469681630.11137.1456347727250.JavaMail.mhammett@ThunderFuck> Message-ID: Transit providers are the mdidlemen of the internet, I see no problem with the concept of "double dipping". It's their fiber and infrastructure, if you want access to everything on their network, including other people on their network, pay for it or find a way to get access. On Wed, Feb 24, 2016 at 4:02 PM, Mike Hammett wrote: > *nods* and everything is pros and cons. In one's situation, does Cogent > have enough pros to overcome the cons? Same for HE or any other carrier. If > I get full tables (v4 and b6) from multiple networks and\or I peer with the > networks that are missing from a particular provider's offering, I may very > well not give a darn about it being missing. I may never have even used it > in the first place. If whatever advantages to me outweigh that loss, so be > it. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Wednesday, February 24, 2016 2:27:21 PM > Subject: Re: Cogent & Google IPv6 > > Agreed on all points. ?Double dipping? is not morally abhorrent, or even > slightly slimy. However, Cogent customers paid Cogent to connect to The > Internet, not ?The other networks that are paying Cogent?. So in this case, > if I had to make a choice of which provider to drop, I?d stick with Google. > (I do not have to make such a decision.) > > One could claim the same about HE vs. Cogent. However, I?m still going to > give the nod to the people saying ?we are happy to connect? over the people > who say ?pay me to connect?. Obviously a lot of details I?m glossing over, > but HE does have, IMHO, a good argument for v6 peering with Cogent. Doesn?t > mean either is ?wrong", just that is how I would vote with my wallet if I > had to make the choice. (Again, I do not.) > > So when FB does the same thing, when Comcast does the same thing, when > Apple does the same thing, when ?. When will Cogent feel enough pain to > relent? > > Or will this simply delay the full implementation of IPv6 even more, and > Cogent won?t notice because everyone falls back to v4? > > -- > TTFN, > patrick > > > On Feb 24, 2016, at 3:16 PM, Mike Hammett wrote: > > > > Whomever hurts the most will blink first. I don't really care who that > is. I have no ill will towards "double dipping". Either they do or they > don't offer the desired connectivity and I'm moving on. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Patrick W. Gilmore" > > To: "NANOG list" > > Sent: Wednesday, February 24, 2016 2:12:07 PM > > Subject: Re: Cogent & Google IPv6 > > > > Are HE & Google the new L3 & FT? > > > > Nah, L3 would never have baked Cogent a cake. :) > > > > Shall we start a pool? Only problem is, should the pool be ?who will > disconnect from Cogent next?? or ?when will Cogent blink?? I?m voting for > the former. > > > > -- > > TTFN, > > patrick > > > >> On Feb 24, 2016, at 3:08 PM, Baldur Norddahl > wrote: > >> > >> This is Google saying that Google does not want to pay for traffic to > >> Cogent. If Cogent wants to exchange any traffic with Google, Cogent is > >> invited to peer directly with Google. Of course Cogent refuses. And now > >> Cogent is not only missing the part of IPv6 internet that is Hurricane > >> Electric single homed but also everything Google. > >> > >> Why does Cogent refuse? They used to deliver this traffic on free > peering > >> with another tier 1 provider. Now they are asked to deliver the same > >> traffic for the same price (free) on a direct peering session. They > won't > >> because Cogent believes Google should pay for this traffic. That another > >> Cogent customer already paid for the traffic does not matter. They want > >> double dipping or nothing. So nothing it is. > >> > >> Seems to me that if you are serious about IPv6 you can not use Cogent as > >> your primary or secondary transit provider. You can use them as your > third > >> if you want to. > >> > >> Regards, > >> > >> Baldur > >> > >> > >> > >> On 24 February 2016 at 20:46, Matt Hoppes > >> wrote: > >> > >>> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, > >>> shouldn't the traffic flow out to one of their peer points where > another > >>> peer DOES peer with Google IPv6 and get you in? > >>> > >>> Isn't that how the Internet is suppose to work? > >>> > >>> > >>> On 2/24/16 2:43 PM, Damien Burke wrote: > >>> > >>>> Not sure. I got the same thing today as well. > >>>> > >>>> Is this some kind of ipv6 war? > >>>> > >>>> -----Original Message----- > >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark > >>>> Sent: Wednesday, February 24, 2016 10:25 AM > >>>> To: NANOG > >>>> Subject: Cogent & Google IPv6 > >>>> > >>>> Anyone know what's actually going on here? We received the following > >>>> information from the two of them, and this just started a week or so > ago. > >>>> > >>>> > >>>> *From Cogent, the transit provider for a branch office of ours:* > >>>> > >>>> Dear Cogent Customer, > >>>> > >>>> Thank you for contacting Cogent Customer Support for information about > >>>> the Google IPv6 addresses you are unable to reach. > >>>> > >>>> Google uses transit providers to announce their IPv4 routes to Cogent. > >>>> > >>>> At this time however, Google has chosen not to announce their IPv6 > routes > >>>> to Cogent through transit providers. > >>>> > >>>> We apologize for any inconvenience this may cause you and will notify > you > >>>> if there is an update to the situation. > >>>> > >>>> > >>>> > >>>> *From Google (re: Cogent):* > >>>> > >>>> Unfortunately it seems that your transit provider does not have IPv6 > >>>> connectivity with Google. We suggest you ask your transit provider to > look > >>>> for alternatives to interconnect with us. > >>>> > >>>> Google maintains an open interconnect policy for IPv6 and welcomes any > >>>> network to peer with us for access via IPv6 (and IPv4). For those > networks > >>>> that aren't able, or chose not to peer with Google via IPv6, they are > able > >>>> to reach us through any of a large number of transit providers. > >>>> > >>>> For more information in how to peer directly with Google please visit > >>>> https://peering.google.com > >>>> > >>>> > >>>> -- > >>>> Ian Clark > >>>> Lead Network Engineer > >>>> DreamHost > >>>> > >>>> > > > > > From brandon at rd.bbc.co.uk Wed Feb 24 21:40:51 2016 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Wed, 24 Feb 2016 21:40:51 GMT Subject: Cogent & Google IPv6 Message-ID: <201602242140.VAA17234@sunf10.rd.bbc.co.uk> > From nanog-bounces at nanog.org Wed Feb 24 21:03:17 2016 > In one's situation, does Cogent have enough pros to overcome the > cons? Same for HE or any other carrier. Who cares, with everyone trying to be IPv6 transit free and covering it with a settlement free peering policy it may accidentally turn into an open peering stand off and everyone wins (except single homed Cogent customers but they'll figure it out) brandon From jfbeam at gmail.com Wed Feb 24 21:48:24 2016 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 24 Feb 2016 16:48:24 -0500 Subject: Cogent & Google IPv6 In-Reply-To: References: <1906151786.11094.1456345593687.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, 24 Feb 2016 15:48:22 -0500, Patrick W. Gilmore wrote: > And Ricky is wrong, the vast majority of prefixes Cogent routes have > zero dollars behind them. Cogent gets paid by customers, not peers. (At > least not the big ones.) Show me a single connection to Cogent for which Cogent isn't being paid. Cogent is the only provider I've ever heard of that will not do any form of settlement-free peering. From patrick at ianai.net Wed Feb 24 21:51:55 2016 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 24 Feb 2016 16:51:55 -0500 Subject: Cogent & Google IPv6 In-Reply-To: References: <1906151786.11094.1456345593687.JavaMail.mhammett@ThunderFuck> Message-ID: On Feb 24, 2016, at 4:48 PM, Ricky Beam wrote: > On Wed, 24 Feb 2016 15:48:22 -0500, Patrick W. Gilmore wrote: >> And Ricky is wrong, the vast majority of prefixes Cogent routes have zero dollars behind them. Cogent gets paid by customers, not peers. (At least not the big ones.) > > Show me a single connection to Cogent for which Cogent isn't being paid. Cogent is the only provider I've ever heard of that will not do any form of settlement-free peering. You really think AT&T, Comcast, Level 3, Sprint, Verizon, etc. are paying Cogent? Good thing I put my drink down before I read that. Or do you think Cogent is paying all of them? That is a possibility, but it means that Cogent is not getting paid - by definition. -- TTFN, patrick From Valdis.Kletnieks at vt.edu Wed Feb 24 23:18:10 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 24 Feb 2016 18:18:10 -0500 Subject: Cogent & Google IPv6 In-Reply-To: References: <1906151786.11094.1456345593687.JavaMail.mhammett@ThunderFuck> Message-ID: <38119.1456355890@turing-police.cc.vt.edu> On Wed, 24 Feb 2016 16:51:55 -0500, "Patrick W. Gilmore" said: > Or do you think Cogent is paying all of them? That is a possibility, but it > means that Cogent is not getting paid - by definition. All depends how creative their accountants are... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From fkittred at gwi.net Wed Feb 24 20:55:35 2016 From: fkittred at gwi.net (Fletcher Kittredge) Date: Wed, 24 Feb 2016 15:55:35 -0500 Subject: Standard terminology for a dark fiber path? Message-ID: What is the standard terminology for strands of dark fiber spliced together to form a continuous path between points A and Z? I have seen: - *fiber circuit* [but also seen used to denote a connection at the network layer over a physical fiber connection. This definition of circuit would include the dark fiber path, the transmitters and receivers and logic making up the data and network layers.] - *fiber loop *[ Does a loop define an electrical circuit with two physically separate positive and negative strands? In that case, is this a Bellhead remnant? ] I am particularly interested in last mile systems, but I don't see any reason that the term wouldn't be the same in the middle mile. thanks, Fletcher -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From larrysheldon at cox.net Thu Feb 25 06:02:35 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 25 Feb 2016 00:02:35 -0600 Subject: Standard terminology for a dark fiber path? In-Reply-To: References: Message-ID: <56CE98FB.2030100@cox.net> On 2/24/2016 14:55, Fletcher Kittredge wrote: > What is the standard terminology for strands of dark fiber spliced together > to form a continuous path between points A and Z? > > I have seen: > > - *fiber circuit* [but also seen used to denote a connection at the > network layer over a physical fiber connection. This definition of circuit > would include the dark fiber path, the transmitters and receivers and logic > making up the data and network layers.] > - *fiber loop *[ Does a loop define an electrical circuit with two > physically separate positive and negative strands? In that case, is this a > Bellhead remnant? ] > > I am particularly interested in last mile systems, but I don't see any > reason that the term wouldn't be the same in the middle mile. What do you call it if it is made out of copper instead of glass? Or air? I don't see anything wrong with "fiber path". (Answering my own question, maybe: "dry pair from A to B". "[Microwave] Radio link between A and B.") -- sed quis custodiet ipsos custodes? (Juvenal) From randy at psg.com Thu Feb 25 20:30:17 2016 From: randy at psg.com (Randy Bush) Date: Fri, 26 Feb 2016 05:30:17 +0900 Subject: Cogent & Google IPv6 In-Reply-To: References: <1906151786.11094.1456345593687.JavaMail.mhammett@ThunderFuck> Message-ID: > Show me a single connection to Cogent for which Cogent isn't being > paid. i suspect none of att|ntt|l3|... pay cogent From mhardeman at ipifony.com Thu Feb 25 21:04:05 2016 From: mhardeman at ipifony.com (Matthew D. Hardeman) Date: Thu, 25 Feb 2016 15:04:05 -0600 Subject: Cogent & Google IPv6 In-Reply-To: <56CE0A23.2030206@netassist.ua> References: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> <56CE08B0.2080103@indigowireless.com> <56CE0A23.2030206@netassist.ua> Message-ID: <40947023-CF8B-440D-9634-85C53C1E8E39@ipifony.com> What?s truly amazing to me about this is that only Cogent seems to be engaging in this kind of behavior on IPv6. Furthermore, the only people Cogent is hurting with their willful ignorance of the changing peering landscape in IPv6 is THEIR OWN PAYING CUSTOMERS. Which is really bizarre when you think about it. I?m trying to understand this from Cogent?s perspective and failing. They are creating a problem that impacts only their customers while others do not create this same problem. How can they imagine this is benefiting them? > On Feb 24, 2016, at 1:53 PM, Max Tulyev wrote: > > If you connected to Internet ONLY through Cogent - there is no other > way. If you have another upstreams - Google should be reachable. > > On 24.02.16 21:46, Matt Hoppes wrote: >> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, >> shouldn't the traffic flow out to one of their peer points where another >> peer DOES peer with Google IPv6 and get you in? >> >> Isn't that how the Internet is suppose to work? >> >> >> On 2/24/16 2:43 PM, Damien Burke wrote: >>> Not sure. I got the same thing today as well. >>> >>> Is this some kind of ipv6 war? >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark >>> Sent: Wednesday, February 24, 2016 10:25 AM >>> To: NANOG >>> Subject: Cogent & Google IPv6 >>> >>> Anyone know what's actually going on here? We received the following >>> information from the two of them, and this just started a week or so ago. >>> >>> >>> *From Cogent, the transit provider for a branch office of ours:* >>> >>> Dear Cogent Customer, >>> >>> Thank you for contacting Cogent Customer Support for information about >>> the Google IPv6 addresses you are unable to reach. >>> >>> Google uses transit providers to announce their IPv4 routes to Cogent. >>> >>> At this time however, Google has chosen not to announce their IPv6 >>> routes to Cogent through transit providers. >>> >>> We apologize for any inconvenience this may cause you and will notify >>> you if there is an update to the situation. >>> >>> >>> >>> *From Google (re: Cogent):* >>> >>> Unfortunately it seems that your transit provider does not have IPv6 >>> connectivity with Google. We suggest you ask your transit provider to >>> look for alternatives to interconnect with us. >>> >>> Google maintains an open interconnect policy for IPv6 and welcomes any >>> network to peer with us for access via IPv6 (and IPv4). For those >>> networks that aren't able, or chose not to peer with Google via IPv6, >>> they are able to reach us through any of a large number of transit >>> providers. >>> >>> For more information in how to peer directly with Google please visit >>> https://peering.google.com >>> >>> >>> -- >>> Ian Clark >>> Lead Network Engineer >>> DreamHost >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4190 bytes Desc: not available URL: From randy at psg.com Thu Feb 25 21:17:26 2016 From: randy at psg.com (Randy Bush) Date: Fri, 26 Feb 2016 06:17:26 +0900 Subject: Cogent & Google IPv6 In-Reply-To: <40947023-CF8B-440D-9634-85C53C1E8E39@ipifony.com> References: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> <56CE08B0.2080103@indigowireless.com> <56CE0A23.2030206@netassist.ua> <40947023-CF8B-440D-9634-85C53C1E8E39@ipifony.com> Message-ID: i suspect that what is goiing on here is actually a good sign of ipv6 becoming commercially real. for the last couple of decades, ipv6 has been connected via tunnels, an unusual amount of free peering, packets carried by donkeys over the mountains, anything that worked. as ipv6 starts to become commercially real, traffic exchange agreements are becoming commercial. so the free peering etc. are going away. it sure would be nice if the tunnels and donkeys went away too. welcome to the not my mother's internet. yes, virginia, there really are tier-1 settlement-free providers. but keep whining, it moves a lot of packets; not. randy From mureninc at gmail.com Thu Feb 25 21:40:27 2016 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 25 Feb 2016 13:40:27 -0800 Subject: Cogent & Google IPv6 In-Reply-To: <40947023-CF8B-440D-9634-85C53C1E8E39@ipifony.com> References: <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local> <56CE08B0.2080103@indigowireless.com> <56CE0A23.2030206@netassist.ua> <40947023-CF8B-440D-9634-85C53C1E8E39@ipifony.com> Message-ID: I completely agree, the only possible explanation would be if they actually get paid by Google for IPv4 transit (either directly or indirectly), or somehow use Google's IPv4 traffic as a leverage to pad the in/out ratios (and/or overall traffic levels) such as to continue to enjoy settlement-free peering with other transit providers. C. On 25 February 2016 at 13:04, Matthew D. Hardeman wrote: > What?s truly amazing to me about this is that only Cogent seems to be engaging in this kind of behavior on IPv6. Furthermore, the only people Cogent is hurting with their willful ignorance of the changing peering landscape in IPv6 is THEIR OWN PAYING CUSTOMERS. Which is really bizarre when you think about it. I?m trying to understand this from Cogent?s perspective and failing. They are creating a problem that impacts only their customers while others do not create this same problem. How can they imagine this is benefiting them? > > >> On Feb 24, 2016, at 1:53 PM, Max Tulyev wrote: >> >> If you connected to Internet ONLY through Cogent - there is no other >> way. If you have another upstreams - Google should be reachable. >> >> On 24.02.16 21:46, Matt Hoppes wrote: >>> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, >>> shouldn't the traffic flow out to one of their peer points where another >>> peer DOES peer with Google IPv6 and get you in? >>> >>> Isn't that how the Internet is suppose to work? >>> >>> >>> On 2/24/16 2:43 PM, Damien Burke wrote: >>>> Not sure. I got the same thing today as well. >>>> >>>> Is this some kind of ipv6 war? >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark >>>> Sent: Wednesday, February 24, 2016 10:25 AM >>>> To: NANOG >>>> Subject: Cogent & Google IPv6 >>>> >>>> Anyone know what's actually going on here? We received the following >>>> information from the two of them, and this just started a week or so ago. >>>> >>>> >>>> *From Cogent, the transit provider for a branch office of ours:* >>>> >>>> Dear Cogent Customer, >>>> >>>> Thank you for contacting Cogent Customer Support for information about >>>> the Google IPv6 addresses you are unable to reach. >>>> >>>> Google uses transit providers to announce their IPv4 routes to Cogent. >>>> >>>> At this time however, Google has chosen not to announce their IPv6 >>>> routes to Cogent through transit providers. >>>> >>>> We apologize for any inconvenience this may cause you and will notify >>>> you if there is an update to the situation. >>>> >>>> >>>> >>>> *From Google (re: Cogent):* >>>> >>>> Unfortunately it seems that your transit provider does not have IPv6 >>>> connectivity with Google. We suggest you ask your transit provider to >>>> look for alternatives to interconnect with us. >>>> >>>> Google maintains an open interconnect policy for IPv6 and welcomes any >>>> network to peer with us for access via IPv6 (and IPv4). For those >>>> networks that aren't able, or chose not to peer with Google via IPv6, >>>> they are able to reach us through any of a large number of transit >>>> providers. >>>> >>>> For more information in how to peer directly with Google please visit >>>> https://peering.google.com >>>> >>>> >>>> -- >>>> Ian Clark >>>> Lead Network Engineer >>>> DreamHost From ryangard at gmail.com Thu Feb 25 21:45:41 2016 From: ryangard at gmail.com (Ryan Gard) Date: Thu, 25 Feb 2016 16:45:41 -0500 Subject: Ticketmaster Blocking IPs? Message-ID: Hello folks, I'm grasping a bit at straws here, and really hope maybe somebody has some knowledge that may assist in getting an answer where we've been met with silence. We're a small isp who unfortunately is dealing with our entire range of IP blocks being restricted on what appears to be a permanent basis from TicketMaster's services. We've attempted all avenues available to reach out to them, between their NOC contact and their... client support contacts... to no avail. Unfortunately, the ones caught out in the cold at this point have been the end users who as a result cannot utilize Ticketmaster... I'm hoping someone can offer some insight if they've been down this path before, or further, if you're from Ticketmaster, contact me off list to trade coordinates so we can resolve this quickly. Thanks! -- Ryan Gard From ryangard at gmail.com Thu Feb 25 21:49:03 2016 From: ryangard at gmail.com (Ryan Gard) Date: Thu, 25 Feb 2016 16:49:03 -0500 Subject: Netflix NOC? VPN Mismarked? In-Reply-To: References: Message-ID: To offer some closure on this, after digging up the NOC contact and sending them a lengthy eMail detailing the issue and the ip blocks in question, they were quick to resolve the issue and get the clients up and rolling again. Thanks again for everyone's insight. On Tue, Jan 26, 2016 at 2:49 PM, Josh Luthman wrote: > Use cdnetops at netflix.com > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Sun, Jan 24, 2016 at 10:32 PM, Ryan Gard wrote: > >> Hey, >> >> Per chance if someone @ Netflix could reach me off list? Seems that as of >> this weekend there's a number of our clients (residential internet) who >> are >> unable to utilize Netflix directly, instead being presented with a message >> advising them they're using a VPN service... Have a feeling that our IP >> blocks were lumped in with someone somehow... >> >> Thanks! >> >> -- >> Ryan Gard >> > > -- Ryan Gard From Steve.Mikulasik at civeo.com Thu Feb 25 21:55:11 2016 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Thu, 25 Feb 2016 21:55:11 +0000 Subject: Ticketmaster Blocking IPs? In-Reply-To: References: Message-ID: Funny, I am dealing with the same issue, you are not alone! Reverse lookup on their IP shows that it is hosted by Akamai. I have reached out to them, but the issue hasn't been resolved yet. I have had issues with Akamai black listing our IPs in the past, it has taken 1-2 weeks to get it fully resolved normally. Non-authoritative answer: Name: www.ticketmaster.com Address: 23.221.34.213 Name: a23-221-34-213.deploy.static.akamaitechnologies.com Address: 23.221.34.213 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ryan Gard Sent: Thursday, February 25, 2016 2:46 PM To: nanog at nanog.org Subject: Ticketmaster Blocking IPs? Hello folks, I'm grasping a bit at straws here, and really hope maybe somebody has some knowledge that may assist in getting an answer where we've been met with silence. We're a small isp who unfortunately is dealing with our entire range of IP blocks being restricted on what appears to be a permanent basis from TicketMaster's services. We've attempted all avenues available to reach out to them, between their NOC contact and their... client support contacts... to no avail. Unfortunately, the ones caught out in the cold at this point have been the end users who as a result cannot utilize Ticketmaster... I'm hoping someone can offer some insight if they've been down this path before, or further, if you're from Ticketmaster, contact me off list to trade coordinates so we can resolve this quickly. Thanks! -- Ryan Gard From brian.cruze at verizon.com Thu Feb 25 16:43:28 2016 From: brian.cruze at verizon.com (Cruze, Brian A) Date: Thu, 25 Feb 2016 11:43:28 -0500 Subject: Looking for someone behind noc@internap.net Message-ID: Can someone with Internap that lives behind the noc at internap.net contact me off list? It seems nobody monitors that mailbox... From mkoshti at gmail.com Thu Feb 25 18:07:47 2016 From: mkoshti at gmail.com (Manoj Koshti) Date: Thu, 25 Feb 2016 10:07:47 -0800 Subject: XO and Cox Message-ID: Hi All, If customers are on XO or Cox what is the best to minimize the XO/COX backhaul network. Which ISP should be best transit/peering that can offload traffic to local egress point? Thanks Manoj From anthonyrjunk at gmail.com Thu Feb 25 18:08:01 2016 From: anthonyrjunk at gmail.com (Anthony Junk) Date: Thu, 25 Feb 2016 13:08:01 -0500 Subject: Standard terminology for a dark fiber path? In-Reply-To: <56CE98FB.2030100@cox.net> References: <56CE98FB.2030100@cox.net> Message-ID: Just my .02 but I would think to call it a "single fiber link" or perhaps just a "fiber link". A fiber path doesn't strike me as being one solid connection but could instead include patching in the middle and not be a continuous strand. As far as fiber loop, that is used to reference the OC192 transport ring that exists in the DC metro area. Again, this is just from my experience but I find people misusing terms all the time so I've come to accept that I need to always ask qualifying questions to determine what they truly mean. Sincerely, Anthony R Junk Network and Security Engineer (410) 929-1838 anthonyrjunk at gmail.com On Thu, Feb 25, 2016 at 1:02 AM, Larry Sheldon wrote: > On 2/24/2016 14:55, Fletcher Kittredge wrote: > >> What is the standard terminology for strands of dark fiber spliced >> together >> to form a continuous path between points A and Z? >> >> I have seen: >> >> - *fiber circuit* [but also seen used to denote a connection at the >> network layer over a physical fiber connection. This definition of >> circuit >> would include the dark fiber path, the transmitters and receivers and >> logic >> making up the data and network layers.] >> - *fiber loop *[ Does a loop define an electrical circuit with two >> physically separate positive and negative strands? In that case, is >> this a >> Bellhead remnant? ] >> >> I am particularly interested in last mile systems, but I don't see any >> reason that the term wouldn't be the same in the middle mile. >> > > What do you call it if it is made out of copper instead of glass? Or air? > > I don't see anything wrong with "fiber path". > > (Answering my own question, maybe: "dry pair from A to B". "[Microwave] > Radio link between A and B.") > > > > -- > sed quis custodiet ipsos custodes? (Juvenal) > From mloftis at wgops.com Thu Feb 25 23:27:17 2016 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 25 Feb 2016 15:27:17 -0800 Subject: Standard terminology for a dark fiber path? In-Reply-To: References: Message-ID: IDK what elsewhere uses but strand or (less common) span is the common term I've seen specifically for a passive piece of glass between two points. On Wed, Feb 24, 2016 at 12:55 PM, Fletcher Kittredge wrote: > What is the standard terminology for strands of dark fiber spliced together > to form a continuous path between points A and Z? > > I have seen: > > - *fiber circuit* [but also seen used to denote a connection at the > network layer over a physical fiber connection. This definition of circuit > would include the dark fiber path, the transmitters and receivers and logic > making up the data and network layers.] > - *fiber loop *[ Does a loop define an electrical circuit with two > physically separate positive and negative strands? In that case, is this a > Bellhead remnant? ] > > I am particularly interested in last mile systems, but I don't see any > reason that the term wouldn't be the same in the middle mile. > > thanks, > Fletcher > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From mcenzatti at hush.com Fri Feb 26 00:26:05 2016 From: mcenzatti at hush.com (Marcus Cenzatti) Date: Thu, 25 Feb 2016 21:26:05 -0300 Subject: Ticketmaster Blocking IPs? In-Reply-To: Message-ID: <20160226002605.E6EE340102@smtp.hushmail.com> On 2/25/2016 at 6:46 PM, "Ryan Gard" wrote: > >Hello folks, > >I'm grasping a bit at straws here, and really hope maybe somebody >has some >knowledge that may assist in getting an answer where we've been >met with >silence. > >We're a small isp who unfortunately is dealing with our entire >range of IP >blocks being restricted on what appears to be a permanent basis >from >TicketMaster's services. We've attempted all avenues available to >reach out >to them, between their NOC contact and their... client support >contacts... >to no avail. Unfortunately, the ones caught out in the cold at >this point >have been the end users who as a result cannot utilize >Ticketmaster... > >I'm hoping someone can offer some insight if they've been down >this path >before, or further, if you're from Ticketmaster, contact me off >list to >trade coordinates so we can resolve this quickly. > >Thanks! First you were blocked by Netflix, now Ticketmaster, is your CIDR a newly assigned one, part of a block previously reserved or something? It looks like there's a chance you lack on proper IRR registries or you are still marked bogon for any reason. Do some investigations on your CIDR, who it belonged before (previous IRR, past whois dbs, IP reputation databases, etc). Regarding TM, well it's Akamai, maybe you will have some luck calling +1-617-444-2535? -- Marcus Cenzatti > >-- >Ryan Gard From craetdave at gmail.com Fri Feb 26 01:32:28 2016 From: craetdave at gmail.com (Dave Cohen) Date: Thu, 25 Feb 2016 20:32:28 -0500 Subject: Standard terminology for a dark fiber path? In-Reply-To: References: Message-ID: FWIW, at my $dayjob (a fiber-based service provider), the accepted term is "span", which accounts for any continuous segment between add/drop and/or regen locations (i.e. no provider or end user electronics in the middle, only at the endpoints). The most common alternate I come across is "segment". Re a couple of earlier suggestions - A patch between cables to provide continuity, as compared to a fusion splice, doesn't inherently change this view, as it has no bearing on the logical use of the span. Similarly, "strand" isn't favored as it assumes a single fiber only, where the vast majority of applications require a pair (or multiple pairs), so doesn't accurately reflect the logical use of the span. I think "1F Span" is the favored reference for a single-fiber deployment, for the sake of both consistency and clarity. On Thu, Feb 25, 2016 at 6:27 PM, Michael Loftis wrote: > IDK what elsewhere uses but strand or (less common) span is the common > term I've seen specifically for a passive piece of glass between two > points. > > On Wed, Feb 24, 2016 at 12:55 PM, Fletcher Kittredge > wrote: > > What is the standard terminology for strands of dark fiber spliced > together > > to form a continuous path between points A and Z? > > > > I have seen: > > > > - *fiber circuit* [but also seen used to denote a connection at the > > network layer over a physical fiber connection. This definition of > circuit > > would include the dark fiber path, the transmitters and receivers and > logic > > making up the data and network layers.] > > - *fiber loop *[ Does a loop define an electrical circuit with two > > physically separate positive and negative strands? In that case, is > this a > > Bellhead remnant? ] > > > > I am particularly interested in last mile systems, but I don't see any > > reason that the term wouldn't be the same in the middle mile. > > > > thanks, > > Fletcher > > > > -- > > Fletcher Kittredge > > GWI > > 8 Pomerleau Street > > Biddeford, ME 04005-9457 > > 207-602-1134 > > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler > -- - Dave Cohen eM: craetdave at gmail.com AIM: dCo says From nanog at ics-il.net Fri Feb 26 03:46:12 2016 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 25 Feb 2016 21:46:12 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> Message-ID: <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> I know. It seems odd, doesn't it? They're actually suspending people's accounts for DNS amplification. My aunt got a call about it tonight. I had already firewalled that off on her router before they called, but they're doing it. There's more that they could do I'm sure, but they're doing it. Maybe it's flooding their upstream causing other service issues.... but they're doing it. So many others aren't doing much at all. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From paras at protrafsolutions.com Fri Feb 26 03:52:34 2016 From: paras at protrafsolutions.com (Paras Jha) Date: Thu, 25 Feb 2016 22:52:34 -0500 Subject: Thank you, Comcast. In-Reply-To: <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> Message-ID: It's interesting that they'd call about DNS amplification... You don't typically see DNS amplified floods coming from home ISPs. I would imagine SSDP amplification is a far greater issue for any home ISP. On Thu, Feb 25, 2016 at 10:46 PM, Mike Hammett wrote: > I know. It seems odd, doesn't it? > > They're actually suspending people's accounts for DNS amplification. My > aunt got a call about it tonight. I had already firewalled that off on her > router before they called, but they're doing it. There's more that they > could do I'm sure, but they're doing it. Maybe it's flooding their upstream > causing other service issues.... but they're doing it. > > So many others aren't doing much at all. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From rdobbins at arbor.net Fri Feb 26 03:58:11 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 26 Feb 2016 10:58:11 +0700 Subject: Thank you, Comcast. In-Reply-To: References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> Message-ID: <8FAB829A-3A59-4CE7-BF53-01EDC4B9F749@arbor.net> On 26 Feb 2016, at 10:52, Paras Jha wrote: > You don't typically see DNS amplified floods coming from home ISPs. Actually, it's quite common, as a lot of CPE have abusable DNS forwarders running on their public interfaces. DNS, SSDP, and SNMP reflection/amplification quite commonly emanate from broadband access networks due to abusable CPE. Others, as well, of course, but those are generally the most prevalent. ----------------------------------- Roland Dobbins From jared at puck.nether.net Fri Feb 26 03:59:34 2016 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 25 Feb 2016 22:59:34 -0500 Subject: Thank you, Comcast. In-Reply-To: References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> Message-ID: SSDP, DNS and other amplification is a big issue for large consumer networks like Comcast. This is something I?m hoping other vendors take seriously (eg: Netgear) when it comes to their usage of DNSMASQ and other tools on-box and iptables configs that promote spoofing by using IP ranges vs constraining rules with the ingress/egress interface. It?s these simple amateur errors that can turn a port 53 redirect into a spoofing instance when it only passes the INPUT rule vs -t NAT rule. Please block SSDP and Chargen on your networks. Consider rate-limiting DNS & SNMP to 1% or something appropriate to avoid issues. Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work. - Jared > On Feb 25, 2016, at 10:52 PM, Paras Jha wrote: > > It's interesting that they'd call about DNS amplification... You don't > typically see DNS amplified floods coming from home ISPs. I would imagine > SSDP amplification is a far greater issue for any home ISP. > > On Thu, Feb 25, 2016 at 10:46 PM, Mike Hammett wrote: > >> I know. It seems odd, doesn't it? >> >> They're actually suspending people's accounts for DNS amplification. My >> aunt got a call about it tonight. I had already firewalled that off on her >> router before they called, but they're doing it. There's more that they >> could do I'm sure, but they're doing it. Maybe it's flooding their upstream >> causing other service issues.... but they're doing it. >> >> So many others aren't doing much at all. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> From swmike at swm.pp.se Fri Feb 26 06:20:28 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 26 Feb 2016 07:20:28 +0100 (CET) Subject: Thank you, Comcast. In-Reply-To: References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, 25 Feb 2016, Jared Mauch wrote: > Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work. Speaking of which, historically ISPs have been blocking TCP/135, TCP/445 and a few others towards customers (at least that's what I know). TCP/25 seems to be blocked as well. Why isn't UDP/53 blocked towards customers? I know historically there were resolvers that used UDP/53 as source port for queries, but is this the case nowadays? I know providers that have blocked UDP/53 towards customers as a countermeasure to the amplification attacks. As far as I heard, there were no customer complaints. -- Mikael Abrahamsson email: swmike at swm.pp.se From marka at isc.org Fri Feb 26 06:27:07 2016 From: marka at isc.org (Mark Andrews) Date: Fri, 26 Feb 2016 17:27:07 +1100 Subject: Thank you, Comcast. In-Reply-To: Your message of "Fri, 26 Feb 2016 07:20:28 +0100." References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> Message-ID: <20160226062707.2B6894340F53@rock.dv.isc.org> In message , Mikael Abrah amsson writes: > On Thu, 25 Feb 2016, Jared Mauch wrote: > > > Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work. > > Speaking of which, historically ISPs have been blocking TCP/135, TCP/445 > and a few others towards customers (at least that's what I know). TCP/25 > seems to be blocked as well. > > Why isn't UDP/53 blocked towards customers? I know historically there were > resolvers that used UDP/53 as source port for queries, but is this the > case nowadays? > > I know providers that have blocked UDP/53 towards customers as a > countermeasure to the amplification attacks. As far as I heard, there were > no customer complaints. Because complaining is like talking to a brick wall most of the time. People work around the ISP idiocy by shifting ports, its easier than trying to get through help desk hell. > -- > Mikael Abrahamsson email: swmike at swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mikeal.clark at gmail.com Fri Feb 26 06:36:07 2016 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Fri, 26 Feb 2016 00:36:07 -0600 Subject: Thank you, Comcast. In-Reply-To: <20160226062707.2B6894340F53@rock.dv.isc.org> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <20160226062707.2B6894340F53@rock.dv.isc.org> Message-ID: Totally agree. It's silly that my home lab has to cost me 5x the normal rate if I want to use some of the standard ports but that is normal now. On Fri, Feb 26, 2016 at 12:27 AM, Mark Andrews wrote: > > In message , Mikael Abrah > amsson writes: >> On Thu, 25 Feb 2016, Jared Mauch wrote: >> >> > Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work. >> >> Speaking of which, historically ISPs have been blocking TCP/135, TCP/445 >> and a few others towards customers (at least that's what I know). TCP/25 >> seems to be blocked as well. >> >> Why isn't UDP/53 blocked towards customers? I know historically there were >> resolvers that used UDP/53 as source port for queries, but is this the >> case nowadays? >> >> I know providers that have blocked UDP/53 towards customers as a >> countermeasure to the amplification attacks. As far as I heard, there were >> no customer complaints. > > Because complaining is like talking to a brick wall most of the > time. People work around the ISP idiocy by shifting ports, its > easier than trying to get through help desk hell. > >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at ics-il.net Fri Feb 26 12:36:46 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Feb 2016 06:36:46 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: Message-ID: <1716490168.13716.1456490206106.JavaMail.mhammett@ThunderFuck> I do on my network (well, the ISP, not the IX). It makes complete sense. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mikael Abrahamsson" To: "Jared Mauch" Cc: "NANOG list" Sent: Friday, February 26, 2016 12:20:28 AM Subject: Re: Thank you, Comcast. On Thu, 25 Feb 2016, Jared Mauch wrote: > Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work. Speaking of which, historically ISPs have been blocking TCP/135, TCP/445 and a few others towards customers (at least that's what I know). TCP/25 seems to be blocked as well. Why isn't UDP/53 blocked towards customers? I know historically there were resolvers that used UDP/53 as source port for queries, but is this the case nowadays? I know providers that have blocked UDP/53 towards customers as a countermeasure to the amplification attacks. As far as I heard, there were no customer complaints. -- Mikael Abrahamsson email: swmike at swm.pp.se From nick at foobar.org Fri Feb 26 13:17:30 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 26 Feb 2016 13:17:30 +0000 Subject: Thank you, Comcast. In-Reply-To: References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> Message-ID: <56D0506A.3030902@foobar.org> Mikael Abrahamsson wrote: > Why isn't UDP/53 blocked towards customers? I know historically there > were resolvers that used UDP/53 as source port for queries, but is this > the case nowadays? > > I know providers that have blocked UDP/53 towards customers as a > countermeasure to the amplification attacks. As far as I heard, there > were no customer complaints. Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random. If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc. Nick From nanog at ics-il.net Fri Feb 26 13:27:50 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Feb 2016 07:27:50 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: <56D0506A.3030902@foobar.org> Message-ID: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> "you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc." I'm fine with that. Residential customers shouldn't be running DNS servers anyway and as far as the outside resolvers to go, ehhhh... I see the case for OpenDNS given that you can use it to filter (though that's easily bypassed), but not really for any others. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nick Hilliard" To: "Mikael Abrahamsson" Cc: "NANOG list" Sent: Friday, February 26, 2016 7:17:30 AM Subject: Re: Thank you, Comcast. Mikael Abrahamsson wrote: > Why isn't UDP/53 blocked towards customers? I know historically there > were resolvers that used UDP/53 as source port for queries, but is this > the case nowadays? > > I know providers that have blocked UDP/53 towards customers as a > countermeasure to the amplification attacks. As far as I heard, there > were no customer complaints. Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random. If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc. Nick From yann.lejeune at gmail.com Fri Feb 26 09:33:27 2016 From: yann.lejeune at gmail.com (Yann Lejeune) Date: Fri, 26 Feb 2016 10:33:27 +0100 Subject: BGP MVPN RFC6513, Section 10 In-Reply-To: References: Message-ID: Hi To support the section ?10 in your conf you have two choices: a. (?10.1) implementing the RP on your PE (protocol pim rp local). It will advertises the route type after pim register message (or msdp source active from other RP is you have other rp in your network) + be sure to use spt-only mvpn mode (default one) b. (?10.2) implementing an MSDP session between the RP and its PE each time the RP will learn a source (either because it receives a pim register or a SA message from another RP (full meshing msdp between rp), it will advertise route type 5 to the mVPN. This way receiver PE will learnt source and if they received join (*,g), they will be able to advertise the good route type 7 to the source PE. The required conf is: - msdp session between the pe and the rp - defining the rp address (protocols pim rp static....) - be sure to use spt-only mvpn mode (default one) The route type 6 is used in another mode call rpt-spt, where you are closer to the traditionnal multicast behavior (first we build the rp tree and second we build the source tree). this mode must be enable explicitely per routing-instance in the mvpn-mode knob. One thing: even in spt-only mode, the junos will create a route type 6 when receiving a join (*,g) but will not advertise it. It just wait to get a related route type 5 It's up to you to choose what mode you want to use: - spt-only: is quite "simple". We only have (s,g) in the core. To validate an os, it's faster. - rpt-spt. We have both (*,g) and (s,g) in the core. the validation is more complex, the protocol is more dynamic... Regards, Yann. On 23 February 2016 at 16:39, Jason Iannone wrote: > Hi all, > > I'm having trouble interpreting under what circumstance section 10 of > BGP MVPN comes into play. > > The way I read this section, upon the receipt of PIM/IGMP Join to > (*,G) the Receiver Site PE does not signal Type 6 or Type 7 Joins > until a Type 5 Source Active route is received from a Sender Site PE. > > If Section 10 assumes the use of ASM groups in the VPN, why develop a > Type 6 Shared Tree Join A-D route for unknown sources? > > What are the practical minimum Juniper configurations to support > Section 10 for ASM and (*,G) PIM Join when the PE doesn't know a > source? > > CE1---PE1,C-RP-----P-----PE2---CE2 > Sender Site-------------------Receiver Site > > 1. CE1 has no active source > 2. CE2 forwards PIM Join (*,G) to PE2 toward PE1,C-RP > 3. PE2 eats PIM Join, maintains (*,G) state > 4. CE1 generates Register messages to PE1 > 5. PE1 originates Type 5 (S,G) > 6. PE2 receives Type 5 (S,G) > 7. PE2 verifies existing (*,G) state > 8. PE2 advertises Type 7 Join (S,G) > 9. PE2 does PMSI and P-Tunnel attachment > 10. PE1 receives (S,G) from PE2 > 11. PE1 adds PMSI to downstream interfaces > 12. Multicast flow end to end > 13. Achievement unlocked! > > I'm least sure about steps 2 & 3. > > Comprehension challenged, > > Jason > From volists at staff.velocityonline.net Fri Feb 26 12:34:31 2016 From: volists at staff.velocityonline.net (Velocity Lists) Date: Fri, 26 Feb 2016 07:34:31 -0500 Subject: Standard terminology for a dark fiber path? In-Reply-To: References: Message-ID: +1 on span along with fiber count designation. On Feb 25, 2016 8:52 PM, "Dave Cohen" wrote: > FWIW, at my $dayjob (a fiber-based service provider), the accepted term is > "span", which accounts for any continuous segment between add/drop and/or > regen locations (i.e. no provider or end user electronics in the middle, > only at the endpoints). The most common alternate I come across is > "segment". > > Re a couple of earlier suggestions - A patch between cables to provide > continuity, as compared to a fusion splice, doesn't inherently change this > view, as it has no bearing on the logical use of the span. Similarly, > "strand" isn't favored as it assumes a single fiber only, where the vast > majority of applications require a pair (or multiple pairs), so doesn't > accurately reflect the logical use of the span. I think "1F Span" is the > favored reference for a single-fiber deployment, for the sake of both > consistency and clarity. > > On Thu, Feb 25, 2016 at 6:27 PM, Michael Loftis wrote: > > > IDK what elsewhere uses but strand or (less common) span is the common > > term I've seen specifically for a passive piece of glass between two > > points. > > > > On Wed, Feb 24, 2016 at 12:55 PM, Fletcher Kittredge > > wrote: > > > What is the standard terminology for strands of dark fiber spliced > > together > > > to form a continuous path between points A and Z? > > > > > > I have seen: > > > > > > - *fiber circuit* [but also seen used to denote a connection at the > > > network layer over a physical fiber connection. This definition of > > circuit > > > would include the dark fiber path, the transmitters and receivers > and > > logic > > > making up the data and network layers.] > > > - *fiber loop *[ Does a loop define an electrical circuit with two > > > physically separate positive and negative strands? In that case, is > > this a > > > Bellhead remnant? ] > > > > > > I am particularly interested in last mile systems, but I don't see any > > > reason that the term wouldn't be the same in the middle mile. > > > > > > thanks, > > > Fletcher > > > > > > -- > > > Fletcher Kittredge > > > GWI > > > 8 Pomerleau Street > > > Biddeford, ME 04005-9457 > > > 207-602-1134 > > > > > > > > -- > > > > "Genius might be described as a supreme capacity for getting its > possessors > > into trouble of all kinds." > > -- Samuel Butler > > > > > > -- > - Dave Cohen > eM: craetdave at gmail.com > AIM: dCo says > From dovid at telecurve.com Fri Feb 26 13:32:09 2016 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 26 Feb 2016 13:32:09 +0000 Subject: Thank you, Comcast. In-Reply-To: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> References: <56D0506A.3030902@foobar.org> <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> Message-ID: <1204131924-1456493530-cardhu_decombobulator_blackberry.rim.net-849286781-@b11.c1.bise6.blackberry> I had a client with a few boxes that had dns wide open. Couldn't you use snort to match against those specific requests and just drop those packets? Regards, Dovid -----Original Message----- From: Mike Hammett Sender: "NANOG" Date: Fri, 26 Feb 2016 07:27:50 Cc: NANOG list Subject: Re: Thank you, Comcast. "you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc." I'm fine with that. Residential customers shouldn't be running DNS servers anyway and as far as the outside resolvers to go, ehhhh... I see the case for OpenDNS given that you can use it to filter (though that's easily bypassed), but not really for any others. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nick Hilliard" To: "Mikael Abrahamsson" Cc: "NANOG list" Sent: Friday, February 26, 2016 7:17:30 AM Subject: Re: Thank you, Comcast. Mikael Abrahamsson wrote: > Why isn't UDP/53 blocked towards customers? I know historically there > were resolvers that used UDP/53 as source port for queries, but is this > the case nowadays? > > I know providers that have blocked UDP/53 towards customers as a > countermeasure to the amplification attacks. As far as I heard, there > were no customer complaints. Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random. If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc. Nick From cb.list6 at gmail.com Fri Feb 26 13:42:55 2016 From: cb.list6 at gmail.com (Ca By) Date: Fri, 26 Feb 2016 05:42:55 -0800 Subject: Thank you, Comcast. In-Reply-To: <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> Message-ID: On Thursday, February 25, 2016, Mike Hammett wrote: > I know. It seems odd, doesn't it? > > They're actually suspending people's accounts for DNS amplification. My > aunt got a call about it tonight. I had already firewalled that off on her > router before they called, but they're doing it. There's more that they > could do I'm sure, but they're doing it. Maybe it's flooding their upstream > causing other service issues.... but they're doing it. > > So many others aren't doing much at all. > > > +1 for thank you Comcast and all the folks that file and respond to network abuse reports. Comcast is one of the good ones helping the internet thrive (IPv6, dnsssec, responding to and shutting down abuse) CB > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From rdobbins at arbor.net Fri Feb 26 13:53:41 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 26 Feb 2016 20:53:41 +0700 Subject: Thank you, Comcast. In-Reply-To: <56D0506A.3030902@foobar.org> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> Message-ID: On 26 Feb 2016, at 20:17, Nick Hilliard wrote: > If you block packets with udp src port=53 towards > customers, you will also block legitimate return traffic if the > customers run their own DNS servers or use opendns / google dns / etc. Actually, what they're talking about is blocking packets *destined* for UDP/53 on broadband access networks, not *sourced from*. ----------------------------------- Roland Dobbins From swmike at swm.pp.se Fri Feb 26 13:55:26 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 26 Feb 2016 14:55:26 +0100 (CET) Subject: Thank you, Comcast. In-Reply-To: <56D0506A.3030902@foobar.org> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> Message-ID: On Fri, 26 Feb 2016, Nick Hilliard wrote: > Traffic from dns-spoofing attacks generally has src port = 53 and dst > port = random. If you block packets with udp src port=53 towards > customers, you will also block legitimate return traffic if the > customers run their own DNS servers or use opendns / google dns / etc. Sure, it's a very interesting discussion what ports should be blocked or not. http://www.bitag.org/documents/Port-Blocking.pdf This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been blocked for a very long time to fix some issues, even though there is legitimate use for these ports. So if you're blocking these ports, it seems like a small step to block UDP/TCP/53 towards customers as well. I can't come up with an argument that makes sense to block TCP/25 and then not block port UDP/TCP/53 as well. If you're protecting the Internet from your customers misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well? This is a slippery slope of course, and judgement calls are not easy to make. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at ics-il.net Fri Feb 26 13:58:38 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Feb 2016 07:58:38 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: <1204131924-1456493530-cardhu_decombobulator_blackberry.rim.net-849286781-@b11.c1.bise6.blackberry> Message-ID: <1191055027.13800.1456495114197.JavaMail.mhammett@ThunderFuck> I'm sure someone smarter than I will chime in here, but I'd say far too much effort\resources for too little tangible results. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Dovid Bender" To: "Mike Hammett" , "NANOG" Cc: "NANOG list" Sent: Friday, February 26, 2016 7:32:09 AM Subject: Re: Thank you, Comcast. I had a client with a few boxes that had dns wide open. Couldn't you use snort to match against those specific requests and just drop those packets? Regards, Dovid -----Original Message----- From: Mike Hammett Sender: "NANOG" Date: Fri, 26 Feb 2016 07:27:50 Cc: NANOG list Subject: Re: Thank you, Comcast. "you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc." I'm fine with that. Residential customers shouldn't be running DNS servers anyway and as far as the outside resolvers to go, ehhhh... I see the case for OpenDNS given that you can use it to filter (though that's easily bypassed), but not really for any others. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nick Hilliard" To: "Mikael Abrahamsson" Cc: "NANOG list" Sent: Friday, February 26, 2016 7:17:30 AM Subject: Re: Thank you, Comcast. Mikael Abrahamsson wrote: > Why isn't UDP/53 blocked towards customers? I know historically there > were resolvers that used UDP/53 as source port for queries, but is this > the case nowadays? > > I know providers that have blocked UDP/53 towards customers as a > countermeasure to the amplification attacks. As far as I heard, there > were no customer complaints. Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random. If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc. Nick From mcole.mailinglists at gmail.com Fri Feb 26 14:18:50 2016 From: mcole.mailinglists at gmail.com (Maxwell Cole) Date: Fri, 26 Feb 2016 09:18:50 -0500 Subject: Thank you, Comcast. In-Reply-To: References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> Message-ID: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> I agree, At the very least things like SNMP/NTP should be blocked. I mean how many people actually run a legit NTP server out of their home? Dozens? And the people who run SNMP devices with the default/common communities aren?t the ones using it. If the argument is that you need a Business class account to run a mail server then I have no problem extending that to DNS servers also. Cheers, Max > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson wrote: > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > >> Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random. If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc. > > Sure, it's a very interesting discussion what ports should be blocked or not. > > http://www.bitag.org/documents/Port-Blocking.pdf > > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been blocked for a very long time to fix some issues, even though there is legitimate use for these ports. > > So if you're blocking these ports, it seems like a small step to block UDP/TCP/53 towards customers as well. I can't come up with an argument that makes sense to block TCP/25 and then not block port UDP/TCP/53 as well. If you're protecting the Internet from your customers misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well? > > This is a slippery slope of course, and judgement calls are not easy to make. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From jared at puck.nether.net Fri Feb 26 14:28:48 2016 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Feb 2016 09:28:48 -0500 Subject: Thank you, Comcast. In-Reply-To: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> Message-ID: <991FA495-A6F6-4C94-BCE9-37C1D6D73793@puck.nether.net> Most of the NTP hosts have been remediated or blocked. Using QoS to set a cap of the amount of SNMP and DNS traffic is a fair response IMHO. Some carriers eg: 7018 block chargen wholesale across their network. We haven't taken that step but it's also something I'm not opposed to. As a community we need to determine if this background radiation and these responses are proper. I think it's a good response since vendors can't do uRPF at line rate and the major purchasers of BCM switches don't ask for it and aren't doing it, so it's not optimized or does not exist. /sigh Jared Mauch > On Feb 26, 2016, at 9:18 AM, Maxwell Cole wrote: > > I agree, > > At the very least things like SNMP/NTP should be blocked. I mean how many people actually run a legit NTP server out of their home? Dozens? And the people who run SNMP devices with the default/common communities aren?t the ones using it. > > If the argument is that you need a Business class account to run a mail server then I have no problem extending that to DNS servers also. > > Cheers, > Max > >> On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson wrote: >> >> On Fri, 26 Feb 2016, Nick Hilliard wrote: >> >>> Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random. If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc. >> >> Sure, it's a very interesting discussion what ports should be blocked or not. >> >> http://www.bitag.org/documents/Port-Blocking.pdf >> >> This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been blocked for a very long time to fix some issues, even though there is legitimate use for these ports. >> >> So if you're blocking these ports, it seems like a small step to block UDP/TCP/53 towards customers as well. I can't come up with an argument that makes sense to block TCP/25 and then not block port UDP/TCP/53 as well. If you're protecting the Internet from your customers misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well? >> >> This is a slippery slope of course, and judgement calls are not easy to make. >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se From kmedcalf at dessus.com Fri Feb 26 14:31:47 2016 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 26 Feb 2016 07:31:47 -0700 Subject: Thank you, Comcast. In-Reply-To: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> Message-ID: ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet Service), and specifying exactly what the built-in deficiencies are. Deficiencies may include: port/protocol blockage toward the customer (destination blocks) port/protocol blockage toward the internet (source blocks) DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) Traffic Shaping/Policing/Congestion policies, inbound and outbound Some ISPs are good at this and provide opt-in/out methods for at least the first three on the list. Others not so much. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maxwell Cole > Sent: Friday, 26 February, 2016 07:19 > To: Mikael Abrahamsson > Cc: NANOG list > Subject: Re: Thank you, Comcast. > > I agree, > > At the very least things like SNMP/NTP should be blocked. I mean how many > people actually run a legit NTP server out of their home? Dozens? And the > people who run SNMP devices with the default/common communities aren?t the > ones using it. > > If the argument is that you need a Business class account to run a mail > server then I have no problem extending that to DNS servers also. > > Cheers, > Max > > > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson > wrote: > > > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > > > >> Traffic from dns-spoofing attacks generally has src port = 53 and dst > port = random. If you block packets with udp src port=53 towards > customers, you will also block legitimate return traffic if the customers > run their own DNS servers or use opendns / google dns / etc. > > > > Sure, it's a very interesting discussion what ports should be blocked or > not. > > > > http://www.bitag.org/documents/Port-Blocking.pdf > > > > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been > blocked for a very long time to fix some issues, even though there is > legitimate use for these ports. > > > > So if you're blocking these ports, it seems like a small step to block > UDP/TCP/53 towards customers as well. I can't come up with an argument > that makes sense to block TCP/25 and then not block port UDP/TCP/53 as > well. If you're protecting the Internet from your customers > misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well? > > > > This is a slippery slope of course, and judgement calls are not easy to > make. > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se From jared at puck.nether.net Fri Feb 26 14:28:48 2016 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Feb 2016 09:28:48 -0500 Subject: Thank you, Comcast. In-Reply-To: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> Message-ID: <991FA495-A6F6-4C94-BCE9-37C1D6D73793@puck.nether.net> Most of the NTP hosts have been remediated or blocked. Using QoS to set a cap of the amount of SNMP and DNS traffic is a fair response IMHO. Some carriers eg: 7018 block chargen wholesale across their network. We haven't taken that step but it's also something I'm not opposed to. As a community we need to determine if this background radiation and these responses are proper. I think it's a good response since vendors can't do uRPF at line rate and the major purchasers of BCM switches don't ask for it and aren't doing it, so it's not optimized or does not exist. /sigh Jared Mauch > On Feb 26, 2016, at 9:18 AM, Maxwell Cole wrote: > > I agree, > > At the very least things like SNMP/NTP should be blocked. I mean how many people actually run a legit NTP server out of their home? Dozens? And the people who run SNMP devices with the default/common communities aren?t the ones using it. > > If the argument is that you need a Business class account to run a mail server then I have no problem extending that to DNS servers also. > > Cheers, > Max > >> On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson wrote: >> >> On Fri, 26 Feb 2016, Nick Hilliard wrote: >> >>> Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random. If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc. >> >> Sure, it's a very interesting discussion what ports should be blocked or not. >> >> http://www.bitag.org/documents/Port-Blocking.pdf >> >> This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been blocked for a very long time to fix some issues, even though there is legitimate use for these ports. >> >> So if you're blocking these ports, it seems like a small step to block UDP/TCP/53 towards customers as well. I can't come up with an argument that makes sense to block TCP/25 and then not block port UDP/TCP/53 as well. If you're protecting the Internet from your customers misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well? >> >> This is a slippery slope of course, and judgement calls are not easy to make. >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se From Jason_Livingood at comcast.com Fri Feb 26 15:09:41 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Fri, 26 Feb 2016 15:09:41 +0000 Subject: Thank you, Comcast. In-Reply-To: References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> Message-ID: And you?d be correct (about SSDP). ;-) - Jason (Comcast) On 2/25/16, 10:52 PM, "NANOG on behalf of Paras Jha" wrote: >It's interesting that they'd call about DNS amplification... You don't >typically see DNS amplified floods coming from home ISPs. I would imagine >SSDP amplification is a far greater issue for any home ISP. > >On Thu, Feb 25, 2016 at 10:46 PM, Mike Hammett wrote: > >> I know. It seems odd, doesn't it? >> >> They're actually suspending people's accounts for DNS amplification. My >> aunt got a call about it tonight. I had already firewalled that off on >>her >> router before they called, but they're doing it. There's more that they >> could do I'm sure, but they're doing it. Maybe it's flooding their >>upstream >> causing other service issues.... but they're doing it. >> >> So many others aren't doing much at all. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> > From Jason_Livingood at comcast.com Fri Feb 26 15:11:01 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Fri, 26 Feb 2016 15:11:01 +0000 Subject: Thank you, Comcast. In-Reply-To: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> References: <56D0506A.3030902@foobar.org> <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> Message-ID: On 2/26/16, 8:27 AM, "NANOG on behalf of Mike Hammett" wrote: >"you will also block legitimate return traffic if the >customers run their own DNS servers or use opendns / google dns / etc." > >I'm fine with that. Residential customers shouldn't be running DNS >servers anyway and as far as the outside resolvers to go, ehhhh... I see >the case for OpenDNS given that you can use it to filter (though that's >easily bypassed), but not really for any others. There?s some question about whether the FCC or 3rd party DNS providers would be though. Especially under the Title-II rules around non-blocking of legitimate traffic. - Jason From Jason_Livingood at comcast.com Fri Feb 26 15:12:43 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Fri, 26 Feb 2016 15:12:43 +0000 Subject: Thank you, Comcast. In-Reply-To: References: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> Message-ID: FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked-ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously. We are in the process of considering adding some new ports to this block list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody). Thanks! Jason On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" on behalf of kmedcalf at dessus.com> wrote: ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet Service), and specifying exactly what the built-in deficiencies are. Deficiencies may include: port/protocol blockage toward the customer (destination blocks) port/protocol blockage toward the internet (source blocks) DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) Traffic Shaping/Policing/Congestion policies, inbound and outbound Some ISPs are good at this and provide opt-in/out methods for at least the first three on the list. Others not so much. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast. I agree, At the very least things like SNMP/NTP should be blocked. I mean how many people actually run a legit NTP server out of their home? Dozens? And the people who run SNMP devices with the default/common communities aren't the ones using it. If the argument is that you need a Business class account to run a mail server then I have no problem extending that to DNS servers also. Cheers, Max > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson > wrote: > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > >> Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random. If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc. > > Sure, it's a very interesting discussion what ports should be blocked or not. > > http://www.bitag.org/documents/Port-Blocking.pdf > > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been blocked for a very long time to fix some issues, even though there is legitimate use for these ports. > > So if you're blocking these ports, it seems like a small step to block UDP/TCP/53 towards customers as well. I can't come up with an argument that makes sense to block TCP/25 and then not block port UDP/TCP/53 as well. If you're protecting the Internet from your customers misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well? > > This is a slippery slope of course, and judgement calls are not easy to make. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From nanog at ics-il.net Fri Feb 26 15:14:19 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Feb 2016 09:14:19 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: Message-ID: <64261913.13831.1456499657138.JavaMail.mhammett@ThunderFuck> *yawn* I expected this from the news sites selling page views, not NANOG where people are supposed to actually know how things work. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" To: "NANOG list" Sent: Friday, February 26, 2016 8:31:47 AM Subject: RE: Thank you, Comcast. ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet Service), and specifying exactly what the built-in deficiencies are. Deficiencies may include: port/protocol blockage toward the customer (destination blocks) port/protocol blockage toward the internet (source blocks) DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) Traffic Shaping/Policing/Congestion policies, inbound and outbound Some ISPs are good at this and provide opt-in/out methods for at least the first three on the list. Others not so much. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maxwell Cole > Sent: Friday, 26 February, 2016 07:19 > To: Mikael Abrahamsson > Cc: NANOG list > Subject: Re: Thank you, Comcast. > > I agree, > > At the very least things like SNMP/NTP should be blocked. I mean how many > people actually run a legit NTP server out of their home? Dozens? And the > people who run SNMP devices with the default/common communities aren?t the > ones using it. > > If the argument is that you need a Business class account to run a mail > server then I have no problem extending that to DNS servers also. > > Cheers, > Max > > > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson > wrote: > > > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > > > >> Traffic from dns-spoofing attacks generally has src port = 53 and dst > port = random. If you block packets with udp src port=53 towards > customers, you will also block legitimate return traffic if the customers > run their own DNS servers or use opendns / google dns / etc. > > > > Sure, it's a very interesting discussion what ports should be blocked or > not. > > > > http://www.bitag.org/documents/Port-Blocking.pdf > > > > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been > blocked for a very long time to fix some issues, even though there is > legitimate use for these ports. > > > > So if you're blocking these ports, it seems like a small step to block > UDP/TCP/53 towards customers as well. I can't come up with an argument > that makes sense to block TCP/25 and then not block port UDP/TCP/53 as > well. If you're protecting the Internet from your customers > misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well? > > > > This is a slippery slope of course, and judgement calls are not easy to > make. > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se From egon at egon.cc Fri Feb 26 15:32:13 2016 From: egon at egon.cc (James Downs) Date: Fri, 26 Feb 2016 07:32:13 -0800 Subject: Thank you, Comcast. In-Reply-To: References: Message-ID: <19A51CD2-67DC-4724-88AE-361BC33FDB16@egon.cc> > On Feb 26, 2016, at 06:31, Keith Medcalf wrote: > > ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet Service), and specifying exactly what the built-in deficiencies are. Absolutely. It?s funny that a group that worries about about net neutrality and whinges about T-Mobile?s zero-rating certain video sources is perfectly fine with blindly blocking *ports*, without even understanding if it?s legitimate traffic. > Deficiencies may include: > port/protocol blockage toward the customer (destination blocks) > port/protocol blockage toward the internet (source blocks) > DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) This would be a big reason to point to a different DNS... > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > Some ISPs are good at this and provide opt-in/out methods for at least the first three on the list. Others not so much. From davidbass570 at gmail.com Fri Feb 26 15:54:26 2016 From: davidbass570 at gmail.com (David Bass) Date: Fri, 26 Feb 2016 10:54:26 -0500 Subject: Thank you, Comcast. In-Reply-To: References: Message-ID: <8A0DDB2E-A379-49AC-9BE2-FC8CF26EAE54@gmail.com> I agree with this...from a customer perspective. I've seen ISPs block other traffic as well...even on "business" accounts, and break their customers networks. It's the Internet not a private network... I've never been a typical user though...maybe one of the "dozen" Mike refers to that runs a email server, web server, dns server, etc, etc, etc out of their house. > On Feb 26, 2016, at 9:31 AM, Keith Medcalf wrote: > > > ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet Service), and specifying exactly what the built-in deficiencies are. > > Deficiencies may include: > port/protocol blockage toward the customer (destination blocks) > port/protocol blockage toward the internet (source blocks) > DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > Some ISPs are good at this and provide opt-in/out methods for at least the first three on the list. Others not so much. > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maxwell Cole >> Sent: Friday, 26 February, 2016 07:19 >> To: Mikael Abrahamsson >> Cc: NANOG list >> Subject: Re: Thank you, Comcast. >> >> I agree, >> >> At the very least things like SNMP/NTP should be blocked. I mean how many >> people actually run a legit NTP server out of their home? Dozens? And the >> people who run SNMP devices with the default/common communities aren?t the >> ones using it. >> >> If the argument is that you need a Business class account to run a mail >> server then I have no problem extending that to DNS servers also. >> >> Cheers, >> Max >> >>>> On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson >>> wrote: >>> >>>> On Fri, 26 Feb 2016, Nick Hilliard wrote: >>>> >>>> Traffic from dns-spoofing attacks generally has src port = 53 and dst >> port = random. If you block packets with udp src port=53 towards >> customers, you will also block legitimate return traffic if the customers >> run their own DNS servers or use opendns / google dns / etc. >>> >>> Sure, it's a very interesting discussion what ports should be blocked or >> not. >>> >>> http://www.bitag.org/documents/Port-Blocking.pdf >>> >>> This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been >> blocked for a very long time to fix some issues, even though there is >> legitimate use for these ports. >>> >>> So if you're blocking these ports, it seems like a small step to block >> UDP/TCP/53 towards customers as well. I can't come up with an argument >> that makes sense to block TCP/25 and then not block port UDP/TCP/53 as >> well. If you're protecting the Internet from your customers >> misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well? >>> >>> This is a slippery slope of course, and judgement calls are not easy to >> make. >>> >>> -- >>> Mikael Abrahamsson email: swmike at swm.pp.se > > > > From kmedcalf at dessus.com Fri Feb 26 15:55:20 2016 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 26 Feb 2016 08:55:20 -0700 Subject: Thank you, Comcast. In-Reply-To: Message-ID: On Friday, 26 February, 2016 08:13, Jason_Livingood at comcast.com said: > FWIW, Comcast's list of blocked ports is at > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > ports/. The suspensions this week are in direct response to reported abuse > from amplification attacks, which we obviously take very seriously. God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop. It has so much intertwined malicious javascript, cross-site scripting, and malicious trackers that the alarm klaxons go off when I attempt to access it. I spent a couple of minutes attempting to access the page but still maintaining blocks to the malicious links. Apparently, viewing the page requires that all security be turned off and that the viewer allows completely untrusted code from completely untrustworty sources to run unabated on the viewers computer. I do not permit this. For anyone. Ever. This pretty much ensures that I would never be one of your customers. If you cannot operate a server which serves renderable non-malicious web pages properly, what hope is there that you can do anything else right? > We are in the process of considering adding some new ports to this block > list right now, and one big suggestion is SSDP. If you have any others you > wish to suggest please send them to me and the guy on the cc line (Nirmal > Mody). > On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" bounces at nanog.org on behalf of kmedcalf at dessus.com> wrote: > > > > ISP's should block nothing, to or from the customer, unless they > make it clear *before* selling the service (and include it in the Terms > and Conditions of Service Contract), that they are not selling an Internet > connection but are selling a partially functional Internet connection (or > a limited Internet Service), and specifying exactly what the built-in > deficiencies are. > > Deficiencies may include: > port/protocol blockage toward the customer (destination blocks) > port/protocol blockage toward the internet (source blocks) > DNS diddling (filtering of responses, NXDOMAIN > redirection/wildcards, etc) > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > Some ISPs are good at this and provide opt-in/out methods for at > least the first three on the list. Others not so much. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > Maxwell Cole > Sent: Friday, 26 February, 2016 07:19 > To: Mikael Abrahamsson > Cc: NANOG list > Subject: Re: Thank you, Comcast. > I agree, > At the very least things like SNMP/NTP should be blocked. I > mean how many > people actually run a legit NTP server out of their home? > Dozens? And the > people who run SNMP devices with the default/common > communities aren't the > ones using it. > If the argument is that you need a Business class account to > run a mail > server then I have no problem extending that to DNS servers > also. > Cheers, > Max > > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson > > wrote: > > > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > > > >> Traffic from dns-spoofing attacks generally has src port = > 53 and dst > port = random. If you block packets with udp src port=53 > towards > customers, you will also block legitimate return traffic if > the customers > run their own DNS servers or use opendns / google dns / etc. > > > > Sure, it's a very interesting discussion what ports should > be blocked or > not. > > > > http://www.bitag.org/documents/Port-Blocking.pdf > > > > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. > They've been > blocked for a very long time to fix some issues, even though > there is > legitimate use for these ports. > > > > So if you're blocking these ports, it seems like a small > step to block > UDP/TCP/53 towards customers as well. I can't come up with an > argument > that makes sense to block TCP/25 and then not block port > UDP/TCP/53 as > well. If you're protecting the Internet from your customers > misconfiguraiton by blocking port 25 and the MS ports, why not > 53 as well? > > > > This is a slippery slope of course, and judgement calls are > not easy to > make. > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se > > > > > > From bruns at 2mbit.com Fri Feb 26 15:56:40 2016 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 26 Feb 2016 08:56:40 -0700 Subject: Thank you, Comcast. In-Reply-To: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> Message-ID: <56D075B8.3080806@2mbit.com> On 2/26/16 6:27 AM, Mike Hammett wrote: > "you will also block legitimate return traffic if the customers run > their own DNS servers or use opendns / google dns / etc." > > I'm fine with that. Residential customers shouldn't be running DNS > servers anyway and as far as the outside resolvers to go, ehhhh... I > see the case for OpenDNS given that you can use it to filter (though > that's easily bypassed), but not really for any others. Except that half the time people run their own DNS resolvers because their provider's resolvers are 1) Absolute garbage and either fail queries for no reason, don't respond at times, respond super slow, etc. 2) Hijack NXDOMAIN for advertising / money generation 3) Hijack responses to inject their own ads, popups, etc. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From nanog at ics-il.net Fri Feb 26 16:00:43 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Feb 2016 10:00:43 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: Message-ID: <1267666062.13998.1456502441885.JavaMail.mhammett@ThunderFuck> Works fine on a default Chrome installation. *shrugs* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" To: "NANOG list" Cc: "Nirmal Mody" Sent: Friday, February 26, 2016 9:55:20 AM Subject: RE: Thank you, Comcast. On Friday, 26 February, 2016 08:13, Jason_Livingood at comcast.com said: > FWIW, Comcast's list of blocked ports is at > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > ports/. The suspensions this week are in direct response to reported abuse > from amplification attacks, which we obviously take very seriously. God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop. It has so much intertwined malicious javascript, cross-site scripting, and malicious trackers that the alarm klaxons go off when I attempt to access it. I spent a couple of minutes attempting to access the page but still maintaining blocks to the malicious links. Apparently, viewing the page requires that all security be turned off and that the viewer allows completely untrusted code from completely untrustworty sources to run unabated on the viewers computer. I do not permit this. For anyone. Ever. This pretty much ensures that I would never be one of your customers. If you cannot operate a server which serves renderable non-malicious web pages properly, what hope is there that you can do anything else right? > We are in the process of considering adding some new ports to this block > list right now, and one big suggestion is SSDP. If you have any others you > wish to suggest please send them to me and the guy on the cc line (Nirmal > Mody). > On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" bounces at nanog.org on behalf of kmedcalf at dessus.com> wrote: > > > > ISP's should block nothing, to or from the customer, unless they > make it clear *before* selling the service (and include it in the Terms > and Conditions of Service Contract), that they are not selling an Internet > connection but are selling a partially functional Internet connection (or > a limited Internet Service), and specifying exactly what the built-in > deficiencies are. > > Deficiencies may include: > port/protocol blockage toward the customer (destination blocks) > port/protocol blockage toward the internet (source blocks) > DNS diddling (filtering of responses, NXDOMAIN > redirection/wildcards, etc) > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > Some ISPs are good at this and provide opt-in/out methods for at > least the first three on the list. Others not so much. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > Maxwell Cole > Sent: Friday, 26 February, 2016 07:19 > To: Mikael Abrahamsson > Cc: NANOG list > Subject: Re: Thank you, Comcast. > I agree, > At the very least things like SNMP/NTP should be blocked. I > mean how many > people actually run a legit NTP server out of their home? > Dozens? And the > people who run SNMP devices with the default/common > communities aren't the > ones using it. > If the argument is that you need a Business class account to > run a mail > server then I have no problem extending that to DNS servers > also. > Cheers, > Max > > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson > > wrote: > > > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > > > >> Traffic from dns-spoofing attacks generally has src port = > 53 and dst > port = random. If you block packets with udp src port=53 > towards > customers, you will also block legitimate return traffic if > the customers > run their own DNS servers or use opendns / google dns / etc. > > > > Sure, it's a very interesting discussion what ports should > be blocked or > not. > > > > http://www.bitag.org/documents/Port-Blocking.pdf > > > > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. > They've been > blocked for a very long time to fix some issues, even though > there is > legitimate use for these ports. > > > > So if you're blocking these ports, it seems like a small > step to block > UDP/TCP/53 towards customers as well. I can't come up with an > argument > that makes sense to block TCP/25 and then not block port > UDP/TCP/53 as > well. If you're protecting the Internet from your customers > misconfiguraiton by blocking port 25 and the MS ports, why not > 53 as well? > > > > This is a slippery slope of course, and judgement calls are > not easy to > make. > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se > > > > > > From mcole.mailinglists at gmail.com Fri Feb 26 16:00:59 2016 From: mcole.mailinglists at gmail.com (Maxwell Cole) Date: Fri, 26 Feb 2016 11:00:59 -0500 Subject: Thank you, Comcast. In-Reply-To: <19A51CD2-67DC-4724-88AE-361BC33FDB16@egon.cc> References: <19A51CD2-67DC-4724-88AE-361BC33FDB16@egon.cc> Message-ID: Thats not really a fair comparison, I think a lot of people have issues with people censoring/controlling/prioritizing internet access to make money. Its a somewhat more nuanced conversation when you are talking about doing the same thing to prevent abuse. Cheers, Max > On Feb 26, 2016, at 10:32 AM, James Downs wrote: > > >> On Feb 26, 2016, at 06:31, Keith Medcalf wrote: >> >> ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet Service), and specifying exactly what the built-in deficiencies are. > > Absolutely. It?s funny that a group that worries about about net neutrality and whinges about T-Mobile?s zero-rating certain video sources is perfectly fine with blindly blocking *ports*, without even understanding if it?s legitimate traffic. > >> Deficiencies may include: >> port/protocol blockage toward the customer (destination blocks) >> port/protocol blockage toward the internet (source blocks) >> DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) > > This would be a big reason to point to a different DNS... > >> Traffic Shaping/Policing/Congestion policies, inbound and outbound >> >> Some ISPs are good at this and provide opt-in/out methods for at least the first three on the list. Others not so much. > From bruns at 2mbit.com Fri Feb 26 16:02:31 2016 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 26 Feb 2016 09:02:31 -0700 Subject: Thank you, Comcast. In-Reply-To: References: Message-ID: <56D07717.8010304@2mbit.com> On 2/26/16 7:31 AM, Keith Medcalf wrote: > ISP's should block nothing, to or from the customer, unless they make it clear*before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet Service), and specifying exactly what the built-in deficiencies are. > > Deficiencies may include: > port/protocol blockage toward the customer (destination blocks) > port/protocol blockage toward the internet (source blocks) > DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > Some ISPs are good at this and provide opt-in/out methods for at least the first three on the list. Others not so much. Thumbs up to this one. I like how CenturyLink gives me the option of turning off port 25 blocking quickly if you know where to go, but it is on by default. I can live with blocks on by default, but easily be able to be turned off (if you are smart enough to know where to look to disable the options). Only thing I dislike is that they don't seem to remember it between service upgrades, and every time I bump my customer speeds I have to remember to go reset it or they can't send e-mail. :-) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From damian at google.com Fri Feb 26 16:02:52 2016 From: damian at google.com (Damian Menscher) Date: Fri, 26 Feb 2016 08:02:52 -0800 Subject: Thank you, Comcast. In-Reply-To: <991FA495-A6F6-4C94-BCE9-37C1D6D73793@puck.nether.net> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <991FA495-A6F6-4C94-BCE9-37C1D6D73793@puck.nether.net> Message-ID: On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch wrote: > As a community we need to determine if this background radiation and these > responses are proper. I think it's a good response since vendors can't do > uRPF at line rate and the major purchasers of BCM switches don't ask for it > and aren't doing it, so it's not optimized or does not exist. /sigh > I don't agree with the approach of going after individual reflectors (open*project) or blocking specific ports (Comcast's action here) as both are reactive, unlikely to be particularly effective (there are still millions of reflectors and plenty of open ports available), and don't solve the root problem (spoofed packets making it onto the public internet). What I'd much rather see Comcast do is use their netflow to trace the source of the spoofed packets (one of their peers or transit providers, no doubt) and strongly encourage (using their legal or PR team as needed) them to trace back and stop the spoofing. This benefits everyone in a much more direct and scalable way. Until some of the larger providers start doing that, amplification attacks and other spoofed-source attacks (DNS and synfloods) will continue to thrive. (I've contacted several ISPs about the spoofed traffic they send to us. The next major hurdle is that so many don't have netflow or other useful monitoring of their networks....) Damian From tagno25 at gmail.com Fri Feb 26 16:04:08 2016 From: tagno25 at gmail.com (Philip Dorr) Date: Fri, 26 Feb 2016 10:04:08 -0600 Subject: Thank you, Comcast. In-Reply-To: References: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> Message-ID: On Feb 26, 2016 8:34 AM, "Keith Medcalf" wrote: > > > ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet Service), and specifying exactly what the built-in deficiencies are. > > Deficiencies may include: > port/protocol blockage toward the customer (destination blocks) > port/protocol blockage toward the internet (source blocks) > DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > Some ISPs are good at this and provide opt-in/out methods for at least the first three on the list. Others not so much. > Every ISP I have felt with that messes with the DNS, has no valid opt-out other than using different DNS. The opt-out they use is a HTTP cookie, which only works for web browsers. It doesn't work for any other program. From cmaurand at xyonet.com Fri Feb 26 16:04:49 2016 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 26 Feb 2016 11:04:49 -0500 Subject: Thank you, Comcast. In-Reply-To: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> Message-ID: <56D077A1.7020207@xyonet.com> I run my own resolver from behind my firewall at my home. I don't allow incoming port 53 traffic. I realize there's not a lot of privacy on the net, but I don't like having my dns queries tracked in order to target advertising at me and for annoying failed queries to end up at some annoying search page. On 2/26/2016 9:18 AM, Maxwell Cole wrote: > I agree, > > At the very least things like SNMP/NTP should be blocked. I mean how many people actually run a legit NTP server out of their home? Dozens? And the people who run SNMP devices with the default/common communities aren?t the ones using it. > > If the argument is that you need a Business class account to run a mail server then I have no problem extending that to DNS servers also. > > Cheers, > Max > >> On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson wrote: >> >> On Fri, 26 Feb 2016, Nick Hilliard wrote: >> >>> Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random. If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc. >> Sure, it's a very interesting discussion what ports should be blocked or not. >> >> http://www.bitag.org/documents/Port-Blocking.pdf >> >> This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been blocked for a very long time to fix some issues, even though there is legitimate use for these ports. >> >> So if you're blocking these ports, it seems like a small step to block UDP/TCP/53 towards customers as well. I can't come up with an argument that makes sense to block TCP/25 and then not block port UDP/TCP/53 as well. If you're protecting the Internet from your customers misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well? >> >> This is a slippery slope of course, and judgement calls are not easy to make. >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se -- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand at xyonet.com http://www.xyonet.com From nanog at ics-il.net Fri Feb 26 16:15:49 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Feb 2016 10:15:49 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: <56D075B8.3080806@2mbit.com> Message-ID: <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck> I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" To: nanog at nanog.org Sent: Friday, February 26, 2016 9:56:40 AM Subject: Re: Thank you, Comcast. On 2/26/16 6:27 AM, Mike Hammett wrote: > "you will also block legitimate return traffic if the customers run > their own DNS servers or use opendns / google dns / etc." > > I'm fine with that. Residential customers shouldn't be running DNS > servers anyway and as far as the outside resolvers to go, ehhhh... I > see the case for OpenDNS given that you can use it to filter (though > that's easily bypassed), but not really for any others. Except that half the time people run their own DNS resolvers because their provider's resolvers are 1) Absolute garbage and either fail queries for no reason, don't respond at times, respond super slow, etc. 2) Hijack NXDOMAIN for advertising / money generation 3) Hijack responses to inject their own ads, popups, etc. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From rdobbins at arbor.net Fri Feb 26 16:27:12 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 26 Feb 2016 23:27:12 +0700 Subject: Thank you, Comcast. In-Reply-To: References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <991FA495-A6F6-4C94-BCE9-37C1D6D73793@puck.nether.net> Message-ID: <0A874AB4-73B8-4B67-91A3-B2739D4DADFF@arbor.net> On 26 Feb 2016, at 23:02, Damian Menscher via NANOG wrote: > What I'd much rather see Comcast do is use their netflow to trace the > source of the spoofed packets (one of their peers or transit > providers, no > doubt) and strongly encourage (using their legal or PR team as needed) > them > to trace back and stop the spoofing. These approaches aren't necessarily mutually exclusive, as most flow telemetry implementations still report on blocked traffic from exporting devices. Keeping the network up and available for the vast majority of the customer base trumps all other considerations. DNS queries should not typically be directed towards consumer broadband access netblocks, period; and when they cause operational problems due to abusable CPE being, well, abused, immediate remediation action(s) must be taken. To do otherwise would be irresponsible. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Fri Feb 26 16:30:31 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 26 Feb 2016 23:30:31 +0700 Subject: Thank you, Comcast. In-Reply-To: <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck> References: <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck> Message-ID: <8A52A783-68A5-496D-BFB0-89D052E574E2@arbor.net> On 26 Feb 2016, at 23:15, Mike Hammett wrote: > I think you'd be hard pressed to find more than a tenth of a percent > of people attempt to run their own DNS server. You'll find a heck of a lot more of them doing so unknowingly, because they're running misconfigured, abusable CPE devices which can be leveraged by attackers to launch DNS reflection/amplification attacks. Note that outbound/crossbound DDoS attacks can have just as much of a negative impact on availability as inbound DDoS attacks; even more, when multiple attackers are abusing the same reflectors/amplifiers (which is often the case). And even that small tenth of a percent who're deliberately running their own DNS servers can end up inadvertently causing disruption if they're running those DNS servers as open recursors. ----------------------------------- Roland Dobbins From blake at ispn.net Fri Feb 26 16:44:26 2016 From: blake at ispn.net (Blake Hudson) Date: Fri, 26 Feb 2016 10:44:26 -0600 Subject: Thank you, Comcast. In-Reply-To: References: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> Message-ID: <56D080EA.1000500@ispn.net> Livingood, Jason wrote on 2/26/2016 9:12 AM: > FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked-ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously. > > We are in the process of considering adding some new ports to this block list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody). > > Thanks! > Jason > > Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port > 1024 and is used as part of the ephemeral port range on some devices) ? Is the downside of blocking (admittedly a small amount of) legitimate user traffic worth the upside? And is this practice /Open Internet/ friendly? --Blake From bruns at 2mbit.com Fri Feb 26 16:46:27 2016 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 26 Feb 2016 09:46:27 -0700 Subject: Thank you, Comcast. In-Reply-To: <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck> References: <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck> Message-ID: <56D08163.2090702@2mbit.com> On 2/26/16 9:15 AM, Mike Hammett wrote: > I think you'd be hard pressed to find more than a tenth of a percent of > people attempt to run their own DNS server. Some do because they think > it'll be better in some way. Rare is the occasion where anything user > configured would outperform a local DNS server managed by the ISP that > does no form of trickery. "does no form of trickery" Therein lies the problem. Can we trust ISPs to be honest about not messing with our traffic? Kudos to you if you can say that with a straight face :-) Doesn't matter how many people actually have what we think is a 'valid' reason to do it. People have their reasons, may it be because of performance, or what they perceive as CDN issues, or just not trusting their provider. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From davidbass570 at gmail.com Fri Feb 26 16:47:55 2016 From: davidbass570 at gmail.com (David Bass) Date: Fri, 26 Feb 2016 11:47:55 -0500 Subject: Thank you, Comcast. In-Reply-To: <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck> References: <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck> Message-ID: I disagree...the point of what I sent (missed by some) is that in just this small audience there are many that do/have/know about customers that run their own stuff. Trying to blow it off, or minimize those customers just makes you seem a little arrogant. Nothing worse than an arrogant business... > On Feb 26, 2016, at 11:15 AM, Mike Hammett wrote: > > I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Brielle Bruns" > To: nanog at nanog.org > Sent: Friday, February 26, 2016 9:56:40 AM > Subject: Re: Thank you, Comcast. > >> On 2/26/16 6:27 AM, Mike Hammett wrote: >> "you will also block legitimate return traffic if the customers run >> their own DNS servers or use opendns / google dns / etc." >> >> I'm fine with that. Residential customers shouldn't be running DNS >> servers anyway and as far as the outside resolvers to go, ehhhh... I >> see the case for OpenDNS given that you can use it to filter (though >> that's easily bypassed), but not really for any others. > > > Except that half the time people run their own DNS resolvers because > their provider's resolvers are > > 1) Absolute garbage and either fail queries for no reason, don't respond > at times, respond super slow, etc. > > 2) Hijack NXDOMAIN for advertising / money generation > > 3) Hijack responses to inject their own ads, popups, etc. > > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From rdobbins at arbor.net Fri Feb 26 16:51:57 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 26 Feb 2016 23:51:57 +0700 Subject: Thank you, Comcast. In-Reply-To: <56D080EA.1000500@ispn.net> References: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <56D080EA.1000500@ispn.net> Message-ID: On 26 Feb 2016, at 23:44, Blake Hudson wrote: > Jason, how do you propose to block SSDP without also blocking > legitimate traffic as well (since SSDP uses a port > 1024 and is used > as part of the ephemeral port range on some devices) ? I'm not Jason, but blocking specific port-pairs such as UDP/80 ---> UDP/1900 and UDP/443 ---> UDP/1900 solves close to 90% of the problem, as UDP/80 and UDP/443 are the most common destination ports leveraged in this type of attack. For an explanation of how UDP reflection/amplification attacks work, see this .pdf preso: ----------------------------------- Roland Dobbins From nanog at ics-il.net Fri Feb 26 17:01:28 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Feb 2016 11:01:28 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: <56D08163.2090702@2mbit.com> Message-ID: <1891654333.14143.1456506087783.JavaMail.mhammett@ThunderFuck> They have to be honest or face litigation. Transparency is the biggest (if not the only) useful thing out of the Open Internet Order. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Friday, February 26, 2016 10:46:27 AM Subject: Re: Thank you, Comcast. On 2/26/16 9:15 AM, Mike Hammett wrote: > I think you'd be hard pressed to find more than a tenth of a percent of > people attempt to run their own DNS server. Some do because they think > it'll be better in some way. Rare is the occasion where anything user > configured would outperform a local DNS server managed by the ISP that > does no form of trickery. "does no form of trickery" Therein lies the problem. Can we trust ISPs to be honest about not messing with our traffic? Kudos to you if you can say that with a straight face :-) Doesn't matter how many people actually have what we think is a 'valid' reason to do it. People have their reasons, may it be because of performance, or what they perceive as CDN issues, or just not trusting their provider. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From cma at cmadams.net Fri Feb 26 17:02:27 2016 From: cma at cmadams.net (Chris Adams) Date: Fri, 26 Feb 2016 11:02:27 -0600 Subject: Thank you, Comcast. In-Reply-To: <56D075B8.3080806@2mbit.com> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> Message-ID: <20160226170227.GF8465@cmadams.net> Once upon a time, Brielle Bruns said: > >I'm fine with that. Residential customers shouldn't be running DNS > >servers anyway and as far as the outside resolvers to go, ehhhh... I > >see the case for OpenDNS given that you can use it to filter (though > >that's easily bypassed), but not really for any others. > > > Except that half the time people run their own DNS resolvers because > their provider's resolvers are Resolver != authoritative server. Your local DNS resolver doesn't need to be (and should not be) listening to port 53 on the Internet. Only DNS authoritative servers need to accept Internet traffic on port 53, and almost nobody needs to be running one on a typical residential connection (especially since residential IPs do change from time to time). -- Chris Adams From nanog at ics-il.net Fri Feb 26 17:03:38 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Feb 2016 11:03:38 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: Message-ID: <966595503.14146.1456506214644.JavaMail.mhammett@ThunderFuck> This small audience also consists of predominately people that administer networks and would be doing such things. I'll be you'll find a vastly different percentage of the Cross Stitch Operators Group even know what DNS is, much less have any desire to change it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "David Bass" To: "Mike Hammett" Cc: "Brielle Bruns" , nanog at nanog.org Sent: Friday, February 26, 2016 10:47:55 AM Subject: Re: Thank you, Comcast. I disagree...the point of what I sent (missed by some) is that in just this small audience there are many that do/have/know about customers that run their own stuff. Trying to blow it off, or minimize those customers just makes you seem a little arrogant. Nothing worse than an arrogant business... > On Feb 26, 2016, at 11:15 AM, Mike Hammett wrote: > > I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Brielle Bruns" > To: nanog at nanog.org > Sent: Friday, February 26, 2016 9:56:40 AM > Subject: Re: Thank you, Comcast. > >> On 2/26/16 6:27 AM, Mike Hammett wrote: >> "you will also block legitimate return traffic if the customers run >> their own DNS servers or use opendns / google dns / etc." >> >> I'm fine with that. Residential customers shouldn't be running DNS >> servers anyway and as far as the outside resolvers to go, ehhhh... I >> see the case for OpenDNS given that you can use it to filter (though >> that's easily bypassed), but not really for any others. > > > Except that half the time people run their own DNS resolvers because > their provider's resolvers are > > 1) Absolute garbage and either fail queries for no reason, don't respond > at times, respond super slow, etc. > > 2) Hijack NXDOMAIN for advertising / money generation > > 3) Hijack responses to inject their own ads, popups, etc. > > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From bruns at 2mbit.com Fri Feb 26 17:09:03 2016 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 26 Feb 2016 10:09:03 -0700 Subject: Thank you, Comcast. In-Reply-To: <1891654333.14143.1456506087783.JavaMail.mhammett@ThunderFuck> References: <1891654333.14143.1456506087783.JavaMail.mhammett@ThunderFuck> Message-ID: <56D086AF.1010605@2mbit.com> On 2/26/16 10:01 AM, Mike Hammett wrote: > They have to be honest or face litigation. Transparency is the biggest (if not the only) useful thing out of the Open Internet Order. As long as the profit from doing shady things and lying is greater then the cost of settling a lawsuit, companies will be dishonest and do shady things. So, no, I don't believe threat of litigation is any barrier to how ISPs conduct their business. In fact, with how pro-business and fuck-consumer the current climate is from the govt, its just going to get worse. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From SNaslund at medline.com Fri Feb 26 17:11:23 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 26 Feb 2016 17:11:23 +0000 Subject: Thank you, Comcast. In-Reply-To: <1267666062.13998.1456502441885.JavaMail.mhammett@ThunderFuck> References: <1267666062.13998.1456502441885.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B401C9C04AB4@MUNPRDMBXA1.medline.com> Also worked fine in IE 11 and Firefox. I didn't change any particular security settings either. Might want to check your stuff before you rant on someone's web site. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Friday, February 26, 2016 10:01 AM To: NANOG list Subject: Re: Thank you, Comcast. Works fine on a default Chrome installation. *shrugs* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" To: "NANOG list" Cc: "Nirmal Mody" Sent: Friday, February 26, 2016 9:55:20 AM Subject: RE: Thank you, Comcast. On Friday, 26 February, 2016 08:13, Jason_Livingood at comcast.com said: > FWIW, Comcast's list of blocked ports is at > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > ports/. The suspensions this week are in direct response to reported > abuse from amplification attacks, which we obviously take very seriously. God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop. It has so much intertwined malicious javascript, cross-site scripting, and malicious trackers that the alarm klaxons go off when I attempt to access it. I spent a couple of minutes attempting to access the page but still maintaining blocks to the malicious links. Apparently, viewing the page requires that all security be turned off and that the viewer allows completely untrusted code from completely untrustworty sources to run unabated on the viewers computer. I do not permit this. For anyone. Ever. This pretty much ensures that I would never be one of your customers. If you cannot operate a server which serves renderable non-malicious web pages properly, what hope is there that you can do anything else right? > We are in the process of considering adding some new ports to this > block list right now, and one big suggestion is SSDP. If you have any > others you wish to suggest please send them to me and the guy on the > cc line (Nirmal Mody). > On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" bounces at nanog.org on behalf of kmedcalf at dessus.com> wrote: > > > > ISP's should block nothing, to or from the customer, unless they make > it clear *before* selling the service (and include it in the Terms and > Conditions of Service Contract), that they are not selling an Internet > connection but are selling a partially functional Internet connection > (or a limited Internet Service), and specifying exactly what the > built-in deficiencies are. > > Deficiencies may include: > port/protocol blockage toward the customer (destination blocks) > port/protocol blockage toward the internet (source blocks) DNS > diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > Some ISPs are good at this and provide opt-in/out methods for at least > the first three on the list. Others not so much. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maxwell Cole > Sent: Friday, 26 February, 2016 07:19 > To: Mikael Abrahamsson > Cc: NANOG list > Subject: Re: Thank you, Comcast. > I agree, > At the very least things like SNMP/NTP should be blocked. I mean how > many people actually run a legit NTP server out of their home? > Dozens? And the > people who run SNMP devices with the default/common communities aren't > the ones using it. > If the argument is that you need a Business class account to run a > mail server then I have no problem extending that to DNS servers also. > Cheers, > Max > > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson > > wrote: > > > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > > > >> Traffic from dns-spoofing attacks generally has src port = > 53 and dst > port = random. If you block packets with udp src port=53 towards > customers, you will also block legitimate return traffic if the > customers run their own DNS servers or use opendns / google dns / etc. > > > > Sure, it's a very interesting discussion what ports should > be blocked or > not. > > > > http://www.bitag.org/documents/Port-Blocking.pdf > > > > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. > They've been > blocked for a very long time to fix some issues, even though there is > legitimate use for these ports. > > > > So if you're blocking these ports, it seems like a small > step to block > UDP/TCP/53 towards customers as well. I can't come up with an argument > that makes sense to block TCP/25 and then not block port > UDP/TCP/53 as > well. If you're protecting the Internet from your customers > misconfiguraiton by blocking port 25 and the MS ports, why not > 53 as well? > > > > This is a slippery slope of course, and judgement calls are > not easy to > make. > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se > > > > > > From bruns at 2mbit.com Fri Feb 26 17:16:33 2016 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 26 Feb 2016 10:16:33 -0700 Subject: Thank you, Comcast. In-Reply-To: <20160226170227.GF8465@cmadams.net> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> Message-ID: <56D08871.7080001@2mbit.com> On 2/26/16 10:02 AM, Chris Adams wrote: >> >> Except that half the time people run their own DNS resolvers because >> their provider's resolvers are > > Resolver != authoritative server. Your local DNS resolver doesn't need > to be (and should not be) listening to port 53 on the Internet. Only > DNS authoritative servers need to accept Internet traffic on port 53, > and almost nobody needs to be running one on a typical residential > connection (especially since residential IPs do change from time to > time). > UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the customer also will block responses to recursive queries that originate from SRC 53/UDP. Connection tracking sorta makes it stateful to a point, but it can get ugly with enough traffic. Place the blame for local resolvers listening on WAN squarely where it belongs - the router vendors who make these devices. You can't do anything about idiots buying a pro-sumer/professional device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, D-Link, Netgear, etc that are targeted towards home users should be held to the fire for that kind of screw up. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From rsk at gsp.org Fri Feb 26 17:17:32 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 26 Feb 2016 12:17:32 -0500 Subject: Thank you, Comcast. In-Reply-To: References: Message-ID: <20160226171732.GA6363@gsp.org> On Fri, Feb 26, 2016 at 08:55:20AM -0700, Keith Medcalf wrote: > > On Friday, 26 February, 2016 08:13, Jason_Livingood at comcast.com said: > > > FWIW, Comcast's list of blocked ports is at > > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > > ports/. The suspensions this week are in direct response to reported abuse > > from amplification attacks, which we obviously take very seriously. > > God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop. Agreed -- it's completely dysfunctional worthless crap. I wonder if it occurred to anybody that a list of blocked ports could be published as a single static web page with no scripting, or better yet, as a text file so that it could be acquired with and used by scripts. ---rsk From SNaslund at medline.com Fri Feb 26 17:19:25 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 26 Feb 2016 17:19:25 +0000 Subject: Thank you, Comcast. In-Reply-To: <8A0DDB2E-A379-49AC-9BE2-FC8CF26EAE54@gmail.com> References: <8A0DDB2E-A379-49AC-9BE2-FC8CF26EAE54@gmail.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C9C04AEC@MUNPRDMBXA1.medline.com> I don't have a problem with an ISP blocking certain things by default as long as they identify them like Comcast has done especially for consumer service. It would be nice if there was a way to opt out of the protection for the few people that need those services either through a web interface or a phone call. They might make the case though that certain services require a business class of service. Back in the 90s we used to block port 25 traffic for all customers unless they needed it opened because there were so many insecure mail systems out there. Sometimes you have to protect the clueless majority at the expense of a slight inconvenience for the geeks. So if you were smart enough to know that you need port 25 opened, we would do it. Most people did not know that it should be blocked most of the time so we protected them. Steven Naslund Chicago IL >I agree with this...from a customer perspective. I've seen ISPs block other traffic as well...even on "business" accounts, and break their customers networks. >It's the Internet not a private network... >I've never been a typical user though...maybe one of the "dozen" Mike refers to that runs a email server, web server, dns server, etc, etc, etc out of their house. >> On Feb 26, 2016, at 9:31 AM, Keith Medcalf wrote: >> >> >> ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service >>Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet Service), and specifying >>exactly what the built-in deficiencies are. > >> Deficiencies may include: >> port/protocol blockage toward the customer (destination blocks) >> port/protocol blockage toward the internet (source blocks) DNS >> diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) >> Traffic Shaping/Policing/Congestion policies, inbound and outbound > > Some ISPs are good at this and provide opt-in/out methods for at least the first three on the list. Others not so much. > From rsk at gsp.org Fri Feb 26 17:21:27 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 26 Feb 2016 12:21:27 -0500 Subject: Thank you, Comcast. In-Reply-To: <56D077A1.7020207@xyonet.com> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <56D077A1.7020207@xyonet.com> Message-ID: <20160226172127.GB6363@gsp.org> On Fri, Feb 26, 2016 at 11:04:49AM -0500, Curtis Maurand wrote: > I run my own resolver from behind my firewall at my home. I don't > allow incoming port 53 traffic. I realize there's not a lot of > privacy on the net, but I don't like having my dns queries tracked > in order to target advertising at me and for annoying failed queries > to end up at some annoying search page. Likewise, and I don't like getting back forged DNS responses because some already-bloated ISP needs to tuck a few more dollars into their executives' paychecks. I've tested it fairly thoroughly in order to ensure that it can't be conscripted into an attack and do so again every time I make a firewall configuration change or a software upgrade. I've also started running local resolvers on portable systems in order to avoid the same set of problems when connecting to random networks. It often occurs to me that if the engineers of those networks invested the time that they spend corrupting DNS into preventing DNS-borne attacks that the entire Internet would be better off. ---rsk From nanog at ics-il.net Fri Feb 26 17:22:00 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Feb 2016 11:22:00 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: <56D086AF.1010605@2mbit.com> Message-ID: <687616443.14240.1456507315544.JavaMail.mhammett@ThunderFuck> Said in a forum comprised largely of ISPs? Bold move. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" To: nanog at nanog.org Sent: Friday, February 26, 2016 11:09:03 AM Subject: Re: Thank you, Comcast. On 2/26/16 10:01 AM, Mike Hammett wrote: > They have to be honest or face litigation. Transparency is the biggest (if not the only) useful thing out of the Open Internet Order. As long as the profit from doing shady things and lying is greater then the cost of settling a lawsuit, companies will be dishonest and do shady things. So, no, I don't believe threat of litigation is any barrier to how ISPs conduct their business. In fact, with how pro-business and fuck-consumer the current climate is from the govt, its just going to get worse. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From rdobbins at arbor.net Fri Feb 26 17:25:01 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 Feb 2016 00:25:01 +0700 Subject: Thank you, Comcast. In-Reply-To: <56D08871.7080001@2mbit.com> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> <56D08871.7080001@2mbit.com> Message-ID: On 27 Feb 2016, at 0:16, Brielle Bruns wrote: > UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the > customer also will block responses to recursive queries that originate > from SRC 53/UDP. Which are relatively rare, these days. Any device doing this by default is likely running out-of-date software that is abusable in multiple ways. ----------------------------------- Roland Dobbins From anthonyrjunk at gmail.com Fri Feb 26 17:25:35 2016 From: anthonyrjunk at gmail.com (Anthony Junk) Date: Fri, 26 Feb 2016 12:25:35 -0500 Subject: Thank you, Comcast. In-Reply-To: <20160226170227.GF8465@cmadams.net> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> Message-ID: There is so much arrogance in these posts saying that these things should be blocked because it's best or because it's negligible. The point of having an open internet is that people are going to have use cases that you haven't even thought of and should not be hindered. Even the reasons you have identified--who are you to say that I can't run services for my own use to my home? Why should I have to pay for two separate connections so that I can have tv and internet because I require ports not being blocked for it to function? I maintain a lab out of my home and it's on my dime to maintain and for my personal use. Please tell me again about my need for a business connection. Sincerely, Anthony R Junk Network and Security Engineer (410) 929-1838 anthonyrjunk at gmail.com On Fri, Feb 26, 2016 at 12:02 PM, Chris Adams wrote: > Once upon a time, Brielle Bruns said: > > >I'm fine with that. Residential customers shouldn't be running DNS > > >servers anyway and as far as the outside resolvers to go, ehhhh... I > > >see the case for OpenDNS given that you can use it to filter (though > > >that's easily bypassed), but not really for any others. > > > > > > Except that half the time people run their own DNS resolvers because > > their provider's resolvers are > > Resolver != authoritative server. Your local DNS resolver doesn't need > to be (and should not be) listening to port 53 on the Internet. Only > DNS authoritative servers need to accept Internet traffic on port 53, > and almost nobody needs to be running one on a typical residential > connection (especially since residential IPs do change from time to > time). > > -- > Chris Adams > From jjn at nuge.com Fri Feb 26 15:52:55 2016 From: jjn at nuge.com (Jay Nugent) Date: Fri, 26 Feb 2016 10:52:55 -0500 (EST) Subject: Thank you, Comcast. In-Reply-To: References: Message-ID: Greetings, On Fri, 26 Feb 2016, Keith Medcalf wrote: > > ISP's should block nothing, to or from the customer, unless they make it > clear *before* selling the service (and include it in the Terms and > Conditions of Service Contract), that they are not selling an Internet > connection but are selling a partially functional Internet connection > (or a limited Internet Service), and specifying exactly what the > built-in deficiencies are. > > Deficiencies may include: > port/protocol blockage toward the customer (destination blocks) > port/protocol blockage toward the internet (source blocks) > DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > Some ISPs are good at this and provide opt-in/out methods for at least > the first three on the list. Others not so much. I wholeheartedly agree! When purchasing an "Internet connection", we expect that to be full access to the Internet. Granted, *some* parts of the Internet are up/down or never available, but the *protocols* should *ALL* be available. Customers regularly use various VPN protocols from GRE, SIT, and IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where we spend the bulk of our time troubleshooting). Customers EXPECT their packets to be passed unhampered. Otherwise, all the provider is giving them is acces to email and to surf for porn. That provider would simply be offering an "entertainment" connection to the public Internet, not full Internet access. However, if a 'provider' wishes to block ANYTHING, then they need to inform the customer IN WRITING exactly what will be blocked so that customer doesn't waste their time and money with said (limited) service and vote with their wallet by buying *real* Internet service, elsewhere. --- Jay Nugent Nugent Telecommunications consulting Ypsilanti, Michigan >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maxwell Cole >> Sent: Friday, 26 February, 2016 07:19 >> To: Mikael Abrahamsson >> Cc: NANOG list >> Subject: Re: Thank you, Comcast. >> >> I agree, >> >> At the very least things like SNMP/NTP should be blocked. I mean how many >> people actually run a legit NTP server out of their home? Dozens? And the >> people who run SNMP devices with the default/common communities aren?t the >> ones using it. >> >> If the argument is that you need a Business class account to run a mail >> server then I have no problem extending that to DNS servers also. >> >> Cheers, >> Max >> >>> On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson >> wrote: >>> >>> On Fri, 26 Feb 2016, Nick Hilliard wrote: >>> >>>> Traffic from dns-spoofing attacks generally has src port = 53 and dst >> port = random. If you block packets with udp src port=53 towards >> customers, you will also block legitimate return traffic if the customers >> run their own DNS servers or use opendns / google dns / etc. >>> >>> Sure, it's a very interesting discussion what ports should be blocked or >> not. >>> >>> http://www.bitag.org/documents/Port-Blocking.pdf >>> >>> This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been >> blocked for a very long time to fix some issues, even though there is >> legitimate use for these ports. >>> >>> So if you're blocking these ports, it seems like a small step to block >> UDP/TCP/53 towards customers as well. I can't come up with an argument >> that makes sense to block TCP/25 and then not block port UDP/TCP/53 as >> well. If you're protecting the Internet from your customers >> misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well? >>> >>> This is a slippery slope of course, and judgement calls are not easy to >> make. >>> >>> -- >>> Mikael Abrahamsson email: swmike at swm.pp.se > > > > > -- () ascii ribbon campaign in /\ support of plain text e-mail o Averaging at least 3 days of MTBWTF!?!?!? o The solution for long term Internet growth is IPv6. +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design | | ISP Monitoring [www.ispmonitor.org] ISP Performance Monitoring | +------------------------------------------------------------------------+ 10:01:01 up 6 days, 20:04, 2 users, load average: 0.40, 0.54, 0.43 From robt at cymru.com Fri Feb 26 13:49:58 2016 From: robt at cymru.com (Rabbi Rob Thomas) Date: Fri, 26 Feb 2016 08:49:58 -0500 Subject: Brighthouse Networks security contact? Message-ID: <56D05806.6070207@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear team, I'm looking for a Brighthouse Networks security contact, please. Thank you! Rob. - -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree." - Leo McKern -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJW0FgGAAoJEEPoYWL6hfKNOpoP/2GU92cFZ7a6WQoblQK9qPcc rxA+y+a6l0F42jFZxt6Acm4gbV/otWg+yyN8d5rxr+7V3rQL6xR3/iUyrFh2VJ91 tDX+7LN/oXC9hJMci0090Va7RDjWQsohT/MRDEoa/zlpFG/lGNQDQDIfIsp/vxba o7sdzlPBxOlxX0nhB84E1VYXVMu23MxcR0L1hWuAPA/eU8f+XknILyxh7dPxoArv 5iHfqDo05G2YLewdKdwdYGtjGm55+kQS/SHQudM1KjTRV4uhPwmgEkcWy1sSqdxa StRXLEGcz9ATXaJmqSaZ/aK5IUtGQWHZ0srGWpKnp/RxbEEjUvM+arXowPdKRfNB s33akM5Hqvzqj/wQqYUdpRsF5owK//4lAO4cxDYYSHdnqBIuEk8NY7egD5HJOF5Y vhhQoyBwcAdNQfvomy/Jiv9+cUA63Dq5W4PRRcMyyhrT/HealCVDOCMFPsFSotqx pLH0FEVJJqFg6fIKlH7AwJ/85Cu2AnH2OlOBKEmqPfax5H0lDyC5wmbSmqgDzB8U 7fhPf7TZlilaXZC8McZ668XztCNX4/c/1ZZgc77euQQ2UUHGmwLs4o6AJb9l2FSX prNr71gxqeNw82agQz///pXppT0l89inZZkFkPLSpGwHeOk+WMicQoEwuIaVfGgN OSpUx4IZ6yuKMGXFQRSS =EM6x -----END PGP SIGNATURE----- From rdobbins at arbor.net Fri Feb 26 17:33:25 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 Feb 2016 00:33:25 +0700 Subject: Thank you, Comcast. In-Reply-To: <56D08871.7080001@2mbit.com> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> <56D08871.7080001@2mbit.com> Message-ID: On 27 Feb 2016, at 0:16, Brielle Bruns wrote: > You can't do anything about idiots buying a pro-sumer/professional > device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, > D-Link, Netgear, etc that are targeted towards home users should be > held to the fire for that kind of screw up. Also, see this article: and this .pdf preso: ----------------------------------- Roland Dobbins From octalnanog at alvarezp.org Fri Feb 26 17:33:29 2016 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Fri, 26 Feb 2016 09:33:29 -0800 Subject: Thank you, Comcast. In-Reply-To: <56D08871.7080001@2mbit.com> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> <56D08871.7080001@2mbit.com> Message-ID: <56D08C69.7070601@alvarezp.org> On 26/02/16 09:16, Brielle Bruns wrote: > Place the blame for local resolvers listening on WAN squarely where it > belongs - the router vendors who make these devices. As long as ISPs massively buy crappy hardware pieces, vendors will make them and sell them. That's how it works. Best regards. From cma at cmadams.net Fri Feb 26 17:42:15 2016 From: cma at cmadams.net (Chris Adams) Date: Fri, 26 Feb 2016 11:42:15 -0600 Subject: Thank you, Comcast. In-Reply-To: <56D08871.7080001@2mbit.com> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> <56D08871.7080001@2mbit.com> Message-ID: <20160226174215.GG8465@cmadams.net> Once upon a time, Brielle Bruns said: > UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to > the customer also will block responses to recursive queries that > originate from SRC 53/UDP. Connection tracking sorta makes it > stateful to a point, but it can get ugly with enough traffic. Sending queries from port 53 has been considered bad behavior and deprecated for what, 15 years now? -- Chris Adams From johnl at iecc.com Fri Feb 26 17:42:21 2016 From: johnl at iecc.com (John Levine) Date: 26 Feb 2016 17:42:21 -0000 Subject: Thank you, Comcast. In-Reply-To: Message-ID: <20160226174221.42323.qmail@ary.lan> In article you write: >ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and >Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or >a limited Internet Service), and specifying exactly what the built-in deficiencies are. Huh. Is it 1998 again? R's, John From rdobbins at arbor.net Fri Feb 26 17:53:50 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 Feb 2016 00:53:50 +0700 Subject: Thank you, Comcast. In-Reply-To: References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> Message-ID: On 27 Feb 2016, at 0:25, Anthony Junk wrote: > There is so much arrogance in these posts saying that these things > should be blocked because it's best or because it's negligible. I think there's a lack of comprehension on the part of those who don't run large networks and/or who aren't responsible for maintaing network availability for their customer base. Blocking or QoSing down port-pairs at the peering/transit edge is all too often the least worst option these operators have > Please tell me again about my need for a business connection. Caveat emptor. ----------------------------------- Roland Dobbins From johnl at iecc.com Fri Feb 26 17:54:26 2016 From: johnl at iecc.com (John Levine) Date: 26 Feb 2016 17:54:26 -0000 Subject: DNS filtering, was Thank you, Comcast. In-Reply-To: <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck> Message-ID: <20160226175426.42365.qmail@ary.lan> In article <848464982.14027.1456503347620.JavaMail.mhammett at ThunderFuck> you write: >I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think >it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery. I run my own DNS cache behind my home NAT router. It knows about some locally served names so I can refer to the computers on my LAN by name, and it does DNSSEC which my ISP's (T-W) DNS caches don't. Since it's not visible from outside, it's hard to see how anyone could abuse it, and it really does stuff that other caches don't. I wouldn't have any problem if my ISP filtered outgoing port 53 traffic with the QR bit set, of which I should be sending none, but I'd be annoyed if they filtered outgoing queries. R's, John From rdobbins at arbor.net Fri Feb 26 17:55:20 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 Feb 2016 00:55:20 +0700 Subject: Thank you, Comcast. In-Reply-To: References: Message-ID: <276C5EE1-891E-4D50-9515-268B6A37F8B3@arbor.net> On 26 Feb 2016, at 22:52, Jay Nugent wrote: > Customers regularly use various VPN protocols from GRE, SIT, and > IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where > we spend the bulk of our time troubleshooting). Not so on consumer broadband access networks, which are what's being discussed in this thread. It's a different story for transit operators. ----------------------------------- Roland Dobbins From jared at puck.nether.net Fri Feb 26 18:02:32 2016 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Feb 2016 13:02:32 -0500 Subject: Thank you, Comcast. In-Reply-To: <20160226174221.42323.qmail@ary.lan> References: <20160226174221.42323.qmail@ary.lan> Message-ID: > On Feb 26, 2016, at 12:42 PM, John Levine wrote: > > Huh. Is it 1998 again? More like NANOG again. - jared From johnl at iecc.com Fri Feb 26 18:03:56 2016 From: johnl at iecc.com (John Levine) Date: 26 Feb 2016 18:03:56 -0000 Subject: messing with DNS, was Thank you, Comcast. In-Reply-To: Message-ID: <20160226180356.42547.qmail@ary.lan> >Every ISP I have felt with that messes with the DNS, has no valid opt-out >other than using different DNS. The opt-out they use is a HTTP cookie, >which only works for web browsers. It doesn't work for any other program. T-W and I am fairly sure Comcast have per-customer opt-out from DNS "enhancement". T-W's is at http://dnssearch.rr.com/prefs.php I still don't use their DNS caches, but that's not the reason. R's, John From cscora at apnic.net Fri Feb 26 18:11:57 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Feb 2016 04:11:57 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201602261811.u1QIBvep027572@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 Feb, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 585422 Prefixes after maximum aggregation (per Origin AS): 215201 Deaggregation factor: 2.72 Unique aggregates announced (without unneeded subnets): 285164 Total ASes present in the Internet Routing Table: 52903 Prefixes per ASN: 11.07 Origin-only ASes present in the Internet Routing Table: 36594 Origin ASes announcing only one prefix: 15805 Transit ASes present in the Internet Routing Table: 6406 Transit-only ASes present in the Internet Routing Table: 165 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 39 Max AS path prepend of ASN ( 40285) 34 Prefixes from unregistered ASNs in the Routing Table: 1127 Unregistered ASNs in the Routing Table: 397 Number of 32-bit ASNs allocated by the RIRs: 12856 Number of 32-bit ASNs visible in the Routing Table: 9903 Prefixes from 32-bit ASNs in the Routing Table: 38748 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 400 Number of addresses announced to Internet: 2805844804 Equivalent to 167 /8s, 61 /16s and 203 /24s Percentage of available address space announced: 75.8 Percentage of allocated address space announced: 75.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.0 Total number of prefixes smaller than registry allocations: 192303 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 150016 Total APNIC prefixes after maximum aggregation: 41513 APNIC Deaggregation factor: 3.61 Prefixes being announced from the APNIC address blocks: 159948 Unique aggregates announced from the APNIC address blocks: 64754 APNIC Region origin ASes present in the Internet Routing Table: 5142 APNIC Prefixes per ASN: 31.11 APNIC Region origin ASes announcing only one prefix: 1183 APNIC Region transit ASes present in the Internet Routing Table: 906 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1891 Number of APNIC addresses announced to Internet: 752276868 Equivalent to 44 /8s, 214 /16s and 213 /24s Percentage of available APNIC address space announced: 87.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 179657 Total ARIN prefixes after maximum aggregation: 88788 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 184355 Unique aggregates announced from the ARIN address blocks: 87428 ARIN Region origin ASes present in the Internet Routing Table: 16405 ARIN Prefixes per ASN: 11.24 ARIN Region origin ASes announcing only one prefix: 5891 ARIN Region transit ASes present in the Internet Routing Table: 1697 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 37 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1030 Number of ARIN addresses announced to Internet: 1102230080 Equivalent to 65 /8s, 178 /16s and 178 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 140791 Total RIPE prefixes after maximum aggregation: 69611 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 149251 Unique aggregates announced from the RIPE address blocks: 91992 RIPE Region origin ASes present in the Internet Routing Table: 18051 RIPE Prefixes per ASN: 8.27 RIPE Region origin ASes announcing only one prefix: 7954 RIPE Region transit ASes present in the Internet Routing Table: 3010 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4495 Number of RIPE addresses announced to Internet: 703041408 Equivalent to 41 /8s, 231 /16s and 143 /24s Percentage of available RIPE address space announced: 102.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 61389 Total LACNIC prefixes after maximum aggregation: 12081 LACNIC Deaggregation factor: 5.08 Prefixes being announced from the LACNIC address blocks: 75026 Unique aggregates announced from the LACNIC address blocks: 35027 LACNIC Region origin ASes present in the Internet Routing Table: 2469 LACNIC Prefixes per ASN: 30.39 LACNIC Region origin ASes announcing only one prefix: 586 LACNIC Region transit ASes present in the Internet Routing Table: 545 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 23 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2300 Number of LACNIC addresses announced to Internet: 170789888 Equivalent to 10 /8s, 46 /16s and 12 /24s Percentage of available LACNIC address space announced: 101.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: 14666 Total AfriNIC prefixes after maximum aggregation: 3167 AfriNIC Deaggregation factor: 4.63 Prefixes being announced from the AfriNIC address blocks: 16442 Unique aggregates announced from the AfriNIC address blocks: 5608 AfriNIC Region origin ASes present in the Internet Routing Table: 742 AfriNIC Prefixes per ASN: 22.16 AfriNIC Region origin ASes announcing only one prefix: 191 AfriNIC Region transit ASes present in the Internet Routing Table: 171 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 187 Number of AfriNIC addresses announced to Internet: 77081344 Equivalent to 4 /8s, 152 /16s and 43 /24s Percentage of available AfriNIC address space announced: 76.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5592 4192 76 China Education and Research 7545 3187 351 182 TPG Telecom Limited 4766 3117 11142 1094 Korea Telecom 17974 2908 914 96 PT Telekomunikasi Indonesia 9829 2381 1448 428 National Internet Backbone 4755 2084 431 237 TATA Communications formerly 9808 1832 8717 30 Guangdong Mobile Communicatio 45899 1698 1095 172 VNNIC 4808 1632 2287 522 CNCGROUP IP network China169 9583 1520 121 561 Sify Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3291 2948 147 Cox Communications Inc. 6389 2394 3687 42 BellSouth.net Inc. 18566 2211 394 276 MegaPath Corporation 20115 1915 1917 401 Charter Communications 30036 1713 340 267 Mediacom Communications Corp 6983 1690 849 233 EarthLink, Inc. 4323 1588 1023 393 tw telecom holdings, inc. 209 1501 4482 1210 Qwest Communications Company, 701 1396 11455 664 MCI Communications Services, 11492 1254 233 597 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 39891 2515 135 9 SaudiNet, Saudi Telecom Compa 20940 2405 928 1719 Akamai International B.V. 34984 1947 322 415 TELLCOM ILETISIM HIZMETLERI A 8551 1227 376 53 Bezeq International-Ltd 6849 1179 355 21 JSC "Ukrtelecom" 8402 1144 544 15 OJSC "Vimpelcom" 12479 1139 981 83 France Telecom Espana SA 13188 1077 98 78 TOV "Bank-Inform" 31148 1041 47 41 Freenet Ltd. 9198 970 352 25 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3434 541 150 Telmex Colombia S.A. 8151 2173 3392 519 Uninet S.A. de C.V. 7303 1520 940 239 Telecom Argentina S.A. 11830 1434 366 25 Instituto Costarricense de El 6503 1428 437 56 Axtel, S.A.B. de C.V. 6147 1036 377 27 Telefonica del Peru S.A.A. 28573 1005 2177 155 NET Servi?os de Comunica??o S 26615 995 2325 34 Tim Celular S.A. 7738 994 1882 41 Telemar Norte Leste S.A. 3816 984 477 191 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1422 1472 15 TE-AS 24863 1193 402 39 Link Egypt (Link.NET) 37611 626 48 2 Afrihost-Brevis Computer Serv 36903 584 294 104 Office National des Postes et 36992 501 1239 29 ETISALAT MISR 37492 358 216 66 Orange Tunisie 24835 333 146 12 Vodafone Data 29571 266 21 12 Cote d'Ivoire Telecom 2018 249 327 74 TENET (The UNINET Project) 3741 220 821 181 Internet Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5592 4192 76 China Education and Research 10620 3434 541 150 Telmex Colombia S.A. 22773 3291 2948 147 Cox Communications Inc. 7545 3187 351 182 TPG Telecom Limited 4766 3117 11142 1094 Korea Telecom 17974 2908 914 96 PT Telekomunikasi Indonesia 39891 2515 135 9 SaudiNet, Saudi Telecom Compa 20940 2405 928 1719 Akamai International B.V. 6389 2394 3687 42 BellSouth.net Inc. 9829 2381 1448 428 National Internet Backbone Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3434 3284 Telmex Colombia S.A. 22773 3291 3144 Cox Communications Inc. 7545 3187 3005 TPG Telecom Limited 17974 2908 2812 PT Telekomunikasi Indonesia 39891 2515 2506 SaudiNet, Saudi Telecom Compa 6389 2394 2352 BellSouth.net Inc. 4766 3117 2023 Korea Telecom 9829 2381 1953 National Internet Backbone 18566 2211 1935 MegaPath Corporation 4755 2084 1847 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 65001 PRIVATE 5.143.176.0/20 15468 OJSC Rostelecom 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 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 37.46.10.0/23 36351 SoftLayer Technologies Inc. 37.46.14.0/24 36351 SoftLayer Technologies Inc. 37.46.15.0/24 36351 SoftLayer Technologies Inc. 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:101 /12:266 /13:513 /14:1027 /15:1761 /16:12973 /17:7484 /18:12589 /19:25694 /20:38134 /21:40127 /22:65105 /23:56132 /24:321847 /25:550 /26:585 /27:401 /28:18 /29:16 /30:12 /31:0 /32:22 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2476 3291 Cox Communications Inc. 39891 2472 2515 SaudiNet, Saudi Telecom Compa 18566 2113 2211 MegaPath Corporation 30036 1528 1713 Mediacom Communications Corp 6389 1521 2394 BellSouth.net Inc. 6983 1340 1690 EarthLink, Inc. 10620 1320 3434 Telmex Colombia S.A. 34984 1236 1947 TELLCOM ILETISIM HIZMETLERI A 11492 1164 1254 CABLE ONE, INC. 6849 997 1179 JSC "Ukrtelecom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1601 2:735 4:20 5:2099 6:26 8:914 12:1783 13:36 14:1680 15:22 16:2 17:68 18:20 20:48 23:1376 24:1743 27:2245 31:1745 32:54 33:2 34:2 35:4 36:234 37:2356 38:1175 39:26 40:85 41:3188 42:385 43:1683 44:40 45:1698 46:2418 47:68 49:1121 50:844 51:3 52:76 54:179 55:3 56:6 57:44 58:1510 59:860 60:564 61:1793 62:1446 63:1921 64:4465 65:2167 66:4057 67:2086 68:1104 69:3300 70:1040 71:464 72:1983 74:2543 75:357 76:426 77:1376 78:1281 79:813 80:1305 81:1358 82:899 83:671 84:800 85:1581 86:468 87:1040 88:563 89:1935 90:167 91:6049 92:852 93:2312 94:2381 95:2284 96:471 97:356 98:954 99:45 100:69 101:1010 103:9846 104:2263 105:101 106:390 107:1145 108:651 109:2143 110:1262 111:1624 112:936 113:1275 114:1111 115:1687 116:1522 117:1408 118:2109 119:1540 120:510 121:1168 122:2234 123:2015 124:1612 125:1748 128:719 129:369 130:427 131:1272 132:595 133:171 134:449 135:122 136:353 137:337 138:1717 139:200 140:248 141:466 142:629 143:870 144:598 145:160 146:843 147:605 148:1463 149:471 150:662 151:825 152:602 153:270 154:573 155:900 156:487 157:428 158:347 159:1090 160:426 161:723 162:2279 163:530 164:728 165:1119 166:313 167:1018 168:1517 169:600 170:1498 171:264 172:470 173:1637 174:719 175:869 176:1512 177:4028 178:2217 179:1074 180:2112 181:1670 182:1947 183:684 184:790 185:5791 186:3027 187:1990 188:2091 189:1728 190:7668 191:1227 192:8887 193:5725 194:4355 195:3762 196:1654 197:1318 198:5503 199:5574 200:6827 201:3722 202:10112 203:9591 204:4617 205:2691 206:2983 207:3055 208:4041 209:3871 210:3953 211:2010 212:2653 213:2190 214:808 215:73 216:5714 217:1905 218:749 219:564 220:1660 221:851 222:681 223:931 End of report From henry at AegisInfoSys.com Fri Feb 26 18:41:40 2016 From: henry at AegisInfoSys.com (Henry Yen) Date: Fri, 26 Feb 2016 13:41:40 -0500 Subject: Thank you, Comcast. In-Reply-To: <20160226171732.GA6363@gsp.org> References: <20160226171732.GA6363@gsp.org> Message-ID: <20160226184131.GT28629@nntp.AegisInfoSys.com> On Fri, Feb 26, 2016 at 12:17:32PM -0500, Rich Kulawiec wrote: > On Fri, Feb 26, 2016 at 08:55:20AM -0700, Keith Medcalf wrote: > > On Friday, 26 February, 2016 08:13, Jason_Livingood at comcast.com said: > > > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > > > ports/ > > > > ... I cannot view it. ... > Agreed -- it's completely dysfunctional worthless crap. I wonder if it > occurred to anybody that a list of blocked ports could be published as > a single static web page with no scripting, or better yet, as a text > file so that it could be acquired with and used by scripts. And also be made usable by the visually-impaired (section 508, e.g. http://webaim.org/standards/508/checklist). -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From dovid at telecurve.com Fri Feb 26 18:48:50 2016 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 26 Feb 2016 18:48:50 +0000 Subject: Thank you, Comcast. In-Reply-To: References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <991FA495-A6F6-4C94-BCE9-37C1D6D73793@puck.nether.net> Message-ID: <874993180-1456512531-cardhu_decombobulator_blackberry.rim.net-817540925-@b11.c1.bise6.blackberry> We all know what countries this traffic is coming from. While you can threaten the local ISP's the ones over seas where the traffic is coming from won't care. Regards, Dovid -----Original Message----- From: Damian Menscher via NANOG Sender: "NANOG" Date: Fri, 26 Feb 2016 08:02:52 To: Jared Mauch; Jason Livingood; Mody, Nirmal Reply-To: Damian Menscher Cc: NANOG list Subject: Re: Thank you, Comcast. On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch wrote: > As a community we need to determine if this background radiation and these > responses are proper. I think it's a good response since vendors can't do > uRPF at line rate and the major purchasers of BCM switches don't ask for it > and aren't doing it, so it's not optimized or does not exist. /sigh > I don't agree with the approach of going after individual reflectors (open*project) or blocking specific ports (Comcast's action here) as both are reactive, unlikely to be particularly effective (there are still millions of reflectors and plenty of open ports available), and don't solve the root problem (spoofed packets making it onto the public internet). What I'd much rather see Comcast do is use their netflow to trace the source of the spoofed packets (one of their peers or transit providers, no doubt) and strongly encourage (using their legal or PR team as needed) them to trace back and stop the spoofing. This benefits everyone in a much more direct and scalable way. Until some of the larger providers start doing that, amplification attacks and other spoofed-source attacks (DNS and synfloods) will continue to thrive. (I've contacted several ISPs about the spoofed traffic they send to us. The next major hurdle is that so many don't have netflow or other useful monitoring of their networks....) Damian From Valdis.Kletnieks at vt.edu Fri Feb 26 18:50:18 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 26 Feb 2016 13:50:18 -0500 Subject: Thank you, Comcast. In-Reply-To: References: Message-ID: <4772.1456512618@turing-police.cc.vt.edu> On Fri, 26 Feb 2016 10:52:55 -0500, Jay Nugent said: > However, if a 'provider' wishes to block ANYTHING, then they need to > inform the customer IN WRITING exactly what will be blocked so that > customer doesn't waste their time and money with said (limited) service > and vote with their wallet by buying *real* Internet service, elsewhere. Which is only an option in those rare places where there's actual real competition. In most places, it's a monopoly, or a non-functional duopoly (Let's face it - how many users will protest a 10M cable connection with 4 ports punched out by moving to 768K DSL?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jared at puck.nether.net Fri Feb 26 18:50:53 2016 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Feb 2016 13:50:53 -0500 Subject: Thank you, Comcast. In-Reply-To: <874993180-1456512531-cardhu_decombobulator_blackberry.rim.net-817540925-@b11.c1.bise6.blackberry> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <991FA495-A6F6-4C94-BCE9-37C1D6D73793@puck.nether.net> <874993180-1456512531-cardhu_decombobulator_blackberry.rim.net-817540925-@b11.c1.bise6.blackberry> Message-ID: <221D7C88-453A-469A-A876-4C463775005D@puck.nether.net> Disconnecting the US isn?t a viable solution. > On Feb 26, 2016, at 1:48 PM, Dovid Bender wrote: > > We all know what countries this traffic is coming from. While you can threaten the local ISP's the ones over seas where the traffic is coming from won't care. From dovid at telecurve.com Fri Feb 26 18:53:58 2016 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 26 Feb 2016 18:53:58 +0000 Subject: Thank you, Comcast. In-Reply-To: <56D08871.7080001@2mbit.com> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> <56D08871.7080001@2mbit.com> Message-ID: <1488759577-1456512839-cardhu_decombobulator_blackberry.rim.net-108703775-@b11.c1.bise6.blackberry> This is one of my pet peeves. Another is default passwords for devices. Kudo to TP-Link for not shipping devices with default passwords. Regards, Dovid -----Original Message----- From: Brielle Bruns Sender: "NANOG" Date: Fri, 26 Feb 2016 10:16:33 To: Subject: Re: Thank you, Comcast. On 2/26/16 10:02 AM, Chris Adams wrote: >> >> Except that half the time people run their own DNS resolvers because >> their provider's resolvers are > > Resolver != authoritative server. Your local DNS resolver doesn't need > to be (and should not be) listening to port 53 on the Internet. Only > DNS authoritative servers need to accept Internet traffic on port 53, > and almost nobody needs to be running one on a typical residential > connection (especially since residential IPs do change from time to > time). > UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the customer also will block responses to recursive queries that originate from SRC 53/UDP. Connection tracking sorta makes it stateful to a point, but it can get ugly with enough traffic. Place the blame for local resolvers listening on WAN squarely where it belongs - the router vendors who make these devices. You can't do anything about idiots buying a pro-sumer/professional device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, D-Link, Netgear, etc that are targeted towards home users should be held to the fire for that kind of screw up. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Fri Feb 26 18:57:19 2016 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 26 Feb 2016 11:57:19 -0700 Subject: Thank you, Comcast. In-Reply-To: <687616443.14240.1456507315544.JavaMail.mhammett@ThunderFuck> References: <687616443.14240.1456507315544.JavaMail.mhammett@ThunderFuck> Message-ID: <56D0A00F.3050605@2mbit.com> On 2/26/16 10:22 AM, Mike Hammett wrote: > Said in a forum comprised largely of ISPs? Bold move. I appreciate the work the technical people here do, but doesn't change the fact that the people who call the shots aren't always on the same page or have the same goals as do the technical people. I don't work for ISPs anymore like I did in my early career, but my experiences from back then burned quite a bit into my brain. So, sorry if anyone feels slighted by what I said, but honesty hurts. Dancing around the truth does no one any good. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jtk at cymru.com Fri Feb 26 19:02:22 2016 From: jtk at cymru.com (John Kristoff) Date: Fri, 26 Feb 2016 13:02:22 -0600 Subject: Thank you, Comcast. In-Reply-To: References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> Message-ID: <20160226130222.5f87dde5@localhost> On Fri, 26 Feb 2016 07:20:28 +0100 (CET) Mikael Abrahamsson wrote: > I know historically there were resolvers that used UDP/53 as source > port for queries, but is this the case nowadays? Empirically from what I've observed, much less than there once was. Looking at a sample of a few thousand queries on a server set I can see, I don't need much more than what two hands can count. I still see the occasional ISP name server, probably having been around forever and perhaps locked in with the query-source option in BIND. You also see what is probably as a result of some local oddball policy, making something easier, such as the queries *.labs.rapid7.com (hi guys) like to issue for things like VERSION.BIND CH TXT. John From Jason_Livingood at comcast.com Fri Feb 26 19:11:22 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Fri, 26 Feb 2016 19:11:22 +0000 Subject: messing with DNS, was Thank you, Comcast. In-Reply-To: <20160226180356.42547.qmail@ary.lan> References: <20160226180356.42547.qmail@ary.lan> Message-ID: On 2/26/16, 1:03 PM, "NANOG on behalf of John Levine" on behalf of johnl at iecc.com> wrote: T-W and I am fairly sure Comcast have per-customer opt-out from DNS "enhancement". T-W's is at http://dnssearch.rr.com/prefs.php I still don't use their DNS caches, but that's not the reason. Comcast stopped doing NXDOMAIN redirection on January 10, 2012, a little more than 4 years ago. We did so when we completed our DNSSEC deployment. The relevant announcements can be found at: http://corporate.comcast.com/comcast-voices/comcast-completes-dnssec-deployment and http://corporate.comcast.com/comcast-voices/comcast-domain-helper-shuts-down Regards Jason / Comcast From Jason_Livingood at comcast.com Fri Feb 26 19:28:42 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Fri, 26 Feb 2016 19:28:42 +0000 Subject: Thank you, Comcast. In-Reply-To: <56D08C69.7070601@alvarezp.org> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> <56D08871.7080001@2mbit.com> <56D08C69.7070601@alvarezp.org> Message-ID: On 2/26/16, 12:33 PM, "NANOG on behalf of Octavio Alvarez" wrote: >On 26/02/16 09:16, Brielle Bruns wrote: >> Place the blame for local resolvers listening on WAN squarely where it >>belongs - the router vendors who make these devices. > >As long as ISPs massively buy crappy hardware pieces, vendors will make >them and sell them. That's how it works. I think the bigger culprit is not the stuff ISPs buy but what consumers buy (aka COAM). Jason From Jason_Livingood at comcast.com Fri Feb 26 19:32:10 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Fri, 26 Feb 2016 19:32:10 +0000 Subject: Thank you, Comcast. In-Reply-To: <56D080EA.1000500@ispn.net> References: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <56D080EA.1000500@ispn.net> Message-ID: On 2/26/16, 11:44 AM, "Blake Hudson" > wrote: Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port > 1024 and is used as part of the ephemeral port range on some devices) ? As Roland suggested, very likely via UDP/1900. This will obviously be disclosed in advance to customers and tested thoroughly. I believe a few other ISPs have already taken this step. And is this practice Open Internet friendly? Port blocking is considered a form of reasonable network management provided it can be justified by security or operational stability reasons. Of course it must also be transparently disclosed and so on. Jason From jared at puck.nether.net Fri Feb 26 19:41:05 2016 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Feb 2016 14:41:05 -0500 Subject: Consumer Equipment Sucks (Re: Thank you, Comcast.) In-Reply-To: References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> <56D08871.7080001@2mbit.com> <56D08C69.7070601@alvarezp.org> Message-ID: <8807D303-B816-4B90-86D4-935DDCC97DE5@puck.nether.net> > On Feb 26, 2016, at 2:28 PM, Livingood, Jason wrote: > > I think the bigger culprit is not the stuff ISPs buy but what consumers > buy (aka COAM). I?m certainly not a comcast apologist, (I do wish they would service the communities where they had their call centers, like here in the unserved parts of their Scio Township call center). But Jason is spot-on here. There are clear scale problems when dealing with large numbers of customers, and no matter what some of them will use crap equipment. We as an the techies in industry often ?just fix it? for our friends/parents/colleagues. I am an enabler of CGN as I often help a local WISP with their environment when they should be doing IPv6 or something else. Often people are willing to leave as a customer because their device which gets no firmware updates blocks valid DNS requests or has some other problem. These items are shipped freight 6 months in advance from someplace like Shenzhen and never updated, then when they don?t work, customers who don?t understand RF propagation issues, why running a cable through the wall is better, etc.. end up ditching because of the $200 gift card offered for 8 hours of time waiting for an installation appointment in 2 years. These incentives are all wrong in the marketplace, we need better equipment, better people and better responses to the issues. We all have committed various technical sins, I?m not immune, nor is Comcast or likely most people on the list. This thread was started because Comcast and the teams led by Michael actually worked to remediate abusive customer equipment that wasn?t their fault. As we continue to connect devices to the network, the ability to do this type of remediation is essential. If you don?t believe me, look at the recent settlement with ASUS (http://arstechnica.com/security/2016/02/asus-lawsuit-puts-entire-industry-on-notice-over-shoddy-router-security/) or this twitter account - http://tinyurl.com/p6tfh8d where things are comically documented. (Short URL as it uses a profane term that some systems may filter). - Jared From damian at google.com Fri Feb 26 19:47:43 2016 From: damian at google.com (Damian Menscher) Date: Fri, 26 Feb 2016 11:47:43 -0800 Subject: Thank you, Comcast. In-Reply-To: <874993180-1456512531-cardhu_decombobulator_blackberry.rim.net-817540925-@b11.c1.bise6.blackberry> References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <991FA495-A6F6-4C94-BCE9-37C1D6D73793@puck.nether.net> <874993180-1456512531-cardhu_decombobulator_blackberry.rim.net-817540925-@b11.c1.bise6.blackberry> Message-ID: "We all know..." followed by a false statement is amusing. A significant portion of spoofing originates from North America. In a recent attack I'm reviewing, the top sources of spoofing were the southwestern US, the northwestern US, and east Asia (and almost none from Europe). If ISPs understood how to collect and review netflow we might get somewhere... why is this so hard, and how do we fix it? Damian On Fri, Feb 26, 2016 at 10:48 AM, Dovid Bender wrote: > We all know what countries this traffic is coming from. While you can > threaten the local ISP's the ones over seas where the traffic is coming > from won't care. > > Regards, > > Dovid > > -----Original Message----- > From: Damian Menscher via NANOG > Sender: "NANOG" Date: Fri, 26 Feb 2016 08:02:52 > To: Jared Mauch; Jason Livingood< > Jason_Livingood at cable.comcast.com>; Mody, Nirmal< > Nirmal_Mody at cable.comcast.com> > Reply-To: Damian Menscher > Cc: NANOG list > Subject: Re: Thank you, Comcast. > > On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch > wrote: > > > As a community we need to determine if this background radiation and > these > > responses are proper. I think it's a good response since vendors can't do > > uRPF at line rate and the major purchasers of BCM switches don't ask for > it > > and aren't doing it, so it's not optimized or does not exist. /sigh > > > > I don't agree with the approach of going after individual reflectors > (open*project) or blocking specific ports (Comcast's action here) as both > are reactive, unlikely to be particularly effective (there are still > millions of reflectors and plenty of open ports available), and don't solve > the root problem (spoofed packets making it onto the public internet). > What I'd much rather see Comcast do is use their netflow to trace the > source of the spoofed packets (one of their peers or transit providers, no > doubt) and strongly encourage (using their legal or PR team as needed) them > to trace back and stop the spoofing. This benefits everyone in a much more > direct and scalable way. Until some of the larger providers start doing > that, amplification attacks and other spoofed-source attacks (DNS and > synfloods) will continue to thrive. > > (I've contacted several ISPs about the spoofed traffic they send to us. > The next major hurdle is that so many don't have netflow or other useful > monitoring of their networks....) > > Damian > From swanjonson at gmail.com Fri Feb 26 18:32:48 2016 From: swanjonson at gmail.com (Jon Swanson) Date: Fri, 26 Feb 2016 13:32:48 -0500 Subject: Standard terminology for a dark fiber path? In-Reply-To: References: Message-ID: As Dave C pointed out, it commonly referenced as a Fiber Span. The fiber span would be inclusive of any splice points and/or patches needed to provide connectivity between point A and point Z. A Fiber Stand is a single piece of glass within the cable sheath, often spliced to create a fiber span. A Dark Fiber Circuit commonly refers to the service/product that was sold by or bought from a Service Provider. The Dark Fiber Circuits are turned over to the customer as a fiber span between point A and point Z. It should also be noted that the span can consist of 1 fiber or a pair of fiber. It is common for service providers to us "Bi-Di" optics, allowing the use of 1 fiber for transmit and receive between their equipment. On Thu, Feb 25, 2016 at 8:32 PM, Dave Cohen wrote: > FWIW, at my $dayjob (a fiber-based service provider), the accepted term is > "span", which accounts for any continuous segment between add/drop and/or > regen locations (i.e. no provider or end user electronics in the middle, > only at the endpoints). The most common alternate I come across is > "segment". > > Re a couple of earlier suggestions - A patch between cables to provide > continuity, as compared to a fusion splice, doesn't inherently change this > view, as it has no bearing on the logical use of the span. Similarly, > "strand" isn't favored as it assumes a single fiber only, where the vast > majority of applications require a pair (or multiple pairs), so doesn't > accurately reflect the logical use of the span. I think "1F Span" is the > favored reference for a single-fiber deployment, for the sake of both > consistency and clarity. > > On Thu, Feb 25, 2016 at 6:27 PM, Michael Loftis wrote: > > > IDK what elsewhere uses but strand or (less common) span is the common > > term I've seen specifically for a passive piece of glass between two > > points. > > > > On Wed, Feb 24, 2016 at 12:55 PM, Fletcher Kittredge > > wrote: > > > What is the standard terminology for strands of dark fiber spliced > > together > > > to form a continuous path between points A and Z? > > > > > > I have seen: > > > > > > - *fiber circuit* [but also seen used to denote a connection at the > > > network layer over a physical fiber connection. This definition of > > circuit > > > would include the dark fiber path, the transmitters and receivers > and > > logic > > > making up the data and network layers.] > > > - *fiber loop *[ Does a loop define an electrical circuit with two > > > physically separate positive and negative strands? In that case, is > > this a > > > Bellhead remnant? ] > > > > > > I am particularly interested in last mile systems, but I don't see any > > > reason that the term wouldn't be the same in the middle mile. > > > > > > thanks, > > > Fletcher > > > > > > -- > > > Fletcher Kittredge > > > GWI > > > 8 Pomerleau Street > > > Biddeford, ME 04005-9457 > > > 207-602-1134 > > > > > > > > -- > > > > "Genius might be described as a supreme capacity for getting its > possessors > > into trouble of all kinds." > > -- Samuel Butler > > > > > > -- > - Dave Cohen > eM: craetdave at gmail.com > AIM: dCo says > From blake at ispn.net Fri Feb 26 20:01:05 2016 From: blake at ispn.net (Blake Hudson) Date: Fri, 26 Feb 2016 14:01:05 -0600 Subject: Thank you, Comcast. In-Reply-To: References: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <56D080EA.1000500@ispn.net> Message-ID: <56D0AF01.6040303@ispn.net> Livingood, Jason wrote on 2/26/2016 1:32 PM: > On 2/26/16, 11:44 AM, "Blake Hudson" > wrote: > > Jason, how do you propose to block SSDP without also blocking > legitimate traffic as well (since SSDP uses a port > 1024 and is > used as part of the ephemeral port range on some devices) ? > > > As Roland suggested, very likely via UDP/1900. This will obviously be > disclosed in advance to customers and tested thoroughly. I believe a > few other ISPs have already taken this step. > > And is this practice /Open Internet/ friendly? > > > Port blocking is considered a form of reasonable network management > provided it can be justified by security or operational stability > reasons. Of course it must also be transparently disclosed and so on. > > Jason The difference in blocking any of the existing ports on your list and blocking UDP/1900 is that the ports on your list are all registered ports. Port 1900 is not registered - a host may use port 1900 when making an outbound connection to another host (lookup ephemeral port range for more info) regardless of whether either host is using or running an SSDP server. A block on port 1900 will result in blocking legitimate customer traffic if the customer's device happened to select port 1900 as parts of its ephemeral port range. To my knowledge, a current Windows, Linux, Apple device will not use port 1900 as part of its ephemeral port range, but Wikipedia suggests XP and older Windows operating systems will and I know that many NAT routers will (which affects all clients behind that NAT router, regardless of their OS). I have no idea what popular mobile clients use for their ephemeral port ranges. I imagine the NAT routers will be most common actors using ports outside of the IANA suggested ephemeral port range. Do you suggest that it is "reasonable network management" that users behind a NAT router have their 876th (1900 - 1024) UDP connection attempt blocked? --Blake From blake at ispn.net Fri Feb 26 20:04:07 2016 From: blake at ispn.net (Blake Hudson) Date: Fri, 26 Feb 2016 14:04:07 -0600 Subject: Thank you, Comcast. In-Reply-To: <56D0AF01.6040303@ispn.net> References: <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <56D080EA.1000500@ispn.net> <56D0AF01.6040303@ispn.net> Message-ID: <56D0AFB7.5010406@ispn.net> Blake Hudson wrote on 2/26/2016 2:01 PM: > > Livingood, Jason wrote on 2/26/2016 1:32 PM: >> On 2/26/16, 11:44 AM, "Blake Hudson" > > wrote: >> >> Jason, how do you propose to block SSDP without also blocking >> legitimate traffic as well (since SSDP uses a port > 1024 and is >> used as part of the ephemeral port range on some devices) ? >> >> >> As Roland suggested, very likely via UDP/1900. This will obviously be >> disclosed in advance to customers and tested thoroughly. I believe a >> few other ISPs have already taken this step. >> >> And is this practice /Open Internet/ friendly? >> >> >> Port blocking is considered a form of reasonable network management >> provided it can be justified by security or operational stability >> reasons. Of course it must also be transparently disclosed and so on. >> >> Jason > The difference in blocking any of the existing ports on your list and > blocking UDP/1900 is that the ports on your list are all registered > ports. Port 1900 is not registered - a host may use port 1900 when > making an outbound connection to another host (lookup ephemeral port > range for more info) regardless of whether either host is using or > running an SSDP server. A block on port 1900 will result in blocking > legitimate customer traffic if the customer's device happened to > select port 1900 as parts of its ephemeral port range. > > To my knowledge, a current Windows, Linux, Apple device will not use > port 1900 as part of its ephemeral port range, but Wikipedia suggests > XP and older Windows operating systems will and I know that many NAT > routers will (which affects all clients behind that NAT router, > regardless of their OS). I have no idea what popular mobile clients > use for their ephemeral port ranges. I imagine the NAT routers will be > most common actors using ports outside of the IANA suggested ephemeral > port range. Do you suggest that it is "reasonable network management" > that users behind a NAT router have their 876th (1900 - 1024) UDP > connection attempt blocked? > > --Blake Correction, I should have stated that the ports < 1024 were well-known. 1900 is not a well-known port From rsk at gsp.org Fri Feb 26 20:08:15 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 26 Feb 2016 15:08:15 -0500 Subject: Thank you, Comcast. In-Reply-To: <56D08871.7080001@2mbit.com> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> <56D08871.7080001@2mbit.com> Message-ID: <20160226200815.GA1883@gsp.org> On Fri, Feb 26, 2016 at 10:16:33AM -0700, Brielle Bruns wrote: > You can't do anything about idiots buying a pro-sumer/professional > device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, > D-Link, Netgear, etc that are targeted towards home users should be > held to the fire for that kind of screw up. That is starting to happen: FTC Dings ASUS For Selling 'Secure' Routers That Shipped With Default Admin/Admin Login (And Other Flaws) https://www.techdirt.com/articles/20160223/11103133687/ftc-dings-asus-selling-secure-routers-that-shipped-with-default-admin-admin-login-other-flaws.shtml ---rsk From dovid at telecurve.com Fri Feb 26 20:43:34 2016 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 26 Feb 2016 20:43:34 +0000 Subject: Thank you, Comcast. In-Reply-To: References: <1310695257.13597.1456458114690.JavaMail.mhammett@ThunderFuck> <1341162075.13611.1456458371134.JavaMail.mhammett@ThunderFuck> <56D0506A.3030902@foobar.org> <5A798886-DA0A-4921-B5A6-9FF22A603865@gmail.com> <991FA495-A6F6-4C94-BCE9-37C1D6D73793@puck.nether.net> <874993180-1456512531-cardhu_decombobulator_blackberry.rim.net-817540925-@b11.c1.bise6.blackberry> Message-ID: <979224264-1456519416-cardhu_decombobulator_blackberry.rim.net-973200548-@b11.c1.bise6.blackberry> Lawsuits? There is no reason the dedicated server I have with a 100meg pipe for $65.00 per month is able to spoof IP's. The colo's should be doing a better job to lock this down. Regards, Dovid -----Original Message----- From: Damian Menscher Date: Fri, 26 Feb 2016 11:47:43 To: Dovid B Cc: Jared Mauch; Jason Livingood; Mody, Nirmal; NANOG list Subject: Re: Thank you, Comcast. "We all know..." followed by a false statement is amusing. A significant portion of spoofing originates from North America. In a recent attack I'm reviewing, the top sources of spoofing were the southwestern US, the northwestern US, and east Asia (and almost none from Europe). If ISPs understood how to collect and review netflow we might get somewhere... why is this so hard, and how do we fix it? Damian On Fri, Feb 26, 2016 at 10:48 AM, Dovid Bender wrote: > We all know what countries this traffic is coming from. While you can > threaten the local ISP's the ones over seas where the traffic is coming > from won't care. > > Regards, > > Dovid > > -----Original Message----- > From: Damian Menscher via NANOG > Sender: "NANOG" Date: Fri, 26 Feb 2016 08:02:52 > To: Jared Mauch; Jason Livingood< > Jason_Livingood at cable.comcast.com>; Mody, Nirmal< > Nirmal_Mody at cable.comcast.com> > Reply-To: Damian Menscher > Cc: NANOG list > Subject: Re: Thank you, Comcast. > > On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch > wrote: > > > As a community we need to determine if this background radiation and > these > > responses are proper. I think it's a good response since vendors can't do > > uRPF at line rate and the major purchasers of BCM switches don't ask for > it > > and aren't doing it, so it's not optimized or does not exist. /sigh > > > > I don't agree with the approach of going after individual reflectors > (open*project) or blocking specific ports (Comcast's action here) as both > are reactive, unlikely to be particularly effective (there are still > millions of reflectors and plenty of open ports available), and don't solve > the root problem (spoofed packets making it onto the public internet). > What I'd much rather see Comcast do is use their netflow to trace the > source of the spoofed packets (one of their peers or transit providers, no > doubt) and strongly encourage (using their legal or PR team as needed) them > to trace back and stop the spoofing. This benefits everyone in a much more > direct and scalable way. Until some of the larger providers start doing > that, amplification attacks and other spoofed-source attacks (DNS and > synfloods) will continue to thrive. > > (I've contacted several ISPs about the spoofed traffic they send to us. > The next major hurdle is that so many don't have netflow or other useful > monitoring of their networks....) > > Damian > From johnl at iecc.com Fri Feb 26 21:03:15 2016 From: johnl at iecc.com (John Levine) Date: 26 Feb 2016 21:03:15 -0000 Subject: Thank you, Comcast. In-Reply-To: <276C5EE1-891E-4D50-9515-268B6A37F8B3@arbor.net> Message-ID: <20160226210315.42978.qmail@ary.lan> >> Customers regularly use various VPN protocols from GRE, SIT, and >> IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where >> we spend the bulk of our time troubleshooting). > >Not so on consumer broadband access networks, which are what's being >discussed in this thread. A certain number of us work from home and connect to headquarters with a VPN. and have SIP phones, you know. Not just meganerds. R's, John From johnl at iecc.com Fri Feb 26 21:06:10 2016 From: johnl at iecc.com (John Levine) Date: 26 Feb 2016 21:06:10 -0000 Subject: Thank you, Comcast. In-Reply-To: <56D0AF01.6040303@ispn.net> Message-ID: <20160226210610.43001.qmail@ary.lan> >The difference in blocking any of the existing ports on your list and >blocking UDP/1900 is that the ports on your list are all registered >ports. Port 1900 is not registered - IANA is under the impression it's registered for SSDP. Do you have some reason to believe they're mistaken? http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=34 From bruns at 2mbit.com Fri Feb 26 22:04:12 2016 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 26 Feb 2016 15:04:12 -0700 Subject: Thank you, Comcast. In-Reply-To: <20160226200815.GA1883@gsp.org> References: <996175185.13792.1456493268163.JavaMail.mhammett@ThunderFuck> <56D075B8.3080806@2mbit.com> <20160226170227.GF8465@cmadams.net> <56D08871.7080001@2mbit.com> <20160226200815.GA1883@gsp.org> Message-ID: <56D0CBDC.80807@2mbit.com> On 2/26/16 1:08 PM, Rich Kulawiec wrote: > On Fri, Feb 26, 2016 at 10:16:33AM -0700, Brielle Bruns wrote: >> You can't do anything about idiots buying a pro-sumer/professional >> device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, >> D-Link, Netgear, etc that are targeted towards home users should be >> held to the fire for that kind of screw up. > > That is starting to happen: > > FTC Dings ASUS For Selling 'Secure' Routers That Shipped With Default Admin/Admin Login (And Other Flaws) > https://www.techdirt.com/articles/20160223/11103133687/ftc-dings-asus-selling-secure-routers-that-shipped-with-default-admin-admin-login-other-flaws.shtml > > ---rsk > It looks like they nailed ASUS due to it claiming to be 'secure'. I don't have a problem per-se with default passwords being used on a new device that requires configuration before it actually works and isn't marketed to the ignorant end user. IE: (again my experience with Ubiquiti stuff being a baseline) The EdgeRouter series is power user/professional targeted, default passwords, however it does not come 'pre-configured', can't route, can't NAT, etc without some initial setup. Cisco's non-consumer stuff like the Cat6500, etc having no password by default doesn't bug me because the thing is useless until you actually configure it. Its all about the market you are targeting IMHO. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From baldur.norddahl at gmail.com Fri Feb 26 23:18:16 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 27 Feb 2016 00:18:16 +0100 Subject: mrtg alternative Message-ID: Hi I am currently using MRTG and RRD to make traffic graphs. I am searching for more modern alternatives that allows the user to dynamically zoom and scroll the timeline. Bonus points if the user can customize the graphs directly in the webbrowse. For example he might be able to add or remove individual peers from the graph by simply clicking a checkbox. What is the 2016 tool for this? Regards, Baldur From adam at arfmail.com Fri Feb 26 21:07:51 2016 From: adam at arfmail.com (Adam) Date: Fri, 26 Feb 2016 21:07:51 +0000 Subject: Thank you, Comcast. In-Reply-To: <979224264-1456519416-cardhu_decombobulator_blackberry.rim.net-973200548-@b11.c1.bise6.blackberry> Message-ID: I'd expect the Colo's to start "locking this down" about the same time I'd expect ISP's to start implementing BCP38 in earnest. Adam ------ Original Message ------ From: "Dovid Bender" To: "Damian Menscher" Cc: "Mody, Nirmal" ; "NANOG list" Sent: 2/26/2016 3:43:34 PM Subject: Re: Thank you, Comcast. >Lawsuits? There is no reason the dedicated server I have with a 100meg >pipe for $65.00 per month is able to spoof IP's. The colo's should be >doing a better job to lock this down. > >Regards, > >Dovid > >-----Original Message----- >From: Damian Menscher >Date: Fri, 26 Feb 2016 11:47:43 >To: Dovid B >Cc: Jared Mauch; Jason >Livingood; Mody, >Nirmal; NANOG list >Subject: Re: Thank you, Comcast. > >"We all know..." followed by a false statement is amusing. > >A significant portion of spoofing originates from North America. In a >recent attack I'm reviewing, the top sources of spoofing were the >southwestern US, the northwestern US, and east Asia (and almost none >from >Europe). > >If ISPs understood how to collect and review netflow we might get >somewhere... why is this so hard, and how do we fix it? > >Damian > >On Fri, Feb 26, 2016 at 10:48 AM, Dovid Bender >wrote: > >> We all know what countries this traffic is coming from. While you can >> threaten the local ISP's the ones over seas where the traffic is >>coming >> from won't care. >> >> Regards, >> >> Dovid >> >> -----Original Message----- >> From: Damian Menscher via NANOG >> Sender: "NANOG" Date: Fri, 26 Feb 2016 >>08:02:52 >> To: Jared Mauch; Jason Livingood< >> Jason_Livingood at cable.comcast.com>; Mody, Nirmal< >> Nirmal_Mody at cable.comcast.com> >> Reply-To: Damian Menscher >> Cc: NANOG list >> Subject: Re: Thank you, Comcast. >> >> On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch >> wrote: >> >> > As a community we need to determine if this background radiation >>and >> these >> > responses are proper. I think it's a good response since vendors >>can't do >> > uRPF at line rate and the major purchasers of BCM switches don't >>ask for >> it >> > and aren't doing it, so it's not optimized or does not exist. /sigh >> > >> >> I don't agree with the approach of going after individual reflectors >> (open*project) or blocking specific ports (Comcast's action here) as >>both >> are reactive, unlikely to be particularly effective (there are still >> millions of reflectors and plenty of open ports available), and don't >>solve >> the root problem (spoofed packets making it onto the public >>internet). >> What I'd much rather see Comcast do is use their netflow to trace the >> source of the spoofed packets (one of their peers or transit >>providers, no >> doubt) and strongly encourage (using their legal or PR team as >>needed) them >> to trace back and stop the spoofing. This benefits everyone in a >>much more >> direct and scalable way. Until some of the larger providers start >>doing >> that, amplification attacks and other spoofed-source attacks (DNS and >> synfloods) will continue to thrive. >> >> (I've contacted several ISPs about the spoofed traffic they send to >>us. >> The next major hurdle is that so many don't have netflow or other >>useful >> monitoring of their networks....) >> >> Damian >> > From source_route at yahoo.com Fri Feb 26 23:01:21 2016 From: source_route at yahoo.com (Philip Lavine) Date: Fri, 26 Feb 2016 23:01:21 +0000 (UTC) Subject: google search threshold References: <1091559020.49418.1456527681809.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1091559020.49418.1456527681809.JavaMail.yahoo@mail.yahoo.com> Does anybody know what the threshold for google searches is before you get the captcha?I? am trying to decide if I need to break up the overload NAT to a pool. -thx From rdobbins at arbor.net Fri Feb 26 23:27:07 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 Feb 2016 06:27:07 +0700 Subject: Thank you, Comcast. In-Reply-To: <20160226210315.42978.qmail@ary.lan> References: <20160226210315.42978.qmail@ary.lan> Message-ID: On 27 Feb 2016, at 4:03, John Levine wrote: > A certain number of us work from home and connect to headquarters with > a VPN. and have SIP phones, you know. Not typically via/requiring the protocols you mentioned. ----------------------------------- Roland Dobbins From shawnl at up.net Fri Feb 26 23:30:02 2016 From: shawnl at up.net (Shawn L) Date: Fri, 26 Feb 2016 18:30:02 -0500 (EST) Subject: mrtg alternative In-Reply-To: References: Message-ID: <1456529402.703617259@upnet.mymailsrvr.com> We use observium. It has most of what you're looking for. Used to use cacti but switched a couple of months ago -----Original Message----- From: "Baldur Norddahl" Sent: Friday, February 26, 2016 6:18pm To: "nanog at nanog.org" Subject: mrtg alternative Hi I am currently using MRTG and RRD to make traffic graphs. I am searching for more modern alternatives that allows the user to dynamically zoom and scroll the timeline. Bonus points if the user can customize the graphs directly in the webbrowse. For example he might be able to add or remove individual peers from the graph by simply clicking a checkbox. What is the 2016 tool for this? Regards, Baldur From johnl at iecc.com Sat Feb 27 00:23:16 2016 From: johnl at iecc.com (John Levine) Date: 27 Feb 2016 00:23:16 -0000 Subject: Thank you, Comcast. In-Reply-To: Message-ID: <20160227002316.43463.qmail@ary.lan> >> A certain number of us work from home and connect to headquarters with >> a VPN. and have SIP phones, you know. > >Not typically via/requiring the protocols you mentioned. The VoIP phones sure use SIP. R's, John From rdobbins at arbor.net Sat Feb 27 00:36:26 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 Feb 2016 07:36:26 +0700 Subject: Thank you, Comcast. In-Reply-To: <20160227002316.43463.qmail@ary.lan> References: <20160227002316.43463.qmail@ary.lan> Message-ID: <2E05F3F7-6117-47B9-AE3C-04F8A5485E20@arbor.net> On 27 Feb 2016, at 7:23, John Levine wrote: > The VoIP phones sure use SIP. True, but how prevalent are 'bare' SIP phones vs. VoIP systems utilized by remote workers via VPNs? ----------------------------------- Roland Dobbins From kmedcalf at dessus.com Sat Feb 27 00:59:28 2016 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 26 Feb 2016 17:59:28 -0700 Subject: Thank you, Comcast. In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C9C04AB4@MUNPRDMBXA1.medline.com> Message-ID: <36636036dd03884ba8a23c4c0fc3c369@mail.dessus.com> The default configuration of IE (all versions), Firefox (all versions), Edge (all versions) and Chrome (all versions) is a zero-security configuration. Of course it works fine in a zero-security configuration -- I said that from the get go. It does not work if you do not permit javascript to run unless approved, and do not permit unapproved (and unapprovable scripts from third-party sites of unknown provenance) to run. It does not work if you block cross-site access to widgets and crap coming from third-parties of equally unknown provenance. I do not know what it is looking for, but it cannot do that, so therefore it does not work. You may not care about how insecure your browser is -- I do. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve > Sent: Friday, 26 February, 2016 10:11 > To: NANOG list > Subject: RE: Thank you, Comcast. > > Also worked fine in IE 11 and Firefox. I didn't change any particular > security settings either. Might want to check your stuff before you rant > on someone's web site. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Friday, February 26, 2016 10:01 AM > To: NANOG list > Subject: Re: Thank you, Comcast. > > Works fine on a default Chrome installation. *shrugs* > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Keith Medcalf" > To: "NANOG list" > Cc: "Nirmal Mody" > Sent: Friday, February 26, 2016 9:55:20 AM > Subject: RE: Thank you, Comcast. > > > On Friday, 26 February, 2016 08:13, Jason_Livingood at comcast.com said: > > > FWIW, Comcast's list of blocked ports is at > > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > > ports/. The suspensions this week are in direct response to reported > > abuse from amplification attacks, which we obviously take very > seriously. > > God is that a horrid web page. I cannot view it. The wheels on the bus go > round and round non-stop. > > It has so much intertwined malicious javascript, cross-site scripting, and > malicious trackers that the alarm klaxons go off when I attempt to access > it. I spent a couple of minutes attempting to access the page but still > maintaining blocks to the malicious links. Apparently, viewing the page > requires that all security be turned off and that the viewer allows > completely untrusted code from completely untrustworty sources to run > unabated on the viewers computer. > > I do not permit this. For anyone. Ever. > > This pretty much ensures that I would never be one of your customers. If > you cannot operate a server which serves renderable non-malicious web > pages properly, what hope is there that you can do anything else right? > > > We are in the process of considering adding some new ports to this > > block list right now, and one big suggestion is SSDP. If you have any > > others you wish to suggest please send them to me and the guy on the > > cc line (Nirmal Mody). > > > On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" > bounces at nanog.org on behalf of kmedcalf at dessus.com> wrote: > > > > > > > > ISP's should block nothing, to or from the customer, unless they make > > it clear *before* selling the service (and include it in the Terms and > > Conditions of Service Contract), that they are not selling an Internet > > connection but are selling a partially functional Internet connection > > (or a limited Internet Service), and specifying exactly what the > > built-in deficiencies are. > > > > Deficiencies may include: > > port/protocol blockage toward the customer (destination blocks) > > port/protocol blockage toward the internet (source blocks) DNS > > diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) > > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > > > Some ISPs are good at this and provide opt-in/out methods for at least > > the first three on the list. Others not so much. > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maxwell Cole > > Sent: Friday, 26 February, 2016 07:19 > > To: Mikael Abrahamsson > > Cc: NANOG list > > Subject: Re: Thank you, Comcast. > > I agree, > > At the very least things like SNMP/NTP should be blocked. I mean how > > many people actually run a legit NTP server out of their home? > > Dozens? And the > > people who run SNMP devices with the default/common communities aren't > > the ones using it. > > If the argument is that you need a Business class account to run a > > mail server then I have no problem extending that to DNS servers also. > > Cheers, > > Max > > > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson > > > > wrote: > > > > > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > > > > > >> Traffic from dns-spoofing attacks generally has src port = > > 53 and dst > > port = random. If you block packets with udp src port=53 towards > > customers, you will also block legitimate return traffic if the > > customers run their own DNS servers or use opendns / google dns / etc. > > > > > > Sure, it's a very interesting discussion what ports should > > be blocked or > > not. > > > > > > http://www.bitag.org/documents/Port-Blocking.pdf > > > > > > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. > > They've been > > blocked for a very long time to fix some issues, even though there is > > legitimate use for these ports. > > > > > > So if you're blocking these ports, it seems like a small > > step to block > > UDP/TCP/53 towards customers as well. I can't come up with an argument > > that makes sense to block TCP/25 and then not block port > > UDP/TCP/53 as > > well. If you're protecting the Internet from your customers > > misconfiguraiton by blocking port 25 and the MS ports, why not > > 53 as well? > > > > > > This is a slippery slope of course, and judgement calls are > > not easy to > > make. > > > > > > -- > > > Mikael Abrahamsson email: swmike at swm.pp.se > > > > > > > > > > > > > > > > From johnl at iecc.com Sat Feb 27 00:59:49 2016 From: johnl at iecc.com (John Levine) Date: 27 Feb 2016 00:59:49 -0000 Subject: Thank you, Comcast. In-Reply-To: <2E05F3F7-6117-47B9-AE3C-04F8A5485E20@arbor.net> Message-ID: <20160227005949.43608.qmail@ary.lan> >True, but how prevalent are 'bare' SIP phones vs. VoIP systems utilized >by remote workers via VPNs? Dunno, but I have two of them. I think that most if not all of the consumer over the top VoIP phones like Vonage use SIP. R's, John From rdobbins at arbor.net Sat Feb 27 01:02:06 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 Feb 2016 08:02:06 +0700 Subject: Thank you, Comcast. In-Reply-To: <20160227005949.43608.qmail@ary.lan> References: <20160227005949.43608.qmail@ary.lan> Message-ID: On 27 Feb 2016, at 7:59, John Levine wrote: > I think that most if not all of the consumer over the top VoIP phones > like Vonage use SIP. That's true. One would hope that they're not globally reachable, however. ----------------------------------- Roland Dobbins From kmedcalf at dessus.com Sat Feb 27 01:06:07 2016 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 26 Feb 2016 18:06:07 -0700 Subject: Thank you, Comcast. In-Reply-To: <276C5EE1-891E-4D50-9515-268B6A37F8B3@arbor.net> Message-ID: Really? Consumer Narrowband Access Networks use these protocols all the time. (I call them narrowband since that is what they are -- even though the common euphamism is broadband, "broad" it certainly is not). > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins > Sent: Friday, 26 February, 2016 10:55 > To: NANOG list > Subject: Re: Thank you, Comcast. > > On 26 Feb 2016, at 22:52, Jay Nugent wrote: > > > Customers regularly use various VPN protocols from GRE, SIT, and > > IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where > > we spend the bulk of our time troubleshooting). > > Not so on consumer broadband access networks, which are what's being > discussed in this thread. > > It's a different story for transit operators. > > ----------------------------------- > Roland Dobbins From rdobbins at arbor.net Sat Feb 27 01:16:27 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 Feb 2016 08:16:27 +0700 Subject: Thank you, Comcast. In-Reply-To: References: Message-ID: <90A7AA5C-149F-4E68-9851-D0455B0566B8@arbor.net> On 27 Feb 2016, at 8:06, Keith Medcalf wrote: > Consumer Narrowband Access Networks use these protocols all the time. Most broadband access customers do not actively use these protocols, themselves, with the partial exception of SIP. ----------------------------------- Roland Dobbins From nanog at ics-il.net Sat Feb 27 01:21:04 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Feb 2016 19:21:04 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: <36636036dd03884ba8a23c4c0fc3c369@mail.dessus.com> Message-ID: <554056413.14721.1456536064092.JavaMail.mhammett@ThunderFuck> So we have people saying that blocking residential users from hosting DNS servers is not really providing Internet service. Now we have people saying it isn't service if it doesn't (more or less) completely work in lynx. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" To: "NANOG list" Sent: Friday, February 26, 2016 6:59:28 PM Subject: RE: Thank you, Comcast. The default configuration of IE (all versions), Firefox (all versions), Edge (all versions) and Chrome (all versions) is a zero-security configuration. Of course it works fine in a zero-security configuration -- I said that from the get go. It does not work if you do not permit javascript to run unless approved, and do not permit unapproved (and unapprovable scripts from third-party sites of unknown provenance) to run. It does not work if you block cross-site access to widgets and crap coming from third-parties of equally unknown provenance. I do not know what it is looking for, but it cannot do that, so therefore it does not work. You may not care about how insecure your browser is -- I do. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve > Sent: Friday, 26 February, 2016 10:11 > To: NANOG list > Subject: RE: Thank you, Comcast. > > Also worked fine in IE 11 and Firefox. I didn't change any particular > security settings either. Might want to check your stuff before you rant > on someone's web site. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Friday, February 26, 2016 10:01 AM > To: NANOG list > Subject: Re: Thank you, Comcast. > > Works fine on a default Chrome installation. *shrugs* > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Keith Medcalf" > To: "NANOG list" > Cc: "Nirmal Mody" > Sent: Friday, February 26, 2016 9:55:20 AM > Subject: RE: Thank you, Comcast. > > > On Friday, 26 February, 2016 08:13, Jason_Livingood at comcast.com said: > > > FWIW, Comcast's list of blocked ports is at > > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > > ports/. The suspensions this week are in direct response to reported > > abuse from amplification attacks, which we obviously take very > seriously. > > God is that a horrid web page. I cannot view it. The wheels on the bus go > round and round non-stop. > > It has so much intertwined malicious javascript, cross-site scripting, and > malicious trackers that the alarm klaxons go off when I attempt to access > it. I spent a couple of minutes attempting to access the page but still > maintaining blocks to the malicious links. Apparently, viewing the page > requires that all security be turned off and that the viewer allows > completely untrusted code from completely untrustworty sources to run > unabated on the viewers computer. > > I do not permit this. For anyone. Ever. > > This pretty much ensures that I would never be one of your customers. If > you cannot operate a server which serves renderable non-malicious web > pages properly, what hope is there that you can do anything else right? > > > We are in the process of considering adding some new ports to this > > block list right now, and one big suggestion is SSDP. If you have any > > others you wish to suggest please send them to me and the guy on the > > cc line (Nirmal Mody). > > > On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" > bounces at nanog.org on behalf of kmedcalf at dessus.com> wrote: > > > > > > > > ISP's should block nothing, to or from the customer, unless they make > > it clear *before* selling the service (and include it in the Terms and > > Conditions of Service Contract), that they are not selling an Internet > > connection but are selling a partially functional Internet connection > > (or a limited Internet Service), and specifying exactly what the > > built-in deficiencies are. > > > > Deficiencies may include: > > port/protocol blockage toward the customer (destination blocks) > > port/protocol blockage toward the internet (source blocks) DNS > > diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) > > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > > > Some ISPs are good at this and provide opt-in/out methods for at least > > the first three on the list. Others not so much. > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maxwell Cole > > Sent: Friday, 26 February, 2016 07:19 > > To: Mikael Abrahamsson > > Cc: NANOG list > > Subject: Re: Thank you, Comcast. > > I agree, > > At the very least things like SNMP/NTP should be blocked. I mean how > > many people actually run a legit NTP server out of their home? > > Dozens? And the > > people who run SNMP devices with the default/common communities aren't > > the ones using it. > > If the argument is that you need a Business class account to run a > > mail server then I have no problem extending that to DNS servers also. > > Cheers, > > Max > > > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson > > > > wrote: > > > > > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > > > > > >> Traffic from dns-spoofing attacks generally has src port = > > 53 and dst > > port = random. If you block packets with udp src port=53 towards > > customers, you will also block legitimate return traffic if the > > customers run their own DNS servers or use opendns / google dns / etc. > > > > > > Sure, it's a very interesting discussion what ports should > > be blocked or > > not. > > > > > > http://www.bitag.org/documents/Port-Blocking.pdf > > > > > > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. > > They've been > > blocked for a very long time to fix some issues, even though there is > > legitimate use for these ports. > > > > > > So if you're blocking these ports, it seems like a small > > step to block > > UDP/TCP/53 towards customers as well. I can't come up with an argument > > that makes sense to block TCP/25 and then not block port > > UDP/TCP/53 as > > well. If you're protecting the Internet from your customers > > misconfiguraiton by blocking port 25 and the MS ports, why not > > 53 as well? > > > > > > This is a slippery slope of course, and judgement calls are > > not easy to > > make. > > > > > > -- > > > Mikael Abrahamsson email: swmike at swm.pp.se > > > > > > > > > > > > > > > > From yang.yu.list at gmail.com Sat Feb 27 01:42:09 2016 From: yang.yu.list at gmail.com (Yang Yu) Date: Fri, 26 Feb 2016 19:42:09 -0600 Subject: Sprint Wireless DNS server not resolving ietf.org Message-ID: ietf.org and its subdomains such as tools.ietf.org are not accessible on Sprint 3G/LTE (DNS timeout). From what I gathered this is affecting Sprint wireless customers nationwide. I created a DNS measurement on ripe atlas and no signs of other carriers experiencing the same issue. Emailed Sprint NOC and opened a ticket via support channel, got no update. Is there someone from Sprint Wireless on this list? DNS servers 68.28.169.132 68.28.168.132 Thanks. Yang From kmedcalf at dessus.com Sat Feb 27 01:43:17 2016 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 26 Feb 2016 18:43:17 -0700 Subject: Thank you, Comcast. In-Reply-To: <554056413.14721.1456536064092.JavaMail.mhammett@ThunderFuck> Message-ID: Who said that? Of course, it is almost impossible to do anything malicious with lynx as the browser. Why you need to run scripts from google, adobe, and a myriad of other sources (including not less than 3 third party malvertizing sites, 6 tracking sites, and 2 miscellaneous known-malicious content sites is beyond me. It is downright disgusting that your page requires that such malicious sh*t be allowed free reign in order to view your web pages (which would be more properly known as infection pages). Of course, you might also be requiring Flash or some other dildo-ass plugin as well, all of which will not run because I do not permit them to run without permission (in fact, the blocking is so damn good that you will be unable to detect whether those facilities exist or not). > Now we have people > saying it isn't service if it doesn't (more or less) completely work in > lynx. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Keith Medcalf" > To: "NANOG list" > Sent: Friday, February 26, 2016 6:59:28 PM > Subject: RE: Thank you, Comcast. > > > The default configuration of IE (all versions), Firefox (all versions), > Edge (all versions) and Chrome (all versions) is a zero-security > configuration. Of course it works fine in a zero-security configuration -- > I said that from the get go. > > It does not work if you do not permit javascript to run unless approved, > and do not permit unapproved (and unapprovable scripts from third-party > sites of unknown provenance) to run. It does not work if you block cross- > site access to widgets and crap coming from third-parties of equally > unknown provenance. > > I do not know what it is looking for, but it cannot do that, so therefore > it does not work. > > You may not care about how insecure your browser is -- I do. > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve > > Sent: Friday, 26 February, 2016 10:11 > > To: NANOG list > > Subject: RE: Thank you, Comcast. > > > > Also worked fine in IE 11 and Firefox. I didn't change any particular > > security settings either. Might want to check your stuff before you rant > > on someone's web site. > > > > Steven Naslund > > Chicago IL > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > > Sent: Friday, February 26, 2016 10:01 AM > > To: NANOG list > > Subject: Re: Thank you, Comcast. > > > > Works fine on a default Chrome installation. *shrugs* > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Keith Medcalf" > > To: "NANOG list" > > Cc: "Nirmal Mody" > > Sent: Friday, February 26, 2016 9:55:20 AM > > Subject: RE: Thank you, Comcast. > > > > > > On Friday, 26 February, 2016 08:13, Jason_Livingood at comcast.com said: > > > > > FWIW, Comcast's list of blocked ports is at > > > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > > > ports/. The suspensions this week are in direct response to reported > > > abuse from amplification attacks, which we obviously take very > > seriously. > > > > God is that a horrid web page. I cannot view it. The wheels on the bus > go > > round and round non-stop. > > > > It has so much intertwined malicious javascript, cross-site scripting, > and > > malicious trackers that the alarm klaxons go off when I attempt to > access > > it. I spent a couple of minutes attempting to access the page but still > > maintaining blocks to the malicious links. Apparently, viewing the page > > requires that all security be turned off and that the viewer allows > > completely untrusted code from completely untrustworty sources to run > > unabated on the viewers computer. > > > > I do not permit this. For anyone. Ever. > > > > This pretty much ensures that I would never be one of your customers. If > > you cannot operate a server which serves renderable non-malicious web > > pages properly, what hope is there that you can do anything else right? > > > > > We are in the process of considering adding some new ports to this > > > block list right now, and one big suggestion is SSDP. If you have any > > > others you wish to suggest please send them to me and the guy on the > > > cc line (Nirmal Mody). > > > > > On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" > > bounces at nanog.org on behalf of kmedcalf at dessus.com> wrote: > > > > > > > > > > > > ISP's should block nothing, to or from the customer, unless they make > > > it clear *before* selling the service (and include it in the Terms and > > > Conditions of Service Contract), that they are not selling an Internet > > > connection but are selling a partially functional Internet connection > > > (or a limited Internet Service), and specifying exactly what the > > > built-in deficiencies are. > > > > > > Deficiencies may include: > > > port/protocol blockage toward the customer (destination blocks) > > > port/protocol blockage toward the internet (source blocks) DNS > > > diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc) > > > Traffic Shaping/Policing/Congestion policies, inbound and outbound > > > > > > Some ISPs are good at this and provide opt-in/out methods for at least > > > the first three on the list. Others not so much. > > > > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maxwell Cole > > > Sent: Friday, 26 February, 2016 07:19 > > > To: Mikael Abrahamsson > > > Cc: NANOG list > > > Subject: Re: Thank you, Comcast. > > > I agree, > > > At the very least things like SNMP/NTP should be blocked. I mean how > > > many people actually run a legit NTP server out of their home? > > > Dozens? And the > > > people who run SNMP devices with the default/common communities aren't > > > the ones using it. > > > If the argument is that you need a Business class account to run a > > > mail server then I have no problem extending that to DNS servers also. > > > Cheers, > > > Max > > > > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson > > > > > > wrote: > > > > > > > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > > > > > > > >> Traffic from dns-spoofing attacks generally has src port = > > > 53 and dst > > > port = random. If you block packets with udp src port=53 towards > > > customers, you will also block legitimate return traffic if the > > > customers run their own DNS servers or use opendns / google dns / etc. > > > > > > > > Sure, it's a very interesting discussion what ports should > > > be blocked or > > > not. > > > > > > > > http://www.bitag.org/documents/Port-Blocking.pdf > > > > > > > > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. > > > They've been > > > blocked for a very long time to fix some issues, even though there is > > > legitimate use for these ports. > > > > > > > > So if you're blocking these ports, it seems like a small > > > step to block > > > UDP/TCP/53 towards customers as well. I can't come up with an argument > > > that makes sense to block TCP/25 and then not block port > > > UDP/TCP/53 as > > > well. If you're protecting the Internet from your customers > > > misconfiguraiton by blocking port 25 and the MS ports, why not > > > 53 as well? > > > > > > > > This is a slippery slope of course, and judgement calls are > > > not easy to > > > make. > > > > > > > > -- > > > > Mikael Abrahamsson email: swmike at swm.pp.se > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From damian at google.com Sat Feb 27 02:05:17 2016 From: damian at google.com (Damian Menscher) Date: Fri, 26 Feb 2016 18:05:17 -0800 Subject: google search threshold In-Reply-To: <1091559020.49418.1456527681809.JavaMail.yahoo@mail.yahoo.com> References: <1091559020.49418.1456527681809.JavaMail.yahoo.ref@mail.yahoo.com> <1091559020.49418.1456527681809.JavaMail.yahoo@mail.yahoo.com> Message-ID: On Fri, Feb 26, 2016 at 3:01 PM, Philip Lavine via NANOG wrote: > Does anybody know what the threshold for google searches is before you get > the captcha?I am trying to decide if I need to break up the overload NAT > to a pool. > There isn't a threshold -- if you send automated searches from an IP, then it gets blocked (for a while). So... this comes down to how much you trust your machines/users. If you're a company with managed systems, then you can have thousands of users share the same IP without problems. But if you're an ISP, you'll likely run into problems much earlier (since users like their malware). Some tips: - if you do NAT: try to partition users into pools so one abusive user can't get all your external IPs blocked - if you have a proxy: make sure it inserts the X-Forwarded-For header, and is restricted to your own users - if you're an ISP: IPv6 will allow each user to have their own /64, which avoids shared-fate from abusive ones Damian (responsible for DDoS defense) -- Damian Menscher :: Security Reliability Engineer :: Google :: AS15169 From rsk at gsp.org Sat Feb 27 13:07:04 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 27 Feb 2016 08:07:04 -0500 Subject: Thank you, Comcast. In-Reply-To: <554056413.14721.1456536064092.JavaMail.mhammett@ThunderFuck> References: <36636036dd03884ba8a23c4c0fc3c369@mail.dessus.com> <554056413.14721.1456536064092.JavaMail.mhammett@ThunderFuck> Message-ID: <20160227130704.GA15598@gsp.org> On Fri, Feb 26, 2016 at 07:21:04PM -0600, Mike Hammett wrote: > So we have people saying that blocking residential users from hosting > DNS servers is not really providing Internet service. Now we have people > saying it isn't service if it doesn't (more or less) completely work > in lynx. Actually, nobody is saying that, but: there is zero reason why that page shouldn't work in a text-only browser like lynx or w3m. It conveys technical information of importance to current and prospective users of the service. It *should* comply with the ADA and other accessability standards, and one well-known baseline way to (at minimum) take a vague step in that direction is to ensure that it's reasable (and navigable) in a text-only browser. There's also zero reason why that page should require Javascript, plugins (especially obsolete and dangerous plugins like Flash), or why it should utilize advertising, trackers, and malicious third-party sites, or why it should be horribly bloated with useless junk. The problem here is not the people who choose to use browsers and browser configurations set for security and privacy. The problem is the jerks who published important information in a cesspool. ---rsk From nanog at ics-il.net Sat Feb 27 13:59:36 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 27 Feb 2016 07:59:36 -0600 (CST) Subject: Thank you, Comcast. In-Reply-To: <20160227130704.GA15598@gsp.org> Message-ID: <82542234.15.1456581570884.JavaMail.mhammett@ThunderFuck> I'm fairly certainly we'll never agree., so might as well end it now. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Rich Kulawiec" To: nanog at nanog.org Sent: Saturday, February 27, 2016 7:07:04 AM Subject: Re: Thank you, Comcast. On Fri, Feb 26, 2016 at 07:21:04PM -0600, Mike Hammett wrote: > So we have people saying that blocking residential users from hosting > DNS servers is not really providing Internet service. Now we have people > saying it isn't service if it doesn't (more or less) completely work > in lynx. Actually, nobody is saying that, but: there is zero reason why that page shouldn't work in a text-only browser like lynx or w3m. It conveys technical information of importance to current and prospective users of the service. It *should* comply with the ADA and other accessability standards, and one well-known baseline way to (at minimum) take a vague step in that direction is to ensure that it's reasable (and navigable) in a text-only browser. There's also zero reason why that page should require Javascript, plugins (especially obsolete and dangerous plugins like Flash), or why it should utilize advertising, trackers, and malicious third-party sites, or why it should be horribly bloated with useless junk. The problem here is not the people who choose to use browsers and browser configurations set for security and privacy. The problem is the jerks who published important information in a cesspool. ---rsk From frnkblk at iname.com Sat Feb 27 18:26:41 2016 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 27 Feb 2016 12:26:41 -0600 Subject: Southwest Airlines captive portal Message-ID: <000a01d1718c$686eff80$394cfe80$@iname.com> Anyone from Southwest Airlines on this list? On a recent flight I discovered I couldn't complete payment through PayPal because my web browsers properly noticed that the Southwest Airlines SSL certificate that the captive portal was giving for PayPal didn't match up. =) I had to create an exception for PayPal just to complete payment. Frank From damien at supremebytes.com Sat Feb 27 18:57:55 2016 From: damien at supremebytes.com (Damien Burke) Date: Sat, 27 Feb 2016 18:57:55 +0000 Subject: Southwest Airlines captive portal In-Reply-To: <000a01d1718c$686eff80$394cfe80$@iname.com> References: <000a01d1718c$686eff80$394cfe80$@iname.com> Message-ID: <2FD50E6D13594B4C93B743BFCF9F52843D0D604D@EXCH01.sb.local> You should change your paypal password. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk Sent: Saturday, February 27, 2016 10:27 AM To: nanog at nanog.org Subject: Southwest Airlines captive portal Anyone from Southwest Airlines on this list? On a recent flight I discovered I couldn't complete payment through PayPal because my web browsers properly noticed that the Southwest Airlines SSL certificate that the captive portal was giving for PayPal didn't match up. =) I had to create an exception for PayPal just to complete payment. Frank From mkamal at noor.net Sat Feb 27 21:01:33 2016 From: mkamal at noor.net (Mohamed Kamal) Date: Sat, 27 Feb 2016 23:01:33 +0200 Subject: mrtg alternative In-Reply-To: References: Message-ID: <56D20EAD.2040608@noor.net> We use Zenoss, pretty awesome and do the job. Mohamed Kamal Core Network Sr. Engineer On 2/27/2016 1:18 AM, Baldur Norddahl wrote: > Hi > > I am currently using MRTG and RRD to make traffic graphs. I am searching > for more modern alternatives that allows the user to dynamically zoom and > scroll the timeline. > > Bonus points if the user can customize the graphs directly in the > webbrowse. For example he might be able to add or remove individual peers > from the graph by simply clicking a checkbox. > > What is the 2016 tool for this? > > Regards, > > Baldur > From rganascim at gmail.com Sat Feb 27 21:12:12 2016 From: rganascim at gmail.com (Rafael Ganascim) Date: Sat, 27 Feb 2016 18:12:12 -0300 Subject: mrtg alternative In-Reply-To: References: Message-ID: I like cacti: http://www.cacti.net 2016-02-26 20:18 GMT-03:00 Baldur Norddahl : > Hi > > I am currently using MRTG and RRD to make traffic graphs. I am searching > for more modern alternatives that allows the user to dynamically zoom and > scroll the timeline. > > Bonus points if the user can customize the graphs directly in the > webbrowse. For example he might be able to add or remove individual peers > from the graph by simply clicking a checkbox. > > What is the 2016 tool for this? > > Regards, > > Baldur > From paras at protrafsolutions.com Sat Feb 27 23:09:00 2016 From: paras at protrafsolutions.com (Paras Jha) Date: Sat, 27 Feb 2016 18:09:00 -0500 Subject: Southwest Airlines captive portal In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F52843D0D604D@EXCH01.sb.local> References: <000a01d1718c$686eff80$394cfe80$@iname.com> <2FD50E6D13594B4C93B743BFCF9F52843D0D604D@EXCH01.sb.local> Message-ID: You got MITM'd On Sat, Feb 27, 2016 at 1:57 PM, Damien Burke wrote: > You should change your paypal password. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk > Sent: Saturday, February 27, 2016 10:27 AM > To: nanog at nanog.org > Subject: Southwest Airlines captive portal > > Anyone from Southwest Airlines on this list? > > On a recent flight I discovered I couldn't complete payment through PayPal > because my web browsers properly noticed that the Southwest Airlines SSL > certificate that the captive portal was giving for PayPal didn't match up. > =) I had to create an exception for PayPal just to complete payment. > > Frank > > From mureninc at gmail.com Sat Feb 27 23:32:39 2016 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sat, 27 Feb 2016 15:32:39 -0800 Subject: Southwest Airlines captive portal In-Reply-To: <000a01d1718c$686eff80$394cfe80$@iname.com> References: <000a01d1718c$686eff80$394cfe80$@iname.com> Message-ID: On 27 February 2016 at 10:26, Frank Bulk wrote: > Anyone from Southwest Airlines on this list? > > On a recent flight I discovered I couldn't complete payment through PayPal > because my web browsers properly noticed that the Southwest Airlines SSL > certificate that the captive portal was giving for PayPal didn't match up. > =) I had to create an exception for PayPal just to complete payment. > > Frank I think it is PayPal you should be contacting instead. PayPal User Agreement requires that you maintain adequate security of your account credentials, and immediately notify PayPal that your password has been compromised. https://www.paypal.com/webapps/mpp/ua/useragreement-full > 1.6 Password Security and Keeping Your Email and Address Current. You are responsible for maintaining adequate security and control of any and all IDs, passwords, personal identification numbers (PINs), or any other codes that you use to access the Services. ... > 12.2 Notification Requirements. > > You should immediately notify PayPal if you believe: > there has been an unauthorized transaction or unauthorized access to your Account; > there is an error in your Account Profile or activity or transaction confirmation sent to you by email; > your password or PIN has been compromised; ... C. From peterl at standingwave.org Sat Feb 27 23:33:20 2016 From: peterl at standingwave.org (Peter Loron) Date: Sat, 27 Feb 2016 15:33:20 -0800 Subject: mrtg alternative In-Reply-To: References: Message-ID: We?re using Observium for trend collecting, graphing, and alerting. -Pete On 2/27/16, 13:12, "NANOG on behalf of Rafael Ganascim" wrote: >I like cacti: > >http://www.cacti.net > > > >2016-02-26 20:18 GMT-03:00 Baldur Norddahl : > >> Hi >> >> I am currently using MRTG and RRD to make traffic graphs. I am searching >> for more modern alternatives that allows the user to dynamically zoom and >> scroll the timeline. >> >> Bonus points if the user can customize the graphs directly in the >> webbrowse. For example he might be able to add or remove individual peers >> from the graph by simply clicking a checkbox. >> >> What is the 2016 tool for this? >> >> Regards, >> >> Baldur >> > From peterl at standingwave.org Sat Feb 27 23:34:24 2016 From: peterl at standingwave.org (Peter Loron) Date: Sat, 27 Feb 2016 15:34:24 -0800 Subject: Southwest Airlines captive portal In-Reply-To: References: <000a01d1718c$686eff80$394cfe80$@iname.com> <2FD50E6D13594B4C93B743BFCF9F52843D0D604D@EXCH01.sb.local> Message-ID: <7CBE2368-6EF0-4F1E-9AD1-C8CA1C44F5B6@standingwave.org> Likely. Let Southwest know, and as others have said, change your password. Hopefully it was unique to PayPal. -Pete On 2/27/16, 15:09, "NANOG on behalf of Paras Jha" wrote: >You got MITM'd > >On Sat, Feb 27, 2016 at 1:57 PM, Damien Burke >wrote: > >> You should change your paypal password. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk >> Sent: Saturday, February 27, 2016 10:27 AM >> To: nanog at nanog.org >> Subject: Southwest Airlines captive portal >> >> Anyone from Southwest Airlines on this list? >> >> On a recent flight I discovered I couldn't complete payment through PayPal >> because my web browsers properly noticed that the Southwest Airlines SSL >> certificate that the captive portal was giving for PayPal didn't match up. >> =) I had to create an exception for PayPal just to complete payment. >> >> Frank >> >> > From rubensk at gmail.com Sat Feb 27 23:40:40 2016 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 27 Feb 2016 20:40:40 -0300 Subject: Southwest Airlines captive portal In-Reply-To: <000a01d1718c$686eff80$394cfe80$@iname.com> References: <000a01d1718c$686eff80$394cfe80$@iname.com> Message-ID: On Sat, Feb 27, 2016 at 3:26 PM, Frank Bulk wrote: > Anyone from Southwest Airlines on this list? > > On a recent flight I discovered I couldn't complete payment through PayPal > because my web browsers properly noticed that the Southwest Airlines SSL > certificate that the captive portal was giving for PayPal didn't match up. > =) I had to create an exception for PayPal just to complete payment. > > Perhaps not a captive portal but a TLS accelerator that is sometimes used in satellite connections, that does act as MITM like corporate security products but with a performance focus. Since many commonly used web properties are moving to HSTS + HPKP + CT it will become increasingly difficult to balance performance and security in high latency connections, but when it comes to a payment gateway, that airline should probably turn off acceleration for paypal.com and 3-D Secure bank pages. Rubens From saper at saper.info Sat Feb 27 23:43:47 2016 From: saper at saper.info (Marcin Cieslak) Date: Sat, 27 Feb 2016 23:43:47 +0000 Subject: Southwest Airlines captive portal In-Reply-To: References: <000a01d1718c$686eff80$394cfe80$@iname.com> Message-ID: On Sat, 27 Feb 2016, Constantine A. Murenin wrote: > On 27 February 2016 at 10:26, Frank Bulk wrote: > > Anyone from Southwest Airlines on this list? > > > > On a recent flight I discovered I couldn't complete payment through PayPal > > because my web browsers properly noticed that the Southwest Airlines SSL > > certificate that the captive portal was giving for PayPal didn't match up. > > =) I had to create an exception for PayPal just to complete payment. > > > > Frank > > I think it is PayPal you should be contacting instead. > > PayPal User Agreement requires that you maintain adequate security of > your account credentials, and immediately notify PayPal that your > password has been compromised. > > https://www.paypal.com/webapps/mpp/ua/useragreement-full > > > 1.6 Password Security and Keeping Your Email and Address Current. You are responsible for maintaining adequate security and control of any and all IDs, passwords, personal identification numbers (PINs), or any other codes that you use to access the Services. > ... in theory I suspected I was almost mit'med once, I have notified them immediately and got a standard blurb about keeping my anti virus software up to date... Marcin From yang.yu.list at gmail.com Sun Feb 28 01:24:08 2016 From: yang.yu.list at gmail.com (Yang Yu) Date: Sat, 27 Feb 2016 19:24:08 -0600 Subject: Southwest Airlines captive portal In-Reply-To: References: <000a01d1718c$686eff80$394cfe80$@iname.com> Message-ID: On Sat, Feb 27, 2016 at 5:40 PM, Rubens Kuhl wrote: > Since many commonly used web properties are moving to HSTS + HPKP + CT it > will become increasingly difficult to balance performance and security in > high latency connections, but when it comes to a payment gateway, that > airline should probably turn off acceleration for paypal.com and 3-D Secure > bank pages. Paypal's certificate is not pinned in Chrome/Firefox. imo a hard error is desirable in this kind of scenario. https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json?view=markup https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#New_sites_pinned_in_Firefox_32 FWIW Southwest uses Row 44 (GEE Media) for inflight wifi. http://www.geemedia.com/products/connectivity From b-nanog at grmbl.net Sun Feb 28 01:42:31 2016 From: b-nanog at grmbl.net (B) Date: Sun, 28 Feb 2016 02:42:31 +0100 Subject: mrtg alternative In-Reply-To: <1456529402.703617259@upnet.mymailsrvr.com> References: <1456529402.703617259@upnet.mymailsrvr.com> Message-ID: <20160228014231.GA8264@mx.grmbl.net> Welcome to the future. Graphite/grafana. On Fri, Feb 26, 2016 at 06:30:02PM -0500, Shawn L wrote: > > We use observium. It has most of what you're looking for. Used to use cacti but switched a couple of months ago > > > -----Original Message----- > From: "Baldur Norddahl" > Sent: Friday, February 26, 2016 6:18pm > To: "nanog at nanog.org" > Subject: mrtg alternative > > > > Hi > > I am currently using MRTG and RRD to make traffic graphs. I am searching > for more modern alternatives that allows the user to dynamically zoom and > scroll the timeline. > > Bonus points if the user can customize the graphs directly in the > webbrowse. For example he might be able to add or remove individual peers > from the graph by simply clicking a checkbox. > > What is the 2016 tool for this? > > Regards, > > Baldur From jason at unlimitednet.us Sun Feb 28 02:04:44 2016 From: jason at unlimitednet.us (Jason Canady) Date: Sat, 27 Feb 2016 21:04:44 -0500 Subject: mrtg alternative In-Reply-To: <20160228014231.GA8264@mx.grmbl.net> References: <1456529402.703617259@upnet.mymailsrvr.com> <20160228014231.GA8264@mx.grmbl.net> Message-ID: <6424CCC3-25C2-4EC8-ACBF-F2A312BD8267@unlimitednet.us> A friend was just showing me grafana this morning. I use rtg for a lot of bandwidth data / graphs, but I also have observium for a lot of extra stuff. Kicked cacti to the curb a long time ago. rtg is really flexible, but the graphing isn't pretty. Sent from my iPhone > On Feb 27, 2016, at 20:42, B wrote: > > Welcome to the future. > Graphite/grafana. > >> On Fri, Feb 26, 2016 at 06:30:02PM -0500, Shawn L wrote: >> >> We use observium. It has most of what you're looking for. Used to use cacti but switched a couple of months ago >> >> >> -----Original Message----- >> From: "Baldur Norddahl" >> Sent: Friday, February 26, 2016 6:18pm >> To: "nanog at nanog.org" >> Subject: mrtg alternative >> >> >> >> Hi >> >> I am currently using MRTG and RRD to make traffic graphs. I am searching >> for more modern alternatives that allows the user to dynamically zoom and >> scroll the timeline. >> >> Bonus points if the user can customize the graphs directly in the >> webbrowse. For example he might be able to add or remove individual peers >> from the graph by simply clicking a checkbox. >> >> What is the 2016 tool for this? >> >> Regards, >> >> Baldur From joelja at bogus.com Sun Feb 28 03:10:44 2016 From: joelja at bogus.com (joel jaeggli) Date: Sat, 27 Feb 2016 19:10:44 -0800 Subject: Sprint Wireless DNS server not resolving ietf.org In-Reply-To: References: Message-ID: On 2/26/16 5:42 PM, Yang Yu wrote: > ietf.org and its subdomains such as tools.ietf.org are not accessible > on Sprint 3G/LTE (DNS timeout). From what I gathered this is affecting > Sprint wireless customers nationwide. I created a DNS measurement on > ripe atlas and no signs of other carriers experiencing the same issue. ietf.org has physically diverse secondaries so it strikes me as unlikely that this problem is outside sprint ietf.org. 86400 IN NS ns0.amsl.com. ietf.org. 86400 IN NS ns1.ams1.afilias-nst.info. ietf.org. 86400 IN NS ns1.mia1.afilias-nst.info. ietf.org. 86400 IN NS ns1.sea1.afilias-nst.info. ietf.org. 86400 IN NS ns1.hkg1.afilias-nst.info. ietf.org. 86400 IN NS ns1.yyz1.afilias-nst.info. > Emailed Sprint NOC and opened a ticket via support channel, got no > update. Is there someone from Sprint Wireless on this list? > > DNS servers > 68.28.169.132 > 68.28.168.132 > > Thanks. > > > Yang > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From amekkaoui at mektel.ca Sun Feb 28 04:41:20 2016 From: amekkaoui at mektel.ca (K MEKKAOUI) Date: Sat, 27 Feb 2016 23:41:20 -0500 Subject: DOS Attack Message-ID: <00ab01d171e2$463a2ba0$d2ae82e0$@ca> Hi Do you know about a DOS attack protection provider that you can recommend to me please? Thank you KARIM M. From peter.phaal at gmail.com Sat Feb 27 23:20:21 2016 From: peter.phaal at gmail.com (Peter Phaal) Date: Sat, 27 Feb 2016 15:20:21 -0800 Subject: mrtg alternative In-Reply-To: References: Message-ID: InfluxDB + Grafana are a modern alternative from the DevOps space: http://lkhill.com/using-influxdb-grafana-to-display-network-statistics/ On Fri, Feb 26, 2016 at 3:18 PM, Baldur Norddahl wrote: > Hi > > I am currently using MRTG and RRD to make traffic graphs. I am searching > for more modern alternatives that allows the user to dynamically zoom and > scroll the timeline. > > Bonus points if the user can customize the graphs directly in the > webbrowse. For example he might be able to add or remove individual peers > from the graph by simply clicking a checkbox. > > What is the 2016 tool for this? > > Regards, > > Baldur From ralvarado at anycast.cl Sat Feb 27 23:27:55 2016 From: ralvarado at anycast.cl (=?UTF-8?B?Um9iZXJ0byBBbHZhcmFkbw==?=) Date: Sat, 27 Feb 2016 20:27:55 -0300 Subject: mrtg alternative In-Reply-To: References: Message-ID: Zabbix works for me > On 27-02-2016, at 18:12, Rafael Ganascim wrote: > > I like cacti: > > http://www.cacti.net > > > > 2016-02-26 20:18 GMT-03:00 Baldur Norddahl : > >> Hi >> >> I am currently using MRTG and RRD to make traffic graphs. I am searching >> for more modern alternatives that allows the user to dynamically zoom and >> scroll the timeline. >> >> Bonus points if the user can customize the graphs directly in the >> webbrowse. For example he might be able to add or remove individual peers >> from the graph by simply clicking a checkbox. >> >> What is the 2016 tool for this? >> >> Regards, >> >> Baldur >> From raymond.beaudoin at icarustech.com Sun Feb 28 03:45:37 2016 From: raymond.beaudoin at icarustech.com (Raymond Beaudoin) Date: Sat, 27 Feb 2016 21:45:37 -0600 Subject: SoftLayer DAL05/DAL09 Public Network Issues Message-ID: Has anyone else experienced intermittent packet loss out of SoftLayer's DAL05/DAL09 facilities this evening? From frnkblk at iname.com Sun Feb 28 04:45:38 2016 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 27 Feb 2016 22:45:38 -0600 Subject: Southwest Airlines captive portal In-Reply-To: References: <000a01d1718c$686eff80$394cfe80$@iname.com> <2FD50E6D13594B4C93B743BFCF9F52843D0D604D@EXCH01.sb.local> Message-ID: <001701d171e2$df9ef820$9edce860$@iname.com> I was MITMed, but not maliciously, but by Southwest Airline?s system (which uses Row44). The site doesn?t have to be pinned for a browser to throw up a warning about the SSL certificate not matching the URL. I did connect with an SWA employee. Frank From: Paras Jha [mailto:paras at protrafsolutions.com] Sent: Saturday, February 27, 2016 5:09 PM To: Damien Burke Cc: Frank Bulk ; nanog at nanog.org Subject: Re: Southwest Airlines captive portal You got MITM'd On Sat, Feb 27, 2016 at 1:57 PM, Damien Burke > wrote: You should change your paypal password. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org ] On Behalf Of Frank Bulk Sent: Saturday, February 27, 2016 10:27 AM To: nanog at nanog.org Subject: Southwest Airlines captive portal Anyone from Southwest Airlines on this list? On a recent flight I discovered I couldn't complete payment through PayPal because my web browsers properly noticed that the Southwest Airlines SSL certificate that the captive portal was giving for PayPal didn't match up. =) I had to create an exception for PayPal just to complete payment. Frank From frnkblk at iname.com Sun Feb 28 04:49:36 2016 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 27 Feb 2016 22:49:36 -0600 Subject: DOS Attack In-Reply-To: <00ab01d171e2$463a2ba0$d2ae82e0$@ca> References: <00ab01d171e2$463a2ba0$d2ae82e0$@ca> Message-ID: <001c01d171e3$6d7787c0$48669740$@iname.com> Here are some threads: http://markmail.org/message/4hkuymimt54snpyi http://markmail.org/message/qc67dfw2zi224ciu http://markmail.org/message/2pqnaoru5gvxwyn5 Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K MEKKAOUI Sent: Saturday, February 27, 2016 10:41 PM To: 'NANOG' Subject: DOS Attack Hi Do you know about a DOS attack protection provider that you can recommend to me please? Thank you KARIM M. From mark.tinka at seacom.mu Sun Feb 28 06:11:19 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 28 Feb 2016 08:11:19 +0200 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> Message-ID: <48cce2c5-ad60-b888-cd78-d9baad30da7f@seacom.mu> On 2/Feb/16 23:03, David Bass wrote: > Looking to see what others are using out there as an alternative to a Cisco ME3600X? Also, what other vendors out there are playing in this space? > > Need a full MPLS stack. . Cisco ASR920 - an evolution of the ME3600X, cheaper, more featured and simpler to operate. Juniper's ACX5000 is an option, but that Broadcom chipset scares me. Mark. From mark.tinka at seacom.mu Sun Feb 28 06:13:41 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 28 Feb 2016 08:13:41 +0200 Subject: Low density Juniper (or alternative) Edge In-Reply-To: <56B1B32E.4030609@foobar.org> References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <56B1B32E.4030609@foobar.org> Message-ID: <0a03a53f-b7c1-52e0-800f-9bce6f87ca08@seacom.mu> On 3/Feb/16 09:58, Nick Hilliard wrote: > Typically the features that fall by the wayside first are: reasonable > port buffers, qos knobs and decent lag/ecmp hashing support for mpls > packets. Cisco, in general, are suffering here, i.e., QoS on LAG's. IOS, IOS XE and IOS XR suffer massively. We find that Junos does a better job here. Mark. From mark.tinka at seacom.mu Sun Feb 28 08:54:37 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 28 Feb 2016 10:54:37 +0200 Subject: Low density Juniper (or alternative) Edge In-Reply-To: References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com> <6441f7bd68304968afd3dd7fefcac0fa@exch2013-1.hq.nac.net> <87D4D4CF-59C7-48CB-AFC3-3BEADB53C8CF@gmail.com> Message-ID: <0fce4fb5-279a-0983-0922-9ed56a974e76@seacom.mu> On 6/Feb/16 23:41, Josh Reynolds wrote: > Newer, more expensive, more bugs. 4500 is cheap on the secondary market. The EX4600 is actually just a shy cheaper than the EX4550. We are looking at it not because the EX4550 is a bad box, but because Juniper are focusing development on the EX4600 instead (much like Cisco are doing between the ME3600X and ASR920). You lose 8x ports on the EX4600, though, if coming from the EX4550. May or may not be an issue for you. I wouldn't look at the EX4500. Too big and old now. Mark. From mark.tinka at seacom.mu Sun Feb 28 09:11:02 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 28 Feb 2016 11:11:02 +0200 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: References: Message-ID: <9ad6d4c9-e225-95c6-2fc1-f5e4a8d497b3@seacom.mu> On 18/Feb/16 15:45, Colton Conor wrote: > I would like opinions of the differences between these two platforms if > possible. > > I was going to buy a used Juniper MX960 Router MX960-PREMIUM2-AC-ECM with > 2 x RE-S-1800X4-16G and 3 x SCBE-MX-S. Then I was going to load this up > with a couple of older DPCE-R-4XGE-XFP 4x10GE DPC Enhanced cards. > > Now Cisco has offered me a new ASR9010 with dual ASR9K Route Switch > Processor with 440G/slot Fabric and 6GB, and two 4X10GE / 16X1G Combo > Linecard, Packet Transport Optimized for about the same price as the used > Juniper. The only catch is the Cisco's support and warranty looks > very expensive per year, but that's hard to compare since a used Juniper > has zero support and warranty included. If DPC's are your only option on the MX960, then the ASR9010 will be a better option with those line cards. If you are able to run the newer MIC/MPC line cards on the Juniper, capabilities will not vary much; but IMHO, the MX960 will have a slight edge over the ASR9010. Mark. From mark.tinka at seacom.mu Sun Feb 28 09:12:01 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 28 Feb 2016 11:12:01 +0200 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> References: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> Message-ID: On 18/Feb/16 15:55, Jason Bothe wrote: > We have both and they?re both great boxes, however it?s sort of embarrassing that the ASR9k still can?t do virtualized routing, ie. logical-systems. Not sure if thats a deal breaker for you but just thought you?d like to beware. We also find OS configurations on the Juniper much easier than the cumbersome XR OS that the Cisco runs. The 9k does however get a huge win with the ability to apply a ?pie? or software patch while staying in service vs requiring a reload. Either way, I don?t think you?ll go wrong. It can be hit & miss with the PIE's and SMU's. We've been in situations where in-service updates (not ISSU) were documented as being hitless, but ooops... Mark. From mark.tinka at seacom.mu Sun Feb 28 09:13:02 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 28 Feb 2016 11:13:02 +0200 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: References: <5566DE15-D4B9-437F-A348-305CC46E3DFF@rice.edu> Message-ID: <6a43210c-f2dc-e421-7036-a06c5a164f7c@seacom.mu> On 18/Feb/16 15:59, Josh Reynolds wrote: > With GRES, can't you simply set the master RE as backup, apply firmware, > then switch back to master and upgrade the backup RE? Not always. Multicast, for example, tends to not survive upgrades in GRES conditions as a matter of protocol. Mark. From mark.tinka at seacom.mu Sun Feb 28 10:20:40 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 28 Feb 2016 12:20:40 +0200 Subject: Cisco ASR9010 vs Juniper MX960 In-Reply-To: References: Message-ID: <19b9b56c-8036-e54e-6915-2b19a17a031a@seacom.mu> On 18/Feb/16 16:46, Saku Ytti wrote: > If I could get classicIOS with commit and RPL, I'd run that rather > than XR right now. +1. Mark. From guillaume at ironie.org Sun Feb 28 10:38:28 2016 From: guillaume at ironie.org (Guillaume Tournat) Date: Sun, 28 Feb 2016 11:38:28 +0100 Subject: mrtg alternative In-Reply-To: References: Message-ID: <2645FE41-C517-40B2-B8BE-4A4A84D00E7E@ironie.org> Zabbix for monitoring/graphing/alerting Can be used for maps and SLA measurements too > Le 28 f?vr. 2016 ? 00:27, Roberto Alvarado a ?crit : > > Zabbix works for me > > > >> On 27-02-2016, at 18:12, Rafael Ganascim wrote: >> >> I like cacti: >> >> http://www.cacti.net >> >> >> >> 2016-02-26 20:18 GMT-03:00 Baldur Norddahl : >> >>> Hi >>> >>> I am currently using MRTG and RRD to make traffic graphs. I am searching >>> for more modern alternatives that allows the user to dynamically zoom and >>> scroll the timeline. >>> >>> Bonus points if the user can customize the graphs directly in the >>> webbrowse. For example he might be able to add or remove individual peers >>> from the graph by simply clicking a checkbox. >>> >>> What is the 2016 tool for this? >>> >>> Regards, >>> >>> Baldur >>> From JJaritsch at anexia-it.com Sun Feb 28 10:44:41 2016 From: JJaritsch at anexia-it.com (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Sun, 28 Feb 2016 10:44:41 +0000 Subject: mrtg alternative In-Reply-To: <2645FE41-C517-40B2-B8BE-4A4A84D00E7E@ironie.org> References: , <2645FE41-C517-40B2-B8BE-4A4A84D00E7E@ironie.org> Message-ID: <2fba4f05383b41ecbc1f6fadccd6302e@anx-i-dag02.anx.local> PRTG since years ... And smokeping for special things ... Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Original Message----- From: Guillaume Tournat [guillaume at ironie.org] Received: Sonntag, 28 Feb. 2016, 11:39 To: Roberto Alvarado [ralvarado at anycast.cl]; nanog at nanog.org [nanog at nanog.org] Subject: Re: mrtg alternative Zabbix for monitoring/graphing/alerting Can be used for maps and SLA measurements too > Le 28 f?vr. 2016 ? 00:27, Roberto Alvarado a ?crit : > > Zabbix works for me > > > >> On 27-02-2016, at 18:12, Rafael Ganascim wrote: >> >> I like cacti: >> >> http://www.cacti.net >> >> >> >> 2016-02-26 20:18 GMT-03:00 Baldur Norddahl : >> >>> Hi >>> >>> I am currently using MRTG and RRD to make traffic graphs. I am searching >>> for more modern alternatives that allows the user to dynamically zoom and >>> scroll the timeline. >>> >>> Bonus points if the user can customize the graphs directly in the >>> webbrowse. For example he might be able to add or remove individual peers >>> from the graph by simply clicking a checkbox. >>> >>> What is the 2016 tool for this? >>> >>> Regards, >>> >>> Baldur >>> From mark.tinka at seacom.mu Sun Feb 28 10:51:33 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 28 Feb 2016 12:51:33 +0200 Subject: BGP MVPN RFC6513, Section 10 In-Reply-To: References: Message-ID: On 26/Feb/16 11:33, Yann Lejeune wrote: > > It's up to you to choose what mode you want to use: > - spt-only: is quite "simple". We only have (s,g) in the core. To validate > an os, it's faster. > - rpt-spt. We have both (*,g) and (s,g) in the core. the validation is more > complex, the protocol is more dynamic... I've ran both modes, and found SPT-only mode to be a fair compromise between speed and scale. When operating SPT-only modes, we did not witness a noticeable difference in channel-changing times. In SPT-only mode, the (S,G) state is already present on the Receiver PE router even though there is no downstream interest for that state. So when an IGMP Join request comes into the router, it does not have to travel the RPT tree like it would if you ran RPT-SPT mode (which is traditional Multicast). In our case, we had Multicast probes connected to every Receiver PE router to track performance for each channel. So if you have that, you're going to need all the channels present on the router anyway, even though downstream interest is not present. In this case, avoiding the extra steps associated with RPT-SPT mode is what compelled us to run SPT-only mode. But as Yann has mentioned, even in SPT-only mode, the Type 6 routes will exit in the router, but won't really be used. Type 5 routes are more important when operating in SPT-only mode, and those are always present in such a state. My next NG-MVPN operation will be SSM-based, so this should be simpler still. Mark. From job at instituut.net Sun Feb 28 11:01:46 2016 From: job at instituut.net (Job Snijders) Date: Sun, 28 Feb 2016 12:01:46 +0100 Subject: mrtg alternative In-Reply-To: References: Message-ID: <20160228110146.GD90577@22.rev.meerval.net> On Sat, Feb 27, 2016 at 12:18:16AM +0100, Baldur Norddahl wrote: > I am currently using MRTG and RRD to make traffic graphs. I am > searching for more modern alternatives that allows the user to > dynamically zoom and scroll the timeline. > > Bonus points if the user can customize the graphs directly in the > webbrowse. For example he might be able to add or remove individual peers > from the graph by simply clicking a checkbox. You might want to check out http://www.librenms.org/ Kind regards, Job From ramy.ihashish at gmail.com Sun Feb 28 13:10:10 2016 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Sun, 28 Feb 2016 15:10:10 +0200 Subject: Media converter vendors - GFP/EoSDH Message-ID: Hello there, Any recommendations for Ethernet-SDH/SONET media converter vendors? Thanks, Ramy From clayton at MNSi.Net Sun Feb 28 14:50:01 2016 From: clayton at MNSi.Net (Clayton Zekelman) Date: Sun, 28 Feb 2016 09:50:01 -0500 Subject: Media converter vendors - GFP/EoSDH In-Reply-To: References: Message-ID: <1456671004_353372@surgemail.mnsi.net> What speeds SONET are you looking to map your Ethernet on to? RAD makes some products. http://www.rad.com/10/Ethernet-over-SDH-SONET-ADM/2833/ We use BIT Systems 2.5G Muxponders to map 2xGE to OC48. Works well. http://www.btisystems.com/Portals/0/Documents/Data-Sheets/Muxponder-Family-DS0022.pdf We also have some ADTRAN Opti-6100 units using Ethernet mappers. At 08:10 AM 28/02/2016, Ramy Hashish wrote: >Hello there, > >Any recommendations for Ethernet-SDH/SONET media converter vendors? > >Thanks, > >Ramy -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From mark.tinka at seacom.mu Sun Feb 28 15:49:26 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 28 Feb 2016 17:49:26 +0200 Subject: Media converter vendors - GFP/EoSDH In-Reply-To: References: Message-ID: <71b738ee-c5de-d598-f956-6c274367ea75@seacom.mu> On 28/Feb/16 15:10, Ramy Hashish wrote: > Hello there, > > Any recommendations for Ethernet-SDH/SONET media converter vendors? Huawei, Tejas, BTI, ECI, Tejas, all come to mind on the lower price scale. Mark. From swanjonson at gmail.com Sun Feb 28 17:54:03 2016 From: swanjonson at gmail.com (Jon Swanson) Date: Sun, 28 Feb 2016 12:54:03 -0500 Subject: Media converter vendors - GFP/EoSDH In-Reply-To: <71b738ee-c5de-d598-f956-6c274367ea75@seacom.mu> References: <71b738ee-c5de-d598-f956-6c274367ea75@seacom.mu> Message-ID: MRV makes some nicely priced options. I have used them for years with no issues. On Sunday, February 28, 2016, Mark Tinka wrote: > > > On 28/Feb/16 15:10, Ramy Hashish wrote: > > > Hello there, > > > > Any recommendations for Ethernet-SDH/SONET media converter vendors? > > Huawei, Tejas, BTI, ECI, Tejas, all come to mind on the lower price scale. > > Mark. > From frnkblk at iname.com Sun Feb 28 18:25:08 2016 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 28 Feb 2016 12:25:08 -0600 Subject: Packet loss on XO's network Message-ID: <003201d17255$5b57ea90$1207bfb0$@iname.com> Since ~11:08 am Central our monitoring system has been reporting intermittent HTTPv6 timeouts to www.sprint.net, www.qwest.com , enterprise.com, and enterprise.ca. It goes bad for a while and then clears. Using mtr, these all have XO's network in common, and the packet loss to the endpoint sustains over 40%. Seems to be between 2610:18:18b:c000::11 and mcr1.minneapolis-mn.us.xo.net [2610:18::30b8] Frank To enterprise.com: Host Loss% Snt Last Avg Best Wrst StDev 1. router-core.mtcnet.net 0.0% 929 0.3 0.6 0.2 37.6 2.5 2. sxct.sxcy.mtcnet.net 0.0% 929 0.3 0.3 0.2 11.2 0.6 3. v6-premier.sxcy-mlx.fbnt.netins.net 0.0% 929 1.6 1.5 1.5 12.6 0.9 4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net 52.4% 929 8.1 8.0 7.8 10.5 0.3 5. v6-ins-dc1-te-7-4.desm.netins.net 52.4% 929 7.9 8.0 7.6 10.9 0.5 6. 2610:18:18b:c000::11 0.0% 929 13.9 13.2 12.8 46.8 3.0 7. mcr1.minneapolis-mn.us.xo.net 50.3% 929 54.7 71.2 54.6 86.7 7.7 8. 2610:18::5802 50.8% 929 55.7 72.8 54.6 84.3 7.8 9. 2610:18::5202 51.4% 929 54.4 72.9 54.4 85.0 8.0 2610:18::5804 10. 2610:18::2070 52.3% 928 54.4 71.5 54.4 90.7 7.9 2610:18::5304 11. 2600:803:2::9 41.6% 928 54.5 56.8 47.8 96.7 3.4 2610:18::5303 12. 2610:18::5200 96.0% 928 54.5 55.8 54.4 75.6 3.7 13. 2610:18::5202 96.0% 928 55.5 56.6 54.6 58.5 1.2 14. 2610:18::2070 96.0% 928 61.8 55.1 54.6 61.8 1.2 15. 2600:803:2::9 95.9% 928 45.0 45.1 45.0 48.0 0.5 16. ??? To www.sprint.net: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router-core.mtcnet.net 0.0% 846 0.4 0.8 0.2 91.5 3.9 2. sxct.sxcy.mtcnet.net 0.0% 846 0.9 0.3 0.2 10.3 0.4 3. v6-premier.sxcy-mlx.fbnt.netins.net 0.0% 846 1.5 1.6 1.5 12.0 0.8 4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net 55.4% 846 7.9 8.1 7.8 14.8 0.4 5. v6-ins-dc1-te-7-4.desm.netins.net 54.3% 846 7.8 8.2 7.6 19.2 1.0 6. 2610:18:18b:c000::11 0.0% 846 12.9 14.0 12.8 73.0 5.4 7. mcr1.minneapolis-mn.us.xo.net 49.8% 846 54.7 70.0 54.6 100.1 8.1 8. 2610:18::5802 47.4% 846 58.3 71.9 54.6 82.9 8.2 9. 2610:18::5202 45.0% 846 54.4 72.1 54.4 83.3 8.4 2610:18::5804 10. 2610:18::2070 50.6% 845 54.4 70.4 54.3 88.8 8.1 2610:18::5304 11. sl-st31-ash-te0-15-2-0.v6.sprintlink.net 43.4% 845 57.5 59.1 53.1 80.5 2.3 2610:18::5303 12. sl-crs3-dc-be13.v6.sprintlink.net 46.7% 845 54.6 64.7 54.4 69.1 3.7 2610:18::5200 13. sl-crs1-ffx-be2.v6.sprintlink.net 44.1% 844 55.0 71.8 55.0 79.7 5.3 2610:18::5202 14. sl-crs1-orl-bu-1.v6.sprintlink.net 41.7% 844 54.9 75.7 54.7 96.3 7.4 2610:18::2070 15. sl-lkdstr2-p1-0.v6.sprintlink.net 41.0% 844 46.4 73.5 45.8 81.7 7.0 sl-st31-ash-te0-15-2-0.v6.sprintlink.net 16. www.sprint.net 43.1% 844 54.5 74.6 53.5 81.6 5.0 sl-crs3-dc-be13.v6.sprintlink.net From frnkblk at iname.com Sun Feb 28 19:47:45 2016 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 28 Feb 2016 13:47:45 -0600 Subject: Packet loss on XO's network In-Reply-To: <003201d17255$5b57ea90$1207bfb0$@iname.com> References: <003201d17255$5b57ea90$1207bfb0$@iname.com> Message-ID: <004801d17260$e600bd10$b2023730$@iname.com> XO contacted me offline. Things have bene stable since ~12:15 pm Central. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk Sent: Sunday, February 28, 2016 12:25 PM To: nanog at nanog.org Subject: Packet loss on XO's network Since ~11:08 am Central our monitoring system has been reporting intermittent HTTPv6 timeouts to www.sprint.net, www.qwest.com , enterprise.com, and enterprise.ca. It goes bad for a while and then clears. Using mtr, these all have XO's network in common, and the packet loss to the endpoint sustains over 40%. Seems to be between 2610:18:18b:c000::11 and mcr1.minneapolis-mn.us.xo.net [2610:18::30b8] Frank To enterprise.com: Host Loss% Snt Last Avg Best Wrst StDev 1. router-core.mtcnet.net 0.0% 929 0.3 0.6 0.2 37.6 2.5 2. sxct.sxcy.mtcnet.net 0.0% 929 0.3 0.3 0.2 11.2 0.6 3. v6-premier.sxcy-mlx.fbnt.netins.net 0.0% 929 1.6 1.5 1.5 12.6 0.9 4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net 52.4% 929 8.1 8.0 7.8 10.5 0.3 5. v6-ins-dc1-te-7-4.desm.netins.net 52.4% 929 7.9 8.0 7.6 10.9 0.5 6. 2610:18:18b:c000::11 0.0% 929 13.9 13.2 12.8 46.8 3.0 7. mcr1.minneapolis-mn.us.xo.net 50.3% 929 54.7 71.2 54.6 86.7 7.7 8. 2610:18::5802 50.8% 929 55.7 72.8 54.6 84.3 7.8 9. 2610:18::5202 51.4% 929 54.4 72.9 54.4 85.0 8.0 2610:18::5804 10. 2610:18::2070 52.3% 928 54.4 71.5 54.4 90.7 7.9 2610:18::5304 11. 2600:803:2::9 41.6% 928 54.5 56.8 47.8 96.7 3.4 2610:18::5303 12. 2610:18::5200 96.0% 928 54.5 55.8 54.4 75.6 3.7 13. 2610:18::5202 96.0% 928 55.5 56.6 54.6 58.5 1.2 14. 2610:18::2070 96.0% 928 61.8 55.1 54.6 61.8 1.2 15. 2600:803:2::9 95.9% 928 45.0 45.1 45.0 48.0 0.5 16. ??? To www.sprint.net: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router-core.mtcnet.net 0.0% 846 0.4 0.8 0.2 91.5 3.9 2. sxct.sxcy.mtcnet.net 0.0% 846 0.9 0.3 0.2 10.3 0.4 3. v6-premier.sxcy-mlx.fbnt.netins.net 0.0% 846 1.5 1.6 1.5 12.0 0.8 4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net 55.4% 846 7.9 8.1 7.8 14.8 0.4 5. v6-ins-dc1-te-7-4.desm.netins.net 54.3% 846 7.8 8.2 7.6 19.2 1.0 6. 2610:18:18b:c000::11 0.0% 846 12.9 14.0 12.8 73.0 5.4 7. mcr1.minneapolis-mn.us.xo.net 49.8% 846 54.7 70.0 54.6 100.1 8.1 8. 2610:18::5802 47.4% 846 58.3 71.9 54.6 82.9 8.2 9. 2610:18::5202 45.0% 846 54.4 72.1 54.4 83.3 8.4 2610:18::5804 10. 2610:18::2070 50.6% 845 54.4 70.4 54.3 88.8 8.1 2610:18::5304 11. sl-st31-ash-te0-15-2-0.v6.sprintlink.net 43.4% 845 57.5 59.1 53.1 80.5 2.3 2610:18::5303 12. sl-crs3-dc-be13.v6.sprintlink.net 46.7% 845 54.6 64.7 54.4 69.1 3.7 2610:18::5200 13. sl-crs1-ffx-be2.v6.sprintlink.net 44.1% 844 55.0 71.8 55.0 79.7 5.3 2610:18::5202 14. sl-crs1-orl-bu-1.v6.sprintlink.net 41.7% 844 54.9 75.7 54.7 96.3 7.4 2610:18::2070 15. sl-lkdstr2-p1-0.v6.sprintlink.net 41.0% 844 46.4 73.5 45.8 81.7 7.0 sl-st31-ash-te0-15-2-0.v6.sprintlink.net 16. www.sprint.net 43.1% 844 54.5 74.6 53.5 81.6 5.0 sl-crs3-dc-be13.v6.sprintlink.net From todd.crane at n5tech.com Sun Feb 28 20:06:34 2016 From: todd.crane at n5tech.com (Todd Crane) Date: Sun, 28 Feb 2016 13:06:34 -0700 Subject: sFlow vs netFlow/IPFIX Message-ID: This maybe outside the scope of this list but I was wondering if anybody had advice or lessons learned on the whole sFlow vs netFlow debate. We are looking at using it for billing and influencing our sdn flows. It seems like everything I have found is biased (articles by companies who have commercial offerings for the "better" protocol) Todd Crane From sperreault at jive.com Sun Feb 28 21:21:07 2016 From: sperreault at jive.com (Simon Perreault) Date: Sun, 28 Feb 2016 16:21:07 -0500 Subject: mrtg alternative In-Reply-To: <20160228014231.GA8264@mx.grmbl.net> References: <1456529402.703617259@upnet.mymailsrvr.com> <20160228014231.GA8264@mx.grmbl.net> Message-ID: <56D364C3.8070209@jive.com> Le 2016-02-27 20:42, B a ?crit : > Graphite/grafana. I strongly recommend Graphite to all my competitors! :) Simon From frnkblk at iname.com Sun Feb 28 22:33:38 2016 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 28 Feb 2016 16:33:38 -0600 Subject: Packet loss on XO's network In-Reply-To: <419a71d8e35e47679e47221191fa44b1@TXPLANEXCH102.corp.inthosts.net> References: <003201d17255$5b57ea90$1207bfb0$@iname.com> <419a71d8e35e47679e47221191fa44b1@TXPLANEXCH102.corp.inthosts.net> Message-ID: <006201d17278$1236d380$36a47a80$@iname.com> Terri, Except the initial traces show that hop 6 is clean. If the problem really started at hop 4 then the issue would likely show up in hop 6 (unless there was a hashing on the return path based on the far end router's source IP that caused just some traffic to be thrown away). Hop 4 and 5 always have packet loss - I believe it's due to ICMPv6 rate limiters protecting their CPU: Frank From: Fullenkamp, Terri L [mailto:terri.l.fullenkamp at xo.com] Sent: Sunday, February 28, 2016 2:59 PM To: Frank Bulk ; nanog at nanog.org Cc: # SUP - NCC Level 1 Data Subject: RE: Packet loss on XO's network >From the traces provided the packet loss starts accruing at hop 4 and 5 and that is before it gets into the XO network, If you are a customer of XO please contact care @ 888-575-6398 with any other questions Trace from hop 6 tfullenk at MCR2.Minneapolis-MN > traceroute enterprise.com traceroute6 to enterprise.com (2620:103:e049:31a7::b4) from 2610:18::30bc, 64 hops max, 12 byte packets 1 mcr1.minneapolis-mn.us.xo.net (2610:18::30b8) 29.325 ms 28.950 ms 31.327 ms MPLS Label=318081 CoS=0 TTL=1 S=0 MPLS Label=2 CoS=0 TTL=1 S=1 2 2610:18::5802 (2610:18::5802) 32.680 ms 29.684 ms 32.643 ms MPLS Label=19268 CoS=0 TTL=255 S=0 MPLS Label=2 CoS=0 TTL=255 S=1 3 2610:18::5804 (2610:18::5804) 30.629 ms 33.384 ms 81.985 ms MPLS Label=757571 CoS=0 TTL=1 S=0 MPLS Label=2 CoS=0 TTL=3 S=1 4 2610:18::5803 (2610:18::5803) 65.305 ms 28.876 ms 39.141 ms MPLS Label=419427 CoS=0 TTL=1 S=0 MPLS Label=2 CoS=0 TTL=4 S=1 5 2610:18::5201 (2610:18::5201) 36.762 ms 28.776 ms 28.718 ms MPLS Label=694064 CoS=0 TTL=1 S=0 MPLS Label=2 CoS=0 TTL=5 S=1 6 2610:18::2070 (2610:18::2070) 29.487 ms 28.920 ms 42.500 ms 7 2610:18:16::32 (2610:18:16::32) 28.619 ms 2600:803:2::9 (2600:803:2::9) 28.706 ms 28.692 ms 8 2600:807:21f::22 (2600:807:21f::22) 47.997 ms 48.042 ms 50.504 ms 9 2600:807:21f::22 (2600:807:21f::22) 48.026 ms 48.084 ms 49.172 ms Terri Fullenkamp NCC Specialist V / IP Data / XO Communications / 2020 Westport Center Drive, Maryland Heights, MO 63146 T: 866-966-8975 F: 314-787- 7799 E: terri.l.fullenkamp at xo.com From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, February 28, 2016 12:25 To: nanog at nanog.org Subject: Packet loss on XO's network Since ~11:08 am Central our monitoring system has been reporting intermittent HTTPv6 timeouts to www.sprint.net , www.qwest.com , enterprise.com, and enterprise.ca. It goes bad for a while and then clears. Using mtr, these all have XO's network in common, and the packet loss to the endpoint sustains over 40%. Seems to be between 2610:18:18b:c000::11 and mcr1.minneapolis-mn.us.xo.net [2610:18::30b8] Frank To enterprise.com: Host Loss% Snt Last Avg Best Wrst StDev 1. router-core.mtcnet.net 0.0% 929 0.3 0.6 0.2 37.6 2.5 2. sxct.sxcy.mtcnet.net 0.0% 929 0.3 0.3 0.2 11.2 0.6 3. v6-premier.sxcy-mlx.fbnt.netins.net 0.0% 929 1.6 1.5 1.5 12.6 0.9 4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net 52.4% 929 8.1 8.0 7.8 10.5 0.3 5. v6-ins-dc1-te-7-4.desm.netins.net 52.4% 929 7.9 8.0 7.6 10.9 0.5 6. 2610:18:18b:c000::11 0.0% 929 13.9 13.2 12.8 46.8 3.0 7. mcr1.minneapolis-mn.us.xo.net 50.3% 929 54.7 71.2 54.6 86.7 7.7 8. 2610:18::5802 50.8% 929 55.7 72.8 54.6 84.3 7.8 9. 2610:18::5202 51.4% 929 54.4 72.9 54.4 85.0 8.0 2610:18::5804 10. 2610:18::2070 52.3% 928 54.4 71.5 54.4 90.7 7.9 2610:18::5304 11. 2600:803:2::9 41.6% 928 54.5 56.8 47.8 96.7 3.4 2610:18::5303 12. 2610:18::5200 96.0% 928 54.5 55.8 54.4 75.6 3.7 13. 2610:18::5202 96.0% 928 55.5 56.6 54.6 58.5 1.2 14. 2610:18::2070 96.0% 928 61.8 55.1 54.6 61.8 1.2 15. 2600:803:2::9 95.9% 928 45.0 45.1 45.0 48.0 0.5 16. ??? To www.sprint.net : Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router-core.mtcnet.net 0.0% 846 0.4 0.8 0.2 91.5 3.9 2. sxct.sxcy.mtcnet.net 0.0% 846 0.9 0.3 0.2 10.3 0.4 3. v6-premier.sxcy-mlx.fbnt.netins.net 0.0% 846 1.5 1.6 1.5 12.0 0.8 4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net 55.4% 846 7.9 8.1 7.8 14.8 0.4 5. v6-ins-dc1-te-7-4.desm.netins.net 54.3% 846 7.8 8.2 7.6 19.2 1.0 6. 2610:18:18b:c000::11 0.0% 846 12.9 14.0 12.8 73.0 5.4 7. mcr1.minneapolis-mn.us.xo.net 49.8% 846 54.7 70.0 54.6 100.1 8.1 8. 2610:18::5802 47.4% 846 58.3 71.9 54.6 82.9 8.2 9. 2610:18::5202 45.0% 846 54.4 72.1 54.4 83.3 8.4 2610:18::5804 10. 2610:18::2070 50.6% 845 54.4 70.4 54.3 88.8 8.1 2610:18::5304 11. sl-st31-ash-te0-15-2-0.v6.sprintlink.net 43.4% 845 57.5 59.1 53.1 80.5 2.3 2610:18::5303 12. sl-crs3-dc-be13.v6.sprintlink.net 46.7% 845 54.6 64.7 54.4 69.1 3.7 2610:18::5200 13. sl-crs1-ffx-be2.v6.sprintlink.net 44.1% 844 55.0 71.8 55.0 79.7 5.3 2610:18::5202 14. sl-crs1-orl-bu-1.v6.sprintlink.net 41.7% 844 54.9 75.7 54.7 96.3 7.4 2610:18::2070 15. sl-lkdstr2-p1-0.v6.sprintlink.net 41.0% 844 46.4 73.5 45.8 81.7 7.0 sl-st31-ash-te0-15-2-0.v6.sprintlink.net 16. www.sprint.net 43.1% 844 54.5 74.6 53.5 81.6 5.0 sl-crs3-dc-be13.v6.sprintlink.net From nick at foobar.org Sun Feb 28 22:40:47 2016 From: nick at foobar.org (Nick Hilliard) Date: Sun, 28 Feb 2016 22:40:47 +0000 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: Message-ID: <56D3776F.7050508@foobar.org> Todd Crane wrote: > This maybe outside the scope of this list but I was wondering if > anybody had advice or lessons learned on the whole sFlow vs netFlow > debate. We are looking at using it for billing and influencing our > sdn flows. It seems like everything I have found is biased (articles > by companies who have commercial offerings for the "better" > protocol) There is a lot of religion floating around about this subject. Netflow was designed to measure flows, and it turned out that the design was robust enough for it to be more-or-less good enough for billing purposes. It's "more or less" because on larger routers, you can't do 1:1 data export and you end up needing to do traffic sampling, at which point you're billing based on realistic estimates rather than exact data. That's fine if your contract with your customer says it's ok. Netflow works by tracking individual flows in the data plane. This is pretty complicated in practice and requires dedicated hardware to handle it at line rate. You generally end up with two packet forwarding engines on a hardware-forwarded router: one to handle the forwarding, and the other to categorise and handle the flow data. This means that netflow is expensive to design, build and run. Sflow is a simple packet header sampling mechanism. The only thing it does is to pick out every 1 in N packets, and to try to figure out where the headers stop and the data begins. The header is then forwarded to the sflow collector, which is where all the smart stuff is done. If your netflow / sflow packet sampling mechanism is accurate and your router is configured appropriate for the quantity of flow data being exported (i.e. it isn't dropping data samples due to overload), then for the most part, there will be no substantial difference between using sflow and sampled netflow (depending on the data flow type), assuming that each protocol provides the data you're looking for. Obviously, if your sampling mechanism is broken or your exporter is overloaded, then both sflow and netflow will produce trash. If you're using unsampled netflow, then netflow will be more accurate, assuming you don't end up overflowing the netflow data export mechanism. Anything which uses sampling - regardless of whether it's for netflow or sflow - needs to be profiled before being pushed into production, because you need to understand the limits of the sampling mechanism. Hardware sampling often doesn't work properly or plateaus off at a certain stage, dropping packets in the process. This can cause unwelcome surprises. Without knowing anything more about your requirements or your choice of equipment, I'd suggest that sflow would probably be a better choice for SDN tuning and probably netflow would be better for billing, but YMMV. Nick From bedard.phil at gmail.com Sun Feb 28 23:15:55 2016 From: bedard.phil at gmail.com (Phil Bedard) Date: Sun, 28 Feb 2016 18:15:55 -0500 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: Message-ID: <56d37fb0.d75b810a.c0636.ffffce24@mx.google.com> What HW are your looking at our are you rolling your own probes? Router/switch HW almost never does both. Netflow/IPFIX puts the flow intelligence in the router, but with that comes more limitations. Sflow typically uses more BW because you are sending headers for each packet. The sflow collector also needs more intelligence since it's doing flow correlation, AS matching, etc. instead of the router doing it. However it is more flexible since adding a new header, like vxlan or NSH is much easier to implement in some analysis SW than router SW. Phil From: Todd Crane Sent: Sunday, February 28, 2016 3:09 PM To: nanog at nanog.org Subject: sFlow vs netFlow/IPFIX This maybe outside the scope of this list but I was wondering if anybody had advice or lessons learned on the whole sFlow vs netFlow debate. We are looking at using it for billing and influencing our sdn flows. It seems like everything I have found is biased (articles by companies who have commercial offerings for the "better" protocol) Todd Crane From baldur.norddahl at gmail.com Sun Feb 28 23:26:53 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 29 Feb 2016 00:26:53 +0100 Subject: sFlow vs netFlow/IPFIX In-Reply-To: <56D3776F.7050508@foobar.org> References: <56D3776F.7050508@foobar.org> Message-ID: On 28 February 2016 at 23:40, Nick Hilliard wrote: > Netflow was designed to measure flows, and it turned out that the design > was robust enough for it to be more-or-less good enough for billing > purposes. It's "more or less" because on larger routers, you can't do > 1:1 data export and you end up needing to do traffic sampling, at which > point you're billing based on realistic estimates rather than exact > data. That's fine if your contract with your customer says it's ok. > Around here they are currently voting on a law that will require unsampled 1:1 netflow on all data in an ISP network with more than 100 users. Then store that data for 1 year, so the police and other parties can request a copy (with a warrant but you are never allowed to tell anyone that they came for the data and the judges will never say no). My routers can apparently actually do 1:1 netflow and the documentation does not state any limits on that. So maybe I am lucky? To the original question: in this country sFlow only is apparently about to become illegal. Regards, Baldur From baldur.norddahl at gmail.com Sun Feb 28 23:28:27 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 29 Feb 2016 00:28:27 +0100 Subject: mrtg alternative In-Reply-To: References: Message-ID: I went with InfluxDB and Grafana. It was exactly what I wanted. Thanks for all the suggestions. Regards, Baldur On 28 February 2016 at 00:20, Peter Phaal wrote: > InfluxDB + Grafana are a modern alternative from the DevOps space: > > http://lkhill.com/using-influxdb-grafana-to-display-network-statistics/ > > On Fri, Feb 26, 2016 at 3:18 PM, Baldur Norddahl > wrote: > > Hi > > > > I am currently using MRTG and RRD to make traffic graphs. I am searching > > for more modern alternatives that allows the user to dynamically zoom and > > scroll the timeline. > > > > Bonus points if the user can customize the graphs directly in the > > webbrowse. For example he might be able to add or remove individual peers > > from the graph by simply clicking a checkbox. > > > > What is the 2016 tool for this? > > > > Regards, > > > > Baldur > From rdobbins at arbor.net Mon Feb 29 02:24:42 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 29 Feb 2016 09:24:42 +0700 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> Message-ID: On 29 Feb 2016, at 6:26, Baldur Norddahl wrote: > Around here they are currently voting on a law that will require unsampled > 1:1 netflow on all data in an ISP network with more than 100 users. That's interesting, given that most larger routers don't support 1:1. ----------------------------------- Roland Dobbins From Valdis.Kletnieks at vt.edu Mon Feb 29 02:41:54 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 28 Feb 2016 21:41:54 -0500 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> Message-ID: <250778.1456713714@turing-police.cc.vt.edu> On Mon, 29 Feb 2016 09:24:42 +0700, "Roland Dobbins" said: > On 29 Feb 2016, at 6:26, Baldur Norddahl wrote: > > > Around here they are currently voting on a law that will require unsampled > > 1:1 netflow on all data in an ISP network with more than 100 users. > > That's interesting, given that most larger routers don't support 1:1. In the war between reality and governmental paranoia, reality usually loses. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ramy.ihashish at gmail.com Mon Feb 29 04:45:45 2016 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 29 Feb 2016 06:45:45 +0200 Subject: Media converter vendors - GFP/EoSDH In-Reply-To: <1456671004_353372@surgemail.mnsi.net> References: <1456671004_353372@surgemail.mnsi.net> Message-ID: Hello Clayton, We are mainly looking for OC3, however OC12 and OC48 support -on multirate ports- will be a plus of course... On Sun, Feb 28, 2016 at 4:50 PM, Clayton Zekelman wrote: > > What speeds SONET are you looking to map your Ethernet on to? > > RAD makes some products. > > http://www.rad.com/10/Ethernet-over-SDH-SONET-ADM/2833/ > > We use BIT Systems 2.5G Muxponders to map 2xGE to OC48. Works well. > > > http://www.btisystems.com/Portals/0/Documents/Data-Sheets/Muxponder-Family-DS0022.pdf > > We also have some ADTRAN Opti-6100 units using Ethernet mappers. > > > > > > At 08:10 AM 28/02/2016, Ramy Hashish wrote: > >> Hello there, >> >> Any recommendations for Ethernet-SDH/SONET media converter vendors? >> >> Thanks, >> >> Ramy >> > > -- > > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 3363 Tecumseh Rd. E > Windsor, Ontario > N8W 1H4 > > tel. 519-985-8410 > fax. 519-985-8409 > From ramy.ihashish at gmail.com Mon Feb 29 04:47:14 2016 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 29 Feb 2016 06:47:14 +0200 Subject: Media converter vendors - GFP/EoSDH In-Reply-To: <71b738ee-c5de-d598-f956-6c274367ea75@seacom.mu> References: <71b738ee-c5de-d598-f956-6c274367ea75@seacom.mu> Message-ID: Hello Mark, Do you know anything about their MEF compliance? which of them is capable of working in carrier-grade large scale environment? Ramy On Sun, Feb 28, 2016 at 5:49 PM, Mark Tinka wrote: > > > On 28/Feb/16 15:10, Ramy Hashish wrote: > > > Hello there, > > > > Any recommendations for Ethernet-SDH/SONET media converter vendors? > > Huawei, Tejas, BTI, ECI, Tejas, all come to mind on the lower price scale. > > Mark. > From pavel.odintsov at gmail.com Mon Feb 29 07:26:16 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 29 Feb 2016 10:26:16 +0300 Subject: sFlow vs netFlow/IPFIX In-Reply-To: <250778.1456713714@turing-police.cc.vt.edu> References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> Message-ID: Hello, folks! I've huge experience for battle sflow vs netflow because in my free DDoS detection toolkit fastnetmon we support both capture methods. You could look at this comparison table: https://github.com/pavel-odintsov/fastnetmon/blob/master/docs/CAPTURE_BACKENDS.md >From my own experience sflow should be selected if you are interested in internal packet payload (for dpi / ddos detection) or you need fast reaction time on some actions (ddos is best example). If you just need to count traffic and you accept pretty long reaction time and not enough accurate traffic bandwidth data you could select netflow. >From hardware point of view almost all brand new switches support sflow free of charge (no additional licenses or modules). But be aware, Cisco do not support this protocol at all (that's pretty weird, really). Also keep in mind sflow implemented in hardware ASIC with small help from CPU and it's pretty fast and suitable for really any traffic bandwidth. I have experience with sflow analytics for 1.5 Tb+ network and it's working really well! For netflow sometimes you need additional modules / software licenses and sometime devices completely haven't support for it. And if you have software devices (for example small SRX routers from Juniper) netflow generation will be pretty expensive from CPU point of view because netflow need pretty big amount of CPU resources for aggregation. On Mon, Feb 29, 2016 at 5:41 AM, wrote: > On Mon, 29 Feb 2016 09:24:42 +0700, "Roland Dobbins" said: >> On 29 Feb 2016, at 6:26, Baldur Norddahl wrote: >> >> > Around here they are currently voting on a law that will require unsampled >> > 1:1 netflow on all data in an ISP network with more than 100 users. >> >> That's interesting, given that most larger routers don't support 1:1. > > In the war between reality and governmental paranoia, reality usually loses. -- Sincerely yours, Pavel Odintsov From freedman at freedman.net Mon Feb 29 07:27:24 2016 From: freedman at freedman.net (Avi Freedman) Date: Mon, 29 Feb 2016 02:27:24 -0500 (EST) Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> Message-ID: <20160229072724.5FC59550C6B43@freedman.net> Re: limits - For Cisco/Juniper it's in the low hundreds of thousands of flows/sec per chipset/linecard for 1:1 NetFlow/IPFIX, I think. Then of course, as has been mentioned, you'll need to be able to send it and receive it to something - and store+query. Avi Freedman CEO, Kentik > On 28 February 2016 at 23:40, Nick Hilliard wrote: > Around here they are currently voting on a law that will require unsampled > 1:1 netflow on all data in an ISP network with more than 100 users. Then > store that data for 1 year, so the police and other parties can request a > copy (with a warrant but you are never allowed to tell anyone that they > came for the data and the judges will never say no). > > My routers can apparently actually do 1:1 netflow and the documentation > does not state any limits on that. So maybe I am lucky? > > To the original question: in this country sFlow only is apparently about to > become illegal. > > Regards, > > Baldur From rdobbins at arbor.net Mon Feb 29 07:32:37 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 29 Feb 2016 14:32:37 +0700 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> Message-ID: <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> On 29 Feb 2016, at 14:26, Pavel Odintsov wrote: > From my own experience sflow should be selected if you are interested > in internal packet payload (for dpi / ddos detection) or you need fast > reaction time on some actions (ddos is best example). This does not match my experience. In particular, the implied canard about flow telemetry being inadequate for timely DDoS detection/classification/traceback grows tiresome, as it's used for that purpose every day, and works quite well. If one is also using an IDMS-type device to mitigate DDoS traffic, the device sees the whole packet, anyways. ----------------------------------- Roland Dobbins From freedman at freedman.net Mon Feb 29 07:38:17 2016 From: freedman at freedman.net (Avi Freedman) Date: Mon, 29 Feb 2016 02:38:17 -0500 (EST) Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: Message-ID: <20160229073817.92B2F550C6B7D@freedman.net> > This maybe outside the scope of this list but I was wondering if anybody had advice or lessons learned on the whole sFlow vs netFlow debate. We are looking at using it for billing and influencing our sdn flows. It seems like everything I have found is biased (articles by companies who have commercial offerings for the "better" protocol) > > Todd Crane Most vendors that take "flow" take both so there tends not to be THAT much religion unless you talk to someone who hates being flooded with 1:1 flow, or debugging broken (usually NetFlow) implementations. In our experience, they both basically work for ops use cases nowadays, for major vendors of routers, and most switches. sFlow gives faster feedback and more accurate (adding things up, * sample rates, closer to SNMP counter data) than most NetFlow/IPFIX implementations. How much varies from slightly to extreme (if you're using Catalysts for NetFlow/IPFIX). My thesis overall re: why sFlow 'just works' a bit better is that it's just so much easier to implement sFlow because there's no need to track flows (hash table or whatever data structure you need). Just grab samples of headers, parse, fill structs, and send. That said, things are hugely less sucky than 10 or even 5 years ago in the NetFlow world, and for the right vendor and box and software it's possible to get NetFlow/IPFIX essentially as accurate. And has been noted, it at least in theory some boxes that do tens to hundreds of gigabits (or low terabits) of traffic support 1:1, which you could in theory do with sFlow as a transport, but I haven't seen a switch or router that does that. Re: 1-1 flow - the boxes supporting that are generally not the biggest purchase-able from Cisco or Juniper, but are used as the big-boy backbone and border routers by a good number of multi-terabit networks, and even some multi-tens-of-terabit networks. Good luck in your flow journeys. Avi Freedman CEO, Kentik From pavel.odintsov at gmail.com Mon Feb 29 07:41:48 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 29 Feb 2016 10:41:48 +0300 Subject: sFlow vs netFlow/IPFIX In-Reply-To: <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> Message-ID: Sorry but I could not understand what issues you've found in sflow. Could you describe they in details? Recently I had speech at RIPE 71 and show pattern of real attack which achieved 6 gbps in first 30 seconds (just check slide 6 here http://www.slideshare.net/pavel_odintsov/ripe71-fastnetmon-open-source-dos-ddos-mitigation). And sflow device could offer 3-4 seconds detection time from this case. But netflow __could__ delay telemetry up to 30 seconds (in case of huge syn/syn-ack flood for example) and you network will experience downtime. But with sflow you could detect and mitigate this attack in seconds. Is it make sense? On Mon, Feb 29, 2016 at 10:32 AM, Roland Dobbins wrote: > On 29 Feb 2016, at 14:26, Pavel Odintsov wrote: > >> From my own experience sflow should be selected if you are interested in >> internal packet payload (for dpi / ddos detection) or you need fast reaction >> time on some actions (ddos is best example). > > > This does not match my experience. In particular, the implied canard about > flow telemetry being inadequate for timely DDoS > detection/classification/traceback grows tiresome, as it's used for that > purpose every day, and works quite well. > > If one is also using an IDMS-type device to mitigate DDoS traffic, the > device sees the whole packet, anyways. > > ----------------------------------- > Roland Dobbins -- Sincerely yours, Pavel Odintsov From mark.tinka at seacom.mu Mon Feb 29 07:50:43 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 29 Feb 2016 09:50:43 +0200 Subject: Media converter vendors - GFP/EoSDH In-Reply-To: References: <71b738ee-c5de-d598-f956-6c274367ea75@seacom.mu> Message-ID: <2b961b11-2f8a-390b-f22b-06f405889448@seacom.mu> On 29/Feb/16 06:47, Ramy Hashish wrote: > Hello Mark, > > Do you know anything about their MEF compliance? which of them is > capable of working in carrier-grade large scale environment? All the ones I've mentioned seem to have some kind of CE 2.0 compliance. How true it is I'm not really sure. I only use Cisco and Juniper for my Carrier Ethernet deployments. All those vendors have Carrier Ethernet support in their transport gear, but it will usually be based on simple 802.1Q or MPLS-TP at the most. If you want an IP/MPLS control plane, you'd need to look at their router offerings, for those that have. Mark. From rdobbins at arbor.net Mon Feb 29 07:53:19 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 29 Feb 2016 14:53:19 +0700 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> Message-ID: On 29 Feb 2016, at 14:41, Pavel Odintsov wrote: > Could you describe they in details? Inconsistent stats, lack of ifindex information. > But netflow __could__ delay telemetry up to 30 seconds (in case of > huge syn/syn-ack flood for example) and you network will experience > downtime. This is incorrect, and reflects an inaccurate understanding of how NetFlow/IPFIX actually works, in practice. It's often repeated by those with little or no operational experience with NetFlow/IPFIX. ----------------------------------- Roland Dobbins From pavel.odintsov at gmail.com Mon Feb 29 08:12:32 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 29 Feb 2016 11:12:32 +0300 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> Message-ID: What you mean as lack of ifindex in sflow? I could offer example sflow v5 sample structure description (it's from my C++ based sflow parser but actually it's pretty simple to understand): uint32_t sample_sequence_number; // sample sequence number uint32_t source_id_type; // source id type uint32_t source_id_index; // source id index uint32_t sampling_rate; // sampling ratio uint32_t sample_pool; // number of sampled packets uint32_t drops_count; // number of drops due to hardware overload uint32_t input_port_type; // input port type uint32_t input_port_index; // input port index uint32_t output_port_type; // output port type uint32_t output_port_index; // outpurt port index uint32_t number_of_flow_records; ssize_t original_payload_length; As you can see we have source id, sampling rate and definitely we have full information about source and destination ifindexes. In addition to sample structure (which consist of first X bytes of each packet) we have counter structures which working as old good "snmp counters" and offer detailed information about load on each port. Looks like you haven't so much field experience with sflow. I could help and offer some real field experience below. --- Few words about netflow. When you are speaking about "netflow" you should mentions explicit vendors. Because netflow is very-very-very vendor specific. I have my own netflow collector implementation for netflow v5, netflow v9 and IPFIX (just check my repository https://github.com/pavel-odintsov/fastnetmon/blob/master/src/netflow_plugin/netflow_collector.cpp). I spent so much nights on debugging this protocols. So you know about Mirkotik implementation of netflow (they have minimum possible active and inactive timeout - 60 seconds) ? Or what about old Cisco routers which support only 180 seconds as active timeouts? Could they offer affordable time for telemetry delivery? The only one way to have accurate bandwidth data in netflow to use some sort of average or moving average for certain time (30 seconds for example). But if you have really huge network you should use netflow sampling. And here I should say multiple nice questions! Cisco and Juniper are using really incompatible way to encode sampling rate. That's really funny but that is. I do not know about other vendors because network sampling is very specific feature. But with sampling (if your collector could decode yet another netflow incompatible implementation) things going really weird :) And you could get accurate bandwidth data only if you have really HUGE network with only 10-100GE customers because traffic speed to small (100 - 1000mbps) customers will be really weird :) What's your ideas about this all? Please mention vendor names whet you vote for netflow next time. Because not all netflow implementations are OK. And definitely some netflow implementations are broken. On Mon, Feb 29, 2016 at 10:53 AM, Roland Dobbins wrote: > On 29 Feb 2016, at 14:41, Pavel Odintsov wrote: > >> Could you describe they in details? > > > Inconsistent stats, lack of ifindex information. > >> But netflow __could__ delay telemetry up to 30 seconds (in case of huge >> syn/syn-ack flood for example) and you network will experience downtime. > > > This is incorrect, and reflects an inaccurate understanding of how > NetFlow/IPFIX actually works, in practice. It's often repeated by those > with little or no operational experience with NetFlow/IPFIX. > > ----------------------------------- > Roland Dobbins -- Sincerely yours, Pavel Odintsov From rdobbins at arbor.net Mon Feb 29 08:38:10 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 29 Feb 2016 15:38:10 +0700 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> Message-ID: On 29 Feb 2016, at 15:12, Pavel Odintsov wrote: > Looks like you haven't so much field experience with sflow. I could > help and offer some real field experience below. I've already recounted my real-world operational experience with NetFlow. > I have my own netflow collector implementation for netflow v5, netflow > v9 and IPFIX (just check my repository Coding something and using something operationally are two different things. I'm not a coder, but I've used NetFlow operationally since 1998, primarily on Cisco platforms (some Junipers, but I don't know a lot about Juniper boxes). > So you know about Mirkotik implementation of netflow (they have > minimum possible active and inactive timeout - 60 seconds) ? Yes. That does not equate to a 60s delay in detection/classifying/tracing back a SYN-flood, or anything else. > Or what about old Cisco routers which support only 180 seconds as > active timeouts? I think you're referring to the *default* value for the active flow timer, which can of course be altered. > Could they offer affordable time for telemetry delivery? Yes, because there has never been any such router, and also because cache size and other tunable parameters, as well as FIFOing out of flows when the cache is full, guarantees that very few flows of the type seen in DDoS traffic hang around in the cache for any appreciable length of time. > Because not all netflow implementations are OK. And definitely some > netflow implementations are broken. You can search the archives on this list and see my previous detailed explanation of NetFlow caveats on Cisco 6500/7600 with EARL6 and EARL7 ASICs. Your statements about it taking an inordinately long time to detect/classify/traceback SYN-floods and other types of DDoS attacks utilizing NetFlow implementations (with the exceptions of crippled implementations like the aforementioned EARL6/EARL7 and pre-Sup7 Cisco 4500) are simply untrue. ----------------------------------- Roland Dobbins From pavel.odintsov at gmail.com Mon Feb 29 08:53:44 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 29 Feb 2016 11:53:44 +0300 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> Message-ID: Thanks for explained answer! But actually it's mistake to think I haven't real field experience just because I'm developer. In world of big companies nobody could do ops and development. But I'm trying to keep close to both worlds. And could conclude it's definitely possible. It's definitely possible thanks to my flexible company :) But actually "I think you're referring to the *default* value for the active flow timer, which can of course be altered." It's not about default. It's about minimal possible. For Mikrotik routers same issue. Minimal possible timeout is 60 / 60. And impossible to decrease it. Also so much routers could not do enough accurate netflow without additional (and very expensive) line cards just for netflow generation. OK, we could handle some sort of SYN flood. But what about 20 Gbps http flood with valid requests when each customer are real (and not spoofied) and they are sending huge post requests and hang on connection? How netflow will handle correctly handshaked connection, established http session but haven't closed correctly for a while? Actually it could wait for active/inactive timeout and you will get bad news from ops guys about network downtime. But sflow will handle it with flying colors without delay. What about destination http host detection with netflow? Could it extract "host" header from netflow? And drop only part of traffic to our own host? Definitely not. Netflow haven't any information about http headers but sflow has. What about same issue for dns flood when somebody flood out some certain host? You could detect this attack with netflow. But you could not extract information about certain type of DDoS attack and attacked domain. When we speaking about "very rough" DDoS attack mitigation and filtering we could use netflow. But when we are really care about network stability, customer service SLA and ability to filter malicious traffic with perfect precision we should use sflow. I really like to hear feedback about my vision. On Mon, Feb 29, 2016 at 11:38 AM, Roland Dobbins wrote: > On 29 Feb 2016, at 15:12, Pavel Odintsov wrote: > >> Looks like you haven't so much field experience with sflow. I could >> help and offer some real field experience below. > > > I've already recounted my real-world operational experience with NetFlow. > >> I have my own netflow collector implementation for netflow v5, netflow v9 >> and IPFIX (just check my repository > > > Coding something and using something operationally are two different things. > I'm not a coder, but I've used NetFlow operationally since 1998, primarily > on Cisco platforms (some Junipers, but I don't know a lot about Juniper > boxes). > >> So you know about Mirkotik implementation of netflow (they have >> minimum possible active and inactive timeout - 60 seconds) ? > > > Yes. That does not equate to a 60s delay in detection/classifying/tracing > back a SYN-flood, or anything else. > >> Or what about old Cisco routers which support only 180 seconds as active >> timeouts? > > > I think you're referring to the *default* value for the active flow timer, > which can of course be altered. > >> Could they offer affordable time for telemetry delivery? > > > Yes, because there has never been any such router, and also because cache > size and other tunable parameters, as well as FIFOing out of flows when the > cache is full, guarantees that very few flows of the type seen in DDoS > traffic hang around in the cache for any appreciable length of time. > >> Because not all netflow implementations are OK. And definitely some >> netflow implementations are broken. > > > You can search the archives on this list and see my previous detailed > explanation of NetFlow caveats on Cisco 6500/7600 with EARL6 and EARL7 > ASICs. > > Your statements about it taking an inordinately long time to > detect/classify/traceback SYN-floods and other types of DDoS attacks > utilizing NetFlow implementations (with the exceptions of crippled > implementations like the aforementioned EARL6/EARL7 and pre-Sup7 Cisco 4500) > are simply untrue. > > ----------------------------------- > Roland Dobbins -- Sincerely yours, Pavel Odintsov From rdobbins at arbor.net Mon Feb 29 09:42:45 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 29 Feb 2016 16:42:45 +0700 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> Message-ID: On 29 Feb 2016, at 15:53, Pavel Odintsov wrote: > It's not about default. It's about minimal possible. To my knowledge, there has never been a Cisco router which only allowed an active flow timer value of 180s, which wasn't user-configurable. I would appreciate the details of any such router. > > For Mikrotik routers same issue. Minimal possible timeout is 60 / 60. > And impossible to decrease it. As we've seen already from another poster in this thread, that isn't the case. > Also so much routers could not do enough accurate netflow without > additional (and very expensive) line cards just for netflow > generation. I believe you're referring to PICs on Juniper routers, yes? Or perhaps the requirement for E3 or E5 linecards on Cisco 12Ks? Or maybe DFCs on Cisco 6500s/7600s? Or possibly M-series linecards on Cisco N7Ks (which are switches, of course)? TANSTAAFL. > OK, we could handle some sort of SYN flood. As noted previously, this is indeed the case. > > But what about 20 Gbps http flood with valid requests when each > customer are real (and not spoofied) and they are sending huge post > requests and hang on connection? Attacks of this nature generally leave a 'wake' or 'contrail' which is pretty easily spotted if one's statistical anomaly detection routines are optimal. > Actually it could wait for active/inactive timeout and you will get > bad news from ops guys about network downtime. As a network ops guy, I can assure you that you are incorrect, largely because you don't seem to understand the interplay of active flow timer, inactive flow timer, NetFlow cache size, NetFlow cache FIFOing, and normal flow cache baselines. > But sflow will handle it with flying colors without delay. NetFlow handles it with flying colors without delay. > > What about destination http host detection with netflow? Could it > extract "host" header from netflow? And drop only part of traffic to > our own host? Of course not, for classical flow telemetry templates - but that's when one drops from the macroanlytical to the microanalytical. And flow telemetry doesn't 'drop' anything. For some reason, you don't mention Flexible NetFlow at all. It's true that it's taken a while to become practical to use (back when the then-Cisco NetFlow PM asked me to create the CLI grammar and syntax for FNF, I noted that it wouldn't take off until there was a decent control-plane interface for creating, configuring, and tearing down dynamic flow caches, as well as some degree of ASIC support on larger platforms), but now that the various 'SDN'-type provisioning mechanisms are being implemented, and now that at least partial FNF is supported to varying degrees on various ASICs, this will hopefully change. > > Netflow haven't any information about http headers but sflow has. See above. This isn't necessary, and it isn't possible at scale with s/Flow, either. > > What about same issue for dns flood when somebody flood out some > certain host? You could detect this attack with netflow. But you could > not extract information about certain type of DDoS attack and attacked > domain. There's no need to do this with flow telemetry. Once the attack has been detected/classified/traced back, one drops to the microanalytical for situationally-appropriate mitigation. > > When we speaking about "very rough" DDoS attack mitigation and > filtering we could use netflow. Not just 'very rough', see above. > But when we are really care about network stability, customer service > SLA and ability to filter malicious traffic with perfect precision we > should use sflow. This is demonstrably incorrect. Many of the largest networks in the world successfully utilize NetFlow telemetry for all these purposes; they have for many years, and will continue to do so. [And, btw, nothing has 'perfect precision'.] That doesn't mean that NetFlow (or IPFIX) is perfect, and it doesn't mean that all implementations are perfect, and it doesn't mean that the ability to get more information about traffic via FNF or IPFIX EE mechanisms isn't desirable. But you are simply wrong about the utility of NetFlow and/or IPFIX with classical flow templates. > I really like to hear feedback about my vision. See above. ----------------------------------- Roland Dobbins From pavel.odintsov at gmail.com Mon Feb 29 09:59:02 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 29 Feb 2016 12:59:02 +0300 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> Message-ID: Thanks for detailed question! I have only one question. Why you against sFLOW protocol telemetry with so huge passion ? :) It's not proprietary technology and not an product from yet another big company. I'm not trying to sell anything because... nothing to sell. Really, isn't it? It's just yet another open standard to analyze data approved and implemented as RFC. If somebody developed this standard. Implemented it in ASIC (they have very huge price for development and production you know). That's means "somebody" really want it and will definitely use it. Actually, sflow is not so popular as netflow. But to be honest it's pretty young standard in compare with netflow and it implements slightly different approach. Which will be useful in some cases. For example, at huge Internet Exchanges you actually haven't any netflow enabled devices (just check design architecures from AMX-IX, DEC-IX, LINX or even MSK-IX). Almost all IX developed with L2 in ming and they actually haven't any devices which could produce netflow. So IX could not use netflow even if they want. But you vote for "sflow is weird protocol and you should avoid it". How IX could monitor traffic if they haven't netflow? So if they follow your recommendations they should drop idea about traffic monitoring at all :) I do not like holy wars about something vs something. But actually in modern network world every technology has applicable usage and it's not good idea to avoid it just because your religion (I'm speaking about netflow religion) prohibit it for you. Actually you are writing this email from company email and I could conclude it's Arbor vision and is not your own. Could you clarify it? Could I use your vision as Arbor's vision in public speeches / presentations? Thanks! On Mon, Feb 29, 2016 at 12:42 PM, Roland Dobbins wrote: > On 29 Feb 2016, at 15:53, Pavel Odintsov wrote: > >> It's not about default. It's about minimal possible. > > > To my knowledge, there has never been a Cisco router which only allowed an > active flow timer value of 180s, which wasn't user-configurable. I would > appreciate the details of any such router. >> >> >> For Mikrotik routers same issue. Minimal possible timeout is 60 / 60. >> And impossible to decrease it. > > > As we've seen already from another poster in this thread, that isn't the > case. > >> Also so much routers could not do enough accurate netflow without >> additional (and very expensive) line cards just for netflow >> generation. > > > I believe you're referring to PICs on Juniper routers, yes? Or perhaps the > requirement for E3 or E5 linecards on Cisco 12Ks? Or maybe DFCs on Cisco > 6500s/7600s? Or possibly M-series linecards on Cisco N7Ks (which are > switches, of course)? > > TANSTAAFL. > >> OK, we could handle some sort of SYN flood. > > > As noted previously, this is indeed the case. >> >> >> But what about 20 Gbps http flood with valid requests when each >> customer are real (and not spoofied) and they are sending huge post >> requests and hang on connection? > > > Attacks of this nature generally leave a 'wake' or 'contrail' which is > pretty easily spotted if one's statistical anomaly detection routines are > optimal. > >> Actually it could wait for active/inactive timeout and you will get >> bad news from ops guys about network downtime. > > > As a network ops guy, I can assure you that you are incorrect, largely > because you don't seem to understand the interplay of active flow timer, > inactive flow timer, NetFlow cache size, NetFlow cache FIFOing, and normal > flow cache baselines. > >> But sflow will handle it with flying colors without delay. > > > NetFlow handles it with flying colors without delay. >> >> >> What about destination http host detection with netflow? Could it >> extract "host" header from netflow? And drop only part of traffic to >> our own host? > > > Of course not, for classical flow telemetry templates - but that's when one > drops from the macroanlytical to the microanalytical. And flow telemetry > doesn't 'drop' anything. > > For some reason, you don't mention Flexible NetFlow at all. It's true that > it's taken a while to become practical to use (back when the then-Cisco > NetFlow PM asked me to create the CLI grammar and syntax for FNF, I noted > that it wouldn't take off until there was a decent control-plane interface > for creating, configuring, and tearing down dynamic flow caches, as well as > some degree of ASIC support on larger platforms), but now that the various > 'SDN'-type provisioning mechanisms are being implemented, and now that at > least partial FNF is supported to varying degrees on various ASICs, this > will hopefully change. > >> >> Netflow haven't any information about http headers but sflow has. > > > See above. This isn't necessary, and it isn't possible at scale with > s/Flow, either. >> >> >> What about same issue for dns flood when somebody flood out some >> certain host? You could detect this attack with netflow. But you could >> not extract information about certain type of DDoS attack and attacked >> domain. > > > There's no need to do this with flow telemetry. Once the attack has been > detected/classified/traced back, one drops to the microanalytical for > situationally-appropriate mitigation. >> >> >> When we speaking about "very rough" DDoS attack mitigation and >> filtering we could use netflow. > > > Not just 'very rough', see above. > >> But when we are really care about network stability, customer service >> SLA and ability to filter malicious traffic with perfect precision we >> should use sflow. > > > This is demonstrably incorrect. Many of the largest networks in the world > successfully utilize NetFlow telemetry for all these purposes; they have for > many years, and will continue to do so. > > [And, btw, nothing has 'perfect precision'.] > > That doesn't mean that NetFlow (or IPFIX) is perfect, and it doesn't mean > that all implementations are perfect, and it doesn't mean that the ability > to get more information about traffic via FNF or IPFIX EE mechanisms isn't > desirable. But you are simply wrong about the utility of NetFlow and/or > IPFIX with classical flow templates. > >> I really like to hear feedback about my vision. > > > See above. > > ----------------------------------- > Roland Dobbins -- Sincerely yours, Pavel Odintsov From rdobbins at arbor.net Mon Feb 29 10:14:23 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 29 Feb 2016 17:14:23 +0700 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> Message-ID: On 29 Feb 2016, at 16:59, Pavel Odintsov wrote: > I have only one question. Why you against sFLOW protocol telemetry > with so huge passion ? :) Because I've had very poor experiences with it. And it doesn't seem to scale very well. > Actually, sflow is not so popular as netflow. But to be honest it's > pretty young standard in compare with netflow and it implements > slightly different approach. sFlow has been around for a while, though. It isn't new. > So IX could not use netflow even if they want. This depends upon the devices utilized - there are actually some devices which can export layer-2 NetFlow. There are other issues with NetFlow as it's currently generally implemented which are also concerns with IX scenarios, FYI. I will leave it as an exercise for you to find out what they are. > But you vote for "sflow is weird protocol and you should avoid it". My view is that it's generally better to use NetFlow or IPFIX, where and when possible. > How IX could monitor traffic if they haven't netflow? So if they > follow your recommendations they should drop idea about traffic > monitoring at all :) Straw man. I never said that nor implied it. If sFlow is all that's available, then of course operators can and should use it. > But actually in modern network world every technology has applicable > usage and it's > not good idea to avoid it just because your religion (I'm speaking > about netflow religion) prohibit it for you. It isn't 'religion'. It's based upon the fact that a) my experiences with sFlow have been suboptimal and b) sFlow isn't generally available on large routers used at network edges. > Actually you are writing this email from company email and I could > conclude it's Arbor vision and is not your own. No, that is incorrect. I speak only for myself. And as I previously noted, Arbor products support sFlow, and have for many years; I'm just not a big fan of it. > Could you clarify it? I just did. > Could I use your vision as Arbor's vision in public speeches / > presentations? No, you may not, per the above. Arbor is telemetry-neutral; we aim to support all relevant telemetry formats in line with the expressed needs of our customers. And that includes sFlow. These trollish, passive-aggressive rhetorical tactics grow wearisome. I will not reply any further to this thread, so as to avoid further spamming the list. ----------------------------------- Roland Dobbins From saku at ytti.fi Mon Feb 29 12:03:02 2016 From: saku at ytti.fi (Saku Ytti) Date: Mon, 29 Feb 2016 14:03:02 +0200 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> Message-ID: On 29 February 2016 at 04:24, Roland Dobbins wrote: >> Around here they are currently voting on a law that will require unsampled >> 1:1 netflow on all data in an ISP network with more than 100 users. > > That's interesting, given that most larger routers don't support 1:1. I find that strange, because if you're doing in in HW, doing hash lookup for flow and adding packets and bytes to the counter is cheap. It's expensive having lot of those flows, but incrementing their packet and byte counter isn't. I know that all JNPR Trio kit (MX, T, EX9k...) do 1:1. I guess if you're doing it in LC CPU things are very different. -- ++ytti From saku at ytti.fi Mon Feb 29 12:12:13 2016 From: saku at ytti.fi (Saku Ytti) Date: Mon, 29 Feb 2016 14:12:13 +0200 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: Message-ID: On 28 February 2016 at 22:06, Todd Crane wrote: > This maybe outside the scope of this list but I was wondering if anybody had advice or lessons learned on the whole sFlow vs netFlow debate. We are looking at using it for billing and influencing our sdn flows. It seems like everything I have found is biased (articles by companies who have commercial offerings for the "better" protocol) I view sflow as subset of NetflowV9 V10/IPFIX. You could produce sflow behaviour in IPFIX, by adding record of packet sample, and exporting immediately instead of keeping state of flows. However you couldn't produce IPFIX behaviour in sflow, inherently so. sflow is older than IPFIX (v10) or v9 netflow, and I'm guessing no one would invent sflow today, they'd instead specify some restricted IPFIX with same behaviour. I completely understand why sflow was needed netflowv5 time, but I don't really see much point there now. It just means that collectors need to be more complicated than they must, by having two parsers. -- ++ytti From edward.dore at freethought-internet.co.uk Mon Feb 29 12:16:29 2016 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Mon, 29 Feb 2016 12:16:29 +0000 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> Message-ID: <58FE72C0-DA61-496D-8442-FBB5D830CF77@freethought-internet.co.uk> > On 29 Feb 2016, at 09:59, Pavel Odintsov wrote: > > For example, at huge Internet Exchanges you actually haven't any > netflow enabled devices (just check design architecures from AMX-IX, > DEC-IX, LINX or even MSK-IX). LINX use IPFIX (which is derived from NetFlow) for the Juniper LAN. The Extreme LAN uses sFlow. Edward Dore Freethought Internet -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sthaug at nethelp.no Mon Feb 29 12:17:48 2016 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 29 Feb 2016 13:17:48 +0100 (CET) Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: Message-ID: <20160229.131748.74688177.sthaug@nethelp.no> > > That's interesting, given that most larger routers don't support 1:1. > > I find that strange, because if you're doing in in HW, doing hash > lookup for flow and adding packets and bytes to the counter is cheap. > It's expensive having lot of those flows, but incrementing their > packet and byte counter isn't. > > I know that all JNPR Trio kit (MX, T, EX9k...) do 1:1. I guess if > you're doing it in LC CPU things are very different. A relevant question might be if the Trio hardware can do 1:1 while handling multiple ports of line rate DDoS traffic consisting of small packets with different port numbers (i.e. high pps traffic resulting in basically 1 flow per packet). No, I don't know the answer (but I suspect it might be negative). Here we're using Trio hardware with 1:100 sampling, and are reasonably happy with the results. Steinar Haug, AS2116 From pavel.odintsov at gmail.com Mon Feb 29 12:37:56 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 29 Feb 2016 15:37:56 +0300 Subject: sFlow vs netFlow/IPFIX In-Reply-To: <58FE72C0-DA61-496D-8442-FBB5D830CF77@freethought-internet.co.uk> References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> <58FE72C0-DA61-496D-8442-FBB5D830CF77@freethought-internet.co.uk> Message-ID: Hello! Nice information. Very interesting architecture. They are using L3 on IX? How big Juniper Lan in comparison with Extreme lan? On Mon, Feb 29, 2016 at 3:16 PM, Edward Dore wrote: > >> On 29 Feb 2016, at 09:59, Pavel Odintsov wrote: >> >> For example, at huge Internet Exchanges you actually haven't any >> netflow enabled devices (just check design architecures from AMX-IX, >> DEC-IX, LINX or even MSK-IX). > > > LINX use IPFIX (which is derived from NetFlow) for the Juniper LAN. > > The Extreme LAN uses sFlow. > > Edward Dore > Freethought Internet -- Sincerely yours, Pavel Odintsov From saku at ytti.fi Mon Feb 29 12:41:03 2016 From: saku at ytti.fi (Saku Ytti) Date: Mon, 29 Feb 2016 14:41:03 +0200 Subject: sFlow vs netFlow/IPFIX In-Reply-To: <20160229.131748.74688177.sthaug@nethelp.no> References: <20160229.131748.74688177.sthaug@nethelp.no> Message-ID: On 29 February 2016 at 14:17, wrote: > A relevant question might be if the Trio hardware can do 1:1 while > handling multiple ports of line rate DDoS traffic consisting of small > packets with different port numbers (i.e. high pps traffic resulting > in basically 1 flow per packet). No, I don't know the answer (but I > suspect it might be negative). I cannot see why not, it's cheap. You're doing 1-2 LPM on the packet, QoS lookup, ACL lookup, incrementing various counters, etc., adding one hash lookup and two counters is not going to be relevant cost to the lookup time. Having many entries in the hash table is an issue, incrementing their counters is not. > Here we're using Trio hardware with 1:100 sampling, and are reasonably > happy with the results. -- ++ytti From edward.dore at freethought-internet.co.uk Mon Feb 29 12:55:33 2016 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Mon, 29 Feb 2016 12:55:33 +0000 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> <58FE72C0-DA61-496D-8442-FBB5D830CF77@freethought-internet.co.uk> Message-ID: <71BAACEE-D69B-407B-91DA-91E31CB46184@freethought-internet.co.uk> > On 29 Feb 2016, at 12:37, Pavel Odintsov wrote: > > Hello! > > Nice information. Very interesting architecture. They are using L3 on > IX? How big Juniper Lan in comparison with Extreme lan? Hi Pavel, The Juniper LAN is VPLS and the Extreme LAN is standard layer 2 with EAPS instead of *STP. The Juniper LAN peaks at ~2.7Tbps (https://stats.linx.net/lans#lon1), whilst the Extreme LAN peaks at ~0.6Tbps (https://stats.linx.net/lans#lon2). Edward Dore Freethought Internet -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pavel.odintsov at gmail.com Mon Feb 29 12:56:48 2016 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 29 Feb 2016 15:56:48 +0300 Subject: sFlow vs netFlow/IPFIX In-Reply-To: <71BAACEE-D69B-407B-91DA-91E31CB46184@freethought-internet.co.uk> References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> <58FE72C0-DA61-496D-8442-FBB5D830CF77@freethought-internet.co.uk> <71BAACEE-D69B-407B-91DA-91E31CB46184@freethought-internet.co.uk> Message-ID: Thanks! Very interesting. Will dig into details :) On Mon, Feb 29, 2016 at 3:55 PM, Edward Dore wrote: > >> On 29 Feb 2016, at 12:37, Pavel Odintsov wrote: >> >> Hello! >> >> Nice information. Very interesting architecture. They are using L3 on >> IX? How big Juniper Lan in comparison with Extreme lan? > > Hi Pavel, > > The Juniper LAN is VPLS and the Extreme LAN is standard layer 2 with EAPS instead of *STP. > > The Juniper LAN peaks at ~2.7Tbps (https://stats.linx.net/lans#lon1), whilst the Extreme LAN peaks at ~0.6Tbps (https://stats.linx.net/lans#lon2). > > Edward Dore > Freethought Internet -- Sincerely yours, Pavel Odintsov From nick at foobar.org Mon Feb 29 13:05:56 2016 From: nick at foobar.org (Nick Hilliard) Date: Mon, 29 Feb 2016 13:05:56 +0000 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <20160229.131748.74688177.sthaug@nethelp.no> Message-ID: <56D44234.9080600@foobar.org> Saku Ytti wrote: > I cannot see why not, it's cheap. You're doing 1-2 LPM on the packet, > QoS lookup, ACL lookup, incrementing various counters, etc., adding > one hash lookup and two counters is not going to be relevant cost to > the lookup time. depends on what you define by "cheap". Netflow requires separate packet forwarding lookup and ACL handling silicon. > Having many entries in the hash table is an issue, incrementing their > counters is not. it is certainly an issue if you get splatted with lots of discrete junk flow, yes. Neither of these are a problem for sflow. It just plucks packets out of the data plane at a pre-defined rate and forwards their headers to the collector. So long as your sampler is accurate, it's great. Nick From nick at foobar.org Mon Feb 29 13:11:18 2016 From: nick at foobar.org (Nick Hilliard) Date: Mon, 29 Feb 2016 13:11:18 +0000 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> <21F620E9-84AF-490A-80E0-D23AF56BDF13@arbor.net> Message-ID: <56D44376.60609@foobar.org> Roland Dobbins wrote: > Inconsistent stats, lack of ifindex information. I've not yet come across an sflow implementation which didn't fill out the ifindex field. No doubt they exist. Not sure what you mean by "inconsistent stats". Nick From nick at foobar.org Mon Feb 29 13:19:58 2016 From: nick at foobar.org (Nick Hilliard) Date: Mon, 29 Feb 2016 13:19:58 +0000 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> Message-ID: <56D4457E.2060004@foobar.org> Pavel Odintsov wrote: > From hardware point of view almost all brand new switches support > sflow free of charge (no additional licenses or modules). But be > aware, Cisco do not support this protocol at all (that's pretty weird, > really). sflow is supported on the Nexus 3k range, but it's available as ingress + egress only, non-configurable (despite the fact that the option to configure is available at the chipset level). This means that you can't define an account perimeter on the switch, which makes it mostly useless from a production point of view. Pretty much every other switch on the market will allow you to specify either ingress or egress. The only consistent explanation I can suggest for Cisco's vehement antipathy towards sflow is "not invented here". It's supported in hardware by several of the other chipsets that Cisco uses, but left non-enabled in software. TBH it's a short sighted and disappointing approach to telemetry. Nick From saku at ytti.fi Mon Feb 29 13:31:52 2016 From: saku at ytti.fi (Saku Ytti) Date: Mon, 29 Feb 2016 15:31:52 +0200 Subject: sFlow vs netFlow/IPFIX In-Reply-To: <56D44234.9080600@foobar.org> References: <20160229.131748.74688177.sthaug@nethelp.no> <56D44234.9080600@foobar.org> Message-ID: On 29 February 2016 at 15:05, Nick Hilliard wrote: > depends on what you define by "cheap". Netflow requires separate packet > forwarding lookup and ACL handling silicon. That's not inherently so, it depends how specialised your hardware is. If it's very specialised like implementing just LPM, sure. If it's NPU, then no, that's not given. The cost is many entries in the hash table, not updating them. But if you'd emulate sflow behaviour in IPFIX then you don't need the hash tables or the counters. > Neither of these are a problem for sflow. It just plucks packets out of > the data plane at a pre-defined rate and forwards their headers to the > collector. So long as your sampler is accurate, it's great. ACK and as in explained in earlier post, there is nothing stopping from IPFIX working like this. sflow is subset of what's possible in IPFIX. -- ++ytti From sathish.kumar.ippani at gmail.com Mon Feb 29 14:37:40 2016 From: sathish.kumar.ippani at gmail.com (sathish kumar Ippani) Date: Mon, 29 Feb 2016 20:07:40 +0530 Subject: Observium Message-ID: Hello Everyone, This is off topic, i am posting request as i need some help in configuring obsrvium for RANCID and traffic polling. for traffic polling I am seeing white space in the graph as shown in the below. [image: Inline image 1] Rancid. Device back up are fine for few devices (daily) for few devices backup were not happening. Rancid cronjob ============================ 58 11 * * * /var/lib/rancid/bin/rancid-run #hourly router dump 59 11 * * * /usr/bin/find /var/lib/rancid/logs -type f -mtime +2 -exec rm {} \; poller cronjob ================== */5 * * * * root /opt/observium/poller-wrapper.py 10 >> /dev/null 2>&1 -- With Regards, Sathish Kumar Ippani 9177166040 From job at instituut.net Mon Feb 29 14:44:26 2016 From: job at instituut.net (Job Snijders) Date: Mon, 29 Feb 2016 15:44:26 +0100 Subject: Observium In-Reply-To: References: Message-ID: <20160229144426.GJ43080@57.rev.meerval.net> On Mon, Feb 29, 2016 at 08:07:40PM +0530, sathish kumar Ippani wrote: > This is off topic, i am posting request as i need some help in > configuring obsrvium for RANCID and traffic polling. This is indeed the wrong mailing-list. Please direct your questions to http://observium.org/docs/mailinglists/ instead. Kind regards, Job From b-nanog at grmbl.net Mon Feb 29 14:47:35 2016 From: b-nanog at grmbl.net (B) Date: Mon, 29 Feb 2016 15:47:35 +0100 Subject: mrtg alternative - librenms In-Reply-To: References: Message-ID: <20160229144734.GG39311@mx.grmbl.net> An alternative to Observium is LibreNMS, with a more liberal license/community. Cheers, B On Sat, Feb 27, 2016 at 12:18:16AM +0100, Baldur Norddahl wrote: > Hi > > I am currently using MRTG and RRD to make traffic graphs. I am searching > for more modern alternatives that allows the user to dynamically zoom and > scroll the timeline. > > Bonus points if the user can customize the graphs directly in the > webbrowse. For example he might be able to add or remove individual peers > from the graph by simply clicking a checkbox. > > What is the 2016 tool for this? > > Regards, > > Baldur From bedard.phil at gmail.com Mon Feb 29 15:40:59 2016 From: bedard.phil at gmail.com (Phil Bedard) Date: Mon, 29 Feb 2016 10:40:59 -0500 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <20160229.131748.74688177.sthaug@nethelp.no> <56D44234.9080600@foobar.org> Message-ID: <432E6F5B-E2C3-4E36-93CA-E51125FDE4DA@gmail.com> -----Original Message----- From: NANOG on behalf of Saku Ytti Date: Monday, February 29, 2016 at 08:31 To: Nick Hilliard Cc: nanog list Subject: Re: sFlow vs netFlow/IPFIX >On 29 February 2016 at 15:05, Nick Hilliard wrote: > >> depends on what you define by "cheap". Netflow requires separate packet >> forwarding lookup and ACL handling silicon. > >That's not inherently so, it depends how specialised your hardware is. >If it's very specialised like implementing just LPM, sure. If it's >NPU, then no, that's not given. I don?t think anyone uses dedicated Netflow HW these days. The ASICs have functionality for other things like mirroring, etc. which are augmented for Netflow use. Usually it?s a mix of dedicated functions in the ASICs and then the LC CPU and general CPU on some platforms. Really in the end the router is doing something like SFlow internally. > >The cost is many entries in the hash table, not updating them. But if >you'd emulate sflow behaviour in IPFIX then you don't need the hash >tables or the counters. It would be interesting to get some data from vendors on what the actual limitation is. I know with some new platforms like the NCS 55XX from Cisco (BRCM Jericho) it has limited space for counters, but I don?t know if that contributes to its minimum 1:8000 Netflow sampling rate. The new PTX FPC supporting Netflow has a minimum of 1:1000. Phil From benno at NLnetLabs.nl Mon Feb 29 15:53:14 2016 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Mon, 29 Feb 2016 16:53:14 +0100 Subject: 2nd call for presentations RIPE 72 Message-ID: <3bfa3605-225c-3ce4-30d1-a1d9af431799@NLnetLabs.nl> Dear colleagues, Please note the approaching deadline of 13 March 2016 for RIPE 72 plenary programme submissions. You can find the CFP for RIPE 72 below or at https://ripe72.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://www.ripe.net/participate/meetings/ripe-meetings/pc -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 72 will take place from 23-27 May 2016 in Copenhagen, Denmark. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 72. See the full descriptions of the different presentation formats, https://ripe72.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 13 March 2016. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe72.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe72.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice---in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From source_route at yahoo.com Mon Feb 29 15:53:54 2016 From: source_route at yahoo.com (Philip Lavine) Date: Mon, 29 Feb 2016 15:53:54 +0000 (UTC) Subject: google search threshold In-Reply-To: References: Message-ID: <726393422.785405.1456761234633.JavaMail.yahoo@mail.yahoo.com> I have about 2000 users behind a single NAT. I have been looking at netflow, URL filter logs, IDS logs, etc. The traffic seems to be legit. I am going to move more users to IPv6 and divide some of the subnets into different NATS and see if that alleviates the traffic load. Thanks for the advice. -Philip From: Damian Menscher To: Philip Lavine Cc: "nanog at nanog.org" Sent: Friday, February 26, 2016 6:05 PM Subject: Re: google search threshold On Fri, Feb 26, 2016 at 3:01 PM, Philip Lavine via NANOG wrote: Does anybody know what the threshold for google searches is before you get the captcha?I? am trying to decide if I need to break up the overload NAT to a pool. There isn't a threshold -- if you send automated searches from an IP, then it gets blocked (for a while). So... this comes down to how much you trust your machines/users.? If you're a company with managed systems, then you can have thousands of users share the same IP without problems.? But if you're an ISP, you'll likely run into problems much earlier (since users like their malware). Some tips:?? - if you do NAT: try to partition users into pools so one abusive user can't get all your external IPs blocked? - if you have a proxy: make sure it inserts the X-Forwarded-For header, and is restricted to your own users? - if you're an ISP: IPv6 will allow each user to have their own /64, which avoids shared-fate from abusive ones Damian (responsible for DDoS defense)--?Damian Menscher :: Security Reliability Engineer :: Google :: AS15169 From jason+nanog at lixfeld.ca Mon Feb 29 16:07:39 2016 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Mon, 29 Feb 2016 11:07:39 -0500 Subject: Duplex negotiation over 100Base fibre Message-ID: <7024EEDA-5401-4470-B944-89DC33647DE1@lixfeld.ca> Hello, My understanding is that for 1G and 10G optical networks, there is no concept of half-duplex mode, but I?m unclear about half duplex in the 100M optical world. Specifically, if I connect two 100Base-LX (or BX) transceivers together, is there a requirement for the controller(s on either side) to select between full or half duplex, either by static configuration, or auto-negotiation? Thanks! From ktims at stargate.ca Mon Feb 29 16:49:52 2016 From: ktims at stargate.ca (Keenan Tims) Date: Mon, 29 Feb 2016 16:49:52 +0000 Subject: google search threshold In-Reply-To: <726393422.785405.1456761234633.JavaMail.yahoo@mail.yahoo.com> References: , <726393422.785405.1456761234633.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1456764592334.38533@stargate.ca> FWIW I have seen the captchas more often on IPv6 both from home and the office than when both networks were using a single shared IPv4; not sure if this is just related to chronology or a real effect. Once a month or so I seem to get them for a couple of days, then they go away. No idea what's triggering it. It would be *really* helpful if Google could provide some useful technical details beyond a generic FAQ page. As it is I just get annoyed by it and have no way to troubleshoot or correct the constant false positives. How is Google detecting "robots"? My sense is that I tend to trigger the captcha thing when iterating similar search terms (particularly due to removal of the + operator and extremely poor "change my search terms because you think you know better than I do what I want to search for" behaviour. My search patterns haven't really changed since turning up IPv6 everywhere, so I have to think either the captcha trigger has gotten more aggressive, or somehow prefers to blacklist IPv6 users. In any case, just going to IPv6 is definitely not a complete fix for this. It seems to be related to search behaviour and $blackbox_magic. Keenan Tims Stargate Connections ________________________________________ From: NANOG on behalf of Philip Lavine via NANOG Sent: February 29, 2016 7:53 AM To: Damian Menscher Cc: nanog at nanog.org Subject: Re: google search threshold I have about 2000 users behind a single NAT. I have been looking at netflow, URL filter logs, IDS logs, etc. The traffic seems to be legit. I am going to move more users to IPv6 and divide some of the subnets into different NATS and see if that alleviates the traffic load. Thanks for the advice. -Philip From: Damian Menscher To: Philip Lavine Cc: "nanog at nanog.org" Sent: Friday, February 26, 2016 6:05 PM Subject: Re: google search threshold On Fri, Feb 26, 2016 at 3:01 PM, Philip Lavine via NANOG wrote: Does anybody know what the threshold for google searches is before you get the captcha?I am trying to decide if I need to break up the overload NAT to a pool. There isn't a threshold -- if you send automated searches from an IP, then it gets blocked (for a while). So... this comes down to how much you trust your machines/users. If you're a company with managed systems, then you can have thousands of users share the same IP without problems. But if you're an ISP, you'll likely run into problems much earlier (since users like their malware). Some tips: - if you do NAT: try to partition users into pools so one abusive user can't get all your external IPs blocked - if you have a proxy: make sure it inserts the X-Forwarded-For header, and is restricted to your own users - if you're an ISP: IPv6 will allow each user to have their own /64, which avoids shared-fate from abusive ones Damian (responsible for DDoS defense)-- Damian Menscher :: Security Reliability Engineer :: Google :: AS15169 From contact at winterei.se Mon Feb 29 16:53:30 2016 From: contact at winterei.se (Paul S.) Date: Tue, 1 Mar 2016 01:53:30 +0900 Subject: google search threshold In-Reply-To: <1456764592334.38533@stargate.ca> References: <726393422.785405.1456761234633.JavaMail.yahoo@mail.yahoo.com> <1456764592334.38533@stargate.ca> Message-ID: <56D4778A.3080109@winterei.se> DO's SG range is allocated out of a single /64 (I think?) and Google basically asks for captcha on every single request over IPv6. :( We're using it as a corporate vpn. On 3/1/2016 01:49 AM, Keenan Tims wrote: > FWIW I have seen the captchas more often on IPv6 both from home and the office than when both networks were using a single shared IPv4; not sure if this is just related to chronology or a real effect. Once a month or so I seem to get them for a couple of days, then they go away. > > No idea what's triggering it. It would be *really* helpful if Google could provide some useful technical details beyond a generic FAQ page. As it is I just get annoyed by it and have no way to troubleshoot or correct the constant false positives. How is Google detecting "robots"? My sense is that I tend to trigger the captcha thing when iterating similar search terms (particularly due to removal of the + operator and extremely poor "change my search terms because you think you know better than I do what I want to search for" behaviour. My search patterns haven't really changed since turning up IPv6 everywhere, so I have to think either the captcha trigger has gotten more aggressive, or somehow prefers to blacklist IPv6 users. > > In any case, just going to IPv6 is definitely not a complete fix for this. It seems to be related to search behaviour and $blackbox_magic. > > Keenan Tims > Stargate Connections > ________________________________________ > From: NANOG on behalf of Philip Lavine via NANOG > Sent: February 29, 2016 7:53 AM > To: Damian Menscher > Cc: nanog at nanog.org > Subject: Re: google search threshold > > I have about 2000 users behind a single NAT. I have been looking at netflow, URL filter logs, IDS logs, etc. The traffic seems to be legit. > > I am going to move more users to IPv6 and divide some of the subnets into different NATS and see if that alleviates the traffic load. > Thanks for the advice. > -Philip > > > From: Damian Menscher > To: Philip Lavine > Cc: "nanog at nanog.org" > Sent: Friday, February 26, 2016 6:05 PM > Subject: Re: google search threshold > > On Fri, Feb 26, 2016 at 3:01 PM, Philip Lavine via NANOG wrote: > > Does anybody know what the threshold for google searches is before you get the captcha?I am trying to decide if I need to break up the overload NAT to a pool. > > > There isn't a threshold -- if you send automated searches from an IP, then it gets blocked (for a while). > > So... this comes down to how much you trust your machines/users. If you're a company with managed systems, then you can have thousands of users share the same IP without problems. But if you're an ISP, you'll likely run into problems much earlier (since users like their malware). > Some tips: - if you do NAT: try to partition users into pools so one abusive user can't get all your external IPs blocked - if you have a proxy: make sure it inserts the X-Forwarded-For header, and is restricted to your own users - if you're an ISP: IPv6 will allow each user to have their own /64, which avoids shared-fate from abusive ones > Damian (responsible for DDoS defense)-- Damian Menscher :: Security Reliability Engineer :: Google :: AS15169 > > From alejandroacostaalamo at gmail.com Mon Feb 29 17:13:48 2016 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Mon, 29 Feb 2016 12:43:48 -0430 Subject: Google APIs Rate Limit - Was: Re: google search threshold In-Reply-To: <726393422.785405.1456761234633.JavaMail.yahoo@mail.yahoo.com> References: <726393422.785405.1456761234633.JavaMail.yahoo@mail.yahoo.com> Message-ID: <56D47C4C.8000708@gmail.com> Hello, Something similar to this topic. The other day working with Google APIs (geolocation [1] ) I thought that in order to promote a little bit IPv6, Google (and others) might do something like: Google Maps Geocoding API Usage Limits With IPv4: 2,500 free requests per day (from IPv4 clients) 10 requests per second (from IPv4 clients) With IPv6 5,000 free requests per day (from ipv6 clients) 20 requests per second (from ipv6 clients) Summary: increase rate limit to v6 clients Regards, Alejandro, [1] El 2/29/2016 a las 11:23 AM, Philip Lavine via NANOG escribi?: > I have about 2000 users behind a single NAT. I have been looking at netflow, URL filter logs, IDS logs, etc. The traffic seems to be legit. > > I am going to move more users to IPv6 and divide some of the subnets into different NATS and see if that alleviates the traffic load. > Thanks for the advice. > -Philip > > > From: Damian Menscher > To: Philip Lavine > Cc: "nanog at nanog.org" > Sent: Friday, February 26, 2016 6:05 PM > Subject: Re: google search threshold > > On Fri, Feb 26, 2016 at 3:01 PM, Philip Lavine via NANOG wrote: > > Does anybody know what the threshold for google searches is before you get the captcha?I am trying to decide if I need to break up the overload NAT to a pool. > > > There isn't a threshold -- if you send automated searches from an IP, then it gets blocked (for a while). > > So... this comes down to how much you trust your machines/users. If you're a company with managed systems, then you can have thousands of users share the same IP without problems. But if you're an ISP, you'll likely run into problems much earlier (since users like their malware). > Some tips: - if you do NAT: try to partition users into pools so one abusive user can't get all your external IPs blocked - if you have a proxy: make sure it inserts the X-Forwarded-For header, and is restricted to your own users - if you're an ISP: IPv6 will allow each user to have their own /64, which avoids shared-fate from abusive ones > Damian (responsible for DDoS defense)-- Damian Menscher :: Security Reliability Engineer :: Google :: AS15169 > > From jared at puck.nether.net Mon Feb 29 18:01:12 2016 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 29 Feb 2016 13:01:12 -0500 Subject: Duplex negotiation over 100Base fibre In-Reply-To: <7024EEDA-5401-4470-B944-89DC33647DE1@lixfeld.ca> References: <7024EEDA-5401-4470-B944-89DC33647DE1@lixfeld.ca> Message-ID: <6D69A488-DCEA-4C2B-B4B3-E6AB43672477@puck.nether.net> > On Feb 29, 2016, at 11:07 AM, Jason Lixfeld wrote: > > Hello, > > My understanding is that for 1G and 10G optical networks, there is no concept of half-duplex mode, but I?m unclear about half duplex in the 100M optical world. Specifically, if I connect two 100Base-LX (or BX) transceivers together, is there a requirement for the controller(s on either side) to select between full or half duplex, either by static configuration, or auto-negotiation? I can say even at 1G speeds, the fiber is just the medium, the underlying data stream can still be half-duplex or require autonegotation or the lack of it. I recall many years ago having to adjust settings for GSR <-> Foundry negotiation and how it would vary depending on the device, so if you changed from GSR -> 6500/7600, you may have to make changes to maintain link. Having a standard device/switch/config will help you here. Most media converters I?ve seen have a switch on the side that lets you set if it should advertise autonegotation, take the super-cheap MC220L as an example, it has a switch for this purpose. After many years of hard coding things to gig/full, i?ve started to see the autonegotation work much better and require less custom coding of the config. This doesn?t stop someone from plugging in really-old stuff, and we still see people connecting at 10/half or 10/full when I really wonder what they are connecting. - Jared From saku at ytti.fi Mon Feb 29 19:06:23 2016 From: saku at ytti.fi (Saku Ytti) Date: Mon, 29 Feb 2016 21:06:23 +0200 Subject: sFlow vs netFlow/IPFIX In-Reply-To: <432E6F5B-E2C3-4E36-93CA-E51125FDE4DA@gmail.com> References: <20160229.131748.74688177.sthaug@nethelp.no> <56D44234.9080600@foobar.org> <432E6F5B-E2C3-4E36-93CA-E51125FDE4DA@gmail.com> Message-ID: On 29 February 2016 at 17:40, Phil Bedard wrote: > It would be interesting to get some data from vendors on what the actual limitation is. I know with some new platforms like the NCS 55XX from Cisco (BRCM Jericho) it has limited space for counters, but I don?t know if that contributes to its minimum 1:8000 Netflow sampling rate. The new PTX FPC supporting Netflow has a minimum of 1:1000. Are they are doing netflow in HW at all? To me it sounds like they might be doing it in LC CPU and HW is only doing sampled punting. Which would explain the performance hit. I would be very surprised if Jericho could do netflow in HW. And I'm 100% sure PE chip can't do netflow in HW. -- ++ytti From mureninc at gmail.com Mon Feb 29 20:36:55 2016 From: mureninc at gmail.com (Constantine A. Murenin) Date: Mon, 29 Feb 2016 12:36:55 -0800 Subject: google search threshold In-Reply-To: <56D4778A.3080109@winterei.se> References: <726393422.785405.1456761234633.JavaMail.yahoo@mail.yahoo.com> <1456764592334.38533@stargate.ca> <56D4778A.3080109@winterei.se> Message-ID: On 29 February 2016 at 08:53, Paul S. wrote: > DO's SG range is allocated out of a single /64 (I think?) and Google > basically asks for captcha on every single request over IPv6. :( The solution is to not signup with providers that have no respect for RFCs and BCPs. Proper VPS providers have no issue giving out a /64 to each customer, and many will even give out a /56 or /48 upon request as well. C. From pete at ots.utsystem.edu Mon Feb 29 05:29:30 2016 From: pete at ots.utsystem.edu (Pete Mitcheltree) Date: Sun, 28 Feb 2016 23:29:30 -0600 Subject: Media converter vendors - GFP/EoSDH In-Reply-To: References: <71b738ee-c5de-d598-f956-6c274367ea75@seacom.mu> Message-ID: <56D3D73A.4050100@ots.utsystem.edu> products in URL below may be of interest to you. http://www.overturenetworks.com/products/overture-networks-carrier-ethernet-products/overture-1400/ --pete On 2/28/2016 10:47 PM, Ramy Hashish wrote: > Hello Mark, > > Do you know anything about their MEF compliance? which of them is capable > of working in carrier-grade large scale environment? > > Ramy > > On Sun, Feb 28, 2016 at 5:49 PM, Mark Tinka wrote: > >> >> On 28/Feb/16 15:10, Ramy Hashish wrote: >> >>> Hello there, >>> >>> Any recommendations for Ethernet-SDH/SONET media converter vendors? >> Huawei, Tejas, BTI, ECI, Tejas, all come to mind on the lower price scale. >> >> Mark. >> From shopik+lists at nvcube.net Mon Feb 29 10:15:56 2016 From: shopik+lists at nvcube.net (Nikolay Shopik) Date: Mon, 29 Feb 2016 13:15:56 +0300 Subject: sFlow vs netFlow/IPFIX In-Reply-To: References: <56D3776F.7050508@foobar.org> <250778.1456713714@turing-police.cc.vt.edu> Message-ID: <56D41A5C.70907@nvcube.net> Cisco Nexus switches support sflow, since they are broadcom based. On 29/02/16 10:26, Pavel Odintsov wrote: > Cisco do not support this protocol at all (that's pretty weird, > really). From nmehrotra at riorey.com Mon Feb 29 16:48:15 2016 From: nmehrotra at riorey.com (Nitin Mehrotra) Date: Mon, 29 Feb 2016 16:48:15 +0000 Subject: Duplex negotiation over 100Base fibre In-Reply-To: <7024EEDA-5401-4470-B944-89DC33647DE1@lixfeld.ca> References: <7024EEDA-5401-4470-B944-89DC33647DE1@lixfeld.ca> Message-ID: <1456764524500.57757@riorey.com> >From all my observations, if both ends are 100Base-LX (or BX or T) and are set to auto-negotiate then they will negotiate to full-duplex. If one end is manually configured for full duplex and the other end is configured as auto then that end _may_ end up as half-duplex. This is particularly true when connecting a 1G port to a port configured as 100M full-duplex port. If the 1G is configured for auto-speed then it _will_ negotiate to 100M half-duplex resulting in traffic impact. HTH, Nitin ________________________________________ From: NANOG on behalf of Jason Lixfeld Sent: Monday, February 29, 2016 11:07 AM To: NANOG Subject: Duplex negotiation over 100Base fibre Hello, My understanding is that for 1G and 10G optical networks, there is no concept of half-duplex mode, but I?m unclear about half duplex in the 100M optical world. Specifically, if I connect two 100Base-LX (or BX) transceivers together, is there a requirement for the controller(s on either side) to select between full or half duplex, either by static configuration, or auto-negotiation? Thanks!