From merculiani at gmail.com Mon Jul 2 19:25:03 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Mon, 2 Jul 2018 14:25:03 -0500 Subject: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks) In-Reply-To: References: <004101d40e35$c2daed10$4890c730$@netconsultings.com> Message-ID: Unfortunately, like many other industry terms, "open" is becoming a meaningless marketing buzzword much like "cloud", "converged", even "redundancy" or any other technical term that has had its definition diluted as time goes on. We're all well aware on the ISP side that it only takes one Fortune 500 to start using a buzzword incorrectly, then the rest of the big guys all the way to mom and pop shops around the world start using it in the same context. Unfortunately I don't see any end to this trend in sight. "...fingerprints is took, days is lost, bail is made, court dates are ignored, cycle is repeated." - Early Cuyler -Matt On Thu, Jun 28, 2018 at 11:29 AM, Tails Pipes wrote: > No, things changed there as well. Lookup merchant sillicon, and revise this > post every 6 months. have you heard of Barefoot networks? The days of ASICs > from Cisco are gone and we are glad, we tested the P4 DSL (cisco never got > that right with mantel) on Nexus and its wonderful. > > The asics you speak of are no longer important or valuable because people > realized that in many networking planets and galaxies, the asic is reflects > the network design, they are related, and specifically for the data center, > the clos fabric design won, and that does not require fancy asics. > I guess your knowledge is out dated a bit. Cisco itself is using those > merchant sillicon ASICs happily. (lookup Chuck's comments on nexus9000, > best selling cisco switch ever)...guess it is a good switch, because bright > box pushed cisco to do that, and if any one on this list can disagree with > me here, i'm up to that challenge. > > What i have discovered recently is that things happen in following way. > > Your boss or his boss picks a work culture (no one gets fired for buying > IBM/Cisco), that culture (buying the shiny suits) impacts how you do work, > it makes you select vendors (the ones that sends me to vegas every year) > and not the right network design, you select cisco and you are stuck there > for life, because once they tell you how things should work (aka : > certificates), things are worse, now every time you make a new network > purchase (afraid of new CLI ), you will not be able to look the other way > because you just dont know any thing else (and loosing your certificate > value). > > I wish the culture would change to, no one got fired for buying closed but > didnt get promoted either. change requires boldness. > > https://toolr.io/2018/06/18/stop-abusing-the-word-open/ > > > > On Wed, Jun 27, 2018 at 9:41 AM, wrote: > >> > Tails Pipes >> > Sent: Friday, June 22, 2018 3:00 PM >> > >> > can you easily answer this question ? why packets are not pushed in >> linux ? >> > is it because of big switch, cumulus, pica8 ? >> > >> > can you push packets in linux without writing code to do that ? who is >> writing >> > that code ? >> > >> > this is supposedly a community effort, something that older generations >> > dont understand. >> > >> If pure linux as NOS has some legs it'll fly regardless of cisco blessing, >> don't worry no single company owns the whole industry. >> Also we can argue that this is only about the OS but in reality it's also >> the quality of apps running on top and the quality of the underlying HW >> that plays a major role. >> The quality of BGP app for instance, or the ability of the forwarding ASIC >> to deliver the stated pps rate even if multiple features are enabled or >> protect high priority traffic even if ASIC is overloaded. >> >> >> Oh and with regards to: >> < I am sick of having to learn all the cisco specific terms to all sorts >> of different boxes and technologies >> I'd recommend you read all the cisco books on networking to get yourself >> educated on the topic and to get the difference between SW and HW >> forwarding ( -on why packets are not routed in linux) >> And while on that I suggest you read all Stanford university lectures on >> how routers work too, it'll help you understand why Cisco and Juniper ASICs >> are so much more expensive than white-box ASICs. >> >> adam >> >> netconsultings.com >> ::carrier-class solutions for the telecommunications industry:: >> >> >> From Jeroen.Wunnink at gtt.net Tue Jul 3 16:06:05 2018 From: Jeroen.Wunnink at gtt.net (Jeroen Wunnink) Date: Tue, 3 Jul 2018 16:06:05 +0000 Subject: NANOG73 - moar power outlets Message-ID: I might’ve missed someone mentioning it already, but a small request to the team organizing the NANOG events: Can we get a few power strips on the tables around the general seating area next time? I’ve been hunting for a free outlet multiple times last week. Getting a charge going was a bit of a challenge. Jeroen Wunnink Integration Engineering Manager www.gtt.net [id:image001.png at 01D37331.D1301F60] From frnkblk at iname.com Tue Jul 3 22:38:32 2018 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 3 Jul 2018 17:38:32 -0500 Subject: Looking for Incapsula contact Message-ID: <002301d4131e$927bcac0$b7736040$@iname.com> Emails to NOC have gone unanswered (I did have success with that a year or two ago). Have had a handful of business customers in the last week contact us about B2B web sites they can't reach anymore ... of the eight documented websites, five are using Incapusla address space and others might be using Incapusla's service. Packet traces are showing the remote (web) site is issuing a TCP RST. Frank CTO, Premier Communications From sandy at tislabs.com Thu Jul 5 15:11:02 2018 From: sandy at tislabs.com (Sandra Murphy) Date: Thu, 5 Jul 2018 11:11:02 -0400 Subject: videos from NANOG73? Message-ID: <6B900082-6FC0-4387-B732-7D6682C3A02C@tislabs.com> The agenda for NANOG73 is still on the cevent site. The links for slides all seem to be there, which is good. But only the sessions on Monday morning have links for the videos. I hope that’s not due to a taping failure. I looked in the archive, and the presentations from NANOG73 aren’t there. Understandable. It does look like they are available on youtube. Can you let me know when the videos will be available on the nanog site? I like to point people to the nanog site, so they can get everything, past, present and future, mail, videos, slides, etc, all together. —Sandy From mark.tinka at seacom.mu Wed Jul 4 17:32:16 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 4 Jul 2018 19:32:16 +0200 Subject: SAFNOG-4 + EANOG, tzNOG & TISPA Call for Papers! - Update! In-Reply-To: <1450bc08-1a9e-d732-7a98-336a2a93fb8e@seacom.mu> References: <1450bc08-1a9e-d732-7a98-336a2a93fb8e@seacom.mu> Message-ID: <1a07f696-dc5c-2ce2-9046-e1e9b310002f@seacom.mu> As an update: Please note you can submit your papers at the URL below:     https://papers.safnog.org/user/login.php?event=76 Mark. On 4/Jul/18 14:45, Mark Tinka wrote: > Hello all. > > The SAFNOG-4/EANOG/tzNOG Programme Committee are now seeking > contributions for Presentations and Tutorials for the > SAFNOG-4/EANOG/tzNOG 2018 Conference. > > We are looking for presenters who would: > >     - Offer a technical tutorial on an appropriate topic; >     - Participate in the technical conference sessions as a speaker; >     - Convene and chair panel sessions of relevant topics. > >                                         *Conference Milestones* >                     Call for Papers Opens                 Now >                     Draft Program Published             As papers are > confirmed >                     Final Deadline for Submissions    10 September, > 2018   >                     Final Program Published             17 September, 2018 >                     Final Slides Received                  21 > September, 2018 > > NOTE THAT REGARDLESS OF DEADLINES, SLOTS ARE FILLED ON A FIRST COME, > FIRST SERVED BASIS > > *Program Material* > > The SAFNOG-4/EANOG/tzNOG Conference Programme consists of two parts, > these being the Tutorials and Conference Tracks. > > Topics proposed must be relevant to Internet Operations and Technologies: > >     - IPv4 / IPv6 Routing and Operations >     - IPv6 deployment and transition technologies >     - Internet backbone operations >     - ISP and Carrier services >     - IXPs and Peering >     - Research on Internet Operations and Deployment >     - Software Defined Networking / Network Function Virtualisaton >     - Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware) >     - DNS / DNSSEC >     - Internet policy (Security, Regulation, Content Management, > Addressing, etc) >     - Access and Transport Technologies, including Cable/DSL, LTE/5G, > wireless, metro ethernet, fibre, segment routing >     - Content & Service Delivery (Multicast, Voice, Video, > "telepresence", Gaming) and Cloud Computing > > *CfP Submissions* > > Draft slides for both tutorials and conference sessions MUST be > provided with CfP submissions otherwise the Programme Committee will > be unable to review the submission. For avoidance of doubt this means > that submissions which do not include slides will be rejected > immediately. For work in progress, the most current information > available at time of submission is acceptable. > > All draft and complete slides must be submitted in PDF format only > > Final slides are to be provided by the specified deadline for > publication on the SAFNOG-4/EANOG/tzNOG websites. > > Prospective presenters should note that the majority of speaking slots > will be filled well before the final submission deadline. The PC may, > at their discretion, retain a limited number of slots up to the final > submission deadline for presentations that are exceptionally timely, > important, or of critical operational importance. Every year we turn > away submissions, due to filling up all available programme slots > before the deadline. Presenters should endeavour to get material into > the PC sooner rather than later. > > Any questions or concerns should be addressed to the Programme > Committee by e-mail at: > >                                             *pc-chairs at safnog.org* > > We look forward to receiving your presentation proposals. > > Cheers, > > Mark Tinka > On Behalf of the SAFNOG/EANOG/tzNOG Organizing Committee From sandy at tislabs.com Thu Jul 5 18:13:03 2018 From: sandy at tislabs.com (Sandra Murphy) Date: Thu, 5 Jul 2018 14:13:03 -0400 Subject: videos from NANOG73? In-Reply-To: <6B900082-6FC0-4387-B732-7D6682C3A02C@tislabs.com> References: <6B900082-6FC0-4387-B732-7D6682C3A02C@tislabs.com> Message-ID: <365FB3EA-27E1-4B51-BDAD-C5C54B1BA81B@tislabs.com> Apologies. I fell victim to autocomplete. I did not mean that query to go to the whole list. I’ve forwarded appropriately. —Sandy > On Jul 5, 2018, at 11:11 AM, Sandra Murphy wrote: > > The agenda for NANOG73 is still on the cevent site. The links for slides all seem to be there, which is good. > > But only the sessions on Monday morning have links for the videos. > > I hope that’s not due to a taping failure. > > I looked in the archive, and the presentations from NANOG73 aren’t there. Understandable. > > It does look like they are available on youtube. > > Can you let me know when the videos will be available on the nanog site? I like to point people to the nanog site, so they can get everything, past, present and future, mail, videos, slides, etc, all together. > > —Sandy > From matthew at corp.crocker.com Thu Jul 5 19:46:19 2018 From: matthew at corp.crocker.com (Matthew Crocker) Date: Thu, 5 Jul 2018 19:46:19 +0000 Subject: BGP Communities Message-ID: Hello, I’m just getting started setting up communities for my network. Is there any standard convention for community numbering (*:666 for RTBH for example)? I’ve looked at some examples from other carriers and it looks like everyone does their own thing. -Matt -- Matthew Crocker Crocker Communications, Inc. President From job at ntt.net Thu Jul 5 20:13:31 2018 From: job at ntt.net (Job Snijders) Date: Thu, 5 Jul 2018 22:13:31 +0200 Subject: BGP Communities In-Reply-To: References: Message-ID: On Thu, 5 Jul 2018 at 21:47, Matthew Crocker wrote: > I’m just getting started setting up communities for my network. Is there > any standard convention for community numbering (*:666 for RTBH for > example)? I’ve looked at some examples from other carriers and it looks > like everyone does their own thing. Everyone does their own thing and I think that is a good thing. Just make sure you properly publicly document what communities mean to you. For some inspiration on communities you could take a look at RFC 8195. Kind regards, Job From chip at 2bithacker.net Thu Jul 5 20:16:25 2018 From: chip at 2bithacker.net (Chip Marshall) Date: Thu, 5 Jul 2018 15:16:25 -0500 Subject: BGP Communities In-Reply-To: References: Message-ID: I think it's generally pretty free form, however I just wanted to note that RTBH has a well known community of 65535:666 now, from RFC 7999. On Thu, Jul 5, 2018 at 2:46 PM, Matthew Crocker wrote: > > Hello, > > I’m just getting started setting up communities for my network. Is there > any standard convention for community numbering (*:666 for RTBH for > example)? I’ve looked at some examples from other carriers and it looks > like everyone does their own thing. > > -Matt > > -- > Matthew Crocker > Crocker Communications, Inc. > President > -- Chip Marshall http://2bithacker.net/ From sfisher at cymru.com Thu Jul 5 19:17:19 2018 From: sfisher at cymru.com (Scott Fisher) Date: Thu, 5 Jul 2018 15:17:19 -0400 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: Message-ID: Youssef & all, My team will investigate this and get back to the list on what we are going to do. Thanks, Scott Fisher Systems Engineer Team Cymru On 6/28/18 3:11 PM, Youssef Bengelloun-Zahr wrote: > Hello Job, > > Thank you for this feedback. I guess that NTT adopting this as a best practice will ring some bells around. > > Do you know if Team Cymru has updated their filters accordingly ? > > Best regards. > > > >> Le 28 juin 2018 à 20:58, Job Snijders a écrit : >> >> Dear alll, >> >> Thank you all for your input. Just a heads-up - we deployed a few days ago. >> >> NTT / AS 2914 now considers “2002::/16 le 128” and “192.88.99.0/24 le 32” >> to be bogon prefixes, and no longer accepts announcements for these >> destinations from any EBGP neighbor. >> >> Kind regards, >> >> Job -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: OpenPGP digital signature URL: From bengelly at gmail.com Fri Jul 6 13:42:35 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Fri, 6 Jul 2018 15:42:35 +0200 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: Message-ID: <2B62AC55-F31F-4FBE-BC34-01B9CA5C50B3@gmail.com> Hello Scott, I believe Gary has already provided the community with an official answer yesterday on Team Cymru’s behalf. Best regards. > Le 5 juil. 2018 à 21:17, Scott Fisher a écrit : > > Youssef & all, > > My team will investigate this and get back to the list on what we are > going to do. > > Thanks, > Scott Fisher > Systems Engineer > Team Cymru > > > On 6/28/18 3:11 PM, Youssef Bengelloun-Zahr wrote: >> Hello Job, >> >> Thank you for this feedback. I guess that NTT adopting this as a best practice will ring some bells around. >> >> Do you know if Team Cymru has updated their filters accordingly ? >> >> Best regards. >> >> >> >>> Le 28 juin 2018 à 20:58, Job Snijders a écrit : >>> >>> Dear alll, >>> >>> Thank you all for your input. Just a heads-up - we deployed a few days ago. >>> >>> NTT / AS 2914 now considers “2002::/16 le 128” and “192.88.99.0/24 le 32” >>> to be bogon prefixes, and no longer accepts announcements for these >>> destinations from any EBGP neighbor. >>> >>> Kind regards, >>> >>> Job > From gmcartor at cymru.com Fri Jul 6 14:43:29 2018 From: gmcartor at cymru.com (Gary McArtor) Date: Fri, 6 Jul 2018 09:43:29 -0500 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <79091a9a-3ddf-6d14-84d4-0931510ae430@cymru.com> References: <79091a9a-3ddf-6d14-84d4-0931510ae430@cymru.com> Message-ID: Hi Youssef, My original reply wasn't sent to the Nanog list. Team Cymru considers 2002::/16 and 192.88.99.0/24 to be legitimate prefixes at this time, and will be not be adding them to our bogon filters. Our interpretation of the 6to4 anycast rfc is that while these are encouraged to be made obsolete, in practice they may still be in use, excluding them from being universally defined as a bogon in our feed. The RFC in question: https://tools.ietf.org/html/rfc7526 The rule, as it always should be, is to know your network, and know what is best for it. As noted in the RFC you are encouraged to review any current deployments and any existing filtering and adjust based on your own discretion. Regards, Gary McArtor Team Cymru On 6/28/18 2:32 PM, Rabbi Rob Thomas wrote: > FYI, the question has been raised. I'm not sure if this is wise or not. > Gary, what are your thoughts? > > > -------- Forwarded Message -------- > Subject: Re: Time to add 2002::/16 to bogon filters? > Date: Thu, 28 Jun 2018 21:11:22 +0200 > From: Youssef Bengelloun-Zahr > To: Job Snijders > CC: NANOG [nanog at nanog.org] > > Hello Job, > > Thank you for this feedback. I guess that NTT adopting this as a best > practice will ring some bells around. > > Do you know if Team Cymru has updated their filters accordingly ? > > Best regards. > > > >> Le 28 juin 2018 à 20:58, Job Snijders a écrit : >> >> Dear alll, >> >> Thank you all for your input. Just a heads-up - we deployed a few days ago. >> >> NTT / AS 2914 now considers “2002::/16 le 128” and “192.88.99.0/24 le 32” >> to be bogon prefixes, and no longer accepts announcements for these >> destinations from any EBGP neighbor. >> >> Kind regards, >> >> Job > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From cscora at apnic.net Fri Jul 6 18:03:06 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Jul 2018 04:03:06 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180706180306.0D9BFC450F@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 07 Jul, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 704783 Prefixes after maximum aggregation (per Origin AS): 270812 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 338899 Total ASes present in the Internet Routing Table: 61158 Prefixes per ASN: 11.52 Origin-only ASes present in the Internet Routing Table: 52832 Origin ASes announcing only one prefix: 23031 Transit ASes present in the Internet Routing Table: 8326 Transit-only ASes present in the Internet Routing Table: 275 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 38 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 58 Number of instances of unregistered ASNs: 62 Number of 32-bit ASNs allocated by the RIRs: 23201 Number of 32-bit ASNs visible in the Routing Table: 18695 Prefixes from 32-bit ASNs in the Routing Table: 78406 Number of bogon 32-bit ASNs visible in the Routing Table: 23 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 271 Number of addresses announced to Internet: 2859095363 Equivalent to 170 /8s, 106 /16s and 85 /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: 98.9 Total number of prefixes smaller than registry allocations: 235229 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 192058 Total APNIC prefixes after maximum aggregation: 54723 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 190609 Unique aggregates announced from the APNIC address blocks: 78232 APNIC Region origin ASes present in the Internet Routing Table: 8931 APNIC Prefixes per ASN: 21.34 APNIC Region origin ASes announcing only one prefix: 2523 APNIC Region transit ASes present in the Internet Routing Table: 1338 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3898 Number of APNIC addresses announced to Internet: 768180738 Equivalent to 45 /8s, 201 /16s and 130 /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: 209516 Total ARIN prefixes after maximum aggregation: 99769 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209831 Unique aggregates announced from the ARIN address blocks: 99691 ARIN Region origin ASes present in the Internet Routing Table: 18195 ARIN Prefixes per ASN: 11.53 ARIN Region origin ASes announcing only one prefix: 6728 ARIN Region transit ASes present in the Internet Routing Table: 1806 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2374 Number of ARIN addresses announced to Internet: 1103021728 Equivalent to 65 /8s, 190 /16s and 198 /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: 192989 Total RIPE prefixes after maximum aggregation: 92133 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 189192 Unique aggregates announced from the RIPE address blocks: 112187 RIPE Region origin ASes present in the Internet Routing Table: 25262 RIPE Prefixes per ASN: 7.49 RIPE Region origin ASes announcing only one prefix: 11379 RIPE Region transit ASes present in the Internet Routing Table: 3496 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7146 Number of RIPE addresses announced to Internet: 716014976 Equivalent to 42 /8s, 173 /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: 91266 Total LACNIC prefixes after maximum aggregation: 20116 LACNIC Deaggregation factor: 4.54 Prefixes being announced from the LACNIC address blocks: 92679 Unique aggregates announced from the LACNIC address blocks: 40775 LACNIC Region origin ASes present in the Internet Routing Table: 7301 LACNIC Prefixes per ASN: 12.69 LACNIC Region origin ASes announcing only one prefix: 2012 LACNIC Region transit ASes present in the Internet Routing Table: 1355 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 38 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4841 Number of LACNIC addresses announced to Internet: 172321824 Equivalent to 10 /8s, 69 /16s and 108 /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: 18895 Total AfriNIC prefixes after maximum aggregation: 4021 AfriNIC Deaggregation factor: 4.70 Prefixes being announced from the AfriNIC address blocks: 22201 Unique aggregates announced from the AfriNIC address blocks: 7773 AfriNIC Region origin ASes present in the Internet Routing Table: 1165 AfriNIC Prefixes per ASN: 19.06 AfriNIC Region origin ASes announcing only one prefix: 389 AfriNIC Region transit ASes present in the Internet Routing Table: 232 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 436 Number of AfriNIC addresses announced to Internet: 99110400 Equivalent to 5 /8s, 232 /16s and 78 /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 4692 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4341 466 458 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2897 1153 77 VIETEL-AS-AP Viettel Group, VN 4766 2842 11134 759 KIXS-AS-KR Korea Telecom, KR 9829 2813 1497 543 BSNL-NIB National Internet Backbone, IN 45899 2639 1633 114 VNPT-AS-VN VNPT Corp, VN 9394 2542 4907 31 CTTNET China TieTong Telecommunications 17974 2259 930 70 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2241 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2111 417 205 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 3420 1324 84 SHAW - Shaw Communications Inc., CA 22773 3291 2968 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2391 241 473 CABLEONE - CABLE ONE, INC., US 16509 2222 4721 734 AMAZON-02 - Amazon.com, Inc., US 18566 2169 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2110 2579 473 CHARTER-NET-HKY-NC - Charter Communicat 209 2037 5070 611 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 2000 343 161 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 1951 978 1387 AKAMAI-AS - Akamai Technologies, Inc., 7018 1751 20203 1272 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 4458 1607 120 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2609 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2546 627 1875 AKAMAI-ASN1, US 12389 2014 1877 708 ROSTELECOM-AS, RU 34984 2014 335 497 TELLCOM-AS, TR 9121 1887 1692 19 TTNET, TR 13188 1601 100 43 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1226 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 4999 3307 583 Uninet S.A. de C.V., MX 10620 3565 542 251 Telmex Colombia S.A., CO 11830 2655 369 78 Instituto Costarricense de Electricidad 6503 1666 443 60 Axtel, S.A.B. de C.V., MX 7303 1506 1026 190 Telecom Argentina S.A., AR 28573 1036 2247 183 CLARO S.A., BR 3816 1008 505 129 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 932 377 31 Telefonica del Peru S.A.A., PE 11172 927 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 1157 396 48 LINKdotNET-AS, EG 37611 881 107 9 Afrihost, ZA 36903 768 386 135 MT-MPLS, MA 36992 750 1411 39 ETISALAT-MISR, EG 8452 605 1730 18 TE-AS TE-AS, EG 24835 572 802 18 RAYA-AS, EG 37492 472 470 57 ORANGE-, TN 29571 454 68 11 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 15399 374 39 8 WANANCHI-, KE 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 4999 3307 583 Uninet S.A. de C.V., MX 4538 4692 4192 74 ERX-CERNET-BKB China Education and Rese 12479 4458 1607 120 UNI2-AS, ES 7545 4341 466 458 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3565 542 251 Telmex Colombia S.A., CO 6327 3420 1324 84 SHAW - Shaw Communications Inc., CA 22773 3291 2968 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2897 1153 77 VIETEL-AS-AP Viettel Group, VN 4766 2842 11134 759 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 4692 4618 ERX-CERNET-BKB China Education and Research Net 12479 4458 4338 UNI2-AS, ES 7545 4341 3883 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3420 3336 SHAW - Shaw Communications Inc., CA 10620 3565 3314 Telmex Colombia S.A., CO 22773 3291 3143 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2897 2820 VIETEL-AS-AP Viettel Group, VN 11830 2655 2577 Instituto Costarricense de Electricidad y Telec 8551 2609 2566 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 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 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 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65544 DOCUMENT 103.197.121.0/24 65542 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 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:37 /11:99 /12:290 /13:568 /14:1097 /15:1895 /16:13357 /17:7931 /18:13762 /19:25283 /20:39373 /21:45607 /22:87636 /23:71053 /24:394662 /25:794 /26:558 /27:627 /28:35 /29:20 /30:18 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3207 3420 SHAW - Shaw Communications Inc., CA 12479 3205 4458 UNI2-AS, ES 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2551 3291 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2071 2609 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2062 2169 MEGAPATH5-US - MegaPath Corporation, US 11830 2004 2655 Instituto Costarricense de Electricidad y Telec 11492 1914 2391 CABLEONE - CABLE ONE, INC., US 30036 1752 2000 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1612 3565 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:1608 2:844 4:18 5:2813 6:41 7:1 8:1121 12:1871 13:201 14:1756 15:30 16:3 17:188 18:54 20:49 23:2641 24:2217 25:2 27:2436 31:2028 32:92 35:27 36:501 37:2780 38:1461 39:253 40:121 41:3068 42:679 43:1917 44:120 45:4958 46:3049 47:202 49:1332 50:1048 51:316 52:1069 54:371 55:5 56:12 57:39 58:1600 59:988 60:403 61:2105 62:1859 63:1790 64:5032 65:2199 66:4659 67:2437 68:1167 69:3228 70:1159 71:572 72:2113 74:2707 75:422 76:457 77:1546 78:1716 79:1682 80:1521 81:1379 82:1079 83:792 84:1067 85:2011 86:565 87:1321 88:932 89:2346 90:212 91:6409 92:1241 93:2369 94:2392 95:2899 96:755 97:357 98:946 99:133 100:85 101:1223 102:130 103:18144 104:3555 105:211 106:671 107:1779 108:698 109:3379 110:1604 111:1772 112:1303 113:1281 114:1130 115:1662 116:1647 117:1757 118:2200 119:1660 120:993 121:1056 122:2468 123:1783 124:1446 125:1911 128:1086 129:673 130:458 131:1622 132:699 133:195 134:1015 135:225 136:501 137:564 138:1987 139:652 140:465 141:727 142:799 143:1003 144:803 145:482 146:1197 147:720 148:1638 149:754 150:737 151:1100 152:792 153:317 154:1265 155:771 156:1133 157:803 158:653 159:1742 160:1194 161:784 162:2589 163:593 164:1080 165:1507 166:450 167:1302 168:3099 169:816 170:3814 171:470 172:1080 173:1982 174:907 175:771 176:1987 177:4042 178:2535 179:1230 180:2175 181:2325 182:2367 183:1226 184:1032 185:13772 186:3634 187:2387 188:2848 189:2057 190:8137 191:1393 192:9822 193:5997 194:4866 195:3980 196:2595 197:1586 198:5529 199:5895 200:7325 201:4983 202:10241 203:10234 204:4583 205:2900 206:3097 207:3162 208:3986 209:3965 210:3883 211:1978 212:3015 213:2770 214:984 215:57 216:6029 217:2119 218:856 219:576 220:1778 221:984 222:970 223:1297 End of report From tom at cloudflare.com Fri Jul 6 19:18:05 2018 From: tom at cloudflare.com (Tom Paseka) Date: Fri, 6 Jul 2018 12:18:05 -0700 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <20180626172218.GK5413@vurt.meerval.net> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> Message-ID: Hi, I've been casually observing the connectivity to Bitcanal / AS3266 / AS197426 since the thread started. After GTT shared that bitcanal had been disconnected, bitcanal was only visible behind Cogent. But the Cogent path now also seems to have been disconnected. After Cogent they popped up behind BICS (but just for a few days), that circuit seems to have been disconnected too. On the IX front: I noticed that Bitcanal's IP addresses on LINX (since yesterday) and FranceIX (since today) are no longer responding. It is good to see that discussing BGP hijacking abuse complaints actually results in clean up activities. I hope the remaining IX's they're still connected to can act too. Thanks! -Tom From marcusleskex at gmail.com Sat Jul 7 14:57:49 2018 From: marcusleskex at gmail.com (Marcus Leske) Date: Sat, 7 Jul 2018 07:57:49 -0700 Subject: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks) In-Reply-To: References: <004101d40e35$c2daed10$4890c730$@netconsultings.com> Message-ID: 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. opinions ? danke, markus On Mon, Jul 2, 2018 at 12:25 PM, Matt Erculiani wrote: > Unfortunately, like many other industry terms, "open" is becoming a > meaningless marketing buzzword much like "cloud", "converged", even > "redundancy" or any other technical term that has had its definition > diluted as time goes on. We're all well aware on the ISP side that it > only takes one Fortune 500 to start using a buzzword incorrectly, then > the rest of the big guys all the way to mom and pop shops around the > world start using it in the same context. Unfortunately I don't see > any end to this trend in sight. > > "...fingerprints is took, days is lost, bail is made, court > dates are ignored, cycle is repeated." > - Early Cuyler > > -Matt > > On Thu, Jun 28, 2018 at 11:29 AM, Tails Pipes wrote: >> No, things changed there as well. Lookup merchant sillicon, and revise this >> post every 6 months. have you heard of Barefoot networks? The days of ASICs >> from Cisco are gone and we are glad, we tested the P4 DSL (cisco never got >> that right with mantel) on Nexus and its wonderful. >> >> The asics you speak of are no longer important or valuable because people >> realized that in many networking planets and galaxies, the asic is reflects >> the network design, they are related, and specifically for the data center, >> the clos fabric design won, and that does not require fancy asics. >> I guess your knowledge is out dated a bit. Cisco itself is using those >> merchant sillicon ASICs happily. (lookup Chuck's comments on nexus9000, >> best selling cisco switch ever)...guess it is a good switch, because bright >> box pushed cisco to do that, and if any one on this list can disagree with >> me here, i'm up to that challenge. >> >> What i have discovered recently is that things happen in following way. >> >> Your boss or his boss picks a work culture (no one gets fired for buying >> IBM/Cisco), that culture (buying the shiny suits) impacts how you do work, >> it makes you select vendors (the ones that sends me to vegas every year) >> and not the right network design, you select cisco and you are stuck there >> for life, because once they tell you how things should work (aka : >> certificates), things are worse, now every time you make a new network >> purchase (afraid of new CLI ), you will not be able to look the other way >> because you just dont know any thing else (and loosing your certificate >> value). >> >> I wish the culture would change to, no one got fired for buying closed but >> didnt get promoted either. change requires boldness. >> >> https://toolr.io/2018/06/18/stop-abusing-the-word-open/ >> >> >> >> On Wed, Jun 27, 2018 at 9:41 AM, wrote: >> >>> > Tails Pipes >>> > Sent: Friday, June 22, 2018 3:00 PM >>> > >>> > can you easily answer this question ? why packets are not pushed in >>> linux ? >>> > is it because of big switch, cumulus, pica8 ? >>> > >>> > can you push packets in linux without writing code to do that ? who is >>> writing >>> > that code ? >>> > >>> > this is supposedly a community effort, something that older generations >>> > dont understand. >>> > >>> If pure linux as NOS has some legs it'll fly regardless of cisco blessing, >>> don't worry no single company owns the whole industry. >>> Also we can argue that this is only about the OS but in reality it's also >>> the quality of apps running on top and the quality of the underlying HW >>> that plays a major role. >>> The quality of BGP app for instance, or the ability of the forwarding ASIC >>> to deliver the stated pps rate even if multiple features are enabled or >>> protect high priority traffic even if ASIC is overloaded. >>> >>> >>> Oh and with regards to: >>> < I am sick of having to learn all the cisco specific terms to all sorts >>> of different boxes and technologies >>> I'd recommend you read all the cisco books on networking to get yourself >>> educated on the topic and to get the difference between SW and HW >>> forwarding ( -on why packets are not routed in linux) >>> And while on that I suggest you read all Stanford university lectures on >>> how routers work too, it'll help you understand why Cisco and Juniper ASICs >>> are so much more expensive than white-box ASICs. >>> >>> adam >>> >>> netconsultings.com >>> ::carrier-class solutions for the telecommunications industry:: >>> >>> >>> From list-nanog at beufa.net Mon Jul 9 13:21:31 2018 From: list-nanog at beufa.net (Fabien VINCENT (NaNOG)) Date: Mon, 09 Jul 2018 15:21:31 +0200 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: <79091a9a-3ddf-6d14-84d4-0931510ae430@cymru.com> Message-ID: <309924460d81f400120550b836ae53a8@beufa.net> Le 2018-07-06 16:43, Gary McArtor a écrit : > Hi Youssef, > > My original reply wasn't sent to the Nanog list. > > Team Cymru considers 2002::/16 and 192.88.99.0/24 to be legitimate > prefixes at this time, and will be not be adding them to our bogon > filters. Our interpretation of the 6to4 anycast rfc is that while > these > are encouraged to be made obsolete, in practice they may still be in > use, excluding them from being universally defined as a bogon in our > feed. > > The RFC in question: > https://tools.ietf.org/html/rfc7526 > > The rule, as it always should be, is to know your network, and know > what > is best for it. As noted in the RFC you are encouraged to review any > current deployments and any existing filtering and adjust based on your > own discretion. > > Regards, > > Gary McArtor > Team Cymru > > On 6/28/18 2:32 PM, Rabbi Rob Thomas wrote: FYI, the question has been > raised. I'm not sure if this is wise or not. > Gary, what are your thoughts? > > -------- Forwarded Message -------- > Subject: Re: Time to add 2002::/16 to bogon filters? > Date: Thu, 28 Jun 2018 21:11:22 +0200 > From: Youssef Bengelloun-Zahr > To: Job Snijders > CC: NANOG [nanog at nanog.org] > > Hello Job, > > Thank you for this feedback. I guess that NTT adopting this as a best > practice will ring some bells around. > > Do you know if Team Cymru has updated their filters accordingly ? > > Best regards. > > Le 28 juin 2018 à 20:58, Job Snijders a écrit : > > Dear alll, > > Thank you all for your input. Just a heads-up - we deployed a few days > ago. > > NTT / AS 2914 now considers "2002::/16 le 128" and "192.88.99.0/24 le > 32" > to be bogon prefixes, and no longer accepts announcements for these > destinations from any EBGP neighbor. > > Kind regards, > > Job I think it's still used a bit ? I see today announcements over the following OriginAS over more than 2000 peers. as1103 SURFnet bv as1835 Forskningsnettet - Danish network for Research and Education as2847 Kauno technologijos universitetas as6939 HURRICANE as16150 Availo Networks AB as25192 CZ.NIC, z.s.p.o. as28908 A3 Sverige AB I'm pretty curious about customers impacts if your drop these anycast 6to4 prefixes from your RIB/FIB ;) At home, I use HE.net tunnel broker, because no native IPv6 (yes we already lose matches against Belgium regarding IPv6 and ... beer) and a quick dump shows traffic to 2002:/16 : > sudo tcpdump -ni any 'net 2002::/16' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 15:10:59.588097 IP6 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413 > 2001:470:1f12:dead::beef.51413: UDP, length 94 15:10:59.588233 IP6 2001:470:1f12:dead::beef.51413 > 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413: UDP, length 365 So I'm pretty sure it's still used when no IPv6 is available from an eyeball provider to mount a 6to4 tunnel over a provider that have well deployed IPV6 infrastructure. Perhaps some of the 6to4 tunnel can be tuned to not use anycast prefixes ? -- FABIEN VINCENT _ at beufanet_ From mspring at nktelco.com Fri Jul 6 17:54:11 2018 From: mspring at nktelco.com (Mark Spring) Date: Fri, 6 Jul 2018 13:54:11 -0400 Subject: Looking for Amazon Network Engineer Message-ID: I am having some issues getting some traffic to Amazon and I was curious if there were any Amazon network engineers that might be able to chat with me for a few minutes to discuss my troubles. Shoot me an email and we will set something up. Thanks in advance! Mark Spring Information Systems Manager -- NKTelco 301 W. South St.New Knoxville, OH 45871 Phone: 1-888-NKTELCO Fax: 419-753-2950 This message and the file(s) attached are confidential and proprietary information of NKTelco for the sole use of the intended recipient. Any  unauthorized review, distribution, disclosure, copying, use, or  dissemination, either whole or in part, is strictly prohibited. Do not  transmit these documents, in any form, to any third party without the  expressed written permission of NKTelco. From spoofer-info at caida.org Sun Jul 8 17:00:02 2018 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Sun, 8 Jul 2018 10:00:02 -0700 Subject: Spoofer Report for_NANOG for Jun 2018 Message-ID: <201807081700.w68H0254090810@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 Jun 2018: ASN Name Fixed-By 40764 DNA-DKLB 2018-06-05 29384 Qatar-Foundation 2018-06-06 11796 AIRSTREAMCOMM-NET 2018-06-08 2828 XO-AS15 2018-06-11 11427 SCRR-11427 2018-06-12 5056 AUREON-5056 2018-06-14 20082 ABSNOC1 2018-06-17 6181 FUSE-NET 2018-06-22 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Jun 2018: ASN Name First-Spoofed Last-Spoofed 577 BACOM 2016-03-09 2018-06-24 20115 CHARTER-NET-HKY-NC 2016-06-09 2018-06-15 19230 NANOG 2016-06-13 2018-06-27 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-06-27 6128 CABLE-NET-1 2016-09-03 2018-06-27 20412 CLARITY-TELECOM 2016-09-30 2018-06-25 6181 FUSE-NET 2016-10-10 2018-06-29 25787 ROWE-NETWORKS 2016-10-21 2018-06-26 174 COGENT-174 2016-10-21 2018-06-27 271 BCNET 2016-10-24 2018-06-25 2828 XO-AS15 2016-10-25 2018-06-29 32440 LONI 2016-11-03 2018-06-29 33182 DimeNOC 2016-11-08 2018-06-27 12083 WOW-INTERNET 2016-11-09 2018-06-29 1403 EBOX 2016-11-12 2018-06-27 20105 URICHMOND 2016-11-15 2018-06-28 2152 CSUNET-NW 2017-02-02 2018-06-29 21832 KELLINCOM-1 2017-02-03 2018-06-27 7276 UNIVERSITY-OF-HOUSTON 2017-03-09 2018-06-26 133481 AIS-Fibre 2017-04-20 2018-06-06 6461 ZAYO-6461 2017-06-21 2018-06-29 26253 SCINTERNET 2017-06-30 2018-06-01 63296 AMARILLO-WIRELESS 2017-09-01 2018-06-27 7233 YAHOO-US 2017-09-07 2018-06-28 546 PARSONS-PGS-1 2017-11-20 2018-06-05 54540 INCERO 2018-01-15 2018-06-25 12222 AKAMAI 2018-02-14 2018-06-30 55236 CBC 2018-03-03 2018-06-25 3257 GTT-BACKBONE 2018-03-06 2018-06-25 29384 Qatar-Foundation 2018-03-08 2018-06-28 23148 TERRENAP 2018-03-15 2018-06-27 15176 AS-INOC 2018-04-09 2018-06-15 20009 WADSNET 2018-04-13 2018-06-27 11827 WSU 2018-04-19 2018-06-21 54412 RCC-GRANITE-1 2018-06-04 2018-06-04 393564 SPOKANE 2018-06-05 2018-06-20 35911 BNQ-1 2018-06-06 2018-06-28 4 ISI 2018-06-06 2018-06-06 17402 CENTURYLINK-LEGACY-EMBARQ-CHSK 2018-06-10 2018-06-10 12028 MMINTERNET 2018-06-14 2018-06-14 225 VIRGINIA 2018-06-18 2018-06-18 6576 SUMMITCOMM 2018-06-21 2018-06-21 16837 VABB 2018-06-22 2018-06-22 33509 CASCADE-ACCESS-LLC-CA-ESTOR1 2018-06-22 2018-06-22 394548 NETBLAZR-BOS 2018-06-23 2018-06-28 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 hugge at nordu.net Mon Jul 9 15:24:26 2018 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Mon, 9 Jul 2018 17:24:26 +0200 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> Message-ID: On 2018-07-06 21:18, Tom Paseka via NANOG wrote: > Hi, > > I've been casually observing the connectivity to Bitcanal / AS3266 / > AS197426 since the thread started. > > After GTT shared that bitcanal had been disconnected, bitcanal was only > visible behind Cogent. But the Cogent path now also seems to have been > disconnected. After Cogent they popped up behind BICS (but just for a few > days), that circuit seems to have been disconnected too. > > On the IX front: I noticed that Bitcanal's IP addresses on LINX (since > yesterday) and FranceIX (since today) are no longer responding. > > It is good to see that discussing BGP hijacking abuse complaints actually > results in clean up activities. I hope the remaining IX's they're still > connected to can act too. > > Thanks! > -Tom > And it also seems that they are now no longer reachable over the AMS-IX fabric (and is no longer listed as a member). I also noticed that hey are not reachable over the Megaport/ECIX fabric in Frankfurt either (no arp or ping-reply) but is listed as member on the megaport website, so not sure whats going on there. The only routes i can see now for 3266/197426 is two /24 v4 and one /29 v6 that jumps on over to portugal through 1299 (telia) -> 174 (cogent) -> 29003 (refertelecom / iptelecom). -- hugge From phil.lavin at cloudcall.com Mon Jul 9 15:43:33 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Mon, 9 Jul 2018 15:43:33 +0000 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> Message-ID: > The only routes i can see now for 3266/197426 is two /24 v4 and one /29 v6 that jumps on over to portugal through 1299 > (telia) -> 174 (cogent) -> 29003 (refertelecom / iptelecom). 6939 (HE) are still advertising the routes to their customers. That suggests that 197426 is still active on at least one IX. From valdis.kletnieks at vt.edu Mon Jul 9 16:10:17 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 09 Jul 2018 12:10:17 -0400 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <309924460d81f400120550b836ae53a8@beufa.net> References: <79091a9a-3ddf-6d14-84d4-0931510ae430@cymru.com> <309924460d81f400120550b836ae53a8@beufa.net> Message-ID: <10156.1531152617@turing-police.cc.vt.edu> On Mon, 09 Jul 2018 15:21:31 +0200, "Fabien VINCENT (NaNOG)" said: > I think it's still used a bit ? I see today announcements over the > following OriginAS over more than 2000 peers. > > as1103 SURFnet bv > as1835 Forskningsnettet - Danish network for Research and Education > as2847 Kauno technologijos universitetas > as6939 HURRICANE > as16150 Availo Networks AB > as25192 CZ.NIC, z.s.p.o. > as28908 A3 Sverige AB Announced and used are two different things.. :) > > sudo tcpdump -ni any 'net 2002::/16' > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes > 15:10:59.588097 IP6 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413 > 2001:470:1f12:dead::beef.51413: UDP, length 94 > 15:10:59.588233 IP6 2001:470:1f12:dead::beef.51413 > 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413: UDP, length 365 I'm pretty sure that 2002: address is (a) *your* end of the tunnel and (b) only visible inside your network and *inside* the HE tunnel to the other end. In other words, it shouldn't be seen out on the public net if it's transiting an HE tunnel. I bet if you changed that '-i any' to '-i wlan' (for whatever your router calls the outbound-facing interface) you won't see traffic on 2002: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nchabbey at n3network.ch Mon Jul 9 18:28:53 2018 From: nchabbey at n3network.ch (Nicolas Chabbey) Date: Mon, 9 Jul 2018 20:28:53 +0200 Subject: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks) In-Reply-To: References: <004101d40e35$c2daed10$4890c730$@netconsultings.com> Message-ID: You can certainly add 'security' to the list. I don't mean 'network security' here but 'information security' as a whole. A lot of vendors (notably AV) uses of a lot of marketing terms and they also play with the fears of people to sell their (insert revolutionary) products/solutions. Some of them could be rather useless in a security standpoint, especially if not properly tuned and configured. It can bring a false sense of security which is sometimes worst than a sense of security at all. My two cent.. On 07/07/18 16:57, Marcus Leske wrote: > 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. > > opinions ? > > danke, > markus > > On Mon, Jul 2, 2018 at 12:25 PM, Matt Erculiani wrote: >> Unfortunately, like many other industry terms, "open" is becoming a >> meaningless marketing buzzword much like "cloud", "converged", even >> "redundancy" or any other technical term that has had its definition >> diluted as time goes on. We're all well aware on the ISP side that it >> only takes one Fortune 500 to start using a buzzword incorrectly, then >> the rest of the big guys all the way to mom and pop shops around the >> world start using it in the same context. Unfortunately I don't see >> any end to this trend in sight. >> >> "...fingerprints is took, days is lost, bail is made, court >> dates are ignored, cycle is repeated." >> - Early Cuyler >> >> -Matt >> >> On Thu, Jun 28, 2018 at 11:29 AM, Tails Pipes wrote: >>> No, things changed there as well. Lookup merchant sillicon, and revise this >>> post every 6 months. have you heard of Barefoot networks? The days of ASICs >>> from Cisco are gone and we are glad, we tested the P4 DSL (cisco never got >>> that right with mantel) on Nexus and its wonderful. >>> >>> The asics you speak of are no longer important or valuable because people >>> realized that in many networking planets and galaxies, the asic is reflects >>> the network design, they are related, and specifically for the data center, >>> the clos fabric design won, and that does not require fancy asics. >>> I guess your knowledge is out dated a bit. Cisco itself is using those >>> merchant sillicon ASICs happily. (lookup Chuck's comments on nexus9000, >>> best selling cisco switch ever)...guess it is a good switch, because bright >>> box pushed cisco to do that, and if any one on this list can disagree with >>> me here, i'm up to that challenge. >>> >>> What i have discovered recently is that things happen in following way. >>> >>> Your boss or his boss picks a work culture (no one gets fired for buying >>> IBM/Cisco), that culture (buying the shiny suits) impacts how you do work, >>> it makes you select vendors (the ones that sends me to vegas every year) >>> and not the right network design, you select cisco and you are stuck there >>> for life, because once they tell you how things should work (aka : >>> certificates), things are worse, now every time you make a new network >>> purchase (afraid of new CLI ), you will not be able to look the other way >>> because you just dont know any thing else (and loosing your certificate >>> value). >>> >>> I wish the culture would change to, no one got fired for buying closed but >>> didnt get promoted either. change requires boldness. >>> >>> https://toolr.io/2018/06/18/stop-abusing-the-word-open/ >>> >>> >>> >>> On Wed, Jun 27, 2018 at 9:41 AM, wrote: >>> >>>>> Tails Pipes >>>>> Sent: Friday, June 22, 2018 3:00 PM >>>>> >>>>> can you easily answer this question ? why packets are not pushed in >>>> linux ? >>>>> is it because of big switch, cumulus, pica8 ? >>>>> >>>>> can you push packets in linux without writing code to do that ? who is >>>> writing >>>>> that code ? >>>>> >>>>> this is supposedly a community effort, something that older generations >>>>> dont understand. >>>>> >>>> If pure linux as NOS has some legs it'll fly regardless of cisco blessing, >>>> don't worry no single company owns the whole industry. >>>> Also we can argue that this is only about the OS but in reality it's also >>>> the quality of apps running on top and the quality of the underlying HW >>>> that plays a major role. >>>> The quality of BGP app for instance, or the ability of the forwarding ASIC >>>> to deliver the stated pps rate even if multiple features are enabled or >>>> protect high priority traffic even if ASIC is overloaded. >>>> >>>> >>>> Oh and with regards to: >>>> < I am sick of having to learn all the cisco specific terms to all sorts >>>> of different boxes and technologies >>>> I'd recommend you read all the cisco books on networking to get yourself >>>> educated on the topic and to get the difference between SW and HW >>>> forwarding ( -on why packets are not routed in linux) >>>> And while on that I suggest you read all Stanford university lectures on >>>> how routers work too, it'll help you understand why Cisco and Juniper ASICs >>>> are so much more expensive than white-box ASICs. >>>> >>>> adam >>>> >>>> netconsultings.com >>>> ::carrier-class solutions for the telecommunications industry:: >>>> >>>> >>>> From rwoolleynanog at gmail.com Mon Jul 9 21:45:56 2018 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Mon, 9 Jul 2018 17:45:56 -0400 Subject: NANOG 74 Call for Presentations is open Message-ID: NANOG Community, The NANOG Program Committee is excited to announce that we are now accepting proposals for all sessions at NANOG 74 in Vancouver, BC, Canada, October 1-3, 2018. Below is a summary of key details and dates from the Call For Presentations on the NANOG website, which can be found at: http://www.cvent.com/d/qgqs03/6K The NANOG Program Committee seeks proposals for presentations, panels, tutorials, and track sessions for the NANOG 74 program. We welcome suggestions of speakers or topic ideas. Presentations may cover current technologies already deployed or soon-to-be deployed in the Internet. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations must not be promotional or discuss proprietary solutions. NANOG 74 submissions can be entered on the NANOG Program Committee Tool at https://pc.nanog.org The primary speaker, moderator, or author should submit a presentation proposal and an abstract in the Program Committee Tool. - Select “Propose Talk” from the Talks menu - Select NANOG 74 from the Meeting menu - Select the appropriate *Session* the talk will be presented in (General Session 30-45 minutes; Tutorial 90-120 minutes; Track 90-120 minutes) Timeline for submission and proposal review: - Submitter enters abstract (and draft slides if possible) in Program Committee Tool: any time following Call for Presentations and prior to CFP deadline for slide submission - PC performs initial review and assigns a “shepherd” to help develop the submission: within 2 weeks - Submitter develops draft slides of talk. Please submit initial draft slides early. Panel and Track submissions should provide topic list and intended/confirmed participants - PC reviews slides and continues to work with Submitter as needed to develop topic - Draft presentation slides should be submitted prior to published deadline for slides - PC accepts or declines submission - Agenda assembled and posted - Submitters notified If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the Program Committee, and a representative of the Program Committee will respond. Otherwise, submit your talk, keynote, track, or panel proposal to the Program Committee Tool without delay! We look forward to reviewing your submission. Key Dates for NANOG 74: Monday, 07/09/18 Registration for NANOG 74 Opens Monday, 07/09/18 Agenda Outline for NANOG 74 Posted Tuesday, 09/04/18 CFP Deadline: Presentation Slides Due Tuesday, 09/04/18 CFP Topic List and NANOG Highlights Page Monday, 09/24/18 Speaker FINAL presentation Slides to PC Tool Sunday, 09/30/18 Lightning Talk Submissions Open (Abstracts Only) Sunday, 09/30/18 On-site Registration Final slides must be submitted by Monday, September 24, 2018, and no changes will be accepted between that date and the conference. Materials received after that date will be updated on the web site after the completion of the conference. We look forward to seeing you in October in Vancouver! Sincerely, Ryan Woolley NANOG PC From rmosher at he.net Mon Jul 9 21:44:15 2018 From: rmosher at he.net (Rob Mosher) Date: Mon, 9 Jul 2018 17:44:15 -0400 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> Message-ID: <838b6591-8e5f-a0ef-759b-13e3fb9b89d7@he.net> We saw these announcements from GigaPix and ESPANIX route servers.  Adjustments have been made and we are no longer accepting these. -- Rob Mosher Senior Network and Software Engineer Hurricane Electric / AS6939 On 7/9/2018 11:43 AM, Phil Lavin wrote: >> The only routes i can see now for 3266/197426 is two /24 v4 and one /29 v6 that jumps on over to portugal through 1299 >> (telia) -> 174 (cogent) -> 29003 (refertelecom / iptelecom). > 6939 (HE) are still advertising the routes to their customers. That suggests that 197426 is still active on at least one IX. From list-nanog at beufa.net Mon Jul 9 22:06:00 2018 From: list-nanog at beufa.net (Fabien VINCENT (NaNOG)) Date: Tue, 10 Jul 2018 00:06:00 +0200 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <10156.1531152617@turing-police.cc.vt.edu> References: <79091a9a-3ddf-6d14-84d4-0931510ae430@cymru.com> <309924460d81f400120550b836ae53a8@beufa.net> <10156.1531152617@turing-police.cc.vt.edu> Message-ID: Le 2018-07-09 18:10, valdis.kletnieks at vt.edu a écrit : > On Mon, 09 Jul 2018 15:21:31 +0200, "Fabien VINCENT (NaNOG)" said: > >> I think it's still used a bit ? I see today announcements over the >> following OriginAS over more than 2000 peers. >> >> as1103 SURFnet bv >> as1835 Forskningsnettet - Danish network for Research and Education >> as2847 Kauno technologijos universitetas >> as6939 HURRICANE >> as16150 Availo Networks AB >> as25192 CZ.NIC, z.s.p.o. >> as28908 A3 Sverige AB > > Announced and used are two different things.. :) > > sudo tcpdump -ni any 'net 2002::/16' tcpdump: verbose output > suppressed, use -v or -vv for full protocol decode > listening on any, link-type LINUX_SLL (Linux cooked), capture size > 262144 bytes > 15:10:59.588097 IP6 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413 > > 2001:470:1f12:dead::beef.51413: UDP, length 94 > 15:10:59.588233 IP6 2001:470:1f12:dead::beef.51413 > > 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413: UDP, length 365 I'm pretty sure that 2002: address is (a) *your* end of the tunnel and (b) only visible inside your network and *inside* the HE tunnel to the other end. In other words, it shouldn't be seen out on the public net if it's transiting an HE tunnel. I bet if you changed that '-i any' to '-i wlan' (for whatever your router calls the outbound-facing interface) you won't see traffic on 2002: You're right, it does need to be public to work ;) So my question is why it is still and it was announced on DFZ ? Regards, -- FABIEN VINCENT _ at beufanet_ From phil.lavin at cloudcall.com Mon Jul 9 22:08:44 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Mon, 9 Jul 2018 22:08:44 +0000 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <838b6591-8e5f-a0ef-759b-13e3fb9b89d7@he.net> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> <838b6591-8e5f-a0ef-759b-13e3fb9b89d7@he.net> Message-ID: > Adjustments have been made and we are no longer accepting these. Indeed - I no longer see these routes from you. Thanks :) From large.hadron.collider at gmx.com Mon Jul 9 22:55:56 2018 From: large.hadron.collider at gmx.com (LHC) Date: Mon, 09 Jul 2018 15:55:56 -0700 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: <79091a9a-3ddf-6d14-84d4-0931510ae430@cymru.com> <309924460d81f400120550b836ae53a8@beufa.net> <10156.1531152617@turing-police.cc.vt.edu> Message-ID: <454064C4-C46E-4698-9465-732317ECFA45@gmx.com> 2002::/16 is still valid - not a bogon as long as there is an IPv4 Internet. Add the IPv4 bogons, though (2002:7f00:0000::/48 through 2002:7f.ff:ff.ff::/48, & others) On July 9, 2018 3:06:00 PM PDT, "Fabien VINCENT (NaNOG)" wrote: >Le 2018-07-09 18:10, valdis.kletnieks at vt.edu a écrit : > >> On Mon, 09 Jul 2018 15:21:31 +0200, "Fabien VINCENT (NaNOG)" said: >> >>> I think it's still used a bit ? I see today announcements over the >>> following OriginAS over more than 2000 peers. >>> >>> as1103 SURFnet bv >>> as1835 Forskningsnettet - Danish network for Research and >Education >>> as2847 Kauno technologijos universitetas >>> as6939 HURRICANE >>> as16150 Availo Networks AB >>> as25192 CZ.NIC, z.s.p.o. >>> as28908 A3 Sverige AB >> >> Announced and used are two different things.. :) >> >> sudo tcpdump -ni any 'net 2002::/16' tcpdump: verbose output >> suppressed, use -v or -vv for full protocol decode >> listening on any, link-type LINUX_SLL (Linux cooked), capture size >> 262144 bytes >> 15:10:59.588097 IP6 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413 > >> 2001:470:1f12:dead::beef.51413: UDP, length 94 >> 15:10:59.588233 IP6 2001:470:1f12:dead::beef.51413 > >> 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413: UDP, length 365 > >I'm pretty sure that 2002: address is (a) *your* end of the tunnel and > >(b) >only visible inside your network and *inside* the HE tunnel to the >other >end. >In other words, it shouldn't be seen out on the public net if it's >transiting >an HE tunnel. I bet if you changed that '-i any' to '-i wlan' (for >whatever >your router calls the outbound-facing interface) you won't see traffic >on 2002: > > >You're right, it does need to be public to work ;) So my question is >why >it is still and it was announced on DFZ ? > >Regards, > >-- >FABIEN VINCENT >_ at beufanet_ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From main at kipsang.com Tue Jul 10 11:28:25 2018 From: main at kipsang.com (Michael Bullut) Date: Tue, 10 Jul 2018 14:28:25 +0300 Subject: A.W.S. Product / Services Inquiry... Message-ID: Greetings Team, Anyone from the Amazon Web Services Team here? I have an inquiry regarding your virtual server offerings. Warm regards, Michael Bullut. --- *Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Twitter:* * @Kipsang * *Blog: http://www.kipsang.com/ * *E-mail:* *main at kipsang.com
* *---* From kraig at enguity.com Tue Jul 10 15:39:17 2018 From: kraig at enguity.com (Kraig Beahn) Date: Tue, 10 Jul 2018 11:39:17 -0400 Subject: SE Mediacom reporting complete internet outage FL GA AL Message-ID: SE Mediacom reporting complete internet outage FL GA AL 114800 EDT 07/10/2018 —————— FROM MEDIACOM: big issue in GA, AL, FL atm - currently under investigation... sounds like a major fiber cut From hugge at nordu.net Tue Jul 10 20:00:41 2018 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Tue, 10 Jul 2018 22:00:41 +0200 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> Message-ID: <46758b04-5e3f-9b19-90d4-b76740d47eb6@nordu.net> On 2018-07-09 17:24, Fredrik Korsbäck wrote: > On 2018-07-06 21:18, Tom Paseka via NANOG wrote: >> Hi, >> >> I've been casually observing the connectivity to Bitcanal / AS3266 / >> AS197426 since the thread started. >> >> After GTT shared that bitcanal had been disconnected, bitcanal was only >> visible behind Cogent. But the Cogent path now also seems to have been >> disconnected. After Cogent they popped up behind BICS (but just for a few >> days), that circuit seems to have been disconnected too. >> >> On the IX front: I noticed that Bitcanal's IP addresses on LINX (since >> yesterday) and FranceIX (since today) are no longer responding. >> >> It is good to see that discussing BGP hijacking abuse complaints actually >> results in clean up activities. I hope the remaining IX's they're still >> connected to can act too. >> >> Thanks! >> -Tom >> > > And it also seems that they are now no longer reachable over the AMS-IX fabric (and is no longer listed as a member). > > I also noticed that hey are not reachable over the Megaport/ECIX fabric in Frankfurt either (no arp or ping-reply) but > is listed as member on the megaport website, so not sure whats going on there. > > The only routes i can see now for 3266/197426 is two /24 v4 and one /29 v6 that jumps on over to portugal through 1299 > (telia) -> 174 (cogent) -> 29003 (refertelecom / iptelecom). > > And now it also seems that NANOG-contributor Doug over at Dyn has done a complete wrap-up of the thing and he has hilighted all the important aspects of this incident in a very educative manner. https://dyn.com/blog/shutting-down-the-bgp-hijack-factory/ Thanks for this Doug! I will bring this post up with my NOC and L2-teams since i think these type of incidents will become as common as regular spam in the future... -- hugge From kraig at enguity.com Tue Jul 10 20:13:01 2018 From: kraig at enguity.com (Kraig Beahn) Date: Tue, 10 Jul 2018 16:13:01 -0400 Subject: SE Mediacom reporting complete internet outage FL GA AL In-Reply-To: References: Message-ID: Mediacom Business/Residential Service starting to come back up regionally. On Tue, Jul 10, 2018 at 11:39 AM, Kraig Beahn wrote: > SE Mediacom reporting complete internet outage FL GA AL > > 114800 EDT 07/10/2018 > > —————— > > FROM MEDIACOM: > > big issue in GA, AL, FL atm - currently under investigation... sounds like > a major fiber cut > > > -- From frnkblk at iname.com Wed Jul 11 17:25:57 2018 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 11 Jul 2018 12:25:57 -0500 Subject: Looking for Incapsula contact In-Reply-To: <002301d4131e$927bcac0$b7736040$@iname.com> References: <002301d4131e$927bcac0$b7736040$@iname.com> Message-ID: <000401d4193c$3ac57be0$b05073a0$@iname.com> Emails to NOC and the "Contact Us" form have gone answered, and we keep getting more business customer complaints. Would the NANOG membership be willing to dig into their rolodex and put an Incapusla person in contact with me? Thanks, Frank -----Original Message----- From: NANOG On Behalf Of Frank Bulk Sent: Tuesday, July 03, 2018 5:39 PM To: nanog at nanog.org Subject: Looking for Incapsula contact Emails to NOC have gone unanswered (I did have success with that a year or two ago). Have had a handful of business customers in the last week contact us about B2B web sites they can't reach anymore ... of the eight documented websites, five are using Incapusla address space and others might be using Incapusla's service. Packet traces are showing the remote (web) site is issuing a TCP RST. Frank CTO, Premier Communications From eric-list at truenet.com Wed Jul 11 21:26:47 2018 From: eric-list at truenet.com (Eric Tykwinski) Date: Wed, 11 Jul 2018 17:26:47 -0400 Subject: Mark Tinka ping request Message-ID: <59B4BA3A-A73A-423F-83CE-46B4553F4239@truenet.com> Mark, Kevin does work for Apache and was asking about OSS usage rates in Africa/other places as well. Since I know you are very involved in SAFNOG, et al, I figured you’d be a good resource for contacts over there for data. I’m CCing Kevin McGrail, so more of an intro if you know of anyone. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 From ross at tajvar.io Wed Jul 11 17:16:17 2018 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 11 Jul 2018 13:16:17 -0400 Subject: Verizon/Azure communication issue Message-ID: We have a customer on Fios who (as far as I can tell) can't reach any IP announced by Microsoft. I tried calling both NOCs listed on PeeringDB but Verizon's number didn't work and the Microsoft guy hung up on me. Is there anyone here who has a better contact at either group? Note: It's not a Fios-wide problem, as my office is also on Fios and can reach the IPs fine. It's just 0.ae13.gw9.iad8.alter.net [140.222.236.139] that seems to be having a problem. Thanks, Ross From mark.tinka at seacom.mu Thu Jul 12 06:46:14 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 12 Jul 2018 08:46:14 +0200 Subject: Mark Tinka ping request In-Reply-To: <59B4BA3A-A73A-423F-83CE-46B4553F4239@truenet.com> References: <59B4BA3A-A73A-423F-83CE-46B4553F4239@truenet.com> Message-ID: Thanks, Eric. Kevin, let's unicast so I can get a better understanding of what data you are looking for. Mark. On 11/Jul/18 23:26, Eric Tykwinski wrote: > Mark, > > Kevin does work for Apache and was asking about OSS usage rates in Africa/other places as well. > Since I know you are very involved in SAFNOG, et al, I figured you’d be a good resource for contacts over there for data. > > I’m CCing Kevin McGrail, so more of an intro if you know of anyone. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > > . > From tim.h at bendtel.com Thu Jul 12 17:35:21 2018 From: tim.h at bendtel.com (Tim Howe) Date: Thu, 12 Jul 2018 10:35:21 -0700 Subject: Comcast email filtering broken? Message-ID: <20180712103521.65cf1594@cool> If someone from Comcast who is smarter than their automated email stuff could contact me off list, that would be cool. There appears to be some kind of internal disconnect. --TimH From job at ntt.net Thu Jul 12 17:50:29 2018 From: job at ntt.net (Job Snijders) Date: Thu, 12 Jul 2018 17:50:29 +0000 Subject: deploying RPKI based Origin Validation Message-ID: <20180712175029.GC3037@vurt.meerval.net> Hi all, I wanted to share with you that a ton of activity is taking place in the Dutch networker community to deploy RPKI based BGP Origin Validation. The mantra is "invalid == reject" on all EBGP sessions. What's of note here is that we're now seeing the first commercial ISPs doing Origin Validation. This is a significant step forward compared to what we observed so far (it seemed OV was mostly limited to academic institutions & toy networks). But six months ago Amsio (https://www.amsio.com/en/) made the jump, and today Fusix deployed (https://fusix.nl/deploying-rpki/). We've also seen an uptake of Origin Validation at Internet Exchange route servers: AMS-IX and FranceIX have already deployed. I've read that RPKI OV is under consideration at a number of other exchanges. Other cool news is that Cloudflare launched a Certificate Transparency initiative to help keep everyone honest. Announcement at: https://twitter.com/grittygrease/status/1017224762542587907 Certificate Transparency is a fascinating tool, really a necessity to build confidence in any PKI systems. Anyone here working to deploy RPKI based Origin Validation in their network and reject invalid announcements? Anything of note to share? Kind regards, Job From mark.tinka at seacom.mu Fri Jul 13 12:17:10 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 13 Jul 2018 14:17:10 +0200 Subject: Mark Tinka ping request In-Reply-To: <93ab49ff-ff2f-7812-1031-80b789f02e4b@PCCC.com> References: <59B4BA3A-A73A-423F-83CE-46B4553F4239@truenet.com> <93ab49ff-ff2f-7812-1031-80b789f02e4b@PCCC.com> Message-ID: <739edea0-a4c5-dfd2-f8f7-22cfd14e825b@seacom.mu> On 12/Jul/18 16:40, Kevin A. McGrail wrote: > Thanks Eric as well.  Mark, my interest is less in  the data really. > > What I want to do is improve the use of OSS in Africa in general.  The > data request was a response about the ClamAV usage worldwide.  I'm > always interested in more data but in general, I see the lack of use > of OSS in Africa as a bad sign that will put them behind more and more > over the next few years.  I want to use some of the shining spots like > Ghana and South Africa to leverage working with local groups to > improve their use of OSS.  My sister in law is from Ghana so I noted > that Accra was a big hotspot on a map for Africa and the rest of the > map had vast portions and countries with virtually no heat.   That was > one of my initial contact points finding out more about what was going > on in Ghana that made it look better. > > I have some people who I think can help fund a conference , interest > from the ASF, and another angle as well with financial literacy that > I've been working on with Quicken for Teens and Elderly that I think > will translate over to Apache Fineract and some of the financial > sectors in Africa as well. Just so I'm clear, are you referring to Operations Support Systems or Open Source Software? I was assuming the latter, but when you speak of ClamAV, I suspect the latter. Mark. From mark.tinka at seacom.mu Fri Jul 13 12:37:32 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 13 Jul 2018 14:37:32 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180712175029.GC3037@vurt.meerval.net> References: <20180712175029.GC3037@vurt.meerval.net> Message-ID: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> On 12/Jul/18 19:50, Job Snijders wrote: > Anyone here working to deploy RPKI based Origin Validation in their > network and reject invalid announcements? Anything of note to share? It's great to hear that this is catching up. To be honest, I haven't kept up with the latest goings-on in this space for almost 1 year now, so I hadn't heard about anyone implementing OV in an "Invalid = Drop" manner. Between 2014 - 2016, we (SEACOM, AS37100) deployed and operated (what was then rpki.net) Dragon Research's RPKI CA and RP tools. I believe the project has since moved over to GitHub:     https://github.com/dragonresearch/rpki.net Anyway, the operational issue we ran into was due to our aggressive policy to drop Invalids. The reason this became an issue was networks that ROA'd just their aggregates, but either forgot to or decided not to ROA the longer prefixes that were children of the aggregate. So suddenly, you have a customer who is multi-homed; one connection was to us, SEACOM, and the other was to another ISP not doing OV. Our policy meant the customer was receiving far fewer routes from SEACOM vs. the other provider, which took traffic away from us (and consequently, $$); not to mention the NOC-related headache. After 2 years of struggling to get community traction with OV based on this policy, we decided to maintain the validation, but remove any actions being ran against the validation result. OV where Invalids are dropped is something that all (major, and some regional, at the very least) ISP's need to enable for it to make a real difference in terms of: * Encouraging all networks to participate, and * Reaching the desired outcome, i.e., to mitigate against route leaks and hijacks We also discovered a number of bugs that myself, Randy, Rob, Philip, Fakrul, Matthias, Jay and Andreas, and a few others at Cisco and Juniper helped fix in code that shipped between 2016 - 2017. I would really be keen to hear feedback from you or others that have decided to deploy OV and drop Invalids. I'm more than happy to get back on to this wagon in the interest of cleaning up the global BGP table. But it needs mass... Mark. From job at ntt.net Fri Jul 13 12:43:11 2018 From: job at ntt.net (Job Snijders) Date: Fri, 13 Jul 2018 12:43:11 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> Message-ID: <20180713124311.GI28402@vurt.meerval.net> On Fri, Jul 13, 2018 at 02:37:32PM +0200, Mark Tinka wrote: > Anyway, the operational issue we ran into was due to our aggressive > policy to drop Invalids. The reason this became an issue was networks > that ROA'd just their aggregates, but either forgot to or decided not to > ROA the longer prefixes that were children of the aggregate. > > So suddenly, you have a customer who is multi-homed; one connection was > to us, SEACOM, and the other was to another ISP not doing OV. Our policy > meant the customer was receiving far fewer routes from SEACOM vs. the > other provider, which took traffic away from us (and consequently, $$); > not to mention the NOC-related headache. > > After 2 years of struggling to get community traction with OV based on > this policy, we decided to maintain the validation, but remove any > actions being ran against the validation result. Have you considered applying "invalid == reject" on just transit/peering sessions rather than customer sessions as an intermediate step? I bet most misconfigurations or hijacks didn't come in via your customers. > I would really be keen to hear feedback from you or others that have > decided to deploy OV and drop Invalids. I'm more than happy to get > back on to this wagon in the interest of cleaning up the global BGP > table. But it needs mass... Cool! Kind regards, Job From mark.tinka at seacom.mu Fri Jul 13 12:53:30 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 13 Jul 2018 14:53:30 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180713124311.GI28402@vurt.meerval.net> References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> Message-ID: On 13/Jul/18 14:43, Job Snijders wrote: > Have you considered applying "invalid == reject" on just transit/peering > sessions rather than customer sessions as an intermediate step? I bet > most misconfigurations or hijacks didn't come in via your customers. Yes, we did. The issue is some of our customers did ROA their aggregates, but not the more-specifics. We didn't want to get into a situation where we had to custom-design templates depending on what RPKI mood the customer was in :-). But yes, the majority of the issue was with routes learned from peers and transit. That, though, still leaves the problem where you end up providing a partial routing table to your customers, while your competitors in the same market aren't. Most customers that aren't keen on IPv6 or DNSSEC treat RPKI the same way - as a nuisance. So trying to speak sense into them would be a more treacherous road to take than just turning it off until we get wider support within the BGP operational community. Mark. From mark.tinka at seacom.mu Fri Jul 13 12:56:14 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 13 Jul 2018 14:56:14 +0200 Subject: Mark Tinka ping request In-Reply-To: <40c5ec2f-898d-68c6-d32b-a713ff6d9d81@PCCC.com> References: <59B4BA3A-A73A-423F-83CE-46B4553F4239@truenet.com> <40c5ec2f-898d-68c6-d32b-a713ff6d9d81@PCCC.com> Message-ID: <5bd54921-ea40-e793-ec0a-b0d13ba35f28@seacom.mu> On 12/Jul/18 16:41, Kevin A. McGrail wrote: > Oh, and always happy to jump on a VTC.  Not sure if that's what you > mean when you said unicast. I meant one-on-one e-mail, as I didn't want to give NANOG readers unnecessary noise as we found our initial footing :-). But thinking more about it, I'm certain you refer to OSS as in Open Source Software. In that case, I am very curious where you got the information that Africa have a very poor OSS deployment track record... Please enlighten me... Mark. From mspring at nktelco.com Thu Jul 12 18:31:32 2018 From: mspring at nktelco.com (Mark Spring) Date: Thu, 12 Jul 2018 14:31:32 -0400 Subject: Looking for Amazon Network Engineer In-Reply-To: References: Message-ID: Thank you to those who have reached out to me, I am on the right path now! Mark Spring Information Systems Manager On Fri, Jul 6, 2018 at 1:54 PM, Mark Spring wrote: > I am having some issues getting some traffic to Amazon and I was curious > if there were any Amazon network engineers that might be able to chat with > me for a few minutes to discuss my troubles. Shoot me an email and we will > set something up. > > Thanks in advance! > > Mark Spring > Information Systems Manager > -- NKTelco 301 W. South St.New Knoxville, OH 45871 Phone: 1-888-NKTELCO Fax: 419-753-2950 This message and the file(s) attached are confidential and proprietary information of NKTelco for the sole use of the intended recipient. Any  unauthorized review, distribution, disclosure, copying, use, or  dissemination, either whole or in part, is strictly prohibited. Do not  transmit these documents, in any form, to any third party without the  expressed written permission of NKTelco. From ekgermann at semperen.com Fri Jul 13 02:12:19 2018 From: ekgermann at semperen.com (Eric Germann) Date: Thu, 12 Jul 2018 22:12:19 -0400 Subject: Anyone from Delta on list? Message-ID: <2D8E2754-662A-4029-B6FA-6714B1B6CC74@semperen.com> If so, can you contact me off list, please and thank you? EKG -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3705 bytes Desc: not available URL: From gtaylor at tnetconsulting.net Fri Jul 13 15:18:07 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 13 Jul 2018 09:18:07 -0600 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> Message-ID: On 07/13/2018 06:53 AM, Mark Tinka wrote: > But yes, the majority of the issue was with routes learned from peers > and transit. That, though, still leaves the problem where you end up > providing a partial routing table to your customers, while your > competitors in the same market aren't. Ouch. > Most customers that aren't keen on IPv6 or DNSSEC treat RPKI the same > way - as a nuisance. I can see that. :-( > So trying to speak sense into them would be a more treacherous road to > take than just turning it off until we get wider support within the BGP > operational community. Please forgive the n00b question: But isn't that where carrying the prefixes through your network and conditionally advertising them to customers comes into play? Or does that run into complications where you must also have the prefixes which don't validate routed in your core? The reading I did on RPKI / OV yesterday made me think that it is possible to have validated routes preferred over unknown routes which are preferred over invalid routes. So I'd think that you could still have the routes through your core but conditionally advertise the prefixes to customers based on their desires. I would appreciate it if someone would be kind enough to explain what I'm misunderstanding. Or better, point me to some better documentation to read myself. Thank you from the peanut gallery. -- 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 morrowc.lists at gmail.com Fri Jul 13 16:25:21 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 13 Jul 2018 12:25:21 -0400 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> Message-ID: On Fri, Jul 13, 2018 at 11:19 AM Grant Taylor via NANOG wrote: > > The reading I did on RPKI / OV yesterday made me think that it is > possible to have validated routes preferred over unknown routes which > are preferred over invalid routes. So I'd think that you could still > have the routes through your core but conditionally advertise the > prefixes to customers based on their desires. > you get the option at input (from transit/peering edge say) to evaluate the 'rpki status' of a particular route, then set normal bgp attributes based on that evaluation, so yes you can: valid == localopref 1000 && community-A unknown == localpref 80 && community-B invalid == localpref 1 && community-Z but given: 192.168.0.0/16 - valid 192.168.0.0/17 - unknown 192.168.0.0/24 - invalid your routing system will still forward toward the 192.168.0.0/24 prefix because 'longest prefix match'. Job's plan, I think, is that you reject/drop/do-not-accept the 'invalid' prefix(es) and hope that you follow another / proper path. Perhaps Mark could send along ONLY the valid/unknown routes to his customer, or some mix of the set based on what type of customer: super-sekure-customer - valid only sorta-sekure-customer - valid/unknown wild-wild-west-customer - all it sounded like Mark didn't want to deal with that complexity in his network, until more deployment and more requests from customers like; Customer: "Hey, why did my traffic get hijacked to paY(omlut)pal.com yesterday?" Mark: "because you didn't ask for 'super-sekure-customer config? sorry?" I could have misunderstood either mark or job or you.. of course. > I would appreciate it if someone would be kind enough to explain what > I'm misunderstanding. Or better, point me to some better documentation > to read myself. > > Thank you from the peanut gallery. > > > > -- > Grant. . . . > unix || die > > From job at instituut.net Fri Jul 13 16:37:02 2018 From: job at instituut.net (Job Snijders) Date: Fri, 13 Jul 2018 16:37:02 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> Message-ID: On Fri, Jul 13, 2018 at 4:25 PM, Christopher Morrow wrote: > On Fri, Jul 13, 2018 at 11:19 AM Grant Taylor via NANOG > wrote: >> The reading I did on RPKI / OV yesterday made me think that it is >> possible to have validated routes preferred over unknown routes which >> are preferred over invalid routes. So I'd think that you could still >> have the routes through your core but conditionally advertise the >> prefixes to customers based on their desires. > > you get the option at input (from transit/peering edge say) to evaluate the > 'rpki status' of a particular route, then set normal bgp attributes based > on that evaluation, so yes you can: > valid == localopref 1000 && community-A > unknown == localpref 80 && community-B > invalid == localpref 1 && community-Z > > but given: > 192.168.0.0/16 - valid > 192.168.0.0/17 - unknown > 192.168.0.0/24 - invalid > > your routing system will still forward toward the 192.168.0.0/24 prefix > because 'longest prefix match'. > Job's plan, I think, is that you reject/drop/do-not-accept the 'invalid' > prefix(es) and hope that you follow another / proper path. That is exactly what I mean. Because of the golden rule "most-specific always wins" (and parts of the AS_PATH are pretty easy to spoof) it only makes sense to me to completely reject invalid routes. Kind regards, Job In Junos speak: [...] set policy-options policy-statement IMPORT:PEER term RPKI-DROP-INVALID from protocol bgp set policy-options policy-statement IMPORT:PEER term RPKI-DROP-INVALID from validation-database invalid set policy-options policy-statement IMPORT:PEER term RPKI-DROP-INVALID then validation-state invalid set policy-options policy-statement IMPORT:PEER term RPKI-DROP-INVALID then reject [...] ~ From gtaylor at tnetconsulting.net Fri Jul 13 16:37:26 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 13 Jul 2018 10:37:26 -0600 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> Message-ID: <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> On 07/13/2018 10:25 AM, Christopher Morrow wrote: > you get the option at input (from transit/peering edge say) to evaluate > the 'rpki status' of a particular route, then set normal bgp attributes > based on that evaluation, so yes you can: > > valid == localopref 1000 && community-A > unknown == localpref 80 && community-B > invalid == localpref 1 && community-Z ACK > but given: > 192.168.0.0/16 - valid > 192.168.0.0/17 - unknown > 192.168.0.0/24 - invalid > > your routing system will still forward toward the 192.168.0.0/24 prefix > because 'longest prefix match'. *facePALM* Thank you. So the information would be carried across the network, but it still suffers from the same problem. > Job's plan, I think, is that you reject/drop/do-not-accept the 'invalid' > prefix(es) and hope that you follow another / proper path. Yep. You would almost need separate logical networks / VRF to be able to prevent the longest prefix match winning issue that you reminded me of. > Perhaps Mark could send along ONLY the valid/unknown routes to his > customer, or some mix of the set based on what type of customer: > > super-sekure-customer - valid only > sorta-sekure-customer - valid/unknown > wild-wild-west-customer - all Yep. That's what I was thinking of. > it sounded like Mark didn't want to deal with that complexity in his > network, until more deployment and more requests from customers like; Fair. > Customer: "Hey, why did my traffic get hijacked to paY(omlut)pal.com > yesterday?" > Mark: "because you didn't ask for 'super-sekure-customer config? sorry?" > > I could have misunderstood either mark or job or you.. of course. You understood me correctly. Thank you for explaining what I was missing. -- 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 morrowc.lists at gmail.com Fri Jul 13 17:28:01 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 13 Jul 2018 13:28:01 -0400 Subject: deploying RPKI based Origin Validation In-Reply-To: <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> Message-ID: On Fri, Jul 13, 2018 at 12:41 PM Grant Taylor via NANOG wrote: > On 07/13/2018 10:25 AM, Christopher Morrow wrote: > > > but given: > > 192.168.0.0/16 - valid > > 192.168.0.0/17 - unknown > > 192.168.0.0/24 - invalid > > > > your routing system will still forward toward the 192.168.0.0/24 prefix > > because 'longest prefix match'. > > *facePALM* > > Thank you. > > So the information would be carried across the network, but it still > suffers from the same problem. > > well, consider the situation where Mark's mythical customer(s) are: custA: dual-homed + accept default (from both providers) custB: dual-homed (and live in the 'total sekure world' TSW (tm)) CustA may not see the invalid /24 (nor the /17) but have no other path and "randomly" choose Mark and his /17 + /24 world :( CustB simply drops packets (aka: what Job wants - again, I think) So... if we had more CustB and less CustA ... maybe everywhere it's OK for 'Large Mark Providers' - LMP (tm) to provide such services? I've not looked in a 'long time', but when I worked at a large ISP ~30-35% of our customers did BGP with us, of that ~70+% just did it with us (dual / redundant links to us). I think 'almost all' took a default from us too.. whether they used that default I can't say. I think getting to Job's world is a goal, I think living in Mark's is a reality for a bit still. (yes, you could ALSO do some game playing where the customer ports for TSW were in a VRF with no 'bad' routes, but.. complexity) > > Job's plan, I think, is that you reject/drop/do-not-accept the > 'invalid' > > prefix(es) and hope that you follow another / proper path. > > Yep. > > You would almost need separate logical networks / VRF to be able to > prevent the longest prefix match winning issue that you reminded me of. > > yup, yea... complexity though :( > > Perhaps Mark could send along ONLY the valid/unknown routes to his > > customer, or some mix of the set based on what type of customer: > > > > super-sekure-customer - valid only > > sorta-sekure-customer - valid/unknown > > wild-wild-west-customer - all > > Yep. That's what I was thinking of. > > > it sounded like Mark didn't want to deal with that complexity in his > > network, until more deployment and more requests from customers like; > > Fair. > > > Customer: "Hey, why did my traffic get hijacked to paY(omlut)pal.com > > yesterday?" > > Mark: "because you didn't ask for 'super-sekure-customer config? > sorry?" > > > > I could have misunderstood either mark or job or you.. of course. > > You understood me correctly. > > Thank you for explaining what I was missing. > > > sure thing! (err, this rpki/secure-routing business isn't really super intuitive :( ) > > -- > Grant. . . . > unix || die > > From cscora at apnic.net Fri Jul 13 18:03:10 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Jul 2018 04:03:10 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180713180310.9EA2EC450F@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 14 Jul, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 705823 Prefixes after maximum aggregation (per Origin AS): 271028 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 338650 Total ASes present in the Internet Routing Table: 61231 Prefixes per ASN: 11.53 Origin-only ASes present in the Internet Routing Table: 52910 Origin ASes announcing only one prefix: 23071 Transit ASes present in the Internet Routing Table: 8321 Transit-only ASes present in the Internet Routing Table: 269 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: 62 Number of instances of unregistered ASNs: 67 Number of 32-bit ASNs allocated by the RIRs: 23260 Number of 32-bit ASNs visible in the Routing Table: 18762 Prefixes from 32-bit ASNs in the Routing Table: 78492 Number of bogon 32-bit ASNs visible in the Routing Table: 31 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 281 Number of addresses announced to Internet: 2859655747 Equivalent to 170 /8s, 114 /16s and 226 /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: 235506 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 192665 Total APNIC prefixes after maximum aggregation: 54827 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 191161 Unique aggregates announced from the APNIC address blocks: 78276 APNIC Region origin ASes present in the Internet Routing Table: 8943 APNIC Prefixes per ASN: 21.38 APNIC Region origin ASes announcing only one prefix: 2520 APNIC Region transit ASes present in the Internet Routing Table: 1335 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3904 Number of APNIC addresses announced to Internet: 767722498 Equivalent to 45 /8s, 194 /16s and 132 /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: 209549 Total ARIN prefixes after maximum aggregation: 99744 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209840 Unique aggregates announced from the ARIN address blocks: 99309 ARIN Region origin ASes present in the Internet Routing Table: 18195 ARIN Prefixes per ASN: 11.53 ARIN Region origin ASes announcing only one prefix: 6732 ARIN Region transit ASes present in the Internet Routing Table: 1803 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2376 Number of ARIN addresses announced to Internet: 1103006368 Equivalent to 65 /8s, 190 /16s and 138 /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: 193162 Total RIPE prefixes after maximum aggregation: 92240 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 189351 Unique aggregates announced from the RIPE address blocks: 112214 RIPE Region origin ASes present in the Internet Routing Table: 25288 RIPE Prefixes per ASN: 7.49 RIPE Region origin ASes announcing only one prefix: 11396 RIPE Region transit ASes present in the Internet Routing Table: 3497 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: 7161 Number of RIPE addresses announced to Internet: 716301184 Equivalent to 42 /8s, 177 /16s and 227 /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: 91333 Total LACNIC prefixes after maximum aggregation: 20128 LACNIC Deaggregation factor: 4.54 Prefixes being announced from the LACNIC address blocks: 92727 Unique aggregates announced from the LACNIC address blocks: 40734 LACNIC Region origin ASes present in the Internet Routing Table: 7338 LACNIC Prefixes per ASN: 12.64 LACNIC Region origin ASes announcing only one prefix: 2037 LACNIC Region transit ASes present in the Internet Routing Table: 1364 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4880 Number of LACNIC addresses announced to Internet: 172357664 Equivalent to 10 /8s, 69 /16s and 248 /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: 19051 Total AfriNIC prefixes after maximum aggregation: 4041 AfriNIC Deaggregation factor: 4.71 Prefixes being announced from the AfriNIC address blocks: 22463 Unique aggregates announced from the AfriNIC address blocks: 7870 AfriNIC Region origin ASes present in the Internet Routing Table: 1167 AfriNIC Prefixes per ASN: 19.25 AfriNIC Region origin ASes announcing only one prefix: 386 AfriNIC Region transit ASes present in the Internet Routing Table: 230 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 441 Number of AfriNIC addresses announced to Internet: 99820800 Equivalent to 5 /8s, 243 /16s and 37 /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 4692 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4347 467 459 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2921 1153 80 VIETEL-AS-AP Viettel Group, VN 4766 2832 11134 761 KIXS-AS-KR Korea Telecom, KR 9829 2813 1497 543 BSNL-NIB National Internet Backbone, IN 45899 2641 1633 114 VNPT-AS-VN VNPT Corp, VN 9394 2542 4907 31 CTTNET China TieTong Telecommunications 17974 2260 930 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2239 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2116 417 205 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 3431 1324 84 SHAW - Shaw Communications Inc., CA 22773 3273 2968 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2478 242 471 CABLEONE - CABLE ONE, INC., US 16509 2241 4725 748 AMAZON-02 - Amazon.com, Inc., US 18566 2169 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2109 2580 478 CHARTER-NET-HKY-NC - Charter Communicat 30036 2002 343 159 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1999 5071 605 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16625 1958 983 1395 AKAMAI-AS - Akamai Technologies, Inc., 7018 1753 20203 1273 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 4511 1607 120 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 20940 2543 624 1869 AKAMAI-ASN1, US 8551 2394 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2014 1877 708 ROSTELECOM-AS, RU 34984 2003 334 494 TELLCOM-AS, TR 9121 1883 1692 19 TTNET, TR 13188 1604 100 43 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1222 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 5001 3297 587 Uninet S.A. de C.V., MX 10620 3558 541 265 Telmex Colombia S.A., CO 11830 2655 369 78 Instituto Costarricense de Electricidad 6503 1669 443 62 Axtel, S.A.B. de C.V., MX 7303 1507 1026 188 Telecom Argentina S.A., AR 28573 1035 2247 189 CLARO S.A., BR 3816 1023 508 129 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 934 377 31 Telefonica del Peru S.A.A., PE 11172 928 127 86 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 1156 396 48 LINKdotNET-AS, EG 37611 882 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 743 1411 40 ETISALAT-MISR, EG 8452 627 1730 18 TE-AS TE-AS, EG 24835 608 818 18 RAYA-AS, EG 37492 472 470 57 ORANGE-, TN 29571 456 68 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 5001 3297 587 Uninet S.A. de C.V., MX 4538 4692 4192 74 ERX-CERNET-BKB China Education and Rese 12479 4511 1607 120 UNI2-AS, ES 7545 4347 467 459 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3558 541 265 Telmex Colombia S.A., CO 6327 3431 1324 84 SHAW - Shaw Communications Inc., CA 22773 3273 2968 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2921 1153 80 VIETEL-AS-AP Viettel Group, VN 4766 2832 11134 761 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 4692 4618 ERX-CERNET-BKB China Education and Research Net 12479 4511 4391 UNI2-AS, ES 7545 4347 3888 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3431 3347 SHAW - Shaw Communications Inc., CA 10620 3558 3293 Telmex Colombia S.A., CO 22773 3273 3125 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2921 2841 VIETEL-AS-AP Viettel Group, VN 11830 2655 2577 Instituto Costarricense de Electricidad y Telec 45899 2641 2527 VNPT-AS-VN VNPT Corp, 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 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 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 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:37 /11:99 /12:290 /13:569 /14:1097 /15:1896 /16:13374 /17:7935 /18:13768 /19:25318 /20:39420 /21:45608 /22:87729 /23:71214 /24:395282 /25:802 /26:604 /27:624 /28:35 /29:20 /30:20 /31:6 /32:51 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3261 4511 UNI2-AS, ES 6327 3217 3431 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2537 3273 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2062 2169 MEGAPATH5-US - MegaPath Corporation, US 11830 2004 2655 Instituto Costarricense de Electricidad y Telec 11492 1966 2478 CABLEONE - CABLE ONE, INC., US 8551 1856 2394 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1754 2002 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1612 3558 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:1614 2:838 4:18 5:2854 6:41 7:1 8:1121 12:1873 13:201 14:1755 15:29 16:3 17:188 18:54 20:50 23:2446 24:2222 25:2 27:2467 31:2031 32:91 35:27 36:508 37:2796 38:1470 39:252 40:121 41:3123 42:680 43:1929 44:121 45:5001 46:3076 47:202 49:1333 50:1050 51:316 52:1068 54:372 55:3 56:12 57:39 58:1605 59:991 60:402 61:2102 62:1866 63:1794 64:5045 65:2198 66:4668 67:2433 68:1166 69:3250 70:1157 71:582 72:2137 74:2704 75:422 76:455 77:1547 78:1715 79:1665 80:1536 81:1373 82:1074 83:793 84:1075 85:2011 86:565 87:1328 88:929 89:2350 90:213 91:6402 92:1239 93:2376 94:2385 95:2904 96:779 97:357 98:935 99:133 100:85 101:1236 102:141 103:18096 104:3566 105:208 106:718 107:1784 108:697 109:3188 110:1621 111:1776 112:1305 113:1280 114:1134 115:1657 116:1637 117:1761 118:2197 119:1662 120:997 121:1056 122:2469 123:1775 124:1449 125:1914 128:1084 129:676 130:459 131:1629 132:707 133:195 134:1015 135:226 136:509 137:555 138:1959 139:656 140:467 141:729 142:806 143:1015 144:801 145:483 146:1195 147:728 148:1612 149:748 150:747 151:1100 152:803 153:319 154:1348 155:766 156:1137 157:796 158:652 159:1761 160:1216 161:794 162:2571 163:598 164:1074 165:1509 166:446 167:1297 168:3110 169:817 170:3803 171:474 172:1010 173:1983 174:910 175:771 176:1990 177:4029 178:2537 179:1239 180:2171 181:2378 182:2551 183:1232 184:1035 185:13754 186:3637 187:2419 188:2849 189:2040 190:8141 191:1352 192:9811 193:6038 194:4884 195:3980 196:2625 197:1594 198:5548 199:5904 200:7320 201:4987 202:10266 203:10268 204:4582 205:2895 206:3109 207:3174 208:3989 209:3996 210:3886 211:1982 212:3025 213:2794 214:990 215:59 216:6047 217:2129 218:855 219:576 220:1777 221:985 222:970 223:1349 End of report From johnl at iecc.com Fri Jul 13 19:21:52 2018 From: johnl at iecc.com (John Levine) Date: 13 Jul 2018 15:21:52 -0400 Subject: Anyone from Delta on list? In-Reply-To: <2D8E2754-662A-4029-B6FA-6714B1B6CC74@semperen.com> Message-ID: <20180713192152.9CAF2200244440@ary.qy> In article <2D8E2754-662A-4029-B6FA-6714B1B6CC74 at semperen.com> you write: >-=-=-=-=-=- > >If so, can you contact me off list, please and thank you? Delta the airline? Delta the hotel chain? Delta the plumbing fixture maker? Delta the construction company? Signed, Baffled From matt at netfire.net Fri Jul 13 19:53:35 2018 From: matt at netfire.net (Matt Harris) Date: Fri, 13 Jul 2018 14:53:35 -0500 Subject: Anyone from Delta on list? In-Reply-To: <20180713192152.9CAF2200244440@ary.qy> References: <2D8E2754-662A-4029-B6FA-6714B1B6CC74@semperen.com> <20180713192152.9CAF2200244440@ary.qy> Message-ID: On Fri, Jul 13, 2018 at 2:21 PM, John Levine wrote: > In article <2D8E2754-662A-4029-B6FA-6714B1B6CC74 at semperen.com> you write: > >-=-=-=-=-=- > > > >If so, can you contact me off list, please and thank you? > > Delta the airline? Delta the hotel chain? Delta the plumbing fixture > maker? Delta the construction company? > https://en.wikipedia.org/wiki/Delta_Force From valdis.kletnieks at vt.edu Fri Jul 13 19:58:17 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 13 Jul 2018 15:58:17 -0400 Subject: Anyone from Delta on list? In-Reply-To: <20180713192152.9CAF2200244440@ary.qy> References: <20180713192152.9CAF2200244440@ary.qy> Message-ID: <8610.1531511897@turing-police.cc.vt.edu> On 13 Jul 2018 15:21:52 -0400, "John Levine" said: > Delta the airline? Delta the hotel chain? Delta the plumbing fixture > maker? Delta the construction company? The joys of mapping an address space defined by trademark law into an address space defined by '.com'. And it just went downhill when DNS went global. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From tim.h at bendtel.com Fri Jul 13 22:56:27 2018 From: tim.h at bendtel.com (Tim Howe) Date: Fri, 13 Jul 2018 15:56:27 -0700 Subject: Comcast email filtering broken? In-Reply-To: <20180712103521.65cf1594@cool> References: <20180712103521.65cf1594@cool> Message-ID: <20180713155627.613c0c39@cool> On Thu, 12 Jul 2018 10:35:21 -0700 Tim Howe wrote: > If someone from Comcast who is smarter than their automated email stuff > could contact me off list, that would be cool. There appears to be > some kind of internal disconnect. Just FYI, I got a quick response and this is resolved now. --TimH From mark.tinka at seacom.mu Sat Jul 14 04:46:33 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 14 Jul 2018 06:46:33 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> Message-ID: <13c15517-aa4e-4774-c247-df3f694c282d@seacom.mu> On 13/Jul/18 17:18, Grant Taylor via NANOG wrote: >   > > Please forgive the n00b question:  But isn't that where carrying the > prefixes through your network and conditionally advertising them to > customers comes into play? > > Or does that run into complications where you must also have the > prefixes which don't validate routed in your core? Carrying prefixes in the network is not an issue, valid or otherwise. If you act on them as they enter the network in an aggressive manner, then the other end of an eBGP session will not receive them. That's the issue. Of course, that's how RPKI is supposed to work, but when you're the only one doing it, you're shooting your own foot. > > The reading I did on RPKI / OV yesterday made me think that it is > possible to have validated routes preferred over unknown routes which > are preferred over invalid routes.  So I'd think that you could still > have the routes through your core but conditionally advertise the > prefixes to customers based on their desires. Using LOCAL_PREF to (de)prefer routes based on their validation status is an idea that has been used since 2014. But for me, it defeats the purpose if you are going to go soft when trying to implement something that requires this much resolve to clean up the Internet. Mark. From mark.tinka at seacom.mu Sat Jul 14 04:51:53 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 14 Jul 2018 06:51:53 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> Message-ID: <139b4f76-e23e-d244-c09f-37421672ceaa@seacom.mu> On 13/Jul/18 18:25, Christopher Morrow wrote: > it sounded like Mark didn't want to deal with that complexity in his > network, until more deployment and more requests from customers like; > Customer: "Hey, why did my traffic get hijacked to paY(omlut)pal.com > yesterday?" > Mark: "because you didn't ask for 'super-sekure-customer config? sorry?" > > I could have misunderstood either mark or job or you.. of course. I didn't want to pass on Invalid routes at all, to ensure that the source operator of that route correctly signs it in the RPKI. However, one can't make the horse drink. Using LOCAL_PREF to determine the preference between Valid, Unknown and Invalid routes is just pussy-footing around the feature, if I'm being honest. What's the saying... "Go big, or go home" :-). Mark. From mark.tinka at seacom.mu Sat Jul 14 04:54:35 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 14 Jul 2018 06:54:35 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> Message-ID: <343a8e4c-e2d8-4d6b-8fca-4d4da0920cbd@seacom.mu> On 13/Jul/18 18:37, Job Snijders wrote: > That is exactly what I mean. Because of the golden rule "most-specific > always wins" (and parts of the AS_PATH are pretty easy to spoof) it > only makes sense to me to completely reject invalid routes. Exactly my preference, and exactly what we did for 2 years. But in practice, customers don't really like this, nor does your CFO. We need mass deployment for this to work effectively, and also a bit more education for those that sign aggregates but not the more-specifics. Mark. From mark.tinka at seacom.mu Sat Jul 14 04:57:13 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 14 Jul 2018 06:57:13 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> Message-ID: <0a2c3de0-ee5f-e4bd-fb5b-670aee2fc7c8@seacom.mu> On 13/Jul/18 18:37, Grant Taylor via NANOG wrote: >   > > Yep. > > You would almost need separate logical networks / VRF to be able to > prevent the longest prefix match winning issue that you reminded me of. Oooh, complexity - things we want to avoid :-). Then again, we don't run the Internet in a VRF, so... Mark. From mark.tinka at seacom.mu Sat Jul 14 05:06:22 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 14 Jul 2018 07:06:22 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> Message-ID: <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> On 13/Jul/18 19:28, Christopher Morrow wrote: > I think getting to Job's world is a goal, I think living in Mark's is a > reality for a bit still. > (yes, you could ALSO do some game playing where the customer ports for TSW > were in a VRF with no 'bad' routes, but.. complexity) This summarizes the current status of affairs quite accurately. I'd like to get to the point where RPKI is widely deployed so that we can all run a cleaner BGP. I don't think that waiting for all BGP operators to enable RPKI and drop Invalids will be the solution. So if the top 7 global operators decided to do it, and perhaps suffer the pain of the effects for a few months, the rest of the community will be inclined to follow suit. Kind of like how only a few major operators really use RPSL, which forces all BGP operators to keep some kind of updated IRR, even if they, themselves, may not be RPSL users. > sure thing! (err, this rpki/secure-routing business isn't really super > intuitive :( ) As always, the difficult bit is done, i.e., the protocol spec. is clearly defined, there is code in routing software, and there are plenty of options for Route Validation software. But as always, the hard part is getting the community to implement, as we've seen with IPv6 and DNSSEC. Mark. From baldur.norddahl at gmail.com Sat Jul 14 07:11:11 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 14 Jul 2018 09:11:11 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> Message-ID: In the RIPE part of the world there is no excuse for not getting RPKI correct because RIPE made it so easy. Perhaps the industry could agree on enabling RPKI validation on all european circuits for a start? Regards Baldur From mark.tinka at seacom.mu Sat Jul 14 09:03:16 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 14 Jul 2018 11:03:16 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> Message-ID: On 14/Jul/18 09:11, Baldur Norddahl wrote: > In the RIPE part of the world there is no excuse for not getting RPKI > correct because RIPE made it so easy. Perhaps the industry could agree on > enabling RPKI validation on all european circuits for a start? I think the first step (and what I'd consider to be a quick win) is if we determined all the prefixes that are being designated Invalid, and nail down how many of those are Invalid due to the fact that they are more-specifics announced without a ROA, vs. the parent aggregate which is ROA'd. We would then ask the operators of those prefixes to either withdraw them (easier, but unlikely) or sign them in the RPKI and create ROA's for them (more work, but more likely). Going for the latter. Once that is fixed, and even though the entire BGP world is not running RPKI, those that are and are dropping Invalids would be 100% certain that those Invalids are either leaks or hijacks. I think that will get us 50% of the way there, with the other 50% would now just be growing community participation in RPKI. Thankfully, I believe all (or most) of the RIR's support a simple "click of a button" to say "All prefixes up to a /24 or a /48 of the aggregate should automatically be ROA'd if the aggregate, itself, is ROA'd". So it shouldn't be a lot of work to get what is currently broken fixed. And the beauty, we don't need everyone to participate in the RPKI today for those that want the benefit right now to enjoy it so. Mark. From job at ntt.net Sat Jul 14 12:04:12 2018 From: job at ntt.net (Job Snijders) Date: Sat, 14 Jul 2018 12:04:12 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> Message-ID: <20180714120412.GP28402@vurt.meerval.net> On Fri, Jul 13, 2018 at 02:53:30PM +0200, Mark Tinka wrote: > That, though, still leaves the problem where you end up providing a > partial routing table to your customers, while your competitors in the > same market aren't. I actually view it as a competitive advantage to carry a cleaner set of routes compared to the providers with a more permissive (or lack of) filtering strategy. Sometimes less is more. Kind regards, Job From baldur.norddahl at gmail.com Sat Jul 14 12:13:32 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 14 Jul 2018 14:13:32 +0200 Subject: Linux BNG Message-ID: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> Hello I am investigating Linux as a BNG. The BNG (Broadband Network Gateway) being the thing that acts as default gateway for our customers. The setup is one VLAN per customer. Because 4095 VLANs is not enough, we have QinQ with double VLAN tagging on the customers. The customers can use DHCP or static configuration. DHCP packets need to be option82 tagged and forwarded to a DHCP server. Every customer has one or more static IP addresses. IPv4 subnets need to be shared among multiple customers to conserve address space. We are currently using /26 IPv4 subnets with 60 customers sharing the same default gateway and netmask. In Linux terms this means 60 VLAN interfaces per bridge interface. However Linux is not quite ready for the task. The primary problem being that the system does not scale to thousands of VLAN interfaces. We do not want customers to be able to send non routed packets directly to each other (needs proxy arp). Also customers should not be able to steal another customers IP address. We want to hard code the relation between IP address and VLAN tagging. This can be implemented using ebtables, but we are unsure that it could scale to thousands of customers. I am considering writing a small program or kernel module. This would create two TAP devices (tap0 and tap1). Traffic received on tap0 with VLAN tagging, will be stripped of VLAN tagging and delivered on tap1. Traffic received on tap1 without VLAN tagging, will be tagged according to a lookup table using the destination IP address and then delivered on tap0. ARP and DHCP would need some special handling. This would be completely stateless for the IPv4 implementation. The IPv6 implementation would be harder, because Link Local addressing needs to be supported and that can not be stateless. The customer CPE will make up its own Link Local address based on its MAC address and we do not know what that is in advance. The goal is to support traffic of minimum of 10 Gbit/s per server. Ideally I would have a server with 4x 10 Gbit/s interfaces combined into two 20 Gbit/s channels using bonding (LACP). One channel each for upstream and downstream (customer facing). The upstream would be layer 3 untagged and routed traffic to our transit routers. I am looking for comments, ideas or alternatives. Right now I am considering what kind of CPU would be best for this. Unless I take steps to mitigate, the workload would probably go to one CPU core only and be limited to things like CPU cache and PCI bus bandwidth. Regards, Baldur From saku at ytti.fi Sat Jul 14 13:43:01 2018 From: saku at ytti.fi (Saku Ytti) Date: Sat, 14 Jul 2018 16:43:01 +0300 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180714120412.GP28402@vurt.meerval.net> References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <20180714120412.GP28402@vurt.meerval.net> Message-ID: On Sat, 14 Jul 2018 at 15:07, Job Snijders wrote: > I actually view it as a competitive advantage to carry a cleaner set of > routes compared to the providers with a more permissive (or lack of) > filtering strategy. Sometimes less is more. * When you consider your addressable market 'clueful customers'. -- ++ytti From mfidelman at meetinghouse.net Sat Jul 14 14:54:25 2018 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 14 Jul 2018 08:54:25 -0600 Subject: (perhaps off topic, but) Microwave Towers Message-ID: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> Hi Folks, I find myself driving down Route 66.  On our way through Arizona, I was surprised by what look like a lot of old-style microwave links.  They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. Struck me as somewhat interesting. It also struck me that folks here might have some comments. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From keiths at neilltech.com Sat Jul 14 15:07:22 2018 From: keiths at neilltech.com (Keith Stokes) Date: Sat, 14 Jul 2018 15:07:22 +0000 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> Message-ID: <6707686B-E03F-49D5-8E03-830A4C01522C@neilltech.com> There’s a lot less backhoe fade with microwave. ;-) Kidding aside, I’m sure there are plenty of scenarios where microwave makes better sense than fiber especially since it’s a lot easier to clear right of way through the air. Side gig has me maintaining a satellite system. Yes that still makes sense. As part of that I have a service that monitors people applying for microwave transmitters within a few hundred miles. You’d be surprised how many links are applied for every month. -- Keith Stokes Neill Technologies > On Jul 14, 2018, at 9:56 AM, Miles Fidelman wrote: > > Hi Folks, > > I find myself driving down Route 66. On our way through Arizona, I was surprised by what look like a lot of old-style microwave links. They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. > > Struck me as somewhat interesting. > > It also struck me that folks here might have some comments. > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > From andy at newslink.com Sat Jul 14 15:10:40 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Sat, 14 Jul 2018 10:10:40 -0500 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> Message-ID: <06BBB6B5-CF5E-43B9-920B-18C017D62C4F@newslink.com> > On Jul 14, 2018, at 9:54 AM, Miles Fidelman wrote: > > Hi Folks, > > I find myself driving down Route 66. On our way through Arizona, I was surprised by what look like a lot of old-style microwave links. They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. > > Struck me as somewhat interesting. > > It also struck me that folks here might have some comments. > > Miles Fidelman I’m not 100 percent positive, but from what I recall in my time down that way as a contractor for $major_railroad, I believe they are or were used by the railroad for their communication links. They may not necessarily be in service any longer though. Probably one of those instances where “if it ain’t broke, don’t fix it.” In other words, if the tower isn’t falling down or a hazard, why spend the money to go remove it? I know as recently as 2003, BNSF Railway was still using and upgrading microwave infrastructure in Chicago. http://reference.newslink.com/current-pubs/CHIC/CHIC0304.pdf (see page 2) ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From Brian at ampr.org Sat Jul 14 15:19:14 2018 From: Brian at ampr.org (Brian Kantor) Date: Sat, 14 Jul 2018 08:19:14 -0700 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <6707686B-E03F-49D5-8E03-830A4C01522C@neilltech.com> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> <6707686B-E03F-49D5-8E03-830A4C01522C@neilltech.com> Message-ID: <20180714151914.GA81645@meow.BKantor.net> > > I find myself driving down Route 66. On our way through Arizona, I was surprised by what look like a lot of old-style microwave links. They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. Could they be a legacy of the Southern Pacific Railroad Internal Network Telecommunications, now known under the acronym SPRINT? - Brian From Andy at newslink.com Sat Jul 14 15:41:22 2018 From: Andy at newslink.com (Andy Ringsmuth) Date: Sat, 14 Jul 2018 10:41:22 -0500 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <20180714151914.GA81645@meow.BKantor.net> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> <6707686B-E03F-49D5-8E03-830A4C01522C@neilltech.com> <20180714151914.GA81645@meow.BKantor.net> Message-ID: > On Jul 14, 2018, at 10:19 AM, Brian Kantor wrote: > >>> I find myself driving down Route 66. On our way through Arizona, I was surprised by what look like a lot of old-style microwave links. They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. > > Could they be a legacy of the Southern Pacific Railroad Internal Network Telecommunications, > now known under the acronym SPRINT? > - Brian > Not along Route 66 in Arizona. That generally parallels BNSF Railway, formerly the Santa Fe down there. Southern Pacific followed Interstate 10 much further south. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From ray at oneunified.net Sat Jul 14 17:09:37 2018 From: ray at oneunified.net (Raymond Burkholder) Date: Sat, 14 Jul 2018 11:09:37 -0600 Subject: Linux BNG In-Reply-To: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> Message-ID: <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> interspersed comments .... On 07/14/2018 06:13 AM, Baldur Norddahl wrote: > I am investigating Linux as a BNG. The BNG (Broadband Network Gateway) > being the thing that acts as default gateway for our customers. > > The setup is one VLAN per customer. Because 4095 VLANs is not enough, we > have QinQ with double VLAN tagging on the customers. The customers can > use DHCP or static configuration. DHCP packets need to be option82 > tagged and forwarded to a DHCP server. Every customer has one or more > static IP addresses. Where do you have this happening? Do you have aggregation switches doing this? Are those already in place, or being planned? Because I would make a suggestion for how to do the aggregation. > IPv4 subnets need to be shared among multiple customers to conserve > address space. We are currently using /26 IPv4 subnets with 60 customers > sharing the same default gateway and netmask. In Linux terms this means > 60 VLAN interfaces per bridge interface. I suppose it could be made to work, but forcing a layer 3 boundary over a bunch of layer 2 boundaries, seems to be a bunch of work, but I suppose that would be the brute force and ignorance approach from the mechanisms you would be using. > However Linux is not quite ready for the task. The primary problem being > that the system does not scale to thousands of VLAN interfaces. It probably depends upon which Linux based tooling you wish to use. There are some different ways of looking at this which scale better. > We do not want customers to be able to send non routed packets directly > to each other (needs proxy arp). Also customers should not be able to > steal another customers IP address. We want to hard code the relation > between IP address and VLAN tagging. This can be implemented using > ebtables, but we are unsure that it could scale to thousands of customers. I would consider suggesting the concepts of VxLAN (kernel plus FRR and/or openvswitch) or OpenFlow.(kernel plus openvswitch) VxLAN scales to 16 million vlan equivalents. Which is why I ask about your aggregation layers. Rather than trying to do all the addressing across all the QinQ vlans in the core boxes, the vlans/vxlans and addressing are best dealt with at the edge. Then, rather than running a bunch of vlans through your aggregation/distribution links, you can keep those resilient with a layer 3 only based strategy. > I am considering writing a small program or kernel module. This would > create two TAP devices (tap0 and tap1). Traffic received on tap0 with > VLAN tagging, will be stripped of VLAN tagging and delivered on tap1. > Traffic received on tap1 without VLAN tagging, will be tagged according > to a lookup table using the destination IP address and then delivered on > tap0. ARP and DHCP would need some special handling. I don't think this would be needed. I think all the tools are already available and are robust from daily use. Free Range Routing with EVPN/(VxLAN|MPLS) for a traditional routing mix, or use OpenFlow tooling in Open vSwitch to handle the layer 2 and layer 3 rule definitions you have in mind. Open vSwitch can be programmed via command line rules or can be hooked up to a controller of some sort. So rather than writing your own kernel program, you would write rules for a controller or script which drives the already kernel resident engines. > This would be completely stateless for the IPv4 implementation. The IPv6 > implementation would be harder, because Link Local addressing needs to > be supported and that can not be stateless. The customer CPE will make > up its own Link Local address based on its MAC address and we do not > know what that is in advance. FRR and OVS are IPv4 and IPv6 aware. The dynamics of the CPE MAC would be handled in various ways, depending upon what tooling you decide upon. > The goal is to support traffic of minimum of 10 Gbit/s per server. > Ideally I would have a server with 4x 10 Gbit/s interfaces combined into > two 20 Gbit/s channels using bonding (LACP). One channel each for > upstream and downstream (customer facing). The upstream would be layer 3 > untagged and routed traffic to our transit routers. As mentioned earlier, why make the core boxes do all of the work? Why not distribute the functionality out to the edge? Rather than using traditional switch gear at the edge, use smaller Linux boxes to handle all that complicated edge manipulation, and then keep your high bandwidth core boxes pushing packets only. > I am looking for comments, ideas or alternatives. Right now I am > considering what kind of CPU would be best for this. Unless I take steps > to mitigate, the workload would probably go to one CPU core only and be > limited to things like CPU cache and PCI bus bandwidth. There is much more to write about, but those writings would depend up on what you already have in place, what you would like to put in place, and how you wish to segment your network. Hope this helps. > Baldur -- Raymond Burkholder ray at oneunified.net https://blog.raymond.burkholder.net From frnkblk at iname.com Sat Jul 14 17:20:34 2018 From: frnkblk at iname.com (frnkblk at iname.com) Date: Sat, 14 Jul 2018 12:20:34 -0500 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> Message-ID: <005a01d41b96$fb102290$f13067b0$@iname.com> Is it possibly AT&T's old network? https://99percentinvisible.org/article/vintage-skynet-atts-abandoned-long-lines-microwave-tower-network/ http://long-lines.net/places-routes/ This network runs through our service territory, too. The horns are distinctive. Frank -----Original Message----- From: NANOG On Behalf Of Miles Fidelman Sent: Saturday, July 14, 2018 9:54 AM To: nanog at nanog.org Subject: (perhaps off topic, but) Microwave Towers Hi Folks, I find myself driving down Route 66. On our way through Arizona, I was surprised by what look like a lot of old-style microwave links. They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. Struck me as somewhat interesting. It also struck me that folks here might have some comments. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From gtaylor at tnetconsulting.net Sat Jul 14 17:26:27 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 14 Jul 2018 11:26:27 -0600 Subject: Linux BNG In-Reply-To: <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> Message-ID: <1ae77228-e490-ff97-e7a1-86683d030917@spamtrap.tnetconsulting.net> I agree with all aspects. On 07/14/2018 11:09 AM, Raymond Burkholder wrote: > As mentioned earlier, why make the core boxes do all of the work?  Why > not distribute the functionality out to the edge?  Rather than using > traditional switch gear at the edge, use smaller Linux boxes to handle > all that complicated edge manipulation, and then keep your high > bandwidth core boxes pushing packets only But I do ask: Do you (the ISP) control the CPE (modem / ONT)? Could you push the VxLAN (or maybe MPLS) functionality all the way into it? This would have the added advantage of a (presumably) trusted device providing the identification back to your core equipment. Perhaps even minimal L3 routing w/ DHCP helper such that the customer saw the CPE as the default gateway. (Though this might burn a lot more IPs. This might not be an issue if you're using CGNAT.) -- 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 pozar at lns.com Sat Jul 14 17:46:28 2018 From: pozar at lns.com (Tim Pozar) Date: Sat, 14 Jul 2018 10:46:28 -0700 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> <6707686B-E03F-49D5-8E03-830A4C01522C@neilltech.com> <20180714151914.GA81645@meow.BKantor.net> Message-ID: Did it follow this route? http://long-lines.net/places-routes/maps/MW6003.jpg Tim On 7/14/18 8:41 AM, Andy Ringsmuth wrote: > > >> On Jul 14, 2018, at 10:19 AM, Brian Kantor wrote: >> >>>> I find myself driving down Route 66. On our way through Arizona, I was surprised by what look like a lot of old-style microwave links. They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. >> >> Could they be a legacy of the Southern Pacific Railroad Internal Network Telecommunications, >> now known under the acronym SPRINT? >> - Brian >> > > Not along Route 66 in Arizona. That generally parallels BNSF Railway, formerly the Santa Fe down there. Southern Pacific followed Interstate 10 much further south. > > > ---- > Andy Ringsmuth > andy at newslink.com > News Link – Manager Technology, Travel & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > From tony at wicks.co.nz Sat Jul 14 18:29:08 2018 From: tony at wicks.co.nz (tony at wicks.co.nz) Date: Sun, 15 Jul 2018 06:29:08 +1200 Subject: Linux BNG In-Reply-To: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> Message-ID: <001401d41ba0$8eb59850$ac20c8f0$@wicks.co.nz> >The setup is one VLAN per customer. Because 4095 VLANs is not enough, we have QinQ with double VLAN tagging on the customers. The customers can use DHCP or static configuration. DHCP packets need to be option82 tagged and forwarded to a DHCP server. Every >customer has one or more static IP addresses. What you are describing is how the national fibre network delivers customers to the ISP's in New Zealand (with DHCP and PPP being at the ISP's choice). Generally in New Zealand we have a very active Linux community but I have to say I have not seen any of the service providers attempt to use Linux as a BNG in this way for production customers. Commonly an MPLS network is used to transport these QinQ layer2 "handovers" to centralised BNG's. These BNG's in my experience are normally Cisco (asr1k,asr9k), Juniper (MX, hardware of virtual), Nokia (7750 hardware or virtual) and a small amount of Mikrotik (tends to get swapped out with the previous vendor solutions when scale (2000+) rises). As much as I appreciate Linux, I personally still also see the value of the vendor offerings in this case (think stability and guaranteed performance). My biggest issue with the vendor offerings is that they are not making their virtual offerings (VMX, VSR) attractive enough pricing wise at the small scale, we have successful virtual Juniper and Nokia BNG's in production but pricing wise it generally ends up with the service provider thinking that hardware was probably a better choice in the long run. From baldur.norddahl at gmail.com Sat Jul 14 19:05:38 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 14 Jul 2018 21:05:38 +0200 Subject: Linux BNG In-Reply-To: <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> Message-ID: Den 14/07/2018 kl. 19.09 skrev Raymond Burkholder: > > Where do you have this happening? Do you have aggregation switches > doing this? Are those already in place, or being planned? Because I > would make a suggestion for how to do the aggregation. The POI (Point of Interconnect) with the incumbent telco is one customer per vlan using QinQ. This telco owns all the copper and runs the VDSL2 DSLAMs. They give us a transparent ethernet tunnel to the CPE. We own the CPE. Internally the incumbent uses a MPLS network to transport the VLANs. We in turn also use MPLS with L2VPN to transport the traffic to one of two datacenters. In addition we have our own FTTH network in the ground. This is GPON on Zhone equipment. To make things easier we made the Zhone GPON OLT emulate the same one VLAN per customer setup. The incumbent have telco buildings in each city area. Typically distance between buildings is 10 km. In each such building they have a room where alternative telcos, like us, can rent rack space. The only available power is -48V DC. We currently only have Zhone MXK GPON switches and ZTE MPLS switch equipment in these facilities. Our current BNG solution is some big iron routers (ZTE M6000). This is a device that will do things like 4 million routes in hardware and move many Tb/s (not that we have traffic anything near that level). It works well enough but is not perfect. I think a discussion of the BNG limitations of ZTE M6000 would be a different thread. One of the problems with ZTE M6000 is the price and that goes double for any alternatives mentioned here (Cisco, Juniper etc). Right now I am facing the prospect of investing in more line cards for M6000. I can buy a few servers for the price of one line card and perhaps get a solution that is more "perfect". As to VXLAN the Zhone MXK can not do it and it is not an option for the POI with the incumbent. It would be an alternative to running MPLS but we are happy with the MPLS solution. I have considered OpenFlow and might do that. We have OpenFlow capable switches and I may be able to offload the work to the switch hardware. But I also consider this solution harder to get right than the idea of using Linux with tap devices. Also it appears the Openvswitch implements a different flavour of OpenFlow than the hardware switch (the hardware is limited to some fixed tables that Broadcom made up), so I might not be able to start with the software and then move on to hardware. Regards, Baldur From denys at visp.net.lb Sat Jul 14 19:16:33 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Sat, 14 Jul 2018 22:16:33 +0300 Subject: Linux BNG In-Reply-To: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> Message-ID: <4bcceb10af2c2dafbe0e00a7e9fb1caa@visp.net.lb> On 2018-07-14 15:13, Baldur Norddahl wrote: > Hello > > I am investigating Linux as a BNG. The BNG (Broadband Network Gateway) > being the thing that acts as default gateway for our customers. > > The setup is one VLAN per customer. Because 4095 VLANs is not enough, > we have QinQ with double VLAN tagging on the customers. The customers > can use DHCP or static configuration. DHCP packets need to be option82 > tagged and forwarded to a DHCP server. Every customer has one or more > static IP addresses. > > IPv4 subnets need to be shared among multiple customers to conserve > address space. We are currently using /26 IPv4 subnets with 60 > customers sharing the same default gateway and netmask. In Linux terms > this means 60 VLAN interfaces per bridge interface. > > However Linux is not quite ready for the task. The primary problem > being that the system does not scale to thousands of VLAN interfaces. > > We do not want customers to be able to send non routed packets > directly to each other (needs proxy arp). Also customers should not be > able to steal another customers IP address. We want to hard code the > relation between IP address and VLAN tagging. This can be implemented > using ebtables, but we are unsure that it could scale to thousands of > customers. > > I am considering writing a small program or kernel module. This would > create two TAP devices (tap0 and tap1). Traffic received on tap0 with > VLAN tagging, will be stripped of VLAN tagging and delivered on tap1. > Traffic received on tap1 without VLAN tagging, will be tagged > according to a lookup table using the destination IP address and then > delivered on tap0. ARP and DHCP would need some special handling. > > This would be completely stateless for the IPv4 implementation. The > IPv6 implementation would be harder, because Link Local addressing > needs to be supported and that can not be stateless. The customer CPE > will make up its own Link Local address based on its MAC address and > we do not know what that is in advance. > > The goal is to support traffic of minimum of 10 Gbit/s per server. > Ideally I would have a server with 4x 10 Gbit/s interfaces combined > into two 20 Gbit/s channels using bonding (LACP). One channel each for > upstream and downstream (customer facing). The upstream would be layer > 3 untagged and routed traffic to our transit routers. > > I am looking for comments, ideas or alternatives. Right now I am > considering what kind of CPU would be best for this. Unless I take > steps to mitigate, the workload would probably go to one CPU core only > and be limited to things like CPU cache and PCI bus bandwidth. > accel-ppp supports IPoE termination for both IPv4 and IPv6, with radius and everything. It is also done such way, that it will utilize multicore server efficiently (might need some tuning, depends on hardware). It should handle 2x10G easily on decent server, about 4x10 it depends on your hardware and how well tuning are done. From mark.tinka at seacom.mu Sat Jul 14 19:56:34 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 14 Jul 2018 21:56:34 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180714120412.GP28402@vurt.meerval.net> References: <20180712175029.GC3037@vurt.meerval.net> <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <20180714120412.GP28402@vurt.meerval.net> Message-ID: On 14/Jul/18 14:04, Job Snijders wrote: > I actually view it as a competitive advantage to carry a cleaner set of > routes compared to the providers with a more permissive (or lack of) > filtering strategy. Sometimes less is more. Typically, I wouldn't disagree. In practice, most customers only care about reachability, and not their contribution to the Internet hygiene. A case of "They will look after it", where "they" is not "me". Mark. From mfidelman at meetinghouse.net Sat Jul 14 23:37:29 2018 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 14 Jul 2018 17:37:29 -0600 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: Message-ID: <20180714233732.ADD59CC3B9@server1.neighborhoods.net> Looks like it! -------- Original message --------From: Tim Pozar Date: 7/14/18 11:46 AM (GMT-07:00) To: Andy Ringsmuth , North American Network Operators' Group Subject: Re: (perhaps off topic, but) Microwave Towers Did it follow this route? http://long-lines.net/places-routes/maps/MW6003.jpg Tim On 7/14/18 8:41 AM, Andy Ringsmuth wrote: > > >> On Jul 14, 2018, at 10:19 AM, Brian Kantor wrote: >> >>>> I find myself driving down Route 66.  On our way through Arizona, I was surprised by what look like a lot of old-style microwave links.  They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. >> >> Could they be a legacy of the Southern Pacific Railroad Internal Network Telecommunications, >> now known under the acronym SPRINT? >> - Brian >> > > Not along Route 66 in Arizona. That generally parallels BNSF Railway, formerly the Santa Fe down there. Southern Pacific followed Interstate 10 much further south. > > > ---- > Andy Ringsmuth > andy at newslink.com > News Link – Manager Technology, Travel & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397    (402) 304-0083 cellular > From mfidelman at meetinghouse.net Sat Jul 14 23:40:13 2018 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 14 Jul 2018 17:40:13 -0600 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <20180714151914.GA81645@meow.BKantor.net> Message-ID: <20180714234015.8340CCC3B9@server1.neighborhoods.net> Too far North.  BSNF territory. -------- Original message --------From: Brian Kantor Date: 7/14/18 9:19 AM (GMT-07:00) To: North American Network Operators' Group Subject: Re: (perhaps off topic, but) Microwave Towers > > I find myself driving down Route 66.  On our way through Arizona, I was surprised by what look like a lot of old-style microwave links.  They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. Could they be a legacy of the Southern Pacific Railroad Internal Network Telecommunications, now known under the acronym SPRINT? - Brian From jerome at ceriz.fr Sun Jul 15 03:09:11 2018 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Sun, 15 Jul 2018 05:09:11 +0200 Subject: Linux BNG In-Reply-To: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> Message-ID: Hi Baldur, Le 14/07/2018 à 14:13, Baldur Norddahl a écrit : > I am investigating Linux as a BNG As we say in France, it's like your trying to buttfuck flies (a local saying standing for "reinventing the wheel for no practical reason"). Linux' kernel networking stack is not made for this kind of job. 6WIND or fd.io may be right on the spot, but it's still a lot of dark magic for something that has been done over and over for the past 20 years by most vendors. And it just works. DHCP (implying straight L2 from the CPE to the BNG) may be an option bust most codebases are still young. PPP, on the other hand, is field-tested for extremely large scale deployments with most vendors. If I were in you shooes, and I don't say I'd want to (my BNGs are scaled to less than a few thousand of subscribers, with 1-4 concurrent session each), I'd stick to plain old bitstream (PPP) model, with a decent subscriber framework on my BNGs (I mostly use Juniper MXs, but I also like Nokia's and Cisco's for some features). But let's say we would want to go forward and ditch legacy / proprietary code to surf on the NFV bullshit-wave. What would you actually need ? Linux does soft-recirculation at every encapsulation level by memory copy. You can't scale anything with that. You need to streamline decapsulation with 6wind's turborouter or fd.io frameworks. It'll cost you a few thousand of man-hours to implement your first prototype. Let's say you got a woking framework to treat subsequent headers on the fly (because decapsulation is not really needed, what you want is just to forward the payload, right ?)… Well, you'd need to address provisionning protocols on the same layers. Who would want to rebase a DHCP server with alien packet forms incoming ? I gess no one. Well, I could dissert on the topic for hours, because I've already spent months to address such design issues in scalable ISP networks, and the conclusion is : - PPPoE is simple and proven. Its rigid structure alleviates most of the dual-stack issues. It is well supported and largelly deployed. - DHCP requires hacks (in the form of undocummented options from several vendors) to seemingly work on IPv4, but the multicast boundaries for NDP are a PITA to handle, so no one implemented that properly yet. So it is to avoid for now. - Subscriber frameworks, be it uniper's, Cisco's or Nokia's, are at the core of the largest residentioal ISPs out there. It Just Works. Trust them. That being said, I love the idea of NFV-ing all the things, let it be BNGs first because those bricks in the wall are the most fragile we have to maintain. But I cleraly won't stand for an alternative to traditionnal offerings just yet : it's too critical, and it's a PITA to build from scratch and scale. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From pozar at lns.com Sun Jul 15 04:20:42 2018 From: pozar at lns.com (Tim Pozar) Date: Sat, 14 Jul 2018 21:20:42 -0700 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <20180714233732.ADD59CC3B9@server1.neighborhoods.net> References: <20180714233732.ADD59CC3B9@server1.neighborhoods.net> Message-ID: <85b32a69-60d9-94e9-c94e-0377f914bd54@lns.com> Most of these horns are for 6GHz. I have had friends that have "appropriated" some of them by adding a waveguide to N adapter and use them for the 5.8GHz ISM band with some minor aiming. Kick ass antenna gain. Tim On 7/14/18 4:37 PM, Miles Fidelman wrote: > Looks like it! > > -------- Original message -------- > From: Tim Pozar > Date: 7/14/18 11:46 AM (GMT-07:00) > To: Andy Ringsmuth , North American Network > Operators' Group > Subject: Re: (perhaps off topic, but) Microwave Towers > > Did it follow this route? > > http://long-lines.net/places-routes/maps/MW6003.jpg > > Tim > > On 7/14/18 8:41 AM, Andy Ringsmuth wrote: >> >> >>> On Jul 14, 2018, at 10:19 AM, Brian Kantor wrote: >>> >>>>> I find myself driving down Route 66.  On our way through Arizona, I > was surprised by what look like a lot of old-style microwave links.  > They pretty much follow the East-West rail line - where I'd expect > there's a lot of fiber buried. >>> >>> Could they be a legacy of the Southern Pacific Railroad Internal > Network Telecommunications, >>> now known under the acronym SPRINT? >>> - Brian >>> >> >> Not along Route 66 in Arizona. That generally parallels BNSF Railway, > formerly the Santa Fe down there. Southern Pacific followed Interstate > 10 much further south. >> >> >> ---- >> Andy Ringsmuth >> andy at newslink.com >> News Link – Manager Technology, Travel & Facilities >> 2201 Winthrop Rd., Lincoln, NE 68502-4158 >> (402) 475-6397    (402) 304-0083 cellular >> From josmon at rigozsaurus.com Sun Jul 15 05:03:16 2018 From: josmon at rigozsaurus.com (John Osmon) Date: Sat, 14 Jul 2018 23:03:16 -0600 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> Message-ID: <20180715050316.GA28152@jeeves.rigozsaurus.com> On Sat, Jul 14, 2018 at 08:54:25AM -0600, Miles Fidelman wrote: [...] > I find myself driving down Route 66.  On our way through Arizona, I > was surprised by what look like a lot of old-style microwave links.  > They pretty much follow the East-West rail line - where I'd expect > there's a lot of fiber buried. Not a lot of fiber. If there was, the following wouldn't be needed: https://uto.asu.edu/sun-corridor-network-project-plans-broadband-access-along-i-40 There *are* a number of fiber builds in the area, but none of them are a coherent build across the region. From nanog at radu-adrian.feurdean.net Sun Jul 15 06:51:50 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sun, 15 Jul 2018 08:51:50 +0200 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <6707686B-E03F-49D5-8E03-830A4C01522C@neilltech.com> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> <6707686B-E03F-49D5-8E03-830A4C01522C@neilltech.com> Message-ID: <1531637510.784015.1441112872.52B26F96@webmail.messagingengine.com> On Sat, Jul 14, 2018, at 17:07, Keith Stokes wrote: > There’s a lot less backhoe fade with microwave. ;-) > > Kidding aside, I’m sure there are plenty of scenarios where microwave > makes better sense than fiber especially since it’s a lot easier to HFT or any low-latency app is such a scenario (0.999c through air being 50% faster than 0.66c though fiber), but that region doesn't fit for that use. From web at typo.org Sun Jul 15 07:03:58 2018 From: web at typo.org (Wayne Bouchard) Date: Sun, 15 Jul 2018 00:03:58 -0700 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <005a01d41b96$fb102290$f13067b0$@iname.com> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> <005a01d41b96$fb102290$f13067b0$@iname.com> Message-ID: <20180715070358.GA85101@spider.typo.org> I was going to say... in my experience (I've been to a lot of the Arizona electronics sites, having grown up around broadcasting) that most of the microwave equipment in use was for Bell. That was by far the most populous tower on any mountain top. The broadcasters don't send their signals anywhere but either from downtown to the transmiter or in some cases from the big town to a small town to feed a local low power transmitter (like 5kw VHF as opposed to the normal 100kw). Anything else was Satelite. I know the railroad did some wireless (Sprint's towers were also quite densely packed with directional horns) but a lot of their communication for rail signaling was hardwire as far as I was aware. -Wayne On Sat, Jul 14, 2018 at 12:20:34PM -0500, frnkblk at iname.com wrote: > Is it possibly AT&T's old network? > https://99percentinvisible.org/article/vintage-skynet-atts-abandoned-long-lines-microwave-tower-network/ > http://long-lines.net/places-routes/ > > This network runs through our service territory, too. The horns are distinctive. > > Frank > > -----Original Message----- > From: NANOG On Behalf Of Miles Fidelman > Sent: Saturday, July 14, 2018 9:54 AM > To: nanog at nanog.org > Subject: (perhaps off topic, but) Microwave Towers > > Hi Folks, > > I find myself driving down Route 66. On our way through Arizona, I was > surprised by what look like a lot of old-style microwave links. They > pretty much follow the East-West rail line - where I'd expect there's a > lot of fiber buried. > > Struck me as somewhat interesting. > > It also struck me that folks here might have some comments. > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From jwbensley at gmail.com Sun Jul 15 08:51:23 2018 From: jwbensley at gmail.com (James Bensley) Date: Sun, 15 Jul 2018 09:51:23 +0100 Subject: Linux BNG In-Reply-To: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> Message-ID: Hi Baldur, These guys made a PPPoE client for VPP - you could probably extend that into a PPP server: https://lists.fd.io/g/vpp-dev/message/9181 https://github.com/raydonetworks/vpp-pppoeclient Although, I would agree that deploying PPP now is a bit of a step backwards and IPoE is the way to be doing this in 2018. If you want subscribers with a S-TAG/C-TAG landing in unique virtual interfaces with shared gateway etc, IPv4 + IPv6 (DHCP/v6) and were deploying this on "real service provider networking kit" [1] then the way to do this is with pseudowire headend termination. (PWHE/PWHT). However, you're going to struggle to implement something like PWHT on the native Linux networking stack. Many of the features you want exist in Linux like DHCP/v6, IPv4/6, MPLS, LDP, pseudowires etc, but not all together as a combined service offering. My two pence would be to buy kit from some like Cisco or Juniper as I don't think the open source world is quite there yet. Alternatively if it *must* be Linux look at adding the code to https://wiki.fd.io/view/VPP/Features as it has all constituent parts (DHCP, IP, MPLS, bridges etc.) but not glued together. VPP is an order of magnitude faster than the native Kernel networking stack. I'd be shocked if you did all that you wanted to do at 10Gbps line rate with one CPU core. Cheers, James. [1] Which means the expensive stuff big name vendors like Cisco and Juniper sell From denys at visp.net.lb Sun Jul 15 14:52:21 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Sun, 15 Jul 2018 17:52:21 +0300 Subject: Linux BNG In-Reply-To: References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> Message-ID: <2c90771f529a0ba39e9f9c2b067f2ef2@nuclearcat.com> On 2018-07-15 06:09, Jérôme Nicolle wrote: > Hi Baldur, > > Le 14/07/2018 à 14:13, Baldur Norddahl a écrit : >> I am investigating Linux as a BNG > > As we say in France, it's like your trying to buttfuck flies (a local > saying standing for "reinventing the wheel for no practical reason"). You can say that about whole opensource ecosystem, why to bother, if *proprietary solution name* exists. It is endless flamewar topic. > > Linux' kernel networking stack is not made for this kind of job. 6WIND > or fd.io may be right on the spot, but it's still a lot of dark magic > for something that has been done over and over for the past 20 years by > most vendors. > > And it just works. Linux developers are working continuously to improve this, for example latest feature, XDP, able to process several Mpps on <$1000 server. Ask yourself, why Cloudflare "buttfuck flies" and doesn't buy some proprietary vendor who 20 years does filtering in hardware? https://blog.cloudflare.com/how-to-drop-10-million-packets/ I am doing experiments with XDP as well, to terminate PPPoE, and it is doing that quite well over XDP. > > DHCP (implying straight L2 from the CPE to the BNG) may be an option > bust most codebases are still young. PPP, on the other hand, is > field-tested for extremely large scale deployments with most vendors. DHCP here, at least from RFC 2131 existence in March 1997. Quite old, isn't it? When you stick to PPPoE, you tie yourself with necessary layers of encapsulation/decapsulation, and this is seriously degrading performance at _user_ level at least. With some development experience of firmware for routers, i can tell that hardware offloading of ipv4 routing (DHCP) obviousl is much easier and cheaper, than offloading PPPoE encap/decap+ipv4 routing. Also Vendors keep screwing up their routers with PPP, and for example one of them failed processing properly PADO in newest firmware revision. Another problem, with PPPoE you subscribe to headache called reduced mtu, that also will give a lot of unpleasant hours for ISP support. > > If I were in you shooes, and I don't say I'd want to (my BNGs are > scaled > to less than a few thousand of subscribers, with 1-4 concurrent session > each), I'd stick to plain old bitstream (PPP) model, with a decent > subscriber framework on my BNGs (I mostly use Juniper MXs, but I also > like Nokia's and Cisco's for some features). I am consulting operators from few hundreds to hundreds of thousands. It is very rare, when Linux bng doesn't suit them. > > But let's say we would want to go forward and ditch legacy / > proprietary > code to surf on the NFV bullshit-wave. What would you actually need ? > > Linux does soft-recirculation at every encapsulation level by memory > copy. You can't scale anything with that. You need to streamline > decapsulation with 6wind's turborouter or fd.io frameworks. It'll cost > you a few thousand of man-hours to implement your first prototype. 6wind/fd.io is great solutions, but not suitable for mentioned task. They are mostly created for very tailor made tasks or even as core of some vendor solution. Implementing your BNG based on such frameworks, or DPDK, is really reinventing the wheel, unless you will sell it or can save by that millions of US$. > > Let's say you got a woking framework to treat subsequent headers on the > fly (because decapsulation is not really needed, what you want is just > to forward the payload, right ?)… Well, you'd need to address > provisionning protocols on the same layers. Who would want to rebase a > DHCP server with alien packet forms incoming ? I gess no one. accel-ppp does all that and exactly for IPoE termination, and no black magic there. > > Well, I could dissert on the topic for hours, because I've already > spent > months to address such design issues in scalable ISP networks, and the > conclusion is : > > - PPPoE is simple and proven. Its rigid structure alleviates most of > the > dual-stack issues. It is well supported and largelly deployed. PPPoE has VERY serious flaws. 1)Security of PPPoE sucks big time. Anybody who run rogue PPPoE server in your network will create significant headache for you, while with DHCP you have at least "DHCP snooping". DHCP snooping supported in very many vendors switches, while for PPPoE most of them have nothing, except... you stick each user to his own vlan. Why to pppox them then? 2)DHCP can send some circuit information in Option 82, this is very useful for billing and very cost efficient on last stage of access switches. 3)Modern FTTX(GPON) solutions are built with QinQ in mind, so IPoE fits there flawlessly. > - DHCP requires hacks (in the form of undocummented options from > several > vendors) to seemingly work on IPv4, but the multicast boundaries for > NDP > are a PITA to handle, so no one implemented that properly yet. So it is > to avoid for now. While you can do multicast(mostly for IPTV, yes it is not easy, and need some vendor magic on "native" layer (DHCP), with PPP you can forget about multicast entirely. > - Subscriber frameworks, be it Juniper's, Cisco's or Nokia's, are at > the > core of the largest residentioal ISPs out there. It Just Works. Trust > them. Sticking to "It Just Works" means "zero innovation" as well. For example, while everybody said so, Mikrotik guys appeared, and very possible in total numbers their solutions serving now more users than Cisco or Nokia, for much lower cost. But sure they have their own market niche, Mikrotik doesn't fit well for large deployments. > > That being said, I love the idea of NFV-ing all the things, let it be > BNGs first because those bricks in the wall are the most fragile we > have > to maintain. > > But I cleraly won't stand for an alternative to traditionnal offerings > just yet : it's too critical, and it's a PITA to build from scratch and > scale. > > Best regards, A lot of people who just sit on their warm, monthly salary chair and care about their personal stability only(but not employer profit) - will ask employer to pay for expensive *vendor name* solution, as it's safest bet for them. So, if person who implement solution is just "corporate screw" - he will say *vendor*. Nicolas Taleb "Skin in the game" books perfectly explains, why they will do worst choice. If person is entrepreneur - he will start feasibility study. From denys at visp.net.lb Sun Jul 15 15:03:59 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Sun, 15 Jul 2018 18:03:59 +0300 Subject: Linux BNG In-Reply-To: References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> Message-ID: On 2018-07-14 22:05, Baldur Norddahl wrote: > I have considered OpenFlow and might do that. We have OpenFlow capable > switches and I may be able to offload the work to the switch hardware. > But I also consider this solution harder to get right than the idea of > using Linux with tap devices. Also it appears the Openvswitch > implements a different flavour of OpenFlow than the hardware switch > (the hardware is limited to some fixed tables that Broadcom made up), > so I might not be able to start with the software and then move on to > hardware. AFAIK openflow is suitable for datacenters, but doesn't scale well for users termination purposes. You will run out from TCAM much sooner than you expect. Linux tap device has very high overhead, it suits no more than working as some hotspot gateway for 100s of users. > > Regards, > > Baldur From ahad at swiftelnetworks.com Sun Jul 15 15:31:07 2018 From: ahad at swiftelnetworks.com (Ahad Aboss) Date: Mon, 16 Jul 2018 01:31:07 +1000 Subject: Linux BNG In-Reply-To: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> Message-ID: Hi Baldur, Based on the information you provided, CPE connects to the POI via different service provider (access network provider / middle man) before it reaches your network/POP. With this construct, you are typically responsible for IP allocation and session authentication via DHCP (option 82) with AAA or via Radius for PPPoE. You may also have to deal with the S-TAG and C-TAG at BNG level. Here are some options to consider; *Option 1.* Use Radius for session authentication and IP/DNS allocation to CPE. You can configure BBA-GROUP on the BNG to overcome the 409x vlan limitation as well as the S-TAG and C-TAG. BBA-GROUP can handle multiple session. BBA-GROUP is also a well-supported feature. Here is an example of the config for your BNG (Cisco router) ; =============================================== *bba-group pppoe NAME -1* virtual-template 1 sessions per-mac limit 2 ! *bba-group pppoe NAME -2* virtual-template 2 sessions per-mac limit 2 ! interface GigabitEthernet1/3.100 * encapsulation dot1Q 100 second-dot1q 500-4094* no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip flow egress ip multicast boundary 30 *pppoe enable group NAME -1* no cdp enable ! interface GigabitEthernet1/3.200 encapsulation dot1Q 200 second-dot1q 200-300 no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip flow egress ip multicast boundary 30 *pppoe enable group NAME -2* no cdp enable Configure Virtual templates too. =============================================== *Option 2.* You can deploy a DHCP server using DHCP option 82 to handle all IP or IPoE sessions. DHCP option 82 provides you with additional flexibility that can scale as your customer base grows. You can perform authentication using a combination of CircuitID, RemoteID or CPE MAC-ADD etc. I hope this information helps. Cheers, Ahad On Sat, Jul 14, 2018 at 10:13 PM, Baldur Norddahl wrote: > Hello > > I am investigating Linux as a BNG. The BNG (Broadband Network Gateway) > being the thing that acts as default gateway for our customers. > > The setup is one VLAN per customer. Because 4095 VLANs is not enough, we > have QinQ with double VLAN tagging on the customers. The customers can use > DHCP or static configuration. DHCP packets need to be option82 tagged and > forwarded to a DHCP server. Every customer has one or more static IP > addresses. > > IPv4 subnets need to be shared among multiple customers to conserve > address space. We are currently using /26 IPv4 subnets with 60 customers > sharing the same default gateway and netmask. In Linux terms this means 60 > VLAN interfaces per bridge interface. > > However Linux is not quite ready for the task. The primary problem being > that the system does not scale to thousands of VLAN interfaces. > > We do not want customers to be able to send non routed packets directly to > each other (needs proxy arp). Also customers should not be able to steal > another customers IP address. We want to hard code the relation between IP > address and VLAN tagging. This can be implemented using ebtables, but we > are unsure that it could scale to thousands of customers. > > I am considering writing a small program or kernel module. This would > create two TAP devices (tap0 and tap1). Traffic received on tap0 with VLAN > tagging, will be stripped of VLAN tagging and delivered on tap1. Traffic > received on tap1 without VLAN tagging, will be tagged according to a lookup > table using the destination IP address and then delivered on tap0. ARP and > DHCP would need some special handling. > > This would be completely stateless for the IPv4 implementation. The IPv6 > implementation would be harder, because Link Local addressing needs to be > supported and that can not be stateless. The customer CPE will make up its > own Link Local address based on its MAC address and we do not know what > that is in advance. > > The goal is to support traffic of minimum of 10 Gbit/s per server. Ideally > I would have a server with 4x 10 Gbit/s interfaces combined into two 20 > Gbit/s channels using bonding (LACP). One channel each for upstream and > downstream (customer facing). The upstream would be layer 3 untagged and > routed traffic to our transit routers. > > I am looking for comments, ideas or alternatives. Right now I am > considering what kind of CPU would be best for this. Unless I take steps to > mitigate, the workload would probably go to one CPU core only and be > limited to things like CPU cache and PCI bus bandwidth. > > Regards, > > Baldur > > -- Regards, Ahad Swiftel Networks "*Where the best is good enough*" From ray at oneunified.net Sun Jul 15 16:00:34 2018 From: ray at oneunified.net (Raymond Burkholder) Date: Sun, 15 Jul 2018 10:00:34 -0600 Subject: Linux BNG In-Reply-To: References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> Message-ID: On 07/15/2018 09:03 AM, Denys Fedoryshchenko wrote: > On 2018-07-14 22:05, Baldur Norddahl wrote: >> I have considered OpenFlow and might do that. We have OpenFlow capable >> switches and I may be able to offload the work to the switch hardware. >> But I also consider this solution harder to get right than the idea of >> using Linux with tap devices. Also it appears the Openvswitch >> implements a different flavour of OpenFlow than the hardware switch >> (the hardware is limited to some fixed tables that Broadcom made up), >> so I might not be able to start with the software and then move on to >> hardware. > AFAIK openflow is suitable for datacenters, but doesn't scale well for > users termination purposes. > You will run out from TCAM much sooner than you expect. Denys, could you expand on this? In a linux based solution (say with OVS), TCAM is memory/software based, and in following their dev threads, they have been optimizing flow caches continuously for various types of flows: megaflow, tiny flows, flow quantity and variety, caching, ... When you mate OVS with something like a Mellanox Spectrum switch (via SwitchDev) for hardware based forwarding, I could see certain hardware limitations applying, but don't have first hand experience with that. But I suppose you will see these TCAM issues on hardware only specialized openflow switches. On edge based translations, is hardware based forwarding actually necessary, since there are so many software functions being performed anyway? But I think a clarification on Baldur's speed requirements is needed. He indicates that there are a bunch of locations: do each of the locations require 10G throughput, or was the throughput defined for all sites in aggregate? If the sites indivdiually have smaller throughput, the software based boxes might do, but if that is at each site, then software-only boxes may not handle the throughput. But then, it may be conceivable that by buying a number of servers, and load spreading across the servers will provide some resiliency and will come in at a lower cost than putting in 'big iron' anyway. Because then there are some additional benefits: you can run Network Function Virtualization at the edge and provide additional services to customers. I forgot to mention this in the earlier thread, but there are some companies out there which provide devices with many ports on them and provide compute at the same time. So software based Linux switches are possible, with out reverting to a combination of physical switch and separate compute box. In a Linux based switch, by using IRQ affiinity, traffic from ports can be balanced across CPUs. So by collapsing switch and compute, additional savings might be able to be realized. As a couple of side notes: 1) the DPDK people support a user space dataplane version of OVS/OpenFlow, and 2) an eBPF version of the OVS dataplane is being worked on. In summary, OVS supports three current dataplanes with a fourth on the way. 1) native kernel, 2) hardware offload via TC (SwitchDev), 3) DPDK, 4) eBPF. > Linux tap device has very high overhead, it suits no more than working > as some hotspot gateway for 100s of users. As does the 'veth' construct. >> -- Raymond Burkholder ray at oneunified.net https://blog.raymond.burkholder.net From baldur.norddahl at gmail.com Sun Jul 15 16:43:02 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 15 Jul 2018 18:43:02 +0200 Subject: Linux BNG In-Reply-To: References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> Message-ID: Den 15/07/2018 kl. 18.00 skrev Raymond Burkholder: > But I think a clarification on Baldur's speed requirements is needed. > He indicates that there are a bunch of locations: do each of the > locations require 10G throughput, or was the throughput defined for > all sites in aggregate? If the sites indivdiually have smaller > throughput, the software based boxes might do, but if that is at each > site, then software-only boxes may not handle the throughput. We have considerably more than 10G of total traffic. We are currently transporting it all to one of two locations before doing the BNG function. We then have VRRP to enable failover to the other location. Transport is by MPLS and L2VPN. I set the goal post at 10G per server. To handle more traffic we will have multiple servers. Load balance does not need to be dynamic. We would just distribute the customers so each customer is always handled by the same server. 10G per server translates to approximately 5000 customers per server (2018 - this number is expected to drop as time goes). I am wondering if we could make an open source system (does not strictly have to be Linux) that could do the BNG function at 10G per server, with a server in the price range of 1k - 2k USD. For many sizes of ISP this would be far far cheaper than any of the solutions from Cisco, Juniper et al. Even if you had to get 10 servers to handle 100G you would likely still come out ahead of the big iron solution. And for a startup (like us) it is great to be able to start out with little investment and then let the solution grow with the business. Regards, Baldur From denys at visp.net.lb Sun Jul 15 16:56:42 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Sun, 15 Jul 2018 19:56:42 +0300 Subject: Linux BNG In-Reply-To: References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> Message-ID: On 2018-07-15 19:00, Raymond Burkholder wrote: > On 07/15/2018 09:03 AM, Denys Fedoryshchenko wrote: >> On 2018-07-14 22:05, Baldur Norddahl wrote: >>> I have considered OpenFlow and might do that. We have OpenFlow >>> capable >>> switches and I may be able to offload the work to the switch >>> hardware. >>> But I also consider this solution harder to get right than the idea >>> of >>> using Linux with tap devices. Also it appears the Openvswitch >>> implements a different flavour of OpenFlow than the hardware switch >>> (the hardware is limited to some fixed tables that Broadcom made up), >>> so I might not be able to start with the software and then move on to >>> hardware. > >> AFAIK openflow is suitable for datacenters, but doesn't scale well for >> users termination purposes. >> You will run out from TCAM much sooner than you expect. > > Denys, could you expand on this? In a linux based solution (say with > OVS), TCAM is memory/software based, and in following their dev > threads, they have been optimizing flow caches continuously for > various types of flows: megaflow, tiny flows, flow quantity and > variety, caching, ... > > When you mate OVS with something like a Mellanox Spectrum switch (via > SwitchDev) for hardware based forwarding, I could see certain hardware > limitations applying, but don't have first hand experience with that. > > But I suppose you will see these TCAM issues on hardware only > specialized openflow switches. Yes, definitely only on hardware switches and biggest issue it is vendor+hardware dependent. This means if i find "right" switch, and make your solution depending on it, and vendor decided to issue new revision, or even new firmware, there is no guarantee "unusual" setup will keep working. That what makes many people afraid to use it. Openflow IMO by nature is built to do complex matching, and for example for typical 12-tuple it is 750-4000 entries max in switches, but you go to l2 only matching which was possible at moment i tested, on my experience, only on PF5820 - you can do L2 entries only matching, then it can go 80k flows. But again, sticking to specific vendor is not recommended. About OVS, i didnt looked much at it, as i thought it is not suitable for BNG purposes, like for tens of thousands users termination, i thought it is more about high speed switching for tens of VM. > > On edge based translations, is hardware based forwarding actually > necessary, since there are so many software functions being performed > anyway? IMO at current moment 20-40G on single box is a boundary point when packet forwarding is preferable(but still not necessary) to do in hardware, as passing packets thru whole Linux stack is really not best option. But it works. I'm trying to find an alternative solution, bypassing full stack using XDP, so i can go beyond 40G. > > But then, it may be conceivable that by buying a number of servers, > and load spreading across the servers will provide some resiliency and > will come in at a lower cost than putting in 'big iron' anyway. > > Because then there are some additional benefits: you can run Network > Function Virtualization at the edge and provide additional services to > customers. +1 For IPoE/PPPoE - servers scale very well, while on "hardware" eventually you will hit a limit how many line cards you can put in chassis and then you need to buy new chassis. I am not talking that some chassis have countless unobvious limitations you might hit inside chassis (in pretty old Cisco 6500/7600, which is not EOL, it is a nightmare). If ISP have big enough chassis, he need to remember, that he need second one at same place, and preferable with same amount of line cards, while with servers you are more reliable even with N+M(where M for example N/4) redundancy. Also when premium customers ask me for some unusual things, it is much easier to move them to separate nodes with extended options for termination, where i can implement their demands over custom vCPE. From baldur.norddahl at gmail.com Sun Jul 15 17:38:13 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 15 Jul 2018 19:38:13 +0200 Subject: Linux BNG In-Reply-To: References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> Message-ID: søn. 15. jul. 2018 18.57 skrev Denys Fedoryshchenko : > > Openflow IMO by nature is built to do complex matching, and for example > for > typical 12-tuple it is 750-4000 entries max in switches, but you go to > l2 only matching > which was possible at moment i tested, on my experience, only on PF5820 > - you can do L2 > entries only matching, then it can go 80k flows. > But again, sticking to specific vendor is not recommended. > It would be possible to implement a general forward to controller policy and then upload matching on MAC address only as a offload strategy. You would have a different device doing the layer 3 stuff. The OpenFlow switch just adds and removes vlan tagging based on MAC matching. Regards From ray at oneunified.net Sun Jul 15 18:37:02 2018 From: ray at oneunified.net (Raymond Burkholder) Date: Sun, 15 Jul 2018 12:37:02 -0600 Subject: Linux BNG In-Reply-To: References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> <93739a31-4f18-73de-882c-ac556042be15@oneunified.net> Message-ID: On 07/15/2018 10:56 AM, Denys Fedoryshchenko wrote: > On 2018-07-15 19:00, Raymond Burkholder wrote: >> On 07/15/2018 09:03 AM, Denys Fedoryshchenko wrote: >>> On 2018-07-14 22:05, Baldur Norddahl wrote: > About OVS, i didnt looked much at it, as i thought it is not suitable > for BNG purposes, > like for tens of thousands users termination, i thought it is more about > high speed switching for tens of VM. I would call it more of a generic all purpose tool for customized L2/L3/L4/L5 packet forwarding. It works well for datacenter as well as ISP related scenarios. Due to the wide variety of rule matching, encapsulations supported, and the ability to attach a customized controller for specialized packet handling. >> On edge based translations, is hardware based forwarding actually >> necessary, since there are so many software functions being performed >> anyway? > IMO at current moment 20-40G on single box is a boundary point when > packet forwarding > is preferable(but still not necessary) to do in hardware, as passing > packets > thru whole Linux stack is really not best option. But it works. > I'm trying to find an alternative solution, bypassing full stack using XDP, > so i can go beyond 40G. Tied to XDP is eBPF (which is what makes tcpdump fast). Another tool is P4 which provides tools to build customized SW/HW forwarders. But I'm not sure how applicable it is to BNG. -- Raymond Burkholder ray at oneunified.net https://blog.raymond.burkholder.net From jbothe at me.com Sun Jul 15 22:13:17 2018 From: jbothe at me.com (JASON BOTHE) Date: Sun, 15 Jul 2018 18:13:17 -0400 Subject: NTT engineer in the wings? Message-ID: If there is someone listening from NTT engineering, would you kindly write back? The IP NOC is unable to locate anyone because it’s Sunday so I thought I might try here. Thanks! J~ From saku at ytti.fi Mon Jul 16 09:03:48 2018 From: saku at ytti.fi (Saku Ytti) Date: Mon, 16 Jul 2018 12:03:48 +0300 Subject: NTT engineer in the wings? In-Reply-To: References: Message-ID: Hey Jason, Can you provide me ticket number (VNOC), time you called and who you spoke with? We have 24/7 NOC, and 24/7 escalation. Sunday is like every other day, this is highly atypical and I apologise for it. You can contact me off-list. Thanks! On Mon, 16 Jul 2018 at 01:16, JASON BOTHE via NANOG wrote: > > > If there is someone listening from NTT engineering, would you kindly write back? > > The IP NOC is unable to locate anyone because it’s Sunday so I thought I might try here. > > Thanks! > > J~ > -- ++ytti From randy at psg.com Mon Jul 16 14:22:16 2018 From: randy at psg.com (Randy Bush) Date: Mon, 16 Jul 2018 10:22:16 -0400 Subject: NTT engineer in the wings? In-Reply-To: References: Message-ID: > The IP NOC is unable to locate anyone because it’s Sunday you can't be talking about ntt noc. ntt noc is aggressively responsive. randy From mark.tinka at seacom.mu Mon Jul 16 14:35:14 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 16 Jul 2018 16:35:14 +0200 Subject: Linux BNG In-Reply-To: <001401d41ba0$8eb59850$ac20c8f0$@wicks.co.nz> References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> <001401d41ba0$8eb59850$ac20c8f0$@wicks.co.nz> Message-ID: <1f2926ec-e85e-0956-e205-ac387f9dbe41@seacom.mu> On 14/Jul/18 20:29, tony at wicks.co.nz wrote: > My biggest issue with the vendor offerings is that they are not making their virtual offerings (VMX, VSR) attractive enough pricing wise at the small scale, we have successful virtual Juniper and Nokia BNG's in production but pricing wise it generally ends up with the service provider thinking that hardware was probably a better choice in the long run. vBNG's are fraught with imperceptible license fees. But yes, if you had do deploy a BNG on an x86 box, a vBNG from a well-known vendor will likely be less problematic to setup and scale than a BNG based on Linux. Then again, I last researched this in 2016, so things could have changed a tad. Mark. From aveline at misaka.io Sat Jul 14 00:18:25 2018 From: aveline at misaka.io (Siyuan Miao) Date: Sat, 14 Jul 2018 08:18:25 +0800 Subject: Bogon prefix c0f:f618::/32 announced via Cogent Message-ID: Hi, c0f:f618::/32 originated from AS327814 is announcing via Cogent for several weeks. I've tried to contact Cogent and AS327814 but didn't receive any reply. Tue Jul 10 17:52:48.602 UTC BGP routing table entry for c0f:f618::/32 Versions: Process bRIB/RIB SendTblVer Speaker 76403269 76403269 Local Label: 61339 Last Modified: Jul 3 13:31:40.815 for 1w0d Paths: (1 available, best #1) Advertised to peers (in unique update groups): 38.5.0.99 Path #1: Received by speaker 0 Advertised to peers (in unique update groups): 38.5.0.99 327814 2001:550:0:1000::261c:166 (metric 119060) from 2001:550:0:1000::261c:153 (38.28.1.102) Origin incomplete, localpref 130, valid, internal, best, group-best Received Path ID 0, Local Path ID 0, version 76403269 Community: 174:11100 174:20999 174:21101 174:22012 Originator: 38.28.1.102, Cluster list: 38.28.1.83, 38.28.1.67, 38.28.1.92 From brian at nc-ct.net Mon Jul 16 14:28:29 2018 From: brian at nc-ct.net (Brian) Date: Mon, 16 Jul 2018 10:28:29 -0400 Subject: Gmail admin Message-ID: <1531751309.560.16.camel@n1uro> Is there a gmail admin that can contact me offlist? Thanks much. From ekgermann at semperen.com Sun Jul 15 19:34:39 2018 From: ekgermann at semperen.com (Eric Germann) Date: Sun, 15 Jul 2018 15:34:39 -0400 Subject: Akamai contact Message-ID: <909B78DD-1259-447C-A122-0E5611A2C941@semperen.com> Now that I’ve learned Delta is an airline, runs hotels, and makes faucets, amongst other things, if there is an Akamai [Company that deploys CDN’s and other things] contact who could contact me off list re: continuing to troubleshoot a Delta Airlines [amongst other sites] issue that would be most appreciated. Thank you EKG -------------- 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 radevita at mejeticks.com Sat Jul 14 15:50:25 2018 From: radevita at mejeticks.com (Robert DeVita) Date: Sat, 14 Jul 2018 15:50:25 +0000 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> <6707686B-E03F-49D5-8E03-830A4C01522C@neilltech.com> <20180714151914.GA81645@meow.BKantor.net>, Message-ID: We had a ton of point to point wireless customers at 120E Van Buren out to South Mountain. About 10 years ago there was a significant shortage of fiber outside of Phoenix. You choices were SRP and Cox for the most part and SRP at that time had a very limited fiber network. They were actually the only company that offered dark Fiber out to Chandler when that campus first got built. Robert DeVita Managing Director Mejeticks c. 469-441-8864 e. radevita at mejeticks.com ________________________________ From: 32432146260n behalf of Sent: Saturday, July 14, 2018 10:44 AM To: North American Network Operators' Group Subject: Re: (perhaps off topic, but) Microwave Towers > On Jul 14, 2018, at 10:19 AM, Brian Kantor wrote: > >>> I find myself driving down Route 66. On our way through Arizona, I was surprised by what look like a lot of old-style microwave links. They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. > > Could they be a legacy of the Southern Pacific Railroad Internal Network Telecommunications, > now known under the acronym SPRINT? > - Brian > Not along Route 66 in Arizona. That generally parallels BNSF Railway, formerly the Santa Fe down there. Southern Pacific followed Interstate 10 much further south. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From stb at lassitu.de Sun Jul 15 09:03:53 2018 From: stb at lassitu.de (Stefan Bethke) Date: Sun, 15 Jul 2018 11:03:53 +0200 Subject: Linux BNG In-Reply-To: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> References: <585279b2-eb0b-9c9d-ce84-bc2651804998@gmail.com> Message-ID: Am 14.07.2018 um 14:13 schrieb Baldur Norddahl : > > I am considering writing a small program or kernel module. This would create two TAP devices (tap0 and tap1). Traffic received on tap0 with VLAN tagging, will be stripped of VLAN tagging and delivered on tap1. Traffic received on tap1 without VLAN tagging, will be tagged according to a lookup table using the destination IP address and then delivered on tap0. ARP and DHCP would need some special handling. As a proof of concept, a userland implementation using tap is likely the easiest to implement. But it won’t give you the throughput you’re looking for. I’d look at https://www.dpdk.org if you want to stay in userland. If FreeBSD ist an option, netgraph(4) is designed to allow packet filtering, manipulation and distribution in a set of small processing modules. In either case, Ethernet frames would be processed outside the regular network stack, but could be handed over to the kernel for further processing, i.e. DHCP or SLAAC. Stefan -- Stefan Bethke Fon +49 151 14070811 From jared at puck.nether.net Mon Jul 16 15:20:04 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 16 Jul 2018 11:20:04 -0400 Subject: Akamai contact In-Reply-To: <909B78DD-1259-447C-A122-0E5611A2C941@semperen.com> References: <909B78DD-1259-447C-A122-0E5611A2C941@semperen.com> Message-ID: <09DA2FD0-B048-486F-BC70-A02265F9EDEC@puck.nether.net> Replied offlist. Jared Mauch > On Jul 15, 2018, at 3:34 PM, Eric Germann wrote: > > Now that I’ve learned Delta is an airline, runs hotels, and makes faucets, amongst other things, if there is an Akamai [Company that deploys CDN’s and other things] contact who could contact me off list re: continuing to troubleshoot a Delta Airlines [amongst other sites] issue that would be most appreciated. > > Thank you > > EKG > From bortzmeyer at nic.fr Mon Jul 16 15:20:12 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 16 Jul 2018 17:20:12 +0200 Subject: Bogon prefix c0f:f618::/32 announced via Cogent In-Reply-To: References: Message-ID: <20180716152012.eewvmxncynxnts6z@nic.fr> On Sat, Jul 14, 2018 at 08:18:25AM +0800, Siyuan Miao wrote a message of 27 lines which said: > c0f:f618::/32 originated from AS327814 is announcing via Cogent for several > weeks. Apparently withdrawn 2018-07-14 around 16:00:00 UTC. Your mail to NANOG was effective :-) From job at ntt.net Mon Jul 16 15:26:03 2018 From: job at ntt.net (Job Snijders) Date: Mon, 16 Jul 2018 15:26:03 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> Message-ID: <20180716152603.GE42041@vurt.meerval.net> On Sat, Jul 14, 2018 at 11:03:16AM +0200, Mark Tinka wrote: > On 14/Jul/18 09:11, Baldur Norddahl wrote: > > In the RIPE part of the world there is no excuse for not getting > > RPKI correct because RIPE made it so easy. Perhaps the industry > > could agree on enabling RPKI validation on all european circuits for > > a start? > > I think the first step (and what I'd consider to be a quick win) is if > we determined all the prefixes that are being designated Invalid, and > nail down how many of those are Invalid due to the fact that they are > more-specifics announced without a ROA, vs. the parent aggregate which > is ROA'd. I calculated this here few days ago http://instituut.net/~job/rpki-report-2018.07.12.txt Markus Weber from KPN is generating a daily report here and drew similar conclusions: https://as286.net/data/ana-invalids.txt Markus scrapes all routes from the AS 286 PEs and marks the routes for which no valid or unknown alternative exists as "altpfx=NONE". > We would then ask the operators of those prefixes to either withdraw > them (easier, but unlikely) or sign them in the RPKI and create ROA's > for them (more work, but more likely). Going for the latter. Or delete the incorrect RPKI ROA. Either way is fine. > Once that is fixed, and even though the entire BGP world is not > running RPKI, those that are and are dropping Invalids would be 100% > certain that those Invalids are either leaks or hijacks. > > I think that will get us 50% of the way there, with the other 50% > would now just be growing community participation in RPKI. > > Thankfully, I believe all (or most) of the RIR's support a simple > "click of a button" to say "All prefixes up to a /24 or a /48 of the > aggregate should automatically be ROA'd if the aggregate, itself, is > ROA'd". So it shouldn't be a lot of work to get what is currently > broken fixed. And the beauty, we don't need everyone to participate in > the RPKI today for those that want the benefit right now to enjoy it > so. Perhaps the RIRs should start an outreach program to proactively inform the owners of those 2,200 invalid route announcements to get them to either fix or delete the RPKI ROA. Kind regards, Job From nanog at ics-il.net Mon Jul 16 16:01:56 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 16 Jul 2018 11:01:56 -0500 (CDT) Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> Message-ID: <436655203.537.1531756897488.JavaMail.mhammett@ThunderFuck> No idea where you were at, but lots of big companies have done microwave and lots of new companies do microwave. https://en.wikipedia.org/wiki/MCI_Communications MCI was founded as Microwave Communications, Inc. on October 3, 1963 with John D. Goeken being named the company's first president. The initial business plan was for the company to build a series of microwave relay stations between Chicago, Illinois and St. Louis, Missouri. The relay stations would then be used to interface with limited-range two-way radios used by truckers along U.S. Route 66 or by barges on the Illinois Waterway. https://en.wikipedia.org/wiki/Sprint_Corporation Southern Pacific maintained an extensive microwave communications system along its rights-of-way that the railroad used for internal communications. AT&T had a bunch and I think a couple sites are still active: http://long-lines.net/ Western Union had a microwave network as well. Lots of companies build microwave for internal communications. Rail and utility companies are big here. All of the cell companies do some microwave in their more rural areas. Lots of independent ISPs use microwave to build their entire network. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Miles Fidelman" To: nanog at nanog.org Sent: Saturday, July 14, 2018 9:54:25 AM Subject: (perhaps off topic, but) Microwave Towers Hi Folks, I find myself driving down Route 66. On our way through Arizona, I was surprised by what look like a lot of old-style microwave links. They pretty much follow the East-West rail line - where I'd expect there's a lot of fiber buried. Struck me as somewhat interesting. It also struck me that folks here might have some comments. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From michael at wi-fiber.io Mon Jul 16 16:56:31 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Mon, 16 Jul 2018 10:56:31 -0600 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <436655203.537.1531756897488.JavaMail.mhammett@ThunderFuck> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> <436655203.537.1531756897488.JavaMail.mhammett@ThunderFuck> Message-ID: Microwave radios are the things that break the mold of the incorrect assumption that just because it doesn't make sense to put up more wires to a house you can't have more than one provider. Considering that we've deployed a few wireless systems with less latency, jitter, and downtime than the local incumbent DOCSIS provider. In fact the greatest benefit to wireless microwave systems is the fact that they do not need to follow the right of way. Where wireline and fiberoptics must go through more hubs to get from side of town to the other, wireless is a point to point system with latencies+jitter sub 400 microseconds. No matter how great the incumbent fiber/dsl/coaxial network becomes, there will always be new microwave links going up. For their biggest strengths there's no replacement. Now, their weaknesses may be many, and may be apparent, their stengths just outweigh those. On 16 July 2018 at 10:01, Mike Hammett wrote: > No idea where you were at, but lots of big companies have done microwave > and lots of new companies do microwave. > > https://en.wikipedia.org/wiki/MCI_Communications > > MCI was founded as Microwave Communications, Inc. on October 3, 1963 with > John D. Goeken being named the company's first president. The initial > business plan was for the company to build a series of microwave relay > stations between Chicago, Illinois and St. Louis, Missouri. The relay > stations would then be used to interface with limited-range two-way radios > used by truckers along U.S. Route 66 or by barges on the Illinois Waterway. > > > https://en.wikipedia.org/wiki/Sprint_Corporation > > Southern Pacific maintained an extensive microwave communications system > along its rights-of-way that the railroad used for internal communications. > > > AT&T had a bunch and I think a couple sites are still active: > http://long-lines.net/ > > Western Union had a microwave network as well. > > > > > Lots of companies build microwave for internal communications. Rail and > utility companies are big here. > > All of the cell companies do some microwave in their more rural areas. > > Lots of independent ISPs use microwave to build their entire network. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Miles Fidelman" > To: nanog at nanog.org > Sent: Saturday, July 14, 2018 9:54:25 AM > Subject: (perhaps off topic, but) Microwave Towers > > Hi Folks, > > I find myself driving down Route 66. On our way through Arizona, I was > surprised by what look like a lot of old-style microwave links. They > pretty much follow the East-West rail line - where I'd expect there's a > lot of fiber buried. > > Struck me as somewhat interesting. > > It also struck me that folks here might have some comments. > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > From CGross at ninestarconnect.com Mon Jul 16 17:58:20 2018 From: CGross at ninestarconnect.com (Chris Gross) Date: Mon, 16 Jul 2018 17:58:20 +0000 Subject: Proving Gig Speed Message-ID: I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? From dwhite at olp.net Mon Jul 16 18:02:28 2018 From: dwhite at olp.net (Dan White) Date: Mon, 16 Jul 2018 13:02:28 -0500 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: <20180716180228.GA31062@dan.olp.net> We've found that running windows in safe mode produces better results with Ookla. And MACs usually do better as well. We've gotten >900mb/s with those two approaches. On 07/16/18 17:58 +0000, Chris Gross wrote: >I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > >Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > >Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? From matthew at corp.crocker.com Mon Jul 16 18:06:50 2018 From: matthew at corp.crocker.com (Matthew Crocker) Date: Mon, 16 Jul 2018 18:06:50 +0000 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: <2834779A-2B89-4B00-B4E6-9CFF2698A56E@corp.crocker.com> I'm on a Mac and launch 40 speedtests at the same time and monitor interface bandwidth #!/bin/bash for i in `./speedtest-cli --list | cut -f1 -d')' | head -n 40`; do ./speedtest-cli --server $i & done I've been able to saturate 10G links with this method -Matt -- Matthew Crocker Crocker Communications, Inc. President On 7/16/18, 1:59 PM, "NANOG on behalf of Chris Gross" wrote: I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? From jared at puck.nether.net Mon Jul 16 18:08:08 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 16 Jul 2018 14:08:08 -0400 Subject: Proving Gig Speed In-Reply-To: <20180716180228.GA31062@dan.olp.net> References: <20180716180228.GA31062@dan.olp.net> Message-ID: <20180716180808.GD2568@puck.nether.net> On Mon, Jul 16, 2018 at 01:02:28PM -0500, Dan White wrote: > We've found that running windows in safe mode produces better results with > Ookla. And MACs usually do better as well. We've gotten >900mb/s with those > two approaches. I've seen engineers even forget to account for differing behaviors of vendors, eg: Juniper doesn't display the layer-2 header counters This means a 920Mb/s link may actually be 100% once you add back in ethernet framing. Remind folks that they are seeing the TCP/UDP throughput and there is ethernet + IP headers involved. - Jared From merculiani at gmail.com Mon Jul 16 18:17:19 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Mon, 16 Jul 2018 13:17:19 -0500 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: We use Iperf3 for customers that complain about throughput, it's relatively low overhead compared to the Ookla HTML5 client. Same scenario as you, we have the tech hook up their laptop to the customer's drop and perform testing. I suspect your antivirus may be attempting to perform real-time inspection on the http(s) traffic, which would crush the little laptop CPU for sure. Message me off-list and I'll send you a private Iperf3 server IP to test with. -Matt On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross wrote: > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? From applebaumt at ochin.org Mon Jul 16 18:25:00 2018 From: applebaumt at ochin.org (Tyler Applebaum) Date: Mon, 16 Jul 2018 18:25:00 +0000 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: I have this deployed for our customers, it works well. I have yet to hear any complaints of not being able to max out a connection. https://github.com/adolfintel/speedtest -----Original Message----- From: NANOG On Behalf Of Matt Erculiani Sent: Monday, July 16, 2018 11:17 AM To: Chris Gross Cc: North American Network Operators' Group Subject: Re: Proving Gig Speed We use Iperf3 for customers that complain about throughput, it's relatively low overhead compared to the Ookla HTML5 client. Same scenario as you, we have the tech hook up their laptop to the customer's drop and perform testing. I suspect your antivirus may be attempting to perform real-time inspection on the http(s) traffic, which would crush the little laptop CPU for sure. Message me off-list and I'll send you a private Iperf3 server IP to test with. -Matt On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross wrote: > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compliance at ochin.org, delete this email and destroy all copies. From maxtul at netassist.ua Mon Jul 16 18:28:31 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 16 Jul 2018 21:28:31 +0300 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: Hi! Here I have http://www.speedtest.net/result/7475546550 from my notebook right now. It is i5-2540M CPU. First of all, NIC is much more important than CPU. Intel NIC can give 1Gbps easy, while Realtek or Broadcom probably never gives you more than ~300mbps. Linux times faster than Windows in the same hardware config. Speedtest very dependent on the browser, so try different and find better with your configuration as well. Sometimes you will need to tune TCP stack options to have >100mbps in one TCP session. Speedtest usually shows good results on download, but somewhy shows slow upload speed. Nowdays it is better, but several years ago I can't get more than 100mbps upload in same configuration of notebook and network I have now. Real uploads was on gig speeds. But the best is to use IPERF to do meansurements. It is really accurate. 16.07.18 20:58, Chris Gross пише: > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? > From nanog at ics-il.net Mon Jul 16 18:30:43 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 16 Jul 2018 13:30:43 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: Message-ID: <1125889893.778.1531765841861.JavaMail.mhammett@ThunderFuck> Ookla does have a client that you can install in various OSes to remove browser issues. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Chris Gross" To: "North American Network Operators' Group" Sent: Monday, July 16, 2018 12:58:20 PM Subject: Proving Gig Speed I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? From ben at 6by7.net Mon Jul 16 18:57:27 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 16 Jul 2018 11:57:27 -0700 Subject: Proving Gig Speed In-Reply-To: <1125889893.778.1531765841861.JavaMail.mhammett@ThunderFuck> References: <1125889893.778.1531765841861.JavaMail.mhammett@ThunderFuck> Message-ID: Second the recommendation for the downloadable ookla speedtest desktop app. -Ben > On Jul 16, 2018, at 11:30 AM, Mike Hammett wrote: > > Ookla does have a client that you can install in various OSes to remove browser issues. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Chris Gross" > To: "North American Network Operators' Group" > Sent: Monday, July 16, 2018 12:58:20 PM > Subject: Proving Gig Speed > > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? > From CGross at ninestarconnect.com Mon Jul 16 19:39:00 2018 From: CGross at ninestarconnect.com (Chris Gross) Date: Mon, 16 Jul 2018 19:39:00 +0000 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: Winner winner chicken dinner. I forgot to pull "Antivirus is at fault" card from my deck. 250/675 with it installed, 920/920 when removed so now I get to pass the the issue onwards. Thanks everyone for your replies and the responses for the adolfintel/speedtest github, I'll definitely look at it as a replacement for later. -----Original Message----- From: Matt Erculiani Sent: Monday, July 16, 2018 2:17 PM To: Chris Gross Cc: North American Network Operators' Group Subject: Re: Proving Gig Speed We use Iperf3 for customers that complain about throughput, it's relatively low overhead compared to the Ookla HTML5 client. Same scenario as you, we have the tech hook up their laptop to the customer's drop and perform testing. I suspect your antivirus may be attempting to perform real-time inspection on the http(s) traffic, which would crush the little laptop CPU for sure. Message me off-list and I'll send you a private Iperf3 server IP to test with. -Matt On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross wrote: > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? From Jason_Livingood at comcast.com Mon Jul 16 20:27:03 2018 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Mon, 16 Jul 2018 20:27:03 +0000 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: I recently talked at the IRTF on this subject and followed up with a blog post at https://blog.apnic.net/2018/06/21/measurement-challenges-in-the-gigabit-era/. There's also an open source speed test project you may want to consider at https://github.com/Comcast/Speed-testJS. Jason On 7/16/18, 2:00 PM, "NANOG on behalf of Chris Gross" wrote: I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? From carlos at race.com Mon Jul 16 20:31:13 2018 From: carlos at race.com (Carlos Alcantar) Date: Mon, 16 Jul 2018 20:31:13 +0000 Subject: Proving Gig Speed In-Reply-To: References: , Message-ID: It's a complete rabbit hole different hardware with different browsers give different readings, even not having your laptop plugged into power can cause a change in results due to dropping cpu to power save. The only reliable solution we found for field techs was the exfo ex1. Still talks to the ookla speedtest server etc. Obvious this is a well known issue and exfo has a solution. https://www.exfo.com/en/products/field-network-testing/network-protocol-testing/ethernet-testing/ex1/ Carlos Alcantar Race Communications / Race Team Member Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com ________________________________ From: NANOG on behalf of Chris Gross Sent: Monday, July 16, 2018 12:39 PM To: Matt Erculiani Cc: North American Network Operators' Group Subject: RE: Proving Gig Speed Winner winner chicken dinner. I forgot to pull "Antivirus is at fault" card from my deck. 250/675 with it installed, 920/920 when removed so now I get to pass the the issue onwards. Thanks everyone for your replies and the responses for the adolfintel/speedtest github, I'll definitely look at it as a replacement for later. -----Original Message----- From: Matt Erculiani Sent: Monday, July 16, 2018 2:17 PM To: Chris Gross Cc: North American Network Operators' Group Subject: Re: Proving Gig Speed We use Iperf3 for customers that complain about throughput, it's relatively low overhead compared to the Ookla HTML5 client. Same scenario as you, we have the tech hook up their laptop to the customer's drop and perform testing. I suspect your antivirus may be attempting to perform real-time inspection on the http(s) traffic, which would crush the little laptop CPU for sure. Message me off-list and I'll send you a private Iperf3 server IP to test with. -Matt On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross wrote: > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? From meekjt at gmail.com Mon Jul 16 20:34:17 2018 From: meekjt at gmail.com (Jon Meek) Date: Mon, 16 Jul 2018 16:34:17 -0400 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: On Mon, Jul 16, 2018 at 2:00 PM Chris Gross wrote: > I'm curious what people here have found as a good standard for providing > solid speedtest results to customers. All our techs have Dell laptops of > various models, but we always hit 100% CPU when doing a Ookla speedtest for > a server we have on site. So then if you have a customer paying for 600M or > 1000M symmetric, they get mad and demand you prove it's full speed. At that > point we have to roll out different people with JDSU's to test and prove > it's functional where a Ookla result would substitute fine if we didn't > have crummy laptops possibly. Even though from what I can see on some > google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of > course that never actually uses more than 50M sustained paying for a > residential connection, so running a circuit test on each turn up is > uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop > that can actually do symmetric gig, a rugged small inexpensive device we > can roll with instead to prove, or any other weird solution involving > ritual sacrifice that isn't too offensive to the eyes? > My practice is to use iperf with packet capture on both sides. The packet capture can then be analyzed for accurate per-second, or less, throughput, re-transmit rates, etc. This was implemented in a corporate network in several ways including dedicated servers (that also did other monitoring), and bootable CDs or USB sticks that a user in a small office could run on a standard desktop. Many interesting issues were discovered with this technique, and a fair number of perceived issues were debunked. Here is a wrapper to run iperf + tcpdump on each side of a connection (it could use some automation): https://github.com/meekj/perl-packet-tools/blob/master/run_iperf I originally did the analysis in Perl, but that can be fairly slow when processing 30 seconds of packets on a saturated GigE link. If anyone is interested there is now a C++ version along with analysis code in R at: https://github.com/meekj/iperfsum That version currently has only one second resolution. I have a R interface to libpcap files that could be used for analysis at any time resolution: https://github.com/meekj/libpcapR I have a plan to implement the complete test environment in a Docker container at some point. I also have a collection of small, mostly low-cost, computers that I plan to benchmark for network throughput and data analysis time. Some of the tiny computers can saturate a GigE link but are very slow processing the data. Jon From james.cutler at consultant.com Mon Jul 16 21:03:18 2018 From: james.cutler at consultant.com (James R Cutler) Date: Mon, 16 Jul 2018 17:03:18 -0400 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: > On Jul 16, 2018, at 4:31 PM, Carlos Alcantar wrote: > > It's a complete rabbit hole different hardware with different browsers give different readings, even not having your laptop plugged into power can cause a change in results due to dropping cpu to power save. The only reliable solution we found for field techs was the exfo ex1. Still talks to the ookla speedtest server etc. Obvious this is a well known issue and exfo has a solution. > > > > https://www.exfo.com/en/products/field-network-testing/network-protocol-testing/ethernet-testing/ex1/ > > > This is an interesting device. But the manufactures pages promote it like “Speedtest for Dummies”. Why don’t the User Manual or Spec Sheet mention IPv6 (or even (IPv4)? I should think technicians would want technical answers. Cutler > > > Carlos Alcantar > > Race Communications / Race Team Member > > Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com > > > > ________________________________ > From: NANOG on behalf of Chris Gross > Sent: Monday, July 16, 2018 12:39 PM > To: Matt Erculiani > Cc: North American Network Operators' Group > Subject: RE: Proving Gig Speed > > Winner winner chicken dinner. I forgot to pull "Antivirus is at fault" card from my deck. 250/675 with it installed, 920/920 when removed so now I get to pass the the issue onwards. > > Thanks everyone for your replies and the responses for the adolfintel/speedtest github, I'll definitely look at it as a replacement for later. > > -----Original Message----- > From: Matt Erculiani > Sent: Monday, July 16, 2018 2:17 PM > To: Chris Gross > Cc: North American Network Operators' Group > Subject: Re: Proving Gig Speed > > We use Iperf3 for customers that complain about throughput, it's relatively low overhead compared to the Ookla HTML5 client. Same scenario as you, we have the tech hook up their laptop to the customer's drop and perform testing. I suspect your antivirus may be attempting to perform real-time inspection on the http(s) traffic, which would crush the little laptop CPU for sure. > > Message me off-list and I'll send you a private Iperf3 server IP to test with. > > -Matt > > On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross wrote: >> I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. >> >> Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. >> >> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? From mike at mtcc.com Mon Jul 16 21:19:13 2018 From: mike at mtcc.com (Michael Thomas) Date: Mon, 16 Jul 2018 14:19:13 -0700 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: <9401d827-5b30-e3b4-5907-784a8767a6be@mtcc.com> Thanks, Jason. While I might have idle curiosity of how well my link performs when I first get it, beyond that the only time I care is when I or somebody else in the house starts screaming "THE INTERTOOBZ R SLOWZ!@!". I just had this happen to me the other night as I trying to watch possibly the worst movie ever on Amazon Prime. Maybe because I've been around a long time, my first suspicion is that something at home was slagging the ISP hop. This is often the case, but it is *maddeningly* slow to diagnose -- my popcorn was getting stale. Naively, I may have thought to hook up to one of the speed testers, but it would only show what was obvious from ping times, etc: lots of drops. So where was the problem? I had to manually go around and start disconnecting things. Even after I thought I had found the perp several times, my popcorn's freshness suffered. And in the end, I never did triangulate out where the problem was... and by morning it had magically fixed itself. My popcorn, on the other hand, gave its all. As we get more and more stuff on our home networks, the probability for crappy software, infected devices, piggy updates, etc multiplies. I'm sure this isn't news to $CORPRO network managers, but at home we quite literally have nothing to help us figure out and remedy these kinds of problems. Or if it turns out to *not* be our problem, that we have some reassurance when we decide to call the support desk and be put through IVR maze hell only to find out it was a local problem after all. cheers, Mike On 7/16/18 1:27 PM, Livingood, Jason wrote: > I recently talked at the IRTF on this subject and followed up with a blog post at https://blog.apnic.net/2018/06/21/measurement-challenges-in-the-gigabit-era/. There's also an open source speed test project you may want to consider at https://github.com/Comcast/Speed-testJS. > > Jason > > On 7/16/18, 2:00 PM, "NANOG on behalf of Chris Gross" wrote: > > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? > > From jwbensley at gmail.com Tue Jul 17 07:49:58 2018 From: jwbensley at gmail.com (James Bensley) Date: Tue, 17 Jul 2018 08:49:58 +0100 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: On 16 July 2018 at 18:58, Chris Gross wrote: Hi Chris, > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? I would say, don't use a browser based speed test - how fast is your browser? Answer: It can vary wildly! Also there are SO many variables when testing TCP you MUST test using UDP if you want to just test the network path. Every OS will behave differently with TCP, also with UDP but the variance is a lot lower. Also I recommend you test to a server on you network near to your peering & transit edge. This way users can test up to the point where you would have over the "The Internet" and have no further control. Testing to a server off-net (like off-net Ookla tells me nothing in my opinion). Virtually any modern day laptop with a 1G NIC will saturate a 1G link using UDP traffic in iPerf with ease. I crummy i3 netbook with 1G NIC can do it on one core/thread. We have several iPerf servers dotted around the network and our engineers can test to those at any time and it works well for us. Cheers, James. From saku at ytti.fi Tue Jul 17 08:54:17 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 17 Jul 2018 11:54:17 +0300 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: On Tue, 17 Jul 2018 at 10:53, James Bensley wrote: > Virtually any modern day laptop with a 1G NIC will saturate a 1G link > using UDP traffic in iPerf with ease. I crummy i3 netbook with 1G NIC > can do it on one core/thread. I guess if you use large packets this might be true. But personally, if I'm testing network, I'm interested in latency, jitter, packet, bps _AND_ pps goals as well, not just bps goal. And I've never seen clean 1Gbps on iperf with small packets. It just cannot be done, even if iPerf was written half decently and it used recvmmsg, it still wouldn't be anywhere near. Clean 1Gbps with small packets in user space is actually very much doable today, just you can't use UDP socket, you must use AF_PACKET on Linux or BPF on OSX and you can write portable 1Gbps UDP sender/receiver. I'm very surprised we don't have iperf like program for netengs which does this and reports latency, jitter, packet loss with binary search for highest lossless pps/bps rates. I started to write one with Anton Aksola in Rust (using libpnet[0]), and implemented quite flexible protocol (server/client, client can ask server exactly what kind of packet to construct/expect, what rate to send/receive over JSON based protocol), so you could also use it to ask it to DDoS your routers control-plane in lab etc. And actually got it working, OSX+Linux ~wirarate (still needs higher end laptop to do 1.5Mpps on single core and we didn't implement multicore support). But as both of us are trash in Rust (and every other applicable language in this domain), we kind of dropped the project once we had sufficient POC running on our laptops. Someone who actually can code, could easily implement such program in a weekend. I'm happy to share the trash we've done if someone intends to check this box in open source world. May use it for inspiration, or just straight up add polish and enough CLI to make it usable as-is. I think very important quality is multiplatform with static binaries. Because important use case is, that you can ask modestly informed customer to copy paste one line to donwload server and copy paste another line to have it running. If use case is that both ends have arbitrary clued people, then there are plenty of good solutions, like Cisco's trex[1]. But what I need is iPerf-like program, which actually a) performs and b) reports the correct things. [0] https://github.com/libpnet/libpnet [1] https://trex-tgn.cisco.com/ -- ++ytti From reuben-nanog at reub.net Tue Jul 17 09:20:13 2018 From: reuben-nanog at reub.net (Reuben Farrelly) Date: Tue, 17 Jul 2018 19:20:13 +1000 Subject: Carriage Burst Speeds [was Re: Proving Gig Speed] In-Reply-To: References: Message-ID: On 17/07/2018 5:49 pm, James Bensley wrote: > Also there are SO many variables when testing TCP you MUST test using > UDP if you want to just test the network path. Every OS will behave > differently with TCP, also with UDP but the variance is a lot lower. One of the issues I have repeatedly run into is an incorrect burst size set on shaped carriage circuits. In the specific case I have in mind now, I don't recall what the exact figures were - but the carrier side configuration was set by the carrier to be something like a 64k burst on a 20M L3 MPLS circuit. End to end speed testing results both with browsers and with iperf depended enormously on if the test was done with TCP or UDP. Consequently the end customer was unable to get more than 2-3MBit/sec of single stream TCP traffic through the link. The carrier insisted that because we could still get 19+ MBit/sec of UDP then there was no issue. This was the same for all operating systems. The end customer certainly didn't feel that they were getting the 20Mbit circuit they were sold. The carrier view was that as we were able to get 20 TCP streams running concurrently and max out the link that they were providing the service as ordered. After many months of testing and negotiating we were able to get the shaper burst increased temporarily, and the issue completely went away. The customer was able to get over 18MBit/sec of continuous TCP throughput on a single stream. I was told that despite this finding and admission that the burst was indeed way too small, the carrier was going to continue to provision circuits with almost no burst, because this was their "standard configuration". The common belief seemed to be that a burst was a free upgrade for the customer. I was of the alternate view that this parameter was required to be set correctly for TCP to function properly to get their quoted CIR. I'd be very interested in other's thoughts with regards to testing of this. It seems to me that measuring performance with UDP only means that this very critical real-world aspect of a circuit (burst size on a shaper) is not tested, and this seems to be a very common misconfiguration. In my case...seen across multiple carriers over many years and many dozens of hours spent on "faults" related to it. [NB: I've always used the rule of thumb that the L3 burst size should be about 1/8th the Contracted Line Rate, but there seems to be no consensus whatsoever about that...certainly no agreement whatsoever within the carrier world] Reuben From mark.tinka at seacom.mu Tue Jul 17 11:27:09 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 13:27:09 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180716152603.GE42041@vurt.meerval.net> References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> <20180716152603.GE42041@vurt.meerval.net> Message-ID: On 16/Jul/18 17:26, Job Snijders wrote: > I calculated this here few days ago > http://instituut.net/~job/rpki-report-2018.07.12.txt > > Markus Weber from KPN is generating a daily report here and drew similar > conclusions: https://as286.net/data/ana-invalids.txt Markus scrapes all > routes from the AS 286 PEs and marks the routes for which no valid or > unknown alternative exists as "altpfx=NONE". Thanks. Protein. So the numbers are not that far off from when I last checked this back in 2016, i.e., less than 1% of the total IPv4 routing table. Do you have numbers for IPv6, out of interest? > Or delete the incorrect RPKI ROA. Either way is fine. That would work, but the risk with that then is trying to get those networks back into RPKI would be more difficult, and if they do, chances are that the folk that were pushing it would have since left the company, making our education efforts a lot more difficult. So I'd be for pushing these folk to ROA the more-specifics, which is just a click of a button in their RIR's system. > Perhaps the RIRs should start an outreach program to proactively inform > the owners of those 2,200 invalid route announcements to get them to > either fix... I would be in support of this, and would certainly work very closely with AFRINIC to fix our side of things. Happy to also do a co-preso paper with you during EPF in Athens for the RIPE side of things. If you'll be in Vancouver, we can do the same for the ARIN side. I'm at MyNOG next week, and can speak to the folk from APNIC that will be showing up about this as well. That leaves LACNIC. Mark. From mark.tinka at seacom.mu Tue Jul 17 11:50:32 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 13:50:32 +0200 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: <0cb0b0c9-ff4a-99a3-2d88-da7077baa0bd@seacom.mu> On 16/Jul/18 19:58, Chris Gross wrote: > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? (Ookla) speed tests, in general, are a fundamental problem we grapple with in only one of our markets, where previous ISP trust was eroded by the incumbent. So we are all paying the price for that 20 years on, i.e., the solution to every network problem is a speed test. If a Skype call drops, that's a speed test. If an e-mail attachment doesn't work properly, that's a speed tests. Wi-fi signal is bad, that's a speed test. If Office 365 self-destructs, that's a speed test. If 8.8.8.8 goes coo-koo, that's a speed test. You get the idea... I always ask speed test proponents - "How do you speed test a 100Gbps Internet service delivery :-\?" Server-side limitations notwithstanding, as you rightly point out, the client machine is also a potential point of contention (all pun intended). We recently dealt with a customer that had our NOC running around for 2 months about speed test results, only to realize that the customer was using a USB-to-Ethernet converter for his laptop to run the tests the whole time, which topped out at ±7Mbps, on their 100Mbps service. With a proper laptop that had an on-board Ethernet port being truck-rolled with an engineer to the site showing the difference, the case is now closed. But can you imagine the amount of noise that had been generated over the past 8 weeks? Find me a hole where the floor is pasted with "speed tests go here" so deep that even I can't see it, and I will throw the whole concept so far down it won't stand the chance of ever being converted to oil. But to answer your questions - for some customers, we insist on JDSU testing for large capacities, but only if it's worth the effort. Mark. From mark.tinka at seacom.mu Tue Jul 17 11:51:40 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 13:51:40 +0200 Subject: Proving Gig Speed In-Reply-To: <20180716180808.GD2568@puck.nether.net> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> Message-ID: On 16/Jul/18 20:08, Jared Mauch wrote: > This means a 920Mb/s link may actually be 100% once you add back in > ethernet framing. Remind folks that they are seeing the TCP/UDP throughput > and there is ethernet + IP headers involved. But you sold me 1Gbps. Stop stiffing me my 80Mbps :-)... Mark. From mark.tinka at seacom.mu Tue Jul 17 11:52:27 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 13:52:27 +0200 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: On 16/Jul/18 20:17, Matt Erculiani wrote: > We use Iperf3 for customers that complain about throughput, it's > relatively low overhead compared to the Ookla HTML5 client. Same > scenario as you, we have the tech hook up their laptop to the > customer's drop and perform testing. I suspect your antivirus may be > attempting to perform real-time inspection on the http(s) traffic, > which would crush the little laptop CPU for sure. But iPerf doesn't paint pretty pictures at the end of the test that I can brag to my friends with :-)... Mark. From mark.tinka at seacom.mu Tue Jul 17 12:02:17 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 14:02:17 +0200 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> On 16/Jul/18 22:31, Carlos Alcantar wrote: > It's a complete rabbit hole... Couldn't have said it better myself! Mark. From mark.tinka at seacom.mu Tue Jul 17 12:04:13 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 14:04:13 +0200 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: <3a21afd2-6862-9557-5bfb-515ca2e154a6@seacom.mu> On 16/Jul/18 22:34, Jon Meek wrote: > My practice is to use iperf with packet capture on both sides. The packet > capture can then be analyzed for accurate per-second, or less, throughput, > re-transmit rates, etc. This was implemented in a corporate network in > several ways including dedicated servers (that also did other monitoring), > and bootable CDs or USB sticks that a user in a small office could run on a > standard desktop. Many interesting issues were discovered with this > technique, and a fair number of perceived issues were debunked. If you are doing this for yourself, as a network engineer, this is great. But simple Joe at home doesn't care about all this fancy analysis. Does he get a pretty picture saying "Yay", or "Nay", that's all? Mark. From mark.tinka at seacom.mu Tue Jul 17 12:06:27 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 14:06:27 +0200 Subject: Proving Gig Speed In-Reply-To: <9401d827-5b30-e3b4-5907-784a8767a6be@mtcc.com> References: <9401d827-5b30-e3b4-5907-784a8767a6be@mtcc.com> Message-ID: On 16/Jul/18 23:19, Michael Thomas wrote: >   > > As we get more and more stuff on our home networks, the probability > for crappy software, infected devices, piggy updates, etc multiplies. > I'm sure this isn't news to $CORPRO network managers, but at home we > quite literally have nothing to help us figure out and remedy these > kinds of problems. Or if it turns out to *not* be our problem, that we > have some reassurance when we decide to call the support desk and be > put through IVR maze hell only to find out it was a local problem > after all. Well, at least you had the foresight not to "speed test" your way you into keeping your popcorn fresh :-). Mark. From kscott.helms at gmail.com Tue Jul 17 12:07:27 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Tue, 17 Jul 2018 08:07:27 -0400 Subject: Proving Gig Speed In-Reply-To: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> Message-ID: That's absolutely true, but I don't see any real alternatives in some cases. I've actually built automated testing into some of the CPE we've deployed and that works pretty well for some models but other devices don't seem to be able to fill a ~500 mbps link. On Tue, Jul 17, 2018 at 8:03 AM Mark Tinka wrote: > > > On 16/Jul/18 22:31, Carlos Alcantar wrote: > > > It's a complete rabbit hole... > > Couldn't have said it better myself! > > Mark. > From mattlists at rivervalleyinternet.net Tue Jul 17 12:07:53 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 17 Jul 2018 08:07:53 -0400 Subject: Proving Gig Speed In-Reply-To: References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> Message-ID: <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> Which is why we over provision by 10%. > On Jul 17, 2018, at 07:51, Mark Tinka wrote: > > > >> On 16/Jul/18 20:08, Jared Mauch wrote: >> >> This means a 920Mb/s link may actually be 100% once you add back in >> ethernet framing. Remind folks that they are seeing the TCP/UDP throughput >> and there is ethernet + IP headers involved. > > But you sold me 1Gbps. Stop stiffing me my 80Mbps :-)... > > Mark. From mark.tinka at seacom.mu Tue Jul 17 12:08:29 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 14:08:29 +0200 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: On 17/Jul/18 09:49, James Bensley wrote: > > Also I recommend you test to a server on you network near to your > peering & transit edge. This way users can test up to the point where > you would have over the "The Internet" and have no further control. > Testing to a server off-net (like off-net Ookla tells me nothing in my > opinion). In our market, users don't care about the server that is 1ms away. They want to test the one which is 170ms, because that is where the gaming network sits. And heaven forbid that 170ms server does not return their full 1Gbps subscription report, never mind the state of its affairs, or who's running (if anyone even remembered it's there). Mark. From mark.tinka at seacom.mu Tue Jul 17 12:11:35 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 14:11:35 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> Message-ID: On 17/Jul/18 14:07, K. Scott Helms wrote: > > That's absolutely true, but I don't see any real alternatives in some > cases.  I've actually built automated testing into some of the CPE > we've deployed and that works pretty well for some models but other > devices don't seem to be able to fill a ~500 mbps link. So what are you going to do when 10Gbps FTTH into the home becomes the norm? Perhaps laptops and servers of the time won't even see this as a rounding error :-\... Mark. From mark.tinka at seacom.mu Tue Jul 17 12:12:39 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 14:12:39 +0200 Subject: Proving Gig Speed In-Reply-To: <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> Message-ID: On 17/Jul/18 14:07, Matt Hoppes wrote: > Which is why we over provision by 10%. After a bunch of customers, it starts to add ($$) up. And what do you do if you don't own the last mile, and your Layer 2 service provider sticks to the letter? Mark. From mattlists at rivervalleyinternet.net Tue Jul 17 12:18:45 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 17 Jul 2018 08:18:45 -0400 Subject: Proving Gig Speed In-Reply-To: References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> Message-ID: <90BC7E15-5C78-4BD5-B35F-33C4414EF7D7@rivervalleyinternet.net> Get a better middle mile. That’s why we use Comcast for much of our middle mile. > On Jul 17, 2018, at 08:12, Mark Tinka wrote: > > > > On 17/Jul/18 14:07, Matt Hoppes wrote: > >> Which is why we over provision by 10%. > > After a bunch of customers, it starts to add ($$) up. > > And what do you do if you don't own the last mile, and your Layer 2 service provider sticks to the letter? > > Mark. From cra at WPI.EDU Tue Jul 17 12:37:01 2018 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 17 Jul 2018 08:37:01 -0400 Subject: Bogon prefix c0f:f618::/32 announced via Cogent In-Reply-To: References: Message-ID: <20180717123701.onorkklt5h6rdzge@angus.ind.wpi.edu> Looks like a typo of 2c0f:f618: A V Destination P Prf Metric 1 Metric 2 Next hop AS path* ? 2c0f:f618::/32 B 170 150 69040 174 327814 ? unverified >fe80::f5c0:800:2 On Sat, Jul 14, 2018 at 08:18:25AM +0800, Siyuan Miao wrote: > Hi, > > c0f:f618::/32 originated from AS327814 is announcing via Cogent for several > weeks. > > I've tried to contact Cogent and AS327814 but didn't receive any reply. > > Tue Jul 10 17:52:48.602 UTC > BGP routing table entry for c0f:f618::/32 > Versions: > Process bRIB/RIB SendTblVer > Speaker 76403269 76403269 > Local Label: 61339 > Last Modified: Jul 3 13:31:40.815 for 1w0d > Paths: (1 available, best #1) > Advertised to peers (in unique update groups): > 38.5.0.99 > Path #1: Received by speaker 0 > Advertised to peers (in unique update groups): > 38.5.0.99 > 327814 > 2001:550:0:1000::261c:166 (metric 119060) from > 2001:550:0:1000::261c:153 (38.28.1.102) > Origin incomplete, localpref 130, valid, internal, best, group-best > Received Path ID 0, Local Path ID 0, version 76403269 > Community: 174:11100 174:20999 174:21101 174:22012 > Originator: 38.28.1.102, Cluster list: 38.28.1.83, 38.28.1.67, 38.28.1.92 From cra at WPI.EDU Tue Jul 17 12:41:38 2018 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 17 Jul 2018 08:41:38 -0400 Subject: Bogon prefix c0f:f618::/32 announced via Cogent In-Reply-To: <20180716152012.eewvmxncynxnts6z@nic.fr> References: <20180716152012.eewvmxncynxnts6z@nic.fr> Message-ID: <20180717124138.cwrp7rmjoxcb4us2@angus.ind.wpi.edu> On Mon, Jul 16, 2018 at 05:20:12PM +0200, Stephane Bortzmeyer wrote: > On Sat, Jul 14, 2018 at 08:18:25AM +0800, > Siyuan Miao wrote > a message of 27 lines which said: > > > c0f:f618::/32 originated from AS327814 is announcing via Cogent for several > > weeks. > > Apparently withdrawn 2018-07-14 around 16:00:00 UTC. Your mail to NANOG was > effective :-) I see it right now... From mark.tinka at seacom.mu Tue Jul 17 13:03:26 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 15:03:26 +0200 Subject: Proving Gig Speed In-Reply-To: <90BC7E15-5C78-4BD5-B35F-33C4414EF7D7@rivervalleyinternet.net> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> <90BC7E15-5C78-4BD5-B35F-33C4414EF7D7@rivervalleyinternet.net> Message-ID: On 17/Jul/18 14:18, Matt Hoppes wrote: > Get a better middle mile. That’s why we use Comcast for much of our middle mile. Comcast don't operate in Africa. Some countries don't have (m)any options. Mark. From eparra at zscaler.com Mon Jul 16 18:27:02 2018 From: eparra at zscaler.com (Eddie Parra) Date: Mon, 16 Jul 2018 11:27:02 -0700 Subject: Proving Gig Speed In-Reply-To: <20180716180808.GD2568@puck.nether.net> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> Message-ID: <0D898C12-4D81-4EBE-AA09-2A37B34FF9EF@zscaler.com> +1 to Jared. I’ve seen people not account for this when sizing CoS as well on Juniper. -Eddie > On Jul 16, 2018, at 11:08 AM, Jared Mauch wrote: > >> On Mon, Jul 16, 2018 at 01:02:28PM -0500, Dan White wrote: >> We've found that running windows in safe mode produces better results with >> Ookla. And MACs usually do better as well. We've gotten >900mb/s with those >> two approaches. > > I've seen engineers even forget to account for differing behaviors > of vendors, eg: Juniper doesn't display the layer-2 header counters > > This means a 920Mb/s link may actually be 100% once you add back in > ethernet framing. Remind folks that they are seeing the TCP/UDP throughput > and there is ethernet + IP headers involved. > > - Jared > From morgan.miskell at caro.net Mon Jul 16 18:32:56 2018 From: morgan.miskell at caro.net (Morgan A. Miskell) Date: Mon, 16 Jul 2018 14:32:56 -0400 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: <8879a8ef-2c5f-ebce-4c0c-f31a7bb66863@caro.net> I use my Lenovo Thinkpad with or any "decent" client machine and run iperf to prove the connectivity. Of course, client switch quality or firewall can be an issue. On 07/16/2018 01:58 PM, Chris Gross wrote: > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? > -- Morgan A. Miskell CaroNet Data Centers 704-643-8330 x206 ---------------------------------------------------------------------------- The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited. ---------------------------------------------------------------------------- From pl+list at pmacct.net Mon Jul 16 17:00:59 2018 From: pl+list at pmacct.net (Paolo Lucente) Date: Mon, 16 Jul 2018 17:00:59 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180712175029.GC3037@vurt.meerval.net> References: <20180712175029.GC3037@vurt.meerval.net> Message-ID: <20180716170059.GA20221@moussaka.pmacct.net> Hi Job, All, It is definitely great to see progress on the deployment side! I realize that there may be some gaps in the network operator toolchain, and this may be something i'd like to contribute to. For network operators to better understand the impact of BGP hijacks in terms of revenue or volumes of traffic that went missing, it makes perfect sense if network monitoring tools are aware of which BGP announcements are invalid or not. I will look into adding support for the RTR protocol (RFC 6810, RFC 8210) to pmacct ( https://github.com/pmacct/pmacct , http://pmacct.net/ ) and expose the validation state through an extra field (when collecting routing tables) and primitive (when accounting traffic and correlating it with BGP data). Updating the telemetry tools to be fully aware of RPKI validation states should come in handy! Paolo On Thu, Jul 12, 2018 at 05:50:29PM +0000, Job Snijders wrote: > Hi all, > > I wanted to share with you that a ton of activity is taking place in the > Dutch networker community to deploy RPKI based BGP Origin Validation. > The mantra is "invalid == reject" on all EBGP sessions. > > What's of note here is that we're now seeing the first commercial ISPs > doing Origin Validation. This is a significant step forward compared to > what we observed so far (it seemed OV was mostly limited to academic > institutions & toy networks). But six months ago Amsio (https://www.amsio.com/en/) > made the jump, and today Fusix deployed (https://fusix.nl/deploying-rpki/). > > We've also seen an uptake of Origin Validation at Internet Exchange > route servers: AMS-IX and FranceIX have already deployed. I've read that > RPKI OV is under consideration at a number of other exchanges. > > Other cool news is that Cloudflare launched a Certificate Transparency > initiative to help keep everyone honest. Announcement at: > https://twitter.com/grittygrease/status/1017224762542587907 > Certificate Transparency is a fascinating tool, really a necessity to > build confidence in any PKI systems. > > Anyone here working to deploy RPKI based Origin Validation in their > network and reject invalid announcements? Anything of note to share? > > Kind regards, > > Job From kjohn at ethoplex.com Tue Jul 17 03:12:34 2018 From: kjohn at ethoplex.com (Keefe John) Date: Mon, 16 Jul 2018 22:12:34 -0500 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> <436655203.537.1531756897488.JavaMail.mhammett@ThunderFuck> Message-ID: As Mike points out, there are a lot of us doing fixed-wireless / microwave now. We have our own industry. See: http://wispa.org/ -- Keefe John CEO Ethoplex Direct: 262.345.5200 -------------------- Ethoplex Business Internet http://www.ethoplex.com/ Signal Residential Internet http://www.signalisp.com/ https://www.linkedin.com/in/keefejohn/ On Mon, Jul 16, 2018 at 11:56 AM, Michael Crapse wrote: > Microwave radios are the things that break the mold of the incorrect > assumption that just because it doesn't make sense to put up more wires to > a house you can't have more than one provider. Considering that we've > deployed a few wireless systems with less latency, jitter, and downtime > than the local incumbent DOCSIS provider. In fact the greatest benefit to > wireless microwave systems is the fact that they do not need to follow the > right of way. Where wireline and fiberoptics must go through more hubs to > get from side of town to the other, wireless is a point to point system > with latencies+jitter sub 400 microseconds. > > No matter how great the incumbent fiber/dsl/coaxial network becomes, there > will always be new microwave links going up. For their biggest strengths > there's no replacement. > Now, their weaknesses may be many, and may be apparent, their stengths just > outweigh those. > > On 16 July 2018 at 10:01, Mike Hammett wrote: > > > No idea where you were at, but lots of big companies have done microwave > > and lots of new companies do microwave. > > > > https://en.wikipedia.org/wiki/MCI_Communications > > > > MCI was founded as Microwave Communications, Inc. on October 3, 1963 with > > John D. Goeken being named the company's first president. The initial > > business plan was for the company to build a series of microwave relay > > stations between Chicago, Illinois and St. Louis, Missouri. The relay > > stations would then be used to interface with limited-range two-way > radios > > used by truckers along U.S. Route 66 or by barges on the Illinois > Waterway. > > > > > > https://en.wikipedia.org/wiki/Sprint_Corporation > > > > Southern Pacific maintained an extensive microwave communications system > > along its rights-of-way that the railroad used for internal > communications. > > > > > > AT&T had a bunch and I think a couple sites are still active: > > http://long-lines.net/ > > > > Western Union had a microwave network as well. > > > > > > > > > > Lots of companies build microwave for internal communications. Rail and > > utility companies are big here. > > > > All of the cell companies do some microwave in their more rural areas. > > > > Lots of independent ISPs use microwave to build their entire network. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Miles Fidelman" > > To: nanog at nanog.org > > Sent: Saturday, July 14, 2018 9:54:25 AM > > Subject: (perhaps off topic, but) Microwave Towers > > > > Hi Folks, > > > > I find myself driving down Route 66. On our way through Arizona, I was > > surprised by what look like a lot of old-style microwave links. They > > pretty much follow the East-West rail line - where I'd expect there's a > > lot of fiber buried. > > > > Struck me as somewhat interesting. > > > > It also struck me that folks here might have some comments. > > > > Miles Fidelman > > > > -- > > In theory, there is no difference between theory and practice. > > In practice, there is. .... Yogi Berra > > > > > > > -- Keefe John CEO Ethoplex Direct: 262.345.5200 -------------------- Ethoplex Business Internet http://www.ethoplex.com/ Signal Residential Internet http://www.signalisp.com/ https://www.linkedin.com/in/keefejohn/ From nanog at ics-il.net Tue Jul 17 14:36:34 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 Jul 2018 09:36:34 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: Message-ID: <350999753.1260.1531838190249.JavaMail.mhammett@ThunderFuck> It tells you how good your peering is. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "James Bensley" To: "North American Network Operators' Group" Sent: Tuesday, July 17, 2018 2:49:58 AM Subject: Re: Proving Gig Speed On 16 July 2018 at 18:58, Chris Gross wrote: Hi Chris, > I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? I would say, don't use a browser based speed test - how fast is your browser? Answer: It can vary wildly! Also there are SO many variables when testing TCP you MUST test using UDP if you want to just test the network path. Every OS will behave differently with TCP, also with UDP but the variance is a lot lower. Also I recommend you test to a server on you network near to your peering & transit edge. This way users can test up to the point where you would have over the "The Internet" and have no further control. Testing to a server off-net (like off-net Ookla tells me nothing in my opinion). Virtually any modern day laptop with a 1G NIC will saturate a 1G link using UDP traffic in iPerf with ease. I crummy i3 netbook with 1G NIC can do it on one core/thread. We have several iPerf servers dotted around the network and our engineers can test to those at any time and it works well for us. Cheers, James. From nanog at ics-il.net Tue Jul 17 14:41:58 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 Jul 2018 09:41:58 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> Message-ID: <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" To: "K. Scott Helms" Cc: "NANOG list" Sent: Tuesday, July 17, 2018 7:11:35 AM Subject: Re: Proving Gig Speed On 17/Jul/18 14:07, K. Scott Helms wrote: > > That's absolutely true, but I don't see any real alternatives in some > cases. I've actually built automated testing into some of the CPE > we've deployed and that works pretty well for some models but other > devices don't seem to be able to fill a ~500 mbps link. So what are you going to do when 10Gbps FTTH into the home becomes the norm? Perhaps laptops and servers of the time won't even see this as a rounding error :-\... Mark. From nanog at ics-il.net Tue Jul 17 14:42:41 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 Jul 2018 09:42:41 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> Message-ID: <779483637.1269.1531838556908.JavaMail.mhammett@ThunderFuck> Build your own last mile or order that 10% more? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" To: "Matt Hoppes" Cc: "North American Network Operators' Group" Sent: Tuesday, July 17, 2018 7:12:39 AM Subject: Re: Proving Gig Speed On 17/Jul/18 14:07, Matt Hoppes wrote: > Which is why we over provision by 10%. After a bunch of customers, it starts to add ($$) up. And what do you do if you don't own the last mile, and your Layer 2 service provider sticks to the letter? Mark. From branto at argentiumsolutions.com Tue Jul 17 14:47:35 2018 From: branto at argentiumsolutions.com (Brant Ian Stevens) Date: Tue, 17 Jul 2018 10:47:35 -0400 Subject: Proving Gig Speed In-Reply-To: <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: "There is no reason for any individual to have a computer in his home." "640K ought to be enough for anybody." On 7/17/18 10:41 AM, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mark Tinka" > To: "K. Scott Helms" > Cc: "NANOG list" > Sent: Tuesday, July 17, 2018 7:11:35 AM > Subject: Re: Proving Gig Speed > > > > On 17/Jul/18 14:07, K. Scott Helms wrote: > >> That's absolutely true, but I don't see any real alternatives in some >> cases. I've actually built automated testing into some of the CPE >> we've deployed and that works pretty well for some models but other >> devices don't seem to be able to fill a ~500 mbps link. > So what are you going to do when 10Gbps FTTH into the home becomes the norm? > > Perhaps laptops and servers of the time won't even see this as a > rounding error :-\... > > Mark. > From andy at newslink.com Tue Jul 17 14:53:01 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Tue, 17 Jul 2018 09:53:01 -0500 Subject: Proving Gig Speed In-Reply-To: <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: > On Jul 17, 2018, at 9:41 AM, Mike Hammett wrote: > > 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com Well, in a few years when we’re all watching 4D 32K Netflix on our 16-foot screens with 5 million DPI, it’ll make all the difference in the world, right? Tongue-in-cheek obviously. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From eric.kuhnke at gmail.com Tue Jul 17 15:27:46 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 17 Jul 2018 08:27:46 -0700 Subject: (perhaps off topic, but) Microwave Towers In-Reply-To: <436655203.537.1531756897488.JavaMail.mhammett@ThunderFuck> References: <2d83c709-d209-9fc3-ded1-aada5bfc7bd3@meetinghouse.net> <436655203.537.1531756897488.JavaMail.mhammett@ThunderFuck> Message-ID: Also worth mentioning that AT&T Canada originated with the Canadian Pacific Railway... CP Railway and Unitel --> AT&T Canada --> Allstream --> MTS-Allstream --> Zayo I have a GIS dataset with about 90% of the most important hilltop and mountaintop tower sites in WA, BC, OR and ID. There is a ton of stuff out there and operational. On Mon, Jul 16, 2018 at 9:01 AM, Mike Hammett wrote: > No idea where you were at, but lots of big companies have done microwave > and lots of new companies do microwave. > > https://en.wikipedia.org/wiki/MCI_Communications > > MCI was founded as Microwave Communications, Inc. on October 3, 1963 with > John D. Goeken being named the company's first president. The initial > business plan was for the company to build a series of microwave relay > stations between Chicago, Illinois and St. Louis, Missouri. The relay > stations would then be used to interface with limited-range two-way radios > used by truckers along U.S. Route 66 or by barges on the Illinois Waterway. > > > https://en.wikipedia.org/wiki/Sprint_Corporation > > Southern Pacific maintained an extensive microwave communications system > along its rights-of-way that the railroad used for internal communications. > > > AT&T had a bunch and I think a couple sites are still active: > http://long-lines.net/ > > Western Union had a microwave network as well. > > > > > Lots of companies build microwave for internal communications. Rail and > utility companies are big here. > > All of the cell companies do some microwave in their more rural areas. > > Lots of independent ISPs use microwave to build their entire network. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Miles Fidelman" > To: nanog at nanog.org > Sent: Saturday, July 14, 2018 9:54:25 AM > Subject: (perhaps off topic, but) Microwave Towers > > Hi Folks, > > I find myself driving down Route 66. On our way through Arizona, I was > surprised by what look like a lot of old-style microwave links. They > pretty much follow the East-West rail line - where I'd expect there's a > lot of fiber buried. > > Struck me as somewhat interesting. > > It also struck me that folks here might have some comments. > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > From nanog at ics-il.net Tue Jul 17 15:35:00 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 Jul 2018 10:35:00 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <899353999.1633.1531841698592.JavaMail.mhammett@ThunderFuck> Unrelated. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brant Ian Stevens" To: nanog at nanog.org Sent: Tuesday, July 17, 2018 9:47:35 AM Subject: Re: Proving Gig Speed "There is no reason for any individual to have a computer in his home." "640K ought to be enough for anybody." On 7/17/18 10:41 AM, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mark Tinka" > To: "K. Scott Helms" > Cc: "NANOG list" > Sent: Tuesday, July 17, 2018 7:11:35 AM > Subject: Re: Proving Gig Speed > > > > On 17/Jul/18 14:07, K. Scott Helms wrote: > >> That's absolutely true, but I don't see any real alternatives in some >> cases. I've actually built automated testing into some of the CPE >> we've deployed and that works pretty well for some models but other >> devices don't seem to be able to fill a ~500 mbps link. > So what are you going to do when 10Gbps FTTH into the home becomes the norm? > > Perhaps laptops and servers of the time won't even see this as a > rounding error :-\... > > Mark. > From saku at ytti.fi Tue Jul 17 15:38:52 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 17 Jul 2018 18:38:52 +0300 Subject: Proving Gig Speed In-Reply-To: <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: On Tue, 17 Jul 2018 at 17:45, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. I admire your confidence, when historically we've had poor success in these type of predictions. I seriously doubt we're now living in special time in history where we find the limit of consumer bandwidth demand, while I have no idea what would drive it or how it would be implemented, I'm betting against myself having all the information about future. -- ++ytti From mark.tinka at seacom.mu Tue Jul 17 15:44:10 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 17:44:10 +0200 Subject: Proving Gig Speed In-Reply-To: <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: On 17/Jul/18 16:41, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away > from Ethernet to WiFi where the noise floor for most installs prevents > anyone from reaching 802.11n speeds, much less whatever alphabet soup > comes later. Doesn't stop customers from buying it if it's cheap and available, which doesn't stop them from proving they are getting 10Gbps as advertised. Mark. From mark.tinka at seacom.mu Tue Jul 17 15:45:48 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 17:45:48 +0200 Subject: Proving Gig Speed In-Reply-To: <779483637.1269.1531838556908.JavaMail.mhammett@ThunderFuck> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> <779483637.1269.1531838556908.JavaMail.mhammett@ThunderFuck> Message-ID: <9e45b256-560f-3a27-afa3-5e11454b79e3@seacom.mu> On 17/Jul/18 16:42, Mike Hammett wrote: > Build your own last mile... Hmmh, don't know why everyone doesn't just do that. > or order that 10% more? As Trump said, "All I can do is ask the question..." Mark. From md1clv at md1clv.com Tue Jul 17 15:46:10 2018 From: md1clv at md1clv.com (Daniel Ankers) Date: Tue, 17 Jul 2018 16:46:10 +0100 Subject: Proving Gig Speed In-Reply-To: <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: On 17 July 2018 at 15:41, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away from > Ethernet to WiFi where the noise floor for most installs prevents anyone > from reaching 802.11n speeds, much less whatever alphabet soup comes later. > > That's unless 802.11ad/.11ay gain in popularity. 60GHz offers lots of bandwidth and isn't particularly good at getting through brick walls, which might offer some relief to the noise floor problem. Dan From mark.tinka at seacom.mu Tue Jul 17 15:46:32 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 17:46:32 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <416dd90b-b1e5-10d3-6b66-7b964384e8ad@seacom.mu> On 17/Jul/18 17:38, Saku Ytti wrote: > I admire your confidence, when historically we've had poor success in > these type of predictions. I seriously doubt we're now living in > special time in history where we find the limit of consumer bandwidth > demand, while I have no idea what would drive it or how it would be > implemented, I'm betting against myself having all the information > about future. +1. Mark. From nanog at ics-il.net Tue Jul 17 15:47:45 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 Jul 2018 10:47:45 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <972638918.1677.1531842460834.JavaMail.mhammett@ThunderFuck> We already supply far, far greater than the actual consumer usage (versus want or demand). Consumers are moving away from wired connections in the home for wireless connections (for obvious mobility and ease of setup where there isn't existing wired infrastructure). Consumers are moving away from power desktops and laptops to phones, tablets, and purpose-built appliances. My in-laws have a Comcast service that's >100 megabit/s. The 2.4 and 5 GHz noise floors are so high (-50 to -75 dB, depending on channel and location within the house) that unless you're in the same room, you're not getting more than 10 megabit/s on wireless. On a wire, Comcast delivers full data rate. Speed tests from wire to wireless mirror the wireless to Internet performance. If it can't be delivered within the home, delivering it to the home is pointless. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Saku Ytti" To: "Mike Hammett" Cc: "Mark Tinka" , nanog at nanog.org Sent: Tuesday, July 17, 2018 10:38:52 AM Subject: Re: Proving Gig Speed On Tue, 17 Jul 2018 at 17:45, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. I admire your confidence, when historically we've had poor success in these type of predictions. I seriously doubt we're now living in special time in history where we find the limit of consumer bandwidth demand, while I have no idea what would drive it or how it would be implemented, I'm betting against myself having all the information about future. -- ++ytti From nanog at ics-il.net Tue Jul 17 15:52:04 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 Jul 2018 10:52:04 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: <9e45b256-560f-3a27-afa3-5e11454b79e3@seacom.mu> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> <779483637.1269.1531838556908.JavaMail.mhammett@ThunderFuck> <9e45b256-560f-3a27-afa3-5e11454b79e3@seacom.mu> Message-ID: <1914077751.1687.1531842718024.JavaMail.mhammett@ThunderFuck> Most ISPs I know build their own last mile. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" To: "Mike Hammett" Cc: "North American Network Operators' Group" Sent: Tuesday, July 17, 2018 10:45:48 AM Subject: Re: Proving Gig Speed On 17/Jul/18 16:42, Mike Hammett wrote: Build your own last mile... Hmmh, don't know why everyone doesn't just do that.
or order that 10% more?
As Trump said, "All I can do is ask the question..." Mark. From mark.tinka at seacom.mu Tue Jul 17 15:58:22 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 17 Jul 2018 17:58:22 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: On 17/Jul/18 17:46, Daniel Ankers wrote: > That's unless 802.11ad/.11ay gain in popularity. 60GHz offers lots of > bandwidth and isn't particularly good at getting through brick walls, which > might offer some relief to the noise floor problem. So if 60GHz can't get through brick walls, how does the home connect to the ISP PoP? Mark. From nanog at ics-il.net Tue Jul 17 16:05:50 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 Jul 2018 11:05:50 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <811338676.1718.1531843547504.JavaMail.mhammett@ThunderFuck> 60 GHz isn't particularly good at getting through a wet dream. I use it outdoors with highly directional antenna (42 dBi of gain) and it's only going to be useful in the home for same-room communication. The only chance it has to be more than that are high-count beam forming antennas to take advantage of very precise reflections. Dozens if not hundreds of elements for that directivity. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Daniel Ankers" To: "Mike Hammett" , "NANOG list" Sent: Tuesday, July 17, 2018 10:46:10 AM Subject: Re: Proving Gig Speed On 17 July 2018 at 15:41, Mike Hammett < nanog at ics-il.net > wrote: 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. That's unless 802.11ad/.11ay gain in popularity. 60GHz offers lots of bandwidth and isn't particularly good at getting through brick walls, which might offer some relief to the noise floor problem. Dan From nanog at ics-il.net Tue Jul 17 16:07:19 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 Jul 2018 11:07:19 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <1252063872.1725.1531843636923.JavaMail.mhammett@ThunderFuck> The problem cited is the last 100', not the last mile. For ISPs using 60 GHz for the last mile, a wire is ran from the outdoor antenna to the indoor router. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" To: "Daniel Ankers" , "Mike Hammett" , "NANOG list" Sent: Tuesday, July 17, 2018 10:58:22 AM Subject: Re: Proving Gig Speed On 17/Jul/18 17:46, Daniel Ankers wrote: That's unless 802.11ad/.11ay gain in popularity. 60GHz offers lots of bandwidth and isn't particularly good at getting through brick walls, which might offer some relief to the noise floor problem. So if 60GHz can't get through brick walls, how does the home connect to the ISP PoP? Mark. From andy at newslink.com Tue Jul 17 16:12:22 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Tue, 17 Jul 2018 11:12:22 -0500 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: > On Jul 17, 2018, at 10:44 AM, Mark Tinka wrote: > > > > On 17/Jul/18 16:41, Mike Hammett wrote: > >> 10G to the home will be pointless as more and more people move away >> from Ethernet to WiFi where the noise floor for most installs prevents >> anyone from reaching 802.11n speeds, much less whatever alphabet soup >> comes later. > > Doesn't stop customers from buying it if it's cheap and available, which > doesn't stop them from proving they are getting 10Gbps as advertised. > > Mark. I suppose in reality it’s no different than any other utility. My home has 200 amp electrical service. Will I ever use 200 amps at one time? Highly highly unlikely. But if my electrical utility wanted to advertise “200 amp service in all homes we supply!” they sure could. Would an electrician be able to test it? I’m sure there is a way somehow. If me and everyone on my street tried to use 200 amps all at the same time, could the infrastructure handle it? Doubtful. But do I on occasion saturate my home fiber 300 mbit synchronous connection? Every now and then yes, but rarely. Although if I’m paying for 300 and not getting it, my ISP will be hearing from me. If my electrical utility told me “hey, you can upgrade to 500 amp service for no additional charge” would I do it? Sure, what the heck. If my water utility said “guess what? You can upgrade to a 2-inch water line at no additional charge!” would I do it? Probably yeah, why not? Would I ever use all that capacity on $random_utility at one time? Of course not. But nice to know it’s there if I ever need it. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From nanog at ics-il.net Tue Jul 17 16:18:05 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 17 Jul 2018 11:18:05 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: <20180717161129.GA54411@ns.sol.net> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <972638918.1677.1531842460834.JavaMail.mhammett@ThunderFuck> <20180717161129.GA54411@ns.sol.net> Message-ID: <947864411.1771.1531844269833.JavaMail.mhammett@ThunderFuck> I don't think you understand the gravity of the in-home interference issue. Unfortunately, neither does the IEEE. It doesn't need to be in lock-step, but if a significant number of homes have issues getting over 100 megabit wirelessly, I'm not sure we need to be concerned about 10 gigabit to the home. I am well aware of the wireless world and Ubiquiti. I've been using Ubiquiti (among other brands) for over 10 years and have been a hardware beta tester for several of them. The 640 kb of RAM statements, computers in home statements, 56 kbps days statements... are all tangential at best. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Joe Greco" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Tuesday, July 17, 2018 11:11:29 AM Subject: Re: Proving Gig Speed On Tue, Jul 17, 2018 at 10:47:45AM -0500, Mike Hammett wrote: > We already supply far, far greater than the actual consumer usage (versus want or demand). > > Consumers are moving away from wired connections in the home for wireless connections (for obvious mobility and ease of setup where there isn't existing wired infrastructure). > > Consumers are moving away from power desktops and laptops to phones, tablets, and purpose-built appliances. > > My in-laws have a Comcast service that's >100 megabit/s. The 2.4 and 5 GHz noise floors are so high (-50 to -75 dB, depending on channel and location within the house) that unless you're in the same room, you're not getting more than 10 megabit/s on wireless. On a wire, Comcast delivers full data rate. Speed tests from wire to wireless mirror the wireless to Internet performance. > > If it can't be delivered within the home, delivering it to the home is pointless. And yet if we had had those attitudes back in the days of 56kbps, ... Your argument is flawed because it implies that this is not an issue that can be addressed. Populating a house with more than a single crap-grade built-into-the-CPE radio is certainly possible, and tech people have been using gear such as Ubiquiti to do so for years now, but more recently mesh systems have become readily available as well and are even sold at Best Buy and other electronics stores. There is no need for ISP speeds to be in exact lock-step with wifi speeds. Advances in one will drive advances in the other. Eventually. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jwbensley at gmail.com Tue Jul 17 17:41:08 2018 From: jwbensley at gmail.com (James Bensley) Date: Tue, 17 Jul 2018 18:41:08 +0100 Subject: Proving Gig Speed In-Reply-To: References: Message-ID: On 17 July 2018 at 09:54, Saku Ytti wrote: > On Tue, 17 Jul 2018 at 10:53, James Bensley wrote: > >> Virtually any modern day laptop with a 1G NIC will saturate a 1G link >> using UDP traffic in iPerf with ease. I crummy i3 netbook with 1G NIC >> can do it on one core/thread. > > I guess if you use large packets this might be true. But personally, > if I'm testing network, I'm interested in latency, jitter, packet, bps > _AND_ pps goals as well, not just bps goal. Hi Saku, Yeah I fully agree with what you are saying however, the OPs question sounds like he "only" needed to prove bandwidth. With 1500 byte frames I've run it up to nearly 10Gbps before (it was between VMs in two different DCs that were having slow transfers and the hyper-visors had 10G NICs, so I dare say, on bare metal with large frames it will do 10Gbps). > And I've never seen clean > 1Gbps on iperf with small packets. It just cannot be done, even if > iPerf was written half decently and it used recvmmsg, it still > wouldn't be anywhere near. > Clean 1Gbps with small packets in user space is actually very much > doable today, just you can't use UDP socket, you must use AF_PACKET on > Linux or BPF on OSX and you can write portable 1Gbps UDP > sender/receiver. > I'm very surprised we don't have iperf like program for netengs which > does this and reports latency, jitter, packet loss with binary search > for highest lossless pps/bps rates. I absolutely agree there is a gap in the open source market for this exact application. A tool that sends traffic between Tx and Rx (or bidirectionally) at a specified frame size and frame rate, which can max out 10Gbps at 64 byte frames if required (I say 10Gbps instead of 1Gbps because 10Gbps as an access circuit speed is being increasingly common), and throughout the test it should report RTT and one way latency, jitter and packet loss etc. and then output the results in a format that is easy to parse. It should also have a JSON API and be able to run in a "daemon" mode like an iPerf server that is always on ready for people to test to/from. > I started to write one with Anton Aksola in Rust (using libpnet[0]), > and implemented quite flexible protocol (server/client, client can ask > server exactly what kind of packet to construct/expect, what rate to > send/receive over JSON based protocol), so you could also use it to > ask it to DDoS your routers control-plane in lab etc. And actually got > it working, OSX+Linux ~wirarate (still needs higher end laptop to do > 1.5Mpps on single core and we didn't implement multicore support). But > as both of us are trash in Rust (and every other applicable language > in this domain), we kind of dropped the project once we had sufficient > POC running on our laptops. > Someone who actually can code, could easily implement such program in > a weekend. I'm happy to share the trash we've done if someone intends > to check this box in open source world. May use it for inspiration, or > just straight up add polish and enough CLI to make it usable as-is. I went through a similar process. AF_PACKET is definitely what you need to use if you want to use user-space in Linux (don't know about MAC, only use Linux). I wrote a basic multi-threaded load generator and load sinker (Tx and Rx) in C using various Kernel methods (send(), sendmsg(), sendmmsg(), and PACKET_MMAP) with AF_PACKET to compare them all: https://github.com/jwbensley/EtherateMT The problem is that C is a great language to write high performance stuff, it's a shit language to create a JSON API in. I have two back to back lab servers at work with 10G links between them, low end 2.1Ghz Xeons, I get 1Mpps per core, 8 cores-1 for OS means I max out at 7Mpps :( I know that XDP is coming to Linux user space so we'll see where that goes, as it promises the magic performance levels we want. Also TPACKETv4 is coming for AF_PACKET in Linux which should also get us to that magic level of performance in user land (it is effectively Kernel bypass). I'll add this to EtherateMT when I get some time to check it's performance: https://lwn.net/Articles/737947/ So EtherateMT works OK as a proof of concept, but nothing more. It requires 100% CPU utilisation to send/receive at such high pps rates, there is no CPU time for stats collection or fancy rtt/latency/jitter etc. That can only be done (right now) with something like DPDK, because it we only need one or two cores for Tx/Rx and then we have free cores for stats collections/generations etc. I looked into MoonGen, it creates Lua bindings for DPDK which means you can rapidly develop DPDK based tools without knowing much about DPDK. It had some RFC2544 Lua scripts for DPDK and I started to re-write them as they were old and didn't work with the latest version of MoonGen: https://github.com/jwbensley/MoonGen-Scripts The throughput script works OK-ish (10Gbps on one core no problems): https://github.com/jwbensley/MoonGen-Scripts/blob/master/throughput.lua Luea would allow one to easily provide parseable output and more easily implement a JSON API however, since MoonGen uses DPDK, we can only use the NICs that DPDK supports and not "any Ethernet NIC supported by Linux", which is what I really want by using AF_PACKET + TPACKETv4. > I think very important quality is multiplatform with static binaries. > Because important use case is, that you can ask modestly informed > customer to copy paste one line to donwload server and copy paste > another line to have it running. > If use case is that both ends have arbitrary clued people, then there > are plenty of good solutions, like Cisco's trex[1]. But what I need is > iPerf-like program, which actually a) performs and b) reports the > correct things. Yeah agreed so DPDK is out the window for me for this specific requirement, it's Linux only (ignoring the minor level of BSD support) and NIC specific too. Python *yuk* is multi-OS, it has JSON libraries, and it has some support for AF_PACKET: https://stackoverflow.com/questions/1117958/how-do-i-use-raw-socket-in-python#6374862 I don't know enough about it, but it might be that TPACKETv4 could be leveraged through Python but that still only covers Linux as Windows and MAC have very different network stacks (but then again I do only care about link sooooo...). I'm keen to have another go at this problem now that I've got a better understanding of it having written EtherateMT and played with DPDK etc. Not sure where to go though - so just waiting on TPACKETv4 right now. Cheers, James. From bzs at theworld.com Tue Jul 17 17:44:07 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 17 Jul 2018 13:44:07 -0400 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <23374.10983.746411.287658@gargle.gargle.HOWL> Re: 10gb TTH Just a thought: Do they need 10gb? Or do they need multiple 1gb (e.g.) channels which might be cheaper and easier to provision? -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From jwbensley at gmail.com Tue Jul 17 17:45:58 2018 From: jwbensley at gmail.com (James Bensley) Date: Tue, 17 Jul 2018 18:45:58 +0100 Subject: Proving Gig Speed In-Reply-To: <0cb0b0c9-ff4a-99a3-2d88-da7077baa0bd@seacom.mu> References: <0cb0b0c9-ff4a-99a3-2d88-da7077baa0bd@seacom.mu> Message-ID: On 17 July 2018 at 12:50, Mark Tinka wrote: > But to answer your questions - for some customers, we insist on JDSU > testing for large capacities, but only if it's worth the effort. > > Mark. Hi Mark, Our field engineers have 1G testers, but even at 1G they are costly (in 2018!), so none have 10Gbps or higher testers and we also only do this for those that demand it (i.e. no 20Mbps EFM customer ever asks for a JSDU/EXO test, because iPerf can easily max out such a link, only those that pay for say 1G over 1G get it). Hardware testers are the best in my opinion right now but it annoys me that this is the current state of affairs, in 2018, even for 1Gbps! Cheers, James. From mike at mtcc.com Tue Jul 17 17:53:52 2018 From: mike at mtcc.com (Michael Thomas) Date: Tue, 17 Jul 2018 10:53:52 -0700 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <0b66851c-e7a9-2b59-b937-5ce91dbc3ecc@mtcc.com> SoIP surely will sure require trigabits. Mike On 7/17/18 8:38 AM, Saku Ytti wrote: > On Tue, 17 Jul 2018 at 17:45, Mike Hammett wrote: > >> 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. > I admire your confidence, when historically we've had poor success in > these type of predictions. I seriously doubt we're now living in > special time in history where we find the limit of consumer bandwidth > demand, while I have no idea what would drive it or how it would be > implemented, I'm betting against myself having all the information > about future. > From job at ntt.net Tue Jul 17 17:55:36 2018 From: job at ntt.net (Job Snijders) Date: Tue, 17 Jul 2018 17:55:36 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> <20180716152603.GE42041@vurt.meerval.net> Message-ID: <20180717175536.GS42041@vurt.meerval.net> On Tue, Jul 17, 2018 at 01:27:09PM +0200, Mark Tinka wrote: > > Markus Weber from KPN is generating a daily report here and drew > > similar conclusions: https://as286.net/data/ana-invalids.txt Markus > > scrapes all routes from the AS 286 PEs and marks the routes for > > which no valid or unknown alternative exists as "altpfx=NONE". > > Thanks. Protein. > > So the numbers are not that far off from when I last checked this back > in 2016, i.e., less than 1% of the total IPv4 routing table. > > Do you have numbers for IPv6, out of interest? There are ~ 330 IPv6 invalids in the DFZ, and for 70 of those no alternative covering prefix exists. Kind regards, Job From valdis.kletnieks at vt.edu Tue Jul 17 18:00:47 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 17 Jul 2018 14:00:47 -0400 Subject: Proving Gig Speed In-Reply-To: <23374.10983.746411.287658@gargle.gargle.HOWL> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <23374.10983.746411.287658@gargle.gargle.HOWL> Message-ID: <156732.1531850447@turing-police.cc.vt.edu> On Tue, 17 Jul 2018 13:44:07 -0400, bzs at theworld.com said: > Do they need 10gb? Or do they need multiple 1gb (e.g.) channels which > might be cheaper and easier to provision? Doesn't DOCSIS channel bonding already do that? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From jwbensley at gmail.com Tue Jul 17 18:00:58 2018 From: jwbensley at gmail.com (James Bensley) Date: Tue, 17 Jul 2018 19:00:58 +0100 Subject: Proving Gig Speed In-Reply-To: <947864411.1771.1531844269833.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <972638918.1677.1531842460834.JavaMail.mhammett@ThunderFuck> <20180717161129.GA54411@ns.sol.net> <947864411.1771.1531844269833.JavaMail.mhammett@ThunderFuck> Message-ID: On 17 July 2018 at 17:18, Mike Hammett wrote: > I don't think you understand the gravity of the in-home interference issue. Unfortunately, neither does the IEEE. > > It doesn't need to be in lock-step, but if a significant number of homes have issues getting over 100 megabit wirelessly, I'm not sure we need to be concerned about 10 gigabit to the home. Maybe leaky feeder cables will become the norm, running along the walls/ceilings of all new build homes? But assuming a wired connection within the premises for a moment, and that we get 1Gbps over that wired connection, because we all have FTTH: For the question of "does it make any difference (1Gbps/10Gbps instead of 100Mbps)": If I download a 4K movie to watch it should take an order of magnitude less time at 1Gbps than 100Mbps. Or even when streaming, my player will fetch a video chunk/segment that is typically in the 3-10 seconds range, I would fetch each chunk much quicker, and so my ISPs connection spends more time idle, which means their backbone carries a higher volume of traffic for a smaller period of time. There is some benefit to be had in the balance of a user consuming X Mbps across the backbone for Y seconds or X^2 Mbps but for Y/10 seconds. It expect it would affect oversubscription and content ratios. Cheers, James. From jwbensley at gmail.com Tue Jul 17 18:03:16 2018 From: jwbensley at gmail.com (James Bensley) Date: Tue, 17 Jul 2018 19:03:16 +0100 Subject: Proving Gig Speed In-Reply-To: <350999753.1260.1531838190249.JavaMail.mhammett@ThunderFuck> References: <350999753.1260.1531838190249.JavaMail.mhammett@ThunderFuck> Message-ID: > From: "James Bensley" > Also I recommend you test to a server on you network near to your > peering & transit edge. This way users can test up to the point where > you would have over the "The Internet" and have no further control. > Testing to a server off-net (like off-net Ookla tells me nothing in my > opinion). ... On 17 July 2018 at 15:36, Mike Hammett wrote: > It tells you how good your peering is. ;-) Or transit :) Cheers, James. From ggm at algebras.org Tue Jul 17 18:11:37 2018 From: ggm at algebras.org (George Michaelson) Date: Tue, 17 Jul 2018 14:11:37 -0400 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180717175536.GS42041@vurt.meerval.net> References: <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> <20180716152603.GE42041@vurt.meerval.net> <20180717175536.GS42041@vurt.meerval.net> Message-ID: I don't want to over-state it, but 'number of prefices' slways feels to me like a potential mis-measure. Not that you don't want to know it, but % of announced space for a given origin-as feels like it might be closer to the story, because there can be so many different ways to announce it as dis- and super aggregates. -G On Tue, Jul 17, 2018 at 1:55 PM, Job Snijders wrote: > On Tue, Jul 17, 2018 at 01:27:09PM +0200, Mark Tinka wrote: >> > Markus Weber from KPN is generating a daily report here and drew >> > similar conclusions: https://as286.net/data/ana-invalids.txt Markus >> > scrapes all routes from the AS 286 PEs and marks the routes for >> > which no valid or unknown alternative exists as "altpfx=NONE". >> >> Thanks. Protein. >> >> So the numbers are not that far off from when I last checked this back >> in 2016, i.e., less than 1% of the total IPv4 routing table. >> >> Do you have numbers for IPv6, out of interest? > > There are ~ 330 IPv6 invalids in the DFZ, and for 70 of those no > alternative covering prefix exists. > > Kind regards, > > Job From michel.py at tsisemi.com Tue Jul 17 18:33:59 2018 From: michel.py at tsisemi.com (Michel Py) Date: Tue, 17 Jul 2018 18:33:59 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180716152603.GE42041@vurt.meerval.net> References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> <20180716152603.GE42041@vurt.meerval.net> Message-ID: > Job Snijders wrote : >I calculated this here few days ago > http://instituut.net/~job/rpki-report-2018.07.12.txt > Markus Weber from KPN is generating a daily report here and drew similar > conclusions: https://as286.net/data/ana-invalids.txt Markus scrapes all > routes from the AS 286 PEs and marks the routes for which no valid or > unknown alternative exists as "altpfx=NONE". If I understand this correctly, I have a suggestion : update these files at a regular interval (15/20 min) and make them available for download with a fixed name (not containing the date). Even better : have a route server that announces these prefixes with a :666 community so people could use it as a blackhole. This would not remove the invalid prefixes from one's router, but at leat would prevent traffic from/to these prefixes. In other words : a route server of prefixes that are RPKI invalid with no alternative that people could use without having an RPKI setup. This would even work with people who have chosen do accept a default route from their upstream. I understand this is not ideal; blacklisting a prefix that is RPKI invalid may actually help the hijacker, but blacklisting a prefix that is RPKI invalid AND that has no alternative could be useful ? Should be considered a bogon. Regards, 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 aveline at misaka.io Tue Jul 17 14:19:04 2018 From: aveline at misaka.io (Siyuan Miao) Date: Tue, 17 Jul 2018 22:19:04 +0800 Subject: Looking for Facebook NOC Message-ID: Hi, Our network in Asia Pacific region was always allocated to Ashburn / Lonodn CDN. I'll be very grateful if there's someone from Facebook NOC could give us a hand to troubleshoot this off list. Best Regards, Siyuan Miao From surfer at mauigateway.com Tue Jul 17 20:12:06 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 17 Jul 2018 13:12:06 -0700 Subject: Proving Gig Speed Message-ID: <20180717131206.8AB485DE@m0117460.ppops.net> --- mark.tinka at seacom.mu wrote: From: Mark Tinka As Trump said..." ---------------------------------------------- That should be added to Godwin's Law! >:-/ https://en.wikipedia.org/wiki/Godwin's_law scott From alan.buxey at gmail.com Tue Jul 17 21:47:06 2018 From: alan.buxey at gmail.com (Alan Buxey) Date: Tue, 17 Jul 2018 22:47:06 +0100 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: hi, another prediction would be that your internet connection (and most devices in house) connected by 5G - maybe with some local WiFi - 802.11ax - if theres still spectrum left after the LTE groups have taken it all for aforementioned 5G purposes... legacy devices, still around for another decade or more can have some 2.4GHz connectivity - that ISM band is troublesome to repurpose thanks to all the medical and video senders etc. big old wild west there... alan From saku at ytti.fi Tue Jul 17 22:01:22 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 18 Jul 2018 01:01:22 +0300 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, 18 Jul 2018 at 00:47, Alan Buxey wrote: > another prediction would be that your internet connection (and most devices in house) connected by 5G - maybe with some local > WiFi - 802.11ax - if theres still spectrum left after the LTE groups have taken it all for aforementioned 5G purposes... Already fairly common in Finland to have just LTE dongle for Internet, especially for younger people. DNA quotes average consumption of 8GB per subscriber per month. You can get unlimited for 20eur/month, it's much faster than DSL with lower latency. And if your home DSL is down, it may affect just you, so MTTR can be days, where as on mobile MTTR even without calling anyone is minutes or hour. Even more strange, providers, particularly one of them, is printing money. It's not immediately obvious to me why this the same fundamentals do not seem to work elsewhere. In Cyprus I can't buy more than 6GB contract and connectivity is spotty even in urban centres, which echoes my experience in US and central EU. -- ++ytti From michael at wi-fiber.io Wed Jul 18 02:39:03 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 17 Jul 2018 20:39:03 -0600 Subject: Blizzard, Battle.net connectivity issues Message-ID: Could I get an off list reply from blizzard engineers. Your email system is blocking our emails as spam, and I'm trying to resolve some geolocation issues that disallow our mutual customers to access your services. Thank you Michael Crapse Wi-Fiber, Inc. From andy at newslink.com Wed Jul 18 04:24:51 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Tue, 17 Jul 2018 23:24:51 -0500 Subject: NANOG list errors Message-ID: <0CC37D49-CAFD-4E61-A7AF-8D76E6622DFF@newslink.com> Fellow list members, The last several days, I’ve been receiving mail forwarding loop errors for the list. I’ll receive them several hours after sending a message. I’ll paste the latest two of them below, separated by % symbols. Anyone able to sort this out and fix? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This is the mail system at host mail.nanog.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : mail forwarding loop for nanog at nanog.org Reporting-MTA: dns; mail.nanog.org X-Postfix-Queue-ID: 2B72F160040 X-Postfix-Sender: rfc822; andy at newslink.com Arrival-Date: Wed, 18 Jul 2018 03:41:57 +0000 (UTC) Final-Recipient: rfc822; nanog at nanog.org Original-Recipient: rfc822;nanog at nanog.org Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail forwarding loop for nanog at nanog.org From: Andy Ringsmuth Subject: Re: Proving Gig Speed Date: July 17, 2018 at 9:53:01 AM CDT To: NANOG list > On Jul 17, 2018, at 9:41 AM, Mike Hammett wrote: > > 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com Well, in a few years when we’re all watching 4D 32K Netflix on our 16-foot screens with 5 million DPI, it’ll make all the difference in the world, right? Tongue-in-cheek obviously. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This is the mail system at host mail.nanog.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : mail forwarding loop for nanog at nanog.org Reporting-MTA: dns; mail.nanog.org X-Postfix-Queue-ID: 2F2AA160040 X-Postfix-Sender: rfc822; andy at newslink.com Arrival-Date: Wed, 18 Jul 2018 03:46:02 +0000 (UTC) Final-Recipient: rfc822; nanog at nanog.org Original-Recipient: rfc822;nanog at nanog.org Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail forwarding loop for nanog at nanog.org From: Andy Ringsmuth Subject: Re: Proving Gig Speed Date: July 17, 2018 at 11:12:22 AM CDT To: NANOG list > On Jul 17, 2018, at 10:44 AM, Mark Tinka wrote: > > > > On 17/Jul/18 16:41, Mike Hammett wrote: > >> 10G to the home will be pointless as more and more people move away >> from Ethernet to WiFi where the noise floor for most installs prevents >> anyone from reaching 802.11n speeds, much less whatever alphabet soup >> comes later. > > Doesn't stop customers from buying it if it's cheap and available, which > doesn't stop them from proving they are getting 10Gbps as advertised. > > Mark. I suppose in reality it’s no different than any other utility. My home has 200 amp electrical service. Will I ever use 200 amps at one time? Highly highly unlikely. But if my electrical utility wanted to advertise “200 amp service in all homes we supply!” they sure could. Would an electrician be able to test it? I’m sure there is a way somehow. If me and everyone on my street tried to use 200 amps all at the same time, could the infrastructure handle it? Doubtful. But do I on occasion saturate my home fiber 300 mbit synchronous connection? Every now and then yes, but rarely. Although if I’m paying for 300 and not getting it, my ISP will be hearing from me. If my electrical utility told me “hey, you can upgrade to 500 amp service for no additional charge” would I do it? Sure, what the heck. If my water utility said “guess what? You can upgrade to a 2-inch water line at no additional charge!” would I do it? Probably yeah, why not? Would I ever use all that capacity on $random_utility at one time? Of course not. But nice to know it’s there if I ever need it. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ---- Andy Ringsmuth andy at newslink.com 5609 Harding Dr. Lincoln, NE 68521 (402) 304-0083 cellular From valdis.kletnieks at vt.edu Wed Jul 18 04:39:19 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 18 Jul 2018 00:39:19 -0400 Subject: NANOG list errors In-Reply-To: <0CC37D49-CAFD-4E61-A7AF-8D76E6622DFF@newslink.com> References: <0CC37D49-CAFD-4E61-A7AF-8D76E6622DFF@newslink.com> Message-ID: <45948.1531888759@turing-police.cc.vt.edu> On Tue, 17 Jul 2018 23:24:51 -0500, Andy Ringsmuth said: > Fellow list members, > The last several days, I���ve been receiving mail forwarding loop errors for > the list. I���ll receive them several hours after sending a message. I���ll paste > the latest two of them below, separated by % symbols. > Anyone able to sort this out and fix? Protip: mail forwarding loops almost always require seeing all the Received: headers to correctly diagnose.. I had one of these show up earlier. I'm willing to send to offline to somebody who can act on it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From gustav.ulander at telecomputing.se Wed Jul 18 07:01:39 2018 From: gustav.ulander at telecomputing.se (Gustav Ulander) Date: Wed, 18 Jul 2018 07:01:39 +0000 Subject: SV: Proving Gig Speed In-Reply-To: References: <0cb0b0c9-ff4a-99a3-2d88-da7077baa0bd@seacom.mu> Message-ID: We use Netrounds for this. We make a speedtest site available to the customer for their "click and test" needs which is the first step. If the customer doesn’t achive their allocated speed we will send out a probe (usually some form of Intel NUC or similar machine) that can do more advanced testing automatically also along different times. The customer then gets to send us back the device when the case is solved. Its not without its faults but its been a great tool so far. //Gustav -----Ursprungligt meddelande----- Från: NANOG För James Bensley Skickat: den 17 juli 2018 19:46 Till: Mark Tinka ; North American Network Operators' Group Ämne: Re: Proving Gig Speed On 17 July 2018 at 12:50, Mark Tinka wrote: > But to answer your questions - for some customers, we insist on JDSU > testing for large capacities, but only if it's worth the effort. > > Mark. Hi Mark, Our field engineers have 1G testers, but even at 1G they are costly (in 2018!), so none have 10Gbps or higher testers and we also only do this for those that demand it (i.e. no 20Mbps EFM customer ever asks for a JSDU/EXO test, because iPerf can easily max out such a link, only those that pay for say 1G over 1G get it). Hardware testers are the best in my opinion right now but it annoys me that this is the current state of affairs, in 2018, even for 1Gbps! Cheers, James. From nop at imap.cc Wed Jul 18 08:36:28 2018 From: nop at imap.cc (nop at imap.cc) Date: Wed, 18 Jul 2018 01:36:28 -0700 Subject: Blizzard, Battle.net connectivity issues In-Reply-To: References: Message-ID: <1531902988.2368920.1444576216.3FC20167@webmail.messagingengine.com> Out of curiosity, are you using one of those cheap dirty "misused outside of region" Afrinic blocks? They keep trying (and spamming the crap out of a few forums) to offload them to ISPs temporarily for cheap so that the ISPs will get them cleaned up and marked as residential, then resold/abused afterward for fraud/vpn/bots. On Tue, Jul 17, 2018, at 7:39 PM, Michael Crapse wrote: > Could I get an off list reply from blizzard engineers. Your email system is > blocking our emails as spam, and I'm trying to resolve some geolocation > issues that disallow our mutual customers to access your services. Thank you > > Michael Crapse > Wi-Fiber, Inc. From mark.tinka at seacom.mu Wed Jul 18 11:55:37 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 13:55:37 +0200 Subject: Proving Gig Speed In-Reply-To: <1914077751.1687.1531842718024.JavaMail.mhammett@ThunderFuck> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> <779483637.1269.1531838556908.JavaMail.mhammett@ThunderFuck> <9e45b256-560f-3a27-afa3-5e11454b79e3@seacom.mu> <1914077751.1687.1531842718024.JavaMail.mhammett@ThunderFuck> Message-ID: On 17/Jul/18 17:52, Mike Hammett wrote: > Most ISPs I know build their own last mile. There's a whole world out there... Mark. From mark.tinka at seacom.mu Wed Jul 18 11:57:28 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 13:57:28 +0200 Subject: Proving Gig Speed In-Reply-To: <1252063872.1725.1531843636923.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <1252063872.1725.1531843636923.JavaMail.mhammett@ThunderFuck> Message-ID: <19747b40-62ec-4360-3e43-7b79b6b03662@seacom.mu> On 17/Jul/18 18:07, Mike Hammett wrote: > The problem cited is the last 100', not the last mile. > > For ISPs using 60 GHz for the last mile, a wire is ran from the outdoor antenna to the indoor router. Yeah, the question was rhetorical. I personally don't see ISP's using 60GHz to deliver to the home at scale. But I'll side with Saku and bet against myself for reliably predicting the future. Mark. From kscott.helms at gmail.com Wed Jul 18 12:00:09 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Wed, 18 Jul 2018 08:00:09 -0400 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> Message-ID: That's absolutely a concern Mark, but most of the CPE vendors that support doing this are providing enough juice to keep up with their max forwarding/routing data rates. I don't see 10 Gbps in residential Internet service being normal for quite a long time off even if the port itself is capable of 10Gbps. We have this issue today with commercial customers, but it's generally not as a much of a problem because the commercial CPE get their usage graphed and the commercial CPE have more capabilities for testing. Scott Helms On Tue, Jul 17, 2018 at 8:11 AM Mark Tinka wrote: > > > On 17/Jul/18 14:07, K. Scott Helms wrote: > > > That's absolutely true, but I don't see any real alternatives in some > cases. I've actually built automated testing into some of the CPE we've > deployed and that works pretty well for some models but other devices don't > seem to be able to fill a ~500 mbps link. > > > So what are you going to do when 10Gbps FTTH into the home becomes the > norm? > > Perhaps laptops and servers of the time won't even see this as a rounding > error :-\... > > Mark. > From mark.tinka at seacom.mu Wed Jul 18 12:01:41 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 14:01:41 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: On 17/Jul/18 18:12, Andy Ringsmuth wrote: > I suppose in reality it’s no different than any other utility. My home has 200 amp electrical service. Will I ever use 200 amps at one time? Highly highly unlikely. But if my electrical utility wanted to advertise “200 amp service in all homes we supply!” they sure could. Would an electrician be able to test it? I’m sure there is a way somehow. > > If me and everyone on my street tried to use 200 amps all at the same time, could the infrastructure handle it? Doubtful. But do I on occasion saturate my home fiber 300 mbit synchronous connection? Every now and then yes, but rarely. Although if I’m paying for 300 and not getting it, my ISP will be hearing from me. > > If my electrical utility told me “hey, you can upgrade to 500 amp service for no additional charge” would I do it? Sure, what the heck. If my water utility said “guess what? You can upgrade to a 2-inch water line at no additional charge!” would I do it? Probably yeah, why not? > > Would I ever use all that capacity on $random_utility at one time? Of course not. But nice to know it’s there if I ever need it. The difference, of course, between electricity and the Internet is that there is a lot more information and tools freely available online that Average Jane can arm herself with to run amok with figuring out whether she is getting 300Mbps of her 300Mbps from her ISP. Average Jane could care less about measuring whether she's getting 200 amps of her 200 amps from the power company; likely because there is a lot more structure with how power is produced and delivered, or more to the point, a lot less freely available tools and information with which she can arm herself to run amok with. To her, the power company sucks if the lights go out. In the worst case, if her power starts a fire, she's calling the fire department. Mark. From mark.tinka at seacom.mu Wed Jul 18 12:04:45 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 14:04:45 +0200 Subject: Proving Gig Speed In-Reply-To: <23374.10983.746411.287658@gargle.gargle.HOWL> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <23374.10983.746411.287658@gargle.gargle.HOWL> Message-ID: <892431af-3934-88d7-1324-a8a44eb54009@seacom.mu> On 17/Jul/18 19:44, bzs at theworld.com wrote: > Re: 10gb TTH > > Just a thought: > > Do they need 10gb? Or do they need multiple 1gb (e.g.) channels which > might be cheaper and easier to provision? In my house, for example, I only have a single fibre core coming into my house (single fibre pair for my neighbors who are on Active-E - I'm on GPON). If you're thinking of classic LAG's, not sure how we could do that on one physical link. Mark. From mark.tinka at seacom.mu Wed Jul 18 12:05:32 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 14:05:32 +0200 Subject: Proving Gig Speed In-Reply-To: References: <0cb0b0c9-ff4a-99a3-2d88-da7077baa0bd@seacom.mu> Message-ID: On 17/Jul/18 19:45, James Bensley wrote: > Hi Mark, > > Our field engineers have 1G testers, but even at 1G they are costly > (in 2018!), so none have 10Gbps or higher testers and we also only do > this for those that demand it (i.e. no 20Mbps EFM customer ever asks > for a JSDU/EXO test, because iPerf can easily max out such a link, > only those that pay for say 1G over 1G get it). Hardware testers are > the best in my opinion right now but it annoys me that this is the > current state of affairs, in 2018, even for 1Gbps! Truth. Mark. From mark.tinka at seacom.mu Wed Jul 18 12:06:11 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 14:06:11 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180717175536.GS42041@vurt.meerval.net> References: <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> <20180716152603.GE42041@vurt.meerval.net> <20180717175536.GS42041@vurt.meerval.net> Message-ID: On 17/Jul/18 19:55, Job Snijders wrote: > There are ~ 330 IPv6 invalids in the DFZ, and for 70 of those no > alternative covering prefix exists. Thanks, Job. Mark. From mark.tinka at seacom.mu Wed Jul 18 12:10:56 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 14:10:56 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> <20180716152603.GE42041@vurt.meerval.net> Message-ID: <2d21104f-670d-5c2b-609a-08bb9339e0fc@seacom.mu> On 17/Jul/18 20:33, Michel Py wrote: > If I understand this correctly, I have a suggestion : update these files at a regular interval (15/20 min) and make them available for download with a fixed name (not containing the date). > Even better : have a route server that announces these prefixes with a :666 community so people could use it as a blackhole. > > This would not remove the invalid prefixes from one's router, but at leat would prevent traffic from/to these prefixes. > In other words : a route server of prefixes that are RPKI invalid with no alternative that people could use without having an RPKI setup. > This would even work with people who have chosen do accept a default route from their upstream. > > I understand this is not ideal; blacklisting a prefix that is RPKI invalid may actually help the hijacker, but blacklisting a prefix that is RPKI invalid AND that has no alternative could be useful ? > Should be considered a bogon. Hmmh - I suppose if you want to do this in-house, that is fine. But I would not recommend this at large for the entire BGP community. At any rate, the result is the same, i.e., the route is taken out of the FIB. The difference is you are proposing a mechanism that uses existing infrastructure within almost all ISP's (the BGP Community) in lieu of deploying RPKI. I can't quite imagine the effort needed to implement your suggestion, but I'd rather direct it toward deploying RPKI. At the very least, one just needs reputable RV software, and router code that support RPKI RV. Mark. From nanog at ics-il.net Wed Jul 18 12:11:03 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Jul 2018 07:11:03 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: <19747b40-62ec-4360-3e43-7b79b6b03662@seacom.mu> References: <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <1252063872.1725.1531843636923.JavaMail.mhammett@ThunderFuck> <19747b40-62ec-4360-3e43-7b79b6b03662@seacom.mu> Message-ID: <271058789.2713.1531915862362.JavaMail.mhammett@ThunderFuck> https://www.ignitenet.com/wireless-backhaul/ https://www.siklu.com/product/multihaul-series/ https://mikrotik.com/product/wireless_wire_dish https://mikrotik.com/product/wap_60g_ap ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" To: "Mike Hammett" Cc: "NANOG list" Sent: Wednesday, July 18, 2018 6:57:28 AM Subject: Re: Proving Gig Speed On 17/Jul/18 18:07, Mike Hammett wrote: The problem cited is the last 100', not the last mile. For ISPs using 60 GHz for the last mile, a wire is ran from the outdoor antenna to the indoor router. Yeah, the question was rhetorical. I personally don't see ISP's using 60GHz to deliver to the home at scale. But I'll side with Saku and bet against myself for reliably predicting the future. Mark. From mark.tinka at seacom.mu Wed Jul 18 12:16:45 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 14:16:45 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <7277f5a5-6497-a67c-7076-04b85a46fbc4@seacom.mu> On 18/Jul/18 00:01, Saku Ytti wrote: > Already fairly common in Finland to have just LTE dongle for Internet, > especially for younger people. DNA quotes average consumption of 8GB > per subscriber per month. You can get unlimited for 20eur/month, it's > much faster than DSL with lower latency. And if your home DSL is down, > it may affect just you, so MTTR can be days, where as on mobile MTTR > even without calling anyone is minutes or hour. > Even more strange, providers, particularly one of them, is printing > money. It's not immediately obvious to me why this the same > fundamentals do not seem to work elsewhere. In Cyprus I can't buy more > than 6GB contract and connectivity is spotty even in urban centres, > which echoes my experience in US and central EU. Fairly common in Africa, where there is plenty of GSM infrastructure, and not so much fibre. Mark. From mark.tinka at seacom.mu Wed Jul 18 12:27:50 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 14:27:50 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> Message-ID: <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> On 18/Jul/18 14:00, K. Scott Helms wrote: > > That's absolutely a concern Mark, but most of the CPE vendors that > support doing this are providing enough juice to keep up with their > max forwarding/routing data rates.  I don't see 10 Gbps in residential > Internet service being normal for quite a long time off even if the > port itself is capable of 10Gbps.  We have this issue today with > commercial customers, but it's generally not as a much of a problem > because the commercial CPE get their usage graphed and the commercial > CPE have more capabilities for testing. I suppose the point I was trying to make is when does it stop being feasible to test each and every piece of bandwidth you deliver to a customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or 3.2Gbps, or 5.1Gbps... basically, the rabbit hole. Like Saku, I am more interested in other fundamental metrics that could impact throughput such as latency, packet loss and jitter. Bandwidth, itself, is easy to measure with your choice of SNMP poller + 5 minutes. But when you're trying to explain to a simple customer buying 100Mbps that a break in your Skype video cannot be diagnosed with a throughput speed test, they don't/won't get it. In Africa, for example, customers in only one of our markets are so obsessed with speed tests. But not to speed test servers that are in-country... they want to test servers that sit in Europe, North America, South America and Asia-Pac. With the latency averaging between 140ms - 400ms across all of those regions from source, the amount of energy spent explaining to customers that there is no way you can saturate your delivered capacity beyond a couple of Mbps using Ookla and friends is energy I could spend drinking wine and having a medium-rare steak, instead. For us, at least, aside from going on a mass education drive in this particular market, the ultimate solution is just getting all that content localized in-country or in-region. Once that latency comes down and the resources are available locally, the whole speed test debacle will easily fall away, because the source of these speed tests is simply how physically far the content is. Is this an easy task - hell no; but slamming your head against a wall over and over is no fun either. Mark. From mark.tinka at seacom.mu Wed Jul 18 12:29:31 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 14:29:31 +0200 Subject: Proving Gig Speed In-Reply-To: <271058789.2713.1531915862362.JavaMail.mhammett@ThunderFuck> References: <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <1252063872.1725.1531843636923.JavaMail.mhammett@ThunderFuck> <19747b40-62ec-4360-3e43-7b79b6b03662@seacom.mu> <271058789.2713.1531915862362.JavaMail.mhammett@ThunderFuck> Message-ID: <18426941-5ed5-b7d2-853f-7cb454bda88e@seacom.mu> On 18/Jul/18 14:11, Mike Hammett wrote: > https://www.ignitenet.com/wireless-backhaul/ > https://www.siklu.com/product/multihaul-series/ > > https://mikrotik.com/product/wireless_wire_dish > https://mikrotik.com/product/wap_60g_ap There is a product for everything; doesn't mean it'll make a commercially viable business for whoever chooses to implement it. Mark. From nanog at ics-il.net Wed Jul 18 12:31:56 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Jul 2018 07:31:56 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: <18426941-5ed5-b7d2-853f-7cb454bda88e@seacom.mu> References: <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <1252063872.1725.1531843636923.JavaMail.mhammett@ThunderFuck> <19747b40-62ec-4360-3e43-7b79b6b03662@seacom.mu> <271058789.2713.1531915862362.JavaMail.mhammett@ThunderFuck> <18426941-5ed5-b7d2-853f-7cb454bda88e@seacom.mu> Message-ID: <241919468.2782.1531917112452.JavaMail.mhammett@ThunderFuck> I encourage my competitors to not implement those products in their networks. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" To: "Mike Hammett" Cc: "NANOG list" Sent: Wednesday, July 18, 2018 7:29:31 AM Subject: Re: Proving Gig Speed On 18/Jul/18 14:11, Mike Hammett wrote: https://www.ignitenet.com/wireless-backhaul/ https://www.siklu.com/product/multihaul-series/ https://mikrotik.com/product/wireless_wire_dish https://mikrotik.com/product/wap_60g_ap There is a product for everything; doesn't mean it'll make a commercially viable business for whoever chooses to implement it. Mark. From kscott.helms at gmail.com Wed Jul 18 12:40:31 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Wed, 18 Jul 2018 08:40:31 -0400 Subject: Proving Gig Speed In-Reply-To: <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> Message-ID: Agreed, and it's one of the fundamental problems that a speed test is (and can only) measure the speeds from point A to point B (often both inside the service provider's network) when the customer is concerned with traffic to and from point C off in someone else's network altogether. It's one of the reasons that I think we have to get more comfortable and more collaborative with the CDN providers as well as the large sources of traffic. Netflix, Youtube, and I'm sure others have their own consumer facing performance testing that is _much_ more applicable to most consumers as compared to the "normal" technician test and measurement approach or even the service assurance that you get from normal performance monitoring. What I'd really like to see is a way to measure network performance from the CO/head end/PoP and also get consumer level reporting from these kinds of services. If Google/Netflix/Amazon Video/$others would get on board with this idea it would make all our lives simpler. Providing individual users stats is nice, but if these guys really want to improve service it would be great to get aggregate reporting by ASN. You can get a rough idea by looking at your overall graph from Google, but it's lacking a lot of detail and there's no simple way to compare that to a head end/CO test versus specific end users. https://www.google.com/get/videoqualityreport/ https://fast.com/# On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka wrote: > > > On 18/Jul/18 14:00, K. Scott Helms wrote: > > > That's absolutely a concern Mark, but most of the CPE vendors that support > doing this are providing enough juice to keep up with their max > forwarding/routing data rates. I don't see 10 Gbps in residential Internet > service being normal for quite a long time off even if the port itself is > capable of 10Gbps. We have this issue today with commercial customers, but > it's generally not as a much of a problem because the commercial CPE get > their usage graphed and the commercial CPE have more capabilities for > testing. > > > I suppose the point I was trying to make is when does it stop being > feasible to test each and every piece of bandwidth you deliver to a > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or 3.2Gbps, > or 5.1Gbps... basically, the rabbit hole. > > Like Saku, I am more interested in other fundamental metrics that could > impact throughput such as latency, packet loss and jitter. Bandwidth, > itself, is easy to measure with your choice of SNMP poller + 5 minutes. But > when you're trying to explain to a simple customer buying 100Mbps that a > break in your Skype video cannot be diagnosed with a throughput speed test, > they don't/won't get it. > > In Africa, for example, customers in only one of our markets are so > obsessed with speed tests. But not to speed test servers that are > in-country... they want to test servers that sit in Europe, North America, > South America and Asia-Pac. With the latency averaging between 140ms - > 400ms across all of those regions from source, the amount of energy spent > explaining to customers that there is no way you can saturate your > delivered capacity beyond a couple of Mbps using Ookla and friends is > energy I could spend drinking wine and having a medium-rare steak, instead. > > For us, at least, aside from going on a mass education drive in this > particular market, the ultimate solution is just getting all that content > localized in-country or in-region. Once that latency comes down and the > resources are available locally, the whole speed test debacle will easily > fall away, because the source of these speed tests is simply how physically > far the content is. Is this an easy task - hell no; but slamming your head > against a wall over and over is no fun either. > > Mark. > From mark.tinka at seacom.mu Wed Jul 18 13:01:06 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 15:01:06 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> Message-ID: <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> On 18/Jul/18 14:40, K. Scott Helms wrote: > Agreed, and it's one of the fundamental problems that a speed test is > (and can only) measure the speeds from point A to point B (often both > inside the service provider's network) when the customer is concerned > with traffic to and from point C off in someone else's network altogether. In our market, most customers that put all their faith and slippers in Ookla have no qualms with choosing a random speed test server on the Ookla network, with no regard as to whether that server is on-net or off-net for their ISP, how that server is maintained, how much bandwidth capacity it has, how it was deployed, its hardware sources, how busy it is, how much of its bandwidth it can actually exhaust, how traffic routes to/from it, e.t.c. Whatever the result, the speed test server or the Ookla network is NEVER at fault. So now, an ISP in the African market has to explain why a speed test server on some unknown network in Feira de Santana is claiming that the customer is not getting what they paid for? Then again, we all need reasons to wake up in the morning :-)... >   It's one of the reasons that I think we have to get more comfortable > and more collaborative with the CDN providers as well as the large > sources of traffic.  Netflix, Youtube, and I'm sure others have their > own consumer facing performance testing that is _much_ more applicable > to most consumers as compared to the "normal" technician test and > measurement approach or even the service assurance that you get from > normal performance monitoring.  What I'd really like to see is a way > to measure network performance from the CO/head end/PoP and also get > consumer level reporting from these kinds of services.  If > Google/Netflix/Amazon Video/$others would get on board with this idea > it would make all our lives simpler. > > Providing individual users stats is nice, but if these guys really > want to improve service it would be great to get aggregate reporting > by ASN.  You can get a rough idea by looking at your overall graph > from Google, but it's lacking a lot of detail and there's no simple > way to compare that to a head end/CO test versus specific end users. > > https://www.google.com/get/videoqualityreport/ > https://fast.com/# Personally, I don't think the content networks and CDN's should focus on developing yet-another-speed-test-server, because then they are just pushing the problem back to the ISP. I believe they should better spend their time: * Delivering as-near-to 100% of all of their services to all regions, cities, data centres as they possibly can. * Providing tools for network operators as well as their consumers that are biased toward the expected quality of experience, rather than how fast their bandwidth is. A 5Gbps link full of packet loss does not a service make - but what does that translate into for the type of service the content network or CDN is delivering? Mark. From nanog at ics-il.net Wed Jul 18 13:02:42 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Jul 2018 08:02:42 -0500 (CDT) Subject: NANOG list errors In-Reply-To: <0CC37D49-CAFD-4E61-A7AF-8D76E6622DFF@newslink.com> References: <0CC37D49-CAFD-4E61-A7AF-8D76E6622DFF@newslink.com> Message-ID: <210160164.2893.1531918961035.JavaMail.mhammett@ThunderFuck> I got a whole bunch overnight as well. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Andy Ringsmuth" To: "NANOG list" Sent: Tuesday, July 17, 2018 11:24:51 PM Subject: NANOG list errors Fellow list members, The last several days, I’ve been receiving mail forwarding loop errors for the list. I’ll receive them several hours after sending a message. I’ll paste the latest two of them below, separated by % symbols. Anyone able to sort this out and fix? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This is the mail system at host mail.nanog.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : mail forwarding loop for nanog at nanog.org Reporting-MTA: dns; mail.nanog.org X-Postfix-Queue-ID: 2B72F160040 X-Postfix-Sender: rfc822; andy at newslink.com Arrival-Date: Wed, 18 Jul 2018 03:41:57 +0000 (UTC) Final-Recipient: rfc822; nanog at nanog.org Original-Recipient: rfc822;nanog at nanog.org Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail forwarding loop for nanog at nanog.org From: Andy Ringsmuth Subject: Re: Proving Gig Speed Date: July 17, 2018 at 9:53:01 AM CDT To: NANOG list > On Jul 17, 2018, at 9:41 AM, Mike Hammett wrote: > > 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com Well, in a few years when we’re all watching 4D 32K Netflix on our 16-foot screens with 5 million DPI, it’ll make all the difference in the world, right? Tongue-in-cheek obviously. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This is the mail system at host mail.nanog.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : mail forwarding loop for nanog at nanog.org Reporting-MTA: dns; mail.nanog.org X-Postfix-Queue-ID: 2F2AA160040 X-Postfix-Sender: rfc822; andy at newslink.com Arrival-Date: Wed, 18 Jul 2018 03:46:02 +0000 (UTC) Final-Recipient: rfc822; nanog at nanog.org Original-Recipient: rfc822;nanog at nanog.org Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail forwarding loop for nanog at nanog.org From: Andy Ringsmuth Subject: Re: Proving Gig Speed Date: July 17, 2018 at 11:12:22 AM CDT To: NANOG list > On Jul 17, 2018, at 10:44 AM, Mark Tinka wrote: > > > > On 17/Jul/18 16:41, Mike Hammett wrote: > >> 10G to the home will be pointless as more and more people move away >> from Ethernet to WiFi where the noise floor for most installs prevents >> anyone from reaching 802.11n speeds, much less whatever alphabet soup >> comes later. > > Doesn't stop customers from buying it if it's cheap and available, which > doesn't stop them from proving they are getting 10Gbps as advertised. > > Mark. I suppose in reality it’s no different than any other utility. My home has 200 amp electrical service. Will I ever use 200 amps at one time? Highly highly unlikely. But if my electrical utility wanted to advertise “200 amp service in all homes we supply!” they sure could. Would an electrician be able to test it? I’m sure there is a way somehow. If me and everyone on my street tried to use 200 amps all at the same time, could the infrastructure handle it? Doubtful. But do I on occasion saturate my home fiber 300 mbit synchronous connection? Every now and then yes, but rarely. Although if I’m paying for 300 and not getting it, my ISP will be hearing from me. If my electrical utility told me “hey, you can upgrade to 500 amp service for no additional charge” would I do it? Sure, what the heck. If my water utility said “guess what? You can upgrade to a 2-inch water line at no additional charge!” would I do it? Probably yeah, why not? Would I ever use all that capacity on $random_utility at one time? Of course not. But nice to know it’s there if I ever need it. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ---- Andy Ringsmuth andy at newslink.com 5609 Harding Dr. Lincoln, NE 68521 (402) 304-0083 cellular From nanog at ics-il.net Wed Jul 18 13:24:15 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Jul 2018 08:24:15 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> Message-ID: <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> Check your Google portal for more information as to what Google can do with BGP Communities related to reporting. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "K. Scott Helms" To: "mark tinka" Cc: "NANOG list" Sent: Wednesday, July 18, 2018 7:40:31 AM Subject: Re: Proving Gig Speed Agreed, and it's one of the fundamental problems that a speed test is (and can only) measure the speeds from point A to point B (often both inside the service provider's network) when the customer is concerned with traffic to and from point C off in someone else's network altogether. It's one of the reasons that I think we have to get more comfortable and more collaborative with the CDN providers as well as the large sources of traffic. Netflix, Youtube, and I'm sure others have their own consumer facing performance testing that is _much_ more applicable to most consumers as compared to the "normal" technician test and measurement approach or even the service assurance that you get from normal performance monitoring. What I'd really like to see is a way to measure network performance from the CO/head end/PoP and also get consumer level reporting from these kinds of services. If Google/Netflix/Amazon Video/$others would get on board with this idea it would make all our lives simpler. Providing individual users stats is nice, but if these guys really want to improve service it would be great to get aggregate reporting by ASN. You can get a rough idea by looking at your overall graph from Google, but it's lacking a lot of detail and there's no simple way to compare that to a head end/CO test versus specific end users. https://www.google.com/get/videoqualityreport/ https://fast.com/# On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka wrote: > > > On 18/Jul/18 14:00, K. Scott Helms wrote: > > > That's absolutely a concern Mark, but most of the CPE vendors that support > doing this are providing enough juice to keep up with their max > forwarding/routing data rates. I don't see 10 Gbps in residential Internet > service being normal for quite a long time off even if the port itself is > capable of 10Gbps. We have this issue today with commercial customers, but > it's generally not as a much of a problem because the commercial CPE get > their usage graphed and the commercial CPE have more capabilities for > testing. > > > I suppose the point I was trying to make is when does it stop being > feasible to test each and every piece of bandwidth you deliver to a > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or 3.2Gbps, > or 5.1Gbps... basically, the rabbit hole. > > Like Saku, I am more interested in other fundamental metrics that could > impact throughput such as latency, packet loss and jitter. Bandwidth, > itself, is easy to measure with your choice of SNMP poller + 5 minutes. But > when you're trying to explain to a simple customer buying 100Mbps that a > break in your Skype video cannot be diagnosed with a throughput speed test, > they don't/won't get it. > > In Africa, for example, customers in only one of our markets are so > obsessed with speed tests. But not to speed test servers that are > in-country... they want to test servers that sit in Europe, North America, > South America and Asia-Pac. With the latency averaging between 140ms - > 400ms across all of those regions from source, the amount of energy spent > explaining to customers that there is no way you can saturate your > delivered capacity beyond a couple of Mbps using Ookla and friends is > energy I could spend drinking wine and having a medium-rare steak, instead. > > For us, at least, aside from going on a mass education drive in this > particular market, the ultimate solution is just getting all that content > localized in-country or in-region. Once that latency comes down and the > resources are available locally, the whole speed test debacle will easily > fall away, because the source of these speed tests is simply how physically > far the content is. Is this an easy task - hell no; but slamming your head > against a wall over and over is no fun either. > > Mark. > From nanog at ics-il.net Wed Jul 18 13:24:55 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Jul 2018 08:24:55 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> Message-ID: <813172596.2940.1531920293630.JavaMail.mhammett@ThunderFuck> More speedtest and quality reporting sites\services (including internal to big content) seem more about blaming the ISP than providing the ISP usable information to fix it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "K. Scott Helms" To: "mark tinka" Cc: "NANOG list" Sent: Wednesday, July 18, 2018 7:40:31 AM Subject: Re: Proving Gig Speed Agreed, and it's one of the fundamental problems that a speed test is (and can only) measure the speeds from point A to point B (often both inside the service provider's network) when the customer is concerned with traffic to and from point C off in someone else's network altogether. It's one of the reasons that I think we have to get more comfortable and more collaborative with the CDN providers as well as the large sources of traffic. Netflix, Youtube, and I'm sure others have their own consumer facing performance testing that is _much_ more applicable to most consumers as compared to the "normal" technician test and measurement approach or even the service assurance that you get from normal performance monitoring. What I'd really like to see is a way to measure network performance from the CO/head end/PoP and also get consumer level reporting from these kinds of services. If Google/Netflix/Amazon Video/$others would get on board with this idea it would make all our lives simpler. Providing individual users stats is nice, but if these guys really want to improve service it would be great to get aggregate reporting by ASN. You can get a rough idea by looking at your overall graph from Google, but it's lacking a lot of detail and there's no simple way to compare that to a head end/CO test versus specific end users. https://www.google.com/get/videoqualityreport/ https://fast.com/# On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka wrote: > > > On 18/Jul/18 14:00, K. Scott Helms wrote: > > > That's absolutely a concern Mark, but most of the CPE vendors that support > doing this are providing enough juice to keep up with their max > forwarding/routing data rates. I don't see 10 Gbps in residential Internet > service being normal for quite a long time off even if the port itself is > capable of 10Gbps. We have this issue today with commercial customers, but > it's generally not as a much of a problem because the commercial CPE get > their usage graphed and the commercial CPE have more capabilities for > testing. > > > I suppose the point I was trying to make is when does it stop being > feasible to test each and every piece of bandwidth you deliver to a > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or 3.2Gbps, > or 5.1Gbps... basically, the rabbit hole. > > Like Saku, I am more interested in other fundamental metrics that could > impact throughput such as latency, packet loss and jitter. Bandwidth, > itself, is easy to measure with your choice of SNMP poller + 5 minutes. But > when you're trying to explain to a simple customer buying 100Mbps that a > break in your Skype video cannot be diagnosed with a throughput speed test, > they don't/won't get it. > > In Africa, for example, customers in only one of our markets are so > obsessed with speed tests. But not to speed test servers that are > in-country... they want to test servers that sit in Europe, North America, > South America and Asia-Pac. With the latency averaging between 140ms - > 400ms across all of those regions from source, the amount of energy spent > explaining to customers that there is no way you can saturate your > delivered capacity beyond a couple of Mbps using Ookla and friends is > energy I could spend drinking wine and having a medium-rare steak, instead. > > For us, at least, aside from going on a mass education drive in this > particular market, the ultimate solution is just getting all that content > localized in-country or in-region. Once that latency comes down and the > resources are available locally, the whole speed test debacle will easily > fall away, because the source of these speed tests is simply how physically > far the content is. Is this an easy task - hell no; but slamming your head > against a wall over and over is no fun either. > > Mark. > From mark.tinka at seacom.mu Wed Jul 18 13:36:31 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 15:36:31 +0200 Subject: Proving Gig Speed In-Reply-To: <813172596.2940.1531920293630.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <813172596.2940.1531920293630.JavaMail.mhammett@ThunderFuck> Message-ID: <79d3be01-74a7-5542-68ca-a105621e8ac8@seacom.mu> On 18/Jul/18 15:24, Mike Hammett wrote: > More speedtest and quality reporting sites\services (including internal to big content) seem more about blaming the ISP than providing the ISP usable information to fix it. Agreed. IIRC, this all began with http://www.dslreports.com/speedtest (I can't think of another speed test resource at the time) back in the late '90's... of course, it assumed all ISP's and their eyeballs were in North America. It's been downhill ever since. Mark. From kscott.helms at gmail.com Wed Jul 18 13:41:41 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Wed, 18 Jul 2018 09:41:41 -0400 Subject: Proving Gig Speed In-Reply-To: <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> Message-ID: On Wed, Jul 18, 2018 at 9:01 AM Mark Tinka wrote: > > Personally, I don't think the content networks and CDN's should focus on > developing yet-another-speed-test-server, because then they are just > pushing the problem back to the ISP. I believe they should better spend > their time: > > - Delivering as-near-to 100% of all of their services to all regions, > cities, data centres as they possibly can. > > > - Providing tools for network operators as well as their consumers > that are biased toward the expected quality of experience, rather than how > fast their bandwidth is. A 5Gbps link full of packet loss does not a > service make - but what does that translate into for the type of service > the content network or CDN is delivering? > > Mark. > That's why I vastly prefer stats from the actual CDNs and content providers that aren't generated by speed tests. They're generated by measuring the actual performance of the service they deliver. Now, that won't prevent burden shifting, but it does get rid of a lot of the problems you bring up. Youtube for example wouldn't rate a video stream as good if the packet loss were high because it's actually looking at the bit rate of successfully delivered encapsulated video frames I _think_ the same is true of Netflix though they also offer a real time test as well which frankly isn't as helpful for monitoring but getting a quick test to the Netflix node you'd normally use can be nice in some cases. From kscott.helms at gmail.com Wed Jul 18 13:45:22 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Wed, 18 Jul 2018 09:45:22 -0400 Subject: Proving Gig Speed In-Reply-To: <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, What portal would that be? Do you have a URL? On Wed, Jul 18, 2018 at 9:25 AM Mike Hammett wrote: > Check your Google portal for more information as to what Google can do > with BGP Communities related to reporting. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "K. Scott Helms" > To: "mark tinka" > Cc: "NANOG list" > Sent: Wednesday, July 18, 2018 7:40:31 AM > Subject: Re: Proving Gig Speed > > Agreed, and it's one of the fundamental problems that a speed test is (and > can only) measure the speeds from point A to point B (often both inside > the > service provider's network) when the customer is concerned with traffic to > and from point C off in someone else's network altogether. It's one of the > reasons that I think we have to get more comfortable and more > collaborative > with the CDN providers as well as the large sources of traffic. Netflix, > Youtube, and I'm sure others have their own consumer facing performance > testing that is _much_ more applicable to most consumers as compared to > the > "normal" technician test and measurement approach or even the service > assurance that you get from normal performance monitoring. What I'd really > like to see is a way to measure network performance from the CO/head > end/PoP and also get consumer level reporting from these kinds of > services. If Google/Netflix/Amazon Video/$others would get on board with > this idea it would make all our lives simpler. > > Providing individual users stats is nice, but if these guys really want to > improve service it would be great to get aggregate reporting by ASN. You > can get a rough idea by looking at your overall graph from Google, but > it's > lacking a lot of detail and there's no simple way to compare that to a > head > end/CO test versus specific end users. > > https://www.google.com/get/videoqualityreport/ > https://fast.com/# > > > > On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka wrote: > > > > > > > On 18/Jul/18 14:00, K. Scott Helms wrote: > > > > > > That's absolutely a concern Mark, but most of the CPE vendors that > support > > doing this are providing enough juice to keep up with their max > > forwarding/routing data rates. I don't see 10 Gbps in residential > Internet > > service being normal for quite a long time off even if the port itself > is > > capable of 10Gbps. We have this issue today with commercial customers, > but > > it's generally not as a much of a problem because the commercial CPE get > > their usage graphed and the commercial CPE have more capabilities for > > testing. > > > > > > I suppose the point I was trying to make is when does it stop being > > feasible to test each and every piece of bandwidth you deliver to a > > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or > 3.2Gbps, > > or 5.1Gbps... basically, the rabbit hole. > > > > Like Saku, I am more interested in other fundamental metrics that could > > impact throughput such as latency, packet loss and jitter. Bandwidth, > > itself, is easy to measure with your choice of SNMP poller + 5 minutes. > But > > when you're trying to explain to a simple customer buying 100Mbps that a > > break in your Skype video cannot be diagnosed with a throughput speed > test, > > they don't/won't get it. > > > > In Africa, for example, customers in only one of our markets are so > > obsessed with speed tests. But not to speed test servers that are > > in-country... they want to test servers that sit in Europe, North > America, > > South America and Asia-Pac. With the latency averaging between 140ms - > > 400ms across all of those regions from source, the amount of energy > spent > > explaining to customers that there is no way you can saturate your > > delivered capacity beyond a couple of Mbps using Ookla and friends is > > energy I could spend drinking wine and having a medium-rare steak, > instead. > > > > For us, at least, aside from going on a mass education drive in this > > particular market, the ultimate solution is just getting all that > content > > localized in-country or in-region. Once that latency comes down and the > > resources are available locally, the whole speed test debacle will > easily > > fall away, because the source of these speed tests is simply how > physically > > far the content is. Is this an easy task - hell no; but slamming your > head > > against a wall over and over is no fun either. > > > > Mark. > > > > From nanog at ics-il.net Wed Jul 18 13:45:07 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Jul 2018 08:45:07 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> Message-ID: <871529190.3073.1531921504776.JavaMail.mhammett@ThunderFuck> Fast.com will pull from multiple nodes at the same time. I think there were four streams on the one I looked at, two to the on-net OCA and two that went off-net elsewhere. One of those off-net was in the same country, but very not near. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "K. Scott Helms" To: "mark tinka" Cc: "NANOG list" Sent: Wednesday, July 18, 2018 8:41:41 AM Subject: Re: Proving Gig Speed On Wed, Jul 18, 2018 at 9:01 AM Mark Tinka wrote: > > Personally, I don't think the content networks and CDN's should focus on > developing yet-another-speed-test-server, because then they are just > pushing the problem back to the ISP. I believe they should better spend > their time: > > - Delivering as-near-to 100% of all of their services to all regions, > cities, data centres as they possibly can. > > > - Providing tools for network operators as well as their consumers > that are biased toward the expected quality of experience, rather than how > fast their bandwidth is. A 5Gbps link full of packet loss does not a > service make - but what does that translate into for the type of service > the content network or CDN is delivering? > > Mark. > That's why I vastly prefer stats from the actual CDNs and content providers that aren't generated by speed tests. They're generated by measuring the actual performance of the service they deliver. Now, that won't prevent burden shifting, but it does get rid of a lot of the problems you bring up. Youtube for example wouldn't rate a video stream as good if the packet loss were high because it's actually looking at the bit rate of successfully delivered encapsulated video frames I _think_ the same is true of Netflix though they also offer a real time test as well which frankly isn't as helpful for monitoring but getting a quick test to the Netflix node you'd normally use can be nice in some cases. From nanog at ics-il.net Wed Jul 18 13:46:11 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Jul 2018 08:46:11 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> Message-ID: <1245545974.3079.1531921569392.JavaMail.mhammett@ThunderFuck> https://isp.google.com ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "K. Scott Helms" To: "Mike Hammett" Cc: "NANOG list" Sent: Wednesday, July 18, 2018 8:45:22 AM Subject: Re: Proving Gig Speed Mike, What portal would that be? Do you have a URL? On Wed, Jul 18, 2018 at 9:25 AM Mike Hammett < nanog at ics-il.net > wrote: Check your Google portal for more information as to what Google can do with BGP Communities related to reporting. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "K. Scott Helms" < kscott.helms at gmail.com > To: "mark tinka" < mark.tinka at seacom.mu > Cc: "NANOG list" < nanog at nanog.org > Sent: Wednesday, July 18, 2018 7:40:31 AM Subject: Re: Proving Gig Speed Agreed, and it's one of the fundamental problems that a speed test is (and can only) measure the speeds from point A to point B (often both inside the service provider's network) when the customer is concerned with traffic to and from point C off in someone else's network altogether. It's one of the reasons that I think we have to get more comfortable and more collaborative with the CDN providers as well as the large sources of traffic. Netflix, Youtube, and I'm sure others have their own consumer facing performance testing that is _much_ more applicable to most consumers as compared to the "normal" technician test and measurement approach or even the service assurance that you get from normal performance monitoring. What I'd really like to see is a way to measure network performance from the CO/head end/PoP and also get consumer level reporting from these kinds of services. If Google/Netflix/Amazon Video/$others would get on board with this idea it would make all our lives simpler. Providing individual users stats is nice, but if these guys really want to improve service it would be great to get aggregate reporting by ASN. You can get a rough idea by looking at your overall graph from Google, but it's lacking a lot of detail and there's no simple way to compare that to a head end/CO test versus specific end users. https://www.google.com/get/videoqualityreport/ https://fast.com/# On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka < mark.tinka at seacom.mu > wrote: > > > On 18/Jul/18 14:00, K. Scott Helms wrote: > > > That's absolutely a concern Mark, but most of the CPE vendors that support > doing this are providing enough juice to keep up with their max > forwarding/routing data rates. I don't see 10 Gbps in residential Internet > service being normal for quite a long time off even if the port itself is > capable of 10Gbps. We have this issue today with commercial customers, but > it's generally not as a much of a problem because the commercial CPE get > their usage graphed and the commercial CPE have more capabilities for > testing. > > > I suppose the point I was trying to make is when does it stop being > feasible to test each and every piece of bandwidth you deliver to a > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or 3.2Gbps, > or 5.1Gbps... basically, the rabbit hole. > > Like Saku, I am more interested in other fundamental metrics that could > impact throughput such as latency, packet loss and jitter. Bandwidth, > itself, is easy to measure with your choice of SNMP poller + 5 minutes. But > when you're trying to explain to a simple customer buying 100Mbps that a > break in your Skype video cannot be diagnosed with a throughput speed test, > they don't/won't get it. > > In Africa, for example, customers in only one of our markets are so > obsessed with speed tests. But not to speed test servers that are > in-country... they want to test servers that sit in Europe, North America, > South America and Asia-Pac. With the latency averaging between 140ms - > 400ms across all of those regions from source, the amount of energy spent > explaining to customers that there is no way you can saturate your > delivered capacity beyond a couple of Mbps using Ookla and friends is > energy I could spend drinking wine and having a medium-rare steak, instead. > > For us, at least, aside from going on a mass education drive in this > particular market, the ultimate solution is just getting all that content > localized in-country or in-region. Once that latency comes down and the > resources are available locally, the whole speed test debacle will easily > fall away, because the source of these speed tests is simply how physically > far the content is. Is this an easy task - hell no; but slamming your head > against a wall over and over is no fun either. > > Mark. > From lguillory at reservetele.com Wed Jul 18 13:48:32 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 18 Jul 2018 13:48:32 +0000 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FA54A13@RTC-EXCH01.RESERVE.LDS> https://isp.google.com Thought I think this is only for when you have peering, someone can correct me if that's incorrect. ns -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K. Scott Helms Sent: Wednesday, July 18, 2018 8:45 AM To: Mike Hammett Cc: NANOG list Subject: Re: Proving Gig Speed Mike, What portal would that be? Do you have a URL? On Wed, Jul 18, 2018 at 9:25 AM Mike Hammett wrote: > Check your Google portal for more information as to what Google can do > with BGP Communities related to reporting. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "K. Scott Helms" > To: "mark tinka" > Cc: "NANOG list" > Sent: Wednesday, July 18, 2018 7:40:31 AM > Subject: Re: Proving Gig Speed > > Agreed, and it's one of the fundamental problems that a speed test is > (and can only) measure the speeds from point A to point B (often both > inside the service provider's network) when the customer is concerned > with traffic to and from point C off in someone else's network > altogether. It's one of the reasons that I think we have to get more > comfortable and more collaborative with the CDN providers as well as > the large sources of traffic. Netflix, Youtube, and I'm sure others > have their own consumer facing performance testing that is _much_ more > applicable to most consumers as compared to the "normal" technician > test and measurement approach or even the service assurance that you > get from normal performance monitoring. What I'd really like to see is > a way to measure network performance from the CO/head end/PoP and also > get consumer level reporting from these kinds of services. If > Google/Netflix/Amazon Video/$others would get on board with this idea > it would make all our lives simpler. > > Providing individual users stats is nice, but if these guys really > want to improve service it would be great to get aggregate reporting > by ASN. You can get a rough idea by looking at your overall graph from > Google, but it's lacking a lot of detail and there's no simple way to > compare that to a head end/CO test versus specific end users. > > https://www.google.com/get/videoqualityreport/ > https://fast.com/# > > > > On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka wrote: > > > > > > > On 18/Jul/18 14:00, K. Scott Helms wrote: > > > > > > That's absolutely a concern Mark, but most of the CPE vendors that > support > > doing this are providing enough juice to keep up with their max > > forwarding/routing data rates. I don't see 10 Gbps in residential > Internet > > service being normal for quite a long time off even if the port > > itself > is > > capable of 10Gbps. We have this issue today with commercial > > customers, > but > > it's generally not as a much of a problem because the commercial CPE > > get their usage graphed and the commercial CPE have more > > capabilities for testing. > > > > > > I suppose the point I was trying to make is when does it stop being > > feasible to test each and every piece of bandwidth you deliver to a > > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or > 3.2Gbps, > > or 5.1Gbps... basically, the rabbit hole. > > > > Like Saku, I am more interested in other fundamental metrics that > > could impact throughput such as latency, packet loss and jitter. > > Bandwidth, itself, is easy to measure with your choice of SNMP poller + 5 minutes. > But > > when you're trying to explain to a simple customer buying 100Mbps > > that a break in your Skype video cannot be diagnosed with a > > throughput speed > test, > > they don't/won't get it. > > > > In Africa, for example, customers in only one of our markets are so > > obsessed with speed tests. But not to speed test servers that are > > in-country... they want to test servers that sit in Europe, North > America, > > South America and Asia-Pac. With the latency averaging between 140ms > > - 400ms across all of those regions from source, the amount of > > energy > spent > > explaining to customers that there is no way you can saturate your > > delivered capacity beyond a couple of Mbps using Ookla and friends > > is energy I could spend drinking wine and having a medium-rare > > steak, > instead. > > > > For us, at least, aside from going on a mass education drive in this > > particular market, the ultimate solution is just getting all that > content > > localized in-country or in-region. Once that latency comes down and > > the resources are available locally, the whole speed test debacle > > will > easily > > fall away, because the source of these speed tests is simply how > physically > > far the content is. Is this an easy task - hell no; but slamming > > your > head > > against a wall over and over is no fun either. > > > > Mark. > > > > From nanog at ics-il.net Wed Jul 18 13:54:15 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Jul 2018 08:54:15 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FA54A13@RTC-EXCH01.RESERVE.LDS> References: <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FA54A13@RTC-EXCH01.RESERVE.LDS> Message-ID: <1836466826.3087.1531922050867.JavaMail.mhammett@ThunderFuck> Correct. I figured most eyeballs had Google peering or were looking to get it. I was talking with CVF at ChiNOG about some of the shortcomings of the Google ISP Portal. He saw value in making the portal available to all ISPs. I don't know when (if) that will be available. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Luke Guillory" To: "K. Scott Helms" , "Mike Hammett" Cc: "NANOG list" Sent: Wednesday, July 18, 2018 8:48:32 AM Subject: RE: Proving Gig Speed https://isp.google.com Thought I think this is only for when you have peering, someone can correct me if that's incorrect. ns -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K. Scott Helms Sent: Wednesday, July 18, 2018 8:45 AM To: Mike Hammett Cc: NANOG list Subject: Re: Proving Gig Speed Mike, What portal would that be? Do you have a URL? On Wed, Jul 18, 2018 at 9:25 AM Mike Hammett wrote: > Check your Google portal for more information as to what Google can do > with BGP Communities related to reporting. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "K. Scott Helms" > To: "mark tinka" > Cc: "NANOG list" > Sent: Wednesday, July 18, 2018 7:40:31 AM > Subject: Re: Proving Gig Speed > > Agreed, and it's one of the fundamental problems that a speed test is > (and can only) measure the speeds from point A to point B (often both > inside the service provider's network) when the customer is concerned > with traffic to and from point C off in someone else's network > altogether. It's one of the reasons that I think we have to get more > comfortable and more collaborative with the CDN providers as well as > the large sources of traffic. Netflix, Youtube, and I'm sure others > have their own consumer facing performance testing that is _much_ more > applicable to most consumers as compared to the "normal" technician > test and measurement approach or even the service assurance that you > get from normal performance monitoring. What I'd really like to see is > a way to measure network performance from the CO/head end/PoP and also > get consumer level reporting from these kinds of services. If > Google/Netflix/Amazon Video/$others would get on board with this idea > it would make all our lives simpler. > > Providing individual users stats is nice, but if these guys really > want to improve service it would be great to get aggregate reporting > by ASN. You can get a rough idea by looking at your overall graph from > Google, but it's lacking a lot of detail and there's no simple way to > compare that to a head end/CO test versus specific end users. > > https://www.google.com/get/videoqualityreport/ > https://fast.com/# > > > > On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka wrote: > > > > > > > On 18/Jul/18 14:00, K. Scott Helms wrote: > > > > > > That's absolutely a concern Mark, but most of the CPE vendors that > support > > doing this are providing enough juice to keep up with their max > > forwarding/routing data rates. I don't see 10 Gbps in residential > Internet > > service being normal for quite a long time off even if the port > > itself > is > > capable of 10Gbps. We have this issue today with commercial > > customers, > but > > it's generally not as a much of a problem because the commercial CPE > > get their usage graphed and the commercial CPE have more > > capabilities for testing. > > > > > > I suppose the point I was trying to make is when does it stop being > > feasible to test each and every piece of bandwidth you deliver to a > > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or > 3.2Gbps, > > or 5.1Gbps... basically, the rabbit hole. > > > > Like Saku, I am more interested in other fundamental metrics that > > could impact throughput such as latency, packet loss and jitter. > > Bandwidth, itself, is easy to measure with your choice of SNMP poller + 5 minutes. > But > > when you're trying to explain to a simple customer buying 100Mbps > > that a break in your Skype video cannot be diagnosed with a > > throughput speed > test, > > they don't/won't get it. > > > > In Africa, for example, customers in only one of our markets are so > > obsessed with speed tests. But not to speed test servers that are > > in-country... they want to test servers that sit in Europe, North > America, > > South America and Asia-Pac. With the latency averaging between 140ms > > - 400ms across all of those regions from source, the amount of > > energy > spent > > explaining to customers that there is no way you can saturate your > > delivered capacity beyond a couple of Mbps using Ookla and friends > > is energy I could spend drinking wine and having a medium-rare > > steak, > instead. > > > > For us, at least, aside from going on a mass education drive in this > > particular market, the ultimate solution is just getting all that > content > > localized in-country or in-region. Once that latency comes down and > > the resources are available locally, the whole speed test debacle > > will > easily > > fall away, because the source of these speed tests is simply how > physically > > far the content is. Is this an easy task - hell no; but slamming > > your > head > > against a wall over and over is no fun either. > > > > Mark. > > > > From kscott.helms at gmail.com Wed Jul 18 14:00:27 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Wed, 18 Jul 2018 10:00:27 -0400 Subject: Proving Gig Speed In-Reply-To: <1245545974.3079.1531921569392.JavaMail.mhammett@ThunderFuck> References: <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> <1245545974.3079.1531921569392.JavaMail.mhammett@ThunderFuck> Message-ID: That seems only to be for direct peers Mike. On Wed, Jul 18, 2018 at 9:53 AM Mike Hammett wrote: > https://isp.google.com > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "K. Scott Helms" > To: "Mike Hammett" > Cc: "NANOG list" > Sent: Wednesday, July 18, 2018 8:45:22 AM > Subject: Re: Proving Gig Speed > > > Mike, > > What portal would that be? Do you have a URL? > > > On Wed, Jul 18, 2018 at 9:25 AM Mike Hammett < nanog at ics-il.net > wrote: > > > Check your Google portal for more information as to what Google can do > with BGP Communities related to reporting. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "K. Scott Helms" < kscott.helms at gmail.com > > To: "mark tinka" < mark.tinka at seacom.mu > > Cc: "NANOG list" < nanog at nanog.org > > Sent: Wednesday, July 18, 2018 7:40:31 AM > Subject: Re: Proving Gig Speed > > Agreed, and it's one of the fundamental problems that a speed test is (and > can only) measure the speeds from point A to point B (often both inside > the > service provider's network) when the customer is concerned with traffic to > and from point C off in someone else's network altogether. It's one of the > reasons that I think we have to get more comfortable and more > collaborative > with the CDN providers as well as the large sources of traffic. Netflix, > Youtube, and I'm sure others have their own consumer facing performance > testing that is _much_ more applicable to most consumers as compared to > the > "normal" technician test and measurement approach or even the service > assurance that you get from normal performance monitoring. What I'd really > like to see is a way to measure network performance from the CO/head > end/PoP and also get consumer level reporting from these kinds of > services. If Google/Netflix/Amazon Video/$others would get on board with > this idea it would make all our lives simpler. > > Providing individual users stats is nice, but if these guys really want to > improve service it would be great to get aggregate reporting by ASN. You > can get a rough idea by looking at your overall graph from Google, but > it's > lacking a lot of detail and there's no simple way to compare that to a > head > end/CO test versus specific end users. > > https://www.google.com/get/videoqualityreport/ > https://fast.com/# > > > > On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka < mark.tinka at seacom.mu > > wrote: > > > > > > > On 18/Jul/18 14:00, K. Scott Helms wrote: > > > > > > That's absolutely a concern Mark, but most of the CPE vendors that > support > > doing this are providing enough juice to keep up with their max > > forwarding/routing data rates. I don't see 10 Gbps in residential > Internet > > service being normal for quite a long time off even if the port itself > is > > capable of 10Gbps. We have this issue today with commercial customers, > but > > it's generally not as a much of a problem because the commercial CPE get > > their usage graphed and the commercial CPE have more capabilities for > > testing. > > > > > > I suppose the point I was trying to make is when does it stop being > > feasible to test each and every piece of bandwidth you deliver to a > > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or > 3.2Gbps, > > or 5.1Gbps... basically, the rabbit hole. > > > > Like Saku, I am more interested in other fundamental metrics that could > > impact throughput such as latency, packet loss and jitter. Bandwidth, > > itself, is easy to measure with your choice of SNMP poller + 5 minutes. > But > > when you're trying to explain to a simple customer buying 100Mbps that a > > break in your Skype video cannot be diagnosed with a throughput speed > test, > > they don't/won't get it. > > > > In Africa, for example, customers in only one of our markets are so > > obsessed with speed tests. But not to speed test servers that are > > in-country... they want to test servers that sit in Europe, North > America, > > South America and Asia-Pac. With the latency averaging between 140ms - > > 400ms across all of those regions from source, the amount of energy > spent > > explaining to customers that there is no way you can saturate your > > delivered capacity beyond a couple of Mbps using Ookla and friends is > > energy I could spend drinking wine and having a medium-rare steak, > instead. > > > > For us, at least, aside from going on a mass education drive in this > > particular market, the ultimate solution is just getting all that > content > > localized in-country or in-region. Once that latency comes down and the > > resources are available locally, the whole speed test debacle will > easily > > fall away, because the source of these speed tests is simply how > physically > > far the content is. Is this an easy task - hell no; but slamming your > head > > against a wall over and over is no fun either. > > > > Mark. > > > > > > > From mark.tinka at seacom.mu Wed Jul 18 14:00:49 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 16:00:49 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> Message-ID: <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> On 18/Jul/18 15:41, K. Scott Helms wrote: > > > That's why I vastly prefer stats from the actual CDNs and content > providers that aren't generated by speed tests.  They're generated by > measuring the actual performance of the service they deliver.  Now, > that won't prevent burden shifting, but it does get rid of a lot of > the problems you bring up.  Youtube for example wouldn't rate a video > stream as good if the packet loss were high because it's actually > looking at the bit rate of successfully delivered encapsulated video > frames I _think_ the same is true of Netflix though they also offer a > real time test as well which frankly isn't as helpful for monitoring > but getting a quick test to the Netflix node you'd normally use can be > nice in some cases. Agreed. In our market, we've generally not struggled with users and their experience for services hosted locally in-country. So in addition to providing good tools for operators and eyeballs to measure experience, the biggest win will come from the content folk and CDN's getting their services inside our market. Mark. From mark.tinka at seacom.mu Wed Jul 18 14:01:22 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 16:01:22 +0200 Subject: Proving Gig Speed In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FA54A13@RTC-EXCH01.RESERVE.LDS> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FA54A13@RTC-EXCH01.RESERVE.LDS> Message-ID: <2550ee12-fa79-87e1-a343-e8135553a775@seacom.mu> On 18/Jul/18 15:48, Luke Guillory wrote: > https://isp.google.com > > Thought I think this is only for when you have peering, someone can correct me if that's incorrect. And also if you operate a GGC (which is very likely if you're peering). Mark. From kscott.helms at gmail.com Wed Jul 18 14:22:26 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Wed, 18 Jul 2018 10:22:26 -0400 Subject: Proving Gig Speed In-Reply-To: <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> Message-ID: Mark, I am glad I don't have your challenges :) What's the Netflix (or other substantial OTT video provider) situation for direct peers? It's pretty easy and cheap for North American operators to get settlement free peering to Netflix, Amazon, Youtube and others but I don't know what that looks like in Africa. Scott Helms On Wed, Jul 18, 2018 at 10:00 AM Mark Tinka wrote: > > > On 18/Jul/18 15:41, K. Scott Helms wrote: > > > > That's why I vastly prefer stats from the actual CDNs and content > providers that aren't generated by speed tests. They're generated by > measuring the actual performance of the service they deliver. Now, that > won't prevent burden shifting, but it does get rid of a lot of the problems > you bring up. Youtube for example wouldn't rate a video stream as good if > the packet loss were high because it's actually looking at the bit rate of > successfully delivered encapsulated video frames I _think_ the same is true > of Netflix though they also offer a real time test as well which frankly > isn't as helpful for monitoring but getting a quick test to the Netflix > node you'd normally use can be nice in some cases. > > > Agreed. > > In our market, we've generally not struggled with users and their > experience for services hosted locally in-country. > > So in addition to providing good tools for operators and eyeballs to > measure experience, the biggest win will come from the content folk and > CDN's getting their services inside our market. > > Mark. > > From mark.tinka at seacom.mu Wed Jul 18 14:27:03 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Jul 2018 16:27:03 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> Message-ID: <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> On 18/Jul/18 16:22, K. Scott Helms wrote: > Mark, > > I am glad I don't have your challenges :) > > What's the Netflix (or other substantial OTT video provider) situation > for direct peers?  It's pretty easy and cheap for North American > operators to get settlement free peering to Netflix, Amazon, Youtube > and others but I don't know what that looks like in Africa. Peering isn't the problem. Proximity to content is. Netflix, Google, Akamai and a few others have presence in Africa already. So those aren't the problem (although for those currently in Africa, not all of the services they offer globally are available here - just a few). A lot of user traffic is not video streaming, so that's where a lot of work is required. In particular, cloud and gaming operators are the ones causing real pain. All the peering in the world doesn't help if the latency is well over 100ms+. That's what we need to fix. Mark. From valdis.kletnieks at vt.edu Wed Jul 18 14:53:39 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 18 Jul 2018 10:53:39 -0400 Subject: Proving Gig Speed In-Reply-To: <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> Message-ID: <7011.1531925619@turing-police.cc.vt.edu> On Wed, 18 Jul 2018 08:24:15 -0500, Mike Hammett said: > Check your Google portal for more information as to what Google can do with BGP Communities related to reporting. For a horrifying moment, I misread this as Google surfacing performance stats via a BGP stream by encoding stat_name:value as community:value /me goes searching for mass quantities of caffeine.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From kscott.helms at gmail.com Wed Jul 18 14:58:09 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Wed, 18 Jul 2018 10:58:09 -0400 Subject: Proving Gig Speed In-Reply-To: <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> Message-ID: > Peering isn't the problem. Proximity to content is. > > Netflix, Google, Akamai and a few others have presence in Africa already. > So those aren't the problem (although for those currently in Africa, not > all of the services they offer globally are available here - just a few). > > A lot of user traffic is not video streaming, so that's where a lot of > work is required. In particular, cloud and gaming operators are the ones > causing real pain. > > All the peering in the world doesn't help if the latency is well over > 100ms+. That's what we need to fix. > > Mark. > Mark, I agree completely, I'm working on a paper right now for a conference (waiting on Wireshark to finish with my complex filter at the moment) that shows what's happening with gaming traffic. What's really interesting is how gaming is changing and within the next few years I do expect a lot of games to move into the remote rendering world. I've tested several and the numbers are pretty substantial. You need to have <=30 ms of latency to sustain 1080p gaming and obviously jitter and packet loss are also problematic. The traffic is also pretty impressive with spikes of over 50 mbps down and sustained averages over 21 mbps. Upstream traffic isn't any more of an issue than "normal" online gaming. Nvidia, Google, and a host of start ups are all in the mix with a lot of people predicting Sony and Microsoft will be (or are already) working on pure cloud consoles. Scott Helms From nanog at ics-il.net Wed Jul 18 15:00:48 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Jul 2018 10:00:48 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: References: <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> Message-ID: <653857941.3208.1531926043595.JavaMail.mhammett@ThunderFuck> The game companies (and render farms) also need to work on as extensive peering as the top CDNs have been doing. They're getting better, but not quite there yet. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "K. Scott Helms" To: "mark tinka" Cc: "NANOG list" Sent: Wednesday, July 18, 2018 9:58:09 AM Subject: Re: Proving Gig Speed > Peering isn't the problem. Proximity to content is. > > Netflix, Google, Akamai and a few others have presence in Africa already. > So those aren't the problem (although for those currently in Africa, not > all of the services they offer globally are available here - just a few). > > A lot of user traffic is not video streaming, so that's where a lot of > work is required. In particular, cloud and gaming operators are the ones > causing real pain. > > All the peering in the world doesn't help if the latency is well over > 100ms+. That's what we need to fix. > > Mark. > Mark, I agree completely, I'm working on a paper right now for a conference (waiting on Wireshark to finish with my complex filter at the moment) that shows what's happening with gaming traffic. What's really interesting is how gaming is changing and within the next few years I do expect a lot of games to move into the remote rendering world. I've tested several and the numbers are pretty substantial. You need to have <=30 ms of latency to sustain 1080p gaming and obviously jitter and packet loss are also problematic. The traffic is also pretty impressive with spikes of over 50 mbps down and sustained averages over 21 mbps. Upstream traffic isn't any more of an issue than "normal" online gaming. Nvidia, Google, and a host of start ups are all in the mix with a lot of people predicting Sony and Microsoft will be (or are already) working on pure cloud consoles. Scott Helms From nanog at studio442.com.au Wed Jul 18 15:20:49 2018 From: nanog at studio442.com.au (Julien Goodwin) Date: Thu, 19 Jul 2018 01:20:49 +1000 Subject: Proving Gig Speed In-Reply-To: <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> Message-ID: <1ad38b85-c86b-8e1e-7207-e406aa266df2@studio442.com.au> On 19/07/18 00:27, Mark Tinka wrote: > All the peering in the world doesn't help if the latency is well over > 100ms+. That's what we need to fix. Living in Australia this is an every day experience, especially for content served out of Europe (or for that matter, Africa). TCP & below are rarely the biggest problem these days (at least with TCP-BBR & friends), far too often applications, web services etc. are simply never tested in an environment with any significant latency. While some issues may exist for static content loading for which a CDN can be helpful, that's not helpful for application traffic. From bruns at 2mbit.com Wed Jul 18 15:35:15 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 18 Jul 2018 09:35:15 -0600 Subject: Proving Gig Speed In-Reply-To: <947864411.1771.1531844269833.JavaMail.mhammett@ThunderFuck> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <972638918.1677.1531842460834.JavaMail.mhammett@ThunderFuck> <20180717161129.GA54411@ns.sol.net> <947864411.1771.1531844269833.JavaMail.mhammett@ThunderFuck> Message-ID: On 7/17/2018 10:18 AM, Mike Hammett wrote: > I don't think you understand the gravity of the in-home interference issue. Unfortunately, neither does the IEEE. > > It doesn't need to be in lock-step, but if a significant number of homes have issues getting over 100 megabit wirelessly, I'm not sure we need to be concerned about 10 gigabit to the home. > > I am well aware of the wireless world and Ubiquiti. I've been using Ubiquiti (among other brands) for over 10 years and have been a hardware beta tester for several of them. Customers are still harping on me about going wireless on all of their desktops. Since most of our customers are CAD/Design/Building companies, during planning, we insist on at least two drops to each workstation, preferably 3 or more. But, every time we go to do an upgrade... "Why can't we just use wireless?" Even though 20 minutes prior they're complaining at how slow it is for their laptops to open up large files over the network over wifi. "If you want faster speeds, you'll need to go from AC-Lites to AC-HDs with Wave 2. They're $350 or so each, and since your brand new building likes to absorb wifi, you'll need 5-8 of them to cover every possible location in the building. Oh, and you'll need to replace your laptops with Wave 2 capable ones, plus Wave 2 PCIe cards for every desktop... Except for the cheap $200 AMD APU desktops you bought against our recommendations that don't have expansion slots and no USB 3..." I long for the day when we can get 100mbit throughout a building or house reliably. (I'm a Ubnt hardware tester too, 99% of my customer setups are a mix of EdgeRouter, EdgeSwitch, and Unifi Switch and AP setups). -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From simon.leinen at switch.ch Wed Jul 18 15:38:48 2018 From: simon.leinen at switch.ch (Simon Leinen) Date: Wed, 18 Jul 2018 17:38:48 +0200 Subject: Proving Gig Speed In-Reply-To: <7011.1531925619@turing-police.cc.vt.edu> (valdis kletnieks's message of "Wed, 18 Jul 2018 10:53:39 -0400") References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <1017125415.2937.1531920250827.JavaMail.mhammett@ThunderFuck> <7011.1531925619@turing-police.cc.vt.edu> Message-ID: > For a horrifying moment, I misread this as Google surfacing > performance stats via a BGP stream by encoding stat_name:value as > community:value > /me goes searching for mass quantities of caffeine.... Because you'll be spending the night writing up that Internet-Draft? :-) -- Simon. From michel.py at tsisemi.com Wed Jul 18 19:30:48 2018 From: michel.py at tsisemi.com (Michel Py) Date: Wed, 18 Jul 2018 19:30:48 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: <2d21104f-670d-5c2b-609a-08bb9339e0fc@seacom.mu> References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <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> Message-ID: <7edc9ec76b0b4952adc91273c9a59416@CRA110.am.necel.com> Mark, >> Michel Py wrote: >> If I understand this correctly, I have a suggestion : update these files at a regular interval (15/20 min) and make them available for download with a fixed name >> (not containing the date). Even better : have a route server that announces these prefixes with a :666 community so people could use it as a blackhole. >> This would not remove the invalid prefixes from one's router, but at leat would prevent traffic from/to these prefixes. >> In other words : a route server of prefixes that are RPKI invalid with no alternative that people could use without having an RPKI setup. >> This would even work with people who have chosen do accept a default route from their upstream. >> I understand this is not ideal; blacklisting a prefix that is RPKI invalid may actually help the hijacker, but blacklisting a prefix that is RPKI invalid AND that has no >> alternative could be useful ? Should be considered a bogon. > Mark Tinka wrote : > Hmmh - I suppose if you want to do this in-house, that is fine. But I would not recommend this at large for the entire BGP community. Agree; was trying to to this is the spirit of this: http://arneill-py.sacramento.ca.us/cbbc/ As any blocklist, it should not be default and should be left to the end user to choose if they use it or not. > The difference is you are proposing a mechanism that uses existing infrastructure within almost all ISP's (the BGP Community) in lieu of deploying RPKI. Not in lieu, but when deploying RPKI is not (yet) possible. My routers are not RPKI capable, upgrading will take years (I'm not going to upgrade just because I want RPKI). My upstreams don't do RPKI, I'm trying to convince them but I'm talking to deaf ears. What do I have left : using a subset of RPKI as a blackhole :-( > I can't quite imagine the effort needed to implement your suggestion, Not much at all, I was actually trying you do do the RPKI part for me ;-) This script you wrote, to produce the list of prefixes that are RPKI invalid AND that do not have any alternative, make it run every x minutes on a fixed url (no date/time in name). I will fetch it, inject it in ExaBGP that feeds my iGP and voila, done. Who wants to use it can, not trying to impose it on the entire BGP community. > but I'd rather direct it toward deploying RPKI. At the very least, one just needs reputable RV software, and router code that support RPKI RV. We probably have to wait until attrition brings us routers that have said code. 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 kmedcalf at dessus.com Wed Jul 18 19:32:27 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 18 Jul 2018 13:32:27 -0600 Subject: Proving Gig Speed In-Reply-To: <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <8aac808c80d5fa4089f971e4bd10a3da@mail.dessus.com> Whats WiFi? Is that the "noise" that escapes from the copper cables? Switch to optical fibre, it does not emit RF noise ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike >Hammett >Sent: Tuesday, 17 July, 2018 08:42 >To: Mark Tinka >Cc: NANOG list >Subject: Re: Proving Gig Speed > >10G to the home will be pointless as more and more people move away >from Ethernet to WiFi where the noise floor for most installs >prevents anyone from reaching 802.11n speeds, much less whatever >alphabet soup comes later. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com > >----- Original Message ----- > >From: "Mark Tinka" >To: "K. Scott Helms" >Cc: "NANOG list" >Sent: Tuesday, July 17, 2018 7:11:35 AM >Subject: Re: Proving Gig Speed > > > >On 17/Jul/18 14:07, K. Scott Helms wrote: > >> >> That's absolutely true, but I don't see any real alternatives in >some >> cases. I've actually built automated testing into some of the CPE >> we've deployed and that works pretty well for some models but other >> devices don't seem to be able to fill a ~500 mbps link. > >So what are you going to do when 10Gbps FTTH into the home becomes >the norm? > >Perhaps laptops and servers of the time won't even see this as a >rounding error :-\... > >Mark. From job at ntt.net Wed Jul 18 19:47:00 2018 From: job at ntt.net (Job Snijders) Date: Wed, 18 Jul 2018 19:47:00 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: <7edc9ec76b0b4952adc91273c9a59416@CRA110.am.necel.com> References: <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> Message-ID: <20180718194700.GY42041@vurt.meerval.net> On Wed, Jul 18, 2018 at 07:30:48PM +0000, Michel Py wrote: > Not in lieu, but when deploying RPKI is not (yet) possible. My > routers are not RPKI capable, upgrading will take years (I'm not going > to upgrade just because I want RPKI). Can you elaborate what routers with what software you are using? It surprises me a bit to find routers anno 2018 which can't do OV in some shape or form. > What do I have left : using a subset of RPKI as a blackhole :-( If you implement 'invalid == blackhole', and cannot do normal OV - it seems to me that you'll be blackholing the actual victim of a BGP hijack? That would seem counter-productive. Kind regards, Job From michel.py at tsisemi.com Wed Jul 18 20:16:15 2018 From: michel.py at tsisemi.com (Michel Py) Date: Wed, 18 Jul 2018 20:16:15 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180718194700.GY42041@vurt.meerval.net> References: <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> <20180718194700.GY42041@vurt.meerval.net> Message-ID: <4784b49934ff44578106de5c7869626c@CRA110.am.necel.com> > Job Snijders wrote : > Can you elaborate what routers with what software you are using? It surprises > me a bit to find routers anno 2018 which can't do OV in some shape or form. They're not anno 2018 ! Cisco 3900 with 4 Gigs. Good enough for me, with the current growth of the DFZ I may have 10 years left before I need to upgrade. Probably will upgrade before that caused to bandwidth, but as of now works good enough for me and upgrading just to get OV is going to be a tough sell. >> What do I have left : using a subset of RPKI as a blackhole :-( > If you implement 'invalid == blackhole', and cannot do normal OV - it seems to me that > you'll be blackholing the actual victim of a BGP hijack? That would seem counter-productive. I would indeed, but the intent was a subset of invalid : the invalid prefixes that nobody _but_ the hijacker anounces, so blackholing does not hurt the real owner. In other words : un-announced prefixes that have been hijacked. These are not into bogon lists because they are real. Now I have no illusions : this is not going to solve the world's problems, how many of these are actually announced and how will that play in the longer term are questionable, but would not that be worth a quick shot at it ? Michel. From randy at psg.com Wed Jul 18 21:55:23 2018 From: randy at psg.com (Randy Bush) Date: Wed, 18 Jul 2018 17:55:23 -0400 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180718194700.GY42041@vurt.meerval.net> References: <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> <20180718194700.GY42041@vurt.meerval.net> Message-ID: > Can you elaborate what routers with what software you are using? It > surprises me a bit to find routers anno 2018 which can't do OV in some > shape or form. depends on how picky you are about "some shape or form." draft-ietf-sidrops-ov-clarify was not written because it is usefully implemented by many vendors. randy From keiths at neilltech.com Wed Jul 18 21:56:47 2018 From: keiths at neilltech.com (Keith Stokes) Date: Wed, 18 Jul 2018 21:56:47 +0000 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <5A6328E2-5D60-477F-8973-433703328092@neilltech.com> At least in the US, Jane also doesn’t really have a choice of her electricity provider, so she’s not getting bombarded with advertising from vendors selling “Faster WiFi” than the next guy. I don’t get to choose my method of power generation and therefore cost per kWh. I’d love to buy $.04 from the Pacific NW when I’m in the Southern US. I’m not a betting guy, but my money says when self power generation hits some point and multiple vendors are trying to get people to buy their system, we’ll get “More amps per X hours of sunlight with our system” and she will care. On Jul 18, 2018, at 7:01 AM, Mark Tinka > wrote: On 17/Jul/18 18:12, Andy Ringsmuth wrote: I suppose in reality it’s no different than any other utility. My home has 200 amp electrical service. Will I ever use 200 amps at one time? Highly highly unlikely. But if my electrical utility wanted to advertise “200 amp service in all homes we supply!” they sure could. Would an electrician be able to test it? I’m sure there is a way somehow. If me and everyone on my street tried to use 200 amps all at the same time, could the infrastructure handle it? Doubtful. But do I on occasion saturate my home fiber 300 mbit synchronous connection? Every now and then yes, but rarely. Although if I’m paying for 300 and not getting it, my ISP will be hearing from me. If my electrical utility told me “hey, you can upgrade to 500 amp service for no additional charge” would I do it? Sure, what the heck. If my water utility said “guess what? You can upgrade to a 2-inch water line at no additional charge!” would I do it? Probably yeah, why not? Would I ever use all that capacity on $random_utility at one time? Of course not. But nice to know it’s there if I ever need it. The difference, of course, between electricity and the Internet is that there is a lot more information and tools freely available online that Average Jane can arm herself with to run amok with figuring out whether she is getting 300Mbps of her 300Mbps from her ISP. Average Jane could care less about measuring whether she's getting 200 amps of her 200 amps from the power company; likely because there is a lot more structure with how power is produced and delivered, or more to the point, a lot less freely available tools and information with which she can arm herself to run amok with. To her, the power company sucks if the lights go out. In the worst case, if her power starts a fire, she's calling the fire department. Mark. --- Keith Stokes Neill Technologies From job at ntt.net Wed Jul 18 23:21:03 2018 From: job at ntt.net (Job Snijders) Date: Wed, 18 Jul 2018 23:21:03 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> <20180716152603.GE42041@vurt.meerval.net> <2d21104f-670d-5c2b-609a-08bb9339e0fc@seacom.mu> <7edc9ec76b0b4952adc91273c9a59416@CRA110.am.necel.com> <20180718194700.GY42041@vurt.meerval.net> Message-ID: <20180718232103.GA42041@vurt.meerval.net> On Wed, Jul 18, 2018 at 05:55:23PM -0400, Randy Bush wrote: > > Can you elaborate what routers with what software you are using? It > > surprises me a bit to find routers anno 2018 which can't do OV in > > some shape or form. > > depends on how picky you are about "some shape or form." I was thinking along the lines of "perhaps the box can't do RTR but allows for ROAs to be configured in the run-time config" > draft-ietf-sidrops-ov-clarify was not written because it is usefully > implemented by many vendors. @ all - It would be good if operators ask their vendors if they can get behind this I-D https://tools.ietf.org/html/draft-ietf-sidrops-ov-clarify Kind regards, Job From nanog at ics-il.net Thu Jul 19 02:26:44 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Jul 2018 21:26:44 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: <8aac808c80d5fa4089f971e4bd10a3da@mail.dessus.com> References: <8aac808c80d5fa4089f971e4bd10a3da@mail.dessus.com> Message-ID: <1215968509.3946.1531967203880.JavaMail.mhammett@ThunderFuck> I don't think iPhones have SFP cages. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" To: "Mike Hammett" , "Mark Tinka" Cc: "NANOG list" Sent: Wednesday, July 18, 2018 2:32:27 PM Subject: RE: Proving Gig Speed Whats WiFi? Is that the "noise" that escapes from the copper cables? Switch to optical fibre, it does not emit RF noise ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike >Hammett >Sent: Tuesday, 17 July, 2018 08:42 >To: Mark Tinka >Cc: NANOG list >Subject: Re: Proving Gig Speed > >10G to the home will be pointless as more and more people move away >from Ethernet to WiFi where the noise floor for most installs >prevents anyone from reaching 802.11n speeds, much less whatever >alphabet soup comes later. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com > >----- Original Message ----- > >From: "Mark Tinka" >To: "K. Scott Helms" >Cc: "NANOG list" >Sent: Tuesday, July 17, 2018 7:11:35 AM >Subject: Re: Proving Gig Speed > > > >On 17/Jul/18 14:07, K. Scott Helms wrote: > >> >> That's absolutely true, but I don't see any real alternatives in >some >> cases. I've actually built automated testing into some of the CPE >> we've deployed and that works pretty well for some models but other >> devices don't seem to be able to fill a ~500 mbps link. > >So what are you going to do when 10Gbps FTTH into the home becomes >the norm? > >Perhaps laptops and servers of the time won't even see this as a >rounding error :-\... > >Mark. From aaron at heyaaron.com Thu Jul 19 02:32:23 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 18 Jul 2018 19:32:23 -0700 Subject: Comcast outage Southwest Washington? Message-ID: There a Comcast outage affecting a few of my locations in SW Washington state. We initially had an estimate of 3:26 PM for service restoration. That got bumped to 7 PM. Now the phone system isn't giving an ETR and the phone system says there are excessive hold times. I'm guessing it's a fiber cut. Can anyone provide some insight? Thanks, -A From sethm at rollernet.us Thu Jul 19 03:10:35 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 18 Jul 2018 20:10:35 -0700 Subject: Proving Gig Speed In-Reply-To: <1215968509.3946.1531967203880.JavaMail.mhammett@ThunderFuck> References: <8aac808c80d5fa4089f971e4bd10a3da@mail.dessus.com> <1215968509.3946.1531967203880.JavaMail.mhammett@ThunderFuck> Message-ID: <50ceb823-5d7d-0c4c-4ab8-f115d1612290@rollernet.us> On 7/18/18 7:26 PM, Mike Hammett wrote: > I don't think iPhones have SFP cages. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Keith Medcalf" > To: "Mike Hammett", "Mark Tinka" > Cc: "NANOG list" > Sent: Wednesday, July 18, 2018 2:32:27 PM > Subject: RE: Proving Gig Speed > > > Whats WiFi? Is that the "noise" that escapes from the copper cables? Switch to optical fibre, it does not emit RF noise ... > It's comeback time for IrDA ports! From mark.tinka at seacom.mu Thu Jul 19 05:03:44 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 07:03:44 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> Message-ID: <766158e1-560a-ce9d-e67e-b396bb4b3dab@seacom.mu> On 18/Jul/18 16:58, K. Scott Helms wrote: > > Mark, > > I agree completely, I'm working on a paper right now for a conference > (waiting on Wireshark to finish with my complex filter at the moment) > that shows what's happening with gaming traffic.  What's really > interesting is how gaming is changing and within the next few years I > do expect a lot of games to move into the remote rendering world.  > I've tested several and the numbers are pretty substantial.  You need > to have <=30 ms of latency to sustain 1080p gaming and obviously > jitter and packet loss are also problematic.  The traffic is also > pretty impressive with spikes of over 50 mbps down and sustained > averages over 21 mbps.  Upstream traffic isn't any more of an issue > than "normal" online gaming.  Nvidia, Google, and a host of start ups > are all in the mix with a lot of people predicting Sony and Microsoft > will be (or are already) working on pure cloud consoles. And what we need is for them to ensure all these remote rendering farms are evenly distributed around the world to ensure that 30ms peak latency is achievable. Mark. From mark.tinka at seacom.mu Thu Jul 19 05:06:00 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 07:06:00 +0200 Subject: Proving Gig Speed In-Reply-To: <653857941.3208.1531926043595.JavaMail.mhammett@ThunderFuck> References: <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> <653857941.3208.1531926043595.JavaMail.mhammett@ThunderFuck> Message-ID: On 18/Jul/18 17:00, Mike Hammett wrote: > The game companies (and render farms) also need to work on as extensive peering as the top CDNs have been doing. They're getting better, but not quite there yet. I'm not sure about North America, Asia-Pac or South America, but in Europe, the gaming folk actually peer very well. The problem for us is that is anymore from 112ms - 170ms away, depending on which side of the continent you are. And while we peer extensively with them via our network in Europe, that latency will simply not go away. They need to come into market and satisfy their demand. Mark. From mark.tinka at seacom.mu Thu Jul 19 05:06:36 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 07:06:36 +0200 Subject: Proving Gig Speed In-Reply-To: <1ad38b85-c86b-8e1e-7207-e406aa266df2@studio442.com.au> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> <1ad38b85-c86b-8e1e-7207-e406aa266df2@studio442.com.au> Message-ID: <79bbfd6a-11b7-5789-d89a-8751f116e9a4@seacom.mu> On 18/Jul/18 17:20, Julien Goodwin wrote: > Living in Australia this is an every day experience, especially for > content served out of Europe (or for that matter, Africa). > > TCP & below are rarely the biggest problem these days (at least with > TCP-BBR & friends), far too often applications, web services etc. are > simply never tested in an environment with any significant latency. > > While some issues may exist for static content loading for which a CDN > can be helpful, that's not helpful for application traffic. Yip. Mark. From mark.tinka at seacom.mu Thu Jul 19 05:15:03 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 07:15:03 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <972638918.1677.1531842460834.JavaMail.mhammett@ThunderFuck> <20180717161129.GA54411@ns.sol.net> <947864411.1771.1531844269833.JavaMail.mhammett@ThunderFuck> Message-ID: <6ac027bf-1f5f-d8f1-ba32-bbc2768d122c@seacom.mu> On 18/Jul/18 17:35, Brielle Bruns wrote: >   > > Customers are still harping on me about going wireless on all of their > desktops.  Since most of our customers are CAD/Design/Building > companies, during planning, we insist on at least two drops to each > workstation, preferably 3 or more. > > But, every time we go to do an upgrade... > > "Why can't we just use wireless?" > > Even though 20 minutes prior they're complaining at how slow it is for > their laptops to open up large files over the network over wifi. > > "If you want faster speeds, you'll need to go from AC-Lites to AC-HDs > with Wave 2.  They're $350 or so each, and since your brand new > building likes to absorb wifi, you'll need 5-8 of them to cover every > possible location in the building.  Oh, and you'll need to replace > your laptops with Wave 2 capable ones, plus Wave 2 PCIe cards for > every desktop... Except for the cheap $200 AMD APU desktops you bought > against our recommendations that don't have expansion slots and no USB > 3..." > > I long for the day when we can get 100mbit throughout a building or > house reliably. > > (I'm a Ubnt hardware tester too, 99% of my customer setups are a mix > of EdgeRouter, EdgeSwitch, and Unifi Switch and AP setups). I have a 100Mbps FTTH service to my house, sitting on 802.11ac (Google OnHub units, pretty dope, had them for almost 2 years now). With my 802.11ac client devices, I can do well over 600Mbps within my walls, easily, over the air. But that's because only one of my neighbors that is closest to me has wi-fi (in 2.4GHz, thank God). The rest are too far for my thick walls. It's a totally different story in the office where (fair point, we're still on 802.11n, but...) the wi-fi is simply useless, because of all the competing radios from adjacent companies in all bands and on all channels. And despite having several AP's all over the place + using a controller to manage the radio network, fundamentally, I prefer wiring up when I'm in my office, and only use the wi-fi for my phones or when I need to go to another office or boardroom with my laptop. But the point is you and I get this phenomenon. Users don't, regardless of whether they are sending a 2KB e-mail or rendering a multi-gigabit CAD file. Mark. From mark.tinka at seacom.mu Thu Jul 19 05:25:39 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 07:25:39 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <7edc9ec76b0b4952adc91273c9a59416@CRA110.am.necel.com> References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <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> Message-ID: On 18/Jul/18 21:30, Michel Py wrote: > Not much at all, I was actually trying you do do the RPKI part for me ;-) > This script you wrote, to produce the list of prefixes that are RPKI invalid AND that do not have any alternative, make it run every x minutes on a fixed url (no date/time in name). I will fetch it, inject it in ExaBGP that feeds my iGP and voila, done. Just to clarify, Job wrote that script, not me :-). > Who wants to use it can, not trying to impose it on the entire BGP community. Which is fine, but I want to be cautious about encouraging a parallel stream that slows down the deployment of RPKI. > We probably have to wait until attrition brings us routers that have said code. We generally use typical service provider routers to deliver services. So I'm not sure whether the 3900's you run support it or not. Mark. From mark.tinka at seacom.mu Thu Jul 19 05:30:07 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 07:30:07 +0200 Subject: Proving Gig Speed In-Reply-To: <5A6328E2-5D60-477F-8973-433703328092@neilltech.com> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <5A6328E2-5D60-477F-8973-433703328092@neilltech.com> Message-ID: On 18/Jul/18 23:56, Keith Stokes wrote: > At least in the US, Jane also doesn’t really have a choice of her > electricity provider, so she’s not getting bombarded with advertising > from vendors selling “Faster WiFi” than the next guy. I don’t get to > choose my method of power generation and therefore cost per kWh. I’d > love to buy $.04 from the Pacific NW when I’m in the Southern US. And that's why I suspect that 10Gbps to the home will become a reality not out of necessity, but out of a race on who can out-market the other. The problem for us as operators - which is what I was trying to explain - was that even though the home will likely not saturate that 10Gbps link, never mind even use 1% of it in any sustained fashion, we shall be left the burden of proving the "I want to see my 10Gbps that I bought, or I'm moving to your competitor" case over and over again. When are we going to stop feeding the monster we've created (or more accurately, that has been created for us)? Mark. From mark.tinka at seacom.mu Thu Jul 19 05:46:55 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 07:46:55 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180718232103.GA42041@vurt.meerval.net> References: <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> <20180716152603.GE42041@vurt.meerval.net> <2d21104f-670d-5c2b-609a-08bb9339e0fc@seacom.mu> <7edc9ec76b0b4952adc91273c9a59416@CRA110.am.necel.com> <20180718194700.GY42041@vurt.meerval.net> <20180718232103.GA42041@vurt.meerval.net> Message-ID: <2e1f018f-6bce-ab5e-1025-4f38d058e895@seacom.mu> On 19/Jul/18 01:21, Job Snijders wrote: > @ all - It would be good if operators ask their vendors if they can get > behind this I-D https://tools.ietf.org/html/draft-ietf-sidrops-ov-clarify I'm actually glad to see this (Randy, you've abandoned me, hehe). We actually hit and troubleshot both these issues together with Randy and a bunch of many good folk in the operator and vendor community back in 2016/2017, where we discovered that Cisco were marking all iBGP routes as Valid by default, and automatically applying RPKI policy on routes without actual operator input. The latter issue was actually officially documented as part of how the implementation works over at Cisco-land, but the former was a direct violation of the RFC. These issues were eventually fixed later in 2017, but glad to see that there is an I-D that proposes this more firmly! Thanks, Randy! Mark. From nanog-isp at mail.com Thu Jul 19 06:48:58 2018 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Thu, 19 Jul 2018 08:48:58 +0200 Subject: Proving Gig Speed Message-ID: No, but you can connect iPhones with gigabit Ethernet over copper. Jared >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike >Hammett >Cc: NANOG list >Subject: Re: Proving Gig Speed > > I don't think iPhones have SFP cages. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com From joelja at bogus.com Thu Jul 19 12:57:36 2018 From: joelja at bogus.com (joel jaeggli) Date: Thu, 19 Jul 2018 08:57:36 -0400 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <5A6328E2-5D60-477F-8973-433703328092@neilltech.com> Message-ID: On 7/19/18 1:30 AM, Mark Tinka wrote: > > On 18/Jul/18 23:56, Keith Stokes wrote: > >> At least in the US, Jane also doesn’t really have a choice of her >> electricity provider, so she’s not getting bombarded with advertising >> from vendors selling “Faster WiFi” than the next guy. I don’t get to >> choose my method of power generation and therefore cost per kWh. I’d >> love to buy $.04 from the Pacific NW when I’m in the Southern US. > And that's why I suspect that 10Gbps to the home will become a reality > not out of necessity, but out of a race on who can out-market the other. > > The problem for us as operators - which is what I was trying to explain > - was that even though the home will likely not saturate that 10Gbps > link, never mind even use 1% of it in any sustained fashion, we shall be > left the burden of proving the "I want to see my 10Gbps that I bought, > or I'm moving to your competitor" case over and over again. > > When are we going to stop feeding the monster we've created (or more > accurately, that has been created for us)? There is a point beyond which the network ceases to be a serious imposition on what you are trying to do. When it gets there, it fades into the background as a utility function. The fact that multiple streaming audio / video applications in a household doesn't have to routinely cheese people off point to the threshold having been reached for the those applications at least in fixed networks. For others it will it still be a while. When that 5GB software update or a new purchased 25GB game takes 20 minutes to  deliver that's a delay between intent and action that the user or service operator might seek to minimize. Likewise, Latency or Jitter associated with network resource contention impacts real-time applications. When the network is sufficiently scaled / well behaved that these applications can coexist without imposition that stops being a point of contention. > Mark. > From aaron1 at gvtc.com Thu Jul 19 14:34:39 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 19 Jul 2018 09:34:39 -0500 Subject: issues through CGNat (juniper ms-mpc-128g in mx960) Message-ID: <000001d41f6d$a014efd0$e03ecf70$@gvtc.com> (please forgive cross-posting between jnsp and nanog.looking for anyone who could help shed light) I moved customers behind MS-MPC-128G (MX960) CGNat boundary a few nights ago. for the most part it went well. with these couple issues. please let me know what you know about this and how to fix. I don't know if it's fixed on the endpoints, or in the cgnat config or what. 1 - IPSEC VPN - Customer said the vpn connect light on cisco vpn router blinks (not connected to vpn) - I found out the vpn addresses that this cisco vpn router is trying to connect to. - I did a fix in cgnat rule stanza where all UDP 500 and 4500 traffic to that distant vpn endpoint(s) will always be natted to one and only one ip address (I did this thinking that the changing ip of the public pool assigned ip addresses for udp 500 and 4500 was possible breaking it) 2 - PS4 gaming - Customer said playing a few games (call of duty, etc) with Internet players now doesn't work. - They said the PS4 nat type is nat type 3 (strict) whereas before the moved them to cgnat, it was NAT type 2 moderate and worked. -Aaron From merculiani at gmail.com Thu Jul 19 14:44:06 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Thu, 19 Jul 2018 09:44:06 -0500 Subject: issues through CGNat (juniper ms-mpc-128g in mx960) In-Reply-To: <000001d41f6d$a014efd0$e03ecf70$@gvtc.com> References: <000001d41f6d$a014efd0$e03ecf70$@gvtc.com> Message-ID: One of the biggest deal-breakers about the Miltiservices DPC and MPC is that it does not support NAT Transversal (UDP hole punching), which is probably the reason you're having trouble with the PS4 online gaming. It also messes with VoIP too. As for the IPsec issue, im not sure if that would be related to NAT-T, but you'd probably need logs. Might just be easier to give anyone using an IPsec tunnel a public IP. -M On Thu, Jul 19, 2018, 09:35 Aaron Gould wrote: > (please forgive cross-posting between jnsp and nanog.looking for anyone who > could help shed light) > > > > I moved customers behind MS-MPC-128G (MX960) CGNat boundary a few nights > ago. for the most part it went well. with these couple issues. please let > me > know what you know about this and how to fix. I don't know if it's fixed on > the endpoints, or in the cgnat config or what. > > > > 1 - IPSEC VPN > > - Customer said the vpn connect light on cisco vpn router blinks > (not > connected to vpn) > > - I found out the vpn addresses that this cisco vpn router is trying > to connect to. > > - I did a fix in cgnat rule stanza where all UDP 500 and 4500 > traffic > to that distant vpn endpoint(s) will always be natted to one and only one > ip > address (I did this thinking that the changing ip of the public pool > assigned ip addresses for udp 500 and 4500 was possible breaking it) > > > > 2 - PS4 gaming > > - Customer said playing a few games (call of duty, etc) with > Internet > players now doesn't work. > > - They said the PS4 nat type is nat type 3 (strict) whereas before > the moved them to cgnat, it was NAT type 2 moderate and worked. > > > > > > -Aaron > > > > From wessels at packet-pushers.com Thu Jul 19 05:19:39 2018 From: wessels at packet-pushers.com (Duane Wessels) Date: Wed, 18 Jul 2018 22:19:39 -0700 Subject: NANOG list errors In-Reply-To: <0CC37D49-CAFD-4E61-A7AF-8D76E6622DFF@newslink.com> References: <0CC37D49-CAFD-4E61-A7AF-8D76E6622DFF@newslink.com> Message-ID: > On Jul 17, 2018, at 9:24 PM, Andy Ringsmuth wrote: > > Fellow list members, > > The last several days, I’ve been receiving mail forwarding loop errors for the list. I’ll receive them several hours after sending a message. I’ll paste the latest two of them below, separated by % symbols. > > Anyone able to sort this out and fix? Andy (and others), if you forward a few full bounces to me I can take a look and see what might be going on. DW From mark.tinka at seacom.mu Thu Jul 19 15:02:50 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 17:02:50 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <20180716170059.GA20221@moussaka.pmacct.net> References: <20180712175029.GC3037@vurt.meerval.net> <20180716170059.GA20221@moussaka.pmacct.net> Message-ID: <1ac02402-cdcb-57f7-549b-25bb695ef119@seacom.mu> On 16/Jul/18 19:00, Paolo Lucente wrote: > Hi Job, All, > > It is definitely great to see progress on the deployment side! I realize > that there may be some gaps in the network operator toolchain, and this > may be something i'd like to contribute to. > > For network operators to better understand the impact of BGP hijacks in > terms of revenue or volumes of traffic that went missing, it makes perfect > sense if network monitoring tools are aware of which BGP announcements > are invalid or not. > > I will look into adding support for the RTR protocol (RFC 6810, RFC > 8210) to pmacct ( https://github.com/pmacct/pmacct , http://pmacct.net/ ) > and expose the validation state through an extra field (when collecting > routing tables) and primitive (when accounting traffic and correlating > it with BGP data). > > Updating the telemetry tools to be fully aware of RPKI validation states > should come in handy! Sounds great, Paolo. Many thanks for this. Mark. From nathalie at ripe.net Thu Jul 19 13:23:58 2018 From: nathalie at ripe.net (Nathalie Trenaman) Date: Thu, 19 Jul 2018 15:23:58 +0200 Subject: Implementation plan and dates for NWI5 - Out-of-region ROUTE(6) objects and removal of ASN authorisation for ROUTE(6) object creation. Message-ID: <8B1934F2-3956-4DED-97FF-D1D33421C0C1@ripe.net> Dear colleagues, In February 2018, the RIPE Database Working Group reached consensus on NWI-5 - creating out of region ROUTE(6) objects in the RIPE Database. We will soon be making changes to the way out-of-region objects are handled in the RIPE Database. It's important that database users are aware of these changes and what they mean: 1. The RIPE Routing Registry will no longer support the creation of out-of-region ROUTE(6) and AUT-NUM objects 2. Existing out-of-region objects will have their "source:” attribute changed to "RIPE-NONAUTH” 3. The creation of ROUTE(6) objects will no longer need authorisation from the ASN holder We will implement these changes in the Release Candidate environment on Thursday, 2 August and go to full production on Tuesday, 4 September. Our implementation plan can be found at: https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation The RIPE Database Working Group chairs also wrote a RIPE Labs article that describes the background of NWI-5: https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objects-in-the-ripe-database > Please contact ripe-dbm at ripe.net if you still have questions after reading the implementation plan. Best regards, Nathalie Trenaman Product Manager RIPE NCC From mhohman at newheights.org Thu Jul 19 04:15:54 2018 From: mhohman at newheights.org (Matt Hohman) Date: Thu, 19 Jul 2018 04:15:54 +0000 Subject: Comcast outage Southwest Washington? In-Reply-To: References: Message-ID: Seeing the same in one of 6 locations in Clark County. Our Comcast DIA fiber service and all but our east Clark county location are still up and running. Thanks, Matt Hohman Technical Ministries New Heights Church ________________________________ From: 20231464200n behalf of Sent: Wednesday, July 18, 2018 7:33 PM To: NANOG mailing list Subject: Comcast outage Southwest Washington? There a Comcast outage affecting a few of my locations in SW Washington state. We initially had an estimate of 3:26 PM for service restoration. That got bumped to 7 PM. Now the phone system isn't giving an ETR and the phone system says there are excessive hold times. I'm guessing it's a fiber cut. Can anyone provide some insight? Thanks, -A From kennethfinnegan2007 at gmail.com Thu Jul 19 04:38:23 2018 From: kennethfinnegan2007 at gmail.com (Kenneth Finnegan) Date: Wed, 18 Jul 2018 21:38:23 -0700 Subject: Quickstart Guide to IRR/RPSL Message-ID: Greetings, As part of setting up a new Internet Exchange in Fremont, California, we've been investigating prefix filtering on the route servers based on IRR. Unfortunately, we were not satisfied with any of the existing documentation available online as far as taking a network engineer from "zero" to "just enough IRR to post our prefixes for filtering". Lacking this documentation, it was rather unreasonable for us to turn on filtering and drop most of our peer's prefixes without a relevant whitepaper to point them to to get started. So, we wrote our own guide: http://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html I thought others on this list would find our whitepaper interesting, and/or have valuable feedback based on their experience applying IRR themselves. -- Kenneth Finnegan Technical Director Fremont Cabal Internet Exchange http://fcix.net/ From niels=nanog at bakker.net Thu Jul 19 15:06:55 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 19 Jul 2018 17:06:55 +0200 Subject: Proving Gig Speed In-Reply-To: References: <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> <653857941.3208.1531926043595.JavaMail.mhammett@ThunderFuck> Message-ID: <20180719150655.GA11417@jima.tpb.net> * mark.tinka at seacom.mu (Mark Tinka) [Thu 19 Jul 2018, 07:08 CEST]: >I'm not sure about North America, Asia-Pac or South America, but in >Europe, the gaming folk actually peer very well. > >The problem for us is that is anymore from 112ms - 170ms away, >depending on which side of the continent you are. > >And while we peer extensively with them via our network in Europe, >that latency will simply not go away. They need to come into market >and satisfy their demand. That will happen as soon as it's affordable for them to do so - which requires an ecosystem of affordable and reliable independent IP transit/transport and colocation to exist. -- Niels. From oscar.vives at gmail.com Thu Jul 19 15:08:26 2018 From: oscar.vives at gmail.com (Tei) Date: Thu, 19 Jul 2018 17:08:26 +0200 Subject: Proving Gig Speed In-Reply-To: <79bbfd6a-11b7-5789-d89a-8751f116e9a4@seacom.mu> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> <1ad38b85-c86b-8e1e-7207-e406aa266df2@studio442.com.au> <79bbfd6a-11b7-5789-d89a-8751f116e9a4@seacom.mu> Message-ID: On 19 July 2018 at 07:06, Mark Tinka wrote: > > > On 18/Jul/18 17:20, Julien Goodwin wrote: > >> Living in Australia this is an every day experience, especially for >> content served out of Europe (or for that matter, Africa). >> >> TCP & below are rarely the biggest problem these days (at least with >> TCP-BBR & friends), far too often applications, web services etc. are >> simply never tested in an environment with any significant latency. >> >> While some issues may exist for static content loading for which a CDN >> can be helpful, that's not helpful for application traffic. > > Yip. > > Mark. Sorry about that. I feel bad has a webmaster. Most of us on the web we are creating websites that are not documents to be download and viewed, but applications that require to work many small parts that are executed togeter. Most VRML examples from 1997 are unavailable because host moved, directories changed name, whole websites where redone with new technologies. Only a 1% of that exist in a readable format. But the current web is much more delicate, and will break more and sooner than that. Perhaps something can be done about it. Chrome already include a option to test websites emulating "Slow 3G" that webmasters may use and want to use. I suggest a header or html meta tag where a documents disable external js scripts, or limit these to a white list of hosts. . So if you are a Vodafone customer. And you are reading a political document. Vodafone can inject a javascript script in the page. But it will not run because of the presence of . Vodafone can still further alter the html of the page to remove this meta and inject their script. Get webmasters into the idea of making websites that are documents. That require no execution of scripts. So they will still work in 2048. And will work in poor network conditions, where a website that load 47 different js files may break. tl:dr: the web is evolving into a network of applications, instead of documents. Documents can't "break" easily. Programs may break completelly even to tiny changes. Maybe getting webmasters on board of biasing in favor of documents could do us all a favour. -- -- ℱin del ℳensaje. From mark.tinka at seacom.mu Thu Jul 19 15:19:55 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 17:19:55 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> <5A6328E2-5D60-477F-8973-433703328092@neilltech.com> Message-ID: <3ccb1af5-b0ed-0f13-11c2-1c6b11b373db@seacom.mu> On 19/Jul/18 14:57, joel jaeggli wrote: > There is a point beyond which the network ceases to be a serious > imposition on what you are trying to do. > > When it gets there, it fades into the background as a utility function. I've seen this to be the case when customers are used to buying large capacity, i.e., 10Gbps, 20Gbps, 50Gbps, 120Gbps, e.t.c. Admittedly, these tend to be service providers or super large enterprises, and there is no way they are going to practically ask you to test their 50Gbps delivery - mostly because it's physically onerous, and also because they have some clue about speed tests not being any form of scientific measure. The problem is with the customers that buy orders of magnitude less than, say, 1Gbps. They will be interested in speed tests as a matter of course. We notice that as the purchased capacity goes up, customers tend to be less interested in speed tests. If anything, concern shifts to more important metrics such as packet loss and latency. > The fact that multiple streaming audio / video applications in a > household doesn't have to routinely cheese people off point to the > threshold having been reached for the those applications at least in > fixed networks. One angle of attack is to educate less savvy customers about bandwidth being more about supporting multiple users on the network at the same time all with smiles on their faces, than about it making things go faster. I had to tell a customer, recently, that more bandwidth will help increase application speed up to a certain point. After that, it's about being able to add users without each individual user being disadvantaged. Y'know, a case of 2 highway lanes running at 80km/hr vs. 25 highway lanes running at 80km/hr. > For others it will it still be a while. When that 5GB > software update or a new purchased 25GB game takes 20 minutes to  > deliver that's a delay between intent and action that the user or > service operator might seek to minimize. That's where the CDN's and content operators need to chip in and do their part. The physics is the physics, and while I can (could) install DownThemAll on my Firefox install to accelerate downloads, I don't have those options when waiting for my PS4 to download that 25GB purchase, or my iPhone to download that 5GB update. > Likewise, Latency or Jitter > associated with network resource contention impacts real-time > applications. When the network is sufficiently scaled / well behaved > that these applications can coexist without imposition that stops being > a point of contention. All agreed there. In our market, it's not a lack of backbone resources. It's that the majority of online resources customers are trying to reach are physically too far away. Mark. From eric.kuhnke at gmail.com Thu Jul 19 15:29:15 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 19 Jul 2018 08:29:15 -0700 Subject: Proving Gig Speed In-Reply-To: <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> Message-ID: Mark already knows this, but for the benefit of the North American network operators on the list, **where** in Africa makes a huge difference. Certain submarine cables reach certain coastal cities at very different transport prices, depending on location, what sort of organizational structure of cable it is, age of cable, etc. For example Sierra Leone and Liberia are logically network stubs, suburbs of London, UK. To the best of my knowledge the ISPs and mobile network operators there greatly prefer buying transport capacity to reach London rather than the other direction to Accra and Lagos. I do not know of any SL or LR ISPs which have small POPs with IP edge routers in Accra or Lagos, and definitely not in Cape Town. Whatever circuits exist for voice traffic that go to Lagos are much smaller. On Wed, Jul 18, 2018 at 7:27 AM, Mark Tinka wrote: > > > On 18/Jul/18 16:22, K. Scott Helms wrote: > > > Mark, > > > > I am glad I don't have your challenges :) > > > > What's the Netflix (or other substantial OTT video provider) situation > > for direct peers? It's pretty easy and cheap for North American > > operators to get settlement free peering to Netflix, Amazon, Youtube > > and others but I don't know what that looks like in Africa. > > Peering isn't the problem. Proximity to content is. > > Netflix, Google, Akamai and a few others have presence in Africa > already. So those aren't the problem (although for those currently in > Africa, not all of the services they offer globally are available here - > just a few). > > A lot of user traffic is not video streaming, so that's where a lot of > work is required. In particular, cloud and gaming operators are the ones > causing real pain. > > All the peering in the world doesn't help if the latency is well over > 100ms+. That's what we need to fix. > > Mark. > From mark.tinka at seacom.mu Thu Jul 19 15:34:33 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 17:34:33 +0200 Subject: Proving Gig Speed In-Reply-To: <20180719150655.GA11417@jima.tpb.net> References: <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> <653857941.3208.1531926043595.JavaMail.mhammett@ThunderFuck> <20180719150655.GA11417@jima.tpb.net> Message-ID: <2e8ea6ee-ed2f-71a2-643a-d6fe9e8bad4c@seacom.mu> On 19/Jul/18 17:06, Niels Bakker wrote: >   > > That will happen as soon as it's affordable for them to do so - which > requires an ecosystem of affordable and reliable independent IP > transit/transport and colocation to exist. Agreed, but as experience has shown, those aren't the only considerations they have to make. You'd be amazed how often delays in deployment are about a lack of resources on their side to deploy at all the sites on their agenda. Mark. From mark.tinka at seacom.mu Thu Jul 19 15:40:29 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 17:40:29 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> <1ad38b85-c86b-8e1e-7207-e406aa266df2@studio442.com.au> <79bbfd6a-11b7-5789-d89a-8751f116e9a4@seacom.mu> Message-ID: <075f4fb8-f738-9167-2748-6335ca375629@seacom.mu> On 19/Jul/18 17:08, Tei wrote: > tl:dr: the web is evolving into a network of applications, instead of > documents. Documents can't "break" easily. Programs may break > completelly even to tiny changes. Maybe getting webmasters on board of > biasing in favor of documents could do us all a favour. Yes, that would be great, but I recall there was someone asking about deploying a WISP in rural America several weeks ago and how to deal with these "busy" web sites of 2018. And your suggestion was one of the proposals NANOG suggested to the OP. While it'd be good for webmasters to optimize the content they create, I appreciate that as the Internet continues to develop, web sites and content will only get a lot more dynamic and complicated, to appeal to the human desire for "pretty nice shiny things". Certainly, optimizations for mobile devices is better than for laptops/desktops for obvious reasons, but as those mobile devices keep adding power, it will slowly release the constraints webmasters have when developing for said platforms. So in terms of effort expended, I'd be losing if I tried to get content creators to simplify their content. Rather, I'll hunt down opportunities that encourage content to move closer to our markets. Mark. From job at ntt.net Thu Jul 19 16:19:33 2018 From: job at ntt.net (Job Snijders) Date: Thu, 19 Jul 2018 16:19:33 +0000 Subject: Quickstart Guide to IRR/RPSL In-Reply-To: References: Message-ID: <20180719161933.GO42041@vurt.meerval.net> Dear Kenneth, On Wed, Jul 18, 2018 at 09:38:23PM -0700, Kenneth Finnegan wrote: > As part of setting up a new Internet Exchange in Fremont, California, > we've been investigating prefix filtering on the route servers based > on IRR. Excellent, have you also considered using ARIN-WHOIS and RPKI as data sources for your route servers? An excellent tool to generate route server configurations is 'arouteserver' http://arouteserver.readthedocs.io/ > Unfortunately, we were not satisfied with any of the existing > documentation available online as far as taking a network engineer > from "zero" to "just enough IRR to post our prefixes for filtering". > Lacking this documentation, it was rather unreasonable for us to turn > on filtering and drop most of our peer's prefixes without a relevant > whitepaper to point them to to get started. > > So, we wrote our own guide: > http://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html This is excellent reasoning, there indeed is a lack of easy to consume information. > I thought others on this list would find our whitepaper interesting, > and/or have valuable feedback based on their experience applying IRR > themselves. 1/ About the "Selecting an IRR Database" section, the best current practise is to use the IRR that your RIR provides you. In other words: register ARIN managed prefixes in the ARIN IRR, and RIPE managed prefixes in the RIPE IRR. Only the RIRs are in a position to attest that it was the owner of a prefix that created the route(6): object. Databases such as RADB, NTTCOM, ALTDB are so-called "third party" databases and at this moment in time have no way to validate anything. I've highlighted the differences between the various sources of data in this talk at RIPE76 https://ripe76.ripe.net/archives/video/22 Also, in most regions people are paying their RIR money, this money pays for IRR services so I'd recommend to use those. 2/ I'd delete the "Step 2: Document Your Autonomous System’s Routing Policy" step, nobody uses this. 3/ Step 3 is excellent, everybody who generates filters uses AS-SETs. I like how detail was given to the "AS15562:AS-SNIJDERS" format to ensure unique names. Good work. 4/ Step 4 can be extended to promote creating RPKI ROAs (in addition to) the route objects. Anyone can create a route: object in ALTDB, but only the owner of a prefix can create a RPKI ROA. As such the RPKI ROAs are a far more valuable source of data to filter generators. In summary, great work! Can I update http://peering.exposed/ and add FCIX with a 'yes' to both secure route servers & BCP 214? :-) Kind regards, Job From James at arenalgroup.co Thu Jul 19 18:14:03 2018 From: James at arenalgroup.co (James Breeden) Date: Thu, 19 Jul 2018 18:14:03 +0000 Subject: Centurylink/Level3 Plans Message-ID: Does anyone know what the plans or even watercooler chat is concerning Centurylink (AS209) and Level3 (AS3356) integration, direct peering, or continuing separation? We are looking at a IP Transit deal involving one or both networks and while I'd love to have transit routes from both, I don't want to design to be shot in the foot later on either if they are talking about soon-to-be integrated or something. TIA... James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co From joe at breathe-underwater.com Thu Jul 19 18:19:39 2018 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Thu, 19 Jul 2018 13:19:39 -0500 Subject: Centurylink/Level3 Plans In-Reply-To: References: Message-ID: So the reps/SEs/Techs that I have spoken with are saying they are going to keep them separate. In my case I am tw customer and was worried about their network when L3 took them over. I was even more worried when Centurylink then took over L3 that I was going to lose one of the networks. However I gotten assurances from everyone there that they are going to maintain all 3 networks as separate for the foreseeable future. On July 19, 2018 at 11:15:39 AM, James Breeden (james at arenalgroup.co) wrote: Does anyone know what the plans or even watercooler chat is concerning Centurylink (AS209) and Level3 (AS3356) integration, direct peering, or continuing separation? We are looking at a IP Transit deal involving one or both networks and while I'd love to have transit routes from both, I don't want to design to be shot in the foot later on either if they are talking about soon-to-be integrated or something. TIA... James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co< http://www.arenalgroup.co> From job at ntt.net Thu Jul 19 18:30:17 2018 From: job at ntt.net (Job Snijders) Date: Thu, 19 Jul 2018 18:30:17 +0000 Subject: Quickstart Guide to IRR/RPSL In-Reply-To: References: <20180719161933.GO42041@vurt.meerval.net> Message-ID: <20180719183017.GS42041@vurt.meerval.net> On Thu, Jul 19, 2018 at 11:19:12AM -0700, Kenneth Finnegan wrote: > As for ARIN-WHOIS, I think I had gotten confused whether it was > additive or exclusive of IRR objects for allowing prefixes. Indeed, in arouteserver it is 'additive'. Documentation from ARIN is here: https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters-of-authority/ > > 2/ I'd delete the "Step 2: Document Your Autonomous System’s Routing > > Policy" step, nobody uses this. > > Is the expectation that the only source of a network's as-set is > PeeringDB then? Yes, or the IX/transit operator can ask what AS-SET to use during the turn-up of the circuit. > I have reason to believe there are IRR consumers who do parse > export/mp-export statements. I think at least documenting an mp-export > to AS-ANY policy is reasonable, but I'll reconsider that. Globally I think there are only 2 or 3 organisations left that parse this information. The vast majority either autodiscovers via peeringdb, or just explicitly asks for it during provisioning. > > Can I update http://peering.exposed/ and add FCIX with a 'yes' to > > both secure route servers & BCP 214? :-) > > Please do. :-) $0 for 10G, N/A for 100G. Excellent, done. > The next IRR puzzle for us is converting a CSV of member ASNs to their > as-sets to generate the requested AS33495:AS-MEMBERS as-set so our > members can also generate filters against the route servers. It seems > like there's probably a tool like bgpq3 that can turn a list of ASNs > into an as-set of their exports, but I'm not seeing it. bgpq3 can only go from IRR sources (using the RADB IRRd protocol) to outputs such as Cisco, Juniper, BIRD, JSON - not the other way around. > Anyone have something at hand, or am I breaking out the python soon? Go python Kind regards, Job From bruns at 2mbit.com Thu Jul 19 18:36:04 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 19 Jul 2018 12:36:04 -0600 Subject: Centurylink/Level3 Plans In-Reply-To: References: Message-ID: On 7/19/2018 12:19 PM, Joseph Jenkins wrote: > So the reps/SEs/Techs that I have spoken with are saying they are going to > keep them separate. In my case I am tw customer and was worried about their > network when L3 took them over. I was even more worried when Centurylink > then took over L3 that I was going to lose one of the networks. However I > gotten assurances from everyone there that they are going to maintain all 3 > networks as separate for the foreseeable future. > They were also forced to divest some of their L3 assets in various places - like here in Boise where they sold the L3 part to Syringa Networks. We've got fiber and BGP from CL in Boise, and our paths still seem to only take CL transit and don't happen to hit L3 unless its a specific customer on L3. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From mehmet at akcin.net Thu Jul 19 18:48:51 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 19 Jul 2018 20:48:51 +0200 Subject: Centurylink/Level3 Plans In-Reply-To: References: Message-ID: Remember Global Crossing & Level3 merger? Perhaps look for an option that involves neither There are few good options out there! Mehmet On Thu, Jul 19, 2018 at 8:14 PM James Breeden wrote: > Does anyone know what the plans or even watercooler chat is concerning > Centurylink (AS209) and Level3 (AS3356) integration, direct peering, or > continuing separation? > > We are looking at a IP Transit deal involving one or both networks and > while I'd love to have transit routes from both, I don't want to design to > be shot in the foot later on either if they are talking about soon-to-be > integrated or something. > > TIA... > > James W. Breeden > Managing Partner > > [logo_transparent_background] > Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media > PO Box 1063 | Smithville, TX 78957 > Email: james at arenalgroup.co | office > 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co< > http://www.arenalgroup.co> > > From michel.py at tsisemi.com Thu Jul 19 19:47:40 2018 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 19 Jul 2018 19:47:40 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <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> Message-ID: > Mark Tinka wrote : > but I want to be cautious about encouraging a parallel stream that slows down the deployment of RPKI. I understand that; if there is an easier way to do RPKI, people are going to use it instead of the right way. However, I think that the blacklist targets a different kind of customer : the end user. We want the enterprise to certify their prefixes with RPKI and put pressure on their upstreams to deploy it, the more noise we make the better. What I want is my upstreams to give me a clean routing tables without invalids, but it does not happen so in the meantime I'm trying to do what I can with my limited resources. > We generally use typical service provider routers to deliver services. So I'm not sure whether the 3900's you run support it or not. The picture from the enterprise is quite different. There is a lot of stuff out there that does not get upgraded, that is not even under a maintenance contract to get the new software, or that is on EOL/EOS hardware. 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 surfer at mauigateway.com Thu Jul 19 20:43:51 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 19 Jul 2018 13:43:51 -0700 Subject: Proving Gig Speed Message-ID: <20180719134351.8AB434DA@m0117565.ppops.net> --- mark.tinka at seacom.mu wrote: From: Mark Tinka On 18/Jul/18 16:58, K. Scott Helms wrote: > ... What's really interesting is how gaming is changing > and within the next few years I do expect a lot of games > to move into the remote rendering world. You need to > have <=30 ms of latency to sustain 1080p gaming and > obviously jitter and packet loss are also problematic. > The traffic is also pretty impressive with spikes of > over 50 mbps down and sustained averages over 21 mbps. And what we need is for them to ensure all these remote rendering farms are evenly distributed around the world to ensure that 30ms peak latency is achievable. ----------------------------------------------- I know we're talking about Africa and other less well connected countries, but good luck with that in the Pacific, which covers about 1/3 of the planet. https://oceanexplorer.noaa.gov/facts/pacific-size.html scott From mark.tinka at seacom.mu Thu Jul 19 20:50:22 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 22:50:22 +0200 Subject: Proving Gig Speed In-Reply-To: <20180719134351.8AB434DA@m0117565.ppops.net> References: <20180719134351.8AB434DA@m0117565.ppops.net> Message-ID: <8c3a6167-cf2e-ec14-8ea0-92d474eec994@seacom.mu> On 19/Jul/18 22:43, Scott Weeks wrote: > > I know we're talking about Africa and other less well > connected countries, but good luck with that in the > Pacific, which covers about 1/3 of the planet. > > https://oceanexplorer.noaa.gov/facts/pacific-size.html Yeah, things and people tend to work better if hosted on land... Mark. From mark.tinka at seacom.mu Thu Jul 19 21:04:03 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Jul 2018 23:04:03 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <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> Message-ID: <8b3764d9-da8d-ea6c-e5a1-28133eb5d0e7@seacom.mu> On 19/Jul/18 21:47, Michel Py wrote: > I understand that; if there is an easier way to do RPKI, people are going to use it instead of the right way. However, I think that the blacklist targets a different kind of customer : the end user. We want the enterprise to certify their prefixes with RPKI and put pressure on their upstreams to deploy it, the more noise we make the better. What I want is my upstreams to give me a clean routing tables without invalids, but it does not happen so in the meantime I'm trying to do what I can with my limited resources. The script that Job wrote is neat, but I'm sure neither he nor I would run it in production in lieu of the actual RPKI infrastructure. Even though you're my competitor, I'd caution against this. But, your network, your rules. > The picture from the enterprise is quite different. There is a lot of stuff out there that does not get upgraded, that is not even under a maintenance contract to get the new software, or that is on EOL/EOS hardware. So don't re-invent this wheel; that is what Delegated RPKI is for. Several RPKI tools out there support CA functionality, as much as they support the RP side as well. Let's not create something totally out of scope to mimic specs and tools already exist. If you really want to participate in the RPKI, then you seriously need to consider supporting software that implements it. If not, use your ISP's CA tools to sign your IP addresses, and then rely on them to have clean FIB's when you use them for transit. RPSL got complicated enough with all its good intentions, and we know how that turned out. Let's not muddy the RPKI waters. Mark. From job at ntt.net Thu Jul 19 21:07:13 2018 From: job at ntt.net (Job Snijders) Date: Thu, 19 Jul 2018 21:07:13 +0000 Subject: NTT now treats RPKI ROAs as IRR route(6)-objects Message-ID: <20180719210713.GC42041@vurt.meerval.net> Dear NANOG, [ TL:DR - From now on, NTT / AS 2914 allows customers to either register their announcements in the IRR, or as RPKI ROAs. This is a convenience service for relevant regions of the world where IRR is not the norm but RPKI is commonly available. Previously NTT only accepted IRR and ARIN-WHOIS. I hope competitors and partners will use this approach too! ] As most of you know, the Resource Public Key Infrastructure (RPKI) is a modern reimagination of the good ole' IRR system we have come to love and hate. The main advantage of the RPKI is that a consumer of the data can cryptographically verify whether it was the actual owner of the IP prefix that created a so-called "RPKI ROA". (more reading: https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure) Given that RPKI ROAs are somewhat equivalent to IRR route-objects, but more reliable in terms of authoritativeness, NTT now has an automated nightly process that converts RPKI information into IRR format so that our toolchain can consume the data as if it were just another IRR source. Using RPKI ROAs as if they are IRR route(6)-objects is a transitional step towards increased security in the routing ecosystem. We are not the first to explore this method (see post-scriptum), but I think we are the first to republish elements from RPKI ROAs via a publicly accessible IRRd instance queryable with the RADB IRRd protocol. This means that anyone that points their bgpq3 or peval programs at rr.ntt.net can leverage this method without having to update anything else in the pipeline. An example can be inspected here: job at eng0 ~$ whois -h rr.ntt.net 193.0.6.139 [Querying rr.ntt.net] [rr.ntt.net] route: 193.0.0.0/21 descr: RIPE-NCC origin: AS3333 mnt-by: RIPE-NCC-MNT changed: unread at ripe.net 20000101 source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** route: 193.0.0.0/21 descr: RPKI ROA for 193.0.0.0/21 remarks: This route object represents routing data retrieved from the RPKI remarks: The original data can be found here: https://rpki.gin.ntt.net/r/AS3333/193.0.0.0/21 remarks: This route object is the result of an automated RPKI-to-IRR conversion process. remarks: maxLength 21 origin: AS3333 mnt-by: MAINT-JOB changed: job at ntt.net 20180718 source: RPKI # Trust Anchor: RIPE NCC RPKI Root job at eng0 ~$ The first object is an actual IRR "route:" object from the RIPE NCC operated IRR, the second object is a representation of the RPKI ROA in RPSL format published via rr.ntt.net. In general we can state that RPKI data is very good quality data, however please keep in mind that it may not be /correct/ data. In this context "Good Quality" means that it cannot easily be forged or tampered with by adversaries (but of course that doesn't protect the legitimate owner against making misconfigurations). Just like with IRR route(6)-objects, owners may input the wrong origin ASN in this type of object or configure the wrong MaxLength. NTT operates a "RPKI Cache Validator" at https://rpki.gin.ntt.net/ Everyone is free to inspect and click around in this webinterface. Instead of https://rpki.gin.ntt.net/, there also is a command line interface available via BGPMon's whois service: job at vurt ~$ whois -h whois.bgpmon.com 193.0.0.0/21 % This is the BGPmon.net whois Service % You can use this whois gateway to retrieve information % about an IP adress or prefix % We support both IPv4 and IPv6 address. % % For more information visit: % https://portal.bgpmon.net/bgpmonapi.php Prefix: 193.0.0.0/21 Prefix description: RIPE-NCC Country code: NL Origin AS: 3333 Origin AS Name: Reseaux IP Europeens Network Coordination Centre (RIPE NCC) RPKI status: ROA validation successful First seen: 2011-10-19 Last seen: 2018-07-19 Seen by #peers: 77 Notice in the above output the "ROA validation successful". Nota bene: the fact that NTT uses RPKI ROA information in the prefix filter generation process - does _not_ mean that NTT does "RPKI Origin Validation" for BGP updates (yet). RPKI Origin Validation is an additional security layer that we hope to deploy in the not too distant future. Using RPKI ROAs in this way is an important step forward in this process. Kind regards, Job Snijders Post scriptum on prior work: Dragon Research Labs implemented the idea in 2015: https://github.com/dragonresearch/rpki.net/blob/master/potpourri/roa-to-irr.py RIPE NCC's RPKI Validator added RPSL export functionality in 2015: https://mailman.nanog.org/pipermail/nanog/2015-May/075185.html Arouteserver added native support for this method in October 2017. https://github.com/pierky/arouteserver/issues/19 From surfer at mauigateway.com Thu Jul 19 22:07:36 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 19 Jul 2018 15:07:36 -0700 Subject: Proving Gig Speed Message-ID: <20180719150736.8AB43C4C@m0117565.ppops.net> --- mark.tinka at seacom.mu wrote: From: Mark Tinka On 19/Jul/18 22:43, Scott Weeks wrote: > I know we're talking about Africa and other less well > connected countries, but good luck with that in the > Pacific, which covers about 1/3 of the planet. > > https://oceanexplorer.noaa.gov/facts/pacific-size.html Yeah, things and people tend to work better if hosted on land... ----------------------------------------------------- I believe I'm on land here... ;) And there're a lot of islands with lots of people out here. 1/3 of the planet and all. :) scott From surfer at mauigateway.com Thu Jul 19 22:13:09 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 19 Jul 2018 15:13:09 -0700 Subject: Proving Gig Speed Message-ID: <20180719151309.8AB43C3F@m0117565.ppops.net> --- mark.tinka at seacom.mu wrote: From: Mark Tinka On 19/Jul/18 22:43, Scott Weeks wrote: > I know we're talking about Africa and other less well > connected countries, but good luck with that in the > Pacific, which covers about 1/3 of the planet. > > https://oceanexplorer.noaa.gov/facts/pacific-size.html Yeah, things and people tend to work better if hosted on land... ----------------------------------------------------- I believe I'm on land here... ;) And there're a lot of islands with lots of people out here. 1/3 of the planet and all. :) ------------------------------------------------------ What I meant to say is a lot of folks get connectivity through satellite. 500msec plus and jitter to spare. Further it's expensive and all the 'busy' sites cost a lot of money to download the stuff folks on this list don't blink an eye at and you can't turn it off. I believe satellite coverage serves a lot of the planet's population. scott From kennethfinnegan2007 at gmail.com Thu Jul 19 18:19:12 2018 From: kennethfinnegan2007 at gmail.com (Kenneth Finnegan) Date: Thu, 19 Jul 2018 11:19:12 -0700 Subject: Quickstart Guide to IRR/RPSL In-Reply-To: <20180719161933.GO42041@vurt.meerval.net> References: <20180719161933.GO42041@vurt.meerval.net> Message-ID: On Thu, Jul 19, 2018 at 9:19 AM, Job Snijders wrote: > Excellent, have you also considered using ARIN-WHOIS and RPKI as data > sources for your route servers? An excellent tool to generate route > server configurations is 'arouteserver' http://arouteserver.readthedocs.io/ After the volume of time and level of frustration it took just to get a handle on IRR, RPKI has been placed very low on our priority list. It's still on our list, but we've got plenty of other work to do before I figure out the implications of turning on RPKI, and I'm not willing to turn on a prefix authentication that I'm not able to walk my members through a way to correct. As for ARIN-WHOIS, I think I had gotten confused whether it was additive or exclusive of IRR objects for allowing prefixes. We have a lot of members running prefixes off of letters of authorization, so rejecting routes based on ARIN-WHOIS wasn't attractive, but that documentation you linked to reads more like it'll accept prefixes in addition to what gets accepted based on IRR alone. We will experiment with it. And yes, arouteserver is an excellent tool; we're currently using it, so enabling RPKI and ARIN-WHOIS will be relatively easy once we're willing to qualify it and roll it out. > 1/ About the "Selecting an IRR Database" section, the best current > practise is to use the IRR that your RIR provides you. In other words: > register ARIN managed prefixes in the ARIN IRR, and RIPE managed > prefixes in the RIPE IRR. Only the RIRs are in a position to attest that > it was the owner of a prefix that created the route(6): object. This is true. I wanted to write a more evergreen guide than walking through the current implementation of a single region's RIR, since there's several of them with their own unique work-flows and I get the sense that several of them are currently in flux. If we could ultimately replace this whitepaper with links to five equivalent documents from the RIRs, so be it. > Databases such as RADB, NTTCOM, ALTDB are so-called "third party" > databases and at this moment in time have no way to validate anything. > I've highlighted the differences between the various sources of data in > this talk at RIPE76 https://ripe76.ripe.net/archives/video/22 I did eventually find that talk useful once I had climbed high enough on the learning curve to really understand what you were talking about. Thanks. > 2/ I'd delete the "Step 2: Document Your Autonomous System’s Routing > Policy" step, nobody uses this. Is the expectation that the only source of a network's as-set is PeeringDB then? I have reason to believe there are IRR consumers who do parse export/mp-export statements. I think at least documenting an mp-export to AS-ANY policy is reasonable, but I'll reconsider that. > 4/ Step 4 can be extended to promote creating RPKI ROAs (in addition to) > the route objects. Anyone can create a route: object in ALTDB, but only > the owner of a prefix can create a RPKI ROA. As such the RPKI ROAs are a > far more valuable source of data to filter generators. Yes. Someone should write a "zero to RPKI" tutorial. After this whitepaper literally took sitting down and reading the RFCs for something that people bemoan isn't used by every network, I'm not excited to try and get the same handle on RPKI to be able to speak with authority on how to set it up. > Can I update http://peering.exposed/ and add FCIX with a 'yes' to both > secure route servers & BCP 214? :-) Please do. :-) $0 for 10G, N/A for 100G. The next IRR puzzle for us is converting a CSV of member ASNs to their as-sets to generate the requested AS33495:AS-MEMBERS as-set so our members can also generate filters against the route servers. It seems like there's probably a tool like bgpq3 that can turn a list of ASNs into an as-set of their exports, but I'm not seeing it. Anyone have something at hand, or am I breaking out the python soon? -- Kenneth Finnegan http://blog.thelifeofkenneth.com/ From Joshua.Vijsma at true.nl Thu Jul 19 20:47:56 2018 From: Joshua.Vijsma at true.nl (Joshua Vijsma / True) Date: Thu, 19 Jul 2018 20:47:56 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: References: Message-ID: Hi all, Just wanted to share our (AS15703, True B.V.) experience as a hosting provider with enabling RPKI invalid filtering (invalid == reject). We've secured (most of) our routes since 2014 with ROAs but last Tuesday we have deployed filters which reject RPKI invalid routes. We have had two tickets regarding users in one certain RPKI invalid prefix not being able to reach our network, but those people quickly understood that this wasn't our problem but a problem with their hosting partner. They took it up with their hosting partner and it was fixed within a day. Overal, I would certainly recommend filtering RPKI invalids (and create ROAs for your prefixes!!) to prevent hijacks. -- Met vriendelijke groet / Best regards, Joshua Vijsma > On 13 Jul 2018, at 14:00, nanog-request at nanog.org wrote: > > > ------------------------------ > > Message: 2 > Date: Thu, 12 Jul 2018 17:50:29 +0000 > From: Job Snijders > To: nanog at nanog.org > Subject: deploying RPKI based Origin Validation > Message-ID: <20180712175029.GC3037 at vurt.meerval.net> > Content-Type: text/plain; charset=us-ascii > > Hi all, > > I wanted to share with you that a ton of activity is taking place in the > Dutch networker community to deploy RPKI based BGP Origin Validation. > The mantra is "invalid == reject" on all EBGP sessions. > > What's of note here is that we're now seeing the first commercial ISPs > doing Origin Validation. This is a significant step forward compared to > what we observed so far (it seemed OV was mostly limited to academic > institutions & toy networks). But six months ago Amsio (https://www.amsio.com/en/) > made the jump, and today Fusix deployed (https://fusix.nl/deploying-rpki/). > > We've also seen an uptake of Origin Validation at Internet Exchange > route servers: AMS-IX and FranceIX have already deployed. I've read that > RPKI OV is under consideration at a number of other exchanges. > > Other cool news is that Cloudflare launched a Certificate Transparency > initiative to help keep everyone honest. Announcement at: > https://twitter.com/grittygrease/status/1017224762542587907 > Certificate Transparency is a fascinating tool, really a necessity to > build confidence in any PKI systems. > > Anyone here working to deploy RPKI based Origin Validation in their > network and reject invalid announcements? Anything of note to share? > > Kind regards, > > Job From mark.tinka at seacom.mu Fri Jul 20 07:29:40 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 20 Jul 2018 09:29:40 +0200 Subject: NTT now treats RPKI ROAs as IRR route(6)-objects In-Reply-To: <20180719210713.GC42041@vurt.meerval.net> References: <20180719210713.GC42041@vurt.meerval.net> Message-ID: <66e6cb51-5df8-3cad-df08-6c2389cc9386@seacom.mu> On 19/Jul/18 23:07, Job Snijders wrote: > Dear NANOG, > > [ TL:DR - From now on, NTT / AS 2914 allows customers to either register > their announcements in the IRR, or as RPKI ROAs. This is a convenience > service for relevant regions of the world where IRR is not the norm but > RPKI is commonly available. Previously NTT only accepted IRR and > ARIN-WHOIS. I hope competitors and partners will use this approach too! ] One step closer! Well done, Job and team! Mark. From mark.tinka at seacom.mu Fri Jul 20 07:37:19 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 20 Jul 2018 09:37:19 +0200 Subject: Proving Gig Speed In-Reply-To: <20180719151309.8AB43C3F@m0117565.ppops.net> References: <20180719151309.8AB43C3F@m0117565.ppops.net> Message-ID: <24d19b97-084b-c115-ef0b-12fa07fcf3dd@seacom.mu> On 20/Jul/18 00:13, Scott Weeks wrote: > What I meant to say is a lot of folks get connectivity > through satellite. 500msec plus and jitter to spare. > > Further it's expensive and all the 'busy' sites cost a > lot of money to download the stuff folks on this list > don't blink an eye at and you can't turn it off. I > believe satellite coverage serves a lot of the planet's > population. Agreed. Having ran a satellite-based ISP longer than I have my current fibre-based one, I can safely say that with satellite, speed tests generally tend to be the least of you or your customer's worries. Just simply having a working transmission to/from the bird, and looking for all the cash in the world to service that satellite space segment, is enough of a drama. Would having local CDN caches help satellite-based providers? Sure, particularly in this day & age where classic caches (Squid et al) have nothing against the type of content that's out there. There is a direct relationship between the existence of (submarine) fibre into a country/region, the availability of infrastructure, the eyeball density, the telecoms regulatory regime, and the desire for content operators and CDN's to invest. Even in Africa, parts that now have (submarine) fibre lack the rest of these elements, and are suffering the disinterest from those that create and distribute the content. Mark. From mark.tinka at seacom.mu Fri Jul 20 07:45:21 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 20 Jul 2018 09:45:21 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <02bd2796-d2d0-d919-e948-c27b1bfc7c3c@seacom.mu> <06a4eea5-7246-6987-a972-9ba5f5c40686@seacom.mu> Message-ID: <5a78cb42-bf2c-d83a-6bef-c5e9398acdfe@seacom.mu> On 19/Jul/18 17:29, Eric Kuhnke wrote: > Mark already knows this, but for the benefit of the North American network > operators on the list, **where** in Africa makes a huge difference. Certain > submarine cables reach certain coastal cities at very different transport > prices, depending on location, what sort of organizational structure of > cable it is, age of cable, etc. > > For example Sierra Leone and Liberia are logically network stubs, suburbs > of London, UK. To the best of my knowledge the ISPs and mobile network > operators there greatly prefer buying transport capacity to reach London > rather than the other direction to Accra and Lagos. I do not know of any SL > or LR ISPs which have small POPs with IP edge routers in Accra or Lagos, > and definitely not in Cape Town. Whatever circuits exist for voice traffic > that go to Lagos are much smaller. You're right, Eric. Unfortunately, West Africa, at the moment, even with the number of submarine cables available in the region, is lagging behind Eastern & Southern Africa, particularly since 2009. There are a number of reasons for this, but fundamentally, there is a lot more progressiveness around openness and diversification of infrastructure deployment, operation and regional regulatory synergies that the East & South have done better than the West. Which is not to say that there isn't work going on in West Africa... there certainly is. It's just taking a little longer than it ought to. In my region, for example (which covers East & South), we are working extra hard to de-legitimise Europe as a clearing house for our traffic, and also, as a source for off-continent traffic. We are fortunate to have a number of global actors participating in this transition, and with it, a whole eco system is coming alive. West Africa need to consider their own methods of attaining this goal, so they do not look like suburbs of London from a connectivity standpoint, sooner rather than later. To their benefit, there a couple of things going on that may very well accelerate this. Mark. From cscora at apnic.net Fri Jul 20 18:03:09 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Jul 2018 04:03:09 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180720180309.E5AD1C450F@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 21 Jul, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 706689 Prefixes after maximum aggregation (per Origin AS): 271490 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 339522 Total ASes present in the Internet Routing Table: 61277 Prefixes per ASN: 11.53 Origin-only ASes present in the Internet Routing Table: 52941 Origin ASes announcing only one prefix: 23079 Transit ASes present in the Internet Routing Table: 8336 Transit-only ASes present in the Internet Routing Table: 278 Average AS path length visible in the Internet Routing Table: 4.1 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 56 Number of instances of unregistered ASNs: 59 Number of 32-bit ASNs allocated by the RIRs: 23343 Number of 32-bit ASNs visible in the Routing Table: 18822 Prefixes from 32-bit ASNs in the Routing Table: 78370 Number of bogon 32-bit ASNs visible in the Routing Table: 27 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 289 Number of addresses announced to Internet: 2856751939 Equivalent to 170 /8s, 70 /16s and 147 /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: 235774 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 192804 Total APNIC prefixes after maximum aggregation: 54910 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 191212 Unique aggregates announced from the APNIC address blocks: 78530 APNIC Region origin ASes present in the Internet Routing Table: 8959 APNIC Prefixes per ASN: 21.34 APNIC Region origin ASes announcing only one prefix: 2522 APNIC Region transit ASes present in the Internet Routing Table: 1335 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3919 Number of APNIC addresses announced to Internet: 767822850 Equivalent to 45 /8s, 196 /16s and 12 /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: 209991 Total ARIN prefixes after maximum aggregation: 99923 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 210273 Unique aggregates announced from the ARIN address blocks: 99476 ARIN Region origin ASes present in the Internet Routing Table: 18190 ARIN Prefixes per ASN: 11.56 ARIN Region origin ASes announcing only one prefix: 6725 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: 2386 Number of ARIN addresses announced to Internet: 1102400672 Equivalent to 65 /8s, 181 /16s and 76 /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: 193597 Total RIPE prefixes after maximum aggregation: 92449 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 189728 Unique aggregates announced from the RIPE address blocks: 112597 RIPE Region origin ASes present in the Internet Routing Table: 25313 RIPE Prefixes per ASN: 7.50 RIPE Region origin ASes announcing only one prefix: 11414 RIPE Region transit ASes present in the Internet Routing Table: 3490 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: 7187 Number of RIPE addresses announced to Internet: 714018432 Equivalent to 42 /8s, 143 /16s and 14 /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: 91068 Total LACNIC prefixes after maximum aggregation: 20101 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 92487 Unique aggregates announced from the LACNIC address blocks: 40809 LACNIC Region origin ASes present in the Internet Routing Table: 7333 LACNIC Prefixes per ASN: 12.61 LACNIC Region origin ASes announcing only one prefix: 2029 LACNIC Region transit ASes present in the Internet Routing Table: 1382 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4880 Number of LACNIC addresses announced to Internet: 172083488 Equivalent to 10 /8s, 65 /16s and 201 /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: 19172 Total AfriNIC prefixes after maximum aggregation: 4062 AfriNIC Deaggregation factor: 4.72 Prefixes being announced from the AfriNIC address blocks: 22700 Unique aggregates announced from the AfriNIC address blocks: 7856 AfriNIC Region origin ASes present in the Internet Routing Table: 1175 AfriNIC Prefixes per ASN: 19.32 AfriNIC Region origin ASes announcing only one prefix: 389 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: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 450 Number of AfriNIC addresses announced to Internet: 99974400 Equivalent to 5 /8s, 245 /16s and 125 /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 4690 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4348 467 459 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2948 1153 83 VIETEL-AS-AP Viettel Group, VN 4766 2853 11130 764 KIXS-AS-KR Korea Telecom, KR 9829 2813 1497 543 BSNL-NIB National Internet Backbone, IN 45899 2658 1633 114 VNPT-AS-VN VNPT Corp, VN 9394 2542 4907 31 CTTNET China TieTong Telecommunications 17974 2260 930 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2236 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2115 417 205 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 3431 1324 84 SHAW - Shaw Communications Inc., CA 22773 3271 2968 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2550 247 462 CABLEONE - CABLE ONE, INC., US 16509 2248 4727 753 AMAZON-02 - Amazon.com, Inc., US 18566 2168 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2114 2591 478 CHARTER-NET-HKY-NC - Charter Communicat 30036 2004 343 154 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1994 5070 605 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16625 1966 988 1404 AKAMAI-AS - Akamai Technologies, Inc., 7018 1751 20201 1270 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 4543 1609 122 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 20940 2547 623 1880 AKAMAI-ASN1, US 8551 2536 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2014 1877 708 ROSTELECOM-AS, RU 34984 2009 335 499 TELLCOM-AS, TR 9121 1879 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 5007 3299 589 Uninet S.A. de C.V., MX 10620 3560 541 256 Telmex Colombia S.A., CO 11830 2655 369 78 Instituto Costarricense de Electricidad 6503 1669 443 62 Axtel, S.A.B. de C.V., MX 7303 1507 1026 188 Telecom Argentina S.A., AR 28573 1035 2248 184 CLARO S.A., BR 3816 1023 508 129 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 936 377 31 Telefonica del Peru S.A.A., PE 11172 929 127 86 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 884 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 744 1411 40 ETISALAT-MISR, EG 8452 635 1730 18 TE-AS TE-AS, EG 24835 635 818 18 RAYA-AS, EG 37492 472 470 57 ORANGE-, TN 29571 457 68 11 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 378 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 5007 3299 589 Uninet S.A. de C.V., MX 4538 4690 4192 74 ERX-CERNET-BKB China Education and Rese 12479 4543 1609 122 UNI2-AS, ES 7545 4348 467 459 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3560 541 256 Telmex Colombia S.A., CO 6327 3431 1324 84 SHAW - Shaw Communications Inc., CA 22773 3271 2968 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2948 1153 83 VIETEL-AS-AP Viettel Group, VN 4766 2853 11130 764 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 4690 4616 ERX-CERNET-BKB China Education and Research Net 12479 4543 4421 UNI2-AS, ES 7545 4348 3889 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3431 3347 SHAW - Shaw Communications Inc., CA 10620 3560 3304 Telmex Colombia S.A., CO 22773 3271 3123 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2948 2865 VIETEL-AS-AP Viettel Group, VN 11830 2655 2577 Instituto Costarricense de Electricidad y Telec 45899 2658 2544 VNPT-AS-VN VNPT Corp, 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 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 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 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:1095 /15:1894 /16:13348 /17:7939 /18:13760 /19:25331 /20:39376 /21:45625 /22:87778 /23:71260 /24:396097 /25:802 /26:607 /27:624 /28:35 /29:20 /30:19 /31:6 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3291 4543 UNI2-AS, ES 6327 3217 3431 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2535 3271 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2168 MEGAPATH5-US - MegaPath Corporation, US 11830 2004 2655 Instituto Costarricense de Electricidad y Telec 8551 1998 2536 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1972 2550 CABLEONE - CABLE ONE, INC., US 30036 1756 2004 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1613 3560 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:1615 2:834 4:18 5:2854 6:40 7:1 8:1125 12:1869 13:206 14:1765 15:29 16:3 17:188 18:54 20:50 23:2460 24:2224 25:2 27:2475 31:2041 32:92 35:27 36:508 37:2821 38:1482 39:248 40:121 41:3152 42:690 43:1959 44:121 45:5012 46:3094 47:203 49:1332 50:1056 51:317 52:1070 54:372 55:4 56:12 57:39 58:1618 59:993 60:401 61:2102 62:1876 63:1790 64:5026 65:2196 66:4673 67:2423 68:1170 69:3266 70:1157 71:580 72:2137 74:2704 75:422 76:459 77:1545 78:1712 79:1817 80:1535 81:1384 82:1075 83:790 84:1077 85:2012 86:561 87:1351 88:929 89:2350 90:216 91:6433 92:1251 93:2383 94:2395 95:2917 96:781 97:359 98:935 99:133 100:85 101:1231 102:146 103:18174 104:3567 105:213 106:738 107:1789 108:694 109:3180 110:1624 111:1773 112:1309 113:1292 114:1133 115:1660 116:1631 117:1763 118:2209 119:1658 120:1003 121:1063 122:2462 123:1757 124:1448 125:1912 128:1082 129:674 130:489 131:1636 132:697 133:195 134:1020 135:225 136:502 137:651 138:1942 139:661 140:468 141:730 142:803 143:1022 144:801 145:486 146:1197 147:725 148:1644 149:756 150:749 151:1096 152:794 153:320 154:1429 155:789 156:1136 157:799 158:654 159:1779 160:1262 161:785 162:2574 163:604 164:1071 165:1521 166:449 167:1302 168:3113 169:821 170:3805 171:488 172:994 173:1983 174:905 175:769 176:1994 177:4067 178:2540 179:1235 180:2169 181:2358 182:2405 183:1238 184:1034 185:13807 186:3564 187:2439 188:2843 189:2045 190:8131 191:1309 192:9789 193:6062 194:4898 195:3977 196:2643 197:1588 198:5554 199:5906 200:7312 201:4988 202:10236 203:10256 204:4583 205:2893 206:3164 207:3179 208:3984 209:3997 210:3888 211:1984 212:3023 213:2784 214:1046 215:57 216:6035 217:2134 218:859 219:577 220:1785 221:985 222:971 223:1352 End of report From surfer at mauigateway.com Fri Jul 20 19:37:08 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 20 Jul 2018 12:37:08 -0700 Subject: Proving Gig Speed Message-ID: <20180720123708.B8CD7975@m0117565.ppops.net> --- mark.tinka at seacom.mu wrote: From: Mark Tinka On 20/Jul/18 00:13, Scott Weeks wrote: > What I meant to say is a lot of folks get connectivity > through satellite. 500msec plus and jitter to spare. Would having local CDN caches help satellite-based providers? Sure... -------------------------------------- Could you explain that? Do you mean logically near the ground stations? I had a funny thought... CDN in the satellite. :) scott From karljorn787 at gmail.com Fri Jul 20 19:30:38 2018 From: karljorn787 at gmail.com (=?UTF-8?Q?Karl_J=C3=B8rn?=) Date: Fri, 20 Jul 2018 12:30:38 -0700 Subject: YANG daemeon for Linux Message-ID: Hi Is there a YANG daemeon for Linux ? If yes, can any one please share their experiences ? Danke, Karl From dylan at ambauen.com Fri Jul 20 23:07:26 2018 From: dylan at ambauen.com (Dylan Ambauen) Date: Fri, 20 Jul 2018 16:07:26 -0700 Subject: My compliments to Wowrack in Seattle Message-ID: Wowrack responded to an abuse report within 24 hours. This is the first abuse report for which I have ever received a response. They nullrouted the culprit, a paying customer no doubt. Thank you Wowrack. From surfer at mauigateway.com Sat Jul 21 03:53:04 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 20 Jul 2018 20:53:04 -0700 Subject: using expect to log into devices Message-ID: <20180720205304.B8CD66CA@m0117565.ppops.net> I have looked extensively on the web for an answer and cannot find one, so I come to you guys. I am not allowed to use modules in PERL or Python or I wouldn't have to do it this way. I have to do this all in Expect and I am a newbie at it. Also, maybe I'm having the Friday afternoon "I want to go home" mental block and the answer is right in front of my nose. I have a file with 1000s of devices and another file with a list of commands. The program issues all commands for a device and then moves on to the next one using nested loops. In the debug I see the "spawn_id expNN" (where NN is a number that, I believe is representative of the number of file descriptors used in the system) increment only when a device does not respond. As long as a device responds before the timeout period I see the expNN number does not increase. As soon as a device doesn't respond the expNN count goes up and I can't figure out why. Once I hit a certain expNN the program exits ungracefully; usually somewhere between 2500 and 3500 devices because our FD is set to 256 and that's how long it takes for 256 devices to not respond before the timeout period. Can anyone tell me why? Here is the relevant config snippet. I've tried every iteration of close and wait I found and no love... You'll want to put this into a fixed width font like Courier New or it'll just be a mess. foreach element $device { send_user "\n\n" send_user "#####################################\n" send_user "###### BEGIN $element #######\n" send_user "#####################################\n" spawn ssh -q -o StrictHostKeyChecking=no $username@$element expect { timeout { send_user "\nfailed to get password prompt\n\n" send_user "#####################################\n" send_user "####### END $element ########\n" send_user "#####################################\n" send_user "\n\n\n"; continue close $spawn_id wait } eof { send_user "\nssh failure for $element\n\n" send_user "#####################################\n" send_user "####### END $element ########\n" send_user "#####################################\n" send_user "\n\n\n"; continue close $spawn_id wait } "assword" { send "$password\n" } } expect { timeout { send_user "\npassword did not work or enable mode not achieved\n\n" send_user "#####################################\n" send_user "####### END $element ########\n" send_user "#####################################\n" send_user "\n\n\n"; continue close $spawn_id wait } eof { send_user "\npassword failure for $element\n\n" send_user "#####################################\n" send_user "######## END $element #########\n" send_user "#####################################\n" send_user "\n\n\n"; continue close $spawn_id wait } "" { send "term len 0\n" # send "skip-page-display\n" foreach command $commands { expect "#" send "$command\n" send_user "\n\n" } } } send "exit\n" send "exit\n" send_user "#####################################\n" send_user "####### END $element ########\n" send_user "#####################################\n" send_user "\n\n\n" close wait } Thanks! scott ps; I realize my indenting of the curly braces and other things are not standard... :) From mark.tinka at seacom.mu Sat Jul 21 06:01:24 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 21 Jul 2018 08:01:24 +0200 Subject: Proving Gig Speed In-Reply-To: <20180720123708.B8CD7975@m0117565.ppops.net> References: <20180720123708.B8CD7975@m0117565.ppops.net> Message-ID: <2b6c7e2c-21ea-77d7-3da9-d63a3b81c712@seacom.mu> On 20/Jul/18 21:37, Scott Weeks wrote: > Could you explain that? Do you mean logically near the > ground stations? I mean physically in the ISP's backbone. They would use the satellite link for cache-fill, but then deliver content locally. This should speed things up a great deal. Having the cache on the other side of the satellite link doesn't help at all, since the biggest latency tax is on the satellite link itself. > I had a funny thought... CDN in the satellite. :) :-) - don't give them ideas, hehe... Mark. From surfer at mauigateway.com Sat Jul 21 06:22:05 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 20 Jul 2018 23:22:05 -0700 Subject: Proving Gig Speed Message-ID: <20180720232205.B8CECC7F@m0117566.ppops.net> --- mark.tinka at seacom.mu wrote: On 20/Jul/18 21:37, Scott Weeks wrote: > Could you explain that? Do you mean logically > near the ground stations? I mean physically in the ISP's backbone. ------------------------------------------ Oops, failure to communicate... They folks on the eyeball end have consumer grade satellite internet with VSATs in their yard. Thus my CDN in the satellite joke. scott From mark.tinka at seacom.mu Sat Jul 21 06:49:19 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 21 Jul 2018 08:49:19 +0200 Subject: Proving Gig Speed In-Reply-To: <20180720232205.B8CECC7F@m0117566.ppops.net> References: <20180720232205.B8CECC7F@m0117566.ppops.net> Message-ID: <4e5d9736-ceeb-b3be-8eea-d9cef7662f63@seacom.mu> On 21/Jul/18 08:22, Scott Weeks wrote: > > Oops, failure to communicate... They folks on the > eyeball end have consumer grade satellite internet > with VSATs in their yard. Thus my CDN in the > satellite joke. Ah, got you :-). Well, if the earth station on the other side is in a well-connected city, they've got the best they can get. Mark. From list at satchell.net Sat Jul 21 07:21:32 2018 From: list at satchell.net (Stephen Satchell) Date: Sat, 21 Jul 2018 00:21:32 -0700 Subject: Proving Gig Speed In-Reply-To: <20180720232205.B8CECC7F@m0117566.ppops.net> References: <20180720232205.B8CECC7F@m0117566.ppops.net> Message-ID: <3ba65fd9-413b-3a1e-c561-487420f2b0f6@satchell.net> On 07/20/2018 11:22 PM, Scott Weeks wrote: > Oops, failure to communicate... They folks on the > eyeball end have consumer grade satellite internet > with VSATs in their yard. Thus my CDN in the > satellite joke. That idea would work better with a constellation of LEO satellites, as opposed to geosync. Especially if there was a link satellite-to-satellite for update purposes. From jwbensley at gmail.com Sat Jul 21 07:50:37 2018 From: jwbensley at gmail.com (James Bensley) Date: Sat, 21 Jul 2018 08:50:37 +0100 Subject: using expect to log into devices In-Reply-To: <20180720205304.B8CD66CA@m0117565.ppops.net> References: <20180720205304.B8CD66CA@m0117565.ppops.net> Message-ID: <8B6325DB-A367-40C0-8B2B-6E430FA9A6B3@gmail.com> Do you need to write this yourself, I've used this expect script too many times such that I should be ashamed...It "just works": https://sourceforge.net/projects/cosi-nms/files/ciscocmd/ Cheers, James. From surfer at mauigateway.com Sat Jul 21 08:14:39 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 21 Jul 2018 01:14:39 -0700 Subject: using expect to log into devices Message-ID: <20180721011439.B8CD63A4@m0117460.ppops.net> --- jwbensley at gmail.com wrote: From: James Bensley :: Do you need to write this yourself, No, but I'm tired of being a coding wussie, so this is 1) an exercise for me in getting better at it and 2) I want it to read a list of machines from one file and execute a list of commands from another. Then I just vi the files and done. :: I've used this expect script too many :: times such that I should be ashamed...It :: "just works": :: :: https://sourceforge.net/projects/cosi-nms/files/ciscocmd/ Thanks, it's beertime Friday, so I will look at it tomorrow. However, I'd sure like to know why I an using up all the file descriptors on the system. scott From ler762 at gmail.com Sat Jul 21 11:11:49 2018 From: ler762 at gmail.com (Lee) Date: Sat, 21 Jul 2018 07:11:49 -0400 Subject: using expect to log into devices In-Reply-To: <20180720205304.B8CD66CA@m0117565.ppops.net> References: <20180720205304.B8CD66CA@m0117565.ppops.net> Message-ID: On 7/20/18, Scott Weeks wrote: > > I have looked extensively on the web for an answer > and cannot find one, so I come to you guys. I am > not allowed to use modules in PERL or Python or I > wouldn't have to do it this way. I have to do this > all in Expect and I am a newbie at it. > > Also, maybe I'm having the Friday afternoon "I want > to go home" mental block and the answer is right in > front of my nose. > > I have a file with 1000s of devices and another file > with a list of commands. The program issues all > commands for a device and then moves on to the next > one using nested loops. In the debug I see the > "spawn_id expNN" (where NN is a number that, I > believe is representative of the number of file > descriptors used in the system) increment only when > a device does not respond. As long as a device > responds before the timeout period I see the expNN > number does not increase. As soon as a device > doesn't respond the expNN count goes up and I can't > figure out why. Once I hit a certain expNN the > program exits ungracefully; usually somewhere between > 2500 and 3500 devices because our FD is set to 256 > and that's how long it takes for 256 devices to not > respond before the timeout period. Can anyone tell > me why? Here is the relevant config snippet. I've > tried every iteration of close and wait I found and > no love... 'close $spawn_id' is wrong, so maybe that's it? man expect close [-slave] [-onexec 0|1] [-i spawn_id] closes the connection to the current process. ... The -i flag declares the process to close corresponding to the named spawn_id. <.. snip ..> No matter whether the connection is closed implicitly or explicitly, you should call wait to clear up the corresponding kernel process slot. close does not call wait since there is no guarantee that closing a process connection will cause it to exit. See wait below for more info. get rancid from here ftp://ftp.shrubbery.net/pub/rancid/ and take a look at clogin (which allows you to do 'clogin -x fileName dev1 dev2 ... devN' to run the commands in 'fileName' on the list of devices) The eof and timeout cases are basically { catch {close}; catch {wait}; } Regards, Lee > > You'll want to put this into a fixed width font like > Courier New or it'll just be a mess. > > > foreach element $device { > > send_user "\n\n" > > send_user "#####################################\n" > send_user "###### BEGIN $element #######\n" > send_user "#####################################\n" > > spawn ssh -q -o StrictHostKeyChecking=no $username@$element > > expect { > timeout { send_user "\nfailed to get password prompt\n\n" > send_user "#####################################\n" > send_user "####### END $element ########\n" > send_user "#####################################\n" > send_user "\n\n\n"; continue > close $spawn_id > wait > } > eof { send_user "\nssh failure for $element\n\n" > send_user "#####################################\n" > send_user "####### END $element ########\n" > send_user "#####################################\n" > send_user "\n\n\n"; continue > close $spawn_id > wait > } > "assword" { > send "$password\n" > } > } > > > expect { > timeout { send_user "\npassword did not work or enable mode not > achieved\n\n" > send_user "#####################################\n" > send_user "####### END $element ########\n" > send_user "#####################################\n" > send_user "\n\n\n"; continue > close $spawn_id > wait > } > eof { send_user "\npassword failure for $element\n\n" > send_user "#####################################\n" > send_user "######## END $element #########\n" > send_user "#####################################\n" > send_user "\n\n\n"; continue > close $spawn_id > wait > } > "" { > send "term len 0\n" > # send "skip-page-display\n" > > foreach command $commands { > expect "#" > send "$command\n" > send_user "\n\n" > } > } > } > > send "exit\n" > send "exit\n" > > send_user "#####################################\n" > send_user "####### END $element ########\n" > send_user "#####################################\n" > send_user "\n\n\n" > > close > wait > } > > > Thanks! > scott > > ps; I realize my indenting of the curly braces and other > things are not standard... :) > > From surfer at mauigateway.com Sat Jul 21 20:37:47 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 21 Jul 2018 13:37:47 -0700 Subject: using expect to log into devices Message-ID: <20180721133747.B8CD5503@m0117460.ppops.net> --- ler762 at gmail.com wrote: From: Lee > I have a file with 1000s of devices and another file > with a list of commands. The program issues all > commands for a device and then moves on to the next > one using nested loops. In the debug I see the > "spawn_id expNN" (where NN is a number that, I > believe is representative of the number of file > descriptors used in the system) increment only when > a device does not respond. As long as a device > responds before the timeout period I see the expNN > number does not increase. As soon as a device > doesn't respond the expNN count goes up and I can't > figure out why. Once I hit a certain expNN the :: 'close $spawn_id' is wrong, so maybe that's it? :: man expect :: close [-slave] [-onexec 0|1] [-i spawn_id] :: closes the connection to the current process. :: ... The -i :: flag declares the :: process to close corresponding to the named :: spawn_id. <.. snip ..> ---------------------------------------- I hand typed the close stuff in the email with just 'close spawn_id'. I did the -i in previous iterations, but saw no difference. Maybe I should try more. I saw the 'close' alone a lot on Stackexchange a lot,so I was copying those in this iteration. I also should have read the man page more than I did, so a face slap to myself. :: No matter whether the connection is closed :: implicitly or explicitly, you should call wait to :: clear up the corresponding kernel process slot. :: close does not call wait since there is no guarantee :: that closing a process connection will cause it to :: exit. See wait below for more info. :: The eof and timeout cases are basically :: { catch {close}; catch {wait}; } I always used wait after close and need to look into those above. Maybe they close it different somehow. :: get rancid from here... and take a look at clogin... I'm going to be looking for a new job and want to up my skills, in case I get a chance to do the SDN/NFV stuff, which I read requires coding skills, so this is also an exercise toward that. Plus it's fun. I had already done this in PERL, but, even though we have PERL, we are not allowed to download modules here. So, I'm redoing it in Expect. I thought someone would say a "oh just and you're done" type of response. Thanks a lot from everyone private and on the list. I'll post for the archives if I find the answer. scott From niels=nanog at bakker.net Sat Jul 21 22:43:35 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Sun, 22 Jul 2018 00:43:35 +0200 Subject: using expect to log into devices In-Reply-To: <20180721133747.B8CD5503@m0117460.ppops.net> References: <20180721133747.B8CD5503@m0117460.ppops.net> Message-ID: <20180721224335.GA9970@jima.tpb.net> * surfer at mauigateway.com (Scott Weeks) [Sat 21 Jul 2018, 22:38 CEST]: >I had already done this in PERL, but, even though we have PERL, we >are not allowed to download modules here. So, I'm redoing it in >Expect. I thought someone would say a "oh just and >you're done" type of response. Well, what you're doing right here is reimplementing rancid. Which is wholly unnecessary because we already have rancid, and a more modern alternative named oxidized. And you've gotten that response already. Fine as a personal exercise, of course. The inability to download modules seems sadistic to me, though. -- Niels. From valdis.kletnieks at vt.edu Sun Jul 22 00:20:44 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 21 Jul 2018 20:20:44 -0400 Subject: using expect to log into devices In-Reply-To: <20180721224335.GA9970@jima.tpb.net> References: <20180721133747.B8CD5503@m0117460.ppops.net> <20180721224335.GA9970@jima.tpb.net> Message-ID: <241314.1532218844@turing-police.cc.vt.edu> On Sun, 22 Jul 2018 00:43:35 +0200, Niels Bakker said: > Fine as a personal exercise, of course. The inability to download > modules seems sadistic to me, though. And given the adage "Never create a rule you can't enforce", I wonder how they enforce it - have to be pretty hardcore to make sure that stuff doesn't get imported via USB or tethering off a cellphone. (Or more correctly, I know how they do those sort of things if you're a spook agency or doing classified research - how do you make it palatable to employees in corporate sites?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From jcrowe215 at gmail.com Sun Jul 22 04:10:06 2018 From: jcrowe215 at gmail.com (J Crowe) Date: Sun, 22 Jul 2018 00:10:06 -0400 Subject: using expect to log into devices In-Reply-To: <241314.1532218844@turing-police.cc.vt.edu> References: <20180721133747.B8CD5503@m0117460.ppops.net> <20180721224335.GA9970@jima.tpb.net> <241314.1532218844@turing-police.cc.vt.edu> Message-ID: Have you looked into utilizing Ansible? On Sat, Jul 21, 2018 at 8:22 PM wrote: > On Sun, 22 Jul 2018 00:43:35 +0200, Niels Bakker said: > > Fine as a personal exercise, of course. The inability to download > > modules seems sadistic to me, though. > > And given the adage "Never create a rule you can't enforce", I > wonder how they enforce it - have to be pretty hardcore to make > sure that stuff doesn't get imported via USB or tethering off a > cellphone. (Or more correctly, I know how they do those sort of > things if you're a spook agency or doing classified research - how > do you make it palatable to employees in corporate sites?) > From valdis.kletnieks at vt.edu Sun Jul 22 07:02:10 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 22 Jul 2018 03:02:10 -0400 Subject: using expect to log into devices In-Reply-To: References: <20180721133747.B8CD5503@m0117460.ppops.net> <20180721224335.GA9970@jima.tpb.net> <241314.1532218844@turing-police.cc.vt.edu> Message-ID: <124824.1532242930@turing-police.cc.vt.edu> On Sun, 22 Jul 2018 00:10:06 -0400, J Crowe said: > Have you looked into utilizing Ansible? Yes, we use Ansible heavily on production services. But Ansible doesn't *stop* somebody from downloading modules, especially if it's a laptop used for diagnosis/testing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nanog at radu-adrian.feurdean.net Sun Jul 22 07:46:25 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sun, 22 Jul 2018 09:46:25 +0200 Subject: Proving Gig Speed In-Reply-To: <779483637.1269.1531838556908.JavaMail.mhammett@ThunderFuck> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> <779483637.1269.1531838556908.JavaMail.mhammett@ThunderFuck> Message-ID: <1532245585.1996649.1448742496.2F954A1A@webmail.messagingengine.com> On Tue, Jul 17, 2018, at 16:42, Mike Hammett wrote: > Build your own last mile or order that 10% more? Do you realize what you are saying ? Let me offer a few translations: 1. "Don't spend N00 Currency/month for X Mbps from your customer to your aggregation DC on an existing NNI, but pay something like N0 KCurrency one shot (sometimes significantly more) + whatever is needed to extend your backbone ot the customer area (long-haul capacity, equipment, housing, ...)." CFO hates this unless you have enough customers in a single decently-sized area. 2. The "10% more" does not work this way. In this part of the world, the next step after 100 Mbps is 200 Mbps, and the next step after 1Gbps (on 1G port) is 2 Gbps (on 10G port). You can't buy 110 Mbps or 1100 Mbps. You just can't over-provision L2 transport for those speeds. Even if you are in a situation where you really can over-provision, your customer stays yours only as long as the price is correct. A competitor that does not over-provision but instead explains how things work ends up winning "your"customers. 3. There are zone where you are just not allowed to run your local loop. Most common example is airport and harbor areas. Then there are country-specific zones where you may not be allowed, and finally there are zones where a few select people do a lot of things so that only their favorite provider (usually the incumbent) deploys. A derivative of this, is the "select people" is the telecom regulator, that grants an almost-monopoly in certain areas to the first operator that comes with a deployment plan for the whole area (fiber anyone - individual and business - in a 80K people town - you have 10/15/20 years to do it). You may argue that some of those issues do not apply in North America (the NA from NANOG), but NANOG became pretty much global :) From mark.tinka at seacom.mu Sun Jul 22 10:00:52 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 22 Jul 2018 12:00:52 +0200 Subject: Proving Gig Speed In-Reply-To: <1532245585.1996649.1448742496.2F954A1A@webmail.messagingengine.com> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> <779483637.1269.1531838556908.JavaMail.mhammett@ThunderFuck> <1532245585.1996649.1448742496.2F954A1A@webmail.messagingengine.com> Message-ID: <3c84d262-50bc-7af8-ed46-04532bb8de33@seacom.mu> On 22/Jul/18 09:46, Radu-Adrian Feurdean wrote: > You may argue that some of those issues do not apply in North America (the NA from NANOG), but NANOG became pretty much global :) I am certain that there are places in (North) America where you cannot "build your own" or "order 10% more"... Mark. From nanog at radu-adrian.feurdean.net Sun Jul 22 10:48:24 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sun, 22 Jul 2018 12:48:24 +0200 Subject: Proving Gig Speed In-Reply-To: References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> Message-ID: <1532256504.2050033.1448817224.51F5144B@webmail.messagingengine.com> On Tue, Jul 17, 2018, at 18:12, Andy Ringsmuth wrote: > I suppose in reality it’s no different than any other utility. My home > has 200 amp electrical service. Will I ever use 200 amps at one time? No, because at 201 Amps instantaneous the breaker will cut everything. > Highly highly unlikely. But if my electrical utility wanted to advertise > “200 amp service in all homes we supply!” they sure could. Would an > electrician be able to test it? I’m sure there is a way somehow. Will they deal with customers calling to complain that their (unknown to the utility) "megatron equipment" says it cannot draw 199 Amps from a single outlet ? I don't think so. They just ensure the global breaker will not trigger when oven+microwave+home-wide air-con+water heating+BT rig in the basement all draw all they can (i.e. up to ~25 Amps each) for something like 5 min. > saturate my home fiber 300 mbit synchronous connection? Every now and > then yes, but rarely. Although if I’m paying for 300 and not getting it, > my ISP will be hearing from me. Will you waste your time if some random site says "you have 200 Mbps" ? On residential, we only accept complaints for tests in pre-determined (wired, no intermediate device, select set of test servers and tools, customer hardware check) conditions and only for results lower than 60-70% of "advertised speed". If wireless is invoved, test is being dismissed as "dear customer, please fix your network, regards". For pro/enterprise service, we use higher bandwidth threshold, but we do expect the other side to be competent enough for something like an iperf3 test. However, I have to mention that for the moment we can afford to run a congestion-free network (strictly less than 80% charge - usually less than 50% - measured with 1-minute sampling). > If my electrical utility told me “hey, you can upgrade to 500 amp Are the 200 Amps written somewhere in the contract or is it what reads on the usually installed breaker ? Around here, the maximal power is determined in the contract (and enforced by the "connected" electrical meter/breaker that has a generous functioning margin. From nanog at radu-adrian.feurdean.net Sun Jul 22 11:26:26 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sun, 22 Jul 2018 13:26:26 +0200 Subject: Proving Gig Speed In-Reply-To: <871529190.3073.1531921504776.JavaMail.mhammett@ThunderFuck> References: <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <871529190.3073.1531921504776.JavaMail.mhammett@ThunderFuck> Message-ID: <1532258786.2060995.1448851280.39984406@webmail.messagingengine.com> On Wed, Jul 18, 2018, at 15:45, Mike Hammett wrote: > Fast.com will pull from multiple nodes at the same time. I think there Here in Europe, fast.com consistently proven to be 100% UNreliable, especially on high-speed FTTH. OOKla and nPerf gave better results for high-speed connections 100% of the time. From nanog at radu-adrian.feurdean.net Sun Jul 22 13:21:17 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sun, 22 Jul 2018 15:21:17 +0200 Subject: issues through CGNat (juniper ms-mpc-128g in mx960) In-Reply-To: <000001d41f6d$a014efd0$e03ecf70$@gvtc.com> References: <000001d41f6d$a014efd0$e03ecf70$@gvtc.com> Message-ID: <1532265677.2094237.1448903360.1E0DB934@webmail.messagingengine.com> On Thu, Jul 19, 2018, at 16:34, Aaron Gould wrote: > I don't know if it's fixed on the endpoints, or in the cgnat config or what. Not specific to Juniper, but it's NOT fixed. You'll either start spending time on work-arounds or you start selling a new service with dedicated public IPv4 - more expensive than the CGNATed one. Or you can afford to still delay deploying CGN. From nanog at ics-il.net Sun Jul 22 13:25:19 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 22 Jul 2018 08:25:19 -0500 (CDT) Subject: Proving Gig Speed In-Reply-To: <1532245585.1996649.1448742496.2F954A1A@webmail.messagingengine.com> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> <779483637.1269.1531838556908.JavaMail.mhammett@ThunderFuck> <1532245585.1996649.1448742496.2F954A1A@webmail.messagingengine.com> Message-ID: <28315852.1173.1532265916607.JavaMail.mhammett@ThunderFuck> As someone that has built his own last-mile ISP and knows first hand literally hundreds of others and coaches thousands more through social media and a podcast, yes, I realize what I'm saying when I say to build your own last mile. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Radu-Adrian Feurdean" To: nanog at nanog.org Sent: Sunday, July 22, 2018 2:46:25 AM Subject: Re: Proving Gig Speed On Tue, Jul 17, 2018, at 16:42, Mike Hammett wrote: > Build your own last mile or order that 10% more? Do you realize what you are saying ? Let me offer a few translations: 1. "Don't spend N00 Currency/month for X Mbps from your customer to your aggregation DC on an existing NNI, but pay something like N0 KCurrency one shot (sometimes significantly more) + whatever is needed to extend your backbone ot the customer area (long-haul capacity, equipment, housing, ...)." CFO hates this unless you have enough customers in a single decently-sized area. 2. The "10% more" does not work this way. In this part of the world, the next step after 100 Mbps is 200 Mbps, and the next step after 1Gbps (on 1G port) is 2 Gbps (on 10G port). You can't buy 110 Mbps or 1100 Mbps. You just can't over-provision L2 transport for those speeds. Even if you are in a situation where you really can over-provision, your customer stays yours only as long as the price is correct. A competitor that does not over-provision but instead explains how things work ends up winning "your"customers. 3. There are zone where you are just not allowed to run your local loop. Most common example is airport and harbor areas. Then there are country-specific zones where you may not be allowed, and finally there are zones where a few select people do a lot of things so that only their favorite provider (usually the incumbent) deploys. A derivative of this, is the "select people" is the telecom regulator, that grants an almost-monopoly in certain areas to the first operator that comes with a deployment plan for the whole area (fiber anyone - individual and business - in a 80K people town - you have 10/15/20 years to do it). You may argue that some of those issues do not apply in North America (the NA from NANOG), but NANOG became pretty much global :) From cb.list6 at gmail.com Sun Jul 22 14:21:25 2018 From: cb.list6 at gmail.com (Ca By) Date: Sun, 22 Jul 2018 07:21:25 -0700 Subject: issues through CGNat (juniper ms-mpc-128g in mx960) In-Reply-To: <1532265677.2094237.1448903360.1E0DB934@webmail.messagingengine.com> References: <000001d41f6d$a014efd0$e03ecf70$@gvtc.com> <1532265677.2094237.1448903360.1E0DB934@webmail.messagingengine.com> Message-ID: On Sun, Jul 22, 2018 at 6:23 AM Radu-Adrian Feurdean < nanog at radu-adrian.feurdean.net> wrote: > On Thu, Jul 19, 2018, at 16:34, Aaron Gould wrote: > > I don't know if it's fixed on the endpoints, or in the cgnat config or > what. > > Not specific to Juniper, but it's NOT fixed. > You'll either start spending time on work-arounds or you start selling a > new service with dedicated public IPv4 - more expensive than the CGNATed > one. Or you can afford to still delay deploying CGN. Or, do us all a favor, and leave PS4 broken and refer your customers to Nintendo for them to support ipv6. If you dont, then we all remain hostage to nintendo and their dedicated ipv4 bs > From keiths at neilltech.com Sun Jul 22 14:25:41 2018 From: keiths at neilltech.com (Keith Stokes) Date: Sun, 22 Jul 2018 14:25:41 +0000 Subject: Proving Gig Speed In-Reply-To: <1532256504.2050033.1448817224.51F5144B@webmail.messagingengine.com> References: <81904878-fce8-1e5d-56b0-b5298e8176bc@seacom.mu> <459697011.1265.1531838515059.JavaMail.mhammett@ThunderFuck> , <1532256504.2050033.1448817224.51F5144B@webmail.messagingengine.com> Message-ID: <402727DA-B69D-4867-BBD8-E59495DED467@neilltech.com> Typical electrical breakers are not instantaneous devices and likely will not trip at .5% over rated load until they've been run near limit for extended periods of time. ----- Keith Stokes > On Jul 22, 2018, at 5:52 AM, Radu-Adrian Feurdean wrote: > >> On Tue, Jul 17, 2018, at 18:12, Andy Ringsmuth wrote: >> >> I suppose in reality it’s no different than any other utility. My home >> has 200 amp electrical service. Will I ever use 200 amps at one time? > > No, because at 201 Amps instantaneous the breaker will cut everything. > >> Highly highly unlikely. But if my electrical utility wanted to advertise >> “200 amp service in all homes we supply!” they sure could. Would an >> electrician be able to test it? I’m sure there is a way somehow. > > Will they deal with customers calling to complain that their (unknown to the utility) "megatron equipment" says it cannot draw 199 Amps from a single outlet ? I don't think so. They just ensure the global breaker will not trigger when oven+microwave+home-wide air-con+water heating+BT rig in the basement all draw all they can (i.e. up to ~25 Amps each) for something like 5 min. > >> saturate my home fiber 300 mbit synchronous connection? Every now and >> then yes, but rarely. Although if I’m paying for 300 and not getting it, >> my ISP will be hearing from me. > > Will you waste your time if some random site says "you have 200 Mbps" ? On residential, we only accept complaints for tests in pre-determined (wired, no intermediate device, select set of test servers and tools, customer hardware check) conditions and only for results lower than 60-70% of "advertised speed". If wireless is invoved, test is being dismissed as "dear customer, please fix your network, regards". > > For pro/enterprise service, we use higher bandwidth threshold, but we do expect the other side to be competent enough for something like an iperf3 test. > > However, I have to mention that for the moment we can afford to run a congestion-free network (strictly less than 80% charge - usually less than 50% - measured with 1-minute sampling). > >> If my electrical utility told me “hey, you can upgrade to 500 amp > > Are the 200 Amps written somewhere in the contract or is it what reads on the usually installed breaker ? Around here, the maximal power is determined in the contract (and enforced by the "connected" electrical meter/breaker that has a generous functioning margin. From mark.tinka at seacom.mu Sun Jul 22 16:03:22 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 22 Jul 2018 18:03:22 +0200 Subject: Proving Gig Speed In-Reply-To: <28315852.1173.1532265916607.JavaMail.mhammett@ThunderFuck> References: <20180716180228.GA31062@dan.olp.net> <20180716180808.GD2568@puck.nether.net> <609DDB73-86EE-40D7-A197-C9D0BC5E19CD@rivervalleyinternet.net> <779483637.1269.1531838556908.JavaMail.mhammett@ThunderFuck> <1532245585.1996649.1448742496.2F954A1A@webmail.messagingengine.com> <28315852.1173.1532265916607.JavaMail.mhammett@ThunderFuck> Message-ID: <2a66f0ee-27a5-c8c4-d55b-7e35bc5a9510@seacom.mu> On 22/Jul/18 15:25, Mike Hammett wrote: > As someone that has built his own last-mile ISP and knows first hand literally hundreds of others and coaches thousands more through social media and a podcast, yes, I realize what I'm saying when I say to build your own last mile. Hell, what are you doing all the way out there man? Wanna come to Africa and make some real bucks :-)... Mark. From niels=nanog at bakker.net Sun Jul 22 19:54:21 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Sun, 22 Jul 2018 21:54:21 +0200 Subject: Proving Gig Speed In-Reply-To: <1532258786.2060995.1448851280.39984406@webmail.messagingengine.com> References: <8a00dd71-15b0-6a2e-9314-618d888b6ff1@seacom.mu> <3412514b-60e0-d979-b6ff-cf1ac8c79eda@seacom.mu> <871529190.3073.1531921504776.JavaMail.mhammett@ThunderFuck> <1532258786.2060995.1448851280.39984406@webmail.messagingengine.com> Message-ID: <20180722195421.GB9970@jima.tpb.net> * nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) [Sun 22 Jul 2018, 13:27 CEST]: >On Wed, Jul 18, 2018, at 15:45, Mike Hammett wrote: >>Fast.com will pull from multiple nodes at the same time. I think there > >Here in Europe, fast.com consistently proven to be 100% UNreliable, >especially on high-speed FTTH. OOKla and nPerf gave better results >for high-speed connections 100% of the time. It has a tendency to download over IPv6 from New York, which, while still fast enough for HD movie streaming, doesn't give a good indication of line speed. (I have native IPv6 here, no tunnels.) -- Niels. From sean at donelan.com Mon Jul 23 01:01:12 2018 From: sean at donelan.com (Sean Donelan) Date: Sun, 22 Jul 2018 21:01:12 -0400 (EDT) Subject: Rising sea levels are going to mess with the internet Message-ID: https://www.popsci.com/sea-level-rise-internet-infrastructure Rising sea levels are going to mess with the internet, sooner than you think [...] Despite its magnitude, this network is increasingly vulnerable to sea levels inching their way higher, according to research presented at an academic conference in Montreal this week. The findings estimate that within 15 years, thousands of miles of what should be land-bound cables in the United States will be submerged underwater. “Most of the climate change-related impacts are going to happen very soon,” says Paul Barford, a computer scientist at the University of Wisconsin and lead author of the paper. [...] From me at colinbaker.net Mon Jul 23 07:09:23 2018 From: me at colinbaker.net (Colin Baker) Date: Mon, 23 Jul 2018 02:09:23 -0500 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: Message-ID: <5c1bc5eaae07d51fab808f20f772033d@colinbaker.net> On 2018-07-22 20:01, Sean Donelan wrote: > https://www.popsci.com/sea-level-rise-internet-infrastructure > > Rising sea levels are going to mess with the internet, sooner than you > think > > [...] > Despite its magnitude, this network is increasingly vulnerable to sea > levels inching their way higher, according to research presented at an > academic conference in Montreal this week. The findings estimate that > within 15 years, thousands of miles of what should be land-bound > cables in the United States will be submerged underwater. > > “Most of the climate change-related impacts are going to happen very > soon,” says Paul Barford, a computer scientist at the University of > Wisconsin and lead author of the paper. > [...] These guys would freak if they popped open a manhole in the spring -- "640K ought to be enough for anybody." -Kurt Cobain From rob at invaluement.com Mon Jul 23 02:52:32 2018 From: rob at invaluement.com (Rob McEwen) Date: Sun, 22 Jul 2018 22:52:32 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: Message-ID: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> For the past 100+ years, the sea levels have been rising by about 2-4 mm per year. If you go to the following two sites: https://oceanservice.noaa.gov/facts/sealevel.html https://climate.nasa.gov/vital-signs/sea-level/ You'll see all kinds of scary language about dire predictions about how the sea levels are rising and accelerating. And you'll see SCARY charts that look like Mt. Everest. But when you dig into the actual data, you'll find that there MIGHT have been (at most!) a CUMULATIVE 1mm/year acceleration... but even that took about 4 decades to materialize, it could be somewhat within the margin of error, and it might be a part of the fake data that often drives this debate. Meanwhile, global warming alarmists have ALREADY made MANY dire predictions about oceans levels rising - that ALREADY didn't even come close to true. The bottom line is that there is no trend of recently observed sea level rising data that is even close to being on track to hit all these dire predictions within the foreseeable future. And even as the West has reduced (or lessened the acceleration of) CO2 emissions - this has been easily made up for by the CO2 emission increases caused by the modernization of China and India in recent decades. And, again, there were articles like this 10, 15, and even 20 years ago that made very similar predictions - that didn't happen. So, it is hard to believe that the dire predictions in this article could come true in 15 years. But I suppose that it might be a good idea to take inventory of the absolute lowest altitude cables and make sure that they are not vulnerable to the type of flooding that might happen more often after a few decades from now after the ocean has further risen about 2 inches? But the sky is not falling anytime soon. Rob McEwen On 7/22/2018 9:01 PM, Sean Donelan wrote: > https://www.popsci.com/sea-level-rise-internet-infrastructure > > Rising sea levels are going to mess with the internet, sooner than you > think > > [...] > Despite its magnitude, this network is increasingly vulnerable to sea > levels inching their way higher, according to research presented at an > academic conference in Montreal this week. The findings estimate that > within 15 years, thousands of miles of what should be land-bound > cables in the United States will be submerged underwater. > > “Most of the climate change-related impacts are going to happen very > soon,” says Paul Barford, a computer scientist at the University of > Wisconsin and lead author of the paper. > [...] > -- Rob McEwen From surfer at mauigateway.com Mon Jul 23 04:16:11 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 22 Jul 2018 21:16:11 -0700 Subject: Rising sea levels are going to mess with the internet Message-ID: <20180722211611.B8CD4D0B@m0117460.ppops.net> --- rob at invaluement.com wrote: From: Rob McEwen The bottom line is that there is no trend of recently observed sea level rising data that is even close to being on track to hit all these dire predictions within the foreseeable future.... And, again, there were articles like this 10, 15, and even 20 years ago that made very similar predictions - that didn't happen. ------------------------------------------ Maybe the dire predictions didn't happen, but when combined with other drivers stuff happens. For example: https://www.theguardian.com/environment/2016/may/10/headlines-exaggerated-climate-link-to-sinking-of-pacific-islands "The study blamed the loss on a combination of sea-level rise and high wave energy." "The major misunderstanding stems from the conflation of sea-level rise with climate change." "...the ocean has been rising in the Solomon Islands at 7mm per year, more than double the global average." "...driven partly by global warming and partly by climatic cycles - in particular the Pacific Decadal Oscillation." So for us, it's an it depends thing. It depends what cables and where they're located. scott From valdis.kletnieks at vt.edu Mon Jul 23 07:06:48 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 23 Jul 2018 03:06:48 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <5c1bc5eaae07d51fab808f20f772033d@colinbaker.net> References: <5c1bc5eaae07d51fab808f20f772033d@colinbaker.net> Message-ID: <248133.1532329608@turing-police.cc.vt.edu> On Mon, 23 Jul 2018 02:09:23 -0500, Colin Baker said: > These guys would freak if they popped open a manhole in the spring It's a lot harder to pump out a manhole if it's now below the water table. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From saku at ytti.fi Mon Jul 23 07:55:23 2018 From: saku at ytti.fi (Saku Ytti) Date: Mon, 23 Jul 2018 10:55:23 +0300 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: On Mon, 23 Jul 2018 at 05:55, Rob McEwen wrote: > Meanwhile, global warming > alarmists have ALREADY made MANY dire predictions about oceans levels > rising - that ALREADY didn't even come close to true. Now this discussion does not belong to NANOG, but 'global warming alarmist' is worrying term to me. What is the perceived harm you're trying to reduce? Are the acts which try to address the problem the harm you'd like to see avoided? This seems very imbalanced bet, but bet lot of people with no training in the subject matter, including leader of the free world, are willing to take. This is like people who have never ever professionally been involved with Internet keep predicting that Internet is going to break. While (I'd hope) overwhelming majority of subject matter expert are confident that there isn't any concrete observable threat. Much in same way, compelling majority of scientists (>95%) believe in human caused global warming and even larger percentage in those scientists who have researched the subject matter. The skepticism is almost exclusively in people who have no training or research in the subject matter. It's curious phenomena where we are very willing to ignore all the data points that disagree with us, and accept the one data point that agrees with us, even when admitted to be fabrication. Some starting points, while of course entirely ineffective for reasons explained: http://www.grist.org/article/series/skeptics/ http://www.skepticalscience.com/argument.php http://www.realclimate.org/index.php/archives/2007/05/start-here/ http://blogs.discovermagazine.com/badastronomy/2011/08/24/case-closed-climategate-was-manufactured/-- -- ++ytti From mark.tinka at seacom.mu Mon Jul 23 08:44:36 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 23 Jul 2018 10:44:36 +0200 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: <21bcfdd1-a483-6600-7d33-58583f1630ec@seacom.mu> On 23/Jul/18 09:55, Saku Ytti wrote: > It's curious phenomena where we are very willing to > ignore all the data points that disagree with us, and accept the one > data point that agrees with us, even when admitted to be fabrication. Some people just always prefer to do the opposite of everyone else, and/or the obvious. I have many friends like this. Mark. From rob at invaluement.com Mon Jul 23 10:54:57 2018 From: rob at invaluement.com (Rob McEwen) Date: Mon, 23 Jul 2018 06:54:57 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: On 7/23/2018 3:55 AM, Saku Ytti wrote: > On Mon, 23 Jul 2018 at 05:55, Rob McEwen wrote: >> Meanwhile, global warming >> alarmists have ALREADY made MANY dire predictions about oceans levels >> rising - that ALREADY didn't even come close to true. > Now this discussion does not belong to NANOG Yes - sad isn't it - that someone else brought this up. > but 'global warming > alarmist' is worrying term to me. What is the perceived harm you're > trying to reduce? Are the acts which try to address the problem the > harm you'd like to see avoided? Anytime a "big solution" is applied to a "small problem" (or non-existent problem), problems arise. At the least, mis-allocation of resources  can cause situations where other important issues fail to get addressed when the small problem gets an over-allocation of resources. (and real peoples' lives get damaged in the process) > Much in same way, compelling majority of scientists (>95%) believe in > human caused global warming Your ">95%" is MORE junk science. The popular percentage to throw out is "97%" - as quoted by Obama  and many others - this came from 2013 paper by John Cook - that was so incredibly and dishonestly flawed as to basically be unscientific propaganda. (1) many scientists' papers were falsely classified and (2) he did a "bait and switch" where he "read into" certain papers stuff that wasn't really there. http://www.populartechnology.net/2013/05/97-study-falsely-classifies-scientists.html https://www.theguardian.com/environment/blog/2014/jun/06/97-consensus-global-warming Real science makes "risky predictions" and then is willing to redo the hypothesis when those predictions don't happen as predicted. In contrast, junk science stubbornly sticks to preconceived biases even when the data continually fails to validate the hypothesis (which is happening here!). The fact that you're so quick to try your "appeal to authority" with that fake ">95%" percentage - and you don't seem to understand that a mis-allocation of resources based on junk science is NOT a victim-less crime (so to speak - not technically a crime - but REAL people ARE damaged by this) - undermines your credibility. Tell you what, I'll admit that I might be wrong the first time that we see a 5+mm per year average of sea level rising over a 5 year period. HINT: We won't. For example, look at the blue line at the end of this "scary graph" from a "climage change" site that has your same viewpoint: https://insideclimatenews.org/content/average-global-sea-level-rise-1993-2017 - as scary as that chart looks like at first glance - it shows little-to-no *acceleration* - the rate of increase holds steady at 3.5 mm/year - BUT HERE IS THE INTERESTING PART: even this pro-climate change site's own graph shows that the sea levels have failed to rise AT ALL over the past couple of years. But 15 years from now, we'll see new rounds of NEW dire predictions about alarming FUTURE sea level risings that are allegedly just around the corner. -- Rob McEwen From nick at foobar.org Mon Jul 23 11:26:47 2018 From: nick at foobar.org (Nick Hilliard) Date: Mon, 23 Jul 2018 12:26:47 +0100 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: <31f7ccf2-6740-5912-9b19-f3eb46eb7f63@foobar.org> Rob McEwen wrote on 23/07/2018 11:54: > HINT: We won't. For example, look at the blue line at the end of this > "scary graph" from a "climage change" site that has your same viewpoint: > https://insideclimatenews.org/content/average-global-sea-level-rise-1993-2017 > - as scary as that chart looks like at first glance - it shows > little-to-no *acceleration* - the rate of increase holds steady at 3.5 > mm/year - BUT HERE IS THE INTERESTING PART: even this pro-climate change > site's own graph shows that the sea levels have failed to rise AT ALL > over the past couple of years. Little known fact: facts become factier when you use capital letters. Someone said it on the Internet, so it must be true. Nick From theghost101 at gmail.com Mon Jul 23 11:37:00 2018 From: theghost101 at gmail.com (Danijel Starman) Date: Mon, 23 Jul 2018 13:37:00 +0200 Subject: [OT] Internet in China Message-ID: Hi, Can someone suggest a reliable internet provider in China? Are all options China Telecom? Some current links we have in Shanghai are sometimes exhibiting ~40% packet loss to Japan/Singapore AWS regions which is not really acceptable. Off-list replies are welcome too. Thank you! -- *blap* From deleskie at gmail.com Mon Jul 23 11:46:55 2018 From: deleskie at gmail.com (jim deleskie) Date: Mon, 23 Jul 2018 08:46:55 -0300 Subject: [OT] Internet in China In-Reply-To: References: Message-ID: Chinese ISP's typically like to run their links very hot. Don't expect much different if you change providers. -jim On Mon, Jul 23, 2018 at 8:37 AM, Danijel Starman wrote: > Hi, > > Can someone suggest a reliable internet provider in China? Are all > options China Telecom? > > Some current links we have in Shanghai are sometimes exhibiting ~40% packet > loss to Japan/Singapore AWS regions which is not really acceptable. > > Off-list replies are welcome too. > > Thank you! > > -- > *blap* > From rsk at gsp.org Mon Jul 23 12:47:07 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 23 Jul 2018 08:47:07 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: <20180723124707.GA27610@gsp.org> On Mon, Jul 23, 2018 at 10:55:23AM +0300, Saku Ytti wrote: > This seems very imbalanced bet, but > bet lot of people with no training in the subject matter, including > leader of the free world, are willing to take. I often reflect that it's striking how so many people who have no education or training in science and who do not read scientific literature (and in many cases, cannot read scientific literature because they don't comprehend the mathematics), will -- correctly -- be reluctant to express opinions on topics such as the Higgs boson, liquid chromatography, or RNA protocols...while adamantly declaring their opinions on evolution and AGW. Let me suggest that anyone wishing to avail themselves of an entry-level education on this topic begin by reading what it currently the go-to document: the IPCC (Intergovernmental Panel on Climate Change) Fifth Assessment Report, which may be found here: IPCC Fifth Assessment Report https://www.ipcc.ch/report/ar5/index.shtml There are four sections: - The Physical Science Basis (what's happening) - Impacts, Adaptation, and Vulnerability (what the effects are) - Mitigation (what we can do about it) - Synthesis (the big picture) The first one, The Physical Science Basis, underpins the others. It's the synthesis of the work of thousands of the world's climate scientists and the product of exhaustive reviews of the available research. It's lengthy (1552 pages in a 375M PDF) it's painstakingly complete, and it's heavily supported and sourced. It was created by 209 coordinating and lead authors, plus another 600 contributing authors, using -- among other things -- 54,677 written review comments from 1,089 expert reviewers and 38 governments. So this is pretty much the document that you need to read and understand if you want to know what the world's climatology community thinks is going on with the planet. It's here: Climate Change 2013: The Physical Science Basis https://www.ipcc.ch/report/ar5/wg1/ Once you've read this, read the other three sections. When you have finished, let me know, and I'll recommend some other reports, papers, textbooks, etc. Of course you (the rhetorical "you") don't have to do any of this. But don't expect to have a seat at the discussion table unless you've done the homework: you don't deserve one. Note also that the IPCC is preparing a special report, to be finalized in September 2019, focused on the oceans and cryosphere. This will be issued well before the next assessment report, due in 2022. ---rsk From ramy.ihashish at gmail.com Mon Jul 23 13:22:46 2018 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 23 Jul 2018 15:22:46 +0200 Subject: SP security knowledge build up Message-ID: Hello All, I am planning to build up a security team of fresh engineers whom are "network oriented", any advice on the knowledge resources we can start with? We are looking forward to building a concrete foundation of a well-rounded security engineer, we are looking for vendor/operator agnostic resources. Thanks, Ramy From bill at herrin.us Mon Jul 23 13:25:28 2018 From: bill at herrin.us (William Herrin) Date: Mon, 23 Jul 2018 09:25:28 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: On Mon, Jul 23, 2018 at 3:55 AM, Saku Ytti wrote: > On Mon, 23 Jul 2018 at 05:55, Rob McEwen wrote: >> Meanwhile, global warming >> alarmists have ALREADY made MANY dire predictions about oceans levels >> rising - that ALREADY didn't even come close to true. > > Now this discussion does not belong to NANOG, but 'global warming > alarmist' is worrying term to me. What is the perceived harm you're > trying to reduce? Government regulation which results in increased costs. Climate science is interesting and worthy, but it's still too shaky and incomplete to justify trillion dollar decisions. For anyone who would have us Act Now Before It's Too Late, alarmist is the right term. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From ops.lists at gmail.com Mon Jul 23 13:31:40 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 23 Jul 2018 19:01:40 +0530 Subject: SP security knowledge build up In-Reply-To: References: Message-ID: The usual / canonical sysadmin book might work, there is a lot of security related material in there as well. https://www.amazon.com/Practice-System-Network-Administration-Second/dp/0321492668 And this updated for enterprise / devops and other such new fangled things https://www.amazon.com/Practice-System-Network-Administration-Enterprise/dp/0321919165/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=2N4F09FPM9FG9VQNT433 On 23/07/18, 6:55 PM, "NANOG on behalf of Ramy Hashish" wrote: Hello All, I am planning to build up a security team of fresh engineers whom are "network oriented", any advice on the knowledge resources we can start with? We are looking forward to building a concrete foundation of a well-rounded security engineer, we are looking for vendor/operator agnostic resources. Thanks, Ramy From marshall.eubanks at gmail.com Mon Jul 23 13:44:31 2018 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Mon, 23 Jul 2018 09:44:31 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: Message-ID: On Sun, Jul 22, 2018 at 9:01 PM, Sean Donelan wrote: > > https://www.popsci.com/sea-level-rise-internet-infrastructure > > Rising sea levels are going to mess with the internet, sooner than you > think > > The sea level is certainly rising, but post-glacial rebound is also bending the entire East Coast of the United States, which means that parts of the East Coast are sinking into rising oceans. https://www.eenews.net/stories/1059972339 https://www.nasa.gov/feature/goddard/glacial-rebound-the-not-so-solid-earth Unfortunately, that includes the New York city area in the downwards zone. Note that most of the intrinsic sea level change is due to the thermal expansion of upper ocean layers, and that can vary regionally, and this regional variation appears to be driving some of what we see. The sea level in Southern Florida is persistently rising even though it's not entirely clear why (if I had to bet, I'd bet on post-glacial rebound). https://www.fsbpa.com/documents/Florida%20Sea%20Level_rev04042008.pdf Florida sits on very water permeable rock and I would thus worry the most about the Internet infrastructure in Southern Florida, but I suspect anyone there already knows about this. http://www.businessinsider.com/miami-floods-sea-level-rise-solutions-2018-4 Regards Marshall Eubanks > [...] > Despite its magnitude, this network is increasingly vulnerable to sea > levels inching their way higher, according to research presented at an > academic conference in Montreal this week. The findings estimate that > within 15 years, thousands of miles of what should be land-bound cables in > the United States will be submerged underwater. > > “Most of the climate change-related impacts are going to happen very > soon,” says Paul Barford, a computer scientist at the University of > Wisconsin and lead author of the paper. > [...] > From jcurran at arin.net Mon Jul 23 13:47:28 2018 From: jcurran at arin.net (John Curran) Date: Mon, 23 Jul 2018 13:47:28 +0000 Subject: Nominations Open Until 31 July for ARIN Board of Trustees, ARIN Advisory Council, and NRO Number Council Seats Message-ID: <6AE1BBD3-F603-4CF3-86AB-097BAA6B5819@arin.net> Folks - For those of you associated with ARIN member organizations, please note an important deadline fast approaching: the 31st of July is the last day for ARIN Members to nominate candidates to serve on the ARIN Board of Trustees and/or the ARIN Advisory Council. Note that 31 July is also the last day to nominate candidates to represent the ARIN region on the NRO Number Council (and anyone in the community may make such a nomination.) Submit your nomination(s) at https://www.surveymonkey.com/r/ARIN2018Nominations You can out find more information about ARIN elections at: https://www.arin.net/participate/elections/ Each ARIN member organization may cast one ballot in the ARIN Board, ARIN AC elections, and NRO NC elections – voting is done by the organization’s Voting Contact on record. Note that 20 August is the deadline to organizations to establish voter eligibility. More information is available at: https://www.arin.net/about_us/membership/votingcontacts.html (or reach out to members at arin.net with any questions or requests for assistance.) As NRO-NC are open to anyone in the community, those NANOG 74 and ARIN 42 meeting attendees who are registered by 27 September will receive an email invitation to vote online in the NRO NC elections which run from 1-12 October. Thanks! /John John Curran President and CEO American Registry for Internet Numbers (ARIN) From morrowc.lists at gmail.com Mon Jul 23 14:06:44 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 23 Jul 2018 10:06:44 -0400 Subject: SP security knowledge build up In-Reply-To: References: Message-ID: I thought also there was a set of videos from nanog meetings... I can't find a set, but here are some: ISP Security 101 primer https://www.youtube.com/watch?v=ueRminCpnMc isp security real-world techniques - 2 https://www.youtube.com/watch?v=Ijd9A5wUS_0 https://www.youtube.com/watch?v=T6ZSxgVvjdA (older version of previous?) ISP Security toolkits https://www.youtube.com/watch?v=w7XcZS_99WQ NRIC Best Practices for ISP Security https://www.youtube.com/watch?v=1bzL5eUGC-0 there are actually quite a few more, searching for 'security nanog' turned up. On Mon, Jul 23, 2018 at 9:32 AM Suresh Ramasubramanian wrote: > The usual / canonical sysadmin book might work, there is a lot of security > related material in there as well. > > > https://www.amazon.com/Practice-System-Network-Administration-Second/dp/0321492668 > > And this updated for enterprise / devops and other such new fangled things > > > https://www.amazon.com/Practice-System-Network-Administration-Enterprise/dp/0321919165/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=2N4F09FPM9FG9VQNT433 > > > On 23/07/18, 6:55 PM, "NANOG on behalf of Ramy Hashish" > ramy.ihashish at gmail.com> wrote: > > Hello All, > > I am planning to build up a security team of fresh engineers whom are > "network oriented", any advice on the knowledge resources we can start > with? We are looking forward to building a concrete foundation of a > well-rounded security engineer, we are looking for vendor/operator > agnostic > resources. > > Thanks, > > Ramy > > > > From Brian at ampr.org Mon Jul 23 14:54:17 2018 From: Brian at ampr.org (Brian Kantor) Date: Mon, 23 Jul 2018 07:54:17 -0700 Subject: FSEC.OR.KR Message-ID: <20180723145417.GB56343@meow.BKantor.net> Does anyone have a working contact email address for isac at fsec.or.kr? >From time to time we receive a security complaint from them, usually involving an IP address on our network that we know is not in use. They claim to represent the Financial Security Institute(FSI) of Korea, and usually say they may contact law enforcement in both our and their country. They request that we advise them of our action in whatever matter they happen to be complaining about. So far, so good. But... There is no record of fsec.or.kr at the APNIC nor KRNIC. All attempts to reply to these folks are in vain; they reject EVERY reply message - even "hello world" - with the rejection notice that the message contains spam. Before I put them in my 'smtp connection refused' list, I'd like to discuss the matter with them, or to at least let them know that they have a severe CRIS problem. - Brian From matt at netfire.net Mon Jul 23 15:13:48 2018 From: matt at netfire.net (Matt Harris) Date: Mon, 23 Jul 2018 10:13:48 -0500 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: On Mon, Jul 23, 2018 at 8:25 AM, William Herrin wrote: > > > Government regulation which results in increased costs. > > Climate science is interesting and worthy, but it's still too shaky > and incomplete to justify trillion dollar decisions. > > For anyone who would have us Act Now Before It's Too Late, alarmist is > the right term. > > Regards, > Bill Herrin > The United States has lowered carbon emissions while the EU and China continue to increase. https://www.epa.gov/sites/production/files/2018-01/documents/2018_complete_ report.pdf https://rhg.com/research/taking-stock-2018/ https://www.greentechmedia.com/articles/read/european- renewables-are-up-so-are-carbon-emissions#gs.=_L422U I'm not sure exactly what this means, but in general, I think it's fair to say that the US has taken a more market-driven approach that includes working with industry to decrease carbon emissions. During the same time frame the EU, China, and other nations and regions that tend towards more heavy handed top-down regulatory approaches to problems such as this seem to be having trouble making progress and are in fact still headed in the wrong direction. Draw your own conclusions from that. ;) From Rich.Compton at charter.com Mon Jul 23 15:30:56 2018 From: Rich.Compton at charter.com (Compton, Rich A) Date: Mon, 23 Jul 2018 15:30:56 +0000 Subject: SP security knowledge build up In-Reply-To: References: Message-ID: Barry Greene's site has some good info on ISP security as well: http://www.senki.org On 7/23/18, 8:08 AM, "NANOG on behalf of Christopher Morrow" wrote: I thought also there was a set of videos from nanog meetings... I can't find a set, but here are some: ISP Security 101 primer https://www.youtube.com/watch?v=ueRminCpnMc isp security real-world techniques - 2 https://www.youtube.com/watch?v=Ijd9A5wUS_0 https://www.youtube.com/watch?v=T6ZSxgVvjdA (older version of previous?) ISP Security toolkits https://www.youtube.com/watch?v=w7XcZS_99WQ NRIC Best Practices for ISP Security https://www.youtube.com/watch?v=1bzL5eUGC-0 there are actually quite a few more, searching for 'security nanog' turned up. On Mon, Jul 23, 2018 at 9:32 AM Suresh Ramasubramanian wrote: > The usual / canonical sysadmin book might work, there is a lot of security > related material in there as well. > > > https://www.amazon.com/Practice-System-Network-Administration-Second/dp/0321492668 > > And this updated for enterprise / devops and other such new fangled things > > > https://www.amazon.com/Practice-System-Network-Administration-Enterprise/dp/0321919165/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=2N4F09FPM9FG9VQNT433 > > > On 23/07/18, 6:55 PM, "NANOG on behalf of Ramy Hashish" > ramy.ihashish at gmail.com> wrote: > > Hello All, > > I am planning to build up a security team of fresh engineers whom are > "network oriented", any advice on the knowledge resources we can start > with? We are looking forward to building a concrete foundation of a > well-rounded security engineer, we are looking for vendor/operator > agnostic > resources. > > Thanks, > > Ramy > > > > 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 nick at foobar.org Mon Jul 23 15:50:23 2018 From: nick at foobar.org (Nick Hilliard) Date: Mon, 23 Jul 2018 16:50:23 +0100 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> Matt Harris wrote on 23/07/2018 16:13: > I'm not sure exactly what this means, but in general, I think it's fair to > say that the US has taken a more market-driven approach that includes > working with industry to decrease carbon emissions. During the same time > frame the EU, China, and other nations and regions that tend towards more > heavy handed top-down regulatory approaches to problems such as this seem > to be having trouble making progress and are in fact still headed in the > wrong direction. The available data does not support your speculation. > https://data.worldbank.org/indicator/EN.ATM.GHGT.KT.CE?locations=US-EU-CN Nick From tyler at exospec.us Mon Jul 23 04:50:49 2018 From: tyler at exospec.us (Tyler Harden) Date: Mon, 23 Jul 2018 00:50:49 -0400 Subject: Spectrum Outage Message-ID: <95C06C5D-2C41-4934-898F-342BA91D41FB@exospec.us> Any Charter/Spectrum engineers in here? Seems to be a large outage. From ross at tajvar.io Sun Jul 22 14:24:27 2018 From: ross at tajvar.io (Ross Tajvar) Date: Sun, 22 Jul 2018 10:24:27 -0400 Subject: issues through CGNat (juniper ms-mpc-128g in mx960) In-Reply-To: References: <000001d41f6d$a014efd0$e03ecf70$@gvtc.com> <1532265677.2094237.1448903360.1E0DB934@webmail.messagingengine.com> Message-ID: That would be Sony... On Sun, Jul 22, 2018, 10:24 AM Ca By wrote: > On Sun, Jul 22, 2018 at 6:23 AM Radu-Adrian Feurdean < > nanog at radu-adrian.feurdean.net> wrote: > > > On Thu, Jul 19, 2018, at 16:34, Aaron Gould wrote: > > > I don't know if it's fixed on the endpoints, or in the cgnat config or > > what. > > > > Not specific to Juniper, but it's NOT fixed. > > You'll either start spending time on work-arounds or you start selling a > > new service with dedicated public IPv4 - more expensive than the CGNATed > > one. Or you can afford to still delay deploying CGN. > > > Or, do us all a favor, and leave PS4 broken and refer your customers to > Nintendo for them to support ipv6. If you dont, then we all remain hostage > to nintendo and their dedicated ipv4 bs > > > > > From keith at contoocook.net Mon Jul 23 12:47:46 2018 From: keith at contoocook.net (keith at contoocook.net) Date: Mon, 23 Jul 2018 08:47:46 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <20180722211611.B8CD4D0B@m0117460.ppops.net> References: <20180722211611.B8CD4D0B@m0117460.ppops.net> Message-ID: <9fab9797-4c1e-4c76-869e-309fe254d132.maildroid@localhost> I'd be more worried about tidal surge in lower manhattan. Look what t.s. Sandy did in terms of outages. Sent from my android device. -----Original Message----- From: Scott Weeks To: nanog at nanog.org Sent: Mon, 23 Jul 2018 0:16 Subject: Re: Rising sea levels are going to mess with the internet --- rob at invaluement.com wrote: From: Rob McEwen The bottom line is that there is no trend of recently observed sea level rising data that is even close to being on track to hit all these dire predictions within the foreseeable future.... And, again, there were articles like this 10, 15, and even 20 years ago that made very similar predictions - that didn't happen. ------------------------------------------ Maybe the dire predictions didn't happen, but when combined with other drivers stuff happens. For example: https://www.theguardian.com/environment/2016/may/10/headlines-exaggerated-climate-link-to-sinking-of-pacific-islands "The study blamed the loss on a combination of sea-level rise and high wave energy." "The major misunderstanding stems from the conflation of sea-level rise with climate change." "...the ocean has been rising in the Solomon Islands at 7mm per year, more than double the global average." "...driven partly by global warming and partly by climatic cycles - in particular the Pacific Decadal Oscillation." So for us, it's an it depends thing. It depends what cables and where they're located. scott From dorn at hetzel.org Mon Jul 23 13:30:15 2018 From: dorn at hetzel.org (Dorn Hetzel) Date: Mon, 23 Jul 2018 09:30:15 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: What sort of regulations and what sort of associated costs are you talking about, if we can be specific? On Mon, Jul 23, 2018 at 9:26 AM William Herrin wrote: > On Mon, Jul 23, 2018 at 3:55 AM, Saku Ytti wrote: > > On Mon, 23 Jul 2018 at 05:55, Rob McEwen wrote: > >> Meanwhile, global warming > >> alarmists have ALREADY made MANY dire predictions about oceans levels > >> rising - that ALREADY didn't even come close to true. > > > > Now this discussion does not belong to NANOG, but 'global warming > > alarmist' is worrying term to me. What is the perceived harm you're > > trying to reduce? > > Government regulation which results in increased costs. > > Climate science is interesting and worthy, but it's still too shaky > and incomplete to justify trillion dollar decisions. > > For anyone who would have us Act Now Before It's Too Late, alarmist is > the right term. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From bryan at shout.net Mon Jul 23 17:02:51 2018 From: bryan at shout.net (Bryan Holloway) Date: Mon, 23 Jul 2018 12:02:51 -0500 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: <72d8703c-2d26-ab1a-1e7f-bccaa8de0968@shout.net> This thread needs to go elsewhere. On 7/23/18 8:30 AM, Dorn Hetzel wrote: > What sort of regulations and what sort of associated costs are you talking > about, if we can be specific? > > On Mon, Jul 23, 2018 at 9:26 AM William Herrin wrote: > >> On Mon, Jul 23, 2018 at 3:55 AM, Saku Ytti wrote: >>> On Mon, 23 Jul 2018 at 05:55, Rob McEwen wrote: >>>> Meanwhile, global warming >>>> alarmists have ALREADY made MANY dire predictions about oceans levels >>>> rising - that ALREADY didn't even come close to true. >>> >>> Now this discussion does not belong to NANOG, but 'global warming >>> alarmist' is worrying term to me. What is the perceived harm you're >>> trying to reduce? >> >> Government regulation which results in increased costs. >> >> Climate science is interesting and worthy, but it's still too shaky >> and incomplete to justify trillion dollar decisions. >> >> For anyone who would have us Act Now Before It's Too Late, alarmist is >> the right term. >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> From sander at steffann.nl Mon Jul 23 17:05:53 2018 From: sander at steffann.nl (Sander Steffann) Date: Mon, 23 Jul 2018 19:05:53 +0200 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> Message-ID: <54F77CA7-4415-4D77-A71F-FB794B31F059@steffann.nl> Hi, > The available data does not support your speculation. > >> https://data.worldbank.org/indicator/EN.ATM.GHGT.KT.CE?locations=US-EU-CN Maybe it would be more fair to look at CO2 emissions per capita: https://data.worldbank.org/indicator/EN.ATM.CO2E.PC?locations=EU-US-CN Cheers, Sander From jsage at finchhaven.com Mon Jul 23 17:11:53 2018 From: jsage at finchhaven.com (John Sage) Date: Mon, 23 Jul 2018 10:11:53 -0700 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <72d8703c-2d26-ab1a-1e7f-bccaa8de0968@shout.net> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <72d8703c-2d26-ab1a-1e7f-bccaa8de0968@shout.net> Message-ID: <5B560C59.8060800@finchhaven.com> On 07/23/2018 10:02 AM, Bryan Holloway wrote: > This thread needs to go elsewhere. > Seriously. After that 5,000-post long "Proving Gig Speed" thread (that now seems to be entirely bored sysops-sysadmin who check the list once ever few days and reply to four or five posts and then leave for days) and now the Climate Change Deniers troll-of-the-week, it's getting to be about time to unsubscribe. Again. For the fourth or fifth time... - John -- John Sage FinchHaven Digital Photography Web: https://finchhaven.smugmug.com/ Old web: http://www.finchhaven.com/ From eric.kuhnke at gmail.com Mon Jul 23 17:13:14 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 23 Jul 2018 10:13:14 -0700 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: Message-ID: I'm thankfully late to this thread and don't really agree with how operational discussions can devolve into political debates... But from a purely factual, operational consideration point of view at OSI layer 1: There is a very real reason why some facilities are built the way they are. Take a look at "NAP of the Americas", the Terremark-built colo/datacenter/IX point in Miami. It's built to withstand a certain type of hurricane. The first 12 feet of ground level can be flooded and it can remain operational. Its engineering design is a very real consequence of its location in Miami and its critical role related to submarine cable traffic to/from the Caribbean, Latin America and Miami. These Miami-specific design considerations are valid for discussion, the same as earthquake related issues are for critical telecom infrastructure in Seattle, Vancouver or San Francisco. I would be very surprised if the people responsible for budgets and planning of modern cable landing stations were not taking into account extreme weather events, possible sea level rise, and other factors. On Sun, Jul 22, 2018 at 6:01 PM, Sean Donelan wrote: > > https://www.popsci.com/sea-level-rise-internet-infrastructure > > Rising sea levels are going to mess with the internet, sooner than you > think > > [...] > Despite its magnitude, this network is increasingly vulnerable to sea > levels inching their way higher, according to research presented at an > academic conference in Montreal this week. The findings estimate that > within 15 years, thousands of miles of what should be land-bound cables in > the United States will be submerged underwater. > > “Most of the climate change-related impacts are going to happen very > soon,” says Paul Barford, a computer scientist at the University of > Wisconsin and lead author of the paper. > [...] > From owen at delong.com Mon Jul 23 18:03:31 2018 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Jul 2018 11:03:31 -0700 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> Message-ID: > On Jul 23, 2018, at 08:50 , Nick Hilliard wrote: > > Matt Harris wrote on 23/07/2018 16:13: >> I'm not sure exactly what this means, but in general, I think it's fair to >> say that the US has taken a more market-driven approach that includes >> working with industry to decrease carbon emissions. During the same time >> frame the EU, China, and other nations and regions that tend towards more >> heavy handed top-down regulatory approaches to problems such as this seem >> to be having trouble making progress and are in fact still headed in the >> wrong direction. > > The available data does not support your speculation. > >> https://data.worldbank.org/indicator/EN.ATM.GHGT.KT.CE?locations=US-EU-CN > > Nick Actually, the graphic that is at the top of that link does support his claims. It shows China, the most heavy handed of the three economies in the graphic as having an accelerating growth in carbon emissions. It does show that the EU started a downward trend earlier than the US, but that the downward trend in the EU appears to be leveling off and the US downward trend looks to be steeper now and accelerating. In addition, if you drill down to the individual EU countries, several of them are, in fact, headed up while the more market-based members of the EU seem to be headed down or having leveled off after a sharp decline earlier. I don’t want Matt to be right, I’m not a big fan of the “market will solve all” mentality, but, in this case, the data you (Nick) presented does actually appear to largely support his claim. Owen From matt at netfire.net Mon Jul 23 18:22:25 2018 From: matt at netfire.net (Matt Harris) Date: Mon, 23 Jul 2018 13:22:25 -0500 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> Message-ID: On Mon, Jul 23, 2018 at 10:50 AM, Nick Hilliard wrote: > >> The available data does not support your speculation. > > https://data.worldbank.org/indicator/EN.ATM.GHGT.KT.CE?locations=US-EU-CN >> > > Nick > Which data are you referring to? Did you look at the three links that I provided? My linked stats are from the past couple of years, but the worldbank link you posted contains a chart which only comes to 2012 at the latest, six year old data. The EPA report covers 1990-2016, the Rhodium Group report primarily looks at 2005-2016 but also analyzes some information from 2017 and speculates on trends in the coming decades, and the GreentechMedia link specifically looks at the EU and its member states during 2017. So I'm very confused as to which data you're referring to, and which speculation you're referring to, since it seems you're just pointing at data which is several years out of date compared to the information I provided in my post, which I believe to be the best and most recently currently published. From rob at invaluement.com Mon Jul 23 18:28:02 2018 From: rob at invaluement.com (Rob McEwen) Date: Mon, 23 Jul 2018 14:28:02 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> Message-ID: <8ae71bf3-5ab1-10b1-a691-686578a29495@invaluement.com> On 7/23/2018 2:03 PM, Owen DeLong wrote: > Actually, the graphic that is at the top of that link does support his claims. I was thinking that too - but it could ALSO have something to do with the fact that literally hundreds of millions of Indians and Chinese citizens joined the 1st world economy - and started doing things like driving cars - in recent decades. That could be a larger factor than their particular political/economic systems. ALSO: The BEST arguments on this thread for why we should worry about flooding or rising water levels - came from arguments that the actual continents are shifting in ways that cause certain coasts to rise or sink - regardless of the actual overall ocean depth. I don't know much about that - but I do know that (1) THAT particular situation has NOTHING to do with CO2 levels or emissions. (2) the parts of this conversation that does have to do with CO2 levels is specifically based on the theory that (a) high CO2 levels cause warming, which then (b) causes the icecaps to melt, which then causes (c) the sea levels to rise at an accelerated pace (beyond what it did when the overall CO2 levels were lower), as a direct result of increasing levels of CO2 in the atmosphere. but (c) is junk science - since it is NOT happening - the acceleration of sea levels rising beyond an average of 3.5mm/year is almost non-existent - therefore discussions of CO2 levels and emissions unnecessarily politicizes this discussion. Or, at least, the people who are complaining about how this doesn't belong on NANOG (which is a reasonable assessment) - and who complain about "climate deniers" - shouldn't be able to shut down certain factual and logical arguments (that rock their world) - yet not have a problem with continued discussion about CO2 levels and emissions. (that would be hypocritical and unscientific) -- Rob McEwen From Grzegorz at Janoszka.pl Mon Jul 23 19:35:36 2018 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Mon, 23 Jul 2018 21:35:36 +0200 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> Message-ID: On 23/07/2018 20:03, Owen DeLong wrote: > It shows China, the most heavy handed of the three economies in the graphic as having an accelerating growth in carbon emissions. It does show that the EU started a downward trend earlier than the US, but that the downward trend in the EU appears to be leveling off and the US downward trend looks to be steeper now and accelerating. > > In addition, if you drill down to the individual EU countries, several of them are, in fact, headed up while the more market-based members of the EU seem to be headed down or having leveled off after a sharp decline earlier. The data is flawed. The carbon emissions per country don't include import, so you can just import the most carbon-heavy product from China and you will see your country emissions falling and China's growing. And the carbon emission of USA doesn't include Pentagon, while any other army is included in it's country numbers. So we can' really compare such flawed data - these are just numbers for politicians but they have nothing in common with reality. Regarding rising sea levels - I wonder why nobody mentioned submarine fiber landing stations. If something will be affected, it will be them. -- Grzegorz Janoszka From bob at FiberInternetCenter.com Mon Jul 23 20:18:00 2018 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 23 Jul 2018 13:18:00 -0700 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> Message-ID: <488acace585476e29d40ffc79d69b026.squirrel@66.201.44.180> How much ocean water displacement is taking place in Hawaii as a result of eruptions? How about volcanoes we don't know about deep in the ocean? In the last 5 years, California governments have played a negative roll in the burning of well over a million acres. These carbon emissions are rarely calculated and considered as a cause of global warming. How many California miles driven in cars = one 250,000 acre fire? I don't know. Did you know there are adults in California that don't think burning trees emit carbon emissions that count unless it happens in a man made fireplace ? Yes, most of those people went to high school in California. But anyways - can we please drop the non-internet related discussions from filling my nanog filtered technical email folders? Lots of smart people to have discussions with in nanog...maybe we create a list called nanog-other-stuff at nanog.org Thank You Bob Evans CTO > On 23/07/2018 20:03, Owen DeLong wrote: >> It shows China, the most heavy handed of the three economies in the >> graphic as having an accelerating growth in carbon emissions. It does >> show that the EU started a downward trend earlier than the US, but that >> the downward trend in the EU appears to be leveling off and the US >> downward trend looks to be steeper now and accelerating. >> >> In addition, if you drill down to the individual EU countries, several >> of them are, in fact, headed up while the more market-based members of >> the EU seem to be headed down or having leveled off after a sharp >> decline earlier. > > The data is flawed. The carbon emissions per country don't include > import, so you can just import the most carbon-heavy product from China > and you will see your country emissions falling and China's growing. > > And the carbon emission of USA doesn't include Pentagon, while any other > army is included in it's country numbers. > > So we can' really compare such flawed data - these are just numbers for > politicians but they have nothing in common with reality. > > Regarding rising sea levels - I wonder why nobody mentioned submarine > fiber landing stations. If something will be affected, it will be them. > > -- > Grzegorz Janoszka > From bill at herrin.us Mon Jul 23 20:31:40 2018 From: bill at herrin.us (William Herrin) Date: Mon, 23 Jul 2018 16:31:40 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <488acace585476e29d40ffc79d69b026.squirrel@66.201.44.180> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> <488acace585476e29d40ffc79d69b026.squirrel@66.201.44.180> Message-ID: On Mon, Jul 23, 2018 at 4:18 PM, Bob Evans wrote: > How much ocean water displacement is taking place in Hawaii as a result of > eruptions? How about volcanoes we don't know about deep in the ocean? Not much on a global scale. The rift that has been erupting for what's it been, 3 months or so now? That's added a little over a square mile of coast, all of it where shallow water used to be. https://volcanoes.usgs.gov/observatories/hvo/maps_uploads/image-521.jpg I plan to retire on the slope of a different volcano, so I've been watching with interest. > In the last 5 years, California governments have played a negative roll in > the burning of well over a million acres. These carbon emissions are > rarely calculated and considered as a cause of global warming. How many > California miles driven in cars = one 250,000 acre fire? I don't know. Greenhouse gasses are also emitted when dead plant matter rots in the forest. Not as quickly but there's a whole lot of it. https://msutoday.msu.edu/news/2017/decomposing-leaves-are-a-surprising-source-of-greenhouse-gases/ > But anyways - can we please drop the non-internet related discussions from > filling my nanog filtered technical email folders? Apparently not. ;) Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From amitchell at isipp.com Mon Jul 23 20:38:44 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Mon, 23 Jul 2018 14:38:44 -0600 Subject: Cox contact? Message-ID: Does anybody have a contact at Cox (need networking but I'd take anything)? Thank you! Anne Anne P. Mitchell, Attorney at Law GDPR & CCPA Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Association Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From me at anuragbhatia.com Mon Jul 23 20:58:49 2018 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 24 Jul 2018 02:28:49 +0530 Subject: Question about bird RS config with BGP Community support Message-ID: Hello, We are running a small IX fabric (in Mumbai, India) and with multiple route servers based on a bird. There has been a demand of support of BGP communities from some of our members and I am trying to find a way to set it up in the bird. Idea is to provide a community say 0:123 where tagged routes with 0:123 do not reach AS123. I am new to the bird. Tried testing with config given here - https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_based_filtering_and_single_RIB and that results in no announcement peer where the route is going out. (No specific comms even used. Just applying the export config results in a drop of the route announcement). I also tried other config example given over there for putting routes of each peer in their table (as per https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_based_filtering_and_multiple_RIBs) and behaviour is same. No route announcement to peers. Was wondering if anyone can point to right config to support BGP communities? Thanks! -- Anurag Bhatia anuragbhatia.com From valdis.kletnieks at vt.edu Mon Jul 23 21:00:54 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 23 Jul 2018 17:00:54 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: <38544.1532379654@turing-police.cc.vt.edu> On Mon, 23 Jul 2018 09:25:28 -0400, William Herrin said: > Climate science is interesting and worthy, but it's still too shaky > and incomplete to justify trillion dollar decisions. So cleaner, less polluting energy sources don't justify it right there? Check the air quality in Beijing or parts of India for a non-climate-change reason to get off fossil fuel. Also, we're going to run out of fossil fuels at some point, and delaying that point by lowering our us of them is worth it right there. We're resorting to fracking to get out oil that wasn't economical before - and it's making more of a mess than ever before. > For anyone who would have us Act Now Before It's Too Late, alarmist is > the right term. Do you want to get out of South Florida real estate before or after the bubble pops? At some point, banks are going to start refusing to write mortgages for the Miami area due to recurrent flooding - at which point all the real estate will be underwater once their land values plummet (pun intended). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From job at instituut.net Mon Jul 23 21:05:15 2018 From: job at instituut.net (Job Snijders) Date: Mon, 23 Jul 2018 23:05:15 +0200 Subject: Question about bird RS config with BGP Community support In-Reply-To: References: Message-ID: On Mon, 23 Jul 2018 at 23:00, Anurag Bhatia wrote: > We are running a small IX fabric (in Mumbai, India) and with multiple > route servers based on a bird. There has been a demand of support of BGP > communities from some of our members and I am trying to find a way to set > it up in the bird. Idea is to provide a community say 0:123 where tagged > routes with 0:123 do not reach AS123. I am new to the bird. I strongly recommend to either use “arouteserver” or “IXP manager” to generate the BIRD configuration files on your behalf, and no type it by hand. Setting up a fully featured secure route server is a lot of work and research, I’d really recommend to leverage the work others have done in this problem space. I fear otherwise you may risk repeating mistakes that others already made. https://arouteserver.readthedocs.io/en/latest/ https://github.com/pierky/arouteserver https://www.ixpmanager.org/ And using these automated tools means less work for the IX operator. Turning up new peers is a breeze with both tools! Kind regards, Job > From raphael.timothy at gmail.com Mon Jul 23 21:28:05 2018 From: raphael.timothy at gmail.com (Tim Raphael) Date: Tue, 24 Jul 2018 07:28:05 +1000 Subject: Question about bird RS config with BGP Community support In-Reply-To: References: Message-ID: <37C02BC2-5918-4AE1-B2C1-319D49AD6B1F@gmail.com> As an operator of large, established IXP I would also recommend this path. A lot of work had gone into the likes of IXPManager and arouteserver and they provide great value in providing secure configurations with added features such as action communities you are after. Cheers, Tim > On 24 Jul 2018, at 7:05 am, Job Snijders wrote: > >> On Mon, 23 Jul 2018 at 23:00, Anurag Bhatia wrote: >> >> We are running a small IX fabric (in Mumbai, India) and with multiple >> route servers based on a bird. There has been a demand of support of BGP >> communities from some of our members and I am trying to find a way to set >> it up in the bird. Idea is to provide a community say 0:123 where tagged >> routes with 0:123 do not reach AS123. I am new to the bird. > > > I strongly recommend to either use “arouteserver” or “IXP manager” to > generate the BIRD configuration files on your behalf, and no type it by > hand. > > Setting up a fully featured secure route server is a lot of work and > research, I’d really recommend to leverage the work others have done in > this problem space. I fear otherwise you may risk repeating mistakes that > others already made. > > https://arouteserver.readthedocs.io/en/latest/ > https://github.com/pierky/arouteserver > https://www.ixpmanager.org/ > > And using these automated tools means less work for the IX operator. > Turning up new peers is a breeze with both tools! > > Kind regards, > > Job > >> From goemon at sasami.anime.net Mon Jul 23 21:51:14 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Mon, 23 Jul 2018 14:51:14 -0700 (PDT) Subject: looking for collaborating data for phishing email Message-ID: Anyone who recently received the following phishing email, please drop me an email. I'm looking for collaborating data on an email database breach. Date: Wed, 18 Jul 2018 06:36:19 -0400 Return-Path: Received: from amp3.nuskin.com (amp3.nuskin.net [170.89.24.19] (may be forged)) From: American Express To: americanexpress at aep.com Subject: Act Now: Information About your Cardmember Account. -Dan From rdobbins at arbor.net Mon Jul 23 22:36:35 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 24 Jul 2018 05:36:35 +0700 Subject: SP security knowledge build up In-Reply-To: References: Message-ID: <2FFDE720-89FE-4DA2-9B9D-96F6A52D4BC8@arbor.net> On 23 Jul 2018, at 22:30, Compton, Rich A wrote: > Barry Greene's site has some good info on ISP security as well: Here're some more: This book is also highly recommended: ----------------------------------- Roland Dobbins From rfg at tristatelogic.com Tue Jul 24 04:28:14 2018 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 23 Jul 2018 21:28:14 -0700 Subject: AS205869, AS57166: Featured Hijacker of the Month, July, 2018 Message-ID: <27526.1532406494@segfault.tristatelogic.com> Before I get into talking about this month's honorary Hijacker of the Month, I really must start by thanking everyone who pitched in and helped to insure an appropriate response and outcome for the BitCanal case, which I reported here last month. You all know who you are, and I won't explicitly name you here, only because most of you have expressed to me privately that you would prefer it if I didn't. But you folks deserve the lion's share of the credit, and I, in contrast, played only the most minor supporting role. I must also say that I was astonished and very pleasantly surprised by the very effective and, to-date, very nearly 100% effective response to my call to action with respect to Bitcanal. This thief, Joao Silveira, aka Mr. Bitcanal, and his business are still limping along, and, I'm sure, trying desperately to get back online after everybody with half a brain became convinced of what he has been up to for lo these past several years. He's apparently managed to at least get his main web site (www.bitcanal.com) back online, but now he's totally dependent on GoDaddy hosting for that. :-) I guess that he doesn't have a whole lot of IP space to call his own anymore, or any least not very much of it that he can actually get anyone to route for him. I should also offer my apologies for the rather deliberately rude way that I got right up into the faces of Cogent, GTT, and Level3, right here on the NANOG list, with regards to BitCanal. I see now that that was really rather completely unfair and uncalled for. All three took swift and appropriate action once they became fully aware of the issue/problem, and I am grateful to all of them for their prompt action, and also, of course, I am equally grateful also to the many other providers and IXes who also took appropriate action in this case. Following my posting last month about BitCanal, at least one person rightly took me to task for the rude way I approached the problem, and even moreso for the fact that I escalated the problem to this list as my first response to the whole issue. With 20/20 hindsight, I can now only agree with those criticisms. I shouldn't have done that. I am pleased with the final result, i.e. Bitcanal being kicked from essentially the whole Internet, but the ends do not justify the rather hamfisted means I elected to employ. I will try to do better in future. With that in mind, when I recently found another such operation... another entity performing an entire set of obviously very deliberate hijacks, evidently for the purpose of leasing the hijacked space to snowshoe spammers... I took what I had learned from the BitCanal case and applied it. In particular, rather than me having a very public tantrum and getting on the cases of each and every company that bgp.he.net said might be connected to the hijacker somehow, I instead began by running traceroutes to all of the relevant hijacked blocks. (If I would have had the good sense to have done this in the BitCanal case, I most probably would have begun by just hasseling Cogent alone, and privately, off list, since from where I sit, all of the traceroutes to all the blocks that Bitcvanal stole had Cogent as the next-to-last hop. YMMV) Anyway, in this new case I found that the next-to-last hop for all of the relevant traceroutes was a set of routers belonging to Telecom Italia. Rather than calling them out here, this time I had the good sense to just message TelecomItalia directly about the issue. it took me a couple of tries, but I was eventually able to find a proper contact address for a proper sort of person to discuss this matter with @ Telecom Italia. The two links below are (1) my message to them and (2) their very nice and proactive response back to me: Me -> Telecom Italia https://pastebin.com/raw/Ek3mxKCR Telecom Italia -> Me https://pastebin.com/raw/mtcA4Ehy Given that I sent my message to them well after business hours on Friday, I consider their response, sent on Monday, to be super-fast and very responsive. Of course, I am absolutely ecstatic also that they have elected to stop all routing to the particular bunch of of badness that I explicitly called out to them, at least for the time being. As you can all see, my message to TelecomItalia describes the issue/problem with AS205869 - Universal IP Solution Corp. in some considerable detail. In a nutshell, these guys are criminals and they've been reselling the IPv4 space they've hijacked, specifically but perhaps not only to snowshoe spammers. (Specific evidence available upon request.) Of course, one can easily imagine even vastly worse uses that may be made of stolen IP space. By the time that I personally became aware of what these specific jerks were up to, they had already used, abused, and tossed aside several other IPv4 blocks -and- also a number of other previously abandoned ASNs. (They have been absconding with -both- abandoned IPv4 address blocks -and- also a number of previously abandoned ASNs... as well as one that was/is in active use by its legitimate owner. And they have bee doing so without any apparent restraint watever.) The evidence of all this is crystal clear from a quick review of all of the relevant RIPE records. They left their bloody fingerprints all over this mess. Anyway, by the time I noticed them. late last week, the set of routes and ASNs that this particular set of crooks were still fradulently using were as follows: ASN Route ---------------------- 10510 216.238.64.0/18 10737 207.183.96.0/20 10800 192.110.32.0/19 19529 104.143.112.0/20 19529 198.14.0.0/20 19529 198.32.208.0/20 19529 206.41.128.0/20 30237 192.73.128.0/20 30237 192.73.144.0/20 30237 192.73.160.0/20 30237 192.73.176.0/20 (The above list was present also in my private message to TelecomItalia. See link above.) I suspect that perhaps the fact that the final four routes in the list above are for IPv4 space which is formally registered to the United States Air Force may possibly have contributed somewhat to TelecomItalia's apparent readiness and willingness to take swift and decisive action in this case. (It's not every day that you see USAF IP space being routed by mysterious Ukranian networks. :-) In any case, as I've noted above, I am greatly pleased that TelecomItalia took the action it did, regardless of what factors may have entered into their decision. At this point in my presentation, anyone who might have been expecting another "call to arms", like my posting here last month, will be disappointed. I'd greatly appreciate it if readers of this post would help me to to confirm that the non-routing of the above block is both universal and complete... as it is, at least, from where I am sitting... but at this point I have nothing and nobody to rail against. (Or so I thought! But while writing this post I found some new and apparently associated curiosities relating to a different ASN, AS57166. Read on!) So, anyway with regards to AS205869... case closed? Is it Miller time? Well, yes and no. There's still the question of just who or what the devil is this thing called Universal IP Solution Corp. (which also, apparently, goes by the name of "ADMASTER-MNT" within RIPE WHOIS records). And then there is the question of what there is to prevent these hijackers from just coming back tomorrow under a different guise or corporate identity and starting the game all over again. Even more worrying is the distinct possibility that they may not even find it necessary to change out their current corporate identity before getting back into the game. They could just keep their current name... as BitCanal did... and try to reroute their connectivity via one of their other existing peers. The (ostensible) list of those is shown here: https://bgp.he.net/AS205869#_peers These crooks may have already anticipated the small setback of losing their TelecomItalia connection, and as you can see, they already have nine listed IPv4 peers, although at least four of these are provably ones that they themselves have been masquerading as, specifically: AS11717 Solarus AS7827 American Business Information AS11324 BRFHH Shreveport, LLC AS32226 Menard, Inc. The above ASNs have all been hijacked by the folks using the handle ADMASTER-MNT. The RIPE WHOIS records essentially prove that. (Menard, Inc., by the way, is a chain of retail home improvement stores, comparable to HomeDepot, located in the U.S. MidWest region. Hardly the kind of place you'd expect to be peering with mysterious Ukranian company, -or- to be indirectly routing space... 216.238.64.0/18... for a long-dead Pennsylvania ISP such as Razor, Inc. The case of BRFHH Shreveport, LLC is arguably more worrying than any of the rest of this, because in that case the hijackers apparently didn't even care that the ASN in question was still in active use by its rightful owners, uhsystem.com, which appears to be a University-based hospital in Louisiana. HIPPA horrors easily imaginable!) Anyway, eliminating the ASNs above, we are still left with multiple possible "Plan Bs" for this hijacking operation: AS6762 Telecom Italia <============== plug already pulled AS8359 MTS PJSC (Russia) AS1299 Telia Company AB (Sweden) AS35320 Eurotranstelecom Ltd. (Ukraine) AS57166 D2 International Investment Ukraine Ltd. Now that Telecom Italia has pulled the plug, I'll be emailing to the other peers listed above, and asking them to do likewise. We'll just have to wait and see what they do. But there is one ASN from the above list that I quite definitely -won't- be sending any emails to, and that's the last one, D2 International Investment Ukraine Ltd. AS57166, D2 International Investment Ukraine Ltd. was a name already known to me. It came up previously, right here on this mailing list, in the context of a discussion I had started here on October 5th, 2016 relating to a previous set of hijacks that I had reported here: https://mailman.nanog.org/pipermail/nanog/2016-October/088487.html This thing, whetever it is, has/had a peering relationship, both then and now, with AS29632 Netassist Limited, which is headquartered in... ummm... Ukraine. No. Wait. Make that Gibraltar. Anyway, we'll come back to that a bit latter on. Back in the day, D2 International Investment Ukraine Ltd. was using two different ASNs, i.e. AS43659 and AS57166. As of now, it doesn't seem to be using the former for much of anything: https://bgp.he.net/AS43659 AS57166 is a rather different story however. The listing of IPv4 peers shown currently at bgp.he.net (https://bgp.he.net/AS57166#_peers) shows the following as current peers of AS57166: AS205869 Universal IP Solution Corp. AS29632 Netassist Limited AS11695 TheStreet.Com AS8011 CoreComm Internet Services Inc The first two are (or were) headquartered in Ukraine, so other than the fact that Universal IP Solution Corp. is hip deep in IP address space thievery, those two are unremarkable as peers for D2 International Investment Ukraine Ltd. which is also allegedly located in Ukraine. That third one should come as a bit of a shock to anyone who has ever had the privlege (or misfortune, depending on your point of view) of watching "Mr. Booyah" Jim Cramer attempts to make the muundane world of stock trading entertaining for the masses. TheStreet.com is a highly popular web destination belonging to a company of the same name which was founded by the same said Mr. Jim Cramer. From Wikipedia: TheStreet, Inc. is an American financial news and services website founded by Jim Cramer and Martin Peretz. How does a company like this get mixed up with a bunch of Ukranians of dubious repute?? Well, quite simply they don't. The ASN has been hijacked by AS57166 -- D2 International Investment Ukraine Ltd. As we speak, D2 International Investment Ukraine Ltd. is using this hijacked ASN, AS11695 -- TheStreet.Com for an ongoing set of hijacks, mostly of abandoned legacy IPv4 space belonging to various defunct U.S. companies, but with one Canadian block (69.171.160.0/19) and one Mongolian block (192.82.64.0/19) mixed in just to give this portfolio of hijacks a bit of an international flavor, I suppose. The list of blocks currently announced by AS11695, according to stat.ripe.net, is as follows: 24.137.0.0/20 24.137.0.0/19 24.137.16.0/20 24.236.0.0/19 52.128.192.0/19 66.219.64.0/19 68.232.96.0/20 69.171.160.0/19 70.34.192.0/20 70.34.192.0/19 70.34.208.0/20 98.143.176.0/20 163.123.192.0/20 163.123.192.0/18 163.123.208.0/20 163.123.224.0/20 163.123.240.0/20 192.82.64.0/19 192.254.32.0/19 198.40.192.0/19 204.195.192.0/18 206.15.32.0/19 206.54.128.0/20 206.125.0.0/19 206.127.224.0/19 206.190.160.0/19 206.222.128.0/19 206.246.32.0/19 207.183.64.0/19 209.182.0.0/20 209.182.0.0/18 209.182.16.0/20 209.182.32.0/20 209.182.48.0/20 This is quite an impressive list, even if it does fall a bit short of the recent and slightly more prodigious escapades of Bitcanal. I've run a few traceroutes on a few of the above routes and I've found them to have next-to-last hops within the same batch of Telcom Italia routers as were being used by the batch of hijacks that were easily tracable back to AS205869 - Universal IP Solution Corp. Not a real huge surprise there. AS205869 is peering with AS57166 and vise versa. They are both quite obviously working together on this grand hijacking scheme. Of course, I will shortly be initiating another friendly and, I hope, equally productive chat with my new friend @ Telecom Italia regarding these additional blatant and obvious hijacks. I have so far neglected to mention the forth and final peer of AS57166, i.e. AS8011 -- CoreComm Internet Services Inc. Based on my reading of he relevant RIPE records, this ASN appears to have been registered with RIPE on or about 2017-01-12 by whoever was in control of the RIPE handle "DATASTAR-MNT" as of that date. It appears to me that, with a few exceptions, such as the RIPE WHOIS record for this ASN, pretty much everything else that has been created and installed into the RIPE WHOIS data base by "DATASTAR-MNT" is fundamentally fradulent. Here is the full list of such stuff: https://pastebin.com/raw/DQbWe0gq By extension from this premise, I think that it may be reasonably assumed that any routes currently being announced by AS8011 are most likely also hijacks. As of now, this seems to be limited to only one single route: 216.127.0.0/19. This IPv4 block would seem to have been yet another abandoned IPv4 block that was just left lying around, and which has now been very effectively repurposed in service of the hijackers' preferred ends. Finally, as some may have noted, there is one rather glaring hole in the story it has been presented above, specifically, the true and verifiable identities of the hijackers, which remain cloaked in mystery. D2 International Investment Ukraine Ltd. historically used the domain name etthua.net as part of its contact email address, but that domain currently has no DNS, and data from archives suggests that it may have never had a functioning web site. RIPE NCC undoubtedly has the name of some specific individual to go along with this corporate front name, but even before the advent of the travesty that is GDPR, they almost certainly would refuse to divulge that to any party, based on their traditional strict contractual code of omerta. A page on virustotal seems to suggest a connection of some sort between D2 International Investment Ukraine Ltd. and the now notorious coinhive scam, but it is not at all clear how this connection was derived or even whether there actually is any real connection at all: https://www.virustotal.com/#/ip-address/94.130.90.152 Googling now, I see that I myself called out this crooked enterprise on a RIPE mailing list back on 2016-10-08. (I didn't really remember doing that, as it has been nearly 2 years ago now.) https://www.ripe.net/participate/mail/forum/anti-abuse-wg/PDMxNjk3LjE0NzU5NjAwMzhAc2VnZmF1bHQudHJpc3RhdGVsb2dpYy5jb20+ I also have no specific recollection of this follow-up post by a rather outspoked fellow who goes by the name of Marilson, and who has frequently appeared to drink even substantially more coffee than I do: https://lists.ripe.net/pipermail/anti-abuse-wg/2016-October/003726.html I myself have no direct knowledge of the "Samuel Joel Nirushan" that Marilson spoke of, or about any of Mr. Marilson's specific allegations against him (including that this Mr. Nirushan is even connected in any way to D2 International Investment Ukraine Ltd.) but I did find that if one simply googles for "Samuel Joel Nirushan" or alternatively, for "D2 International Investments" (note: plural, rather than singular) one quickly comes upon a plethora of public postings made by -somebody- who was apparently quite angry at this guy, many most or all of which seem to date from October, 2011, and all of which contain many of the same unsubstantiated allegations of fradulent activities. As these allegations are not accompanied by any relevant documentation, then must be judged to only be worth even less that the electrons they were written on. Arguably more relevant is this archived RIPE WHOIS record that I found online and which appears to show that D2 International Investment Ukraine Ltd. was formerly granted a sub-allocation of IPv4 space which, at that time, and also currently, is registered to NetAssist, Ltd (Ukraine): https://pastebin.com/raw/95LRyvwv This, taken together with the fact that NetAssist, Ltd (AS57166) is currently peering with AS57166 - D2 International Investment Ukraine Ltd., ertainly suggest a strong business relationship between the Netassist and D2, whatever the hell it is. Returning briefly to the other obviously crooked actor in this drama, i.e. AS205869 - Universal IP Solution Corp., it is worth mentioning that this company, like D2 International Investment, also has a domain that is used as part of its contact email address, universalipsolution.bz (BZ -- Belize??) but this domain also, like etthua.net for D2, does not currently have any web site, and based on my reading of historical passive DNS data, it appears that it may have -never- have had one. Nontheless, both D2 International Investments and Universal IP Solution are both members in good standing of RIPE: https://www.ripe.net/membership/indices/data/ua.d2investukraine.html https://www.ripe.net/membership/indices/data/bz.universal.html So, you know, one wonders how these two crooked companies that are clearly colluding together to hijack lots and lots of IP space are then able to somehow turn around and make a profit by selling off bits and pieces of what they have stolen when neither of them even have any web site via which they could entice eager buyers of their stolen property. This is an enigma, but I have a theory that seems at least possible. RIPE provides many useful services to its members, but there is one in particular that I personally have become acquainted with only quite recently. RIPE NCC apparently maintains a list of what they call "Recognised IPv4 Transfer Brokers": https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/brokers As noted on the above page "there are no costs involved" in being admitted to this prestigious and exclusive club, "...however, you will need to agree to adhere to the relevant RIPE Policies and RIPE NCC procedural documents..." >From these public statements of the RIPE web site I infer that as long as one can fog a mirror, and as long as one is willing and able to raise one's right hand and swear on some sort of religious text, one can be and will be admitted into this special club of "recognised" IP brokers. One company listed on the above page that caught my eye is NetAssist LLC, formerly of Ukraine, but more recently re-incorporated in the jurisdiction of Gibraltar. (Why the company elected to up and change jurisdictions is not immediately obvious.) Whereas neither Universal IP Solution Corp. nor their apparent partners in crime, D2 International Investment Ukraine Ltd. have any web sites, and whereas they both thus have no apparent means of easily reselling/ offloading/fencing any or all of the IP space that the two of them together have stolen, it appears that D2's friend and peer, NetAssist LLC, is already well positioned to barter blocks of IPv4 space that may have unexpectedly gone walkabout. This is not to say that they have done so. I have no direct evidence of that. I just personally find NetAssist's formal registration, with RIPE, as an "recognized" IP broker to be a possibly relevant detail, and one that may perhaps be exceptionally convenient, under the curcumstances. Plesse note that Bitcanal, using its full, formal, and legal name of Ebonyhorizon Telecomunicacoes Lda., is also still a member in good standing of not only RIPE, but also of RIPE's cadre of "Recognised IPv4 Transfer Brokers". (See link above.) To reiterate, I have posted all of this information here on the NANOG list, not as a call to action... I'll be trying myself to contact any and all relevant providers and encouraging them to take appropriate action... but rather just because I felt that people here on this list might want to at least be aware of all of these convoluted shenanigans and schemes. Certainly, I encourage everyone reading this to be extra vigilant, in future, and especially if you are approached in the near future by any Ukrainian (or Gibraltarian) networks requesting peering. Regards, rfg P.S. It is left as an exercise for the reader as to why these sorts of large scale hijacking schemes always seem to originate somewhere within the RIPE geographical region and never elsewhere. From sthaug at nethelp.no Tue Jul 24 07:03:16 2018 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 24 Jul 2018 09:03:16 +0200 (CEST) Subject: AS205869, AS57166: Featured Hijacker of the Month, July, 2018 In-Reply-To: <27526.1532406494@segfault.tristatelogic.com> References: <27526.1532406494@segfault.tristatelogic.com> Message-ID: <20180724.090316.47077931.sthaug@nethelp.no> > I'd greatly appreciate it if readers of this post would help me to to confirm > that the non-routing of the above block is both universal and complete... > as it is, at least, from where I am sitting... but at this point I have > nothing and nobody to rail against. (Or so I thought! But while writing > this post I found some new and apparently associated curiosities relating > to a different ASN, AS57166. Read on!) All prefixes still visible here (Oslo, Norway), through HE. Here's your original table augmented with the AS paths I see on our border routers: ASN Route AS path ----------------------------------------------- 10510 216.238.64.0/18 6939 205869 32226 10510 10737 207.183.96.0/20 6939 205869 7827 10737 10800 192.110.32.0/19 6939 205869 11717 10800 19529 104.143.112.0/20 6939 205869 11324 19529 19529 198.14.0.0/20 6939 205869 7827 19529 19529 198.32.208.0/20 6939 205869 7827 19529 19529 206.41.128.0/20 6939 205869 11324 19529 30237 192.73.128.0/20 6939 205869 11717 30237 30237 192.73.144.0/20 6939 205869 11717 30237 30237 192.73.160.0/20 6939 205869 11717 30237 30237 192.73.176.0/20 6939 205869 11717 30237 Steinar Haug, Nethelp consulting, sthaug at nethelp.no From ramy.ihashish at gmail.com Tue Jul 24 09:03:53 2018 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Tue, 24 Jul 2018 11:03:53 +0200 Subject: SP security knowledge build up In-Reply-To: References: Message-ID: Thank you Christopher, Compton and Suresh, that was helpful. I am still looking for more. Does anyone want to recommend any MOOC? Thanks, Ramy On 23 July 2018 at 17:30, Compton, Rich A wrote: > Barry Greene's site has some good info on ISP security as well: > http://www.senki.org > > On 7/23/18, 8:08 AM, "NANOG on behalf of Christopher Morrow" < > nanog-bounces at nanog.org on behalf of morrowc.lists at gmail.com> wrote: > > I thought also there was a set of videos from nanog meetings... > I can't find a set, but here are some: > > ISP Security 101 primer > https://www.youtube.com/watch?v=ueRminCpnMc > > isp security real-world techniques - 2 > https://www.youtube.com/watch?v=Ijd9A5wUS_0 > https://www.youtube.com/watch?v=T6ZSxgVvjdA (older version of > previous?) > > ISP Security toolkits > https://www.youtube.com/watch?v=w7XcZS_99WQ > > NRIC Best Practices for ISP Security > https://www.youtube.com/watch?v=1bzL5eUGC-0 > > there are actually quite a few more, searching for 'security nanog' > turned > up. > > On Mon, Jul 23, 2018 at 9:32 AM Suresh Ramasubramanian < > ops.lists at gmail.com> > wrote: > > > The usual / canonical sysadmin book might work, there is a lot of > security > > related material in there as well. > > > > > > https://www.amazon.com/Practice-System-Network- > Administration-Second/dp/0321492668 > > > > And this updated for enterprise / devops and other such new fangled > things > > > > > > https://www.amazon.com/Practice-System-Network- > Administration-Enterprise/dp/0321919165/ref=pd_lpo_sbs_14_ > t_0?_encoding=UTF8&psc=1&refRID=2N4F09FPM9FG9VQNT433 > > > > > > On 23/07/18, 6:55 PM, "NANOG on behalf of Ramy Hashish" > > > ramy.ihashish at gmail.com> wrote: > > > > Hello All, > > > > I am planning to build up a security team of fresh engineers > whom are > > "network oriented", any advice on the knowledge resources we can > start > > with? We are looking forward to building a concrete foundation > of a > > well-rounded security engineer, we are looking for > vendor/operator > > agnostic > > resources. > > > > Thanks, > > > > Ramy > > > > > > > > > > > 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 ops.lists at gmail.com Tue Jul 24 09:06:36 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 24 Jul 2018 14:36:36 +0530 Subject: SP security knowledge build up In-Reply-To: References: Message-ID: <8EAF16BD-BD83-4C89-AB5A-B7101988D92B@gmail.com> Not a MOOC.  But several schools now have graduate programs in security.  Off the top of my head, Georgia Tech, UAB, GMU .. They might offer some shorter courses as well, for working professionals.   Take a look. From: Ramy Hashish Date: Tuesday, 24 July 2018 at 2:33 PM To: "Compton, Rich A" Cc: Christopher Morrow , Suresh Ramasubramanian , nanog list Subject: Re: SP security knowledge build up Thank you Christopher, Compton and Suresh, that was helpful. I am still looking for more. Does anyone want to recommend any MOOC? Thanks, Ramy On 23 July 2018 at 17:30, Compton, Rich A wrote: Barry Greene's site has some good info on ISP security as well: http://www.senki.org On 7/23/18, 8:08 AM, "NANOG on behalf of Christopher Morrow" wrote: I thought also there was a set of videos from nanog meetings... I can't find a set, but here are some: ISP Security 101 primer https://www.youtube.com/watch?v=ueRminCpnMc isp security real-world techniques - 2 https://www.youtube.com/watch?v=Ijd9A5wUS_0 https://www.youtube.com/watch?v=T6ZSxgVvjdA (older version of previous?) ISP Security toolkits https://www.youtube.com/watch?v=w7XcZS_99WQ NRIC Best Practices for ISP Security https://www.youtube.com/watch?v=1bzL5eUGC-0 there are actually quite a few more, searching for 'security nanog' turned up. On Mon, Jul 23, 2018 at 9:32 AM Suresh Ramasubramanian wrote: > The usual / canonical sysadmin book might work, there is a lot of security > related material in there as well. > > > https://www.amazon.com/Practice-System-Network-Administration-Second/dp/0321492668 > > And this updated for enterprise / devops and other such new fangled things > > > https://www.amazon.com/Practice-System-Network-Administration-Enterprise/dp/0321919165/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=2N4F09FPM9FG9VQNT433 > > > On 23/07/18, 6:55 PM, "NANOG on behalf of Ramy Hashish" > ramy.ihashish at gmail.com> wrote: > > Hello All, > > I am planning to build up a security team of fresh engineers whom are > "network oriented", any advice on the knowledge resources we can start > with? We are looking forward to building a concrete foundation of a > well-rounded security engineer, we are looking for vendor/operator > agnostic > resources. > > Thanks, > > Ramy > > > > 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 lobna_gouda at hotmail.com Tue Jul 24 09:39:57 2018 From: lobna_gouda at hotmail.com (lobna gouda) Date: Tue, 24 Jul 2018 09:39:57 +0000 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <181889.1529788619@turing-police.cc.vt.edu> References: <20180611141656.D25636BB@m0117567.ppops.net> <9e2c59eb-2b9a-b68e-76c5-e60531c9a499@retevia.net> <322c14af-82db-c8dd-6bd8-6b3b3d8196d1@ddostest.me>, <181889.1529788619@turing-police.cc.vt.edu> Message-ID: My guessing, it is rather a proof than a cause. Apple wanted to push their dev to see more ipv6 traffic with HE algorithm before working with IPv6 only -based on their assumption that the throughput may be better over IPv6 and with better V6 implementation eventually they are not going to be trading it with latency. https://www.internetsociety.org/blog/2016/05/starting-june-1-apple-requires-all-ios-apps-to-work-in-ipv6-only-networks/ By the way, the same argument is adopted to justify a good practice for SDN and IOT implementations. Basically the need for an v6-based networks -where there is no correlation other than the need for more addresses to achieve manageability and the ability to scale. Big ISPs are starting to realize this market and are performing the changes to get this business. https://searchsdn.techtarget.com/feature/IPv6-SDN-When-worlds-collide-in-a-good-way Brgds, LG [https://cdn.ttgtmedia.com/ITKE/images/logos/TTlogo-379x201.png] IPv6, SDN: When worlds collide ... in a good way searchsdn.techtarget.com What do IPv6 and software-defined networking have in common? Not a lot, but then again, oh so much. Both IPv6 and SDN stand to radically change the way we build networks, and if implemented correctly, both play a role in making the cloud and IT as a Service more of a reality. In this two-part guide ... Starting June 1, Apple Requires All iOS Apps To Work in ... www.internetsociety.org Back at their June 2015 WWDC event, Apple announced that all iOS 9 applications must support IPv6. This week Apple declared that as of June 1 all apps submitted to the AppStore MUST support IPv6-only networking. ________________________________ From: NANOG on behalf of valdis.kletnieks at vt.edu Sent: Saturday, June 23, 2018 5:16 PM To: Jean | ddostest.me Cc: nanog at nanog.org Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On Sat, 23 Jun 2018 12:27:35 -0400, "Jean | ddostest.me via NANOG" said: > Because, Apple adds a 25 ms artifical penalty to ipv4 dns resolution. > > https://ma.ttias.be/apple-favours-ipv6-gives-ipv4-a-25ms-penalty/ [https://ma.ttias.be/wp-content/uploads/2015/07/official-apple-logo.png] Apple Favours IPv6, Gives IPv4 a 25ms Penalty - ma.ttias.be ma.ttias.be This is pretty exciting news for the adoption of IPv6. Last month, Apple announced that all iOS9 apps need to be "IPv6 compatible". Because IPv6 support is so critical to ensuring your applications work across the world for every customer, we are making it an AppStore submission requirement ... Umm.. It's 3 year old news that Apple implemented Happy Eyeballs. And if you read, it continues on saying that both Firefox and Chrome use a 300ms timer rather than 25ms. The solution is, of course, to not build websites that need to hit 20 or 30 IPv4-only tracking and affiliate and ad sites. :) From aftab.siddiqui at gmail.com Tue Jul 24 11:24:22 2018 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 24 Jul 2018 21:24:22 +1000 Subject: Definition/Classification of Bogon Message-ID: Hi Everyone, Just wanted to understand something about Bogons. As per RFC3871 - A "Bogon" (plural: "bogons") is a packet with an IP source address in an address block not yet allocated by IANA or the Regional Internet Registries (ARIN, RIPE, APNIC...) as well as all addresses reserved for private or special use by RFCs. See [RFC3330] and [RFC1918]. Q - Generally, Private or Reserved ASNs are considered as Bogon ASN but what about unallocated ASNs? Q - Is there any RFC (or even draft) which classify unallocated ASNs as Bogon as well? Additionally, Geoff Huston [1] explained all the possible classifications of "Bogon" in his blog post back in 2004 --> "Sometimes a bogon is just a case of keystroke error by a network operator, and the consequent bogons are entirely inadvertent, and other times it may be a disagreement between an end user and a registration authority" Q - In the above scenario when an RIR deregister a resource (IPv4/v6 or ASN) due to any disagreement (sometimes deregistration happens because of non-payment and can be resolved in a few days/weeks). How long should a service provider wait to mark them as bogon and stop advertising or accepting it? [1] - http://www.potaroo.net/ispcol/2004-04/2004-04-isp.htm From dovid at telecurve.com Tue Jul 24 11:57:13 2018 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 24 Jul 2018 07:57:13 -0400 Subject: AS205869, AS57166: Featured Hijacker of the Month, July, 2018 In-Reply-To: <20180724.090316.47077931.sthaug@nethelp.no> References: <27526.1532406494@segfault.tristatelogic.com> <20180724.090316.47077931.sthaug@nethelp.no> Message-ID: Dead for me via: HE NTT COX On Tue, Jul 24, 2018 at 3:03 AM, wrote: > > I'd greatly appreciate it if readers of this post would help me to to > confirm > > that the non-routing of the above block is both universal and complete... > > as it is, at least, from where I am sitting... but at this point I have > > nothing and nobody to rail against. (Or so I thought! But while writing > > this post I found some new and apparently associated curiosities relating > > to a different ASN, AS57166. Read on!) > > All prefixes still visible here (Oslo, Norway), through HE. Here's your > original table augmented with the AS paths I see on our border routers: > > ASN Route AS path > ----------------------------------------------- > 10510 216.238.64.0/18 6939 205869 32226 10510 > 10737 207.183.96.0/20 6939 205869 7827 10737 > 10800 192.110.32.0/19 6939 205869 11717 10800 > 19529 104.143.112.0/20 6939 205869 11324 19529 > 19529 198.14.0.0/20 6939 205869 7827 19529 > 19529 198.32.208.0/20 6939 205869 7827 19529 > 19529 206.41.128.0/20 6939 205869 11324 19529 > 30237 192.73.128.0/20 6939 205869 11717 30237 > 30237 192.73.144.0/20 6939 205869 11717 30237 > 30237 192.73.160.0/20 6939 205869 11717 30237 > 30237 192.73.176.0/20 6939 205869 11717 30237 > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > From phil.lavin at cloudcall.com Tue Jul 24 12:15:54 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Tue, 24 Jul 2018 12:15:54 +0000 Subject: AS205869, AS57166: Featured Hijacker of the Month, July, 2018 In-Reply-To: References: <27526.1532406494@segfault.tristatelogic.com> <20180724.090316.47077931.sthaug@nethelp.no> Message-ID: > Dead for me via: > HE > NTT > COX Likewise here, via a bunch of other transits. I saw them from HE this morning but they appear to have been withdrawn now. From sthaug at nethelp.no Tue Jul 24 12:59:15 2018 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 24 Jul 2018 14:59:15 +0200 (CEST) Subject: AS205869, AS57166: Featured Hijacker of the Month, July, 2018 In-Reply-To: References: <20180724.090316.47077931.sthaug@nethelp.no> Message-ID: <20180724.145915.126590476.sthaug@nethelp.no> >> Dead for me via: >> HE >> NTT >> COX > > Likewise here, via a bunch of other transits. I saw them from HE this morning but they appear to have been withdrawn now. Also gone from HE from my vantage point in Oslo, Norway. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bill at herrin.us Tue Jul 24 13:02:28 2018 From: bill at herrin.us (William Herrin) Date: Tue, 24 Jul 2018 09:02:28 -0400 Subject: Definition/Classification of Bogon In-Reply-To: References: Message-ID: On Tue, Jul 24, 2018 at 7:24 AM, Aftab Siddiqui wrote: > Q - Generally, Private or Reserved ASNs are considered as Bogon ASN but > what about unallocated ASNs? Hi Aftab, You can reasonably think of a bogon as any Internet number resource which according to the registration authority should not appear on whatever network is at issue. > Q - Is there any RFC (or even draft) which classify unallocated ASNs as > Bogon as well? The RFCs offer guidelines and conventions in this, not hard rules. It would be an error to treat them as hard rules. > Q - In the above scenario when an RIR deregister a resource (IPv4/v6 or > ASN) due to any disagreement (sometimes deregistration happens because of > non-payment and can be resolved in a few days/weeks). How long should a > service provider wait to mark them as bogon and stop advertising or > accepting it? In my opinion: until the customer stops paying you or the authority assigns the resource to someone else. As long as the resource was properly assigned to the customer when they started advertising it, there's no real angle to forcibly ending it sooner. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From apishdadi at gmail.com Mon Jul 23 20:27:51 2018 From: apishdadi at gmail.com (A. Pishdadi) Date: Mon, 23 Jul 2018 15:27:51 -0500 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <488acace585476e29d40ffc79d69b026.squirrel@66.201.44.180> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <7582a151-7ac9-7d7b-b3c2-13130a0bd609@foobar.org> <488acace585476e29d40ffc79d69b026.squirrel@66.201.44.180> Message-ID: How often does someone ask you for a breakfast sandwich? 😀 On Mon, Jul 23, 2018 at 3:19 PM Bob Evans wrote: > How much ocean water displacement is taking place in Hawaii as a result of > eruptions? How about volcanoes we don't know about deep in the ocean? > > In the last 5 years, California governments have played a negative roll in > the burning of well over a million acres. These carbon emissions are > rarely calculated and considered as a cause of global warming. How many > California miles driven in cars = one 250,000 acre fire? I don't know. > > Did you know there are adults in California that don't think burning trees > emit carbon emissions that count unless it happens in a man made fireplace > ? Yes, most of those people went to high school in California. > > But anyways - can we please drop the non-internet related discussions from > filling my nanog filtered technical email folders? > > Lots of smart people to have discussions with in nanog...maybe we create a > list called nanog-other-stuff at nanog.org > > Thank You > Bob Evans > CTO > > > > > > On 23/07/2018 20:03, Owen DeLong wrote: > >> It shows China, the most heavy handed of the three economies in the > >> graphic as having an accelerating growth in carbon emissions. It does > >> show that the EU started a downward trend earlier than the US, but that > >> the downward trend in the EU appears to be leveling off and the US > >> downward trend looks to be steeper now and accelerating. > >> > >> In addition, if you drill down to the individual EU countries, several > >> of them are, in fact, headed up while the more market-based members of > >> the EU seem to be headed down or having leveled off after a sharp > >> decline earlier. > > > > The data is flawed. The carbon emissions per country don't include > > import, so you can just import the most carbon-heavy product from China > > and you will see your country emissions falling and China's growing. > > > > And the carbon emission of USA doesn't include Pentagon, while any other > > army is included in it's country numbers. > > > > So we can' really compare such flawed data - these are just numbers for > > politicians but they have nothing in common with reality. > > > > Regarding rising sea levels - I wonder why nobody mentioned submarine > > fiber landing stations. If something will be affected, it will be them. > > > > -- > > Grzegorz Janoszka > > > > > From marc at sachs.us Mon Jul 23 23:16:45 2018 From: marc at sachs.us (Marc Sachs) Date: Mon, 23 Jul 2018 19:16:45 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <38544.1532379654@turing-police.cc.vt.edu> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <38544.1532379654@turing-police.cc.vt.edu> Message-ID: <023801d422db$39af9ee0$ad0edca0$@sachs.us> If the Intertubes are going to all be under water in 15 years, then we need a new cartoon from the New Yorker. I suggest this: On the Internet nobody knows you are a phish -----Original Message----- From: NANOG On Behalf Of valdis.kletnieks at vt.edu Sent: Monday, July 23, 2018 5:01 PM To: William Herrin Cc: nanog at nanog.org Subject: Re: Rising sea levels are going to mess with the internet From stephend at ameslab.gov Tue Jul 24 12:59:58 2018 From: stephend at ameslab.gov (Douglas C. Stephens) Date: Tue, 24 Jul 2018 07:59:58 -0500 Subject: SP security knowledge build up In-Reply-To: <8EAF16BD-BD83-4C89-AB5A-B7101988D92B@gmail.com> References: <8EAF16BD-BD83-4C89-AB5A-B7101988D92B@gmail.com> Message-ID: <6efd278f-31a0-7d0b-d755-8e14bf344cd8@ameslab.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To add to Suresh's list, Iowa State University (iastate.edu) offers a graduate major program and an undergraduate minor program in cyber security (a.k.a. Information Assurance). They also run an annual cyber defense competition (ISEAGE). On 7/24/2018 4:06 AM, Suresh Ramasubramanian wrote: > Not a MOOC. But several schools now have graduate programs in > security. Off the top of my head, Georgia Tech, UAB, GMU .. > > > > They might offer some shorter courses as well, for working > professionals. Take a look. > > > > From: Ramy Hashish Date: Tuesday, 24 > July 2018 at 2:33 PM To: "Compton, Rich A" > Cc: Christopher Morrow > , Suresh Ramasubramanian > , nanog list Subject: Re: SP > security knowledge build up > > > > Thank you Christopher, Compton and Suresh, that was helpful. > > > > I am still looking for more. > > > > Does anyone want to recommend any MOOC? > > > > Thanks, > > > > Ramy > > > > On 23 July 2018 at 17:30, Compton, Rich A > wrote: > > Barry Greene's site has some good info on ISP security as well: > http://www.senki.org > > > On 7/23/18, 8:08 AM, "NANOG on behalf of Christopher Morrow" > > wrote: > > I thought also there was a set of videos from nanog meetings... I > can't find a set, but here are some: > > ISP Security 101 primer > https://www.youtube.com/watch?v=ueRminCpnMc > > isp security real-world techniques - 2 > https://www.youtube.com/watch?v=Ijd9A5wUS_0 > https://www.youtube.com/watch?v=T6ZSxgVvjdA (older version of > previous?) > > ISP Security toolkits https://www.youtube.com/watch?v=w7XcZS_99WQ > > NRIC Best Practices for ISP Security > https://www.youtube.com/watch?v=1bzL5eUGC-0 > > there are actually quite a few more, searching for 'security > nanog' turned up. > > On Mon, Jul 23, 2018 at 9:32 AM Suresh Ramasubramanian > wrote: > >> The usual / canonical sysadmin book might work, there is a lot >> of security related material in there as well. >> >> >> https://www.amazon.com/Practice-System-Network-Administration-Second/ dp/0321492668 > >> > >> >> And this updated for enterprise / devops and other such new >> fangled things >> >> >> https://www.amazon.com/Practice-System-Network-Administration-Enterpr ise/dp/0321919165/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=2N4F 09FPM9FG9VQNT433 > >> > >> >> >> On 23/07/18, 6:55 PM, "NANOG on behalf of Ramy Hashish" >> > ramy.ihashish at gmail.com> wrote: >> >> Hello All, >> >> I am planning to build up a security team of fresh engineers >> whom are "network oriented", any advice on the knowledge >> resources we can start with? We are looking forward to building a >> concrete foundation of a well-rounded security engineer, we are >> looking for vendor/operator agnostic resources. >> >> Thanks, >> >> Ramy >> >> >> >> > > > 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. > > > - -- Douglas C. Stephens | Network Systems Analyst Enterprise Information Services | Phone: (515) 294-6102 Ames Laboratory, US DOE | Email: stephend at ameslab.gov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iEUEARECAAYFAltXIs4ACgkQ46phdn656QTvoACgnZ7bbZkoauPAy7F6Ur8YBBBr uNQAmOjWWvjDnZC/tnQP9dkuI0gjHdA= =iG2H -----END PGP SIGNATURE----- From rsk at gsp.org Tue Jul 24 16:43:12 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 24 Jul 2018 12:43:12 -0400 Subject: SP security knowledge build up In-Reply-To: References: Message-ID: <20180724164312.GA6933@gsp.org> On Mon, Jul 23, 2018 at 03:22:46PM +0200, Ramy Hashish wrote: > I am planning to build up a security team of fresh engineers whom are > "network oriented", any advice on the knowledge resources we can start > with? 1. Start with one or more engineers who aren't "fresh". This is more expensive, potentially much more expensive, but it's much more likely to result in success than trying to feed a crash course in security into the brains of people who've never done any of this before. Even if all those experienced people do is stop you from making well-known mistakes, then the investment will be more than worth it. 2. I see that several academic programs were mentioned downthread; one that I'd add to the list is UMBC, which is excellent. ---rsk From me at anuragbhatia.com Tue Jul 24 18:06:21 2018 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 24 Jul 2018 23:36:21 +0530 Subject: Question about bird RS config with BGP Community support In-Reply-To: <37C02BC2-5918-4AE1-B2C1-319D49AD6B1F@gmail.com> References: <37C02BC2-5918-4AE1-B2C1-319D49AD6B1F@gmail.com> Message-ID: Hi Tim & Job Thanks a lot for your advice. I was aware of IXP Manager and there were certain issues we faced due to which we couldn't use it when we tried last time (which was a few months ago before the latest stable release). I wish to re-visit and keep on re-visiting it until we can make it work because it does seem like a package full of everything an IXP needs. :) I checked arouteseerver project which I missed during the previous lookup. It seems really good and I ended up in building config and getting it live. For now, we got what we needed (the BGP community support as well as a way to automatically update config regularly). I will explore IXP manager again in the very near future. Thanks again for your help. And oh btw I still do not have an answer to my question on why route announcement did not go. I do have a well tested and working config which does the job but the config generated by arouteserver is like 10x bigger than original config (for 5 peers). Still trying to read and get a sense from it on what was wrong earlier. Thanks. On Tue, Jul 24, 2018 at 2:58 AM Tim Raphael wrote: > As an operator of large, established IXP I would also recommend this path. > A lot of work had gone into the likes of IXPManager and arouteserver and > they provide great value in providing secure configurations with added > features such as action communities you are after. > > Cheers, > > Tim > > > On 24 Jul 2018, at 7:05 am, Job Snijders wrote: > > > >> On Mon, 23 Jul 2018 at 23:00, Anurag Bhatia > wrote: > >> > >> We are running a small IX fabric (in Mumbai, India) and with multiple > >> route servers based on a bird. There has been a demand of support of BGP > >> communities from some of our members and I am trying to find a way to > set > >> it up in the bird. Idea is to provide a community say 0:123 where tagged > >> routes with 0:123 do not reach AS123. I am new to the bird. > > > > > > I strongly recommend to either use “arouteserver” or “IXP manager” to > > generate the BIRD configuration files on your behalf, and no type it by > > hand. > > > > Setting up a fully featured secure route server is a lot of work and > > research, I’d really recommend to leverage the work others have done in > > this problem space. I fear otherwise you may risk repeating mistakes that > > others already made. > > > > https://arouteserver.readthedocs.io/en/latest/ > > https://github.com/pierky/arouteserver > > https://www.ixpmanager.org/ > > > > And using these automated tools means less work for the IX operator. > > Turning up new peers is a breeze with both tools! > > > > Kind regards, > > > > Job > > > >> > -- Anurag Bhatia anuragbhatia.com From randy at psg.com Tue Jul 24 18:13:05 2018 From: randy at psg.com (Randy Bush) Date: Tue, 24 Jul 2018 11:13:05 -0700 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <21bcfdd1-a483-6600-7d33-58583f1630ec@seacom.mu> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <21bcfdd1-a483-6600-7d33-58583f1630ec@seacom.mu> Message-ID: >> It's curious phenomena where we are very willing to ignore all the >> data points that disagree with us, and accept the one data point that >> agrees with us, even when admitted to be fabrication. > Some people just always prefer to do the opposite of everyone else, > and/or the obvious. I have many friends like this. i have ex-friends like this From Pratik.Lotia at charter.com Tue Jul 24 17:31:01 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Tue, 24 Jul 2018 17:31:01 +0000 Subject: SP security knowledge build up In-Reply-To: <20180724164312.GA6933@gsp.org> References: <20180724164312.GA6933@gsp.org> Message-ID: On Mon, Jul 23, 2018 at 03:22:46PM +0200, Ramy Hashish wrote: > I am planning to build up a security team of fresh engineers whom are > "network oriented", any advice on the knowledge resources we can start > with? To add to the academic programs - CU Boulder has an excellent telecom program for network security and network engineering; one of their courses focuses solely on SP networks (full disclosure: I am a CU Boulder alumnus). With Gratitude, Pratik Lotia  | Security Engineer III Charter Communications -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rich Kulawiec Sent: Tuesday, July 24, 2018 10:43 AM To: nanog at nanog.org Subject: Re: SP security knowledge build up On Mon, Jul 23, 2018 at 03:22:46PM +0200, Ramy Hashish wrote: > I am planning to build up a security team of fresh engineers whom are > "network oriented", any advice on the knowledge resources we can start > with? 1. Start with one or more engineers who aren't "fresh". This is more expensive, potentially much more expensive, but it's much more likely to result in success than trying to feed a crash course in security into the brains of people who've never done any of this before. Even if all those experienced people do is stop you from making well-known mistakes, then the investment will be more than worth it. 2. I see that several academic programs were mentioned downthread; one that I'd add to the list is UMBC, which is excellent. ---rsk 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 job at instituut.net Tue Jul 24 18:29:38 2018 From: job at instituut.net (Job Snijders) Date: Tue, 24 Jul 2018 18:29:38 +0000 Subject: Question about bird RS config with BGP Community support In-Reply-To: References: <37C02BC2-5918-4AE1-B2C1-319D49AD6B1F@gmail.com> Message-ID: <20180724182938.GO37801@vurt.meerval.net> On Tue, Jul 24, 2018 at 11:36:21PM +0530, Anurag Bhatia wrote: > Thanks a lot for your advice. I was aware of IXP Manager and there > were certain issues we faced due to which we couldn't use it when we > tried last time (which was a few months ago before the latest stable > release). I wish to re-visit and keep on re-visiting it until we can > make it work because it does seem like a package full of everything an > IXP needs. :) > > I checked arouteseerver project which I missed during the previous > lookup. It seems really good and I ended up in building config and > getting it live. For now, we got what we needed (the BGP community > support as well as a way to automatically update config regularly). I > will explore IXP manager again in the very near future. Note that you can use arouteserver in conjunction with IXP Manager: arouteserver can plug into IXP Manager so that you use IXP Manager for the administrative side of things (the portal, statistics, etc), and use arouteserver for the routeserver configuration generation. Arouteserver (compared to IXP Manager) offers a bunch of more advanced features such as "Use RPKI ROAs as route-objects", the "ARIN-WHOIS" data source, and some extra filters/features. Both are excellent, it is good to have a choice :-) > Thanks again for your help. And oh btw I still do not have an answer > to my question on why route announcement did not go. Feel free to send me your full BIRD configuration off-list and I'll help you analyse what's wrong in the adoption of that example config. > I do have a well tested and working config which does the job but the > config generated by arouteserver is like 10x bigger than original > config (for 5 peers). Still trying to read and get a sense from it on > what was wrong earlier. The arouteserver (or ixp manager) configurations are indeed bigger, most likely due to extensive prefix and as_path filtering! This is a good thing. Don't worry about size - I've loaded 50 megabyte config files into BIRD and it handles such large configurations fine. Kind regards, Job From rfg at tristatelogic.com Tue Jul 24 19:01:56 2018 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 24 Jul 2018 12:01:56 -0700 Subject: AS205869, AS57166: Featured Hijacker of the Month, July, 2018 In-Reply-To: <20180724.090316.47077931.sthaug@nethelp.no> Message-ID: <31053.1532458916@segfault.tristatelogic.com> In message <20180724.090316.47077931.sthaug at nethelp.no>, sthaug at nethelp.no wrote: >All prefixes still visible here (Oslo, Norway), through HE. Here's your >original table augmented with the AS paths I see on our border routers: > >ASN Route AS path >----------------------------------------------- >10510 216.238.64.0/18 6939 205869 32226 10510 >10737 207.183.96.0/20 6939 205869 7827 10737 >10800 192.110.32.0/19 6939 205869 11717 10800 >19529 104.143.112.0/20 6939 205869 11324 19529 >19529 198.14.0.0/20 6939 205869 7827 19529 >19529 198.32.208.0/20 6939 205869 7827 19529 >19529 206.41.128.0/20 6939 205869 11324 19529 >30237 192.73.128.0/20 6939 205869 11717 30237 >30237 192.73.144.0/20 6939 205869 11717 30237 >30237 192.73.160.0/20 6939 205869 11717 30237 >30237 192.73.176.0/20 6939 205869 11717 30237 Thanks for checking this. I gather from the other posts in this thread that this has already been rectified, and that the above CIDRs are no longer reachable via HE.NET, correct? Even if that's the case, I'm still left scratching my head. There's a bit of a mystery here, or at least something that I don't quite understand. (NOTE: I've never laid claim to being anything like an "expert" when it comes to all this routing stuff. I just muddle along and try to do the best I can with the limited knowledge and understanding that I have.) So, here's what's perplexing me. You reported that all eleven of the routes in the table above had AS paths that directly connected Universal IP Solution Corp. (AS205869) to Hurricane Electric (AS6939). And yet, when I looked at the following page, both yesterday and today, I see no reported connection between those two ASNs: https://bgp.he.net/AS205869#_peers I already knew before now that each of the alleged peerings reported on similar pages on the bgp.he.net web site had to be taken with a grain of salt, mostly or entirely because of the kinds of hanky panky and path forgery being undertaken by various bad guys. In at least some cases, these screwy games appear to have caused bgp.he.net to list peerings that didn't actually exist. But this is a rather entirely different case. In this case, it seems that one very notable peering that -did- in fact exist, between AS205869 and AS6939, was not reported at all on the bgp.he.net page linked to above. To be clear, I most definitely am *not* suggeting any sort of deliberate obfsucation here, on anybody's part. Rather, I just suspect that some of the algorithms that are used to produce the peers lists on bgp.he.net could use some... ah... fine tuning. It certainly seems to be true that in this case, one very important peering was utterly missed by the algorithms that power bgp.he.net. Regards, rfg From nanog at radu-adrian.feurdean.net Tue Jul 24 20:10:31 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Tue, 24 Jul 2018 22:10:31 +0200 Subject: Definition/Classification of Bogon In-Reply-To: References: Message-ID: <1532463031.1411964.1451633656.17A27AD9@webmail.messagingengine.com> On Tue, Jul 24, 2018, at 13:24, Aftab Siddiqui wrote: > Q - Generally, Private or Reserved ASNs are considered as Bogon ASN but > what about unallocated ASNs? If you don't have an automated update process running at decent time intervals (one week or more often, under no circumstance less than once a month) and you don't have processes in place that monitor that updates do happen properly with some corrective action being done when they don't - then stick with private or reserved. If you do have everything needed, and are aware that what is unallocated today may be allocated tomorrow, then you can (should) go with private+reserved+unallocated option. From alderfjh at emu.edu Tue Jul 24 20:17:16 2018 From: alderfjh at emu.edu (Jason Alderfer) Date: Tue, 24 Jul 2018 16:17:16 -0400 Subject: AS205869, AS57166: Featured Hijacker of the Month, July, 2018 In-Reply-To: <31053.1532458916@segfault.tristatelogic.com> References: <20180724.090316.47077931.sthaug@nethelp.no> <31053.1532458916@segfault.tristatelogic.com> Message-ID: radar.qrator.net serves as a complementary view to bgp.he.net and AS205869 does show as peered with AS6939 there. Jason On Tue, Jul 24, 2018 at 3:02 PM Ronald F. Guilmette wrote: > > In message <20180724.090316.47077931.sthaug at nethelp.no>, > sthaug at nethelp.no wrote: > > >All prefixes still visible here (Oslo, Norway), through HE. Here's your > >original table augmented with the AS paths I see on our border routers: > > > >ASN Route AS path > >----------------------------------------------- > >10510 216.238.64.0/18 6939 205869 32226 10510 > >10737 207.183.96.0/20 6939 205869 7827 10737 > >10800 192.110.32.0/19 6939 205869 11717 10800 > >19529 104.143.112.0/20 6939 205869 11324 19529 > >19529 198.14.0.0/20 6939 205869 7827 19529 > >19529 198.32.208.0/20 6939 205869 7827 19529 > >19529 206.41.128.0/20 6939 205869 11324 19529 > >30237 192.73.128.0/20 6939 205869 11717 30237 > >30237 192.73.144.0/20 6939 205869 11717 30237 > >30237 192.73.160.0/20 6939 205869 11717 30237 > >30237 192.73.176.0/20 6939 205869 11717 30237 > > Thanks for checking this. I gather from the other posts in this thread > that this has already been rectified, and that the above CIDRs are no > longer reachable via HE.NET, correct? > > Even if that's the case, I'm still left scratching my head. There's a > bit of a mystery here, or at least something that I don't quite understand. > (NOTE: I've never laid claim to being anything like an "expert" when it > comes to all this routing stuff. I just muddle along and try to do the > best I can with the limited knowledge and understanding that I have.) > > So, here's what's perplexing me. You reported that all eleven of the > routes in the table above had AS paths that directly connected > Universal IP Solution Corp. (AS205869) to Hurricane Electric (AS6939). > And yet, when I looked at the following page, both yesterday and today, > I see no reported connection between those two ASNs: > > https://bgp.he.net/AS205869#_peers > > I already knew before now that each of the alleged peerings reported on > similar pages on the bgp.he.net web site had to be taken with a grain of > salt, mostly or entirely because of the kinds of hanky panky and path > forgery being undertaken by various bad guys. In at least some cases, > these screwy games appear to have caused bgp.he.net to list peerings that > didn't actually exist. > > But this is a rather entirely different case. In this case, it seems > that one very notable peering that -did- in fact exist, between AS205869 > and AS6939, was not reported at all on the bgp.he.net page linked to > above. > > To be clear, I most definitely am *not* suggeting any sort of deliberate > obfsucation here, on anybody's part. Rather, I just suspect that some > of the algorithms that are used to produce the peers lists on bgp.he.net > could use some... ah... fine tuning. It certainly seems to be true that > in this case, one very important peering was utterly missed by the > algorithms > that power bgp.he.net. > > > Regards, > rfg > From goemon at sasami.anime.net Tue Jul 24 23:19:22 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Tue, 24 Jul 2018 16:19:22 -0700 (PDT) Subject: unwise filtering policy on abuse mailboxes In-Reply-To: <201807242314.w6ONEJNH007001@yuri.anime.net> References: <201807242314.w6ONEJNH007001@yuri.anime.net> Message-ID: can we please just stop this nonsense? ip under your direct control originates sewage. you should accept reports as-is. requiring victims of your sewage to go through special contortions to report it to you is not acceptable. > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 "The mail server detected your message as spam and has prevented delivery.") From Brian at ampr.org Tue Jul 24 23:36:47 2018 From: Brian at ampr.org (Brian Kantor) Date: Tue, 24 Jul 2018 16:36:47 -0700 Subject: unwise filtering policy on abuse mailboxes In-Reply-To: References: <201807242314.w6ONEJNH007001@yuri.anime.net> Message-ID: <20180724233647.GA63038@meow.BKantor.net> On Tue, Jul 24, 2018 at 04:19:22PM -0700, Dan Hollis wrote: > can we please just stop this nonsense? > > ip under your direct control originates sewage. you should accept reports as-is. > > requiring victims of your sewage to go through special contortions to > report it to you is not acceptable. > > > ----- The following addresses had permanent fatal errors ----- > > > > (reason: 550 "The mail server detected your message as spam and has prevented delivery.") abuse at fsec.or.kr and cert at fsec.or.kr do the same thing. - Brian From mel at beckman.org Wed Jul 25 00:08:35 2018 From: mel at beckman.org (Mel Beckman) Date: Wed, 25 Jul 2018 00:08:35 +0000 Subject: unwise filtering policy on abuse mailboxes In-Reply-To: <20180724233647.GA63038@meow.BKantor.net> References: <201807242314.w6ONEJNH007001@yuri.anime.net> , <20180724233647.GA63038@meow.BKantor.net> Message-ID: <060EE445-5E5C-4B24-BF70-16626626711E@beckman.org> Dan, Are you saying Nanog if spamming you? It's not at all clear what your complaint is. -mel via cell > On Jul 24, 2018, at 4:37 PM, Brian Kantor wrote: > > >> On Tue, Jul 24, 2018 at 04:19:22PM -0700, Dan Hollis wrote: >> can we please just stop this nonsense? >> >> ip under your direct control originates sewage. you should accept reports as-is. >> >> requiring victims of your sewage to go through special contortions to >> report it to you is not acceptable. >> >>> ----- The following addresses had permanent fatal errors ----- >>> >>> (reason: 550 "The mail server detected your message as spam and has prevented delivery.") > > > abuse at fsec.or.kr and cert at fsec.or.kr do the same thing. > - Brian > From ross at tajvar.io Wed Jul 25 00:17:07 2018 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 24 Jul 2018 20:17:07 -0400 Subject: unwise filtering policy on abuse mailboxes In-Reply-To: <060EE445-5E5C-4B24-BF70-16626626711E@beckman.org> References: <201807242314.w6ONEJNH007001@yuri.anime.net> <20180724233647.GA63038@meow.BKantor.net> <060EE445-5E5C-4B24-BF70-16626626711E@beckman.org> Message-ID: Seemed pretty clear to me. He sent an abuse report to abuse at psychz.net and it was rejected as spam. On Tue, Jul 24, 2018, 8:11 PM Mel Beckman wrote: > Dan, > > Are you saying Nanog if spamming you? It's not at all clear what your > complaint is. > > -mel via cell > > > On Jul 24, 2018, at 4:37 PM, Brian Kantor wrote: > > > > > >> On Tue, Jul 24, 2018 at 04:19:22PM -0700, Dan Hollis wrote: > >> can we please just stop this nonsense? > >> > >> ip under your direct control originates sewage. you should accept > reports as-is. > >> > >> requiring victims of your sewage to go through special contortions to > >> report it to you is not acceptable. > >> > >>> ----- The following addresses had permanent fatal errors ----- > >>> > >>> (reason: 550 "The mail server detected your message as spam and has > prevented delivery.") > > > > > > abuse at fsec.or.kr and cert at fsec.or.kr do the same thing. > > - Brian > > > From morrowc.lists at gmail.com Wed Jul 25 00:47:33 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 24 Jul 2018 20:47:33 -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: I bet you can search the nanog list archive and find this very discussion topic surface about ever 8-12 months... folk always fall in this trap (or a form of it): "Welp, we've had 1 too many people in $CORP get infected via email, spam filter all the things!!!" ... wait... "Oh, yea duh.. our spam/abuse alias can't block spam.. because people will send us email they get that has spam/viruses/etc in it..whoops!!" this 'always' happens, and we discuss it every 8-12 months. On Tue, Jul 24, 2018 at 8:18 PM Ross Tajvar wrote: > Seemed pretty clear to me. He sent an abuse report to abuse at psychz.net and > it was rejected as spam. > > On Tue, Jul 24, 2018, 8:11 PM Mel Beckman wrote: > > > Dan, > > > > Are you saying Nanog if spamming you? It's not at all clear what your > > complaint is. > > > > -mel via cell > > > > > On Jul 24, 2018, at 4:37 PM, Brian Kantor wrote: > > > > > > > > >> On Tue, Jul 24, 2018 at 04:19:22PM -0700, Dan Hollis wrote: > > >> can we please just stop this nonsense? > > >> > > >> ip under your direct control originates sewage. you should accept > > reports as-is. > > >> > > >> requiring victims of your sewage to go through special contortions to > > >> report it to you is not acceptable. > > >> > > >>> ----- The following addresses had permanent fatal errors ----- > > >>> > > >>> (reason: 550 "The mail server detected your message as spam and has > > prevented delivery.") > > > > > > > > > abuse at fsec.or.kr and cert at fsec.or.kr do the same thing. > > > - Brian > > > > > > From goemon at sasami.anime.net Wed Jul 25 00:53:48 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Tue, 24 Jul 2018 17:53:48 -0700 (PDT) Subject: unwise filtering policy on abuse mailboxes In-Reply-To: <060EE445-5E5C-4B24-BF70-16626626711E@beckman.org> References: <201807242314.w6ONEJNH007001@yuri.anime.net> , <20180724233647.GA63038@meow.BKantor.net> <060EE445-5E5C-4B24-BF70-16626626711E@beckman.org> Message-ID: I'm saying people who filter their abuse mailboxes need to stop doing so. -Dan On Wed, 25 Jul 2018, Mel Beckman wrote: > Dan, > > Are you saying Nanog if spamming you? It's not at all clear what your complaint is. > > -mel via cell > >> On Jul 24, 2018, at 4:37 PM, Brian Kantor wrote: >> >> >>> On Tue, Jul 24, 2018 at 04:19:22PM -0700, Dan Hollis wrote: >>> can we please just stop this nonsense? >>> >>> ip under your direct control originates sewage. you should accept reports as-is. >>> >>> requiring victims of your sewage to go through special contortions to >>> report it to you is not acceptable. >>> >>>> ----- The following addresses had permanent fatal errors ----- >>>> >>>> (reason: 550 "The mail server detected your message as spam and has prevented delivery.") >> >> >> abuse at fsec.or.kr and cert at fsec.or.kr do the same thing. >> - Brian >> > From aftab.siddiqui at gmail.com Wed Jul 25 02:37:16 2018 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Wed, 25 Jul 2018 12:37:16 +1000 Subject: Definition/Classification of Bogon In-Reply-To: <1532463031.1411964.1451633656.17A27AD9@webmail.messagingengine.com> References: <1532463031.1411964.1451633656.17A27AD9@webmail.messagingengine.com> Message-ID: Hi, On Wed, 25 Jul 2018 at 06:12 Radu-Adrian Feurdean < nanog at radu-adrian.feurdean.net> wrote: > On Tue, Jul 24, 2018, at 13:24, Aftab Siddiqui wrote: > > Q - Generally, Private or Reserved ASNs are considered as Bogon ASN but > > what about unallocated ASNs? > > If you don't have an automated update process running at decent time > intervals (one week or more often, under no circumstance less than once a > month) and you don't have processes in place that monitor that updates do > happen properly with some corrective action being done when they don't - > then stick with private or reserved. > > If you do have everything needed, and are aware that what is unallocated > today may be allocated tomorrow, then you can (should) go with > private+reserved+unallocated option. > Exactly, getting the right and updated info is so tricky that people only filter Private+Reserved ASNs. Because of the same reason more than 600 unallocated ASNs are in the routing table as per the CIDR-Report. Wouldn't that be simple to parse the list and start updating filters on daily basis? I understand its troublesome for big operators. I've just started this so lets see what happens :) but I can tell that the diff on file created every night isn't much (around 10-20). http://www.cidr-report.org/as2.0/#Bogons From johnl at iecc.com Wed Jul 25 02:42:53 2018 From: johnl at iecc.com (John Levine) Date: 24 Jul 2018 22:42:53 -0400 Subject: unwise filtering policy on abuse mailboxes In-Reply-To: Message-ID: <20180725024253.9D06E2002D2235@ary.qy> In article you write: >I'm saying people who filter their abuse mailboxes need to stop doing so. See Canute, King. R's, John From aftab.siddiqui at gmail.com Wed Jul 25 02:46:53 2018 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Wed, 25 Jul 2018 12:46:53 +1000 Subject: Definition/Classification of Bogon In-Reply-To: References: Message-ID: Hi Bill, On Tue, 24 Jul 2018 at 23:03 William Herrin wrote: > On Tue, Jul 24, 2018 at 7:24 AM, Aftab Siddiqui > wrote: > > Q - Generally, Private or Reserved ASNs are considered as Bogon ASN but > > what about unallocated ASNs? > > Hi Aftab, > > You can reasonably think of a bogon as any Internet number resource > which according to the registration authority should not appear on > whatever network is at issue. > Perfect definition. I have the same opinion. BUT > Q - Is there any RFC (or even draft) which classify unallocated ASNs as > > Bogon as well? > > The RFCs offer guidelines and conventions in this, not hard rules. It > would be an error to treat them as hard rules. > Recently, during a discussion with few decent size service providers who pointed me to RFC3871 suggesting that the word Bogon is for "IP resources" only. Hence, I asked this question here. > > Q - In the above scenario when an RIR deregister a resource (IPv4/v6 or > > ASN) due to any disagreement (sometimes deregistration happens because of > > non-payment and can be resolved in a few days/weeks). How long should a > > service provider wait to mark them as bogon and stop advertising or > > accepting it? > > In my opinion: until the customer stops paying you or the authority > assigns the resource to someone else. As long as the resource was > properly assigned to the customer when they started advertising it, > there's no real angle to forcibly ending it sooner. This is the current practice though it isn't the best one. From surfer at mauigateway.com Wed Jul 25 02:53:46 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 24 Jul 2018 19:53:46 -0700 Subject: using expect to log into devices Message-ID: <20180724195346.B8CE6BB7@m0117566.ppops.net> Was out. Late reply... --- niels=nanog at bakker.net wrote: From: Niels Bakker * surfer at mauigateway.com (Scott Weeks) [Sat 21 Jul 2018, 22:38 CEST]: >I had already done this in PERL, but, even though we have PERL, we >are not allowed to download modules here. So, I'm redoing it in >Expect. I thought someone would say a "oh just and >you're done" type of response. Well, what you're doing right here is reimplementing rancid. Which is wholly unnecessary because we already have rancid, and a more modern alternative named oxidized. And you've gotten that response already. Fine as a personal exercise, of course. The inability to download modules seems sadistic to me, though. -------------------------------------------------- It IS sadistic and I don't have a choice. Can't use rancid, either. Thus my comment of $next-job and personal exercise in prep for that. But, while I'm here I want something non-GUI I can use without losing my mind. scott From mel at beckman.org Wed Jul 25 02:54:01 2018 From: mel at beckman.org (Mel Beckman) Date: Wed, 25 Jul 2018 02:54:01 +0000 Subject: unwise filtering policy on abuse mailboxes In-Reply-To: <20180725024253.9D06E2002D2235@ary.qy> References: , <20180725024253.9D06E2002D2235@ary.qy> Message-ID: Why are you telling us here on Nanog? -mel > On Jul 24, 2018, at 7:43 PM, John Levine wrote: > > In article you write: >> I'm saying people who filter their abuse mailboxes need to stop doing so. > > See Canute, King. > > R's, > John From surfer at mauigateway.com Wed Jul 25 02:55:55 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 24 Jul 2018 19:55:55 -0700 Subject: using expect to log into devices Message-ID: <20180724195555.B8CE6BB2@m0117566.ppops.net> --- valdis.kletnieks at vt.edu wrote: From: valdis.kletnieks at vt.edu On Sun, 22 Jul 2018 00:43:35 +0200, Niels Bakker said: > Fine as a personal exercise, of course. The inability to download > modules seems sadistic to me, though. And given the adage "Never create a rule you can't enforce", I wonder how they enforce it - have to be pretty hardcore to make sure that stuff doesn't get imported via USB or tethering off a cellphone. (Or more correctly, I know how they do those sort of things if you're a spook agency or doing classified research - how do you make it palatable to employees in corporate sites?) ------------------------------------------------- It's not corporate and believe me, they enforce it... ;-) scott From mysidia at gmail.com Wed Jul 25 03:52:57 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 24 Jul 2018 22:52:57 -0500 Subject: using expect to log into devices In-Reply-To: <20180724195555.B8CE6BB2@m0117566.ppops.net> References: <20180724195555.B8CE6BB2@m0117566.ppops.net> Message-ID: On Tue, Jul 24, 2018 at 9:55 PM, Scott Weeks wrote: > > --- valdis.kletnieks at vt.edu wrote: > From: valdis.kletnieks at vt.edu > > On Sun, 22 Jul 2018 00:43:35 +0200, Niels Bakker said: > > Fine as a personal exercise, of course. The inability to download > > modules seems sadistic to me, though. > Yeah... just download RANCID and check the command line options. Expect is mainly of historical interest, and the code already exists in several forms, so no need to completely re-invent the wheel (as a square) here. I call shenanigans about the avoidance of Perl modules. No real-world system has such constraints. Besides, Expect itself is a module / extension of the Tcl language and requires the use of dynamically-loaded extension libraries for pattern matching and various functions, so using Expect would break the "No modules rule". If you're not allowed the use of modules, then your implementation option is pretty much to write in something that compiles to straight machine language. -- -JH From hank at efes.iucc.ac.il Wed Jul 25 04:51:15 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 25 Jul 2018 07:51:15 +0300 Subject: Definition/Classification of Bogon In-Reply-To: References: <1532463031.1411964.1451633656.17A27AD9@webmail.messagingengine.com> Message-ID: <8157bfd9-53ef-bf1c-e718-01ab513c5422@efes.iucc.ac.il> On 25/07/2018 05:37, Aftab Siddiqui wrote: > Exactly, getting the right and updated info is so tricky that people only > filter Private+Reserved ASNs. Because of the same reason more than 600 > unallocated ASNs are in the routing table as per the CIDR-Report. > > Wouldn't that be simple to parse the list and start updating filters on > daily basis? I understand its troublesome for big operators. I've just > started this so lets see what happens :) but I can tell that the diff on > file created every night isn't much (around 10-20). > > http://www.cidr-report.org/as2.0/#Bogons > Been there, done that - 15 years ago with Barry: https://www.nanog.org/meetings/nanog27/presentations/hank.pdf IPs, ASNs, it don't matter...no one gives a sh*t.  Not today, not 15 years ago. Nowadays, the bible on being a good ISPs is defined by MANRS and if it don't appear there then you and I are clearly delusional. -Hank From morrowc.lists at gmail.com Wed Jul 25 05:11:46 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 25 Jul 2018 01:11:46 -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: On Tue, Jul 24, 2018 at 8:55 PM Dan Hollis wrote: > I'm saying people who filter their abuse mailboxes need to stop doing so. > > it's totally possible that the person who 'runs' the abuse@ is not the person that 'runs' the mail system at the places in question. the larger the organization the certainty of that being true. (yes people should lear, no they probably all won't) -chris From dcorbe at hammerfiber.com Wed Jul 25 05:15:05 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Wed, 25 Jul 2018 01:15:05 -0400 Subject: unwise filtering policy on abuse mailboxes In-Reply-To: References: <20180725024253.9D06E2002D2235@ary.qy> Message-ID: <908B6621-37EB-4782-8619-DFB83E7F9728@hammerfiber.com> Maybe he’s hoping there’s an off chance that someone from psychz.net is subscribed and listening. After all they run a network and this is an operational mailing list. at 10:54 PM, Mel Beckman wrote: > Why are you telling us here on Nanog? > -mel From phil.lavin at cloudcall.com Wed Jul 25 08:35:17 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Wed, 25 Jul 2018 08:35:17 +0000 Subject: AS205869, AS57166: Featured Hijacker of the Month, July, 2018 In-Reply-To: <31053.1532458916@segfault.tristatelogic.com> References: <20180724.090316.47077931.sthaug@nethelp.no> <31053.1532458916@segfault.tristatelogic.com> Message-ID: > But this is a rather entirely different case. In this case, it seems that one very notable peering that -did- in fact exist, between AS205869 and AS6939, was not reported at all on the bgp.he.net page linked to above. HE usually learn these hijacked routes from IX peering and route servers. bgp.he.net tends not to report on IX peering. To their credit, HE have an extremely open peering policy. To their detriment, this means their customers see the large majority of hijacked routes due to poor filtering on many IX route servers. From jerome at ceriz.fr Wed Jul 25 10:58:46 2018 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Wed, 25 Jul 2018 12:58:46 +0200 Subject: AS205869, AS57166: Featured Hijacker of the Month, July, 2018 In-Reply-To: <27526.1532406494@segfault.tristatelogic.com> References: <27526.1532406494@segfault.tristatelogic.com> Message-ID: <578e22a7-d909-1a55-5bfe-88045d1f4bfc@ceriz.fr> Hi Ronald, >From your initial list, I can still see some prefixes with the NLnog ring : http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=206.41.128.0 http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=52.128.192.0 http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=206.222.128.0 Also http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=94.130.90.152 Best regards, From job at ntt.net Wed Jul 25 11:05:24 2018 From: job at ntt.net (Job Snijders) Date: Wed, 25 Jul 2018 13:05:24 +0200 Subject: AS205869, AS57166: Featured Hijacker of the Month, July, 2018 In-Reply-To: <578e22a7-d909-1a55-5bfe-88045d1f4bfc@ceriz.fr> References: <27526.1532406494@segfault.tristatelogic.com> <578e22a7-d909-1a55-5bfe-88045d1f4bfc@ceriz.fr> Message-ID: <20180725110524.GB1359@hanna.meerval.net> On Wed, Jul 25, 2018 at 12:58:46PM +0200, Jérôme Nicolle wrote: > From your initial list, I can still see some prefixes with the NLnog ring : > > http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=206.41.128.0 > http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=52.128.192.0 > http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=206.222.128.0 > > Also http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=94.130.90.152 If I have to guess, those probably are ghost or stale routes. Wouldn't worry about them. I've noticed that quite a bunch of networks that use "BGP optimisers" end up reporting having certain routes to the NLNOG LG while in reality those were withdrawn globally. Kind regards, Job From Jacques.Latour at cira.ca Wed Jul 25 14:10:03 2018 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Wed, 25 Jul 2018 14:10:03 +0000 Subject: Finally some common sense - No to blocking DNS Message-ID: This is good news for the internet up here! It's unconstitutional to block DNS access!!! JF must be happy :) https://www.theglobeandmail.com/canada/article-court-rejects-quebecs-bid-to-ban-citizens-access-to-private-online-2/ Court rejects Quebec's bid to ban citizens' access to private online gaming sites THE CANADIAN PRESS PUBLISHED JULY 24, 2018UPDATED 18 HOURS AGO Quebec's attempt to ban its citizens' access to online gaming websites unauthorized by the state-run gambling corporation is unconstitutional because it infringes upon federal jurisdiction, indicated a recent Superior Court ruling....... From matt at conundrum.com Wed Jul 25 14:23:36 2018 From: matt at conundrum.com (Matthew Pounsett) Date: Wed, 25 Jul 2018 10:23:36 -0400 Subject: Finally some common sense - No to blocking DNS In-Reply-To: References: Message-ID: On 25 July 2018 at 10:10, Jacques Latour wrote: > This is good news for the internet up here! It's unconstitutional to block > DNS access!!! JF must be happy :) > https://www.theglobeandmail.com/canada/article-court- > rejects-quebecs-bid-to-ban-citizens-access-to-private-online-2/ > > Court rejects Quebec's bid to ban citizens' access to private online > gaming sites > THE CANADIAN PRESS > PUBLISHED JULY 24, 2018UPDATED 18 HOURS AGO > Quebec's attempt to ban its citizens' access to online gaming websites > unauthorized by the state-run gambling corporation is unconstitutional > because it infringes upon federal jurisdiction, indicated a recent Superior > Court ruling....... > > It looks to me like the ruling is that Quebec overstepped the bounds of its authority, and not that DNS blocking is unconstitutional per se. From the look of things, it'd be perfectly fine for the feds or the CRTC to enable blocking, based solely on this ruling. And of course.. now I wonder if they'll try to invoke the Notwithstanding Clause. From joe at nethead.com Wed Jul 25 06:58:59 2018 From: joe at nethead.com (Joe Hamelin) Date: Tue, 24 Jul 2018 23:58:59 -0700 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: On Tue, Jul 24, 2018 at 10:13 PM Christopher Morrow < morrowc.lists at gmail.com> wrote: > > it's totally possible that the person who 'runs' the abuse@ is not the > person that 'runs' the mail system at the places in question. At my work you'll get an email issue addressed if you send it to postmaster@.com. RFC-2142 lays this out in section 5. In the last five years I've not had one email sent to it. This reminds me to review the others on the list to make sure they actually reach someone. Maybe a little incognito test. -Joe -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 > > From woody at pch.net Wed Jul 25 17:45:10 2018 From: woody at pch.net (Bill Woodcock) Date: Wed, 25 Jul 2018 10:45:10 -0700 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: <6D9ACA9B-1FB4-43D9-9715-F4E0CDA80606@pch.net> > On Jun 5, 2018, at 11:47 AM, Mehmet Akcin wrote: > > thank you very much to so many people who have reached out providing leads > , made introductions and followed up offering help. > > I wanted to update the list with the progress we have made so far. > > 1) We've identified several datacenter facilities where networks are > commonly present and diverse from each other with some additional network > assets. We will soon be touring these facilities. > 2) We've talked to backbone and transit providers and got incredible deals > for this market & caribbean > 3) We've engaged few "core" Content networks and asked them to join our > initiative (Great interest here but we need more.) > 4) Last but not least, we need some people on the island for bootstrapping > and ongoing support of the IX and the members (this is a challenge, I will > personally work on resolving by spending 2 weeks in August in Puerto Rico > both searching & interviewing candidates. > 5) We were offered some hardware donations but they are fairly old PCH is always willing to donate new equipment to support any IXP. We’re generally giving out 100G-capable switches for IXPs now. -Bill -------------- 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 Jamie.S.Bowden at raytheon.com Wed Jul 25 14:56:39 2018 From: Jamie.S.Bowden at raytheon.com (Jamie Bowden) Date: Wed, 25 Jul 2018 14:56:39 +0000 Subject: using expect to log into devices In-Reply-To: References: <20180724195555.B8CE6BB2@m0117566.ppops.net> Message-ID: <58b1560c854f4e6e8d3c2542244e687d@SN1F00802MB0045.008f.mgd2.msft.net> Jimmy Hess > > On Tue, Jul 24, 2018 at 9:55 PM, Scott Weeks > wrote: > > > > --- valdis.kletnieks at vt.edu wrote: > > From: valdis.kletnieks at vt.edu > > > > On Sun, 22 Jul 2018 00:43:35 +0200, Niels Bakker said: > > > Fine as a personal exercise, of course. The inability to download > > > modules seems sadistic to me, though. > > > > Yeah... just download RANCID and check the command line options. > Expect is mainly of historical interest, and the code already exists in > several forms, so no need to completely re-invent the wheel (as a square) > here. In a follow up he stated that wasn't allowed either. > I call shenanigans about the avoidance of Perl modules. No real-world > system > has such constraints. As someone who administers systems with such constraints, allow me to say that you are incorrect in your assertion. > Besides, Expect itself is a module / extension of the Tcl language and > requires the > use of dynamically-loaded extension libraries for pattern matching and > various functions, > so using Expect would break the "No modules rule". "No PERL modules" != "no dynamically linked binaries" Jamie From ESundberg at nitelusa.com Wed Jul 25 21:51:35 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Wed, 25 Jul 2018 21:51:35 +0000 Subject: Godaddy Contact needed for routing issue Message-ID: Hello, Can someone from GoDaddy's routing team contact me off list. We have customer's unable to reach www.cat5cableguys.com via the Equinix Chicago - Internet Exchange. #traceroute www.cat5cableguy.com Wed Jul 25 16:47:08.266 CDT Type escape sequence to abort. Tracing the route to 184.168.221.11 1 ge-0-0-0-8.ar1.chi1.us.nitelusa.net (207.200.195.173) 22 msec 21 msec 21 msec 2 eqix-ch.godaddy.com (208.115.136.141) 22 msec 22 msec 21 msec 3 * * * 4 * * * 5 * * * This website is reachable over other carrier's just not Equinix Chicago - Internet Exchange. Thanks Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From pkranz at unwiredltd.com Wed Jul 25 21:57:51 2018 From: pkranz at unwiredltd.com (Peter Kranz) Date: Wed, 25 Jul 2018 14:57:51 -0700 Subject: Equinix SV8 Peering fabric flooded since 1:45PM PST Message-ID: <069801d42462$885517e0$98ff47a0$@unwiredltd.com> Since around 1:45PM PST today we've been receiving a constant 10Gbps of flooding from the SV8 peering fabric. Traffic is not in the VLAN 6 peering VLAN so I haven't peeked at it. Anyone else seeing this at that exchange? Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com From amitchell at isipp.com Thu Jul 26 15:15:32 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 26 Jul 2018 09:15:32 -0600 Subject: Godaddy Contact needed for routing issue In-Reply-To: References: Message-ID: <04129F99-2D2C-4EE3-93C7-4C9DD9EC4648@isipp.com> Erik, we can help. Please contact me offlist. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance GDPR & CCPA Compliance Consultant GDPR & CCPA Compliance Certification http://www.SuretyMail.com/ http://www.SuretyMail.eu/ > Hello, > > > Can someone from GoDaddy's routing team contact me off list. > > > We have customer's unable to reach www.cat5cableguys.com via the Equinix Chicago - Internet Exchange. > > > #traceroute www.cat5cableguy.com > > Wed Jul 25 16:47:08.266 CDT > > Type escape sequence to abort. > Tracing the route to 184.168.221.11 > > 1 ge-0-0-0-8.ar1.chi1.us.nitelusa.net (207.200.195.173) 22 msec 21 msec 21 msec > 2 eqix-ch.godaddy.com (208.115.136.141) 22 msec 22 msec 21 msec > 3 * * * > 4 * * * > 5 * * * > > > > This website is reachable over other carrier's just not Equinix Chicago - Internet Exchange. > > > Thanks > > Erik > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From rod.beck at unitedcablecompany.com Thu Jul 26 16:08:08 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 26 Jul 2018 16:08:08 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> Message-ID: Well, Rob, you are wrong on almost every point. But it is not wasting our time with the Flat Earth society. Regards, Roderick. ________________________________ From: NANOG on behalf of Rob McEwen Sent: Monday, July 23, 2018 4:52 AM To: nanog at nanog.org Subject: Re: Rising sea levels are going to mess with the internet For the past 100+ years, the sea levels have been rising by about 2-4 mm per year. If you go to the following two sites: https://oceanservice.noaa.gov/facts/sealevel.html [http://oceanservice.noaa.gov/apple-icon-144x144.png] Is sea level rising? - NOAA's National Ocean Service oceanservice.noaa.gov There is strong evidence that sea level is rising and will continue to rise this century at increasing rates. https://climate.nasa.gov/vital-signs/sea-level/ You'll see all kinds of scary language about dire predictions about how the sea levels are rising and accelerating. And you'll see SCARY charts that look like Mt. Everest. But when you dig into the actual data, you'll find that there MIGHT have been (at most!) a CUMULATIVE 1mm/year acceleration... but even that took about 4 decades to materialize, it could be somewhat within the margin of error, and it might be a part of the fake data that often drives this debate. Meanwhile, global warming alarmists have ALREADY made MANY dire predictions about oceans levels rising - that ALREADY didn't even come close to true. The bottom line is that there is no trend of recently observed sea level rising data that is even close to being on track to hit all these dire predictions within the foreseeable future. And even as the West has reduced (or lessened the acceleration of) CO2 emissions - this has been easily made up for by the CO2 emission increases caused by the modernization of China and India in recent decades. And, again, there were articles like this 10, 15, and even 20 years ago that made very similar predictions - that didn't happen. So, it is hard to believe that the dire predictions in this article could come true in 15 years. But I suppose that it might be a good idea to take inventory of the absolute lowest altitude cables and make sure that they are not vulnerable to the type of flooding that might happen more often after a few decades from now after the ocean has further risen about 2 inches? But the sky is not falling anytime soon. Rob McEwen On 7/22/2018 9:01 PM, Sean Donelan wrote: > https://www.popsci.com/sea-level-rise-internet-infrastructure > > Rising sea levels are going to mess with the internet, sooner than you > think > > [...] > Despite its magnitude, this network is increasingly vulnerable to sea > levels inching their way higher, according to research presented at an > academic conference in Montreal this week. The findings estimate that > within 15 years, thousands of miles of what should be land-bound > cables in the United States will be submerged underwater. > > “Most of the climate change-related impacts are going to happen very > soon,” says Paul Barford, a computer scientist at the University of > Wisconsin and lead author of the paper. > [...] > -- Rob McEwen From sean at donelan.com Thu Jul 26 16:11:36 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 26 Jul 2018 12:11:36 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: After wildfires killed 40+ people in northern California last fall, I asked if Amazon and Google had any plans to include emergency alerts in their smart speaker/intelligent assistant products. Smart speakers seem like a way to alert people to imminent life-threatening danger during the night when they may be asleep or not aware of it. Probably not a surprise, the product managers at Amazon and Google didn't see a benefit. Instead of emergency alerts, instead the product improvement roadmap priority is on package tracking and delivery alerts :-) Also shouldn't be a surprise. Senator Schatz and Representative Gabbard have introduced bills to study the feasibility of establishing systems and signalling for emergency alerts to Internet audio and video streaming services. Its just a proposed bill for a study, for now. My opinion is it makes more sense to do emergency alerts at the smart device level (smart speaker, smart tv, smart streaming box) rather than at the content layer (hulu, netflix, spotify). Amazon Alexa, Google Assistant and Microsoft Cortana want to keep track of everything else in my life, why not if there is an emergency alert at my current location. There is a lot of opportunity to come up with better ways to notify people in ways they want, when they want, beyond tracking their package deliveries. And since its at the voluntary stage now, a chance to shape the discussion. https://www.congress.gov/bill/115th-congress/senate-bill/3238 S. 3238 To improve oversight by the Federal Communications Commission of the wireless and broadcast emergency alert systems. [...] SEC. 8. ONLINE STREAMING SERVICES EMERGENCY ALERT EXAMINATION. (a) Study.—Not later than 180 days after the date of enactment of this Act, the Commission shall complete an inquiry to examine the feasibility of establishing systems and signaling to offer Emergency Alert System alerts to audio and video streaming services delivered over the internet. (b) Report.—Not later than 90 days after completing the inquiry under subsection (a), the Commission shall submit a report on the findings and conclusions of the inquiry to— (1) the Committee on Commerce, Science, and Transportation of the Senate; and (2) the Committee on Energy and Commerce of the House of Representatives. From mel at beckman.org Thu Jul 26 16:16:42 2018 From: mel at beckman.org (Mel Beckman) Date: Thu, 26 Jul 2018 16:16:42 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, Message-ID: <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> Well, Rod, you just made a claim with zero support, while Rob provided accurate citations proving every one of his statements. But it’s not wasting our time with the Fiber Optic Networks Are Doomed by Sea Level Rise society :) See what I did there? I brought the discussion back to the original claim, which I think has now been finally thoroughly debunked. Sea levels no more threaten the Internet than marshmallows. Less, probably :) -mel > On Jul 26, 2018, at 9:08 AM, Rod Beck wrote: > > Well, Rob, you are wrong on almost every point. But it is not wasting our time with the Flat Earth society. > > > Regards, > > > Roderick. > > > ________________________________ > From: NANOG on behalf of Rob McEwen > Sent: Monday, July 23, 2018 4:52 AM > To: nanog at nanog.org > Subject: Re: Rising sea levels are going to mess with the internet > > For the past 100+ years, the sea levels have been rising by about 2-4 mm > per year. If you go to the following two sites: > > https://oceanservice.noaa.gov/facts/sealevel.html > [http://oceanservice.noaa.gov/apple-icon-144x144.png] > > Is sea level rising? - NOAA's National Ocean Service > oceanservice.noaa.gov > There is strong evidence that sea level is rising and will continue to rise this century at increasing rates. > > > https://climate.nasa.gov/vital-signs/sea-level/ > > You'll see all kinds of scary language about dire predictions about how > the sea levels are rising and accelerating. And you'll see SCARY charts > that look like Mt. Everest. But when you dig into the actual data, > you'll find that there MIGHT have been (at most!) a CUMULATIVE 1mm/year > acceleration... but even that took about 4 decades to materialize, it > could be somewhat within the margin of error, and it might be a part of > the fake data that often drives this debate. Meanwhile, global warming > alarmists have ALREADY made MANY dire predictions about oceans levels > rising - that ALREADY didn't even come close to true. > > The bottom line is that there is no trend of recently observed sea level > rising data that is even close to being on track to hit all these dire > predictions within the foreseeable future. And even as the West has > reduced (or lessened the acceleration of) CO2 emissions - this has been > easily made up for by the CO2 emission increases caused by the > modernization of China and India in recent decades. > > And, again, there were articles like this 10, 15, and even 20 years ago > that made very similar predictions - that didn't happen. So, it is hard > to believe that the dire predictions in this article could come true in > 15 years. > > But I suppose that it might be a good idea to take inventory of the > absolute lowest altitude cables and make sure that they are not > vulnerable to the type of flooding that might happen more often after a > few decades from now after the ocean has further risen about 2 inches? > But the sky is not falling anytime soon. > > Rob McEwen > > >> On 7/22/2018 9:01 PM, Sean Donelan wrote: >> https://www.popsci.com/sea-level-rise-internet-infrastructure >> >> Rising sea levels are going to mess with the internet, sooner than you >> think >> >> [...] >> Despite its magnitude, this network is increasingly vulnerable to sea >> levels inching their way higher, according to research presented at an >> academic conference in Montreal this week. The findings estimate that >> within 15 years, thousands of miles of what should be land-bound >> cables in the United States will be submerged underwater. >> >> “Most of the climate change-related impacts are going to happen very >> soon,” says Paul Barford, a computer scientist at the University of >> Wisconsin and lead author of the paper. >> [...] >> > > -- > Rob McEwen > From Brian at ampr.org Thu Jul 26 16:44:53 2018 From: Brian at ampr.org (Brian Kantor) Date: Thu, 26 Jul 2018 09:44:53 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: <20180726164453.GA12588@meow.BKantor.net> I can see my way clear to supporting this bill ONLY if it ALSO proposes to enhance the liabilities for officials of agencies who issue a false or disproportionate alert. - Brian On Thu, Jul 26, 2018 at 12:11:36PM -0400, Sean Donelan wrote: > Also shouldn't be a surprise. Senator Schatz and Representative Gabbard > have introduced bills to study the feasibility of establishing systems > and signalling for emergency alerts to Internet audio and video streaming > services. Its just a proposed bill for a study, for now. From rod.beck at unitedcablecompany.com Thu Jul 26 16:48:27 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 26 Jul 2018 16:48:27 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> Message-ID: Unfortunately, the science community disagrees with Rob and you. Have a great day, big guy. Regards, Roderick. ________________________________ From: Mel Beckman Sent: Thursday, July 26, 2018 6:16 PM To: Rod Beck Cc: Rob McEwen; nanog at nanog.org Subject: Re: Rising sea levels are going to mess with the internet Well, Rod, you just made a claim with zero support, while Rob provided accurate citations proving every one of his statements. But it’s not wasting our time with the Fiber Optic Networks Are Doomed by Sea Level Rise society :) See what I did there? I brought the discussion back to the original claim, which I think has now been finally thoroughly debunked. Sea levels no more threaten the Internet than marshmallows. Less, probably :) -mel > On Jul 26, 2018, at 9:08 AM, Rod Beck wrote: > > Well, Rob, you are wrong on almost every point. But it is not wasting our time with the Flat Earth society. > > > Regards, > > > Roderick. > > > ________________________________ > From: NANOG on behalf of Rob McEwen > Sent: Monday, July 23, 2018 4:52 AM > To: nanog at nanog.org > Subject: Re: Rising sea levels are going to mess with the internet > > For the past 100+ years, the sea levels have been rising by about 2-4 mm > per year. If you go to the following two sites: > > https://oceanservice.noaa.gov/facts/sealevel.html [http://oceanservice.noaa.gov/apple-icon-144x144.png] Is sea level rising? - NOAA's National Ocean Service oceanservice.noaa.gov There is strong evidence that sea level is rising and will continue to rise this century at increasing rates. > [http://oceanservice.noaa.gov/apple-icon-144x144.png] > > Is sea level rising? - NOAA's National Ocean Service > oceanservice.noaa.gov > There is strong evidence that sea level is rising and will continue to rise this century at increasing rates. > > > https://climate.nasa.gov/vital-signs/sea-level/ > > You'll see all kinds of scary language about dire predictions about how > the sea levels are rising and accelerating. And you'll see SCARY charts > that look like Mt. Everest. But when you dig into the actual data, > you'll find that there MIGHT have been (at most!) a CUMULATIVE 1mm/year > acceleration... but even that took about 4 decades to materialize, it > could be somewhat within the margin of error, and it might be a part of > the fake data that often drives this debate. Meanwhile, global warming > alarmists have ALREADY made MANY dire predictions about oceans levels > rising - that ALREADY didn't even come close to true. > > The bottom line is that there is no trend of recently observed sea level > rising data that is even close to being on track to hit all these dire > predictions within the foreseeable future. And even as the West has > reduced (or lessened the acceleration of) CO2 emissions - this has been > easily made up for by the CO2 emission increases caused by the > modernization of China and India in recent decades. > > And, again, there were articles like this 10, 15, and even 20 years ago > that made very similar predictions - that didn't happen. So, it is hard > to believe that the dire predictions in this article could come true in > 15 years. > > But I suppose that it might be a good idea to take inventory of the > absolute lowest altitude cables and make sure that they are not > vulnerable to the type of flooding that might happen more often after a > few decades from now after the ocean has further risen about 2 inches? > But the sky is not falling anytime soon. > > Rob McEwen > > >> On 7/22/2018 9:01 PM, Sean Donelan wrote: >> https://www.popsci.com/sea-level-rise-internet-infrastructure >> >> Rising sea levels are going to mess with the internet, sooner than you >> think >> >> [...] >> Despite its magnitude, this network is increasingly vulnerable to sea >> levels inching their way higher, according to research presented at an >> academic conference in Montreal this week. The findings estimate that >> within 15 years, thousands of miles of what should be land-bound >> cables in the United States will be submerged underwater. >> >> “Most of the climate change-related impacts are going to happen very >> soon,” says Paul Barford, a computer scientist at the University of >> Wisconsin and lead author of the paper. >> [...] >> > > -- > Rob McEwen > From aaron at heyaaron.com Thu Jul 26 16:51:04 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 26 Jul 2018 09:51:04 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: On Thu, Jul 26, 2018 at 9:14 AM Sean Donelan wrote: > Probably not a surprise, the product managers at Amazon and Google didn't > see a benefit. Instead of emergency alerts, instead the product > improvement roadmap priority is on package tracking and delivery alerts :-) > I'm not aware of a public bug tracker/feature request feature for Google Home, but the devices to support "Ok Google, feedback" (not sure about Alexa). Perhaps if people on this list gave them feedback about emergency alerts they might be able to put an count to the people requesting the feature. My opinion is it makes more sense to do emergency alerts at the smart > device level (smart speaker, smart tv, smart streaming box) rather than at > the content layer (hulu, netflix, spotify). > I agree. My TV already automatically switches between Google and Amazon devices automatically using some sort of HDMI trigger when one has a notification--completely interrupting me if I'm watching something on the other device. I can only imagine how convenient it will be for the two devices to fight back-and-forth for control of the display during an emergency. ;) Of course there's also the single-device question of: Will it work if I don't have the Hulu app open? Will Hulu run in the background and preempt? Will Hulu and Netflix start fighting for control because they both have messages? > There is a lot of opportunity to come up with better ways to notify people > in ways they want, when they want, beyond tracking their package > deliveries. And since its at the voluntary stage now, a chance to shape > the discussion. > That's the whole reason I ditched Alexa. All it would do is blink constantly and notify me that ordered had been processed, then shipped, then delivered (I know already, the UPS guy knocked), as well as constantly misunderstanding me and then asking if I wanted to purchase some random product based off the misunderstanding. The NEST guys also didn't seem very receptive to the emergency alert stuff when I contacted them. Capitalist solution: Build yet another IoT device that just does emergency alerting. Someone with free time should start a kickstarter or something. I'd totally chip in. -A From sethm at rollernet.us Thu Jul 26 16:54:10 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 26 Jul 2018 09:54:10 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> On 7/26/18 9:51 AM, Aaron C. de Bruyn via NANOG wrote: > Capitalist solution: Build yet another IoT device that just does emergency > alerting. People in tornado areas seem to be the most aware that alert radios already exist. No internet access required. From SNaslund at medline.com Thu Jul 26 16:56:08 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 16:56:08 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> Since we have been able to cope with train derailments, backhoes, forest fires, traffic accidents, etc, I am pretty confident that the networks will keep up with the lightning fast 1/8" per year rise in sea level. Steven Naslund Chicago IL From jason.w.kuehl at gmail.com Thu Jul 26 16:58:11 2018 From: jason.w.kuehl at gmail.com (Jason Kuehl) Date: Thu, 26 Jul 2018 12:58:11 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> Message-ID: Science https://climate.nasa.gov/vital-signs/sea-level/ Give the data yourself. On Thu, Jul 26, 2018 at 12:50 PM Rod Beck wrote: > Unfortunately, the science community disagrees with Rob and you. > > > Have a great day, big guy. > > > Regards, > > > Roderick. > > > ________________________________ > From: Mel Beckman > Sent: Thursday, July 26, 2018 6:16 PM > To: Rod Beck > Cc: Rob McEwen; nanog at nanog.org > Subject: Re: Rising sea levels are going to mess with the internet > > Well, Rod, you just made a claim with zero support, while Rob provided > accurate citations proving every one of his statements. > > But it’s not wasting our time with the Fiber Optic Networks Are Doomed by > Sea Level Rise society :) > > See what I did there? I brought the discussion back to the original claim, > which I think has now been finally thoroughly debunked. Sea levels no more > threaten the Internet than marshmallows. Less, probably :) > > -mel > > > On Jul 26, 2018, at 9:08 AM, Rod Beck > wrote: > > > > Well, Rob, you are wrong on almost every point. But it is not wasting > our time with the Flat Earth society. > > > > > > Regards, > > > > > > Roderick. > > > > > > ________________________________ > > From: NANOG on behalf of Rob McEwen < > rob at invaluement.com> > > Sent: Monday, July 23, 2018 4:52 AM > > To: nanog at nanog.org > > Subject: Re: Rising sea levels are going to mess with the internet > > > > For the past 100+ years, the sea levels have been rising by about 2-4 mm > > per year. If you go to the following two sites: > > > > https://oceanservice.noaa.gov/facts/sealevel.html > [http://oceanservice.noaa.gov/apple-icon-144x144.png]< > https://oceanservice.noaa.gov/facts/sealevel.html> > > Is sea level rising? - NOAA's National Ocean Service< > https://oceanservice.noaa.gov/facts/sealevel.html> > oceanservice.noaa.gov > There is strong evidence that sea level is rising and will continue to > rise this century at increasing rates. > > > > [http://oceanservice.noaa.gov/apple-icon-144x144.png]< > https://oceanservice.noaa.gov/facts/sealevel.html> > > > > Is sea level rising? - NOAA's National Ocean Service< > https://oceanservice.noaa.gov/facts/sealevel.html> > > oceanservice.noaa.gov > > There is strong evidence that sea level is rising and will continue to > rise this century at increasing rates. > > > > > > https://climate.nasa.gov/vital-signs/sea-level/ > > > > You'll see all kinds of scary language about dire predictions about how > > the sea levels are rising and accelerating. And you'll see SCARY charts > > that look like Mt. Everest. But when you dig into the actual data, > > you'll find that there MIGHT have been (at most!) a CUMULATIVE 1mm/year > > acceleration... but even that took about 4 decades to materialize, it > > could be somewhat within the margin of error, and it might be a part of > > the fake data that often drives this debate. Meanwhile, global warming > > alarmists have ALREADY made MANY dire predictions about oceans levels > > rising - that ALREADY didn't even come close to true. > > > > The bottom line is that there is no trend of recently observed sea level > > rising data that is even close to being on track to hit all these dire > > predictions within the foreseeable future. And even as the West has > > reduced (or lessened the acceleration of) CO2 emissions - this has been > > easily made up for by the CO2 emission increases caused by the > > modernization of China and India in recent decades. > > > > And, again, there were articles like this 10, 15, and even 20 years ago > > that made very similar predictions - that didn't happen. So, it is hard > > to believe that the dire predictions in this article could come true in > > 15 years. > > > > But I suppose that it might be a good idea to take inventory of the > > absolute lowest altitude cables and make sure that they are not > > vulnerable to the type of flooding that might happen more often after a > > few decades from now after the ocean has further risen about 2 inches? > > But the sky is not falling anytime soon. > > > > Rob McEwen > > > > > >> On 7/22/2018 9:01 PM, Sean Donelan wrote: > >> https://www.popsci.com/sea-level-rise-internet-infrastructure > >> > >> Rising sea levels are going to mess with the internet, sooner than you > >> think > >> > >> [...] > >> Despite its magnitude, this network is increasingly vulnerable to sea > >> levels inching their way higher, according to research presented at an > >> academic conference in Montreal this week. The findings estimate that > >> within 15 years, thousands of miles of what should be land-bound > >> cables in the United States will be submerged underwater. > >> > >> “Most of the climate change-related impacts are going to happen very > >> soon,” says Paul Barford, a computer scientist at the University of > >> Wisconsin and lead author of the paper. > >> [...] > >> > > > > -- > > Rob McEwen > > > -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl at gmail.com From SNaslund at medline.com Thu Jul 26 16:59:51 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 16:59:51 +0000 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB379@MUNPRDMBXA1.medline.com> Almost everyone with a cell phone gets real time alerts too. I am not sure how many more ways we can make people aware of things around them. Seems like yet another government mandate to dictate what a device must do. >People in tornado areas seem to be the most aware that alert radios >already exist. No internet access required. Steven Naslund Chicago IL From list at satchell.net Thu Jul 26 17:00:08 2018 From: list at satchell.net (Stephen Satchell) Date: Thu, 26 Jul 2018 10:00:08 -0700 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> Message-ID: <3d0efd74-6813-0378-1c79-fed096e59bac@satchell.net> On 07/26/2018 09:48 AM, Rod Beck wrote: > Unfortunately, the science community disagrees with Rob and you. You mean the community that lives or dies on whether they get grant money? And the way to get grant money is to justify why they could be fed MORE money. Can you imagine how the "science community" would continue to survive? Now, the medical research community is another story. Perhaps a better use for that grant money would be to develop Best Practices for installing fiber cable that can withstand immersion to a depth of 200 feet without failing -- thereby coming up with something positive in light of the so-called scientific predictions. Instead of "the sky is falling", say "here is how to prop up the sky on a dollar a day." From SNaslund at medline.com Thu Jul 26 17:02:57 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 17:02:57 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB386@MUNPRDMBXA1.medline.com> BTW, I have installed thousands of miles of fiber and been submerged in plenty of manholes over the years. If you have been in a manhole in the spring you would know what a non-event you are talking about here. A lot of your Internet is under water a lot of the time anyway (not even counting all of the oceanic stuff). >Since we have been able to cope with train derailments, backhoes, forest fires, traffic accidents, etc, I am pretty confident that the networks will keep up with the lightning fast 1/8" per year rise in >sea level. > Steven Naslund Chicago IL From rod.beck at unitedcablecompany.com Thu Jul 26 17:06:01 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 26 Jul 2018 17:06:01 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> , <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> Message-ID: I don't have a strong feeling on this matter, but it is not the average increase that matters. Every small increase in average has a multiplier effect on storm surge. http://www.pnas.org/content/early/2017/10/23/1715895114. Nonetheless, my guess is that the real threat is to general property close to the shore, not the terrestrial cables even though they are not waterproof (only submarine cable can handle long term immersion). Regards, Roderick. ________________________________ From: NANOG on behalf of Naslund, Steve Sent: Thursday, July 26, 2018 6:56 PM To: nanog at nanog.org Subject: RE: Rising sea levels are going to mess with the internet Since we have been able to cope with train derailments, backhoes, forest fires, traffic accidents, etc, I am pretty confident that the networks will keep up with the lightning fast 1/8" per year rise in sea level. Steven Naslund Chicago IL From SNaslund at medline.com Thu Jul 26 17:08:13 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 17:08:13 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> So, I accept the data. Going back to 1880 I will be generous and say that you have a 250 mm rise in sea level (which is about 10 inches for us Imperial types). I think we will probably be ready to outrun that problem. Let's get back to real network threats like BGP Hijacking which can wipe you out tomorrow. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Kuehl >Sent: Thursday, July 26, 2018 11:58 AM >To: rod.beck at unitedcablecompany.com >Cc: NANOG >Subject: Re: Rising sea levels are going to mess with the internet > >Science https://climate.nasa.gov/vital-signs/sea-level/ > >Give the data yourself. From valdis.kletnieks at vt.edu Thu Jul 26 17:08:36 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 26 Jul 2018 13:08:36 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> Message-ID: <17622.1532624916@turing-police.cc.vt.edu> On Thu, 26 Jul 2018 16:56:08 -0000, "Naslund, Steve" said: > Since we have been able to cope with train derailments, backhoes, forest > fires, traffic accidents, etc, I am pretty confident that the networks will > keep up with the lightning fast 1/8" per year rise in sea level. Have they finished fixing all the corroded copper wiring from Sandy pumping sea water into lower Manhattan? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Thu Jul 26 17:09:14 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 26 Jul 2018 13:09:14 -0400 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> Message-ID: <17707.1532624954@turing-police.cc.vt.edu> On Thu, 26 Jul 2018 09:54:10 -0700, Seth Mattinen said: > People in tornado areas seem to be the most aware that alert radios > already exist. No internet access required. Do those use a frequency band that's suitable for cellphones to monitor (antenna size, power, etc)? Because your best chance of getting my attention in an emergency is to make my phone start shrieking. (For what it's worth, I actually did get an Amber Alert on my phone last night, and a phone-based weather alert as well) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From SNaslund at medline.com Thu Jul 26 17:10:14 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 17:10:14 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> , <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB3E2@MUNPRDMBXA1.medline.com> I know of tons of manholes that are continuously full of water every time I have been out to them, I am pretty sure those cables have dealt with the immersion for quite a number of years. Steven Naslund Chicago IL >I don't have a strong feeling on this matter, but it is not the average increase that matters. Every small increase in average has a multiplier effect on storm surge. >http://www.pnas.org/content/early/2017/10/23/1715895114. > >Nonetheless, my guess is that the real threat is to general property close to the shore, not the terrestrial cables even though they are not waterproof (only submarine cable can handle long term immersion). > >Regards, > >Roderick. From rod.beck at unitedcablecompany.com Thu Jul 26 17:11:14 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 26 Jul 2018 17:11:14 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <3d0efd74-6813-0378-1c79-fed096e59bac@satchell.net> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> , <3d0efd74-6813-0378-1c79-fed096e59bac@satchell.net> Message-ID: That is true of all science today, Stephen. That is a particularly bad argument on your part. Virtually all science depends on grants and academic and government financing. So you are invoking conspiracy theories. Good work. ________________________________ From: NANOG on behalf of Stephen Satchell Sent: Thursday, July 26, 2018 7:00 PM To: nanog at nanog.org Subject: Re: Rising sea levels are going to mess with the internet On 07/26/2018 09:48 AM, Rod Beck wrote: > Unfortunately, the science community disagrees with Rob and you. You mean the community that lives or dies on whether they get grant money? And the way to get grant money is to justify why they could be fed MORE money. Can you imagine how the "science community" would continue to survive? Now, the medical research community is another story. Perhaps a better use for that grant money would be to develop Best Practices for installing fiber cable that can withstand immersion to a depth of 200 feet without failing -- thereby coming up with something positive in light of the so-called scientific predictions. Instead of "the sky is falling", say "here is how to prop up the sky on a dollar a day." From cma at cmadams.net Thu Jul 26 17:12:07 2018 From: cma at cmadams.net (Chris Adams) Date: Thu, 26 Jul 2018 12:12:07 -0500 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: <20180726171207.GA14114@cmadams.net> Once upon a time, Sean Donelan said: > After wildfires killed 40+ people in northern California last fall, > I asked if Amazon and Google had any plans to include emergency > alerts in their smart speaker/intelligent assistant products. Smart > speakers seem like a way to alert people to imminent > life-threatening danger during the night when they may be asleep or > not aware of it. My biggest concern is them making such alerts mandatory. At a minimum they should be opt-out; a one-time notice during setup (or when the functionality is added) to allow opt-in would be better IMHO. You don't know what I might be streaming on that speaker; could be I'm listening to scanner traffic from storm spotters for example. I have been closely watching local TV station radar coverage of a radar-indicated tornado heading towards my home when the cable system takes over my TiVo to play the NWS tornado warning message. That takes a couple of minutes minutes, during which changing the channel is disabled (and there's no way to opt out of such cable-sent alerts). This is highly counter-productive; it just means that now I know when there's dangerous weather headed towards my home, I cannot use TV for tracking it unless I get out an antenna-fed portable TV. -- Chris Adams From rod.beck at unitedcablecompany.com Thu Jul 26 17:12:43 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 26 Jul 2018 17:12:43 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB3E2@MUNPRDMBXA1.medline.com> References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> , <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> , <9578293AE169674F9A048B2BC9A081B402D1DEB3E2@MUNPRDMBXA1.medline.com> Message-ID: Easy way to settle it. Look at Hurricane Sandy and Katrina. If they had no effect on terrestrial cables, then this is probably a misplaced concern. - R. ________________________________ From: Naslund, Steve Sent: Thursday, July 26, 2018 7:10 PM To: Rod Beck; nanog at nanog.org Subject: RE: Rising sea levels are going to mess with the internet I know of tons of manholes that are continuously full of water every time I have been out to them, I am pretty sure those cables have dealt with the immersion for quite a number of years. Steven Naslund Chicago IL >I don't have a strong feeling on this matter, but it is not the average increase that matters. Every small increase in average has a multiplier effect on storm surge. >http://www.pnas.org/content/early/2017/10/23/1715895114. Rising hazard of storm-surge flooding www.pnas.org The 2017 Atlantic hurricane season is one for the history books. It has blown a number of records out of the water. Harvey dumped more rain on the United States than any previous hurricane. Irma maintained the highest category 5 longer than any storm anywhere in the world. September 2017 has accumulated the most cyclone energy of any month on record in the Atlantic. Last, but not least, if early estimates of damages hold up, three of the five costliest storms in US history will have occurred this year: Harvey, Irma, and Maria (1⇓–3). The other two are Katrina and Sandy, which flooded New Orleans in 2005 and New York in 2012 (Fig. 1), respectively. A new study in PNAS by Garner et al. (4) tackles a critical and highly topical question: How will coastal flood risk change in the future on a warming Earth? They approach this question in a case study for New York, but most coastal cities in the world will be facing similar issues in the coming decades and, indeed, centuries. Fig. 1. Map of New York City floodi > >Nonetheless, my guess is that the real threat is to general property close to the shore, not the terrestrial cables even though they are not waterproof (only submarine cable can handle long term immersion). > >Regards, > >Roderick. From SNaslund at medline.com Thu Jul 26 17:13:07 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 17:13:07 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <17622.1532624916@turing-police.cc.vt.edu> References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> <17622.1532624916@turing-police.cc.vt.edu> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB3F3@MUNPRDMBXA1.medline.com> Don't know but the backbone of the Internet is not running on it. Also, a hurricane is not the same as a rise in sea level at less than 10" per century which was the threat described here. There are all kinds of floods for reasons other than rising sea levels. Steven Naslund Chicago IL >-----Original Message----- >From: Valdis Kletnieks [mailto:valdis at vt.edu] On Behalf Of valdis.kletnieks at vt.edu >Sent: Thursday, July 26, 2018 12:09 PM >To: Naslund, Steve >Cc: nanog at nanog.org >Subject: Re: Rising sea levels are going to mess with the internet > > >Have they finished fixing all the corroded copper wiring from Sandy pumping sea water into lower Manhattan? From cboyd at gizmopartners.com Thu Jul 26 17:13:35 2018 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 26 Jul 2018 12:13:35 -0500 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> Message-ID: <8B65672B-F557-4373-B9A3-6DC3BD1A5861@gizmopartners.com> > On Jul 26, 2018, at 11:54 AM, Seth Mattinen wrote: > > People in tornado areas seem to be the most aware that alert radios already exist. No internet access required. For those interested in more info, http://www.nws.noaa.gov/nwr/ Pretty popular service in rural Texas. —Chris From rod.beck at unitedcablecompany.com Thu Jul 26 17:16:11 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 26 Jul 2018 17:16:11 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB386@MUNPRDMBXA1.medline.com> References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com>, <9578293AE169674F9A048B2BC9A081B402D1DEB386@MUNPRDMBXA1.medline.com> Message-ID: But the reality is that if you get bigger storm surges, your Internet access will be knocked. You will get loss of power and even if the backbone holds up, the access networks will not. Every time we get a severe flood here in Budapest, power is knocked out and we are down hard. The general population may not take much comfort in your installation of thousands of miles of fiber. Just a fact. Regards, Roderick. ________________________________ From: NANOG on behalf of Naslund, Steve Sent: Thursday, July 26, 2018 7:02 PM To: nanog at nanog.org Subject: RE: Rising sea levels are going to mess with the internet BTW, I have installed thousands of miles of fiber and been submerged in plenty of manholes over the years. If you have been in a manhole in the spring you would know what a non-event you are talking about here. A lot of your Internet is under water a lot of the time anyway (not even counting all of the oceanic stuff). >Since we have been able to cope with train derailments, backhoes, forest fires, traffic accidents, etc, I am pretty confident that the networks will keep up with the lightning fast 1/8" per year rise in >sea level. > Steven Naslund Chicago IL From SNaslund at medline.com Thu Jul 26 17:16:16 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 17:16:16 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> , <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> , <9578293AE169674F9A048B2BC9A081B402D1DEB3E2@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB419@MUNPRDMBXA1.medline.com> Again, the original argument was about rising ocean levels not all causes of floods. Are floods a threat, yep but not as much as it used to be before fiber. Is the rise of ocean levels by 10” per century the cause of all floods, no its not. Steven Naslund Chicago IL >From: Rod Beck [mailto:rod.beck at unitedcablecompany.com] >Sent: Thursday, July 26, 2018 12:13 PM >To: Naslund, Steve; nanog at nanog.org >Subject: Re: Rising sea levels are going to mess with the internet > >Easy way to settle it. Look at Hurricane Sandy and Katrina. If they had no effect on terrestrial cables, then this is probably a misplaced concern. > >- R. From bill at herrin.us Thu Jul 26 17:16:40 2018 From: bill at herrin.us (William Herrin) Date: Thu, 26 Jul 2018 13:16:40 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> Message-ID: On Thu, Jul 26, 2018 at 12:58 PM, Jason Kuehl wrote: > Science https://climate.nasa.gov/vital-signs/sea-level/ "The first graph tracks the change in sea level since 1993 as observed by satellites." I *really* want to understand the technology that lets a satellite hundreds of miles in the sky detect a 3mm change in average global sea level between the start and end of the year with an error bar that grows to only 4mm over a quarter of a century. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From SNaslund at medline.com Thu Jul 26 17:23:56 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 17:23:56 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: , <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com>, , <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com>, <9578293AE169674F9A048B2BC9A081B402D1DEB386@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB44D@MUNPRDMBXA1.medline.com> If you live near a coast, you are going to experience bigger storms and loss of power more often than someone that lives inland. If you live in the Himalayas you are going to get more snow and cold weather. Not my problem if you like your beach front property. However I have not seen any major damage to fiber based networks and I was a first responder during Hurricane Katrina. The majority of damage was to flooded central offices which is going to happen from time to time no matter where you are at. Overall network reliability has increased greatly over the years which is undeniable. This all just seems very alarmist to me. Also, even if we assume you are correct about ocean levels threatening networks (which I don't believe to be even close to the biggest threats), what exactly can the NANOG community do about it for you. There are real, live, NOW, threats like the BGP hijackings that have been responded to that are real operational responses. Steven Naslund Chicago IL >But the reality is that if you get bigger storm surges, your Internet access will be knocked. You will get loss of power and even if the backbone holds up, the access networks will not. Every time we get a severe flood here in Budapest, power is >knocked out and we are down hard. The general population may not take much comfort in your installation of thousands of miles of fiber. Just a fact. > >Regards, > >Roderick. From nate at santafe.edu Thu Jul 26 17:30:39 2018 From: nate at santafe.edu (Nate Metheny) Date: Thu, 26 Jul 2018 11:30:39 -0600 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <17707.1532624954@turing-police.cc.vt.edu> References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> <17707.1532624954@turing-police.cc.vt.edu> Message-ID: <32d45b5d-e0a8-63ed-3654-4d6be33ae8f8@santafe.edu> No. NWR requires a special radio receiver or scanner capable of picking up the signal. Broadcasts are found in the VHF public service band at these seven frequencies (MHz): 162.400 162.425 162.450 162.475 162.500 162.525 162.550 Although, you can buy a wind-up weather radio receiver for $20 that doesn't require batteries or a charger (really helpful when you have an actual emergency and can't rely on an iDevice, or a congested network, for your information). On 07/26/2018 11:09 AM, valdis.kletnieks at vt.edu wrote: > On Thu, 26 Jul 2018 09:54:10 -0700, Seth Mattinen said: > >> People in tornado areas seem to be the most aware that alert radios >> already exist. No internet access required. > > Do those use a frequency band that's suitable for cellphones to monitor (antenna > size, power, etc)? Because your best chance of getting my attention in an emergency > is to make my phone start shrieking. > > (For what it's worth, I actually did get an Amber Alert on my phone last night, and > a phone-based weather alert as well) > -- .==== === -- - -- - - - - - ---. | Nate Metheny Director, Technology | | Santa Fe Institute office 505.946.2730 | | cell 505.672.8790 fax 505.982.0565 | | http://www.santafe.edu nate at santafe.edu | `--- - -- - - -- - = == ===' -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3804 bytes Desc: S/MIME Cryptographic Signature URL: From cboyd at gizmopartners.com Thu Jul 26 17:31:31 2018 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 26 Jul 2018 12:31:31 -0500 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <17707.1532624954@turing-police.cc.vt.edu> References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> <17707.1532624954@turing-police.cc.vt.edu> Message-ID: > On Jul 26, 2018, at 12:09 PM, valdis.kletnieks at vt.edu wrote: > > Do those use a frequency band that's suitable for cellphones to monitor (antenna > size, power, etc)? Because your best chance of getting my attention in an emergency > is to make my phone start shrieking. VHF, on 7 frequencies: 162.400 162.425 162.450 162.475 162.500 162.525 162.550 That’s about 1.85 meter wavelength, so a quarter wave antenna would be pretty large. I’m sure the RF engineers can come up with a way to listen effectively without a huge antenna. —Chris From rod.beck at unitedcablecompany.com Thu Jul 26 17:32:12 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 26 Jul 2018 17:32:12 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> , <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> Message-ID: Steve, You are simply wrong. The sea level is rising at an increasing rate. The average sea level will go up by 30 centimeters to 1 meter by 2100. And of course, the storm surge will increase by a multiple of that. Sources: NOAA. It means access networks along the two coasts will be increasingly down. r. - ________________________________ From: NANOG on behalf of Naslund, Steve Sent: Thursday, July 26, 2018 7:08 PM To: nanog at nanog.org Subject: RE: Rising sea levels are going to mess with the internet So, I accept the data. Going back to 1880 I will be generous and say that you have a 250 mm rise in sea level (which is about 10 inches for us Imperial types). I think we will probably be ready to outrun that problem. Let's get back to real network threats like BGP Hijacking which can wipe you out tomorrow. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Kuehl >Sent: Thursday, July 26, 2018 11:58 AM >To: rod.beck at unitedcablecompany.com >Cc: NANOG >Subject: Re: Rising sea levels are going to mess with the internet > >Science https://climate.nasa.gov/vital-signs/sea-level/ > >Give the data yourself. From cma at cmadams.net Thu Jul 26 17:32:16 2018 From: cma at cmadams.net (Chris Adams) Date: Thu, 26 Jul 2018 12:32:16 -0500 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <17707.1532624954@turing-police.cc.vt.edu> References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> <17707.1532624954@turing-police.cc.vt.edu> Message-ID: <20180726173216.GB14114@cmadams.net> Once upon a time, valdis.kletnieks at vt.edu said: > Do those use a frequency band that's suitable for cellphones to monitor (antenna > size, power, etc)? Because your best chance of getting my attention in an emergency > is to make my phone start shrieking. NOAA Weather Radio frequencies are in the 162 MHz band. I have no idea how well a cell-phone could pick that up, but even if they could, it's going to be a power draw. Also, there are 7 different channels, and the phone would have to know which channel to tune for the local area. For phones, it is much more practical to use the (already provided) notifications from the cell network (which you can mostly opt out of as well). -- Chris Adams From bill at herrin.us Thu Jul 26 17:48:56 2018 From: bill at herrin.us (William Herrin) Date: Thu, 26 Jul 2018 13:48:56 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> Message-ID: On Thu, Jul 26, 2018 at 1:06 PM, Rod Beck wrote: > only submarine cable can handle long term immersion Any gel-core direct burial cable can handle long-term shallow water immersion. Steve is correct: the fiber in many manholes are underwater until the next time someone needs to climb down and make a new splice. I once asked a dark fiber provider to splice from a particular manhole and they had to send someone out to look because it had somehow fallen off their map. When they popped the cover to look, the vault was completely inundated. Hadn't caused them the slightest difficulty. Submarine cable is needed for deeper water (higher pressures) with more armor against damage since it's just laying on the seafloor exposed to everything that happens by. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From sean at donelan.com Thu Jul 26 17:53:21 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 26 Jul 2018 13:53:21 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> Message-ID: On Thu, 26 Jul 2018, Seth Mattinen wrote: > On 7/26/18 9:51 AM, Aaron C. de Bruyn via NANOG wrote: >> Capitalist solution: Build yet another IoT device that just does emergency >> alerting. > > People in tornado areas seem to be the most aware that alert radios already > exist. No internet access required. I remember 15 years ago, when the cellular carriers argued they shouldn't be required to build emergency notifications into cell phones (I know OEM make the phones). The carriers said it was unneccessary because of alternative ways to notify the public about emergencies, i.e. radio, outdoor sirens, etc. About 2% to 5% of households have weather alert radios. The 5% is in severe weather (tornado) areas, the rest of the country is less. But catastrophes aren't limited to particular severe weather areas. If we knew where fires would start, we would only put smoke detectors in those places. About 18% (and growing) of households have smart speakers, and about 58% of households have a "connected" device of some kind. The number of households with working am/fm radios is 71% (and declining). Younger generations (15 to 39-year olds) are even less likely to have working am/fm radios in the home (43%). If you are listening to a local radio station streaming over a smart speaker, the streaming channel usually has different ads than the over-the-air radio broadcast and does not include emergency notifications. Televisions households haven't declined as much. However, about 11% of "smart" televisions now are only used for over-the-top internet programming. In other words, 11% of unconnected "smart" televisions do not have a cable coax or an over-the-air antenna connected, and would not get any emergency notifications. If the product managers for smart speakers and smart TVs are successful, and replace am/fm radios and cable/over-the-air TVs in households, eventually there will be a catastrophe. After the catstrophe, the public (and politicians) will likely ask why didn't they get a emergency warning from their smart speakers and smart TVs like they used to get from their old am/fm radios and old TVs? From sethm at rollernet.us Thu Jul 26 18:00:45 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 26 Jul 2018 11:00:45 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB379@MUNPRDMBXA1.medline.com> References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> <9578293AE169674F9A048B2BC9A081B402D1DEB379@MUNPRDMBXA1.medline.com> Message-ID: <3fc0fc37-ac2b-7ffe-e686-65caebd94ea8@rollernet.us> On 7/26/18 9:59 AM, Naslund, Steve wrote: > Almost everyone with a cell phone gets real time alerts too. I am not sure how many more ways we can make people aware of things around them. Seems like yet another government mandate to dictate what a device must do. > >> People in tornado areas seem to be the most aware that alert radios >> already exist. No internet access required. > The next question would be, was the system used to alert for the wildfires? It already exists and has a code for fires. https://en.wikipedia.org/wiki/Specific_Area_Message_Encoding If it wasn't activated for the fires, why not? If it was and people just don't have alert radios, maybe there should be some education to go buy one if you live in wildfire prone areas just like how people that live in tornado prone areas usually have one (or more). They come in portable or fixed, and some have alarms louder than any cell phone. From cma at cmadams.net Thu Jul 26 18:00:53 2018 From: cma at cmadams.net (Chris Adams) Date: Thu, 26 Jul 2018 13:00:53 -0500 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> Message-ID: <20180726180053.GC14114@cmadams.net> Once upon a time, William Herrin said: > On Thu, Jul 26, 2018 at 12:58 PM, Jason Kuehl wrote: > > Science https://climate.nasa.gov/vital-signs/sea-level/ > > "The first graph tracks the change in sea level since 1993 as observed > by satellites." > > I *really* want to understand the technology that lets a satellite > hundreds of miles in the sky detect a 3mm change in average global sea > level between the start and end of the year with an error bar that > grows to only 4mm over a quarter of a century. Well, you must not *really* want to understand, since there's a "Learn more" link to follow on the above page that (after a couple more clicks) would lead you to this page that has some explanation: https://www.aviso.altimetry.fr/en/techniques/altimetry.html -- Chris Adams From egon at egon.cc Thu Jul 26 18:13:51 2018 From: egon at egon.cc (James Downs) Date: Thu, 26 Jul 2018 11:13:51 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> <17707.1532624954@turing-police.cc.vt.edu> Message-ID: <20180726181351.GL28957@nemesis.egontech.com> On Thu, Jul 26, 2018 at 12:31:31PM -0500, Chris Boyd wrote: > That’s about 1.85 meter wavelength, so a quarter wave antenna would be pretty large. I’m sure the RF engineers can come up with a way to listen effectively without a huge antenna. For 162Mhz, a 1/4 wave antenna would have a vertical radiating element of around 17". However, for receive only purposes, it's not necessary that the antenna be resonant. You can demonstrate this yourself with any FM radio and a paperclip. Cheers, -j From sean at donelan.com Thu Jul 26 18:28:30 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 26 Jul 2018 14:28:30 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: <20180726171207.GA14114@cmadams.net> References: <20180726171207.GA14114@cmadams.net> Message-ID: On Thu, 26 Jul 2018, Chris Adams wrote: > My biggest concern is them making such alerts mandatory. At a minimum > they should be opt-out; a one-time notice during setup (or when the > functionality is added) to allow opt-in would be better IMHO. That's a reason to get involved early, when everything is voluntary and the decisions haven't been decided yet. Even though no rule requires it, Google adds emergency alerts to the top of its search result pages. google.org/publicalerts shows government alerts around the world. Google does a nice job of integrating the results, even giving suggestions about what to do for several standard types of alerts. Its possible to create a nice user-focused design. When I was the SBC (now AT&T) u-verse "emergency alert product manager," because no one else wanted that job, I discovered the EAS/WEA rules are very flexible. Lots of things being done by competitors weren't actually required. Instead it was because things had always done that way, not because any rule required it. For example, I added a "dismiss alert" button to u-Verse EAS alert product so you could immediately get ride of alerts you didn't care about or change channels. I also worked with the IPTV middleware vendor to ensure u-verse EAS alerts were not recorded by the DVR, and didn't interrupt the DVR recording. One advantage of not recording the EAS by the u-verse DVR, if EAS came during the game-winning home-run during the World Series, you could hit rewind on the DVR and see/hear what you missed because it was still recording in the background. I've felt that some companies deliberately make the emergency notification product on their cell phones and cable/tv as attrocious as possible as a middle-finger response to the government requiring them to do it. Because almost all emergency notifications are voluntary, company product managers can give you a lot of choice which, when, and how you get emergency notifications. But its easier/cheaper for product managers to treat it as a compliance thing, lobby against it, and not spend any effort on a user-centered design for their alert notifications. I keep expecting after catastrophe happens in pacific northwest or silicon valley, some company executives and product managers will suddenly add emergency notifications to their smart speaker and smart tv product roadmaps. From Daniel.Jameson at tdstelecom.com Thu Jul 26 19:09:33 2018 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Thu, 26 Jul 2018 19:09:33 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <20180726180053.GC14114@cmadams.net> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <20180726180053.GC14114@cmadams.net> Message-ID: Its not satellite data, it's the exact same data-set that NOAA provides for ocean levels; The data is from tidal sensors; the data is relayed via satellite so... technically ;). It's kind of funny the data in the table, vs the chart-data presented, some .orgs say 80mm, some say 60mm all depends on when you start counting. I'd like to see the raw data, geospatially portray it, and get a sense of the true impact; an average of a statisticcal averages, smoothed and corrected over 60 days with a self-ratcheting baseline... Not sure how valuable the data here is other than support a presupposition. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Adams Sent: Thursday, July 26, 2018 12:01 PM To: nanog at nanog.org Subject: Re: Rising sea levels are going to mess with the internet Once upon a time, William Herrin said: > On Thu, Jul 26, 2018 at 12:58 PM, Jason Kuehl wrote: > > Science https://climate.nasa.gov/vital-signs/sea-level/ > > "The first graph tracks the change in sea level since 1993 as observed > by satellites." > > I *really* want to understand the technology that lets a satellite > hundreds of miles in the sky detect a 3mm change in average global sea > level between the start and end of the year with an error bar that > grows to only 4mm over a quarter of a century. Well, you must not *really* want to understand, since there's a "Learn more" link to follow on the above page that (after a couple more clicks) would lead you to this page that has some explanation: https://www.aviso.altimetry.fr/en/techniques/altimetry.html -- Chris Adams From cma at cmadams.net Thu Jul 26 19:15:02 2018 From: cma at cmadams.net (Chris Adams) Date: Thu, 26 Jul 2018 14:15:02 -0500 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <20180726180053.GC14114@cmadams.net> Message-ID: <20180726191502.GD14114@cmadams.net> Once upon a time, Jameson, Daniel said: > Its not satellite data, it's the exact same data-set that NOAA provides for ocean levels; The data is from tidal sensors; the data is relayed via satellite so... technically ;). No, you are wrong. Did you read any of the provided links? It is actually gathered with satellite-based radar and laser systems, not tidal sensors. -- Chris Adams From sean at donelan.com Thu Jul 26 19:16:58 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 26 Jul 2018 15:16:58 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: <20180726164453.GA12588@meow.BKantor.net> References: <20180726164453.GA12588@meow.BKantor.net> Message-ID: On Thu, 26 Jul 2018, Brian Kantor wrote: > I can see my way clear to supporting this bill ONLY if it ALSO > proposes to enhance the liabilities for officials of agencies > who issue a false or disproportionate alert. Section 5 of the proposed bill is about emergency alert best practices. That includes best practices for officials to avoid issuing false alerts. https://www.congress.gov/bill/115th-congress/senate-bill/3238/text For non-weather emergencies, you are far more likely NOT to get any warning during a catastrophe. Almost all of the deaths have occured when emergency officials did not have, did not use or had problems activating warning systems. Local officials don't get a lot of practice issuing public warnings, and tend to be shy about issuing public warnings until its too late. For weather warnings, the National Weather Service tends to issue a lot of warnings. Weather radios let you turn off types of warning messages you aren't interested. I want to be woken up before a tsunami, I don't want to be woken up about coastal flooding. Weather fatalities http://www.nws.noaa.gov/om/hazstats.shtml Yes, false alerts happen. False alerts should be minimized. You are extremelly unlikely to die as the result of a false alert. Lack of warning really sucks when it happens to you. Its even worse than missing your package delivery notification. From bill at herrin.us Thu Jul 26 19:18:46 2018 From: bill at herrin.us (William Herrin) Date: Thu, 26 Jul 2018 15:18:46 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <20180726180053.GC14114@cmadams.net> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <20180726180053.GC14114@cmadams.net> Message-ID: On Thu, Jul 26, 2018 at 2:00 PM, Chris Adams wrote: > Once upon a time, William Herrin said: >> On Thu, Jul 26, 2018 at 12:58 PM, Jason Kuehl wrote: >> > Science https://climate.nasa.gov/vital-signs/sea-level/ >> >> "The first graph tracks the change in sea level since 1993 as observed >> by satellites." >> >> I *really* want to understand the technology that lets a satellite >> hundreds of miles in the sky detect a 3mm change in average global sea >> level between the start and end of the year with an error bar that >> grows to only 4mm over a quarter of a century. > > Well, you must not *really* want to understand, since there's a "Learn > more" link to follow on the above page that (after a couple more clicks) > would lead you to this page that has some explanation: > > https://www.aviso.altimetry.fr/en/techniques/altimetry.html Chris, I understand how radar altimetry works. I would like to understand how they achieve the claimed precision. 3.2mm is one heck of a precise measurement from a flying platform hundreds of kilometers away, particularly when that requires the platform itself to be located with even higher precision against some reference points deemed stable for the purpose of making the measurement. On Thu, Jul 26, 2018 at 3:09 PM, Jameson, Daniel wrote: > Its not satellite data, The data is from tidal sensors The second chart is from tidal sensors. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bzs at theworld.com Thu Jul 26 19:29:01 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 26 Jul 2018 15:29:01 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> Message-ID: <23386.8445.684160.527397@gargle.gargle.HOWL> On July 26, 2018 at 16:56 SNaslund at medline.com (Naslund, Steve) wrote: > > Since we have been able to cope with train derailments, backhoes, forest fires, traffic accidents, etc, I am pretty confident that the networks will keep up with the lightning fast 1/8" per year rise in sea level. Anthropologists say (there was a pretty good article on this in The Atlantic a year or two ago) that's what we (humanity) have done historically, adapted, eventually learned to eat acorns or rats or whatever*. And very little if anything to combat the basic problem even if we understood it well enough. We'll adapt and adapt because the problems tend to evolve slowly. Unfortunately I tend to think that's the likely outcome here simply because whatever we (more developed countries) do several billion people out there will undo faster because let's face it they want to eat regularly, have reliable electricity, etc. etc. etc. And a lot of what could be done works against their getting all that, at least if it's limited to their means. Perhaps not in theory. But call me when the G8 or G20 proposes to plunk down the many trillions it would likely cost to provide the rest of them with fertilizer and farming techniques and energy generation plants and so on which aren't contributing to the problem. Didn't India recently state that they won't even talk about slowing down the rate of increase (2nd derivative) of coal usage for at least ten years? Not picking on India, they have their reasons, but just trying to be realistic and move past these late-night dorm room bull sessions about how the world ought to work. * One significant exception was crop and field rotation which worked very well where it was possible. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From SNaslund at medline.com Thu Jul 26 19:39:03 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 19:39:03 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> , <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB707@MUNPRDMBXA1.medline.com> In 2000 the network runs on completely different infrastructure than it did in 1900 (what little network existed). By 2100 I am pretty sure we will be on different infrastructure by then. Are you saying there will be no changes in network topology to account for that? By 2100 neither you or I will have to worry about it in any case unless you know of a more major breakthrough in the near future. Steve >Steve, > >You are simply wrong. The sea level is rising at an increasing rate. The average sea level will go up by 30 centimeters to 1 meter by 2100. And of course, the storm surge will increase by a multiple of that. > >Sources: NOAA. > >It means access networks along the two coasts will be increasingly down. >r. - From rob at invaluement.com Thu Jul 26 19:39:51 2018 From: rob at invaluement.com (Rob McEwen) Date: Thu, 26 Jul 2018 15:39:51 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> Message-ID: <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> On 7/26/2018 1:32 PM, Rod Beck wrote: > You are simply wrong. The sea level is rising at an increasing rate. The average sea level will go up by 30 centimeters to 1 meter by 2100. And of course, the storm surge will increase by a multiple of that. Sources: NOAA. Looking at the SAME sources (NOAA, NASA, etc) - as scary as those "Mt Everest" charts look (where they make 3.5mm/year rising look like Mt Everest) - the lines on THEIR charts are ALMOST perfectly straight and JUST BARELY curve upwards. So I dug into THEIR actual data - and even THEIR data shows something like a cumulative 1mm/year increase - and - it took ~40 years or so to get to that 1mm increase (to be extra clear, this is a reported increase over how much oceans are rising now compared to ~40 years ago. But I'm not even sure this added up to even a full 1 mm.) These sources ALSO have all kind of scary PREDICTIONS or ESTIMATES about FUTURE acceleration that goes MUCH faster - just like they did 10 and 20 years go - but their scary predictions never materialize. Does pointing out these FACTS - using data from the SAME sources that you are using - STILL qualify me for the "flat earth society"? On this same thread, I've also been called a "climate change denier", and otherwise insulted multiple times - for just pointing out clear indisputable facts. Others keep pointing out how "a majority of scientist disagree" - yet that 97% figure that keeps getting thrown around - was from ONE SINGLE extremely flawed study that has since been thoroughly debunked. BTW - in my original message, I did state: -------------------- "But I suppose that it might be a good idea to take inventory of the absolute lowest altitude cables and make sure that they are not vulnerable to the type of flooding that might happen more often after a few decades from now after the ocean has further risen about 2 inches? But the sky is not falling anytime soon." -------------------- So ALSO - everyone - please ALSO stop arguing with a "straw man" here - I never said that there wasn't anything to be concerned about. -- Rob McEwen From SNaslund at medline.com Thu Jul 26 19:43:37 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 19:43:37 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <23386.8445.684160.527397@gargle.gargle.HOWL> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> <23386.8445.684160.527397@gargle.gargle.HOWL> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB718@MUNPRDMBXA1.medline.com> Well, the problem might be that I am an old guy and remember very well in the 70s when the "scientific community" screamed at us about the coming ice age. Next, we had global warming. Now we just call it climate change because we just don't know which way it's going to go. Those same anthropologists also know that in my area which is Illinois, it was once much hotter and we had Tyrannosaurus running around. We also had ice ages that carved the Great Lakes that I am sitting next to. All of that way before we were here. Did we warm up the climate and prevent the coming ice age in the 70's or could it be that the Earth is still in the cycle of coming out of the last ice age? We know the climate has changed without our input. As an engineer I would like to know how we separate what would be happening without us from what effect we are having. I am not denying that there are changes but I am not confident in what effect we have and whether our effect is counter or accelerating the normal trend. So, I am not sure what is causing climate change but I am very sure that there will be major climate changes on Earth. Whether a species survives or not is a matter of whether they adapt. Steven Naslund >Anthropologists say (there was a pretty good article on this in The >Atlantic a year or two ago) that's what we (humanity) have done >historically, adapted, eventually learned to eat acorns or rats or >whatever*. > >And very little if anything to combat the basic problem even if we >understood it well enough. > >We'll adapt and adapt because the problems tend to evolve slowly. > >Unfortunately I tend to think that's the likely outcome here simply >because whatever we (more developed countries) do several billion >people out there will undo faster because let's face it they want to >eat regularly, have reliable electricity, etc. etc. etc. > >And a lot of what could be done works against their getting all that, >at least if it's limited to their means. > >Perhaps not in theory. > >But call me when the G8 or G20 proposes to plunk down the many >trillions it would likely cost to provide the rest of them with >fertilizer and farming techniques and energy generation plants and so >on which aren't contributing to the problem. > >Didn't India recently state that they won't even talk about slowing >down the rate of increase (2nd derivative) of coal usage for at least >ten years? > >Not picking on India, they have their reasons, but just trying to be >realistic and move past these late-night dorm room bull sessions about >how the world ought to work. > >* One significant exception was crop and field rotation which worked >very well where it was possible. > >-- > -Barry Shein > >Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com >Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD >The World: Since 1989 | A Public Information Utility | *oo* From SNaslund at medline.com Thu Jul 26 19:44:53 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 19:44:53 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <20180726180053.GC14114@cmadams.net> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB72E@MUNPRDMBXA1.medline.com> I agree with this. I suppose you could take tons of measurements and average them out to be pretty accurate but I am not sure how you would account for tidal gravitational effects which vary all the time. Seems like the precision claimed would be really hard to pull off without knowing exactly the gravitational effect at that location at exactly the same time. I am also wondering how many points on the ocean you would have to take this measurement and how often to get that level of precision. Given the altitude of the satellites the percentage of error here is super small, not even OTDR units can get that kind of precision on a measurement. You would also have to align the satellite measurements with the pre-satellite measurement which could not have possibly have the same level of precision. A statistics person would have to tell me if that methodology is even valid. The level charts go back to the 1880s and I can't imagine a global network of measurement for that time. I'm also pretty sure they were not taking measurements in mm in the United States so there is that conversion error to deal with not to mention the lack of international measurement standards. Steven Naslund Chicago IL >Chris, > >I understand how radar altimetry works. I would like to understand how >they achieve the claimed precision. 3.2mm is one heck of a precise >measurement from a flying platform hundreds of kilometers away, >particularly when that requires the platform itself to be located with >even higher precision against some reference points deemed stable for >the purpose of making the measurement. > > From valdis.kletnieks at vt.edu Thu Jul 26 19:49:13 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 26 Jul 2018 15:49:13 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> Message-ID: <174884.1532634553@turing-police.cc.vt.edu> On Thu, 26 Jul 2018 15:39:51 -0400, Rob McEwen said: > JUST BARELY curve upwards. So I dug into THEIR actual data - and even > THEIR data shows something like a cumulative 1mm/year increase - and - > it took ~40 years or so to get to that 1mm increase (to be extra clear, > this is a reported increase over how much oceans are rising now compared > to ~40 years ago. But I'm not even sure this added up to even a full 1 mm.) Compound interest is a bitch. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Thu Jul 26 19:56:24 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 26 Jul 2018 15:56:24 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB718@MUNPRDMBXA1.medline.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> <23386.8445.684160.527397@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402D1DEB718@MUNPRDMBXA1.medline.com> Message-ID: <175763.1532634984@turing-police.cc.vt.edu> On Thu, 26 Jul 2018 19:43:37 -0000, "Naslund, Steve" said: > As an engineer I would like to know how we separate what would be happening > without us from what effect we are having. Well, when all previous data shows temperature changes on the order of degrees per millenium (absent major incidents like the Yellowstone supervolcano going off or the Chixlulub impact), and suddenly you see an effect that's degrees per decade.. In other words, the same way you realize a DDoS is hitting your net when the packet rate for a host isn't changing in percent per week, but percent by minute.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From SNaslund at medline.com Thu Jul 26 19:56:34 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 19:56:34 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB718@MUNPRDMBXA1.medline.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> <23386.8445.684160.527397@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402D1DEB718@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB7F4@MUNPRDMBXA1.medline.com> And just to be abundantly clear. I am not denying climate change and I am all for eliminating pollution and our impact on the planet in general. However I firmly believe that there will be further climate change regardless of what humans do. That is the cycle of the planet so far and way before we were here. My main argument is against the case that rising sea level constitutes some kind of emergency for network infrastructure. I don't believe it is an emergency and believe that our infrastructure is constantly evolving and all of these routes will be handled in the natural course of things. I say this coming from years of network infrastructure engineering and installations and time spent in trenches, central offices, and manholes all around the world. Given that the backbone of the Internet is mostly running on fiber optics which are highly water resistant, localized coastal flooding is less of an issue than ever. Did you ever look into how far an oceanic cable comes ashore before it hits the landing station? If you did you would not be worried about a few mm of ocean rise. Steven Naslund Chicago IL From rob at invaluement.com Thu Jul 26 20:07:56 2018 From: rob at invaluement.com (Rob McEwen) Date: Thu, 26 Jul 2018 16:07:56 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <174884.1532634553@turing-police.cc.vt.edu> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> Message-ID: <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> On 7/26/2018 3:49 PM, valdis.kletnieks at vt.edu wrote: > On Thu, 26 Jul 2018 15:39:51 -0400, Rob McEwen said: > >> JUST BARELY curve upwards. So I dug into THEIR actual data - and even >> THEIR data shows something like a cumulative 1mm/year increase - and - >> it took ~40 years or so to get to that 1mm increase (to be extra clear, >> this is a reported increase over how much oceans are rising now compared >> to ~40 years ago. But I'm not even sure this added up to even a full 1 mm.) > Compound interest is a bitch. But NOT so much when the rate of increase is THIS tiny. Yes, if the rate of the increase holds steady, then this could start causing a lot of problems EVENTUALLY. But this still only adds up to an ADDITIONAL 4 inches (total!) per century (over what would have happened). That is an amount and time-scale that warrants concern and long-range planning. However, extreme measures that would harm our economy in the short term (and in many cases wouldn't have helped anyways) are counter productive because they then put us on a long-term less healthy economic trajectory that would make us less able to afford the future changes that would be needed to deal with this extremely long-term problem. ANALOGY: Freshman college kid becomes a health nut and spends all his money on only the best specialized organic foods, exotic vitamins, and a membership at the best health club, even paying extra for a personalized trainer. Then he has to drop out of college because he can't afford it. Then he runs out of money and can't get a decent paying job because he doesn't have a college education. Now he eats horrible cheap food and works long hours at a low paying job that leaves him little time to properly exercise. (in general - solving a SMALL problem with a BIG solution - like this - causes problems) -- Rob McEwen From sean at donelan.com Thu Jul 26 20:08:14 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 26 Jul 2018 16:08:14 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: <17707.1532624954@turing-police.cc.vt.edu> References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> <17707.1532624954@turing-police.cc.vt.edu> Message-ID: On Thu, 26 Jul 2018, valdis.kletnieks at vt.edu wrote: > Do those use a frequency band that's suitable for cellphones to monitor (antenna > size, power, etc)? Because your best chance of getting my attention in an emergency > is to make my phone start shrieking. 15 years ago (way back in 2003), one of the reasons the cellular industry gave for NOT having mobile alerts was everyone had a home landline phone. The cellular industry argument was the best way of getting people's attention at home in an emergency using Reverse-911 to call all the phone numbers in the local exchange. The cellular industry said mobile phone alerts were unneccessary and impractical because they wouldn't know where the cell phone was. Fast forward to today. How many people would answer (or still have) their home landline phones if the local emergency service called in the middle of the night with an emergency message? How many people have moved around the country, and still have a cellular phone number from several cities ago? Now my mobile phone gets emergency alerts based on the phone's current location, not the telephone number exchange from four cities ago. > (For what it's worth, I actually did get an Amber Alert on my phone last night, and > a phone-based weather alert as well) If the cellular industry had successfully avoided mobile emergency alerts 15 years ago, because "everyone" had a landline phone, you might not have gotten an alert last night. Those where minor things, but there may be a big thing in the future. Silicon Valley loves to talk about "disrupting" things, but not about consequence of that disruption. Smart speakers are great, but no more am/fm radios for emergencies. Smart TVs are great, but no more cable/antenna for emergencies. Cell phones are great, but no more landline phones at home. Although, I do admit, I turned off Amber alerts on my cell phone a long time ago because NCMEC always seemed to send them early in the morning while I'm sleeping. A From SNaslund at medline.com Thu Jul 26 20:13:50 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 20:13:50 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <174884.1532634553@turing-police.cc.vt.edu> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB834@MUNPRDMBXA1.medline.com> There are lots of ways to construct a graph to look scary. Just try to redraw that graph as the change in overall depth of the ocean. It would be so flat as to be useless. Wikipedia (might be right or not) says the average depth of the ocean is 3,688 meters or 12,100 feet. If we take that and convert to mm we get 3,688,000. So let's take some of the number thrown around here. If we have a 250 mm rise since 1888 we have a percentage change of 0.01 % If we have around a mm per year, we have a an annual change of .000027%, if it is 3 mm per year that is .000081% Just for reference 1 mm is about the size of the average pin head and a flea is approximately 1.5mm in length. Not exactly an alarming graph when you look at it that way. By the way I am also really interested in why sea level actually fell in 2010 according to the NASA satellite graph from 56 mm to 48 mm. Were we especially good people that year? Steven Naslund Chicago IL >> JUST BARELY curve upwards. So I dug into THEIR actual data - and even >> THEIR data shows something like a cumulative 1mm/year increase - and - >> it took ~40 years or so to get to that 1mm increase (to be extra >> clear, this is a reported increase over how much oceans are rising now >> compared to ~40 years ago. But I'm not even sure this added up to even >> a full 1 mm.) >Compound interest is a bitch. From valdis.kletnieks at vt.edu Thu Jul 26 20:22:22 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 26 Jul 2018 16:22:22 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> Message-ID: <178481.1532636542@turing-police.cc.vt.edu> On Thu, 26 Jul 2018 16:07:56 -0400, Rob McEwen said: > On 7/26/2018 3:49 PM, valdis.kletnieks at vt.edu wrote: > > Compound interest is a bitch. >> it took ~40 years or so to get to that 1mm increase (to be extra clear, >> this is a reported increase over how much oceans are rising now compared >> to ~40 years ago. In other words, it's acceleration, second derivative, not velocity first derivative. Which means that the number added each time period is bigger each time period. The growth per year now is bigger than the growth per year 40 years ago. > But NOT so much when the rate of increase is THIS tiny. Yes, if the rate > of the increase holds steady, then this could start causing a lot of > problems EVENTUALLY. But this still only adds up to an ADDITIONAL 4 > inches (total!) per century (over what would have happened). Let's run the math. 1mm/additional per year. So 1 the first year, 2 aditional the second, ... and the century year then adds 100mm or 4 inches *by itself*. But we need to add years 1 to 99's contributions too... sum(1..100) = 101 * 50 or 5050mm. Divide by 25.4 and you get 198 inches cumulative. Be glad the actual rate of acceleration is less than 1mm/year. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From SNaslund at medline.com Thu Jul 26 20:31:39 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 20:31:39 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <178481.1532636542@turing-police.cc.vt.edu> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> <178481.1532636542@turing-police.cc.vt.edu> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB883@MUNPRDMBXA1.medline.com> Pretty hard to accept 198 inches since NASA's own data shows no more than 250mm or 9.4 inches since 1888. You would have to assume there are no balancing factors. If the earth gets warmer then there is also more evaporation of the oceans which causes more rainfall which helps moderate temperature and moves oceanic water inland. I agree the climate is getting warmer but doubt that trend continues forever. History says it won't. Common sense says that in any closed system, things do not change exponentially forever. I really do need an answer to the question of why in certain years ocean levels were actually lower than the year before like 2010. I honestly want to know why that happens. Steven Naslund Chicago IL >Let's run the math. 1mm/additional per year. So 1 the first year, 2 aditional the second, ... and the century year then adds 100mm or 4 inches *by itself*. >But we need to add years 1 to 99's contributions too... > >sum(1..100) = 101 * 50 or 5050mm. Divide by 25.4 and you get 198 inches cumulative. > > >Be glad the actual rate of acceleration is less than 1mm/year. From list at satchell.net Thu Jul 26 20:35:41 2018 From: list at satchell.net (Stephen Satchell) Date: Thu, 26 Jul 2018 13:35:41 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> <17707.1532624954@turing-police.cc.vt.edu> Message-ID: <5fbcecd3-1d65-b8e7-f7f4-70871f312fab@satchell.net> On 07/26/2018 10:31 AM, Chris Boyd wrote: > 162.400 > 162.425 > 162.450 > 162.475 > 162.500 > 162.525 > 162.550 > > That’s about 1.85 meter wavelength, so a quarter wave antenna would > be pretty large. I’m sure the RF engineers can come up with a way to > listen effectively without a huge antenna. That's what loaded whips are for. My shortwave radio has a loaded whip, with the load switched by band. From SNaslund at medline.com Thu Jul 26 20:43:02 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 20:43:02 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB883@MUNPRDMBXA1.medline.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> <178481.1532636542@turing-police.cc.vt.edu> <9578293AE169674F9A048B2BC9A081B402D1DEB883@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB8B9@MUNPRDMBXA1.medline.com> Here is a simple question to answer while you are at it. Once the arctic ice and glaciers melt, what will cause the ocean levels to continue to rise at this incredible rate? The total estimate for sea level rise would be 70 meters if absolutely all ice on the face of the Earth melted. A radical change no doubt but it will not continue forever. The Earth right now is about as warm as it was during the previous interglacial period which was about 125,000 years ago. At that time sea level was actually 4 METERS HIGHER THAN IT IS RIGHT NOW. So we know that before humans were widespread on Earth, sea level was 4 METERS higher than it is right now. I guess this goes against the "worse than it has ever been" kind of arguments". Steven Naslund Chicago IL >Pretty hard to accept 198 inches since NASA's own data shows no more than 250mm or 9.4 inches since 1888. You would have to assume there are no balancing factors. If the earth gets warmer then there >is also more evaporation of the oceans which causes more rainfall which helps moderate temperature and moves oceanic water inland. I agree the climate is getting warmer but doubt that trend continues >forever. History says it won't. Common sense says that in any closed system, things do not change exponentially forever. I really do need an answer to the question of why in certain years ocean >levels were actually lower than the year before like 2010. I honestly want to know why that happens. > >Steven Naslund >Chicago IL From list at satchell.net Thu Jul 26 20:43:14 2018 From: list at satchell.net (Stephen Satchell) Date: Thu, 26 Jul 2018 13:43:14 -0700 Subject: Rising sea levels are going to mess with the internet In-Reply-To: References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB31E@MUNPRDMBXA1.medline.com> Message-ID: <5ba95271-eb5c-d76a-8a5a-97bd5d4207c9@satchell.net> On 07/26/2018 10:48 AM, William Herrin wrote: > Submarine cable is needed for deeper water (higher pressures) with > more armor against damage since it's just laying on the seafloor > exposed to everything that happens by. Let's be specific: everything with teeth that happens by. From SNaslund at medline.com Thu Jul 26 20:48:58 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Jul 2018 20:48:58 +0000 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB8B9@MUNPRDMBXA1.medline.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> <178481.1532636542@turing-police.cc.vt.edu> <9578293AE169674F9A048B2BC9A081B402D1DEB883@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402D1DEB8B9@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402D1DEB8D6@MUNPRDMBXA1.medline.com> Don't panic though about the 70 meter rise though. According to this article by National Geographic, it would take around 5000 years to melt that much ice even assuming the current temperature rise continues. Steven Naslund Chicago IL >Here is a simple question to answer while you are at it. Once the arctic ice and glaciers melt, what will cause the ocean levels to continue to rise at this incredible rate? The total estimate for sea >level rise would be 70 meters if absolutely all ice on the face of the Earth melted. A radical change no doubt but it will not continue forever. > >The Earth right now is about as warm as it was during the previous interglacial period which was about 125,000 years ago. At that time sea level was actually 4 METERS HIGHER THAN IT IS RIGHT NOW. So >we know that before humans were widespread on Earth, sea level was 4 METERS higher than it is right now. I guess this goes against the "worse than it has ever been" kind of arguments". > >Steven Naslund >Chicago IL From jeffshultz at sctcweb.com Thu Jul 26 20:51:05 2018 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Thu, 26 Jul 2018 13:51:05 -0700 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB8B9@MUNPRDMBXA1.medline.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> <178481.1532636542@turing-police.cc.vt.edu> <9578293AE169674F9A048B2BC9A081B402D1DEB883@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402D1DEB8B9@MUNPRDMBXA1.medline.com> Message-ID: It might be worth noting that with Plate Tectonics, the shoreline itself is not exactly locked in place either. Particularly on the West Coast in ring of fire territory. Come the predicted Cascadia Fault earthquake, the landing stations are going to first be shaken by the EQ, then swamped by a major tsunami, and after everything settles down, potentially find the ocean lapping at their doorsteps, not because the water level has risen, but because the land level has dropped perhaps 1 meter as the North American Plate "unlocked" and extended over the Juan de Fuca plate during the EQ. Bandon, Nedonna Beach, Pacific City, Rockaway Beach and Warrenton, Oregon take note... Not saying the oceans aren't rising - but there are other factors that may be potentially in play as well. FWIW. On Thu, Jul 26, 2018 at 1:44 PM Naslund, Steve wrote: > > Here is a simple question to answer while you are at it. Once the arctic ice and glaciers melt, what will cause the ocean levels to continue to rise at this incredible rate? The total estimate for sea level rise would be 70 meters if absolutely all ice on the face of the Earth melted. A radical change no doubt but it will not continue forever. > > The Earth right now is about as warm as it was during the previous interglacial period which was about 125,000 years ago. At that time sea level was actually 4 METERS HIGHER THAN IT IS RIGHT NOW. So we know that before humans were widespread on Earth, sea level was 4 METERS higher than it is right now. I guess this goes against the "worse than it has ever been" kind of arguments". > > Steven Naslund > Chicago IL > > > > >Pretty hard to accept 198 inches since NASA's own data shows no more than 250mm or 9.4 inches since 1888. You would have to assume there are no balancing factors. If the earth gets warmer then there >is also more evaporation of the oceans which causes more rainfall which helps moderate temperature and moves oceanic water inland. I agree the climate is getting warmer but doubt that trend continues >forever. History says it won't. Common sense says that in any closed system, things do not change exponentially forever. I really do need an answer to the question of why in certain years ocean >levels were actually lower than the year before like 2010. I honestly want to know why that happens. > > > >Steven Naslund > >Chicago IL > -- 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 valdis.kletnieks at vt.edu Thu Jul 26 21:21:52 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 26 Jul 2018 17:21:52 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <9578293AE169674F9A048B2BC9A081B402D1DEB8D6@MUNPRDMBXA1.medline.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> <178481.1532636542@turing-police.cc.vt.edu> <9578293AE169674F9A048B2BC9A081B402D1DEB883@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402D1DEB8B9@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402D1DEB8D6@MUNPRDMBXA1.medline.com> Message-ID: <184093.1532640112@turing-police.cc.vt.edu> On Thu, 26 Jul 2018 20:48:58 -0000, "Naslund, Steve" said: > Don't panic though about the 70 meter rise though. According to this article > by National Geographic, it would take around 5000 years to melt that much ice > even assuming the current temperature rise continues. Was that article from before or after we discovered just how fast an ice shelf can catastrophically collapse? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From streinerj at gmail.com Thu Jul 26 21:31:55 2018 From: streinerj at gmail.com (Justin M. Streiner) Date: Thu, 26 Jul 2018 17:31:55 -0400 (EDT) Subject: Rising sea levels are going to mess with the internet In-Reply-To: <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> Message-ID: All: Let's kindly kill off the portions of this thread that have absolutely nothing to do with running a network. Political rants, plate tectonics, Math 101, and debating whether or not climate change is a thing really have no place on this list / in this context. Thank you jms From rob at invaluement.com Thu Jul 26 21:45:08 2018 From: rob at invaluement.com (Rob McEwen) Date: Thu, 26 Jul 2018 17:45:08 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <178481.1532636542@turing-police.cc.vt.edu> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> <178481.1532636542@turing-police.cc.vt.edu> Message-ID: <61a53146-a179-dedb-b7aa-c62ba508919a@invaluement.com> On 7/26/2018 4:22 PM, valdis.kletnieks at vt.edu wrote: > Let's run the math. 1mm/additional per year. So 1 the first year, 2 aditional > the second, ... and the century year then adds 100mm or 4 inches*by itself*. > But we need to add years 1 to 99's contributions too... > > sum(1..100) = 101 * 50 or 5050mm. Divide by 25.4 and you get 198 inches > cumula You misinterpreted what I said. I was merely saying that the current yearly increase is about 1 mm more than the yearly increase was from 40 years ago. (But maybe not even that much!) I was NOT saying that each year was increasing by a rate that was mm more than the previous year. Your calculation is based on year-to-year acceleration of growth. In fact, that year-to-year /*acceleration*/ of rising sea levels is actually a ~0.025 mm average increase over the previous year. (this is HALF the thickness of a single sheet of paper!) So try your calculation again - except see how impressive that "compound interest" you talk about is when the year-to-year acceleration of growth over the previous year is only 0.025 mm. ALSO - I say "average rate of increase" because the graph is not a smooth line. Like almost everything, it is jagged - where some years show signs of more rapid acceleration, and other years show a decrease in acceleration, or even a lowering of the sea levels. Anytime one of the other hits a historical extreme, it raises curiosity that we might be in the middle of a fundamental shift to a "new normal". But before anyone assumes that we're about to hit a new normal where that .025 mm year-to-year increase in the rate of rising - is about to accelerate - note that, in fact, the sea levels have actually LOWERED in the past couple of years. (not just rising less fast - ACTUALLY LOWERING). (see blue line at the end of this graph: https://insideclimatenews.org/content/average-global-sea-level-rise-1993-2017) -- Rob McEwen https://www.invaluement.com +1 (478) 475-9032 From bzs at theworld.com Fri Jul 27 02:18:50 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 26 Jul 2018 22:18:50 -0400 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> <6965697b-7a8b-4d68-2d31-489f81e33b24@invaluement.com> Message-ID: <23386.33034.747068.48296@gargle.gargle.HOWL> If you want to read a really, really depressing article on all this read this one in Foreign Affairs: Why Carbon Pricing Isn’t Working https://www.foreignaffairs.com/articles/world/2018-06-14/why-carbon-pricing-isnt-working It isn't so much the specifics of carbon pricing. It's the harsh cold slap of reality about how the world, even when well-intentioned, works. In a tiny nutshell: You know how many (developed) countries boast about meeting or exceeding their carbon goals via carbon markets? Those markets are rigged. The governments hand out carbon credits like Zimbabwe printed fiat cash in trade for the usual things politicians like in return such as campaign contributions or support for some pet legislation. And then boast about how their major industries have met or exceeded carbon goals. How would you know otherwise? To bring it back on topic, somewhat, the internet is a very, very special place where things mostly work as promised and expected. If the page loads it's working. Be glad when there's no thuggish legislator trying to get you to rig the numbers to make it only appear to be working. But we'll get there, just give it time... -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From ramy.ihashish at gmail.com Fri Jul 27 11:42:09 2018 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Fri, 27 Jul 2018 13:42:09 +0200 Subject: SP security knowledge build up Message-ID: > > Message: 6 > Date: Tue, 24 Jul 2018 07:59:58 -0500 > From: "Douglas C. Stephens" > To: nanog at nanog.org > Subject: SP security knowledge build up > Message-ID: <6efd278f-31a0-7d0b-d755-8e14bf344cd8 at ameslab.gov> > Content-Type: text/plain; charset=utf-8 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > To add to Suresh's list, Iowa State University (iastate.edu) offers a > graduate major program and an undergraduate minor program in cyber > security (a.k.a. Information Assurance). They also run an annual > cyber defense competition (ISEAGE). > > > > On 7/24/2018 4:06 AM, Suresh Ramasubramanian wrote: > > Not a MOOC. But several schools now have graduate programs in > > security. Off the top of my head, Georgia Tech, UAB, GMU .. > > > > > > > > They might offer some shorter courses as well, for working > > professionals. Take a look. > > > > > > > Message: 7 > Date: Tue, 24 Jul 2018 12:43:12 -0400 > From: Rich Kulawiec > To: nanog at nanog.org > Subject: Re: SP security knowledge build up > Message-ID: <20180724164312.GA6933 at gsp.org> > Content-Type: text/plain; charset=us-ascii > > On Mon, Jul 23, 2018 at 03:22:46PM +0200, Ramy Hashish wrote: > > I am planning to build up a security team of fresh engineers whom are > > "network oriented", any advice on the knowledge resources we can start > > with? > > 1. Start with one or more engineers who aren't "fresh". This is more > expensive, potentially much more expensive, but it's much more likely > to result in success than trying to feed a crash course in security > into the brains of people who've never done any of this before. Even if > all > those experienced people do is stop you from making well-known mistakes, > then the investment will be more than worth it. > > 2. I see that several academic programs were mentioned downthread; > one that I'd add to the list is UMBC, which is excellent. > > ---rsk > > > Message: 10 > Date: Tue, 24 Jul 2018 17:31:01 +0000 > From: "Lotia, Pratik M" > To: "nanog at nanog.org" > Subject: RE: SP security knowledge build up > Message-ID: > > > Content-Type: text/plain; charset="iso-8859-1" > > On Mon, Jul 23, 2018 at 03:22:46PM +0200, Ramy Hashish wrote: > > I am planning to build up a security team of fresh engineers whom are > > "network oriented", any advice on the knowledge resources we can start > > with? > > To add to the academic programs - > > CU Boulder has an excellent telecom program for network security and > network engineering; one of their courses focuses solely on SP networks > (full disclosure: I am a CU Boulder alumnus). > > > With Gratitude, > > Pratik Lotia | Security Engineer III > Charter Communications > > Thank you guys for all your academic recommendation, unfortunately we are not US residents, so can you recommend the references/books/curriculum used in the mentioned programs? Thanks, Ramy From ops.lists at gmail.com Fri Jul 27 12:09:48 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 27 Jul 2018 17:39:48 +0530 Subject: SP security knowledge build up In-Reply-To: References: Message-ID: Please start with the nanog videos Chris referenced and the book that I told you about. Before security knowledge, there’s a lot of hard CS and pure math involved if you want to teach it as a discipline – but that should be available most anywhere.   And of course practical courses on network and system administration. Depends on whether you want to train junior analysts and build their knowledge in a more hands on manner in on the job training, or proceed with a graduate course that’ll take years and give them a deeper dive into this. For on the job training the videos and the Limoncelli book will do very well indeed for a start. --srs From: Ramy Hashish Date: Friday, 27 July 2018 at 5:12 PM To: NANOG Mailing List , , , Suresh Ramasubramanian , Subject: Re: SP security knowledge build up Thank you guys for all your academic recommendation, unfortunately we are not US residents, so can you recommend the references/books/curriculum used in the mentioned programs? From rsk at gsp.org Fri Jul 27 12:35:46 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 27 Jul 2018 08:35:46 -0400 Subject: unwise filtering policy on abuse mailboxes In-Reply-To: References: <201807242314.w6ONEJNH007001@yuri.anime.net> Message-ID: <20180727123546.GA9134@gsp.org> On Tue, Jul 24, 2018 at 04:19:22PM -0700, Dan Hollis wrote: > can we please just stop this nonsense? An excellent way to stop this particular nonsense is to firewall out every network allocation under the control of Psychz. This achieves lossless compression of incoming data. ---rsk From rsk at gsp.org Fri Jul 27 12:40:15 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 27 Jul 2018 08:40:15 -0400 Subject: SP security knowledge build up In-Reply-To: References: Message-ID: <20180727124015.GB9134@gsp.org> On Fri, Jul 27, 2018 at 01:42:09PM +0200, Ramy Hashish wrote: > Thank you guys for all your academic recommendation, unfortunately we are > not US residents, so can you recommend the references/books/curriculum used > in the mentioned programs? First, please learn how to properly quote/cite email messages in a mailing list discussion thread. Second, you've been given plenty of pointers already. If you lack the initiative to follow up on those, read the curricula, take note of the textbooks used in particular classes, etc., then you probably lack the intiative to be successful in this endeavor. ---rsk From job at ntt.net Fri Jul 27 14:40:42 2018 From: job at ntt.net (Job Snijders) Date: Fri, 27 Jul 2018 14:40:42 +0000 Subject: deploying RPKI based Origin Validation In-Reply-To: References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <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: Dear Alex, On Thu, 26 Jul 2018 at 19:11, Alex Band wrote: > NLnet Labs recently committed to building a full RPKI Toolset, including a (Delegated) Certificate Authority, a Publication Server and Relying Party software. As an RP implementation was the easiest way to get going, we now have some running code – in Rust – here: > > https://github.com/NLnetLabs/routinator > > We’re committed to offering a toolset that is on par with our other projects such as NSD and Unbound, in terms of quality, feature set and update frequency. We’re looking forward to your feedback; in the mean time we’re getting started with the CA and Publication Server. 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. Kind regards, Job From egon at egon.cc Fri Jul 27 16:19:41 2018 From: egon at egon.cc (James Downs) Date: Fri, 27 Jul 2018 09:19:41 -0700 Subject: Rising sea levels are going to mess with the internet In-Reply-To: <174884.1532634553@turing-police.cc.vt.edu> References: <446b2abc-6f8e-19dd-0dfc-c59f00925b32@invaluement.com> <29214D28-E24C-47F8-B4F1-96CCC63DEB98@beckman.org> <9578293AE169674F9A048B2BC9A081B402D1DEB3BD@MUNPRDMBXA1.medline.com> <23abe71e-4a0f-bebc-35cc-5d8f48a03be4@invaluement.com> <174884.1532634553@turing-police.cc.vt.edu> Message-ID: <20180727161939.GM28957@nemesis.egontech.com> On Thu, Jul 26, 2018 at 03:49:13PM -0400, valdis.kletnieks at vt.edu wrote: > Compound interest is a bitch. Sure is, but a numerically fixed change YoY is not compound interest. From cscora at apnic.net Fri Jul 27 18:03:07 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Jul 2018 04:03:07 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180727180307.63BA5C450F@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 28 Jul, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 707831 Prefixes after maximum aggregation (per Origin AS): 271940 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 339769 Total ASes present in the Internet Routing Table: 61314 Prefixes per ASN: 11.54 Origin-only ASes present in the Internet Routing Table: 52960 Origin ASes announcing only one prefix: 23085 Transit ASes present in the Internet Routing Table: 8354 Transit-only ASes present in the Internet Routing Table: 267 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: 23460 Number of 32-bit ASNs visible in the Routing Table: 18868 Prefixes from 32-bit ASNs in the Routing Table: 78889 Number of bogon 32-bit ASNs visible in the Routing Table: 22 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 282 Number of addresses announced to Internet: 2857289283 Equivalent to 170 /8s, 78 /16s and 198 /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: 235856 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 193185 Total APNIC prefixes after maximum aggregation: 54926 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 191556 Unique aggregates announced from the APNIC address blocks: 78618 APNIC Region origin ASes present in the Internet Routing Table: 8971 APNIC Prefixes per ASN: 21.35 APNIC Region origin ASes announcing only one prefix: 2518 APNIC Region transit ASes present in the Internet Routing Table: 1338 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: 3922 Number of APNIC addresses announced to Internet: 767760130 Equivalent to 45 /8s, 195 /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: 210288 Total ARIN prefixes after maximum aggregation: 100019 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 210480 Unique aggregates announced from the ARIN address blocks: 99420 ARIN Region origin ASes present in the Internet Routing Table: 18191 ARIN Prefixes per ASN: 11.57 ARIN Region origin ASes announcing only one prefix: 6721 ARIN Region transit ASes present in the Internet Routing Table: 1807 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2385 Number of ARIN addresses announced to Internet: 1102770848 Equivalent to 65 /8s, 186 /16s and 242 /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: 193768 Total RIPE prefixes after maximum aggregation: 92607 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 189917 Unique aggregates announced from the RIPE address blocks: 112763 RIPE Region origin ASes present in the Internet Routing Table: 25326 RIPE Prefixes per ASN: 7.50 RIPE Region origin ASes announcing only one prefix: 11415 RIPE Region transit ASes present in the Internet Routing Table: 3503 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: 7216 Number of RIPE addresses announced to Internet: 714010240 Equivalent to 42 /8s, 142 /16s and 238 /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: 91315 Total LACNIC prefixes after maximum aggregation: 20268 LACNIC Deaggregation factor: 4.51 Prefixes being announced from the LACNIC address blocks: 92744 Unique aggregates announced from the LACNIC address blocks: 40795 LACNIC Region origin ASes present in the Internet Routing Table: 7348 LACNIC Prefixes per ASN: 12.62 LACNIC Region origin ASes announcing only one prefix: 2032 LACNIC Region transit ASes present in the Internet Routing Table: 1379 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 34 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4891 Number of LACNIC addresses announced to Internet: 172285216 Equivalent to 10 /8s, 68 /16s and 221 /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: 19219 Total AfriNIC prefixes after maximum aggregation: 4076 AfriNIC Deaggregation factor: 4.72 Prefixes being announced from the AfriNIC address blocks: 22852 Unique aggregates announced from the AfriNIC address blocks: 7926 AfriNIC Region origin ASes present in the Internet Routing Table: 1183 AfriNIC Prefixes per ASN: 19.32 AfriNIC Region origin ASes announcing only one prefix: 399 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: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 454 Number of AfriNIC addresses announced to Internet: 100013568 Equivalent to 5 /8s, 246 /16s and 22 /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 4692 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4364 467 460 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2966 1153 83 VIETEL-AS-AP Viettel Group, VN 4766 2863 11135 765 KIXS-AS-KR Korea Telecom, KR 9829 2813 1497 543 BSNL-NIB National Internet Backbone, IN 45899 2657 1637 110 VNPT-AS-VN VNPT Corp, VN 9394 2542 4907 31 CTTNET China TieTong Telecommunications 17974 2260 930 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2238 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2112 417 205 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 3433 1324 82 SHAW - Shaw Communications Inc., CA 22773 3272 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2541 244 475 CABLEONE - CABLE ONE, INC., US 16509 2250 4790 759 AMAZON-02 - Amazon.com, Inc., US 18566 2167 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2118 2616 480 CHARTER-NET-HKY-NC - Charter Communicat 16625 2014 1033 1440 AKAMAI-AS - Akamai Technologies, Inc., 30036 2013 344 148 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1996 5071 607 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 7018 1746 20200 1263 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 4614 1610 122 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 20940 2540 624 1886 AKAMAI-ASN1, US 8551 2523 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2043 1891 731 ROSTELECOM-AS, RU 34984 2008 335 500 TELLCOM-AS, TR 9121 1865 1692 19 TTNET, TR 13188 1604 100 43 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1203 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 5155 3346 605 Uninet S.A. de C.V., MX 10620 3533 538 320 Telmex Colombia S.A., CO 11830 2656 369 78 Instituto Costarricense de Electricidad 6503 1670 444 64 Axtel, S.A.B. de C.V., MX 7303 1507 1026 188 Telecom Argentina S.A., AR 28573 1039 2248 184 CLARO S.A., BR 3816 1024 508 130 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 931 377 31 Telefonica del Peru S.A.A., PE 11172 922 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 1166 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 8452 641 1730 18 TE-AS TE-AS, EG 24835 635 818 18 RAYA-AS, EG 37492 473 470 57 ORANGE-, TN 29571 458 68 12 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 378 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 5155 3346 605 Uninet S.A. de C.V., MX 4538 4692 4192 74 ERX-CERNET-BKB China Education and Rese 12479 4614 1610 122 UNI2-AS, ES 7545 4364 467 460 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3533 538 320 Telmex Colombia S.A., CO 6327 3433 1324 82 SHAW - Shaw Communications Inc., CA 22773 3272 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2966 1153 83 VIETEL-AS-AP Viettel Group, VN 4766 2863 11135 765 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 4692 4618 ERX-CERNET-BKB China Education and Research Net 12479 4614 4492 UNI2-AS, ES 7545 4364 3904 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3433 3351 SHAW - Shaw Communications Inc., CA 10620 3533 3213 Telmex Colombia S.A., CO 22773 3272 3123 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2966 2883 VIETEL-AS-AP Viettel Group, VN 11830 2656 2578 Instituto Costarricense de Electricidad y Telec 45899 2657 2547 VNPT-AS-VN VNPT Corp, 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 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 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 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:7948 /18:13788 /19:25370 /20:39367 /21:45769 /22:87770 /23:71416 /24:396848 /25:803 /26:606 /27:626 /28:35 /29:20 /30:19 /31:4 /32:54 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3355 4614 UNI2-AS, ES 6327 3220 3433 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2534 3272 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2060 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 2004 2656 Instituto Costarricense de Electricidad y Telec 8551 1985 2523 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1963 2541 CABLEONE - CABLE ONE, INC., US 30036 1765 2013 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1601 3533 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:1613 2:825 4:18 5:2832 6:41 7:1 8:1123 12:1874 13:207 14:1767 15:30 16:3 17:188 18:54 20:50 23:2458 24:2202 25:2 27:2478 31:2033 32:85 35:27 36:508 37:2876 38:1490 39:247 40:122 41:3126 42:692 43:1965 44:121 45:5105 46:3092 47:204 49:1330 50:1054 51:317 52:1071 54:370 55:4 56:12 57:39 58:1619 59:993 60:401 61:2112 62:1867 63:1799 64:5048 65:2201 66:4657 67:2429 68:1166 69:3274 70:1155 71:580 72:2150 74:2713 75:419 76:461 77:1571 78:1700 79:1820 80:1533 81:1389 82:1073 83:787 84:1070 85:2004 86:564 87:1352 88:923 89:2350 90:214 91:6424 92:1253 93:2371 94:2391 95:2924 96:774 97:358 98:935 99:133 100:85 101:1234 102:170 103:18260 104:3590 105:217 106:746 107:1789 108:695 109:3173 110:1630 111:1772 112:1314 113:1293 114:1135 115:1653 116:1638 117:1767 118:2207 119:1669 120:1006 121:1061 122:2474 123:1760 124:1447 125:1920 128:1084 129:666 130:489 131:1643 132:712 133:195 134:1018 135:231 136:504 137:650 138:1925 139:663 140:477 141:735 142:805 143:1012 144:805 145:486 146:1204 147:742 148:1642 149:752 150:741 151:1098 152:816 153:320 154:1457 155:798 156:1182 157:797 158:654 159:1778 160:1266 161:799 162:2587 163:609 164:1063 165:1524 166:458 167:1307 168:3121 169:827 170:3796 171:492 172:1006 173:1991 174:905 175:761 176:2007 177:4025 178:2542 179:1240 180:2174 181:2380 182:2395 183:1239 184:1030 185:13841 186:3568 187:2398 188:2883 189:2012 190:8183 191:1371 192:9801 193:6095 194:4913 195:3976 196:2657 197:1608 198:5562 199:5903 200:7338 201:4971 202:10218 203:10254 204:4575 205:2902 206:3174 207:3199 208:3975 209:3989 210:3887 211:1977 212:3016 213:2810 214:1050 215:57 216:6041 217:2129 218:856 219:584 220:1806 221:994 222:973 223:1359 End of report From chris at scsalaska.net Thu Jul 26 17:21:43 2018 From: chris at scsalaska.net (Chris J. Ruschmann) Date: Thu, 26 Jul 2018 17:21:43 +0000 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: This just seems like another way to build taxes into cloud based products that are otherwise tax free. I can just see it now, emergency services taxes attached to your Amazon and Google bills. -----Original Message----- From: NANOG [mailto:nanog-bounces+chris=scsalaska.net at nanog.org] On Behalf Of Sean Donelan Sent: Thursday, July 26, 2018 8:12 AM To: nanog at nanog.org Subject: Re: California fires: smart speakers and emergency alerts After wildfires killed 40+ people in northern California last fall, I asked if Amazon and Google had any plans to include emergency alerts in their smart speaker/intelligent assistant products. Smart speakers seem like a way to alert people to imminent life-threatening danger during the night when they may be asleep or not aware of it. Probably not a surprise, the product managers at Amazon and Google didn't see a benefit. Instead of emergency alerts, instead the product improvement roadmap priority is on package tracking and delivery alerts :-) Also shouldn't be a surprise. Senator Schatz and Representative Gabbard have introduced bills to study the feasibility of establishing systems and signalling for emergency alerts to Internet audio and video streaming services. Its just a proposed bill for a study, for now. My opinion is it makes more sense to do emergency alerts at the smart device level (smart speaker, smart tv, smart streaming box) rather than at the content layer (hulu, netflix, spotify). Amazon Alexa, Google Assistant and Microsoft Cortana want to keep track of everything else in my life, why not if there is an emergency alert at my current location. There is a lot of opportunity to come up with better ways to notify people in ways they want, when they want, beyond tracking their package deliveries. And since its at the voluntary stage now, a chance to shape the discussion. https://www.congress.gov/bill/115th-congress/senate-bill/3238 S. 3238 To improve oversight by the Federal Communications Commission of the wireless and broadcast emergency alert systems. [...] SEC. 8. ONLINE STREAMING SERVICES EMERGENCY ALERT EXAMINATION. (a) Study.—Not later than 180 days after the date of enactment of this Act, the Commission shall complete an inquiry to examine the feasibility of establishing systems and signaling to offer Emergency Alert System alerts to audio and video streaming services delivered over the internet. (b) Report.—Not later than 90 days after completing the inquiry under subsection (a), the Commission shall submit a report on the findings and conclusions of the inquiry to— (1) the Committee on Commerce, Science, and Transportation of the Senate; and (2) the Committee on Energy and Commerce of the House of Representatives. From karljorn787 at gmail.com Thu Jul 26 18:58:21 2018 From: karljorn787 at gmail.com (=?UTF-8?Q?Karl_J=C3=B8rn?=) Date: Thu, 26 Jul 2018 11:58:21 -0700 Subject: 2nd try: YANG daemeon for Linux Message-ID: Anyone ? Found this but i am not sure if this is going to go public or not : https://packetpushers.net/new-network-os-startup-arrcus-targets-whitebox-switching-routing/ Danke, Karl On Fri, Jul 20, 2018 at 12:30 PM, Karl Jørn wrote: > Hi > > Is there a YANG daemeon for Linux ? If yes, can any one please share their > experiences ? > > Danke, > Karl > From alex at nlnetlabs.nl Thu Jul 26 19:09:16 2018 From: alex at nlnetlabs.nl (Alex Band) Date: Thu, 26 Jul 2018 21:09:16 +0200 Subject: deploying RPKI based Origin Validation In-Reply-To: <8b3764d9-da8d-ea6c-e5a1-28133eb5d0e7@seacom.mu> References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <20180713124311.GI28402@vurt.meerval.net> <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: <6A7269B5-DAE8-4E5F-9AD2-2D6AE5849B2C@nlnetlabs.nl> > On 19 Jul 2018, at 23:04, Mark Tinka wrote: > > > > On 19/Jul/18 21:47, Michel Py wrote: > >> I understand that; if there is an easier way to do RPKI, people are going to use it instead of the right way. However, I think that the blacklist targets a different kind of customer : the end user. We want the enterprise to certify their prefixes with RPKI and put pressure on their upstreams to deploy it, the more noise we make the better. What I want is my upstreams to give me a clean routing tables without invalids, but it does not happen so in the meantime I'm trying to do what I can with my limited resources. > > The script that Job wrote is neat, but I'm sure neither he nor I would > run it in production in lieu of the actual RPKI infrastructure. > > Even though you're my competitor, I'd caution against this. But, your > network, your rules. > > >> The picture from the enterprise is quite different. There is a lot of stuff out there that does not get upgraded, that is not even under a maintenance contract to get the new software, or that is on EOL/EOS hardware. > > So don't re-invent this wheel; that is what Delegated RPKI is for. > Several RPKI tools out there support CA functionality, as much as they > support the RP side as well. To add to the genetic diversity, NLnet Labs recently committed to building a full RPKI Toolset, including a (Delegated) Certificate Authority, a Publication Server and Relying Party software. As an RP implementation was the easiest way to get going, we now have some running code – in Rust – here: https://github.com/NLnetLabs/routinator Ou mission is to offer a toolset that on par with our other projects such as NSD and Unbound, in terms of quality, feature set and update frequency. We’re looking forward to your feedback; in the mean time we’re getting started with the CA and Publication Server. Cheers, Alex From wmf at felter.org Fri Jul 27 18:25:07 2018 From: wmf at felter.org (Wes Felter) Date: Fri, 27 Jul 2018 13:25:07 -0500 Subject: YANG daemeon for Linux In-Reply-To: References: Message-ID: On 7/20/18 2:30 PM, Karl Jørn wrote: > Is there a YANG daemeon for Linux ? If yes, can any one please share their > experiences ? It's not clear what problem you're trying to solve, but http://www.clicon.org/ might do what you want. From karljorn787 at gmail.com Fri Jul 27 19:23:08 2018 From: karljorn787 at gmail.com (=?UTF-8?Q?Karl_J=C3=B8rn?=) Date: Fri, 27 Jul 2018 12:23:08 -0700 Subject: YANG daemeon for Linux In-Reply-To: References: Message-ID: Looking for an agent on Linux that will render YANG models, so I can provision networking on Linux. Danke, Karl On Fri, Jul 27, 2018 at 11:25 AM, Wes Felter wrote: > On 7/20/18 2:30 PM, Karl Jørn wrote: > > Is there a YANG daemeon for Linux ? If yes, can any one please share their >> experiences ? >> > > It's not clear what problem you're trying to solve, but > http://www.clicon.org/ might do what you want. > > From Ryan.Hamel at quadranet.com Fri Jul 27 20:22:28 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Fri, 27 Jul 2018 20:22:28 +0000 Subject: unwise filtering policy on abuse mailboxes In-Reply-To: <20180727123546.GA9134@gsp.org> References: <201807242314.w6ONEJNH007001@yuri.anime.net> <20180727123546.GA9134@gsp.org> Message-ID: All, My colleague has already contacted their friend at Psychz when I received the first message. Not everyone has to be on the list to get the message relayed to them. Rich, shall we all drop your email? It would achieve the same effect, and make this email thread more productive. Ryan -----Original Message----- From: NANOG On Behalf Of Rich Kulawiec Sent: Friday, July 27, 2018 5:36 AM To: nanog at nanog.org Subject: Re: unwise filtering policy on abuse mailboxes On Tue, Jul 24, 2018 at 04:19:22PM -0700, Dan Hollis wrote: > can we please just stop this nonsense? An excellent way to stop this particular nonsense is to firewall out every network allocation under the control of Psychz. This achieves lossless compression of incoming data. ---rsk From lou at metron.com Fri Jul 27 21:24:25 2018 From: lou at metron.com (Lou Katz) Date: Fri, 27 Jul 2018 14:24:25 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: <20180727212425.GB28013@metron.com> On Thu, Jul 26, 2018 at 09:51:04AM -0700, Aaron C. de Bruyn via NANOG wrote: > On Thu, Jul 26, 2018 at 9:14 AM Sean Donelan wrote: > > The NEST guys also didn't seem very receptive to the emergency alert stuff > when I contacted them. And the NEST folk say there is NO WAY that you will ever be able to connect to your own servers rather than theirs. > > Capitalist solution: Build yet another IoT device that just does emergency > alerting. > > Someone with free time should start a kickstarter or something. I'd > totally chip in. > > -A -- -=[L]=- Composed on an ASR33 "Religion teaches you to be satisfied with nonanswers. It's a sort of crime against childhood." - Richard Dawkins From lou at metron.com Fri Jul 27 21:27:17 2018 From: lou at metron.com (Lou Katz) Date: Fri, 27 Jul 2018 14:27:17 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <5da8620e-7a93-ed69-23e7-0a10a96c1bbe@rollernet.us> Message-ID: <20180727212717.GC28013@metron.com> On Thu, Jul 26, 2018 at 01:53:21PM -0400, Sean Donelan wrote: > > > If the product managers for smart speakers and smart TVs are successful, > and replace am/fm radios and cable/over-the-air TVs in households, > eventually there will be a catastrophe. After the catstrophe, the public > (and politicians) will likely ask why didn't they get a emergency warning > from their smart speakers and smart TVs like they used to get from their > old am/fm radios and old TVs? That means I can't use my TV, etc. without agreeing to the manufacturers 'Terms and Conditions' -- -=[L]=- Hand typed on my Remington portable Lies, Damn lies, Statistics, Benchmarks, and Delivery dates. From bernat at luffy.cx Sat Jul 28 10:51:38 2018 From: bernat at luffy.cx (Vincent Bernat) Date: Sat, 28 Jul 2018 12:51:38 +0200 Subject: YANG daemeon for Linux In-Reply-To: ("Karl =?utf-8?Q?J=C3=B8rn=22's?= message of "Fri, 27 Jul 2018 12:23:08 -0700") References: Message-ID: ❦ 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 joelja at bogus.com Sat Jul 28 22:19:51 2018 From: joelja at bogus.com (joel jaeggli) Date: Sat, 28 Jul 2018 15:19:51 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <20180727212425.GB28013@metron.com> References: <20180727212425.GB28013@metron.com> Message-ID: <466bff67-7aa7-b129-4ba4-9ee3bba3db95@bogus.com> 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. >> >> Someone with free time should start a kickstarter or something. I'd >> totally chip in. >> >> -A It would be helpful if it worked when your celltower was down... http://www.nws.noaa.gov/nwr/info/nwrsame.html From timothy at creswick.eu Sun Jul 29 14:23:56 2018 From: timothy at creswick.eu (Timothy Creswick) Date: Sun, 29 Jul 2018 14:23:56 +0000 Subject: AWS S3 network contact? Issues in London Message-ID: Hi Guys, Several networks peered with Amazon in London have noticed sporadic but easily replicated slowness (a few KB/s) on around 25% of traffic from S3. This has been going on for over a week; email to your NOC a couple of days ago hasn't received a response but issue looks quite widespread. Happy to share more details, but a simple wget loop to an S3 resource in eu-west-* will fail between 10-30% of the time. I've had this confirmed by at least 5 other ASNs in the region. We don't see the same problem in our other peering locations, and we see this issue on more than one London IX. Regards, - Timothy Creswick From rjs at rob.sh Sun Jul 29 16:27:40 2018 From: rjs at rob.sh (Rob Shakir) Date: Sun, 29 Jul 2018 09:27:40 -0700 Subject: YANG daemeon for Linux In-Reply-To: References: Message-ID: 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 ramy.ihashish at gmail.com Mon Jul 30 04:43:35 2018 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 30 Jul 2018 06:43:35 +0200 Subject: Security team objectives Message-ID: Good day all, If you are going to start a security team in a newly founded IT organization, what will the objectives/results be? Thanks, Ramy From valdis.kletnieks at vt.edu Mon Jul 30 04:58:21 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 30 Jul 2018 00:58:21 -0400 Subject: Security team objectives In-Reply-To: References: Message-ID: <82933.1532926701@turing-police.cc.vt.edu> On Mon, 30 Jul 2018 06:43:35 +0200, Ramy Hashish said: > Good day all, > > If you are going to start a security team in a newly founded IT > organization, what will the objectives/results be? The answer will depend heavily on the organization that contains the IT group. The right answers will be different for a bank, an ISP, a Fortune500, or a large university. The location (country and state/province) and legal requirements for the company will also matter - I have to worry about FERPA, Comcast probably doesn't... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From royce at techsolvency.com Mon Jul 30 05:12:26 2018 From: royce at techsolvency.com (Royce Williams) Date: Sun, 29 Jul 2018 21:12:26 -0800 Subject: Security team objectives In-Reply-To: <82933.1532926701@turing-police.cc.vt.edu> References: <82933.1532926701@turing-police.cc.vt.edu> Message-ID: On Sun, Jul 29, 2018 at 8:58 PM wrote: > > On Mon, 30 Jul 2018 06:43:35 +0200, Ramy Hashish said: > > If you are going to start a security team in a newly founded IT > > organization, what will the objectives/results be? > > The answer will depend heavily on the organization that contains the IT > group. The right answers will be different for a bank, an ISP, a > Fortune500, or a large university. The location (country and > state/province) and legal requirements for the company will also > matter - I have to worry about FERPA, Comcast probably doesn't... Nevertheless, some broad common objectives exist. IMO, no one summarizes it better than Richard Bejtlich, in his "Defensible Network Architecture 2.0": https://taosecurity.blogspot.com/2008/01/defensible-network-architecture-20.html The corresponding metrics for measuring results/progress would be more specific to the type of org. Royce Royce From ramy.ihashish at gmail.com Mon Jul 30 05:19:40 2018 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 30 Jul 2018 07:19:40 +0200 Subject: SP security knowledge build up Message-ID: First, please learn how to properly quote/cite email messages in a mailing > list discussion thread. > Sure I will, thank you for highlighting this. > Second, you've been given plenty of pointers already. If you lack the > initiative to follow up on those, read the curricula, take note of the > textbooks used in particular classes, etc., then you probably lack the > intiative to be successful in this endeavor. > > No, you assumption is wrong. From ramy.ihashish at gmail.com Mon Jul 30 05:22:28 2018 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 30 Jul 2018 07:22:28 +0200 Subject: Security team objectives In-Reply-To: <82933.1532926701@turing-police.cc.vt.edu> References: <82933.1532926701@turing-police.cc.vt.edu> Message-ID: On 30 July 2018 at 06:58, wrote: > On Mon, 30 Jul 2018 06:43:35 +0200, Ramy Hashish said: > > Good day all, > > > > If you are going to start a security team in a newly founded IT > > organization, what will the objectives/results be? > > The answer will depend heavily on the organization that contains the IT > group. The right answers will be different for a bank, an ISP, a > Fortune500, or a large university. The location (country and > state/province) and legal requirements for the company will also > matter - I have to worry about FERPA, Comcast probably doesn't... > You are absolutely right, sorry for missing that, the organization is an ISP. Ramy From jtk at depaul.edu Mon Jul 30 11:59:36 2018 From: jtk at depaul.edu (John Kristoff) Date: Mon, 30 Jul 2018 06:59:36 -0500 Subject: Security team objectives In-Reply-To: References: Message-ID: <20180730065936.6408736c@p50.localdomain> On Mon, 30 Jul 2018 04:43:35 +0000 Ramy Hashish wrote: > If you are going to start a security team in a newly founded IT > organization, what will the objectives/results be? Hello Ramy, Management and organization buy-in is important. Initially I would say it would be helpful to do some internal education and awareness, which helps with the first point. Identify a few things you can improve upon right away. Some small obtainable achievements would help justify the team if the team can point to some early success. Then build up that. FIRST.org, which is the original security team community, has a wealth of very detailed guides and information you might look over: John From nanog at ics-il.net Mon Jul 30 15:22:32 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 30 Jul 2018 10:22:32 -0500 (CDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: <466bff67-7aa7-b129-4ba4-9ee3bba3db95@bogus.com> References: <20180727212425.GB28013@metron.com> <466bff67-7aa7-b129-4ba4-9ee3bba3db95@bogus.com> Message-ID: <956859605.4005.1532964150102.JavaMail.mhammett@ThunderFuck> Sometimes they survive forest fires. Here's a video from a WISP in California. Their tower did just that last week. https://www.facebook.com/ShastaBeam/videos/2102541106701276/ ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "joel jaeggli" To: "Lou Katz" , "Aaron C. de Bruyn" Cc: nanog at nanog.org Sent: Saturday, July 28, 2018 5:19:51 PM Subject: Re: California fires: smart speakers and emergency alerts 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. >> >> Someone with free time should start a kickstarter or something. I'd >> totally chip in. >> >> -A It would be helpful if it worked when your celltower was down... http://www.nws.noaa.gov/nwr/info/nwrsame.html From sean at donelan.com Mon Jul 30 16:33:43 2018 From: sean at donelan.com (Sean Donelan) Date: Mon, 30 Jul 2018 12:33:43 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: <20180727212425.GB28013@metron.com> References: <20180727212425.GB28013@metron.com> Message-ID: On Fri, 27 Jul 2018, Lou Katz wrote: >> The NEST guys also didn't seem very receptive to the emergency alert stuff >> when I contacted them. > > And the NEST folk say there is NO WAY that you will ever be able to connect > to your own servers rather than theirs. For the same reason I don't think Netflix and Spotify is the right place for emergency alerts, but I do think emergency alerts should be part of your smart TV and smart speakers. Or more precisely, part of the intelligent assistant that controls those smart devices. Although NEST is being re-absorbed back into Google, I also agree with the NEST people as far as as their old approach that not part of individual IoT devices. NEST products are mostly "sensor" things. The individual sensors do a single thing, i.e. doorbell, thermostat, etc. Its the "intelligent assistant" that you interact with, through smart TVs and smart speakers, which makes the whole thing "smart." So, not part of the NEST products, but emergency warnings should be part of Google Assistant and the Google Home ecosystem. Product managers love the word ecosystem. Several people have told me about Amazon message notifications. Yes, that is correct. Notifications were added last year. However, Amazon's view of notifications is similar to voice mail message waiting lights. Amazon's user guidelines (really requirements) for notifications are meant to be an unobtrusive light and chime, like old-fashion message waiting on answering machines, not to wake you up. Amazon also has an alarm clock function that is designed to wake you up to music or a news report at a specific time; but third-party apps can't use that to set event-driven alarms. Third-party apps aren't allowed to fake it, and set an alarm clock timer for 1 second from now. Only Amazon's Alexa can directly set alarm timers. If you knew the tornado was going to strike your house at 3:42am before you went to bed, why would you need an emergency notification to wake you up? Several weather companies have had discussions about how to improve severe weather warnings with products in the Amazon Alexa, Google Assistant, etc. ecosystems for at least a year, likely longer. Amazon, Apple, Google and Microsoft just need to search their BizDev files for find them. I get companies like Amazon, Apple, Google and Microsoft want to control the user experience with their intelligent assistants. They want to control unsolicited commercials for "Pizza's On Its Way" at 110db at 3am and potentially driving consumers away from their products with a bad user experiences. One way to control that, is by making emergency warnings part of the base infrastructure under their control instead of random third-party apps using APIs in all sorts of undesirable ways. Third-parties weather apps could still provide "value added" enhancements. >> Capitalist solution: Build yet another IoT device that just does emergency >> alerting. >> >> Someone with free time should start a kickstarter or something. I'd >> totally chip in. Capitalism has proven time and again to suck at public safety issues. Most safety laws are passed after stupid acts of capitalism, i.e. saving a penny and shocking deaths. Its not always as obvious as chaining exit doors closed in night clubs or disabling automotive safety features while testing self-driving cars on public streets. Last fall, AT&T had a single fiber line in Northern California. AT&T wouldn't install a second fiber route, because of captalism. The local communities paid to subsidize a second fiber line, but AT&T refused to use a competitor fiber to provide a backup fiber route. Guess what happened during the wildfires last fall? The lone AT&T fiber was damaged, and all AT&T service, AT&T cell towers, AT&T internet, etc. went down throughout the region during the wildfires. The Cable Act of 1992, which requires cable companies provide emergency announcements on all channels, was passed after large number of tornado deaths occurred in towns where the local cable companies didn't broadcast weather warnings on cable channels. Survivors reported that they were watching cable TV, and didn't know a tornado was about to destroy their neighborhood. The Warning, Alert and Response Network Act of 2006, which created the mobile cell phone warning system in the U.S., was passed after Hurricane Katrina. The post-Katrina reports didn't necessarily identify specific problems with mobile phones during Katrina, but more general challenges reaching vulnerable populations during emergencies resulted in lots of changes. Apple iOS and Google Android implemented a bare bones cell phone alerting, with the worst cell phone user interface, only after the WARN act was passed. Those companies are well-known for their user interface psychologists and testing. Why does their cell phone alert user interface suck so bad? You would expect them to collect lots of analytics about its performance and improvements. But that's not how capitalism works for safety/compliance features. From timothy at creswick.eu Mon Jul 30 19:00:39 2018 From: timothy at creswick.eu (Timothy Creswick) Date: Mon, 30 Jul 2018 19:00:39 +0000 Subject: AWS S3 network contact? Issues in London In-Reply-To: References: Message-ID: > Several networks peered with Amazon in London have noticed sporadic but easily replicated slowness (a few KB/s) on > around 25% of traffic from S3. Issue now resolved and thanks to those who got in touch. T From outsider at scarynet.org Mon Jul 30 19:58:06 2018 From: outsider at scarynet.org (Alexander Maassen) Date: Mon, 30 Jul 2018 21:58:06 +0200 Subject: Letsencrypt In-Reply-To: References: <20180727212425.GB28013@metron.com> Message-ID: <98a229db-1a90-da51-a974-f3cd0c0f22a4@scarynet.org> As most of you noticed, the domain letsencrypt.org is on clientHold, does anyone have more information as of why this is the case ? -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1774 bytes Desc: not available URL: From surfer at mauigateway.com Mon Jul 30 19:59:21 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 30 Jul 2018 12:59:21 -0700 Subject: Security team objectives Message-ID: <20180730125921.B8CF046E@m0117566.ppops.net> On Mon, 30 Jul 2018 04:43:35 +0000 Ramy Hashish wrote: > If you are going to start a security team in a newly founded > IT organization, what will the objectives/results be? -------------------------------------------------- Mine would be to start with someone who is experienced; even if only temporarily as a contractor. The most important thing is how you start it. Start it well and it goes well. Don't start it well and it is a headache every day after. There is no list to follow... scott From edward.dore at freethought-internet.co.uk Mon Jul 30 20:02:06 2018 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Mon, 30 Jul 2018 20:02:06 +0000 Subject: Letsencrypt In-Reply-To: <98a229db-1a90-da51-a974-f3cd0c0f22a4@scarynet.org> References: <20180727212425.GB28013@metron.com> <98a229db-1a90-da51-a974-f3cd0c0f22a4@scarynet.org> Message-ID: <8BA0CB55-1A5C-4755-8F6A-498CFE976338@freethought-internet.co.uk> It's just been fixed - see https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/5b5f5aa93a343f54d7982864. Edward Dore Freethought Internet On 30/07/2018, 21:01, "NANOG on behalf of Alexander Maassen" wrote: As most of you noticed, the domain letsencrypt.org is on clientHold, does anyone have more information as of why this is the case ? From michel.py at tsisemi.com Mon Jul 30 20:06:14 2018 From: michel.py at tsisemi.com (Michel Py) Date: Mon, 30 Jul 2018 20:06:14 +0000 Subject: Letsencrypt In-Reply-To: <98a229db-1a90-da51-a974-f3cd0c0f22a4@scarynet.org> References: <20180727212425.GB28013@metron.com> <98a229db-1a90-da51-a974-f3cd0c0f22a4@scarynet.org> Message-ID: <8c363c0a58424a2496ee5b548f498734@CRA110.am.necel.com> > Alexander Maassen wrote: > As most of you noticed, the domain letsencrypt.org is on clientHold, does anyone have more information as of why this is the case ? They are aware of it. https://letsencrypt.status.io/ 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 outsider at scarynet.org Mon Jul 30 20:12:44 2018 From: outsider at scarynet.org (Alexander Maassen) Date: Mon, 30 Jul 2018 22:12:44 +0200 Subject: Letsencrypt In-Reply-To: <8BA0CB55-1A5C-4755-8F6A-498CFE976338@freethought-internet.co.uk> References: <20180727212425.GB28013@metron.com> <98a229db-1a90-da51-a974-f3cd0c0f22a4@scarynet.org> <8BA0CB55-1A5C-4755-8F6A-498CFE976338@freethought-internet.co.uk> Message-ID: <4bca4400-c2af-0aea-580a-8cc1a2a0c48d@scarynet.org> thanks to all replies both public and offlist about the issue being fixed now, no more replies needed regarding that, only perhaps if you know how and why this happened ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1774 bytes Desc: not available URL: From michel.py at tsisemi.com Mon Jul 30 20:48:07 2018 From: michel.py at tsisemi.com (Michel Py) Date: Mon, 30 Jul 2018 20:48:07 +0000 Subject: NTT US contact Message-ID: <24bfe2615e104bd995fbcfea029d1340@CRA110.am.necel.com> Can someone from NTT US contact me off-list please ? Preferably someone with some RPKI clue. Thanks, Michel Py | Sr. Network Engineer TSI Semiconductors 7501 Foothills Blvd. Roseville, CA 95747 T: (916) 789-4951 M: (916) 297-0534 michel.py at tsisemi.com | www.tsisemi.com MHP10-ARIN [tsi] [cid:image004.gif at 01D1EBEE.F4F11880] Please consider the environment before printing this email. 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 morrowc.lists at gmail.com Mon Jul 30 20:50:14 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 30 Jul 2018 16:50:14 -0400 Subject: NTT US contact In-Reply-To: <24bfe2615e104bd995fbcfea029d1340@CRA110.am.necel.com> References: <24bfe2615e104bd995fbcfea029d1340@CRA110.am.necel.com> Message-ID: job On Mon, Jul 30, 2018 at 4:49 PM Michel Py wrote: > Can someone from NTT US contact me off-list please ? > Preferably someone with some RPKI clue. > > Thanks, > > Michel Py | Sr. Network Engineer > TSI Semiconductors > 7501 Foothills Blvd. > Roseville, CA 95747 > T: (916) 789-4951 M: (916) 297-0534 > michel.py at tsisemi.com | www.tsisemi.com< > http://www.tsisemi.com/> > MHP10-ARIN > > > [tsi] > > [cid:image004.gif at 01D1EBEE.F4F11880] > > Please consider the environment before printing this email. > > > > > > 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 ntt.net Mon Jul 30 21:04:37 2018 From: job at ntt.net (Job Snijders) Date: Mon, 30 Jul 2018 23:04:37 +0200 Subject: NTT US contact In-Reply-To: References: <24bfe2615e104bd995fbcfea029d1340@CRA110.am.necel.com> Message-ID: We are reaching out off list! Kind regards, Job On Mon, 30 Jul 2018 at 22:52, Christopher Morrow wrote: > job > > On Mon, Jul 30, 2018 at 4:49 PM Michel Py wrote: > > > Can someone from NTT US contact me off-list please ? > > Preferably someone with some RPKI clue. > > > > Thanks, > > > > Michel Py | Sr. Network Engineer > > TSI Semiconductors > > 7501 Foothills Blvd. > > Roseville, CA 95747 > > T: (916) 789-4951 M: (916) 297-0534 > > michel.py at tsisemi.com | www.tsisemi.com< > > http://www.tsisemi.com/> > > MHP10-ARIN > > > > > > [tsi] > > > > [cid:image004.gif at 01D1EBEE.F4F11880] > > > > Please consider the environment before printing this email. > > > > > > > > > > > > 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 ops.lists at gmail.com Tue Jul 31 06:11:13 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 31 Jul 2018 11:41:13 +0530 Subject: SP security knowledge build up In-Reply-To: References: Message-ID: As for MOOC course content - I don't know these guys from Adam's off ox, and while I know IIIT (note, not IIT) Bangalore, this is a course offered by them in collaboration with an outfit called FISST (oh dear.. the name). The course name looks like it is meant to train skript kiddeez but the content looks much more reasonable. Of course, given the extremely short course length, it is possibly like the usual mile wide inch deep CISSP training that'll help you learn a lot of buzzwords if nothing else. --srs https://talentedge.in/certified-cyber-warrior-iiit-bangalore/ Syllabus Cyber Security Foundation Module: Introduction & Overview of Cyber Security Common Security threats and prevention/mitigation plans Cryptography – fundamentals with theory of encryption keys (LMS) Networking Security – fundamentals with N/w layers and various protocols (LMS) Introduction to IT Act and Cyber Laws: Cyber Laws – Overview of Cyber Civil Wrong Cyber Laws – overview of Cyber Offences Case studies where brand and financial loss has been reported Introduction to Dark web and Deep Web: Dark web & Deep Web Anatomy of Financial Cyber Crime Organization Network Security & Best practices for secured n/w administration VPN Wireless Security Vulnerabilities in various layers of Information Systems: Overview of Multitasking and Multiprocessing Assess And Mitigate Security Vulnerabilities Understanding Security Capabilities of Information System Virtualization Memory Protection Memory & Address protection Protection Mechanisms Brief Introduction to Cyber Risk and Cyber Insurance Best Practices: Cyber Risk & Information Risk Management Risk Management Concepts Component of Risk Management – example Risk Management Process Common Cyber Threats Framework for Cyber and IS Risk Management Cyber Insurance – an Introduction What is cyber insurance How to assess and bargain a good policy How to implement documentation for claims Best practices for ‘zero’ risk policies Introduction to Physical Security & importance to protect IT Assets: Physical Security Introduction Perimeter / Boundary Security Building Security Inside Building with back-end command & Control System Overview of IoT devices Security & Concerns Introduction to Blockchain, Cryptocurrencies, and Bitcoins Introduction to Blockchain concept Cryptocurrencies Cyber Security Design and Maintaining Resilience Cyber Security Designing And Maintaining Resilience Designing a Resilient Enterprise Maintaining Enterprise Resilience Perimeter Protection with Firewall Incident Response Plan Cyber Risk Management process Inventory Authorized and Unauthorized devices and Software Recommended Best practices for Cyber Security: Cyber Hygiene Data Security Wireless networking Invoke the Incident Response Plan Recover RTO – RPO Preparedness Plan Audit Test your incident response plan Vendor Incident response 20 Critical Security Components – Part 1 Critical Control 1: Inventory of Authorized and Unauthorized Devices Critical Control 2: Inventory of Authorized and Unauthorized Software Critical Control 3: Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers Critical Control 4: Continuous Vulnerability Assessment and Remediation Critical Control 5: Controlled Use of Administrative Privileges Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs Critical Control 7: Email and Web Browser Protections Critical Control 8: Malware Defenses Critical Control 9: Limitation and Control of Network Ports, Protocols, and Services 20 Critical Security Components – Part 2 Critical Control 10: Data Recovery Capability Critical Control 11: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches Critical Control 12: Boundary Defense Critical Control 13: Data Protection Critical Control 14: Controlled Access Based On Need to Know Critical Control 15: Wireless Device Control Critical Control 16: Account Monitoring and Control Critical Control 17: Security Skills Assessment and Appropriate Training to Fill Gaps Critical Control 18: Application Software Security Critical Control 19: Incident Response and Management Critical Control 20: Penetration Tests and Red Team Exercises 2 Day On Campus Boot Camp at IIIT B Lab Session – General Threats Lab Session – Cryptography Boot Camp 1 Boot Camp 2 On Fri, Jul 27, 2018 at 5:39 PM Suresh Ramasubramanian wrote: > > Please start with the nanog videos Chris referenced and the book that I told you about. > > > > Before security knowledge, there’s a lot of hard CS and pure math involved if you want to teach it as a discipline – but that should be available most anywhere. And of course practical courses on network and system administration. > > > > Depends on whether you want to train junior analysts and build their knowledge in a more hands on manner in on the job training, or proceed with a graduate course that’ll take years and give them a deeper dive into this. > > > > For on the job training the videos and the Limoncelli book will do very well indeed for a start. > > > > --srs > > > > From: Ramy Hashish > Date: Friday, 27 July 2018 at 5:12 PM > To: NANOG Mailing List , , , Suresh Ramasubramanian , > Subject: Re: SP security knowledge build up > > > > Thank you guys for all your academic recommendation, unfortunately we are not US residents, so can you recommend the references/books/curriculum used in the mentioned programs? > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jcurran at arin.net Tue Jul 31 14:55:21 2018 From: jcurran at arin.net (John Curran) Date: Tue, 31 Jul 2018 14:55:21 +0000 Subject: TIMELY - Nominations close today at 5PM ET for NRO Number Council position Message-ID: Folks - Nominations are still being accepted until 5:00 PM EDT today, Tuesday, 31 July 2018 for candidates from the ARIN region to fill one seat on the Number Resource Organization Number Council (NRO NC) that will become vacant when Louie Lee’s term expires on 31 December 2018. If you aware of anyone who would be good at serving on the NRO NC and is interested in running, please nominate them ASAP! For more information see , or review the details attached to this message. Thanks! /John John Curran President and CEO ARIN === Begin forwarded message: From: ARIN > Subject: [arin-announce] 2018 Call for Nominations: NRO NC Date: 31 July 2018 at 10:45:45 AM EDT To: > Nominations are still being accepted until 5:00 PM EDT today, Tuesday, 31 July 2018 for candidates from the ARIN region to fill one seat on the Number Resource Organization Number Council (NRO NC) that will become vacant when Louie Lee’s term expires on 31 December 2018. Nominees for the NRO NC must reside within the ARIN region and be willing and available to serve a three-year term beginning 1 January 2019. Incumbents may be nominated for consecutive terms. NRO NC representatives are expected to attend all regularly-scheduled ARIN, ICANN, and ASO in-person meetings and teleconferences and serve as representatives from the ARIN region on the ICANN Address Supporting Organization Advisory Council (ASOAC). To view the role of the NRO NC and the function of the ASO, please visit: https://www.arin.net/about_us/nronc.html To view initial requirements and responsibilities of the NRO NC, please visit: https://www.arin.net/about_us/nronc_requirements.html Any individual, regardless of ARIN Member affiliation, may self-nominate or nominate one or more candidates for any open NRO NC position. All nominations must be received by 5:00 PM EDT, today, Tuesday, 31 July. Nominees who accept their nomination will have until 5:00 PM EDT Friday, 3 August to complete and submit their questionnaire. A final slate of NRO NC candidates will be announced on Monday, 24 September and elections will open to North American Network Operators Group (NANOG) and ARIN meeting attendees only on Monday, 1 October. Elections open to all eligible ARIN Member organizations’ Voting Contacts on Thursday, 4 October. To submit a nomination now, please click on the following link: https://www.surveymonkey.com/r/ARIN2018Nominations For more information on the nomination process and nominee eligibility requirements and responsibilities, including viewing ARIN’s region, please visit: https://www.arin.net/participate/elections/nronumbercouncil.html For questions or to request additional information, please email the ARIN Member Services team at members at arin.net. Regards, Wendy Leedy Member Engagement Coordinator American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From rubensk at gmail.com Tue Jul 31 16:33:39 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 31 Jul 2018 13:33:39 -0300 Subject: TIMELY - Nominations close today at 5PM ET for NRO Number Council position In-Reply-To: References: Message-ID: Only hat-wearing candidates may apply, otherwise ICANN will have 1 less hat. Rubens Em ter, 31 de jul de 2018 11:56, John Curran escreveu: > Folks - > > Nominations are still being accepted until 5:00 PM EDT today, Tuesday, 31 > July 2018 for candidates from the ARIN region to fill one seat on the > Number Resource Organization Number Council (NRO NC) that will become > vacant when Louie Lee’s term expires on 31 December 2018. > > If you aware of anyone who would be good at serving on the NRO NC and is > interested in running, please nominate them ASAP! > > For more information see < > https://lists.arin.net/pipermail/arin-announce/2018-July/002248.html>, or > review the details attached to this message. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > === > > Begin forwarded message: > > From: ARIN > > Subject: [arin-announce] 2018 Call for Nominations: NRO NC > Date: 31 July 2018 at 10:45:45 AM EDT > To: > > > Nominations are still being accepted until 5:00 PM EDT today, Tuesday, 31 > July 2018 for candidates from the ARIN region to fill one seat on the > Number Resource Organization Number Council (NRO NC) that will become > vacant when Louie Lee’s term expires on 31 December 2018. > > Nominees for the NRO NC must reside within the ARIN region and be willing > and available to serve a three-year term beginning 1 January 2019. > Incumbents may be nominated for consecutive terms. > > NRO NC representatives are expected to attend all regularly-scheduled > ARIN, ICANN, and ASO in-person meetings and teleconferences and serve as > representatives from the ARIN region on the ICANN Address Supporting > Organization Advisory Council (ASOAC). > > To view the role of the NRO NC and the function of the ASO, please visit: > > https://www.arin.net/about_us/nronc.html > > To view initial requirements and responsibilities of the NRO NC, please > visit: > > https://www.arin.net/about_us/nronc_requirements.html > > Any individual, regardless of ARIN Member affiliation, may self-nominate > or nominate one or more candidates for any open NRO NC position. All > nominations must be received by 5:00 PM EDT, today, Tuesday, 31 July. > Nominees who accept their nomination will have until 5:00 PM EDT Friday, 3 > August to complete and submit their questionnaire. > > A final slate of NRO NC candidates will be announced on Monday, 24 > September and elections will open to North American Network Operators Group > (NANOG) and ARIN meeting attendees only on Monday, 1 October. Elections > open to all eligible ARIN Member organizations’ Voting Contacts on > Thursday, 4 October. > > To submit a nomination now, please click on the following link: > > https://www.surveymonkey.com/r/ARIN2018Nominations > > For more information on the nomination process and nominee eligibility > requirements and responsibilities, including viewing ARIN’s region, please > visit: > > https://www.arin.net/participate/elections/nronumbercouncil.html > > For questions or to request additional information, please email the ARIN > Member Services team at members at arin.net. > > Regards, > > Wendy Leedy > Member Engagement Coordinator > American Registry for Internet Numbers (ARIN) > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. > > From dave at dogwood.com Fri Jul 27 23:18:47 2018 From: dave at dogwood.com (David Cornejo) Date: Fri, 27 Jul 2018 13:18:47 -1000 Subject: YANG daemeon for Linux In-Reply-To: References: Message-ID: YANG is a data modelling language and not a method for configuring Linux, though it can be used as a part of one. I am unaware of any open source software that implements a complete solution for parsing the YANG into a model, allowing the manipulation of that models data, and configuring the system to match that model. clixon (www.clicon.org), and it's companion CLI tool cligen, are toolkits to provide a parts of the solution, but they require a large amount of code to be complete. clixon parses the YANG into an XML schema and provides for the manipulation of the data via RESTCONF/NETCONF. clixon also has hooks to call routines to configure the system according to the model data, but not the actual calls. the companion cligen allows you to define a CLI language to manipulate the data, but a language is not provided. disclaimer: I am a contributor to clixon/cligen, the maintainer of its FreeBSD port, and a user of this software in a commercial product. On Fri, Jul 27, 2018 at 9:24 AM Karl Jørn wrote: > Looking for an agent on Linux that will render YANG models, so I can > provision networking on Linux. > > Danke, > Karl > > On Fri, Jul 27, 2018 at 11:25 AM, Wes Felter wrote: > > > On 7/20/18 2:30 PM, Karl Jørn wrote: > > > > Is there a YANG daemeon for Linux ? If yes, can any one please share > their > >> experiences ? > >> > > > > It's not clear what problem you're trying to solve, but > > http://www.clicon.org/ might do what you want. > > > > > -- Kailua, Hawaiʻi US +1 (808) 728-3050 UK +44 (020) 3286 2808 From alan at routingloop.com Mon Jul 30 13:21:56 2018 From: alan at routingloop.com (Alan Hannan) Date: Mon, 30 Jul 2018 08:21:56 -0500 Subject: Arista Backbone MPLS TE Message-ID: I'm interested in talking with folks who are using Arista for Backbone MPLS TE. Please contact me privately. Thanks! -- Alan Hannan 408-692-5268 From David.Hiers at cdk.com Mon Jul 30 17:00:24 2018 From: David.Hiers at cdk.com (Hiers, David) Date: Mon, 30 Jul 2018 17:00:24 +0000 Subject: Security team objectives In-Reply-To: <20180730065936.6408736c@p50.localdomain> References: <20180730065936.6408736c@p50.localdomain> Message-ID: The Big Goal of security can be stated something like this: "To bend all of the cost and benefit curves to most closely align with the organization's security goals" If the Board of Directors can't articulate the goals, your pretty much doomed. David -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Kristoff Sent: Monday, July 30, 2018 5:00 AM To: nanog at nanog.org Subject: Re: Security team objectives On Mon, 30 Jul 2018 04:43:35 +0000 Ramy Hashish wrote: > If you are going to start a security team in a newly founded IT > organization, what will the objectives/results be? Hello Ramy, Management and organization buy-in is important. Initially I would say it would be helpful to do some internal education and awareness, which helps with the first point. Identify a few things you can improve upon right away. Some small obtainable achievements would help justify the team if the team can point to some early success. Then build up that. FIRST.org, which is the original security team community, has a wealth of very detailed guides and information you might look over: John ---------------------------------------------------------------------- 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 blakangel at gmail.com Mon Jul 30 17:04:31 2018 From: blakangel at gmail.com (blakangel) Date: Mon, 30 Jul 2018 10:04:31 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <5B5F451F.1000608@gmail.com> References: <20180727212425.GB28013@metron.com> <5B5F451F.1000608@gmail.com> Message-ID: <5B5F451F.1000608@gmail.com> An HTML attachment was scrubbed... URL: From schoen at loyalty.org Mon Jul 30 20:06:23 2018 From: schoen at loyalty.org (Seth David Schoen) Date: Mon, 30 Jul 2018 13:06:23 -0700 Subject: Letsencrypt In-Reply-To: <98a229db-1a90-da51-a974-f3cd0c0f22a4@scarynet.org> References: <20180727212425.GB28013@metron.com> <98a229db-1a90-da51-a974-f3cd0c0f22a4@scarynet.org> Message-ID: <20180730200623.GT20782@frotz.zork.net> Alexander Maassen writes: > As most of you noticed, the domain letsencrypt.org is on clientHold, > does anyone have more information as of why this is the case ? Please see https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/5b5f5aa93a343f54d7982864 for updates and (eventually) https://community.letsencrypt.org/c/incidents for a postmortem. -- Seth David Schoen | Qué empresa fácil no pensar http://www.loyalty.org/~schoen/ | en un tigre, reflexioné. 8F08B027A5DB06ECF993B4660FD4F0CD2B11D2F9 | -- Borges, "El Zahir" From nicotine at warningg.com Tue Jul 31 17:19:49 2018 From: nicotine at warningg.com (Brandon Ewing) Date: Tue, 31 Jul 2018 12:19:49 -0500 Subject: YANG daemeon for Linux In-Reply-To: References: Message-ID: <20180731171948.GD8394@radiological.warningg.com> On Fri, Jul 27, 2018 at 01:18:47PM -1000, David Cornejo wrote: > > I am unaware of any open source software that implements a complete > solution for parsing the YANG into a model, allowing the manipulation of > that models data, and configuring the system to match that model. > pyangbind (https://github.com/robshakir/pyangbind) can be used to generate Python classes that you can bind data to. This isn't Linux-specific, but it is possible to input a YANG model, and some external data, and produce a usable Python data structure. napalm-yang (https://github.com/napalm-automation/napalm-yang) is an example of doing this via NAPALM output via profiles that handle the parsing to/from device native data structures, with differing levels of support: https://napalm-yang.readthedocs.io/en/latest/root/supported_models/index.html#profiles -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bill at herrin.us Tue Jul 31 18:37:10 2018 From: bill at herrin.us (William Herrin) Date: Tue, 31 Jul 2018 14:37:10 -0400 Subject: Security team objectives In-Reply-To: References: Message-ID: On Mon, Jul 30, 2018 at 12:43 AM, Ramy Hashish wrote: > If you are going to start a security team in a newly founded IT > organization, what will the objectives/results be? Hi Ramy, Sounds like you're putting the cart before the horse. Understand your security objectives first. That will determine the nature of the security team or indeed, if there should be a specific security team at all or some other security structure. Some common security objectives include: * Compliance with customer and vendor requirements * Loss prevention * Avoidance of legal liability for system compromise * Avoidance of brand damage due to system compromise * Operations continuity Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From sean at donelan.com Tue Jul 31 21:28:31 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 31 Jul 2018 17:28:31 -0400 (EDT) Subject: Confirming source-routed multicast is dead on the public Internet Message-ID: 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. From aaron1 at gvtc.com Tue Jul 31 21:32:26 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 31 Jul 2018 16:32:26 -0500 Subject: issues through CGNat (juniper ms-mpc-128g in mx960) In-Reply-To: <000001d41f6d$a014efd0$e03ecf70$@gvtc.com> References: <000001d41f6d$a014efd0$e03ecf70$@gvtc.com> Message-ID: <000e01d42915$fa4d50d0$eee7f270$@gvtc.com> Thanks for your replies... In the last week or so I've been testing further... Using the following items to slow/alleviate the otherwise randomness of ip's and port's been generated via my cgnat boundary nodes... APP - Address pooling paired EIM - Endpoint independent mapping EIF - Endpoint independent filtering (session-limit and outbound refresh are recommended) AMS Load balancing hash-key src-ip on my inside domain interface These combinations of options seems to cause a few nicer things to occur to help gaming and peer-to-peer and banking websites to work as they should. Let me know if you have seen similar issues and successes or failures with your cgnat deployment. -Aaron From bill at herrin.us Tue Jul 31 21:46:12 2018 From: bill at herrin.us (William Herrin) Date: Tue, 31 Jul 2018 17:46:12 -0400 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: On Tue, Jul 31, 2018 at 5:28 PM, 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. Hi Sean, I'm sure that transit providers with whom you have no commercial relationship are happy to let you program their routers to forward your multicast packets. Not just happy, ecstatic I'd say. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From woody at pch.net Tue Jul 31 21:50:05 2018 From: woody at pch.net (Bill Woodcock) Date: Tue, 31 Jul 2018 14:50:05 -0700 Subject: Confirming source-routed multicast is dead on the public Internet References: Message-ID: <7F4616E4-7B4F-4B27-B1D7-88D95894CB04@pch.net> > 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 -------------- 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 sean at donelan.com Tue Jul 31 22:02:56 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 31 Jul 2018 18:02:56 -0400 (EDT) Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: head-thunk Source-Specific Multicast Never post while extremely frustrated. From job at ntt.net Tue Jul 31 22:15:47 2018 From: job at ntt.net (Job Snijders) Date: Wed, 1 Aug 2018 00:15:47 +0200 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: 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 jtk at depaul.edu Tue Jul 31 22:40:19 2018 From: jtk at depaul.edu (John Kristoff) Date: Tue, 31 Jul 2018 17:40:19 -0500 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: <258fe76ff8ca4ee9b4da39f5ab42ad11@XCASPRD01-DFT.dpu.depaul.edu> References: <258fe76ff8ca4ee9b4da39f5ab42ad11@XCASPRD01-DFT.dpu.depaul.edu> Message-ID: <20180731174019.115ec162@p50.localdomain> On Tue, 31 Jul 2018 21:28:31 +0000 Sean Donelan wrote: > 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. More anecdotal evidence. Probably the best place to know what is going on with multicast is on the mboned list (yea that still exists): 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. There is almost no public multicast monitoring anymore. Practically all dead. You could poke around the I2 router proxies and see what is happening on some of the last of the remaining IP multicast-enabled Internet (hint, mostly noise from odd devices that have strayed outside the local institution): show multicast routes show pim join ... I keep hearing about some research project in the deep blue sea that uses it. You might find a small amount of it out there, but I'd bet overall its usage is teeny tiny and limited to a shrinking number of networks. Turned off interdomain multicast when I returned here in 2016. John From patrick at ianai.net Tue Jul 31 22:44:47 2018 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 31 Jul 2018 15:44:47 -0700 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: <110887A0-972C-44D0-A0B2-E207D4A2C58F@ianai.net> 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. -- TTFN, patrick > On Jul 31, 2018, at 15:15, 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 woody at pch.net Tue Jul 31 21:36:09 2018 From: woody at pch.net (Bill Woodcock) Date: Tue, 31 Jul 2018 14:36:09 -0700 Subject: Confirming source-routed multicast is dead on the public Internet In-Reply-To: References: Message-ID: > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: