From aaron1 at gvtc.com Wed Aug 1 11:21:40 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 1 Aug 2018 06:21:40 -0500 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: <19C2613D-DB2D-4934-BCD3-A690E2AC6E1C@gvtc.com> As you all have said, to confirm, I use ssm Mcast to distribute TV from satellite down links in the headend, out to a few different remote head ends. From there it's converted back to RF video and sent to subscribers via cable or hfc plant Aaron > On Jul 31, 2018, at 5:15 PM, Job Snijders wrote: > >> On Tue, 31 Jul 2018 at 23:29, Sean Donelan wrote: >> >> Its tought to prove a negative. I'm extremely confident the answer is yes, >> public internet multicast is not viable. I did all the google searches, >> check all the usual CAIDA and ISP sites. IP Multicast is used on private >> enterprise networks, and some ISPs use it for some closed services. >> >> I got sent back with a random comment from a senior official saying "but >> I heard different." I bit my tongue, and said I would double (now >> quadruple) check. >> >> If any ISPs have working IP source-routed multicast on the public >> Internet that I missed, or what I got wrong. That's what content >> distribution networks (cdn's) are for instead. > > > > AS 2914 is working to fully dismantle all its Internet multicast related > infrastructure and configs. All MSDP sessions have been turned off, we have > deny-all filters for the multicast AFI, and the RPs have been shut down. > > For years we haven’t seen actual legit multicast traffic. Also the > multicast “Default-Free Zone” has always been severely partitioned. Not all > the players were peering with each other, which led to significant > complexity for any potential multicast source. > > Reasoning behind turning it off is that it limits the attack surface > (multicast can bring quite some state to the core), reduces the things we > need to test and qualify, and by taking this off the RFPs we can perhaps > consider more vendors. > > However, as you noted; multicast within a single administrative domain > (such as an access network distributing linear TV), or confined to > purpose-built L3VPNs very much is a thing. On the public Internet multicast > seems dead. > > Kind regards, > > Job From smeuse at mara.org Wed Aug 1 13:48:01 2018 From: smeuse at mara.org (Steve Meuse) Date: Wed, 1 Aug 2018 07:48:01 -0600 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: <19C2613D-DB2D-4934-BCD3-A690E2AC6E1C@gvtc.com> References: <19C2613D-DB2D-4934-BCD3-A690E2AC6E1C@gvtc.com> Message-ID: Can your hfc customers do an igmp join? No? Then it's probably not considered "public". -Steve On Wed, Aug 1, 2018 at 5:21 AM Aaron Gould wrote: > As you all have said, to confirm, I use ssm Mcast to distribute TV from > satellite down links in the headend, out to a few different remote head > ends. From there it's converted back to RF video and sent to subscribers > via cable or hfc plant > > Aaron > > > On Jul 31, 2018, at 5:15 PM, Job Snijders wrote: > > > >> On Tue, 31 Jul 2018 at 23:29, Sean Donelan wrote: > >> > >> Its tought to prove a negative. I'm extremely confident the answer is > yes, > >> public internet multicast is not viable. I did all the google searches, > >> check all the usual CAIDA and ISP sites. IP Multicast is used on private > >> enterprise networks, and some ISPs use it for some closed services. > >> > >> I got sent back with a random comment from a senior official saying "but > >> I heard different." I bit my tongue, and said I would double (now > >> quadruple) check. > >> > >> If any ISPs have working IP source-routed multicast on the public > >> Internet that I missed, or what I got wrong. That's what content > >> distribution networks (cdn's) are for instead. > > > > > > > > AS 2914 is working to fully dismantle all its Internet multicast related > > infrastructure and configs. All MSDP sessions have been turned off, we > have > > deny-all filters for the multicast AFI, and the RPs have been shut down. > > > > For years we haven’t seen actual legit multicast traffic. Also the > > multicast “Default-Free Zone” has always been severely partitioned. Not > all > > the players were peering with each other, which led to significant > > complexity for any potential multicast source. > > > > Reasoning behind turning it off is that it limits the attack surface > > (multicast can bring quite some state to the core), reduces the things we > > need to test and qualify, and by taking this off the RFPs we can perhaps > > consider more vendors. > > > > However, as you noted; multicast within a single administrative domain > > (such as an access network distributing linear TV), or confined to > > purpose-built L3VPNs very much is a thing. On the public Internet > multicast > > seems dead. > > > > Kind regards, > > > > Job > > From mankamis at cisco.com Wed Aug 1 02:43:10 2018 From: mankamis at cisco.com (Mankamana Mishra (mankamis)) Date: Wed, 1 Aug 2018 02:43:10 +0000 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> other than billing problem, is there any other reasons why multicast would not be viable for public internet ? Mankamana > On Jul 31, 2018, at 2:36 PM, Bill Woodcock wrote: > > > >> On Jul 31, 2018, at 2:28 PM, Sean Donelan wrote: >> >> Its tough to prove a negative. I'm extremely confident the answer is yes, public internet multicast is not viable. > > From a technical perspective, yeah, that’s right, but as you say, tough to prove a negative. If you want to give them a “why” it doesn’t work, Zhi-Li Zhang and I wrote that up fifteen years ago, when it became evident that it wasn’t going to happen. > > https://www.pch.net/resources/Papers/multicast-billing/multicast-billing-v10.pdf > > -Bill From rsk at gsp.org Wed Aug 1 15:19:36 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 1 Aug 2018 11:19:36 -0400 Subject: unwise filtering policy on abuse mailboxes In-Reply-To: References: <201807242314.w6ONEJNH007001@yuri.anime.net> <20180724233647.GA63038@meow.BKantor.net> <060EE445-5E5C-4B24-BF70-16626626711E@beckman.org> Message-ID: <20180801151936.GA11969@gsp.org> On Tue, Jul 24, 2018 at 05:53:48PM -0700, Dan Hollis wrote: > I'm saying people who filter their abuse mailboxes need to stop doing so. 1. They needed to stop doing so a few decades ago. Anybody still doing it today is doing it on purpose, which of course leads directly to the question: why? 2. In the case of this operation, perhaps it's because it has a very, VERY long history of support for spammers and other abusers. A quick glance at data-on-hand shows 250+ incidents over the past decade, and I'm sure that's only the surface. 3. There is no point whatsoever in reporting abuse to them. The most likely outcome of doing so is that you will be targeted for retaliation. 4. With that in mind, isn't it curious that I posted a comment in this thread on 7/27 and then on 7/28 observed this (heavily redacted) from their network space: Failed password for root from 116.206.72.123 Failed password for invalid user VM from 116.206.72.123 Failed password for invalid user localhost from 116.206.72.123 Failed password for root from 116.206.72.123 Failed password for invalid user sir from 116.206.72.123 Failed password for root from 116.206.72.123 ---rsk From rsk at gsp.org Wed Aug 1 15:22:50 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 1 Aug 2018 11:22:50 -0400 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: <20180801152250.GB11969@gsp.org> On Thu, Jul 26, 2018 at 09:51:04AM -0700, Aaron C. de Bruyn via NANOG wrote: > Capitalist solution: Build yet another IoT device that just does emergency > alerting. Please no. The IoT is already a security/privacy dumpster fire of enormous proportions and this will provide yet another vector for attacks. ---rsk From dwcarder at es.net Wed Aug 1 15:24:25 2018 From: dwcarder at es.net (Dale W. Carder) Date: Wed, 1 Aug 2018 10:24:25 -0500 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> References: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> Message-ID: <20180801152425.GF3558@cs-it-6805697.local> Thus spake Mankamana Mishra (mankamis) via NANOG (nanog at nanog.org) on Wed, Aug 01, 2018 at 02:43:10AM +0000: > other than billing problem, is there any other reasons why multicast would not be viable for public internet ? Hi Mankamana, You can find a reasonable overview here with respect to ASM: https://tools.ietf.org/html/draft-acg-mboned-deprecate-interdomain-asm-02 Dale From jtk at depaul.edu Wed Aug 1 15:36:07 2018 From: jtk at depaul.edu (John Kristoff) Date: Wed, 1 Aug 2018 10:36:07 -0500 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: <17b5e42c7c694dae9cd710731f0f050e@XCASPRD02.dpu.depaul.edu> References: <17b5e42c7c694dae9cd710731f0f050e@XCASPRD02.dpu.depaul.edu> Message-ID: <20180801103607.5d7b1d06@p50.localdomain> On Wed, 1 Aug 2018 02:43:10 +0000 "Mankamana Mishra (mankamis) via NANOG" wrote: > other than billing problem, is there any other reasons why multicast > would not be viable for public internet ? Two other significant contributing factors stem from complexity and security issues. Here are some references I'm familiar with: The last link was briefly maintained on Team Cymru's production template section, but it looks it is now gone and like this is the last copy of it I had before it was published a few years ago. John From mike.meredith at port.ac.uk Wed Aug 1 15:43:23 2018 From: mike.meredith at port.ac.uk (Mike Meredith) Date: Wed, 1 Aug 2018 16:43:23 +0100 Subject: unwise filtering policy on abuse mailboxes In-Reply-To: <20180801151936.GA11969@gsp.org> References: <201807242314.w6ONEJNH007001@yuri.anime.net> <20180724233647.GA63038@meow.BKantor.net> <060EE445-5E5C-4B24-BF70-16626626711E@beckman.org> <20180801151936.GA11969@gsp.org> Message-ID: <20180801164323.227ee4d0@scrofula.eps.is.port.ac.uk> On Wed, 1 Aug 2018 11:19:36 -0400, Rich Kulawiec may have written: > On Tue, Jul 24, 2018 at 05:53:48PM -0700, Dan Hollis wrote: > > I'm saying people who filter their abuse mailboxes need to stop doing > > so. > > 1. They needed to stop doing so a few decades ago. Anybody still doing > it today is doing it on purpose, which of course leads directly to the > question: why? Never assume malice ("on purpose") something which can be adequately explained by incompetance. -- Mike Meredith, University of Portsmouth Chief Systems Engineer, Hostmaster, Security, and Timelord! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From adam at davenpro.com Wed Aug 1 15:45:44 2018 From: adam at davenpro.com (Adam Davenport) Date: Wed, 1 Aug 2018 11:45:44 -0400 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: <110887A0-972C-44D0-A0B2-E207D4A2C58F@ianai.net> References: <110887A0-972C-44D0-A0B2-E207D4A2C58F@ianai.net> Message-ID: I can confirm that GTT does indeed filter IP sourced from 224.0.0.0/4 at its edge. On 7/31/2018 6:44 PM, Patrick W. Gilmore wrote: > It is hard to prove a negative. > > So let’s prove a positive. One of the largest (2nd largest?) transit networks on the planet just affirmatively stated they filter at their border. It is now possible to state that multicast is not ubiquitous on the Internet. > > If any other large transit network (L3, GTT, HE, Cogent, etc.) would like to confirm they filter at their borders as well, that would put the final nail in the coffin. > From jtk at depaul.edu Wed Aug 1 15:58:09 2018 From: jtk at depaul.edu (John Kristoff) Date: Wed, 1 Aug 2018 10:58:09 -0500 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: <110887A0-972C-44D0-A0B2-E207D4A2C58F@ianai.net> Message-ID: <20180801105809.571b630e@p50.localdomain> On Wed, 1 Aug 2018 15:45:44 +0000 Adam Davenport wrote: > I can confirm that GTT does indeed filter IP sourced from 224.0.0.0/4 at its edge. Do you mean sent to 224/4 or literally anything with a source address of 224/4? For those that are or are considering filtering, you might also want to consider limiting IGMP at router interfaces. The only known use of IGMP past the local link I'm aware of was for mtrace tool, but allowing it can pose some danger in two forms. One is yet another DDoS reflection and amplification vector, another is a some router system and configuration disclosure. See the following for details: In experiments I ran in early parts of that work I found that Cogent did not forward IGMP messages through its network in my tests, but this may be due to the routing hardware/software they were using at the time rather than an explicit filtering policy. John From streinerj at gmail.com Wed Aug 1 16:07:41 2018 From: streinerj at gmail.com (Justin M. Streiner) Date: Wed, 1 Aug 2018 12:07:41 -0400 (EDT) Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: <20180731174019.115ec162@p50.localdomain> References: <258fe76ff8ca4ee9b4da39f5ab42ad11@XCASPRD01-DFT.dpu.depaul.edu> <20180731174019.115ec162@p50.localdomain> Message-ID: On Tue, 31 Jul 2018, John Kristoff wrote: > Second best might be the Internet2 community where a number of > institutions that have always had it might still have it turned on. > Though there has been only one post in all of 2018 on their list if > that tells you anything. At my previous job (large .edu), we spoke MSDP with Internet2 through our regional I2 connector, however we turned that MSDP session off probably two years ago, and I don't think that session moved any useful traffic for probably two years before that. Multicast was used extensively within our network, but nothing outside for quite a while. I agree with general sentiment that multicast across the larger Internet is dead. Thank you jms From saku at ytti.fi Wed Aug 1 16:24:21 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 1 Aug 2018 19:24:21 +0300 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> References: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> Message-ID: Hey Mankamana, > other than billing problem, is there any other reasons why multicast would not be viable for public internet ? Imagine someone like youtube or netflix would like to use multicast, instead of caches. They'd need to start new multicast stream for every content with small delay (to get more viewers on given stream), how much delay would consumer tolerate before content starts? 1min? 5min? So every minute or every 5 minute new stream of movie would be sent, except it would need to be sent many times, for each bitrate supported. Each of these streams is wide (wider than unicast) HW state that needs to be stored on every device on path, for unicast we only store 1 narrow HW state per destination, for multicast we store 1 wide HW state per flow/stream, we don't have the hardware to do that, if there would be any significant demand for multicast. It only works when there is no use-case for it, and even then, it's insecure DoS vector. -- ++ytti From sean at donelan.com Wed Aug 1 16:25:16 2018 From: sean at donelan.com (Sean Donelan) Date: Wed, 1 Aug 2018 12:25:16 -0400 (EDT) Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: <19C2613D-DB2D-4934-BCD3-A690E2AC6E1C@gvtc.com> References: <19C2613D-DB2D-4934-BCD3-A690E2AC6E1C@gvtc.com> Message-ID: On Wed, 1 Aug 2018, Aaron Gould wrote: > As you all have said, to confirm, I use ssm Mcast to distribute TV from > satellite down links in the headend, out to a few different remote head > ends. From there it's converted back to RF video and sent to > subscribers via cable or hfc plant I'm aware that multicast is used extensively for "closed enterprise" networks in the financial and media industries. It seems to work well when a single organization is paying for the entire network. My executive official came from that background, so I get why someone from that world would think multicast is widely used. Asking enterprise network sales people, they keep saying Yes, of course we support multicast. That's why I wanted to hear from public Internet engineers if multicast was still viable on the *public Internet*. From hf0002+nanog at uah.edu Wed Aug 1 16:31:20 2018 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Wed, 1 Aug 2018 11:31:20 -0500 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: <19C2613D-DB2D-4934-BCD3-A690E2AC6E1C@gvtc.com> Message-ID: On Wed, Aug 1, 2018 at 11:27 Sean Donelan wrote: > On Wed, 1 Aug 2018, Aaron Gould wrote: > > As you all have said, to confirm, I use ssm Mcast to distribute TV from > > satellite down links in the headend, out to a few different remote head > > ends. From there it's converted back to RF video and sent to > > subscribers via cable or hfc plant > > I'm aware that multicast is used extensively for "closed enterprise" > networks in the financial and media industries. It seems to work well > when a single organization is paying for the entire network. > > My executive official came from that background, so I get why someone > from that world would think multicast is widely used. Asking enterprise > network sales people, they keep saying Yes, of course we support > multicast. > > That's why I wanted to hear from public Internet engineers if multicast > was still viable on the *public Internet*. I'd say no - even though we have done inter-AS multicast before, it's only been with our direct peers. From jeffshultz at sctcweb.com Wed Aug 1 17:01:51 2018 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Wed, 1 Aug 2018 10:01:51 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <20180801152250.GB11969@gsp.org> References: <20180801152250.GB11969@gsp.org> Message-ID: If someone wants that sort of thing... does anyone still make AM transistor radios? On Wed, Aug 1, 2018 at 8:25 AM Rich Kulawiec wrote: > > On Thu, Jul 26, 2018 at 09:51:04AM -0700, Aaron C. de Bruyn via NANOG wrote: > > Capitalist solution: Build yet another IoT device that just does emergency > > alerting. > > Please no. The IoT is already a security/privacy dumpster fire of enormous > proportions and this will provide yet another vector for attacks. > > ---rsk > -- Jeff Shultz -- Like us on Social Media for News, Promotions, and other information!!                      _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_ From matt at netfire.net Wed Aug 1 17:11:15 2018 From: matt at netfire.net (Matt Harris) Date: Wed, 1 Aug 2018 12:11:15 -0500 Subject: Avast / Privax abuse contact Message-ID: Anybody know anyone at or anything about Privax or Avast? AS 198605 is announcing the problem networks. Getting a ton of SIP brute force attacks from their space, and emails with addresses/timestamps to the abuse contacts listed at RIRs/etc have not yieled any responses. Attacks still coming. Thanks! From marshall.eubanks at gmail.com Wed Aug 1 17:11:44 2018 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Wed, 1 Aug 2018 13:11:44 -0400 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: At a recent meeting on space policy a representative from Hughes/Echostar told us that, as they provide satellite connectivity to gas stations in the fire regions, they have been working with emergency services to give fire fighters directions to where they can go to get gas for their trucks, based on their knowledge of which stations are up and have not been sold out. Putting alerts (whether by landline or satellite) on screens at the pumps or in convenience stores does not seem like much of a stretch, but I can't see any indication that this is being done. Regards Marshall On Fri, Oct 13, 2017 at 4:59 PM, Sean Donelan wrote: > > Has anyone heard if the smart speaker companies (Amazon Echo, Google Home) > plan to include emergency alert capability? An estimate 10% of households > own a smart speaker, and Gartner (well-known for its forecasting accuracy) > predicts 75% of US households will have a smart speaker by 2020. > > Although most silicon valley tech nerds are still in the "invincible" > years, were the california fires close enough to silicon valley that smart > speaker developers might think an emergency could affect them. And an > emergency alert capability in their smart speakers might be important? > > From michael at wi-fiber.io Wed Aug 1 17:27:24 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Wed, 1 Aug 2018 11:27:24 -0600 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> Message-ID: What if... Bear with me for a moment here, we don't try to force VoD onto a multicast setup? Multicast is used extensively by all major ISPs(if they have the rights) to deliver IPTV. One issue you brought up is people unwillin to wait 1 or 5 mins for a show, well before the days of youtube people waited weeks for OTA programming that started with or without delay, depending on how many relays you were going through. As a use case of multicast over the internet, a Real time TV rebroadcaster would be a really good use case. The federal govt already subsidises super expensive energy hogging TV broadcast towers, who's to say they wouldn't prefer it to just go over the interwebs? Bit rate's not a problem, a 720i stream takes 1 or 2 mbps, which is a fraction of a home broadband connection(25mbps down 3 up, last time i checked). I think we all on nanog would agree internet is more important than TV. Govt money might better be spent on a better internet than TV radios. Of course that might mean some internet backbone upgrades(maybe even govt subsidised upgrade), but i would never say that there isn't a commercial use case for it. On 1 August 2018 at 10:24, Saku Ytti wrote: > Hey Mankamana, > > > other than billing problem, is there any other reasons why multicast > would not be viable for public internet ? > > Imagine someone like youtube or netflix would like to use multicast, > instead of caches. They'd need to start new multicast stream for every > content with small delay (to get more viewers on given stream), how > much delay would consumer tolerate before content starts? 1min? 5min? > So every minute or every 5 minute new stream of movie would be sent, > except it would need to be sent many times, for each bitrate > supported. > Each of these streams is wide (wider than unicast) HW state that needs > to be stored on every device on path, for unicast we only store 1 > narrow HW state per destination, for multicast we store 1 wide HW > state per flow/stream, we don't have the hardware to do that, if there > would be any significant demand for multicast. > It only works when there is no use-case for it, and even then, it's > insecure DoS vector. > > -- > ++ytti > From lambert at psc.edu Wed Aug 1 15:51:47 2018 From: lambert at psc.edu (Michael H Lambert) Date: Wed, 1 Aug 2018 11:51:47 -0400 Subject: Windstream Contact Message-ID: <3416B146-D844-4DA0-ADFE-D60BDD6D6953@psc.edu> Could someone from Windstream please contact me off-list? We have a peering issue. Thanks, Michael ----- Michael H Lambert, GigaPoP Manager Phone: +1 412 268-4960 Pittsburgh Supercomputing Center/3ROX FAX: +1 412 268-5832 300 S Craig St, Pittsburgh, PA 15213 USA lambert at psc.edu From jimpop at domainmail.org Wed Aug 1 15:56:02 2018 From: jimpop at domainmail.org (Jim Popovitch) Date: Wed, 01 Aug 2018 11:56:02 -0400 Subject: [NANOG] Re: unwise filtering policy on abuse mailboxes In-Reply-To: <20180801151936.GA11969@gsp.org> References: <201807242314.w6ONEJNH007001@yuri.anime.net> <20180724233647.GA63038@meow.BKantor.net> <060EE445-5E5C-4B24-BF70-16626626711E@beckman.org> <20180801151936.GA11969@gsp.org> Message-ID: <1533138962.1553.3.camel@domainmail.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2018-08-01 at 11:19 -0400, Rich Kulawiec wrote: > 1. They needed to stop doing so a few decades ago.  Anybody still > doing it today is doing it on purpose, which of course leads directly > to the question: why? One reason as to "why" is that there is no good way to specify an alternate abuse@ address, where said alternate abuse address is on a completely different (sub)?domain, ala ruf/rua=. So then it becomes an issue of not filtering the base domain, which would be a massive headache for those who follow the 2 age-old smtp golden rules:  -- "never accept email you can't deliver" -- "reject at connect, never bounce" 49% of folks would've said whois could have been a great place for an Abuse contact... and another 49% would say security.txt is the place. The end result is there is zero standard nor recommended way, imho. - -Jim P. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAlth2BMACgkQJxVetMRa JwVVvxAAjF5Nzd2NvilFWSJWc8Mo1Yl9rckNi4pMf0hdU3NbHBAq/Q1gbe/XfHu7 nMyHc0V9Puwm0eb1LPHldwVwjcxG8SRYAztjagUFEhnes1SyUq+c5UdG2pzkn03A SMgNFKiwLQdqhtnGsjpp9YFEGyrzHYIuBxzqSXTysXgg55nzxP1kQ/BEk2uKzhBO ///M8+cgFIsK+9SgYvYHh1dLTi+vK6PI79dUT6JNcK5imirbKORCwL/05rJp7PXx VG/0mBxWFcw1/5e2uDcu1eEhYboNH1QVf6O4a+HUS37HhJSayVC2AKr5rTm8/NWs YpvO4mZ0Sy/3o0tsZp1gahKRrlN5VZzbuKjuGVD71OY+Rwaxsga6YQJGajOUs8Rc 8D3rT7lC2c7V2xooOKF5FnOM8B7xJwbwb3M9IMWmsB7d2c+WvdBvzZGiO8Gzdah5 giiYh2ninyVQdJ8diIuQChJ/hpBakuXmtq+RIHWpEgfF//tUux/rCI1NG8DJbs73 UuwuQmQ7goOs43/FGEV+hoqAdKH7eY3/8MNFajoqEmvQSKWpUm+7nZtcaLxVDM+J K1uXYKv9Sy6ZHdQr2BPTNra2RlrhsTEKWZLp4/UVH/S+dEhK56zwKX1tM0DgDwtQ t1pBBC4+n+2PmeqIB+9VIF24D0dPsSTaDscsbWoey2enb0pGCEI= =MoLL -----END PGP SIGNATURE----- From mfidelman at meetinghouse.net Wed Aug 1 17:38:56 2018 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 1 Aug 2018 13:38:56 -0400 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> Message-ID: On 8/1/18 12:24 PM, Saku Ytti wrote: > Hey Mankamana, > >> other than billing problem, is there any other reasons why multicast would not be viable for public internet ? > Imagine someone like youtube or netflix would like to use multicast, > instead of caches. They'd need to start new multicast stream for every > content with small delay (to get more viewers on given stream), how > much delay would consumer tolerate before content starts? 1min? 5min? > So every minute or every 5 minute new stream of movie would be sent, > except it would need to be sent many times, for each bitrate > supported. > Each of these streams is wide (wider than unicast) HW state that needs > to be stored on every device on path, for unicast we only store 1 > narrow HW state per destination, for multicast we store 1 wide HW > state per flow/stream, we don't have the hardware to do that, if there > would be any significant demand for multicast. > It only works when there is no use-case for it, and even then, it's > insecure DoS vector. > Personally, I think the use case is a lot stronger for multi-person video conferencing. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From tarko at lanparty.ee Wed Aug 1 17:43:03 2018 From: tarko at lanparty.ee (Tarko Tikan) Date: Wed, 1 Aug 2018 20:43:03 +0300 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> Message-ID: <13dc0c0e-6a42-f1f9-e3a8-37073ebbef02@lanparty.ee> hey, > What if... Bear with me for a moment here, we don't try to force VoD onto a > multicast setup? Multicast is used extensively by all major ISPs(if they > have the rights) to deliver IPTV. We are an IPTV provider in europe and we definetly see share of linear TV (that we are delivering via intra-AS multicast today) decreasing YOY. OTT plays a big part but even more customers use our own on-demand services including network PVR. Numbers don't add up yet but in 3-4 years even the intra-AS multicast will not make sense for us any more, easier/better to deliver everything via unicast. -- tarko From saku at ytti.fi Wed Aug 1 17:47:43 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 1 Aug 2018 20:47:43 +0300 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> Message-ID: Hey Miles and Michael, It is entirely fair to debate what the use-case would be, the underlaying technical problem remains the same, if it becomes useful (globally) we don't have the hardware to cater for it. I'm sure both of your use cases are used extensively in internal network. I've worked for company who distributed broadcast TV on their MPLS IP backbone, two-plane network, red and blue, one copy for each tv channel on both planes and far-end drops redundant copy. Very attractive solution commercially for client and provider. But no potential for global scale. On Wed, 1 Aug 2018 at 20:44, Miles Fidelman wrote: > > On 8/1/18 12:24 PM, Saku Ytti wrote: > > > Hey Mankamana, > > > >> other than billing problem, is there any other reasons why multicast would not be viable for public internet ? > > Imagine someone like youtube or netflix would like to use multicast, > > instead of caches. They'd need to start new multicast stream for every > > content with small delay (to get more viewers on given stream), how > > much delay would consumer tolerate before content starts? 1min? 5min? > > So every minute or every 5 minute new stream of movie would be sent, > > except it would need to be sent many times, for each bitrate > > supported. > > Each of these streams is wide (wider than unicast) HW state that needs > > to be stored on every device on path, for unicast we only store 1 > > narrow HW state per destination, for multicast we store 1 wide HW > > state per flow/stream, we don't have the hardware to do that, if there > > would be any significant demand for multicast. > > It only works when there is no use-case for it, and even then, it's > > insecure DoS vector. > > > Personally, I think the use case is a lot stronger for multi-person > video conferencing. > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > -- ++ytti From saku at ytti.fi Wed Aug 1 17:51:13 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 1 Aug 2018 20:51:13 +0300 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> Message-ID: On Wed, 1 Aug 2018 at 20:47, Saku Ytti wrote: > I'm sure both of your use cases are used extensively in internal > network. I've worked for company who distributed broadcast TV on their > MPLS IP backbone, two-plane network, red and blue, one copy for each > tv channel on both planes and far-end drops redundant copy. Very > attractive solution commercially for client and provider. But no > potential for global scale. Just to clarify what I mean by 'broadcast TV', these streams were not received by set-top boxes receiving IP packets. End-users were cable/antennae users, 'client' was receiving the content at antennae site to be transmitted over air. Classically these are separate purpose built networks, which are very expensive, so in this particular case everyone won, except the legacy provider who was billing for the purpose built network. -- ++ytti From sean at donelan.com Wed Aug 1 18:14:20 2018 From: sean at donelan.com (Sean Donelan) Date: Wed, 1 Aug 2018 14:14:20 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <20180801152250.GB11969@gsp.org> Message-ID: Heavy sigh. Its not about AM radios, although some tinkers have hooked up raspberry pi's to weather band radio chips. Its a cool hack, but not the point. Today, 99% of emergency alerts are diissiminated via the Internet, in addition to other channels (over the air broadcasters, cable, twitter, even Google maps and Google search show emergency alerts, etc). You don't want a single dissimination method. You want diversity of warning channels. For example, only 77 cell phone companies participate in Wireless Alerts. While you are roaming on another carrier's tower, even if your home carrier participates, your current roaming tower might not transmit any wireless alerts about that wildfire heading your way. https://www.fcc.gov/pshs/docs/services/cmas/WEACarrierRegistry121313.xls Nonparticipating cell phone companies are required to inform customers at the point of sale they do not provide wireless alerts. Roaming customers often don't know. The point of the study in proposed bill is customers of Netflix and Spotify (just to pick on them because everyone seems too) watching videos on "Smart TVs" or listening on "Smart Speakers" may not realize those devices won't get emergency alerts like their old-fashion AM/FM radios and over-the-air TVs. If Netflix or Spotify customers are watching or listening on their "Smart Phones", they do get emergency alerts from the cell phone provider. Much like watching Netflix and listening to Spotify on smart phones, Netflix and Spotify do not control the alert function on Smart TVs and Smart Speakers. The alarm API of smart devices is predominately controlled by Amazon Alexa (34%), Google Assistant (34%), Apple Siri (10%), and others (21%). The message waiting notification API isn't a real substitute for an emergency alert API. Even if you created a new Internet of Thing warning device, that device would still have to work in the ecosystems controlled by Amazon Alexa, Google Assistant, Apple Siri. The API product managers at Amazon, Google and Apple make those decisions. Netflix and Spotify -- wrong place for emergency alerts, over the top content doesn't know what else is happening with the user interface on the smart device. Internet Service Providers -- wrong place for emergency alerts, too low in communication layers to break in. ISPs keep wanting to insert advertisements in web pages -- bad idea. Smart device APIs (Alexa, Google Assistant, Apple Siri) already mediate user interaction. The "intelligent assistant" seems like the best place for the user to control how they receive emergency alerts. On Wed, 1 Aug 2018, Jeff Shultz wrote: > If someone wants that sort of thing... does anyone still make AM > transistor radios? >>> Capitalist solution: Build yet another IoT device that just does emergency >>> alerting. >> Please no. The IoT is already a security/privacy dumpster fire of enormous >> proportions and this will provide yet another vector for attacks. From kmedcalf at dessus.com Wed Aug 1 19:44:04 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 01 Aug 2018 13:44:04 -0600 Subject: California fires: smart speakers and emergency alerts In-Reply-To: Message-ID: <562d4d6a29a6d349959a0c5a956ee21f@mail.dessus.com> >The point of the study in proposed bill is customers of Netflix and >Spotify (just to pick on them because everyone seems too) watching videos >on "Smart TVs" or listening on "Smart Speakers" may not realize those >devices won't get emergency alerts like their old-fashion AM/FM radios >and over-the-air TVs. If Netflix or Spotify customers are watching or >listening on their "Smart Phones", they do get emergency alerts from the >cell phone provider. I haven't used an "over-the-air" TV in fifty years ... >Much like watching Netflix and listening to Spotify on smart phones, >Netflix and Spotify do not control the alert function on Smart TVs >and >Smart Speakers. The alarm API of smart devices is predominately >controlled >by Amazon Alexa (34%), Google Assistant (34%), Apple Siri (10%), and >others (21%). The message waiting notification API isn't a real >substitute >for an emergency alert API. Thank the lord I have none of those things and never intend to have any of those things. Also, I only ever use "stupid" devices. Nary a "Smart" device is permitted anywhere near me or any network I use. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From dovid at telecurve.com Wed Aug 1 20:08:59 2018 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 1 Aug 2018 16:08:59 -0400 Subject: Avast / Privax abuse contact In-Reply-To: References: Message-ID: Matt, Rarely do we ever get a response when we file complaints for SIP traffic. We simply use Kamilio and where have known bad UA's we just drop the packets and ban the IP's (using Fail2Ban), it will save you a lot of grief. It's like trying to go after every get request to phpMyAdmin. On Wed, Aug 1, 2018 at 1:11 PM, Matt Harris wrote: > Anybody know anyone at or anything about Privax or Avast? AS 198605 is > announcing the problem networks. > > Getting a ton of SIP brute force attacks from their space, and emails with > addresses/timestamps to the abuse contacts listed at RIRs/etc have not > yieled any responses. Attacks still coming. > > Thanks! > From nop at imap.cc Wed Aug 1 20:58:10 2018 From: nop at imap.cc (nop at imap.cc) Date: Wed, 01 Aug 2018 13:58:10 -0700 Subject: Avast / Privax abuse contact In-Reply-To: References: Message-ID: <1533157090.1574985.1460424968.2120F51C@webmail.messagingengine.com> On Wed, Aug 1, 2018, at 10:11 AM, Matt Harris wrote: > Anybody know anyone at or anything about Privax or Avast? AS 198605 is > announcing the problem networks. Chances are slim you'll get a useful response. Crappy "HIDE YOUR ACTIVITY TORRENT FREELY" VPN provider that has a TON of abusive traffic, tons of IP space with falsified whois data and falsified country/geolocation info. From jbarrett at calltower.com Wed Aug 1 22:34:16 2018 From: jbarrett at calltower.com (Jack Barrett) Date: Wed, 1 Aug 2018 22:34:16 +0000 Subject: Avast / Privax abuse contact In-Reply-To: References: Message-ID: I agree. Complaints are rarely acknowledged and never promptly. We simply use a combination of Fail2Ban and remote trigger black hole filtering to drop the inbound traffic from probing IPs at our borders. -----Original Message----- From: NANOG On Behalf Of Dovid Bender Sent: Wednesday, August 1, 2018 3:09 PM To: Matt Harris Cc: North American Network Operators' Group Subject: Re: Avast / Privax abuse contact Matt, Rarely do we ever get a response when we file complaints for SIP traffic. We simply use Kamilio and where have known bad UA's we just drop the packets and ban the IP's (using Fail2Ban), it will save you a lot of grief. It's like trying to go after every get request to phpMyAdmin. On Wed, Aug 1, 2018 at 1:11 PM, Matt Harris wrote: > Anybody know anyone at or anything about Privax or Avast? AS 198605 > is announcing the problem networks. > > Getting a ton of SIP brute force attacks from their space, and emails > with addresses/timestamps to the abuse contacts listed at RIRs/etc > have not yieled any responses. Attacks still coming. > > Thanks! > From mark.tinka at seacom.mu Thu Aug 2 06:15:29 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Aug 2018 08:15:29 +0200 Subject: SAFNOG-4/EANOG/tzNOG Registration Now Open! Message-ID: <3f5a2a26-3f48-e1d7-5097-ac888349d5d9@seacom.mu> Hi all. Pleased to inform you that registration for the upcoming SAFNOG-4/EANOG/tzNOG meeting in Dar Es Salaam, 24th - 29th September, is now open. You may register at the URL below:     http://www.safnog.org/ We look forward to seeing you there. Mark. From sean at donelan.com Thu Aug 2 15:27:49 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 2 Aug 2018 11:27:49 -0400 (EDT) Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: Thanks to everyone that helped. Off-list I heard from network engineers at several global Internet providers. They all confirmed that multicast is no longer supported on their public Internet backbones, no matter what their sales people might say. If someone opened a multicast trouble ticket, likely no one in their NOC would know what to do with it. They acknowledged there might be some old multicast configs on Internet facing routers, and eventually they'll clean those out. Backbone network engineers are fairly blunt. Multicast is being used in various private IP networks. It seems to work very well for satellite content distribution because multicast doesn't require ack's. Enterprise networks also use multicast. From johnl at iecc.com Thu Aug 2 18:55:41 2018 From: johnl at iecc.com (John Levine) Date: 2 Aug 2018 14:55:41 -0400 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: Message-ID: <20180802185542.3E97C200334ABB@ary.qy> In article you write: >Multicast is being used in various private IP networks. It seems to work >very well for satellite content distribution because multicast doesn't >require ack's. Enterprise networks also use multicast. I would think it'd work fine on private networks, but since there's no authentication, on the public Internet how could you tell the multicast you want from random malicious junk on the same IP address? From sean at donelan.com Thu Aug 2 19:26:03 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 2 Aug 2018 15:26:03 -0400 (EDT) Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: <20180802185542.3E97C200334ABB@ary.qy> References: <20180802185542.3E97C200334ABB@ary.qy> Message-ID: On Thu, 2 Aug 2018, John Levine wrote: > In article you write: >> Multicast is being used in various private IP networks. It seems to work >> very well for satellite content distribution because multicast doesn't >> require ack's. Enterprise networks also use multicast. > > I would think it'd work fine on private networks, but since there's no > authentication, on the public Internet how could you tell the > multicast you want from random malicious junk on the same IP address? They use some type of encryption to authenticate the data. Satellite distribution networks usually encrypt both the satellite signal so only authorized receivers get the download. The multicast data files are also separately encrypted/signed/checked. On private/enterprise networks, I guess they just trust its a controlled network. On the public Internet. Gosh darn, I don't know, shrug? From michel.py at tsisemi.com Thu Aug 2 20:27:16 2018 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 2 Aug 2018 20:27:16 +0000 Subject: [Nanog] BGPMon RPKI Validation Failed (Code: 9) Message-ID: Hi Nanog, I received recently some of these messages, and I don't understand the logic of them. If there is no ROA found, the code should be 1, and the status unknown / not found. What is the logic behind getting a Validation failure if there is no ROA ? Please help RPKI n00b, Thanks. ==================================================================== RPKI Validation Failed (Code: 9) ==================================================================== Your prefix: 216.230.25.0/24: Prefix Description: TSI Semiconductors Update time: 2018-07-20 00:10 (UTC) Detected by #peers: 4 Detected prefix: 216.230.25.0/24 Announced by: AS14051 (Consolidated Communications, Inc.) Upstream AS: AS2914 (NTT America, Inc.) ASpath: 25291 2914 14051 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=82315862 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=82315862 RPKI Status: No ROA found TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From job at instituut.net Thu Aug 2 20:31:36 2018 From: job at instituut.net (Job Snijders) Date: Thu, 2 Aug 2018 22:31:36 +0200 Subject: [Nanog] BGPMon RPKI Validation Failed (Code: 9) In-Reply-To: References: Message-ID: Dear Michel, This question is probably best answered by Andree Toonk from the BGPMon project. I've CCed him. Kind regards, Job On Thu, Aug 2, 2018 at 10:27 PM, Michel Py wrote: > Hi Nanog, > > I received recently some of these messages, and I don't understand the logic of them. > If there is no ROA found, the code should be 1, and the status unknown / not found. > What is the logic behind getting a Validation failure if there is no ROA ? > > Please help RPKI n00b, > Thanks. > > > ==================================================================== > > RPKI Validation Failed (Code: 9) > > ==================================================================== > > Your prefix: 216.230.25.0/24: > > Prefix Description: TSI Semiconductors > > Update time: 2018-07-20 00:10 (UTC) > > Detected by #peers: 4 > > Detected prefix: 216.230.25.0/24 > > Announced by: AS14051 (Consolidated Communications, Inc.) > > Upstream AS: AS2914 (NTT America, Inc.) > > ASpath: 25291 2914 14051 > > Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=82315862 > > Mark as false alert: https://portal.bgpmon.net/fp.php?aid=82315862 > > RPKI Status: No ROA found > > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From surfer at mauigateway.com Thu Aug 2 21:25:19 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 2 Aug 2018 14:25:19 -0700 Subject: possible hawaii weather issue next week Message-ID: <20180802142519.F785D5A7@m0117565.ppops.net> If you have stuff in Hawaii, you might want to start thinking about your DR plan. Things can change a lot for the better in 7 days, but they can also get ugly fast. Best to prepare just in case... https://www.nhc.noaa.gov/refresh/graphics_ep5+shtml/204426.shtml?cone https://www.nhc.noaa.gov/refresh/graphics_ep5+shtml/204426.shtml?tswind120 M is >110MPH scott From jheitz at cisco.com Thu Aug 2 21:33:33 2018 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Thu, 2 Aug 2018 21:33:33 +0000 Subject: Confirming source-routed multicast is dead on the public Internet Message-ID: Hey, there's a better way. Split the movie into segments: Segment 1: Minute 1. Segment 2: Minute 2. Segment 3: Minutes 3,4. Segment 4: Minutes 5-8. Segment 5: Minutes 9-16. etc. Then send each segment in a loop. Each receiver receives every loop simultaneously. Each segment may start receiving part way through, but then it starts again. By the time a segment needs to play, it is completely received. A 128 minute movie needs 8 streams. While waiting for the first minute, you can play ads :) The shorter segments don't need to be sent for long: Receivers can stop receiving the short segments once they have received one loop of it. When no receiver is receiving a loop, you can stop sending it. Regards, Jakob. -----Original Message----- Date: Wed, 1 Aug 2018 19:24:21 +0300 From: Saku Ytti Imagine someone like youtube or netflix would like to use multicast, instead of caches. They'd need to start new multicast stream for every content with small delay (to get more viewers on given stream), how much delay would consumer tolerate before content starts? 1min? 5min? So every minute or every 5 minute new stream of movie would be sent, except it would need to be sent many times, for each bitrate supported. From saku at ytti.fi Thu Aug 2 21:42:29 2018 From: saku at ytti.fi (Saku Ytti) Date: Fri, 3 Aug 2018 00:42:29 +0300 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: Hey, On Fri, 3 Aug 2018 at 00:36, Jakob Heitz (jheitz) via NANOG wrote: > Hey, there's a better way. > Split the movie into segments: > Segment 1: Minute 1. > Segment 2: Minute 2. > Segment 3: Minutes 3,4. > Segment 4: Minutes 5-8. > Segment 5: Minutes 9-16. > etc. > Then send each segment in a loop. > Each receiver receives every loop simultaneously. > Each segment may start receiving part way through, but then it starts again. > By the time a segment needs to play, it is completely received. > A 128 minute movie needs 8 streams. > While waiting for the first minute, you can play ads :) > The shorter segments don't need to be sent for long: > Receivers can stop receiving the short segments once they have received one loop of it. > When no receiver is receiving a loop, you can stop sending it. Cute :). Well 8*bitrates, but nice optimisation to make stream count finite. Of course at cost of quality, as receiver needs up-speed of 8x at start. Interesting side-effect, quality increases as movie progresses :) -- ++ytti From saku at ytti.fi Thu Aug 2 21:45:06 2018 From: saku at ytti.fi (Saku Ytti) Date: Fri, 3 Aug 2018 00:45:06 +0300 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: On Fri, 3 Aug 2018 at 00:42, Saku Ytti wrote: > Cute :). Well 8*bitrates, but nice optimisation to make stream count > finite. Of course at cost of quality, as receiver needs up-speed of 8x > at start. Interesting side-effect, quality increases as movie > progresses :) I may have worded up-speed potentially ambiguously, I mean over-speed, meaning access needs higher than stream bitrate to receive stream of specific bitrate. In practical world, of course already very problematic scenario for most NFLX consumers. -- ++ytti From jheitz at cisco.com Thu Aug 2 21:52:26 2018 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Thu, 2 Aug 2018 21:52:26 +0000 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: <906631dc728a4121b81b5dd70a95fe29@XCH-ALN-014.cisco.com> ok. Play 2 minutes of ads at the start and save a stream. Play another 2 minutes of ads every 16 minutes, then the maximum number of streams is 4. The ads can be received in a single stream or be received after the shorter streams have completed. Regards, Jakob. -----Original Message----- From: Saku Ytti Sent: Thursday, August 2, 2018 2:42 PM To: Jakob Heitz (jheitz) Cc: nanog at nanog.org Subject: Re: Confirming source-routed multicast is dead on the public Internet Hey, On Fri, 3 Aug 2018 at 00:36, Jakob Heitz (jheitz) via NANOG wrote: > Hey, there's a better way. > Split the movie into segments: > Segment 1: Minute 1. > Segment 2: Minute 2. > Segment 3: Minutes 3,4. > Segment 4: Minutes 5-8. > Segment 5: Minutes 9-16. > etc. > Then send each segment in a loop. > Each receiver receives every loop simultaneously. > Each segment may start receiving part way through, but then it starts again. > By the time a segment needs to play, it is completely received. > A 128 minute movie needs 8 streams. > While waiting for the first minute, you can play ads :) > The shorter segments don't need to be sent for long: > Receivers can stop receiving the short segments once they have received one loop of it. > When no receiver is receiving a loop, you can stop sending it. Cute :). Well 8*bitrates, but nice optimisation to make stream count finite. Of course at cost of quality, as receiver needs up-speed of 8x at start. Interesting side-effect, quality increases as movie progresses :) -- ++ytti From jheitz at cisco.com Thu Aug 2 21:56:32 2018 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Thu, 2 Aug 2018 21:56:32 +0000 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: You could put this multicast receiver into the last hop before the customer and then send unicast to the customer. Regards, Jakob. -----Original Message----- From: Saku Ytti Sent: Thursday, August 2, 2018 2:45 PM To: Jakob Heitz (jheitz) Cc: nanog at nanog.org Subject: Re: Confirming source-routed multicast is dead on the public Internet On Fri, 3 Aug 2018 at 00:42, Saku Ytti wrote: > Cute :). Well 8*bitrates, but nice optimisation to make stream count > finite. Of course at cost of quality, as receiver needs up-speed of 8x > at start. Interesting side-effect, quality increases as movie > progresses :) I may have worded up-speed potentially ambiguously, I mean over-speed, meaning access needs higher than stream bitrate to receive stream of specific bitrate. In practical world, of course already very problematic scenario for most NFLX consumers. -- ++ytti From surfer at mauigateway.com Thu Aug 2 22:56:39 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 2 Aug 2018 15:56:39 -0700 Subject: possible hawaii weather issue next week Message-ID: <20180802155639.F785AB9C@m0117565.ppops.net> ________________________________ If you have stuff in Hawaii, you might want to start thinking about your DR plan. Things can change a lot for the better in 7 days, but they can also get ugly fast. Best to prepare just in case... https://www.nhc.noaa.gov/refresh/graphics_ep5+shtml/204426.shtml?cone https://www.nhc.noaa.gov/refresh/graphics_ep5+shtml/204426.shtml?tswind120 M is >110MPH -------------------------------------------- --- radevita at mejeticks.com wrote: From: Robert DeVita Especially with the main carrier Hotel being located next to the ocean. -------------------------------------------- I'm guessing you mean DR Fortress. Most everything is next to the ocean here. :) However, DRF is likely pretty well protected from storm surge from a hurricane. It's also pretty well protected from flying debris, which is the main worry, especially when the winds are in excess of 100MPH. However, other facilities will have trouble (electric, fuel, etc), thus my suggestion to dust off DR plans and test if you haven't. We're the closest to the Asia Pacific countries you can get and still be in a US state and, as well, a good timezone between west coast going home and Asia coming in, so there may be a lot of folks here for some of the big networks, which is why I sent out the note. scott From andree+nanog at toonk.nl Fri Aug 3 01:28:51 2018 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 02 Aug 2018 18:28:51 -0700 Subject: [Nanog] BGPMon RPKI Validation Failed (Code: 9) In-Reply-To: References: Message-ID: <5B63AFD3.8050504@toonk.nl> Hi Michel, it looks likes you have RPKI validation enabled for this prefix in BGPmon.net. This will tell BGPmon to run the RPKI validation checks for the prefix and alert you if there's no valid ROA found. This bgpmon alert below is from July 20 which was right around the time the ROA was created, so I'm guessing the ROA hadn't fully propagated or rsync'd with our systems yet. Either way the BGPmon systems considers this prefix as RPKI valid now and it looks like these alerts have stopped for you: $ whois -h whois.bgpmon.net 216.230.25.0/24 Prefix: 216.230.25.0/24 Prefix description: Created by CCI on behalf of TSI Semiconductors Country code: US Origin AS: 14051 Origin AS Name: Consolidated Communications, Inc. *RPKI status: ROA validation successful* First seen: 2018-04-24 Last seen: 2018-08-01 Little known but handy feature to get all ROA details from the CLI: $ whois -h whois.bgpmon.net " --roa 14051 216.230.25.0/24" *0 - Valid* ------------------------ ROA Details ------------------------ Origin ASN: AS14051 Not valid Before: 2018-07-19 04:00:00 Not valid After: 2028-07-19 04:00:00 Expires in 9y350d22h43m31.3999999761581s Trust Anchor: rpki.arin.net Prefixes: 216.230.25.0/24 Ping me directly for any follow up questions Cheers Andree (BGPmon) My secret spy satellite informs me that Michel Py wrote On 2018-08-02, 1:27 PM: > Hi Nanog, > > I received recently some of these messages, and I don't understand the logic of them. > If there is no ROA found, the code should be 1, and the status unknown / not found. > What is the logic behind getting a Validation failure if there is no ROA ? > > Please help RPKI n00b, > Thanks. > > > ==================================================================== > > RPKI Validation Failed (Code: 9) > > ==================================================================== > > Your prefix: 216.230.25.0/24: > > Prefix Description: TSI Semiconductors > > Update time: 2018-07-20 00:10 (UTC) > > Detected by #peers: 4 > > Detected prefix: 216.230.25.0/24 > > Announced by: AS14051 (Consolidated Communications, Inc.) > > Upstream AS: AS2914 (NTT America, Inc.) > > ASpath: 25291 2914 14051 > > Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=82315862 > > Mark as false alert: https://portal.bgpmon.net/fp.php?aid=82315862 > > RPKI Status: No ROA found > > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From radevita at mejeticks.com Thu Aug 2 21:28:08 2018 From: radevita at mejeticks.com (Robert DeVita) Date: Thu, 2 Aug 2018 21:28:08 +0000 Subject: possible hawaii weather issue next week In-Reply-To: <20180802142519.F785D5A7@m0117565.ppops.net> References: <20180802142519.F785D5A7@m0117565.ppops.net> Message-ID: Especially with the main carrier Hotel being located next to the ocean. Robert DeVita Managing Director Mejeticks c. 469-441-8864 e. radevita at mejeticks.com ________________________________ From: 32531414200n behalf of Sent: Thursday, August 2, 2018 4:27 PM To: nanog at nanog.org Subject: possible hawaii weather issue next week If you have stuff in Hawaii, you might want to start thinking about your DR plan. Things can change a lot for the better in 7 days, but they can also get ugly fast. Best to prepare just in case... https://www.nhc.noaa.gov/refresh/graphics_ep5+shtml/204426.shtml?cone https://www.nhc.noaa.gov/refresh/graphics_ep5+shtml/204426.shtml?tswind120 M is >110MPH scott From mark.tinka at seacom.mu Fri Aug 3 06:18:39 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 3 Aug 2018 08:18:39 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> <20180716152603.GE42041@vurt.meerval.net> <2d21104f-670d-5c2b-609a-08bb9339e0fc@seacom.mu> <7edc9ec76b0b4952adc91273c9a59416@CRA110.am.necel.com> <8b3764d9-da8d-ea6c-e5a1-28133eb5d0e7@seacom.mu> Message-ID: <6fd6a682-6da7-4a0a-695d-152723be0641@seacom.mu> On 27/Jul/18 16:40, Job Snijders wrote: > This is awesome! I think it is important to have multiple high quality > implementations so operators have a choice, this way we can work > towards a healthy routing security software ecosystem and avoid > mono-culture. Yes, great to see more implementations out there. Mark. From mark.tinka at seacom.mu Fri Aug 3 06:21:07 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 3 Aug 2018 08:21:07 +0200 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: On 1/Aug/18 00:15, Job Snijders wrote: > However, as you noted; multicast within a single administrative domain > (such as an access network distributing linear TV), or confined to > purpose-built L3VPNs very much is a thing. On the public Internet multicast > seems dead. I'd concur. Mark. From mark.tinka at seacom.mu Fri Aug 3 06:34:06 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 3 Aug 2018 08:34:06 +0200 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: <13dc0c0e-6a42-f1f9-e3a8-37073ebbef02@lanparty.ee> References: <8EE8D6F3-E7C6-4CE2-A376-7FA4AE559BDC@cisco.com> <13dc0c0e-6a42-f1f9-e3a8-37073ebbef02@lanparty.ee> Message-ID: On 1/Aug/18 19:43, Tarko Tikan wrote: >   > > We are an IPTV provider in europe and we definetly see share of linear > TV (that we are delivering via intra-AS multicast today) decreasing YOY. > > OTT plays a big part but even more customers use our own on-demand > services including network PVR. > > Numbers don't add up yet but in 3-4 years even the intra-AS multicast > will not make sense for us any more, easier/better to deliver > everything via unicast. I fully expect this to trend. In Africa, linear (pay) TV is on the down every month, and the only reason it's mostly still seeing some patronage is because of the sports channels which "cannot be" unbundled from the full package. The other reason it's still marginally alive is because of customers that can't spare enough "data" to do the majority of their entertainment online. I know several power users that have deliberately cut the linear TV cord, have gone fully VoD, and have managed to make arrangements to stream sports shows in other ways. The leading pay TV operator in sub-Saharan Africa, Multichoice (DStv) are thinking about their future and are providing the ability for customers to stream all of their channels online, either in real-time or as post-aired VoD content. They've also launched ShowMax, which is their offering to compete with Netflix, Hulu, e.t.c. I was in Malaysia the other day, and Astro are definitely struggling with the declining demand in their pay TV service (both satellite- and IPTV-based). I'm with Tarko when I say in 5 or so years, Multicast for IPTV will begin to die off because customers will be moving more to VoD use-cases. Mark. From michel.py at tsisemi.com Fri Aug 3 17:09:03 2018 From: michel.py at tsisemi.com (Michel Py) Date: Fri, 3 Aug 2018 17:09:03 +0000 Subject: [Nanog] BGPMon RPKI Validation Failed (Code: 9) In-Reply-To: <5B63AFD3.8050504@toonk.nl> References: <5B63AFD3.8050504@toonk.nl> Message-ID: <1ccd8a0c6cd54f58ab72d123a183ad9a@CRA110.am.necel.com> Hi Andree, > Andree Toonk wrote : > it looks likes you have RPKI validation enabled for this prefix in BGPmon.net. > This will tell BGPmon to run the RPKI validation checks for the prefix and alert you if there's no valid ROA found. Makes perfect sense now. Code 9 is a BGPMon extension to code 1. Thanks much for the clarification. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From cscora at apnic.net Fri Aug 3 18:03:09 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Aug 2018 04:03:09 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180803180309.DBBDAC450F@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 04 Aug, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 709541 Prefixes after maximum aggregation (per Origin AS): 272353 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 340445 Total ASes present in the Internet Routing Table: 61400 Prefixes per ASN: 11.56 Origin-only ASes present in the Internet Routing Table: 53022 Origin ASes announcing only one prefix: 23103 Transit ASes present in the Internet Routing Table: 8378 Transit-only ASes present in the Internet Routing Table: 271 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 69 Number of instances of unregistered ASNs: 69 Number of 32-bit ASNs allocated by the RIRs: 23546 Number of 32-bit ASNs visible in the Routing Table: 18953 Prefixes from 32-bit ASNs in the Routing Table: 79380 Number of bogon 32-bit ASNs visible in the Routing Table: 37 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 286 Number of addresses announced to Internet: 2857337412 Equivalent to 170 /8s, 79 /16s and 130 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 236740 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 193849 Total APNIC prefixes after maximum aggregation: 55014 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 192078 Unique aggregates announced from the APNIC address blocks: 78887 APNIC Region origin ASes present in the Internet Routing Table: 8980 APNIC Prefixes per ASN: 21.39 APNIC Region origin ASes announcing only one prefix: 2527 APNIC Region transit ASes present in the Internet Routing Table: 1331 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3937 Number of APNIC addresses announced to Internet: 767366915 Equivalent to 45 /8s, 189 /16s and 23 /24s 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, 64297-64395, 131072-137529 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: 210390 Total ARIN prefixes after maximum aggregation: 100012 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 210547 Unique aggregates announced from the ARIN address blocks: 99642 ARIN Region origin ASes present in the Internet Routing Table: 18194 ARIN Prefixes per ASN: 11.57 ARIN Region origin ASes announcing only one prefix: 6731 ARIN Region transit ASes present in the Internet Routing Table: 1810 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2391 Number of ARIN addresses announced to Internet: 1103191200 Equivalent to 65 /8s, 193 /16s and 92 /24s 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-397212 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: 194343 Total RIPE prefixes after maximum aggregation: 92754 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 190547 Unique aggregates announced from the RIPE address blocks: 112905 RIPE Region origin ASes present in the Internet Routing Table: 25366 RIPE Prefixes per ASN: 7.51 RIPE Region origin ASes announcing only one prefix: 11433 RIPE Region transit ASes present in the Internet Routing Table: 3511 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7254 Number of RIPE addresses announced to Internet: 714013824 Equivalent to 42 /8s, 142 /16s and 252 /24s 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, 64396-64495 196608-207259 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: 91640 Total LACNIC prefixes after maximum aggregation: 20428 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 93081 Unique aggregates announced from the LACNIC address blocks: 40845 LACNIC Region origin ASes present in the Internet Routing Table: 7379 LACNIC Prefixes per ASN: 12.61 LACNIC Region origin ASes announcing only one prefix: 2020 LACNIC Region transit ASes present in the Internet Routing Table: 1393 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4922 Number of LACNIC addresses announced to Internet: 172281632 Equivalent to 10 /8s, 68 /16s and 207 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 19249 Total AfriNIC prefixes after maximum aggregation: 4087 AfriNIC Deaggregation factor: 4.71 Prefixes being announced from the AfriNIC address blocks: 23002 Unique aggregates announced from the AfriNIC address blocks: 7917 AfriNIC Region origin ASes present in the Internet Routing Table: 1180 AfriNIC Prefixes per ASN: 19.49 AfriNIC Region origin ASes announcing only one prefix: 392 AfriNIC Region transit ASes present in the Internet Routing Table: 236 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 449 Number of AfriNIC addresses announced to Internet: 100038144 Equivalent to 5 /8s, 246 /16s and 118 /24s 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 4694 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4383 467 464 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2979 1153 84 VIETEL-AS-AP Viettel Group, VN 4766 2855 11135 767 KIXS-AS-KR Korea Telecom, KR 9829 2813 1497 543 BSNL-NIB National Internet Backbone, IN 45899 2658 1636 109 VNPT-AS-VN VNPT Corp, VN 9394 2541 4907 31 CTTNET China TieTong Telecommunications 17974 2260 946 70 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2240 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2115 433 206 TATACOMM-AS TATA Communications formerl 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 6327 3435 1324 82 SHAW - Shaw Communications Inc., CA 22773 3261 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2691 252 436 CABLEONE - CABLE ONE, INC., US 16509 2247 4790 767 AMAZON-02 - Amazon.com, Inc., US 18566 2167 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2124 2640 485 CHARTER-NET-HKY-NC - Charter Communicat 30036 2016 344 147 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 2013 1037 1447 AKAMAI-AS - Akamai Technologies, Inc., 209 1993 5085 603 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 7018 1761 20206 1278 ATT-INTERNET4 - AT&T Services, Inc., US 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 12479 4657 1611 123 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2847 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2541 622 1886 AKAMAI-ASN1, US 12389 2041 1891 731 ROSTELECOM-AS, RU 34984 1999 334 511 TELLCOM-AS, TR 9121 1855 1692 19 TTNET, TR 13188 1605 100 39 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1214 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5178 3349 606 Uninet S.A. de C.V., MX 10620 3515 535 387 Telmex Colombia S.A., CO 11830 2656 369 78 Instituto Costarricense de Electricidad 6503 1667 444 64 Axtel, S.A.B. de C.V., MX 7303 1507 1026 188 Telecom Argentina S.A., AR 28573 1088 2245 185 CLARO S.A., BR 3816 1020 508 129 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 931 377 31 Telefonica del Peru S.A.A., PE 11172 929 126 85 Alestra, S. de R.L. de C.V., MX 18881 913 1078 30 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1170 396 48 LINKdotNET-AS, EG 37611 888 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 742 1411 40 ETISALAT-MISR, EG 24835 635 818 18 RAYA-AS, EG 8452 617 1730 18 TE-AS TE-AS, EG 37492 473 470 57 ORANGE-, TN 29571 458 68 12 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 377 231 15 MauritiusTelecom, MU 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 8151 5178 3349 606 Uninet S.A. de C.V., MX 4538 4694 4192 74 ERX-CERNET-BKB China Education and Rese 12479 4657 1611 123 UNI2-AS, ES 7545 4383 467 464 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3515 535 387 Telmex Colombia S.A., CO 6327 3435 1324 82 SHAW - Shaw Communications Inc., CA 22773 3261 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2979 1153 84 VIETEL-AS-AP Viettel Group, VN 4766 2855 11135 767 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4538 4694 4620 ERX-CERNET-BKB China Education and Research Net 12479 4657 4534 UNI2-AS, ES 7545 4383 3919 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3435 3353 SHAW - Shaw Communications Inc., CA 10620 3515 3128 Telmex Colombia S.A., CO 22773 3261 3112 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2979 2895 VIETEL-AS-AP Viettel Group, VN 8551 2847 2803 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2656 2578 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 64514 PRIVATE 5.42.231.0/24 35753 ITC ITC AS number, SA 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 64500 DOCUMENT 45.43.56.0/24 135391 AOFEI-HK AOFEI DATA INTERNATIO 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 4200015017 PRIVATE 47.74.136.0/24 45102 CNNIC-ALIBABA-CN-NET-AP Alibab 4200015017 PRIVATE 47.74.161.0/24 45102 CNNIC-ALIBABA-CN-NET-AP Alibab 4200015017 PRIVATE 47.74.203.0/24 45102 CNNIC-ALIBABA-CN-NET-AP Alibab 4200015017 PRIVATE 47.88.147.0/24 45102 CNNIC-ALIBABA-CN-NET-AP Alibab 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 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:14 /9:11 /10:36 /11:99 /12:291 /13:570 /14:1096 /15:1897 /16:13374 /17:7928 /18:13775 /19:25377 /20:39399 /21:45804 /22:87910 /23:71570 /24:398231 /25:797 /26:605 /27:625 /28:35 /29:20 /30:19 /31:4 /32:54 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3399 4657 UNI2-AS, ES 6327 3222 3435 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2522 3261 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2309 2847 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 2110 2691 CABLEONE - CABLE ONE, INC., US 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 2004 2656 Instituto Costarricense de Electricidad y Telec 30036 1768 2016 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1593 3515 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1612 2:846 4:18 5:2825 6:41 7:1 8:1125 12:1872 13:208 14:1787 15:31 16:3 17:189 18:54 20:50 23:2465 24:2223 25:2 27:2473 31:2037 32:86 35:27 36:509 37:2777 38:1483 39:246 40:122 41:3155 42:695 43:1967 44:122 45:5227 46:3094 47:205 49:1331 50:1054 51:318 52:1076 54:365 55:1 56:12 57:39 58:1626 59:992 60:400 61:2118 62:1873 63:1788 64:5045 65:2199 66:4683 67:2471 68:1162 69:3288 70:1154 71:580 72:2135 74:2716 75:420 76:460 77:1635 78:1698 79:2149 80:1545 81:1381 82:1067 83:786 84:1069 85:1987 86:566 87:1358 88:920 89:2361 90:214 91:6435 92:1258 93:2382 94:2387 95:2918 96:778 97:355 98:936 99:133 100:86 101:1237 102:172 103:18311 104:3566 105:216 106:768 107:1796 108:696 109:3170 110:1626 111:1792 112:1332 113:1298 114:1135 115:1654 116:1644 117:1896 118:2211 119:1678 120:1009 121:1057 122:2472 123:1766 124:1448 125:1922 128:1101 129:684 130:492 131:1609 132:729 133:195 134:1023 135:232 136:503 137:651 138:1930 139:660 140:476 141:734 142:803 143:1007 144:809 145:484 146:1211 147:727 148:1643 149:754 150:743 151:1095 152:816 153:321 154:1463 155:799 156:1256 157:795 158:655 159:1784 160:1277 161:804 162:2593 163:597 164:1074 165:1525 166:462 167:1307 168:3126 169:827 170:3828 171:492 172:1022 173:2001 174:929 175:771 176:2000 177:4051 178:2552 179:1247 180:2176 181:2412 182:2399 183:1239 184:1053 185:13899 186:3601 187:2376 188:2922 189:2045 190:8173 191:1352 192:9810 193:6092 194:4973 195:3984 196:2617 197:1608 198:5554 199:5900 200:7335 201:5040 202:10248 203:10268 204:4561 205:2870 206:3176 207:3199 208:3969 209:4009 210:3867 211:1983 212:3051 213:2813 214:1025 215:56 216:6037 217:2123 218:853 219:578 220:1817 221:992 222:973 223:1375 End of report From eric.kuhnke at gmail.com Sat Aug 4 05:04:17 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 3 Aug 2018 22:04:17 -0700 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes Message-ID: If you were setting up something new from a clean sheet of paper design - do you consider it appropriate to have an abuse role inbox that's dedicated to actual network abuse issues (security problems, DDoS, IP hijacks, misbehavior of downstream customers, etc), and keep that separate from DMCA notifications? Automated sorting tools *can* pull things which match regexes for automatically-generated DMCA notifications out of an inbox and route them to the appropriate place. However, I'm pondering whether it's better to have an ISP's ARIN IP space whois entries state clearly that copyright violation type notices should go to a dedicated-purpose dmca at ispname inbox. From ross at tajvar.io Sat Aug 4 05:56:16 2018 From: ross at tajvar.io (Ross Tajvar) Date: Sat, 4 Aug 2018 01:56:16 -0400 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: References: Message-ID: I'd keep them separate since it's a different set of people that needs to handle dmca vs actual abuse. On Sat, Aug 4, 2018, 1:07 AM Eric Kuhnke wrote: > If you were setting up something new from a clean sheet of paper design - > do you consider it appropriate to have an abuse role inbox that's dedicated > to actual network abuse issues (security problems, DDoS, IP hijacks, > misbehavior of downstream customers, etc), and keep that separate from DMCA > notifications? > > Automated sorting tools *can* pull things which match regexes for > automatically-generated DMCA notifications out of an inbox and route them > to the appropriate place. > > However, I'm pondering whether it's better to have an ISP's ARIN IP space > whois entries state clearly that copyright violation type notices should go > to a dedicated-purpose dmca at ispname inbox. > From outsider at scarynet.org Sat Aug 4 09:57:09 2018 From: outsider at scarynet.org (Alexander Maassen) Date: Sat, 04 Aug 2018 11:57:09 +0200 Subject: Avast / Privax abuse contact In-Reply-To: Message-ID: try srboljub.bosnjak at avast.com . contacted us recently regarding a hidemyass vpn ip we have listed. btw, if you folks want to do more with such abusers, i could hook you up with us. Kind regards, Alexander Maassen - Maintainer DroneBL- Peplink Certified Engineer -------- Oorspronkelijk bericht --------Van: Matt Harris Datum: 01-08-18 19:11 (GMT+01:00) Aan: North American Network Operators' Group Onderwerp: Avast / Privax abuse contact Anybody know anyone at or anything about Privax or Avast?  AS 198605 is announcing the problem networks. Getting a ton of SIP brute force attacks from their space, and emails with addresses/timestamps to the abuse contacts listed at RIRs/etc have not yieled any responses.  Attacks still coming. Thanks! From rsk at gsp.org Sat Aug 4 15:05:42 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 4 Aug 2018 11:05:42 -0400 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: References: Message-ID: <20180804150542.GA23158@gsp.org> On Fri, Aug 03, 2018 at 10:04:17PM -0700, Eric Kuhnke wrote: > If you were setting up something new from a clean sheet of paper design - > do you consider it appropriate to have an abuse role inbox that's dedicated > to actual network abuse issues (security problems, DDoS, IP hijacks, > misbehavior of downstream customers, etc), and keep that separate from DMCA > notifications? Separate, because you'll need to design/implement different defenses for them. For example: abuse@ *must* accept traffic with attached malware, since victims of abuse may forward messages containing said malware. But dmca@ doesn't need to and shouldn't. ---rsk From oliver.oboyle at gmail.com Sun Aug 5 17:29:40 2018 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Sun, 5 Aug 2018 13:29:40 -0400 Subject: Ott Message-ID: I am an exceptionally nice otter and picked up dig food and some basic groceries before getting to the games late. On your way back, the exit you need from the 55 to the 10 is closed and you need to get off going towards Sherbrooke. Drive 10 km past the first exit and loop back on in the correct direction. There are 2 not so obvious detour signs once you are on the 10 towards Sherbrook so keep your eyes out . Drive safely. Ott! From dcorbe at hammerfiber.com Sun Aug 5 19:43:36 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Sun, 05 Aug 2018 19:43:36 +0000 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: References: Message-ID: On 8/4/2018 01:04:17, "Eric Kuhnke" wrote: >If you were setting up something new from a clean sheet of paper design >- >do you consider it appropriate to have an abuse role inbox that's >dedicated >to actual network abuse issues (security problems, DDoS, IP hijacks, >misbehavior of downstream customers, etc), and keep that separate from >DMCA >notifications? > >Automated sorting tools *can* pull things which match regexes for >automatically-generated DMCA notifications out of an inbox and route >them >to the appropriate place. > >However, I'm pondering whether it's better to have an ISP's ARIN IP >space >whois entries state clearly that copyright violation type notices >should go >to a dedicated-purpose dmca at ispname inbox. > The main issue with the notion of keeping abuse@ separate from a dedicated DMCA takedown mailbox is companies like IP Echelon will just blindly E-mail whatever abuse POC is associated with either the AS record or whichever POCs are specifically associated with the NET block. So it becomes kind of difficult to keep them routing to different places. The guys doing the DMCA takedowns use automated tooling. So asking them nicely isn't going to help you. > From nanog at jack.fr.eu.org Sun Aug 5 19:51:28 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Sun, 5 Aug 2018 21:51:28 +0200 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: References: Message-ID: <5B675540.3070709@jack.fr.eu.org> On 8/4/2018 01:04:17, "Eric Kuhnke" wrote: > Automated sorting tools *can* pull things which match regexes for > automatically-generated DMCA notifications out of an inbox and route them > to the appropriate place. By "appropriate place", you mean "the trash bin" ? Sieve filters are enough for this task From johnl at iecc.com Sun Aug 5 20:53:35 2018 From: johnl at iecc.com (John Levine) Date: 5 Aug 2018 16:53:35 -0400 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: Message-ID: <20180805205336.3A58020034C71D@ary.qy> In article you write: >The main issue with the notion of keeping abuse@ separate from a >dedicated DMCA takedown mailbox is companies like IP Echelon will just >blindly E-mail whatever abuse POC is associated with either the AS >record or whichever POCs are specifically associated with the NET block. > >So it becomes kind of difficult to keep them routing to different >places. > >The guys doing the DMCA takedowns use automated tooling. So asking >them nicely isn't going to help you. Seems to me that if you've registered your DMCA address in the Library of Congress database, and they send takedowns somewhere else, that's their problem, not not yours. If you haven't registered, you should. You can do the whole thing online in a couple of minutes. The fee is $6 per update no matter how many business names and domain names you register. See https://www.copyright.gov/dmca-directory/ R's, John From dcorbe at hammerfiber.com Sun Aug 5 21:26:52 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Sun, 05 Aug 2018 21:26:52 +0000 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: <20180805205336.3A58020034C71D@ary.qy> References: <20180805205336.3A58020034C71D@ary.qy> Message-ID: On 8/5/2018 16:53:35, "John Levine" wrote: >Seems to me that if you've registered your DMCA address in the Library >of Congress database, and they send takedowns somewhere else, that's >their problem, not not yours. > >If you haven't registered, you should. You can do the whole thing >online in a couple of minutes. The fee is $6 per update no matter how >many business names and domain names you register. > >See https://www.copyright.gov/dmca-directory/ > Thanks. I didn't know this was a thing. > From rsk at gsp.org Sun Aug 5 22:46:36 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 5 Aug 2018 18:46:36 -0400 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: References: Message-ID: <20180805224635.GA517@gsp.org> On Sun, Aug 05, 2018 at 07:43:36PM +0000, Daniel Corbe wrote: > The main issue with the notion of keeping abuse@ separate from a dedicated > DMCA takedown mailbox is companies like IP Echelon will just blindly E-mail > whatever abuse POC is associated with either the AS record or whichever POCs > are specifically associated with the NET block. > > So it becomes kind of difficult to keep them routing to different places. This is a solvable problem. If they're sending unsolicited bulk email (aka "spam"), then they are, by definition, spammers. Block them and move on. If/when they decide to send proper DMCA notices and send them to the proper address, perhaps you can then allow them to petition for the privilege of access to your mail system. ---rsk From neil.johnson at erudicon.com Sat Aug 4 21:29:35 2018 From: neil.johnson at erudicon.com (Neil Johnson) Date: Sat, 4 Aug 2018 16:29:35 -0500 Subject: Looking for a CBS Interactive Contact Message-ID: Can someone in Tier 3 level support from CBS Interactive please contact me at neil-johnson at uiowa dot edu? (For some reason I can't subscribe that address to this list). (Yes, I'm a real network engineer at the University) We are having reach-ability issues with CBS All Access content at the University of Iowa. I've tried reaching out to your support teams via your web page and by phone, but never get a follow-up response. If you need some incentive to respond, your losing CBS All Access subscribers in the dorms of a Big 10 institution because they can't access your content from some of our networks. Thanks! - Neil -- Neil Johnson From jerome at ceriz.fr Mon Aug 6 14:03:00 2018 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Mon, 6 Aug 2018 16:03:00 +0200 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: <5B675540.3070709@jack.fr.eu.org> References: <5B675540.3070709@jack.fr.eu.org> Message-ID: <8656d201-8061-7d16-7a73-daffd934612a@ceriz.fr> Hi Jack, Le 05/08/2018 à 21:51, nanog at jack.fr.eu.org a écrit : > By "appropriate place", you mean "the trash bin" ? Nope, that would eat-up storage and IOs. The proper destination is /dev/null, unless they provide you with the required informations to send a bill. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From dcorbe at hammerfiber.com Mon Aug 6 14:48:38 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Mon, 06 Aug 2018 14:48:38 +0000 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: <20180805224635.GA517@gsp.org> References: <20180805224635.GA517@gsp.org> Message-ID: On 8/5/2018 18:46:36, "Rich Kulawiec" wrote: >On Sun, Aug 05, 2018 at 07:43:36PM +0000, Daniel Corbe wrote: > >This is a solvable problem. If they're sending unsolicited bulk email >(aka "spam"), then they are, by definition, spammers. Block them and >move on. If/when they decide to send proper DMCA notices and send them >to the proper address, perhaps you can then allow them to petition for >the privilege of access to your mail system. > > It doesn't work like that though. I can't just bitbucket DMCA takedown requests because I also provide people with cable TV service. That means I have content contracts and these contracts are all very specific about what I need to do to process DMCA takedown requests. I'm sure that they receive reports regularly from the companies they contract to do DMCA enforcment. Or maybe they don't and I have no idea what I'm talking about. But I'm still not going to put my content contracts at risk because I think my users would be even more pissed off if their cable TV packages were suddenly unavailable to them. > From matt at netfire.net Mon Aug 6 14:51:17 2018 From: matt at netfire.net (Matt Harris) Date: Mon, 6 Aug 2018 09:51:17 -0500 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: <20180805224635.GA517@gsp.org> References: <20180805224635.GA517@gsp.org> Message-ID: On Sun, Aug 5, 2018 at 5:46 PM, Rich Kulawiec wrote: > This is a solvable problem. If they're sending unsolicited bulk email > (aka "spam"), then they are, by definition, spammers. Block them and > move on. If/when they decide to send proper DMCA notices and send them > to the proper address, perhaps you can then allow them to petition for > the privilege of access to your mail system. > > ---rsk > But then the question becomes "how are they supposed to find the 'proper address' for their reports?" If you run a whois server and link it from your RIRs or create a custom "DMCA Compliance" POC in the RIR listings then you could maybe list that sort of thing there, but most address maintainers do neither, so by default whatever address is listed on those net block records with the RIR seems appropriate enough to me. There's no other established protocol for determining an appropriate contact (like calling the associated phone number and asking, or trying to determine your web url and browing that site for it, or something else much more involved.) If there should be a different protocol established for that, then we need to figure it out and document that and get a critical mass of reporters to buy in to it. From valdis.kletnieks at vt.edu Mon Aug 6 15:09:18 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 06 Aug 2018 11:09:18 -0400 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: References: <20180805224635.GA517@gsp.org> Message-ID: <7984.1533568158@turing-police.cc.vt.edu> On Mon, 06 Aug 2018 09:51:17 -0500, Matt Harris said: > But then the question becomes "how are they supposed to find the 'proper > address' for their reports?" Asked and answered already. On 8/5/2018 16:53:35, "John Levine" wrote: >See https://www.copyright.gov/dmca-directory/ If you are in fact registered there, it becomes *their* problem to send their reports to the address you registered. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From matt at netfire.net Mon Aug 6 15:24:20 2018 From: matt at netfire.net (Matt Harris) Date: Mon, 6 Aug 2018 10:24:20 -0500 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: <7984.1533568158@turing-police.cc.vt.edu> References: <20180805224635.GA517@gsp.org> <7984.1533568158@turing-police.cc.vt.edu> Message-ID: On Mon, Aug 6, 2018 at 10:09 AM, wrote: > > Asked and answered already. > > On 8/5/2018 16:53:35, "John Levine" wrote: > >See https://www.copyright.gov/dmca-directory/ > > If you are in fact registered there, it becomes *their* problem to send > their reports to the address you registered. > > I forgot that exists; seems like the only legitimate source for that information, then. From mh at xalto.net Mon Aug 6 20:45:13 2018 From: mh at xalto.net (Michael Hallgren) Date: Mon, 06 Aug 2018 22:45:13 +0200 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: <8656d201-8061-7d16-7a73-daffd934612a@ceriz.fr> References: <5B675540.3070709@jack.fr.eu.org> <8656d201-8061-7d16-7a73-daffd934612a@ceriz.fr> Message-ID: Le 2018-08-06 16:03, Jérôme Nicolle a écrit : > Hi Jack, > > Le 05/08/2018 à 21:51, nanog at jack.fr.eu.org a écrit : >> By "appropriate place", you mean "the trash bin" ? > > Nope, that would eat-up storage and IOs. The proper destination is > /dev/null, unless they provide you with the required informations to > send a bill. Straight to unless, right ;-) mh > > Best regards, From jerome at ceriz.fr Mon Aug 6 22:31:03 2018 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Tue, 7 Aug 2018 00:31:03 +0200 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: References: <20180805224635.GA517@gsp.org> Message-ID: Hi Daniel, Le 06/08/2018 à 16:48, Daniel Corbe a écrit : > It doesn't work like that though.   I can't just bitbucket DMCA takedown > requests because I also provide people with cable TV service.  That > means I have content contracts and these contracts are all very specific > about what I need to do to process DMCA takedown requests.   I'm sure > that they receive reports regularly from the companies they contract to > do DMCA enforcment.    Or maybe they don't and I have no idea what I'm > talking about.   But I'm still not going to put my content contracts at > risk because I think my users would be even more pissed off if their > cable TV packages were suddenly unavailable to them. I'm very sorry to read that, as an ISP, you have to comply with a para-judicial process that puts you in charge of censorship. I'd like to think that you'd have some margin to let these "copyright holders" fuck-off when it comes to your mere-pipe services. But I guess it depends on the jurisdiction you're operating under. Providing IP services and CATV are two different things that should not be liable one to another. If you have any right to give them a finger, please, on behalf of our community, give it to them. If not, please work harder on denouncing those indecent contracts. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From johnl at iecc.com Tue Aug 7 00:56:26 2018 From: johnl at iecc.com (John Levine) Date: 6 Aug 2018 20:56:26 -0400 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: Message-ID: <20180807005627.3330B2003538D0@ary.qy> In article you write: >I'm very sorry to read that, as an ISP, you have to comply with a >para-judicial process that puts you in charge of censorship. Dealing with DMCA notices is a matter of statute law in the US, and it is a really, really bad idea to ignore them unread. It doesn't matter what anyone here thinks about it. R's, John PS: Here's why: https://www.techdirt.com/articles/20180802/17420540355/sensing-blood-water-all-major-labels-sue-cox-ignoring-their-dmca-notices.shtml From dcorbe at hammerfiber.com Tue Aug 7 04:32:44 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 7 Aug 2018 00:32:44 -0400 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: <20180807005627.3330B2003538D0@ary.qy> References: <20180807005627.3330B2003538D0@ary.qy> Message-ID: <47F2D183-390C-4B2F-965F-2DAADA4C2EBB@hammerfiber.com> at 8:56 PM, John Levine wrote: > In article you write: >> I'm very sorry to read that, as an ISP, you have to comply with a >> para-judicial process that puts you in charge of censorship. > > Dealing with DMCA notices is a matter of statute law in the US, and it > is a really, really bad idea to ignore them unread. It doesn't matter > what anyone here thinks about it. > > R's, > John > > PS: Here's why: > > https://www.techdirt.com/articles/20180802/17420540355/sensing-blood-water-all-major-labels-sue-cox-ignoring-their-dmca-notices.shtml This. Plus I’m largely indifferent to it. On one hand, I’m a firm believer in a free and open Internet. But on the other hand, it’s so easy to hide your online activity that I have a hard time feeling sorry for anyone who gets caught up in the drag net. Anyone who gets a notice from us is completely and utterly apathetic about online privacy and it’s astonishing to be just how lazy people really are. I only have a few hundred users, so definitely not a representative sample size, but in all my time here we’ve only had a single repeat offender. From nanog at ics-il.net Tue Aug 7 12:19:52 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 7 Aug 2018 07:19:52 -0500 (CDT) Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: References: Message-ID: <627928051.4141.1533644391202.JavaMail.mhammett@ThunderFuck> Unless the e-mail is to the contact on file with the FCC, it isn't an official DMCA take down request, so the request is garbage. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Daniel Corbe" To: "Eric Kuhnke" , "nanog at nanog.org list" Sent: Sunday, August 5, 2018 2:43:36 PM Subject: Re: Best practices on logical separation of abuse@ vs dmca@ role inboxes On 8/4/2018 01:04:17, "Eric Kuhnke" wrote: >If you were setting up something new from a clean sheet of paper design >- >do you consider it appropriate to have an abuse role inbox that's >dedicated >to actual network abuse issues (security problems, DDoS, IP hijacks, >misbehavior of downstream customers, etc), and keep that separate from >DMCA >notifications? > >Automated sorting tools *can* pull things which match regexes for >automatically-generated DMCA notifications out of an inbox and route >them >to the appropriate place. > >However, I'm pondering whether it's better to have an ISP's ARIN IP >space >whois entries state clearly that copyright violation type notices >should go >to a dedicated-purpose dmca at ispname inbox. > The main issue with the notion of keeping abuse@ separate from a dedicated DMCA takedown mailbox is companies like IP Echelon will just blindly E-mail whatever abuse POC is associated with either the AS record or whichever POCs are specifically associated with the NET block. So it becomes kind of difficult to keep them routing to different places. The guys doing the DMCA takedowns use automated tooling. So asking them nicely isn't going to help you. > From jtk at depaul.edu Tue Aug 7 13:49:42 2018 From: jtk at depaul.edu (John Kristoff) Date: Tue, 7 Aug 2018 08:49:42 -0500 Subject: Dedicated Server and IP anycast provider recommendation Message-ID: <20180807084942.5080ca68@p50.localdomain> Friends, For those that may have used or know of a service like this. I know some exist, but it doesn't seem to be that popular or widely advertised as a standard service. I'm interested in pointers to a hosting/network provider that leases dedicated servers and can provide an anycast IP address assignment to two or more US-diversely connected POPs, but with reasonably consistent routing (e.g. peering, transit). A customer-shared prefix is OK. I'm interested in pointers to networks that would provide the prefix and handle all the routing. If you represent a network and sales is part of your job, I don't mind an off list pointer to a web page describing such a service, but please, this is not an invitation for "call me to discuss needs and options" replies nor an opportunity to get me on your customer prospect list. You likely ensure I never do business with you if you do either of those things. :-) Thank you, John From jnford at uiowa.net Tue Aug 7 13:58:32 2018 From: jnford at uiowa.net (Jay Ford) Date: Tue, 7 Aug 2018 08:58:32 -0500 (CDT) Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: <20180807084942.5080ca68@p50.localdomain> References: <20180807084942.5080ca68@p50.localdomain> Message-ID: On Tue, 7 Aug 2018, John Kristoff wrote: > For those that may have used or know of a service like this. I know > some exist, but it doesn't seem to be that popular or widely advertised > as a standard service. > > I'm interested in pointers to a hosting/network provider that leases > dedicated servers and can provide an anycast IP address assignment to > two or more US-diversely connected POPs, but with reasonably consistent > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > interested in pointers to networks that would provide the prefix and > handle all the routing. Depending on the details of what you're after, Packet Host and/or Vultr might suffice. They do BGP, IPv4 & IPv6 even. They have various flavors of servers, some of which might meet your definition of "dedicated". I do a little BGP-based anycast DNS with both of them, with pretty decent results. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford at uiowa.edu, phone: 319-335-5555 From anthony at fms.io Tue Aug 7 14:04:02 2018 From: anthony at fms.io (Anthony Leto) Date: Tue, 7 Aug 2018 14:04:02 +0000 Subject: Dedicated Server and IP anycast provider recommendation Message-ID: Hi, I would checkout NetActuate. They are pretty awesome when it comes to Anycast IPv4 /IPv6 and they do custom VM's. Anthony Leto On 8/7/2018 2:51:59 PM, John Kristoff wrote: Friends, For those that may have used or know of a service like this. I know some exist, but it doesn't seem to be that popular or widely advertised as a standard service. I'm interested in pointers to a hosting/network provider that leases dedicated servers and can provide an anycast IP address assignment to two or more US-diversely connected POPs, but with reasonably consistent routing (e.g. peering, transit). A customer-shared prefix is OK. I'm interested in pointers to networks that would provide the prefix and handle all the routing. If you represent a network and sales is part of your job, I don't mind an off list pointer to a web page describing such a service, but please, this is not an invitation for "call me to discuss needs and options" replies nor an opportunity to get me on your customer prospect list. You likely ensure I never do business with you if you do either of those things. :-) Thank you, John From ryan at finnesey.com Tue Aug 7 14:05:22 2018 From: ryan at finnesey.com (Ryan Finnesey) Date: Tue, 7 Aug 2018 14:05:22 +0000 Subject: NANOG On The Road - DC? Message-ID: Does anyone know if there is a block of rooms for NANOG On The Road - DC? I called the Hilton and they did not have the meeting on their calendar. From lathama at gmail.com Tue Aug 7 14:29:07 2018 From: lathama at gmail.com (Andrew Latham) Date: Tue, 7 Aug 2018 09:29:07 -0500 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: <20180807084942.5080ca68@p50.localdomain> References: <20180807084942.5080ca68@p50.localdomain> Message-ID: As mentioned https://www.packet.net/ is the MaaS provider that fits the bill. You can optionally order servers like this from HE and other IXPs for a price. On Tue, Aug 7, 2018 at 8:51 AM John Kristoff wrote: > Friends, > > For those that may have used or know of a service like this. I know > some exist, but it doesn't seem to be that popular or widely advertised > as a standard service. > > I'm interested in pointers to a hosting/network provider that leases > dedicated servers and can provide an anycast IP address assignment to > two or more US-diversely connected POPs, but with reasonably consistent > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > interested in pointers to networks that would provide the prefix and > handle all the routing. > > If you represent a network and sales is part of your job, I don't mind > an off list pointer to a web page describing such a service, but please, > this is not an invitation for "call me to discuss needs and options" > replies nor an opportunity to get me on your customer prospect list. > You likely ensure I never do business with you if you do either of > those things. :-) > > Thank you, > > John > -- - Andrew "lathama" Latham - From bill at herrin.us Tue Aug 7 14:43:31 2018 From: bill at herrin.us (William Herrin) Date: Tue, 7 Aug 2018 10:43:31 -0400 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: References: <20180807084942.5080ca68@p50.localdomain> Message-ID: On Tue, Aug 7, 2018 at 9:58 AM, Jay Ford wrote: > Depending on the details of what you're after, Packet Host and/or Vultr > might suffice. They do BGP, IPv4 & IPv6 even. They have various flavors of > servers, some of which might meet your definition of "dedicated". I do a > little BGP-based anycast DNS with both of them, with pretty decent results. I can second Vultr. Their BGP+VPS product is inexpensive, it worked right the first time and it has continued working properly. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From aaron1 at gvtc.com Tue Aug 7 15:05:47 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 7 Aug 2018 10:05:47 -0500 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: References: <20180807084942.5080ca68@p50.localdomain> Message-ID: <20CDF7CC-A72D-4C7F-AAC3-8141277F61FE@gvtc.com> vultr ? Is this the same vultr that appears to be hosting a lot of Sony PlayStation games ? I've been tshooting PS4 CGNAT issues and seeing my test ps4 gaming console connecting to Vultr owned /27 address space all over the US.... Chicago, Miami, Seattle, etc Aaron > On Aug 7, 2018, at 9:43 AM, William Herrin wrote: > >> On Tue, Aug 7, 2018 at 9:58 AM, Jay Ford wrote: >> Depending on the details of what you're after, Packet Host and/or Vultr >> might suffice. They do BGP, IPv4 & IPv6 even. They have various flavors of >> servers, some of which might meet your definition of "dedicated". I do a >> little BGP-based anycast DNS with both of them, with pretty decent results. > > I can second Vultr. Their BGP+VPS product is inexpensive, it worked > right the first time and it has continued working properly. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From johnl at iecc.com Tue Aug 7 15:29:43 2018 From: johnl at iecc.com (John Levine) Date: 7 Aug 2018 11:29:43 -0400 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: <627928051.4141.1533644391202.JavaMail.mhammett@ThunderFuck> Message-ID: <20180807152943.65F3C20035654D@ary.qy> In article <627928051.4141.1533644391202.JavaMail.mhammett at ThunderFuck> you write: >Unless the e-mail is to the contact on file with the FCC, it isn't an official DMCA take down request, so the request is garbage. It's not the FCC, it's the copyright office. The law also says that the contact address should be on your web site somewhere. R's, John > > > > >----- >Mike Hammett >Intelligent Computing Solutions > >Midwest Internet Exchange > >The Brothers WISP From owen at delong.com Tue Aug 7 15:33:19 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 7 Aug 2018 08:33:19 -0700 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: <20180807084942.5080ca68@p50.localdomain> References: <20180807084942.5080ca68@p50.localdomain> Message-ID: Netactuate has been doing this for years. I highly recommend them. http://netactuate.com Owen > On Aug 7, 2018, at 06:49, John Kristoff wrote: > > Friends, > > For those that may have used or know of a service like this. I know > some exist, but it doesn't seem to be that popular or widely advertised > as a standard service. > > I'm interested in pointers to a hosting/network provider that leases > dedicated servers and can provide an anycast IP address assignment to > two or more US-diversely connected POPs, but with reasonably consistent > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > interested in pointers to networks that would provide the prefix and > handle all the routing. > > If you represent a network and sales is part of your job, I don't mind > an off list pointer to a web page describing such a service, but please, > this is not an invitation for "call me to discuss needs and options" > replies nor an opportunity to get me on your customer prospect list. > You likely ensure I never do business with you if you do either of > those things. :-) > > Thank you, > > John From mehmet at akcin.net Tue Aug 7 15:37:03 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 7 Aug 2018 08:37:03 -0700 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: References: <20180807084942.5080ca68@p50.localdomain> Message-ID: +1 for Netactuate. On Tue, Aug 7, 2018 at 8:33 AM, Owen DeLong wrote: > Netactuate has been doing this for years. > > I highly recommend them. > > http://netactuate.com > > Owen > > > > On Aug 7, 2018, at 06:49, John Kristoff wrote: > > > > Friends, > > > > For those that may have used or know of a service like this. I know > > some exist, but it doesn't seem to be that popular or widely advertised > > as a standard service. > > > > I'm interested in pointers to a hosting/network provider that leases > > dedicated servers and can provide an anycast IP address assignment to > > two or more US-diversely connected POPs, but with reasonably consistent > > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > > interested in pointers to networks that would provide the prefix and > > handle all the routing. > > > > If you represent a network and sales is part of your job, I don't mind > > an off list pointer to a web page describing such a service, but please, > > this is not an invitation for "call me to discuss needs and options" > > replies nor an opportunity to get me on your customer prospect list. > > You likely ensure I never do business with you if you do either of > > those things. :-) > > > > Thank you, > > > > John > From hello at yugandhar.me Tue Aug 7 14:25:09 2018 From: hello at yugandhar.me (Yugandhar Veeramachaneni) Date: Tue, 7 Aug 2018 14:25:09 +0000 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: References: Message-ID: Hello, http://bgp.services is a community maintained spreadsheet with details of providers who offer BGP sessions across the world. I think it will be useful for you. Regards, Yugandhar On Tue, Aug 7, 2018 at 9:06 AM Anthony Leto wrote: > Hi, > > I would checkout NetActuate. They are pretty awesome when it comes to > Anycast IPv4 /IPv6 and they do custom VM's. > > Anthony Leto > > On 8/7/2018 2:51:59 PM, John Kristoff wrote: > > Friends, > > For those that may have used or know of a service like this. I know > some exist, but it doesn't seem to be that popular or widely advertised > as a standard service. > > I'm interested in pointers to a hosting/network provider that leases > dedicated servers and can provide an anycast IP address assignment to > two or more US-diversely connected POPs, but with reasonably consistent > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > interested in pointers to networks that would provide the prefix and > handle all the routing. > > If you represent a network and sales is part of your job, I don't mind > an off list pointer to a web page describing such a service, but please, > this is not an invitation for "call me to discuss needs and options" > replies nor an opportunity to get me on your customer prospect list. > You likely ensure I never do business with you if you do either of > those things. :-) > > Thank you, > > John > From aveline at misaka.io Tue Aug 7 14:29:58 2018 From: aveline at misaka.io (Siyuan Miao) Date: Tue, 7 Aug 2018 22:29:58 +0800 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: References: Message-ID: I would recommend Vultr, you can bring your own IP address and set up BGP session using VM. Their BGP service are fully automated and provide well-documented BGP community for traffic engineering. -- Siyuan Miao Misaka Network, Inc | https://misaka.io On Tue, Aug 7, 2018 at 10:06 PM Anthony Leto wrote: > Hi, > > I would checkout NetActuate. They are pretty awesome when it comes to > Anycast IPv4 /IPv6 and they do custom VM's. > > Anthony Leto > > On 8/7/2018 2:51:59 PM, John Kristoff wrote: > > Friends, > > For those that may have used or know of a service like this. I know > some exist, but it doesn't seem to be that popular or widely advertised > as a standard service. > > I'm interested in pointers to a hosting/network provider that leases > dedicated servers and can provide an anycast IP address assignment to > two or more US-diversely connected POPs, but with reasonably consistent > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > interested in pointers to networks that would provide the prefix and > handle all the routing. > > If you represent a network and sales is part of your job, I don't mind > an off list pointer to a web page describing such a service, but please, > this is not an invitation for "call me to discuss needs and options" > replies nor an opportunity to get me on your customer prospect list. > You likely ensure I never do business with you if you do either of > those things. :-) > > Thank you, > > John > From p.bonvin at edsi-tech.com Tue Aug 7 17:45:38 2018 From: p.bonvin at edsi-tech.com (Philippe Bonvin) Date: Tue, 7 Aug 2018 17:45:38 +0000 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: References: , Message-ID: We use http://packet.net/ for our anycast setup, their pricing isn't cheap compared to Vultr but it worth try. If you commit on long-term you can get custom pricing. ________________________________ From: NANOG on behalf of Siyuan Miao Sent: Tuesday, August 7, 2018 16:29 To: anthony at fms.io Cc: nanog at nanog.org Subject: Re: Dedicated Server and IP anycast provider recommendation I would recommend Vultr, you can bring your own IP address and set up BGP session using VM. Their BGP service are fully automated and provide well-documented BGP community for traffic engineering. -- Siyuan Miao Misaka Network, Inc | https://misaka.io On Tue, Aug 7, 2018 at 10:06 PM Anthony Leto wrote: > Hi, > > I would checkout NetActuate. They are pretty awesome when it comes to > Anycast IPv4 /IPv6 and they do custom VM's. > > Anthony Leto > > On 8/7/2018 2:51:59 PM, John Kristoff wrote: > > Friends, > > For those that may have used or know of a service like this. I know > some exist, but it doesn't seem to be that popular or widely advertised > as a standard service. > > I'm interested in pointers to a hosting/network provider that leases > dedicated servers and can provide an anycast IP address assignment to > two or more US-diversely connected POPs, but with reasonably consistent > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > interested in pointers to networks that would provide the prefix and > handle all the routing. > > If you represent a network and sales is part of your job, I don't mind > an off list pointer to a web page describing such a service, but please, > this is not an invitation for "call me to discuss needs and options" > replies nor an opportunity to get me on your customer prospect list. > You likely ensure I never do business with you if you do either of > those things. :-) > > Thank you, > > John > [EDSI-Tech Sarl] Philippe Bonvin, Directeur, Ing. MSc. in Computer Science, IPMA, eMBA EDSI-Tech Sàrl EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | Téléphone: +41 (0) 21 566 14 15, poste 99 Disclaimer: This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this information, be advised that you have received this email in error and that any usage, disclosure, distribution, copying of the information or any part of it in any form whatsoever is strictly prohibited. If you have received this email in error please notify the EDSI-Tech helpdesk by phone on +41 21 566 14 15 and then delete this e-mail. From apishdadi at gmail.com Tue Aug 7 16:28:18 2018 From: apishdadi at gmail.com (A. Pishdadi) Date: Tue, 7 Aug 2018 11:28:18 -0500 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: <20180807084942.5080ca68@p50.localdomain> References: <20180807084942.5080ca68@p50.localdomain> Message-ID: Gigenet.com can be done in two or three locations , La, Chicago, ashburn, and done with dedicated, colo or cloud. On Tue, Aug 7, 2018 at 8:50 AM John Kristoff wrote: > Friends, > > For those that may have used or know of a service like this. I know > some exist, but it doesn't seem to be that popular or widely advertised > as a standard service. > > I'm interested in pointers to a hosting/network provider that leases > dedicated servers and can provide an anycast IP address assignment to > two or more US-diversely connected POPs, but with reasonably consistent > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > interested in pointers to networks that would provide the prefix and > handle all the routing. > > If you represent a network and sales is part of your job, I don't mind > an off list pointer to a web page describing such a service, but please, > this is not an invitation for "call me to discuss needs and options" > replies nor an opportunity to get me on your customer prospect list. > You likely ensure I never do business with you if you do either of > those things. :-) > > Thank you, > > John > From baldur.norddahl at gmail.com Tue Aug 7 19:46:03 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 7 Aug 2018 21:46:03 +0200 Subject: optical circulator as a bidirectional one fiber solution Message-ID: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> Hello There is a lack of bidirectional one fiber (BIDI) options for 40G and 100G optics. Usually BIDI is implemented using two CWDM wavelengths, one for tx and one for rx. However there is also a lack of CWDM and DWDM options for 40G and 100G. Would it be possible to use an optical circulator like this one (customized to 1310 nm)? https://www.fs.com/de/en/products/33364.html Combined with a traditional two fiber 1310 nm 10 km 40G QSFP module like this: https://www.fs.com/de/en/products/24422.html The link distance would be 5 km. The optical circulator separates tx and rx by the direction the light travels in. It would work even though both directions use the same wavelength. There will likely be some reflection but hopefully attenuated enough that it is regarded as background noise. Has anyone done this? Any reason it would not work? Regards, Baldur From dcorbe at hammerfiber.com Tue Aug 7 19:58:56 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 07 Aug 2018 19:58:56 +0000 Subject: optical circulator as a bidirectional one fiber solution In-Reply-To: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> References: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> Message-ID: On 8/7/2018 15:46:03, "Baldur Norddahl" wrote: >Hello > >There is a lack of bidirectional one fiber (BIDI) options for 40G and >100G optics. Usually BIDI is implemented using two CWDM wavelengths, >one for tx and one for rx. However there is also a lack of CWDM and >DWDM options for 40G and 100G. > >Would it be possible to use an optical circulator like this one >(customized to 1310 nm)? > >https://www.fs.com/de/en/products/33364.html > >Combined with a traditional two fiber 1310 nm 10 km 40G QSFP module >like this: https://www.fs.com/de/en/products/24422.html > >The link distance would be 5 km. > >The optical circulator separates tx and rx by the direction the light >travels in. It would work even though both directions use the same >wavelength. There will likely be some reflection but hopefully >attenuated enough that it is regarded as background noise. > >Has anyone done this? Any reason it would not work? > >Regards, > >Baldur > The main issue you're going to run into (especially trying to plug anything into a DWDM shelf) is 40G and 100G transceivers usually emit 4 lanes of traffic instead of a single lane like 10 and 1G optics do. I'd imagine that's why there are so few solutions that don't involve things like OTN. From bill at herrin.us Tue Aug 7 21:47:13 2018 From: bill at herrin.us (William Herrin) Date: Tue, 7 Aug 2018 17:47:13 -0400 Subject: Godaddy outage? Message-ID: Hi, Does anyone have information on the godaddy outage? I don't see anything on https://puck.nether.net/mailman/listinfo/outages or status.godaddy.com but my DNS server logs: Aug 7 17:02:11 dns-a named[2383]: error (unexpected RCODE REFUSED) resolving 'pdns11.domaincontrol.com/A/IN': 173.201.65.35#53 Aug 7 17:02:11 dns-a named[2383]: error (unexpected RCODE REFUSED) resolving 'pdns12.domaincontrol.com/A/IN': 173.201.65.35#53 Aug 7 17:02:32 dns-a named[2383]: error (unexpected RCODE REFUSED) resolving 'ns38.domaincontrol.com/A/IN': 216.69.185.35#53 Aug 7 17:02:32 dns-a named[2383]: error (unexpected RCODE REFUSED) resolving 'ns37.domaincontrol.com/A/IN': 216.69.185.35#53 my zones aren't resolving consistently and an attempt to access the web portal at https://dcc.godaddy.com/manage/dns reports "We apologize for this inconvenience, but an error has been detected." First noticed about 75 minutes ago. Thanks, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From kenneth.mcrae at me.com Tue Aug 7 21:50:29 2018 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Tue, 07 Aug 2018 14:50:29 -0700 Subject: Godaddy outage? In-Reply-To: References: Message-ID: <2D75514D-C70F-4DC8-A4D5-457D2B432276@me.com> Outage confirmed by support staff. No present ETR. > On Aug 7, 2018, at 2:47 PM, William Herrin wrote: > > Hi, > > Does anyone have information on the godaddy outage? I don't see > anything on https://puck.nether.net/mailman/listinfo/outages or > status.godaddy.com but my DNS server logs: > > Aug 7 17:02:11 dns-a named[2383]: error (unexpected RCODE REFUSED) > resolving 'pdns11.domaincontrol.com/A/IN': 173.201.65.35#53 > Aug 7 17:02:11 dns-a named[2383]: error (unexpected RCODE REFUSED) > resolving 'pdns12.domaincontrol.com/A/IN': 173.201.65.35#53 > Aug 7 17:02:32 dns-a named[2383]: error (unexpected RCODE REFUSED) > resolving 'ns38.domaincontrol.com/A/IN': 216.69.185.35#53 > Aug 7 17:02:32 dns-a named[2383]: error (unexpected RCODE REFUSED) > resolving 'ns37.domaincontrol.com/A/IN': 216.69.185.35#53 > > my zones aren't resolving consistently and an attempt to access the > web portal at https://dcc.godaddy.com/manage/dns reports "We apologize > for this inconvenience, but an error has been detected." > > First noticed about 75 minutes ago. > > Thanks, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From branto at argentiumsolutions.com Wed Aug 8 14:57:17 2018 From: branto at argentiumsolutions.com (Brant Ian Stevens) Date: Wed, 8 Aug 2018 10:57:17 -0400 Subject: Nokia SP Business Group Account Contact Message-ID: <6a4405f1-ed60-145c-4092-fa5ebb63f13f@argentiumsolutions.com> Sorry to bother the list, but could someone help me get in touch with a Nokia account rep from their SP team for the NYC area? Specifically looking for information on the managed sp wireless solution. I've tried going through the website, but have made no progress reaching the right people to move my request forward. -- Regards, -- Brant I. Stevens From me at tombowdit.ch Tue Aug 7 18:14:28 2018 From: me at tombowdit.ch (Tommy Bowditch) Date: Tue, 7 Aug 2018 19:14:28 +0100 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: References: Message-ID: Hi all, As it was mentioned just thought I'd chime in - I'm the operator of https://bgp.services/ - if you have any suggestions/additions shoot me a mail off-list and I'll be more than happy to add them. Tom On Tue, Aug 7, 2018 at 5:28 PM Yugandhar Veeramachaneni wrote: > Hello, > > http://bgp.services is a community maintained spreadsheet with details of > providers who offer BGP sessions across the world. I think it will be > useful for you. > > Regards, > Yugandhar > > > On Tue, Aug 7, 2018 at 9:06 AM Anthony Leto wrote: > > > Hi, > > > > I would checkout NetActuate. They are pretty awesome when it comes to > > Anycast IPv4 /IPv6 and they do custom VM's. > > > > Anthony Leto > > > > On 8/7/2018 2:51:59 PM, John Kristoff wrote: > > > > Friends, > > > > For those that may have used or know of a service like this. I know > > some exist, but it doesn't seem to be that popular or widely advertised > > as a standard service. > > > > I'm interested in pointers to a hosting/network provider that leases > > dedicated servers and can provide an anycast IP address assignment to > > two or more US-diversely connected POPs, but with reasonably consistent > > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > > interested in pointers to networks that would provide the prefix and > > handle all the routing. > > > > If you represent a network and sales is part of your job, I don't mind > > an off list pointer to a web page describing such a service, but please, > > this is not an invitation for "call me to discuss needs and options" > > replies nor an opportunity to get me on your customer prospect list. > > You likely ensure I never do business with you if you do either of > > those things. :-) > > > > Thank you, > > > > John > > > From nusenu-lists at riseup.net Tue Aug 7 23:37:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Tue, 07 Aug 2018 23:37:00 +0000 Subject: Best practices on logical separation of abuse@ vs dmca@ role inboxes In-Reply-To: <20180805205336.3A58020034C71D@ary.qy> References: <20180805205336.3A58020034C71D@ary.qy> Message-ID: John Levine: > In article you write: >> The main issue with the notion of keeping abuse@ separate from a >> dedicated DMCA takedown mailbox is companies like IP Echelon will just >> blindly E-mail whatever abuse POC is associated with either the AS >> record or whichever POCs are specifically associated with the NET block. >> >> So it becomes kind of difficult to keep them routing to different >> places. >> >> The guys doing the DMCA takedowns use automated tooling. So asking >> them nicely isn't going to help you. > > Seems to me that if you've registered your DMCA address in the Library > of Congress database, and they send takedowns somewhere else, that's > their problem, not not yours. > > If you haven't registered, you should. You can do the whole thing > online in a couple of minutes. The fee is $6 per update no matter how > many business names and domain names you register. > > See https://www.copyright.gov/dmca-directory/ thanks this is useful. has anyone practical experience with how many of the usual DMCA email sending companies actually take this into account when they send their automated emails? Does creating a record there actually result in a substantial fraction of DMCA emails being routed to the email address given there? -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From spoofer-info at caida.org Wed Aug 8 17:00:02 2018 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Wed, 8 Aug 2018 10:00:02 -0700 Subject: Spoofer Report for NANOG for Jul 2018 Message-ID: <201808081700.w78H02Pe048650@fro.caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Jul 2018: ASN Name Fixed-By 7922 COMCAST-7922 2018-07-02 33651 CMCS 2018-07-21 29384 Qatar-Foundation 2018-07-25 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Jul 2018: ASN Name First-Spoofed Last-Spoofed 3356 LEVEL3 2016-03-06 2018-07-25 577 BACOM 2016-03-09 2018-07-31 7922 COMCAST-7922 2016-06-04 2018-07-27 20115 CHARTER-NET-HKY-NC 2016-06-09 2018-07-03 7029 WINDSTREAM 2016-06-21 2018-07-16 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-07-25 6128 CABLE-NET-1 2016-09-03 2018-07-05 20412 CLARITY-TELECOM 2016-09-30 2018-07-30 6181 FUSE-NET 2016-10-10 2018-07-31 25787 ROWE-NETWORKS 2016-10-21 2018-07-25 174 COGENT-174 2016-10-21 2018-07-18 271 BCNET 2016-10-24 2018-07-16 2828 XO-AS15 2016-10-25 2018-07-27 32440 LONI 2016-11-03 2018-07-28 33182 DimeNOC 2016-11-08 2018-07-26 12083 WOW-INTERNET 2016-11-09 2018-07-29 1403 EBOX 2016-11-12 2018-07-25 2152 CSUNET-NW 2017-02-02 2018-07-30 21832 KELLINCOM-1 2017-02-03 2018-07-28 7276 UNIVERSITY-OF-HOUSTON 2017-03-09 2018-07-04 6461 ZAYO-6461 2017-06-21 2018-07-27 63296 AMARILLO-WIRELESS 2017-09-01 2018-07-26 7233 YAHOO-US 2017-09-07 2018-07-31 546 PARSONS-PGS-1 2017-11-20 2018-07-19 54540 INCERO 2018-01-15 2018-07-25 12222 AKAMAI 2018-02-14 2018-07-31 55236 CBC 2018-03-03 2018-07-02 3257 GTT-BACKBONE 2018-03-06 2018-07-25 29384 Qatar-Foundation 2018-03-08 2018-07-29 23148 TERRENAP 2018-03-15 2018-07-26 20009 WADSNET 2018-04-13 2018-07-04 4201 ORST 2018-04-19 2018-07-31 11827 WSU 2018-04-19 2018-07-27 393564 SPOKANE 2018-06-05 2018-07-25 35911 BNQ-1 2018-06-06 2018-07-29 225 VIRGINIA 2018-06-18 2018-07-26 4150 SUPRANET-WIS 2018-07-06 2018-07-06 16628 DEDICATED-FIBER-COMMUNICATIONS 2018-07-13 2018-07-13 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From jawaid.bazyar at FORETHOUGHT.net Wed Aug 8 19:33:49 2018 From: jawaid.bazyar at FORETHOUGHT.net (Jawaid Bazyar) Date: Wed, 8 Aug 2018 13:33:49 -0600 Subject: Akamai Contact Message-ID: Hi, having trouble engaging with an Akamai contact in relation to the server stack we have here. Feel free to contact me. -- Jawaid Bazyar President ph 303.815.1814 fax 303.815.1001 Jawaid.Bazyar at foreThought.net From mankamis at cisco.com Wed Aug 8 18:49:52 2018 From: mankamis at cisco.com (Mankamana Mishra (mankamis)) Date: Wed, 8 Aug 2018 18:49:52 +0000 Subject: Multicast traffic % in enterprise network ? Message-ID: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Hi Every one, Recently we had good discussion over multicast uses in public internet. From discussion, it was pointed out uses of multicast is more with in enterprise. Wanted to understand how much % multicast traffic present in network * If there is any data which can provide what % of traffic is multicast traffic. And if multicast is removed, how much unicast traffic it would add up? * Since this forum has people from deployment area, I would love to know if there is real deployment problems or its pain to deploy multicast. These questions is to work / discussion in IETF to see what is pain points for multicast, and how can we simplify it. Thanks Mankamana From mauro at interlink.com.ar Wed Aug 8 19:22:23 2018 From: mauro at interlink.com.ar (Mauro Gasparini) Date: Wed, 8 Aug 2018 16:22:23 -0300 Subject: PPPoE Server Message-ID: <07be3f37-c89b-2d2f-cc1b-28a413a5e649@interlink.com.ar> Good afternoon people. I would like to advice me some appliance or software (running on top level server line) which supports 20,000 simultaneous PPPoE connections. The customer has a Cisco ASR1000 but I don't have any confirmed experience that can support it. Mauro Gasparini. From nanog at jack.fr.eu.org Wed Aug 8 20:29:19 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Wed, 8 Aug 2018 22:29:19 +0200 Subject: Multicast traffic % in enterprise network ? In-Reply-To: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: <5B6B529F.3080302@jack.fr.eu.org> I believe multicast is only used for IPTV Multicast by itself does not reduce much bandwidth : that reduction is purely based on the network design If you place unicast nodes near your customers, multicast is effectively unicast (just think about it) :) On 08/08/2018 08:49 PM, Mankamana Mishra (mankamis) via NANOG wrote: > Hi Every one, > Recently we had good discussion over multicast uses in public internet. From discussion, it was pointed out uses of multicast is more with in enterprise. Wanted to understand how much % multicast traffic present in network > > * If there is any data which can provide what % of traffic is multicast traffic. And if multicast is removed, how much unicast traffic it would add up? > * Since this forum has people from deployment area, I would love to know if there is real deployment problems or its pain to deploy multicast. > > > These questions is to work / discussion in IETF to see what is pain points for multicast, and how can we simplify it. > > > > Thanks > Mankamana > From bruce.curtis at ndsu.edu Wed Aug 8 20:38:30 2018 From: bruce.curtis at ndsu.edu (Curtis, Bruce) Date: Wed, 8 Aug 2018 20:38:30 +0000 Subject: Multicast traffic % in enterprise network ? In-Reply-To: <5B6B529F.3080302@jack.fr.eu.org> References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> <5B6B529F.3080302@jack.fr.eu.org> Message-ID: On Aug 8, 2018, at 3:29 PM, nanog at jack.fr.eu.org wrote: I believe multicast is only used for IPTV There is at least one company that is using multicast for video switching, or in other words to replace HDMI switchers in rooms with video sources and displays. They have devices that encode video from an HDMI input to a multicast stream. And devices that receive a multicast stream and output the video from that stream to an HDMI output. So you can have multiple cameras and a multicast stream for each camera is input into the network. Then you can have a projector that can choose any of those multicast streams to display. I believe the video is uncompressed Multicast by itself does not reduce much bandwidth : that reduction is purely based on the network design If you place unicast nodes near your customers, multicast is effectively unicast (just think about it) :) On 08/08/2018 08:49 PM, Mankamana Mishra (mankamis) via NANOG wrote: Hi Every one, Recently we had good discussion over multicast uses in public internet. From discussion, it was pointed out uses of multicast is more with in enterprise. Wanted to understand how much % multicast traffic present in network * If there is any data which can provide what % of traffic is multicast traffic. And if multicast is removed, how much unicast traffic it would add up? * Since this forum has people from deployment area, I would love to know if there is real deployment problems or its pain to deploy multicast. These questions is to work / discussion in IETF to see what is pain points for multicast, and how can we simplify it. Thanks Mankamana --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From josejorquera10 at gmail.com Wed Aug 8 20:43:40 2018 From: josejorquera10 at gmail.com (Jose Jorquera) Date: Wed, 8 Aug 2018 16:43:40 -0400 Subject: PPPoE Server In-Reply-To: <07be3f37-c89b-2d2f-cc1b-28a413a5e649@interlink.com.ar> References: <07be3f37-c89b-2d2f-cc1b-28a413a5e649@interlink.com.ar> Message-ID: Cisco is the any option? I read about BRAS server on Juniper MX-480,can you check "Juniper one day: dynamic subscriber management” for more info. > El 08-08-2018, a las 15:22, Mauro Gasparini escribió: > > Good afternoon people. > I would like to advice me some appliance or software (running on top level server line) which supports 20,000 simultaneous PPPoE connections. > The customer has a Cisco ASR1000 but I don't have any confirmed experience that can support it. > > Mauro Gasparini. > > From aaron1 at gvtc.com Wed Aug 8 20:45:13 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 8 Aug 2018 15:45:13 -0500 Subject: Akamai Contact In-Reply-To: References: Message-ID: <001401d42f58$b54236b0$1fc6a410$@gvtc.com> Akamai Customer Care - 877-425-2832 Akamai NOCC - 877-625-2624 - 877-6-akamai (same as above) - 617-444-3007 - nocc-shift at akamai.com - (if you do anything that would affect our cluster, give them at least 3 hours notice and give them IP of cluster - hardware issues and 24x7 contact: nocc-tix at akamai.com +1-877-6AKAMAI Akamai Network Support - traffic issues: netsupport-tix at akamai.com +1-888-421-1003 -Aaron From sob at academ.com Wed Aug 8 20:31:36 2018 From: sob at academ.com (Stan Barber) Date: Wed, 8 Aug 2018 13:31:36 -0700 Subject: Multicast traffic % in enterprise network ? In-Reply-To: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: As someone else remarked, part of this will depend on the type of network you are profiling. One enterprise networking may have critical internal applications that depend on multicast to work and others may have nothing but the basic requirements of the network itself (e.g. IPv6 uses multicast instead of broadcast for some network control information distribution). On Wed, Aug 8, 2018 at 11:49 AM, Mankamana Mishra (mankamis) via NANOG < nanog at nanog.org> wrote: > Hi Every one, > Recently we had good discussion over multicast uses in public internet. > From discussion, it was pointed out uses of multicast is more with in > enterprise. Wanted to understand how much % multicast traffic present in > network > > * If there is any data which can provide what % of traffic is > multicast traffic. And if multicast is removed, how much unicast traffic it > would add up? > * Since this forum has people from deployment area, I would love to > know if there is real deployment problems or its pain to deploy multicast. > > > These questions is to work / discussion in IETF to see what is pain points > for multicast, and how can we simplify it. > > > > Thanks > Mankamana > > From clayton at MNSi.Net Wed Aug 8 20:49:30 2018 From: clayton at MNSi.Net (Clayton Zekelman) Date: Wed, 08 Aug 2018 16:49:30 -0400 Subject: PPPoE Server In-Reply-To: References: <07be3f37-c89b-2d2f-cc1b-28a413a5e649@interlink.com.ar> Message-ID: <1533761373_308475@surgemail.mnsi.net> I'll second that. Juniper MX works well for us. We have one router terminating 10,000 PPPoE and 3,500 L2TP and it handles the load fine. At 04:43 PM 08/08/2018, Jose Jorquera wrote: >Cisco is the any option? I read about BRAS >server on Juniper MX-480,can you check "Juniper >one day: dynamic subscriber management” for more info. > > > El 08-08-2018, a las 15:22, Mauro Gasparini > escribió: > > > > Good afternoon people. > > I would like to advice me some appliance or > software (running on top level server line) > which supports 20,000 simultaneous PPPoE connections. > > The customer has a Cisco ASR1000 but I don't > have any confirmed experience that can support it. > > > > Mauro Gasparini. > > > > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From tony at wicks.co.nz Wed Aug 8 21:11:53 2018 From: tony at wicks.co.nz (Tony Wicks) Date: Thu, 9 Aug 2018 09:11:53 +1200 Subject: PPPoE Server In-Reply-To: <1533761373_308475@surgemail.mnsi.net> References: <07be3f37-c89b-2d2f-cc1b-28a413a5e649@interlink.com.ar> <1533761373_308475@surgemail.mnsi.net> Message-ID: <004801d42f5c$6f8aa180$4e9fe480$@wicks.co.nz> Cisco ASR1k can support up to 64K PPPoE depending on the model/cards. Juniper MX and Nokia 7750 can scale up to a couple of hundred thousands depending on the model. The thing to bear in mind is the ASR1000 is a CPU based router, this means it is very flexible (NAT/L2TP etc can just turn on without extra cards) but throughput is limited to your processor capacity and what you turn on. The Juniper MX and Nokia 7750 are more hardware based routers that can massively scale but you need to work closely with the vendor to ensure you have appropriate cards for your intended application. Personally I have used all of these solutions and I would stray towards the Juniper. This being said the Nokia is also a magnificent box albeit a bit less user friendly IMHO. -----Original Message----- From: NANOG On Behalf Of Clayton Zekelman Sent: Thursday, 9 August 2018 8:50 AM To: Jose Jorquera ; Mauro Gasparini Cc: nanog at nanog.org Subject: Re: PPPoE Server I'll second that. Juniper MX works well for us. We have one router terminating 10,000 PPPoE and 3,500 L2TP and it handles the load fine. At 04:43 PM 08/08/2018, Jose Jorquera wrote: >Cisco is the any option? I read about BRAS server on Juniper MX-480,can >you check "Juniper one day: dynamic subscriber management” for more >info. > > > El 08-08-2018, a las 15:22, Mauro Gasparini > escribió: > > > > Good afternoon people. > > I would like to advice me some appliance or > software (running on top level server line) which supports 20,000 > simultaneous PPPoE connections. > > The customer has a Cisco ASR1000 but I don't > have any confirmed experience that can support it. > > > > Mauro Gasparini. > > > > From streinerj at gmail.com Wed Aug 8 21:22:45 2018 From: streinerj at gmail.com (Justin M. Streiner) Date: Wed, 8 Aug 2018 17:22:45 -0400 (EDT) Subject: Multicast traffic % in enterprise network ? In-Reply-To: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: On Wed, 8 Aug 2018, Mankamana Mishra (mankamis) via NANOG wrote: > * If there is any data which can provide what % of traffic is > multicast traffic. And if multicast is removed, how much unicast traffic > it would add up? > * Since this forum has people from deployment area, I would love to > know if there is real deployment problems or its pain to deploy > multicast. > These questions is to work / discussion in IETF to see what is pain > points for multicast, and how can we simplify it. The amount of multicast traffic on an enterprise network will depend greatly on how multicast is being used, and to some extent, the type of business the enterprise is in. An enterprise that uses multicast primarily for IPTV distribution might have different business and technology drivers than, say, a hospital or healthcare organization that has patient monitors that use multicast to communicate back to a central monitoring station. The percentage of multicast traffic in those two scenarios might be vastly different, but no less important to their respective organizations. Thank you jms From saku at ytti.fi Wed Aug 8 21:27:51 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 9 Aug 2018 00:27:51 +0300 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: On Wed, 8 Aug 2018 at 23:53, Stan Barber wrote: > but the basic requirements of the network itself (e.g. IPv6 uses multicast > instead of broadcast for some network control information distribution). This is almost never true, it's rare exception rather than common case. The idea was that in IPv4 networks ARP broadcast waste bandwidth and host CPU. To fix this problem, each host (sufficiently small group of IPv6 addresses unlikely to collide) subscribes to its own multicast group. So we don't need to flood the ND traffic to hosts not needing it. But it turned out supporting ~infinitely many multicast states is harder problem than pushing frames in hardware to all ports. So all practical networks run IPv6 ND same as ARP. Another 'we fixed a problem in IPv6', which turned out to be worse than the original problem and was quietly ignored in practical networks. -- ++ytti From gjshep at gmail.com Wed Aug 8 21:15:11 2018 From: gjshep at gmail.com (Greg Shepherd) Date: Wed, 8 Aug 2018 14:15:11 -0700 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: Financial exchanges around the world use multicast. On Wed, Aug 8, 2018 at 1:31 PM, Stan Barber wrote: > As someone else remarked, part of this will depend on the type of network > you are profiling. One enterprise networking may have critical internal > applications that depend on multicast to work and others may have nothing > but the basic requirements of the network itself (e.g. IPv6 uses multicast > instead of broadcast for some network control information distribution). > > On Wed, Aug 8, 2018 at 11:49 AM, Mankamana Mishra (mankamis) via NANOG < > nanog at nanog.org> wrote: > > > Hi Every one, > > Recently we had good discussion over multicast uses in public internet. > > From discussion, it was pointed out uses of multicast is more with in > > enterprise. Wanted to understand how much % multicast traffic present in > > network > > > > * If there is any data which can provide what % of traffic is > > multicast traffic. And if multicast is removed, how much unicast traffic > it > > would add up? > > * Since this forum has people from deployment area, I would love to > > know if there is real deployment problems or its pain to deploy > multicast. > > > > > > These questions is to work / discussion in IETF to see what is pain > points > > for multicast, and how can we simplify it. > > > > > > > > Thanks > > Mankamana > > > > > From arievayner at gmail.com Wed Aug 8 21:28:26 2018 From: arievayner at gmail.com (Arie Vayner) Date: Thu, 9 Aug 2018 00:28:26 +0300 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: Multicast is heavily used for applications such as stock trading and industrial networks. So it really depends... On Thu, Aug 9, 2018, 00:23 Justin M. Streiner wrote: > On Wed, 8 Aug 2018, Mankamana Mishra (mankamis) via NANOG wrote: > > > * If there is any data which can provide what % of traffic is > > multicast traffic. And if multicast is removed, how much unicast traffic > > it would add up? > > * Since this forum has people from deployment area, I would love to > > know if there is real deployment problems or its pain to deploy > > multicast. > > > These questions is to work / discussion in IETF to see what is pain > > points for multicast, and how can we simplify it. > > The amount of multicast traffic on an enterprise network will depend > greatly on how multicast is being used, and to some extent, the type of > business the enterprise is in. > > An enterprise that uses multicast primarily for IPTV distribution might > have different business and technology drivers than, say, a hospital > or healthcare organization that has patient monitors that use multicast > to communicate back to a central monitoring station. The percentage of > multicast traffic in those two scenarios might be vastly different, but > no less important to their respective organizations. > > Thank you > jms > From nanog at jack.fr.eu.org Wed Aug 8 21:36:20 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Wed, 8 Aug 2018 23:36:20 +0200 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: <5B6B6254.6080809@jack.fr.eu.org> On 08/08/2018 11:27 PM, Saku Ytti wrote: > On Wed, 8 Aug 2018 at 23:53, Stan Barber wrote: > Another 'we fixed a problem in IPv6', which turned out to be worse > than the original problem and was quietly ignored in practical > networks. > Let me fix that for you. Using multicast on IPv6 grant us the ability to do more. Today, this is worthless. Will it be the same tomorrow ? Multicast without NDP is broadcast, thus for that particular thing, ipv6 is just better than ipv4. From nanog at jack.fr.eu.org Wed Aug 8 21:37:12 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Wed, 8 Aug 2018 23:37:12 +0200 Subject: Multicast traffic % in enterprise network ? In-Reply-To: <5B6B6254.6080809@jack.fr.eu.org> References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> <5B6B6254.6080809@jack.fr.eu.org> Message-ID: <5B6B6288.7040103@jack.fr.eu.org> s/NDP/MLD/ On 08/08/2018 11:36 PM, nanog at jack.fr.eu.org wrote: > On 08/08/2018 11:27 PM, Saku Ytti wrote: >> On Wed, 8 Aug 2018 at 23:53, Stan Barber wrote: >> Another 'we fixed a problem in IPv6', which turned out to be worse >> than the original problem and was quietly ignored in practical >> networks. >> > > Let me fix that for you. > Using multicast on IPv6 grant us the ability to do more. > Today, this is worthless. > Will it be the same tomorrow ? > > Multicast without NDP is broadcast, thus for that particular thing, ipv6 > is just better than ipv4. > From jtk at depaul.edu Wed Aug 8 21:53:19 2018 From: jtk at depaul.edu (John Kristoff) Date: Wed, 8 Aug 2018 16:53:19 -0500 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: Message-ID: <20180808165319.7c22c7ed@p50.localdomain> On Wed, 8 Aug 2018 18:49:52 +0000 "Mankamana Mishra (mankamis) via NANOG" wrote: > * If there is any data which can provide what % of traffic is > multicast traffic. And if multicast is removed, how much unicast > traffic it would add up? Good question about the volume (and frequency). I will see if I can measure here, but all I can say if it helps any, is that is still fairly widely used in the enterprise for "imaging" systems. That is, updating a set of systems and apps simultaneously from a single source. > * Since this forum has people from deployment area, I would love > to know if there is real deployment problems or its pain to deploy > multicast. In my experience, real world IP multicast experience and expertise is almost non-existent. This is the big problem potentially, because it is fairly popular on some campuses for niche applications, but it tends to just work once setup and rarely changes. For many R&E institutions, the setup was done a long time ago and people rarely touch it now. However, I rarely see IP multicast-related problems anymore. It helps that interdomain multicast is dying. Traditional PIM-SM with one or more anycast RPs isn't too complicated, and I can't remember the last time anything out of the ordinary came up. A decade or more ago at another institution that did IP/TV over IP multicast to dorms, we'd run into head-banging-against-the-wall problems about once a year. Very painful experiences usually due to buggy router code or interesting switch/router behavior with IGMP-snooping and/or joins/leaves. Those days seem to be behind us. > These questions is to work / discussion in IETF to see what is pain > points for multicast, and how can we simplify it. I can't think of too much that should change now. If I want to simplify and secure things a little more, I'd probably look at better limiting IGMP and PIM joins. Limiting as much of the possibility for anyone or anything to instantiate state in the network devices. SSM without the all the potential source-specific state would be nice. John From surfer at mauigateway.com Wed Aug 8 22:22:04 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 8 Aug 2018 15:22:04 -0700 Subject: Multicast traffic % in enterprise network ? Message-ID: <20180808152204.15360B8D@m0117566.ppops.net> --- jtk at depaul.edu wrote: From: John Kristoff :: In my experience, real world IP multicast experience :: and expertise is almost non-existent. :: but it tends to just work once setup and rarely :: changes. :: the setup was done a long time ago and people rarely :: touch it now. :: If I want to simplify and secure things a little :: more, I'd probably look at better limiting IGMP and :: PIM joins. Limiting as much of the possibility for :: anyone or anything to instantiate state in the :: network Major snippage, but these're my experiences, too. However, not in the .edu world. scott From surfer at mauigateway.com Wed Aug 8 23:17:16 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 8 Aug 2018 16:17:16 -0700 Subject: possible hawaii weather issue next week Message-ID: <20180808161716.15360CBC@m0117566.ppops.net> --- surfer at mauigateway.com wrote: From: "Scott Weeks" If you have stuff in Hawaii, you might want to start thinking about your DR plan. ---------------------------------------- Whew, that was close! http://weather.hawaii.edu/satellite/jsanim.cgi?res=4km&chnl=ir&domain=nep&period=720&incr=30&rr=900&banner=uhmet&satplat=goeswest&overlay=off I don't know if anyone's interested in the discussion, (and perhaps it should go into another thread, if so) but I have been noticing a tendency among managers here to ignore getting ready for stuff like this. Is that normal for what you see or do managers where you are start dusting off and following your DR plan? "We don't have time to moved all that data off site to the mainland and all the other stuff in the plan. We need you to focus on XXX first". scott From ryan at finnesey.com Wed Aug 8 23:56:27 2018 From: ryan at finnesey.com (Ryan Finnesey) Date: Wed, 8 Aug 2018 23:56:27 +0000 Subject: Feedback - SBC Vendors. Message-ID: I am going to have to install a series of SBCs for a voice offering connected to Microsoft Teams. We are going to pass the SIP traffic off to a larger number of SIP providers. I would like to get some feedback from the group on SBC vendors. I have two options for vendors Ribbon or AudioCodes. I am leaning towards a software based SBC over an appliance. Would be helpful to get the other members feedback on Ribbon or AudioCodes deployments within their networks. Cheers Ryan From ramirezcyrus at yahoo.com Thu Aug 9 00:08:31 2018 From: ramirezcyrus at yahoo.com (cyrus ramirez) Date: Thu, 9 Aug 2018 00:08:31 +0000 (UTC) Subject: Feedback - SBC Vendors. In-Reply-To: References: Message-ID: <527991436.4144586.1533773311467@mail.yahoo.com> Hello:Unfortunately, we use Oracle SBC due to our text requirements. Cytus Ramirez Sent from Yahoo Mail on Android On Wed, Aug 8, 2018 at 7:57 PM, Ryan Finnesey wrote: I am going to have to install a series of SBCs for a  voice offering connected to Microsoft Teams.  We are going to pass the SIP traffic off to a larger number of SIP providers.  I would like  to get some feedback from the group on SBC vendors.  I have two options for vendors Ribbon or AudioCodes.  I am leaning towards a software based SBC over an appliance. Would be helpful to get the other members feedback on Ribbon or AudioCodes deployments within their networks. Cheers Ryan From marcusleskex at gmail.com Thu Aug 9 01:51:55 2018 From: marcusleskex at gmail.com (Marcus Leske) Date: Wed, 8 Aug 2018 18:51:55 -0700 Subject: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks) In-Reply-To: References: <004101d40e35$c2daed10$4890c730$@netconsultings.com> <007f01d41707$74e128b0$5ea37a10$@netconsultings.com> Message-ID: What do you mean ? Examples of Telemetry use cases are infinite? Are you asking for popular use cases that were not possible with snmp and netflow? Cheers On Sunday, August 5, 2018, Sami Joseph wrote: > On the topic of marketing hypes vs real requirements, does anyone see real > use cases for telemetry ? Can anyone pls give me examples? > > Thanks > > On Sunday, July 8, 2018, wrote: > >> > From: Marcus Leske [mailto:marcusleskex at gmail.com] >> > Sent: Saturday, July 07, 2018 3:58 PM >> > >> > open APIs tops that funny abuse list IMHO : >> > https://github.com/OAI/OpenAPI-Specification/issues/568 >> > >> > can we change the topic of the thread to an informative one, instead of >> a >> > leaked video or not, to why exactly do network engineers are often >> > confused by the abusive marketing all over the place of what is open and >> > what is not and other computing terms. >> > >> > I guess this is happening in networking more often than other domains >> > because networking people didnt get a chance in their career to learn >> about >> > the world of computing, their heads were somewhere else, learning about >> > complex networking protocols and not the common computing interfaces, >> > the open source world, existing frameworks and paradigms, this video >> helps >> > a bit on how did this happen: >> > https://vimeo.com/262190505https://vimeo.com/262190505 >> > >> > has anyone here seen list of topics that network engineers usually miss >> on >> > their journey ? i know they never get exposed to software development >> > and engineering in general, databases, web technologies, operating >> system >> > fundamentals. >> > >> Well I guess if you stick around in networking for long time you kind of >> get exposed to some of these to a certain level on a day job, some of it >> was covered in school in various levels of detail, and to some of these >> concepts we (networkers) get a specific very narrow filed exposure I'd say, >> like in your example of databases -well various protocol tables are good >> examples of decentralized distributed databases, then some Network OS-es >> are good examples of distributed operating systems. So I guess it then just >> boils down to the willingness of and individual to understand these >> concepts on an ever more fundamental level -with every next interaction >> with these. Maybe it draws one more towards the software development side >> or perhaps more towards the somewhat holistic understanding of the >> networking discipline through graph theory and complex adaptive systems. >> >> >> adam >> >> netconsultings.com >> ::carrier-class solutions for the telecommunications industry:: >> >> >> _______________________________________________ >> 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 branto at argentiumsolutions.com Thu Aug 9 01:54:53 2018 From: branto at argentiumsolutions.com (Brant Ian Stevens) Date: Wed, 8 Aug 2018 21:54:53 -0400 Subject: Nokia SP Business Group Account Contact In-Reply-To: <6a4405f1-ed60-145c-4092-fa5ebb63f13f@argentiumsolutions.com> References: <6a4405f1-ed60-145c-4092-fa5ebb63f13f@argentiumsolutions.com> Message-ID: <5565aa06-3040-4979-d653-ccc3406e8949@argentiumsolutions.com> Thank you to everyone that reached-out to me offline and forwarded my request onward.  I'm all set now. -- Regards, -- Brant I. Stevens On 8/8/18 10:57 AM, Brant Ian Stevens wrote: > Sorry to bother the list, but could someone help me get in touch with > a Nokia account rep from their SP team for the NYC area? Specifically > looking for information on the managed sp wireless solution. > > I've tried going through the website, but have made no progress > reaching the right people to move my request forward. > From marcusleskex at gmail.com Thu Aug 9 01:56:49 2018 From: marcusleskex at gmail.com (Marcus Leske) Date: Wed, 8 Aug 2018 18:56:49 -0700 Subject: YANG daemeon for Linux In-Reply-To: References: Message-ID: Yes Rob, i’d like to do what you described: use netconf and yang to provision the quagga BGP implementation. Can you describe work arounds? If any. Can i convert a bgp yang model to json/yaml and have some other app consume it? Thanks On Sunday, July 29, 2018, Rob Shakir wrote: > Could you define "render"? If you're looking to take a YANG model (which > one?) and configure Linux kernel networking features with it, I can't > recall having seen something that does this. I have been working on a side > project (which I'm hoping to bring to a hackathon) to take Linux networking > and map it to OpenConfig - but this is maexceptionally embryonic. > > If you're looking for ways to manipulate data instances for YANG-modelled > schemas on Linux, here are some options (full disclosure: I lead the > development of two of them): > > - ygot - produces Go structs, or Protobufs that correspond to a YANG > model - github.com/openconfig/ygot > - pyangbind - produces Python classes that correspond to a YANG model - > github.com/robshakir/pyangbind > - ydk (Cisco) - produces Python and C++ APIs, more centred around device > interaction (https://developer.cisco.com/site/ydk/) > > Cheers, > r. > > On Sat, 28 Jul 2018 at 03:54 Vincent Bernat wrote: > > > ❦ 27 juillet 2018 12:23 -0700, Karl Jørn : > > > > > Looking for an agent on Linux that will render YANG models, so I can > > > provision networking on Linux. > > > > Maybe looking at this one: > > http://yuma123.org/wiki/index.php/Yuma_netconfd_Manual > > -- > > Make sure your code "does nothing" gracefully. > > - The Elements of Programming Style (Kernighan & Plauger) > > > From dcorbe at hammerfiber.com Thu Aug 9 02:25:08 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Wed, 8 Aug 2018 22:25:08 -0400 Subject: Feedback - SBC Vendors. In-Reply-To: References: Message-ID: at 7:56 PM, Ryan Finnesey wrote: > I am going to have to install a series of SBCs for a voice offering > connected to Microsoft Teams. We are going to pass the SIP traffic off > to a larger number of SIP providers. I would like to get some feedback > from the group on SBC vendors. I have two options for vendors Ribbon or > AudioCodes. I am leaning towards a software based SBC over an appliance. > > Would be helpful to get the other members feedback on Ribbon or > AudioCodes deployments within their networks. > > Cheers > Ryan I have a few things to add to this because I’ve been through the ringer when it comes to SBCs. 1) I didn’t know AudioCodes still made SBCs. But at one point in time, they absorbed NetRake and promised NetRake’s customers that they’d continue looking after the product. A couple of years after that deal was done, they discontinued support with only a few months warning. So given their track record, maybe it’s something to avoid. 2) No opinion on Ribbon. I’ve never worked with their stuff. If you’re looking for suitable market alternatives for feature and pricing comparison, check out Genband and Sansay. 3) Avoid Oracle’s SBCs like the plague. They used to be Acme Packet, the industry gold standard. But under Oracle, they’ve crushed themselves under the weight of their own apathy. I’ve had nothing but support nightmares. I still to this day have a pair of broken 3830s that they refuse to take a look at. 4) The notion that software based solutions are better than hardware ones is a good notion. On modern hardware, a dual-core VM can process a few thousand simultaneous calls at very healthy and respectable tear-down and set-up rates. And hardware is always going to be more expensive than software. -Daniel From dcorbe at hammerfiber.com Thu Aug 9 02:46:27 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Thu, 09 Aug 2018 02:46:27 +0000 Subject: Multicast traffic % in enterprise network ? In-Reply-To: <20180808152204.15360B8D@m0117566.ppops.net> References: <20180808152204.15360B8D@m0117566.ppops.net> Message-ID: On 8/8/2018 18:22:04, "Scott Weeks" wrote: > >--- jtk at depaul.edu wrote: >From: John Kristoff > >:: In my experience, real world IP multicast experience >:: and expertise is almost non-existent. > > > >Major snippage, but these're my experiences, too. >However, not in the .edu world. > >scott > > > I've been working with IP now for close to 15 years and my first exposure to multicast wasn't until I recently began working on a cable TV product for an ISP that runs a residential access network. So I can believe that, for sure. > From aaron1 at gvtc.com Thu Aug 9 03:07:06 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 8 Aug 2018 22:07:06 -0500 Subject: Feedback - SBC Vendors. In-Reply-To: References: Message-ID: <98F7BB17-BB13-4A20-9953-D81AD237D4A6@gvtc.com> I work for a Telephone/ISP/CATV/Security company.... We used ACME Packet SBC years ago, then migrated to our MetaSwitch IP phone system with Perimeta SBC https://www.metaswitch.com/products/core-network/perimeta-sbc If you would like to talk to the voice engineers that I work with, let me know and I can put you in touch with them. They work closely with those two products (Like I said we migrate away from Acme packet years ago, from what I understand it might be an Oracle product now) Aaron > On Aug 8, 2018, at 6:56 PM, Ryan Finnesey wrote: > > I am going to have to install a series of SBCs for a voice offering connected to Microsoft Teams. We are going to pass the SIP traffic off to a larger number of SIP providers. I would like to get some feedback from the group on SBC vendors. I have two options for vendors Ribbon or AudioCodes. I am leaning towards a software based SBC over an appliance. > > Would be helpful to get the other members feedback on Ribbon or AudioCodes deployments within their networks. > > Cheers > Ryan > From ml at knight-networks.com Thu Aug 9 04:26:29 2018 From: ml at knight-networks.com (Brian Knight) Date: Wed, 08 Aug 2018 23:26:29 -0500 Subject: Multicast traffic % in enterprise network ? In-Reply-To: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: <05a83f94fabe68d0b172231f6059dac5@mail.knight-networks.com> On 2018-08-08 13:49, Mankamana Mishra (mankamis) via NANOG wrote: > Hi Every one, > Recently we had good discussion over multicast uses in public > internet. From discussion, it was pointed out uses of multicast is > more with in enterprise. Wanted to understand how much % multicast > traffic present in network > > * If there is any data which can provide what % of traffic is > multicast traffic. And if multicast is removed, how much unicast > traffic it would add up? > * Since this forum has people from deployment area, I would love > to know if there is real deployment problems or its pain to deploy > multicast. > > > These questions is to work / discussion in IETF to see what is pain > points for multicast, and how can we simplify it. > > > > Thanks > Mankamana Hi Mankamana, I once worked for a financial futures broker-dealer where I implemented multicast, which was around 2009. They had one main application, which was a trading "screen" that traders and customers used to execute trades. I would guesstimate maybe 5-10% of the packets and bytes flowing over the network was multicast, depending on network conditions. In terms of bandwidth savings, I'm not sure how much we saved. We had nine or ten participants using that particular application. However, they all worked on different desks, trading different products. The app was smart enough to send only the price feeds in which the user was interested. Assuming at least 50% of the users looked at the same price feeds 50% of the time, I'd say it saved about 25-50 meg. We also had one major exchange distributing price feeds via multicast. However, that feed was not routed on our network. Our systems plugged directly into exchange-provided switches for the feed. The hurdles I had to overcome to implement multicast were: * The learning curve for PIM. Deciding on the deployment model was difficult, as were the first few support calls. We wound up going with PIM-SM w/ BSR for RP selection. * Vendor support for PIM on our gear. These were mainly troubles with PIM running on firewalls in high-availability mode. If I had to do it over again, I wouldn't have bothered with multicast. It was a great opportunity and we learned a lot, but the app had a unicast mode of operation that would have worked perfectly fine for our purposes. I work for an ISP now. We have decided not to support multicast on our network for now mainly because of the learning curve, and also because we simply don't see that much demand. Those two or three prospective customers that wanted it, wanted it for multi-site video conferencing on an MPLS VPN. Hope this helps, -Brian From bellman at nsc.liu.se Thu Aug 9 08:33:54 2018 From: bellman at nsc.liu.se (Thomas Bellman) Date: Thu, 9 Aug 2018 10:33:54 +0200 Subject: Multicast traffic % in enterprise network ? In-Reply-To: <5B6B6254.6080809@jack.fr.eu.org> References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> <5B6B6254.6080809@jack.fr.eu.org> Message-ID: On 2018-08-08 23:36, nanog at jack.fr.eu.org wrote: > Let me fix that for you. > Using multicast on IPv6 grant us the ability to do more. > Today, this is worthless. > Will it be the same tomorrow ? Problem is, to handle the Neigbour Discovery design (16M multicast groups), we need hardware that does not exist yet, is unlikely to exist for at least another decade and will not be down to reasonable prices (< 5 kUSD) for even longer. In the meantime, IPv6 neigbour discovery *precludes* the use of multicast for other purposes on non-small networks, because IPv6 ND will use up all multicast groups. If ND had limited itself to 256 multicast groups, it wouldn't have been a problem. > Multicast without NDP is broadcast, (With s/NDP/MLD/ as you yourself mentioned.) That's the case for Ethernet. Hop over to the Infiniband or OmniPath world, and multicast without MLD will cause packets to be dropped. There is no such thing as broadcast on IB or OPA. (At least OmniPath does have something called "multicast LID sharing", where the IPv6 ND groups are clamped down to just 512 distinct groups, but I haven't read up on the details for how that works, yet. I don't know offhand if there is something similar for Infiniband.) /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From jwbensley at gmail.com Thu Aug 9 12:24:17 2018 From: jwbensley at gmail.com (James Bensley) Date: Thu, 9 Aug 2018 13:24:17 +0100 Subject: Multicast traffic % in enterprise network ? In-Reply-To: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: On 8 August 2018 at 19:49, Mankamana Mishra (mankamis) via NANOG wrote: > Hi Every one, > Recently we had good discussion over multicast uses in public internet. From discussion, it was pointed out uses of multicast is more with in enterprise. Wanted to understand how much % multicast traffic present in network > > * If there is any data which can provide what % of traffic is multicast traffic. And if multicast is removed, how much unicast traffic it would add up? > * Since this forum has people from deployment area, I would love to know if there is real deployment problems or its pain to deploy multicast. > > > These questions is to work / discussion in IETF to see what is pain points for multicast, and how can we simplify it. A recent customer uses multicast to have the same packet arrive at multiple destinations at the same time for resilience (their own internal systems, not IPTV or media etc). Having just refreshed their network for the next 5-10 years it's not going away anytime soon. Cheers, James. From saku at ytti.fi Thu Aug 9 12:57:47 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 9 Aug 2018 15:57:47 +0300 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: On Thu, 9 Aug 2018 at 15:27, James Bensley wrote: > A recent customer uses multicast to have the same packet arrive at > multiple destinations at the same time for resilience (their own > internal systems, not IPTV or media etc). Having just refreshed their > network for the next 5-10 years it's not going away anytime soon. I believe the same time delivery is motivation for stock exchanges too. One of the larger exchanges used MX and multicast, which of course does btree or utree (in this case utree) replication, which makes delivery times are very much variant. So it is very much implementation detail what type of delivery time differences to expect in different ports and it is not by design superior to unicast. -- ++ytti From jared at puck.nether.net Thu Aug 9 13:00:05 2018 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Aug 2018 09:00:05 -0400 Subject: Akamai Contact In-Reply-To: References: Message-ID: <33215308-D17C-402E-B81E-479DC67B2AAA@puck.nether.net> Replied offlist Jared Mauch > On Aug 8, 2018, at 3:33 PM, Jawaid Bazyar wrote: > > Hi, having trouble engaging with an Akamai contact in relation to the server stack we have here. Feel free to contact me. > > -- > > Jawaid Bazyar > > President > > ph 303.815.1814 > > fax 303.815.1001 > > Jawaid.Bazyar at foreThought.net > From jmilko at gmail.com Thu Aug 9 14:06:03 2018 From: jmilko at gmail.com (James Milko) Date: Thu, 9 Aug 2018 10:06:03 -0400 Subject: Feedback - SBC Vendors. In-Reply-To: References: Message-ID: Which Ribbon product are you looking at? There are quite a few now and they have different code bases/features. JM On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey wrote: > I am going to have to install a series of SBCs for a voice offering > connected to Microsoft Teams. We are going to pass the SIP traffic off to > a larger number of SIP providers. I would like to get some feedback from > the group on SBC vendors. I have two options for vendors Ribbon or > AudioCodes. I am leaning towards a software based SBC over an appliance. > > Would be helpful to get the other members feedback on Ribbon or AudioCodes > deployments within their networks. > > Cheers > Ryan > > From ryan at finnesey.com Thu Aug 9 14:11:30 2018 From: ryan at finnesey.com (Ryan Finnesey) Date: Thu, 9 Aug 2018 14:11:30 +0000 Subject: Feedback - SBC Vendors. In-Reply-To: References: Message-ID: I was looking at SBC SWe (Software Edition) I think the same code base as the - SBC 5400 – appliance. From: James Milko Sent: Thursday, August 9, 2018 10:06 AM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: Feedback - SBC Vendors. Which Ribbon product are you looking at? There are quite a few now and they have different code bases/features. JM On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey > wrote: I am going to have to install a series of SBCs for a voice offering connected to Microsoft Teams. We are going to pass the SIP traffic off to a larger number of SIP providers. I would like to get some feedback from the group on SBC vendors. I have two options for vendors Ribbon or AudioCodes. I am leaning towards a software based SBC over an appliance. Would be helpful to get the other members feedback on Ribbon or AudioCodes deployments within their networks. Cheers Ryan From David.Hiers at cdk.com Thu Aug 9 14:11:33 2018 From: David.Hiers at cdk.com (Hiers, David) Date: Thu, 9 Aug 2018 14:11:33 +0000 Subject: Feedback - SBC Vendors. In-Reply-To: References: Message-ID: You might want to drop this question on the VoiceOps list: voiceops at voiceops.org It runs at a good signal-to-noise ratio, so you'll get some useful responses. David -----Original Message----- From: NANOG [mailto:nanog-bounces+david.hiers=cdk.com at nanog.org] On Behalf Of James Milko Sent: Thursday, August 09, 2018 7:06 AM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: Feedback - SBC Vendors. Which Ribbon product are you looking at? There are quite a few now and they have different code bases/features. JM On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey wrote: > I am going to have to install a series of SBCs for a voice offering > connected to Microsoft Teams. We are going to pass the SIP traffic > off to a larger number of SIP providers. I would like to get some > feedback from the group on SBC vendors. I have two options for > vendors Ribbon or AudioCodes. I am leaning towards a software based SBC over an appliance. > > Would be helpful to get the other members feedback on Ribbon or > AudioCodes deployments within their networks. > > Cheers > Ryan > > ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. From ryan at finnesey.com Thu Aug 9 14:12:48 2018 From: ryan at finnesey.com (Ryan Finnesey) Date: Thu, 9 Aug 2018 14:12:48 +0000 Subject: Feedback - SBC Vendors. In-Reply-To: References: , Message-ID: Thanks I will post there as well ________________________________ From: Hiers, David Sent: Thursday, August 9, 2018 10:11:33 AM To: James Milko; Ryan Finnesey Cc: nanog at nanog.org Subject: RE: Feedback - SBC Vendors. You might want to drop this question on the VoiceOps list: voiceops at voiceops.org It runs at a good signal-to-noise ratio, so you'll get some useful responses. David -----Original Message----- From: NANOG [mailto:nanog-bounces+david.hiers=cdk.com at nanog.org] On Behalf Of James Milko Sent: Thursday, August 09, 2018 7:06 AM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: Feedback - SBC Vendors. Which Ribbon product are you looking at? There are quite a few now and they have different code bases/features. JM On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey wrote: > I am going to have to install a series of SBCs for a voice offering > connected to Microsoft Teams. We are going to pass the SIP traffic > off to a larger number of SIP providers. I would like to get some > feedback from the group on SBC vendors. I have two options for > vendors Ribbon or AudioCodes. I am leaning towards a software based SBC over an appliance. > > Would be helpful to get the other members feedback on Ribbon or > AudioCodes deployments within their networks. > > Cheers > Ryan > > ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. From jwbensley at gmail.com Thu Aug 9 15:54:37 2018 From: jwbensley at gmail.com (James Bensley) Date: Thu, 9 Aug 2018 16:54:37 +0100 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: On 9 August 2018 at 13:57, Saku Ytti wrote: > On Thu, 9 Aug 2018 at 15:27, James Bensley wrote: > >> A recent customer uses multicast to have the same packet arrive at >> multiple destinations at the same time for resilience (their own >> internal systems, not IPTV or media etc). Having just refreshed their >> network for the next 5-10 years it's not going away anytime soon. > > I believe the same time delivery is motivation for stock exchanges > too. One of the larger exchanges used MX and multicast, which of > course does btree or utree (in this case utree) replication, which > makes delivery times are very much variant. > So it is very much implementation detail what type of delivery time > differences to expect in different ports and it is not by design > superior to unicast. I'm definately not saying it was a good idea / good design :) I'm just saying that it's another example of multicast in use that is not the usual IPTV or financial trading (aeronautical in this case). Cheers, James. From smkarp at galliumnetworks.com Thu Aug 9 00:14:39 2018 From: smkarp at galliumnetworks.com (Steven Karp) Date: Thu, 9 Aug 2018 00:14:39 +0000 Subject: PPPoE Server In-Reply-To: <004801d42f5c$6f8aa180$4e9fe480$@wicks.co.nz> References: <07be3f37-c89b-2d2f-cc1b-28a413a5e649@interlink.com.ar> <1533761373_308475@surgemail.mnsi.net>, <004801d42f5c$6f8aa180$4e9fe480$@wicks.co.nz> Message-ID: For 20,000 sessions two or more Juniper VMX routers can share the BNG / BRAS licensing and provide high availability. The BNG licenses for hardware based MX routers are tied to the chassis and cannot be shared between multiple routers. Sent from my mobile device > On Aug 8, 2018, at 4:13 PM, Tony Wicks wrote: > > Cisco ASR1k can support up to 64K PPPoE depending on the model/cards. Juniper MX and Nokia 7750 can scale up to a couple of hundred thousands depending on the model. The thing to bear in mind is the ASR1000 is a CPU based router, this means it is very flexible (NAT/L2TP etc can just turn on without extra cards) but throughput is limited to your processor capacity and what you turn on. The Juniper MX and Nokia 7750 are more hardware based routers that can massively scale but you need to work closely with the vendor to ensure you have appropriate cards for your intended application. Personally I have used all of these solutions and I would stray towards the Juniper. This being said the Nokia is also a magnificent box albeit a bit less user friendly IMHO. > > > > -----Original Message----- > From: NANOG On Behalf Of Clayton Zekelman > Sent: Thursday, 9 August 2018 8:50 AM > To: Jose Jorquera ; Mauro Gasparini > Cc: nanog at nanog.org > Subject: Re: PPPoE Server > > > I'll second that. Juniper MX works well for us. We have one router terminating 10,000 PPPoE and 3,500 L2TP and it handles the load fine. > > > At 04:43 PM 08/08/2018, Jose Jorquera wrote: >> Cisco is the any option? I read about BRAS server on Juniper MX-480,can >> you check "Juniper one day: dynamic subscriber management” for more >> info. >> >>> El 08-08-2018, a las 15:22, Mauro Gasparini >> escribió: >>> >>> Good afternoon people. >>> I would like to advice me some appliance or >> software (running on top level server line) which supports 20,000 >> simultaneous PPPoE connections. >>> The customer has a Cisco ASR1000 but I don't >> have any confirmed experience that can support it. >>> >>> Mauro Gasparini. >>> >>> > From mauro at interlink.com.ar Thu Aug 9 15:57:21 2018 From: mauro at interlink.com.ar (Mauro Gasparini) Date: Thu, 9 Aug 2018 12:57:21 -0300 Subject: PPPoE Server In-Reply-To: <004801d42f5c$6f8aa180$4e9fe480$@wicks.co.nz> References: <07be3f37-c89b-2d2f-cc1b-28a413a5e649@interlink.com.ar> <1533761373_308475@surgemail.mnsi.net> <004801d42f5c$6f8aa180$4e9fe480$@wicks.co.nz> Message-ID: <18bdc08c-d41d-5d00-aa93-372add6e62d0@interlink.com.ar> In fact, today I also received comments about the preferences with Juniper, even with its BNG software mounted on a server. Thank you all for the responses. El 08/08/18 a las 18:11, Tony Wicks escribió: > Cisco ASR1k can support up to 64K PPPoE depending on the model/cards. Juniper MX and Nokia 7750 can scale up to a couple of hundred thousands depending on the model. The thing to bear in mind is the ASR1000 is a CPU based router, this means it is very flexible (NAT/L2TP etc can just turn on without extra cards) but throughput is limited to your processor capacity and what you turn on. The Juniper MX and Nokia 7750 are more hardware based routers that can massively scale but you need to work closely with the vendor to ensure you have appropriate cards for your intended application. Personally I have used all of these solutions and I would stray towards the Juniper. This being said the Nokia is also a magnificent box albeit a bit less user friendly IMHO. > > > > -----Original Message----- > From: NANOG On Behalf Of Clayton Zekelman > Sent: Thursday, 9 August 2018 8:50 AM > To: Jose Jorquera ; Mauro Gasparini > Cc: nanog at nanog.org > Subject: Re: PPPoE Server > > > I'll second that. Juniper MX works well for us. We have one router terminating 10,000 PPPoE and 3,500 L2TP and it handles the load fine. > > > At 04:43 PM 08/08/2018, Jose Jorquera wrote: >> Cisco is the any option? I read about BRAS server on Juniper MX-480,can >> you check "Juniper one day: dynamic subscriber management” for more >> info. >> >>> El 08-08-2018, a las 15:22, Mauro Gasparini >> escribió: >>> Good afternoon people. >>> I would like to advice me some appliance or >> software (running on top level server line) which supports 20,000 >> simultaneous PPPoE connections. >>> The customer has a Cisco ASR1000 but I don't >> have any confirmed experience that can support it. >>> Mauro Gasparini. >>> >>> > From bruce.curtis at ndsu.edu Thu Aug 9 18:41:02 2018 From: bruce.curtis at ndsu.edu (Curtis, Bruce) Date: Thu, 9 Aug 2018 18:41:02 +0000 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: Multicast was also required for earlier versions of VXLAN. But later versions or VXLAN only require unicast. For the far future it seems like Named Data Neworking, Content Centric Networking, Information Centric Networking, Data Centric Networking etc all list multicast as a requirement or fundamental part of their architecture. > On Aug 8, 2018, at 4:15 PM, Greg Shepherd wrote: > > Financial exchanges around the world use multicast. > > On Wed, Aug 8, 2018 at 1:31 PM, Stan Barber wrote: > >> As someone else remarked, part of this will depend on the type of network >> you are profiling. One enterprise networking may have critical internal >> applications that depend on multicast to work and others may have nothing >> but the basic requirements of the network itself (e.g. IPv6 uses multicast >> instead of broadcast for some network control information distribution). >> >> On Wed, Aug 8, 2018 at 11:49 AM, Mankamana Mishra (mankamis) via NANOG < >> nanog at nanog.org> wrote: >> >>> Hi Every one, >>> Recently we had good discussion over multicast uses in public internet. >>> From discussion, it was pointed out uses of multicast is more with in >>> enterprise. Wanted to understand how much % multicast traffic present in >>> network >>> >>> * If there is any data which can provide what % of traffic is >>> multicast traffic. And if multicast is removed, how much unicast traffic >> it >>> would add up? >>> * Since this forum has people from deployment area, I would love to >>> know if there is real deployment problems or its pain to deploy >> multicast. >>> >>> >>> These questions is to work / discussion in IETF to see what is pain >> points >>> for multicast, and how can we simplify it. >>> >>> >>> >>> Thanks >>> Mankamana >>> >>> >> --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From andy at newslink.com Thu Aug 9 18:41:40 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Thu, 9 Aug 2018 13:41:40 -0500 Subject: Yahoo Groups contact Message-ID: Any chance someone here has admin/troubleshooting involvement with Yahoo Groups, or knows someone who does? Much appreciated. ---- Andy Ringsmuth andy at newslink.com 5609 Harding Dr. Lincoln, NE 68521 (402) 304-0083 cellular From gjshep at gmail.com Thu Aug 9 18:56:52 2018 From: gjshep at gmail.com (Greg Shepherd) Date: Thu, 9 Aug 2018 11:56:52 -0700 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: On Thu, Aug 9, 2018 at 11:41 AM, Curtis, Bruce wrote: > > Multicast was also required for earlier versions of VXLAN. But later > versions or VXLAN only require unicast. > > For the far future it seems like Named Data Neworking, Content Centric > Networking, Information Centric Networking, Data Centric Networking etc all > list multicast as a requirement or fundamental part of their architecture. And they would all be better served by using BIER. Greg > > On Aug 8, 2018, at 4:15 PM, Greg Shepherd wrote: > > > > Financial exchanges around the world use multicast. > > > > On Wed, Aug 8, 2018 at 1:31 PM, Stan Barber wrote: > > > >> As someone else remarked, part of this will depend on the type of > network > >> you are profiling. One enterprise networking may have critical internal > >> applications that depend on multicast to work and others may have > nothing > >> but the basic requirements of the network itself (e.g. IPv6 uses > multicast > >> instead of broadcast for some network control information distribution). > >> > >> On Wed, Aug 8, 2018 at 11:49 AM, Mankamana Mishra (mankamis) via NANOG < > >> nanog at nanog.org> wrote: > >> > >>> Hi Every one, > >>> Recently we had good discussion over multicast uses in public internet. > >>> From discussion, it was pointed out uses of multicast is more with in > >>> enterprise. Wanted to understand how much % multicast traffic present > in > >>> network > >>> > >>> * If there is any data which can provide what % of traffic is > >>> multicast traffic. And if multicast is removed, how much unicast > traffic > >> it > >>> would add up? > >>> * Since this forum has people from deployment area, I would love to > >>> know if there is real deployment problems or its pain to deploy > >> multicast. > >>> > >>> > >>> These questions is to work / discussion in IETF to see what is pain > >> points > >>> for multicast, and how can we simplify it. > >>> > >>> > >>> > >>> Thanks > >>> Mankamana > >>> > >>> > >> > > > --- > Bruce Curtis bruce.curtis at ndsu.edu > Certified NetAnalyst II 701-231-8527 > North Dakota State University > > From shawnritchie at gmail.com Thu Aug 9 21:47:04 2018 From: shawnritchie at gmail.com (Shawn Ritchie) Date: Thu, 9 Aug 2018 16:47:04 -0500 Subject: Feedback - SBC Vendors. In-Reply-To: References: Message-ID: I second what's been said about ACME Packet; loved them when we first got them, phasing them out now in favor of Ribbon due to what a pain Oracle has been to deal with. We're all hardware on the Ribbon side, using both the 5k line and some premise 1k SBC's. They've been fine so far. On Thu, Aug 9, 2018 at 9:26 AM Ryan Finnesey wrote: > Thanks I will post there as well > > > > > > > > ________________________________ > From: Hiers, David > Sent: Thursday, August 9, 2018 10:11:33 AM > To: James Milko; Ryan Finnesey > Cc: nanog at nanog.org > Subject: RE: Feedback - SBC Vendors. > > You might want to drop this question on the VoiceOps list: > > voiceops at voiceops.org > > It runs at a good signal-to-noise ratio, so you'll get some useful > responses. > > > David > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+david.hiers=cdk.com at nanog.org] On > Behalf Of James Milko > Sent: Thursday, August 09, 2018 7:06 AM > To: Ryan Finnesey > Cc: nanog at nanog.org > Subject: Re: Feedback - SBC Vendors. > > Which Ribbon product are you looking at? There are quite a few now and > they have different code bases/features. > > JM > > On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey wrote: > > > I am going to have to install a series of SBCs for a voice offering > > connected to Microsoft Teams. We are going to pass the SIP traffic > > off to a larger number of SIP providers. I would like to get some > > feedback from the group on SBC vendors. I have two options for > > vendors Ribbon or AudioCodes. I am leaning towards a software based SBC > over an appliance. > > > > Would be helpful to get the other members feedback on Ribbon or > > AudioCodes deployments within their networks. > > > > Cheers > > Ryan > > > > > > ---------------------------------------------------------------------- > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, notify the sender immediately by > return email and delete the message and any attachments from your system. > -- Shawn From rfg at tristatelogic.com Fri Aug 10 02:29:10 2018 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 09 Aug 2018 19:29:10 -0700 Subject: Summer of Hijacks: My message to RIPE and the RIPE Executive Board Message-ID: <57557.1533868150@segfault.tristatelogic.com> Found yet another big hijacking operation. Coming out of RIPEland, again. See below for full details. I didn't really want to post again to NANOG on this topic (hijacks) quite this soon, but the bloody European crooks, spammers, and hijackers aren't really giving me a break, and I can't abide just sitting in silence and stewing about it for another month or three. I mean this stuff is just getting ridiculous. And I do wory that the Internet community is just starting to accept this stuff as "normal behavior", which it isn't. Maybe the following will finally get somebody's attention in RIPEland, but I'm not holding my breath for what I personally consider a Good Outcome (which would include full disclosure about what the hell they are actually going to do about any of this, which is probably far too much to even hope for). I'll probably be permanently banned from all of the relevant RIPE mailing lists for having posted this. I just skimmed over RIPE's Code of Conduct for their mailing lists and it basically says that Thou Shalt Not Say Anything Bad About Anybody Specifically, Ever, and I'm pretty sure that I just broke that rule, in spades. Oh well. May God bless the First Amendment, and may God bless NANOG! P.S. It was just now brough to my attention that AS197328, Istanbuldc, is -only- routing 176.116.0.0/19, which looks to be one of the few routes that are maintained by MNT-SERVERSGET that are actually for legitimately allocated IPv4 blocks. For the record, I do not dispute that some of the routes maintained by MNT-SERVERSGET are for legitimately allocated space. I will and do however dispute any assertion that ALL such routes are for IP space that has been legitimately allocated to either Mr. Alexander Samuilov or to his various corporate identities or corporate partners. That does not appear to be the case, based on the evidence. (note - minor edits applied) ========================================================================== From: "Ronald F. Guilmette" To: exec-board at ripe.net, db-wg at ripe.net, routing-wg at ripe.net, anti-abuse-wg at ripe.net, noc at ripe.net, Subject: The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top The entire set of objects in the RIPE WHOIS data base that are currently registered with mnt-by: MNT-SERVERSGET is listed here: https://pastebin.com/raw/GiYWxHMh Among this set of objects there are 235 separate route objects. Evidence indicates persuasively that some sizable fraction of these RIPE- registered route objects are fradulent and are simply there to provide cover for multiple IPv4 address block hijacks. The presence of these objects in the data base permits the following set of ASNs to claim that they are acting "legitimately" even as they route these hijacked blocks: AS9009 M247 Ltd (UK) AS43350 NFOrce Internet Sevices (Netherlands) AS57129 Optibit, LLC (Russia) AS197328 Istanbuldc Veri Merkezi Ltd. Sti (Turkey) -- SEE NOTE ABOVE AS202287 Men Danil Valentinovich (Russia) AS204895 Santa Plus, LLC (Russia) The total amount of IPv4 space encompassed within the set of route objects registered with mnt-by: MNT-SERVERSGET at the present time amounts to eight hundred and fifty nine (859) /24 blocks. Of these, only three hundred and five (305) actually have correctly functioning and properly delegated reverse DNS at the present time, and even among those, only two hundred and two (202) have functioning reverse DNS delegations to the prefered name servers of MNT-SERVERSGET, which is to say the name servers ns5.dnsget.top and ns6.dnsget.top. The bottom line is that it appears that, at the present time, something less than 1/4 of all of the IPv4 address space currently registered in the RIPE data base (via route objects) by and to MNT-SERVERSGET is space for which a plausible case could be made that the blocks in question are actually legitimately assigned to and/or under the legitimate control of MNT-SERVERSGET aka Mr. Alexander Samuilov. The other 3/4ths of the IPv4 space in question has provenance which is, at best, dubious. Due to its use of little country-of-registration flags for each IP address block, the web site bgp.he.net provides the most visually obvious indications of at least two of the specific block hijacks in this case, specifically the hijacks of 27.103.192.0/19 and 36.0.192.0/19 by AS57129: https://bgp.he.net/AS57129#_prefixes Based upon the foregoing, I hereby respectfully request RIPE NCC to undertake an immediate and conmprehensive review of all objects in the data base that are currently registered with mnt-by: MNT-SERVERSGET. Additionally, I also respectfully request RIPE NCC to publish the results of this review to the mailing lists of the Database Working Group and the Anti-Abuse Working Group. The charters of both of these Working Groups are directly relevant to this issue, and there exists neither need nor reason to simply sweep this issue quietly under the carpet, as has been done in previous and similar cases. Cases such as this, and the two others of similar magnitude that I have publicly disclosed just this summer, affect the operation of, the stability of, and the continued enjoyment of the entire planetary Internet and its billions of users. Despite its status as a strictly private corporation, RIPE has a public responsibility, not only to handle such incidents responsibly and competently, but to show the world that it is ready, willing, and able to do so. The responses of RIPE to prior instances of this exact type of bad behavior have been largely or entirely cloaked in secrecy, presumably to protect the guilty. This longstanding and antiquated tradition of omerta within the RIPE community is unambiguously counterproductive to the goal of a well-managed and properly fuctioning Internet. Just as importantly, it naturally gives rise to unavoidable questions about the actual competence of, and capabilities of RIPE NCC staff as they attempt to deal with such incidents. I personally feel that RIPE NCC staff are doing the best they can when responding to incidents such as this, but the tradition of playing "hide the ball" with respect to their actions in such cases reflects badly on them, and badly on RIPE generally. It certainly raises doubts about RIPE's claim to authority over even its own data base. Lastly, I respectfully request both the RIPE Executive Board and the RIPE membership to make plain and explicit their respective intentions with regards to the various bad actors that have been caught, and that may in future be caught red handed engaging in the deliberate and premeditated corruption of the RIPE data base. To date, the policies an actions that RIPE applies, or which RIPE may apply to such bad actors have been shrouded in apparently deliberate secrecy and mystery. To put this request in more concrete terms, I would like to know if RIPE and the Executive Board actually and deliberately intend to take no action whatsoever with respect to the ongoing RIPE memberships of clearly identified bad actors, specifically, in this case, whatever persons or entities are currently repreesented by the RIPE WHOIS handle MNT-SERVERSGET (aka AS202287 and AS202275), which would appear to be this specific entity / RIPE member: https://www.ripe.net/membership/indices/data/ru.danil.html Is it the express intention of both the Board and the RIPE membership to simply deprive this bad actor of just those fradulent data base entries that have effectively legitimized his/her/its fradulent routing announcements? Is it the express intention of both the Board and the RIPE membership to simply make this bad actor give back what he has stolen, and to otherwise take no action, just as the response has been in the two other and similar cases that have also arisen in the RIPE region and that I have also publicly reported on this summer? https://mailman.nanog.org/pipermail/nanog/2018-June/096034.html https://mailman.nanog.org/pipermail/nanog/2018-July/096437.html My question is prompted by the following simple facts. In the two prior cases cited above, and also in the one I am presenting here today, the bad actors involved were seen to have not only hijacked large swaths of IP address space that clearly didn't belong to them, but also, as in the case I am presenting today, these same bad actors additionally acted to corrupt the RIPE data base with premeditated and deliberately fradulent entries. Nonetheless, and regardless of these attacks on the reliability and trustworthyness of the RIPE data base, to date it appears that no action whatsoever has been taken which might affect the ongoing RIPE memberships of the relevant parties and bad actors involved, and they are all still members in good standing of RIPE at the present time: https://www.ripe.net/membership/indices/data/pt.bitcanal-pt.html https://www.ripe.net/membership/indices/data/ua.d2investukraine.html https://www.ripe.net/membership/indices/data/bz.universal.html This is, to say the least, puzzling. I would like to know when, where, and how the Executive Board and/or the RIPE membership reached the altogether dubious conclusion that the best possible way to deal with bad actors such as these is to make them give back -just- the stuff the stole, and then to otherwise impose no penality of any kind, thus allowing them to live on, so that they may hijack another day. Whether this policy is a result of either deliberation or default, it *does* appear to be the policy, based on the evidence. Without intending to be rude, I feel that I must ask the obvious question: In what Universe does this otherwise admirable and generous Christian policy of "turning the other cheek" with respect to such verified bad actors have any effect other than encouraging the next hijacker, and then next one, and the one after that? Has either the Board or the membership even ever seriously debated what penalties should be imposed upon those members who are caught red handed deliberately corrupting the RIPE data base? Is the present RIPE policy of "forgive and forget" with respect to such travesties a product of anyone's intentional design, or is it instead merely the result of utter apathy and indifference on the part of the entire RIPE community? In either case, I believe it to be self evident that the time is... ummm... blooming, blossoming, burgeoning, flourishing, and flowering for this policy to be reexamined and revised. From where I am sitting it is self evident that the current policy of turning a blind eye to these events, and to the bad actors behind them is quite clearly encouraging others to follow suit and to themselves undertake the exact same sorts of travesties. Why shouldn't they? There is no downside. At the very worst, one is simply made to give back all of the stuff that one has stolen, and one is then allowed to go on one's merry way. Regards, rfg P.S. As incensed as I am at the fact that the above named bad actors have been allowed not only to retain their RIPE memberships, but also, apparently, 100% of their legitimately-allocated number resources, this is not even nearly as utterly appalling and inexplicable as the fact that two of the bad actors with direct and provable connections to the prior instances of hijacking that I have reported on publicly this summer have been allowed to remain as officially recognized RIPE IP brokers: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/brokers I am referring here specifically to Ebonyhorizon Telecomunicacoes Lda (aka Bitcanal) and also to NetAssist LLC (AS29632), which conveniently continues to maintain its association with, and peering arrangements with both AS57166 aka D2 International Investment Ukraine, Ltd. and, indirectly via D2, AS205869 aka Universal IP Solution Corp., both of which apparently continue to this day to try their best to hijack, either directly or indirectly, via AS Path fraud, a number of IPv4 blocks that clearly do not belong to any of these three Ukranian entities: https://bgp.he.net/AS57166#_peers https://bgp.he.net/AS205869#_peers https://bgp.he.net/AS29632#_peers What IP blocks are these two officially recognized RIPE IP brokers, Ebony Horizon and NetAssist brokering, exactly? Are they blocks that have been successfully hijacked? Does either RIPE or RIPE NCC even know? Does either RIPE or RIPE NCC even care? (One cannot help but wonder what might occur if RIPE were put in charge of distributing meat supplies within Europe. Would RIPE officially designate the McDonald's "Hamburglar" as RIPE's officially recognized agent for said distributions?) I guess that, in the end, all of the questions I have raised above can be boiled down to just one simple question: Who exactly does one need to either kill or maim or seriously wound in order to get kicked out of this organization (RIPE)? Regards, rfg P.P.S. Among the set of six companies / ASNs listed toward the top of this message as possible facilitators of the current hijacks of MNT-SERVERSGET, three are already fairly well known... at least in anti-spam circles... as being among "the usual suspects" when it comes to facilitating spamming and spammers. And no, I do not care to publicly specify which three. It may be true, as the saying goes that "On the Internet, nobody knows that you're a dog", but memories are long, and people don't forget if your company has been repeatedly caught acting like one. From jethro.binks at strath.ac.uk Fri Aug 10 07:44:55 2018 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Fri, 10 Aug 2018 08:44:55 +0100 (BST) Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: In terms of other Internet use, the BBC recently published this white paper on the R&D efforts with HTTP Server Push/QUIC, part of which describes an "experimental IP multicast profile of HTTP over QUIC". https://www.bbc.co.uk/rd/publications/whitepaper336 Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. On Thu, 9 Aug 2018, Curtis, Bruce wrote: > Multicast was also required for earlier versions of VXLAN. But later versions or VXLAN only require unicast. > > For the far future it seems like Named Data Neworking, Content Centric Networking, Information Centric Networking, Data Centric Networking etc all list multicast as a requirement or fundamental part of their architecture. > > > On Aug 8, 2018, at 4:15 PM, Greg Shepherd wrote: > > > > Financial exchanges around the world use multicast. > > > > On Wed, Aug 8, 2018 at 1:31 PM, Stan Barber wrote: > > > >> As someone else remarked, part of this will depend on the type of network > >> you are profiling. One enterprise networking may have critical internal > >> applications that depend on multicast to work and others may have nothing > >> but the basic requirements of the network itself (e.g. IPv6 uses multicast > >> instead of broadcast for some network control information distribution). > >> > >> On Wed, Aug 8, 2018 at 11:49 AM, Mankamana Mishra (mankamis) via NANOG < > >> nanog at nanog.org> wrote: > >> > >>> Hi Every one, > >>> Recently we had good discussion over multicast uses in public internet. > >>> From discussion, it was pointed out uses of multicast is more with in > >>> enterprise. Wanted to understand how much % multicast traffic present in > >>> network > >>> > >>> * If there is any data which can provide what % of traffic is > >>> multicast traffic. And if multicast is removed, how much unicast traffic > >> it > >>> would add up? > >>> * Since this forum has people from deployment area, I would love to > >>> know if there is real deployment problems or its pain to deploy > >> multicast. > >>> > >>> > >>> These questions is to work / discussion in IETF to see what is pain > >> points > >>> for multicast, and how can we simplify it. > >>> > >>> > >>> > >>> Thanks > >>> Mankamana > >>> > >>> > >> > > > --- > Bruce Curtis bruce.curtis at ndsu.edu > Certified NetAnalyst II 701-231-8527 > North Dakota State University > > From jwbensley at gmail.com Fri Aug 10 12:02:38 2018 From: jwbensley at gmail.com (James Bensley) Date: Fri, 10 Aug 2018 13:02:38 +0100 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: On 10 August 2018 at 08:44, Jethro R Binks wrote: > > In terms of other Internet use, the BBC recently published this white > paper on the R&D efforts with HTTP Server Push/QUIC, part of which > describes an "experimental IP multicast profile of HTTP over QUIC". > > https://www.bbc.co.uk/rd/publications/whitepaper336 > > Jethro. The BBC publishes this list of multicast partners but I'm not sure if it's up-to-date and they still offer multicast outside of their own network? iPlayer is unicast to consumer, so? Do they offer multicast to iPlayer to these partners or only for set-top-box services? Cheers, James. From brandon at rd.bbc.co.uk Fri Aug 10 12:30:29 2018 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 10 Aug 2018 13:30:29 +0100 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: <20180810123029.GA15420@sunf10.rd.bbc.co.uk> On Fri Aug 10, 2018 at 08:44:55AM +0100, Jethro R Binks wrote: > In terms of other Internet use, the BBC recently published this white > paper on the R&D efforts with HTTP Server Push/QUIC, part of which > describes an "experimental IP multicast profile of HTTP over QUIC". > > https://www.bbc.co.uk/rd/publications/whitepaper336 We're doing this as part of our work on moving the entirety of broadcast, from camera to viewer, to IP. The broadcast industry is going this way now (visit IBC or NAB and see) so you'll see plenty of multicast inside their networks https://www.bbc.co.uk/rd/publications/whitepaper268 I've kept out of the multicast hate fest, it's a tool and some tools work better in some situations than others, some may be a bit old and blunt. I don't think banishing multicast is the answer. It would be better to fix the problems instead, if we don't want to sustain the content based balkanisation of the internet by content rights holders and eyeball networks that support them to exlude competition. Internet VOD is huge but there is little linear TV. VOD traffic is driving standards development not linear TV, so there is no demand to fix inter domain multicast. We think our iPlayer VOD service traffic is quite large but it is only 5% of our viewing so linear TV is not dead yet, especially for major events. We could scale our CDNs for this but multicast does it more efficiently in some networks. https://www.bbc.co.uk/rd/blog/2018-07-ultra-high-definition-uhd-viewing Our aim with MPEG-DASH is to have one standard for uni and multicast streaming where clients transparently use whichever works. If an edge network wishes to use multicast, as many do for IPTV, they can but they may have to use unicast from the origin, we didn't want to be delayed for another 10 years waiting for other networks to turn it (back) on. The edge network does not have to roll out multicast 100% as it will just be used wherever it happens to have been deployed. There have been standards for this, usually with tunnels. Using the same DASH stream format means it's simpler to do transparently this way giving networks more flexibility to handle the capacity issues when we do a World Cup in IP only. https://www.bbc.co.uk/sport/football/44850988 The latency problem remains, people don't like hearing the goal cheers through the wall and waiting for it to appear on their screen. Sometimes not all new standards, forcing video over HTTP rather than RTSP, are progress. brandon From job at ntt.net Fri Aug 10 12:30:38 2018 From: job at ntt.net (Job Snijders) Date: Fri, 10 Aug 2018 12:30:38 +0000 Subject: celebrating 10 years of routing insecurity Message-ID: <20180810123038.GB70217@vurt.meerval.net> Dear all, Today marks the 10th anniversary of the famous Kapela-Pilosov Man-in-the-middle BGP attack! It is a fantastic and innovative attack that would be worthy of referencing in the next Mr Robot season. :-) video: https://www.youtube.com/watch?v=S0BM6aB90n8 slide: https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf So, what is the state of routing security anno 2018? It seems that as an industry we're on an upwards trajectory: various IRR registries are locking themselves down to prevent creation of unauthorized route(6) objects, new filter generation tools are becoming available, RPKI based BGP Origin Validation is slowly seeing more and more deployment, and the concept of blocking route announcements with improbable AS_PATHs is gaining popularity as well. Let's see where we are 10 years from now! Kind regards, Job From brandon at rd.bbc.co.uk Fri Aug 10 12:40:52 2018 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 10 Aug 2018 13:40:52 +0100 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: <20180810124052.GA17224@sunf10.rd.bbc.co.uk> On Fri Aug 10, 2018 at 01:02:38PM +0100, James Bensley wrote: > Do they offer multicast to iPlayer to these partners or only > for set-top-box services? Only to STB currently, with little end user device support for multicast it didn't go anywhere as a direct consumer proposition. The ISPs with enough users to make it worthwhile either had their own STB (Virgin, Sky) or jointly made one with us (Youview - BT/TalkTalk) brandon From alan.buxey at gmail.com Fri Aug 10 12:53:29 2018 From: alan.buxey at gmail.com (Alan Buxey) Date: Fri, 10 Aug 2018 13:53:29 +0100 Subject: Multicast traffic % in enterprise network ? In-Reply-To: References: <4255D3BD-EBCC-4924-B6C4-4E5D53D824E9@cisco.com> Message-ID: when i was last on a proper working multicast-enabled UK university network, could pick up the BBC streams (TV and radio) using VLC :) alan From cscora at apnic.net Fri Aug 10 18:03:12 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Aug 2018 04:03:12 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180810180312.B04ADC450F@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 11 Aug, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 710351 Prefixes after maximum aggregation (per Origin AS): 272851 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 341377 Total ASes present in the Internet Routing Table: 61486 Prefixes per ASN: 11.55 Origin-only ASes present in the Internet Routing Table: 53097 Origin ASes announcing only one prefix: 23134 Transit ASes present in the Internet Routing Table: 8389 Transit-only ASes present in the Internet Routing Table: 266 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 71 Number of instances of unregistered ASNs: 71 Number of 32-bit ASNs allocated by the RIRs: 23624 Number of 32-bit ASNs visible in the Routing Table: 19037 Prefixes from 32-bit ASNs in the Routing Table: 79679 Number of bogon 32-bit ASNs visible in the Routing Table: 107 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 275 Number of addresses announced to Internet: 2857141828 Equivalent to 170 /8s, 76 /16s and 134 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 237154 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 193620 Total APNIC prefixes after maximum aggregation: 55167 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 191870 Unique aggregates announced from the APNIC address blocks: 79105 APNIC Region origin ASes present in the Internet Routing Table: 8995 APNIC Prefixes per ASN: 21.33 APNIC Region origin ASes announcing only one prefix: 2537 APNIC Region transit ASes present in the Internet Routing Table: 1341 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3958 Number of APNIC addresses announced to Internet: 767223811 Equivalent to 45 /8s, 186 /16s and 232 /24s 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, 64297-64395, 131072-139577 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: 210910 Total ARIN prefixes after maximum aggregation: 100181 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 210886 Unique aggregates announced from the ARIN address blocks: 99818 ARIN Region origin ASes present in the Internet Routing Table: 18212 ARIN Prefixes per ASN: 11.58 ARIN Region origin ASes announcing only one prefix: 6737 ARIN Region transit ASes present in the Internet Routing Table: 1812 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2396 Number of ARIN addresses announced to Internet: 1103025824 Equivalent to 65 /8s, 190 /16s and 214 /24s 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-399260 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: 194304 Total RIPE prefixes after maximum aggregation: 92790 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 190611 Unique aggregates announced from the RIPE address blocks: 113115 RIPE Region origin ASes present in the Internet Routing Table: 25398 RIPE Prefixes per ASN: 7.50 RIPE Region origin ASes announcing only one prefix: 11460 RIPE Region transit ASes present in the Internet Routing Table: 3514 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7284 Number of RIPE addresses announced to Internet: 714048896 Equivalent to 42 /8s, 143 /16s and 133 /24s 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, 64396-64495 196608-207259 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: 92228 Total LACNIC prefixes after maximum aggregation: 20546 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 93649 Unique aggregates announced from the LACNIC address blocks: 41078 LACNIC Region origin ASes present in the Internet Routing Table: 7399 LACNIC Prefixes per ASN: 12.66 LACNIC Region origin ASes announcing only one prefix: 2008 LACNIC Region transit ASes present in the Internet Routing Table: 1387 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4944 Number of LACNIC addresses announced to Internet: 172309792 Equivalent to 10 /8s, 69 /16s and 61 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 19217 Total AfriNIC prefixes after maximum aggregation: 4104 AfriNIC Deaggregation factor: 4.68 Prefixes being announced from the AfriNIC address blocks: 23060 Unique aggregates announced from the AfriNIC address blocks: 8018 AfriNIC Region origin ASes present in the Internet Routing Table: 1185 AfriNIC Prefixes per ASN: 19.46 AfriNIC Region origin ASes announcing only one prefix: 392 AfriNIC Region transit ASes present in the Internet Routing Table: 237 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 455 Number of AfriNIC addresses announced to Internet: 100085248 Equivalent to 5 /8s, 247 /16s and 46 /24s 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 4689 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4405 477 468 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2969 1153 83 VIETEL-AS-AP Viettel Group, VN 4766 2830 11132 759 KIXS-AS-KR Korea Telecom, KR 9829 2816 1497 543 BSNL-NIB National Internet Backbone, IN 45899 2573 1634 157 VNPT-AS-VN VNPT Corp, VN 9394 2543 4907 32 CTTNET China TieTong Telecommunications 17974 2261 962 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2249 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2115 417 203 TATACOMM-AS TATA Communications formerl 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 6327 3442 1324 82 SHAW - Shaw Communications Inc., CA 22773 3253 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2842 256 421 CABLEONE - CABLE ONE, INC., US 16509 2259 4791 768 AMAZON-02 - Amazon.com, Inc., US 18566 2166 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2124 2641 484 CHARTER-NET-HKY-NC - Charter Communicat 30036 2018 344 142 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 2007 1031 1445 AKAMAI-AS - Akamai Technologies, Inc., 209 1994 5085 604 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 7018 1764 20206 1281 ATT-INTERNET4 - AT&T Services, Inc., US 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 12479 4682 1613 128 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2819 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2552 624 1891 AKAMAI-ASN1, US 12389 2042 1891 731 ROSTELECOM-AS, RU 34984 2013 335 506 TELLCOM-AS, TR 9121 1837 1692 19 TTNET, TR 13188 1605 100 39 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1204 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5191 3349 607 Uninet S.A. de C.V., MX 10620 3483 531 456 Telmex Colombia S.A., CO 11830 2657 369 78 Instituto Costarricense de Electricidad 6503 1666 444 63 Axtel, S.A.B. de C.V., MX 7303 1508 1027 189 Telecom Argentina S.A., AR 28573 1087 2241 189 CLARO S.A., BR 3816 1020 508 128 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 933 377 31 Telefonica del Peru S.A.A., PE 11172 929 126 85 Alestra, S. de R.L. de C.V., MX 18881 913 1078 30 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1172 396 48 LINKdotNET-AS, EG 37611 890 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 744 1411 40 ETISALAT-MISR, EG 24835 635 818 18 RAYA-AS, EG 8452 602 1730 18 TE-AS TE-AS, EG 37492 474 470 57 ORANGE-, TN 29571 459 68 12 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 373 231 15 MauritiusTelecom, MU 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 8151 5191 3349 607 Uninet S.A. de C.V., MX 4538 4689 4192 74 ERX-CERNET-BKB China Education and Rese 12479 4682 1613 128 UNI2-AS, ES 7545 4405 477 468 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3483 531 456 Telmex Colombia S.A., CO 6327 3442 1324 82 SHAW - Shaw Communications Inc., CA 22773 3253 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2969 1153 83 VIETEL-AS-AP Viettel Group, VN 11492 2842 256 421 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4538 4689 4615 ERX-CERNET-BKB China Education and Research Net 12479 4682 4554 UNI2-AS, ES 7545 4405 3937 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3442 3360 SHAW - Shaw Communications Inc., CA 22773 3253 3104 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 10620 3483 3027 Telmex Colombia S.A., CO 7552 2969 2886 VIETEL-AS-AP Viettel Group, VN 8551 2819 2775 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2657 2579 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 64514 PRIVATE 5.42.231.0/24 35753 ITC ITC AS number, SA 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 64500 DOCUMENT 45.43.56.0/24 135391 AOFEI-HK AOFEI DATA INTERNATIO 268422 UNALLOCATED 45.160.208.0/24 263321 Ejmnet Tecnologia ltda, BR 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 45.121.32.0/22 134356 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:14 /9:11 /10:36 /11:99 /12:291 /13:570 /14:1096 /15:1896 /16:13372 /17:7913 /18:13792 /19:25356 /20:39404 /21:45677 /22:88015 /23:71590 /24:399059 /25:800 /26:602 /27:627 /28:35 /29:20 /30:19 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3427 4682 UNI2-AS, ES 6327 3231 3442 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2515 3253 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2281 2819 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 2214 2842 CABLEONE - CABLE ONE, INC., US 18566 2060 2166 MEGAPATH5-US - MegaPath Corporation, US 11830 2005 2657 Instituto Costarricense de Electricidad y Telec 30036 1770 2018 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1575 3483 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1612 2:835 4:18 5:2827 6:43 7:1 8:1128 12:1877 13:210 14:1795 15:31 16:3 17:190 18:54 20:50 23:2464 24:2209 25:2 27:2476 31:2020 32:88 35:29 36:512 37:2883 38:1486 39:254 40:122 41:3154 42:652 43:1967 44:122 45:5309 46:3101 47:197 49:1333 50:1049 51:318 52:1078 54:370 55:1 56:12 57:39 58:1622 59:991 60:403 61:2118 62:1862 63:1793 64:5050 65:2216 66:4705 67:2552 68:1164 69:3290 70:1155 71:582 72:2155 74:2722 75:422 76:463 77:1643 78:1686 79:2133 80:1541 81:1381 82:1031 83:783 84:1034 85:1986 86:566 87:1357 88:918 89:2356 90:216 91:6444 92:1263 93:2368 94:2393 95:2919 96:793 97:357 98:934 99:133 100:85 101:1234 102:174 103:18328 104:3578 105:216 106:769 107:1775 108:714 109:3147 110:1639 111:1798 112:1334 113:1299 114:1136 115:1660 116:1645 117:1774 118:2217 119:1678 120:1009 121:1047 122:2435 123:1767 124:1446 125:1922 128:1109 129:690 130:492 131:1636 132:727 133:195 134:1023 135:232 136:499 137:645 138:1946 139:664 140:471 141:736 142:810 143:1027 144:809 145:484 146:1209 147:730 148:1646 149:748 150:741 151:1100 152:821 153:323 154:1488 155:804 156:1313 157:797 158:655 159:1821 160:1296 161:841 162:2592 163:602 164:1080 165:1528 166:460 167:1296 168:3135 169:828 170:3833 171:492 172:1002 173:2027 174:929 175:779 176:2005 177:4035 178:2505 179:1251 180:2170 181:2421 182:2392 183:1240 184:1041 185:13938 186:3644 187:2401 188:2914 189:2037 190:8357 191:1357 192:9812 193:6099 194:5002 195:3983 196:2660 197:1593 198:5572 199:5911 200:7394 201:5018 202:10247 203:10290 204:4590 205:2923 206:3163 207:3207 208:3962 209:4012 210:3866 211:1989 212:3042 213:2811 214:1043 215:56 216:6041 217:2118 218:859 219:578 220:1813 221:994 222:972 223:1373 End of report From carlosm3011 at gmail.com Fri Aug 10 20:25:30 2018 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Fri, 10 Aug 2018 17:25:30 -0300 Subject: Contact at SpeedTest.net Message-ID: Hi all, If anyone has a contact at SpeedTest it would be greatly appreciated. Thanks! /Carlos From sean at donelan.com Fri Aug 10 23:14:21 2018 From: sean at donelan.com (Sean Donelan) Date: Fri, 10 Aug 2018 19:14:21 -0400 (EDT) Subject: FCC: Nominations for new Disaster Response and Recovery Working Group Message-ID: https://docs.fcc.gov/public/attachments/DA-18-837A1.pdf The Federal Communications Commission (Commission) solicits nominations for membership on a new Disaster Response and Recovery Working Group of the Broadband Deployment Advisory Committee (BDAC). This new working group will assist the BDAC in providing advice and recommendations to the Commission on steps that can be taken to improve disaster preparation, response, and recovery for broadband infrastructure. Nominations for membership to the BDAC’s Disaster Response and Recovery Working Group should be submitted to the FCC no later than September 7, 2018. [...] The BDAC’s Disaster Response and Recovery Working Group will be charged with making recommendations on additional measures that can be taken before a disaster to improve resiliency of broadband infrastructure, strategies that can be used during the response to a disaster to minimize the downtime of broadband networks, and actions that can be taken to restore broadband infrastructure during disaster recovery. [...] From sabri at cluecentral.net Sun Aug 12 23:12:40 2018 From: sabri at cluecentral.net (Sabri Berisha) Date: Sun, 12 Aug 2018 16:12:40 -0700 (PDT) Subject: PPPoE Server In-Reply-To: <07be3f37-c89b-2d2f-cc1b-28a413a5e649@interlink.com.ar> References: <07be3f37-c89b-2d2f-cc1b-28a413a5e649@interlink.com.ar> Message-ID: <546831621.297420.1534115560756.JavaMail.zimbra@cluecentral.net> Hi, I used to work for Redback Networks, which was acquired by Ericsson. The Redback SmartEdge series can easily handle your load (the SE1200 can terminate up to 256,000 subs). I'm not sure if E/// still sells them, last I heard from my former colleagues was that most of the ex-Redback folks were let go. The design dating back to 2001 will still outperform an ASR9k or MX960 today. Depending on your needs, you may find some gently used gear on eBay. Configuration is Cisco-like. Thanks, Sabri JNCIE #261 ----- On Aug 8, 2018, at 12:22 PM, Mauro Gasparini mauro at interlink.com.ar wrote: > Good afternoon people. > I would like to advice me some appliance or software (running on top > level server line) which supports 20,000 simultaneous PPPoE connections. > The customer has a Cisco ASR1000 but I don't have any confirmed > experience that can support it. > > Mauro Gasparini. From etienne at cloudflare.com Mon Aug 13 12:31:44 2018 From: etienne at cloudflare.com (=?UTF-8?Q?=c3=89tienne?=) Date: Mon, 13 Aug 2018 13:31:44 +0100 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: <20180807084942.5080ca68@p50.localdomain> References: <20180807084942.5080ca68@p50.localdomain> Message-ID: <6c6c9cd5-9d2e-38bd-29de-b3051def7d26@cloudflare.com> On 07/08/18 14:49, John Kristoff wrote: > Friends, > > For those that may have used or know of a service like this. I know > some exist, but it doesn't seem to be that popular or widely advertised > as a standard service. > > I'm interested in pointers to a hosting/network provider that leases > dedicated servers and can provide an anycast IP address assignment to > two or more US-diversely connected POPs, but with reasonably consistent > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > interested in pointers to networks that would provide the prefix and > handle all the routing. Not sure you're still looking for something, but there's this spreadsheet that has a few pointers: http://bgp.services/ Cheers, -- Étienne From damian at google.com Mon Aug 13 14:35:33 2018 From: damian at google.com (Damian Menscher) Date: Mon, 13 Aug 2018 07:35:33 -0700 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: <20180807084942.5080ca68@p50.localdomain> References: <20180807084942.5080ca68@p50.localdomain> Message-ID: Not quite a dedicated server, but may meet your needs anyway: https://cloud.google.com/load-balancing/ Damian On Tue, Aug 7, 2018 at 6:50 AM John Kristoff wrote: > Friends, > > For those that may have used or know of a service like this. I know > some exist, but it doesn't seem to be that popular or widely advertised > as a standard service. > > I'm interested in pointers to a hosting/network provider that leases > dedicated servers and can provide an anycast IP address assignment to > two or more US-diversely connected POPs, but with reasonably consistent > routing (e.g. peering, transit). A customer-shared prefix is OK. I'm > interested in pointers to networks that would provide the prefix and > handle all the routing. > > If you represent a network and sales is part of your job, I don't mind > an off list pointer to a web page describing such a service, but please, > this is not an invitation for "call me to discuss needs and options" > replies nor an opportunity to get me on your customer prospect list. > You likely ensure I never do business with you if you do either of > those things. :-) > > Thank you, > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtk at depaul.edu Mon Aug 13 15:02:57 2018 From: jtk at depaul.edu (John Kristoff) Date: Mon, 13 Aug 2018 10:02:57 -0500 Subject: Dedicated Server and IP anycast provider recommendation In-Reply-To: <05db4a1b27ca4a3684e15f27c2f89784@XCASPRD02-DFT.dpu.depaul.edu> References: <20180807084942.5080ca68@p50.localdomain> <05db4a1b27ca4a3684e15f27c2f89784@XCASPRD02-DFT.dpu.depaul.edu> Message-ID: <20180813100257.53c0c7dd@p50.localdomain> On Mon, 13 Aug 2018 12:31:44 +0000 Étienne via NANOG wrote: > Not sure you're still looking for something, but there's this > spreadsheet that has a few pointers: http://bgp.services/ Thanks again. This is at least the third time someone has pointed this web page out to me. :-) To summarize, NetActuate and Packet were two of the most commonly suggested providers and probably the closest to what I was asking for. Some well known providers can do this, but don't have a specific web page / service offering describing it as a standard product offering. Many others, such as the often mentioned Vultr, require you to bring your own BGP speaker and prefix. What I was asking for isn't a popular, mass-marketed product offering, but is available. It just requires some research and careful evaluation. I think I"m familiar many hosting providers, especially the so-called low-end/cost providers for an entirely separate project. I'm always interested in those too, but not specifically for their ability to speak BGP. I maintain my own list here of providers I use here: Follow ups about that list are best sent to me directly or at that page directly. Thanks for all the on/off list replies and suggestions. John From eric.kuhnke at gmail.com Mon Aug 13 17:49:11 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 13 Aug 2018 10:49:11 -0700 Subject: optical circulator as a bidirectional one fiber solution In-Reply-To: References: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> Message-ID: Something that is broadly the same as a coherent 100G QPSK single wavelength optical module, but in two different frequencies, and a passive CWDM mux/demux prism at each end might work. The limitation would be availability of optics for a modern 100G MSA that are both coherent and Tx/Rx at two different THz frequencies. Or with some box and vendor equipment in between, such as: http://cdn.extranet.coriant.com/resources/Application-Notes/AN_Groove_Bidirectional_Fiber_74C0169.pdf?mtime=20180206023321 On Tue, Aug 7, 2018 at 1:00 PM Daniel Corbe wrote: > On 8/7/2018 15:46:03, "Baldur Norddahl" > wrote: > > >Hello > > > >There is a lack of bidirectional one fiber (BIDI) options for 40G and > >100G optics. Usually BIDI is implemented using two CWDM wavelengths, > >one for tx and one for rx. However there is also a lack of CWDM and > >DWDM options for 40G and 100G. > > > >Would it be possible to use an optical circulator like this one > >(customized to 1310 nm)? > > > >https://www.fs.com/de/en/products/33364.html > > > >Combined with a traditional two fiber 1310 nm 10 km 40G QSFP module > >like this: https://www.fs.com/de/en/products/24422.html > > > >The link distance would be 5 km. > > > >The optical circulator separates tx and rx by the direction the light > >travels in. It would work even though both directions use the same > >wavelength. There will likely be some reflection but hopefully > >attenuated enough that it is regarded as background noise. > > > >Has anyone done this? Any reason it would not work? > > > >Regards, > > > >Baldur > > > > The main issue you're going to run into (especially trying to plug > anything into a DWDM shelf) is 40G and 100G transceivers usually emit 4 > lanes of traffic instead of a single lane like 10 and 1G optics do. > > I'd imagine that's why there are so few solutions that don't involve > things like OTN. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Mon Aug 13 20:57:25 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 13 Aug 2018 13:57:25 -0700 Subject: optical circulator as a bidirectional one fiber solution In-Reply-To: References: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> Message-ID: <03073978-B3BA-4714-A6CF-38808EA18A60@6by7.net> Good news about almost all optics, their Rx window is pretty wide. Meaning a 1550nm optic will activate the receiver on a 1560nm optic just fine (and probably anything in the 1500nm band). Careful use of specialized single strand DWDM muxes (FS.com) can yield great bidi-like results with increased channel count. -Ben > On Aug 13, 2018, at 10:49 AM, Eric Kuhnke wrote: > > Something that is broadly the same as a coherent 100G QPSK single wavelength optical module, but in two different frequencies, and a passive CWDM mux/demux prism at each end might work. The limitation would be availability of optics for a modern 100G MSA that are both coherent and Tx/Rx at two different THz frequencies. > > Or with some box and vendor equipment in between, such as: > > http://cdn.extranet.coriant.com/resources/Application-Notes/AN_Groove_Bidirectional_Fiber_74C0169.pdf?mtime=20180206023321 > >> On Tue, Aug 7, 2018 at 1:00 PM Daniel Corbe wrote: >> On 8/7/2018 15:46:03, "Baldur Norddahl" >> wrote: >> >> >Hello >> > >> >There is a lack of bidirectional one fiber (BIDI) options for 40G and >> >100G optics. Usually BIDI is implemented using two CWDM wavelengths, >> >one for tx and one for rx. However there is also a lack of CWDM and >> >DWDM options for 40G and 100G. >> > >> >Would it be possible to use an optical circulator like this one >> >(customized to 1310 nm)? >> > >> >https://www.fs.com/de/en/products/33364.html >> > >> >Combined with a traditional two fiber 1310 nm 10 km 40G QSFP module >> >like this: https://www.fs.com/de/en/products/24422.html >> > >> >The link distance would be 5 km. >> > >> >The optical circulator separates tx and rx by the direction the light >> >travels in. It would work even though both directions use the same >> >wavelength. There will likely be some reflection but hopefully >> >attenuated enough that it is regarded as background noise. >> > >> >Has anyone done this? Any reason it would not work? >> > >> >Regards, >> > >> >Baldur >> > >> >> The main issue you're going to run into (especially trying to plug >> anything into a DWDM shelf) is 40G and 100G transceivers usually emit 4 >> lanes of traffic instead of a single lane like 10 and 1G optics do. >> >> I'd imagine that's why there are so few solutions that don't involve >> things like OTN. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnstong at westmancom.com Mon Aug 13 21:04:28 2018 From: johnstong at westmancom.com (Graham Johnston) Date: Mon, 13 Aug 2018 21:04:28 +0000 Subject: DAZN CDN Message-ID: Anyone from DAZN here, or anyone know what CDN is used for their content? I'm specifically curious about NFL Sunday Ticket content in case it makes a difference. Thanks, Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Mon Aug 13 21:56:04 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 13 Aug 2018 14:56:04 -0700 Subject: optical circulator as a bidirectional one fiber solution In-Reply-To: <03073978-B3BA-4714-A6CF-38808EA18A60@6by7.net> References: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> <03073978-B3BA-4714-A6CF-38808EA18A60@6by7.net> Message-ID: For 1 and 10Gbps OOK modulation yes, but not for something like a ITU DWDM grid channelized or tunable coherent optic. In which the (QPSK, 8PSK, 16QAM) signal has a specific THz width and frequency not unlike a radio operating in a very, very narrow waveguide. On Mon, Aug 13, 2018 at 1:57 PM Ben Cannon wrote: > Good news about almost all optics, their Rx window is pretty wide. Meaning > a 1550nm optic will activate the receiver on a 1560nm optic just fine (and > probably anything in the 1500nm band). Careful use of specialized single > strand DWDM muxes (FS.com) can yield great bidi-like results with > increased channel count. > > -Ben > > On Aug 13, 2018, at 10:49 AM, Eric Kuhnke wrote: > > Something that is broadly the same as a coherent 100G QPSK single > wavelength optical module, but in two different frequencies, and a passive > CWDM mux/demux prism at each end might work. The limitation would be > availability of optics for a modern 100G MSA that are both coherent and > Tx/Rx at two different THz frequencies. > > Or with some box and vendor equipment in between, such as: > > > http://cdn.extranet.coriant.com/resources/Application-Notes/AN_Groove_Bidirectional_Fiber_74C0169.pdf?mtime=20180206023321 > > On Tue, Aug 7, 2018 at 1:00 PM Daniel Corbe > wrote: > >> On 8/7/2018 15:46:03, "Baldur Norddahl" >> wrote: >> >> >Hello >> > >> >There is a lack of bidirectional one fiber (BIDI) options for 40G and >> >100G optics. Usually BIDI is implemented using two CWDM wavelengths, >> >one for tx and one for rx. However there is also a lack of CWDM and >> >DWDM options for 40G and 100G. >> > >> >Would it be possible to use an optical circulator like this one >> >(customized to 1310 nm)? >> > >> >https://www.fs.com/de/en/products/33364.html >> > >> >Combined with a traditional two fiber 1310 nm 10 km 40G QSFP module >> >like this: https://www.fs.com/de/en/products/24422.html >> > >> >The link distance would be 5 km. >> > >> >The optical circulator separates tx and rx by the direction the light >> >travels in. It would work even though both directions use the same >> >wavelength. There will likely be some reflection but hopefully >> >attenuated enough that it is regarded as background noise. >> > >> >Has anyone done this? Any reason it would not work? >> > >> >Regards, >> > >> >Baldur >> > >> >> The main issue you're going to run into (especially trying to plug >> anything into a DWDM shelf) is 40G and 100G transceivers usually emit 4 >> lanes of traffic instead of a single lane like 10 and 1G optics do. >> >> I'd imagine that's why there are so few solutions that don't involve >> things like OTN. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel.Jameson at tdstelecom.com Mon Aug 13 22:19:58 2018 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Mon, 13 Aug 2018 22:19:58 +0000 Subject: optical circulator as a bidirectional one fiber solution In-Reply-To: References: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> <03073978-B3BA-4714-A6CF-38808EA18A60@6by7.net> Message-ID: You would still need to frequency shift TX and RX. They are travelling opposite directions on the same piece of glass; as the traffic rate increases the likelihood of collisions increases and you’ll start to get errors. The collision would either cancel the ‘bit’ or act like OBI and get erroneous bits and checksum errors or missing chunks from the constellation. There are BIDI 100G transceivers for Multi-mode available today based on the Foxconn optics, I’d imagine we’ll see BIDI for the O and C bands in the next 18 months. From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke Sent: Monday, August 13, 2018 3:56 PM To: ben at 6by7.net; nanog at nanog.org list Subject: Re: optical circulator as a bidirectional one fiber solution For 1 and 10Gbps OOK modulation yes, but not for something like a ITU DWDM grid channelized or tunable coherent optic. In which the (QPSK, 8PSK, 16QAM) signal has a specific THz width and frequency not unlike a radio operating in a very, very narrow waveguide. On Mon, Aug 13, 2018 at 1:57 PM Ben Cannon > wrote: Good news about almost all optics, their Rx window is pretty wide. Meaning a 1550nm optic will activate the receiver on a 1560nm optic just fine (and probably anything in the 1500nm band). Careful use of specialized single strand DWDM muxes (FS.com) can yield great bidi-like results with increased channel count. -Ben On Aug 13, 2018, at 10:49 AM, Eric Kuhnke > wrote: Something that is broadly the same as a coherent 100G QPSK single wavelength optical module, but in two different frequencies, and a passive CWDM mux/demux prism at each end might work. The limitation would be availability of optics for a modern 100G MSA that are both coherent and Tx/Rx at two different THz frequencies. Or with some box and vendor equipment in between, such as: http://cdn.extranet.coriant.com/resources/Application-Notes/AN_Groove_Bidirectional_Fiber_74C0169.pdf?mtime=20180206023321 On Tue, Aug 7, 2018 at 1:00 PM Daniel Corbe > wrote: On 8/7/2018 15:46:03, "Baldur Norddahl" > wrote: >Hello > >There is a lack of bidirectional one fiber (BIDI) options for 40G and >100G optics. Usually BIDI is implemented using two CWDM wavelengths, >one for tx and one for rx. However there is also a lack of CWDM and >DWDM options for 40G and 100G. > >Would it be possible to use an optical circulator like this one >(customized to 1310 nm)? > >https://www.fs.com/de/en/products/33364.html > >Combined with a traditional two fiber 1310 nm 10 km 40G QSFP module >like this: https://www.fs.com/de/en/products/24422.html > >The link distance would be 5 km. > >The optical circulator separates tx and rx by the direction the light >travels in. It would work even though both directions use the same >wavelength. There will likely be some reflection but hopefully >attenuated enough that it is regarded as background noise. > >Has anyone done this? Any reason it would not work? > >Regards, > >Baldur > The main issue you're going to run into (especially trying to plug anything into a DWDM shelf) is 40G and 100G transceivers usually emit 4 lanes of traffic instead of a single lane like 10 and 1G optics do. I'd imagine that's why there are so few solutions that don't involve things like OTN. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Mon Aug 13 22:24:21 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 13 Aug 2018 15:24:21 -0700 Subject: optical circulator as a bidirectional one fiber solution In-Reply-To: References: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> <03073978-B3BA-4714-A6CF-38808EA18A60@6by7.net> Message-ID: <78FD85E6-4B38-4AFB-ABED-06A9F26397BF@6by7.net> What about 100Ghz ITU spacing on the tx, are the rx optics broad enough to take the off-band input? -Ben > On Aug 13, 2018, at 3:19 PM, Jameson, Daniel wrote: > > You would still need to frequency shift TX and RX. They are travelling opposite directions on the same piece of glass; as the traffic rate increases the likelihood of collisions increases and you’ll start to get errors. The collision would either cancel the ‘bit’ or act like OBI and get erroneous bits and checksum errors or missing chunks from the constellation. There are BIDI 100G transceivers for Multi-mode available today based on the Foxconn optics, I’d imagine we’ll see BIDI for the O and C bands in the next 18 months. > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke > Sent: Monday, August 13, 2018 3:56 PM > To: ben at 6by7.net; nanog at nanog.org list > Subject: Re: optical circulator as a bidirectional one fiber solution > > For 1 and 10Gbps OOK modulation yes, but not for something like a ITU DWDM grid channelized or tunable coherent optic. In which the (QPSK, 8PSK, 16QAM) signal has a specific THz width and frequency not unlike a radio operating in a very, very narrow waveguide. > > > On Mon, Aug 13, 2018 at 1:57 PM Ben Cannon wrote: > Good news about almost all optics, their Rx window is pretty wide. Meaning a 1550nm optic will activate the receiver on a 1560nm optic just fine (and probably anything in the 1500nm band). Careful use of specialized single strand DWDM muxes (FS.com) can yield great bidi-like results with increased channel count. > > -Ben > > On Aug 13, 2018, at 10:49 AM, Eric Kuhnke wrote: > > Something that is broadly the same as a coherent 100G QPSK single wavelength optical module, but in two different frequencies, and a passive CWDM mux/demux prism at each end might work. The limitation would be availability of optics for a modern 100G MSA that are both coherent and Tx/Rx at two different THz frequencies. > > Or with some box and vendor equipment in between, such as: > > http://cdn.extranet.coriant.com/resources/Application-Notes/AN_Groove_Bidirectional_Fiber_74C0169.pdf?mtime=20180206023321 > > On Tue, Aug 7, 2018 at 1:00 PM Daniel Corbe wrote: > On 8/7/2018 15:46:03, "Baldur Norddahl" > wrote: > > >Hello > > > >There is a lack of bidirectional one fiber (BIDI) options for 40G and > >100G optics. Usually BIDI is implemented using two CWDM wavelengths, > >one for tx and one for rx. However there is also a lack of CWDM and > >DWDM options for 40G and 100G. > > > >Would it be possible to use an optical circulator like this one > >(customized to 1310 nm)? > > > >https://www.fs.com/de/en/products/33364.html > > > >Combined with a traditional two fiber 1310 nm 10 km 40G QSFP module > >like this: https://www.fs.com/de/en/products/24422.html > > > >The link distance would be 5 km. > > > >The optical circulator separates tx and rx by the direction the light > >travels in. It would work even though both directions use the same > >wavelength. There will likely be some reflection but hopefully > >attenuated enough that it is regarded as background noise. > > > >Has anyone done this? Any reason it would not work? > > > >Regards, > > > >Baldur > > > > The main issue you're going to run into (especially trying to plug > anything into a DWDM shelf) is 40G and 100G transceivers usually emit 4 > lanes of traffic instead of a single lane like 10 and 1G optics do. > > I'd imagine that's why there are so few solutions that don't involve > things like OTN. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Mon Aug 13 22:35:21 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 13 Aug 2018 18:35:21 -0400 Subject: optical circulator as a bidirectional one fiber solution In-Reply-To: <78FD85E6-4B38-4AFB-ABED-06A9F26397BF@6by7.net> References: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> <03073978-B3BA-4714-A6CF-38808EA18A60@6by7.net> <78FD85E6-4B38-4AFB-ABED-06A9F26397BF@6by7.net> Message-ID: <73efc2df-3509-bced-ac76-51cf3379230a@monmotha.net> On 08/13/2018 06:24 PM, Ben Cannon wrote: > What about 100Ghz ITU spacing on the tx, are the rx optics broad enough > to take the off-band input? Non-coherent receivers usually seem to even when paired with DWDM grid transceivers. You're paying for the tightly controlled laser on those, not so much the receiver. Coherent of course will demod whatever you tune them to (and pretty well reject other stuff) but are therefore subject to their LO tuning range. Figure your typical OOK optical receiver is roughly like a single-stage AM radio receiver (crystal radio or similar, just followed by amplification to logic level) without any front-end filtering on it. The demux in front of it, where present, is the front-end filter. It'll capture and downconvert to RF basically anything it sees. -- Brandon Martin From Daniel.Jameson at tdstelecom.com Mon Aug 13 22:43:22 2018 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Mon, 13 Aug 2018 22:43:22 +0000 Subject: optical circulator as a bidirectional one fiber solution In-Reply-To: <78FD85E6-4B38-4AFB-ABED-06A9F26397BF@6by7.net> References: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> <03073978-B3BA-4714-A6CF-38808EA18A60@6by7.net> <78FD85E6-4B38-4AFB-ABED-06A9F26397BF@6by7.net> Message-ID: If we were talking 10G, adjacent channels, add a TFFL filter it *Should* work. 100G isn’t just on-off at a high clock rate, it’s also modulated around the center frequency, I don’t think it’d work even with a wideband receiver. From: Ben Cannon [mailto:ben at 6by7.net] Sent: Monday, August 13, 2018 4:24 PM To: Jameson, Daniel Cc: Eric Kuhnke; nanog at nanog.org list Subject: Re: optical circulator as a bidirectional one fiber solution What about 100Ghz ITU spacing on the tx, are the rx optics broad enough to take the off-band input? -Ben On Aug 13, 2018, at 3:19 PM, Jameson, Daniel > wrote: You would still need to frequency shift TX and RX. They are travelling opposite directions on the same piece of glass; as the traffic rate increases the likelihood of collisions increases and you’ll start to get errors. The collision would either cancel the ‘bit’ or act like OBI and get erroneous bits and checksum errors or missing chunks from the constellation. There are BIDI 100G transceivers for Multi-mode available today based on the Foxconn optics, I’d imagine we’ll see BIDI for the O and C bands in the next 18 months. From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke Sent: Monday, August 13, 2018 3:56 PM To: ben at 6by7.net; nanog at nanog.org list Subject: Re: optical circulator as a bidirectional one fiber solution For 1 and 10Gbps OOK modulation yes, but not for something like a ITU DWDM grid channelized or tunable coherent optic. In which the (QPSK, 8PSK, 16QAM) signal has a specific THz width and frequency not unlike a radio operating in a very, very narrow waveguide. On Mon, Aug 13, 2018 at 1:57 PM Ben Cannon > wrote: Good news about almost all optics, their Rx window is pretty wide. Meaning a 1550nm optic will activate the receiver on a 1560nm optic just fine (and probably anything in the 1500nm band). Careful use of specialized single strand DWDM muxes (FS.com) can yield great bidi-like results with increased channel count. -Ben On Aug 13, 2018, at 10:49 AM, Eric Kuhnke > wrote: Something that is broadly the same as a coherent 100G QPSK single wavelength optical module, but in two different frequencies, and a passive CWDM mux/demux prism at each end might work. The limitation would be availability of optics for a modern 100G MSA that are both coherent and Tx/Rx at two different THz frequencies. Or with some box and vendor equipment in between, such as: http://cdn.extranet.coriant.com/resources/Application-Notes/AN_Groove_Bidirectional_Fiber_74C0169.pdf?mtime=20180206023321 On Tue, Aug 7, 2018 at 1:00 PM Daniel Corbe > wrote: On 8/7/2018 15:46:03, "Baldur Norddahl" > wrote: >Hello > >There is a lack of bidirectional one fiber (BIDI) options for 40G and >100G optics. Usually BIDI is implemented using two CWDM wavelengths, >one for tx and one for rx. However there is also a lack of CWDM and >DWDM options for 40G and 100G. > >Would it be possible to use an optical circulator like this one >(customized to 1310 nm)? > >https://www.fs.com/de/en/products/33364.html > >Combined with a traditional two fiber 1310 nm 10 km 40G QSFP module >like this: https://www.fs.com/de/en/products/24422.html > >The link distance would be 5 km. > >The optical circulator separates tx and rx by the direction the light >travels in. It would work even though both directions use the same >wavelength. There will likely be some reflection but hopefully >attenuated enough that it is regarded as background noise. > >Has anyone done this? Any reason it would not work? > >Regards, > >Baldur > The main issue you're going to run into (especially trying to plug anything into a DWDM shelf) is 40G and 100G transceivers usually emit 4 lanes of traffic instead of a single lane like 10 and 1G optics do. I'd imagine that's why there are so few solutions that don't involve things like OTN. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Mon Aug 13 22:43:56 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 13 Aug 2018 18:43:56 -0400 Subject: optical circulator as a bidirectional one fiber solution In-Reply-To: References: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> <03073978-B3BA-4714-A6CF-38808EA18A60@6by7.net> Message-ID: <9E5BC92D-4ABC-47A3-9A0D-ECD2D0C4B328@puck.nether.net> > On Aug 13, 2018, at 5:56 PM, Eric Kuhnke wrote: > > For 1 and 10Gbps OOK modulation yes, but not for something like a ITU DWDM grid channelized or tunable coherent optic. In which the (QPSK, 8PSK, 16QAM) signal has a specific THz width and frequency not unlike a radio operating in a very, very narrow waveguide. > There are some DCO 100G coherent optics on the market, but I think this thread is more about why there’s not much in the way of 40/100g transmission speed, but it really is about how 10G was one of the last walls where OOK was a thing. Once you went 40G/100G you went to parallel signals, either in CDWDM form or parallel signals on parallel fibers (eg: those MPT/MPO cables we all get to enjoy). If you talk to the optics folks you can get customized tx/rx optics, and in theory you could get an optimized 100G-LR4 or 100G-ER4-Lite optic, but even those the reach is quite limited to around 25Km while in the 10G space you can get up to 80-120km with a filter and a bunch of pluggable fixed channel (or tunable) optics. You can get decent 100G OEO solutions for a fair price per channel but you’re still looking at $$ compared to just building a 40x10G system due to the cost differences. Without more details like your link budget, etc.. it’s hard to suggest options other than get at least 2 fibers :-) I know some vendors are working on some creative 1 fiber solutions due to the way the dark fiber is taxed in Europe, so you should be talking to the usual suspects.. - Jared From jared at puck.nether.net Tue Aug 14 17:07:38 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 14 Aug 2018 13:07:38 -0400 Subject: 3549 1273 Message-ID: <9DED4B6F-0548-4B6C-A489-21D51500A4D7@puck.nether.net> 3549<->1273 seem to be generating a lot of BGP updates between each other, is anyone else seeing this or noticed an adverse impact? - Jared From manager at monmouth.com Tue Aug 14 17:56:10 2018 From: manager at monmouth.com (Mark Stevens) Date: Tue, 14 Aug 2018 13:56:10 -0400 Subject: AT&T Wireless Issue Message-ID: Good Afternoon, I am looking to get in touch with an AT&T wireless switch tech in the NY/NJ region. If someone from AT&T could reach out to me offline it would be great. Thanks Mark From bob at FiberInternetCenter.com Tue Aug 14 18:42:49 2018 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 14 Aug 2018 11:42:49 -0700 Subject: Reach for a Verizon "Mobility" Network Contact Message-ID: <2041206e7f71771884b33a9ba760f52b.squirrel@66.201.44.180> Please contact me offline at bob at FiberInternetCenter.com NOT looking for verizon a cell phone dealer - NOT looking for a verizon business multi-phone plan sales person. Looking for the verizon mobility department , someone that can generate a contract for this specific service and has contacts within that part of the organization and knows the individuals by name. Thank You Bob Evans CTO From randy at psg.com Tue Aug 14 21:38:35 2018 From: randy at psg.com (Randy Bush) Date: Tue, 14 Aug 2018 14:38:35 -0700 Subject: tcp md5 bgp attacks? Message-ID: so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack? we were unable to find bgp mib counters. there are igp interface counters, but that was not our immediate interest. we did find that md5 failures are logged. looking at my logs for a few years, i find essentially nothing; two 'attackers,' one my own ibgp peer, and one that noted evildoer rob thomas, bgprs01.ord08.cymru.com. we would be interested in data from others. note that we are neither contemplating nor suggesting removing md5 from [y]our bgp sessions. randy From gtaylor at tnetconsulting.net Tue Aug 14 23:28:13 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 14 Aug 2018 17:28:13 -0600 Subject: tcp md5 bgp attacks? In-Reply-To: References: Message-ID: On 08/14/2018 03:38 PM, Randy Bush wrote: > so we started to wonder if, since we started protecting our bgp > sessions with md5 (in the 1990s), are there still folk trying to > attack? n00b response here I thought using ACLs or otherwise protecting the BGP endpoint was best practice. Thus it's really hard to even try break an MD5 protected BGP session if you can't even establish the TCP connection. Everything that I've seen or set up had an ACL to only allow the peer(s) to be able to connect to (from memory) TCP port 179. Is there something that I've missed the boat on? #learningOpportunity -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From job at ntt.net Tue Aug 14 23:36:02 2018 From: job at ntt.net (Job Snijders) Date: Wed, 15 Aug 2018 01:36:02 +0200 Subject: tcp md5 bgp attacks? In-Reply-To: References: Message-ID: <20180814233602.GO1021@hanna.meerval.net> On Tue, Aug 14, 2018 at 05:28:13PM -0600, Grant Taylor via NANOG wrote: > On 08/14/2018 03:38 PM, Randy Bush wrote: > > so we started to wonder if, since we started protecting our bgp > > sessions with md5 (in the 1990s), are there still folk trying to > > attack? > > n00b response here > > I thought using ACLs or otherwise protecting the BGP endpoint was best > practice. Thus it's really hard to even try break an MD5 protected > BGP session if you can't even establish the TCP connection. > > Everything that I've seen or set up had an ACL to only allow the > peer(s) to be able to connect to (from memory) TCP port 179. > > Is there something that I've missed the boat on? > > #learningOpportunity To further harden your setup, consider using GTSM https://tools.ietf.org/html/rfc5082 Kind regards, Job From rdobbins at arbor.net Tue Aug 14 23:36:08 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 15 Aug 2018 06:36:08 +0700 Subject: tcp md5 bgp attacks? In-Reply-To: References: Message-ID: <506A6E1B-51D5-42C0-8A14-E1032C26F68B@arbor.net> On 15 Aug 2018, at 6:28, Grant Taylor via NANOG wrote: > Is there something that I've missed the boat on? No - it's a belt-and-suspenders sort of thing, along with GTSM. ----------------------------------- Roland Dobbins From jtk at depaul.edu Tue Aug 14 23:56:37 2018 From: jtk at depaul.edu (John Kristoff) Date: Tue, 14 Aug 2018 18:56:37 -0500 Subject: tcp md5 bgp attacks? In-Reply-To: References: Message-ID: <20180814185637.1adc0d23@p50.localdomain> On Tue, 14 Aug 2018 21:38:35 +0000 Randy Bush wrote: > we would be interested in data from others. My data is coarse, but with 'show system statistics tcp | match auth' I see sometimes thousands of rcv packets dropped on BGP routers. I doubt they are attacks, but simply badly configured or stale peer sessions over the course of time the counters initialized from. John From randy at psg.com Wed Aug 15 00:04:07 2018 From: randy at psg.com (Randy Bush) Date: Tue, 14 Aug 2018 17:04:07 -0700 Subject: tcp md5 bgp attacks? In-Reply-To: <20180814185637.1adc0d23@p50.localdomain> References: <20180814185637.1adc0d23@p50.localdomain> Message-ID: > My data is coarse, but with 'show system statistics tcp | match auth' > I see sometimes thousands of rcv packets dropped on BGP routers. I > doubt they are attacks, but simply badly configured or stale peer > sessions over the course of time the counters initialized from. thanks john for the one (so far) answer to my question instead of telling me how to run my routers what i see also looks like config as opposed to attack --- follow-on question: anyone using the timed key-chain stuff? randy From jared at puck.nether.net Wed Aug 15 00:08:47 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 14 Aug 2018 20:08:47 -0400 Subject: tcp md5 bgp attacks? In-Reply-To: References: <20180814185637.1adc0d23@p50.localdomain> Message-ID: <15D300B8-F01C-4209-A8F2-E678D4BEB076@puck.nether.net> > On Aug 14, 2018, at 8:04 PM, Randy Bush wrote: > > follow-on question: > > anyone using the timed key-chain stuff? I’ve looked at it, hear it works, but not been willing to take the hit for any transition. I talked about some of this and other challenges at SAAG WG at IETF 101. Transport area has some possible interesting things, but similar to what Haas said, TCP-AO isn’t really viable yet, and we need something that’s stable enough to last 5-7 years, which is very different from a HTTP transaction that may live only a few seconds. We have some places where we could transition non-BGP protocols and rotate the key, but last I recall it was only there on a single vendor so multi-vendor posed some challenges. - Jared From randy at psg.com Wed Aug 15 00:12:49 2018 From: randy at psg.com (Randy Bush) Date: Tue, 14 Aug 2018 17:12:49 -0700 Subject: tcp md5 bgp attacks? In-Reply-To: <15D300B8-F01C-4209-A8F2-E678D4BEB076@puck.nether.net> References: <20180814185637.1adc0d23@p50.localdomain> <15D300B8-F01C-4209-A8F2-E678D4BEB076@puck.nether.net> Message-ID: [ again, thanks for an answer to the question asked ] >> anyone using the timed key-chain stuff? > > I’ve looked at it, hear it works, but not been willing to take the hit > for any transition. and i am not sure it meets my needs. i am not seeking privacy or pfs. i want roll-if-compromise. (and no, i do not want automated compromise heuristics, a recipe for death). > > we need something that’s stable enough to last 5-7 years, which is > very different from a HTTP transaction that may live only a few > seconds. something such as, or close to, rfc 4808? randy From jared at puck.nether.net Wed Aug 15 00:25:01 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 14 Aug 2018 20:25:01 -0400 Subject: tcp md5 bgp attacks? In-Reply-To: References: <20180814185637.1adc0d23@p50.localdomain> <15D300B8-F01C-4209-A8F2-E678D4BEB076@puck.nether.net> Message-ID: <5D19D385-3CBE-4DF0-B846-74DDC9BF87AA@puck.nether.net> > On Aug 14, 2018, at 8:12 PM, Randy Bush wrote: > > [ again, thanks for an answer to the question asked ] > >>> anyone using the timed key-chain stuff? >> >> I’ve looked at it, hear it works, but not been willing to take the hit >> for any transition. > > and i am not sure it meets my needs. i am not seeking privacy or pfs. > i want roll-if-compromise. (and no, i do not want automated compromise > heuristics, a recipe for death). >> >> we need something that’s stable enough to last 5-7 years, which is >> very different from a HTTP transaction that may live only a few >> seconds. > > something such as, or close to, rfc 4808? It provides some capability, but for example if I have a large iBGP mesh and need to change methods of securing it and have automation involved, it can often be a one-shot change unless I can zone some routers to different versions of templating to have a smooth transition. Basically the negative side of using peer-groups can be quite catastrophic with how you transition from the router software without good update packing/replication to one with a good system. It doesn’t need the groups to optimize the leadership replication, but you still use them to minimize configuration duplication. I’m not sure if in 2018 which is the right path from an automation perspective, if you can have software specify and iterate everything, do you continue to use apply-groups, or just rely upon the automation to output the full configuration? Most systems (including the ones at present and past employers) tend to be a variation on template driven in some language(s) where the original problem/engineer creep doesn’t account for the proper abstract models to allow zoned changes/rollover of subsets of the network. Ie: rolling the key is an all-or-nothing operation. Similar to JTK most of the log messages we see are from people who forgot the MD5 key, or at an IX where we did poor relationship management so the IP is now reused by others and nobody cleaned up the older session(s). I have heard (but not personally seen) of well formed TCP session attacks where md5 may have helped, but since the punt path tends to be the weak link and most folks don’t do GTSH/GTSM (or worse, have hardware that can’t filter based on this) you still incur the expensive punt operation only to have the RP/RE kernel then drop the packet. IOS-XR also has very good/robust defaults with LPTS which helps significantly. I’ve seen quite large attacks against a router be mitigated by LPTS and not require the mpp/control plane filters to be involved. Basically, once you roll md5 you may be at risk for having rolled it to need a way to undo and that pathway may not be easy, with or without automation. - Jared From randy at psg.com Wed Aug 15 00:34:00 2018 From: randy at psg.com (Randy Bush) Date: Tue, 14 Aug 2018 17:34:00 -0700 Subject: tcp md5 bgp attacks? In-Reply-To: <5D19D385-3CBE-4DF0-B846-74DDC9BF87AA@puck.nether.net> References: <20180814185637.1adc0d23@p50.localdomain> <15D300B8-F01C-4209-A8F2-E678D4BEB076@puck.nether.net> <5D19D385-3CBE-4DF0-B846-74DDC9BF87AA@puck.nether.net> Message-ID: >> something such as, or close to, rfc 4808? > > It provides some capability, but for example if I have a large iBGP > mesh and need to change methods of securing it and have automation > involved, it can often be a one-shot change unless I can zone some > routers to different versions of templating to have a smooth > transition. Basically the negative side of using peer-groups can be > quite catastrophic with how you transition from the router software > without good update packing/replication to one with a good system. It > doesn’t need the groups to optimize the leadership replication, but > you still use them to minimize configuration duplication. > > I’m not sure if in 2018 which is the right path from an automation > perspective, if you can have software specify and iterate everything, > do you continue to use apply-groups, or just rely upon the automation > to output the full configuration? > > Most systems (including the ones at present and past employers) tend > to be a variation on template driven in some language(s) where the > original problem/engineer creep doesn’t account for the proper > abstract models to allow zoned changes/rollover of subsets of the > network. Ie: rolling the key is an all-or-nothing operation. > > Similar to JTK most of the log messages we see are from people who > forgot the MD5 key, or at an IX where we did poor relationship > management so the IP is now reused by others and nobody cleaned up the > older session(s). > > I have heard (but not personally seen) of well formed TCP session > attacks where md5 may have helped, but since the punt path tends to be > the weak link and most folks don’t do GTSH/GTSM (or worse, have > hardware that can’t filter based on this) you still incur the > expensive punt operation only to have the RP/RE kernel then drop the > packet. > > IOS-XR also has very good/robust defaults with LPTS which helps > significantly. I’ve seen quite large attacks against a router be > mitigated by LPTS and not require the mpp/control plane filters to be > involved. > > Basically, once you roll md5 you may be at risk for having rolled it > to need a way to undo and that pathway may not be easy, with or > without automation. one or both of us needs to reread 4808 randy From joelja at bogus.com Wed Aug 15 01:42:23 2018 From: joelja at bogus.com (joel jaeggli) Date: Tue, 14 Aug 2018 18:42:23 -0700 Subject: tcp md5 bgp attacks? In-Reply-To: References: Message-ID: <9cbc76f3-06b6-c399-fcff-e19121153381@bogus.com> On 8/14/18 2:38 PM, Randy Bush wrote: > so we started to wonder if, since we started protecting our bgp > sessions with md5 (in the 1990s), are there still folk trying to > attack? To recap for the purpose of my own edification and because hopefully someone will relieve me of my assumptions. The purpose of  of rfc 2385 tcp md5 digests is to keep in-window, tcp segments that are spoofed from being ingested into the tcp stack. At the time of it's writing (1998) some popular network operating systems did not check  that the sequence number was in fact inside the window (so that any tcp packet matching the 4 tupple would be ingested whether it was in-window or not. Variously this improvement was supplemented with the checking the TTL (https://tools.ietf.org/html/draft-gill-btsh-02), checking whether the packet is actually in window, by ACLs that would limit the impacts of  spoofing from off path attackers (you can't target my multihop infracture sessions from outside my network for example), and by filters that would limit the sort of thing you could inject into bgp (rendering prefix hijacking moot) ).  I see broad evidence that MD5 values are extensively shared between sessions and effectively never rekeyed (including cases where I've changed employers and the same asn is using the same values for new peers). given the existance of effective mitigations for the ibgp case, I've need seen a reason  to employ it internally or to explore support for rfc 4808 mechnisms since key rolling is effectively an external coordination problem. Due to window checking and the ttl hack, the best vantage point for launching an attack against a single hop ebgp sessions is as an on path attacker (such that you would be able to identify source port and window), layer-2 exchanges which flood unicast traffic (a hub I guess or any public exchange with broken mac learning) would seem particularly vulnerable since there are many on path neighbors. That is no longer a normal topology. :/ > we were unable to find bgp mib counters. there are igp interface > counters, but that was not our immediate interest. we did find > that md5 failures are logged. I can't quite get there either. md5 failures I see quite a lot of, as peers that formerly have it configured fail either temporarily or over longer timescales. md5 failures for unestablished connections aren't very interesting in this case. I have thousands of establish connections that last a very long time at public exchange points, so the threat of tcp rsts to sessions is clearly not being realized. > > looking at my logs for a few years, i find essentially nothing; > two 'attackers,' one my own ibgp peer, and one that noted evildoer > rob thomas, bgprs01.ord08.cymru.com. > > we would be interested in data from others. > > note that we are neither contemplating nor suggesting removing md5 > from [y]our bgp sessions. > > randy > From randy at psg.com Wed Aug 15 02:27:28 2018 From: randy at psg.com (Randy Bush) Date: Tue, 14 Aug 2018 19:27:28 -0700 Subject: tcp md5 bgp attacks? In-Reply-To: <9cbc76f3-06b6-c399-fcff-e19121153381@bogus.com> References: <9cbc76f3-06b6-c399-fcff-e19121153381@bogus.com> Message-ID: my memory is that seq num guessing and sending rst was the core problem motivating tcp/md5 for bgp, and btsh came some years later. but no big deal. i think that, indeed, md5 keys are shared across many links *within* an op's infrastructure. but, since integrity, and not privacy, is the goal, this does not seem risky. carrying keys to new networks seems a bit risky as does re-use with multiple external parties. > given the existance of effective mitigations for the ibgp case, I've > need seen a reason to employ it internally or to explore support for > rfc 4808 mechnisms since key rolling is effectively an external > coordination problem. if i need to roll keys on ibgp, i suspect i have a far more serious problem than if it is ebgp, twice as serious at a minimum :) < rathole > i am not much worried about a mesh which floods unicast. can you even buy devices which support that any more? a while back, i had to really dig in the closet to find one at 100mbps so i could shark mid-stream. > I have thousands of establish connections that last a very long time > at public exchange points, so the threat of tcp rsts to sessions is > clearly not being realized. my theory is that, as the attacks were mitigated the attackers moved on to other things. after all, the non-nuisance benefit i get by resetting your bgp session with margaret is shifting your traffic past some place i can mitm or to a more expensive, to you, link. the attackers moved on to more lucrative endeavors. randy From rdobbins at arbor.net Wed Aug 15 02:38:05 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 15 Aug 2018 09:38:05 +0700 Subject: tcp md5 bgp attacks? In-Reply-To: References: <9cbc76f3-06b6-c399-fcff-e19121153381@bogus.com> Message-ID: On 15 Aug 2018, at 9:27, Randy Bush wrote: > my theory is that, as the attacks were mitigated the attackers moved > on to other things. With regards to BGP, the MD5 thing was promulgated to counter what was a largely theoretical threat. iACLs, and later GTSM and CoPP and LPTS and so forth really obviated the need for it. For IGPs, MD5 was belt-and-suspenders against someone deliberately or accidentally bringing up a new router and manipulating traffic internally. Passiving the IGP on non-core links was the BCP, but often was honored in the breach; pushing an additional feature for 'security' purposes got some folks' attention when the passiving BCP was ignored. We still see DDoS attacks against routers, of course. But the goal there is disruption of availability, not trying to move traffic onto some alternate path which would somehow benefit the attacker. ----------------------------------- Roland Dobbins From joelja at bogus.com Wed Aug 15 03:23:16 2018 From: joelja at bogus.com (joel jaeggli) Date: Tue, 14 Aug 2018 20:23:16 -0700 Subject: tcp md5 bgp attacks? In-Reply-To: References: <9cbc76f3-06b6-c399-fcff-e19121153381@bogus.com> Message-ID: <83381ff5-b8ca-5726-73bc-90c314d60b47@bogus.com> On 8/14/18 7:27 PM, Randy Bush wrote: > > < rathole > > i am not much worried about a mesh which floods unicast. can you even > buy devices which support that any more? a while back, i had to really > dig in the closet to find one at 100mbps so i could shark mid-stream. I'm not actually worried about it because it is rare, and not a feature, that said, unicast flooding is in fact something we detect on exchanges with a fair amount of frequency e.g. 2-3 a week across the exchanges were we are present. That traffic gets discarded on our ingress but you can count dport 179  packets in there that aren't yours. I certainly wouldn't build a business model around gaining insight from that information leakage (and the bulk of the traffic is whatever the neighbor is exchanging, with someone else, from looking at mac's that sort of thing tends to be one sided unless for example it's a whole switch). >> I have thousands of establish connections that last a very long time >> at public exchange points, so the threat of tcp rsts to sessions is >> clearly not being realized. From Pratik.Lotia at charter.com Tue Aug 14 22:05:09 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Tue, 14 Aug 2018 22:05:09 +0000 Subject: tcp md5 bgp attacks? In-Reply-To: References: Message-ID: Just to point out - Data about md5 attacks from various organizations will depend on a number of factors such as - Is BGP TTL Security check being done? Are anti-spoofing ACLs enabled? uRPF enabled? Strict or Loose? BGP Session over a separate interface (tunnel)? With Gratitude, Pratik Lotia  | Security Engineer | Advanced Engineering Security Charter Communications "A satisfied customer is the best business strategy of all." -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush Sent: Tuesday, August 14, 2018 3:39 PM To: North American Network Operators' Group Subject: tcp md5 bgp attacks? so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack? we were unable to find bgp mib counters. there are igp interface counters, but that was not our immediate interest. we did find that md5 failures are logged. looking at my logs for a few years, i find essentially nothing; two 'attackers,' one my own ibgp peer, and one that noted evildoer rob thomas, bgprs01.ord08.cymru.com. we would be interested in data from others. note that we are neither contemplating nor suggesting removing md5 from [y]our bgp sessions. randy E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From fredbaker.ietf at gmail.com Tue Aug 14 23:34:11 2018 From: fredbaker.ietf at gmail.com (Fred Baker) Date: Tue, 14 Aug 2018 16:34:11 -0700 Subject: tcp md5 bgp attacks? In-Reply-To: References: Message-ID: Well, think about RST attacks, in which someone bombards a TCP connection with TCP RESET in the hopes of threading a needle and taking it down. It's not the end of the world - BGP restarts - but there is an outage. The simplest way to protect against that (and against having someone with a hijacked IP address connect to your router) is to put mutual authentication on the TCP connection. Having it also at the BGP layer, and having ACLs to be sure you know what's going on, are good things, but TCP MD5, TCP-AO, or IPsec are an awful lot safer. > On Aug 14, 2018, at 4:28 PM, Grant Taylor via NANOG wrote: > > On 08/14/2018 03:38 PM, Randy Bush wrote: >> so we started to wonder if, since we started protecting our bgp >> sessions with md5 (in the 1990s), are there still folk trying to >> attack? > > n00b response here > > I thought using ACLs or otherwise protecting the BGP endpoint was best practice. Thus it's really hard to even try break an MD5 protected BGP session if you can't even establish the TCP connection. > > Everything that I've seen or set up had an ACL to only allow the peer(s) to be able to connect to (from memory) TCP port 179. > > Is there something that I've missed the boat on? > > #learningOpportunity > > > > -- > Grant. . . . > unix || die > -------------------------------------------------------------------------------- The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From colton.conor at gmail.com Wed Aug 15 13:49:12 2018 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 15 Aug 2018 08:49:12 -0500 Subject: What NMS do you use and why? Message-ID: We are looking for a new network monitoring system. Since there are so many operators on this list, I would like to know which NMS do you use and why? Is there one that you really like, and others that you hate? For free options (opensouce), LibreNMS and NetXMS come highly recommended by many wireless ISPs on low budgets. However, I am not sure the commercial options available nor their price points. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cra at WPI.EDU Wed Aug 15 16:19:02 2018 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 15 Aug 2018 12:19:02 -0400 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: <20180815161902.57hxwjkavtcdrazd@angus.ind.wpi.edu> On Wed, Aug 15, 2018 at 08:49:12AM -0500, Colton Conor wrote: > We are looking for a new network monitoring system. Since there are so many > operators on this list, I would like to know which NMS do you use and why? > Is there one that you really like, and others that you hate? > > For free options (opensouce), LibreNMS and NetXMS come highly recommended > by many wireless ISPs on low budgets. However, I am not sure the commercial > options available nor their price points. For monitoring network device/interface data plane reachability with ping, we are still using an ancient piece of open source software called Autostatus. I find it invaluable for notifying us about reachability issues with it's simple to understand parent/child relationships and graph-based fping methodology. It isn't perfect--it doesn't scale very well, it doesn't have HA/clustering, it has no fancy dependencies (just basic parent-child) and no event correlation, no contact scheduling, no API, etc. but it is very easy to understand why you are getting an alert or not and boiling that down to a single point of failure and as such it provides reliable, trustable information about data plane reachability from one vantage point on the network. For monitoring server & network service availability, device/environmental health, etc. we are currently using Nagios. My problems with it are that it has complex rules for how/when to perform a specific health check and send or suppress a notification (and perhaps bugs in our old version that never ever seems to send any Host notifications except when it does) and the whole idea of "suppress the Host check unless all Service checks for all services on the host are down" doesn't really fit well with the idea of monitoring device/interface reachability on routers & switches that make up a complex graph of dependencies. Trying to shoehorn Nagios into alerting on just the one IP address/device/interface that is causing all the others behind it to be unreachable doesn't work very well. You can't use Host Depenencies because Host checks are suppressed by default, and Host Dependencies don't affect Service Checks/notifications. Forcing Host checks to always run causes performance problems. Creating a "Ping" service for every host requires creating manual Service Dependencies between all the "Ping" services on every Host. Then you end up with a complex configuration that is very hard to understand. But for things like telling you when a power supply or fan has died, or if the web service crashed, it works well. We did a survey of a bunch of open source tools to replace Nagios and have settled on Icinga for it's APIs, dynamic rules with pattern matching and boolean logic, and compatibility with Nagios plugins. But it still doesn't change the basic architectural choices of the Nagios core engine and hence isn't a good fit for network device/interface reachability monitoring IMO. From jason+nanog at lixfeld.ca Wed Aug 15 16:41:17 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Wed, 15 Aug 2018 12:41:17 -0400 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: (resending with really, really the correct from:) Here’s a snapshot of what tends to work for me, along with my $0.02 of thoughts: - Observium handles polling, graphing and alerting for SNMP exposed objects on network devices, - I feel that a visual representation of the physical network topology is extremely helpful for many aspects of day-to-day operations, so InterMapper handles that, - Syslog and SNMPTRAP collection, correlation and alerting is handled by Splunk, - Netflow collection and graphing is handled by nfsen, - Smokeping for what smokeping does (but I just discovered vaping this morning, which looks awesome and will get some love). I believe that LibraNMS has at some capability to use more robust graphing engines, which for me would be great; I find rrd is a little limiting these days. I think it also has (better?) support for weathermap, so I could technically replace InterMapper with weathermap and collapse the tool chain a bit. With streaming telemetry becoming more of a thing, there will definitely be a shift away from SNMP for things that are polled for statistics. There are interesting Netflow tools like Elastiflow and pmacct that are more robust than nfsen. The latter has a ton of functionality that can produce some interesting data for purposes of traffic engineering, among other things. The former uses ELK so it’s inherently gorgeous and fast, but it requires a ton of resources depending on the number of flows/sec that you’re collecting. Hope that helps. Sent from my iPhone > On Aug 15, 2018, at 9:49 AM, Colton Conor wrote: > > We are looking for a new network monitoring system. Since there are so many operators on this list, I would like to know which NMS do you use and why? Is there one that you really like, and others that you hate? > > For free options (opensouce), LibreNMS and NetXMS come highly recommended by many wireless ISPs on low budgets. However, I am not sure the commercial options available nor their price points. > > From daniel.p.lacey at gmail.com Wed Aug 15 17:04:59 2018 From: daniel.p.lacey at gmail.com (Daniel Lacey) Date: Wed, 15 Aug 2018 11:04:59 -0600 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: <906bb176-1a4c-7602-3998-d86d38b5987c@gmail.com> Take a look at opennms.org Scales very well. Lots of API hooks for integration with other data sources and applications. It is open source and they offer paid support services, one-time (e.g. setup and training) or on-going support contracts. On 8/15/18 7:49 AM, Colton Conor wrote: > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use > and why? Is there one that you really like, and others that you hate?  > > For free options (opensouce), LibreNMS and NetXMS come highly > recommended by many wireless ISPs on low budgets. However, I am not > sure the commercial options available nor their price points. > > From mel at beckman.org Wed Aug 15 17:09:44 2018 From: mel at beckman.org (Mel Beckman) Date: Wed, 15 Aug 2018 17:09:44 +0000 Subject: What NMS do you use and why? In-Reply-To: <906bb176-1a4c-7602-3998-d86d38b5987c@gmail.com> References: , <906bb176-1a4c-7602-3998-d86d38b5987c@gmail.com> Message-ID: I run OpenNMS currently, and the one problem I have is it's very peculiar -- one might say academic -- terminology and structure. It's not a point-and-click interface, despite being web-based. Instead, you must wrangle with pollers and responders and notifiers. Eventually I got my head around it, but it's still pretty painful to use. I run a mix of Cactus, Intermapper, and PRTG, with PRTG a very nice commercial product that offers a free version supporting up to 100 sensors. -mel ________________________________ From: NANOG on behalf of Daniel Lacey Sent: Wednesday, August 15, 2018 10:04:59 AM To: nanog at nanog.org Subject: Re: What NMS do you use and why? Take a look at opennms.org Scales very well. Lots of API hooks for integration with other data sources and applications. It is open source and they offer paid support services, one-time (e.g. setup and training) or on-going support contracts. On 8/15/18 7:49 AM, Colton Conor wrote: > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use > and why? Is there one that you really like, and others that you hate? > > For free options (opensouce), LibreNMS and NetXMS come highly > recommended by many wireless ISPs on low budgets. However, I am not > sure the commercial options available nor their price points. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cra at WPI.EDU Wed Aug 15 17:20:08 2018 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 15 Aug 2018 13:20:08 -0400 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: <20180815172008.u77lt7ac2ltw5w7o@angus.ind.wpi.edu> On Wed, Aug 15, 2018 at 08:49:12AM -0500, Colton Conor wrote: > We are looking for a new network monitoring system. Since there are so many > operators on this list, I would like to know which NMS do you use and why? > Is there one that you really like, and others that you hate? > > For free options (opensouce), LibreNMS and NetXMS come highly recommended > by many wireless ISPs on low budgets. However, I am not sure the commercial > options available nor their price points. Part 2 (see Part 1 for my epistles on Autostatus & Nagios). To complement Autostatus and Nagios and to replace our ancient Cricket SNMP graphing/trending solution, several years ago we had adopted Statseeker. We've now replaced that with AKiPS, which I highly recommend. It does your basic 1 minute SNMP graphing, but it also collects SNMP Traps & Syslog feeds and can alert on custom matches & events as well as host down via ping. Its main feature is its comprehensive vendor MIB support--it supports almost every vendor's device we use out of the box with no special configuration. They are constantly adding support for new vendors/devices and they are pretty responsive to adding new ones. AKiPS' weakness is in alerting--it makes no attempt at depenencies or event correlation, so you can get flooded with events. From randy at psg.com Wed Aug 15 17:41:54 2018 From: randy at psg.com (Randy Bush) Date: Wed, 15 Aug 2018 10:41:54 -0700 Subject: tcp md5 bgp attacks? In-Reply-To: References: <9cbc76f3-06b6-c399-fcff-e19121153381@bogus.com> Message-ID: > With regards to BGP, the MD5 thing was promulgated to counter what was > a largely theoretical threat. the rst attacks were a very serious problem. attacks were very real and very disruptive. gtsm et alia were a few years later. > We still see DDoS attacks against routers, of course. i am focused on bgp, not the daily craptastic packet fling. randy From peter at colovore.com Wed Aug 15 16:37:34 2018 From: peter at colovore.com (Peter Harrison) Date: Wed, 15 Aug 2018 09:37:34 -0700 Subject: What NMS do you use and why? In-Reply-To: <20180815161902.57hxwjkavtcdrazd@angus.ind.wpi.edu> References: <20180815161902.57hxwjkavtcdrazd@angus.ind.wpi.edu> Message-ID: As a small operator, we mainly use Icinga for the reasons Chuck mentioned. The API allows us to do updates based on configuration parameters we've created in a custom MySQL database. Peter Peter Harrison CTO, Colovore LLC On Wed, Aug 15, 2018 at 9:19 AM, Chuck Anderson wrote: > On Wed, Aug 15, 2018 at 08:49:12AM -0500, Colton Conor wrote: > > We are looking for a new network monitoring system. Since there are so > many > > operators on this list, I would like to know which NMS do you use and > why? > > Is there one that you really like, and others that you hate? > > > > For free options (opensouce), LibreNMS and NetXMS come highly recommended > > by many wireless ISPs on low budgets. However, I am not sure the > commercial > > options available nor their price points. > > For monitoring network device/interface data plane reachability with > ping, we are still using an ancient piece of open source software > called Autostatus. I find it invaluable for notifying us about > reachability issues with it's simple to understand parent/child > relationships and graph-based fping methodology. It isn't perfect--it > doesn't scale very well, it doesn't have HA/clustering, it has no > fancy dependencies (just basic parent-child) and no event correlation, > no contact scheduling, no API, etc. but it is very easy to understand > why you are getting an alert or not and boiling that down to a single > point of failure and as such it provides reliable, trustable > information about data plane reachability from one vantage point on > the network. > > For monitoring server & network service availability, > device/environmental health, etc. we are currently using Nagios. My > problems with it are that it has complex rules for how/when to perform > a specific health check and send or suppress a notification (and > perhaps bugs in our old version that never ever seems to send any Host > notifications except when it does) and the whole idea of "suppress the > Host check unless all Service checks for all services on the host are > down" doesn't really fit well with the idea of monitoring > device/interface reachability on routers & switches that make up a > complex graph of dependencies. Trying to shoehorn Nagios into > alerting on just the one IP address/device/interface that is causing > all the others behind it to be unreachable doesn't work very well. > You can't use Host Depenencies because Host checks are suppressed by > default, and Host Dependencies don't affect Service > Checks/notifications. Forcing Host checks to always run causes > performance problems. Creating a "Ping" service for every host > requires creating manual Service Dependencies between all the "Ping" > services on every Host. Then you end up with a complex configuration > that is very hard to understand. But for things like telling you when > a power supply or fan has died, or if the web service crashed, it > works well. > > We did a survey of a bunch of open source tools to replace Nagios and > have settled on Icinga for it's APIs, dynamic rules with pattern > matching and boolean logic, and compatibility with Nagios plugins. > But it still doesn't change the basic architectural choices of the > Nagios core engine and hence isn't a good fit for network > device/interface reachability monitoring IMO. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at wi-fiber.io Wed Aug 15 19:21:05 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Wed, 15 Aug 2018 13:21:05 -0600 Subject: Craigslist Message-ID: Cragslist is blocking our largest IP block, if someone from CL could contact me off list, that would be great. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Aug 15 19:25:48 2018 From: bill at herrin.us (William Herrin) Date: Wed, 15 Aug 2018 15:25:48 -0400 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor wrote: > We are looking for a new network monitoring system. Since there are so many > operators on this list, I would like to know which NMS do you use and why? > Is there one that you really like, and others that you hate? I still use a tool I wrote in perl nearly 20 years ago called "MrPing." MrPing handles multi-dependency graphs. Consider: A is reachable via either B or C. If A and B are down but C is up, A being down is a separate failure from B being down. I need to know about both. If B and C are both down, A is unreachable. I don't want to receive alerts about A because they'll distract me from the root cause of the problem: that both B and C are down. The NMS should record that A is unreachable but it should also tell me that A being unreachable is a dependent failure that I can ignore until I fix the failures it depends on. The NMSes I've paid attention to either don't support dependencies well at all or support only simple hierarchical dependencies. Resilient, professional networks simply aren't built that way. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From lobna_gouda at hotmail.com Wed Aug 15 23:06:11 2018 From: lobna_gouda at hotmail.com (lobna gouda) Date: Wed, 15 Aug 2018 23:06:11 +0000 Subject: tcp md5 bgp attacks? In-Reply-To: References: Message-ID: Out of curiosity, are you asking for a specific research/project that you need some data for? GTSM is not a replacement for the ACL filtering the bgp speakers or the MD5 ( that is widely supported). If GTSM is not supported you can always predefine the TTL it in the session and manipulate the defaults ( 1 for EBGP 64 IBGP) yet this is works on small scale networks. Another practice is to define who starts the session ( as port 179 is not hard to figure). Yet in all case the ACL is your first defense who is allowed for TCP and when the session is established what they can advertise and what you are willing to accept across the session ( NXT hop, n0. of routers, as-path, communities....etc). https://www.noction.com/blog/bgp_security_md5_password_and_gtsm [https://www.noction.com/wp-content/uploads/2015/04/MD5-password.png] BGP Security – the MD5 password and GTSM | Noction www.noction.com There are three security mechanisms that can protect against potential security issues with BGP: the BGP TCP MD5 password, IPsec and GTSM... Brgds, LG ________________________________ From: NANOG on behalf of Randy Bush Sent: Tuesday, August 14, 2018 5:38 PM To: North American Network Operators' Group Subject: tcp md5 bgp attacks? so we started to wonder if, since we started protecting our bgp sessions with md5 (in the 1990s), are there still folk trying to attack? we were unable to find bgp mib counters. there are igp interface counters, but that was not our immediate interest. we did find that md5 failures are logged. looking at my logs for a few years, i find essentially nothing; two 'attackers,' one my own ibgp peer, and one that noted evildoer rob thomas, bgprs01.ord08.cymru.com. we would be interested in data from others. note that we are neither contemplating nor suggesting removing md5 from [y]our bgp sessions. randy [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif] Virus-free. www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From npeelman at ETC1.net Wed Aug 15 23:14:32 2018 From: npeelman at ETC1.net (Nick Peelman) Date: Wed, 15 Aug 2018 23:14:32 +0000 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: I think anybody looking for a be-all-end-all solution will find nothing but heartburn. different suites have different strong suits, and deciding you are going to pursue one and ignore all others may mean living without a feature or set of features you may find really useful or eventually necessary. but maintaining multiple complete NMSes isn’t really tenable either. all of that said, we use a combination of a couple. Nagios/Icinga because it’s been around forever (both in the world and in our network), and the power of script based checks, being able to write your own handlers and pretty much just leverage it as a framework you can shove questions into and get regular answers from is invaluable. LibreNMS gives us the best pretty pictures, letting us monitor much much more than just interface traffic, out of the box. much more than cacti is capable of without a ton of work (i.e. down to the tx/rx power and temperature readings of individual SFPs). it scales relatively well; at least in theory. i will be able to tell you for sure later this year as we are near the limits of what we can monitor with a single polling device. alerting out of Libre into Slack has proven quite fantastic. we can spawn threads attached to anything from a BGP peer dropping or a CPU alert as we move to triage and solve, even if we are in the field or meetings or whatever. we also still have cacti around for random one-offs. as great as Libre is, its poller can be a bit intense for some devices; so in those cases it’s safer for us to just have cacti graph the one or two OIDs we need specifically, without trolling all the other available sensors. we ran OpenNMS for a bit, but it proved way to dumb to maintain a large (and growing) complex network, without dedicating at least one or two people to the care and feeding of it. -nick — Nick Peelman Network Engineer | Enhanced Telecommunications Corp. 812-222-0169 | npeelman at etc1.net | www.etczone.com Sent from my iPhone On Aug 15, 2018, at 09:49, Colton Conor > wrote: We are looking for a new network monitoring system. Since there are so many operators on this list, I would like to know which NMS do you use and why? Is there one that you really like, and others that you hate? For free options (opensouce), LibreNMS and NetXMS come highly recommended by many wireless ISPs on low budgets. However, I am not sure the commercial options available nor their price points. From jloiacon at gmail.com Thu Aug 16 00:31:13 2018 From: jloiacon at gmail.com (Joe Loiacono) Date: Wed, 15 Aug 2018 20:31:13 -0400 (EDT) Subject: What NMS do you use and why? In-Reply-To: Message-ID: <593335944.184.1534379472982.JavaMail.jloia@DESKTOP-FDMC6S8> Consider also open-source FlowViewer for netflow capture and analysis. A lot of very useful netflow based analytical tools in an easy UI. Sits on top of a robust set of Carnegie-Mellon's high-capacity SiLK netflow tools. https://sourceforge.net/projects/flowviewer/ Joe ----- Original Message ----- From: "William Herrin" To: "Colton Conor" Cc: "NANOG" Sent: Wednesday, August 15, 2018 3:25:48 PM Subject: Re: What NMS do you use and why? On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor wrote: > We are looking for a new network monitoring system. Since there are so many > operators on this list, I would like to know which NMS do you use and why? > Is there one that you really like, and others that you hate? I still use a tool I wrote in perl nearly 20 years ago called "MrPing." MrPing handles multi-dependency graphs. Consider: A is reachable via either B or C. If A and B are down but C is up, A being down is a separate failure from B being down. I need to know about both. If B and C are both down, A is unreachable. I don't want to receive alerts about A because they'll distract me from the root cause of the problem: that both B and C are down. The NMS should record that A is unreachable but it should also tell me that A being unreachable is a dependent failure that I can ignore until I fix the failures it depends on. The NMSes I've paid attention to either don't support dependencies well at all or support only simple hierarchical dependencies. Resilient, professional networks simply aren't built that way. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From stano at imaginesoftware.com Thu Aug 16 15:39:52 2018 From: stano at imaginesoftware.com (Stan Ouchakov) Date: Thu, 16 Aug 2018 15:39:52 +0000 Subject: What NMS do you use and why? In-Reply-To: <593335944.184.1534379472982.JavaMail.jloia@DESKTOP-FDMC6S8> References: <593335944.184.1534379472982.JavaMail.jloia@DESKTOP-FDMC6S8> Message-ID: Regarding netflow/sflow/ipfix monitoring, we had recently started using elastiflow by Robert Cowart. Scales very well with pretty visualizations. Cannot imagine what paid / supported version has to offer :) https://github.com/robcowart/elastiflow -----Original Message----- From: NANOG On Behalf Of Joe Loiacono Sent: Wednesday, August 15, 2018 8:31 PM To: William Herrin Cc: NANOG Subject: Re: What NMS do you use and why? Consider also open-source FlowViewer for netflow capture and analysis. A lot of very useful netflow based analytical tools in an easy UI. Sits on top of a robust set of Carnegie-Mellon's high-capacity SiLK netflow tools. https://sourceforge.net/projects/flowviewer/ Joe ----- Original Message ----- From: "William Herrin" To: "Colton Conor" Cc: "NANOG" Sent: Wednesday, August 15, 2018 3:25:48 PM Subject: Re: What NMS do you use and why? On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor wrote: > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use and why? > Is there one that you really like, and others that you hate? I still use a tool I wrote in perl nearly 20 years ago called "MrPing." MrPing handles multi-dependency graphs. Consider: A is reachable via either B or C. If A and B are down but C is up, A being down is a separate failure from B being down. I need to know about both. If B and C are both down, A is unreachable. I don't want to receive alerts about A because they'll distract me from the root cause of the problem: that both B and C are down. The NMS should record that A is unreachable but it should also tell me that A being unreachable is a dependent failure that I can ignore until I fix the failures it depends on. The NMSes I've paid attention to either don't support dependencies well at all or support only simple hierarchical dependencies. Resilient, professional networks simply aren't built that way. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From npeelman at ETC1.net Thu Aug 16 15:42:44 2018 From: npeelman at ETC1.net (Nick Peelman) Date: Thu, 16 Aug 2018 15:42:44 +0000 Subject: What NMS do you use and why? In-Reply-To: References: <593335944.184.1534379472982.JavaMail.jloia@DESKTOP-FDMC6S8>, Message-ID: <61BD4D17-F5EB-46AC-BEE2-5D289FECDDBD@ETC1.net> seconded. the pains of maintaining ELK are made worthwhile by this alone. -nick — Nick Peelman Network Engineer | Enhanced Telecommunications Corp. 812-222-0169 | npeelman at etc1.net | www.etczone.com Sent from my iPhone On Aug 16, 2018, at 11:41, Stan Ouchakov > wrote: Regarding netflow/sflow/ipfix monitoring, we had recently started using elastiflow by Robert Cowart. Scales very well with pretty visualizations. Cannot imagine what paid / supported version has to offer :) https://github.com/robcowart/elastiflow -----Original Message----- From: NANOG > On Behalf Of Joe Loiacono Sent: Wednesday, August 15, 2018 8:31 PM To: William Herrin > Cc: NANOG > Subject: Re: What NMS do you use and why? Consider also open-source FlowViewer for netflow capture and analysis. A lot of very useful netflow based analytical tools in an easy UI. Sits on top of a robust set of Carnegie-Mellon's high-capacity SiLK netflow tools. https://sourceforge.net/projects/flowviewer/ Joe ----- Original Message ----- From: "William Herrin" > To: "Colton Conor" > Cc: "NANOG" > Sent: Wednesday, August 15, 2018 3:25:48 PM Subject: Re: What NMS do you use and why? On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor > wrote: We are looking for a new network monitoring system. Since there are so many operators on this list, I would like to know which NMS do you use and why? Is there one that you really like, and others that you hate? I still use a tool I wrote in perl nearly 20 years ago called "MrPing." MrPing handles multi-dependency graphs. Consider: A is reachable via either B or C. If A and B are down but C is up, A being down is a separate failure from B being down. I need to know about both. If B and C are both down, A is unreachable. I don't want to receive alerts about A because they'll distract me from the root cause of the problem: that both B and C are down. The NMS should record that A is unreachable but it should also tell me that A being unreachable is a dependent failure that I can ignore until I fix the failures it depends on. The NMSes I've paid attention to either don't support dependencies well at all or support only simple hierarchical dependencies. Resilient, professional networks simply aren't built that way. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From kushal.r at h4g.co Thu Aug 16 16:49:35 2018 From: kushal.r at h4g.co (Kushal) Date: Thu, 16 Aug 2018 22:19:35 +0530 Subject: What NMS do you use and why? In-Reply-To: <61BD4D17-F5EB-46AC-BEE2-5D289FECDDBD@ETC1.net> References: <593335944.184.1534379472982.JavaMail.jloia@DESKTOP-FDMC6S8> <61BD4D17-F5EB-46AC-BEE2-5D289FECDDBD@ETC1.net> Message-ID: Being a small business we like to use a mostly free and open source tools. Our networking monitoring stack presently looks like: Simple Reachability Monitoring  (Ping) - uptimerobot.com Just $4.5 per month for 50 monitors with 1 minute intervals (free if you are find with 5 minutes monitoring intervals). This is connected to our slack channel and also sends SMS when something goes offline. Traffic & Device Monitoring - LibreNMS A fork of Observium but adds the much needed alerting feature that observing only offers with it's paid plans. We use it to monitor switch port traffic, BGP sessions, device health, etc. Packet Inspection or Flow Monitoring we use FastNetMon (https://fastnetmon.com/features/) the free edition is good for our needs.  On August 16, 2018 at 9:16:42 PM, Nick Peelman (npeelman at etc1.net) wrote: seconded. the pains of maintaining ELK are made worthwhile by this alone. -nick — Nick Peelman Network Engineer | Enhanced Telecommunications Corp. 812-222-0169 | npeelman at etc1.net | www.etczone.com Sent from my iPhone On Aug 16, 2018, at 11:41, Stan Ouchakov > wrote: Regarding netflow/sflow/ipfix monitoring, we had recently started using elastiflow by Robert Cowart. Scales very well with pretty visualizations. Cannot imagine what paid / supported version has to offer :) https://github.com/robcowart/elastiflow -----Original Message----- From: NANOG > On Behalf Of Joe Loiacono Sent: Wednesday, August 15, 2018 8:31 PM To: William Herrin > Cc: NANOG > Subject: Re: What NMS do you use and why? Consider also open-source FlowViewer for netflow capture and analysis. A lot of very useful netflow based analytical tools in an easy UI. Sits on top of a robust set of Carnegie-Mellon's high-capacity SiLK netflow tools. https://sourceforge.net/projects/flowviewer/ Joe ----- Original Message ----- From: "William Herrin" > To: "Colton Conor" > Cc: "NANOG" > Sent: Wednesday, August 15, 2018 3:25:48 PM Subject: Re: What NMS do you use and why? On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor > wrote: We are looking for a new network monitoring system. Since there are so many operators on this list, I would like to know which NMS do you use and why? Is there one that you really like, and others that you hate? I still use a tool I wrote in perl nearly 20 years ago called "MrPing." MrPing handles multi-dependency graphs. Consider: A is reachable via either B or C. If A and B are down but C is up, A being down is a separate failure from B being down. I need to know about both. If B and C are both down, A is unreachable. I don't want to receive alerts about A because they'll distract me from the root cause of the problem: that both B and C are down. The NMS should record that A is unreachable but it should also tell me that A being unreachable is a dependent failure that I can ignore until I fix the failures it depends on. The NMSes I've paid attention to either don't support dependencies well at all or support only simple hierarchical dependencies. Resilient, professional networks simply aren't built that way. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From michbrau at cisco.com Thu Aug 16 18:23:47 2018 From: michbrau at cisco.com (Michael Braun (michbrau)) Date: Thu, 16 Aug 2018 18:23:47 +0000 Subject: What NMS do you use and why? In-Reply-To: <61BD4D17-F5EB-46AC-BEE2-5D289FECDDBD@ETC1.net> References: <593335944.184.1534379472982.JavaMail.jloia@DESKTOP-FDMC6S8>, <61BD4D17-F5EB-46AC-BEE2-5D289FECDDBD@ETC1.net> Message-ID: As open source tools go, Smokeping is a great tool to add to your NMS arsenal: https://oss.oetiker.ch/smokeping/ Mike On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor > wrote: We are looking for a new network monitoring system. Since there are so many operators on this list, I would like to know which NMS do you use and why? Is there one that you really like, and others that you hate? I still use a tool I wrote in perl nearly 20 years ago called "MrPing." MrPing handles multi-dependency graphs. From nickdwhite at gmail.com Thu Aug 16 20:53:43 2018 From: nickdwhite at gmail.com (Nick W) Date: Thu, 16 Aug 2018 16:53:43 -0400 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: LibreNMS + Weathermap for graphs, real-time, and alerting. Vaping for a simple Up/Degraded/Down dashboard (great replacement for Multiping/PingPlotter on a TV). Elastiflow for netflow. I really really want to like OpenNMS, and would love to use it daily; I feel like it could handle many integrations well, but have never had the time to dedicate to fully diving into it. I have used it in the past for small setups (monitoring ~100 remotely managed routers/firewall) and it did well, after getting past some learning curves. I keep coming back to it every 6 months or so and trying the latest version. On Wed, Aug 15, 2018 at 9:51 AM Colton Conor wrote: > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use and > why? Is there one that you really like, and others that you hate? > > For free options (opensouce), LibreNMS and NetXMS come highly recommended > by many wireless ISPs on low budgets. However, I am not sure the commercial > options available nor their price points. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Romeo.Czumbil at tierpoint.com Fri Aug 17 00:40:24 2018 From: Romeo.Czumbil at tierpoint.com (Romeo Czumbil) Date: Fri, 17 Aug 2018 00:40:24 +0000 Subject: Akamia Contact Message-ID: <41e12b5cbbf540028a969c4fa2119c62@dal01-ex01.tierpoint.net> Can somebody from Akamia Network Engineering contact me off-list Thank you From richb.hanover at gmail.com Fri Aug 17 15:13:04 2018 From: richb.hanover at gmail.com (Rich Brown) Date: Fri, 17 Aug 2018 11:13:04 -0400 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: <1F4CB16E-7748-46D3-8BC0-5EF1B7ED3EF3@gmail.com> > On Aug 17, 2018, at 8:00 AM, nanog-request at nanog.org wrote: > > Message: 2 > Date: Wed, 15 Aug 2018 20:31:13 -0400 (EDT) > From: Joe Loiacono > > To: William Herrin > > Cc: NANOG >, Colton Conor > > Subject: Re: What NMS do you use and why? > Message-ID: > <593335944.184.1534379472982.JavaMail.jloia at DESKTOP-FDMC6S8> > Content-Type: text/plain; charset=utf-8 > > Consider also open-source FlowViewer for netflow capture and analysis. A lot of very useful netflow based analytical tools in an easy UI. Sits on top of a robust set of Carnegie-Mellon's high-capacity SiLK netflow tools. > > https://sourceforge.net/projects/flowviewer/ > > Joe About a year ago, I was horsing around with Netflow tools. I built a Docker image to make it easy to install FlowViewer. I also factored the FlowViewer source files to make it easier to install in a Docker instance. I have no opinion whether Docker would be a good solution for a high performance Netflow collector. However, this Dockerfile makes it easy (~15 minutes) to get started with testing. Grab the files from my github repo's: https://github.com/richb-hanover/FlowViewer https://github.com/richb-hanover/docker-silk-flowviewer I also made a couple other Docker instances of Netflow tools. They're mentioned in my blog: http://richb-hanover.com/netflow-collectors-for-home-networks/ Enjoy! Rich Brown Blueberry Hill Software -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Aug 17 18:03:36 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Aug 2018 04:03:36 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180817180336.794C3C450F@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 18 Aug, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 710936 Prefixes after maximum aggregation (per Origin AS): 273073 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 341471 Total ASes present in the Internet Routing Table: 61560 Prefixes per ASN: 11.55 Origin-only ASes present in the Internet Routing Table: 53145 Origin ASes announcing only one prefix: 23145 Transit ASes present in the Internet Routing Table: 8415 Transit-only ASes present in the Internet Routing Table: 265 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 64 Number of instances of unregistered ASNs: 64 Number of 32-bit ASNs allocated by the RIRs: 23718 Number of 32-bit ASNs visible in the Routing Table: 19114 Prefixes from 32-bit ASNs in the Routing Table: 80241 Number of bogon 32-bit ASNs visible in the Routing Table: 79 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 273 Number of addresses announced to Internet: 2857353028 Equivalent to 170 /8s, 79 /16s and 191 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 237374 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 193698 Total APNIC prefixes after maximum aggregation: 55273 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 191862 Unique aggregates announced from the APNIC address blocks: 79147 APNIC Region origin ASes present in the Internet Routing Table: 9007 APNIC Prefixes per ASN: 21.30 APNIC Region origin ASes announcing only one prefix: 2525 APNIC Region transit ASes present in the Internet Routing Table: 1346 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3968 Number of APNIC addresses announced to Internet: 767572739 Equivalent to 45 /8s, 192 /16s and 59 /24s 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, 64297-64395, 131072-139577 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: 211280 Total ARIN prefixes after maximum aggregation: 100125 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 211152 Unique aggregates announced from the ARIN address blocks: 100055 ARIN Region origin ASes present in the Internet Routing Table: 18222 ARIN Prefixes per ASN: 11.59 ARIN Region origin ASes announcing only one prefix: 6755 ARIN Region transit ASes present in the Internet Routing Table: 1805 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2404 Number of ARIN addresses announced to Internet: 1103306912 Equivalent to 65 /8s, 195 /16s and 32 /24s 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-399260 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: 194600 Total RIPE prefixes after maximum aggregation: 92972 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 190927 Unique aggregates announced from the RIPE address blocks: 113250 RIPE Region origin ASes present in the Internet Routing Table: 25424 RIPE Prefixes per ASN: 7.51 RIPE Region origin ASes announcing only one prefix: 11458 RIPE Region transit ASes present in the Internet Routing Table: 3531 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7311 Number of RIPE addresses announced to Internet: 713978496 Equivalent to 42 /8s, 142 /16s and 114 /24s 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, 64396-64495 196608-207259 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: 91962 Total LACNIC prefixes after maximum aggregation: 20542 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 93397 Unique aggregates announced from the LACNIC address blocks: 40757 LACNIC Region origin ASes present in the Internet Routing Table: 7426 LACNIC Prefixes per ASN: 12.58 LACNIC Region origin ASes announcing only one prefix: 2016 LACNIC Region transit ASes present in the Internet Routing Table: 1397 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4971 Number of LACNIC addresses announced to Internet: 171888672 Equivalent to 10 /8s, 62 /16s and 208 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 19331 Total AfriNIC prefixes after maximum aggregation: 4104 AfriNIC Deaggregation factor: 4.71 Prefixes being announced from the AfriNIC address blocks: 23325 Unique aggregates announced from the AfriNIC address blocks: 8018 AfriNIC Region origin ASes present in the Internet Routing Table: 1187 AfriNIC Prefixes per ASN: 19.65 AfriNIC Region origin ASes announcing only one prefix: 391 AfriNIC Region transit ASes present in the Internet Routing Table: 240 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 460 Number of AfriNIC addresses announced to Internet: 100161536 Equivalent to 5 /8s, 248 /16s and 88 /24s 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 4684 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4414 477 468 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2968 1150 82 VIETEL-AS-AP Viettel Group, VN 4766 2840 11134 766 KIXS-AS-KR Korea Telecom, KR 9829 2812 1497 543 BSNL-NIB National Internet Backbone, IN 45899 2578 1638 157 VNPT-AS-VN VNPT Corp, VN 9394 2544 4907 32 CTTNET China TieTong Telecommunications 17974 2262 962 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2249 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2117 417 204 TATACOMM-AS TATA Communications formerl 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 6327 3442 1324 82 SHAW - Shaw Communications Inc., CA 22773 3235 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 3041 256 408 CABLEONE - CABLE ONE, INC., US 16509 2258 4807 767 AMAZON-02 - Amazon.com, Inc., US 18566 2166 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2125 2640 488 CHARTER-NET-HKY-NC - Charter Communicat 30036 2022 344 144 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2016 5085 604 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16625 2012 1035 1454 AKAMAI-AS - Akamai Technologies, Inc., 7018 1765 20206 1280 ATT-INTERNET4 - AT&T Services, Inc., US 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 12479 4691 1613 124 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2804 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2541 621 1889 AKAMAI-ASN1, US 12389 2041 1891 731 ROSTELECOM-AS, RU 34984 2013 335 506 TELLCOM-AS, TR 9121 1824 1692 19 TTNET, TR 13188 1604 100 43 TRIOLAN, UA 8402 1194 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1177 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5196 3349 607 Uninet S.A. de C.V., MX 10620 3488 532 453 Telmex Colombia S.A., CO 11830 2657 369 78 Instituto Costarricense de Electricidad 6503 1665 444 63 Axtel, S.A.B. de C.V., MX 7303 1429 952 205 Telecom Argentina S.A., AR 28573 1085 2229 181 CLARO S.A., BR 3816 1021 508 129 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 933 377 31 Telefonica del Peru S.A.A., PE 18881 915 1080 32 TELEF�NICA BRASIL S.A, BR 13999 878 522 248 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1184 396 48 LINKdotNET-AS, EG 37611 893 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 743 1411 40 ETISALAT-MISR, EG 24835 641 818 18 RAYA-AS, EG 8452 593 1728 14 TE-AS TE-AS, EG 37492 474 470 57 ORANGE-, TN 29571 460 68 12 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 379 231 15 MauritiusTelecom, MU 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 8151 5196 3349 607 Uninet S.A. de C.V., MX 12479 4691 1613 124 UNI2-AS, ES 4538 4684 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4414 477 468 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3488 532 453 Telmex Colombia S.A., CO 6327 3442 1324 82 SHAW - Shaw Communications Inc., CA 22773 3235 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 3041 256 408 CABLEONE - CABLE ONE, INC., US 7552 2968 1150 82 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4538 4684 4610 ERX-CERNET-BKB China Education and Research Net 12479 4691 4567 UNI2-AS, ES 7545 4414 3946 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3442 3360 SHAW - Shaw Communications Inc., CA 22773 3235 3086 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 10620 3488 3035 Telmex Colombia S.A., CO 7552 2968 2886 VIETEL-AS-AP Viettel Group, VN 8551 2804 2760 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3041 2633 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 64500 DOCUMENT 45.43.56.0/24 135391 AOFEI-HK AOFEI DATA INTERNATIO 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 4259905537 PRIVATE 103.250.48.0/24 132917 YELLOWPAGESGROUP-AS-AP Yellow Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 45.121.32.0/22 134356 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:14 /9:11 /10:36 /11:99 /12:291 /13:570 /14:1096 /15:1899 /16:13380 /17:7929 /18:13805 /19:25371 /20:39332 /21:45624 /22:88177 /23:71681 /24:399464 /25:800 /26:603 /27:624 /28:35 /29:20 /30:19 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3440 4691 UNI2-AS, ES 6327 3231 3442 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2501 3235 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11492 2413 3041 CABLEONE - CABLE ONE, INC., US 8551 2266 2804 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2060 2166 MEGAPATH5-US - MegaPath Corporation, US 11830 2005 2657 Instituto Costarricense de Electricidad y Telec 30036 1774 2022 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1579 3488 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1617 2:823 4:19 5:2843 6:43 7:1 8:1126 12:1864 13:211 14:1799 15:32 16:3 17:194 18:54 20:50 23:2478 24:2239 25:2 27:2480 31:2029 32:88 35:29 36:522 37:2891 38:1494 39:254 40:118 41:3168 42:698 43:1965 44:121 45:5346 46:3110 47:198 49:1340 50:1054 51:318 52:1077 54:368 55:1 56:12 57:39 58:1627 59:991 60:402 61:2118 62:1860 63:1789 64:5075 65:2211 66:4722 67:2587 68:1161 69:3299 70:1157 71:582 72:2169 74:2723 75:419 76:463 77:1629 78:1688 79:2131 80:1566 81:1379 82:1051 83:783 84:1033 85:1999 86:566 87:1369 88:909 89:2353 90:215 91:6437 92:1269 93:2379 94:2395 95:2953 96:893 97:356 98:934 99:133 100:85 101:992 102:173 103:18381 104:3565 105:214 106:770 107:1783 108:711 109:3158 110:1642 111:1796 112:1337 113:1301 114:1130 115:1642 116:1646 117:1715 118:2221 119:1670 120:1015 121:1050 122:2418 123:1725 124:1445 125:1916 128:1118 129:680 130:496 131:1631 132:730 133:190 134:1024 135:225 136:504 137:646 138:1950 139:673 140:473 141:734 142:815 143:1013 144:812 145:483 146:1219 147:728 148:1641 149:758 150:751 151:1101 152:827 153:323 154:1493 155:802 156:1452 157:798 158:655 159:1820 160:1306 161:808 162:2622 163:606 164:1083 165:1539 166:462 167:1294 168:3147 169:833 170:3827 171:493 172:1005 173:2056 174:947 175:786 176:1999 177:4033 178:2506 179:1272 180:2180 181:2420 182:2559 183:1237 184:1046 185:13971 186:3563 187:2420 188:2928 189:2029 190:8166 191:1358 192:9828 193:6111 194:5006 195:3985 196:2685 197:1614 198:5578 199:5917 200:7369 201:4974 202:10286 203:10276 204:4583 205:2900 206:3162 207:3208 208:3936 209:4023 210:3878 211:1998 212:3040 213:2823 214:1036 215:55 216:6041 217:2117 218:859 219:568 220:1805 221:995 222:971 223:1377 End of report From willd at staff.gwi.net Fri Aug 17 19:31:27 2018 From: willd at staff.gwi.net (Will Duquette) Date: Fri, 17 Aug 2018 15:31:27 -0400 Subject: Inbound Call Issues Message-ID: Has anyone had issues reported over the last few weeks from customers with inbound calls in the Northeast reporting the following: 1. Long call setup 2. No ring back or very delayed ring back (Post Dial Delay) 3. Delayed audio in calls. Persons on each end maybe talking over each other. 4. Multiple call logs showing up for a single call in logs. We have been engaging multiple providers (CCI, Spectrum, Windstream and Onvoy) and have been making some progress but are looking to see if anyone else is experiencing the same issues. Thanks, -- Will Duquette *Network Engineer II*GWI *Office:* 207-602-1228 *Cell:* 207-590-2084 *Fax:* 207-282-5036 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Fri Aug 17 19:35:25 2018 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 17 Aug 2018 15:35:25 -0400 Subject: Inbound Call Issues In-Reply-To: References: Message-ID: I got this from Bandwidth earlier this afternoon. Might be related: Inbound Calling to Canada Incident Report for Bandwidth New Incident Status: Identified Bandwidth’s vendor has identified the source of impairment within their network and are working towards a resolution. Aug 17, 12:03 EDT Investigating Bandwidth is currently working with our Canadian based vendor to investigate inbound calling to Canadian Numbers. Aug 17, 11:22 EDT This incident affects: Inbound Calling Services (Inbound Calling (SIP)). On Fri, Aug 17, 2018 at 3:31 PM, Will Duquette wrote: > Has anyone had issues reported over the last few weeks from customers with > inbound calls in the Northeast reporting the following: > > 1. Long call setup > 2. No ring back or very delayed ring back (Post Dial Delay) > 3. Delayed audio in calls. Persons on each end maybe talking over each > other. > 4. Multiple call logs showing up for a single call in logs. > > We have been engaging multiple providers (CCI, Spectrum, Windstream and > Onvoy) and have been making some progress but are looking to see if anyone > else is experiencing the same issues. > > Thanks, > > -- > Will Duquette > > *Network Engineer II*GWI > > *Office:* 207-602-1228 > *Cell:* 207-590-2084 > *Fax:* 207-282-5036 > www.gwi.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lguillory at reservetele.com Fri Aug 17 19:37:55 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Fri, 17 Aug 2018 19:37:55 +0000 Subject: Inbound Call Issues In-Reply-To: References: Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FAB0539@RTC-EXCH01.RESERVE.LDS> Yes but I’m in South Louisiana, we’re only seeing issues with Sprint Cell inbound at the moment. I think someone mentioned T-Mobile but haven’t confirmed. We’ve reached out to ATT since the calls are coming into the tandem, they’ve kicked the ticket to maintenance group. We’ve also opened a ticket up with Sprint today, don’t think anything has come of it yet. Luke ns From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Will Duquette Sent: Friday, August 17, 2018 2:31 PM To: nanog at nanog.org Subject: Inbound Call Issues Has anyone had issues reported over the last few weeks from customers with inbound calls in the Northeast reporting the following: 1. Long call setup 2. No ring back or very delayed ring back (Post Dial Delay) 3. Delayed audio in calls. Persons on each end maybe talking over each other. 4. Multiple call logs showing up for a single call in logs. We have been engaging multiple providers (CCI, Spectrum, Windstream and Onvoy) and have been making some progress but are looking to see if anyone else is experiencing the same issues. Thanks, -- Will Duquette Network Engineer II GWI Office: 207-602-1228 Cell: 207-590-2084 Fax: 207-282-5036 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Aug 17 20:50:35 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 17 Aug 2018 15:50:35 -0500 (CDT) Subject: Web UI DHCP Option 82 In-Reply-To: <33165605.6591.1534538778037.JavaMail.mhammett@ThunderFuck> Message-ID: <1799393681.6601.1534539034280.JavaMail.mhammett@ThunderFuck> Are there any web interfaces out there for DHCP servers that accommodate management of DHCP option 82 configs? Neither webmin nor Glass seem to handle ISC's agent.circuit-id outside of presenting the raw config file. I can do that just fine in nano, but I'm looking at something more user-friendly so I'm not the only one that can work on it. I'm also cheap, so not looking at Infoblox or anything like that. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Fri Aug 17 21:41:18 2018 From: mel at beckman.org (Mel Beckman) Date: Fri, 17 Aug 2018 21:41:18 +0000 Subject: Web UI DHCP Option 82 In-Reply-To: <1799393681.6601.1534539034280.JavaMail.mhammett@ThunderFuck> References: <33165605.6591.1534538778037.JavaMail.mhammett@ThunderFuck>, <1799393681.6601.1534539034280.JavaMail.mhammett@ThunderFuck> Message-ID: <6E4A504F-B773-4ED2-8DEE-7B415CC63799@beckman.org> SimpleDNS is a Windows-based DNS server that has an extensive web API. You try out the HTTP API at https://simpledns.com/swagger-ui You could build some simple PHP pages to provide whatever DHCP Options configuration you like. -mel On Aug 17, 2018, at 1:58 PM, Mike Hammett > wrote: Are there any web interfaces out there for DHCP servers that accommodate management of DHCP option 82 configs? Neither webmin nor Glass seem to handle ISC's agent.circuit-id outside of presenting the raw config file. I can do that just fine in nano, but I'm looking at something more user-friendly so I'm not the only one that can work on it. I'm also cheap, so not looking at Infoblox or anything like that. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ryan.Hamel at quadranet.com Fri Aug 17 22:10:02 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Fri, 17 Aug 2018 22:10:02 +0000 Subject: Web UI DHCP Option 82 In-Reply-To: <1799393681.6601.1534539034280.JavaMail.mhammett@ThunderFuck> References: <33165605.6591.1534538778037.JavaMail.mhammett@ThunderFuck> <1799393681.6601.1534539034280.JavaMail.mhammett@ThunderFuck> Message-ID: <582d40b61df94023846f26bbbf6c85c7@MIA-MBX01.quadranet.local> Mike, Take a look into Kea from ISC. The config is JSON based, which allows for nearly any scripting language to make changes, or you can dig into how it works with MySQL for dynamic operation (https://kea.isc.org/wiki/HostReservationsHowTo). Ryan From: NANOG On Behalf Of Mike Hammett Sent: Friday, August 17, 2018 1:51 PM To: nanog at nanog.org list Subject: Web UI DHCP Option 82 Are there any web interfaces out there for DHCP servers that accommodate management of DHCP option 82 configs? Neither webmin nor Glass seem to handle ISC's agent.circuit-id outside of presenting the raw config file. I can do that just fine in nano, but I'm looking at something more user-friendly so I'm not the only one that can work on it. I'm also cheap, so not looking at Infoblox or anything like that. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Fri Aug 17 23:33:13 2018 From: bryan at shout.net (Bryan Holloway) Date: Fri, 17 Aug 2018 18:33:13 -0500 Subject: ARIN IRR whois broken? Message-ID: > whois -h rr.arin.net 2001:500:: % This is the ARIN Routing Registry. %ERROR:101: no entries found % % No entries found in the selected source(s). -- > whois -h rr.ntt.net 2001:500:: route6: 2001:500::/48 descr: Proxy RO for Internet Systems Consortium, Inc. origin: AS3557 remarks: contacts per RFC2142: remarks: Abuse / UCE reports abuse at verio.net remarks: Security issues security at verio.net mnt-by: MAINT-NTTCOM-RA changed: boudreat at eng.verio.net 20070413 source: NTTCOM -- > whois -h rr.level3.net 2001:500:: % RIPEdb(3.0.0a13) with ISI RPSL extensions route6: 2001:500::/48 descr: Proxy RO for Internet Systems Consortium, Inc. origin: AS3557 remarks: contacts per RFC2142: remarks: Abuse / UCE reports abuse at verio.net remarks: Security issues security at verio.net mnt-by: MAINT-NTTCOM-RA changed: boudreat at eng.verio.net 20070413 source: NTTCOM From bryan at shout.net Sat Aug 18 00:01:35 2018 From: bryan at shout.net (Bryan Holloway) Date: Fri, 17 Aug 2018 19:01:35 -0500 Subject: ARIN IRR whois broken? In-Reply-To: References: Message-ID: <84e22a12-ad6b-63cf-d437-00b9ff5923dd@shout.net> Nevermind ... I think I was puzzled by the fact that ARIN doesn't have an entry for its own IP space. Time for beer. On 8/17/18 6:33 PM, Bryan Holloway wrote: > > whois -h rr.arin.net 2001:500:: > % This is the ARIN Routing Registry. > > %ERROR:101: no entries found > % > % No entries found in the selected source(s). > > -- > > > whois -h rr.ntt.net 2001:500:: > route6:     2001:500::/48 > descr:      Proxy RO for Internet Systems Consortium, Inc. > origin:     AS3557 > remarks:    contacts per RFC2142: > remarks:    Abuse / UCE reports abuse at verio.net > remarks:    Security issues     security at verio.net > mnt-by:     MAINT-NTTCOM-RA > changed:    boudreat at eng.verio.net 20070413 > source:     NTTCOM > > -- > > > whois -h rr.level3.net 2001:500:: > > % RIPEdb(3.0.0a13) with ISI RPSL extensions > > route6:        2001:500::/48 > descr:         Proxy RO for Internet Systems Consortium, Inc. > origin:        AS3557 > remarks:       contacts per RFC2142: > remarks:       Abuse / UCE reports abuse at verio.net > remarks:       Security issues     security at verio.net > mnt-by:        MAINT-NTTCOM-RA > changed:       boudreat at eng.verio.net 20070413 > source:        NTTCOM > From niels=nanog at bakker.net Sat Aug 18 10:57:03 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 18 Aug 2018 12:57:03 +0200 Subject: ARIN IRR whois broken? In-Reply-To: <84e22a12-ad6b-63cf-d437-00b9ff5923dd@shout.net> References: <84e22a12-ad6b-63cf-d437-00b9ff5923dd@shout.net> Message-ID: <20180818105703.GC9970@jima.tpb.net> * bryan at shout.net (Bryan Holloway) [Sat 18 Aug 2018, 02:02 CEST]: >Nevermind ... I think I was puzzled by the fact that ARIN doesn't >have an entry for its own IP space. >On 8/17/18 6:33 PM, Bryan Holloway wrote: >> > whois -h rr.arin.net 2001:500:: Try 2001:400::/23 :) -- Niels. From colton.conor at gmail.com Sat Aug 18 13:36:37 2018 From: colton.conor at gmail.com (Colton Conor) Date: Sat, 18 Aug 2018 08:36:37 -0500 Subject: Web UI DHCP Option 82 In-Reply-To: <582d40b61df94023846f26bbbf6c85c7@MIA-MBX01.quadranet.local> References: <33165605.6591.1534538778037.JavaMail.mhammett@ThunderFuck> <1799393681.6601.1534539034280.JavaMail.mhammett@ThunderFuck> <582d40b61df94023846f26bbbf6c85c7@MIA-MBX01.quadranet.local> Message-ID: Mike, I am looking for the same thing. Does Mikrotik have the ability to do what you are requesting? On Fri, Aug 17, 2018 at 5:11 PM Ryan Hamel wrote: > Mike, > > Take a look into Kea from ISC. The config is JSON based, which allows for > nearly any scripting language to make changes, or you can dig into how it > works with MySQL for dynamic operation ( > https://kea.isc.org/wiki/HostReservationsHowTo). > > > > Ryan > > > > *From:* NANOG *On Behalf Of *Mike Hammett > *Sent:* Friday, August 17, 2018 1:51 PM > *To:* nanog at nanog.org list > *Subject:* Web UI DHCP Option 82 > > > > Are there any web interfaces out there for DHCP servers that accommodate > management of DHCP option 82 configs? Neither webmin nor Glass seem to > handle ISC's agent.circuit-id outside of presenting the raw config file. I > can do that just fine in nano, but I'm looking at something more > user-friendly so I'm not the only one that can work on it. > > I'm also cheap, so not looking at Infoblox or anything like that. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spike at zitomedia.net Sun Aug 19 13:30:10 2018 From: spike at zitomedia.net (daveb) Date: Sun, 19 Aug 2018 09:30:10 -0400 Subject: Web UI DHCP Option 82 In-Reply-To: References: <33165605.6591.1534538778037.JavaMail.mhammett@ThunderFuck> <1799393681.6601.1534539034280.JavaMail.mhammett@ThunderFuck> <582d40b61df94023846f26bbbf6c85c7@MIA-MBX01.quadranet.local> Message-ID: <5b7970e3.1c69fb81.78160.78b0SMTPIN_ADDED_MISSING@mx.google.com> There's no GUI but I'll second the Kea recommendation. At 09:36 AM 8/18/2018, Colton Conor wrote: >Mike, I am looking for the same thing. Does >Mikrotik have the ability to do what you are requesting? > >On Fri, Aug 17, 2018 at 5:11 PM Ryan Hamel ><Ryan.Hamel at quadranet.com> wrote: > >Mike, > >Take a look into Kea from ISC. The config is >JSON based, which allows for nearly any >scripting language to make changes, or you can >dig into how it works with MySQL for dynamic >operation >(https://kea.isc.org/wiki/HostReservationsHowTo). > > > >Ryan > > > >From: NANOG ><nanog-bounces at nanog.org> >On Behalf Of Mike Hammett >Sent: Friday, August 17, 2018 1:51 PM >To: nanog at nanog.org list ><nanog at nanog.org> >Subject: Web UI DHCP Option 82 > > > >Are there any web interfaces out there for DHCP >servers that accommodate management of DHCP >option 82 configs? Neither webmin nor Glass seem >to handle ISC's agent.circuit-id outside of >presenting the raw config file. I can do that >just fine in nano, but I'm looking at something >more user-friendly so I'm not the only one that can work on it. > >I'm also cheap, so not looking at Infoblox or anything like that. > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com From Ryan.Hamel at quadranet.com Sun Aug 19 18:18:45 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Sun, 19 Aug 2018 18:18:45 +0000 Subject: Web UI DHCP Option 82 In-Reply-To: <5b7970e3.1c69fb81.78160.78b0SMTPIN_ADDED_MISSING@mx.google.com> References: <33165605.6591.1534538778037.JavaMail.mhammett@ThunderFuck> <1799393681.6601.1534539034280.JavaMail.mhammett@ThunderFuck> <582d40b61df94023846f26bbbf6c85c7@MIA-MBX01.quadranet.local> <5b7970e3.1c69fb81.78160.78b0SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <2ada019682ad4a9cb6cb8230cbf6d7ce@MIA-MBX01.quadranet.local> I just had a brain fart a moment ago, PHPMyAdmin is an option if you want to create a number of MySQL users that have access to the same table. -----Original Message----- From: NANOG On Behalf Of daveb Sent: Sunday, August 19, 2018 6:30 AM To: NANOG Subject: Re: Web UI DHCP Option 82 There's no GUI but I'll second the Kea recommendation. At 09:36 AM 8/18/2018, Colton Conor wrote: >Mike, I am looking for the same thing. Does Mikrotik have the ability >to do what you are requesting? > >On Fri, Aug 17, 2018 at 5:11 PM Ryan Hamel ><Ryan.Hamel at quadranet.com> wrote: > >Mike, > >Take a look into Kea from ISC. The config is JSON based, which allows >for nearly any scripting language to make changes, or you can dig into >how it works with MySQL for dynamic operation >(https://kea.isc.org/wiki/HostReservationsHowTo). > > > >Ryan > > > >From: NANOG ><nanog-bounces at nanog.org> >On Behalf Of Mike Hammett >Sent: Friday, August 17, 2018 1:51 PM >To: nanog at nanog.org list ><nanog at nanog.org> >Subject: Web UI DHCP Option 82 > > > >Are there any web interfaces out there for DHCP servers that >accommodate management of DHCP option 82 configs? Neither webmin nor >Glass seem to handle ISC's agent.circuit-id outside of presenting the >raw config file. I can do that just fine in nano, but I'm looking at >something more user-friendly so I'm not the only one that can work on >it. > >I'm also cheap, so not looking at Infoblox or anything like that. > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com From niels=nanog at bakker.net Sun Aug 19 20:32:51 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Sun, 19 Aug 2018 22:32:51 +0200 Subject: tcp md5 bgp attacks? In-Reply-To: References: <9cbc76f3-06b6-c399-fcff-e19121153381@bogus.com> Message-ID: <20180819203251.GD9970@jima.tpb.net> * randy at psg.com (Randy Bush) [Wed 15 Aug 2018, 04:27 CEST]: >my memory is that seq num guessing and sending rst was the core >problem motivating tcp/md5 for bgp, and btsh came some years later. >but no big deal. And a few looking glasses exposed detailed TCP window information when run against certain hardware vendors' routers, making that very easy. -- Niels. From benno at NLnetLabs.nl Mon Aug 20 15:09:47 2018 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Mon, 20 Aug 2018 17:09:47 +0200 Subject: 2nd call for presentations RIPE 77 Message-ID: <98a49515-8b61-b6ce-5419-457c3464960b@NLnetLabs.nl> Dear colleagues, Please note the approaching deadline of *26 August 2018* for RIPE 77 plenary programme submissions. You can find the CFP for RIPE 77 below or at https://ripe77.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, see the "Speakers" paragraph in CFP for more information. Kind regards, Benno Overeinder RIPE PC Chair https://ripe77.ripe.net/ripe-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 77 will take place from 15-19 October in Amsterdam, The Netherlands* 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 77. See the full descriptions of the different presentation formats: https://ripe77.ripe.net/submit-topic/presentation-formats/ Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *26 August 2018*. Proposals submitted after this date will be considered depending on the slots still available in the programme. The PC is looking for presentations covering the topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) ---- Speakers ---- Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc at ripe.net. Also note that, on an individual basis, participants can apply for a RIPE Fellowship or RACI to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship https://www.ripe.net/participate/ripe/raci ---- Submissions ---- Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe77.ripe.net/plenary-or-wg/ 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 should 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 (during evening sessions) - Lightning talks: 10 minutes in total for both the presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe77.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe77.ripe.net/submit-topic/) 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. ---- Diversity and Inclusion - On-Site Childcare and the RIPE Meeting Code of Conduct ---- Did you know that RIPE Meetings now have on-site childcare? You can reserve a spot for your child (age 6 months – 10 years) during the registration process for the meeting. Registrations for RIPE 77 will open mid-July. Childcare places are limited, so please be quick to reserve a spot for your child! Read about the experiences of our next generation of engineers at: https://labs.ripe.net/Members/agowland/ripe-meeting-diversity-efforts-on-site-childcare-at-ripe-76 Ensuring that RIPE Meeting values are upheld and that attendees experience a professional, respectful and safe meeting is a priority. Please do read the RIPE Meeting Code of Conduct: https://www.ripe.net/participate/meetings/ripe-meetings/ripe-meeting-code-of-conduct --- If you have any questions or requests concerning content submissions, please email pc at ripe.net. From garrett at skjelstad.org Sun Aug 19 21:36:34 2018 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Sun, 19 Aug 2018 14:36:34 -0700 Subject: tcp md5 bgp attacks? In-Reply-To: References: Message-ID: Nah, they aren't asking about the other things, and only the order of operations which vary per vendor will matter. If I am reading correctly, they aren't asking about only successful MD5 attacks, but MD5 attacks in general. All the rest of your listed security configurations would be 'extra' router demographics. -Garrett On Wed, Aug 15, 2018, 06:43 Lotia, Pratik M wrote: > Just to point out - > Data about md5 attacks from various organizations will depend on a number > of factors such as - > Is BGP TTL Security check being done? > Are anti-spoofing ACLs enabled? > uRPF enabled? Strict or Loose? > BGP Session over a separate interface (tunnel)? > > > > With Gratitude, > > > Pratik Lotia | Security Engineer | Advanced Engineering Security > Charter Communications > > "A satisfied customer is the best business strategy of all." > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush > Sent: Tuesday, August 14, 2018 3:39 PM > To: North American Network Operators' Group > Subject: tcp md5 bgp attacks? > > so we started to wonder if, since we started protecting our bgp > sessions with md5 (in the 1990s), are there still folk trying to > attack? > > we were unable to find bgp mib counters. there are igp interface > counters, but that was not our immediate interest. we did find > that md5 failures are logged. > > looking at my logs for a few years, i find essentially nothing; > two 'attackers,' one my own ibgp peer, and one that noted evildoer > rob thomas, bgprs01.ord08.cymru.com. > > we would be interested in data from others. > > note that we are neither contemplating nor suggesting removing md5 > from [y]our bgp sessions. > > randy > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended > solely for the addressee(s) and may contain confidential and/or legally > privileged information. If you are not the intended recipient of this > message or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message > and any attachments. If you are not the intended recipient, you are > notified that any use, dissemination, distribution, copying, or storage of > this message or any attachment is strictly prohibited. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at antiphase.net Mon Aug 20 17:05:09 2018 From: nanog at antiphase.net (Anthony Newman) Date: Mon, 20 Aug 2018 10:05:09 -0700 Subject: Web UI DHCP Option 82 In-Reply-To: <2ada019682ad4a9cb6cb8230cbf6d7ce@MIA-MBX01.quadranet.local> References: <33165605.6591.1534538778037.JavaMail.mhammett@ThunderFuck> <1799393681.6601.1534539034280.JavaMail.mhammett@ThunderFuck> <582d40b61df94023846f26bbbf6c85c7@MIA-MBX01.quadranet.local> <5b7970e3.1c69fb81.78160.78b0SMTPIN_ADDED_MISSING@mx.google.com> <2ada019682ad4a9cb6cb8230cbf6d7ce@MIA-MBX01.quadranet.local> Message-ID: <3ac78363-8db2-6ab0-f5d3-7d9bc5ba677f@antiphase.net> On 2018-08-19 11:18 AM, Ryan Hamel wrote: > I just had a brain fart a moment ago, PHPMyAdmin is an option if you want to create a number of MySQL users that have access to the same table. Sysadmins hate this one simple trick! From dwhite at olp.net Tue Aug 21 14:13:51 2018 From: dwhite at olp.net (Dan White) Date: Tue, 21 Aug 2018 09:13:51 -0500 Subject: DirecTV Now Geolocation Contact Message-ID: <20180821141351.GA28252@dan.olp.net> Are there any DirecTV Now contacts on-list? We are having geolocation trouble with a well established ip range. -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at mybtc.com http://www.btcbroadband.com From blake at ispn.net Tue Aug 21 15:40:53 2018 From: blake at ispn.net (Blake Hudson) Date: Tue, 21 Aug 2018 10:40:53 -0500 Subject: DirecTV Now Geolocation Contact In-Reply-To: <20180821141351.GA28252@dan.olp.net> References: <20180821141351.GA28252@dan.olp.net> Message-ID: Hey Dan, just an FYI we had a client indicate issues with previously working DirecTV service suddenly stop working last month because DirecTV was geolocating their customer to the wrong state. There was some errant whois information likely to blame for this, but the WHOIS information had been unchanged for years. Seems like DirecTV may have changed their geolocation provider or their granularity (locating to city or state  level rather than country/region). --Blake Dan White wrote on 8/21/2018 9:13 AM: > Are there any DirecTV Now contacts on-list? We are having geolocation > trouble with a well established ip range. > From darin.steffl at mnwifi.com Tue Aug 21 23:48:56 2018 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Tue, 21 Aug 2018 18:48:56 -0500 Subject: DirecTV Now Geolocation Contact In-Reply-To: References: <20180821141351.GA28252@dan.olp.net> Message-ID: We heard from a customer that it was working great then their locals stopped working because Directv said they were out of market. Of course we didn't change anything and it was normal on our end. Since it's not our service and everything except their locals was working, we told them to escalate to Directv and we haven't heard back. Not sure if it's fixed or not. On Tue, Aug 21, 2018, 10:42 AM Blake Hudson wrote: > Hey Dan, just an FYI we had a client indicate issues with previously > working DirecTV service suddenly stop working last month because DirecTV > was geolocating their customer to the wrong state. There was some errant > whois information likely to blame for this, but the WHOIS information > had been unchanged for years. Seems like DirecTV may have changed their > geolocation provider or their granularity (locating to city or state > level rather than country/region). > > --Blake > > Dan White wrote on 8/21/2018 9:13 AM: > > Are there any DirecTV Now contacts on-list? We are having geolocation > > trouble with a well established ip range. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome at ceriz.fr Wed Aug 22 10:32:57 2018 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Wed, 22 Aug 2018 12:32:57 +0200 Subject: optical circulator as a bidirectional one fiber solution In-Reply-To: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> References: <7e624de3-5e18-010f-4ca5-bcf68d727119@gmail.com> Message-ID: <1c45180c-e19f-d955-9c29-1fea16aae373@ceriz.fr> Hi Baldur, Le 07/08/2018 à 21:46, Baldur Norddahl a écrit : > Would it be possible to use an optical circulator like this one > (customized to 1310 nm)? > > Has anyone done this? Any reason it would not work? While it often does work, reflectance is a bitch. I'd advise you to order some attenuators to plug on RX ports in case the ghost signal is too high. Of course, you should use APC connectors all along the optical path. Also bear in mind that circulators have a narrow spectrum range (likely 1280-1340 in your case, good for 100G-LR4/ER4, but not for 100G-CWDM4) and are rarely polarization neutral, meaning a DP-QPSK coherent optic cannot be used. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From sean at donelan.com Wed Aug 22 13:50:46 2018 From: sean at donelan.com (Sean Donelan) Date: Wed, 22 Aug 2018 09:50:46 -0400 (EDT) Subject: Hurricane Lane: Catagory 5 storm forecast to sideswipe Hawaii Message-ID: Hurricane warnings have been issued for Hurricane Lane, which strengthened to a catagory 5 storm on Tuesday. The forecast cone of uncertainity shows the path sideswiping Hawaii on Thursday. From ingrid at ripe.net Tue Aug 21 11:34:53 2018 From: ingrid at ripe.net (Ingrid Wijte) Date: Tue, 21 Aug 2018 13:34:53 +0200 Subject: New AS Number Block allocated to the RIPE NCC Message-ID: Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA on 20 August 2018: 207260-208283 208284-209307 209308-210331 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager and Policy Development RIPE NCC From ratul at ratul.org Wed Aug 22 03:25:42 2018 From: ratul at ratul.org (Ratul Mahajan) Date: Tue, 21 Aug 2018 20:25:42 -0700 Subject: Pybatfish - Open source network validation SDK Message-ID: Hey, folks - Since many of you build and use tools for network validation, I wanted to share a quick announcement. We just released Pybatfish , a Python SDK for Batfish. As you may know, Batfish is an open source framework for deep (semantic) validation in multi-vendor networks (which we presented at NANOG65 ). Pybatfish will make it easy for you to leverage the power of Batfish and to embed validation in your testing/automation pipeline. Getting started is easy: Check out the Jupyter notebooks on our github page (or corresponding videos ), or ping us on Slack . Cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saymon at online.net.br Wed Aug 22 13:22:36 2018 From: saymon at online.net.br (=?UTF-8?Q?Saymon_Ara=C3=BAjo?=) Date: Wed, 22 Aug 2018 10:22:36 -0300 Subject: NANOG Digest, Vol 127, Issue 16 In-Reply-To: References: Message-ID: - PRTG, it's realy easy to configure. Most of the senssors are SNMP of: traffic/ping/cpu/memory and some senssors for servers like DNS and Radius, etc. - Zabbix, there's 2 things that made us use Zabbix, the first one it's Zabbix Proxy, since the network it's geographical distribuited we need a tool that provides us monitoring from another places with a low price. And LLD that i use for monitoring BGP/OSPF sessions and prefix. - Elastiflow - For Syslog we use Graylog, that i recomend, it's a excelente tool for monitoring syslog messages and there's a lot of features such as extractors, streams and alerts. I think that PRTG it's kind expensive solution ( if you buy the license ), but provides a easy way to monitor a lot of things. Just one thing, if your license expires your are no able to update your software and if you want to buy the license for upgrade, the days without the license counts as negative days, i never seen that before, like, if you don't update the license for 1 year and bought the 3 years lisence, you will got 2 years of support and upgrade. Atenciosamente, Em sex, 17 de ago de 2018 às 09:00, escreveu: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: What NMS do you use and why? (Nick Peelman) > 2. Re: What NMS do you use and why? (Joe Loiacono) > 3. RE: What NMS do you use and why? (Stan Ouchakov) > 4. Re: What NMS do you use and why? (Nick Peelman) > 5. Re: What NMS do you use and why? (Kushal) > 6. RE: What NMS do you use and why? (Michael Braun (michbrau)) > 7. Re: What NMS do you use and why? (Nick W) > 8. Akamia Contact (Romeo Czumbil) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Aug 2018 23:14:32 +0000 > From: Nick Peelman > To: Colton Conor > Cc: NANOG > Subject: Re: What NMS do you use and why? > Message-ID: > Content-Type: text/plain; charset="Windows-1252" > > I think anybody looking for a be-all-end-all solution will find nothing > but heartburn. > > different suites have different strong suits, and deciding you are going > to pursue one and ignore all others may mean living without a feature or > set of features you may find really useful or eventually necessary. but > maintaining multiple complete NMSes isn’t really tenable either. > > all of that said, we use a combination of a couple. Nagios/Icinga because > it’s been around forever (both in the world and in our network), and the > power of script based checks, being able to write your own handlers and > pretty much just leverage it as a framework you can shove questions into > and get regular answers from is invaluable. > > LibreNMS gives us the best pretty pictures, letting us monitor much much > more than just interface traffic, out of the box. much more than cacti is > capable of without a ton of work (i.e. down to the tx/rx power and > temperature readings of individual SFPs). it scales relatively well; at > least in theory. i will be able to tell you for sure later this year as we > are near the limits of what we can monitor with a single polling device. > alerting out of Libre into Slack has proven quite fantastic. we can spawn > threads attached to anything from a BGP peer dropping or a CPU alert as we > move to triage and solve, even if we are in the field or meetings or > whatever. > > we also still have cacti around for random one-offs. as great as Libre is, > its poller can be a bit intense for some devices; so in those cases it’s > safer for us to just have cacti graph the one or two OIDs we need > specifically, without trolling all the other available sensors. > > we ran OpenNMS for a bit, but it proved way to dumb to maintain a large > (and growing) complex network, without dedicating at least one or two > people to the care and feeding of it. > > -nick > > — > Nick Peelman > Network Engineer | Enhanced Telecommunications Corp. > 812-222-0169 | npeelman at etc1.net npeelman at etc1.net> | www.etczone.com > > Sent from my iPhone > > On Aug 15, 2018, at 09:49, Colton Conor colton.conor at gmail.com>> wrote: > > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use and > why? Is there one that you really like, and others that you hate? > > For free options (opensouce), LibreNMS and NetXMS come highly recommended > by many wireless ISPs on low budgets. However, I am not sure the commercial > options available nor their price points. > > > > > ------------------------------ > > Message: 2 > Date: Wed, 15 Aug 2018 20:31:13 -0400 (EDT) > From: Joe Loiacono > To: William Herrin > Cc: NANOG , Colton Conor > Subject: Re: What NMS do you use and why? > Message-ID: > <593335944.184.1534379472982.JavaMail.jloia at DESKTOP-FDMC6S8> > Content-Type: text/plain; charset=utf-8 > > Consider also open-source FlowViewer for netflow capture and analysis. A > lot of very useful netflow based analytical tools in an easy UI. Sits on > top of a robust set of Carnegie-Mellon's high-capacity SiLK netflow tools. > > https://sourceforge.net/projects/flowviewer/ > > Joe > > > > ----- Original Message ----- > From: "William Herrin" > To: "Colton Conor" > Cc: "NANOG" > Sent: Wednesday, August 15, 2018 3:25:48 PM > Subject: Re: What NMS do you use and why? > > On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor > wrote: > > We are looking for a new network monitoring system. Since there are so > many > > operators on this list, I would like to know which NMS do you use and > why? > > Is there one that you really like, and others that you hate? > > I still use a tool I wrote in perl nearly 20 years ago called > "MrPing." MrPing handles multi-dependency graphs. > > Consider: > > A is reachable via either B or C. > > If A and B are down but C is up, A being down is a separate failure > from B being down. I need to know about both. > > If B and C are both down, A is unreachable. I don't want to receive > alerts about A because they'll distract me from the root cause of the > problem: that both B and C are down. The NMS should record that A is > unreachable but it should also tell me that A being unreachable is a > dependent failure that I can ignore until I fix the failures it > depends on. > > > The NMSes I've paid attention to either don't support dependencies > well at all or support only simple hierarchical dependencies. > Resilient, professional networks simply aren't built that way. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > > > ------------------------------ > > Message: 3 > Date: Thu, 16 Aug 2018 15:39:52 +0000 > From: Stan Ouchakov > To: Joe Loiacono , William Herrin > Cc: NANOG > Subject: RE: What NMS do you use and why? > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Regarding netflow/sflow/ipfix monitoring, we had recently started using > elastiflow by Robert Cowart. Scales very well with pretty visualizations. > Cannot imagine what paid / supported version has to offer :) > > https://github.com/robcowart/elastiflow > > > > -----Original Message----- > From: NANOG On Behalf Of Joe Loiacono > Sent: Wednesday, August 15, 2018 8:31 PM > To: William Herrin > Cc: NANOG > Subject: Re: What NMS do you use and why? > > Consider also open-source FlowViewer for netflow capture and analysis. A > lot of very useful netflow based analytical tools in an easy UI. Sits on > top of a robust set of Carnegie-Mellon's high-capacity SiLK netflow tools. > > https://sourceforge.net/projects/flowviewer/ > > Joe > > > > ----- Original Message ----- > From: "William Herrin" > To: "Colton Conor" > Cc: "NANOG" > Sent: Wednesday, August 15, 2018 3:25:48 PM > Subject: Re: What NMS do you use and why? > > On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor > wrote: > > We are looking for a new network monitoring system. Since there are so > > many operators on this list, I would like to know which NMS do you use > and why? > > Is there one that you really like, and others that you hate? > > I still use a tool I wrote in perl nearly 20 years ago called "MrPing." > MrPing handles multi-dependency graphs. > > Consider: > > A is reachable via either B or C. > > If A and B are down but C is up, A being down is a separate failure from B > being down. I need to know about both. > > If B and C are both down, A is unreachable. I don't want to receive alerts > about A because they'll distract me from the root cause of the > problem: that both B and C are down. The NMS should record that A is > unreachable but it should also tell me that A being unreachable is a > dependent failure that I can ignore until I fix the failures it depends on. > > > The NMSes I've paid attention to either don't support dependencies well at > all or support only simple hierarchical dependencies. > Resilient, professional networks simply aren't built that way. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > > ------------------------------ > > Message: 4 > Date: Thu, 16 Aug 2018 15:42:44 +0000 > From: Nick Peelman > To: Stan Ouchakov > Cc: Joe Loiacono , William Herrin > , NANOG > Subject: Re: What NMS do you use and why? > Message-ID: <61BD4D17-F5EB-46AC-BEE2-5D289FECDDBD at ETC1.net> > Content-Type: text/plain; charset="Windows-1252" > > seconded. the pains of maintaining ELK are made worthwhile by this alone. > > -nick > > — > Nick Peelman > Network Engineer | Enhanced Telecommunications Corp. > 812-222-0169 | npeelman at etc1.net npeelman at etc1.net> | www.etczone.com > > Sent from my iPhone > > On Aug 16, 2018, at 11:41, Stan Ouchakov > wrote: > > Regarding netflow/sflow/ipfix monitoring, we had recently started using > elastiflow by Robert Cowart. Scales very well with pretty visualizations. > Cannot imagine what paid / supported version has to offer :) > > https://github.com/robcowart/elastiflow > > > > -----Original Message----- > From: NANOG > On > Behalf Of Joe Loiacono > Sent: Wednesday, August 15, 2018 8:31 PM > To: William Herrin > > Cc: NANOG > > Subject: Re: What NMS do you use and why? > > Consider also open-source FlowViewer for netflow capture and analysis. A > lot of very useful netflow based analytical tools in an easy UI. Sits on > top of a robust set of Carnegie-Mellon's high-capacity SiLK netflow tools. > > https://sourceforge.net/projects/flowviewer/ > > Joe > > > > ----- Original Message ----- > From: "William Herrin" > > To: "Colton Conor" > > Cc: "NANOG" > > Sent: Wednesday, August 15, 2018 3:25:48 PM > Subject: Re: What NMS do you use and why? > > On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor > wrote: > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use and > why? > Is there one that you really like, and others that you hate? > > I still use a tool I wrote in perl nearly 20 years ago called "MrPing." > MrPing handles multi-dependency graphs. > > Consider: > > A is reachable via either B or C. > > If A and B are down but C is up, A being down is a separate failure from B > being down. I need to know about both. > > If B and C are both down, A is unreachable. I don't want to receive alerts > about A because they'll distract me from the root cause of the > problem: that both B and C are down. The NMS should record that A is > unreachable but it should also tell me that A being unreachable is a > dependent failure that I can ignore until I fix the failures it depends on. > > > The NMSes I've paid attention to either don't support dependencies well at > all or support only simple hierarchical dependencies. > Resilient, professional networks simply aren't built that way. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com herrin at dirtside.com> bill at herrin.us Dirtside > Systems ......... Web: > > > ------------------------------ > > Message: 5 > Date: Thu, 16 Aug 2018 22:19:35 +0530 > From: Kushal > To: Stan Ouchakov , Nick Peelman > > Cc: NANOG > Subject: Re: What NMS do you use and why? > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Being a small business we like to use a mostly free and open source tools. > Our networking monitoring stack presently looks like: > > Simple Reachability Monitoring (Ping) - uptimerobot.com > > Just $4.5 per month for 50 monitors with 1 minute intervals (free if you > are find with 5 minutes monitoring intervals). This is connected to our > slack channel and also sends SMS when something goes offline. > > Traffic & Device Monitoring - LibreNMS > > A fork of Observium but adds the much needed alerting feature that > observing only offers with it's paid plans. We use it to monitor switch > port traffic, BGP sessions, device health, etc. > > Packet Inspection or Flow Monitoring we use FastNetMon ( > https://fastnetmon.com/features/) the free edition is good for our needs. > > > On August 16, 2018 at 9:16:42 PM, Nick Peelman (npeelman at etc1.net) wrote: > > seconded. the pains of maintaining ELK are made worthwhile by this alone. > > -nick > > — > Nick Peelman > Network Engineer | Enhanced Telecommunications Corp. > 812-222-0169 | npeelman at etc1.net npeelman at etc1.net> | www.etczone.com > > Sent from my iPhone > > On Aug 16, 2018, at 11:41, Stan Ouchakov > wrote: > > Regarding netflow/sflow/ipfix monitoring, we had recently started using > elastiflow by Robert Cowart. Scales very well with pretty visualizations. > Cannot imagine what paid / supported version has to offer :) > > https://github.com/robcowart/elastiflow > > > > -----Original Message----- > From: NANOG > On > Behalf Of Joe Loiacono > Sent: Wednesday, August 15, 2018 8:31 PM > To: William Herrin > > Cc: NANOG > > Subject: Re: What NMS do you use and why? > > Consider also open-source FlowViewer for netflow capture and analysis. A > lot of very useful netflow based analytical tools in an easy UI. Sits on > top of a robust set of Carnegie-Mellon's high-capacity SiLK netflow tools. > > https://sourceforge.net/projects/flowviewer/ > > Joe > > > > ----- Original Message ----- > From: "William Herrin" > > To: "Colton Conor" > > > Cc: "NANOG" > > Sent: Wednesday, August 15, 2018 3:25:48 PM > Subject: Re: What NMS do you use and why? > > On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor > wrote: > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use and > why? > Is there one that you really like, and others that you hate? > > I still use a tool I wrote in perl nearly 20 years ago called "MrPing." > MrPing handles multi-dependency graphs. > > Consider: > > A is reachable via either B or C. > > If A and B are down but C is up, A being down is a separate failure from B > being down. I need to know about both. > > If B and C are both down, A is unreachable. I don't want to receive alerts > about A because they'll distract me from the root cause of the > problem: that both B and C are down. The NMS should record that A is > unreachable but it should also tell me that A being unreachable is a > dependent failure that I can ignore until I fix the failures it depends > on. > > > The NMSes I've paid attention to either don't support dependencies well at > all or support only simple hierarchical dependencies. > Resilient, professional networks simply aren't built that way. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com herrin at dirtside.com> bill at herrin.us Dirtside > Systems ......... Web: > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20180816/f9dcbdea/attachment-0001.html > > > > ------------------------------ > > Message: 6 > Date: Thu, 16 Aug 2018 18:23:47 +0000 > From: "Michael Braun (michbrau)" > To: NANOG > Subject: RE: What NMS do you use and why? > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > As open source tools go, Smokeping is a great tool to add to your NMS > arsenal: > > https://oss.oetiker.ch/smokeping/ > > Mike > > > On Wed, Aug 15, 2018 at 9:49 AM, Colton Conor > wrote: > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use and > why? > Is there one that you really like, and others that you hate? > > I still use a tool I wrote in perl nearly 20 years ago called "MrPing." > MrPing handles multi-dependency graphs. > > > > > ------------------------------ > > Message: 7 > Date: Thu, 16 Aug 2018 16:53:43 -0400 > From: Nick W > Cc: nanog at nanog.org > Subject: Re: What NMS do you use and why? > Message-ID: > < > CAJg9_Yyj2cciS22oqV233A6hTW5pBbtOwGWBK0pE-OUKfYk3Kg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > LibreNMS + Weathermap for graphs, real-time, and alerting. Vaping for a > simple Up/Degraded/Down dashboard (great replacement for > Multiping/PingPlotter on a TV). Elastiflow for netflow. > > I really really want to like OpenNMS, and would love to use it daily; I > feel like it could handle many integrations well, but have never had the > time to dedicate to fully diving into it. I have used it in the past for > small setups (monitoring ~100 remotely managed routers/firewall) and it did > well, after getting past some learning curves. I keep coming back to it > every 6 months or so and trying the latest version. > > On Wed, Aug 15, 2018 at 9:51 AM Colton Conor > wrote: > > > We are looking for a new network monitoring system. Since there are so > > many operators on this list, I would like to know which NMS do you use > and > > why? Is there one that you really like, and others that you hate? > > > > For free options (opensouce), LibreNMS and NetXMS come highly recommended > > by many wireless ISPs on low budgets. However, I am not sure the > commercial > > options available nor their price points. > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20180816/0860ca34/attachment-0001.html > > > > ------------------------------ > > Message: 8 > Date: Fri, 17 Aug 2018 00:40:24 +0000 > From: Romeo Czumbil > To: "nanog at nanog.org" > Subject: Akamia Contact > Message-ID: > <41e12b5cbbf540028a969c4fa2119c62 at dal01-ex01.tierpoint.net> > Content-Type: text/plain; charset="us-ascii" > > Can somebody from Akamia Network Engineering contact me off-list > > Thank you > > > End of NANOG Digest, Vol 127, Issue 16 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Wed Aug 22 16:55:50 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 22 Aug 2018 09:55:50 -0700 Subject: Hurricane Lane: Catagory 5 storm forecast to sideswipe Hawaii Message-ID: <20180822095550.5E09FA0A@m0117458.ppops.net> --- sean at donelan.com wrote: From: Sean Donelan Hurricane warnings have been issued for Hurricane Lane, which strengthened to a catagory 5 storm on Tuesday. The forecast cone of uncertainity shows the path sideswiping Hawaii on Thursday. ------------------------------------------- Yep, this one's closer than the other 2-3 weeks ago. I thought about sending another 'dust off your DR plan' for those networks doing business in the AP region that have stuff here, but if they didn't on the last one they wouldn't on this one, either. :-) It's an M (>110 MPH) until the Big Island on Thur and then goes down to a regular hurricane Friday when it hits Maui and Oahu Friday. http://www.prh.noaa.gov/cphc/tcpages/?product=5day_cone_with_line_and_wind&stormid=EP142018 http://weather.hawaii.edu/satellite/jsanim.cgi?res=4km&chnl=ir&domain=nep&period=720&incr=30&rr=900&banner=uhmet&satplat=goeswest&overlay=off scott From lists at mtin.net Thu Aug 23 17:14:58 2018 From: lists at mtin.net (Justin Wilson) Date: Thu, 23 Aug 2018 13:14:58 -0400 Subject: IPv6 Management Message-ID: We were having an interesting debate on IPV6 management on layer2 devices. Does anyone have a best practice document they have seen for utilizing v6 Management addresses? I know Cisco has some extensive documentation on using v6 on their wireless products. I know everyone has thoughts so am interested in any best practices which have been presented to the community. I haven’t worried about management access on layer2 devices, as long as the layer2 devices can pass any cast, multicast, and other things v6 needs. However, I could see why you would want v6 management addresses. And go…. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Aug 23 18:54:23 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Aug 2018 11:54:23 -0700 Subject: IPv6 Management In-Reply-To: References: Message-ID: <0235F935-F68B-4B1D-9799-A5E34A20C0E2@delong.com> I don’t see much difference between v6 management addresses and v4 management addresses when it comes to best practices. I will say that if it were my network, I’d move everything internal-only that I could to IPv6 as quickly as possible, freeing up those v4 addresses for other purposes (or if GUA, possibly monetization while they’re still valuable). Once you’ve got the ability to use IPv6 management addresses, what’s the point of maintaining legacy IPv4 management infrastructure? It’s just an albatross of dead weight hanging around the neck of your network. Owen > On Aug 23, 2018, at 10:14 , Justin Wilson wrote: > > We were having an interesting debate on IPV6 management on layer2 devices. Does anyone have a best practice document they have seen for utilizing v6 Management addresses? I know Cisco has some extensive documentation on using v6 on their wireless products. > > I know everyone has thoughts so am interested in any best practices which have been presented to the community. I haven’t worried about management access on layer2 devices, as long as the layer2 devices can pass any cast, multicast, and other things v6 needs. However, I could see why you would want v6 management addresses. > > And go…. > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at finnesey.com Fri Aug 24 13:47:05 2018 From: ryan at finnesey.com (Ryan Finnesey) Date: Fri, 24 Aug 2018 13:47:05 +0000 Subject: Microsoft - list of Azure DNS servers Message-ID: I am looking for someone from Microsoft to contact me off list. I am looking for a complete list of Azure DNS servers. Cheers Ryan From blake at ispn.net Fri Aug 24 15:14:53 2018 From: blake at ispn.net (Blake Hudson) Date: Fri, 24 Aug 2018 10:14:53 -0500 Subject: IPv6 Management In-Reply-To: <0235F935-F68B-4B1D-9799-A5E34A20C0E2@delong.com> References: <0235F935-F68B-4B1D-9799-A5E34A20C0E2@delong.com> Message-ID: <8e798f4d-8a90-33f0-75a9-fccf5414d532@ispn.net> Agreed, lots of (relatively) old switches support IPv6 management addresses without issue. My suggestion is to dedicate a nibble in your IPv6 numbering plan for loopbacks/mgmt addresses, firewall access to this nibble as necessary, and go to town. Owen DeLong wrote on 8/23/2018 1:54 PM: > I don’t see much difference between v6 management addresses and v4 > management addresses when it comes to best practices. > > I will say that if it were my network, I’d move everything > internal-only that I could to IPv6 as quickly as possible, freeing up > those v4 addresses > for other purposes (or if GUA, possibly monetization while they’re > still valuable). > > Once you’ve got the ability to use IPv6 management addresses, what’s > the point of maintaining legacy IPv4 management infrastructure? It’s > just an albatross of dead weight hanging around the neck of your network. > > Owen > > >> On Aug 23, 2018, at 10:14 , Justin Wilson > > wrote: >> >> We were having an interesting debate on IPV6 management on layer2 >> devices.  Does anyone have a best practice document they have seen >> for utilizing v6 Management addresses? I know Cisco has some >> extensive documentation on using v6 on their wireless products. >> >> I know everyone has thoughts so am interested in any best practices >> which have been presented to the community.  I haven’t worried about >> management access on layer2 devices, as long as the layer2 devices >> can pass any cast, multicast, and other things v6 needs.  However, I >> could see why you would want v6 management addresses. >> >> And go…. >> >> >> Justin Wilson >> j2sw at mtin.net >> >> www.mtin.net >> www.midwest-ix.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sob at academ.com Thu Aug 23 20:19:01 2018 From: sob at academ.com (Stan Barber) Date: Thu, 23 Aug 2018 13:19:01 -0700 Subject: IPv6 Management In-Reply-To: <0235F935-F68B-4B1D-9799-A5E34A20C0E2@delong.com> References: <0235F935-F68B-4B1D-9799-A5E34A20C0E2@delong.com> Message-ID: I am with Owen here. If the IPv6 management is working and reliable, maintaining the IPv4 management infrastructure should not be needed. Certainly, the ability to get to "working and reliable" is going to depend on a host of factors, but a good architecture and using best practices during the deployment of the IPv6 network will make it easier. On Thu, Aug 23, 2018 at 11:54 AM, Owen DeLong wrote: > I don’t see much difference between v6 management addresses and v4 > management addresses when it comes to best practices. > > I will say that if it were my network, I’d move everything internal-only > that I could to IPv6 as quickly as possible, freeing up those v4 addresses > for other purposes (or if GUA, possibly monetization while they’re still > valuable). > > Once you’ve got the ability to use IPv6 management addresses, what’s the > point of maintaining legacy IPv4 management infrastructure? It’s just an > albatross of dead weight hanging around the neck of your network. > > Owen > > > On Aug 23, 2018, at 10:14 , Justin Wilson wrote: > > We were having an interesting debate on IPV6 management on layer2 > devices. Does anyone have a best practice document they have seen for > utilizing v6 Management addresses? I know Cisco has some extensive > documentation on using v6 on their wireless products. > > I know everyone has thoughts so am interested in any best practices which > have been presented to the community. I haven’t worried about management > access on layer2 devices, as long as the layer2 devices can pass any cast, > multicast, and other things v6 needs. However, I could see why you would > want v6 management addresses. > > And go…. > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Aug 24 18:03:40 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Aug 2018 04:03:40 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180824180340.717CEC450F@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 25 Aug, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 711713 Prefixes after maximum aggregation (per Origin AS): 273276 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 341846 Total ASes present in the Internet Routing Table: 61612 Prefixes per ASN: 11.55 Origin-only ASes present in the Internet Routing Table: 53212 Origin ASes announcing only one prefix: 23205 Transit ASes present in the Internet Routing Table: 8400 Transit-only ASes present in the Internet Routing Table: 260 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 55 Number of instances of unregistered ASNs: 55 Number of 32-bit ASNs allocated by the RIRs: 23808 Number of 32-bit ASNs visible in the Routing Table: 19184 Prefixes from 32-bit ASNs in the Routing Table: 80326 Number of bogon 32-bit ASNs visible in the Routing Table: 20 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 272 Number of addresses announced to Internet: 2857455684 Equivalent to 170 /8s, 81 /16s and 80 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 237793 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 193767 Total APNIC prefixes after maximum aggregation: 55359 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 191973 Unique aggregates announced from the APNIC address blocks: 79241 APNIC Region origin ASes present in the Internet Routing Table: 9019 APNIC Prefixes per ASN: 21.29 APNIC Region origin ASes announcing only one prefix: 2534 APNIC Region transit ASes present in the Internet Routing Table: 1342 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3981 Number of APNIC addresses announced to Internet: 767386627 Equivalent to 45 /8s, 189 /16s and 100 /24s 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, 64297-64395, 131072-139577 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: 211629 Total ARIN prefixes after maximum aggregation: 100126 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 211412 Unique aggregates announced from the ARIN address blocks: 100195 ARIN Region origin ASes present in the Internet Routing Table: 18229 ARIN Prefixes per ASN: 11.60 ARIN Region origin ASes announcing only one prefix: 6758 ARIN Region transit ASes present in the Internet Routing Table: 1805 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2415 Number of ARIN addresses announced to Internet: 1103319200 Equivalent to 65 /8s, 195 /16s and 80 /24s 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-399260 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: 195094 Total RIPE prefixes after maximum aggregation: 93057 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 191399 Unique aggregates announced from the RIPE address blocks: 113352 RIPE Region origin ASes present in the Internet Routing Table: 25436 RIPE Prefixes per ASN: 7.52 RIPE Region origin ASes announcing only one prefix: 11467 RIPE Region transit ASes present in the Internet Routing Table: 3523 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7324 Number of RIPE addresses announced to Internet: 714069376 Equivalent to 42 /8s, 143 /16s and 213 /24s 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, 64396-64495 196608-210331 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: 91736 Total LACNIC prefixes after maximum aggregation: 20544 LACNIC Deaggregation factor: 4.47 Prefixes being announced from the LACNIC address blocks: 93193 Unique aggregates announced from the LACNIC address blocks: 40829 LACNIC Region origin ASes present in the Internet Routing Table: 7458 LACNIC Prefixes per ASN: 12.50 LACNIC Region origin ASes announcing only one prefix: 2060 LACNIC Region transit ASes present in the Internet Routing Table: 1398 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5006 Number of LACNIC addresses announced to Internet: 172006176 Equivalent to 10 /8s, 64 /16s and 155 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 19431 Total AfriNIC prefixes after maximum aggregation: 4143 AfriNIC Deaggregation factor: 4.69 Prefixes being announced from the AfriNIC address blocks: 23464 Unique aggregates announced from the AfriNIC address blocks: 7986 AfriNIC Region origin ASes present in the Internet Routing Table: 1183 AfriNIC Prefixes per ASN: 19.83 AfriNIC Region origin ASes announcing only one prefix: 386 AfriNIC Region transit ASes present in the Internet Routing Table: 235 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 458 Number of AfriNIC addresses announced to Internet: 100231168 Equivalent to 5 /8s, 249 /16s and 104 /24s 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 4681 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4421 478 471 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2989 1154 86 VIETEL-AS-AP Viettel Group, VN 4766 2825 11135 768 KIXS-AS-KR Korea Telecom, KR 9829 2813 1495 541 BSNL-NIB National Internet Backbone, IN 45899 2569 1638 157 VNPT-AS-VN VNPT Corp, VN 9394 2541 4907 32 CTTNET China TieTong Telecommunications 17974 2262 962 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2252 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2118 417 204 TATACOMM-AS TATA Communications formerl 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 6327 3448 1324 82 SHAW - Shaw Communications Inc., CA 11492 3268 253 411 CABLEONE - CABLE ONE, INC., US 22773 3228 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2271 4808 773 AMAZON-02 - Amazon.com, Inc., US 18566 2166 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2141 2652 505 CHARTER-NET-HKY-NC - Charter Communicat 209 2038 5085 604 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 2028 345 142 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 1995 1043 1463 AKAMAI-AS - Akamai Technologies, Inc., 7018 1774 20210 1283 ATT-INTERNET4 - AT&T Services, Inc., US 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 12479 4704 1613 125 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3099 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2546 615 1892 AKAMAI-ASN1, US 12389 2042 1893 732 ROSTELECOM-AS, RU 34984 2015 335 507 TELLCOM-AS, TR 9121 1821 1692 19 TTNET, TR 13188 1604 100 43 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1205 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 4884 3349 608 Uninet S.A. de C.V., MX 10620 3487 531 459 Telmex Colombia S.A., CO 11830 2657 369 78 Instituto Costarricense de Electricidad 6503 1665 444 63 Axtel, S.A.B. de C.V., MX 7303 1429 952 205 Telecom Argentina S.A., AR 28573 1084 2229 181 CLARO S.A., BR 3816 1022 510 117 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 929 126 85 Alestra, S. de R.L. de C.V., MX 18881 915 1080 32 TELEF�NICA BRASIL S.A, BR 6147 907 377 31 Telefonica del Peru S.A.A., PE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1184 396 48 LINKdotNET-AS, EG 37611 895 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 745 1411 40 ETISALAT-MISR, EG 24835 641 818 18 RAYA-AS, EG 8452 591 1728 14 TE-AS TE-AS, EG 37492 474 470 57 ORANGE-, TN 29571 463 70 13 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 375 231 15 MauritiusTelecom, MU 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 8151 4884 3349 608 Uninet S.A. de C.V., MX 12479 4704 1613 125 UNI2-AS, ES 4538 4681 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4421 478 471 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3487 531 459 Telmex Colombia S.A., CO 6327 3448 1324 82 SHAW - Shaw Communications Inc., CA 11492 3268 253 411 CABLEONE - CABLE ONE, INC., US 22773 3228 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3099 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4538 4681 4607 ERX-CERNET-BKB China Education and Research Net 12479 4704 4579 UNI2-AS, ES 7545 4421 3950 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3448 3366 SHAW - Shaw Communications Inc., CA 22773 3228 3079 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3099 3055 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 10620 3487 3028 Telmex Colombia S.A., CO 7552 2989 2903 VIETEL-AS-AP Viettel Group, VN 11492 3268 2857 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 64500 DOCUMENT 45.43.56.0/24 135391 AOFEI-HK AOFEI DATA INTERNATIO 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 4259905537 PRIVATE 103.250.48.0/24 132917 YELLOWPAGESGROUP-AS-AP Yellow Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 45.121.32.0/22 134356 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:14 /9:11 /10:36 /11:99 /12:291 /13:570 /14:1096 /15:1900 /16:13370 /17:7932 /18:13806 /19:25374 /20:39278 /21:45530 /22:88363 /23:71758 /24:400129 /25:799 /26:603 /27:624 /28:35 /29:20 /30:19 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3455 4704 UNI2-AS, ES 6327 3238 3448 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2623 3268 CABLEONE - CABLE ONE, INC., US 8551 2561 3099 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2497 3228 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2060 2166 MEGAPATH5-US - MegaPath Corporation, US 11830 2005 2657 Instituto Costarricense de Electricidad y Telec 30036 1780 2028 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1580 3487 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1616 2:827 4:18 5:2861 6:43 7:1 8:1125 12:1871 13:210 14:1796 15:32 16:3 17:191 18:54 20:51 23:2489 24:2341 25:2 27:2478 31:2012 32:88 35:29 36:522 37:2896 38:1495 39:257 40:118 41:3191 42:702 43:1975 44:120 45:5363 46:3116 47:199 49:1339 50:1054 51:318 52:1088 54:368 55:1 56:12 57:39 58:1629 59:992 60:406 61:2113 62:1870 63:1790 64:5078 65:2201 66:4716 67:2673 68:1147 69:3306 70:1157 71:582 72:2191 74:2724 75:416 76:464 77:1650 78:1690 79:2253 80:1569 81:1393 82:1065 83:782 84:1034 85:1998 86:561 87:1364 88:908 89:2355 90:214 91:6434 92:1260 93:2377 94:2406 95:2961 96:901 97:355 98:935 99:133 100:84 101:989 102:184 103:18502 104:3533 105:215 106:769 107:1769 108:710 109:3324 110:1645 111:1800 112:1337 113:1306 114:1130 115:1646 116:1655 117:1775 118:2214 119:1659 120:1015 121:1043 122:2423 123:1725 124:1447 125:1920 128:1129 129:671 130:494 131:1620 132:732 133:190 134:1003 135:232 136:507 137:651 138:1942 139:677 140:475 141:737 142:851 143:1000 144:810 145:476 146:1230 147:735 148:1643 149:757 150:756 151:1097 152:825 153:323 154:1489 155:800 156:1464 157:799 158:657 159:1840 160:1312 161:810 162:2633 163:605 164:1077 165:1552 166:462 167:1257 168:3150 169:831 170:3859 171:492 172:1007 173:2087 174:971 175:796 176:2029 177:4013 178:2501 179:1269 180:2180 181:2412 182:2350 183:1254 184:1062 185:13979 186:3538 187:2425 188:2899 189:2000 190:8157 191:1354 192:9803 193:6103 194:5017 195:3992 196:2743 197:1612 198:5573 199:5914 200:7435 201:4876 202:10293 203:10269 204:4571 205:2903 206:3197 207:3209 208:3933 209:4027 210:3884 211:1998 212:3044 213:2818 214:1037 215:56 216:5999 217:2130 218:860 219:567 220:1807 221:998 222:971 223:1372 End of report From eric at emj.se Sun Aug 26 05:46:05 2018 From: eric at emj.se (=?UTF-8?Q?Eric_Lindsj=c3=b6?=) Date: Sun, 26 Aug 2018 07:46:05 +0200 Subject: YANG daemeon for Linux In-Reply-To: References: Message-ID: What you want is probably sysrepo https://github.com/sysrepo/sysrepo /Eric On 08/09/2018 03:56 AM, Marcus Leske wrote: > Yes Rob, i’d like to do what you described: use netconf and yang to > provision the quagga BGP implementation. > > Can you describe work arounds? If any. > > Can i convert a bgp yang model to json/yaml and have some other app consume > it? > > Thanks > > On Sunday, July 29, 2018, Rob Shakir wrote: > >> Could you define "render"? If you're looking to take a YANG model (which >> one?) and configure Linux kernel networking features with it, I can't >> recall having seen something that does this. I have been working on a side >> project (which I'm hoping to bring to a hackathon) to take Linux networking >> and map it to OpenConfig - but this is maexceptionally embryonic. >> >> If you're looking for ways to manipulate data instances for YANG-modelled >> schemas on Linux, here are some options (full disclosure: I lead the >> development of two of them): >> >> - ygot - produces Go structs, or Protobufs that correspond to a YANG >> model - github.com/openconfig/ygot >> - pyangbind - produces Python classes that correspond to a YANG model - >> github.com/robshakir/pyangbind >> - ydk (Cisco) - produces Python and C++ APIs, more centred around device >> interaction (https://developer.cisco.com/site/ydk/) >> >> Cheers, >> r. >> >> On Sat, 28 Jul 2018 at 03:54 Vincent Bernat wrote: >> >>> ❦ 27 juillet 2018 12:23 -0700, Karl Jørn : >>> >>>> Looking for an agent on Linux that will render YANG models, so I can >>>> provision networking on Linux. >>> Maybe looking at this one: >>> http://yuma123.org/wiki/index.php/Yuma_netconfd_Manual >>> -- >>> Make sure your code "does nothing" gracefully. >>> - The Elements of Programming Style (Kernighan & Plauger) >>> From lguillory at reservetele.com Mon Aug 27 18:31:15 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 27 Aug 2018 18:31:15 +0000 Subject: Sprint Wireless Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FACA0FC@RTC-EXCH01.RESERVE.LDS> Anyone from Sprint on here that can help or direct me to a contact that can help with trunk issues into a tandem? Running out of options trying to get them to sort of their issues for their customers. Thanks Luke Ns -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Mon Aug 27 18:45:06 2018 From: sean at donelan.com (Sean Donelan) Date: Mon, 27 Aug 2018 14:45:06 -0400 (EDT) Subject: FCC: 2017 Atlantic Hurricane Season Impact on Communications Message-ID: The FCC has published a report "2017 Atlantic Hurricane Season Impact on CommunicationsReport and Recommendations." It is a bit excessive on the back-slapping about the FCC's leadership. No independent ISPs submitted comments to the Commission. Are there any independent ISPs left in Puerto Rico or U.S. Virgin Islands? https://docs.fcc.gov/public/attachments/DOC-353805A1.pdf Some highlights... V. LESSONS LEARNED AND NEXT STEPS 56. Based on information, analysis and feedback received by various stakeholders as well as the HRTF, the Commission presents the following lessons learned and next steps towards enhancing its disaster response and recovery efforts. A. Improvements to FCC’s Emergency Response and Recovery Efforts 57. DIRS Enhancements. 58. Wireless Resiliency Cooperative Framework. 60. Radio Frequency Survey Application. 61. Over-the-Air Information (OTA) Collection During Disasters. 62. Increase Engagement with Emergency Management Partners. 64. Efficient Communication in Languages Other Than English and In Additional Formats. From sean at donelan.com Mon Aug 27 18:51:54 2018 From: sean at donelan.com (Sean Donelan) Date: Mon, 27 Aug 2018 14:51:54 -0400 (EDT) Subject: FCC: 2017 Atlantic Hurricane Season Impact on Communications In-Reply-To: <664421160.4321.1535395618703.JavaMail.mhammett@ThunderFuck> References: <664421160.4321.1535395618703.JavaMail.mhammett@ThunderFuck> Message-ID: On Mon, 27 Aug 2018, Mike Hammett wrote: > There are dozens of independents on the islands. They probably didn't know > their comments were desired. The Commission is still looking for nominations for its disaster response and recovery working group. Any independent ISPs can nominate a representative.... https://docs.fcc.gov/public/attachments/DA-18-837A1.pdf The Federal Communications Commission (Commission) solicits nominations for membership on a new Disaster Response and Recovery Working Group of the Broadband Deployment Advisory Committee (BDAC). This new working group will assist the BDAC in providing advice and recommendations to the Commission on steps that can be taken to improve disaster preparation, response, and recovery for broadband infrastructure. Nominations for membership to the BDAC’s Disaster Response and Recovery Working Group should be submitted to the FCC no later than September 7, 2018. From mehmet at akcin.net Tue Aug 28 08:15:11 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 28 Aug 2018 01:15:11 -0700 Subject: Subsea Cable Status Map Experiment Update Message-ID: Hello everyone, I wanted to send a quick follow up email regarding the subsea cable status map experiment which we have shared few months ago with NANOG community. More details can be found here. Nanog lighting talk can be accessed here. Based on the feedback we have collected from many interested parties,engineers and operators we are taking an approach to work on providing a platform which will enable people to to submit their KML, CVS, or whatever format they prefer which will create maps based on this actual data as well as with some basic APIs we will be able to get NOCs of these submarine cable systems quickly able to update status of the cable and insert other information should a cut/disruption occurs. We will be building this subsea map from complete scratch and only based on the data shared by those who have access to the cables. Our intent is to have this map displayed in every NOC as a cool way to find status of subsea cables (and long term strategy might be to extend this to some long haul, and metro fibre - i know this is VERY hard but dreaming big here..). We are asking for your feedback here, what information would be useful besides cable availability? what is minimum needed for this map to be useful? What really doesn't matter? we are also working on overlaying this map with other maps, if you have suggestions, please share those privately with me (or to the all list). We've created a mailing list which you can join and share your ideas in more details. We are also seeking for help as I am mostly self organizing this project. If you have cycles to write code, and have experience with GIS, Openstreetmap and other mapping software, Python, and interested in contributing please let me know also off-list. thanks in advance, and I hope to have a working demo very soon. Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Wed Aug 29 11:30:24 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 29 Aug 2018 04:30:24 -0700 Subject: FCC: 2017 Atlantic Hurricane Season Impact on Communications In-Reply-To: References: Message-ID: Independent ISPs? Aeronet based in San Juan is much smaller than a typical LEC type entity, but has a significant service area and builds gigabit class last mile using microwave and millimeter wave. https://bgp.he.net/AS14979#_asinfo On Mon, Aug 27, 2018, 11:46 AM Sean Donelan wrote: > The FCC has published a report "2017 Atlantic Hurricane Season Impact on > CommunicationsReport and Recommendations." > > It is a bit excessive on the back-slapping about the FCC's leadership. > > No independent ISPs submitted comments to the Commission. Are there any > independent ISPs left in Puerto Rico or U.S. Virgin Islands? > > > https://docs.fcc.gov/public/attachments/DOC-353805A1.pdf > > Some highlights... > > V. LESSONS LEARNED AND NEXT STEPS > 56. Based on information, analysis and feedback received by various > stakeholders as well as the HRTF, the Commission presents the following > lessons learned and next steps towards enhancing its disaster response and > recovery efforts. > > A. Improvements to FCC’s Emergency Response and Recovery Efforts > 57. DIRS Enhancements. > 58. Wireless Resiliency Cooperative Framework. > 60. Radio Frequency Survey Application. > 61. Over-the-Air Information (OTA) Collection During Disasters. > 62. Increase Engagement with Emergency Management Partners. > 64. Efficient Communication in Languages Other Than English and In > Additional Formats. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed Aug 29 14:09:02 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 29 Aug 2018 07:09:02 -0700 Subject: Vultr Message-ID: Hello Looking for a contact from Vultr. Any offlist intro would be appreciated. Thank you Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jacques.Latour at cira.ca Wed Aug 29 14:16:26 2018 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Wed, 29 Aug 2018 14:16:26 +0000 Subject: Call for Participation -- ICANN DNSSEC Workshop at ICANN63 Barcelona, Spain Message-ID: <3b122e8e33e344f9aed6621ad2a8f1dc@cira.ca> Hi All! Call for Participation -- ICANN DNSSEC Workshop at ICANN63 Barcelona, Spain The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN63 meeting held from 20-25 October 2018 in Barcelona, Spain. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Policy Forum in Panama City, Panama on 25 June 2018. The presentations and transcripts are available at: https://62.schedule.icann.org/meetings/699560 [62.schedule.icann.org], and https://62.schedule.icann.org/meetings/699556 [62.schedule.icann.org] At ICANN63 we are particularly interested in live demonstrations of uses of DNSSEC, DS automation or DANE. Examples might include: * DNSSEC automation and deployment using CDS, CDNSKEY, and CSYNC * DNSSEC/DANE validation in browsers and in applications * Secure email / email encryption using DNSSEC, OPENPGPKEY, or S/MIME * DNSSEC signing solutions and innovation (monitoring, managing, validation) * Tools for automating the generation of DNSSEC/DANE records * Extending DNSSEC/DANE with authentication, SSH, XMPP, SMTP, S/MIME or PGP/GPG and other protocols Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet. We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include: 1. DNSSEC Panel (Regional and Global) For this panel, we are seeking participation from those who have been involved in DNSSEC deployment in the region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn't it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers. 2. Post KSK Rollover Following the Root Key Rollover, we would like to bring together a panel of people who can talk about lessons learned from this KSK Rollover and lessons learned for the next time 3. DS Automation We are looking at innovative ways to automate the parent child synchronization CDS / CDNSKEY and methods to bootstrap new or existing domains. We are also interested in development or plans related to CSYNC, which are aimed at keeping the glue up to date. We would like to hear from DNS Operators what their current thoughts on CDS/CDNSKEY automation are. 3 DNSSEC/DANE Support in the browsers We would be interested in hearing from browser develop what their plans are in terms of supporting DNSSEC/DANE validation. 4. DANE Automation For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as: * How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet? * What tools, systems and services are available to help automate DNSSEC key management? * Can you provide an analysis of current tools/services and identify gaps? * What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries? * What tools and services are now available that can support DANE usage? We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation and services. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-barcelona at isoc.org**07 September 2018 ** We hope that you can join us. Thank you, Jacques Latour On behalf of the DNSSEC Workshop Program Committee: Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Russ Mundy, Parsons Ondřej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society Mark Elkins, DNS/ZACR dnssec-barcelona at isoc.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Wed Aug 29 21:48:48 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 29 Aug 2018 14:48:48 -0700 Subject: TekSavvy (Canada) contact Message-ID: I'm looking for a clueful neteng point of contact at TekSavvy. Please contact me off-list. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at paulstewart.org Wed Aug 29 22:08:48 2018 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 29 Aug 2018 22:08:48 +0000 (UTC) Subject: TekSavvy (Canada) contact In-Reply-To: <1105410579.1375.1535580322400.JavaMail.mhammett@ThunderFuck> References: <1105410579.1375.1535580322400.JavaMail.mhammett@ThunderFuck> Message-ID: <9F19E1E3AA18DC32.0789C402-E66B-4F0E-8692-F74A9915AE84@mail.outlook.com> Thnx all - already reached out  Paul  Get Outlook for iOS On Wed, Aug 29, 2018 at 6:05 PM -0400, "Mike Hammett" wrote: "Paul Stewart" He's on AFMUG too. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Eric Kuhnke" To: "nanog at nanog.org list" Sent: Wednesday, August 29, 2018 4:48:48 PM Subject: TekSavvy (Canada) contact I'm looking for a clueful neteng point of contact at TekSavvy. Please contact me off-list. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at paulstewart.org Thu Aug 30 12:14:35 2018 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 30 Aug 2018 08:14:35 -0400 Subject: TekSavvy (Canada) contact In-Reply-To: <9F19E1E3AA18DC32.0789C402-E66B-4F0E-8692-F74A9915AE84@mail.outlook.com> References: <1105410579.1375.1535580322400.JavaMail.mhammett@ThunderFuck> <9F19E1E3AA18DC32.0789C402-E66B-4F0E-8692-F74A9915AE84@mail.outlook.com> Message-ID: <7C428EA0-7865-4A90-803B-5C3770CE0488@paulstewart.org> Folks – please do *not* request “clueful neteng point of contact” on the list if you are really looking to place an order for residential service.  Thanks … Paul From: NANOG on behalf of "paul at paulstewart.org" Date: Wednesday, August 29, 2018 at 6:09 PM To: Mike Hammett Cc: "nanog at nanog.org list" Subject: Re: TekSavvy (Canada) contact Thnx all - already reached out Paul Get Outlook for iOS On Wed, Aug 29, 2018 at 6:05 PM -0400, "Mike Hammett" wrote: "Paul Stewart" He's on AFMUG too. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Eric Kuhnke" To: "nanog at nanog.org list" Sent: Wednesday, August 29, 2018 4:48:48 PM Subject: TekSavvy (Canada) contact I'm looking for a clueful neteng point of contact at TekSavvy. Please contact me off-list. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From faisal at snappytelecom.net Thu Aug 30 14:22:55 2018 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 30 Aug 2018 14:22:55 +0000 (GMT) Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: <1086383134.4795609.1535638975022.JavaMail.zimbra@snappytelecom.net> Having done a full circle on the number of network monitoring packages, dealing with pro's and con's, we ended up with using Check_mk, moreover OMD.... http://omdisto.org We found (OMD) this to be a very powerful combination of different packages, each can shine for it's own strength and other compliments it for for the weaknesses ! Regards. Faisal Imtiaz Snappy Internet & Telecom http://www.snappytelecom.net Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > From: "Colton Conor" > To: "nanog list" > Sent: Wednesday, August 15, 2018 9:49:12 AM > Subject: What NMS do you use and why? > We are looking for a new network monitoring system. Since there are so many > operators on this list, I would like to know which NMS do you use and why? Is > there one that you really like, and others that you hate? > For free options (opensouce), LibreNMS and NetXMS come highly recommended by > many wireless ISPs on low budgets. However, I am not sure the commercial > options available nor their price points. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lathama at gmail.com Thu Aug 30 14:33:02 2018 From: lathama at gmail.com (Andrew Latham) Date: Thu, 30 Aug 2018 09:33:02 -0500 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: Additionally mention: * https://www.centreon.com/en/solutions/centreon/ Related Tooling: * https://www.cyphon.io/ On Wed, Aug 15, 2018 at 8:51 AM Colton Conor wrote: > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use and > why? Is there one that you really like, and others that you hate? > > For free options (opensouce), LibreNMS and NetXMS come highly recommended > by many wireless ISPs on low budgets. However, I am not sure the commercial > options available nor their price points. > > > -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonwolberg at gmail.com Thu Aug 30 17:31:39 2018 From: jonwolberg at gmail.com (Jon Wolberg) Date: Thu, 30 Aug 2018 10:31:39 -0700 Subject: What NMS do you use and why? In-Reply-To: <1086383134.4795609.1535638975022.JavaMail.zimbra@snappytelecom.net> References: <1086383134.4795609.1535638975022.JavaMail.zimbra@snappytelecom.net> Message-ID: There are many other threads on this topic as well. I can say +1 for check_mk though. On Thu, Aug 30, 2018 at 7:24 AM Faisal Imtiaz wrote: > Having done a full circle on the number of network monitoring packages, > dealing with pro's and con's, we ended up with using Check_mk, moreover > OMD.... http://omdisto.org > > We found (OMD) this to be a very powerful combination of different > packages, each can shine for it's own strength and other compliments it for > for the weaknesses ! > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > http://www.snappytelecom.net > > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ------------------------------ > > *From: *"Colton Conor" > *To: *"nanog list" > *Sent: *Wednesday, August 15, 2018 9:49:12 AM > *Subject: *What NMS do you use and why? > > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use and > why? Is there one that you really like, and others that you hate? > For free options (opensouce), LibreNMS and NetXMS come highly recommended > by many wireless ISPs on low budgets. However, I am not sure the commercial > options available nor their price points. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Thu Aug 30 19:52:56 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 30 Aug 2018 14:52:56 -0500 Subject: automatic rtbh trigger using flow data Message-ID: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? .I'm thinking we could use quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack. Btw, I already have nfsen running and we receive real-time alters of various types of attacks, high volume, high ports, etc. and then we telnet into a cisco trigger router and drop a few lines of code into it and then bgp does the rest within seconds, the upstream providers learn of this route via communities and they rtbh it in their cloud, BUT, I would like my alerts to do this automatically. that would be very nice. Any guidance would be appreciated. -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.luca at gmail.com Thu Aug 30 19:56:11 2018 From: vicente.luca at gmail.com (Vicente De Luca) Date: Thu, 30 Aug 2018 12:56:11 -0700 Subject: automatic rtbh trigger using flow data In-Reply-To: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> Message-ID: <01457371-8F3E-4933-B9D0-84B0C9EE2712@gmail.com> fastnetmon does exactly what you’re looking for. https://fastnetmon.com/ there is also an open source version https://github.com/pavel-odintsov/fastnetmon my best —vicente > On Aug 30, 2018, at 12:52 PM, Aaron Gould wrote: > > Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? …I’m thinking we could use quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack. > > Btw, I already have nfsen running and we receive real-time alters of various types of attacks, high volume, high ports, etc… and then we telnet into a cisco trigger router and drop a few lines of code into it and then bgp does the rest within seconds, the upstream providers learn of this route via communities and they rtbh it in their cloud, BUT, I would like my alerts to do this automatically… that would be very nice. Any guidance would be appreciated. > > -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ryan.Hamel at quadranet.com Thu Aug 30 19:58:08 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Thu, 30 Aug 2018 19:58:08 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> Message-ID: <9df0314a3d6849f18a8f4557b8426d8c@MIA-MBX01.quadranet.local> There are software that combine your needs altogether. I'm sure there are others. WANGuard from Andrisoft (https://www.andrisoft.com/software/wanguard) Fastnetmon (https://fastnetmon.com/) From: NANOG On Behalf Of Aaron Gould Sent: Thursday, August 30, 2018 12:53 PM To: Nanog at nanog.org Subject: automatic rtbh trigger using flow data Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? ...I'm thinking we could use quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack. Btw, I already have nfsen running and we receive real-time alters of various types of attacks, high volume, high ports, etc... and then we telnet into a cisco trigger router and drop a few lines of code into it and then bgp does the rest within seconds, the upstream providers learn of this route via communities and they rtbh it in their cloud, BUT, I would like my alerts to do this automatically... that would be very nice. Any guidance would be appreciated. -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Thu Aug 30 20:08:16 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 30 Aug 2018 15:08:16 -0500 Subject: automatic rtbh trigger using flow data In-Reply-To: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> Message-ID: <003801d4409d$306e5fd0$914b1f70$@gvtc.com> Wow, 4 replies for fastnetmon, thanks Ryan, Vincente, Job and Kushal I'll look into it -Aaron From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould Sent: Thursday, August 30, 2018 2:53 PM To: Nanog at nanog.org Subject: automatic rtbh trigger using flow data Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? .I'm thinking we could use quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack. Btw, I already have nfsen running and we receive real-time alters of various types of attacks, high volume, high ports, etc. and then we telnet into a cisco trigger router and drop a few lines of code into it and then bgp does the rest within seconds, the upstream providers learn of this route via communities and they rtbh it in their cloud, BUT, I would like my alerts to do this automatically. that would be very nice. Any guidance would be appreciated. -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.py at tsisemi.com Thu Aug 30 20:17:10 2018 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 30 Aug 2018 20:17:10 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> Message-ID: > Aaron Gould wrote : > Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? ...I'm thinking we could use > quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack. Look at Exabgp : https://github.com/Exa-Networks/exabgp That's what I use in here : https://arneill-py.sacramento.ca.us/cbbc/ to inject the prefixes in BGP. I block the attacker's addresses, not the victim but if you are willing to write your own scripts it does the job. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From aaron1 at gvtc.com Thu Aug 30 20:38:13 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 30 Aug 2018 15:38:13 -0500 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> Message-ID: <005401d440a1$5f954f40$1ebfedc0$@gvtc.com> Thanks, but what if the attacker is many... like thousands ? ...isn't that typically what we see, is tons and tons of sources (hence distributed....dos) ? -Aaron -----Original Message----- From: Michel Py [mailto:michel.py at tsisemi.com] Sent: Thursday, August 30, 2018 3:17 PM To: Aaron Gould; Nanog at nanog.org Subject: RE: automatic rtbh trigger using flow data > Aaron Gould wrote : > Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? ...I'm thinking we could use > quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack. Look at Exabgp : https://github.com/Exa-Networks/exabgp That's what I use in here : https://arneill-py.sacramento.ca.us/cbbc/ to inject the prefixes in BGP. I block the attacker's addresses, not the victim but if you are willing to write your own scripts it does the job. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From Ryan.Hamel at quadranet.com Thu Aug 30 20:48:06 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Thu, 30 Aug 2018 20:48:06 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: <005401d440a1$5f954f40$1ebfedc0$@gvtc.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <005401d440a1$5f954f40$1ebfedc0$@gvtc.com> Message-ID: <8136b52a9b5a46a69f1f147779cf7726@MIA-MBX01.quadranet.local> Exactly Aaron. No provider will allow a customer to null route a source IP address. I could only assume that a null route on Michel's network is tanking the packets at their edge to 192.0.2.1 (discard/null0). -- Ryan Hamel Senior Support Engineer ryan.hamel at quadranet.com | +1 (888) 578-2372 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud -----Original Message----- From: NANOG On Behalf Of Aaron Gould Sent: Thursday, August 30, 2018 1:38 PM To: 'Michel Py' ; Nanog at nanog.org Subject: RE: automatic rtbh trigger using flow data Thanks, but what if the attacker is many... like thousands ? ...isn't that typically what we see, is tons and tons of sources (hence distributed....dos) ? -Aaron -----Original Message----- From: Michel Py [mailto:michel.py at tsisemi.com] Sent: Thursday, August 30, 2018 3:17 PM To: Aaron Gould; Nanog at nanog.org Subject: RE: automatic rtbh trigger using flow data > Aaron Gould wrote : > Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? ...I'm thinking we could use > quagga or a script of some sort to interact with a router to advertise > to bgp the /32 host route of the victim under attack. Look at Exabgp : https://github.com/Exa-Networks/exabgp That's what I use in here : https://arneill-py.sacramento.ca.us/cbbc/ to inject the prefixes in BGP. I block the attacker's addresses, not the victim but if you are willing to write your own scripts it does the job. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From michel.py at tsisemi.com Thu Aug 30 20:59:18 2018 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 30 Aug 2018 20:59:18 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: <005401d440a1$5f954f40$1ebfedc0$@gvtc.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <005401d440a1$5f954f40$1ebfedc0$@gvtc.com> Message-ID: > Aaron Gould wrote : > Thanks, but what if the attacker is many... like thousands ? ...isn't that typically what we see, is tons and tons of sources (hence distributed....dos) ? At this very moment I blacklist ~ 56,000 individual /32s and historically it has been up to 135,000 at times. It's not a problem for most routers, unless you're on one of these old clunkers with un-upgradable TCAM and a full feed (if you are, you don't have much time left anyway). > Ryan Hamel wrote : > Exactly Aaron. No provider will allow a customer to null route a source IP address. Yes, unless you have your own router on their side of the link and pay for it, or have your own VRF on their router which is not going to be cheap either. > I could only assume that a null route on Michel's network is tanking the packets at their edge to 192.0.2.1 (discard/null0). Correct, and I clearly understand its limitations, paragraph below taken from https://arneill-py.sacramento.ca.us/cbbc/ There indeed is a value in blacklisting the IP address of the host being attacked and feed that with the appropriate community to the upstream that will accept it as it is part of your own space. You sacrifice one host to save the bandwidth to the rest. That being said, if the DDOS targets your entire IP range, none of these will help. I have to withstand DDOS attacks all the time, can the CBBC feed help ? It depends on the type of attack; the CBBC feed is not designed as DDOS mitigation tool. There is no such thing as a free lunch : your ISP will not take the full CBBC feed for free when they can make you pay big bucks for their own one. The CBBC does not prevent the DDOS attack to get to you, it may help with attacks that are based on PPS, not raw bandwidth. What the CBBC does is to block the offending traffic at the router level, so it is blocked before it even reaches your server / firewall. However, the CBBC does not prevent the DDOS traffic from coming to you, so if you have a slow connection to the Internet and the DDOS sends more bandwidth than you have, you still are down. However, if the DDOS is based not on bandwidth but on a higher-level protocol such as DNS or HTTPS, it helps by taking the load off the server. Michel. -Aaron -----Original Message----- From: Michel Py [mailto:michel.py at tsisemi.com] Sent: Thursday, August 30, 2018 3:17 PM To: Aaron Gould; Nanog at nanog.org Subject: RE: automatic rtbh trigger using flow data > Aaron Gould wrote : > Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? ...I'm thinking we could use > quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack. Look at Exabgp : https://github.com/Exa-Networks/exabgp That's what I use in here : https://arneill-py.sacramento.ca.us/cbbc/ to inject the prefixes in BGP. I block the attacker's addresses, not the victim but if you are willing to write your own scripts it does the job. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From jmaimon at jmaimon.com Thu Aug 30 23:30:18 2018 From: jmaimon at jmaimon.com (Joe Maimon) Date: Thu, 30 Aug 2018 19:30:18 -0400 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> Message-ID: <5B887E0A.1090809@jmaimon.com> Michel Py wrote: >> Aaron Gould wrote : >> Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? ...I'm thinking we could use >> quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack. > Look at Exabgp : https://github.com/Exa-Networks/exabgp > That's what I use in here : https://arneill-py.sacramento.ca.us/cbbc/ to inject the prefixes in BGP. > I block the attacker's addresses, not the victim but if you are willing to write your own scripts it does the job. > > Michel. > I use a bunch of scripts plus a supervisory sqlite3 database process all injecting into quagga Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts. Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity. Using flow data, that sounds like an interesting direction to take this into, so thank you! Joe From michel.py at tsisemi.com Thu Aug 30 23:43:24 2018 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 30 Aug 2018 23:43:24 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: <5B887E0A.1090809@jmaimon.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> Message-ID: <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> > Joe Maimon wrote : > I use a bunch of scripts plus a supervisory sqlite3 database process all injecting into quagga I have the sqlite part planned, today I'm using a flat file :-( I know :-( > Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts. Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity. I would like to have your feed. How many attacker prefixes do you currently have ? > Using flow data, that sounds like an interesting direction to take this into, so thank you! The one thing we can share here is the attacker prefixes. The victim prefixes are unique to each of us but I expect our attacker prefixes to be very close. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From aaron1 at gvtc.com Thu Aug 30 23:47:52 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 30 Aug 2018 18:47:52 -0500 Subject: automatic rtbh trigger using flow data In-Reply-To: <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> Message-ID: I'm really surprised that you all are doing this based on source ip, simply because I thought the distribution of botnet members around the world we're so extensive that I never really thought it possible to filter based on sources, if so I'd like to see the list too Even so, this would not stop the attacks from hitting my front door, my side of my Internet uplink...when paying for a 30 gigs CIR and paying double for megabits per second over that, up to the ceiling of 100 gig every bit that hits my front door over 30 gig would cost me extra, remotely triggering based on my victim IP address inside my network would be my solution to saving money But stopping the attack even on my side of my Internet up like would at least stop it from proliferating throughout my internal network which is also costing me when it affects cell towers, etc. Aaron On Aug 30, 2018, at 6:43 PM, Michel Py wrote: >> Joe Maimon wrote : >> I use a bunch of scripts plus a supervisory sqlite3 database process all injecting into quagga > > I have the sqlite part planned, today I'm using a flat file :-( I know :-( > >> Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts. Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity. > > I would like to have your feed. How many attacker prefixes do you currently have ? > >> Using flow data, that sounds like an interesting direction to take this into, so thank you! > > The one thing we can share here is the attacker prefixes. The victim prefixes are unique to each of us but I expect our attacker prefixes to be very close. > > Michel. > > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From rdobbins at arbor.net Thu Aug 30 23:59:29 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 31 Aug 2018 06:59:29 +0700 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> Message-ID: <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> On 31 Aug 2018, at 6:47, Aaron Gould wrote: > I'm really surprised that you all are doing this based on source ip, > simply because I thought the distribution of botnet members around the > world we're so extensive that I never really thought it possible to > filter based on sources, i Using S/RTBH to drop attack sources has been a valid and useful mitigation tactic for close to 20 years. Any kind of modern router scales up to large numbers of sources; and note that S/RTBH isn't limited to /32s. It's discussed in this .pdf preso: ----------------------------------- Roland Dobbins From michel.py at tsisemi.com Fri Aug 31 00:14:50 2018 From: michel.py at tsisemi.com (Michel Py) Date: Fri, 31 Aug 2018 00:14:50 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> Message-ID: > Aaron Gould wrote : > I'm really surprised that you all are doing this based on source ip, simply because I thought the distribution of botnet members around > the world we're so extensive that I never really thought it possible to filter based on sources, if so I'd like to see the list too. I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP prefixes is nothing these days. I am not surprised that Joe pushes that to some CPEs. > Even so, this would not stop the attacks from hitting my front door, my side of my Internet uplink...when paying for a 30 gigs CIR > and paying double for megabits per second over that, up to the ceiling of 100 gig every bit that hits my front door over 30 gig > would cost me extra, remotely triggering based on my victim IP address inside my network would be my solution to saving money. I agree. If you want to get a real use of source blacklisting, to save bandwidth, you probably went to rent a U in a rack at your upstream(s) to block it there. I never did it past 1GE, and I have never measured seriously the bandwidth it would save, would be curious to know. I think the two approaches are complementary to each other though. Michel. On Aug 30, 2018, at 6:43 PM, Michel Py wrote: >> Joe Maimon wrote : >> I use a bunch of scripts plus a supervisory sqlite3 database process all injecting into quagga > > I have the sqlite part planned, today I'm using a flat file :-( I know :-( > >> Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts. Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity. > > I would like to have your feed. How many attacker prefixes do you currently have ? > >> Using flow data, that sounds like an interesting direction to take this into, so thank you! > > The one thing we can share here is the attacker prefixes. The victim prefixes are unique to each of us but I expect our attacker prefixes to be very close. > > Michel. > > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From hibaysal at gmail.com Fri Aug 31 09:09:19 2018 From: hibaysal at gmail.com (H I Baysal) Date: Fri, 31 Aug 2018 11:09:19 +0200 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> Message-ID: <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> Most of the solutions mentioned are paid, or fastnetmon is partially paid. And the thing you want is paid i believe.... Nice tool though, not saying anything against it. However.... My personal view is, as long as you can store your flow info in a timeseries database (like influxdb and NOT SQL LIKE!!!!!!!) you can do whatever you want with the (raw) data. And create custom triggers for different calculations. Flows are on the fly and are coming in constantly, you could have a calculation like group by srcip and whatever protocol you want or just srcip, and make a calculation for every x seconds or minutes. As i mentioned the flow data is a constant stream, so you could have it triggered as fast as you want. (and the nice thing is, with sflow, you also get as path, peer as, localpref,community (if enabled). You could group by anything.. :) I admit it takes a bit more time to setup but the outcome is amazing ;) (especially if you graph it then with grafana) And in your case it would be a script that does a influxdb command to make the calculations and if the outcome shows an IP meeting the thresholds you have set in the calculation, you trigger a script that adjusts the route to be announced to your upstream with the correct (rtbh) community. ( as i mentioned, as long as you have the "raw" flows, you can do anything ) Good luck, whatever you choose :) On 31-08-18 02:14, Michel Py wrote: >> Aaron Gould wrote : >> I'm really surprised that you all are doing this based on source ip, simply because I thought the distribution of botnet members around >> the world we're so extensive that I never really thought it possible to filter based on sources, if so I'd like to see the list too. > I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP prefixes is nothing these days. I am not surprised that Joe pushes that to some CPEs. > >> Even so, this would not stop the attacks from hitting my front door, my side of my Internet uplink...when paying for a 30 gigs CIR >> and paying double for megabits per second over that, up to the ceiling of 100 gig every bit that hits my front door over 30 gig >> would cost me extra, remotely triggering based on my victim IP address inside my network would be my solution to saving money. > I agree. If you want to get a real use of source blacklisting, to save bandwidth, you probably went to rent a U in a rack at your upstream(s) to block it there. > I never did it past 1GE, and I have never measured seriously the bandwidth it would save, would be curious to know. > I think the two approaches are complementary to each other though. > > Michel. > > > On Aug 30, 2018, at 6:43 PM, Michel Py wrote: > >>> Joe Maimon wrote : >>> I use a bunch of scripts plus a supervisory sqlite3 database process all injecting into quagga >> I have the sqlite part planned, today I'm using a flat file :-( I know :-( >> >>> Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts. Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity. >> I would like to have your feed. How many attacker prefixes do you currently have ? >> >>> Using flow data, that sounds like an interesting direction to take this into, so thank you! >> The one thing we can share here is the attacker prefixes. The victim prefixes are unique to each of us but I expect our attacker prefixes to be very close. >> >> Michel. >> >> TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From Ryan.Hamel at quadranet.com Fri Aug 31 09:33:13 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Fri, 31 Aug 2018 09:33:13 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> Message-ID: From experience, sflows are horribly inaccurate for DDoS detection, since the volume could disrupt the control plane and render the process useless, thus not giving data to the external system to act upon it. You can't get any better than mirroring your inbound transit, and sampling the output to a sensor. I have also spent some time on a spare server running netmap and influxdb, it simply could not keep up, nor could I write any useful queries against it. Which is why I'm deciding on using pf_ring ft (flow table) and just let it calculate all the data to be dumped into a MySQL memory table, and also harvesting ntop's NDPI protocol decoding, to enhance the detection rules. My ideal setup is to break things down into dedicated programs like flow exporter, detection, and response. I also want to make clear to Michel, that colo'ing a router at an ISP is no different than plugging it into your local router, your uplink will get saturated beyond what it can physically handle with only the ACLs protecting the other side, but if your clients are also receiving traffic on the same uplink as the attack, it's a denial of service to them. -----Original Message----- From: NANOG On Behalf Of H I Baysal Sent: Friday, August 31, 2018 2:09 AM To: Michel Py ; Aaron Gould ; michel at arneill-py.sacramento.ca.us Cc: Nanog at nanog.org Subject: Re: automatic rtbh trigger using flow data Most of the solutions mentioned are paid, or fastnetmon is partially paid. And the thing you want is paid i believe.... Nice tool though, not saying anything against it. However.... My personal view is, as long as you can store your flow info in a timeseries database (like influxdb and NOT SQL LIKE!!!!!!!) you can do whatever you want with the (raw) data. And create custom triggers for different calculations. Flows are on the fly and are coming in constantly, you could have a calculation like group by srcip and whatever protocol you want or just srcip, and make a calculation for every x seconds or minutes. As i mentioned the flow data is a constant stream, so you could have it triggered as fast as you want. (and the nice thing is, with sflow, you also get as path, peer as, localpref,community (if enabled). You could group by anything.. :) I admit it takes a bit more time to setup but the outcome is amazing ;) (especially if you graph it then with grafana) And in your case it would be a script that does a influxdb command to make the calculations and if the outcome shows an IP meeting the thresholds you have set in the calculation, you trigger a script that adjusts the route to be announced to your upstream with the correct (rtbh) community. ( as i mentioned, as long as you have the "raw" flows, you can do anything ) Good luck, whatever you choose :) On 31-08-18 02:14, Michel Py wrote: >> Aaron Gould wrote : >> I'm really surprised that you all are doing this based on source ip, >> simply because I thought the distribution of botnet members around the world we're so extensive that I never really thought it possible to filter based on sources, if so I'd like to see the list too. > I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP prefixes is nothing these days. I am not surprised that Joe pushes that to some CPEs. > >> Even so, this would not stop the attacks from hitting my front door, >> my side of my Internet uplink...when paying for a 30 gigs CIR and >> paying double for megabits per second over that, up to the ceiling of 100 gig every bit that hits my front door over 30 gig would cost me extra, remotely triggering based on my victim IP address inside my network would be my solution to saving money. > I agree. If you want to get a real use of source blacklisting, to save bandwidth, you probably went to rent a U in a rack at your upstream(s) to block it there. > I never did it past 1GE, and I have never measured seriously the bandwidth it would save, would be curious to know. > I think the two approaches are complementary to each other though. > > Michel. > > > On Aug 30, 2018, at 6:43 PM, Michel Py wrote: > >>> Joe Maimon wrote : >>> I use a bunch of scripts plus a supervisory sqlite3 database process >>> all injecting into quagga >> I have the sqlite part planned, today I'm using a flat file :-( I >> know :-( >> >>> Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts. Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity. >> I would like to have your feed. How many attacker prefixes do you currently have ? >> >>> Using flow data, that sounds like an interesting direction to take this into, so thank you! >> The one thing we can share here is the attacker prefixes. The victim prefixes are unique to each of us but I expect our attacker prefixes to be very close. >> >> Michel. >> >> TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From hibaysal at gmail.com Fri Aug 31 10:02:22 2018 From: hibaysal at gmail.com (H I Baysal) Date: Fri, 31 Aug 2018 12:02:22 +0200 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> Message-ID: I think your experience has to do more with your setup than sflow or influxdb... my sflow data, that i push into influxdb. is 1 on 1 accurate with the interface utilization ( even on group by per source ip ) Arista performs fine with sflow.... Don't know what brand you used. I'm getting 300 mbit of constant (sflow) data in influxdb.... ''' it simply could not keep up, nor could I write any useful queries against it ''' again, i really think this has to do with the setup or the queries you tried to do. (and (i think ) you tried sflow exporter on a server, i think the topic was from a appliance as an exporter) If you still want to give influxdb+ sflow a try, i'm more than willing to help you out ;) On 31-08-18 11:33, Ryan Hamel wrote: > From experience, sflows are horribly inaccurate for DDoS detection, since the volume could disrupt the control plane and render the process useless, thus not giving data to the external system to act upon it. You can't get any better than mirroring your inbound transit, and sampling the output to a sensor. > > I have also spent some time on a spare server running netmap and influxdb, it simply could not keep up, nor could I write any useful queries against it. Which is why I'm deciding on using pf_ring ft (flow table) and just let it calculate all the data to be dumped into a MySQL memory table, and also harvesting ntop's NDPI protocol decoding, to enhance the detection rules. My ideal setup is to break things down into dedicated programs like flow exporter, detection, and response. > > I also want to make clear to Michel, that colo'ing a router at an ISP is no different than plugging it into your local router, your uplink will get saturated beyond what it can physically handle with only the ACLs protecting the other side, but if your clients are also receiving traffic on the same uplink as the attack, it's a denial of service to them. > > -----Original Message----- > From: NANOG On Behalf Of H I Baysal > Sent: Friday, August 31, 2018 2:09 AM > To: Michel Py ; Aaron Gould ; michel at arneill-py.sacramento.ca.us > Cc: Nanog at nanog.org > Subject: Re: automatic rtbh trigger using flow data > > Most of the solutions mentioned are paid, or fastnetmon is partially paid. And the thing you want is paid i believe.... > Nice tool though, not saying anything against it. However.... > > My personal view is, as long as you can store your flow info in a timeseries database (like influxdb and NOT SQL LIKE!!!!!!!) you can do whatever you want with the (raw) data. And create custom triggers for different calculations. > > Flows are on the fly and are coming in constantly, you could have a calculation like group by srcip and whatever protocol you want or just srcip, and make a calculation for every x seconds or minutes. As i mentioned the flow data is a constant stream, so you could have it triggered as fast as you want. > > (and the nice thing is, with sflow, you also get as path, peer as, localpref,community (if enabled). You could group by anything.. :) > > I admit it takes a bit more time to setup but the outcome is amazing ;) (especially if you graph it then with grafana) And in your case it would be a script that does a influxdb command to make the calculations and if the outcome shows an IP meeting the thresholds you have set in the calculation, you trigger a script that adjusts the route to be announced to your upstream with the correct > (rtbh) community. > ( as i mentioned, as long as you have the "raw" flows, you can do anything ) > > > Good luck, whatever you choose :) > > > On 31-08-18 02:14, Michel Py wrote: >>> Aaron Gould wrote : >>> I'm really surprised that you all are doing this based on source ip, >>> simply because I thought the distribution of botnet members around the world we're so extensive that I never really thought it possible to filter based on sources, if so I'd like to see the list too. >> I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP prefixes is nothing these days. I am not surprised that Joe pushes that to some CPEs. >> >>> Even so, this would not stop the attacks from hitting my front door, >>> my side of my Internet uplink...when paying for a 30 gigs CIR and >>> paying double for megabits per second over that, up to the ceiling of 100 gig every bit that hits my front door over 30 gig would cost me extra, remotely triggering based on my victim IP address inside my network would be my solution to saving money. >> I agree. If you want to get a real use of source blacklisting, to save bandwidth, you probably went to rent a U in a rack at your upstream(s) to block it there. >> I never did it past 1GE, and I have never measured seriously the bandwidth it would save, would be curious to know. >> I think the two approaches are complementary to each other though. >> >> Michel. >> >> >> On Aug 30, 2018, at 6:43 PM, Michel Py wrote: >> >>>> Joe Maimon wrote : >>>> I use a bunch of scripts plus a supervisory sqlite3 database process >>>> all injecting into quagga >>> I have the sqlite part planned, today I'm using a flat file :-( I >>> know :-( >>> >>>> Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts. Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity. >>> I would like to have your feed. How many attacker prefixes do you currently have ? >>> >>>> Using flow data, that sounds like an interesting direction to take this into, so thank you! >>> The one thing we can share here is the attacker prefixes. The victim prefixes are unique to each of us but I expect our attacker prefixes to be very close. >>> >>> Michel. >>> >>> TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From hugo at slabnet.com Fri Aug 31 15:15:35 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 31 Aug 2018 08:15:35 -0700 Subject: automatic rtbh trigger using flow data In-Reply-To: <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> Message-ID: <20180831151535.GB9210@bamboo.slabnet.com> On Fri 2018-Aug-31 06:59:29 +0700, Roland Dobbins wrote: >On 31 Aug 2018, at 6:47, Aaron Gould wrote: > >>I'm really surprised that you all are doing this based on source >>ip, simply because I thought the distribution of botnet members >>around the world we're so extensive that I never really thought it >>possible to filter based on sources, i > >Using S/RTBH to drop attack sources has been a valid and useful >mitigation tactic for close to 20 years. Any kind of modern router >scales up to large numbers of sources; and note that S/RTBH isn't >limited to /32s. > >It's discussed in this .pdf preso: > > I would love an upstream that accepts flowspec routes to get granular about drops and to basically push "stateless ACLs" upstream. _keeps dreaming_ -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From rdobbins at arbor.net Fri Aug 31 15:32:01 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 31 Aug 2018 22:32:01 +0700 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> Message-ID: On 31 Aug 2018, at 16:33, Ryan Hamel wrote: > From experience, sflows are horribly inaccurate for DDoS detection, > since the volume could disrupt the control plane and render the > process useless, thus not giving data to the external system to act > upon it. On the contrary, flow telemetry in general works quite well for DDoS detection/classification/traceback, and is widely utilized for such purposes; it has been for many years. I'm not a big fan of s/Flow comparatively speaking, but it and NetFlow, IPFIX, et. al. have proven themselves over the years, assuming that the flow export parameters on the exporting devices are configured correctly, and the collection/analysis systems are configured optimally. Flow telemetry is management-plane, not control-plane. Implementing network infrastructure self-protection BCPs such as iACLs is definitely recommended in general. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Fri Aug 31 15:42:59 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 31 Aug 2018 22:42:59 +0700 Subject: automatic rtbh trigger using flow data In-Reply-To: <20180831151535.GB9210@bamboo.slabnet.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> <20180831151535.GB9210@bamboo.slabnet.com> Message-ID: On 31 Aug 2018, at 22:15, Hugo Slabbert wrote: > I would love an upstream that accepts flowspec routes to get granular > about drops and to basically push "stateless ACLs" upstream. ----------------------------------- Roland Dobbins From Pratik.Lotia at charter.com Fri Aug 31 16:53:30 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Fri, 31 Aug 2018 16:53:30 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> Message-ID: Instead of rtbh I would suggest blocking/rate limiting common ports used in DDoS attacks. That will block 90% of the DDoS attacks. We recently open sourced a BGP Flowspec based tool for DDoS Mitigation. It applies Flowspec rules per victim IP Addr. https://github.com/racompton/docker-auto-flowspec ~Pratik Lotia -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of H I Baysal Sent: Friday, August 31, 2018 3:09 AM To: Michel Py; Aaron Gould; michel at arneill-py.sacramento.ca.us Cc: Nanog at nanog.org Subject: Re: automatic rtbh trigger using flow data Most of the solutions mentioned are paid, or fastnetmon is partially paid. And the thing you want is paid i believe.... Nice tool though, not saying anything against it. However.... My personal view is, as long as you can store your flow info in a timeseries database (like influxdb and NOT SQL LIKE!!!!!!!) you can do whatever you want with the (raw) data. And create custom triggers for different calculations. Flows are on the fly and are coming in constantly, you could have a calculation like group by srcip and whatever protocol you want or just srcip, and make a calculation for every x seconds or minutes. As i mentioned the flow data is a constant stream, so you could have it triggered as fast as you want. (and the nice thing is, with sflow, you also get as path, peer as, localpref,community (if enabled). You could group by anything.. :) I admit it takes a bit more time to setup but the outcome is amazing ;) (especially if you graph it then with grafana) And in your case it would be a script that does a influxdb command to make the calculations and if the outcome shows an IP meeting the thresholds you have set in the calculation, you trigger a script that adjusts the route to be announced to your upstream with the correct (rtbh) community. ( as i mentioned, as long as you have the "raw" flows, you can do anything ) Good luck, whatever you choose :) On 31-08-18 02:14, Michel Py wrote: >> Aaron Gould wrote : >> I'm really surprised that you all are doing this based on source ip, simply because I thought the distribution of botnet members around >> the world we're so extensive that I never really thought it possible to filter based on sources, if so I'd like to see the list too. > I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP prefixes is nothing these days. I am not surprised that Joe pushes that to some CPEs. > >> Even so, this would not stop the attacks from hitting my front door, my side of my Internet uplink...when paying for a 30 gigs CIR >> and paying double for megabits per second over that, up to the ceiling of 100 gig every bit that hits my front door over 30 gig >> would cost me extra, remotely triggering based on my victim IP address inside my network would be my solution to saving money. > I agree. If you want to get a real use of source blacklisting, to save bandwidth, you probably went to rent a U in a rack at your upstream(s) to block it there. > I never did it past 1GE, and I have never measured seriously the bandwidth it would save, would be curious to know. > I think the two approaches are complementary to each other though. > > Michel. > > > On Aug 30, 2018, at 6:43 PM, Michel Py wrote: > >>> Joe Maimon wrote : >>> I use a bunch of scripts plus a supervisory sqlite3 database process all injecting into quagga >> I have the sqlite part planned, today I'm using a flat file :-( I know :-( >> >>> Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts. Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity. >> I would like to have your feed. How many attacker prefixes do you currently have ? >> >>> Using flow data, that sounds like an interesting direction to take this into, so thank you! >> The one thing we can share here is the attacker prefixes. The victim prefixes are unique to each of us but I expect our attacker prefixes to be very close. >> >> Michel. >> >> TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From rdobbins at arbor.net Fri Aug 31 17:13:20 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 01 Sep 2018 00:13:20 +0700 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> Message-ID: On 31 Aug 2018, at 23:53, Lotia, Pratik M wrote: > Instead of rtbh I would suggest blocking/rate limiting common ports > used in DDoS attacks. This isn't an 'instead of', it's an 'in addition to'. And it must be done judiciously; many operators doing this have concentrated on common port-pairs observed in UDP reflection/amplification attacks. It's important to understand that any kind of packet of any protocol/ports (if such concepts apply on the protocol in question) can be used to launch DDoS attacks. We've many tools in the toolbox, and should use them in a situationally-appropriate manner. And when we're using techniques like QoSing down certain ports/protocols, we must err on the side of caution, lest we cause larger problems than the attacks themselves. ----------------------------------- Roland Dobbins From michel.py at tsisemi.com Fri Aug 31 17:38:04 2018 From: michel.py at tsisemi.com (Michel Py) Date: Fri, 31 Aug 2018 17:38:04 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> Message-ID: <48ca6e06f0e045469627ca0e47161ce3@CRA110.am.necel.com> > Ryan Hamel wrote : > I also want to make clear to Michel, that colo'ing a router at an ISP is no different than plugging it into your local router, your uplink will get saturated beyond what it can physically handle with only the ACLs protecting the other side, but if your clients are also receiving traffic on the same uplink as the attack, it's a denial of service to them. I understand, but there still is a difference : Bandwith inside the colo is cheaper than the WAN link; conceptually you could have multiple fat interfaces at the colo and hope to filter the unwanted traffic before it hits where it generally hurts : on the WAN link. Would save money only if the transit is billed separately from the WAN link traffic, and every situation is different. Michel. -----Original Message----- From: NANOG On Behalf Of H I Baysal Sent: Friday, August 31, 2018 2:09 AM To: Michel Py ; Aaron Gould ; michel at arneill-py.sacramento.ca.us Cc: Nanog at nanog.org Subject: Re: automatic rtbh trigger using flow data Most of the solutions mentioned are paid, or fastnetmon is partially paid. And the thing you want is paid i believe.... Nice tool though, not saying anything against it. However.... My personal view is, as long as you can store your flow info in a timeseries database (like influxdb and NOT SQL LIKE!!!!!!!) you can do whatever you want with the (raw) data. And create custom triggers for different calculations. Flows are on the fly and are coming in constantly, you could have a calculation like group by srcip and whatever protocol you want or just srcip, and make a calculation for every x seconds or minutes. As i mentioned the flow data is a constant stream, so you could have it triggered as fast as you want. (and the nice thing is, with sflow, you also get as path, peer as, localpref,community (if enabled). You could group by anything.. :) I admit it takes a bit more time to setup but the outcome is amazing ;) (especially if you graph it then with grafana) And in your case it would be a script that does a influxdb command to make the calculations and if the outcome shows an IP meeting the thresholds you have set in the calculation, you trigger a script that adjusts the route to be announced to your upstream with the correct (rtbh) community. ( as i mentioned, as long as you have the "raw" flows, you can do anything ) Good luck, whatever you choose :) On 31-08-18 02:14, Michel Py wrote: >> Aaron Gould wrote : >> I'm really surprised that you all are doing this based on source ip, >> simply because I thought the distribution of botnet members around the world we're so extensive that I never really thought it possible to filter based on sources, if so I'd like to see the list too. > I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP prefixes is nothing these days. I am not surprised that Joe pushes that to some CPEs. > >> Even so, this would not stop the attacks from hitting my front door, >> my side of my Internet uplink...when paying for a 30 gigs CIR and >> paying double for megabits per second over that, up to the ceiling of 100 gig every bit that hits my front door over 30 gig would cost me extra, remotely triggering based on my victim IP address inside my network would be my solution to saving money. > I agree. If you want to get a real use of source blacklisting, to save bandwidth, you probably went to rent a U in a rack at your upstream(s) to block it there. > I never did it past 1GE, and I have never measured seriously the bandwidth it would save, would be curious to know. > I think the two approaches are complementary to each other though. > > Michel. > > > On Aug 30, 2018, at 6:43 PM, Michel Py wrote: > >>> Joe Maimon wrote : >>> I use a bunch of scripts plus a supervisory sqlite3 database process >>> all injecting into quagga >> I have the sqlite part planned, today I'm using a flat file :-( I >> know :-( >> >>> Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts. Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity. >> I would like to have your feed. How many attacker prefixes do you currently have ? >> >>> Using flow data, that sounds like an interesting direction to take this into, so thank you! >> The one thing we can share here is the attacker prefixes. The victim prefixes are unique to each of us but I expect our attacker prefixes to be very close. >> >> Michel. >> >> TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From cscora at apnic.net Fri Aug 31 18:03:14 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Sep 2018 04:03:14 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180831180314.BAD54C450F@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 01 Sep, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 713837 Prefixes after maximum aggregation (per Origin AS): 273774 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 342471 Total ASes present in the Internet Routing Table: 61678 Prefixes per ASN: 11.57 Origin-only ASes present in the Internet Routing Table: 53258 Origin ASes announcing only one prefix: 23227 Transit ASes present in the Internet Routing Table: 8420 Transit-only ASes present in the Internet Routing Table: 263 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 59 Number of instances of unregistered ASNs: 59 Number of 32-bit ASNs allocated by the RIRs: 23898 Number of 32-bit ASNs visible in the Routing Table: 19283 Prefixes from 32-bit ASNs in the Routing Table: 80844 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 321 Number of addresses announced to Internet: 2855523908 Equivalent to 170 /8s, 51 /16s and 214 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 238618 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 194522 Total APNIC prefixes after maximum aggregation: 55387 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 192645 Unique aggregates announced from the APNIC address blocks: 79290 APNIC Region origin ASes present in the Internet Routing Table: 9034 APNIC Prefixes per ASN: 21.32 APNIC Region origin ASes announcing only one prefix: 2537 APNIC Region transit ASes present in the Internet Routing Table: 1348 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4001 Number of APNIC addresses announced to Internet: 767494915 Equivalent to 45 /8s, 191 /16s and 11 /24s 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, 64297-64395, 131072-139577 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: 212189 Total ARIN prefixes after maximum aggregation: 100386 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 211909 Unique aggregates announced from the ARIN address blocks: 100560 ARIN Region origin ASes present in the Internet Routing Table: 18219 ARIN Prefixes per ASN: 11.63 ARIN Region origin ASes announcing only one prefix: 6756 ARIN Region transit ASes present in the Internet Routing Table: 1808 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2419 Number of ARIN addresses announced to Internet: 1101112992 Equivalent to 65 /8s, 161 /16s and 166 /24s 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-399260 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: 195173 Total RIPE prefixes after maximum aggregation: 93190 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 191486 Unique aggregates announced from the RIPE address blocks: 113483 RIPE Region origin ASes present in the Internet Routing Table: 25451 RIPE Prefixes per ASN: 7.52 RIPE Region origin ASes announcing only one prefix: 11469 RIPE Region transit ASes present in the Internet Routing Table: 3514 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7357 Number of RIPE addresses announced to Internet: 714109312 Equivalent to 42 /8s, 144 /16s and 113 /24s 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, 64396-64495 196608-210331 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: 92401 Total LACNIC prefixes after maximum aggregation: 20612 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 93809 Unique aggregates announced from the LACNIC address blocks: 40895 LACNIC Region origin ASes present in the Internet Routing Table: 7499 LACNIC Prefixes per ASN: 12.51 LACNIC Region origin ASes announcing only one prefix: 2072 LACNIC Region transit ASes present in the Internet Routing Table: 1417 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5047 Number of LACNIC addresses announced to Internet: 172077344 Equivalent to 10 /8s, 65 /16s and 177 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 19492 Total AfriNIC prefixes after maximum aggregation: 4149 AfriNIC Deaggregation factor: 4.70 Prefixes being announced from the AfriNIC address blocks: 23667 Unique aggregates announced from the AfriNIC address blocks: 7969 AfriNIC Region origin ASes present in the Internet Routing Table: 1185 AfriNIC Prefixes per ASN: 19.97 AfriNIC Region origin ASes announcing only one prefix: 393 AfriNIC Region transit ASes present in the Internet Routing Table: 240 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 459 Number of AfriNIC addresses announced to Internet: 100272384 Equivalent to 5 /8s, 250 /16s and 9 /24s 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 4680 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4426 478 470 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2986 1154 90 VIETEL-AS-AP Viettel Group, VN 4766 2825 11135 768 KIXS-AS-KR Korea Telecom, KR 9829 2813 1495 541 BSNL-NIB National Internet Backbone, IN 45899 2712 1646 158 VNPT-AS-VN VNPT Corp, VN 9394 2549 4907 32 CTTNET China TieTong Telecommunications 17974 2262 962 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2255 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2121 417 204 TATACOMM-AS TATA Communications formerl 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 6327 3455 1324 83 SHAW - Shaw Communications Inc., CA 11492 3354 249 439 CABLEONE - CABLE ONE, INC., US 22773 3226 2970 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2279 4809 778 AMAZON-02 - Amazon.com, Inc., US 18566 2166 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2146 2677 506 CHARTER-NET-HKY-NC - Charter Communicat 209 2042 5085 605 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 2032 345 142 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 2004 1051 1469 AKAMAI-AS - Akamai Technologies, Inc., 7018 1771 20199 1282 ATT-INTERNET4 - AT&T Services, Inc., US 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 12479 4733 1613 125 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3081 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2560 620 1900 AKAMAI-ASN1, US 12389 2043 1893 733 ROSTELECOM-AS, RU 34984 2008 335 510 TELLCOM-AS, TR 9121 1819 1692 19 TTNET, TR 13188 1604 100 43 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1210 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5208 3349 607 Uninet S.A. de C.V., MX 10620 3490 532 455 Telmex Colombia S.A., CO 11830 2652 369 78 Instituto Costarricense de Electricidad 6503 1675 444 65 Axtel, S.A.B. de C.V., MX 7303 1430 953 206 Telecom Argentina S.A., AR 28573 1094 2231 192 CLARO S.A., BR 3816 1022 510 116 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 928 126 84 Alestra, S. de R.L. de C.V., MX 18881 916 1082 27 TELEF�NICA BRASIL S.A, BR 6147 884 377 31 Telefonica del Peru S.A.A., PE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1196 396 48 LINKdotNET-AS, EG 37611 896 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 746 1411 41 ETISALAT-MISR, EG 24835 641 818 18 RAYA-AS, EG 8452 578 1728 14 TE-AS TE-AS, EG 37492 474 470 57 ORANGE-, TN 29571 461 70 11 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 376 231 15 MauritiusTelecom, MU 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 8151 5208 3349 607 Uninet S.A. de C.V., MX 12479 4733 1613 125 UNI2-AS, ES 4538 4680 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4426 478 470 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3490 532 455 Telmex Colombia S.A., CO 6327 3455 1324 83 SHAW - Shaw Communications Inc., CA 11492 3354 249 439 CABLEONE - CABLE ONE, INC., US 22773 3226 2970 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3081 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 4733 4608 UNI2-AS, ES 4538 4680 4606 ERX-CERNET-BKB China Education and Research Net 7545 4426 3956 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3455 3372 SHAW - Shaw Communications Inc., CA 22773 3226 3077 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3081 3037 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 10620 3490 3035 Telmex Colombia S.A., CO 11492 3354 2915 CABLEONE - CABLE ONE, INC., US 7552 2986 2896 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 64500 DOCUMENT 45.43.56.0/24 135391 AOFEI-HK AOFEI DATA INTERNATIO 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 4200003000 PRIVATE 47.89.98.0/24 45102 CNNIC-ALIBABA-CN-NET-AP Alibab 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 45.121.32.0/22 134356 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:14 /9:11 /10:36 /11:99 /12:292 /13:567 /14:1094 /15:1893 /16:13357 /17:7938 /18:13818 /19:25388 /20:39498 /21:45678 /22:88576 /23:72247 /24:401135 /25:814 /26:617 /27:634 /28:35 /29:20 /30:19 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3485 4733 UNI2-AS, ES 6327 3244 3455 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2691 3354 CABLEONE - CABLE ONE, INC., US 8551 2543 3081 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2493 3226 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2060 2166 MEGAPATH5-US - MegaPath Corporation, US 11830 2001 2652 Instituto Costarricense de Electricidad y Telec 30036 1783 2032 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1581 3490 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1617 2:830 4:18 5:2832 6:43 7:1 8:1127 12:1873 13:210 14:1798 15:32 16:3 17:192 18:54 20:51 23:2455 24:2387 25:2 27:2493 31:1974 32:88 35:29 36:526 37:2904 38:1494 39:258 40:117 41:3201 42:705 43:1954 44:121 45:5447 46:3131 47:207 49:1341 50:1051 51:318 52:1088 54:368 55:1 56:11 57:38 58:1629 59:994 60:408 61:2116 62:1893 63:1790 64:5068 65:2205 66:4710 67:2669 68:1150 69:3341 70:1156 71:581 72:2215 74:2734 75:419 76:464 77:1642 78:1688 79:2255 80:1582 81:1399 82:1063 83:779 84:1034 85:2001 86:567 87:1349 88:908 89:2341 90:211 91:6424 92:1263 93:2380 94:2427 95:2961 96:935 97:355 98:925 99:135 100:86 101:989 102:192 103:18531 104:3527 105:216 106:771 107:1773 108:709 109:3316 110:1647 111:1794 112:1343 113:1304 114:1128 115:1616 116:1660 117:1776 118:2219 119:1656 120:1029 121:1041 122:2424 123:1729 124:1446 125:1923 128:1120 129:682 130:493 131:1653 132:730 133:191 134:1026 135:235 136:507 137:651 138:1926 139:680 140:479 141:741 142:847 143:1009 144:810 145:479 146:1241 147:738 148:1649 149:768 150:761 151:1101 152:828 153:323 154:1660 155:799 156:1441 157:801 158:660 159:1850 160:1324 161:825 162:2645 163:605 164:1083 165:1551 166:446 167:1208 168:3212 169:834 170:3875 171:491 172:1011 173:2096 174:983 175:795 176:2033 177:4024 178:2490 179:1283 180:2182 181:2419 182:2568 183:1248 184:1056 185:13986 186:3535 187:2470 188:2890 189:2041 190:8215 191:1358 192:9810 193:6119 194:5018 195:3988 196:2738 197:1613 198:5584 199:5931 200:7285 201:5005 202:10265 203:10285 204:4573 205:2892 206:3205 207:3210 208:3927 209:4074 210:3889 211:1997 212:3041 213:2817 214:1038 215:55 216:5999 217:2130 218:861 219:566 220:1811 221:997 222:974 223:1376 End of report From Pratik.Lotia at charter.com Fri Aug 31 18:20:05 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Fri, 31 Aug 2018 18:20:05 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> Message-ID: <07fa1a4b08284f978a88f670ba066d90@SC58MEXGP014.CORP.CHARTERCOM.com> >many operators doing this have concentrated on common >port-pairs observed in UDP reflection/amplification attacks. Yes, because that's a great starting point. > And when we're using techniques like >QoSing down certain ports/protocols, we must err on the side of caution, Arbor report mentions volumetric attacks using DNS, NTP form 75+% of the attacks. Then QoSing certain ports and protocols is the best way to start with. ~Pratik Lotia   -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Friday, August 31, 2018 11:13 AM To: NANOG list Subject: Re: automatic rtbh trigger using flow data On 31 Aug 2018, at 23:53, Lotia, Pratik M wrote: > Instead of rtbh I would suggest blocking/rate limiting common ports > used in DDoS attacks. This isn't an 'instead of', it's an 'in addition to'. And it must be done judiciously; many operators doing this have concentrated on common port-pairs observed in UDP reflection/amplification attacks. It's important to understand that any kind of packet of any protocol/ports (if such concepts apply on the protocol in question) can be used to launch DDoS attacks. We've many tools in the toolbox, and should use them in a situationally-appropriate manner. And when we're using techniques like QoSing down certain ports/protocols, we must err on the side of caution, lest we cause larger problems than the attacks themselves. ----------------------------------- Roland Dobbins E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From aaron1 at gvtc.com Fri Aug 31 18:35:29 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 31 Aug 2018 13:35:29 -0500 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> Message-ID: <000f01d44159$649d6b40$2dd841c0$@gvtc.com> (I think this is all about volumetric attacks btw...it's my belief that slow-and-low attacks are continually occurring and are going largely unnoticed...i'll speak for myself) Few years ago we began seeing certain ports used as attack vectors, thus we began our internet boundary policers for these ports... as time went on, we add to that list of ports. Some ports as we know, like dns, and I think ntp from time to time (dang, sorry, lol) are used in amplification, and so, we can't police legit ports too slowly or real stuff is affected... so that's what Roland probably meant by "judiciously" We also have inside this set of qos tools at the internet boundary, an ever-growing acl that we call "repeat victims"... we have grown to understand that, if a customer ip address is attack once, it's likely it will be attacked again... There are new attacked ports all the time, so sometimes, an attack gets through... which is causing me to think about an overall UDP limit on my internet boundary ports... since most attacks are udp-based*....furthermore, along with that overarching udp limit, I may mark internet-sourced-udp with a certain marking dscp/exp so that as it travels through my internet network, it will be the first to get dropped (? Wred ? work well for udp?) during congestion when an attack gets through -Aaron * btw, what can you experts tell me about tcp-based volumetric attacks... please help me to understand... does tcp have an inherent inability to ramp-up to massive speeds/loads with it's sliding window and must-rcv-ack-before sending more segments ?? I ask since I heard this years ago about tcp and I wonder if this is why -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Friday, August 31, 2018 12:13 PM To: NANOG list Subject: Re: automatic rtbh trigger using flow data On 31 Aug 2018, at 23:53, Lotia, Pratik M wrote: > Instead of rtbh I would suggest blocking/rate limiting common ports > used in DDoS attacks. This isn't an 'instead of', it's an 'in addition to'. And it must be done judiciously; many operators doing this have concentrated on common port-pairs observed in UDP reflection/amplification attacks. It's important to understand that any kind of packet of any protocol/ports (if such concepts apply on the protocol in question) can be used to launch DDoS attacks. We've many tools in the toolbox, and should use them in a situationally-appropriate manner. And when we're using techniques like QoSing down certain ports/protocols, we must err on the side of caution, lest we cause larger problems than the attacks themselves. ----------------------------------- Roland Dobbins From hugo at slabnet.com Fri Aug 31 18:43:04 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 31 Aug 2018 11:43:04 -0700 Subject: automatic rtbh trigger using flow data In-Reply-To: <000f01d44159$649d6b40$2dd841c0$@gvtc.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> <000f01d44159$649d6b40$2dd841c0$@gvtc.com> Message-ID: <20180831184304.GC9210@bamboo.slabnet.com> On Fri 2018-Aug-31 13:35:29 -0500, Aaron Gould wrote: >* btw, what can you experts tell me about tcp-based volumetric attacks... >please help me to understand... does tcp have an inherent inability to >ramp-up to massive speeds/loads with it's sliding window and >must-rcv-ack-before sending more segments ?? I ask since I heard this years >ago about tcp and I wonder if this is why UDP, depending on the application, can be reflected and amplified. Generally on the TCP side you can try SYN or ACK floods, but you're not going to get an amplified reflection. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From pawmal-nanog at freebsd.lublin.pl Fri Aug 31 23:51:22 2018 From: pawmal-nanog at freebsd.lublin.pl (=?utf-8?Q?Pawe=C5=82_Ma=C5=82achowski?=) Date: Sat, 1 Sep 2018 01:51:22 +0200 Subject: automatic rtbh trigger using flow data In-Reply-To: <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> Message-ID: <20180831235122.GA92097@lagoon.freebsd.lublin.pl> On Fri, Aug 31, 2018 at 11:09:19AM +0200, H I Baysal wrote: > My personal view is, as long as you can store your flow info in a > timeseries database (like influxdb and NOT SQL LIKE!!!!!!!) you can do > whatever you want with the (raw) data. And create custom triggers for > different calculations. For one of our customers I've deployed good old pmacct + MySQL (using memory engine) backend for DDoS detection purposes. It has some drawbacks (e.g. one has to frequently delete old records to keep tables fit and fast) but it allows asking complex SQL queries against these short term data (e.g. different detection logic per subnets) or precompute with triggers. > Flows are on the fly and are coming in constantly, you could have a > calculation like group by srcip and whatever protocol you want or just > srcip, Beware of high cardinality issues when facing random src IP floods. BTW, once again pmacct (with some glue) is nice for feeding flow data into time series database. It can pre aggregate and pre filter low volume flows to reduce storage requirements. -- Paweł Małachowski