From nanog at studio442.com.au Thu Nov 1 00:44:54 2018 From: nanog at studio442.com.au (Julien Goodwin) Date: Thu, 1 Nov 2018 11:44:54 +1100 Subject: Brocade SLX Internet Edge In-Reply-To: <3abb1063-53cb-a09f-2d31-d8dc4feed02f@monmotha.net> References: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> <354e4a60-3a39-28e9-62f4-b4356ceb41d7@monmotha.net> <3abb1063-53cb-a09f-2d31-d8dc4feed02f@monmotha.net> Message-ID: <7f142395-6acf-0081-369a-d63b913e4dfe@studio442.com.au> On 01/11/18 09:55, Brandon Martin wrote: > On 10/31/18 6:37 PM, Christopher Morrow wrote: >> If you buy brocade, be sure to also by a license for securecrt so that >> backspace works over ssh... >> also, just don't do brocade... ever. > > Works fine for me using OpenSSH in most Linux-y terminal emulators > (Konsole, Linux console, Gnome terminal).  I didn't do any special > configuration. > > Now, over serial, enjoy your ctrl-H unless you do some remapping. Yep, they fixed backspace via SSH (at least for MLX) a few years ago. Sad that they didn't fix the console ports at the same time. From dcorbe at hammerfiber.com Thu Nov 1 02:51:14 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Wed, 31 Oct 2018 22:51:14 -0400 Subject: Brocade SLX Internet Edge In-Reply-To: <7f142395-6acf-0081-369a-d63b913e4dfe@studio442.com.au> References: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> <354e4a60-3a39-28e9-62f4-b4356ceb41d7@monmotha.net> <3abb1063-53cb-a09f-2d31-d8dc4feed02f@monmotha.net> <7f142395-6acf-0081-369a-d63b913e4dfe@studio442.com.au> Message-ID: <3C51349B-7B0F-4E30-B1E0-1811006935FC@hammerfiber.com> I’m just going to echo what a few others have been saying. Brocade (now Extreme) have come a long way since the Foundry days; and the SLX isn’t based on the old Netiron code. The platform is a completely different animal. I’ve been a happy Brocade customer for a while now. From jk at ip-clear.de Thu Nov 1 10:04:01 2018 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Thu, 01 Nov 2018 11:04:01 +0100 Subject: Brocade SLX Internet Edge In-Reply-To: References: Message-ID: <62459480-3D45-4E4D-B404-4378AEA12E5C@ip-clear.de> Hi, I do have some 9540s near exchange points, but they are not 100% productive right now, basically waiting for the next software release this month and a maintenance window. In my eyes the device is filling the gap between the CES/CER series and the MLX/SLX9850. It will be also interesting where Bro Extreme is going to position the new, bigger (?) brother 9640 next year. Our 9540s take full feeds right now without moaning: show ip route summary IP Routing Table - 717510 entries: Number of prefixes: /0: 1 /8: 14 /9: 11 /10: 35 /11: 98 /12: 291 /13: 567 /14: 1130 /15: 1932 /16: 13357 /17: 7876 /18: 13735 /19: 25102 /20: 38379 /21: 45371 /22: 89251 /23: 73451 /24: 406788 /25: 2 /26: 9 /27: 22 /28: 35 /29: 36 /30: 8 /32: 9 And for this to work, you need - the latest release, 18r.1.00, better 18r.2.00 (End of Nov 18) because of DEFECT000666685 (prefix filter list) - buy / activate the trust-based advanced features license for MPLS, BGP-EVPN, CE2.0, Optiscale, basically on cli: => license eula accept - activate Optiscale Routing in the configuration => profile route route-enhance hw_opt on v4_fib_comp on v6_fib_comp on => shall scale to 1.5M IPv4 & 140k IPv6 routes (the 256k IPv4 / 64k IPv6 information is old) With the advanced license you are also eligible to spin up a Linux VM for additional tools, monitoring et al on a reserved cpu core. The software part of the SLX feels like a mixture of Brocade NOS (port-channel, vlan, switchport, … ) and Netiron components (router configuration, …) while the hardware is pretty much inspired by the VDX line. Therefore some SNMP tools like LibreNMS recognize the SLX as VDX because of fancy wildcards in the hardware model type and I am still looking to write some patches for this. Regards Jörg On 31 Oct 2018, at 21:01, Kevin Burke wrote: > Does anyone have any success with the Brocade SLX 9540 or similar? > Its going to be taking full BGP tables from two Tier1's and some > peering. > > The specs and sales rep says its fine, but the price makes me think > its too good to be true. > > We are trying to shepherd an old Cat 6509 out of our core. > > > Kevin Burke > 802-540-0979 > Burlington Telecom - City of Burlington > 200 Church St, Burlington, VT 05401 From kburke at burlingtontelecom.com Thu Nov 1 13:02:10 2018 From: kburke at burlingtontelecom.com (Kevin Burke) Date: Thu, 1 Nov 2018 13:02:10 +0000 Subject: Brocade SLX Internet Edge In-Reply-To: References: Message-ID: Thanks for everyone who responded on and off list. As a small company that is happy to still be in business the pricing is too good to ignore. A "gently used" ASR-9006 is something like $45k for one plus a shelf spare. A brand new SLX 9540 is something like $30k for one plus a shelf spare. There were some common things. Software is behind where we would like. The occasional bug like that SSH one. Also there are some relatively common features like IPv6 outbound ACL and BGP MED that aren't there. This stuff isn't a showstopper but I will take this a sign of things to come. As for the notes about full tables. Different vendors seem to have used different techniques to get past the hard FIB limit that we are all used to. I had the same question when pawing through the spec sheets. So I asked the sales rep: "We can support 1.5M routes..... These platforms support all of the requirements detailed above for Internet routing. In particular, they support a table size of 1.5 million IP routes today, ensuring headroom for the next 5-7 years. This scale is made possible through our new technology called Extreme OptiScale(tm) for Internet Routing that optimizes programmable hardware and software capabilities to accelerate innovation and deliver investment protection. https://www.extremenetworks.com/extreme-networks-blog/internet-routing-in-the-enterprise/" Kevin Burke 802-540-0979 Burlington Telecom - City of Burlington 200 Church St, Burlington, VT 05401 -----Original Message----- From: NANOG On Behalf Of Kevin Burke Sent: Wednesday, October 31, 2018 4:02 PM To: nanog at nanog.org Subject: Brocade SLX Internet Edge Does anyone have any success with the Brocade SLX 9540 or similar? Its going to be taking full BGP tables from two Tier1's and some peering. The specs and sales rep says its fine, but the price makes me think its too good to be true. We are trying to shepherd an old Cat 6509 out of our core. Kevin Burke 802-540-0979 Burlington Telecom - City of Burlington 200 Church St, Burlington, VT 05401 -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Thu Nov 1 13:23:05 2018 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 1 Nov 2018 08:23:05 -0500 Subject: Brocade SLX Internet Edge In-Reply-To: References: Message-ID: I think Extreme is doing the same thing with their Extreme OptiScale™ that Arista is doing with their Arista FlexRoute™ and EOS NetDB™. They are both using Broadcom Jericho /Qurman with extenal TCAM, but still has a hardware limitiation on route table size. Then in software they filer right? Question is who has a better solution Arista or Extreme for this? Also, the question is can any whitebox vendors do the same thing, with the same Broadcom switch you can buy for around $9k new. Another question, could you even consider these with the Juniper MX204 coming in at $20k? On Thu, Nov 1, 2018 at 8:04 AM Kevin Burke wrote: > Thanks for everyone who responded on and off list. > > > > As a small company that is happy to still be in business the pricing is > too good to ignore. A “gently used” ASR-9006 is something like $45k for > one plus a shelf spare. A brand new SLX 9540 is something like $30k for > one plus a shelf spare. > > > > There were some common things. Software is behind where we would like. > The occasional bug like that SSH one. Also there are some relatively > common features like IPv6 outbound ACL and BGP MED that aren’t there. This > stuff isn't a showstopper but I will take this a sign of things to come. > > > > As for the notes about full tables. Different vendors seem to have used > different techniques to get past the hard FIB limit that we are all used > to. I had the same question when pawing through the spec sheets. So I > asked the sales rep: > > > > “We can support 1.5M routes….. > > > > *These platforms support all of the requirements detailed above for > Internet routing. In particular, they support a table size of 1.5 million > IP routes today, ensuring headroom for the next 5-7 years. This scale is > made possible through our new technology called Extreme OptiScale™ for > Internet Routing that optimizes programmable hardware and software > capabilities to accelerate innovation and deliver investment protection.* > > > > > https://www.extremenetworks.com/extreme-networks-blog/internet-routing-in-the-enterprise/ > > ” > > > > > > Kevin Burke > > 802-540-0979 > > Burlington Telecom - City of Burlington > > 200 Church St, Burlington, VT 05401 > > -----Original Message----- > From: NANOG On Behalf Of Kevin Burke > Sent: Wednesday, October 31, 2018 4:02 PM > To: nanog at nanog.org > Subject: Brocade SLX Internet Edge > > > > Does anyone have any success with the Brocade SLX 9540 or similar? Its > going to be taking full BGP tables from two Tier1's and some peering. > > > > The specs and sales rep says its fine, but the price makes me think its > too good to be true. > > > > We are trying to shepherd an old Cat 6509 out of our core. > > > > > > Kevin Burke > > 802-540-0979 > > Burlington Telecom - City of Burlington > > 200 Church St, Burlington, VT 05401 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Thu Nov 1 14:31:32 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 1 Nov 2018 16:31:32 +0200 Subject: Brocade SLX Internet Edge In-Reply-To: References: Message-ID: Hey, They all do in principle the same thing. There are memories for longest path lookup and memories for exact lookup. I believe the trick is to put specific prefix size, like /24 to exact lookup table, relieving the LPM table stress greatly. Then in parallel ask both, and take more specific result. There are variation to this, like having multiple separate exact match tables, and populating each with different prefix size, and so forth. Juniper on PTX is doing something quite different, they are asking on-chip bloom filter about hint on where to query, reducing query count they need to do towards high latency off-chip memory. MX is doing yet something different, having JNPR proprietary memory ASIC (no longer plain (RL)DRAM). ASR9k is still just TCAM (for all ezchip generations, unsure about lightspeed). On Thu, 1 Nov 2018 at 15:26, Colton Conor wrote: > > I think Extreme is doing the same thing with their Extreme OptiScale™ that Arista is doing with their Arista FlexRoute™ and EOS NetDB™. They are both using Broadcom Jericho /Qurman with extenal TCAM, but still has a hardware limitiation on route table size. Then in software they filer right? > > Question is who has a better solution Arista or Extreme for this? > > Also, the question is can any whitebox vendors do the same thing, with the same Broadcom switch you can buy for around $9k new. > > Another question, could you even consider these with the Juniper MX204 coming in at $20k? > > > > On Thu, Nov 1, 2018 at 8:04 AM Kevin Burke wrote: >> >> Thanks for everyone who responded on and off list. >> >> >> >> As a small company that is happy to still be in business the pricing is too good to ignore. A “gently used” ASR-9006 is something like $45k for one plus a shelf spare. A brand new SLX 9540 is something like $30k for one plus a shelf spare. >> >> >> >> There were some common things. Software is behind where we would like. The occasional bug like that SSH one. Also there are some relatively common features like IPv6 outbound ACL and BGP MED that aren’t there. This stuff isn't a showstopper but I will take this a sign of things to come. >> >> >> >> As for the notes about full tables. Different vendors seem to have used different techniques to get past the hard FIB limit that we are all used to. I had the same question when pawing through the spec sheets. So I asked the sales rep: >> >> >> >> “We can support 1.5M routes….. >> >> >> >> These platforms support all of the requirements detailed above for Internet routing. In particular, they support a table size of 1.5 million IP routes today, ensuring headroom for the next 5-7 years. This scale is made possible through our new technology called Extreme OptiScale™ for Internet Routing that optimizes programmable hardware and software capabilities to accelerate innovation and deliver investment protection. >> >> >> >> https://www.extremenetworks.com/extreme-networks-blog/internet-routing-in-the-enterprise/” >> >> >> >> >> >> Kevin Burke >> >> 802-540-0979 >> >> Burlington Telecom - City of Burlington >> >> 200 Church St, Burlington, VT 05401 >> >> -----Original Message----- >> From: NANOG On Behalf Of Kevin Burke >> Sent: Wednesday, October 31, 2018 4:02 PM >> To: nanog at nanog.org >> Subject: Brocade SLX Internet Edge >> >> >> >> Does anyone have any success with the Brocade SLX 9540 or similar? Its going to be taking full BGP tables from two Tier1's and some peering. >> >> >> >> The specs and sales rep says its fine, but the price makes me think its too good to be true. >> >> >> >> We are trying to shepherd an old Cat 6509 out of our core. >> >> >> >> >> >> Kevin Burke >> >> 802-540-0979 >> >> Burlington Telecom - City of Burlington >> >> 200 Church St, Burlington, VT 05401 -- ++ytti From chris.welti at switch.ch Thu Nov 1 15:03:59 2018 From: chris.welti at switch.ch (Chris Welti) Date: Thu, 1 Nov 2018 16:03:59 +0100 Subject: Brocade SLX Internet Edge In-Reply-To: References: Message-ID: Nicolas Fevrier has a very detailed blog post on how Cisco handles the prefixes on their Broadcom Jericho based NCS 5500 gear. https://xrdocs.io/cloud-scale-networking/tutorials/2017-08-03-understanding-ncs5500-resources-s01e02/ I'm pretty sure the principle is more or less the same for the Jericho based platforms on Arista and Extreme. Best regards, Chris On 01.11.18 15:31, Saku Ytti wrote: > Hey, > > They all do in principle the same thing. There are memories for > longest path lookup and memories for exact lookup. I believe the trick > is to put specific prefix size, like /24 to exact lookup table, > relieving the LPM table stress greatly. Then in parallel ask both, and > take more specific result. > > There are variation to this, like having multiple separate exact match > tables, and populating each with different prefix size, and so forth. > > Juniper on PTX is doing something quite different, they are asking > on-chip bloom filter about hint on where to query, reducing query > count they need to do towards high latency off-chip memory. > > MX is doing yet something different, having JNPR proprietary memory > ASIC (no longer plain (RL)DRAM). > > ASR9k is still just TCAM (for all ezchip generations, unsure about lightspeed). > On Thu, 1 Nov 2018 at 15:26, Colton Conor wrote: >> >> I think Extreme is doing the same thing with their Extreme OptiScale™ that Arista is doing with their Arista FlexRoute™ and EOS NetDB™. They are both using Broadcom Jericho /Qurman with extenal TCAM, but still has a hardware limitiation on route table size. Then in software they filer right? >> >> Question is who has a better solution Arista or Extreme for this? >> >> Also, the question is can any whitebox vendors do the same thing, with the same Broadcom switch you can buy for around $9k new. >> >> Another question, could you even consider these with the Juniper MX204 coming in at $20k? >> >> >> >> On Thu, Nov 1, 2018 at 8:04 AM Kevin Burke wrote: >>> >>> Thanks for everyone who responded on and off list. >>> >>> >>> >>> As a small company that is happy to still be in business the pricing is too good to ignore. A “gently used” ASR-9006 is something like $45k for one plus a shelf spare. A brand new SLX 9540 is something like $30k for one plus a shelf spare. >>> >>> >>> >>> There were some common things. Software is behind where we would like. The occasional bug like that SSH one. Also there are some relatively common features like IPv6 outbound ACL and BGP MED that aren’t there. This stuff isn't a showstopper but I will take this a sign of things to come. >>> >>> >>> >>> As for the notes about full tables. Different vendors seem to have used different techniques to get past the hard FIB limit that we are all used to. I had the same question when pawing through the spec sheets. So I asked the sales rep: >>> >>> >>> >>> “We can support 1.5M routes….. >>> >>> >>> >>> These platforms support all of the requirements detailed above for Internet routing. In particular, they support a table size of 1.5 million IP routes today, ensuring headroom for the next 5-7 years. This scale is made possible through our new technology called Extreme OptiScale™ for Internet Routing that optimizes programmable hardware and software capabilities to accelerate innovation and deliver investment protection. >>> >>> >>> >>> https://www.extremenetworks.com/extreme-networks-blog/internet-routing-in-the-enterprise/” >>> >>> >>> >>> >>> >>> Kevin Burke >>> >>> 802-540-0979 >>> >>> Burlington Telecom - City of Burlington >>> >>> 200 Church St, Burlington, VT 05401 >>> >>> -----Original Message----- >>> From: NANOG On Behalf Of Kevin Burke >>> Sent: Wednesday, October 31, 2018 4:02 PM >>> To: nanog at nanog.org >>> Subject: Brocade SLX Internet Edge >>> >>> >>> >>> Does anyone have any success with the Brocade SLX 9540 or similar? Its going to be taking full BGP tables from two Tier1's and some peering. >>> >>> >>> >>> The specs and sales rep says its fine, but the price makes me think its too good to be true. >>> >>> >>> >>> We are trying to shepherd an old Cat 6509 out of our core. >>> >>> >>> >>> >>> >>> Kevin Burke >>> >>> 802-540-0979 >>> >>> Burlington Telecom - City of Burlington >>> >>> 200 Church St, Burlington, VT 05401 > > > From nanog at ics-il.net Thu Nov 1 15:06:26 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 1 Nov 2018 10:06:26 -0500 (CDT) Subject: Brocade SLX Internet Edge In-Reply-To: <3C51349B-7B0F-4E30-B1E0-1811006935FC@hammerfiber.com> References: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> <354e4a60-3a39-28e9-62f4-b4356ceb41d7@monmotha.net> <3abb1063-53cb-a09f-2d31-d8dc4feed02f@monmotha.net> <7f142395-6acf-0081-369a-d63b913e4dfe@studio442.com.au> <3C51349B-7B0F-4E30-B1E0-1811006935FC@hammerfiber.com> Message-ID: <873723184.417.1541084784885.JavaMail.mhammett@ThunderFuck> Some of it is Extreme, some of it is Arris. The only issue I've had with anything Brocade\Foundry is lack of features in older platforms. They've always been solid for me. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Daniel Corbe" To: "Julien Goodwin" Cc: "nanog list" Sent: Wednesday, October 31, 2018 9:51:14 PM Subject: Re: Brocade SLX Internet Edge I’m just going to echo what a few others have been saying. Brocade (now Extreme) have come a long way since the Foundry days; and the SLX isn’t based on the old Netiron code. The platform is a completely different animal. I’ve been a happy Brocade customer for a while now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Thu Nov 1 18:55:38 2018 From: blake at ispn.net (Blake Hudson) Date: Thu, 1 Nov 2018 13:55:38 -0500 Subject: Brocade SLX Internet Edge In-Reply-To: References: Message-ID: Chris Welti wrote on 11/1/2018 10:03 AM: > Nicolas Fevrier has a very detailed blog post on how Cisco handles the prefixes on their Broadcom Jericho based NCS 5500 gear. > https://xrdocs.io/cloud-scale-networking/tutorials/2017-08-03-understanding-ncs5500-resources-s01e02/ > > I'm pretty sure the principle is more or less the same for the Jericho based platforms on Arista and Extreme. > > Best regards, > Chris I love the nitty gritty detail in this author's post and I'm glad he concludes by stating clearly that while the base card (spec sheet says: "On-chip tables for 256K IPv4 or 64K IPv6 routes" and "On-chip tables for 786K IPv4 host routes, MAC, and labels") can actually hold a full BGP table today when configured appropriately, Cisco still recommends the scale cards for that application (spec sheet says: "FIB scale up 2M IPv4 or 512K IPv6 routes" and "On-chip tables for 786K IPv4 host routes, MAC, and labels"). I do have to wonder about the internal expansion of each /23 route into two /24 routes in their FIB algorithm, as I would have thought Cisco would have attempted to go the opposite way, but I'm sure Cisco has their reasons. From sean at donelan.com Fri Nov 2 00:57:10 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 1 Nov 2018 20:57:10 -0400 (EDT) Subject: FCC Broadband advisory working group in disaster response and recovery Message-ID: The FCC has announced the members of the Broadband Deployment Advisory Committee working group on disaster response and recovery. Chair: Red Grasso, FirstNet State Point of Contact North Carolina Department of Information Technology Vice-Chair: Jonathan Adelstein, President & Chief Executive Officer* Wireless Infrastructure Association Members: Andrew Afflerbach, Chief Executive Officer and Director of Engineering, CTC Technology and Energy National Association of Telecommunications Officers and Advisors Allen Bell, Distribution Support Manager, Georgia Power Company* Southern Company Megan Bixler, Technical Program Manager for Communications Center and 911 Services Association of Public Safety Communications Officials Skyler Ditchfield, Chief Executive Officer GeoLinks Patrick Donovan, Senior Director, Regulatory Affairs CTIA Tony Fischer, Director, Information Technology City of Germantown, Tennessee Monica Gambino, Vice President, Legal Crown Castle Larry Hanson, Executive Director* Georgia Municipal Association David Hartshorn, Chief Executive Officer Geeks Without Frontiers Greg Hauser, Communications Branch Manager/Statewide Interoperability Coordinator, North Carolina Emergency Management Division National Emergency Management Association Kurt Jacobs, Corporate Director, Emerging Technology & Solutions JMA Wireless Richard Kildow, Director of Business Continuity & Emergency Management Verizon Frank Korinek, Director of Government Affairs Motorola Wyatt Leehy, Information Technology Manager Great Plains Communications David Marshack, Telecommunications Regulatory Lead Loon Jim Matheson, Chief Executive Officer* National Rural Electric Cooperative Association Kelly McGriff, Vice President & Deputy General Counsel* Uniti Group Wendy Moser, Commissioner, Colorado Public Utilities Commission National Association of Regulatory Utility Commissioners Alexandra Fernandez Navarro, Commissioner Puerto Rico Public Service Regulatory Board John O’Connor, Director, National Coordinating Center for Communications Department of Homeland Security Eddie Reyes, Prince William County Emergency Communications Center National Public Safety Telecommunications Council Rikin Thaker, Vice President, Telecommunications and Spectrum Policy* Multicultural Media, Telecom and Internet Council Pete Tomczak, Manager, Spectrum Coordination and Clearance FirstNet Rocky Vaz, Director of Emergency Management City of Dallas, Texas Joseph Viens, Senior Director of Government Affairs Charter Debra Wulff, Public Safety Director Confederated Tribes of the Colville Reservation From cscora at apnic.net Fri Nov 2 18:03:14 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Nov 2018 04:03:14 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181102180315.1B65CC450F@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 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 03 Nov, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 724058 Prefixes after maximum aggregation (per Origin AS): 278351 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 347474 Total ASes present in the Internet Routing Table: 62311 Prefixes per ASN: 11.62 Origin-only ASes present in the Internet Routing Table: 53784 Origin ASes announcing only one prefix: 23352 Transit ASes present in the Internet Routing Table: 8527 Transit-only ASes present in the Internet Routing Table: 259 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 36 Max AS path prepend of ASN ( 30873) 34 Prefixes from unregistered ASNs in the Routing Table: 36 Number of instances of unregistered ASNs: 36 Number of 32-bit ASNs allocated by the RIRs: 24713 Number of 32-bit ASNs visible in the Routing Table: 19978 Prefixes from 32-bit ASNs in the Routing Table: 85127 Number of bogon 32-bit ASNs visible in the Routing Table: 15 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 262 Number of addresses announced to Internet: 2857432321 Equivalent to 170 /8s, 80 /16s and 245 /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.1 Total number of prefixes smaller than registry allocations: 241521 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 197668 Total APNIC prefixes after maximum aggregation: 56146 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 195158 Unique aggregates announced from the APNIC address blocks: 80261 APNIC Region origin ASes present in the Internet Routing Table: 9203 APNIC Prefixes per ASN: 21.21 APNIC Region origin ASes announcing only one prefix: 2574 APNIC Region transit ASes present in the Internet Routing Table: 1370 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: 4184 Number of APNIC addresses announced to Internet: 768168640 Equivalent to 45 /8s, 201 /16s and 82 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 215080 Total ARIN prefixes after maximum aggregation: 102072 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 214525 Unique aggregates announced from the ARIN address blocks: 102050 ARIN Region origin ASes present in the Internet Routing Table: 18279 ARIN Prefixes per ASN: 11.74 ARIN Region origin ASes announcing only one prefix: 6787 ARIN Region transit ASes present in the Internet Routing Table: 1828 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: 2486 Number of ARIN addresses announced to Internet: 1098799264 Equivalent to 65 /8s, 126 /16s and 88 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 197489 Total RIPE prefixes after maximum aggregation: 94402 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 193880 Unique aggregates announced from the RIPE address blocks: 114827 RIPE Region origin ASes present in the Internet Routing Table: 25598 RIPE Prefixes per ASN: 7.57 RIPE Region origin ASes announcing only one prefix: 11465 RIPE Region transit ASes present in the Internet Routing Table: 3529 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7541 Number of RIPE addresses announced to Internet: 715282816 Equivalent to 42 /8s, 162 /16s and 89 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 93937 Total LACNIC prefixes after maximum aggregation: 21540 LACNIC Deaggregation factor: 4.36 Prefixes being announced from the LACNIC address blocks: 95372 Unique aggregates announced from the LACNIC address blocks: 41659 LACNIC Region origin ASes present in the Internet Routing Table: 7735 LACNIC Prefixes per ASN: 12.33 LACNIC Region origin ASes announcing only one prefix: 2118 LACNIC Region transit ASes present in the Internet Routing Table: 1451 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5278 Number of LACNIC addresses announced to Internet: 172528672 Equivalent to 10 /8s, 72 /16s and 148 /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: 19847 Total AfriNIC prefixes after maximum aggregation: 4162 AfriNIC Deaggregation factor: 4.77 Prefixes being announced from the AfriNIC address blocks: 24861 Unique aggregates announced from the AfriNIC address blocks: 8434 AfriNIC Region origin ASes present in the Internet Routing Table: 1215 AfriNIC Prefixes per ASN: 20.46 AfriNIC Region origin ASes announcing only one prefix: 408 AfriNIC Region transit ASes present in the Internet Routing Table: 244 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 489 Number of AfriNIC addresses announced to Internet: 102250496 Equivalent to 6 /8s, 24 /16s and 56 /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 4637 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4546 514 511 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2991 1154 94 VIETEL-AS-AP Viettel Group, VN 45899 2947 1685 109 VNPT-AS-VN VNPT Corp, VN 4766 2806 11130 764 KIXS-AS-KR Korea Telecom, KR 9829 2746 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2446 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2422 4907 30 CTTNET China TieTong Telecommunications 17974 2244 968 51 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2130 421 170 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 3467 1324 84 SHAW - Shaw Communications Inc., CA 11492 3459 223 629 CABLEONE - CABLE ONE, INC., US 22773 3271 2972 164 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2413 5012 869 AMAZON-02 - Amazon.com, Inc., US 18566 2154 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2145 2738 541 CHARTER-NET-HKY-NC - Charter Communicat 16625 2117 1140 1571 AKAMAI-AS - Akamai Technologies, Inc., 5650 2084 3074 1461 FRONTIER-FRTR - Frontier Communications 30036 2056 346 148 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2040 5079 594 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5006 1615 134 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3043 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2561 574 1913 AKAMAI-ASN1, US 12389 2178 2172 640 ROSTELECOM-AS, RU 34984 2012 334 534 TELLCOM-AS, TR 9121 1878 1691 17 TTNET, TR 13188 1600 100 42 TRIOLAN, UA 8402 1279 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5439 3307 600 Uninet S.A. de C.V., MX 10620 3196 489 810 Telmex Colombia S.A., CO 11830 2663 370 75 Instituto Costarricense de Electricidad 6503 1660 449 54 Axtel, S.A.B. de C.V., MX 7303 1441 964 208 Telecom Argentina S.A., AR 28573 1128 2237 181 CLARO S.A., BR 6147 1089 377 29 Telefonica del Peru S.A.A., PE 3816 1025 512 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 937 145 72 Alestra, S. de R.L. de C.V., MX 13999 923 538 259 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1155 394 29 LINKdotNET-AS, EG 37611 909 107 9 Afrihost, ZA 36903 794 399 146 MT-MPLS, MA 36992 752 1411 41 ETISALAT-MISR, EG 24835 650 694 19 RAYA-AS, EG 8452 637 1728 15 TE-AS TE-AS, EG 37492 467 470 57 ORANGE-, TN 29571 463 70 12 ORANGE-COTE-IVOIRE, CI 23889 400 231 15 MauritiusTelecom, MU 37342 394 32 1 MOVITEL, MZ 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 5439 3307 600 Uninet S.A. de C.V., MX 12479 5006 1615 134 UNI2-AS, ES 4538 4637 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4546 514 511 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3467 1324 84 SHAW - Shaw Communications Inc., CA 11492 3459 223 629 CABLEONE - CABLE ONE, INC., US 22773 3271 2972 164 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3196 489 810 Telmex Colombia S.A., CO 8551 3043 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5006 4872 UNI2-AS, ES 4538 4637 4563 ERX-CERNET-BKB China Education and Research Net 7545 4546 4035 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3467 3383 SHAW - Shaw Communications Inc., CA 22773 3271 3107 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3043 3000 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2991 2897 VIETEL-AS-AP Viettel Group, VN 45899 2947 2838 VNPT-AS-VN VNPT Corp, VN 11492 3459 2830 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 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 65553 UNALLOCATED 103.218.190.0/24 58715 EARTHTELECOMMUNICATION-AS EART 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 92937 UNALLOCATED 110.49.72.0/24 45458 SBN-AWN-AS-02-AP SBN-ISP/AWN-I 4230060012 PRIVATE 132.190.106.0/24 64673 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.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.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.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 45.252.236.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 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:98 /12:289 /13:567 /14:1099 /15:1890 /16:13332 /17:7865 /18:13832 /19:25440 /20:39630 /21:46101 /22:89932 /23:73951 /24:407748 /25:817 /26:629 /27:640 /28:36 /29:20 /30:24 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3829 5006 UNI2-AS, ES 6327 3252 3467 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2745 3459 CABLEONE - CABLE ONE, INC., US 22773 2527 3271 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2499 3043 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2048 2154 MEGAPATH5-US - MegaPath Corporation, US 11830 2010 2663 Instituto Costarricense de Electricidad y Telec 30036 1805 2056 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2084 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1620 2:886 4:18 5:2694 6:43 7:1 8:1133 12:1875 13:240 14:1863 15:32 16:3 17:192 18:58 20:50 23:2484 24:2441 25:2 27:2498 31:2003 32:85 35:30 36:566 37:2933 38:1563 39:265 40:122 41:3203 42:714 43:1978 44:125 45:5943 46:3093 47:230 49:1308 50:1069 51:318 52:1098 54:363 55:1 56:12 57:38 58:1656 59:992 60:453 61:2086 62:1953 63:1789 64:5050 65:2196 66:4816 67:2664 68:1158 69:3357 70:1178 71:600 72:2230 74:2726 75:414 76:479 77:1669 78:1735 79:2223 80:1567 81:1409 82:1052 83:795 84:1041 85:2075 86:552 87:1469 88:948 89:2381 90:209 91:6477 92:1269 93:2390 94:2425 95:3019 96:914 97:350 98:936 99:152 100:71 101:1163 102:272 103:19057 104:3588 105:231 106:881 107:1845 108:710 109:3386 110:1667 111:1822 112:1396 113:1312 114:1142 115:1685 116:1651 117:1900 118:2201 119:1673 120:1105 121:1045 122:2333 123:1680 124:1447 125:1945 128:1202 129:690 130:507 131:1616 132:708 133:189 134:1038 135:237 136:528 137:659 138:1956 139:721 140:558 141:755 142:809 143:1003 144:844 145:498 146:1247 147:763 148:1682 149:779 150:764 151:998 152:873 153:325 154:2010 155:952 156:1569 157:843 158:656 159:1862 160:1478 161:868 162:2639 163:757 164:1107 165:1580 166:455 167:1349 168:3145 169:861 170:3991 171:492 172:1057 173:2095 174:986 175:829 176:2133 177:4016 178:2510 179:1298 180:2123 181:2432 182:2591 183:1471 184:1130 185:14292 186:3595 187:2455 188:2925 189:2014 190:8328 191:1396 192:9905 193:6376 194:5190 195:4028 196:2897 197:1618 198:5674 199:5968 200:7361 201:5022 202:10220 203:10159 204:4608 205:3024 206:3233 207:3215 208:3944 209:4156 210:3846 211:2015 212:3006 213:2831 214:1048 215:55 216:6032 217:2177 218:874 219:576 220:1825 221:1006 222:972 223:1393 End of report From asr at latency.net Sat Nov 3 02:39:42 2018 From: asr at latency.net (Adam Rothschild) Date: Fri, 2 Nov 2018 22:39:42 -0400 Subject: Brocade SLX Internet Edge In-Reply-To: References: Message-ID: I have no horse in this race, however one need only look at the NYIIX outages list to see how well the Brocade/Extreme SLX platform works on at-scale service provider networks... On Thu, Nov 1, 2018 at 2:55 PM Blake Hudson wrote: > > > Chris Welti wrote on 11/1/2018 10:03 AM: > > Nicolas Fevrier has a very detailed blog post on how Cisco handles the prefixes on their Broadcom Jericho based NCS 5500 gear. > > https://xrdocs.io/cloud-scale-networking/tutorials/2017-08-03-understanding-ncs5500-resources-s01e02/ > > > > I'm pretty sure the principle is more or less the same for the Jericho based platforms on Arista and Extreme. > > > > Best regards, > > Chris > > I love the nitty gritty detail in this author's post and I'm glad he > concludes by stating clearly that while the base card (spec sheet says: > "On-chip tables for 256K IPv4 or 64K IPv6 routes" and "On-chip tables > for 786K IPv4 host routes, MAC, and labels") can actually hold a full > BGP table today when configured appropriately, Cisco still recommends > the scale cards for that application (spec sheet says: "FIB scale up 2M > IPv4 or 512K IPv6 routes" and "On-chip tables for 786K IPv4 host routes, > MAC, and labels"). > > I do have to wonder about the internal expansion of each /23 route into > two /24 routes in their FIB algorithm, as I would have thought Cisco > would have attempted to go the opposite way, but I'm sure Cisco has > their reasons. From sean at donelan.com Sun Nov 4 14:31:37 2018 From: sean at donelan.com (Sean Donelan) Date: Sun, 4 Nov 2018 09:31:37 -0500 (EST) Subject: Super typhoon Yutu strikes U.S. territories of Guam and CNMI In-Reply-To: References: Message-ID: 1 confirmed fatality (unchanged) The island of Rota (relatively small) has all services restored. Ssipsn (the largest) and Tinian still have service outages. Saipan: 6 of 9 power feeders offline; 29 generators installed 12 of 19 gas stations operational; 3 on line power Cellular service is 61% operational (37 of 60 towers operating) cell service remains intermittent Exchange office operating with 96 of backup power, inter-island trunks in service. Tinian: 4 of 4 power feeders offline; 3 generators installed 1 of 2 gas stations operational on generator power Cellular service is 33% operational (3 of 7 towers operating) Rota: All cellular sites operational; 4 on generator power Airports: Restricted to humanitarian relief only (Saipan and Tinian); Saipan mobile Air Traffic Control tower site is unsuitable, assessments for alternative site/power requirements ongoing From tore at fud.no Mon Nov 5 08:54:08 2018 From: tore at fud.no (Tore Anderson) Date: Mon, 5 Nov 2018 09:54:08 +0100 Subject: =?UTF-8?Q?Re=3a_China_=e2=80=99s_Maxim_=e2=80=93_Leave_No_Access_Po?= =?UTF-8?Q?int_Unexploited=3a_The_Hidden_Story_of_China_Telecom=e2=80=99_s_B?= =?UTF-8?Q?GP_Hijacking?= In-Reply-To: References: Message-ID: <45291847-3736-f676-a494-482b6b4c26e7@fud.no> * Harley H > Curious to hear others' thoughts on this.  > https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca > > This paper presents the view that several BGP hijacks performed by China Telecom had malicious intent. The incidents are: > * Canada to Korea - 2016 > * US to Italy - Oct 2016 > * Scandinavia to Japan - April-May 2017 > * Italy to Thailand - April-July 2017 > > The authors claim this is enabled by China Telecom's presence in North America. Hi, I looked a bit into the Scandinavia to Japan claim last week for a Norwegian journalist, who obviously found this rather sensational claim very intriguing. The article (Norwegian, but Google Translate does a decent job) is found at https://www.digi.no/artikler/internettrafikk-fra-norge-og-sverige-ble-kapret-og-omdirigert-til-kina/449797?key=vS1EOiG1 in case you're interested. >From what I can tell from looking at routeviews data from the period, what happened was that SK Broadband (AS9318) was leaking a bunch of routes to China Telecom (AS4134). The leak included the transit routes from SKB's upstream Verizon (AS703) and customers of theirs in turn, including well- known organisations such as Bloomberg (AS10361) and Time Warner (AS36032), which I suppose might be the ones the paper is referring to. The routes in question then propagated from CT to Telia Carrier (AS1299), probably in North America somewhere. Scandinavia is TC's home turf, it makes sense that the detour via CT was easily observed from here. If you want to see for yourself, look for «1299 4134 9318 703» in http://archive.routeviews.org/route-views.linx/bgpdata/2017.04/RIBS/rib.20170430.2200.bz2 Anyway, in my opinion the data for this particular incident (I haven't looked into the other three) does not indicate foul play on CT's behalf, but rather a pretty standard leak by SKB followed by sloppy filtering by CT and TC both. Tore From mehmet at akcin.net Tue Nov 6 16:42:14 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 6 Nov 2018 08:42:14 -0800 Subject: Network Atlas : Help wanted In-Reply-To: References: Message-ID: Hello everyone. Another exciting update to share, the demo which is 20-25x faster loading times globally (thank you Cloud) with a lot more features is now reachable at https://www.networkatlas.org/ - this is the most important upgrade we have released so far! What is coming up next? Well another very exciting feature, self service portal. Are you operator of a fibre network? you can simply put the KMZs and map will show. This should enable us to give you all an amazing ability to grow the map to become much bigger than any single person/company can manage ;) You are going to love what we have been building for you! Join our slack to find out more and help us https://join.slack.com/t/kapany/shared_invite/enQtNDUwOTIzMDEwODM4LWE5NjNmOWRkMmQxYmYzYWU1YmI0ZmEwNWVlODllY2U1MGU5OTVhZDk4YjA1ZmFiN2VhYWI5ZWUyMGQ0YjU0OTc On Wed, Oct 31, 2018 at 9:06 AM Mehmet Akcin wrote: > There were many requests for screenshots and I wanted to share it with > everyone here. > > thank you everyone for all suggestions and help. > > https://drive.google.com/open?id=1JsV7QRaWkzj9W3oEwJe7Qm-vqwXjOdu3 > > > > On Wed, Oct 24, 2018 at 12:44 PM Mehmet Akcin wrote: > >> Hello there, >> >> I wanted to give you all an update on Network Atlas >> http://www.networkatlas.org as we started loading terrestrial links to >> our system, we have ran into some scale issues but we are working thru this >> as we speak. >> >> We are currently looking for people who can help with providing us KMZs >> which are publicly available for as many as terrestrial routes possible for >> us to stress test our newly designed more scalable backend. >> >> If you are able to assist please visit our GitHub repository >> https://github.com/networkatlas/v1/tree/master/Routes and feel free to >> send me links of the KMZs and I will put them all in this repository for >> others to easily access and use. >> >> We also have a slack channel if you are interested in joining you can >> click here https://join.slack >> .com/t/kapany/shared_invite/enQtNDQ1NTkxMzI0NjEyLWUzYWM3YjBjODJmNmYzMjYwZmM4MzFlZjg2MWNjMDUzZGZjMzViNDk0Njc1OTViZmNhMWIxZThiNDBkNWU0YTA >> >> if you want to contribute to project in any other way (hosting, software >> development, etc.. please contact me directly..) >> >> thank you everyone and we look forward to making our next update in >> upcoming weeks. >> >> Mehmet >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Tue Nov 6 17:37:25 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 6 Nov 2018 11:37:25 -0600 (CST) Subject: Switch with high ACL capacity Message-ID: <1204001989.195521.1541525845402.JavaMail.zimbra@ics-il.net> I am looking for recommendations as to a 10G or 40G switch that has the ability to hold a large number of entries in ACLs. Preferred if I can get them there via the BGP flow spec, but some sort of API or even just brute force on the console would be good enough. Used or even end of life is fine. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP From Pratik.Lotia at charter.com Tue Nov 6 18:29:15 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Tue, 6 Nov 2018 18:29:15 +0000 Subject: Switch with high ACL capacity In-Reply-To: <1204001989.195521.1541525845402.JavaMail.zimbra@ics-il.net> References: <1204001989.195521.1541525845402.JavaMail.zimbra@ics-il.net> Message-ID: <0F92049D-1BB8-42C6-9B40-7837EF7017D4@charter.com> Mike, Can you shed some light on the use case? Looks like you are confusing ACLs and BGP Flowspec. ACLs and Flowspec rules are similar in some ways but they have a different use case. ACLs cannot be configured using Flowspec announcements. Flowspec can be loosely explained as 'Routing based on L4 rules' (there's a lot more to it than just L4). I doubt if a there is a Switch which can hold a large number of Flowspec entries. ~Pratik Lotia “Improvement begins with I.” On 11/6/18, 10:39, "NANOG on behalf of Mike Hammett" wrote: I am looking for recommendations as to a 10G or 40G switch that has the ability to hold a large number of entries in ACLs. Preferred if I can get them there via the BGP flow spec, but some sort of API or even just brute force on the console would be good enough. Used or even end of life is fine. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP 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 alfie at fdx.services Tue Nov 6 18:56:55 2018 From: alfie at fdx.services (Alfie Pates) Date: Tue, 06 Nov 2018 18:56:55 +0000 Subject: Network Atlas : Help wanted In-Reply-To: References: Message-ID: <1541530615.4002295.1567794072.0C629895@webmail.messagingengine.com> Looks interesting, I'll have to have a play! One thing; Slack's a little modern for a lot of us, and perhaps unsuitable for people who don't have as much attention to commit - perhaps a mailing list would also be appropriate? ~ a at fdx -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Nov 6 19:02:17 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 6 Nov 2018 11:02:17 -0800 Subject: Network Atlas : Help wanted In-Reply-To: <1541530615.4002295.1567794072.0C629895@webmail.messagingengine.com> References: <1541530615.4002295.1567794072.0C629895@webmail.messagingengine.com> Message-ID: We have a mailing list but discussions happen mostly on slack channel. https://groups.google.com/a/networkatlas.org/forum/m/#!forum/discuss On Tue, Nov 6, 2018 at 10:57 AM Alfie Pates wrote: > Looks interesting, I'll have to have a play! > > One thing; Slack's a little modern for a lot of us, and perhaps unsuitable > for people who don't have as much attention to commit - perhaps a mailing > list would also be appropriate? > > ~ a at fdx > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Tue Nov 6 19:46:40 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 6 Nov 2018 13:46:40 -0600 (CST) Subject: Switch with high ACL capacity In-Reply-To: <0F92049D-1BB8-42C6-9B40-7837EF7017D4@charter.com> References: <1204001989.195521.1541525845402.JavaMail.zimbra@ics-il.net> <0F92049D-1BB8-42C6-9B40-7837EF7017D4@charter.com> Message-ID: <1602337607.196367.1541533600953.JavaMail.zimbra@ics-il.net> The intent is to see if I can construct a poor man's DDOS scrubber. There are low cost systems out there for the detection, but they just trigger something else to do the work. Obviously there is black hole routing, but I'm looking for something with a bit more finesse. If I need to get a switch anyway, might as well try to take advantage of it for other uses. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP ----- Original Message ----- From: Lotia, Pratik M To: Mike Hammett , 'nanog list' Sent: Tue, 06 Nov 2018 12:29:15 -0600 (CST) Subject: Re: Switch with high ACL capacity Mike, Can you shed some light on the use case? Looks like you are confusing ACLs and BGP Flowspec. ACLs and Flowspec rules are similar in some ways but they have a different use case. ACLs cannot be configured using Flowspec announcements. Flowspec can be loosely explained as 'Routing based on L4 rules' (there's a lot more to it than just L4). I doubt if a there is a Switch which can hold a large number of Flowspec entries. ~Pratik Lotia “Improvement begins with I.” On 11/6/18, 10:39, "NANOG on behalf of Mike Hammett" wrote: I am looking for recommendations as to a 10G or 40G switch that has the ability to hold a large number of entries in ACLs. Preferred if I can get them there via the BGP flow spec, but some sort of API or even just brute force on the console would be good enough. Used or even end of life is fine. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP 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 jackson.tim at gmail.com Tue Nov 6 19:51:41 2018 From: jackson.tim at gmail.com (Tim Jackson) Date: Tue, 6 Nov 2018 13:51:41 -0600 Subject: Switch with high ACL capacity In-Reply-To: <1602337607.196367.1541533600953.JavaMail.zimbra@ics-il.net> References: <1204001989.195521.1541525845402.JavaMail.zimbra@ics-il.net> <0F92049D-1BB8-42C6-9B40-7837EF7017D4@charter.com> <1602337607.196367.1541533600953.JavaMail.zimbra@ics-il.net> Message-ID: Juniper QFX10000(including 100002) supports ~64k ACL entries + FlowSpec -- Tim On Tue, Nov 6, 2018 at 1:49 PM Mike Hammett wrote: > The intent is to see if I can construct a poor man's DDOS scrubber. There > are low cost systems out there for the detection, but they just trigger > something else to do the work. Obviously there is black hole routing, but > I'm looking for something with a bit more finesse. > > If I need to get a switch anyway, might as well try to take advantage of > it for other uses. > > -----Mike HammettIntelligent Computing SolutionsMidwest Internet > ExchangeThe Brothers WISP > > ----- Original Message ----- > From: Lotia, Pratik M > To: Mike Hammett , 'nanog list' > Sent: Tue, 06 Nov 2018 12:29:15 -0600 (CST) > Subject: Re: Switch with high ACL capacity > > Mike, > > Can you shed some light on the use case? Looks like you are confusing ACLs > and BGP Flowspec. ACLs and Flowspec rules are similar in some ways but they > have a different use case. ACLs cannot be configured using Flowspec > announcements. Flowspec can be loosely explained as 'Routing based on L4 > rules' (there's a lot more to it than just L4). I doubt if a there is a > Switch which can hold a large number of Flowspec entries. > > > ~Pratik Lotia > “Improvement begins with I.” > > > On 11/6/18, 10:39, "NANOG on behalf of Mike Hammett" < > nanog-bounces at nanog.org on behalf of nanog at ics-il.net> wrote: > > I am looking for recommendations as to a 10G or 40G switch that has > the ability to hold a large number of entries in ACLs. > > Preferred if I can get them there via the BGP flow spec, but some sort > of API or even just brute force on the console would be good enough. > > Used or even end of life is fine. > > -----Mike HammettIntelligent Computing SolutionsMidwest Internet > ExchangeThe Brothers WISP > > > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended > solely for the addressee(s) and may contain confidential and/or legally > privileged information. If you are not the intended recipient of this > message or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message > and any attachments. If you are not the intended recipient, you are > notified that any use, dissemination, distribution, copying, or storage of > this message or any attachment is strictly prohibited. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ryan.Hamel at quadranet.com Tue Nov 6 19:52:38 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Tue, 6 Nov 2018 19:52:38 +0000 Subject: Switch with high ACL capacity In-Reply-To: <1602337607.196367.1541533600953.JavaMail.zimbra@ics-il.net> References: <1204001989.195521.1541525845402.JavaMail.zimbra@ics-il.net> <0F92049D-1BB8-42C6-9B40-7837EF7017D4@charter.com> <1602337607.196367.1541533600953.JavaMail.zimbra@ics-il.net> Message-ID: Mike, Are you sure you have enough inbound capacity to setup such a thing? Do you have RTBH setup for the final means of killing the attack? If you could get another set of circuits to feed this switch from your same providers, and they accept more specific announcements, you could use this to swing /32's or /128's to said dedicated links so it won't affect your clients traffic. -- Ryan Hamel Network Administrator ryan.hamel at quadranet.com | +1 (888) 578-2372 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud -----Original Message----- From: NANOG On Behalf Of Mike Hammett Sent: Tuesday, November 06, 2018 11:47 AM To: Lotia, Pratik M Cc: 'nanog list' Subject: Re: Switch with high ACL capacity The intent is to see if I can construct a poor man's DDOS scrubber. There are low cost systems out there for the detection, but they just trigger something else to do the work. Obviously there is black hole routing, but I'm looking for something with a bit more finesse. If I need to get a switch anyway, might as well try to take advantage of it for other uses. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP ----- Original Message ----- From: Lotia, Pratik M To: Mike Hammett , 'nanog list' Sent: Tue, 06 Nov 2018 12:29:15 -0600 (CST) Subject: Re: Switch with high ACL capacity Mike, Can you shed some light on the use case? Looks like you are confusing ACLs and BGP Flowspec. ACLs and Flowspec rules are similar in some ways but they have a different use case. ACLs cannot be configured using Flowspec announcements. Flowspec can be loosely explained as 'Routing based on L4 rules' (there's a lot more to it than just L4). I doubt if a there is a Switch which can hold a large number of Flowspec entries. ~Pratik Lotia “Improvement begins with I.” On 11/6/18, 10:39, "NANOG on behalf of Mike Hammett" wrote: I am looking for recommendations as to a 10G or 40G switch that has the ability to hold a large number of entries in ACLs. Preferred if I can get them there via the BGP flow spec, but some sort of API or even just brute force on the console would be good enough. Used or even end of life is fine. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP 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 Ryan.Hamel at quadranet.com Tue Nov 6 20:04:36 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Tue, 6 Nov 2018 20:04:36 +0000 Subject: Switch with high ACL capacity In-Reply-To: References: <1204001989.195521.1541525845402.JavaMail.zimbra@ics-il.net> <0F92049D-1BB8-42C6-9B40-7837EF7017D4@charter.com> <1602337607.196367.1541533600953.JavaMail.zimbra@ics-il.net> Message-ID: <7a70eb207351457bad6519c338709f23@LAX-MBX01.quadranet.local> I would see if you can get your upstream providers to apply rules to a dedicated interface upstream (drop NTP, memcache, LDAP, rate limit SSDP), and connect that to your switch, which would announce the /32’s or /128’s to pull the traffic over. You would of course have to announce the /24 or /48 through the carrier that has the filters in place to ensure they get all the traffic. After post processing the spoofed traffic, it should leave you with flooding to take care of. -- Ryan Hamel Network Administrator ryan.hamel at quadranet.com | +1 (888) 578-2372 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud From: NANOG On Behalf Of Tim Jackson Sent: Tuesday, November 06, 2018 11:52 AM To: nanog at ics-il.net Cc: nanog list Subject: Re: Switch with high ACL capacity Juniper QFX10000(including 100002) supports ~64k ACL entries + FlowSpec -- Tim On Tue, Nov 6, 2018 at 1:49 PM Mike Hammett > wrote: The intent is to see if I can construct a poor man's DDOS scrubber. There are low cost systems out there for the detection, but they just trigger something else to do the work. Obviously there is black hole routing, but I'm looking for something with a bit more finesse. If I need to get a switch anyway, might as well try to take advantage of it for other uses. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP ----- Original Message ----- From: Lotia, Pratik M > To: Mike Hammett >, 'nanog list' > Sent: Tue, 06 Nov 2018 12:29:15 -0600 (CST) Subject: Re: Switch with high ACL capacity Mike, Can you shed some light on the use case? Looks like you are confusing ACLs and BGP Flowspec. ACLs and Flowspec rules are similar in some ways but they have a different use case. ACLs cannot be configured using Flowspec announcements. Flowspec can be loosely explained as 'Routing based on L4 rules' (there's a lot more to it than just L4). I doubt if a there is a Switch which can hold a large number of Flowspec entries. ~Pratik Lotia “Improvement begins with I.” On 11/6/18, 10:39, "NANOG on behalf of Mike Hammett" on behalf of nanog at ics-il.net> wrote: I am looking for recommendations as to a 10G or 40G switch that has the ability to hold a large number of entries in ACLs. Preferred if I can get them there via the BGP flow spec, but some sort of API or even just brute force on the console would be good enough. Used or even end of life is fine. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Tue Nov 6 20:38:01 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 6 Nov 2018 14:38:01 -0600 (CST) Subject: Switch with high ACL capacity In-Reply-To: References: <1204001989.195521.1541525845402.JavaMail.zimbra@ics-il.net> <0F92049D-1BB8-42C6-9B40-7837EF7017D4@charter.com> <1602337607.196367.1541533600953.JavaMail.zimbra@ics-il.net> Message-ID: <1463858470.196647.1541536681420.JavaMail.zimbra@ics-il.net> If the DDoS exceeds capacity, I simply resort to the RTBH. Until then, if I can handle it more delicately, then great. If I can handle it by adjusting routing policy (shy of blackholing) or by dropping traffic selectively until then, I deliver a better experience. Eyeball networks can handle DDoSes a bit differently than content guys because most of our traffic is on just a handful of ASNs on a few ports. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP ----- Original Message ----- From: Ryan Hamel To: Mike Hammett , Lotia, Pratik M Cc: 'nanog list' Sent: Tue, 06 Nov 2018 13:52:38 -0600 (CST) Subject: RE: Switch with high ACL capacity Mike, Are you sure you have enough inbound capacity to setup such a thing? Do you have RTBH setup for the final means of killing the attack? If you could get another set of circuits to feed this switch from your same providers, and they accept more specific announcements, you could use this to swing /32's or /128's to said dedicated links so it won't affect your clients traffic. -- Ryan Hamel Network Administrator ryan.hamel at quadranet.com | +1 (888) 578-2372 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud -----Original Message----- From: NANOG On Behalf Of Mike Hammett Sent: Tuesday, November 06, 2018 11:47 AM To: Lotia, Pratik M Cc: 'nanog list' Subject: Re: Switch with high ACL capacity The intent is to see if I can construct a poor man's DDOS scrubber. There are low cost systems out there for the detection, but they just trigger something else to do the work. Obviously there is black hole routing, but I'm looking for something with a bit more finesse. If I need to get a switch anyway, might as well try to take advantage of it for other uses. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP ----- Original Message ----- From: Lotia, Pratik M To: Mike Hammett , 'nanog list' Sent: Tue, 06 Nov 2018 12:29:15 -0600 (CST) Subject: Re: Switch with high ACL capacity Mike, Can you shed some light on the use case? Looks like you are confusing ACLs and BGP Flowspec. ACLs and Flowspec rules are similar in some ways but they have a different use case. ACLs cannot be configured using Flowspec announcements. Flowspec can be loosely explained as 'Routing based on L4 rules' (there's a lot more to it than just L4). I doubt if a there is a Switch which can hold a large number of Flowspec entries. ~Pratik Lotia “Improvement begins with I.” On 11/6/18, 10:39, "NANOG on behalf of Mike Hammett" wrote: I am looking for recommendations as to a 10G or 40G switch that has the ability to hold a large number of entries in ACLs. Preferred if I can get them there via the BGP flow spec, but some sort of API or even just brute force on the console would be good enough. Used or even end of life is fine. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP 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 nanog at ics-il.net Tue Nov 6 20:38:46 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 6 Nov 2018 14:38:46 -0600 (CST) Subject: Switch with high ACL capacity In-Reply-To: References: <1204001989.195521.1541525845402.JavaMail.zimbra@ics-il.net> <0F92049D-1BB8-42C6-9B40-7837EF7017D4@charter.com> <1602337607.196367.1541533600953.JavaMail.zimbra@ics-il.net> Message-ID: <1904886644.196648.1541536726541.JavaMail.zimbra@ics-il.net> Other than it completes the DDoS. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: Zach Puls To: Mike Hammett Cc: 'nanog list' Sent: Tue, 06 Nov 2018 13:55:22 -0600 (CST) Subject: RE: Switch with high ACL capacity Wouldn’t it be more beneficial to just have a low-cost system for detection, then trigger an RTBH community advertisement to your upstream(s)? Zach Puls Network Engineer | MEF-CECP KsFiberNet -----Original Message----- From: NANOG On Behalf Of Mike Hammett Sent: Tuesday, November 06, 2018 13:47 To: Lotia, Pratik M Cc: 'nanog list' Subject: Re: Switch with high ACL capacity The intent is to see if I can construct a poor man's DDOS scrubber. There are low cost systems out there for the detection, but they just trigger something else to do the work. Obviously there is black hole routing, but I'm looking for something with a bit more finesse. If I need to get a switch anyway, might as well try to take advantage of it for other uses. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP ----- Original Message ----- From: Lotia, Pratik M To: Mike Hammett , 'nanog list' Sent: Tue, 06 Nov 2018 12:29:15 -0600 (CST) Subject: Re: Switch with high ACL capacity Mike, Can you shed some light on the use case? Looks like you are confusing ACLs and BGP Flowspec. ACLs and Flowspec rules are similar in some ways but they have a different use case. ACLs cannot be configured using Flowspec announcements. Flowspec can be loosely explained as 'Routing based on L4 rules' (there's a lot more to it than just L4). I doubt if a there is a Switch which can hold a large number of Flowspec entries. ~Pratik Lotia “Improvement begins with I.” On 11/6/18, 10:39, "NANOG on behalf of Mike Hammett" wrote: I am looking for recommendations as to a 10G or 40G switch that has the ability to hold a large number of entries in ACLs. Preferred if I can get them there via the BGP flow spec, but some sort of API or even just brute force on the console would be good enough. Used or even end of life is fine. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP 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 nanog at ics-il.net Tue Nov 6 20:45:43 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 6 Nov 2018 14:45:43 -0600 (CST) Subject: Switch with high ACL capacity In-Reply-To: <7a70eb207351457bad6519c338709f23@LAX-MBX01.quadranet.local> References: <1204001989.195521.1541525845402.JavaMail.zimbra@ics-il.net> <0F92049D-1BB8-42C6-9B40-7837EF7017D4@charter.com> <1602337607.196367.1541533600953.JavaMail.zimbra@ics-il.net> <7a70eb207351457bad6519c338709f23@LAX-MBX01.quadranet.local> Message-ID: <1968662058.196668.1541537143919.JavaMail.zimbra@ics-il.net> *nods* The more ways of knocking down the low hanging fruit the better. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: Ryan Hamel To: Tim Jackson , nanog at ics-il.net Cc: nanog list Sent: Tue, 06 Nov 2018 14:04:36 -0600 (CST) Subject: RE: Switch with high ACL capacity I would see if you can get your upstream providers to apply rules to a dedicated interface upstream (drop NTP, memcache, LDAP, rate limit SSDP), and connect that to your switch, which would announce the /32’s or /128’s to pull the traffic over. You would of course have to announce the /24 or /48 through the carrier that has the filters in place to ensure they get all the traffic. After post processing the spoofed traffic, it should leave you with flooding to take care of. -- Ryan Hamel Network Administrator ryan.hamel at quadranet.com | +1 (888) 578-2372 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud From: NANOG On Behalf Of Tim Jackson Sent: Tuesday, November 06, 2018 11:52 AM To: nanog at ics-il.net Cc: nanog list Subject: Re: Switch with high ACL capacity Juniper QFX10000(including 100002) supports ~64k ACL entries + FlowSpec -- Tim On Tue, Nov 6, 2018 at 1:49 PM Mike Hammett > wrote: The intent is to see if I can construct a poor man's DDOS scrubber. There are low cost systems out there for the detection, but they just trigger something else to do the work. Obviously there is black hole routing, but I'm looking for something with a bit more finesse. If I need to get a switch anyway, might as well try to take advantage of it for other uses. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP ----- Original Message ----- From: Lotia, Pratik M > To: Mike Hammett >, 'nanog list' > Sent: Tue, 06 Nov 2018 12:29:15 -0600 (CST) Subject: Re: Switch with high ACL capacity Mike, Can you shed some light on the use case? Looks like you are confusing ACLs and BGP Flowspec. ACLs and Flowspec rules are similar in some ways but they have a different use case. ACLs cannot be configured using Flowspec announcements. Flowspec can be loosely explained as 'Routing based on L4 rules' (there's a lot more to it than just L4). I doubt if a there is a Switch which can hold a large number of Flowspec entries. ~Pratik Lotia “Improvement begins with I.” On 11/6/18, 10:39, "NANOG on behalf of Mike Hammett" on behalf of nanog at ics-il.net> wrote: I am looking for recommendations as to a 10G or 40G switch that has the ability to hold a large number of entries in ACLs. Preferred if I can get them there via the BGP flow spec, but some sort of API or even just brute force on the console would be good enough. Used or even end of life is fine. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP 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 alex at nlnetlabs.nl Wed Nov 7 08:30:12 2018 From: alex at nlnetlabs.nl (Alex Band) Date: Wed, 7 Nov 2018 15:30:12 +0700 Subject: Routinator 3000 and the RPKI project Message-ID: <34B58668-7EF0-41BE-A600-C0B377CB511A@nlnetlabs.nl> Hello all! Several months ago NLnet Labs committed to building a free open source RPKI toolset to help making BGP routing more secure. This project includes a Certificate Authority, allowing you to run a Delegated CA on your own systems as a child of one or more RIRs, a Publication Server that lets you publish RPKI material or let a third party do it on your behalf and lastly Relying Party software, in order to validate RPKI data and feed it to your routers. I want to give you a little update on where we are now. Since kicking off this project, RIPE NCC and NIC.br have graciously committed to funding these efforts, ensuring we can dedicate full time resources on this in the coming years. In the mean time, we’ve released (and then fixed :cough:) the first version of our Relying Party software. It’s designed to be super lean (as in, runs fine on a Pi Zero) and implements the basic set of functionality: fetching and validating RPKI data and exposing route origin attestations both as output (CSV, JSON, RPSL) and to routers via the RPKI-RTR protocol. We’re very much looking forward to your operational feedback, to ensure this package runs well in a wide variety of environments. Going forward, we’ll be focussing on monitoring for the next release. You can find the source code and further details on Github: https://github.com/NLnetLabs/routinator Cheers, Alex Band NLnet Labs From hank at efes.iucc.ac.il Wed Nov 7 09:18:26 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 7 Nov 2018 11:18:26 +0200 Subject: =?UTF-8?Q?Re:_China_=e2=80=99s_Maxim_=e2=80=93_Leave_No_Access_Poin?= =?UTF-8?Q?t_Unexploited:_The_Hidden_Story_of_China_Telecom=e2=80=99_s_BGP_H?= =?UTF-8?Q?ijacking?= In-Reply-To: <45291847-3736-f676-a494-482b6b4c26e7@fud.no> References: <45291847-3736-f676-a494-482b6b4c26e7@fud.no> Message-ID: On 05/11/2018 10:54, Tore Anderson wrote: > * Harley H > >> Curious to hear others' thoughts on this.  >> https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca >> >> This paper presents the view that several BGP hijacks performed by China Telecom had malicious intent. The incidents are: >> * Canada to Korea - 2016 >> * US to Italy - Oct 2016 >> * Scandinavia to Japan - April-May 2017 >> * Italy to Thailand - April-July 2017 >> >> The authors claim this is enabled by China Telecom's presence in North America. > Hi, > > I looked a bit into the Scandinavia to Japan claim last week for a Norwegian > journalist, who obviously found this rather sensational claim very intriguing. > The article (Norwegian, but Google Translate does a decent job) is found at > https://www.digi.no/artikler/internettrafikk-fra-norge-og-sverige-ble-kapret-og-omdirigert-til-kina/449797?key=vS1EOiG1 > in case you're interested. > > >From what I can tell from looking at routeviews data from the period, what > happened was that SK Broadband (AS9318) was leaking a bunch of routes to > China Telecom (AS4134). The leak included the transit routes from SKB's > upstream Verizon (AS703) and customers of theirs in turn, including well- > known organisations such as Bloomberg (AS10361) and Time Warner (AS36032), > which I suppose might be the ones the paper is referring to. > > The routes in question then propagated from CT to Telia Carrier (AS1299), > probably in North America somewhere. Scandinavia is TC's home turf, it > makes sense that the detour via CT was easily observed from here. > > If you want to see for yourself, look for «1299 4134 9318 703» in > http://archive.routeviews.org/route-views.linx/bgpdata/2017.04/RIBS/rib.20170430.2200.bz2 > > Anyway, in my opinion the data for this particular incident (I haven't > looked into the other three) does not indicate foul play on CT's behalf, > but rather a pretty standard leak by SKB followed by sloppy filtering > by CT and TC both. > > Tore > https://www.zdnet.com/article/oracle-confirms-china-telecom-internet-traffic-misdirections/ "But today, Doug Madory, Director of Oracle's Internet Analysis division (formerly Dyn), confirmed that China Telecom has, indeed, engaged in internet traffic "misdirection." "I don't intend to address the paper's claims around the motivations of these actions," said Madori. "However, there is truth to the assertion that China Telecom (whether intentionally or not) has misdirected internet traffic (including out of the United States) in recent years." "I know because I expended a great deal of effort to stop it in 2017," Madori said. He then goes on to detail several of China Telecom's BGP route "misdirections," most of which have involved hijacking US-to-US traffic and sending it via mainland China before returning it to the US." -Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Nov 8 09:11:18 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 8 Nov 2018 11:11:18 +0200 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <20181011193136.GA30057@cmadams.net> References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> Message-ID: <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> On 11/Oct/18 21:31, Chris Adams wrote: > Requiring an ID is also a violation of the merchant agreements, at least > for VISA and MasterCard (not sure about American Express), unless ID is > otherwise required by law (like for age-limited products). I've walked > out of stores that required an ID. It has always been curious to me how/why the U.S., with one of the largest economies in the world, still do most card-based transactions as a swipe in lieu of a PIN-based approach. In South Africa (and most of southern Africa), all banks make the use of PIN's mandatory, for all types of cards. With the rest of Africa using credit cards more recently, I imagine they are also PIN-based. Europe also use PIN's, as far as I have experienced. Asia-Pac was swipe-based for a long time when I lived there, but I know places like Malaysia and Singapore have started a major PIN-based transaction drive in the past 3 years. 3D Secure for the online version of the transaction also means your card number and CVV number are less susceptible to fraud via restaurants and the like. Of course, this is not fool-proof, as both the merchant and bank need to support and mandate this, which is not well-done at a global level. Mark. From ggm at algebras.org Thu Nov 8 09:16:36 2018 From: ggm at algebras.org (George Michaelson) Date: Thu, 8 Nov 2018 16:16:36 +0700 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> Message-ID: There are two parts of the problem. The first is the assumption of risk: the current model of operation in the US (like in other western economies) puts the onus of risk of misuse of the card on specific actors. When you change the basis from signature (fraud) to chip+pin (leak of knowledge) you have to change the legal basis. Remember, this is an economy where WRITING CHEQUES is still normal. Clearly, the legal basis of money transactions in the US is hugely complicated by savings and loan, credit unions, banks, state and federal law, taxes. We all have some of this worldwide, they have a LOT. Secondly, the cost basis. Who pays? In most of the world the regulator forced cost onto specific players because they could, and forced people to tool up because they could. But, the costs did have to get met. Some people paid more than others. In the US, for reasons not entirely unlike the first set, *making* people do things with cost incursion is remarkably difficult. Making the Walmart brothers re-fit every terminal, when they can go down to DC and buy votes to stop it happening, Making Bank of America spend money re-working its core finance models to suit online chip+pin when it can go down to Walmart and lean on the owners to go down to DC and buy votes... Seriously: Its not lack of clue. Its lack of intestinal political fortitude, and a very strange regulatory and federal/state model. On Thu, Nov 8, 2018 at 4:11 PM Mark Tinka wrote: > > > > On 11/Oct/18 21:31, Chris Adams wrote: > > > Requiring an ID is also a violation of the merchant agreements, at least > > for VISA and MasterCard (not sure about American Express), unless ID is > > otherwise required by law (like for age-limited products). I've walked > > out of stores that required an ID. > > It has always been curious to me how/why the U.S., with one of the > largest economies in the world, still do most card-based transactions as > a swipe in lieu of a PIN-based approach. > > In South Africa (and most of southern Africa), all banks make the use of > PIN's mandatory, for all types of cards. With the rest of Africa using > credit cards more recently, I imagine they are also PIN-based. > > Europe also use PIN's, as far as I have experienced. > > Asia-Pac was swipe-based for a long time when I lived there, but I know > places like Malaysia and Singapore have started a major PIN-based > transaction drive in the past 3 years. > > 3D Secure for the online version of the transaction also means your card > number and CVV number are less susceptible to fraud via restaurants and > the like. Of course, this is not fool-proof, as both the merchant and > bank need to support and mandate this, which is not well-done at a > global level. > > Mark. > > From mark.tinka at seacom.mu Thu Nov 8 09:34:33 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 8 Nov 2018 11:34:33 +0200 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> Message-ID: <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> On 8/Nov/18 11:16, George Michaelson wrote: > There are two parts of the problem. The first is the assumption of > risk: the current model of operation in the US (like in other western > economies) puts the onus of risk of misuse of the card on specific > actors. When you change the basis from signature (fraud) to chip+pin > (leak of knowledge) you have to change the legal basis. Remember, this > is an economy where WRITING CHEQUES is still normal. Clearly, the > legal basis of money transactions in the US is hugely complicated by > savings and loan, credit unions, banks, state and federal law, taxes. > We all have some of this worldwide, they have a LOT. > > Secondly, the cost basis. Who pays? In most of the world the regulator > forced cost onto specific players because they could, and forced > people to tool up because they could. But, the costs did have to get > met. Some people paid more than others. In the US, for reasons not > entirely unlike the first set, *making* people do things with cost > incursion is remarkably difficult. Making the Walmart brothers re-fit > every terminal, when they can go down to DC and buy votes to stop it > happening, Making Bank of America spend money re-working its core > finance models to suit online chip+pin when it can go down to Walmart > and lean on the owners to go down to DC and buy votes... > > Seriously: Its not lack of clue. Its lack of intestinal political > fortitude, and a very strange regulatory and federal/state model. Shame, but I can see how this makes sense as to why things are the way they are. Speaking of "cost" as a motivator, in South Africa, most of the banks are now using extra fees as a way to force users to do their banking online (phone, laptop, app, e.t.c.). If you want to walk into a bank to deposit money, withdraw money, make a transfer, e.t.c., you pay for that service over and above, while the process costs you zero (0) when done online. This has led to banks now renovating banking halls into where there was once 23 tellers, you now have 1 service usher, 1 teller, 2 support agents and 20 self-service computers. I hope the U.S. does catch-up. If we were swipe-based here, we'd all be broke :-). I know a number of major merchants in the U.S. now use PIN's, and I always stick to those when I travel there. Mark. From jw at nuclearfallout.net Thu Nov 8 20:44:24 2018 From: jw at nuclearfallout.net (John Weekes) Date: Thu, 8 Nov 2018 12:44:24 -0800 Subject: Amazon network engineering contact? re: DDoS traffic Message-ID: We've been seeing significant attack activity from Amazon over the last two months, involving apparently compromised instances that commonly send 1-10G of traffic per source and together generate Nx10G of total traffic. Even when our overall upstream capacity exceeds an attack's overall size, the nature of load-balancing over multiple 10G upstream links means that an individual link can be saturated by multiple large flows, forcing our systems to null-route the target to limit impact. We've sent an abuse notification about every traffic source to Amazon, and specific sources seem to stop their involvement over time (suggesting that abuse teams are following up on them), but there is an endless parade of new attackers, and each source participates in many damaging attacks before it is shut down. Is there anyone at Amazon who can help with an engineering solution in terms of programmatically detecting and rate-limiting attack traffic sources, to our networks or overall? Or applying the kludge of a rate-limit for all Amazon traffic to our networks? Or working with us on some other option? At least one other large cloud provider has an automatic rate-limiting system in place that is effective in reducing the damage from repeat high-volume attacks. Emails to the Amazon NOC, peering contacts (since that would be another possible solution), and abuse department have not connected me with anyone. Thanks, John From jw at nuclearfallout.net Thu Nov 8 21:02:38 2018 From: jw at nuclearfallout.net (John Weekes) Date: Thu, 8 Nov 2018 13:02:38 -0800 Subject: Amazon network engineering contact? re: DDoS traffic In-Reply-To: References: Message-ID: Zach, Yes, RTBH is used to distribute the null-routes that I mentioned. Unfortunately, even brief saturation events lasting just 5-10 seconds (a typical amount of time to detect the loss, issue the null-route, and see the traffic start to fall off as it is distributed upstream) can cause real damage to those customers who are sensitive to latency and packet loss. So while null-routes limit the duration of the impact, they can't eliminate it entirely. And, of course, the actual target of the attack -- the now-null-routed IP address -- becomes unreachable, which was presumably the goal of the attacker. -John On 11/8/2018 12:54 PM, Zach Puls wrote: > No idea about an Amazon abuse contact, but do you have RTBH communities enabled with your upstream provider(s)? As a general practice, when you detect a (D)DoS attack in progress, it would help to automatically advertise that prefix to your upstream(s) with the black-hole community. This would at least help mitigate the effects of the attacks when they do occur, even if they come from a different source than AWS. > > Thanks, > > Zach Puls > Network Engineer | MEF-CECP > KsFiberNet > > -----Original Message----- > From: NANOG On Behalf Of John Weekes > Sent: Thursday, November 08, 2018 14:44 > To: nanog at nanog.org > Subject: Amazon network engineering contact? re: DDoS traffic > > We've been seeing significant attack activity from Amazon over the last two months, involving apparently compromised instances that commonly send 1-10G of traffic per source and together generate Nx10G of total traffic. Even when our overall upstream capacity exceeds an attack's overall size, the nature of load-balancing over multiple 10G upstream links means that an individual link can be saturated by multiple large flows, forcing our systems to null-route the target to limit impact. > > We've sent an abuse notification about every traffic source to Amazon, and specific sources seem to stop their involvement over time (suggesting that abuse teams are following up on them), but there is an endless parade of new attackers, and each source participates in many damaging attacks before it is shut down. > > Is there anyone at Amazon who can help with an engineering solution in terms of programmatically detecting and rate-limiting attack traffic sources, to our networks or overall? Or applying the kludge of a rate-limit for all Amazon traffic to our networks? Or working with us on some other option? > > At least one other large cloud provider has an automatic rate-limiting system in place that is effective in reducing the damage from repeat high-volume attacks. > > Emails to the Amazon NOC, peering contacts (since that would be another possible solution), and abuse department have not connected me with anyone. > > Thanks, > John > From sc at ottie.org Thu Nov 8 21:24:30 2018 From: sc at ottie.org (Scott Christopher) Date: Thu, 08 Nov 2018 21:24:30 +0000 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> Message-ID: <1541712270.3007578.1570595888.001B165F@webmail.messagingengine.com> Mark Tinka wrote: > I hope the U.S. does catch-up. If we were swipe-based here, we'd all be > broke :-). I know a number of major merchants in the U.S. now use PIN's, > and I always stick to those when I travel there. In the U.S., pin codes are required for EFTPOS transactions (called debit) over interbank networks like Pulse, STAR, etc Swipe-and-sign (and now just swipe for small amounts) is for Visa, Mastercard, Discover transactions (called credit) Skimming and card fraud is actually uncommon in the U.S. these days, and the police are very effective at combating it. It's just cheaper for the industry to eat fraud losses than to "upgrade" systems. The transition to chip-based cards was a debacle. -- S.C. From jw at nuclearfallout.net Thu Nov 8 21:26:42 2018 From: jw at nuclearfallout.net (John) Date: Thu, 8 Nov 2018 13:26:42 -0800 Subject: Amazon network engineering contact? re: DDoS traffic In-Reply-To: References: Message-ID: <0a497723-1dd4-5d79-e10f-54ad78654644@nuclearfallout.net> Zach, As mentioned before, I am open to peering (where possible) but have not received a response. My goal is to connect with someone at Amazon and work with them on a technical solution, which is why I posted asking for that here. Various factors mean that we can't just upgrade our way out of this one, and manual whac-a-mole on the sources has shown to have limited use. These attacks also impact Amazon and the networks in between the sources and targets, and they take time to handle by the abuse teams, so there are good reasons to investigate them further and find better ways to mitigate or prevent them. -John On 11/8/2018 1:12 PM, Zach Puls wrote: > Makes sense, that's understandable. Do you peer with AWS? If not, maybe opening up a peering agreement will give you a better contact, and a bit more pull when attacks occur? I know someone with a peering agreement with AWS, and they have been able to get resolutions fairly quickly when issues arise. > > Other than that, I'm not sure of a solution other than more IP transit. > > Thanks, > > Zach Puls > Network Engineer | MEF-CECP > KsFiberNet > > -----Original Message----- > From: John Weekes > Sent: Thursday, November 08, 2018 15:03 > To: Zach Puls > Cc: nanog at nanog.org > Subject: Re: Amazon network engineering contact? re: DDoS traffic > > Zach, > > Yes, RTBH is used to distribute the null-routes that I mentioned. > > Unfortunately, even brief saturation events lasting just 5-10 seconds (a typical amount of time to detect the loss, issue the null-route, and see the traffic start to fall off as it is distributed upstream) can cause real damage to those customers who are sensitive to latency and packet loss. So while null-routes limit the duration of the impact, they can't eliminate it entirely. And, of course, the actual target of the attack > -- the now-null-routed IP address -- becomes unreachable, which was presumably the goal of the attacker. > > -John > > On 11/8/2018 12:54 PM, Zach Puls wrote: >> No idea about an Amazon abuse contact, but do you have RTBH communities enabled with your upstream provider(s)? As a general practice, when you detect a (D)DoS attack in progress, it would help to automatically advertise that prefix to your upstream(s) with the black-hole community. This would at least help mitigate the effects of the attacks when they do occur, even if they come from a different source than AWS. >> >> Thanks, >> >> Zach Puls >> Network Engineer | MEF-CECP >> KsFiberNet >> >> -----Original Message----- >> From: NANOG On Behalf Of John Weekes >> Sent: Thursday, November 08, 2018 14:44 >> To: nanog at nanog.org >> Subject: Amazon network engineering contact? re: DDoS traffic >> >> We've been seeing significant attack activity from Amazon over the last two months, involving apparently compromised instances that commonly send 1-10G of traffic per source and together generate Nx10G of total traffic. Even when our overall upstream capacity exceeds an attack's overall size, the nature of load-balancing over multiple 10G upstream links means that an individual link can be saturated by multiple large flows, forcing our systems to null-route the target to limit impact. >> >> We've sent an abuse notification about every traffic source to Amazon, and specific sources seem to stop their involvement over time (suggesting that abuse teams are following up on them), but there is an endless parade of new attackers, and each source participates in many damaging attacks before it is shut down. >> >> Is there anyone at Amazon who can help with an engineering solution in terms of programmatically detecting and rate-limiting attack traffic sources, to our networks or overall? Or applying the kludge of a rate-limit for all Amazon traffic to our networks? Or working with us on some other option? >> >> At least one other large cloud provider has an automatic rate-limiting system in place that is effective in reducing the damage from repeat high-volume attacks. >> >> Emails to the Amazon NOC, peering contacts (since that would be another possible solution), and abuse department have not connected me with anyone. >> >> Thanks, >> John >> > From sean at donelan.com Thu Nov 8 22:18:58 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 8 Nov 2018 17:18:58 -0500 (EST) Subject: FCC Launches Re-Examination of Wireless Resiliency Cooperative Framework In Light of Recent Hurricanes Message-ID: The public, first responders and other service providers can also submit comments to the FCC. https://www.fcc.gov/document/fcc-seeks-industry-input-review-wireless-resiliency-framework To that end, Chief Fowlkes’ letters ask wireless companies participating in the framework to summarize how it was used for all disaster events to which the framework applied. The letters request detailed lists of mutual aid and roaming agreements carriers have established with each other, as well as any instances where such agreements were modified, impeded, or even declined outright. The agency also asks for information as to each company’s implementation of industry best practices. From eric.kuhnke at gmail.com Thu Nov 8 23:53:27 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 8 Nov 2018 15:53:27 -0800 Subject: Amazon now controls 3.0.0.0/8 Message-ID: https://news.ycombinator.com/item?id=18407173 Quoting from the post: " Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. Previous owner was GE. Anecdotal reports across the Internet that AWS EIPs are now being assigned in that range. https://whois.arin.net/rest/net/NET-3-0-0-0-1.html https://whois.arin.net/rest/net/NET-3-128-0-0-1.html " -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Thu Nov 8 23:56:36 2018 From: job at instituut.net (Job Snijders) Date: Fri, 9 Nov 2018 00:56:36 +0100 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: On Fri, Nov 9, 2018 at 0:54 Eric Kuhnke wrote: > https://news.ycombinator.com/item?id=18407173 > > Quoting from the post: > > " > > Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. > > Previous owner was GE. > > Anecdotal reports across the Internet that AWS EIPs are now being assigned > in that range. > > https://whois.arin.net/rest/net/NET-3-0-0-0-1.html > > https://whois.arin.net/rest/net/NET-3-128-0-0-1.html > " > Seems ALTDB should delete the old AS 80 / GE IRR proxy route registration: http://irrexplorer.nlnog.net/search/3.0.0.0 Kind regards, Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merculiani at gmail.com Thu Nov 8 23:58:02 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Thu, 8 Nov 2018 17:58:02 -0600 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS is incoming. -Matt On Thu, Nov 8, 2018, 17:54 Eric Kuhnke https://news.ycombinator.com/item?id=18407173 > > Quoting from the post: > > " > > Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. > > Previous owner was GE. > > Anecdotal reports across the Internet that AWS EIPs are now being assigned > in that range. > > https://whois.arin.net/rest/net/NET-3-0-0-0-1.html > > https://whois.arin.net/rest/net/NET-3-128-0-0-1.html > " > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frnkblk at iname.com Fri Nov 9 00:06:00 2018 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 8 Nov 2018 18:06:00 -0600 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> Message-ID: <003601d477bf$ff1f7ea0$fd5e7be0$@iname.com> I have a low-cost/high interest rate account at one of the Canadian bank and each "assisted" transaction is $5. Frank -----Original Message----- From: NANOG On Behalf Of Mark Tinka Sent: Thursday, November 08, 2018 3:35 AM To: George Michaelson Cc: North American Network Operators' Group Subject: Re: CVV (was: Re: bloomberg on supermicro: sky is falling) References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> <003601d477bf$ff1f7ea0$fd5e7be0$@iname.com> Message-ID: This is a confusing and off-topic discussion with respect to network engineering. But for completeness: Payments systems are architected by fraud rates, not by isolated security requirements or engineering mandates, as i think most network engineers can understand. The fraud rates in the US for credit card transactions were historically very, very low and being a large jurisdiction with a single national law enforcement branch (the FBI) enforcement was effective. Compare this to Europe in the 1980s when credit cards were accepted very few places. This was for two reasons: 1) the fraud rates were much, much higher, which created chargebacks for merchants that they preferred not to eat; 2) trans-national enforcement was virtually nonexistent. interpol had ~zero time to deal with credit card fraud. so the best european fraud rings always operated from a different country than where they perpetrated the fraud. when chip-and-pin was introduced, the point was actually twofold: A) security B) shifting liability to the consumer somewhat famously, even after chip-and-pin was proven compromised, UK banks continued to make consumers liable for all fraudulent transactions that were 'pin used'. this was very, very good for the adoption of credit cards in europe but it was very, very bad for a few people. banks, as usual, didn't are and made some decent money. So why did the US get pin-and-signature? Target. International fraud rings finally got wise to the ripe opportunity that was the soft underbelly of the US economy and figured out ways to perpetrate massive, trans-national fraud in the US. and as soon as that happened, the US got chips. the signature-vs-pin part is mostly about the fact that there are *still* low rates of fraud here as tracked by chargeback rates and as a result there's no real need to pay the cost of support to set everyone up with a pin. and that's what security is always all about: cost tradeoffs. people in countries where everyone has a pin have eaten that cost already and had to because the fraud rates were high enough to justify it. people in the US do not have PINs that they know and setting those up costs money and maintaining people's access to them costs money. so if that's not worth it, it doesn't get done. nor should it. i generally find it amusing when people from other countries mock the US for not having PINs. this is just another way of saying "my country has high fraud rates and yours appears not to." :-) . you can see this in the comment below "If we were swipe-based here, we'd all be broke :-).". the payments systems are architected to minimize cost and maximize adoption and they are usually at (or moving towards) some locally optimal point. the US is no exception in that. now, the checking/chequing system is a whole other, embarrassing beast and mocking that one is just the correct thing to do. :-) anyway, let's talk about networks, no? cheers, t On Thu, Nov 8, 2018, 19:07 Frank Bulk I have a low-cost/high interest rate account at one of the Canadian bank > and each "assisted" transaction is $5. > > Frank > > -----Original Message----- > From: NANOG On Behalf Of Mark Tinka > Sent: Thursday, November 08, 2018 3:35 AM > To: George Michaelson > Cc: North American Network Operators' Group > Subject: Re: CVV (was: Re: bloomberg on supermicro: sky is falling) > > > Speaking of "cost" as a motivator, in South Africa, most of the banks > are now using extra fees as a way to force users to do their banking > online (phone, laptop, app, e.t.c.). If you want to walk into a bank to > deposit money, withdraw money, make a transfer, e.t.c., you pay for that > service over and above, while the process costs you zero (0) when done > online. This has led to banks now renovating banking halls into where > there was once 23 tellers, you now have 1 service usher, 1 teller, 2 > support agents and 20 self-service computers. > > I hope the U.S. does catch-up. If we were swipe-based here, we'd all be > broke :-). I know a number of major merchants in the U.S. now use PIN's, > and I always stick to those when I travel there. > > Mark. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jco at direwolf.com Fri Nov 9 00:44:08 2018 From: jco at direwolf.com (John Orthoefer) Date: Thu, 8 Nov 2018 19:44:08 -0500 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: I wish we could have used 4.4.4.4. Although at the time I suspect we would have used 4.4.4.[123]. Johno > On Nov 8, 2018, at 18:58, Matt Erculiani wrote: > > So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS is incoming. > > -Matt > >> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke > https://news.ycombinator.com/item?id=18407173 >> >> Quoting from the post: >> >> " >> >> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >> Previous owner was GE. >> >> Anecdotal reports across the Internet that AWS EIPs are now being assigned in that range. >> >> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >> >> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >> >> " >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Fri Nov 9 00:46:21 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 8 Nov 2018 16:46:21 -0800 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: 3.4.5.6/24 could be an interesting block to put easily memorable IP services in... On Thu, Nov 8, 2018 at 4:44 PM John Orthoefer wrote: > I wish we could have used 4.4.4.4. Although at the time I suspect we would > have used 4.4.4.[123]. > > Johno > > On Nov 8, 2018, at 18:58, Matt Erculiani wrote: > > So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS > is incoming. > > -Matt > > On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >> https://news.ycombinator.com/item?id=18407173 >> >> Quoting from the post: >> >> " >> >> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >> >> Previous owner was GE. >> >> Anecdotal reports across the Internet that AWS EIPs are now being >> assigned in that range. >> >> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >> >> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >> " >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From smeuse at mara.org Fri Nov 9 01:19:20 2018 From: smeuse at mara.org (Steve Meuse) Date: Thu, 8 Nov 2018 20:19:20 -0500 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: I think it was the dial modem team that beat us to 4.4.4.0/24? -Steve On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer wrote: > I wish we could have used 4.4.4.4. Although at the time I suspect we would > have used 4.4.4.[123]. > > Johno > > On Nov 8, 2018, at 18:58, Matt Erculiani wrote: > > So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS > is incoming. > > -Matt > > On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >> https://news.ycombinator.com/item?id=18407173 >> >> Quoting from the post: >> >> " >> >> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >> >> Previous owner was GE. >> >> Anecdotal reports across the Internet that AWS EIPs are now being >> assigned in that range. >> >> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >> >> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >> " >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddunder at gmail.com Fri Nov 9 01:30:10 2018 From: toddunder at gmail.com (Todd Underwood) Date: Thu, 8 Nov 2018 20:30:10 -0500 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: google used 4.4.4.4 for DNS in the past (2010, IIRC). t On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse wrote: > > I think it was the dial modem team that beat us to 4.4.4.0/24? > > -Steve > > On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer wrote: > >> I wish we could have used 4.4.4.4. Although at the time I suspect we >> would have used 4.4.4.[123]. >> >> Johno >> >> On Nov 8, 2018, at 18:58, Matt Erculiani wrote: >> >> So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS >> is incoming. >> >> -Matt >> >> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke > >>> https://news.ycombinator.com/item?id=18407173 >>> >>> Quoting from the post: >>> >>> " >>> >>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >>> >>> Previous owner was GE. >>> >>> Anecdotal reports across the Internet that AWS EIPs are now being >>> assigned in that range. >>> >>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >>> >>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >>> " >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Fri Nov 9 01:40:29 2018 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 8 Nov 2018 20:40:29 -0500 Subject: Amazon network engineering contact? re: DDoS traffic In-Reply-To: <0a497723-1dd4-5d79-e10f-54ad78654644@nuclearfallout.net> References: <0a497723-1dd4-5d79-e10f-54ad78654644@nuclearfallout.net> Message-ID: Nobody should ever be forced to peer to get someone to address abusive traffic originating from networks under their control. On Thu, Nov 8, 2018 at 4:29 PM John wrote: > Zach, > > As mentioned before, I am open to peering (where possible) but have not > received a response. > > My goal is to connect with someone at Amazon and work with them on a > technical solution, which is why I posted asking for that here. Various > factors mean that we can't just upgrade our way out of this one, and > manual whac-a-mole on the sources has shown to have limited use. > > These attacks also impact Amazon and the networks in between the sources > and targets, and they take time to handle by the abuse teams, so there > are good reasons to investigate them further and find better ways to > mitigate or prevent them. > > -John > > On 11/8/2018 1:12 PM, Zach Puls wrote: > > Makes sense, that's understandable. Do you peer with AWS? If not, maybe > opening up a peering agreement will give you a better contact, and a bit > more pull when attacks occur? I know someone with a peering agreement with > AWS, and they have been able to get resolutions fairly quickly when issues > arise. > > > > Other than that, I'm not sure of a solution other than more IP transit. > > > > Thanks, > > > > Zach Puls > > Network Engineer | MEF-CECP > > KsFiberNet > > > > -----Original Message----- > > From: John Weekes > > Sent: Thursday, November 08, 2018 15:03 > > To: Zach Puls > > Cc: nanog at nanog.org > > Subject: Re: Amazon network engineering contact? re: DDoS traffic > > > > Zach, > > > > Yes, RTBH is used to distribute the null-routes that I mentioned. > > > > Unfortunately, even brief saturation events lasting just 5-10 seconds (a > typical amount of time to detect the loss, issue the null-route, and see > the traffic start to fall off as it is distributed upstream) can cause real > damage to those customers who are sensitive to latency and packet loss. So > while null-routes limit the duration of the impact, they can't eliminate it > entirely. And, of course, the actual target of the attack > > -- the now-null-routed IP address -- becomes unreachable, which was > presumably the goal of the attacker. > > > > -John > > > > On 11/8/2018 12:54 PM, Zach Puls wrote: > >> No idea about an Amazon abuse contact, but do you have RTBH communities > enabled with your upstream provider(s)? As a general practice, when you > detect a (D)DoS attack in progress, it would help to automatically > advertise that prefix to your upstream(s) with the black-hole community. > This would at least help mitigate the effects of the attacks when they do > occur, even if they come from a different source than AWS. > >> > >> Thanks, > >> > >> Zach Puls > >> Network Engineer | MEF-CECP > >> KsFiberNet > >> > >> -----Original Message----- > >> From: NANOG On Behalf Of John Weekes > >> Sent: Thursday, November 08, 2018 14:44 > >> To: nanog at nanog.org > >> Subject: Amazon network engineering contact? re: DDoS traffic > >> > >> We've been seeing significant attack activity from Amazon over the last > two months, involving apparently compromised instances that commonly send > 1-10G of traffic per source and together generate Nx10G of total traffic. > Even when our overall upstream capacity exceeds an attack's overall size, > the nature of load-balancing over multiple 10G upstream links means that an > individual link can be saturated by multiple large flows, forcing our > systems to null-route the target to limit impact. > >> > >> We've sent an abuse notification about every traffic source to Amazon, > and specific sources seem to stop their involvement over time (suggesting > that abuse teams are following up on them), but there is an endless parade > of new attackers, and each source participates in many damaging attacks > before it is shut down. > >> > >> Is there anyone at Amazon who can help with an engineering solution in > terms of programmatically detecting and rate-limiting attack traffic > sources, to our networks or overall? Or applying the kludge of a rate-limit > for all Amazon traffic to our networks? Or working with us on some other > option? > >> > >> At least one other large cloud provider has an automatic rate-limiting > system in place that is effective in reducing the damage from repeat > high-volume attacks. > >> > >> Emails to the Amazon NOC, peering contacts (since that would be another > possible solution), and abuse department have not connected me with anyone. > >> > >> Thanks, > >> John > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Fri Nov 9 01:45:55 2018 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 8 Nov 2018 20:45:55 -0500 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: 4.0.0.0/8 has been GTE/Level3 forever. 4.2.2.1 - 6 have been L3 DNS as far back as I can remember. On Thu, Nov 8, 2018 at 8:32 PM Todd Underwood wrote: > google used 4.4.4.4 for DNS in the past (2010, IIRC). > > t > > On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse wrote: > >> >> I think it was the dial modem team that beat us to 4.4.4.0/24? >> >> -Steve >> >> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer wrote: >> >>> I wish we could have used 4.4.4.4. Although at the time I suspect we >>> would have used 4.4.4.[123]. >>> >>> Johno >>> >>> On Nov 8, 2018, at 18:58, Matt Erculiani wrote: >>> >>> So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS >>> is incoming. >>> >>> -Matt >>> >>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >> >>>> https://news.ycombinator.com/item?id=18407173 >>>> >>>> Quoting from the post: >>>> >>>> " >>>> >>>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >>>> >>>> Previous owner was GE. >>>> >>>> Anecdotal reports across the Internet that AWS EIPs are now being >>>> assigned in that range. >>>> >>>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >>>> >>>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >>>> " >>>> >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From royce at techsolvency.com Fri Nov 9 01:49:49 2018 From: royce at techsolvency.com (Royce Williams) Date: Thu, 8 Nov 2018 16:49:49 -0900 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: Obligatory list of all known same-quad servers and their DNS status - corrections welcome: https://gist.github.com/roycewilliams/6cb91ed94b88730321ca3076006229f1 If there is info about previous/historical use of these IPs, I'd like to find a way to incorporate that as well. -- Royce On Thu, Nov 8, 2018 at 4:31 PM Todd Underwood wrote: > google used 4.4.4.4 for DNS in the past (2010, IIRC). > > t > > On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse wrote: > >> >> I think it was the dial modem team that beat us to 4.4.4.0/24? >> >> -Steve >> >> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer wrote: >> >>> I wish we could have used 4.4.4.4. Although at the time I suspect we >>> would have used 4.4.4.[123]. >>> >>> Johno >>> >>> On Nov 8, 2018, at 18:58, Matt Erculiani wrote: >>> >>> So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS >>> is incoming. >>> >>> -Matt >>> >>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >> >>>> https://news.ycombinator.com/item?id=18407173 >>>> >>>> Quoting from the post: >>>> >>>> " >>>> >>>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >>>> >>>> Previous owner was GE. >>>> >>>> Anecdotal reports across the Internet that AWS EIPs are now being >>>> assigned in that range. >>>> >>>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >>>> >>>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >>>> " >>>> >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcorbe at hammerfiber.com Fri Nov 9 02:11:22 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Thu, 8 Nov 2018 21:11:22 -0500 Subject: Amazon network engineering contact? re: DDoS traffic In-Reply-To: References: <0a497723-1dd4-5d79-e10f-54ad78654644@nuclearfallout.net> Message-ID: <243AA473-971A-4E10-A8AA-ACFA4675D032@hammerfiber.com> at 8:40 PM, Tom Beecher wrote: > Nobody should ever be forced to peer to get someone to address abusive > traffic originating from networks under their control. > > Especially considering the fact that Amazon is just a bit selective about their peers. Though, the size of our border probably had a lot to do with the fact that we didn’t get a response the first time when we requested peering for our 10s of megabits of traffic, we none the less didn’t get a response the first time we tried. Not even a “go away until you have some traffic of significance.” In the end, we had to implore a back channel to get a peering session set up. From smeuse at mara.org Fri Nov 9 02:19:26 2018 From: smeuse at mara.org (Steve Meuse) Date: Thu, 8 Nov 2018 21:19:26 -0500 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: John Orthoefer and I (and dozens of other BBN folks on this list) both worked for BBNPlanet at the time that 4.2.2.1 and 4.2.2.2 were assigned. John was one of the folks who built and ran that system. So when he said "I wish we could have used 4.4.4.4" and my comment of "I think the dial modem folks beat us to..." was referring to the fact that when 4/8 was first being deployed on AS1 we started assigning blocks to various groups and they realized that 4.4.4.0/XX had already been delegated to another internal group (I think it was the dial group). On Thu, Nov 8, 2018 at 8:45 PM Tom Beecher wrote: > 4.0.0.0/8 has been GTE/Level3 forever. > > 4.2.2.1 - 6 have been L3 DNS as far back as I can remember. > > On Thu, Nov 8, 2018 at 8:32 PM Todd Underwood wrote: > >> google used 4.4.4.4 for DNS in the past (2010, IIRC). >> >> t >> >> On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse wrote: >> >>> >>> I think it was the dial modem team that beat us to 4.4.4.0/24? >>> >>> -Steve >>> >>> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer wrote: >>> >>>> I wish we could have used 4.4.4.4. Although at the time I suspect we >>>> would have used 4.4.4.[123]. >>>> >>>> Johno >>>> >>>> On Nov 8, 2018, at 18:58, Matt Erculiani wrote: >>>> >>>> So it looks like GE will be solvent for a few more years and 3.3.3.3 >>>> DNS is incoming. >>>> >>>> -Matt >>>> >>>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >>> >>>>> https://news.ycombinator.com/item?id=18407173 >>>>> >>>>> Quoting from the post: >>>>> >>>>> " >>>>> >>>>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >>>>> >>>>> Previous owner was GE. >>>>> >>>>> Anecdotal reports across the Internet that AWS EIPs are now being >>>>> assigned in that range. >>>>> >>>>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >>>>> >>>>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >>>>> " >>>>> >>>>> >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at tangledhelix.com Fri Nov 9 02:22:50 2018 From: dan at tangledhelix.com (Dan Lowe) Date: Thu, 08 Nov 2018 21:22:50 -0500 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: <1541730170.3039349.1570855456.30C2956B@webmail.messagingengine.com> Maybe Amazon will do something cool with 3.1.33.7 ... dan On Thu, Nov 8, 2018, at 8:30 PM, Todd Underwood wrote: > google used 4.4.4.4 for DNS in the past (2010, IIRC). > > t > > On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse wrote: >> >> I think it was the dial modem team that beat us to 4.4.4.0/24? >> >> -Steve >> >> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer >> wrote:>>> >>> I wish we could have used 4.4.4.4. Although at the time I suspect we >>> would have used 4.4.4.[123].>>> >>> Johno >>> >>> On Nov 8, 2018, at 18:58, Matt Erculiani >>> wrote:>>>> So it looks like GE will be solvent for a few more years and >>>> 3.3.3.3 DNS is incoming.>>>> >>>> -Matt >>>> >>>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >>> wrote:>>>>> https://news.ycombinator.com/item?id=18407173 >>>>> >>>>> Quoting from the post: >>>>> >>>>> " >>>>> >>>>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >>>>> Previous owner was GE. >>>>> Anecdotal reports across the Internet that AWS EIPs are now being >>>>> assigned in that range.>>>>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >>>>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >>>>> " >>>>> >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at spectrum.com.au Fri Nov 9 02:29:45 2018 From: matt at spectrum.com.au (Matt Perkins) Date: Fri, 9 Nov 2018 13:29:45 +1100 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: <1541730170.3039349.1570855456.30C2956B@webmail.messagingengine.com> References: <1541730170.3039349.1570855456.30C2956B@webmail.messagingengine.com> Message-ID: <262a0e86-408b-ed60-e4e2-3a380124f5f6@spectrum.com.au> 3.141.59.27  might be handy. Matt On 9/11/18 1:22 pm, Dan Lowe wrote: > Maybe Amazon will do something cool with 3.1.33.7 ... > > dan > > > On Thu, Nov 8, 2018, at 8:30 PM, Todd Underwood wrote: >> google used 4.4.4.4 for DNS in the past (2010, IIRC). >> >> t >> >> On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse > > wrote: >> >> >> I think it was the dial modem team that beat us to 4.4.4.0/24 >> ? >> >> -Steve >> >> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer > > wrote: >> >> >> I wish we could have used 4.4.4.4. Although at the time I >> suspect we would have used 4.4.4.[123]. >> >> Johno >> >> On Nov 8, 2018, at 18:58, Matt Erculiani >> > wrote: >>> So it looks like GE will be solvent for a few more years and >>> 3.3.3.3 DNS is incoming. >>> >>> -Matt >>> >>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >>> wrote: >>> >>> https://news.ycombinator.com/item?id=18407173 >>> >>> Quoting from the post: >>> >>> " >>> >>> >>> Apparently bought in two chunks: 3.0.0.0/9 >>> and 3.128.0.0/9 . >>> >>> Previous owner was GE. >>> >>> Anecdotal reports across the Internet that AWS EIPs are >>> now being assigned in that range. >>> >>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >>> >>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >>> >>> " >>> >>> >>> > -- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt at spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Fri Nov 9 02:44:45 2018 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 8 Nov 2018 21:44:45 -0500 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: Speaking of AS1 - I've been wondering, what's it being used for? It looks like Level3 owns it, and it's announcing a handful of prefixes and peering with a bunch of random ASes from many different countries. On Thu, Nov 8, 2018 at 9:19 PM, Steve Meuse wrote: > > John Orthoefer and I (and dozens of other BBN folks on this list) both > worked for BBNPlanet at the time that 4.2.2.1 and 4.2.2.2 were assigned. > John was one of the folks who built and ran that system. > > So when he said "I wish we could have used 4.4.4.4" and my comment of "I > think the dial modem folks beat us to..." was referring to the fact that > when 4/8 was first being deployed on AS1 we started assigning blocks to > various groups and they realized that 4.4.4.0/XX had already been > delegated to another internal group (I think it was the dial group). > > > > On Thu, Nov 8, 2018 at 8:45 PM Tom Beecher wrote: > >> 4.0.0.0/8 has been GTE/Level3 forever. >> >> 4.2.2.1 - 6 have been L3 DNS as far back as I can remember. >> >> On Thu, Nov 8, 2018 at 8:32 PM Todd Underwood >> wrote: >> >>> google used 4.4.4.4 for DNS in the past (2010, IIRC). >>> >>> t >>> >>> On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse wrote: >>> >>>> >>>> I think it was the dial modem team that beat us to 4.4.4.0/24? >>>> >>>> -Steve >>>> >>>> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer wrote: >>>> >>>>> I wish we could have used 4.4.4.4. Although at the time I suspect we >>>>> would have used 4.4.4.[123]. >>>>> >>>>> Johno >>>>> >>>>> On Nov 8, 2018, at 18:58, Matt Erculiani wrote: >>>>> >>>>> So it looks like GE will be solvent for a few more years and 3.3.3.3 >>>>> DNS is incoming. >>>>> >>>>> -Matt >>>>> >>>>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >>>> >>>>>> https://news.ycombinator.com/item?id=18407173 >>>>>> >>>>>> Quoting from the post: >>>>>> >>>>>> " >>>>>> >>>>>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >>>>>> >>>>>> Previous owner was GE. >>>>>> >>>>>> Anecdotal reports across the Internet that AWS EIPs are now being >>>>>> assigned in that range. >>>>>> >>>>>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >>>>>> >>>>>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >>>>>> " >>>>>> >>>>>> >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From smeuse at mara.org Fri Nov 9 03:12:15 2018 From: smeuse at mara.org (Steve Meuse) Date: Thu, 8 Nov 2018 22:12:15 -0500 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: It's still in use, I believe Level(3)/CenturyLink uses it for either their VPN or Voice network. -Steve On Thu, Nov 8, 2018 at 9:44 PM Ross Tajvar wrote: > Speaking of AS1 - I've been wondering, what's it being used for? It looks > like Level3 owns it, and it's announcing a handful of prefixes and peering > with a bunch of random ASes from many different countries. > > On Thu, Nov 8, 2018 at 9:19 PM, Steve Meuse wrote: > >> >> John Orthoefer and I (and dozens of other BBN folks on this list) both >> worked for BBNPlanet at the time that 4.2.2.1 and 4.2.2.2 were assigned. >> John was one of the folks who built and ran that system. >> >> So when he said "I wish we could have used 4.4.4.4" and my comment of "I >> think the dial modem folks beat us to..." was referring to the fact that >> when 4/8 was first being deployed on AS1 we started assigning blocks to >> various groups and they realized that 4.4.4.0/XX had already been >> delegated to another internal group (I think it was the dial group). >> >> >> >> On Thu, Nov 8, 2018 at 8:45 PM Tom Beecher wrote: >> >>> 4.0.0.0/8 has been GTE/Level3 forever. >>> >>> 4.2.2.1 - 6 have been L3 DNS as far back as I can remember. >>> >>> On Thu, Nov 8, 2018 at 8:32 PM Todd Underwood >>> wrote: >>> >>>> google used 4.4.4.4 for DNS in the past (2010, IIRC). >>>> >>>> t >>>> >>>> On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse wrote: >>>> >>>>> >>>>> I think it was the dial modem team that beat us to 4.4.4.0/24? >>>>> >>>>> -Steve >>>>> >>>>> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer >>>>> wrote: >>>>> >>>>>> I wish we could have used 4.4.4.4. Although at the time I suspect we >>>>>> would have used 4.4.4.[123]. >>>>>> >>>>>> Johno >>>>>> >>>>>> On Nov 8, 2018, at 18:58, Matt Erculiani >>>>>> wrote: >>>>>> >>>>>> So it looks like GE will be solvent for a few more years and 3.3.3.3 >>>>>> DNS is incoming. >>>>>> >>>>>> -Matt >>>>>> >>>>>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >>>>> >>>>>>> https://news.ycombinator.com/item?id=18407173 >>>>>>> >>>>>>> Quoting from the post: >>>>>>> >>>>>>> " >>>>>>> >>>>>>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >>>>>>> >>>>>>> Previous owner was GE. >>>>>>> >>>>>>> Anecdotal reports across the Internet that AWS EIPs are now being >>>>>>> assigned in that range. >>>>>>> >>>>>>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >>>>>>> >>>>>>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >>>>>>> " >>>>>>> >>>>>>> >>>>>>> >>>>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at cmadams.net Fri Nov 9 03:50:23 2018 From: cma at cmadams.net (Chris Adams) Date: Thu, 8 Nov 2018 21:50:23 -0600 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <1541712270.3007578.1570595888.001B165F@webmail.messagingengine.com> References: <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> <1541712270.3007578.1570595888.001B165F@webmail.messagingengine.com> Message-ID: <20181109035023.GA21189@cmadams.net> Once upon a time, Scott Christopher said: > Swipe-and-sign (and now just swipe for small amounts) is for Visa, Mastercard, Discover transactions (called credit) Signatures are no longer required for chip card transactions in the US, except I think for transactions where the auth is done on the amount before an added tip (restaurants). > Skimming and card fraud is actually uncommon in the U.S. these days, and the police are very effective at combating it. It's just cheaper for the industry to eat fraud losses than to "upgrade" systems. The transition to chip-based cards was a debacle. Skimming is still highly active at gas pumps, where chip support was pushed off (current requirement I believe is late 2020, but may be delayed again). The skimmers get more creative all the time; they're getting inside pumps (possibly with help of low-paid station attendants, but also because of poor physical security) and installing the skimmer hardware out of sight. The hardware has Bluetooth, so the bad guys just pull up and get gas and someone in the car can retrieve the data (from multiple pumps even). -- Chris Adams From simon.leinen at switch.ch Fri Nov 9 07:22:13 2018 From: simon.leinen at switch.ch (Simon Leinen) Date: Fri, 9 Nov 2018 08:22:13 +0100 Subject: CVV In-Reply-To: (Todd Underwood's message of "Thu, 8 Nov 2018 19:22:55 -0500") References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> <003601d477bf$ff1f7ea0$fd5e7be0$@iname.com> Message-ID: Todd Underwood writes: > [interesting and plausible reasoning about why no chip&PIN in US] > anyway, let's talk about networks, no? This topic is obviously "a little" off-topic, but I find some contributions (like yours) relevant for understanding adoption dynamics (or not) of proposed security mechanisms on the Internet (RPKI, route filtering in general, DNSSEC etc.). In general the regulatory environment in the Internet is quite different from that of the financial sector. But I guess credit-card security trade-offs are still made mostly by private actors. (Maybe they sometimes discuss BGP security on their mailing lists :-) -- Simon. From mark.tinka at seacom.mu Fri Nov 9 07:33:38 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 9 Nov 2018 09:33:38 +0200 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> <003601d477bf$ff1f7ea0$fd5e7be0$@iname.com> Message-ID: <6156e22f-a98c-b242-ab69-9c22202bc052@seacom.mu> On 9/Nov/18 02:22, Todd Underwood wrote: > > i generally find it amusing when people from other countries mock the > US for not having PINs.  this is just another way of saying "my > country has high fraud rates and yours appears not to."  :-) . you can > see this in the comment below "If we were swipe-based here, we'd all be > broke :-).".  the payments systems are architected to minimize cost > and maximize adoption and they are usually at (or moving towards) some > locally optimal point.  the US is no exception in that. That was me - and "low" (fraud rates) is not "zero" (fraud rates). Personally, I don't want to add to the statistic. The inconvenience isn't worth the bragging right :-)... Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brock at bmwl.co Fri Nov 9 13:39:40 2018 From: brock at bmwl.co (Brock Tice) Date: Fri, 9 Nov 2018 06:39:40 -0700 Subject: Technical Contact at Yahoo Message-ID: <95710669-e9e7-7f77-4e0a-f1492b8bf1e5@bmwl.co> Yahoo have done a very good job of locking down their contact info. We have an issue where they seem to be blocking one of our CGN public addresses. Does anyone know how I can get in touch with an appropriate person there? From brock at bmwl.co Fri Nov 9 13:39:40 2018 From: brock at bmwl.co (Brock Tice) Date: Fri, 9 Nov 2018 06:39:40 -0700 Subject: Technical Contact at Yahoo Message-ID: <3b5018d0-6c6a-fc2c-3d55-a6cc6c609c50@bmwl.co> Yahoo have done a very good job of locking down their contact info. We have an issue where they seem to be blocking one of our CGN public addresses. Does anyone know how I can get in touch with an appropriate person there? From ahebert at pubnix.net Fri Nov 9 14:29:09 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 9 Nov 2018 09:29:09 -0500 Subject: CVV In-Reply-To: <20181109035023.GA21189@cmadams.net> References: <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> <1541712270.3007578.1570595888.001B165F@webmail.messagingengine.com> <20181109035023.GA21189@cmadams.net> Message-ID:     Well,     Older Pump station installation (and maybe new ones) use RS-232/442 to communicate in clear text with their controller into the building.     Easy to tap to skim Track 1/Track2 of the CHD which is good to dups cards.     Now to get the physical CVV you need a physical skimmer installed on top the pump which is where your Bluetooth come in action.     With those you can dups and make "Card No Present" transaction (aka Internet).     It is a risk/reward thing.     PS: Lazyness is pretty much the greatest threat.  EU/CAN/etc are all CHIP while some other economy still refuse to spend that extra $1 per card :( ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 11/08/18 22:50, Chris Adams wrote: > Once upon a time, Scott Christopher said: >> Swipe-and-sign (and now just swipe for small amounts) is for Visa, Mastercard, Discover transactions (called credit) > Signatures are no longer required for chip card transactions in the US, > except I think for transactions where the auth is done on the amount > before an added tip (restaurants). > >> Skimming and card fraud is actually uncommon in the U.S. these days, and the police are very effective at combating it. It's just cheaper for the industry to eat fraud losses than to "upgrade" systems. The transition to chip-based cards was a debacle. > Skimming is still highly active at gas pumps, where chip support was > pushed off (current requirement I believe is late 2020, but may be > delayed again). > > The skimmers get more creative all the time; they're getting inside > pumps (possibly with help of low-paid station attendants, but also > because of poor physical security) and installing the skimmer hardware > out of sight. The hardware has Bluetooth, so the bad guys just pull up > and get gas and someone in the car can retrieve the data (from multiple > pumps even). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Fri Nov 9 15:18:30 2018 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 9 Nov 2018 10:18:30 -0500 Subject: Technical Contact at Yahoo In-Reply-To: <3b5018d0-6c6a-fc2c-3d55-a6cc6c609c50@bmwl.co> References: <3b5018d0-6c6a-fc2c-3d55-a6cc6c609c50@bmwl.co> Message-ID: I will reach out to you from my company email for details. On Fri, Nov 9, 2018 at 8:45 AM Brock Tice wrote: > Yahoo have done a very good job of locking down their contact info. We > have an issue where they seem to be blocking one of our CGN public > addresses. > > Does anyone know how I can get in touch with an appropriate person there? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Fri Nov 9 17:08:34 2018 From: list at satchell.net (Stephen Satchell) Date: Fri, 9 Nov 2018 09:08:34 -0800 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <20181109035023.GA21189@cmadams.net> References: <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> <1541712270.3007578.1570595888.001B165F@webmail.messagingengine.com> <20181109035023.GA21189@cmadams.net> Message-ID: On 11/08/2018 07:50 PM, Chris Adams wrote: > Signatures are no longer required for chip card transactions in the US, > except I think for transactions where the auth is done on the amount > before an added tip (restaurants). Signatures are required for chip card transactions above a certain dollar amount, with that dollar amount varying from merchant to merchant. I ran into this at the Sprint store when I used a chip card to pay $800+ for my company's overdue wireless bill, and I had to apply pen to paper by hand. And I didn't do my usual response to "sign here": draw a triangle and put "yield" in it. From cma at cmadams.net Fri Nov 9 17:14:29 2018 From: cma at cmadams.net (Chris Adams) Date: Fri, 9 Nov 2018 11:14:29 -0600 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: References: <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> <2147bc1d-9154-482d-8ad3-28b2182a4845@seacom.mu> <1541712270.3007578.1570595888.001B165F@webmail.messagingengine.com> <20181109035023.GA21189@cmadams.net> Message-ID: <20181109171429.GA5607@cmadams.net> Once upon a time, Stephen Satchell said: > On 11/08/2018 07:50 PM, Chris Adams wrote: > > Signatures are no longer required for chip card transactions in the US, > > except I think for transactions where the auth is done on the amount > > before an added tip (restaurants). > > Signatures are required for chip card transactions above a certain > dollar amount, with that dollar amount varying from merchant to > merchant. I ran into this at the Sprint store when I used a chip card > to pay $800+ for my company's overdue wireless bill, and I had to apply > pen to paper by hand. And I didn't do my usual response to "sign here": > draw a triangle and put "yield" in it. That's just because Sprint wanted it, not the credit card company. For example with VISA, the signature is "optional" for chip transactions, no matter the amount, but the retailer can still require it if they want (because they want to annoy customers I guess?). https://www.theverge.com/2018/1/12/16884814/visa-chip-emv-signatures-north-america-credit-card-april-2018 -- Chris Adams From cscora at apnic.net Fri Nov 9 18:03:18 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Nov 2018 04:03:18 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181109180318.CEAC8C450F@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 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 10 Nov, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 724810 Prefixes after maximum aggregation (per Origin AS): 278850 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 347882 Total ASes present in the Internet Routing Table: 62367 Prefixes per ASN: 11.62 Origin-only ASes present in the Internet Routing Table: 53812 Origin ASes announcing only one prefix: 23367 Transit ASes present in the Internet Routing Table: 8555 Transit-only ASes present in the Internet Routing Table: 262 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 36 Max AS path prepend of ASN ( 30873) 34 Prefixes from unregistered ASNs in the Routing Table: 34 Number of instances of unregistered ASNs: 34 Number of 32-bit ASNs allocated by the RIRs: 24790 Number of 32-bit ASNs visible in the Routing Table: 20041 Prefixes from 32-bit ASNs in the Routing Table: 85558 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 269 Number of addresses announced to Internet: 2861029537 Equivalent to 170 /8s, 135 /16s and 216 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.1 Total number of prefixes smaller than registry allocations: 241600 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 198132 Total APNIC prefixes after maximum aggregation: 56287 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 195616 Unique aggregates announced from the APNIC address blocks: 80344 APNIC Region origin ASes present in the Internet Routing Table: 9222 APNIC Prefixes per ASN: 21.21 APNIC Region origin ASes announcing only one prefix: 2585 APNIC Region transit ASes present in the Internet Routing Table: 1370 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: 4202 Number of APNIC addresses announced to Internet: 768556928 Equivalent to 45 /8s, 207 /16s and 63 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 215182 Total ARIN prefixes after maximum aggregation: 102100 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 214589 Unique aggregates announced from the ARIN address blocks: 102000 ARIN Region origin ASes present in the Internet Routing Table: 18281 ARIN Prefixes per ASN: 11.74 ARIN Region origin ASes announcing only one prefix: 6794 ARIN Region transit ASes present in the Internet Routing Table: 1839 Average ARIN Region AS path length visible: 3.7 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2490 Number of ARIN addresses announced to Internet: 1101801632 Equivalent to 65 /8s, 172 /16s and 40 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 197855 Total RIPE prefixes after maximum aggregation: 94547 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 194252 Unique aggregates announced from the RIPE address blocks: 115052 RIPE Region origin ASes present in the Internet Routing Table: 25619 RIPE Prefixes per ASN: 7.58 RIPE Region origin ASes announcing only one prefix: 11474 RIPE Region transit ASes present in the Internet Routing Table: 3530 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7567 Number of RIPE addresses announced to Internet: 715381888 Equivalent to 42 /8s, 163 /16s and 220 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 93832 Total LACNIC prefixes after maximum aggregation: 21694 LACNIC Deaggregation factor: 4.33 Prefixes being announced from the LACNIC address blocks: 95274 Unique aggregates announced from the LACNIC address blocks: 41681 LACNIC Region origin ASes present in the Internet Routing Table: 7748 LACNIC Prefixes per ASN: 12.30 LACNIC Region origin ASes announcing only one prefix: 2108 LACNIC Region transit ASes present in the Internet Routing Table: 1472 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5294 Number of LACNIC addresses announced to Internet: 172547328 Equivalent to 10 /8s, 72 /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: 19774 Total AfriNIC prefixes after maximum aggregation: 4194 AfriNIC Deaggregation factor: 4.71 Prefixes being announced from the AfriNIC address blocks: 24810 Unique aggregates announced from the AfriNIC address blocks: 8562 AfriNIC Region origin ASes present in the Internet Routing Table: 1214 AfriNIC Prefixes per ASN: 20.44 AfriNIC Region origin ASes announcing only one prefix: 406 AfriNIC Region transit ASes present in the Internet Routing Table: 241 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 488 Number of AfriNIC addresses announced to Internet: 102215936 Equivalent to 6 /8s, 23 /16s and 177 /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 4631 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4610 518 515 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2999 1154 93 VIETEL-AS-AP Viettel Group, VN 45899 2951 1685 110 VNPT-AS-VN VNPT Corp, VN 4766 2799 11130 764 KIXS-AS-KR Korea Telecom, KR 9829 2703 1489 571 BSNL-NIB National Internet Backbone, IN 9808 2448 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2412 4907 31 CTTNET China TieTong Telecommunications 17974 2270 968 51 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2123 421 171 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 3463 1324 84 SHAW - Shaw Communications Inc., CA 11492 3463 223 625 CABLEONE - CABLE ONE, INC., US 22773 3273 2973 165 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2446 5082 902 AMAZON-02 - Amazon.com, Inc., US 18566 2154 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2146 2739 545 CHARTER-NET-HKY-NC - Charter Communicat 16625 2120 1144 1574 AKAMAI-AS - Akamai Technologies, Inc., 5650 2085 3074 1461 FRONTIER-FRTR - Frontier Communications 30036 2060 346 142 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2040 5079 594 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5054 1613 133 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3039 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2557 565 1908 AKAMAI-ASN1, US 12389 2181 2178 616 ROSTELECOM-AS, RU 34984 2014 334 536 TELLCOM-AS, TR 9121 1921 1691 17 TTNET, TR 13188 1605 100 42 TRIOLAN, UA 8402 1281 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1218 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5452 3311 603 Uninet S.A. de C.V., MX 10620 3118 475 885 Telmex Colombia S.A., CO 11830 2667 370 75 Instituto Costarricense de Electricidad 6503 1660 449 54 Axtel, S.A.B. de C.V., MX 7303 1440 963 213 Telecom Argentina S.A., AR 28573 1146 2240 183 CLARO S.A., BR 6147 1091 377 29 Telefonica del Peru S.A.A., PE 3816 1025 512 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 938 145 72 Alestra, S. de R.L. de C.V., MX 13999 923 537 260 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1166 394 29 LINKdotNET-AS, EG 37611 910 107 9 Afrihost, ZA 36903 795 399 144 MT-MPLS, MA 36992 762 1411 43 ETISALAT-MISR, EG 24835 653 742 20 RAYA-AS, EG 8452 613 1728 15 TE-AS TE-AS, EG 37492 467 470 57 ORANGE-, TN 29571 462 70 12 ORANGE-COTE-IVOIRE, CI 23889 400 231 15 MauritiusTelecom, MU 37342 394 32 1 MOVITEL, MZ 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 5452 3311 603 Uninet S.A. de C.V., MX 12479 5054 1613 133 UNI2-AS, ES 4538 4631 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4610 518 515 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3463 1324 84 SHAW - Shaw Communications Inc., CA 11492 3463 223 625 CABLEONE - CABLE ONE, INC., US 22773 3273 2973 165 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3118 475 885 Telmex Colombia S.A., CO 8551 3039 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5054 4921 UNI2-AS, ES 4538 4631 4557 ERX-CERNET-BKB China Education and Research Net 7545 4610 4095 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3463 3379 SHAW - Shaw Communications Inc., CA 22773 3273 3108 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3039 2996 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2999 2906 VIETEL-AS-AP Viettel Group, VN 45899 2951 2841 VNPT-AS-VN VNPT Corp, VN 11492 3463 2838 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 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 65553 UNALLOCATED 103.218.190.0/24 58715 EARTHTELECOMMUNICATION-AS EART 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 92937 UNALLOCATED 110.49.72.0/24 45458 SBN-AWN-AS-02-AP SBN-ISP/AWN-I 4230060012 PRIVATE 132.190.106.0/24 64673 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.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.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.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 45.252.236.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 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:290 /13:566 /14:1112 /15:1897 /16:13325 /17:7874 /18:13816 /19:25421 /20:39496 /21:46094 /22:90126 /23:74077 /24:408286 /25:827 /26:651 /27:653 /28:37 /29:20 /30:24 /31:4 /32:54 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3878 5054 UNI2-AS, ES 6327 3248 3463 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2749 3463 CABLEONE - CABLE ONE, INC., US 22773 2528 3273 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2495 3039 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2048 2154 MEGAPATH5-US - MegaPath Corporation, US 11830 2012 2667 Instituto Costarricense de Electricidad y Telec 30036 1809 2060 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2085 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1623 2:890 4:18 5:2695 6:43 7:1 8:1138 12:1876 13:241 14:1875 15:33 16:3 17:197 18:58 20:50 23:2514 24:2414 25:2 27:2517 31:1999 32:85 35:28 36:558 37:2930 38:1558 39:265 40:121 41:3139 42:716 43:1980 44:127 45:6020 46:3084 47:234 49:1312 50:1068 51:318 52:1109 54:362 55:1 56:6 57:38 58:1694 59:1024 60:462 61:2088 62:1960 63:1790 64:5058 65:2181 66:4805 67:2635 68:1159 69:3365 70:1179 71:602 72:2235 74:2729 75:413 76:480 77:1669 78:1749 79:2221 80:1570 81:1415 82:1053 83:804 84:1065 85:2094 86:559 87:1485 88:960 89:2387 90:210 91:6482 92:1268 93:2386 94:2435 95:3039 96:912 97:349 98:938 99:154 100:87 101:1165 102:278 103:19135 104:3595 105:240 106:877 107:1847 108:709 109:3396 110:1642 111:1825 112:1396 113:1327 114:1147 115:1701 116:1664 117:1889 118:2203 119:1675 120:1115 121:1038 122:2331 123:1698 124:1439 125:1945 128:1213 129:690 130:510 131:1624 132:714 133:190 134:1041 135:228 136:532 137:659 138:1967 139:739 140:557 141:754 142:805 143:997 144:839 145:498 146:1244 147:762 148:1682 149:791 150:774 151:996 152:878 153:325 154:1955 155:951 156:1568 157:847 158:648 159:1865 160:1481 161:850 162:2641 163:760 164:1116 165:1581 166:460 167:1343 168:3144 169:868 170:3977 171:496 172:1063 173:2093 174:988 175:833 176:2145 177:4021 178:2513 179:1297 180:2154 181:2388 182:2594 183:1473 184:1130 185:14319 186:3565 187:2448 188:2903 189:2028 190:8308 191:1384 192:9920 193:6404 194:5231 195:4029 196:2969 197:1634 198:5667 199:5985 200:7358 201:4997 202:10199 203:10162 204:4608 205:3004 206:3251 207:3212 208:3943 209:4162 210:3868 211:2011 212:3003 213:2825 214:1056 215:55 216:6024 217:2178 218:877 219:576 220:1827 221:1007 222:970 223:1394 End of report From dovid at telecurve.com Fri Nov 9 18:18:49 2018 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 9 Nov 2018 13:18:49 -0500 Subject: Zayo vs Coent Message-ID: Hi, We are in a facility where my only options are Cogent or Zayo. We plan on getting a 10G connection for a web crawler using v4 only. Looking for feedback on either or (keeping the politics out of it). TIA. Dovid -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Fri Nov 9 18:26:40 2018 From: woody at pch.net (Bill Woodcock) Date: Fri, 9 Nov 2018 10:26:40 -0800 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> Message-ID: > On Nov 8, 2018, at 1:11 AM, Mark Tinka wrote: > It has always been curious to me how/why the U.S., with one of the > largest economies in the world, still do most card-based transactions as > a swipe in lieu of a PIN-based approach. That was true a few years ago, but it’s been at least a year since I’ve seen a swipe anywhere. The change happened quite quickly. It’s all been chip, or chip-and-pin, for at least a year. -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 bill at herrin.us Fri Nov 9 18:51:51 2018 From: bill at herrin.us (William Herrin) Date: Fri, 9 Nov 2018 10:51:51 -0800 Subject: Zayo vs Coent In-Reply-To: References: Message-ID: Zayo is the former above.net. Worked well for me at previous $job. Cogent is Cogent. Refer to the list archives for experiences with Cogent. Regards, Bill Herrin On Fri, Nov 9, 2018 at 10:19 AM Dovid Bender wrote: > > Hi, > > We are in a facility where my only options are Cogent or Zayo. We plan on getting a 10G connection for a web crawler using v4 only. Looking for feedback on either or (keeping the politics out of it). > > TIA. > > Dovid > -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From kushal.r at h4g.co Fri Nov 9 19:03:54 2018 From: kushal.r at h4g.co (Kushal R.) Date: Fri, 9 Nov 2018 20:03:54 +0100 Subject: Zayo vs Coent In-Reply-To: References: Message-ID: Comparing networks and performance I believe zayo will outperform Cogent in most places but I’ve heard nightmares about dealing with Zayo’s account managers and billing reps. Cogent is great at their price point and you will get a very sweet deal for a 10G circuit and their account managers and NOC both have been great for us. On Fri, 9 Nov 2018 at 7:21 PM, Dovid Bender wrote: > Hi, > > We are in a facility where my only options are Cogent or Zayo. We plan on > getting a 10G connection for a web crawler using v4 only. Looking for > feedback on either or (keeping the politics out of it). > > TIA. > > Dovid > > -- -- [image: Host4Geeks] Kushal R Chief Executive | Host4Geeks site: host4geeks.com email: kushal.r at h4g.co skype: kush.raha [image: linkedin] [image: facebook] [image: twitter] [image: instagram] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at deadfrog.net Fri Nov 9 19:23:05 2018 From: ryan at deadfrog.net (Ryan Wilkins) Date: Fri, 9 Nov 2018 14:23:05 -0500 Subject: Zayo vs Coent In-Reply-To: References: Message-ID: <616D5A6E-2EDC-4069-963C-422853F38BFF@deadfrog.net> I have both Zayo and Cogent at my location in West Chicago, IL and have found that most of my traffic transits Cogent. I haven’t had much in the way of issues with the Internet service of either but Zayo does seem to have gone down hill in terms of support quality since they bought Abovenet. I’m aware of the Cogent peering issues but haven’t investigated them fully. Recently, there was an extended service outage on my Zayo 1G link due to dark fiber issues on a private network which left me with Cogent only for about a week and had no support calls because of it. YMMV. Best, Ryan Wilkins > On Nov 9, 2018, at 1:18 PM, Dovid Bender wrote: > > Hi, > > We are in a facility where my only options are Cogent or Zayo. We plan on getting a 10G connection for a web crawler using v4 only. Looking for feedback on either or (keeping the politics out of it). > > TIA. > > Dovid > From merculiani at gmail.com Fri Nov 9 19:27:00 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Fri, 9 Nov 2018 13:27:00 -0600 Subject: Zayo vs Coent In-Reply-To: References: Message-ID: $dayjob hat off: I'll add that they often times use the same fiber for the last mile (hence why they're both on-net at that building), so if you get both with the intention of redundancy, you could potentially be taken out by a single cut unless you harp on the point that they need to be fiber diverse and asking for proof (drawings, etc.) never hurts. On Fri, Nov 9, 2018 at 1:05 PM Kushal R. wrote: > Comparing networks and performance I believe zayo will outperform Cogent > in most places but I’ve heard nightmares about dealing with Zayo’s account > managers and billing reps. > > Cogent is great at their price point and you will get a very sweet deal > for a 10G circuit and their account managers and NOC both have been great > for us. > > On Fri, 9 Nov 2018 at 7:21 PM, Dovid Bender wrote: > >> Hi, >> >> We are in a facility where my only options are Cogent or Zayo. We plan on >> getting a 10G connection for a web crawler using v4 only. Looking for >> feedback on either or (keeping the politics out of it). >> >> TIA. >> >> Dovid >> >> -- > -- > [image: Host4Geeks] > > Kushal R > Chief Executive | Host4Geeks > site: host4geeks.com > email: kushal.r at h4g.co > skype: kush.raha > [image: linkedin] > > [image: facebook] > [image: twitter] > [image: instagram] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Fri Nov 9 20:19:36 2018 From: cb.list6 at gmail.com (Ca By) Date: Fri, 9 Nov 2018 12:19:36 -0800 Subject: Zayo vs Coent In-Reply-To: References: Message-ID: Zayo will provide you all of the internet Cogent will provide you with something that is not all internet, it is missing HE and Google on ipv6. On Fri, Nov 9, 2018 at 10:53 AM William Herrin wrote: > Zayo is the former above.net. Worked well for me at previous $job. > Cogent is Cogent. Refer to the list archives for experiences with > Cogent. > > Regards, > Bill Herrin > On Fri, Nov 9, 2018 at 10:19 AM Dovid Bender wrote: > > > > Hi, > > > > We are in a facility where my only options are Cogent or Zayo. We plan > on getting a 10G connection for a web crawler using v4 only. Looking for > feedback on either or (keeping the politics out of it). > > > > TIA. > > > > Dovid > > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edugas at unknowndevice.ca Fri Nov 9 20:25:57 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Fri, 9 Nov 2018 15:25:57 -0500 Subject: Contact at BGPView.io Message-ID: <1541794899.local-294570e0-9c58-v1.5.2-31660462@getmailspring.com> Hello, Trying to find a contact at BGPView.io (outside the useless contact form). Some of their data for our ASN has been outdated for months so I'm trying to find where they get the data from. Thanks Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Fri Nov 9 20:26:15 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 9 Nov 2018 22:26:15 +0200 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> <20181011193136.GA30057@cmadams.net> <8573fd72-0362-9606-068e-0a817704d61e@seacom.mu> Message-ID: <92581f73-9e47-0d69-8099-5ed1b905e350@seacom.mu> On 9/Nov/18 20:26, Bill Woodcock wrote: > That was true a few years ago, but it’s been at least a year since I’ve seen a swipe anywhere. The change happened quite quickly. It’s all been chip, or chip-and-pin, for at least a year. In the last 2 years, I've seen the rise of PIN-based transactions in the U.S., and this is great. But between San Diego, San Jose, San Francisco, Chicago, Hawaii and Seattle for my 2017/2018 U.S. visits, there are just about as many merchants supporting PIN's as there are that don't. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From jbothe at me.com Fri Nov 9 20:58:28 2018 From: jbothe at me.com (JASON BOTHE) Date: Fri, 09 Nov 2018 14:58:28 -0600 Subject: Zayo vs Coent In-Reply-To: References: Message-ID: <3CC4FDD4-14B9-426C-B1C0-E4FCD7EC3DBF@me.com> If you love yourself and your organization just peer with Zayo and not look back. > On Nov 9, 2018, at 14:19, Ca By wrote: > > Zayo will provide you all of the internet > > Cogent will provide you with something that is not all internet, it is missing HE and Google on ipv6. > >> On Fri, Nov 9, 2018 at 10:53 AM William Herrin wrote: >> Zayo is the former above.net. Worked well for me at previous $job. >> Cogent is Cogent. Refer to the list archives for experiences with >> Cogent. >> >> Regards, >> Bill Herrin >> On Fri, Nov 9, 2018 at 10:19 AM Dovid Bender wrote: >> > >> > Hi, >> > >> > We are in a facility where my only options are Cogent or Zayo. We plan on getting a 10G connection for a web crawler using v4 only. Looking for feedback on either or (keeping the politics out of it). >> > >> > TIA. >> > >> > Dovid >> > >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldumont at fibrenoire.ca Sat Nov 10 01:48:02 2018 From: ldumont at fibrenoire.ca (Laurent Dumont) Date: Fri, 9 Nov 2018 20:48:02 -0500 Subject: GTT Woes Message-ID: Hi Folks, I was expecting a quiet weekend but it seems that is not the case. We have an IP-VPN circuit in Connecticut that feeds back to Montreal. We have a base-line of 15MS over the past few months which fits with the distance. We have a previous incident a week and a half ago where it jumped to 50MS for 5 days. This was resolved by GTT and caused by a failover to a "protected" path due to an alarm that wasn't properly handled for all that time. We had a really bad time with their Support/NOC and are quite stunned at how poorly it was handled. Well surprise, we are back in the same train. My latency jumped from 15MS to 35MS and then to 50MS a bit later. That happened on the 7th at 5:00PM Eastern and has been ongoing ever since. We've hard a very hard time getting anything out of GTT. Numerous back and forth with as much information as possible from our side. I am basically seeing the +35MS on the circuit when reaching the NY/Connecticut GTT PE straight from my device that is in the same region. I even have another GTT 12 miles from that location that has a 15MS latency all the way back to Montreal. If anyone can poke, dig or has anything for us, I would greatly appreciate it. I can provide ticket numbers and circuit ID at any time. Have a latency free weekend! Thanks -- *Laurent Dumont* *Spécialiste réseau / Network specialist* *Fibrenoire* - www.fibrenoire.ca A: 550 , avenue Beaumont, bureau 320, Montréal (Québec) H3N 1V1 T. 514 907-3002 x132 C.438 825-4642 ldumont at fibrenoire.ca Twitter: Twitter Fibrenoire *--Note de confidentialité--* *Ce message électronique et toutes pièces jointes contiennent des informations privilégiées et confidentielles. Si vous n'êtes pas le destinataire prévu, il est strictement interdit d'utiliser, de copier ou divulguer les informations ainsi transmises; merci d'en aviser l'expéditeur et de les supprimer de votre ordinateur.* *--Confidentiality Note--* *This email message and any attachments contain privileged and confidential information. If you are not the intended recipient, your use, copying or disclosure of this information is prohibited; please contact the sender and delete the material from your computer.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier at kjsl.com Sat Nov 10 02:07:05 2018 From: javier at kjsl.com (Javier Henderson) Date: Fri, 9 Nov 2018 18:07:05 -0800 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: > On Nov 8, 2018, at 15:56, Job Snijders wrote: > >> On Fri, Nov 9, 2018 at 0:54 Eric Kuhnke wrote: > >> https://news.ycombinator.com/item?id=18407173 >> >> Quoting from the post: >> >> " >> >> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >> Previous owner was GE. >> >> Anecdotal reports across the Internet that AWS EIPs are now being assigned in that range. >> >> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >> >> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >> >> " > > > Seems ALTDB should delete the old AS 80 / GE IRR proxy route registration: > http://irrexplorer.nlnog.net/search/3.0.0.0 It’s been done. -jav -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrsyeltzin at gmail.com Sat Nov 10 02:52:39 2018 From: mrsyeltzin at gmail.com (Dan Stralka) Date: Fri, 9 Nov 2018 21:52:39 -0500 Subject: Zayo vs Coent In-Reply-To: <3CC4FDD4-14B9-426C-B1C0-E4FCD7EC3DBF@me.com> References: <3CC4FDD4-14B9-426C-B1C0-E4FCD7EC3DBF@me.com> Message-ID: We have 10G IPv4 circuits with both Zayo and Cogent getting full routes. One major difference is the maintenance windows - when Cogent has maintenance, things get weird for hours at a time. On Fri, Nov 9, 2018 at 4:00 PM JASON BOTHE via NANOG wrote: > If you love yourself and your organization just peer with Zayo and not > look back. > > On Nov 9, 2018, at 14:19, Ca By wrote: > > Zayo will provide you all of the internet > > Cogent will provide you with something that is not all internet, it is > missing HE and Google on ipv6. > > On Fri, Nov 9, 2018 at 10:53 AM William Herrin wrote: > >> Zayo is the former above.net. Worked well for me at previous $job. >> Cogent is Cogent. Refer to the list archives for experiences with >> Cogent. >> >> Regards, >> Bill Herrin >> On Fri, Nov 9, 2018 at 10:19 AM Dovid Bender wrote: >> > >> > Hi, >> > >> > We are in a facility where my only options are Cogent or Zayo. We plan >> on getting a 10G connection for a web crawler using v4 only. Looking for >> feedback on either or (keeping the politics out of it). >> > >> > TIA. >> > >> > Dovid >> > >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Sat Nov 10 03:45:59 2018 From: aaron1 at gvtc.com (Aaron1) Date: Fri, 9 Nov 2018 21:45:59 -0600 Subject: Zayo vs Coent In-Reply-To: References: <3CC4FDD4-14B9-426C-B1C0-E4FCD7EC3DBF@me.com> Message-ID: <3F2AF9CA-8277-4CD1-AE59-533EC5B3A4EE@gvtc.com> My cogent is pretty good... I had 10 gig for a few years, then dual 10’s Lag’d together for about year or so, and now 100 gig for about 2 months. So it’s been about five or six years that I’ve been with cogent They usually are knowledgeable when I talk to them and they are able to do what I ask of them. They usually don’t have to hand me off to somebody else. Cogent has good DDOS RTBH also. I trigger a /32 and it’s immediately black holed in the cloud. Cogent does however have an issue with ipv6 peering with google. I currently have my v6 ebgp session shut down with them because of this. Moving forward and doing more V6 in the future, I will have to figure out how to deal with us. I’ve also had Spectrum, ATT, Telia, all good as well. I’ve have no experience with Zayo, so I can’t speak to that Aaron > On Nov 9, 2018, at 8:52 PM, Dan Stralka wrote: > > We have 10G IPv4 circuits with both Zayo and Cogent getting full routes. One major difference is the maintenance windows - when Cogent has maintenance, things get weird for hours at a time. > > > >> On Fri, Nov 9, 2018 at 4:00 PM JASON BOTHE via NANOG wrote: >> If you love yourself and your organization just peer with Zayo and not look back. >> >>> On Nov 9, 2018, at 14:19, Ca By wrote: >>> >>> Zayo will provide you all of the internet >>> >>> Cogent will provide you with something that is not all internet, it is missing HE and Google on ipv6. >>> >>>> On Fri, Nov 9, 2018 at 10:53 AM William Herrin wrote: >>>> Zayo is the former above.net. Worked well for me at previous $job. >>>> Cogent is Cogent. Refer to the list archives for experiences with >>>> Cogent. >>>> >>>> Regards, >>>> Bill Herrin >>>> On Fri, Nov 9, 2018 at 10:19 AM Dovid Bender wrote: >>>> > >>>> > Hi, >>>> > >>>> > We are in a facility where my only options are Cogent or Zayo. We plan on getting a 10G connection for a web crawler using v4 only. Looking for feedback on either or (keeping the politics out of it). >>>> > >>>> > TIA. >>>> > >>>> > Dovid >>>> > >>>> >>>> >>>> -- >>>> William Herrin ................ herrin at dirtside.com bill at herrin.us >>>> Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sun Nov 11 09:29:43 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 11 Nov 2018 11:29:43 +0200 Subject: WIndows Updates Fail Via IPv6 Message-ID: Hi all. Anyone ever figured out why Windows updates fail when the computer has an IPv6 connection? Google has tickets and tickets of this to and outside of Microsoft since 2013, with no real solution or answer as to what the problem actually is. In essence, many of the solutions out there point toward making sure the updates do not occur over IPv6, which, in effect, is the same as disabling it. I have a family PC at home running Windows 10 Pro, and noticed updates would fail in recent months. It took me a moment to realize that this started happening only after I enabled IPv6 in the TCP/IP stack. Disabling it immediately solves the issue. Quite odd that this is happening in 2018... Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sun Nov 11 09:36:18 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 11 Nov 2018 11:36:18 +0200 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: <3438B611A2B2C04495EF0E1B25729C46331C2BA4@mbx032-e1-va-8.exch032.serverpod.net> References: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> <91106287-41c7-3ba6-6922-681cf5b98193@gmail.com> <3438B611A2B2C04495EF0E1B25729C46331C2BA4@mbx032-e1-va-8.exch032.serverpod.net> Message-ID: On 19/Oct/18 16:57, Marshall, Quincy wrote: > > * * > > Not unheard of… requested several new quotes in the last few months > and at least 2 included $50/mo charge for BGP. > My memory could be dodgy, but I think I recall seeing something similar on an order form they sent us for an upgrade (or turn-up) a few years ago. We pick them up in Amsterdam. That said, the fee not being explicitly on the order form does not mean it's not being charged. If I were Cogent and really needed the money, I wouldn't mention it on the order form, but just wrap it into the turn-up NRC or service MRC. That Cogent are explicitly highlighting it in an order form is to send another message, or create an industry standard. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sun Nov 11 09:51:32 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 11 Nov 2018 11:51:32 +0200 Subject: CLS to CLS Latency info In-Reply-To: References: Message-ID: On 30/Oct/18 05:11, Mehmet Akcin wrote: > Hello there > > I have been searching for CLS (Cable Landing Station) to CLS latency > infirnation for submarine cables. I was able to identify only a > handful of them via sales catalogs. I am still missing like 320~ > systems, does wnyone have this info available? > > If i can’t find the data, i am going to formulate from lentgh of fiber > diveded by speed of light on fibre (~ +\- resistance) but I really > would prefer actual ping ;) > > This is for www.networkatlas.org > project. Thank you in advance! For the SEACOM cable system, you're welcome to use:     http://as37100.net/ The CLS-to-CLS numbers are live, so they are accurate. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcorbe at hammerfiber.com Sun Nov 11 11:41:47 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Sun, 11 Nov 2018 06:41:47 -0500 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: References: Message-ID: at 4:29 AM, Mark Tinka wrote: > Hi all. > > Anyone ever figured out why Windows updates fail when the computer has an > IPv6 connection? > > Google has tickets and tickets of this to and outside of Microsoft since > 2013, with no real solution or answer as to what the problem actually is. > In essence, many of the solutions out there point toward making sure the > updates do not occur over IPv6, which, in effect, is the same as > disabling it. > > I have a family PC at home running Windows 10 Pro, and noticed updates > would fail in recent months. It took me a moment to realize that this > started happening only after I enabled IPv6 in the TCP/IP stack. > Disabling it immediately solves the issue. > > Quite odd that this is happening in 2018... > > Mark. I’ve had IPv6 enabled for a while and I don’t have the same issue. We also peer directly with Microsoft. Are you sure it’s an IPv6 issue and not a general reachability issue? -Daniel From savage at savage.za.org Sun Nov 11 12:02:37 2018 From: savage at savage.za.org (Chris Knipe) Date: Sun, 11 Nov 2018 14:02:37 +0200 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: References: Message-ID: Also no problems here with IPv6 and Windows Updates... On Sun, Nov 11, 2018 at 1:42 PM Daniel Corbe wrote: > at 4:29 AM, Mark Tinka wrote: > > > Hi all. > > > > Anyone ever figured out why Windows updates fail when the computer has > an > > IPv6 connection? > > > > Google has tickets and tickets of this to and outside of Microsoft > since > > 2013, with no real solution or answer as to what the problem actually > is. > > In essence, many of the solutions out there point toward making sure > the > > updates do not occur over IPv6, which, in effect, is the same as > > disabling it. > > > > I have a family PC at home running Windows 10 Pro, and noticed updates > > would fail in recent months. It took me a moment to realize that this > > started happening only after I enabled IPv6 in the TCP/IP stack. > > Disabling it immediately solves the issue. > > > > Quite odd that this is happening in 2018... > > > > Mark. > > I’ve had IPv6 enabled for a while and I don’t have the same issue. We > also > peer directly with Microsoft. Are you sure it’s an IPv6 issue and not a > general reachability issue? > > -Daniel > > > -- Regards, Chris Knipe -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sun Nov 11 13:45:40 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 11 Nov 2018 15:45:40 +0200 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: References: Message-ID: On 11/Nov/18 14:02, Chris Knipe wrote: > Also no problems here with IPv6 and Windows Updates... The issue is affecting (and has affected) quite a few folk: https://social.technet.microsoft.com/Forums/windowsserver/en-US/a9b1b537-ad27-4718-821b-57ef33174974/windows-update-fails-if-ipv6-is-enabled?forum=w8itpronetworking https://social.technet.microsoft.com/Forums/office/en-US/16e7aa06-9b90-48f8-8370-76c2329b93a8/windows-update-ipv6?forum=ws2016 https://answers.microsoft.com/en-us/windows/forum/all/windows-8-pro-windows-update-fails-if-ipv6-is/7ebdac22-6675-402b-ad43-e3fa8450659d It occurs to me that this, could, perhaps be CDN specific. I'm currently not in Johannesburg, but last time I checked, the majority of Windows updates were being handled by Akamai. Perhaps this is where the issue could be, although we have got local IPv6 peering with Akamai and don't generally have issues with it. I'll dig deeper into how Akamai may be involved when I get back home. Thanks for the pointers. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at lavanauts.org Sun Nov 11 16:51:35 2018 From: tony at lavanauts.org (Lavanauts) Date: Sun, 11 Nov 2018 06:51:35 -1000 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: References: Message-ID: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> I’m on native IPv6 via Spectrum and have no problems with Windows Updates. Could this be a tunneling issue? Tony > On Nov 10, 2018, at 23:29, Mark Tinka wrote: > > Hi all. > > Anyone ever figured out why Windows updates fail when the computer has an IPv6 connection? > > Google has tickets and tickets of this to and outside of Microsoft since 2013, with no real solution or answer as to what the problem actually is. In essence, many of the solutions out there point toward making sure the updates do not occur over IPv6, which, in effect, is the same as disabling it. > > I have a family PC at home running Windows 10 Pro, and noticed updates would fail in recent months. It took me a moment to realize that this started happening only after I enabled IPv6 in the TCP/IP stack. Disabling it immediately solves the issue. > > Quite odd that this is happening in 2018... > > Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mangawilly at gmail.com Sun Nov 11 17:42:35 2018 From: mangawilly at gmail.com (Willy MANGA) Date: Sun, 11 Nov 2018 18:42:35 +0100 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: References: Message-ID: <56976450-1fd7-aa76-42d8-cf90ffee12e5@gmail.com> Hi, Le 11/11/2018 à 13:00, nanog-request at nanog.org a écrit : > [...] > Date: Sun, 11 Nov 2018 11:29:43 +0200 > From: Mark Tinka > Hi all. > Anyone ever figured out why Windows updates fail when the computer has > an IPv6 connection? Weird .. We have PC running Windows 10 pro (20+) in my organization (based in Cameroon) and dont have that issue. > [...] > I have a family PC at home running Windows 10 Pro, and noticed updates > would fail in recent months. It took me a moment to realize that this > started happening only after I enabled IPv6 in the TCP/IP stack. > Disabling it immediately solves the issue. > > Quite odd that this is happening in 2018... IMHO the issue is in the network somewhere ... -- Willy Manga @ongolaboy https://ongola.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jared at puck.nether.net Sun Nov 11 18:35:00 2018 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 11 Nov 2018 13:35:00 -0500 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: References: Message-ID: <33C8854C-0093-4F5F-92B3-6312AD26CA44@puck.nether.net> > On Nov 11, 2018, at 8:45 AM, Mark Tinka wrote: > > > > On 11/Nov/18 14:02, Chris Knipe wrote: > >> Also no problems here with IPv6 and Windows Updates... > > The issue is affecting (and has affected) quite a few folk: > > https://social.technet.microsoft.com/Forums/windowsserver/en-US/a9b1b537-ad27-4718-821b-57ef33174974/windows-update-fails-if-ipv6-is-enabled?forum=w8itpronetworking > https://social.technet.microsoft.com/Forums/office/en-US/16e7aa06-9b90-48f8-8370-76c2329b93a8/windows-update-ipv6?forum=ws2016 > https://answers.microsoft.com/en-us/windows/forum/all/windows-8-pro-windows-update-fails-if-ipv6-is/7ebdac22-6675-402b-ad43-e3fa8450659d > > It occurs to me that this, could, perhaps be CDN specific. > > I'm currently not in Johannesburg, but last time I checked, the majority of Windows updates were being handled by Akamai. Perhaps this is where the issue could be, although we have got local IPv6 peering with Akamai and don't generally have issues with it. > > I'll dig deeper into how Akamai may be involved when I get back home. Let me know if you see anything related to Akamai. Looking at these threads I don’t see anything really obvious and some are much older posts. - Jared From bryce at thenetworknerds.ca Mon Nov 12 00:57:21 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Sun, 11 Nov 2018 16:57:21 -0800 Subject: Well Known BGP Communities Message-ID: <4708A318-496B-4C87-BC8B-FEE6F17CEA63@thenetworknerds.ca> I’m working on updating the BGP communities that are processed and used in my routers and I was interested as to what some of the common BGP communities that I might want to implement parsing for might be. As I understand it, it is somewhat required that no export, no advertise and no export subconfed are implemented. I believe that there is also a no peer option which asks that a prefix not be announced over a peering relationship, only transit and downstream. I do have my own informational prefixes for source location and peering vs transit prefixes so it would not be a stretch to add a version to allow for restrictions on where a prefix is announced and possibly prepending as well. I am aware that action communities exist for blackhole and setting of local preference but I can not find a consensus as to what those communities may be. Thanks ~ Bryce Wilson, AS202313, EVIX, AS137933 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lista-gter at tbonet.net.br Mon Nov 12 01:51:35 2018 From: lista-gter at tbonet.net.br (=?UTF-8?Q?Jo=c3=a3o_Butzke?=) Date: Sun, 11 Nov 2018 23:51:35 -0200 Subject: Well Known BGP Communities In-Reply-To: <4708A318-496B-4C87-BC8B-FEE6F17CEA63@thenetworknerds.ca> References: <4708A318-496B-4C87-BC8B-FEE6F17CEA63@thenetworknerds.ca> Message-ID: <3589d4f6-1685-6d42-7b03-fd6cb66b8873@tbonet.net.br> Hi, Bryce! Is this what you are looking for? https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml https://tools.ietf.org/html/rfc1997 Best regards, João Butzke. Em 11/11/2018 22:57, Bryce Wilson escreveu: > I’m working on updating the BGP communities that are processed and > used in my routers and I was interested as to what some of the common > BGP communities that I might want to implement parsing for might be. > > As I understand it, it is somewhat required that no export, no > advertise and no export subconfed are implemented. I believe that > there is also a no peer option which asks that a prefix not be > announced over a peering relationship, only transit and downstream. > > I do have my own informational prefixes for source location and > peering vs transit prefixes so it would not be a stretch to add a > version to allow for restrictions on where a prefix is announced and > possibly prepending as well. I am aware that action communities exist > for blackhole and setting of local preference but I can not find a > consensus as to what those communities may be. > > Thanks ~ Bryce Wilson, AS202313, EVIX, AS137933 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Mon Nov 12 14:00:05 2018 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 12 Nov 2018 14:00:05 +0000 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: On 09/11/2018 00:46, Eric Kuhnke wrote: > 3.4.5.6/24 could be an interesting block to put > easily memorable IP services in... My upbringing in the 90s makes '5.6.7.8' far more memorable. :) -- Tom From jared at puck.nether.net Mon Nov 12 14:02:25 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 12 Nov 2018 09:02:25 -0500 Subject: Well Known BGP Communities In-Reply-To: <3589d4f6-1685-6d42-7b03-fd6cb66b8873@tbonet.net.br> References: <4708A318-496B-4C87-BC8B-FEE6F17CEA63@thenetworknerds.ca> <3589d4f6-1685-6d42-7b03-fd6cb66b8873@tbonet.net.br> Message-ID: <20181112140225.GB21054@puck.nether.net> On Sun, Nov 11, 2018 at 11:51:35PM -0200, João Butzke wrote: > Hi, Bryce! > > Is this what you are looking for? > > https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml > > https://tools.ietf.org/html/rfc1997 You may also want to look at https://tools.ietf.org/html/draft-ietf-grow-wkc-behavior -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From clinton at scripty.com Mon Nov 12 16:18:06 2018 From: clinton at scripty.com (Clinton Work) Date: Mon, 12 Nov 2018 09:18:06 -0700 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: References: Message-ID: <1542039486.1383493.1574168360.2AFBE796@webmail.messagingengine.com> I saw this issue randomly on Windows PCs due to IPV6 TCP checksum offloading. Try the following on the problem Windows machine: - Open the Device Manager -> Network Adapters -> Network Interface (Ethernet NIC):- Under the Network Adapter -> Advanced Tab, disable these options if present:TCP Checksum Offloading (IPV6) -> Disabled UDP Checksum Offloading (IPV6) -> Disabled - Try Windows update again -- Clinton Work Airdrie, AB On Sun, Nov 11, 2018, at 2:29 AM, Mark Tinka wrote: > Hi all. > > Anyone ever figured out why Windows updates fail when the computer > has an IPv6 connection? > > Google has tickets and tickets of this to and outside of Microsoft > since 2013, with no real solution or answer as to what the problem > actually is. In essence, many of the solutions out there point toward > making sure the updates do not occur over IPv6, which, in effect, is > the same as disabling it. > > I have a family PC at home running Windows 10 Pro, and noticed > updates would fail in recent months. It took me a moment to realize > that this started happening only after I enabled IPv6 in the TCP/IP > stack. Disabling it immediately solves the issue. > > Quite odd that this is happening in 2018... > > Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Nov 12 18:18:30 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 12 Nov 2018 20:18:30 +0200 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> Message-ID: On 11/Nov/18 18:51, Lavanauts wrote: > I’m on native IPv6 via Spectrum and have no problems with Windows > Updates.  Could this be a tunneling issue? I do run 6-in-4 from my backbone to my house as my FTTH provider does not do IPv6. I can't imagine this to specifically be the issue, as all other IPv6 traffic is fine, but at this point, I'm open to suggestion. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Nov 12 18:19:59 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 12 Nov 2018 20:19:59 +0200 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: <33C8854C-0093-4F5F-92B3-6312AD26CA44@puck.nether.net> References: <33C8854C-0093-4F5F-92B3-6312AD26CA44@puck.nether.net> Message-ID: On 11/Nov/18 20:35, Jared Mauch wrote: > Let me know if you see anything related to Akamai. Will do. > Looking at these threads I don’t see anything really obvious and some are much older posts. Agreed - but those posts were never really solved, and the issue description and behaviour mirrors my own. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Nov 12 18:24:24 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 12 Nov 2018 20:24:24 +0200 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: <1542039486.1383493.1574168360.2AFBE796@webmail.messagingengine.com> References: <1542039486.1383493.1574168360.2AFBE796@webmail.messagingengine.com> Message-ID: <0e5a0897-4eeb-d3bd-7f40-8b6911805ae0@seacom.mu> On 12/Nov/18 18:18, Clinton Work wrote: > I saw this issue randomly on Windows PCs due to IPV6 TCP checksum > offloading.    > > Try the following on the problem Windows machine: > - Open the Device Manager -> Network Adapters -> Network Interface > (Ethernet NIC): > - Under the Network Adapter -> Advanced Tab, disable these options if > present: > TCP Checksum Offloading (IPV6) -> Disabled > UDP Checksum Offloading (IPV6) -> Disabled > - Try Windows update again Thanks, Airdrie, but I don't have those options on the network adapter. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Mon Nov 12 18:34:42 2018 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 12 Nov 2018 19:34:42 +0100 (CET) Subject: WIndows Updates Fail Via IPv6 In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> Message-ID: On Mon, 12 Nov 2018, Mark Tinka wrote: > I do run 6-in-4 from my backbone to my house as my FTTH provider does > not do IPv6. > > I can't imagine this to specifically be the issue, as all other IPv6 > traffic is fine, but at this point, I'm open to suggestion. Are you doing TCP MSS adjust/clamping? If you don't, try that and see if it helps. This might be a PMTUD issue. Otherwise if possible, try lowering the MTU sent in RA to the one you have on your tunnel (this depends on if this is available to you in your RA sending device). -- Mikael Abrahamsson email: swmike at swm.pp.se From spoofer-info at caida.org Thu Nov 8 18:00:05 2018 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Thu, 8 Nov 2018 10:00:05 -0800 Subject: Spoofer Report for NANOG for Oct 2018 Message-ID: <201811081800.wA8I05Gx018426@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 Oct 2018: ASN Name Fixed-By 14361 HOPONE-GLOBAL 2018-10-03 7233 YAHOO-US 2018-10-04 237 MERIT-AS-14 2018-10-05 4 ISI 2018-10-10 15176 AS-INOC 2018-10-17 3356 LEVEL3 2018-10-24 10326 WORCESTER-1 2018-10-29 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Oct 2018: ASN Name First-Spoofed Last-Spoofed 5650 FRONTIER-FRTR 2016-02-22 2018-10-04 577 BACOM 2016-03-09 2018-10-27 18978 ENZUINC-US 2016-04-15 2018-10-26 54825 PACKET 2016-04-15 2018-10-11 7922 COMCAST-7922 2016-06-04 2018-10-09 19230 NANOG 2016-06-13 2018-10-04 7029 WINDSTREAM 2016-06-21 2018-10-30 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-10-28 6128 CABLE-NET-1 2016-09-03 2018-10-31 20412 CLARITY-TELECOM 2016-09-30 2018-10-31 6181 FUSE-NET 2016-10-10 2018-10-30 15305 SYRINGANETWORKS 2016-10-21 2018-10-27 25787 ROWE-NETWORKS 2016-10-21 2018-10-26 174 COGENT-174 2016-10-21 2018-10-31 2828 XO-AS15 2016-10-25 2018-10-06 31857 PRIORITY-TERABIT 2016-10-25 2018-10-19 30341 SCTA-ASN 2016-10-31 2018-10-14 32440 LONI 2016-11-03 2018-10-29 33182 DimeNOC 2016-11-08 2018-10-25 12083 WOW-INTERNET 2016-11-09 2018-10-27 3549 LVLT-3549 2016-11-16 2018-10-03 21832 KELLINCOM-1 2017-02-03 2018-10-26 7122 MTS-ASN 2017-05-16 2018-10-25 6461 ZAYO-6461 2017-06-21 2018-10-31 63296 AMARILLO-WIRELESS 2017-09-01 2018-10-30 7233 YAHOO-US 2017-09-07 2018-10-31 33523 ROWANUNIVERSITY 2017-10-29 2018-10-31 2152 CSUNET-NW 2017-11-08 2018-10-10 546 PARSONS-PGS-1 2017-11-20 2018-10-10 12222 AKAMAI 2018-02-14 2018-10-27 29384 Qatar-Foundation 2018-03-08 2018-10-25 23148 TERRENAP 2018-03-15 2018-10-30 20009 WADSNET 2018-04-13 2018-10-19 4201 ORST 2018-04-19 2018-10-29 11827 WSU 2018-04-19 2018-10-31 393564 SPOKANE 2018-06-05 2018-10-03 35911 BNQ-1 2018-06-06 2018-10-21 225 VIRGINIA 2018-06-18 2018-10-30 53646 HARRIS-BROADBAND 2018-08-10 2018-10-02 40911 L2NC 2018-08-31 2018-10-15 2381 WISCNET1 2018-09-04 2018-10-31 54804 CSMIII-BUNKIELA 2018-09-15 2018-10-16 33452 RW 2018-09-19 2018-10-14 20448 VPNTRANET-LLC 2018-09-20 2018-10-12 11996 LOBOIS 2018-09-24 2018-10-16 10326 WORCESTER-1 2018-09-30 2018-10-05 10929 NETELLIGENT 2018-10-02 2018-10-03 36210 SFCF 2018-10-13 2018-10-13 36327 VINAKOM 2018-10-16 2018-10-16 14031 SCXY 2018-10-18 2018-10-26 19919 VSW 2018-10-23 2018-10-30 22462 NOLA-BROADBAND-INC 2018-10-30 2018-10-30 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 alex at os33.com Fri Nov 9 01:57:55 2018 From: alex at os33.com (Alex Osipov) Date: Fri, 9 Nov 2018 01:57:55 +0000 Subject: Escalation point at Google Message-ID: Hello – Does anyone have an escalation point or a human to speak to on the Google escalations or Google Safe Browsing team? Our entire SaaS business, 15 years in business, in a niche software industry with a good reputation has become blocked in ALL browsers. We are impacting 30k+ enterprise users in the financial space and have tried everything but all roads lead to automated systems. Can anyone please reach out with a contact if you have one? Sorry to spam this list if this is inappropriate content. Very desperate here. Thank you, Alex Osipov / CTO -------------- next part -------------- An HTML attachment was scrubbed... URL: From Paul.Dalton at sprint.com Fri Nov 9 02:50:09 2018 From: Paul.Dalton at sprint.com (Dalton, Paul P [CTO]) Date: Fri, 9 Nov 2018 02:50:09 +0000 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: , Message-ID: Remember when AS 1 was Genuity? First BGP session I ever set-up was with AS 1. Get Outlook for Android ________________________________ From: NANOG on behalf of Ross Tajvar Sent: Thursday, November 8, 2018 6:44:45 PM To: Steve Meuse Cc: North American Network Operators' Group Subject: Re: Amazon now controls 3.0.0.0/8 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Speaking of AS1 - I've been wondering, what's it being used for? It looks like Level3 owns it, and it's announcing a handful of prefixes and peering with a bunch of random ASes from many different countries. On Thu, Nov 8, 2018 at 9:19 PM, Steve Meuse > wrote: John Orthoefer and I (and dozens of other BBN folks on this list) both worked for BBNPlanet at the time that 4.2.2.1 and 4.2.2.2 were assigned. John was one of the folks who built and ran that system. So when he said "I wish we could have used 4.4.4.4" and my comment of "I think the dial modem folks beat us to..." was referring to the fact that when 4/8 was first being deployed on AS1 we started assigning blocks to various groups and they realized that 4.4.4.0/XX had already been delegated to another internal group (I think it was the dial group). On Thu, Nov 8, 2018 at 8:45 PM Tom Beecher wrote: 4.0.0.0/8 has been GTE/Level3 forever. 4.2.2.1 - 6 have been L3 DNS as far back as I can remember. On Thu, Nov 8, 2018 at 8:32 PM Todd Underwood > wrote: google used 4.4.4.4 for DNS in the past (2010, IIRC). t On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse > wrote: I think it was the dial modem team that beat us to 4.4.4.0/24? -Steve On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer > wrote: I wish we could have used 4.4.4.4. Although at the time I suspect we would have used 4.4.4.[123]. Johno On Nov 8, 2018, at 18:58, Matt Erculiani > wrote: So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS is incoming. -Matt On Thu, Nov 8, 2018, 17:54 Eric Kuhnke wrote: https://news.ycombinator.com/item?id=18407173 Quoting from the post: " Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. Previous owner was GE. Anecdotal reports across the Internet that AWS EIPs are now being assigned in that range. https://whois.arin.net/rest/net/NET-3-0-0-0-1.html https://whois.arin.net/rest/net/NET-3-128-0-0-1.html " -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethfinnegan2007 at gmail.com Fri Nov 9 13:58:05 2018 From: kennethfinnegan2007 at gmail.com (Kenneth Finnegan) Date: Fri, 9 Nov 2018 05:58:05 -0800 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: On Thu, Nov 8, 2018 at 3:58 PM Job Snijders wrote: > Seems ALTDB should delete the old AS 80 / GE IRR proxy route registration: > http://irrexplorer.nlnog.net/search/3.0.0.0 Done. For anyone else who is suffering from their prefixes malingering in ALTDB from previous users and has ultimately failed to resolve the issue with the maintainer of the object, you can escalate the matter to the db-admin at altdb.net alias. We have recently started a cleanup effort of the ALTDB database to improve the quality of the routing information present in it. -- Kenneth Finnegan ALTDB Admin From nanog at netfront.jp Fri Nov 9 15:03:12 2018 From: nanog at netfront.jp (im) Date: Sat, 10 Nov 2018 00:03:12 +0900 Subject: IGP protocol Message-ID: goodmorning nanog, I heard that OSPF is only famous in asia region... So that, please could you explain me 1. what is your backbone's IGP protocol? 2. why you choose it? thanks, From dshaw at jabberwocky.com Fri Nov 9 16:47:07 2018 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 9 Nov 2018 11:47:07 -0500 Subject: Oracle abuse contact Message-ID: <8C5442E4-1A69-4B78-B230-DC569DB95C37@jabberwocky.com> Hi, I could really use some help reaching someone at Oracle for a spam problem coming from 129.145.16.122. I've sent countless emails to their abuse contact with no response, tried their tech support chat system and even calling several times without any reaction beyond confusion. It's been almost two weeks now, and while I don't like asking on NANOG, I'm out of options. Any pointers would be very welcomed. David From mehmet at akcin.net Fri Nov 9 19:40:30 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 9 Nov 2018 11:40:30 -0800 Subject: Zayo vs Coent In-Reply-To: References: Message-ID: Using www.networkatlas.org and Zayo KMZs loaded, i can't see neither on this location (maybe they forgot to update the kmzs) [image: Screen Shot 2018-11-09 at 11.38.08 AM.png] You can join our Slack Channel , there are many people who has regional dark fibre knowledge (100+ people) across the world. To discuss further, https://join.slack.com/t/networkatlas/shared_invite/enQtNDUwOTIzMDEwODM4LWE5NjNmOWRkMmQxYmYzYWU1YmI0ZmEwNWVlODllY2U1MGU5OTVhZDk4YjA1ZmFiN2VhYWI5ZWUyMGQ0YjU0OTc On Fri, Nov 9, 2018 at 11:27 AM Matt Erculiani wrote: > $dayjob hat off: I'll add that they often times use the same fiber for the > last mile (hence why they're both on-net at that building), so if you get > both with the intention of redundancy, you could potentially be taken out > by a single cut unless you harp on the point that they need to be fiber > diverse and asking for proof (drawings, etc.) never hurts. > > On Fri, Nov 9, 2018 at 1:05 PM Kushal R. wrote: > >> Comparing networks and performance I believe zayo will outperform Cogent >> in most places but I’ve heard nightmares about dealing with Zayo’s account >> managers and billing reps. >> >> Cogent is great at their price point and you will get a very sweet deal >> for a 10G circuit and their account managers and NOC both have been great >> for us. >> >> On Fri, 9 Nov 2018 at 7:21 PM, Dovid Bender wrote: >> >>> Hi, >>> >>> We are in a facility where my only options are Cogent or Zayo. We plan >>> on getting a 10G connection for a web crawler using v4 only. Looking for >>> feedback on either or (keeping the politics out of it). >>> >>> TIA. >>> >>> Dovid >>> >>> -- >> -- >> [image: Host4Geeks] >> >> Kushal R >> Chief Executive | Host4Geeks >> site: host4geeks.com >> email: kushal.r at h4g.co >> skype: kush.raha >> [image: linkedin] >> >> [image: facebook] >> [image: twitter] >> [image: instagram] >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at via.net Sun Nov 11 01:29:02 2018 From: joe at via.net (joe mcguckin) Date: Sat, 10 Nov 2018 17:29:02 -0800 Subject: Zayo vs Coent Message-ID: <28983C1B-55DE-4E49-9EB1-FB6067C1BA2E@via.net> Zayo is not merely Above.net . Zayo is a massive rollup of many fiber providers. It has acquired over 30 other networks. Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax -------------- next part -------------- An HTML attachment was scrubbed... URL: From fireballiso at yahoo.com Mon Nov 12 02:54:51 2018 From: fireballiso at yahoo.com (fireballiso) Date: Sun, 11 Nov 2018 21:54:51 -0500 Subject: Windows sometimes lets temporary IPv6 addresses expire without renewing Message-ID: <78b9b068-0a85-7c1c-981e-a1107a15d7d4@yahoo.com> Hi! I'm experiencing an IPv6 issue with Windows that I wanted to ask if others are seeing, and get an idea of how widespread it might be. For background, I've been using a /64 tunnel from Hurricane for a few years to test IPv6 connectivity until my ISP offers native service. Linux works well with IPv6. However, I've isolated a problem in Windows 10 (version 1803, build 17134.345) where the Preferred Lifetime of *temporary* IPv6 addresses don't seem to be renewed properly sometimes. The Valid Life will start counting down again from 24 hours, but the Pref Life will stay at 0s; in this condition, the temporary addresses don't work on that interface until I disable and then re-enable it. Output of "netsh int ipv6 show addr", formatted to fit and for privacy: Addr Type   DAD State     Valid Life     Pref. Life   Address ---------   -----------   -----------    ---------- ------- Public      Preferred     23h58m22s   3h58m22s 2001:470:X:X:X:X:X:7a20 Temporary   Deprecated   23h58m22s         0s       2001:470:X:X:bc72:8f4:7d98:3445 Public      Preferred     23h58m22s   3h58m22s fd00:X::X:X:X:7a20 Temporary   Deprecated   23h58m22s         0s     fd00:X::bc72:8f4:7d98:3445 Other       Preferred     infinite       infinite     fe80::X:X:X:7a20%13 In this state, the Public addresses usually work, but these addresses don't change, so some privacy is lost. Occasionally, even the Public addresses stop working, (though the Valid and Pref Life values still have time left), which requires me to disable/enable the interface to regain any IPv6 connectivity to the internet. I've noticed some bug reports stating that the temporary address stops working after a while, but none I've found show the Pref Life staying on 0. Has anyone else seen this bug? Any idea whether there's a fix or workaround, other than an interface disable/re-enable? -- -Indy fireballiso at yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fireballiso at yahoo.com Mon Nov 12 03:06:19 2018 From: fireballiso at yahoo.com (fireballiso) Date: Sun, 11 Nov 2018 22:06:19 -0500 Subject: Windows sometimes lets temporary IPv6 addresses expire without renewing In-Reply-To: <78b9b068-0a85-7c1c-981e-a1107a15d7d4@yahoo.com> References: <78b9b068-0a85-7c1c-981e-a1107a15d7d4@yahoo.com> Message-ID: <88d2b583-a2d0-3d17-8ded-45fa2f25219c@yahoo.com> On 11/11/2018 9:54 PM, fireballiso wrote: > Hi! I'm experiencing an IPv6 issue with Windows that I wanted to ask if > others are seeing, and get an idea of how widespread it might be. > > For background, I've been using a /64 tunnel from Hurricane for a few > years to test IPv6 connectivity until my ISP offers native service. > > Linux works well with IPv6. However, I've isolated a problem in > Windows 10 (version 1803, build 17134.345) where the Preferred Lifetime > of *temporary* IPv6 addresses don't seem to be renewed properly > sometimes. The Valid Life will start counting down > again from 24 hours, but the Pref Life will stay at 0s; in this > condition, the temporary addresses don't work on that interface until I > disable and then re-enable it. > > Output of "netsh int ipv6 show addr", formatted to fit and for privacy: > > Addr Type   DAD State     Valid Life     Pref. Life   Address > ---------   -----------   -----------    ---------- ------- > Public      Preferred     23h58m22s   3h58m22s 2001:470:X:X:X:X:X:7a20 > Temporary   Deprecated   23h58m22s         0s       2001:470:X:X:bc72:8f4:7d98:3445 > Public      Preferred     23h58m22s   3h58m22s fd00:X::X:X:X:7a20 > Temporary   Deprecated   23h58m22s         0s     fd00:X::bc72:8f4:7d98:3445 > Other       Preferred     infinite       infinite     fe80::X:X:X:7a20%13 > > In this state, the Public addresses usually work, but these addresses don't > change, so some privacy is lost. Occasionally, even the Public addresses > stop working, (though the Valid and Pref Life values still have time left), > which requires me to disable/enable the interface to regain any IPv6 > connectivity to the internet. > > I've noticed some bug reports stating that the temporary address stops working > after a while, but none I've found show the Pref Life staying on 0. > > Has anyone else seen this bug? Any idea whether there's a fix or > workaround, other than an interface disable/re-enable? > -- > -Indy > fireballiso at yahoo.com To clarify: when I say "renew", I really mean "countdown reset to 4 hours again, and a new temporary IPv6 address assigned to allow continued connectivity with a temporary address". Sorry for the vague language. -- -Indy fireballiso at yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From morgan.miskell at caro.net Mon Nov 12 16:30:56 2018 From: morgan.miskell at caro.net (Morgan A. Miskell) Date: Mon, 12 Nov 2018 11:30:56 -0500 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: <33C8854C-0093-4F5F-92B3-6312AD26CA44@puck.nether.net> References: <33C8854C-0093-4F5F-92B3-6312AD26CA44@puck.nether.net> Message-ID: <968c4127-89ae-434b-34d7-fd7df670d70c@caro.net> Not to beat a dead horse, but could the problem be so simple? I have tons of dual-stacked machines that have updated forever without issue, so I assume they update via IPV4. That being said, I've not packet sniffed any of the update stuff in a while but if the DNS is any indication then dual-stacked machines can update via IPV4 while IPV6 ONLY machines will likely fail since the DNS shows IPV4 only.... host windowsupdate.microsoft.com windowsupdate.microsoft.com is an alias for windowsupdate.redir.update.microsoft.com.nsatc.net. windowsupdate.redir.update.microsoft.com.nsatc.net is an alias for redir.update.microsoft.com.nsatc.net. redir.update.microsoft.com.nsatc.net has address 157.56.77.153 On 11/11/2018 01:35 PM, Jared Mauch wrote: > > >> On Nov 11, 2018, at 8:45 AM, Mark Tinka wrote: >> >> >> >> On 11/Nov/18 14:02, Chris Knipe wrote: >> >>> Also no problems here with IPv6 and Windows Updates... >> >> The issue is affecting (and has affected) quite a few folk: >> >> https://social.technet.microsoft.com/Forums/windowsserver/en-US/a9b1b537-ad27-4718-821b-57ef33174974/windows-update-fails-if-ipv6-is-enabled?forum=w8itpronetworking >> https://social.technet.microsoft.com/Forums/office/en-US/16e7aa06-9b90-48f8-8370-76c2329b93a8/windows-update-ipv6?forum=ws2016 >> https://answers.microsoft.com/en-us/windows/forum/all/windows-8-pro-windows-update-fails-if-ipv6-is/7ebdac22-6675-402b-ad43-e3fa8450659d >> >> It occurs to me that this, could, perhaps be CDN specific. >> >> I'm currently not in Johannesburg, but last time I checked, the majority of Windows updates were being handled by Akamai. Perhaps this is where the issue could be, although we have got local IPv6 peering with Akamai and don't generally have issues with it. >> >> I'll dig deeper into how Akamai may be involved when I get back home. > > Let me know if you see anything related to Akamai. Looking at these threads I don’t see anything really obvious and some are much older posts. > > - Jared > -- 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 john at essenz.com Mon Nov 12 19:08:01 2018 From: john at essenz.com (John Von Essen) Date: Mon, 12 Nov 2018 14:08:01 -0500 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> Message-ID: <48725bf5-7e4f-60aa-cbee-066060ccaadf@essenz.com> I recently go a Linksys home wifi router, by default it enables ipv6 on the LAN. If there is no native IPv6 on the WAN side (which is my case since FiOS doesnt do v6 yet) the Linksys defaults to a v6 tunnel. For the first few weeks of using the router, I had no idea alot of my traffic was going out via the v6 tunnel. Then I started getting random reachability and availability issues. Google would not load, but Bing and Yahoo would, and so on. I thought it was a FiOS issue, but after digging, I discovered the v6 tunnel, disabled it and all my issues went away. I dont know what Linksys uses for the v6 tunnel because its buried in the firmware, but any tunnel service is vulnerable to a variety of issues that could effect access. Its odd that it always effects Windows update all the time, but who knows. -John On 11/12/18 1:18 PM, Mark Tinka wrote: > > > On 11/Nov/18 18:51, Lavanauts wrote: > >> I’m on native IPv6 via Spectrum and have no problems with Windows >> Updates.  Could this be a tunneling issue? > > I do run 6-in-4 from my backbone to my house as my FTTH provider does > not do IPv6. > > I can't imagine this to specifically be the issue, as all other IPv6 > traffic is fine, but at this point, I'm open to suggestion. > > Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at quonix.net Fri Nov 9 19:24:45 2018 From: john at quonix.net (John Von Essen) Date: Fri, 9 Nov 2018 14:24:45 -0500 Subject: Zayo vs Coent In-Reply-To: References: Message-ID: Zayo is probably a tad better in the network quality, but… Zayo’s NCC is awful when it comes to fixing or resolving anything, even something as simply as add a default route to my BGP session. And its takes forever, like a whole day waiting in queue. Cogent, you can call, and 15 minutes your done. -John > On Nov 9, 2018, at 1:18 PM, Dovid Bender wrote: > > Hi, > > We are in a facility where my only options are Cogent or Zayo. We plan on getting a 10G connection for a web crawler using v4 only. Looking for feedback on either or (keeping the politics out of it). > > TIA. > > Dovid > From JRodenhuis at atlanticbb.com Mon Nov 12 15:56:32 2018 From: JRodenhuis at atlanticbb.com (Rodenhuis, John) Date: Mon, 12 Nov 2018 15:56:32 +0000 Subject: RWHOIS Message-ID: <6948E8A16222A24C81038031162C0D323EC9C133@ABBEXCH01.abb.msad> Greetings list! We are testing implementation of an RWHOIS server to eliminating having to send SWIP emails to ARIN. Looking to see if anyone else is (successfully) using RWHOIS 1.5, and can hopefully provide any lessons-learned. Any other feedback would be welcomed. Thanks, John John Rodenhuis Sr. Broadband Operations Manager Atlantic Broadband w. 603.330.7702 | c. 603.767.6042 -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Mon Nov 12 19:48:43 2018 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 12 Nov 2018 20:48:43 +0100 (CET) Subject: IGP protocol In-Reply-To: References: Message-ID: On Sat, 10 Nov 2018, im wrote: > goodmorning nanog, > > I heard that OSPF is only famous in asia region... > So that, please could you explain me > > 1. what is your backbone's IGP protocol? > 2. why you choose it? This is a 20+ year old discussion. There are lots of comparisons. https://nsrc.org/workshops/2017/ubuntunet-bgp-nrens/networking/nren/en/presentations/08-ISIS-vs-OSPF.pdf https://www.nanog.org/meetings/nanog49/presentations/Sunday/Shamim_Which_Routing_N49.pdf https://www.nada.kth.se/kurser/kth/2D1490/03/papers/Comparitive_Study_of_OSPF_and_ISIS.txt -- Mikael Abrahamsson email: swmike at swm.pp.se From jared at puck.nether.net Mon Nov 12 19:50:37 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 12 Nov 2018 14:50:37 -0500 Subject: IGP protocol In-Reply-To: References: Message-ID: > On Nov 9, 2018, at 10:03 AM, im wrote: > > goodmorning nanog, > > I heard that OSPF is only famous in asia region... > So that, please could you explain me > > 1. what is your backbone's IGP protocol? IS-IS > 2. why you choose it? Single topology, supported by everything for IPv6 and IP(classic). - jared From ryan at kearney.io Mon Nov 12 19:56:32 2018 From: ryan at kearney.io (Ryan Kearney) Date: Mon, 12 Nov 2018 13:56:32 -0600 Subject: IGP protocol In-Reply-To: References: Message-ID: 1. IS-IS for loopbacks and iBGP on the loopbacks for everything else. 2. It was much easier to use than OSPF and seems to scale better. On Mon, Nov 12, 2018 at 1:46 PM im wrote: > > goodmorning nanog, > > I heard that OSPF is only famous in asia region... > So that, please could you explain me > > 1. what is your backbone's IGP protocol? > 2. why you choose it? > > > thanks, From goemon at sasami.anime.net Mon Nov 12 20:03:33 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Mon, 12 Nov 2018 12:03:33 -0800 (PST) Subject: Oracle abuse contact In-Reply-To: <8C5442E4-1A69-4B78-B230-DC569DB95C37@jabberwocky.com> References: <8C5442E4-1A69-4B78-B230-DC569DB95C37@jabberwocky.com> Message-ID: Contact some DNSBLs? Sometimes it takes 550 responses to all their smtp connections for them to wake up from their slumber. -Dan On Fri, 9 Nov 2018, David Shaw wrote: > Hi, > > I could really use some help reaching someone at Oracle for a spam problem coming from 129.145.16.122. I've sent countless emails to their abuse contact with no response, tried their tech support chat system and even calling several times without any reaction beyond confusion. It's been almost two weeks now, and while I don't like asking on NANOG, I'm out of options. > > Any pointers would be very welcomed. > > David > > From SNaslund at medline.com Mon Nov 12 20:21:26 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 12 Nov 2018 20:21:26 +0000 Subject: IGP protocol In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> I don't know where you heard that but it is probably incorrect. Here is what I think you will find. 1. Most large networks (service providers) supporting MPLS will be using ISIS as their IGP. Some will have islands of OSPF because not everything speaks ISIS. 2. Most corporate networks will be running OSPF and/or EIGRP as an IGP. Steven Naslund Chicago IL -----Original Message----- From: NANOG On Behalf Of im Sent: Friday, November 9, 2018 9:03 AM To: nanog at nanog.org Subject: IGP protocol goodmorning nanog, I heard that OSPF is only famous in asia region... So that, please could you explain me 1. what is your backbone's IGP protocol? 2. why you choose it? thanks, From guillaume at ironie.org Mon Nov 12 20:22:19 2018 From: guillaume at ironie.org (Guillaume Tournat) Date: Mon, 12 Nov 2018 21:22:19 +0100 Subject: Escalation point at Google In-Reply-To: References: Message-ID: Hello Problem with blacklisted CA of Symantec, that issued SSL certificates ? > Le 9 nov. 2018 à 02:57, Alex Osipov a écrit : > > Hello – > > Does anyone have an escalation point or a human to speak to on the Google escalations or Google Safe Browsing team? Our entire SaaS business, 15 years in business, in a niche software industry with a good reputation has become blocked in ALL browsers. We are impacting 30k+ enterprise users in the financial space and have tried everything but all roads lead to automated systems. > > Can anyone please reach out with a contact if you have one? > > Sorry to spam this list if this is inappropriate content. Very desperate here. > > Thank you, > Alex Osipov / CTO -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Mon Nov 12 20:28:52 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 12 Nov 2018 15:28:52 -0500 Subject: IGP protocol In-Reply-To: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> Message-ID: <53381.1542054532@turing-police.cc.vt.edu> On Mon, 12 Nov 2018 20:21:26 +0000, "Naslund, Steve" said: > 2. Most corporate networks will be running OSPF and/or EIGRP as an IGP. And I'm sure there's still some crazies out there using RIPv2. :) -------------- 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 ntt.net Mon Nov 12 20:30:54 2018 From: job at ntt.net (Job Snijders) Date: Mon, 12 Nov 2018 21:30:54 +0100 Subject: IGP protocol In-Reply-To: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> Message-ID: The war is over. In IETF the OSPF and ISIS working groups merged. Now all of it is “link-state routing”. https://datatracker.ietf.org/group/lsr/about/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Mon Nov 12 20:35:47 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 12 Nov 2018 20:35:47 +0000 Subject: IGP protocol In-Reply-To: <53381.1542054532@turing-police.cc.vt.edu> References: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> <53381.1542054532@turing-police.cc.vt.edu> Message-ID: <9578293AE169674F9A048B2BC9A081B4030D42FAF8@MUNPRDMBXA1.medline.com> Yeah there are those. Steve -----Original Message----- From: Valdis Kletnieks On Behalf Of valdis.kletnieks at vt.edu Sent: Monday, November 12, 2018 2:29 PM To: Naslund, Steve Cc: nanog at nanog.org Subject: Re: IGP protocol On Mon, 12 Nov 2018 20:21:26 +0000, "Naslund, Steve" said: > 2. Most corporate networks will be running OSPF and/or EIGRP as an IGP. And I'm sure there's still some crazies out there using RIPv2. :) From george.herbert at gmail.com Mon Nov 12 20:44:29 2018 From: george.herbert at gmail.com (George Herbert) Date: Mon, 12 Nov 2018 12:44:29 -0800 Subject: Escalation point at Google In-Reply-To: References: Message-ID: If this is re os33.com where Alex emailed from, the front page is Lets Encrypt. Which is a strange choice for a financial SAAS?... Alex, if your internal app site certs are Symantec that could well explain it; check your cert locations. On Mon, Nov 12, 2018 at 12:30 PM Guillaume Tournat wrote: > Hello > > Problem with blacklisted CA of Symantec, that issued SSL certificates ? > > > > Le 9 nov. 2018 à 02:57, Alex Osipov a écrit : > > Hello – > > > > Does anyone have an escalation point or a human to speak to on the Google > escalations or Google Safe Browsing team? Our entire SaaS business, 15 > years in business, in a niche software industry with a good reputation has > become blocked in ALL browsers. We are impacting 30k+ enterprise users in > the financial space and have tried everything but all roads lead to > automated systems. > > > > Can anyone please reach out with a contact if you have one? > > > > Sorry to spam this list if this is inappropriate content. Very desperate > here. > > > > Thank you, > > Alex Osipov / CTO > > -- -george william herbert george.herbert at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwf at loonybin.net Mon Nov 12 20:45:53 2018 From: rwf at loonybin.net (Rob Foehl) Date: Mon, 12 Nov 2018 15:45:53 -0500 (EST) Subject: Zayo vs Coent In-Reply-To: References: Message-ID: On Fri, 9 Nov 2018, Ca By wrote: > Zayo will provide you all of the internet Only the parts for which someone has remembered to call in updates and/or which Zayo has remembered to apply to every manually maintained per-session prefix list, or for which someone has badgered them enough to switch to max prefixes only. They have an incurable allergy to IRR, and it's a bundle of fun to sort out when something gets missed. -Rob From jared at puck.nether.net Mon Nov 12 21:17:08 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 12 Nov 2018 16:17:08 -0500 Subject: Escalation point at Google In-Reply-To: References: Message-ID: <4B985ED7-B911-4D3A-8AD4-5D129087101C@puck.nether.net> Are they getting an error similar to: Websites prove their identity via certificates, which are issued by certificate authorities. Most browsers no longer trust certificates issued by GeoTrust, RapidSSL, Symantec, Thawte, and VeriSign. www.example.com uses a certificate from one of these authorities and so the website’s identity cannot be proven. You may want to check your site here: https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com - Jared > On Nov 12, 2018, at 3:44 PM, George Herbert wrote: > > If this is re os33.com where Alex emailed from, the front page is Lets Encrypt. Which is a strange choice for a financial SAAS?... > > Alex, if your internal app site certs are Symantec that could well explain it; check your cert locations. > > On Mon, Nov 12, 2018 at 12:30 PM Guillaume Tournat wrote: > Hello > > Problem with blacklisted CA of Symantec, that issued SSL certificates ? > > > > Le 9 nov. 2018 à 02:57, Alex Osipov a écrit : > >> Hello – >> >> >> >> Does anyone have an escalation point or a human to speak to on the Google escalations or Google Safe Browsing team? Our entire SaaS business, 15 years in business, in a niche software industry with a good reputation has become blocked in ALL browsers. We are impacting 30k+ enterprise users in the financial space and have tried everything but all roads lead to automated systems. >> >> >> >> Can anyone please reach out with a contact if you have one? >> >> >> >> Sorry to spam this list if this is inappropriate content. Very desperate here. >> >> >> >> Thank you, >> >> Alex Osipov / CTO >> > > > -- > -george william herbert > george.herbert at gmail.com From nickdwhite at gmail.com Mon Nov 12 22:19:55 2018 From: nickdwhite at gmail.com (Nick W) Date: Mon, 12 Nov 2018 17:19:55 -0500 Subject: Zayo vs Coent In-Reply-To: References: Message-ID: I actually went through this exercise recently with Cogent, Zayo, and two other providers. The requests were all made via email at roughly the same time. HE was by far the quickest (I think under an hour), with Cogent being about half a day initially (but they did miss a BGP session, which was fixed within a few hours of notifying them), and Zayo taking about 3 days, with a follow up call around the 2 day mark. >From an outage standpoint: I've had three outages with Zayo, the first being the most painful (left hand doesn't talk to right hand), the second was brief and they provided an RFO same-day, and the third being similar to the first, but resolved quicker because I was able to reference details from the first. I've never had total outages with Cogent on my transit, but I have on transport, and they were relatively quick to respond, resolve, or provide details from third-party providers each time. From a quality standpoint, I "feel" like the Zayo transit is better, but maybe that's because I pay more for it. I think from a peering standpoint, I tend to see better paths through Zayo. I've seen Cogent send traffic way out of region for several content providers - causing customers to complain about high latency to Google. Nick On Mon, Nov 12, 2018 at 3:09 PM John Von Essen wrote: > Zayo is probably a tad better in the network quality, but… Zayo’s NCC is > awful when it comes to fixing or resolving anything, even something as > simply as add a default route to my BGP session. And its takes forever, > like a whole day waiting in queue. Cogent, you can call, and 15 minutes > your done. > > -John > > > On Nov 9, 2018, at 1:18 PM, Dovid Bender wrote: > > > > Hi, > > > > We are in a facility where my only options are Cogent or Zayo. We plan > on getting a 10G connection for a web crawler using v4 only. Looking for > feedback on either or (keeping the politics out of it). > > > > TIA. > > > > Dovid > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Mon Nov 12 22:34:07 2018 From: marka at isc.org (Mark Andrews) Date: Tue, 13 Nov 2018 09:34:07 +1100 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: <48725bf5-7e4f-60aa-cbee-066060ccaadf@essenz.com> References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <48725bf5-7e4f-60aa-cbee-066060ccaadf@essenz.com> Message-ID: Which just shows content providers and tunnel end point problems. * load balancers that don’t properly handle ICMP{v6} * stupid firewalls that block PTB * tunnel end points that don’t generate PTB for EVERY oversize packet (you wouldn’t drop TCP ACKS and PTBs are just as important) PMTD requires PTBs to be generated. Report the problems so they can get fixed. Mark > On 13 Nov 2018, at 6:08 am, John Von Essen wrote: > > I recently go a Linksys home wifi router, by default it enables ipv6 on the LAN. If there is no native IPv6 on the WAN side (which is my case since FiOS doesnt do v6 yet) the Linksys defaults to a v6 tunnel. > > For the first few weeks of using the router, I had no idea alot of my traffic was going out via the v6 tunnel. > > Then I started getting random reachability and availability issues. Google would not load, but Bing and Yahoo would, and so on. I thought it was a FiOS issue, but after digging, I discovered the v6 tunnel, disabled it and all my issues went away. > I dont know what Linksys uses for the v6 tunnel because its buried in the firmware, but any tunnel service is vulnerable to a variety of issues that could effect access. Its odd that it always effects Windows update all the time, but who knows. > > -John > > On 11/12/18 1:18 PM, Mark Tinka wrote: >> >> >> On 11/Nov/18 18:51, Lavanauts wrote: >> >>> I’m on native IPv6 via Spectrum and have no problems with Windows Updates. Could this be a tunneling issue? >> >> I do run 6-in-4 from my backbone to my house as my FTTH provider does not do IPv6. >> >> I can't imagine this to specifically be the issue, as all other IPv6 traffic is fine, but at this point, I'm open to suggestion. >> >> Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From surfer at mauigateway.com Tue Nov 13 05:49:46 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 12 Nov 2018 21:49:46 -0800 Subject: IGP protocol Message-ID: <20181112214946.A597B44@m0117566.ppops.net> --- valdis.kletnieks at vt.edu wrote: On Mon, 12 Nov 2018 20:21:26 +0000, "Naslund, Steve" said: > 2. Most corporate networks will be running OSPF and/or EIGRP as an IGP. And I'm sure there's still some crazies out there using RIPv2. :) ---------------------------------------------- Yes, there are networks out there on the ragged edges doing that. They've been around since forever. I've worked for them. Show up on day 1: WTF??? Oh crap, what'd I get myself into *this* time?! scott From lists.nanog at monmotha.net Tue Nov 13 05:52:55 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 13 Nov 2018 00:52:55 -0500 Subject: IGP protocol In-Reply-To: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> Message-ID: <2e4e02b6-1c9f-771f-55e5-225415ec400e@monmotha.net> On 11/12/18 3:21 PM, Naslund, Steve wrote: > 1. Most large networks (service providers) supporting MPLS will be using ISIS as their IGP. Some will have islands of OSPF because not everything speaks ISIS. Notably, support for OSPF is somewhat common on "layer 3 switch" products while IS-IS support is significantly less common. Most "router" products seem to support either. I was of the impression that there was a draft or similar for single-topology (IPv4+IPv6) OSPF. Did anything ever come of that? -- Brandon Martin From garrett at skjelstad.org Tue Nov 13 06:25:39 2018 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Mon, 12 Nov 2018 22:25:39 -0800 Subject: IGP protocol In-Reply-To: <20181112214946.A597B44@m0117566.ppops.net> References: <20181112214946.A597B44@m0117566.ppops.net> Message-ID: To be fair, Microsoft only just recently added BGP support to RRAS in 2012... On Mon, Nov 12, 2018, 21:50 Scott Weeks > > --- valdis.kletnieks at vt.edu wrote: > On Mon, 12 Nov 2018 20:21:26 +0000, "Naslund, Steve" > said: > > > 2. Most corporate networks will be running OSPF > and/or EIGRP as an IGP. > > And I'm sure there's still some crazies out there > using RIPv2. :) > ---------------------------------------------- > > > Yes, there are networks out there on the ragged edges > doing that. They've been around since forever. I've > worked for them. Show up on day 1: WTF??? Oh crap, > what'd I get myself into *this* time?! > > scott > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Tue Nov 13 08:34:36 2018 From: aled.w.morris at googlemail.com (Aled Morris) Date: Tue, 13 Nov 2018 08:34:36 +0000 Subject: IGP protocol In-Reply-To: <2e4e02b6-1c9f-771f-55e5-225415ec400e@monmotha.net> References: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> <2e4e02b6-1c9f-771f-55e5-225415ec400e@monmotha.net> Message-ID: On Tue, 13 Nov 2018 at 05:54, Brandon Martin wrote: > I was of the impression that there was a draft or similar for > single-topology (IPv4+IPv6) OSPF. Did anything ever come of that? > > Juniper support IPv4 families ("realms") in OSPFv3. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Nov 13 10:34:14 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 13 Nov 2018 12:34:14 +0200 Subject: IGP protocol In-Reply-To: References: Message-ID: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> On 9/Nov/18 17:03, im wrote: > > 1. what is your backbone's IGP protocol? IS-IS. > 2. why you choose it? Main reasons:     - Stringy, i.e., no "all must pay taxes to Area 0" decree.     - Integrated for IPv4 and IPv6.     - Doesn't run over IP. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Nov 13 10:38:56 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 13 Nov 2018 12:38:56 +0200 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> Message-ID: On 12/Nov/18 20:34, Mikael Abrahamsson wrote: >   > > Are you doing TCP MSS adjust/clamping? If you don't, try that and see > if it helps. This might be a PMTUD issue. > > Otherwise if possible, try lowering the MTU sent in RA to the one you > have on your tunnel (this depends on if this is available to you in > your RA sending device). Thanks, Mikael. I'll have a sniff and see of this helps. Mark. From mark.tinka at seacom.mu Tue Nov 13 10:44:27 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 13 Nov 2018 12:44:27 +0200 Subject: IGP protocol In-Reply-To: <2e4e02b6-1c9f-771f-55e5-225415ec400e@monmotha.net> References: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> <2e4e02b6-1c9f-771f-55e5-225415ec400e@monmotha.net> Message-ID: On 13/Nov/18 07:52, Brandon Martin wrote: >   > > I was of the impression that there was a draft or similar for > single-topology (IPv4+IPv6) OSPF.  Did anything ever come of that? Multiple Address Families in OSPFv3. But NLRI is conveyed over IPv6, even for IPv4. First saw it in Junos 9, way back when. Mark. From bjorn at mork.no Tue Nov 13 11:40:37 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 13 Nov 2018 12:40:37 +0100 Subject: WIndows Updates Fail Via IPv6 In-Reply-To: <48725bf5-7e4f-60aa-cbee-066060ccaadf@essenz.com> (John Von Essen's message of "Mon, 12 Nov 2018 14:08:01 -0500") References: <502F6ADF-1417-4A0F-B125-A8B4CD872A1E@lavanauts.org> <48725bf5-7e4f-60aa-cbee-066060ccaadf@essenz.com> Message-ID: <875zx1fbnu.fsf@miraculix.mork.no> John Von Essen writes: > I recently go a Linksys home wifi router, by default it enables ipv6 > on the LAN. If there is no native IPv6 on the WAN side (which is my > case since FiOS doesnt do v6 yet) the Linksys defaults to a v6 tunnel. Could this be a 6RD tunnel requested by your ISP using DHCP with OPTION_6RD? Ref RFC5969 Setting up any tunnel to some pre-configured endpoint by default does not sound like a good idea.... But DHCP on the WAN side is "trusted", so configuring a DHCP requested tunnel by default is reasonable. > For the first few weeks of using the router, I had no idea alot of my > traffic was going out via the v6 tunnel. > > Then I started getting random reachability and availability > issues. Google would not load, but Bing and Yahoo would, and so on. I > thought it was a FiOS issue, but after digging, I discovered the v6 > tunnel, disabled it and all my issues went away. > > I dont know what Linksys uses for the v6 tunnel because its buried in > the firmware, but any tunnel service is vulnerable to a variety of > issues that could effect access. Its odd that it always effects > Windows update all the time, but who knows. It would be great to have more details about this default tunnel setup. Can't you sniff the traffic? Anyway: Thanks for yet another argument for native dual-stack. Avoiding such unwanted tunnels is really simple: If you're an ISP: Offer native dual-stack to your Internet access customers. If you're an Internet access customer: Request native dual-stack from your ISP Problem solved. Bjørn From saku at ytti.fi Tue Nov 13 12:07:20 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 13 Nov 2018 14:07:20 +0200 Subject: IGP protocol In-Reply-To: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> Message-ID: On Tue, 13 Nov 2018 at 12:37, Mark Tinka wrote: > Main reasons: > - Doesn't run over IP. Why is this upside? I've seen on two platforms (7600, MX) ISIS punted on routers running ISIS without interface having ISIS. With no ability to limit it, so any connected interface can DoS device with trivial pps rate, if ISIS is being ran. Are you testing this vector? Also, no one really understands how 802.3+CLNS interact with ISIS. It's probably globally dozen people, all open source implementations seem to copy from early Zebra implementation. And implementations are opportunistic, just enough to make it work, not actually enough to be standard compliant 802.3+CLNS. Just question of what is ES-IS role in all this, gives debates with subject matter experts. To me this is downside, I'd rather have ISIS run over EthernetII and IP. But at that point, why bother, why not just kill it and run OSPF3. I'm paying vendor to implement and maintain both protocols, and there does not seem to have good justification for both to exist. Disclaimer: all networks I've operated have been ISIS networks, and I'll continue using ISIS, not because I think it is better, but because I think the codebase gets more exposure in networks like the on I need to run. -- ++ytti From ahebert at pubnix.net Tue Nov 13 14:23:25 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 13 Nov 2018 09:23:25 -0500 Subject: IGP protocol In-Reply-To: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> Message-ID: <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net>     Hi,     For those that got involved in fixing a network that goes down due to OSPF spoofed packets...  (Before OSPFv2|3)     + Security for IS-IS ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 11/13/18 05:34, Mark Tinka wrote: > > > On 9/Nov/18 17:03, im wrote: > >> 1. what is your backbone's IGP protocol? > > IS-IS. > >> 2. why you choose it? > > Main reasons: > >     - Stringy, i.e., no "all must pay taxes to Area 0" decree. >     - Integrated for IPv4 and IPv6. >     - Doesn't run over IP. > > Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvernhout at gmail.com Tue Nov 13 14:46:24 2018 From: zvernhout at gmail.com (Matt Vernhout) Date: Tue, 13 Nov 2018 09:46:24 -0500 Subject: Oracle abuse contact In-Reply-To: <8C5442E4-1A69-4B78-B230-DC569DB95C37@jabberwocky.com> References: <8C5442E4-1A69-4B78-B230-DC569DB95C37@jabberwocky.com> Message-ID: David, I sent your note to a person at Oracle that should be able to dig into it. Cheers, ~ Matt Vernhout http://www.emailkarma.net Twitter: @emailkarma On Mon, Nov 12, 2018 at 2:48 PM David Shaw wrote: > Hi, > > I could really use some help reaching someone at Oracle for a spam problem > coming from 129.145.16.122. I've sent countless emails to their abuse > contact with no response, tried their tech support chat system and even > calling several times without any reaction beyond confusion. It's been > almost two weeks now, and while I don't like asking on NANOG, I'm out of > options. > > Any pointers would be very welcomed. > > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Tue Nov 13 15:30:41 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 13 Nov 2018 17:30:41 +0200 Subject: IGP protocol In-Reply-To: <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> Message-ID: On Tue, 13 Nov 2018 at 16:27, Alain Hebert wrote: > For those that got involved in fixing a network that goes down due to OSPF spoofed packets... (Before OSPFv2|3) > + Security for IS-IS Do you know connected host can't talk ISIS to you? ISIS is false security. In modern platforms OSPF almost always can be protected (iACL), ISIS in many times cannot. I'd run MD5 in either case. -- ++ytti From hank at efes.iucc.ac.il Tue Nov 13 16:57:53 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 13 Nov 2018 18:57:53 +0200 Subject: =?UTF-8?Q?Re:_China_=e2=80=99s_Maxim_=e2=80=93_Leave_No_Access_Poin?= =?UTF-8?Q?t_Unexploited:_The_Hidden_Story_of_China_Telecom=e2=80=99_s_BGP_H?= =?UTF-8?Q?ijacking?= In-Reply-To: <45291847-3736-f676-a494-482b6b4c26e7@fud.no> References: <45291847-3736-f676-a494-482b6b4c26e7@fud.no> Message-ID: <4851c2c6-0403-705e-a448-4a94c8383741@efes.iucc.ac.il> On 05/11/2018 10:54, Tore Anderson wrote: > * Harley H > >> Curious to hear others' thoughts on this.  >> https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca >> >> This paper presents the view that several BGP hijacks performed by China Telecom had malicious intent. The incidents are: >> * Canada to Korea - 2016 >> * US to Italy - Oct 2016 >> * Scandinavia to Japan - April-May 2017 >> * Italy to Thailand - April-July 2017 >> >> The authors claim this is enabled by China Telecom's presence in North America. > Hi, > > I looked a bit into the Scandinavia to Japan claim last week for a Norwegian > journalist, who obviously found this rather sensational claim very intriguing. > The article (Norwegian, but Google Translate does a decent job) is found at > https://www.digi.no/artikler/internettrafikk-fra-norge-og-sverige-ble-kapret-og-omdirigert-til-kina/449797?key=vS1EOiG1 > in case you're interested. > > >From what I can tell from looking at routeviews data from the period, what > happened was that SK Broadband (AS9318) was leaking a bunch of routes to > China Telecom (AS4134). The leak included the transit routes from SKB's > upstream Verizon (AS703) and customers of theirs in turn, including well- > known organisations such as Bloomberg (AS10361) and Time Warner (AS36032), > which I suppose might be the ones the paper is referring to. > > The routes in question then propagated from CT to Telia Carrier (AS1299), > probably in North America somewhere. Scandinavia is TC's home turf, it > makes sense that the detour via CT was easily observed from here. > > If you want to see for yourself, look for «1299 4134 9318 703» in > http://archive.routeviews.org/route-views.linx/bgpdata/2017.04/RIBS/rib.20170430.2200.bz2 > > Anyway, in my opinion the data for this particular incident (I haven't > looked into the other three) does not indicate foul play on CT's behalf, > but rather a pretty standard leak by SKB followed by sloppy filtering > by CT and TC both. > > Tore > Internet Vulnerability Takes Down Google https://blog.thousandeyes.com/internet-vulnerability-takes-down-google/ -Hank From morrowc.lists at gmail.com Tue Nov 13 17:53:04 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 13 Nov 2018 12:53:04 -0500 Subject: =?UTF-8?Q?Re=3A_China_=E2=80=99s_Maxim_=E2=80=93_Leave_No_Access_Point_Unexp?= =?UTF-8?Q?loited=3A_The_Hidden_Story_of_China_Telecom=E2=80=99_s_BGP_Hijacking?= In-Reply-To: <4851c2c6-0403-705e-a448-4a94c8383741@efes.iucc.ac.il> References: <45291847-3736-f676-a494-482b6b4c26e7@fud.no> <4851c2c6-0403-705e-a448-4a94c8383741@efes.iucc.ac.il> Message-ID: > > > Internet Vulnerability Takes Down Google > https://blog.thousandeyes.com/internet-vulnerability-takes-down-google/ > > I think this was actually just: "neighbor leaked routes beyond where they should have" which means, of course, that 'transit provider is not filtering their customer'. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at wi-fiber.io Tue Nov 13 18:18:24 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 13 Nov 2018 11:18:24 -0700 Subject: Fitbit network contact Message-ID: Hoping to see if an network engineer from fitbit is on list. Our customers are having trouble logging into your app on our network. Perhaps an IP filtering/routing issue. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From royboy at umich.edu Tue Nov 13 20:19:38 2018 From: royboy at umich.edu (Roy Hockett) Date: Tue, 13 Nov 2018 15:19:38 -0500 Subject: verizon AS701 looking glass sever Message-ID: Does anyone have a bookmark for a looking glass server for Verizon/UUnet (AS701)? If someone from Verizon/UUnet noc can contact me offline, that would also be helpful. From morrowc.lists at gmail.com Wed Nov 14 03:06:07 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 13 Nov 2018 22:06:07 -0500 Subject: verizon AS701 looking glass sever In-Reply-To: References: Message-ID: On Tue, Nov 13, 2018 at 3:19 PM Roy Hockett wrote: > Does anyone have a bookmark for a looking glass server for Verizon/UUnet > (AS701)? > > don't think there's really ever been one (there was a web-based lookup ... based on not-real-time data) but I believe that's gone. how about their routeviews peer though? 137.39.3.55 4 701 682105 11481 6892886 0 0 1w0d 712935 If someone from Verizon/UUnet noc can contact me offline, that would also > be helpful. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfie at fdx.services Wed Nov 14 10:18:57 2018 From: alfie at fdx.services (Alfie Pates) Date: Wed, 14 Nov 2018 10:18:57 +0000 Subject: =?utf-8?Q?Re=3A=20China=20=E2=80=99s=20Maxim?= =?utf-8?Q?=20=E2=80=93=20Leave=20No=20Access?= =?utf-8?Q?=20Point=20Unexploited?= =?utf-8?Q?=3A=20The=20Hidden=20Story?= =?utf-8?Q?=20of=20China=20Telecom=E2=80=99?= =?utf-8?Q?=20s=20BGP=20Hijacking?= Message-ID: <1542190737.3349362.1576467080.5A3A4420@webmail.messagingengine.com> Never attribute to malice that which can be adequately explained by apathy. ~A -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwbensley at gmail.com Wed Nov 14 13:53:54 2018 From: jwbensley at gmail.com (James Bensley) Date: Wed, 14 Nov 2018 13:53:54 +0000 Subject: IGP protocol In-Reply-To: References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> Message-ID: On Tue, 13 Nov 2018 at 12:09, Saku Ytti wrote: > > On Tue, 13 Nov 2018 at 12:37, Mark Tinka wrote: > > > Main reasons: > > - Doesn't run over IP. > > Why is this upside? I've seen on two platforms (7600, MX) ISIS punted > on routers running ISIS without interface having ISIS. With no > ability to limit it, so any connected interface can DoS device with > trivial pps rate, if ISIS is being ran. I guess the OPs original question wasn't clear enough because, I think most people are talking about IS-IS vs OSPF2/3 from a theoretical protocol perspective, and you're talking from a practical vendor implementation perspective. >From a purely theoretical perspective I see IS-IS not running over IP as an advantage too. No mater what routes I inject into my IGP, IS-IS won't stop working. I may totally fsck my IP reachability but IS-IS will still work, which means that when I fix the issue, service should be restored quite quickly. Several networks I've seen place management in a VRF / L3 VPN, which means that by the time you have remote management access, everything else is already working, it's like the last thing to come up when there's been a problem. I like the "management in the IGP + IS-IS" design. However, in reality the vendor implementation blows the protocol design out of the water. You need to consider both when evaluating a new IGP. Cisco nearly implemented a handy feature with prefix-suppression, whereby in IOS for OSPF only one would prevent p-t-p links being advertised into the IGP database. But they didn't implement this for IS-IS. Then in IOS-XR they removed this feature from OSPF and implemented it for IS-IS ?!?! So yeah, vendors implementations are just as important and the theoretical potential of the protocol. Oh yeah, forgot to answer the original question. For a greenfield deployment I'd be happy with either OSPFv3 or IS-IS as long as it's well designed I don't see much between them, it would come down to vendor support then. Cheers, James. From nanog at netfront.jp Wed Nov 14 00:24:44 2018 From: nanog at netfront.jp (im) Date: Wed, 14 Nov 2018 09:24:44 +0900 Subject: IGP protocol In-Reply-To: References: Message-ID: Thanks for all to letting me know. I have operating OSPF/iBGP backbone for 10+ years, now my brain has entrenched to OSPF. Now, I beginning to learn IS-IS for more knowledge. thanks! On Sat, Nov 10, 2018 at 12:03 AM im wrote: > > goodmorning nanog, > > I heard that OSPF is only famous in asia region... > So that, please could you explain me > > 1. what is your backbone's IGP protocol? > 2. why you choose it? > > > thanks, From toebinoz at gmail.com Tue Nov 13 10:49:59 2018 From: toebinoz at gmail.com (Tashi Phuntsho) Date: Tue, 13 Nov 2018 20:49:59 +1000 Subject: IGP protocol In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B4030D42FA0F@MUNPRDMBXA1.medline.com> <2e4e02b6-1c9f-771f-55e5-225415ec400e@monmotha.net> Message-ID: <436098F3-BEC3-4B3F-9194-2B0B3D56B67B@gmail.com> > On 13 Nov 2018, at 6:34 pm, Aled Morris via NANOG wrote: > > On Tue, 13 Nov 2018 at 05:54, Brandon Martin > wrote: > I was of the impression that there was a draft or similar for > single-topology (IPv4+IPv6) OSPF. Did anything ever come of that? > > > Juniper support IPv4 families ("realms") in OSPFv3. Available on IOS too. Problem for an ISP (OSPFv3 with AFs): if v6 breaks, v4 breaks too since OSPFv3 runs over v6 (even when carrying v4 AF)? Better with separate OSPFv2 and v3 instances. — Tashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From toebinoz at gmail.com Tue Nov 13 11:07:43 2018 From: toebinoz at gmail.com (Tashi Phuntsho) Date: Tue, 13 Nov 2018 21:07:43 +1000 Subject: IGP protocol In-Reply-To: References: Message-ID: <7B88E887-8FE8-41B4-89B5-DE6BCF838F32@gmail.com> From Asia region (Bhutan): > On 10 Nov 2018, at 1:03 am, im wrote: > > I heard that OSPF is only famous in asia region… Not necessarily :-) > 1. what is your backbone's IGP protocol? IS-IS > 2. why you choose it? OSPFv3 was quite flaky (could have been OS bugs), and there wasn’t v4 support until rfc5838, so migrated to IS-IS when deploying v6 (with Philip Smith’s help). But preferred multi topology to allow for incremental v6 deployment (without affecting v4). — Tashi From surfer at mauigateway.com Wed Nov 14 20:00:20 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 14 Nov 2018 12:00:20 -0800 Subject: =?utf-8?B?UmU6IENoaW5hIOKAmXMgTWF4aW0g4oCTIExlYXZlIE5vIEFjY2VzcyBQb2ludCBVbmV4?= =?utf-8?B?cGxvaXRlZDogVGhlIEhpZGRlbiBTdG9yeSBvZiBDaGluYSBUZWxlY29t4oCZIHMgQg==?= =?utf-8?B?R1AgSGlqYWNraW5n?= Message-ID: <20181114120020.1004E7FE@m0117458.ppops.net> --- alfie at fdx.services wrote: From: Alfie Pates Never attribute to malice that which can be adequately explained by apathy. ------------------------------------------- Especially when they can do it without being seen as was discussed here years ago. I believe this was one of the discussions? https://www.nanog.org/meetings/nanog44/presentations/Tuesday/Kapela_steal_internet_N44.pdf scott From baldur.norddahl at gmail.com Thu Nov 15 01:51:28 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 15 Nov 2018 02:51:28 +0100 Subject: IGP protocol In-Reply-To: References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> Message-ID: We run a MPLS enabled network with internet in a VRF. Management is in VRF default (no VRF). The IGP is OSPFv2. IPv6 is handled by the L3VPN functionality of MPLS. So is IPv4. The IPv4 that is controlled by OSPF is totally separate from everything except management and could really be any protocol. For a small network like ours, with everything in area 0 and VRF/L3VPN to handle dual stack, there is zero differences between is-is and OSPF. The IPv4 management network is not any more reachable than the is-is protocol. There are no raw IPv6 packets on the wire and no need for the IGP to handle IPv6. Also not true that the management network is the last thing to boot. In contrary, everything else depends on that being ready first. And that would also be true if we used is-is. We chose OSPF because it was one less protocol to learn and one less ethernet type on the wire. But really it could be toss a coin. Regards Baldur ons. 14. nov. 2018 14.55 skrev James Bensley : > On Tue, 13 Nov 2018 at 12:09, Saku Ytti wrote: > > > > On Tue, 13 Nov 2018 at 12:37, Mark Tinka wrote: > > > > > Main reasons: > > > - Doesn't run over IP. > > > > Why is this upside? I've seen on two platforms (7600, MX) ISIS punted > > on routers running ISIS without interface having ISIS. With no > > ability to limit it, so any connected interface can DoS device with > > trivial pps rate, if ISIS is being ran. > > I guess the OPs original question wasn't clear enough because, I think > most people are talking about IS-IS vs OSPF2/3 from a theoretical > protocol perspective, and you're talking from a practical vendor > implementation perspective. > > From a purely theoretical perspective I see IS-IS not running over IP > as an advantage too. No mater what routes I inject into my IGP, IS-IS > won't stop working. I may totally fsck my IP reachability but IS-IS > will still work, which means that when I fix the issue, service should > be restored quite quickly. Several networks I've seen place management > in a VRF / L3 VPN, which means that by the time you have remote > management access, everything else is already working, it's like the > last thing to come up when there's been a problem. I like the > "management in the IGP + IS-IS" design. > > However, in reality the vendor implementation blows the protocol > design out of the water. You need to consider both when evaluating a > new IGP. Cisco nearly implemented a handy feature with > prefix-suppression, whereby in IOS for OSPF only one would prevent > p-t-p links being advertised into the IGP database. But they didn't > implement this for IS-IS. Then in IOS-XR they removed this feature > from OSPF and implemented it for IS-IS ?!?! So yeah, vendors > implementations are just as important and the theoretical potential of > the protocol. > > Oh yeah, forgot to answer the original question. For a greenfield > deployment I'd be happy with either OSPFv3 or IS-IS as long as it's > well designed I don't see much between them, it would come down to > vendor support then. > > Cheers, > James. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav.ulander at telecomputing.se Thu Nov 15 02:05:59 2018 From: gustav.ulander at telecomputing.se (Gustav Ulander) Date: Thu, 15 Nov 2018 02:05:59 +0000 Subject: SV: IGP protocol In-Reply-To: References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> Message-ID: Hello all. We also run a small network (sub 50 PEs) It looks pretty similar to Baldurs except we run IS-IS instead of OSPF. IPV4 only in the global table with VPNV4 and VPNv6 services running on top of it. We do run a separate OBM network to handle management without being dependent on service infrastructure for management. Only real difference we notice is that Cisco seem to roll out service provider features and knobs for IS-IS first and then eventually for OSPF. Good or bad is the question. //Gustav Från: NANOG För Baldur Norddahl Skickat: den 15 november 2018 02:51 Till: nanog at nanog.org Ämne: Re: IGP protocol We run a MPLS enabled network with internet in a VRF. Management is in VRF default (no VRF). The IGP is OSPFv2. IPv6 is handled by the L3VPN functionality of MPLS. So is IPv4. The IPv4 that is controlled by OSPF is totally separate from everything except management and could really be any protocol. For a small network like ours, with everything in area 0 and VRF/L3VPN to handle dual stack, there is zero differences between is-is and OSPF. The IPv4 management network is not any more reachable than the is-is protocol. There are no raw IPv6 packets on the wire and no need for the IGP to handle IPv6. Also not true that the management network is the last thing to boot. In contrary, everything else depends on that being ready first. And that would also be true if we used is-is. We chose OSPF because it was one less protocol to learn and one less ethernet type on the wire. But really it could be toss a coin. Regards Baldur ons. 14. nov. 2018 14.55 skrev James Bensley >: On Tue, 13 Nov 2018 at 12:09, Saku Ytti > wrote: > > On Tue, 13 Nov 2018 at 12:37, Mark Tinka > wrote: > > > Main reasons: > > - Doesn't run over IP. > > Why is this upside? I've seen on two platforms (7600, MX) ISIS punted > on routers running ISIS without interface having ISIS. With no > ability to limit it, so any connected interface can DoS device with > trivial pps rate, if ISIS is being ran. I guess the OPs original question wasn't clear enough because, I think most people are talking about IS-IS vs OSPF2/3 from a theoretical protocol perspective, and you're talking from a practical vendor implementation perspective. From a purely theoretical perspective I see IS-IS not running over IP as an advantage too. No mater what routes I inject into my IGP, IS-IS won't stop working. I may totally fsck my IP reachability but IS-IS will still work, which means that when I fix the issue, service should be restored quite quickly. Several networks I've seen place management in a VRF / L3 VPN, which means that by the time you have remote management access, everything else is already working, it's like the last thing to come up when there's been a problem. I like the "management in the IGP + IS-IS" design. However, in reality the vendor implementation blows the protocol design out of the water. You need to consider both when evaluating a new IGP. Cisco nearly implemented a handy feature with prefix-suppression, whereby in IOS for OSPF only one would prevent p-t-p links being advertised into the IGP database. But they didn't implement this for IS-IS. Then in IOS-XR they removed this feature from OSPF and implemented it for IS-IS ?!?! So yeah, vendors implementations are just as important and the theoretical potential of the protocol. Oh yeah, forgot to answer the original question. For a greenfield deployment I'd be happy with either OSPFv3 or IS-IS as long as it's well designed I don't see much between them, it would come down to vendor support then. Cheers, James. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwbensley at gmail.com Thu Nov 15 08:29:59 2018 From: jwbensley at gmail.com (James Bensley) Date: Thu, 15 Nov 2018 08:29:59 +0000 Subject: IGP protocol In-Reply-To: References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> Message-ID: <64FA5A57-BA9C-48E3-9B9C-FD9BC68E9D40@gmail.com> On 15 November 2018 01:51:28 GMT, Baldur Norddahl wrote: >Also not true that the management network is the last thing to boot. In >contrary, everything else depends on that being ready first. And that >would >also be true if we used is-is. It is when you out management in a VRF... >ons. 14. nov. 2018 14.55 skrev James Bensley : > >> Several networks I've seen place >management >> in a VRF / L3 VPN, which means that by the time you have remote >> management access, everything else is already working, it's like the >> last thing to come up when there's been a problem Cheers, James. From mjosephson at inap.com Thu Nov 15 18:43:32 2018 From: mjosephson at inap.com (Marcus Josephson) Date: Thu, 15 Nov 2018 18:43:32 +0000 Subject: Tata Scenic routing in LAX area? Message-ID: Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34) 180.698 ms 180.610 ms 181.712 ms MPLS Label=344269 CoS=0 TTL=1 S=1 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 189.327 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 174.631 ms MPLS Label=609315 CoS=0 TTL=1 S=1 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 174.287 ms 173.370 ms 173.804 ms 4 120.29.215.202 (120.29.215.202) 179.104 ms 179.367 ms 179.324 ms 5 182.79.152.247 (182.79.152.247) 180.164 ms 182.79.152.253 (182.79.152.253) 184.816 ms 182.79.152.247 (182.79.152.247) 250.928 ms 6 unknown.telstraglobal.net (202.127.73.101) [AS 4637] 173.974 ms 173.986 ms 173.484 ms 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS 4637] 175.094 ms 175.699 ms 174.343 ms 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS 4637] 280.686 ms 288.703 ms 280.836 ms 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637] 278.021 ms 276.637 ms 302.249 ms 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4) 174.139 ms 174.163 ms 174.067 ms [cid:image002.jpg at 01D47CE9.3122B790] Marcus Josephson IP Operations mjosephson at inap.com This message is intended for the use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edugas at unknowndevice.ca Thu Nov 15 19:30:15 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Thu, 15 Nov 2018 14:30:15 -0500 Subject: Tata Scenic routing in LAX area? In-Reply-To: References: Message-ID: <1542310169.local-1bb203ab-2729-v1.5.2-31660462@getmailspring.com> That's quite the tour... >From Montreal, QC traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 60 byte packets 1 67-221-x-x.ebox.net (67.221.x.x) 0.459 ms 0.431 ms 0.409 ms 2 ix-ae-10-190.tcore1.mtt-montreal.as6453.net (206.82.135.105) 5.637 ms 5.619 ms 5.588 ms 3 if-ae-12-2.tcore1.w6c-montreal.as6453.net (64.86.31.27) 246.680 ms 246.682 ms 246.723 ms 4 if-ae-30-2.tcore2.ct8-chicago.as6453.net (66.198.96.24) 257.231 ms 257.275 ms 257.286 ms 5 if-ae-22-2.tcore1.ct8-chicago.as6453.net (64.86.79.2) 249.929 ms 249.807 ms 249.989 ms 6 if-ae-29-2.tcore2.sqn-san-jose.as6453.net (64.86.21.104) 257.468 ms 257.206 ms 257.211 ms 7 if-ae-1-2.tcore1.sqn-san-jose.as6453.net (63.243.205.1) 251.862 ms 251.116 ms 250.928 ms 8 if-ae-18-2.tcore2.sv1-santa-clara.as6453.net (63.243.205.13) 251.988 ms if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.26) 254.136 ms if-ae-38-2.tcore2.sv1-santa-clara.as6453.net (63.243.205.75) 252.838 ms 9 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 254.861 ms if-ae-0-2.tcore1.sv1-santa-clara.as6453.net (63.243.251.1) 267.270 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 259.345 ms 10 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 250.794 ms if-et-1-2.hcore2.kv8-chiba.as6453.net (120.29.211.3) 181.610 ms if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 250.683 ms 11 120.29.215.202 (120.29.215.202) 256.046 ms if-ae-23-2.tcore1.svw-singapore.as6453.net (180.87.67.32) 253.692 ms 120.29.215.202 (120.29.215.202) 255.907 ms 12 * * * 13 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 253.551 ms unknown.telstraglobal.net (202.127.73.101) 280.228 ms if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 254.633 ms 14 120.29.215.242 (120.29.215.242) 254.595 ms 269.004 ms 265.841 ms 15 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) 248.997 ms 249.750 ms 249.693 ms 16 i-92.eqnx03.telstraglobal.net (202.84.247.17) 247.845 ms unknown.telstraglobal.net (202.127.73.101) 267.627 ms i-92.eqnx03.telstraglobal.net (202.84.247.17) 249.147 ms 17 * i-93.sgpl-core02.telstraglobal.net (202.84.224.189) 255.787 ms * 18 bbr1.inapbb-dal-sje-1-2-4-6.dal006.pnap.net (64.95.158.182) 261.728 ms bbr2.ae7.sje.pnap.net (64.95.158.178) 248.810 ms bbr1.inapbb-dal-sje-1-2-4-6.dal006.pnap.net (64.95.158.182) 261.988 ms 19 i-92.eqnx03.telstraglobal.net (202.84.247.17) 250.373 ms 245.202 ms bbr2.xe-1-1-1.inapbb-chg-sje-8.chg.pnap.net (64.95.159.21) 260.105 ms 20 * * bbr1.xe-0-0-1.inapbb-wdc-dal-7.wdc002.pnap.net (64.95.158.210) 260.176 ms 21 bbr2.ae7.sje.pnap.net (64.95.158.178) 247.134 ms 251.671 ms bbr1.inapbb-dal-sje-1-2-4-6.dal006.pnap.net (64.95.158.182) 264.785 ms 22 bbr2.xe-1-1-1.inapbb-chg-sje-8.chg.pnap.net (64.95.159.21) 263.305 ms * 64.95.159.45 (64.95.159.45) 287.747 ms 23 bbr1.ae7.nym007.pnap.net (64.95.158.73) 263.963 ms bbr1.xe-4-0-0.inapbb-chg-nym-12.nym007.pnap.net (64.95.159.18) 251.967 ms * 24 tsr1.e6-1.nyj004.pnap.net (64.95.158.234) 267.155 ms 263.123 ms * 25 64.95.159.45 (64.95.159.45) 266.946 ms * * 26 * bbr1.ae7.nym007.pnap.net (64.95.158.73) 266.049 ms * 27 * * tsr1.e6-1.nyj004.pnap.net (64.95.158.234) 262.634 ms 28 * * * 29 * * * 30 * * * On Nov 15 2018, at 1:43 pm, Marcus Josephson wrote: > > Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. > > traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets > 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34) 180.698 ms 180.610 ms 181.712 ms > MPLS Label=344269 CoS=0 TTL=1 S=1 > 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 189.327 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 174.631 ms > MPLS Label=609315 CoS=0 TTL=1 S=1 > 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 174.287 ms 173.370 ms 173.804 ms > 4 120.29.215.202 (120.29.215.202) 179.104 ms 179.367 ms 179.324 ms > 5 182.79.152.247 (182.79.152.247) 180.164 ms 182.79.152.253 (182.79.152.253) 184.816 ms 182.79.152.247 (182.79.152.247) 250.928 ms > 6 unknown.telstraglobal.net (202.127.73.101) [AS 4637] 173.974 ms 173.986 ms 173.484 ms > 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS 4637] 175.094 ms 175.699 ms 174.343 ms > 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS 4637] 280.686 ms 288.703 ms 280.836 ms > 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637] 278.021 ms 276.637 ms 302.249 ms > 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4) 174.139 ms 174.163 ms 174.067 ms > > > > > Marcus Josephson > IP Operations > > mjosephson at inap.com > > This message is intended for the use of the intended recipient(s) and may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From florinvlad.olariu at gmail.com Thu Nov 15 18:27:47 2018 From: florinvlad.olariu at gmail.com (Florin Vlad Olariu) Date: Thu, 15 Nov 2018 13:27:47 -0500 Subject: Cisco IOS BGP Graceful-Restart Implementation query Message-ID: Hey there! In our environment we generally have ASR-1000X-2s everywhere peering via iBGP/eBGP. These routers have no redundant RPs, hence cannot keep forwarding traffic while the router reboots or crashes. As such, this is a clear example of a router that's only NSF-aware (or graceful-restart-aware) but not capable. The reason I enabled this is because, from RFC 4724: In addition, even if the speaker does not have the ability to preserve its forwarding state for any address family during BGP restart, it is still recommended that the speaker advertise the Graceful Restart Capability to its peer (as mentioned before *this is done by not including any in the advertised capability*). There are two reasons for doing this. The first is to indicate its intention of generating the End-of-RIB marker upon the completion of its initial routing updates, as doing this would be useful for routing convergence in general. The second is to indicate its support for a peer which wishes to perform a graceful restart. So what I would expect to see in the "show ip bgp neighbor " command, regarding Graceful Restart, would be something like the following: BGP neighbor is , remote AS , internal link [...] Neighbor capabilities: [...] Graceful Restart Capability: advertised and received Remote Restart timer is 120 seconds Address families advertised by peer: *none* Basically, GR is negotiated, but no address family is specified, effectively only using the EOR marker for routing convergence improvements. Instead, here's what the router specifies: BGP neighbor is , remote AS , internal link [...] Neighbor capabilities: [...] Graceful Restart Capability: advertised and received Remote Restart timer is 120 seconds Address families advertised by peer: *IPv4 Unicast (was not preserved, VPNv4 Unicast (was not preserved* My assumption is that the 'was not preserved' in the parentesis refers to the most recent restart of the neighbor, and it means that when the neighbor re-established the BGP connection, the GR Capability for IPv4 and VPNv4 AFIs did not set the "Forwarding bit" as specified by the GR-RFC: Once the session is re-established, if the "Forwarding State" bit for a specific address family is not set in the newly received Graceful Restart Capability, or if a specific address family is not included in the newly received Graceful Restart Capability, or if the Graceful Restart Capability is not received in the re-established session at all, then the Receiving Speaker MUST immediately remove all the stale routes from the peer that it is retaining for that address family. Clearly the Forwarding State bit is never going to be set by this type of router, due to hardware limitations. Here's my concern though: What happens when the router reboots, and the neighboring routers keep forwarding packets to this router because the GR-capabily did specify IPv4 and VPNv4 AFI/SAFI? This would clearly cause impact as traffic would be blackholed. I will try to simulate this and see how it behaves, I'll report back, but any info you have it would be greatly appreciated. -- Florin Vlad Olariu -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Thu Nov 15 19:46:33 2018 From: john at essenz.com (John Von Essen) Date: Thu, 15 Nov 2018 14:46:33 -0500 Subject: Tata Scenic routing in LAX area? In-Reply-To: <1542310169.local-1bb203ab-2729-v1.5.2-31660462@getmailspring.com> References: <1542310169.local-1bb203ab-2729-v1.5.2-31660462@getmailspring.com> Message-ID: <80d91de8-31bb-2bfc-cec7-9a3076be824d@essenz.com> From East Coast: root at dns1:~# traceroute 23.92.178.22 traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 60 byte packets  1  gw-128-254.phlapalo.quonix.net (208.82.128.254)  0.657 ms  0.657 ms  0.651 ms  2  te0-0-2-3.nr11.b002999-2.phl01.atlas.cogentco.com (38.104.111.121)  1.057 ms  1.118 ms  1.196 ms  3  te0-1-0-0.rcr21.phl01.atlas.cogentco.com (154.24.50.85)  1.018 ms te0-1-0-0.rcr22.phl01.atlas.cogentco.com (154.24.50.89)  0.971 ms te0-1-0-0.rcr21.phl01.atlas.cogentco.com (154.24.50.85)  1.049 ms  4  be2333.ccr42.jfk02.atlas.cogentco.com (154.54.5.1)  3.775 ms be2364.ccr41.jfk02.atlas.cogentco.com (154.54.3.141)  3.756 ms 3.756 ms  5  be3295.ccr31.jfk05.atlas.cogentco.com (154.54.80.2)  3.767 ms be3294.ccr31.jfk05.atlas.cogentco.com (154.54.47.218)  3.877 ms be3295.ccr31.jfk05.atlas.cogentco.com (154.54.80.2)  3.772 ms  6  38.104.74.130 (38.104.74.130)  4.807 ms  5.371 ms  5.414 ms  7  border1-po1-bbnet1.nyj004.pnap.net (216.52.95.46)  3.360 ms 3.343 ms  3.316 ms  8  inapvoxcust-XX.border1.nyj004.pnap.net (74.201.136.66)  12.197 ms  12.222 ms  12.468 ms  9  * * * 10  * * * 11  * * * 12  * * * 13  * * * 14  * * * 15  * * * 16  * * * 17  * * * 18  * * * 19  * * * 20  * * * 21  * * * 22  * * * 23  * * * 24  * * * 25  * * * 26  * * * 27  * * * 28  * * * 29  * * * 30  * * * On 11/15/18 2:30 PM, Eric Dugas wrote: > That's quite the tour... > > From Montreal, QC > > traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 60 byte packets > 1 67-221-x-x.ebox.net (67.221.x.x) 0.459 ms 0.431 ms 0.409 ms > 2 ix-ae-10-190.tcore1.mtt-montreal.as6453.net (206.82.135.105) 5.637 > ms 5.619 ms 5.588 ms > 3 if-ae-12-2.tcore1.w6c-montreal.as6453.net (64.86.31.27) 246.680 ms > 246.682 ms 246.723 ms > 4 if-ae-30-2.tcore2.ct8-chicago.as6453.net (66.198.96.24) 257.231 ms > 257.275 ms 257.286 ms > 5 if-ae-22-2.tcore1.ct8-chicago.as6453.net (64.86.79.2) 249.929 ms > 249.807 ms 249.989 ms > 6 if-ae-29-2.tcore2.sqn-san-jose.as6453.net (64.86.21.104) 257.468 ms > 257.206 ms 257.211 ms > 7 if-ae-1-2.tcore1.sqn-san-jose.as6453.net (63.243.205.1) 251.862 ms > 251.116 ms 250.928 ms > 8 if-ae-18-2.tcore2.sv1-santa-clara.as6453.net (63.243.205.13) 251.988 > ms if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.26) 254.136 > ms if-ae-38-2.tcore2.sv1-santa-clara.as6453.net (63.243.205.75) 252.838 ms > 9 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 254.861 ms > if-ae-0-2.tcore1.sv1-santa-clara.as6453.net (63.243.251.1) 267.270 ms > if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 259.345 ms > 10 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 250.794 > ms if-et-1-2.hcore2.kv8-chiba.as6453.net (120.29.211.3) 181.610 ms > if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 250.683 ms > 11 120.29.215.202 (120.29.215.202) 256.046 ms > if-ae-23-2.tcore1.svw-singapore.as6453.net (180.87.67.32) 253.692 ms > 120.29.215.202 (120.29.215.202) 255.907 ms > 12 * * * > 13 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 253.551 > ms unknown.telstraglobal.net (202.127.73.101) 280.228 ms > if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 254.633 ms > 14 120.29.215.242 (120.29.215.242) 254.595 ms 269.004 ms 265.841 ms > 15 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) 248.997 ms > 249.750 ms 249.693 ms > 16 i-92.eqnx03.telstraglobal.net (202.84.247.17) 247.845 ms > unknown.telstraglobal.net (202.127.73.101) 267.627 ms > i-92.eqnx03.telstraglobal.net (202.84.247.17) 249.147 ms > 17 * i-93.sgpl-core02.telstraglobal.net (202.84.224.189) 255.787 ms * > 18 bbr1.inapbb-dal-sje-1-2-4-6.dal006.pnap.net (64.95.158.182) 261.728 > ms bbr2.ae7.sje.pnap.net (64.95.158.178) 248.810 ms > bbr1.inapbb-dal-sje-1-2-4-6.dal006.pnap.net (64.95.158.182) 261.988 ms > 19 i-92.eqnx03.telstraglobal.net (202.84.247.17) 250.373 ms 245.202 ms > bbr2.xe-1-1-1.inapbb-chg-sje-8.chg.pnap.net (64.95.159.21) 260.105 ms > 20 * * bbr1.xe-0-0-1.inapbb-wdc-dal-7.wdc002.pnap.net (64.95.158.210) > 260.176 ms > 21 bbr2.ae7.sje.pnap.net (64.95.158.178) 247.134 ms 251.671 ms > bbr1.inapbb-dal-sje-1-2-4-6.dal006.pnap.net (64.95.158.182) 264.785 ms > 22 bbr2.xe-1-1-1.inapbb-chg-sje-8.chg.pnap.net (64.95.159.21) 263.305 > ms * 64.95.159.45 (64.95.159.45) 287.747 ms > 23 bbr1.ae7.nym007.pnap.net (64.95.158.73) 263.963 ms > bbr1.xe-4-0-0.inapbb-chg-nym-12.nym007.pnap.net (64.95.159.18) 251.967 > ms * > 24 tsr1.e6-1.nyj004.pnap.net (64.95.158.234) 267.155 ms 263.123 ms * > 25 64.95.159.45 (64.95.159.45) 266.946 ms * * > 26 * bbr1.ae7.nym007.pnap.net (64.95.158.73) 266.049 ms * > 27 * * tsr1.e6-1.nyj004.pnap.net (64.95.158.234) 262.634 ms > 28 * * * > 29 * * * > 30 * * * > > On Nov 15 2018, at 1:43 pm, Marcus Josephson wrote: > > > Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. > > > traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte > packets > > 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34)  > 180.698 ms  180.610 ms  181.712 ms > >      MPLS Label=344269 CoS=0 TTL=1 S=1 > > 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25)  > 189.327 ms if-ae-7-2.tcore2.svw-singapore.as6453.net > (64.86.252.37)  176.800 ms > if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39)  174.631 ms > >      MPLS Label=609315 CoS=0 TTL=1 S=1 > > 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21)  > 174.287 ms  173.370 ms  173.804 ms > > 4 120.29.215.202 (120.29.215.202)  179.104 ms  179.367 ms  179.324 ms > > 5 182.79.152.247 (182.79.152.247)  180.164 ms 182.79.152.253 > (182.79.152.253)  184.816 ms 182.79.152.247 (182.79.152.247)  > 250.928 ms > > 6 unknown.telstraglobal.net (202.127.73.101) [AS  4637] 173.974 > ms  173.986 ms  173.484 ms > > 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS  4637]  > 175.094 ms  175.699 ms  174.343 ms > > 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS  > 4637]  280.686 ms  288.703 ms  280.836 ms > > 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637]  278.021 > ms  276.637 ms  302.249 ms > > 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4)  174.139 ms  > 174.163 ms  174.067 ms > > > > > > Marcus Josephson > > IP Operations > > > mjosephson at inap.com > > > /This message is intended for the use of the intended recipient(s) > and may contain confidential and privileged information./ > > /Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient, please > contact//the sender by reply email and destroy all copies of the > original message./ > From jw at nuclearfallout.net Thu Nov 15 19:47:55 2018 From: jw at nuclearfallout.net (John Weekes) Date: Thu, 15 Nov 2018 11:47:55 -0800 Subject: Tata Scenic routing in LAX area? In-Reply-To: References: Message-ID: <7266d5f5-ec77-443b-4d83-4721c4b0894c@nuclearfallout.net> Marcus, From route-views output, it looks like AS9498/airtel is probably leaking your route between two of its upstreams (AS6453/Tata and AS4637/Telstra) overseas, funneling some of your traffic through their router. route-views>sh ip bgp 23.92.178.22 | i 9498   3356 6453 9498 4637 29791   1403 6453 9498 4637 29791   3549 3356 6453 9498 4637 29791   19214 3257 6453 9498 4637 29791   1403 6453 9498 4637 29791   286 6453 9498 4637 29791   53364 3257 6453 9498 4637 29791   3257 6453 9498 4637 29791   1239 6453 9498 4637 29791   2497 6453 9498 4637 29791   57866 6453 9498 4637 29791   7660 2516 6453 9498 4637 29791   701 6453 9498 4637 29791   3561 209 6453 9498 4637 29791 You might try halting advertisements to your AS4637/Telstra peer while you contact AS9498. -John On 11/15/2018 10:43 AM, Marcus Josephson wrote: > > Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. > > traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets > > 1  if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34)  > 180.698 ms  180.610 ms  181.712 ms > >      MPLS Label=344269 CoS=0 TTL=1 S=1 > > 2  if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25)  189.327 > ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms > if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39)  174.631 ms > >      MPLS Label=609315 CoS=0 TTL=1 S=1 > > 3  if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21)  174.287 > ms  173.370 ms  173.804 ms > > 4  120.29.215.202 (120.29.215.202)  179.104 ms 179.367 ms  179.324 ms > > 5  182.79.152.247 (182.79.152.247)  180.164 ms 182.79.152.253 > (182.79.152.253)  184.816 ms 182.79.152.247 (182.79.152.247)  250.928 ms > > 6  unknown.telstraglobal.net (202.127.73.101) [AS  4637]  173.974 ms  > 173.986 ms  173.484 ms > > 7  i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS  4637]  > 175.094 ms  175.699 ms 174.343 ms > > 8  i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS  4637]  > 280.686 ms  288.703 ms 280.836 ms > > 9  i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS  4637]  278.021 > ms  276.637 ms 302.249 ms > > 10  equinix-ix.sjc1.us.voxel.net (206.223.116.4)  174.139 ms  174.163 > ms  174.067 ms > > Marcus Josephson > > IP Operations > > mjosephson at inap.com > > /This message is intended for the use of the intended recipient(s) and > may contain confidential and privileged information. / > > /Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient, please contact//the > sender by reply email and destroy all copies of the original message./ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stillwaxin at gmail.com Thu Nov 15 20:19:59 2018 From: stillwaxin at gmail.com (Michael Still) Date: Thu, 15 Nov 2018 15:19:59 -0500 Subject: Tata Scenic routing in LAX area? In-Reply-To: <7266d5f5-ec77-443b-4d83-4721c4b0894c@nuclearfallout.net> References: <7266d5f5-ec77-443b-4d83-4721c4b0894c@nuclearfallout.net> Message-ID: FYI 29791 isn't the only origin I'm seeing this on from one point of view: AS path: 3257 6453 9498 4637 AS path: 3257 6453 9498 4637 10310 26085 14210 AS path: 3257 6453 9498 4637 20773 29066 AS path: 3257 6453 9498 4637 2906 AS path: 3257 6453 9498 4637 2906 40027 AS path: 3257 6453 9498 4637 29791 AS path: 3257 6453 9498 4637 30844 AS path: 3257 6453 9498 4637 30844 36991 AS path: 3257 6453 9498 4637 30844 38056 38056 38056 AS path: 3257 6453 9498 4637 37468 37230 AS path: 3257 6453 9498 4637 37468 37230 37230 37230 AS path: 3257 6453 9498 4637 47869 AS path: 3356 6453 9498 4637 AS path: 3356 6453 9498 4637 1299 2906 AS path: 3356 6453 9498 4637 1299 3491 20485 20485 4809 49209 AS path: 3356 6453 9498 4637 20773 29066 AS path: 3356 6453 9498 4637 2906 AS path: 3356 6453 9498 4637 29791 AS path: 3356 6453 9498 4637 30844 AS path: 3356 6453 9498 4637 30844 36991 AS path: 3356 6453 9498 4637 30844 38056 38056 38056 AS path: 3356 6453 9498 4637 37468 37230 AS path: 3356 6453 9498 4637 37468 37230 37230 37230 AS path: 3356 6453 9498 4637 47869 I'm not sure what is supposed to be there for 6453_9498 but I suspect not nearly as much as is currently present (only 4637 listed here for brevity). On Thu, Nov 15, 2018 at 2:53 PM John Weekes wrote: > Marcus, > > From route-views output, it looks like AS9498/airtel is probably leaking > your route between two of its upstreams (AS6453/Tata and AS4637/Telstra) > overseas, funneling some of your traffic through their router. > > route-views>sh ip bgp 23.92.178.22 | i 9498 > 3356 6453 9498 4637 29791 > 1403 6453 9498 4637 29791 > 3549 3356 6453 9498 4637 29791 > 19214 3257 6453 9498 4637 29791 > 1403 6453 9498 4637 29791 > 286 6453 9498 4637 29791 > 53364 3257 6453 9498 4637 29791 > 3257 6453 9498 4637 29791 > 1239 6453 9498 4637 29791 > 2497 6453 9498 4637 29791 > 57866 6453 9498 4637 29791 > 7660 2516 6453 9498 4637 29791 > 701 6453 9498 4637 29791 > 3561 209 6453 9498 4637 29791 > > You might try halting advertisements to your AS4637/Telstra peer while you > contact AS9498. > > -John > > On 11/15/2018 10:43 AM, Marcus Josephson wrote: > > Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. > > > > traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets > > 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34) 180.698 > ms 180.610 ms 181.712 ms > > MPLS Label=344269 CoS=0 TTL=1 S=1 > > 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 189.327 ms > if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms > if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 174.631 ms > > MPLS Label=609315 CoS=0 TTL=1 S=1 > > 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 174.287 ms > 173.370 ms 173.804 ms > > 4 120.29.215.202 (120.29.215.202) 179.104 ms 179.367 ms 179.324 ms > > 5 182.79.152.247 (182.79.152.247) 180.164 ms 182.79.152.253 > (182.79.152.253) 184.816 ms 182.79.152.247 (182.79.152.247) 250.928 ms > > 6 unknown.telstraglobal.net (202.127.73.101) [AS 4637] 173.974 ms > 173.986 ms 173.484 ms > > 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS 4637] > 175.094 ms 175.699 ms 174.343 ms > > 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS 4637] > 280.686 ms 288.703 ms 280.836 ms > > 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637] 278.021 ms > 276.637 ms 302.249 ms > > 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4) 174.139 ms 174.163 ms > 174.067 ms > > > > > > Marcus Josephson > > IP Operations > > > > mjosephson at inap.com > > > > *This message is intended for the use of the intended recipient(s) and may > contain confidential and privileged information. * > > *Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please contact* *the sender by > reply email and destroy all copies of the original message.* > > > > > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Thu Nov 15 20:29:36 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 Nov 2018 15:29:36 -0500 Subject: Tata Scenic routing in LAX area? In-Reply-To: References: <7266d5f5-ec77-443b-4d83-4721c4b0894c@nuclearfallout.net> Message-ID: On Thu, Nov 15, 2018 at 3:21 PM Michael Still wrote: > FYI 29791 isn't the only origin I'm seeing this on from one point of view: > AS path: 3257 6453 9498 4637 > AS path: 3257 6453 9498 4637 10310 26085 14210 > AS path: 3257 6453 9498 4637 20773 29066 > AS path: 3257 6453 9498 4637 2906 > AS path: 3257 6453 9498 4637 2906 40027 > AS path: 3257 6453 9498 4637 29791 > AS path: 3257 6453 9498 4637 30844 > AS path: 3257 6453 9498 4637 30844 36991 > AS path: 3257 6453 9498 4637 30844 38056 38056 38056 > AS path: 3257 6453 9498 4637 37468 37230 > AS path: 3257 6453 9498 4637 37468 37230 37230 37230 > AS path: 3257 6453 9498 4637 47869 > AS path: 3356 6453 9498 4637 > AS path: 3356 6453 9498 4637 1299 2906 > AS path: 3356 6453 9498 4637 1299 3491 20485 20485 > 4809 49209 > AS path: 3356 6453 9498 4637 20773 29066 > AS path: 3356 6453 9498 4637 2906 > AS path: 3356 6453 9498 4637 29791 > AS path: 3356 6453 9498 4637 30844 > AS path: 3356 6453 9498 4637 30844 36991 > AS path: 3356 6453 9498 4637 30844 38056 38056 38056 > AS path: 3356 6453 9498 4637 37468 37230 > AS path: 3356 6453 9498 4637 37468 37230 37230 37230 > AS path: 3356 6453 9498 4637 47869 > > I'm not sure what is supposed to be there for 6453_9498 but I suspect not > nearly as much as is currently present (only 4637 listed here for brevity). > > huh... us-carrier -> tata -> airtel -> telstra .. that seems TOTALLY PLAUSIBLE.. no. > > > On Thu, Nov 15, 2018 at 2:53 PM John Weekes wrote: > >> Marcus, >> >> From route-views output, it looks like AS9498/airtel is probably leaking >> your route between two of its upstreams (AS6453/Tata and AS4637/Telstra) >> overseas, funneling some of your traffic through their router. >> >> route-views>sh ip bgp 23.92.178.22 | i 9498 >> 3356 6453 9498 4637 29791 >> 1403 6453 9498 4637 29791 >> 3549 3356 6453 9498 4637 29791 >> 19214 3257 6453 9498 4637 29791 >> 1403 6453 9498 4637 29791 >> 286 6453 9498 4637 29791 >> 53364 3257 6453 9498 4637 29791 >> 3257 6453 9498 4637 29791 >> 1239 6453 9498 4637 29791 >> 2497 6453 9498 4637 29791 >> 57866 6453 9498 4637 29791 >> 7660 2516 6453 9498 4637 29791 >> 701 6453 9498 4637 29791 >> 3561 209 6453 9498 4637 29791 >> >> You might try halting advertisements to your AS4637/Telstra peer while >> you contact AS9498. >> >> -John >> >> On 11/15/2018 10:43 AM, Marcus Josephson wrote: >> >> Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. >> >> >> >> traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets >> >> 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34) 180.698 >> ms 180.610 ms 181.712 ms >> >> MPLS Label=344269 CoS=0 TTL=1 S=1 >> >> 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 189.327 ms >> if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms >> if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 174.631 ms >> >> MPLS Label=609315 CoS=0 TTL=1 S=1 >> >> 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 174.287 >> ms 173.370 ms 173.804 ms >> >> 4 120.29.215.202 (120.29.215.202) 179.104 ms 179.367 ms 179.324 ms >> >> 5 182.79.152.247 (182.79.152.247) 180.164 ms 182.79.152.253 >> (182.79.152.253) 184.816 ms 182.79.152.247 (182.79.152.247) 250.928 ms >> >> 6 unknown.telstraglobal.net (202.127.73.101) [AS 4637] 173.974 ms >> 173.986 ms 173.484 ms >> >> 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS 4637] >> 175.094 ms 175.699 ms 174.343 ms >> >> 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS 4637] >> 280.686 ms 288.703 ms 280.836 ms >> >> 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637] 278.021 ms >> 276.637 ms 302.249 ms >> >> 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4) 174.139 ms 174.163 >> ms 174.067 ms >> >> >> >> >> >> Marcus Josephson >> >> IP Operations >> >> >> >> mjosephson at inap.com >> >> >> >> *This message is intended for the use of the intended recipient(s) and >> may contain confidential and privileged information. * >> >> *Any unauthorized review, use, disclosure or distribution is prohibited. >> If you are not the intended recipient, please contact* *the sender by >> reply email and destroy all copies of the original message.* >> >> >> >> >> > > -- > [stillwaxin at gmail.com ~]$ cat .signature > cat: .signature: No such file or directory > [stillwaxin at gmail.com ~]$ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjosephson at inap.com Thu Nov 15 20:46:48 2018 From: mjosephson at inap.com (Marcus Josephson) Date: Thu, 15 Nov 2018 20:46:48 +0000 Subject: Tata Scenic routing in LAX area? In-Reply-To: References: <7266d5f5-ec77-443b-4d83-4721c4b0894c@nuclearfallout.net> Message-ID: I have tried to reach out to Airtel, no response yet, but yah I could see my issue being due to them leaking routes. -Marcus From: NANOG On Behalf Of Christopher Morrow Sent: Thursday, November 15, 2018 3:30 PM To: stillwaxin at gmail.com Cc: nanog list Subject: Re: Tata Scenic routing in LAX area? On Thu, Nov 15, 2018 at 3:21 PM Michael Still > wrote: FYI 29791 isn't the only origin I'm seeing this on from one point of view: AS path: 3257 6453 9498 4637 AS path: 3257 6453 9498 4637 10310 26085 14210 AS path: 3257 6453 9498 4637 20773 29066 AS path: 3257 6453 9498 4637 2906 AS path: 3257 6453 9498 4637 2906 40027 AS path: 3257 6453 9498 4637 29791 AS path: 3257 6453 9498 4637 30844 AS path: 3257 6453 9498 4637 30844 36991 AS path: 3257 6453 9498 4637 30844 38056 38056 38056 AS path: 3257 6453 9498 4637 37468 37230 AS path: 3257 6453 9498 4637 37468 37230 37230 37230 AS path: 3257 6453 9498 4637 47869 AS path: 3356 6453 9498 4637 AS path: 3356 6453 9498 4637 1299 2906 AS path: 3356 6453 9498 4637 1299 3491 20485 20485 4809 49209 AS path: 3356 6453 9498 4637 20773 29066 AS path: 3356 6453 9498 4637 2906 AS path: 3356 6453 9498 4637 29791 AS path: 3356 6453 9498 4637 30844 AS path: 3356 6453 9498 4637 30844 36991 AS path: 3356 6453 9498 4637 30844 38056 38056 38056 AS path: 3356 6453 9498 4637 37468 37230 AS path: 3356 6453 9498 4637 37468 37230 37230 37230 AS path: 3356 6453 9498 4637 47869 I'm not sure what is supposed to be there for 6453_9498 but I suspect not nearly as much as is currently present (only 4637 listed here for brevity). huh... us-carrier -> tata -> airtel -> telstra .. that seems TOTALLY PLAUSIBLE.. no. On Thu, Nov 15, 2018 at 2:53 PM John Weekes > wrote: Marcus, From route-views output, it looks like AS9498/airtel is probably leaking your route between two of its upstreams (AS6453/Tata and AS4637/Telstra) overseas, funneling some of your traffic through their router. route-views>sh ip bgp 23.92.178.22 | i 9498 3356 6453 9498 4637 29791 1403 6453 9498 4637 29791 3549 3356 6453 9498 4637 29791 19214 3257 6453 9498 4637 29791 1403 6453 9498 4637 29791 286 6453 9498 4637 29791 53364 3257 6453 9498 4637 29791 3257 6453 9498 4637 29791 1239 6453 9498 4637 29791 2497 6453 9498 4637 29791 57866 6453 9498 4637 29791 7660 2516 6453 9498 4637 29791 701 6453 9498 4637 29791 3561 209 6453 9498 4637 29791 You might try halting advertisements to your AS4637/Telstra peer while you contact AS9498. -John On 11/15/2018 10:43 AM, Marcus Josephson wrote: Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34) 180.698 ms 180.610 ms 181.712 ms MPLS Label=344269 CoS=0 TTL=1 S=1 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 189.327 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 174.631 ms MPLS Label=609315 CoS=0 TTL=1 S=1 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 174.287 ms 173.370 ms 173.804 ms 4 120.29.215.202 (120.29.215.202) 179.104 ms 179.367 ms 179.324 ms 5 182.79.152.247 (182.79.152.247) 180.164 ms 182.79.152.253 (182.79.152.253) 184.816 ms 182.79.152.247 (182.79.152.247) 250.928 ms 6 unknown.telstraglobal.net (202.127.73.101) [AS 4637] 173.974 ms 173.986 ms 173.484 ms 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS 4637] 175.094 ms 175.699 ms 174.343 ms 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS 4637] 280.686 ms 288.703 ms 280.836 ms 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637] 278.021 ms 276.637 ms 302.249 ms 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4) 174.139 ms 174.163 ms 174.067 ms Marcus Josephson IP Operations mjosephson at inap.com This message is intended for the use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pratik.Lotia at charter.com Thu Nov 15 21:10:37 2018 From: Pratik.Lotia at charter.com (Lotia, Pratik M) Date: Thu, 15 Nov 2018 21:10:37 +0000 Subject: Tata Scenic routing in LAX area? In-Reply-To: References: <7266d5f5-ec77-443b-4d83-4721c4b0894c@nuclearfallout.net> Message-ID: 9498/Airtel seems to be leaking a lot of routes. Source: https://bgpstream.com/ All Events for BGP Stream. Event type Country ASN Start time (UTC) End time (UTC) More info BGP Leak Origin AS: Etisalat Lanka (Pvt) Ltd. (AS 17470) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 19:41:26 More detail BGP Leak Origin AS: Bharti Airtel Lanka Pvt. Limited (AS 132045) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 19:41:26 More detail BGP Leak Origin AS: Antena3 S.A. (AS 47220) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 19:22:39 More detail BGP Leak Origin AS: INDOSATM2 ASN (AS 4795) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 18:46:59 More detail BGP Leak Origin AS: KANARTEL (AS 33788) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 18:33:09 More detail BGP Leak Origin AS: FranTech Solutions (AS 53667) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 18:04:47 More detail BGP Leak Origin AS: Pure Line Co. For Telecommunications & Internet Ltd. (AS 59458) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 18:04:05 More detail BGP Leak Origin AS: Sepehr Ava Data Processing Company (LTD) (AS 51541) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 18:01:09 More detail ~Pratik Lotia “Improvement begins with I.” From: NANOG on behalf of Marcus Josephson Date: Thursday, November 15, 2018 at 13:48 To: Christopher Morrow , "stillwaxin at gmail.com" Cc: nanog list Subject: RE: Tata Scenic routing in LAX area? I have tried to reach out to Airtel, no response yet, but yah I could see my issue being due to them leaking routes. -Marcus From: NANOG On Behalf Of Christopher Morrow Sent: Thursday, November 15, 2018 3:30 PM To: stillwaxin at gmail.com Cc: nanog list Subject: Re: Tata Scenic routing in LAX area? On Thu, Nov 15, 2018 at 3:21 PM Michael Still > wrote: FYI 29791 isn't the only origin I'm seeing this on from one point of view: AS path: 3257 6453 9498 4637 AS path: 3257 6453 9498 4637 10310 26085 14210 AS path: 3257 6453 9498 4637 20773 29066 AS path: 3257 6453 9498 4637 2906 AS path: 3257 6453 9498 4637 2906 40027 AS path: 3257 6453 9498 4637 29791 AS path: 3257 6453 9498 4637 30844 AS path: 3257 6453 9498 4637 30844 36991 AS path: 3257 6453 9498 4637 30844 38056 38056 38056 AS path: 3257 6453 9498 4637 37468 37230 AS path: 3257 6453 9498 4637 37468 37230 37230 37230 AS path: 3257 6453 9498 4637 47869 AS path: 3356 6453 9498 4637 AS path: 3356 6453 9498 4637 1299 2906 AS path: 3356 6453 9498 4637 1299 3491 20485 20485 4809 49209 AS path: 3356 6453 9498 4637 20773 29066 AS path: 3356 6453 9498 4637 2906 AS path: 3356 6453 9498 4637 29791 AS path: 3356 6453 9498 4637 30844 AS path: 3356 6453 9498 4637 30844 36991 AS path: 3356 6453 9498 4637 30844 38056 38056 38056 AS path: 3356 6453 9498 4637 37468 37230 AS path: 3356 6453 9498 4637 37468 37230 37230 37230 AS path: 3356 6453 9498 4637 47869 I'm not sure what is supposed to be there for 6453_9498 but I suspect not nearly as much as is currently present (only 4637 listed here for brevity). huh... us-carrier -> tata -> airtel -> telstra .. that seems TOTALLY PLAUSIBLE.. no. On Thu, Nov 15, 2018 at 2:53 PM John Weekes > wrote: Marcus, From route-views output, it looks like AS9498/airtel is probably leaking your route between two of its upstreams (AS6453/Tata and AS4637/Telstra) overseas, funneling some of your traffic through their router. route-views>sh ip bgp 23.92.178.22 | i 9498 3356 6453 9498 4637 29791 1403 6453 9498 4637 29791 3549 3356 6453 9498 4637 29791 19214 3257 6453 9498 4637 29791 1403 6453 9498 4637 29791 286 6453 9498 4637 29791 53364 3257 6453 9498 4637 29791 3257 6453 9498 4637 29791 1239 6453 9498 4637 29791 2497 6453 9498 4637 29791 57866 6453 9498 4637 29791 7660 2516 6453 9498 4637 29791 701 6453 9498 4637 29791 3561 209 6453 9498 4637 29791 You might try halting advertisements to your AS4637/Telstra peer while you contact AS9498. -John On 11/15/2018 10:43 AM, Marcus Josephson wrote: Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34) 180.698 ms 180.610 ms 181.712 ms MPLS Label=344269 CoS=0 TTL=1 S=1 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 189.327 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 174.631 ms MPLS Label=609315 CoS=0 TTL=1 S=1 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 174.287 ms 173.370 ms 173.804 ms 4 120.29.215.202 (120.29.215.202) 179.104 ms 179.367 ms 179.324 ms 5 182.79.152.247 (182.79.152.247) 180.164 ms 182.79.152.253 (182.79.152.253) 184.816 ms 182.79.152.247 (182.79.152.247) 250.928 ms 6 unknown.telstraglobal.net (202.127.73.101) [AS 4637] 173.974 ms 173.986 ms 173.484 ms 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS 4637] 175.094 ms 175.699 ms 174.343 ms 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS 4637] 280.686 ms 288.703 ms 280.836 ms 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637] 278.021 ms 276.637 ms 302.249 ms 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4) 174.139 ms 174.163 ms 174.067 ms Marcus Josephson IP Operations mjosephson at inap.com This message is intended for the use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Thu Nov 15 22:33:56 2018 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 15 Nov 2018 17:33:56 -0500 Subject: Tata Scenic routing in LAX area? In-Reply-To: References: <7266d5f5-ec77-443b-4d83-4721c4b0894c@nuclearfallout.net> Message-ID: I don't know what's less surprising, Tata making sure you see the entire internet (wink wink), or Airtel leaking routes... :) On Thu, Nov 15, 2018 at 4:13 PM Lotia, Pratik M wrote: > 9498/Airtel seems to be leaking a lot of routes. > > > > Source: https://bgpstream.com/ > > > > All Events for BGP Stream. > > *Event type* > > *Country* > > *ASN* > > *Start time (UTC)* > > *End time (UTC)* > > *More info* > > BGP Leak > > *Origin AS:* Etisalat Lanka (Pvt) Ltd. (AS 17470) > *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) > > 2018-11-15 19:41:26 > > More detail > > BGP Leak > > *Origin AS:* Bharti Airtel Lanka Pvt. Limited (AS 132045) > *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) > > 2018-11-15 19:41:26 > > More detail > > BGP Leak > > *Origin AS:* Antena3 S.A. (AS 47220) > *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) > > 2018-11-15 19:22:39 > > More detail > > BGP Leak > > *Origin AS:* INDOSATM2 ASN (AS 4795) > *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) > > 2018-11-15 18:46:59 > > More detail > > BGP Leak > > *Origin AS:* KANARTEL (AS 33788) > *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) > > 2018-11-15 18:33:09 > > More detail > > BGP Leak > > *Origin AS:* FranTech Solutions (AS 53667) > *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) > > 2018-11-15 18:04:47 > > More detail > > BGP Leak > > *Origin AS:* Pure Line Co. For Telecommunications & Internet Ltd. (AS > 59458) > *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) > > 2018-11-15 18:04:05 > > More detail > > BGP Leak > > *Origin AS:* Sepehr Ava Data Processing Company (LTD) (AS 51541) > *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) > > 2018-11-15 18:01:09 > > More detail > > > > > > > > ~Pratik Lotia > > > > “Improvement begins with I.” > > > > > > *From: *NANOG on behalf of Marcus Josephson < > mjosephson at inap.com> > *Date: *Thursday, November 15, 2018 at 13:48 > *To: *Christopher Morrow , "stillwaxin at gmail.com" > > *Cc: *nanog list > *Subject: *RE: Tata Scenic routing in LAX area? > > > > I have tried to reach out to Airtel, no response yet, but yah I could see > my issue being due to them leaking routes. > > > > > > -Marcus > > > > *From:* NANOG *On Behalf Of *Christopher Morrow > *Sent:* Thursday, November 15, 2018 3:30 PM > *To:* stillwaxin at gmail.com > *Cc:* nanog list > *Subject:* Re: Tata Scenic routing in LAX area? > > > > > > On Thu, Nov 15, 2018 at 3:21 PM Michael Still > wrote: > > FYI 29791 isn't the only origin I'm seeing this on from one point of view: > > AS path: 3257 6453 9498 4637 > > AS path: 3257 6453 9498 4637 10310 26085 14210 > > AS path: 3257 6453 9498 4637 20773 29066 > > AS path: 3257 6453 9498 4637 2906 > > AS path: 3257 6453 9498 4637 2906 40027 > > AS path: 3257 6453 9498 4637 29791 > > AS path: 3257 6453 9498 4637 30844 > > AS path: 3257 6453 9498 4637 30844 36991 > > AS path: 3257 6453 9498 4637 30844 38056 38056 38056 > > AS path: 3257 6453 9498 4637 37468 37230 > > AS path: 3257 6453 9498 4637 37468 37230 37230 37230 > > AS path: 3257 6453 9498 4637 47869 > > AS path: 3356 6453 9498 4637 > > AS path: 3356 6453 9498 4637 1299 2906 > > AS path: 3356 6453 9498 4637 1299 3491 20485 20485 > 4809 49209 > > AS path: 3356 6453 9498 4637 20773 29066 > > AS path: 3356 6453 9498 4637 2906 > > AS path: 3356 6453 9498 4637 29791 > > AS path: 3356 6453 9498 4637 30844 > > AS path: 3356 6453 9498 4637 30844 36991 > > AS path: 3356 6453 9498 4637 30844 38056 38056 38056 > > AS path: 3356 6453 9498 4637 37468 37230 > > AS path: 3356 6453 9498 4637 37468 37230 37230 37230 > > AS path: 3356 6453 9498 4637 47869 > > > > I'm not sure what is supposed to be there for 6453_9498 but I suspect not > nearly as much as is currently present (only 4637 listed here for brevity). > > > > > > huh... us-carrier -> tata -> airtel -> telstra .. that seems TOTALLY > PLAUSIBLE.. no. > > > > > > > > On Thu, Nov 15, 2018 at 2:53 PM John Weekes wrote: > > Marcus, > > From route-views output, it looks like AS9498/airtel is probably leaking > your route between two of its upstreams (AS6453/Tata and AS4637/Telstra) > overseas, funneling some of your traffic through their router. > > route-views>sh ip bgp 23.92.178.22 | i 9498 > 3356 6453 9498 4637 29791 > 1403 6453 9498 4637 29791 > 3549 3356 6453 9498 4637 29791 > 19214 3257 6453 9498 4637 29791 > 1403 6453 9498 4637 29791 > 286 6453 9498 4637 29791 > 53364 3257 6453 9498 4637 29791 > 3257 6453 9498 4637 29791 > 1239 6453 9498 4637 29791 > 2497 6453 9498 4637 29791 > 57866 6453 9498 4637 29791 > 7660 2516 6453 9498 4637 29791 > 701 6453 9498 4637 29791 > 3561 209 6453 9498 4637 29791 > > You might try halting advertisements to your AS4637/Telstra peer while you > contact AS9498. > > -John > > On 11/15/2018 10:43 AM, Marcus Josephson wrote: > > Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. > > > > traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets > > 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34) 180.698 > ms 180.610 ms 181.712 ms > > MPLS Label=344269 CoS=0 TTL=1 S=1 > > 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 189.327 ms > if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms > if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 174.631 ms > > MPLS Label=609315 CoS=0 TTL=1 S=1 > > 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 174.287 ms > 173.370 ms 173.804 ms > > 4 120.29.215.202 (120.29.215.202) 179.104 ms 179.367 ms 179.324 ms > > 5 182.79.152.247 (182.79.152.247) 180.164 ms 182.79.152.253 > (182.79.152.253) 184.816 ms 182.79.152.247 (182.79.152.247) 250.928 ms > > 6 unknown.telstraglobal.net (202.127.73.101) [AS 4637] 173.974 ms > 173.986 ms 173.484 ms > > 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS 4637] > 175.094 ms 175.699 ms 174.343 ms > > 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS 4637] > 280.686 ms 288.703 ms 280.836 ms > > 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637] 278.021 ms > 276.637 ms 302.249 ms > > 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4) 174.139 ms 174.163 ms > 174.067 ms > > > > > > Marcus Josephson > > IP Operations > > > > mjosephson at inap.com > > > > *This message is intended for the use of the intended recipient(s) and may > contain confidential and privileged information. * > > *Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please contact* *the sender by > reply email and destroy all copies of the original message.* > > > > > > > > > -- > > [stillwaxin at gmail.com ~]$ cat .signature > cat: .signature: No such file or directory > [stillwaxin at gmail.com ~]$ > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjosephson at inap.com Thu Nov 15 23:05:18 2018 From: mjosephson at inap.com (Marcus Josephson) Date: Thu, 15 Nov 2018 23:05:18 +0000 Subject: Tata Scenic routing in LAX area? In-Reply-To: References: <7266d5f5-ec77-443b-4d83-4721c4b0894c@nuclearfallout.net> Message-ID: Airtel has acknowledged and is in the process of reverting. Thanks all for your input. -Marcus From: Tom Beecher Sent: Thursday, November 15, 2018 5:34 PM To: Pratik.Lotia at charter.com Cc: Marcus Josephson ; morrowc.lists at gmail.com; stillwaxin at gmail.com; NANOG Subject: Re: Tata Scenic routing in LAX area? I don't know what's less surprising, Tata making sure you see the entire internet (wink wink), or Airtel leaking routes... :) On Thu, Nov 15, 2018 at 4:13 PM Lotia, Pratik M > wrote: 9498/Airtel seems to be leaking a lot of routes. Source: https://bgpstream.com/ All Events for BGP Stream. Event type Country ASN Start time (UTC) End time (UTC) More info BGP Leak Origin AS: Etisalat Lanka (Pvt) Ltd. (AS 17470) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 19:41:26 More detail BGP Leak Origin AS: Bharti Airtel Lanka Pvt. Limited (AS 132045) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 19:41:26 More detail BGP Leak Origin AS: Antena3 S.A. (AS 47220) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 19:22:39 More detail BGP Leak Origin AS: INDOSATM2 ASN (AS 4795) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 18:46:59 More detail BGP Leak Origin AS: KANARTEL (AS 33788) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 18:33:09 More detail BGP Leak Origin AS: FranTech Solutions (AS 53667) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 18:04:47 More detail BGP Leak Origin AS: Pure Line Co. For Telecommunications & Internet Ltd. (AS 59458) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 18:04:05 More detail BGP Leak Origin AS: Sepehr Ava Data Processing Company (LTD) (AS 51541) Leaker AS: BHARTI Airtel Ltd. (AS 9498) 2018-11-15 18:01:09 More detail ~Pratik Lotia “Improvement begins with I.” From: NANOG > on behalf of Marcus Josephson > Date: Thursday, November 15, 2018 at 13:48 To: Christopher Morrow >, "stillwaxin at gmail.com" > Cc: nanog list > Subject: RE: Tata Scenic routing in LAX area? I have tried to reach out to Airtel, no response yet, but yah I could see my issue being due to them leaking routes. -Marcus From: NANOG > On Behalf Of Christopher Morrow Sent: Thursday, November 15, 2018 3:30 PM To: stillwaxin at gmail.com Cc: nanog list > Subject: Re: Tata Scenic routing in LAX area? On Thu, Nov 15, 2018 at 3:21 PM Michael Still > wrote: FYI 29791 isn't the only origin I'm seeing this on from one point of view: AS path: 3257 6453 9498 4637 AS path: 3257 6453 9498 4637 10310 26085 14210 AS path: 3257 6453 9498 4637 20773 29066 AS path: 3257 6453 9498 4637 2906 AS path: 3257 6453 9498 4637 2906 40027 AS path: 3257 6453 9498 4637 29791 AS path: 3257 6453 9498 4637 30844 AS path: 3257 6453 9498 4637 30844 36991 AS path: 3257 6453 9498 4637 30844 38056 38056 38056 AS path: 3257 6453 9498 4637 37468 37230 AS path: 3257 6453 9498 4637 37468 37230 37230 37230 AS path: 3257 6453 9498 4637 47869 AS path: 3356 6453 9498 4637 AS path: 3356 6453 9498 4637 1299 2906 AS path: 3356 6453 9498 4637 1299 3491 20485 20485 4809 49209 AS path: 3356 6453 9498 4637 20773 29066 AS path: 3356 6453 9498 4637 2906 AS path: 3356 6453 9498 4637 29791 AS path: 3356 6453 9498 4637 30844 AS path: 3356 6453 9498 4637 30844 36991 AS path: 3356 6453 9498 4637 30844 38056 38056 38056 AS path: 3356 6453 9498 4637 37468 37230 AS path: 3356 6453 9498 4637 37468 37230 37230 37230 AS path: 3356 6453 9498 4637 47869 I'm not sure what is supposed to be there for 6453_9498 but I suspect not nearly as much as is currently present (only 4637 listed here for brevity). huh... us-carrier -> tata -> airtel -> telstra .. that seems TOTALLY PLAUSIBLE.. no. On Thu, Nov 15, 2018 at 2:53 PM John Weekes > wrote: Marcus, From route-views output, it looks like AS9498/airtel is probably leaking your route between two of its upstreams (AS6453/Tata and AS4637/Telstra) overseas, funneling some of your traffic through their router. route-views>sh ip bgp 23.92.178.22 | i 9498 3356 6453 9498 4637 29791 1403 6453 9498 4637 29791 3549 3356 6453 9498 4637 29791 19214 3257 6453 9498 4637 29791 1403 6453 9498 4637 29791 286 6453 9498 4637 29791 53364 3257 6453 9498 4637 29791 3257 6453 9498 4637 29791 1239 6453 9498 4637 29791 2497 6453 9498 4637 29791 57866 6453 9498 4637 29791 7660 2516 6453 9498 4637 29791 701 6453 9498 4637 29791 3561 209 6453 9498 4637 29791 You might try halting advertisements to your AS4637/Telstra peer while you contact AS9498. -John On 11/15/2018 10:43 AM, Marcus Josephson wrote: Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34) 180.698 ms 180.610 ms 181.712 ms MPLS Label=344269 CoS=0 TTL=1 S=1 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 189.327 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 174.631 ms MPLS Label=609315 CoS=0 TTL=1 S=1 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 174.287 ms 173.370 ms 173.804 ms 4 120.29.215.202 (120.29.215.202) 179.104 ms 179.367 ms 179.324 ms 5 182.79.152.247 (182.79.152.247) 180.164 ms 182.79.152.253 (182.79.152.253) 184.816 ms 182.79.152.247 (182.79.152.247) 250.928 ms 6 unknown.telstraglobal.net (202.127.73.101) [AS 4637] 173.974 ms 173.986 ms 173.484 ms 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS 4637] 175.094 ms 175.699 ms 174.343 ms 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS 4637] 280.686 ms 288.703 ms 280.836 ms 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637] 278.021 ms 276.637 ms 302.249 ms 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4) 174.139 ms 174.163 ms 174.067 ms Marcus Josephson IP Operations mjosephson at inap.com This message is intended for the use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at anuragbhatia.com Thu Nov 15 23:37:50 2018 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 16 Nov 2018 05:07:50 +0530 Subject: Tata Scenic routing in LAX area? In-Reply-To: References: <7266d5f5-ec77-443b-4d83-4721c4b0894c@nuclearfallout.net> Message-ID: I have shared about this leak with known contacts in their NOC. Thanks. On Fri, Nov 16, 2018 at 4:05 AM Tom Beecher wrote: > I don't know what's less surprising, Tata making sure you see the entire > internet (wink wink), or Airtel leaking routes... :) > > On Thu, Nov 15, 2018 at 4:13 PM Lotia, Pratik M > wrote: > >> 9498/Airtel seems to be leaking a lot of routes. >> >> >> >> Source: https://bgpstream.com/ >> >> >> >> All Events for BGP Stream. >> >> *Event type* >> >> *Country* >> >> *ASN* >> >> *Start time (UTC)* >> >> *End time (UTC)* >> >> *More info* >> >> BGP Leak >> >> *Origin AS:* Etisalat Lanka (Pvt) Ltd. (AS 17470) >> *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) >> >> 2018-11-15 19:41:26 >> >> More detail >> >> BGP Leak >> >> *Origin AS:* Bharti Airtel Lanka Pvt. Limited (AS 132045) >> *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) >> >> 2018-11-15 19:41:26 >> >> More detail >> >> BGP Leak >> >> *Origin AS:* Antena3 S.A. (AS 47220) >> *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) >> >> 2018-11-15 19:22:39 >> >> More detail >> >> BGP Leak >> >> *Origin AS:* INDOSATM2 ASN (AS 4795) >> *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) >> >> 2018-11-15 18:46:59 >> >> More detail >> >> BGP Leak >> >> *Origin AS:* KANARTEL (AS 33788) >> *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) >> >> 2018-11-15 18:33:09 >> >> More detail >> >> BGP Leak >> >> *Origin AS:* FranTech Solutions (AS 53667) >> *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) >> >> 2018-11-15 18:04:47 >> >> More detail >> >> BGP Leak >> >> *Origin AS:* Pure Line Co. For Telecommunications & Internet Ltd. (AS >> 59458) >> *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) >> >> 2018-11-15 18:04:05 >> >> More detail >> >> BGP Leak >> >> *Origin AS:* Sepehr Ava Data Processing Company (LTD) (AS 51541) >> *Leaker AS: *BHARTI Airtel Ltd. (AS 9498) >> >> 2018-11-15 18:01:09 >> >> More detail >> >> >> >> >> >> >> >> ~Pratik Lotia >> >> >> >> “Improvement begins with I.” >> >> >> >> >> >> *From: *NANOG on behalf of Marcus Josephson < >> mjosephson at inap.com> >> *Date: *Thursday, November 15, 2018 at 13:48 >> *To: *Christopher Morrow , "stillwaxin at gmail.com" >> >> *Cc: *nanog list >> *Subject: *RE: Tata Scenic routing in LAX area? >> >> >> >> I have tried to reach out to Airtel, no response yet, but yah I could see >> my issue being due to them leaking routes. >> >> >> >> >> >> -Marcus >> >> >> >> *From:* NANOG *On Behalf Of *Christopher Morrow >> *Sent:* Thursday, November 15, 2018 3:30 PM >> *To:* stillwaxin at gmail.com >> *Cc:* nanog list >> *Subject:* Re: Tata Scenic routing in LAX area? >> >> >> >> >> >> On Thu, Nov 15, 2018 at 3:21 PM Michael Still >> wrote: >> >> FYI 29791 isn't the only origin I'm seeing this on from one point of view: >> >> AS path: 3257 6453 9498 4637 >> >> AS path: 3257 6453 9498 4637 10310 26085 14210 >> >> AS path: 3257 6453 9498 4637 20773 29066 >> >> AS path: 3257 6453 9498 4637 2906 >> >> AS path: 3257 6453 9498 4637 2906 40027 >> >> AS path: 3257 6453 9498 4637 29791 >> >> AS path: 3257 6453 9498 4637 30844 >> >> AS path: 3257 6453 9498 4637 30844 36991 >> >> AS path: 3257 6453 9498 4637 30844 38056 38056 38056 >> >> AS path: 3257 6453 9498 4637 37468 37230 >> >> AS path: 3257 6453 9498 4637 37468 37230 37230 37230 >> >> AS path: 3257 6453 9498 4637 47869 >> >> AS path: 3356 6453 9498 4637 >> >> AS path: 3356 6453 9498 4637 1299 2906 >> >> AS path: 3356 6453 9498 4637 1299 3491 20485 20485 >> 4809 49209 >> >> AS path: 3356 6453 9498 4637 20773 29066 >> >> AS path: 3356 6453 9498 4637 2906 >> >> AS path: 3356 6453 9498 4637 29791 >> >> AS path: 3356 6453 9498 4637 30844 >> >> AS path: 3356 6453 9498 4637 30844 36991 >> >> AS path: 3356 6453 9498 4637 30844 38056 38056 38056 >> >> AS path: 3356 6453 9498 4637 37468 37230 >> >> AS path: 3356 6453 9498 4637 37468 37230 37230 37230 >> >> AS path: 3356 6453 9498 4637 47869 >> >> >> >> I'm not sure what is supposed to be there for 6453_9498 but I suspect not >> nearly as much as is currently present (only 4637 listed here for brevity). >> >> >> >> >> >> huh... us-carrier -> tata -> airtel -> telstra .. that seems TOTALLY >> PLAUSIBLE.. no. >> >> >> >> >> >> >> >> On Thu, Nov 15, 2018 at 2:53 PM John Weekes >> wrote: >> >> Marcus, >> >> From route-views output, it looks like AS9498/airtel is probably leaking >> your route between two of its upstreams (AS6453/Tata and AS4637/Telstra) >> overseas, funneling some of your traffic through their router. >> >> route-views>sh ip bgp 23.92.178.22 | i 9498 >> 3356 6453 9498 4637 29791 >> 1403 6453 9498 4637 29791 >> 3549 3356 6453 9498 4637 29791 >> 19214 3257 6453 9498 4637 29791 >> 1403 6453 9498 4637 29791 >> 286 6453 9498 4637 29791 >> 53364 3257 6453 9498 4637 29791 >> 3257 6453 9498 4637 29791 >> 1239 6453 9498 4637 29791 >> 2497 6453 9498 4637 29791 >> 57866 6453 9498 4637 29791 >> 7660 2516 6453 9498 4637 29791 >> 701 6453 9498 4637 29791 >> 3561 209 6453 9498 4637 29791 >> >> You might try halting advertisements to your AS4637/Telstra peer while >> you contact AS9498. >> >> -John >> >> On 11/15/2018 10:43 AM, Marcus Josephson wrote: >> >> Anyone else seeing an odd Scenic routing in the LAX/SJE area for tata. >> >> >> >> traceroute to 23.92.178.22 (23.92.178.22), 30 hops max, 52 byte packets >> >> 1 if-ae-13-2.tcore2.lvw-los-angeles.as6453.net (64.86.252.34) 180.698 >> ms 180.610 ms 181.712 ms >> >> MPLS Label=344269 CoS=0 TTL=1 S=1 >> >> 2 if-ae-7-2.tcore2.svw-singapore.as6453.net (180.87.15.25) 189.327 ms >> if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.37) 176.800 ms >> if-ae-7-2.tcore2.svw-singapore.as6453.net (64.86.252.39) 174.631 ms >> >> MPLS Label=609315 CoS=0 TTL=1 S=1 >> >> 3 if-ae-20-2.tcore1.svq-singapore.as6453.net (180.87.96.21) 174.287 >> ms 173.370 ms 173.804 ms >> >> 4 120.29.215.202 (120.29.215.202) 179.104 ms 179.367 ms 179.324 ms >> >> 5 182.79.152.247 (182.79.152.247) 180.164 ms 182.79.152.253 >> (182.79.152.253) 184.816 ms 182.79.152.247 (182.79.152.247) 250.928 ms >> >> 6 unknown.telstraglobal.net (202.127.73.101) [AS 4637] 173.974 ms >> 173.986 ms 173.484 ms >> >> 7 i-93.sgpl-core02.telstraglobal.net (202.84.224.189) [AS 4637] >> 175.094 ms 175.699 ms 174.343 ms >> >> 8 i-10850.eqnx-core02.telstraglobal.net (202.84.140.46) [AS 4637] >> 280.686 ms 288.703 ms 280.836 ms >> >> 9 i-92.eqnx03.telstraglobal.net (202.84.247.17) [AS 4637] 278.021 ms >> 276.637 ms 302.249 ms >> >> 10 equinix-ix.sjc1.us.voxel.net (206.223.116.4) 174.139 ms 174.163 >> ms 174.067 ms >> >> >> >> >> >> Marcus Josephson >> >> IP Operations >> >> >> >> mjosephson at inap.com >> >> >> >> *This message is intended for the use of the intended recipient(s) and >> may contain confidential and privileged information. * >> >> *Any unauthorized review, use, disclosure or distribution is prohibited. >> If you are not the intended recipient, please contact* *the sender by >> reply email and destroy all copies of the original message.* >> >> >> >> >> >> >> >> >> -- >> >> [stillwaxin at gmail.com ~]$ cat .signature >> cat: .signature: No such file or directory >> [stillwaxin at gmail.com ~]$ >> >> 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. >> > -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Fri Nov 16 11:04:57 2018 From: randy at psg.com (Randy Bush) Date: Fri, 16 Nov 2018 03:04:57 -0800 Subject: IGP protocol In-Reply-To: References: Message-ID: > I heard that OSPF is only famous in asia region... > So that, please could you explain me > > 1. what is your backbone's IGP protocol? emacs From jjn at nuge.com Fri Nov 16 12:05:13 2018 From: jjn at nuge.com (Jay Nugent) Date: Fri, 16 Nov 2018 07:05:13 -0500 (EST) Subject: IGP protocol In-Reply-To: References: Message-ID: On Fri, 16 Nov 2018, Randy Bush wrote: >> I heard that OSPF is only famous in asia region... >> So that, please could you explain me >> >> 1. what is your backbone's IGP protocol? > > emacs > vi From merculiani at gmail.com Fri Nov 16 12:13:31 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Fri, 16 Nov 2018 06:13:31 -0600 Subject: IGP protocol In-Reply-To: References: Message-ID: X11 forwarding -> WINE -> notepad.exe On Fri, Nov 16, 2018, 06:06 Jay Nugent On Fri, 16 Nov 2018, Randy Bush wrote: > > >> I heard that OSPF is only famous in asia region... > >> So that, please could you explain me > >> > >> 1. what is your backbone's IGP protocol? > > > > emacs > > > > vi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Fri Nov 16 12:15:25 2018 From: job at instituut.net (Job Snijders) Date: Fri, 16 Nov 2018 13:15:25 +0100 Subject: IGP protocol In-Reply-To: References: Message-ID: Let’s please stay on topic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor at jvknet.com Fri Nov 16 13:04:46 2018 From: victor at jvknet.com (Victor Kuarsingh) Date: Fri, 16 Nov 2018 08:04:46 -0500 Subject: IGP protocol In-Reply-To: References: Message-ID: IM, Some good comments on this thread so far. Having chosen between OSPF and IS-IS more then once over the past 20 years for various networks and have chosen differently in some cases. I have a general preference for IS-IS in very large networks, but OSPF has performed well for me in larger nertowrks as well. I would say at this point, they both can do the same basic job with a few benefits attributable to each of them. With OSPFv3 now more mature, I am sure there may have been a few classic selections of IS-IS that may no longer go that way (+10 years ago, many with OSPFv2 networks turned on IS-IS since OSPFv3 implementations were quite new and IPv6 was staring to come online on backbones). Anyone turning on either IGP today, the major considerations (in my mind would be). 1. Which protocol do you have the operational staff to support? (Someone has to fix things when broken, so what talent do you have in ops?) 2. What protocol design capabilities do you have? (Good designers can learn either protocol, but historical experience can help in some cases) 3. Based on your vendor preference / selection, how well does each fair on your platform of choice ? (Most major vendors do a good job on both, but there are considerations) 5. Some people like that IS-IS is not based on IP and operates directly over Layer-2 (some arguable benefits in security domain - but you can secure both) 6. You running IPv4 and/or IPv6 on your underlay? (If you are running v4 only and use overlay for v4/v6 - some like the maturity of the OSPFv2 implementation) 7. Considerations for how you want your areas to run (some key differences in how L1/L2 areas work in IS-IS along with how boundaries work vs. OSPF areas and boundaries). 8. Route types. In some networks, folks want to import routes from other protocols (sometimes incoming protocols running at edges of networks etc). If you have that, you may want to consider how you want routes to operate. Regards, Victor K On Mon, Nov 12, 2018 at 2:45 PM im wrote: > goodmorning nanog, > > I heard that OSPF is only famous in asia region... > So that, please could you explain me > > 1. what is your backbone's IGP protocol? > 2. why you choose it? > > > thanks, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at nlnetlabs.nl Fri Nov 16 14:11:36 2018 From: alex at nlnetlabs.nl (Alex Band) Date: Fri, 16 Nov 2018 15:11:36 +0100 Subject: Community-driven FAQ for RPKI Message-ID: We put together a Frequently Asked Questions document for the Resource Public Key Infrastructure (RPKI). The aim is to provide a comprehensive overview of common questions that network operators and interested parties ask about the technology itself and the deployment of it, along with peer reviewed answers. To make this truly inclusive, it is available as an open source project on Github, allowing you to fork, do a pull request with an edit or addition, or open an issue in case you have suggestion. The original content was written by David Monosov, Melchior Aelmans, Job Snijders and myself, along with contributions from network operators around the world. The Github project is available here: https://github.com/NLnetLabs/rpki-faq The contents are automatically published on the NLnet Labs website: https://nlnetlabs.nl/projects/rpki/faq/ Many thanks to the NLNOG community for getting this off the ground. Cheers, Alex From brad.raymo at gmail.com Fri Nov 16 15:49:58 2018 From: brad.raymo at gmail.com (BRAD RAYMO) Date: Fri, 16 Nov 2018 08:49:58 -0700 Subject: NANOG 75 Call For Presentations Update Message-ID: NANOG Community, The NANOG Program Committee (PC would like to remind you that we are now accepting proposals for all sessions at NANOG 75 in San Francisco, California, February 18-20, 2019. 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/1bqspy/6K. *Due to the holidays, we have extended the deadline for slides to be submitted to December 17th.* The NANOG PC seeks proposals for presentations, panels, tutorials, and track sessions for the NANOG 75 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 75 submissions can be entered on the NANOG Program Committee Tool (PC Tool) at: https://pc.nanog.org The primary speaker, moderator, or author should submit a presentation proposal and an abstract in the PC Tool. -- Select “Propose Talk” from the Talks menu -- Select NANOG 75 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 PC Tool prior to 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 if not already submitted with initial proposal. Please submit initial draft slides early -- Panel and Track submissions should provide topic list and intended/confirmed participants in the abstract -- 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 will respond. Otherwise, submit your talk, keynote, track, or panel proposal to the PC Tool without delay! We look forward to reviewing your submission. Key Dates for NANOG 75: Oct. 29, 2018: CFP Opens & Agenda Outline Posted *Dec. 17, 2018: CFP Deadline: Presentation Slides Due* Jan. 14, 2019: CFP Topic List & NANOG Meeting Highlights Page Jan. 22, 2019: NANOG 75 Agenda Published Feb. 11, 2019: Speaker FINAL presentations to PC tool or speaker-support Feb. 17, 2019: Lightning Talk Submissions Open (Abstracts Only) Feb. 17, 2019: Onsite Registration Final slides MUST be submitted by Monday, February 11, 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 February in San Francisco! Sincerely, Brad Raymo NANOG PC -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Nov 16 18:03:29 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Nov 2018 04:03:29 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181116180329.38836C450F@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 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 17 Nov, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 726297 Prefixes after maximum aggregation (per Origin AS): 279323 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 348399 Total ASes present in the Internet Routing Table: 62474 Prefixes per ASN: 11.63 Origin-only ASes present in the Internet Routing Table: 53901 Origin ASes announcing only one prefix: 23425 Transit ASes present in the Internet Routing Table: 8573 Transit-only ASes present in the Internet Routing Table: 254 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 37 Prefixes from unregistered ASNs in the Routing Table: 34 Number of instances of unregistered ASNs: 34 Number of 32-bit ASNs allocated by the RIRs: 24905 Number of 32-bit ASNs visible in the Routing Table: 20153 Prefixes from 32-bit ASNs in the Routing Table: 86126 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 263 Number of addresses announced to Internet: 2862740641 Equivalent to 170 /8s, 161 /16s and 244 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.1 Total number of prefixes smaller than registry allocations: 242331 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 198594 Total APNIC prefixes after maximum aggregation: 56383 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 196021 Unique aggregates announced from the APNIC address blocks: 80441 APNIC Region origin ASes present in the Internet Routing Table: 9236 APNIC Prefixes per ASN: 21.22 APNIC Region origin ASes announcing only one prefix: 2584 APNIC Region transit ASes present in the Internet Routing Table: 1369 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: 4219 Number of APNIC addresses announced to Internet: 768640640 Equivalent to 45 /8s, 208 /16s and 134 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 215480 Total ARIN prefixes after maximum aggregation: 102201 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 214804 Unique aggregates announced from the ARIN address blocks: 102213 ARIN Region origin ASes present in the Internet Routing Table: 18304 ARIN Prefixes per ASN: 11.74 ARIN Region origin ASes announcing only one prefix: 6806 ARIN Region transit ASes present in the Internet Routing Table: 1835 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2505 Number of ARIN addresses announced to Internet: 1103190176 Equivalent to 65 /8s, 193 /16s and 88 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 198202 Total RIPE prefixes after maximum aggregation: 94737 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 194634 Unique aggregates announced from the RIPE address blocks: 115231 RIPE Region origin ASes present in the Internet Routing Table: 25636 RIPE Prefixes per ASN: 7.59 RIPE Region origin ASes announcing only one prefix: 11479 RIPE Region transit ASes present in the Internet Routing Table: 3546 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7587 Number of RIPE addresses announced to Internet: 715506304 Equivalent to 42 /8s, 165 /16s and 194 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 93976 Total LACNIC prefixes after maximum aggregation: 21764 LACNIC Deaggregation factor: 4.32 Prefixes being announced from the LACNIC address blocks: 95375 Unique aggregates announced from the LACNIC address blocks: 41696 LACNIC Region origin ASes present in the Internet Routing Table: 7804 LACNIC Prefixes per ASN: 12.22 LACNIC Region origin ASes announcing only one prefix: 2147 LACNIC Region transit ASes present in the Internet Routing Table: 1481 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5349 Number of LACNIC addresses announced to Internet: 172593664 Equivalent to 10 /8s, 73 /16s and 146 /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: 20010 Total AfriNIC prefixes after maximum aggregation: 4210 AfriNIC Deaggregation factor: 4.75 Prefixes being announced from the AfriNIC address blocks: 25200 Unique aggregates announced from the AfriNIC address blocks: 8571 AfriNIC Region origin ASes present in the Internet Routing Table: 1219 AfriNIC Prefixes per ASN: 20.67 AfriNIC Region origin ASes announcing only one prefix: 409 AfriNIC Region transit ASes present in the Internet Routing Table: 245 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 493 Number of AfriNIC addresses announced to Internet: 102417408 Equivalent to 6 /8s, 26 /16s and 196 /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 4639 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4610 518 515 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3012 1154 94 VIETEL-AS-AP Viettel Group, VN 45899 2947 1689 111 VNPT-AS-VN VNPT Corp, VN 4766 2799 11130 764 KIXS-AS-KR Korea Telecom, KR 9829 2747 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2428 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2407 4907 31 CTTNET China TieTong Telecommunications 17974 2247 968 51 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2123 421 172 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 3486 1324 84 SHAW - Shaw Communications Inc., CA 11492 3466 224 627 CABLEONE - CABLE ONE, INC., US 22773 3277 2973 166 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2503 5215 930 AMAZON-02 - Amazon.com, Inc., US 18566 2154 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2145 2739 544 CHARTER-NET-HKY-NC - Charter Communicat 16625 2121 1146 1574 AKAMAI-AS - Akamai Technologies, Inc., 5650 2086 3074 1461 FRONTIER-FRTR - Frontier Communications 30036 2066 347 135 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2044 5079 594 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5092 1613 133 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3038 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2579 569 1918 AKAMAI-ASN1, US 12389 2186 2194 617 ROSTELECOM-AS, RU 34984 2042 337 540 TELLCOM-AS, TR 9121 1845 1691 17 TTNET, TR 13188 1605 100 42 TRIOLAN, UA 8402 1285 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1218 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5462 3313 605 Uninet S.A. de C.V., MX 10620 3120 475 885 Telmex Colombia S.A., CO 11830 2668 370 75 Instituto Costarricense de Electricidad 6503 1660 449 54 Axtel, S.A.B. de C.V., MX 7303 1441 963 208 Telecom Argentina S.A., AR 28573 1192 2237 191 CLARO S.A., BR 6147 1111 377 29 Telefonica del Peru S.A.A., PE 3816 1021 512 118 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 938 145 72 Alestra, S. de R.L. de C.V., MX 13999 922 537 260 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1167 394 29 LINKdotNET-AS, EG 37611 905 107 9 Afrihost, ZA 36903 796 400 142 MT-MPLS, MA 36992 763 1411 43 ETISALAT-MISR, EG 8452 649 1728 15 TE-AS TE-AS, EG 24835 641 680 21 RAYA-AS, EG 37492 467 470 57 ORANGE-, TN 29571 464 70 12 ORANGE-COTE-IVOIRE, CI 23889 401 231 15 MauritiusTelecom, MU 15399 396 45 11 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 5462 3313 605 Uninet S.A. de C.V., MX 12479 5092 1613 133 UNI2-AS, ES 4538 4639 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4610 518 515 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3486 1324 84 SHAW - Shaw Communications Inc., CA 11492 3466 224 627 CABLEONE - CABLE ONE, INC., US 22773 3277 2973 166 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3120 475 885 Telmex Colombia S.A., CO 8551 3038 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5092 4959 UNI2-AS, ES 4538 4639 4565 ERX-CERNET-BKB China Education and Research Net 7545 4610 4095 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3486 3402 SHAW - Shaw Communications Inc., CA 22773 3277 3111 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3038 2995 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3012 2918 VIETEL-AS-AP Viettel Group, VN 11492 3466 2839 CABLEONE - CABLE ONE, INC., US 45899 2947 2836 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 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 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 92937 UNALLOCATED 110.49.72.0/24 45458 SBN-AWN-AS-02-AP SBN-ISP/AWN-I 4230060012 PRIVATE 132.190.106.0/24 64673 -Private Use AS-, ZZ 4230060012 PRIVATE 132.190.232.0/24 64673 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.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.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.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 45.252.236.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 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:290 /13:567 /14:1118 /15:1896 /16:13312 /17:7873 /18:13825 /19:25455 /20:39503 /21:46131 /22:90381 /23:74057 /24:409466 /25:828 /26:646 /27:653 /28:37 /29:20 /30:21 /31:4 /32:54 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3916 5092 UNI2-AS, ES 6327 3258 3486 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2754 3466 CABLEONE - CABLE ONE, INC., US 22773 2529 3277 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2494 3038 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2048 2154 MEGAPATH5-US - MegaPath Corporation, US 11830 2012 2668 Instituto Costarricense de Electricidad y Telec 30036 1815 2066 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2086 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1626 2:891 4:18 5:2721 6:43 7:1 8:1143 12:1872 13:254 14:1877 15:34 16:3 17:196 18:58 20:48 23:2547 24:2420 25:2 27:2528 31:2007 32:85 35:31 36:535 37:2937 38:1567 39:272 40:120 41:3189 42:726 43:1987 44:133 45:6061 46:3057 47:237 49:1314 50:1071 51:318 52:1109 54:362 55:1 56:6 57:41 58:1701 59:1032 60:463 61:2093 62:1879 63:1799 64:5069 65:2199 66:4813 67:2643 68:1157 69:3372 70:1179 71:602 72:2236 74:2724 75:411 76:495 77:1691 78:1747 79:2219 80:1590 81:1416 82:1058 83:813 84:1067 85:2113 86:569 87:1497 88:938 89:2388 90:210 91:6481 92:1285 93:2389 94:2391 95:3078 96:913 97:348 98:940 99:161 100:87 101:1167 102:277 103:19218 104:3605 105:241 106:876 107:1828 108:705 109:3425 110:1635 111:1827 112:1407 113:1328 114:1146 115:1698 116:1662 117:1879 118:2207 119:1675 120:1118 121:1036 122:2344 123:1686 124:1454 125:1952 128:1211 129:667 130:513 131:1630 132:718 133:191 134:1039 135:229 136:532 137:668 138:1959 139:742 140:564 141:755 142:805 143:1011 144:842 145:498 146:1250 147:767 148:1686 149:781 150:769 151:996 152:890 153:325 154:2055 155:955 156:1581 157:844 158:653 159:1865 160:1467 161:884 162:2639 163:757 164:1113 165:1595 166:460 167:1340 168:3158 169:865 170:3997 171:499 172:1051 173:2103 174:988 175:832 176:2197 177:3999 178:2513 179:1310 180:2171 181:2379 182:2598 183:1481 184:1139 185:14352 186:3608 187:2483 188:2923 189:2027 190:8322 191:1387 192:9910 193:6422 194:5247 195:4034 196:2992 197:1790 198:5665 199:5997 200:7314 201:5003 202:10246 203:10195 204:4613 205:2996 206:3260 207:3220 208:3970 209:4176 210:3857 211:2017 212:3021 213:2819 214:1047 215:55 216:6036 217:2188 218:877 219:575 220:1827 221:998 222:969 223:1402 End of report From mark.tinka at seacom.mu Sun Nov 18 09:11:47 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 18 Nov 2018 11:11:47 +0200 Subject: IGP protocol In-Reply-To: References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> Message-ID: <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> On 13/Nov/18 17:30, Saku Ytti wrote: > Do you know connected host can't talk ISIS to you? > > ISIS is false security. In modern platforms OSPF almost always can be > protected (iACL), ISIS in many times cannot. I'd run MD5 in either > case. Yes, IS-IS is designed to speak to connected hosts, but will only do so if you enable IS-IS on the interface facing that host. The scope of the exposure, while present, is limited to the radius between your device and the connected host, vs. OSPF which can be attacked from much farther away. Running MD5 on your IGP (and iBGP) should be sold at birth. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sun Nov 18 09:12:40 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 18 Nov 2018 11:12:40 +0200 Subject: IGP protocol In-Reply-To: References: Message-ID: On 14/Nov/18 02:24, im wrote: > Thanks for all to letting me know. > > I have operating OSPF/iBGP backbone for 10+ years, now my brain has > entrenched to OSPF. > Now, I beginning to learn IS-IS for more knowledge. More power to you :-). Mark. From mark.tinka at seacom.mu Sun Nov 18 09:41:01 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 18 Nov 2018 11:41:01 +0200 Subject: IGP protocol In-Reply-To: References: Message-ID: <709c6630-d4d5-2ef4-34df-03180e5c0142@seacom.mu> On 16/Nov/18 15:04, Victor Kuarsingh wrote: > 3. Based on your vendor preference / selection, how well does each > fair on your platform of choice ? (Most major vendors do a good job on > both, but there are considerations) IS-IS is notoriously bad in Quagga. I met with some of the developers of FRRouting and was happy to learn that they've made plenty of strides with pushing IS-IS for production. I'm going to install and test it, as it would be good to stop having to redistribute from OSPF into IS-IS for my Anycast name servers. Mark. From saku at ytti.fi Sun Nov 18 09:58:22 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 18 Nov 2018 11:58:22 +0200 Subject: IGP protocol In-Reply-To: <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> Message-ID: On Sun, 18 Nov 2018 at 11:15, Mark Tinka wrote: > Yes, IS-IS is designed to speak to connected hosts, but will only do so if you enable IS-IS on the interface facing that host. > The scope of the exposure, while present, is limited to the radius between your device and the connected host, vs. OSPF which can be attacked from much farther away. Should. OSPF you can protect in edge with ACL. In ISIS you hope it's protected. 7600 punts it in every interface, if one interface speaks ISIS, because it doesn't have per-interface punt masks. MX: 2012-10-18 0002096778/2012-1018-0446 (test13nqe3) (11.4R5) ++ytti * ISIS gets to control-plane, even when only family inet is configured This was fixed on later releases. Those are only two devices I've specifically tested for this. I don't think people know what happens to ISIS in their platform, if vendor doesn't know. I wonder what these nice BRCM kit do? I know that one of the more popular entrant can't be protected against ANY protocol until 2019Q1, and two of the networks I know running it in the edge, were entirely unaware of it. My point is, perhaps in theory ISIS is more secure, but in practice OSPF is, because OSPF can be protected perfectly in iACL, feature which is available in HW in cheapest L3 switches. Only reason people think different, is because they don't test it. > Running MD5 on your IGP (and iBGP) should be sold at birth. Yes, or MacSec. -- ++ytti From alfie at fdx.services Sun Nov 18 10:12:27 2018 From: alfie at fdx.services (Alfie Pates) Date: Sun, 18 Nov 2018 10:12:27 +0000 Subject: IGP protocol In-Reply-To: References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> Message-ID: <1542535947.1541447.1580774296.7826FFBD@webmail.messagingengine.com> > or MacSec There's a school of thought which suggests MD5 security on single-hop BGP is absolute theatre with no security benefit and that MACsec is the route you should be taking. ~ a From saku at ytti.fi Sun Nov 18 10:59:19 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 18 Nov 2018 12:59:19 +0200 Subject: IGP protocol In-Reply-To: <1542535947.1541447.1580774296.7826FFBD@webmail.messagingengine.com> References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> <1542535947.1541447.1580774296.7826FFBD@webmail.messagingengine.com> Message-ID: On Sun, 18 Nov 2018 at 12:15, Alfie Pates wrote: > There's a school of thought which suggests MD5 security on single-hop BGP is absolute theatre with no security benefit and that MACsec is the route you should be taking. AFAIK there are no known attacks against HMAC-MD5. eBGP I don't care about. But for iBGP I consider this a problem: Someone goes to random forest where fibre is trenched, digs it up, taps fibre until correct fibre+wave is found, then injects BGP UPDATE to change L3 MPLS VPN labels, and diverts traffic through their device while returning it safely. Seems quite cheap attack, maybe <5k, and entirely compromises MPLS security model. iBGP MD5 should protect well from this. Not arguing that MacSec isn't superior feature, it's just cost of MacSec is non-trivial compared to cost of HMAC-MD5, and it seems HMAC-MD5 for certain attacks is strong guarantee. Ideally we'd implement TCP-AO (RFC5925) to replace BGP HMAC-MD5, just to get derived secret instead of static (how many change their MD5 secret periodically?) but it looks like ship may have sailed on that one. -- ++ytti From nick at foobar.org Sun Nov 18 11:13:12 2018 From: nick at foobar.org (Nick Hilliard) Date: Sun, 18 Nov 2018 11:13:12 +0000 Subject: IGP protocol In-Reply-To: References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> <1542535947.1541447.1580774296.7826FFBD@webmail.messagingengine.com> Message-ID: <3941db12-39d2-7b7d-27e9-d882bc5eabc0@foobar.org> Saku Ytti wrote on 18/11/2018 10:59: > AFAIK there are no known attacks against HMAC-MD5. eBGP I don't care > about. But for iBGP I consider this a problem: one of the few uses for tcp/md5 protection on bgp sessions can be found at IXPs where if you have an participant leaving the fabric, there will often be leftover bgp sessions configured on other routers on the exchange. Pre-configuring MD5 on BGP sessions will ensure that these cannot be used to spoof connectivity to the old network. Nick From mark.tinka at seacom.mu Sun Nov 18 15:35:29 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 18 Nov 2018 17:35:29 +0200 Subject: IGP protocol In-Reply-To: References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> Message-ID: <961f1589-76dd-acdf-8b52-90da3793c5b6@seacom.mu> On 18/Nov/18 11:58, Saku Ytti wrote: > Should. OSPF you can protect in edge with ACL. In ISIS you hope it's protected. > > 7600 punts it in every interface, if one interface speaks ISIS, > because it doesn't have per-interface punt masks. > > MX: > 2012-10-18 0002096778/2012-1018-0446 (test13nqe3) (11.4R5) ++ytti > * ISIS gets to control-plane, even when only family inet is configured > > This was fixed on later releases. While this isn't cool, I don't see this as a major issue when put up against any other nasty's you find in vendor implementations. Find a problem, report it to the vendor, work with them to fix it, close the hole. I've found my fair share of IS-IS bugs since I began using it back in 2007 (when SRC ruled the roost on 7200/7600). What matters is that stuff gets fixed. > > My point is, perhaps in theory ISIS is more secure, but in practice > OSPF is, because OSPF can be protected perfectly in iACL, feature > which is available in HW in cheapest L3 switches. Only reason people > think different, is because they don't test it. I would not be opposed to spending some time with you to hit IS-IS on vendor platforms with known bugs fixed to prove this point. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sun Nov 18 15:38:09 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 18 Nov 2018 17:38:09 +0200 Subject: IGP protocol In-Reply-To: <3941db12-39d2-7b7d-27e9-d882bc5eabc0@foobar.org> References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> <1542535947.1541447.1580774296.7826FFBD@webmail.messagingengine.com> <3941db12-39d2-7b7d-27e9-d882bc5eabc0@foobar.org> Message-ID: <45ca8980-4f8f-fe18-14f2-45a1c87a8d7b@seacom.mu> On 18/Nov/18 13:13, Nick Hilliard wrote: >   > > one of the few uses for tcp/md5 protection on bgp sessions can be > found at IXPs where if you have an participant leaving the fabric, > there will often be leftover bgp sessions configured on other routers > on the exchange.  Pre-configuring MD5 on BGP sessions will ensure that > these cannot be used to spoof connectivity to the old network. Except that exchange point members are notorious for not liking session MD5 protection in the interest of keeping deployment simple. We made it mandatory for peers 6 years ago. We had to loosen our stance a year later :-). Mark. From saku at ytti.fi Sun Nov 18 16:00:35 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 18 Nov 2018 18:00:35 +0200 Subject: IGP protocol In-Reply-To: <961f1589-76dd-acdf-8b52-90da3793c5b6@seacom.mu> References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> <961f1589-76dd-acdf-8b52-90da3793c5b6@seacom.mu> Message-ID: On Sun, 18 Nov 2018 at 17:35, Mark Tinka wrote: > I've found my fair share of IS-IS bugs since I began using it back in 2007 (when SRC ruled the roost on 7200/7600). What matters is that stuff gets fixed. In 7600 it is simply not possible because of hardware limitation. I'd be surprised if 7600 was alone here. But does this actually matter? Probably not. I assume we have functional market, and if there was business case in having secure control-planes we would have them. Networks work because no one is motivated to attack the infrastructure, not because we can or have protected it. I expect in time of crisis all state actors can disable the infrastructure in matter of minutes, as they likely have collection of these problems that control-plane protection has. But we will probably fix the infrastructure in matter of days, so probably even then not a big deal. -- ++ytti From gtaylor at tnetconsulting.net Sun Nov 18 19:04:57 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 18 Nov 2018 12:04:57 -0700 Subject: IGP protocol In-Reply-To: References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> <1542535947.1541447.1580774296.7826FFBD@webmail.messagingengine.com> Message-ID: <85e0ce15-1661-8744-052c-71e04a056f6e@spamtrap.tnetconsulting.net> Warning: n00b level question, ignore at your own discretion. On 11/18/18 3:59 AM, Saku Ytti wrote: > Not arguing that MacSec isn't superior feature, it's just cost of MacSec > is non-trivial compared to cost of HMAC-MD5, and it seems HMAC-MD5 > for certain attacks is strong guarantee. Ideally we'd implement TCP-AO > (RFC5925) to replace BGP HMAC-MD5, just to get derived secret instead > of static (how many change their MD5 secret periodically?) but it looks > like ship may have sailed on that one. Is it not possible to protect (just) the eBGP with IPsec? I would think that IPsec would provide the desired protection and that tuning filters to the proper ports would reduce the overhead that MACsec might incur with all traffic being encrypted. Does anyone have any real world experience to offer this n00b? Thank you in advance. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From saku at ytti.fi Sun Nov 18 19:24:22 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 18 Nov 2018 21:24:22 +0200 Subject: IGP protocol In-Reply-To: <85e0ce15-1661-8744-052c-71e04a056f6e@spamtrap.tnetconsulting.net> References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> <1542535947.1541447.1580774296.7826FFBD@webmail.messagingengine.com> <85e0ce15-1661-8744-052c-71e04a056f6e@spamtrap.tnetconsulting.net> Message-ID: On Sun, 18 Nov 2018 at 21:07, Grant Taylor via NANOG wrote: > Is it not possible to protect (just) the eBGP with IPsec? Not on all gears SPs are deploying. But people doing this. > I would think that IPsec would provide the desired protection and that > tuning filters to the proper ports would reduce the overhead that MACsec > might incur with all traffic being encrypted. Correct and more important being control-plane only feature, it's significantly cheaper. Personally I do trust HMAC-MD5 to offer sufficient security today. -- ++ytti From mark.tinka at seacom.mu Mon Nov 19 11:57:49 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 19 Nov 2018 13:57:49 +0200 Subject: IGP protocol In-Reply-To: References: <1b458f8b-edb4-9867-b8f0-08a727ff869e@seacom.mu> <1e2ea486-77cd-58c6-5f99-be6627375227@pubnix.net> <8c4b16d1-6509-4b87-0017-03314c8da223@seacom.mu> <961f1589-76dd-acdf-8b52-90da3793c5b6@seacom.mu> Message-ID: <5890bb06-39fb-344c-23a9-890c28a32e4a@seacom.mu> On 18/Nov/18 18:00, Saku Ytti wrote: > In 7600 it is simply not possible because of hardware limitation. I'd > be surprised if 7600 was alone here. I've never ran the 7600 (the 6500 was as close as I got, but that was just purely for Ethernet switching). While it wouldn't surprise me that shops were still running this platform in 2018, it's starting to show its age... > But does this actually matter? Probably not. I assume we have > functional market, and if there was business case in having secure > control-planes we would have them. Networks work because no one is > motivated to attack the infrastructure, not because we can or have > protected it. > I expect in time of crisis all state actors can disable the > infrastructure in matter of minutes, as they likely have collection of > these problems that control-plane protection has. But we will probably > fix the infrastructure in matter of days, so probably even then not a > big deal. Fair point. Mark. From ymitsos at noc.grnet.gr Sat Nov 17 10:38:45 2018 From: ymitsos at noc.grnet.gr (Yannis Mitsos) Date: Sat, 17 Nov 2018 12:38:45 +0200 Subject: L3 Network topology in YANG Message-ID: <1760484f-2f82-ecd8-5dcd-be6110586c6e@noc.grnet.gr> All, I was wondering if there is any network operator who exposes (dynamically?) its topology in YANG based on RFC8346 [1]. I understand that for commercial operators and purposes, may not be of any substantial value. We are assessing some available tools[2],[3],[4] on how to achieve this but we would like to know if there is any success story out there. Regards, Yannis [1] https://tools.ietf.org/html/rfc8346 [2] https://github.com/robshakir/pyangbind [3] https://github.com/YangModels/yang.git [4] https://developer.cisco.com/site/ydk From sroche at lakelandnetworks.com Sat Nov 17 16:01:51 2018 From: sroche at lakelandnetworks.com (Sam Roche) Date: Sat, 17 Nov 2018 16:01:51 +0000 Subject: DAZN Geolocation issue Message-ID: Are there any DAZN contacts on-list? We are having geolocation issues with a few IP blocks we purchased last summer. Please contact me off list. Thanks, Sam. Sam Roche | Supervisor of Network Operations | Lakeland Networks Support: support at lakelandnetworks.com 705-646-1846 | Direct: sroche at lakelandnetworks.com 705-640-0086 | www.lakelandnetworks.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at anuragbhatia.com Tue Nov 20 17:20:48 2018 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 20 Nov 2018 22:50:48 +0530 Subject: Amazon now controls 3.0.0.0/8 In-Reply-To: References: Message-ID: A large part of those peerings appears across various tools because people (mistakenly) just use "1" in prepends (and for that matter AS2 and AS3 as well). We looked at that data a while back and there was a very high amount of noise around that ASN. On Fri, Nov 9, 2018 at 8:16 AM Ross Tajvar wrote: > Speaking of AS1 - I've been wondering, what's it being used for? It looks > like Level3 owns it, and it's announcing a handful of prefixes and peering > with a bunch of random ASes from many different countries. > > On Thu, Nov 8, 2018 at 9:19 PM, Steve Meuse wrote: > >> >> John Orthoefer and I (and dozens of other BBN folks on this list) both >> worked for BBNPlanet at the time that 4.2.2.1 and 4.2.2.2 were assigned. >> John was one of the folks who built and ran that system. >> >> So when he said "I wish we could have used 4.4.4.4" and my comment of "I >> think the dial modem folks beat us to..." was referring to the fact that >> when 4/8 was first being deployed on AS1 we started assigning blocks to >> various groups and they realized that 4.4.4.0/XX had already been >> delegated to another internal group (I think it was the dial group). >> >> >> >> On Thu, Nov 8, 2018 at 8:45 PM Tom Beecher wrote: >> >>> 4.0.0.0/8 has been GTE/Level3 forever. >>> >>> 4.2.2.1 - 6 have been L3 DNS as far back as I can remember. >>> >>> On Thu, Nov 8, 2018 at 8:32 PM Todd Underwood >>> wrote: >>> >>>> google used 4.4.4.4 for DNS in the past (2010, IIRC). >>>> >>>> t >>>> >>>> On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse wrote: >>>> >>>>> >>>>> I think it was the dial modem team that beat us to 4.4.4.0/24? >>>>> >>>>> -Steve >>>>> >>>>> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer >>>>> wrote: >>>>> >>>>>> I wish we could have used 4.4.4.4. Although at the time I suspect we >>>>>> would have used 4.4.4.[123]. >>>>>> >>>>>> Johno >>>>>> >>>>>> On Nov 8, 2018, at 18:58, Matt Erculiani >>>>>> wrote: >>>>>> >>>>>> So it looks like GE will be solvent for a few more years and 3.3.3.3 >>>>>> DNS is incoming. >>>>>> >>>>>> -Matt >>>>>> >>>>>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >>>>> >>>>>>> https://news.ycombinator.com/item?id=18407173 >>>>>>> >>>>>>> Quoting from the post: >>>>>>> >>>>>>> " >>>>>>> >>>>>>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. >>>>>>> >>>>>>> Previous owner was GE. >>>>>>> >>>>>>> Anecdotal reports across the Internet that AWS EIPs are now being >>>>>>> assigned in that range. >>>>>>> >>>>>>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html >>>>>>> >>>>>>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html >>>>>>> " >>>>>>> >>>>>>> >>>>>>> >>>>>>> > -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Nov 20 22:00:11 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 20 Nov 2018 14:00:11 -0800 Subject: Networkatlas Message-ID: Hello there, This month has been incredible in so many ways for NetworkAtlas project. You can see how incredible progress we have made by visiting https://dev.networkatlas.org You can also see where we are missing data! We are getting close to having self service ui/api ready which will allow you to register, and upload your own kmz. You can also request to be able to manage (like up/down) cables you own. With that said, we are looking for people who can help in following areas. 1) we are looking for experienced editors who know and can validate the requests which will come from people uploding cable kmzs and also help clean up existing data we have. 2) looking for people who want to demo submitting actual kmzs of network they own and operate. 3) dc providers who want to provide more details of their datacenters (we have 3D buildings now in the map) If you want to help in any other way, please let us know! As always thank you and we will report back in december with more progress! Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From emontemer at reversepath.net Tue Nov 20 20:53:57 2018 From: emontemer at reversepath.net (Erik Montemer) Date: Tue, 20 Nov 2018 15:53:57 -0500 Subject: at&t abuse Message-ID: <16732e6ad0e.c4518f6526100.7903863617112907311@reversepath.net> Hello,Can some from at&t rbl abuse please contact me off list? Having difficulty with RBL delisting through the appropriate and recommended channels.Thank you,Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed Nov 21 03:31:44 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 20 Nov 2018 19:31:44 -0800 Subject: Colombian Internet Message-ID: Hello there, I am looking for individuals who are experienced in colombian internet ecosystem who can do due diligence work and answer couple of questions. If you know about Colombian Internet ecosystem and please contact me offlist Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Wed Nov 21 09:32:39 2018 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 21 Nov 2018 01:32:39 -0800 Subject: Crooks on the Intrernet: Episode 6,427 Message-ID: <85473.1542792759@segfault.tristatelogic.com> I just thought that y'all might want to be aware of this. My attention was called recently to a RIPE-issued block of IPv4 addresses assigned to a particular Polish firm (Marton Media: https://martonmedia.pl/) that appears to sell digital TV services. The block in question is 91.149.192.0/18 aka "PL-MARTON-20061120". It appears that perhaps this company didn't quite need all of that /18 that it got from RIPE, so it looks like they parceled out some sub-parts of that /18 to at least a couple of other parties, to wit: "Hostermatrix LLC" aka "ORG-HL183-RIPE": 91.149.232.0/22 91.149.252.0/22 "Real Tone Hosting LLC" aka "ORG-RTHL1-RIPE" 91.149.224.0/21 91.149.236.0/22 91.149.240.0/21 91.149.248.0/22 Ignoring, for the moment, the fact that neither of these companies actually seem to exist anywhere... at least not on -this- planet... my attention was further called to the pair of /22 blocks that have been sub-allocated by Marton Media (Poland) to this thing they are calling "Hostermatrix LLC". The reverse DNS for those blocks looked like this, just a few short days ago, on November 16th: https://pastebin.com/raw/hjWG5KxA But apparently, that all has been changed rather substantially, just in the past few days, so now it all looks like this instead: https://pastebin.com/raw/58qCdPrc (You might call this the "Schrodinger Effect". When researching bad guys on the Internet, their stuff may change, even as you are looking at it, and perhaps even -because- you are looking at it.) Anyway, the rDNS listing, as it was on the 16th, looked more than a little fishy. Why would anyone need quite this many different outbound SMTP servers? The one and only second-level domain name that appeared in the rDNS listing as of the 16th was "sm-smtp.net". I did a bit of research on that domain name and found that historical passive DNS associates that domain, quite unambiguously, with another domain name, sendermatrix.net. It didn't take much more research for me to find out that a company called Sender Matrix, LLC is in fact registered in the State of Florida to a Mr. Jay Passerino. Mr. Passerino appears to have registered a number of different Florida companies: Haggle USA Corp. Mahem Partners, Inc. Sourcehire, LLC Boat App, LLC, All In Nutraceuticals, LLC Miami Suppliments, LLC Balladex Enterprises, LLC Sender Matrix, LLC (http://sendermatrix.com/) Gasher, Inc. Digital Platinum, Inc. (http://digital-platinum.com/) BB&M Ventures, Inc. Of course, there's nothing at all wrong with Mr. Passerino having prolific and multiple business interests, however a fellow who also, coincidentally, has the name Jay Passerino, and who also, coincidentally, hails from the State of Florida seems to have gotten into what the Brits might call "a spot of bother" with respect to not one but -two- U.S. federal regulatory agencies of late, specifically the SEC and the CFTC, both of which appear to have taken serious issue with this Mr. Jay Passerino's business practices, along with those of several of his cohorts: CFTC Press Release: https://www.cftc.gov/PressRoom/PressReleases/7807-18 SEC Press Release: https://www.sec.gov/news/press-release/2018-216 As you can see, both the SEC and the CFTC elected to take issue... on the exact same day, by the way... with this Mr. Jay Passerino's activities on the Internet, and specifically relating to "pump and dump" email scams. Returning now to the subject of the two /22 sub-allocations that were made by this Polish outfit, Marton Media, to this apparently non-existant corporate entity called "Hostermatrix LLC", i hope that it will not escape anoyone's notice that whereas the IPv4 blocks in question have been provided... seemingly to an Internet crook named Jay Passerino... by a Polish company, the actual -routing- of each of these blocks shows the participation of some other actors within two more (different) European countries: 91.149.232.0/22 - routed by AS51765 (Oy Creanova Hosting Solutions Ltd. - Finland) 91.149.252.0/22 - routed by AS24768 (ALMOUROLTEC SERVICOS DE INFORMATICA E INTERNET LDA - Portugal) The only observation I can offer with respect to all of the forgoing, is the rather obvious one: All of this is, to say the least, rather suspicious. But wait! There's more! It appears that Mr. Passerino's IPv4 assets are not strictly limited to RIPEland. Theres also a Direct Allocation block of ARIN IPv4 space (138.128.224.0/22) that is explicitly registered to Sender Matrix LLC of Miami, Florida: https://pastebin.com/raw/cZcsPYrL This block is routed by AS62519, Netrouting Inc., also, according to ARIN records, of Miami, Florida: https://pastebin.com/raw/mJKnJX6w Curiously, the one and only route being announced by AS62519 is for the /22 registered to Mr. Passerino's Sender Matrix LLC: https://bgp.he.net/AS62519#_prefixes It appears that the only current reason for this ASN to even exist is to provide routing to Mr. Passerino's ARINland /22 IPv4 block. And interestingly, AS62519 has only one IPv4 peer, i.e. AS47869: https://bgp.he.net/AS62519#_peers AS47869 meanwhile appears to belong to a major Dutch connectivity provider, also, not coincidentally, called "Netrouting". And unlike its Miami peer, AS62519, this Dutch network, AS47869, appears to have numerous different peers and to provide routing to numerous different entities, all apparently above board, unlike Mr. Passerino's Sender Matrix LLC: https://bgp.he.net/AS47869#_peers https://bgp.he.net/AS47869#_prefixes So, you know, this kind of begs the question: Did Netrouting realize that Mr. Passerino and/or Sender Matrix LLC were carrying on some rather dubious activites, and did the principals of Netrouting decide to attempt to distance themselves, and their main ASN (AS47869) from this activity, by putting a "cut out" ASN between them and Mr. Passerino (AS62519), just in case anybody ever clued in to what was really going here? Was this extra layer of AS numbers delibrately engineered to provide Netrouting with an extra layer of plausible deniability? I frankly don't know the answer to that question, but the peering and routing arrangement I've just described, together with the apparent nature of Mr. Passerino's Internet activities (as can be construed from the SEC and CFTC press releases) certainly does make one wonder about what the principals of Netrouting knew, and when they knew it. In contrast, I have fewer doubts about the Polish, Finnish, and Portuguese companies that are, apparently, aiding and abetting Mr. Passerino over in RIPEland. The evidence suggests that none of them bothered in the slightest to find out if there even really was any such corporate entity as "Hostermatrix, LLC" registered in -any- jurisdiction on planet earth. (The very helpful opencorporates.com web site suggests that there is no such entity, anywhere on earth.) Or perhaps they all knew full well that this name, "Hostermatrix, LLC", was just a made-up bullcrap name intended to hide the real identity of thhe real registrant of both of these /22 blocks. Either way, these three companies, in Poland, Finland, and Portugal, appear to be actively.. even iof perhaps unwittingly... aiding and abetting a Florida pump-and-dump spammer/scammer. Bottom line: I recommend to all to cease accepting any and all packets from at least the following: 91.149.232.0/22 - "Hostermatrix LLC" 91.149.252.0/22 - "Hostermatrix LLC" 138.128.224.0/22 - "Sender Matrix LLC" Anyone who may feel inclined towards an even more through defense should certainly consider also a complete block of packlets to/from 91.149.192.0/18, or at least blocking that CIDR from your mail server. (After all, Polish digital TV customers are unlikely to be doing much in the way of outbound email anyway.) Regards, rfg From apishdadi at gmail.com Wed Nov 21 09:53:57 2018 From: apishdadi at gmail.com (A. Pishdadi) Date: Wed, 21 Nov 2018 16:53:57 +0700 Subject: Crooks on the Intrernet: Episode 6,427 In-Reply-To: <85473.1542792759@segfault.tristatelogic.com> References: <85473.1542792759@segfault.tristatelogic.com> Message-ID: We have noticed a huge influx of people requesting us to route blocks of ips they rent from IP brokers, we always make sure they show us an LOA and that radb records match the company name and proper registration is in place, I doubt some smaller providers do the same due diligence, but for me it’s concerning how easy it is to rent ip space these days , it just means that there is a coming storm. Nice investigative work, is this guy listed in rokso by chance ? I am traveling and have crappy connectivity on my phone so I don’t want to bother and check at the moment. On Wed, Nov 21, 2018 at 4:33 PM Ronald F. Guilmette wrote: > > I just thought that y'all might want to be aware of this. > > My attention was called recently to a RIPE-issued block of IPv4 addresses > assigned to a particular Polish firm (Marton Media: > https://martonmedia.pl/) > that appears to sell digital TV services. > > The block in question is 91.149.192.0/18 aka "PL-MARTON-20061120". > > It appears that perhaps this company didn't quite need all of that /18 that > it got from RIPE, so it looks like they parceled out some sub-parts of that > /18 to at least a couple of other parties, to wit: > > "Hostermatrix LLC" aka "ORG-HL183-RIPE": > 91.149.232.0/22 > 91.149.252.0/22 > > "Real Tone Hosting LLC" aka "ORG-RTHL1-RIPE" > 91.149.224.0/21 > 91.149.236.0/22 > 91.149.240.0/21 > 91.149.248.0/22 > > Ignoring, for the moment, the fact that neither of these companies actually > seem to exist anywhere... at least not on -this- planet... my attention was > further called to the pair of /22 blocks that have been sub-allocated by > Marton Media (Poland) to this thing they are calling "Hostermatrix LLC". > > The reverse DNS for those blocks looked like this, just a few short > days ago, on November 16th: > > https://pastebin.com/raw/hjWG5KxA > > But apparently, that all has been changed rather substantially, just in the > past few days, so now it all looks like this instead: > > https://pastebin.com/raw/58qCdPrc > > (You might call this the "Schrodinger Effect". When researching bad guys > on > the Internet, their stuff may change, even as you are looking at it, and > perhaps even -because- you are looking at it.) > > Anyway, the rDNS listing, as it was on the 16th, looked more than a little > fishy. Why would anyone need quite this many different outbound SMTP > servers? > > The one and only second-level domain name that appeared in the rDNS listing > as of the 16th was "sm-smtp.net". I did a bit of research on that domain > name and found that historical passive DNS associates that domain, quite > unambiguously, with another domain name, sendermatrix.net. > > It didn't take much more research for me to find out that a company called > Sender Matrix, LLC is in fact registered in the State of Florida to a Mr. > Jay Passerino. Mr. Passerino appears to have registered a number of > different > Florida companies: > > Haggle USA Corp. > Mahem Partners, Inc. > Sourcehire, LLC > Boat App, LLC, > All In Nutraceuticals, LLC > Miami Suppliments, LLC > Balladex Enterprises, LLC > Sender Matrix, LLC (http://sendermatrix.com/) > Gasher, Inc. > Digital Platinum, Inc. (http://digital-platinum.com/) > BB&M Ventures, Inc. > > Of course, there's nothing at all wrong with Mr. Passerino having prolific > and multiple business interests, however a fellow who also, coincidentally, > has the name Jay Passerino, and who also, coincidentally, hails from the > State of Florida seems to have gotten into what the Brits might call "a > spot > of bother" with respect to not one but -two- U.S. federal regulatory > agencies > of late, specifically the SEC and the CFTC, both of which appear to have > taken serious issue with this Mr. Jay Passerino's business practices, along > with those of several of his cohorts: > > CFTC Press Release: > https://www.cftc.gov/PressRoom/PressReleases/7807-18 > > SEC Press Release: > https://www.sec.gov/news/press-release/2018-216 > > As you can see, both the SEC and the CFTC elected to take issue... on the > exact same day, by the way... with this Mr. Jay Passerino's activities on > the Internet, and specifically relating to "pump and dump" email scams. > > Returning now to the subject of the two /22 sub-allocations that were made > by this Polish outfit, Marton Media, to this apparently non-existant > corporate > entity called "Hostermatrix LLC", i hope that it will not escape anoyone's > notice that whereas the IPv4 blocks in question have been provided... > seemingly > to an Internet crook named Jay Passerino... by a Polish company, the actual > -routing- of each of these blocks shows the participation of some other > actors within two more (different) European countries: > > 91.149.232.0/22 - > routed by AS51765 (Oy Creanova Hosting Solutions Ltd. - Finland) > > 91.149.252.0/22 - > routed by AS24768 (ALMOUROLTEC SERVICOS DE INFORMATICA E INTERNET > LDA - > Portugal) > > The only observation I can offer with respect to all of the forgoing, is > the > rather obvious one: All of this is, to say the least, rather suspicious. > > But wait! There's more! > > It appears that Mr. Passerino's IPv4 assets are not strictly limited to > RIPEland. Theres also a Direct Allocation block of ARIN IPv4 space > (138.128.224.0/22) that is explicitly registered to Sender Matrix LLC > of Miami, Florida: > > https://pastebin.com/raw/cZcsPYrL > > This block is routed by AS62519, Netrouting Inc., also, according to ARIN > records, of Miami, Florida: > > https://pastebin.com/raw/mJKnJX6w > > Curiously, the one and only route being announced by AS62519 is for the /22 > registered to Mr. Passerino's Sender Matrix LLC: > > https://bgp.he.net/AS62519#_prefixes > > It appears that the only current reason for this ASN to even exist is to > provide routing to Mr. Passerino's ARINland /22 IPv4 block. > > And interestingly, AS62519 has only one IPv4 peer, i.e. AS47869: > > https://bgp.he.net/AS62519#_peers > > AS47869 meanwhile appears to belong to a major Dutch connectivity provider, > also, not coincidentally, called "Netrouting". And unlike its Miami peer, > AS62519, this Dutch network, AS47869, appears to have numerous different > peers and to provide routing to numerous different entities, all apparently > above board, unlike Mr. Passerino's Sender Matrix LLC: > > https://bgp.he.net/AS47869#_peers > https://bgp.he.net/AS47869#_prefixes > > So, you know, this kind of begs the question: Did Netrouting realize that > Mr. Passerino and/or Sender Matrix LLC were carrying on some rather dubious > activites, and did the principals of Netrouting decide to attempt to > distance themselves, and their main ASN (AS47869) from this activity, > by putting a "cut out" ASN between them and Mr. Passerino (AS62519), just > in case anybody ever clued in to what was really going here? Was this > extra layer of AS numbers delibrately engineered to provide Netrouting > with an extra layer of plausible deniability? > > I frankly don't know the answer to that question, but the peering and > routing > arrangement I've just described, together with the apparent nature of Mr. > Passerino's Internet activities (as can be construed from the SEC and CFTC > press releases) certainly does make one wonder about what the principals of > Netrouting knew, and when they knew it. > > In contrast, I have fewer doubts about the Polish, Finnish, and Portuguese > companies that are, apparently, aiding and abetting Mr. Passerino over in > RIPEland. The evidence suggests that none of them bothered in the > slightest > to find out if there even really was any such corporate entity as > "Hostermatrix, LLC" registered in -any- jurisdiction on planet earth. (The > very helpful opencorporates.com web site suggests that there is no such > entity, anywhere on earth.) Or perhaps they all knew full well that this > name, "Hostermatrix, LLC", was just a made-up bullcrap name intended to > hide the real identity of thhe real registrant of both of these /22 blocks. > Either way, these three companies, in Poland, Finland, and Portugal, appear > to be actively.. even iof perhaps unwittingly... aiding and abetting a > Florida pump-and-dump spammer/scammer. > > Bottom line: I recommend to all to cease accepting any and all packets > from > at least the following: > > 91.149.232.0/22 - "Hostermatrix LLC" > 91.149.252.0/22 - "Hostermatrix LLC" > 138.128.224.0/22 - "Sender Matrix LLC" > > Anyone who may feel inclined towards an even more through defense should > certainly consider also a complete block of packlets to/from > 91.149.192.0/18, > or at least blocking that CIDR from your mail server. (After all, Polish > digital TV customers are unlikely to be doing much in the way of outbound > email anyway.) > > Regards, > rfg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Nov 21 22:55:38 2018 From: bill at herrin.us (William Herrin) Date: Wed, 21 Nov 2018 14:55:38 -0800 Subject: Internet diameter? Message-ID: Hi folks, Does anybody have more or less recent data on the average, median and maximum diameter (ip hop count) of the Internet? My google fu is failing me: I've only found stuff from the '90s. Thanks, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From aaron1 at gvtc.com Thu Nov 22 03:26:58 2018 From: aaron1 at gvtc.com (Aaron1) Date: Wed, 21 Nov 2018 21:26:58 -0600 Subject: Internet diameter? In-Reply-To: References: Message-ID: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Considering 40% of the “internet” is sitting in my backyard in cdn caching, I’d say the perceived diameter for that content is.... 3 or 4 hops. ;) ...but something tells me that isn’t they response you were seeking... ... but seriously it is interesting that with local caching that much of the Internet is now sitting local in the subscriber’s ISP. Aaron > On Nov 21, 2018, at 4:55 PM, William Herrin wrote: > > Hi folks, > > Does anybody have more or less recent data on the average, median and > maximum diameter (ip hop count) of the Internet? My google fu is > failing me: I've only found stuff from the '90s. > > Thanks, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From ross at tajvar.io Thu Nov 22 03:32:53 2018 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 21 Nov 2018 22:32:53 -0500 Subject: Internet diameter? In-Reply-To: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: I'd argue that's just content (though admittedly a lot of it). You can't cache, e.g., a SIP trunk, and offices which need to connect to each other can't cache one another in a CDN either. On Wed, Nov 21, 2018, 10:29 PM Aaron1 Considering 40% of the “internet” is sitting in my backyard in cdn > caching, I’d say the perceived diameter for that content is.... 3 or 4 > hops. ;) > > ...but something tells me that isn’t they response you were seeking... > > ... but seriously it is interesting that with local caching that much of > the Internet is now sitting local in the subscriber’s ISP. > > Aaron > > > On Nov 21, 2018, at 4:55 PM, William Herrin wrote: > > > > Hi folks, > > > > Does anybody have more or less recent data on the average, median and > > maximum diameter (ip hop count) of the Internet? My google fu is > > failing me: I've only found stuff from the '90s. > > > > Thanks, > > Bill Herrin > > > > -- > > William Herrin ................ herrin at dirtside.com bill at herrin.us > > Dirtside Systems ......... Web: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Thu Nov 22 03:44:47 2018 From: list at satchell.net (Stephen Satchell) Date: Wed, 21 Nov 2018 19:44:47 -0800 Subject: Internet diameter? In-Reply-To: References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: On 11/21/2018 07:32 PM, Ross Tajvar wrote: > I'd argue that's just content (though admittedly a lot of it). You can't > cache, e.g., a SIP trunk, and offices which need to connect to each other > can't cache one another in a CDN either. I would further argue that you can't cache active Web content, like bank account statements, utility billing, help desk request/responses, equipment status, and other things that change constantly. From aaron1 at gvtc.com Thu Nov 22 03:48:33 2018 From: aaron1 at gvtc.com (Aaron1) Date: Wed, 21 Nov 2018 21:48:33 -0600 Subject: Internet diameter? In-Reply-To: References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: Yes I agree Ross/Stephen. I didn’t mean to overstate the CDN fact. I wonder what the answer is to Bill’s question is. “average, median and > maximum diameter (ip hop count) of the Internet? “ Aaron > On Nov 21, 2018, at 9:44 PM, Stephen Satchell wrote: > >> On 11/21/2018 07:32 PM, Ross Tajvar wrote: >> I'd argue that's just content (though admittedly a lot of it). You can't >> cache, e.g., a SIP trunk, and offices which need to connect to each other >> can't cache one another in a CDN either. > > > I would further argue that you can't cache active Web content, like bank > account statements, utility billing, help desk request/responses, > equipment status, and other things that change constantly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Thu Nov 22 03:58:32 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 21 Nov 2018 22:58:32 -0500 Subject: Internet diameter? In-Reply-To: References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: 42 now, why does it matter? On Wed, Nov 21, 2018 at 10:49 PM Aaron1 wrote: > Yes I agree Ross/Stephen. I didn’t mean to overstate the CDN fact. > > I wonder what the answer is to Bill’s question is. “average, median and > > maximum diameter (ip hop count) of the Internet? “ > > > Aaron > > On Nov 21, 2018, at 9:44 PM, Stephen Satchell wrote: > > On 11/21/2018 07:32 PM, Ross Tajvar wrote: > > I'd argue that's just content (though admittedly a lot of it). You can't > > cache, e.g., a SIP trunk, and offices which need to connect to each other > > can't cache one another in a CDN either. > > > > I would further argue that you can't cache active Web content, like bank > account statements, utility billing, help desk request/responses, > equipment status, and other things that change constantly. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at thenetworknerds.ca Thu Nov 22 04:10:11 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Wed, 21 Nov 2018 20:10:11 -0800 Subject: Internet diameter? In-Reply-To: References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: I don’t have any hard statistics but I notice that on a majority of ASs on bgp.he.net , the average AS path length is between 4 and 5. As for the average number of hops, it clearly depends on what type of traffic and many ASNs have more than one router. Going on my own experience I would say between 8 and 10 hops would be the average of non-cached content. If you included cached content such as cdns and caches then the actual average might be closer to 5 to 7. This is only an estimate from my own network and those of my clients so the actual value may be completely different. As with what others have said, I’m not sure on what use this data, if collected, would be. Latency is the most important. Thanks ~ Bryce Wilson, AS202313, EVIX, AS137933 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at andyring.com Thu Nov 22 04:17:28 2018 From: andy at andyring.com (Andy Ringsmuth) Date: Wed, 21 Nov 2018 22:17:28 -0600 Subject: Internet diameter? In-Reply-To: References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: <2C0AA9F0-4C14-46E5-AD02-378FC418DBA5@andyring.com> > On Nov 21, 2018, at 9:32 PM, Ross Tajvar wrote: > > I'd argue that's just content (though admittedly a lot of it). You can't cache, e.g., a SIP trunk, and offices which need to connect to each other can't cache one another in a CDN either. > > On Wed, Nov 21, 2018, 10:29 PM Aaron1 Considering 40% of the “internet” is sitting in my backyard in cdn caching, I’d say the perceived diameter for that content is.... 3 or 4 hops. ;) > > ...but something tells me that isn’t they response you were seeking... > > ... but seriously it is interesting that with local caching that much of the Internet is now sitting local in the subscriber’s ISP. > > Aaron > >> On Nov 21, 2018, at 4:55 PM, William Herrin wrote: >> >> Hi folks, >> >> Does anybody have more or less recent data on the average, median and >> maximum diameter (ip hop count) of the Internet? My google fu is >> failing me: I've only found stuff from the '90s. >> >> Thanks, >> Bill Herrin >> Obligatory XKCD: https://xkcd.com/908/ -Andy From ben at 6by7.net Thu Nov 22 04:25:09 2018 From: ben at 6by7.net (Ben Cannon) Date: Wed, 21 Nov 2018 20:25:09 -0800 Subject: Internet diameter? In-Reply-To: References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: <074703F8-EEEF-40B2-B2D9-CE1DF5D6C076@6by7.net> This begs the question, which is more meaningful a metric, AS-path or hop count? Many networks have a large number of routers but the packets don’t stay in them very long. -Ben. > On Nov 21, 2018, at 8:10 PM, Bryce Wilson wrote: > > I don’t have any hard statistics but I notice that on a majority of ASs on bgp.he.net , the average AS path length is between 4 and 5. As for the average number of hops, it clearly depends on what type of traffic and many ASNs have more than one router. Going on my own experience I would say between 8 and 10 hops would be the average of non-cached content. If you included cached content such as cdns and caches then the actual average might be closer to 5 to 7. This is only an estimate from my own network and those of my clients so the actual value may be completely different. > > As with what others have said, I’m not sure on what use this data, if collected, would be. Latency is the most important. > > > Thanks ~ Bryce Wilson, AS202313, EVIX, AS137933 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Thu Nov 22 04:41:52 2018 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 21 Nov 2018 23:41:52 -0500 Subject: Internet diameter? In-Reply-To: <074703F8-EEEF-40B2-B2D9-CE1DF5D6C076@6by7.net> References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> <074703F8-EEEF-40B2-B2D9-CE1DF5D6C076@6by7.net> Message-ID: > I’m not sure on what use this data, if collected, would be. Latency is the most important. It's not operationally useful in any way that I can think of, but it is interesting (at least to me). It's possible that Bill has something in mind, though. > [...] which is more meaningful a metric, AS-path or hop count? Good point. Before we can decide which is more useful, we have to decide what they would be useful for. But, I think it's not really feasible to analyze hop count, because you would have to collect that data with a huge number of traceroutes. Average/median AS-path length can be estimated by static analysis of BGP tables from various routers. > Many networks have a large number of routers but the packets don’t stay in them very long. It wouldn't be a very good router if the packets hung around for a long time before leaving :) On Wed, Nov 21, 2018 at 11:26 PM Ben Cannon wrote: > This begs the question, which is more meaningful a metric, AS-path or hop > count? Many networks have a large number of routers but the packets don’t > stay in them very long. > > -Ben. > > > On Nov 21, 2018, at 8:10 PM, Bryce Wilson > wrote: > > I don’t have any hard statistics but I notice that on a majority of ASs on > bgp.he.net, the average AS path length is between 4 and 5. As for the > average number of hops, it clearly depends on what type of traffic and many > ASNs have more than one router. Going on my own experience I would say > between 8 and 10 hops would be the average of non-cached content. If you > included cached content such as cdns and caches then the actual average > might be closer to 5 to 7. This is only an estimate from my own network and > those of my clients so the actual value may be completely different. > > As with what others have said, I’m not sure on what use this data, if > collected, would be. Latency is the most important. > > > Thanks ~ Bryce Wilson, AS202313, EVIX, AS137933 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Nov 22 05:30:06 2018 From: bill at herrin.us (William Herrin) Date: Wed, 21 Nov 2018 21:30:06 -0800 Subject: Internet diameter? In-Reply-To: References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: On Wed, Nov 21, 2018 at 7:58 PM Christopher Morrow wrote: > now, why does it matter? Good question! It matters because a little over two decades ago we had some angst as equipment configured to emit a TTL of 32 stopped being able to reach everybody. Today we have a lot of equipment configured to emit a TTL of 64. It's the default in Linux, for example. Are we getting close to the limit where that will cause problems? How close? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From oliver.oboyle at gmail.com Thu Nov 22 05:43:49 2018 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 22 Nov 2018 00:43:49 -0500 Subject: Internet diameter? In-Reply-To: References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: ^ This On Thu, Nov 22, 2018, 00:32 William Herrin On Wed, Nov 21, 2018 at 7:58 PM Christopher Morrow > wrote: > > now, why does it matter? > > Good question! It matters because a little over two decades ago we had > some angst as equipment configured to emit a TTL of 32 stopped being > able to reach everybody. Today we have a lot of equipment configured > to emit a TTL of 64. It's the default in Linux, for example. Are we > getting close to the limit where that will cause problems? How close? > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at pelican.org Thu Nov 22 09:55:47 2018 From: tim at pelican.org (tim at pelican.org) Date: Thu, 22 Nov 2018 09:55:47 -0000 (GMT) Subject: =?utf-8?Q?Re=3A_Internet_diameter=3F?= In-Reply-To: References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: <1542880547.21228510@apps.rackspace.com> On Thursday, 22 November, 2018 05:30, "William Herrin" said: > Good question! It matters because a little over two decades ago we had > some angst as equipment configured to emit a TTL of 32 stopped being > able to reach everybody. Today we have a lot of equipment configured > to emit a TTL of 64. It's the default in Linux, for example. Are we > getting close to the limit where that will cause problems? How close? If it's hop-count that's interesting, I think that raises a question on the potential for a sudden large change in the answer, potentially with unforeseen consequences if we do have a lot of devices with TTL=64. Imagine a "tier-1" carrying some non-trivial fraction of Internet traffic who is label-switching global table, with no TTL-propagation into MPLS, and so looks like a single layer-3 hop today. In response to traceroute-whingeing, they turn on TTL-propagation, and suddenly look like 10 layer-3 hops. Having been in the show/hide MPLS hops internal debate at more than one employer, I'd expect flipping the switch to "show" to generate a certain support load from people complaining that they are now "more hops" away from something they care about (although RTT, packet-loss, throughput remain exactly the same). I wouldn't have expected to break connectivity for a whole class of devices. Regards, Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu Nov 22 19:31:24 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 22 Nov 2018 12:31:24 -0700 Subject: Internet diameter? In-Reply-To: Message-ID: <9e0677d0b32dad4497d24af030293deb@mail.dessus.com> >> I'd argue that's just content (though admittedly a lot of it). "just static content" would be more accurate ... >I would further argue that you can't cache active Web content, like >bank account statements, utility billing, help desk request/responses, >equipment status, and other things that change constantly. There were many attempts at this by Johhny-cum-lately ISPs back in the 90's -- particularly Telco and Cableco's -- with their "transparent poxies". Eventually they discovered that it was more cost efficient to actually provide the customer with what the customer had purchased. --- 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 Stephen >Satchell >Sent: Wednesday, 21 November, 2018 20:45 >To: nanog at nanog.org >Subject: Re: Internet diameter? > >On 11/21/2018 07:32 PM, Ross Tajvar wrote: From jason+nanog at lixfeld.ca Thu Nov 22 20:09:08 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Thu, 22 Nov 2018 15:09:08 -0500 Subject: 350 E Cermak Message-ID: <2D9017C6-C7CF-40E1-960D-DCBE25BD5791@lixfeld.ca> Hey all, Looking for some clue on how things work, and who’s who for colo at 350 E Cermak. Looking at possibly putting a rack in somewhere there for a Peering/Transit/PNI POP. Is there a list somewhere of colo facilities in that building? Also, how does it work there in terms if inter-colo, intra-building connectivity, or is that a mixed bag? Thanks! From nanog at ics-il.net Thu Nov 22 21:10:53 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 22 Nov 2018 15:10:53 -0600 (CST) Subject: 350 E Cermak In-Reply-To: <2D9017C6-C7CF-40E1-960D-DCBE25BD5791@lixfeld.ca> References: <2D9017C6-C7CF-40E1-960D-DCBE25BD5791@lixfeld.ca> Message-ID: <466208854.9964.1542921050805.JavaMail.mhammett@ThunderFuck> Equinix is the most popular with TelX bringing up second place. Both have expensive cross connects. There are others, but they aren't relevant for interconnection. Intra-building connectivity is damn expensive. https://peeringdb.com/advanced_search?address1__contains=350&city=Chicago&reftag=fac ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jason Lixfeld" To: "NANOG mailing list" Sent: Thursday, November 22, 2018 2:09:08 PM Subject: 350 E Cermak Hey all, Looking for some clue on how things work, and who’s who for colo at 350 E Cermak. Looking at possibly putting a rack in somewhere there for a Peering/Transit/PNI POP. Is there a list somewhere of colo facilities in that building? Also, how does it work there in terms if inter-colo, intra-building connectivity, or is that a mixed bag? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Nov 22 21:13:13 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 22 Nov 2018 15:13:13 -0600 (CST) Subject: Internet diameter? In-Reply-To: <9e0677d0b32dad4497d24af030293deb@mail.dessus.com> References: <9e0677d0b32dad4497d24af030293deb@mail.dessus.com> Message-ID: <1831068055.9994.1542921192446.JavaMail.mhammett@ThunderFuck> " Eventually they discovered that it was more cost efficient to actually provide the customer with what the customer had purchased." Sometimes yes, sometimes no. Big content has been making this more complicated. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" To: nanog at nanog.org Sent: Thursday, November 22, 2018 1:31:24 PM Subject: RE: Internet diameter? >> I'd argue that's just content (though admittedly a lot of it). "just static content" would be more accurate ... >I would further argue that you can't cache active Web content, like >bank account statements, utility billing, help desk request/responses, >equipment status, and other things that change constantly. There were many attempts at this by Johhny-cum-lately ISPs back in the 90's -- particularly Telco and Cableco's -- with their "transparent poxies". Eventually they discovered that it was more cost efficient to actually provide the customer with what the customer had purchased. --- 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 Stephen >Satchell >Sent: Wednesday, 21 November, 2018 20:45 >To: nanog at nanog.org >Subject: Re: Internet diameter? > >On 11/21/2018 07:32 PM, Ross Tajvar wrote: -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu Nov 22 23:35:23 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 22 Nov 2018 16:35:23 -0700 Subject: Internet diameter? In-Reply-To: <1831068055.9994.1542921192446.JavaMail.mhammett@ThunderFuck> Message-ID: To get back to the original question regarding the "diameter" of the Internet, it would appear to me that we are easily looking at about 30 to 40 hops just within North America -- and easily double that to reach the rest of the Internet outside of North America. Of course, the "Top 5 Channels" are probably only a few hops away due to CDNs, but this is for the most part irrelevant (unless one only wants to watch the Top 5 channels) ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From jeffm at iglou.com Fri Nov 23 17:51:39 2018 From: jeffm at iglou.com (Jeff McAdams) Date: Fri, 23 Nov 2018 12:51:39 -0500 (EST) Subject: RPKI publication Message-ID: <55132.162.155.102.254.1542995499.iglou@webmail.iglou.com> OK, I'm trying to do the responsible thing and further the progress and deployment of RPKI. I feel like I have a pretty good handle on a path forward for doing validation and routing-policy based on ROA validation. However, I also feel like I'm really banging my head against a wall trying to set up publication of ROAs. $employer has IP space from several RIRs, and enough space that there is a pretty strong desire to have our own publication system for this, but I'm really struggling to find extant software to do this. Are there people doing their own publication? Or is everyone just using Hosted ARIN/RIPE/APNIC/etc. systems? My colleagues and I feel like trying to manage and automate processes against multiple RIRs is not ideal, so setting up a publication system that can use the Up-Down protocol, or perhaps publish our own publication points, or whatever is the best way to handle this would be desired. Can anyone point me to some facilitating resources on this? Software packages that are reasonably current and maintained and not a total pain to deploy? -- Jeff From cscora at apnic.net Fri Nov 23 18:03:31 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Nov 2018 04:03:31 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181123180331.86B92C450F@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 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 24 Nov, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 726367 Prefixes after maximum aggregation (per Origin AS): 279703 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 348863 Total ASes present in the Internet Routing Table: 62493 Prefixes per ASN: 11.62 Origin-only ASes present in the Internet Routing Table: 53932 Origin ASes announcing only one prefix: 23432 Transit ASes present in the Internet Routing Table: 8561 Transit-only ASes present in the Internet Routing Table: 252 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 37 Prefixes from unregistered ASNs in the Routing Table: 34 Number of instances of unregistered ASNs: 34 Number of 32-bit ASNs allocated by the RIRs: 24970 Number of 32-bit ASNs visible in the Routing Table: 20203 Prefixes from 32-bit ASNs in the Routing Table: 86579 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 246 Number of addresses announced to Internet: 2863306529 Equivalent to 170 /8s, 170 /16s and 151 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.1 Total number of prefixes smaller than registry allocations: 242174 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 198658 Total APNIC prefixes after maximum aggregation: 56566 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 196048 Unique aggregates announced from the APNIC address blocks: 80608 APNIC Region origin ASes present in the Internet Routing Table: 9245 APNIC Prefixes per ASN: 21.21 APNIC Region origin ASes announcing only one prefix: 2600 APNIC Region transit ASes present in the Internet Routing Table: 1380 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: 4240 Number of APNIC addresses announced to Internet: 768530944 Equivalent to 45 /8s, 206 /16s and 218 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 215580 Total ARIN prefixes after maximum aggregation: 102443 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 214924 Unique aggregates announced from the ARIN address blocks: 102491 ARIN Region origin ASes present in the Internet Routing Table: 18302 ARIN Prefixes per ASN: 11.74 ARIN Region origin ASes announcing only one prefix: 6792 ARIN Region transit ASes present in the Internet Routing Table: 1831 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2508 Number of ARIN addresses announced to Internet: 1103264672 Equivalent to 65 /8s, 194 /16s and 123 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 198248 Total RIPE prefixes after maximum aggregation: 94720 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 194692 Unique aggregates announced from the RIPE address blocks: 115221 RIPE Region origin ASes present in the Internet Routing Table: 25652 RIPE Prefixes per ASN: 7.59 RIPE Region origin ASes announcing only one prefix: 11488 RIPE Region transit ASes present in the Internet Routing Table: 3538 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7616 Number of RIPE addresses announced to Internet: 715984000 Equivalent to 42 /8s, 173 /16s and 12 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 94259 Total LACNIC prefixes after maximum aggregation: 21774 LACNIC Deaggregation factor: 4.33 Prefixes being announced from the LACNIC address blocks: 95642 Unique aggregates announced from the LACNIC address blocks: 41823 LACNIC Region origin ASes present in the Internet Routing Table: 7809 LACNIC Prefixes per ASN: 12.25 LACNIC Region origin ASes announcing only one prefix: 2144 LACNIC Region transit ASes present in the Internet Routing Table: 1482 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5353 Number of LACNIC addresses announced to Internet: 172627712 Equivalent to 10 /8s, 74 /16s and 23 /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: 19587 Total AfriNIC prefixes after maximum aggregation: 4172 AfriNIC Deaggregation factor: 4.69 Prefixes being announced from the AfriNIC address blocks: 24815 Unique aggregates announced from the AfriNIC address blocks: 8490 AfriNIC Region origin ASes present in the Internet Routing Table: 1212 AfriNIC Prefixes per ASN: 20.47 AfriNIC Region origin ASes announcing only one prefix: 408 AfriNIC Region transit ASes present in the Internet Routing Table: 239 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 486 Number of AfriNIC addresses announced to Internet: 102513408 Equivalent to 6 /8s, 28 /16s and 59 /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 4640 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4621 518 516 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3004 1153 93 VIETEL-AS-AP Viettel Group, VN 45899 2958 1689 111 VNPT-AS-VN VNPT Corp, VN 4766 2826 11130 764 KIXS-AS-KR Korea Telecom, KR 9829 2747 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2442 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2431 4907 31 CTTNET China TieTong Telecommunications 17974 2247 968 51 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2121 421 171 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 3495 1324 84 SHAW - Shaw Communications Inc., CA 11492 3465 224 626 CABLEONE - CABLE ONE, INC., US 22773 3280 2973 166 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2543 5241 959 AMAZON-02 - Amazon.com, Inc., US 16625 2222 1205 1659 AKAMAI-AS - Akamai Technologies, Inc., 18566 2154 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2144 2740 538 CHARTER-20115 - Charter Communications, 5650 2087 3074 1462 FRONTIER-FRTR - Frontier Communications 30036 2070 347 137 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2047 5079 593 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5145 1616 134 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3039 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2579 565 1917 AKAMAI-ASN1, US 12389 2185 2194 615 ROSTELECOM-AS, RU 34984 2021 336 537 TELLCOM-AS, TR 9121 1872 1691 17 TTNET, TR 13188 1605 100 42 TRIOLAN, UA 8402 1289 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1218 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5440 3313 605 Uninet S.A. de C.V., MX 10620 3124 475 887 Telmex Colombia S.A., CO 11830 2675 371 71 Instituto Costarricense de Electricidad 6503 1662 449 55 Axtel, S.A.B. de C.V., MX 7303 1439 962 217 Telecom Argentina S.A., AR 28573 1190 2239 187 CLARO S.A., BR 6147 1115 377 29 Telefonica del Peru S.A.A., PE 3816 1024 513 117 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 947 145 70 Alestra, S. de R.L. de C.V., MX 13999 922 537 260 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 37611 907 107 9 Afrihost, ZA 36903 796 400 142 MT-MPLS, MA 36992 783 1411 44 ETISALAT-MISR, EG 24863 735 393 22 LINKdotNET-AS, EG 24835 657 634 21 RAYA-AS, EG 8452 641 1728 15 TE-AS TE-AS, EG 37492 467 470 57 ORANGE-, TN 29571 464 70 12 ORANGE-COTE-IVOIRE, CI 37342 421 32 1 MOVITEL, MZ 15399 411 45 11 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 5440 3313 605 Uninet S.A. de C.V., MX 12479 5145 1616 134 UNI2-AS, ES 4538 4640 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4621 518 516 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3495 1324 84 SHAW - Shaw Communications Inc., CA 11492 3465 224 626 CABLEONE - CABLE ONE, INC., US 22773 3280 2973 166 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3124 475 887 Telmex Colombia S.A., CO 8551 3039 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5145 5011 UNI2-AS, ES 4538 4640 4566 ERX-CERNET-BKB China Education and Research Net 7545 4621 4105 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3495 3411 SHAW - Shaw Communications Inc., CA 22773 3280 3114 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3039 2996 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3004 2911 VIETEL-AS-AP Viettel Group, VN 45899 2958 2847 VNPT-AS-VN VNPT Corp, VN 11492 3465 2839 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 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 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 92937 UNALLOCATED 110.49.72.0/24 45458 SBN-AWN-AS-02-AP SBN-ISP/AWN-I 4230060012 PRIVATE 132.190.106.0/24 64673 -Private Use AS-, ZZ 4230060012 PRIVATE 132.190.232.0/24 64673 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.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.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.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 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:290 /13:566 /14:1117 /15:1897 /16:13314 /17:7884 /18:13881 /19:25487 /20:39516 /21:46126 /22:90120 /23:74168 /24:409596 /25:824 /26:638 /27:645 /28:39 /29:20 /30:21 /31:4 /32:54 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3961 5145 UNI2-AS, ES 6327 3267 3495 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2754 3465 CABLEONE - CABLE ONE, INC., US 22773 2532 3280 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2495 3039 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2048 2154 MEGAPATH5-US - MegaPath Corporation, US 11830 2020 2675 Instituto Costarricense de Electricidad y Telec 30036 1819 2070 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2087 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1628 2:890 4:18 5:2720 6:43 7:1 8:1149 12:1873 13:259 14:1872 15:35 16:3 17:195 18:58 20:48 23:2564 24:2405 25:2 27:2534 31:2003 32:86 35:31 36:531 37:2939 38:1576 39:275 40:120 41:3137 42:730 43:1977 44:134 45:6125 46:3044 47:239 49:1320 50:1068 51:318 52:1109 54:362 55:1 56:6 57:41 58:1693 59:1071 60:463 61:2108 62:1877 63:1800 64:5064 65:2173 66:4778 67:2651 68:1157 69:3349 70:1152 71:600 72:2244 74:2716 75:408 76:495 77:1690 78:1749 79:2214 80:1581 81:1409 82:1057 83:819 84:1074 85:2108 86:548 87:1467 88:947 89:2400 90:210 91:6473 92:1273 93:2397 94:2395 95:3089 96:910 97:348 98:941 99:167 100:87 101:1160 102:288 103:19265 104:3608 105:242 106:890 107:1832 108:705 109:3407 110:1635 111:1827 112:1405 113:1330 114:1146 115:1705 116:1665 117:1882 118:2219 119:1669 120:1117 121:1032 122:2354 123:1695 124:1455 125:1948 128:1198 129:692 130:514 131:1631 132:717 133:193 134:1043 135:224 136:532 137:668 138:1972 139:746 140:564 141:758 142:805 143:998 144:844 145:498 146:1240 147:768 148:1696 149:790 150:769 151:985 152:897 153:327 154:2069 155:958 156:1592 157:843 158:656 159:1881 160:1460 161:883 162:2648 163:760 164:1121 165:1600 166:459 167:1342 168:3139 169:864 170:4019 171:499 172:1056 173:2105 174:987 175:865 176:2208 177:3963 178:2516 179:1309 180:2128 181:2365 182:2600 183:1320 184:1143 185:14405 186:3618 187:2494 188:2931 189:2057 190:8345 191:1380 192:9920 193:6410 194:5252 195:4034 196:2995 197:1765 198:5674 199:5982 200:7401 201:5017 202:10262 203:10188 204:4611 205:3008 206:3259 207:3218 208:3965 209:4181 210:3870 211:2022 212:3024 213:2801 214:1055 215:55 216:6046 217:2179 218:871 219:577 220:1827 221:999 222:969 223:1400 End of report From mehmet at akcin.net Fri Nov 23 18:13:54 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 23 Nov 2018 10:13:54 -0800 Subject: Virtualization of everything Message-ID: hey there, I provide some free vm/hosting for my friends and family but i am trying to shutdown this (or move from physical infra to virtual) and move everything to on premise virtual servers/kubernetes infastructure and have a front/back end which allows my friends and me to give them things they need such as virtual servers, etc. for me i want to get bunch of identical (or identicalish) pizza boxes in future and grow what i have built as needed. i want to be able to make this as self service as possible. so now, if I could just pay someone to go do everything for me as turn key, that would be the ideal way as I am alone and don't really have all the clues I need in order to deliver the end result in a timely manner which makes sense. if you are providing such services , please let me know or if you know people please ping me offlist. thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Fri Nov 23 19:01:00 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 23 Nov 2018 14:01:00 -0500 Subject: Internet diameter? In-Reply-To: References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> Message-ID: On Thu, Nov 22, 2018 at 12:30 AM William Herrin wrote: > On Wed, Nov 21, 2018 at 7:58 PM Christopher Morrow > wrote: > > now, why does it matter? > > Good question! It matters because a little over two decades ago we had > some angst as equipment configured to emit a TTL of 32 stopped being > able to reach everybody. Today we have a lot of equipment configured > to emit a TTL of 64. It's the default in Linux, for example. Are we > getting close to the limit where that will cause problems? How close? > > ah-ha! :) good, much easier to see the point with the goal in mind :) So... you COULD spin up some set of traceroute measurements from ripe-atlas, right? pick 5 probes per city and traceroute to common targets? I think there are a few things to consider: 1) not ever network exposes their hops all the time (mpls where the paths no-decrement-ttl, for instance). 2) the common user traffic pattern is likely not to fall into the 'too many hops' problem because of cdn and/or other trickery to shorten the path between end-user && content (to increase effective bw to the customer AND lower latency,etc) 3) I would think it rare for consumers (the largest pool of internet users by role) to need to send packets to the far side of the internet Or put another way: "How would you pick what's important to measure to?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at nlnetlabs.nl Fri Nov 23 19:30:50 2018 From: alex at nlnetlabs.nl (Alex Band) Date: Fri, 23 Nov 2018 20:30:50 +0100 Subject: RPKI publication In-Reply-To: <55132.162.155.102.254.1542995499.iglou@webmail.iglou.com> References: <55132.162.155.102.254.1542995499.iglou@webmail.iglou.com> Message-ID: <6E4775C8-0107-41C9-A9CB-8DE6706E161F@nlnetlabs.nl> Hi Jeff, While I can’t offer you a solution today, I’m happy to tell you we’ve recognised this particular use case and are working on a free, open source solution. We're building a toolset that allows you to run a CA as a child of one or multiple RIRs transparently and publish using your own or a third party publication server. In addition, we’ll provide validation software. https://www.nlnetlabs.nl/projects/rpki/project-plan/ For the validation software we have running code that is already used in production in various places: https://github.com/NLnetLabs/routinator With development ongoing, we’re still in the process of getting this fully funded as we’re a small non-profit. So far the RIPE NCC Community Projects Fund and Brazilian registry NIC.br are contributing to financing this project. Our goal to to provide something that is on par with our other projects, such as NSD and Unbound. Happy to keep you updated on the progress. Cheers, Alex Band NLnet Labs > On 23 Nov 2018, at 18:51, Jeff McAdams wrote: > > OK, I'm trying to do the responsible thing and further the progress and > deployment of RPKI. I feel like I have a pretty good handle on a path > forward for doing validation and routing-policy based on ROA validation. > > However, I also feel like I'm really banging my head against a wall trying > to set up publication of ROAs. $employer has IP space from several RIRs, > and enough space that there is a pretty strong desire to have our own > publication system for this, but I'm really struggling to find extant > software to do this. > > Are there people doing their own publication? Or is everyone just using > Hosted ARIN/RIPE/APNIC/etc. systems? My colleagues and I feel like trying > to manage and automate processes against multiple RIRs is not ideal, so > setting up a publication system that can use the Up-Down protocol, or > perhaps publish our own publication points, or whatever is the best way to > handle this would be desired. > > Can anyone point me to some facilitating resources on this? Software > packages that are reasonably current and maintained and not a total pain > to deploy? > > -- > Jeff From morrowc.lists at gmail.com Fri Nov 23 21:48:14 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 23 Nov 2018 16:48:14 -0500 Subject: RPKI publication In-Reply-To: <6E4775C8-0107-41C9-A9CB-8DE6706E161F@nlnetlabs.nl> References: <55132.162.155.102.254.1542995499.iglou@webmail.iglou.com> <6E4775C8-0107-41C9-A9CB-8DE6706E161F@nlnetlabs.nl> Message-ID: On Fri, Nov 23, 2018 at 2:31 PM Alex Band wrote: > Hi Jeff, > > While I can’t offer you a solution today, I’m happy to tell you we’ve > recognised this particular use case and are working on a free, open source > solution. > > We're building a toolset that allows you to run a CA as a child of one or > multiple RIRs transparently and publish using your own or a third party > publication server. In addition, we’ll provide validation software. > > https://www.nlnetlabs.nl/projects/rpki/project-plan/ > > For the validation software we have running code that is already used in > production in various places: > > https://github.com/NLnetLabs/routinator > > With development ongoing, we’re still in the process of getting this fully > funded as we’re a small non-profit. So far the RIPE NCC Community Projects > Fund and Brazilian registry NIC.br are contributing to financing this > project. Our goal to to provide something that is on par with our other > projects, such as NSD and Unbound. > > Happy to keep you updated on the progress. > > Cheers, > > Alex Band > NLnet Labs > > > On 23 Nov 2018, at 18:51, Jeff McAdams wrote: > > > > OK, I'm trying to do the responsible thing and further the progress and > > deployment of RPKI. I feel like I have a pretty good handle on a path > > forward for doing validation and routing-policy based on ROA validation. > hey thanks! :) > > However, I also feel like I'm really banging my head against a wall > trying > > to set up publication of ROAs. $employer has IP space from several RIRs, > > and enough space that there is a pretty strong desire to have our own > > publication system for this, but I'm really struggling to find extant > > software to do this. > I think there are 3 options: ripe validator v2 (potentially v3?) - https://github.com/RIPE-NCC/rpki-validator https://github.com/RIPE-NCC/rpki-validator-3 rpki.net validator - https://github.com/dragonresearch/rpki.net bbn rpstir - https://github.com/bgpsecurity/rpstir > Are there people doing their own publication? Or is everyone just using > > Hosted ARIN/RIPE/APNIC/etc. systems? My colleagues and I feel like > trying > > to manage and automate processes against multiple RIRs is not ideal, so > > setting up a publication system that can use the Up-Down protocol, or > > perhaps publish our own publication points, or whatever is the best way > to > > handle this would be desired. > > > > Can anyone point me to some facilitating resources on this? Software > > packages that are reasonably current and maintained and not a total pain > > to deploy? > > > > -- > > Jeff > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffm at iglou.com Fri Nov 23 23:11:53 2018 From: jeffm at iglou.com (Jeff McAdams) Date: Fri, 23 Nov 2018 18:11:53 -0500 Subject: RPKI publication In-Reply-To: References: <55132.162.155.102.254.1542995499.iglou@webmail.iglou.com> <6E4775C8-0107-41C9-A9CB-8DE6706E161F@nlnetlabs.nl> Message-ID: On November 23, 2018 4:48:14 PM EST, Christopher Morrow wrote: >I think there are 3 options: > ripe validator v2 (potentially v3?) - >https://github.com/RIPE-NCC/rpki-validator > >https://github.com/RIPE-NCC/rpki-validator-3 > rpki.net validator - https://github.com/dragonresearch/rpki.net > bbn rpstir - https://github.com/bgpsecurity/rpstir Like I said, validation and caching, "relying party", has several options...several of which are relatively easy to run and manage. It's the CA and publishing for which no really good options (that I've found, at least) are available currently. From morrowc.lists at gmail.com Fri Nov 23 23:20:14 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 23 Nov 2018 18:20:14 -0500 Subject: RPKI publication In-Reply-To: References: <55132.162.155.102.254.1542995499.iglou@webmail.iglou.com> <6E4775C8-0107-41C9-A9CB-8DE6706E161F@nlnetlabs.nl> Message-ID: On Fri, Nov 23, 2018 at 6:12 PM Jeff McAdams wrote: > > > On November 23, 2018 4:48:14 PM EST, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > > >I think there are 3 options: > > ripe validator v2 (potentially v3?) - > >https://github.com/RIPE-NCC/rpki-validator > > > >https://github.com/RIPE-NCC/rpki-validator-3 > > rpki.net validator - https://github.com/dragonresearch/rpki.net > > bbn rpstir - https://github.com/bgpsecurity/rpstir > > Like I said, validation and caching, "relying party", has several > options...several of which are relatively easy to run and manage. It's the > CA and publishing for which no really good options (that I've found, at > least) are available currently. > the ca bits do exist in rpki.net's software set... they are a tad fiddly to setup/run though, yes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffm at iglou.com Sat Nov 24 01:51:01 2018 From: jeffm at iglou.com (Jeff McAdams) Date: Fri, 23 Nov 2018 20:51:01 -0500 (EST) Subject: RPKI publication In-Reply-To: References: <55132.162.155.102.254.1542995499.iglou@webmail.iglou.com> <6E4775C8-0107-41C9-A9CB-8DE6706E161F@nlnetlabs.nl> Message-ID: <27692.24.166.32.244.1543024261.iglou@webmail.iglou.com> On Fri, November 23, 2018 18:20, Christopher Morrow wrote: > On Fri, Nov 23, 2018 at 6:12 PM Jeff McAdams wrote: >> On November 23, 2018 4:48:14 PM EST, Christopher Morrow < >> morrowc.lists at gmail.com> wrote: >> >>> I think there are 3 options: >>> ripe validator v2 (potentially v3?) - >>> https://github.com/RIPE-NCC/rpki-validator >>> >>> >>> https://github.com/RIPE-NCC/rpki-validator-3 >>> rpki.net validator - https://github.com/dragonresearch/rpki.net bbn >>> rpstir - https://github.com/bgpsecurity/rpstir >> >> Like I said, validation and caching, "relying party", has several >> options...several of which are relatively easy to run and manage. It's >> the CA and publishing for which no really good options (that I've found, >> at least) are available currently. >> > > the ca bits do exist in rpki.net's software set... they are a tad fiddly > to setup/run though, yes. Oops, sorry, I missed the rpki.net reference in there (I read and replied to that message from my phone). Yes, I spent several hours trying to even get the Ubuntu 18.04 packages to even install without errors. I'm not particularly keen on installing a 2 1/2 year old distro to run no-longer-supported version of the django framework to support this, so I'm pretty much putting into the "not reasonably current and maintained" category. -- Jeff From darin.steffl at mnwifi.com Sat Nov 24 04:21:51 2018 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Fri, 23 Nov 2018 22:21:51 -0600 Subject: Amazon Peering Message-ID: Hey all, Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From erich at gotfusion.net Sat Nov 24 05:15:50 2018 From: erich at gotfusion.net (Kaiser, Erich) Date: Fri, 23 Nov 2018 23:15:50 -0600 Subject: Amazon Peering In-Reply-To: References: Message-ID: Email all of their peering db contacts. On Fri, Nov 23, 2018 at 10:22 PM Darin Steffl wrote: > Hey all, > > Does anyone have a direct contact to get a peering session established > with Amazon at an IX? I sent a peering request Dec 2017 and two more times > this Sept and Nov with no response. > > I sent to peering at amazon.com and received one automated response back so > I know they received my email but nothing since. > > > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sat Nov 24 16:38:49 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 24 Nov 2018 10:38:49 -0600 (CST) Subject: Amazon Peering In-Reply-To: References: Message-ID: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> I've e-mailed my contacts there a couple times on people's behalf. No response yet. It seems like a lot of organizations need 1 more person in their peering departments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Darin Steffl" To: "North American Network Operators' Group" Sent: Friday, November 23, 2018 10:21:51 PM Subject: Amazon Peering Hey all, Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin.steffl at mnwifi.com Sat Nov 24 16:59:21 2018 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Sat, 24 Nov 2018 10:59:21 -0600 Subject: Amazon Peering In-Reply-To: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> Message-ID: It seems wasteful for Amazon to connect to an IX but then ignore peering requests for a year. They have 40G of connectivity but are unresponsive. I'll try emailing all the other contacts listed in peeringdb. Thanks On Sat, Nov 24, 2018, 10:38 AM Mike Hammett I've e-mailed my contacts there a couple times on people's behalf. No > response yet. > > It seems like a lot of organizations need 1 more person in their peering > departments. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Darin Steffl" > *To: *"North American Network Operators' Group" > *Sent: *Friday, November 23, 2018 10:21:51 PM > *Subject: *Amazon Peering > > Hey all, > > Does anyone have a direct contact to get a peering session established > with Amazon at an IX? I sent a peering request Dec 2017 and two more times > this Sept and Nov with no response. > > I sent to peering at amazon.com and received one automated response back so > I know they received my email but nothing since. > > > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbothe at me.com Sat Nov 24 17:29:57 2018 From: jbothe at me.com (JASON BOTHE) Date: Sat, 24 Nov 2018 11:29:57 -0600 Subject: Amazon Peering In-Reply-To: References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> Message-ID: This is a note I received on Oct18 when checking on a peering request submitted on Aug7.. “Apologies for the delays here. We have temporarily frozen IX peering as we revise some of our automation processes. I’m hopeful this will be unblocked by early November. Thank you for your continued patience.” > On Nov 24, 2018, at 10:59, Darin Steffl wrote: > > It seems wasteful for Amazon to connect to an IX but then ignore peering requests for a year. > > They have 40G of connectivity but are unresponsive. I'll try emailing all the other contacts listed in peeringdb. > > Thanks > >> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett > I've e-mailed my contacts there a couple times on people's behalf. No response yet. >> >> It seems like a lot of organizations need 1 more person in their peering departments. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> From: "Darin Steffl" >> To: "North American Network Operators' Group" >> Sent: Friday, November 23, 2018 10:21:51 PM >> Subject: Amazon Peering >> >> Hey all, >> >> Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. >> >> I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. >> >> >> >> -- >> Darin Steffl >> Minnesota WiFi >> www.mnwifi.com >> 507-634-WiFi >> Like us on Facebook >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgm+nanog at ip-64-139-1-69.sjc.megapath.net Sun Nov 25 01:47:31 2018 From: hgm+nanog at ip-64-139-1-69.sjc.megapath.net (Hal Murray) Date: Sat, 24 Nov 2018 17:47:31 -0800 Subject: Internet diameter? In-Reply-To: Message from "Keith Medcalf" of "Thu, 22 Nov 2018 12:31:24 -0700" <9e0677d0b32dad4497d24af030293deb@mail.dessus.com> Message-ID: <20181125014731.C27B040605C@ip-64-139-1-69.sjc.megapath.net> Keith Medcalf said: > "just static content" would be more accurate ... and using http rather than https > There were many attempts at this by Johhny-cum-lately ISPs back in the 90's > -- particularly Telco and Cableco's -- with their "transparent poxies". > Eventually they discovered that it was more cost efficient to actually > provide the customer with what the customer had purchased. One of the complications in this area is an extra layer of logging which could turn into privacy invasion. I'm pretty sure it was Comcast, but a quick search didn't find a good reference. Many years ago, there were a lot of complaints when customers discovered that their transparent proxy web site traffic was getting logged. Comcast said they weren't using it for anything beyond normal operations work, but nobody believed them. Shortly after that, they gave up on proxying. I'm sure the general reputation of modern Telcos and Cablecos for privacy invasion didn't help. -- These are my opinions. I hate spam. From ben at 6by7.net Sun Nov 25 06:05:05 2018 From: ben at 6by7.net (Ben Cannon) Date: Sat, 24 Nov 2018 22:05:05 -0800 Subject: DWDM forums Message-ID: <5C6667D7-0CF2-4801-840F-C67F213D1F04@6by7.net> Apologies for the noise, but can anyone recommend some DWDM or other glass/laser/amplifier communities or forums? There has to be a ton of overlap with this group. -Ben. From nanog at ics-il.net Sun Nov 25 14:38:54 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 25 Nov 2018 08:38:54 -0600 (CST) Subject: Cheap switch with a couple 100G Message-ID: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> I keep hearing how cheap 100G is compared to 40G and it doesn't seem to hold true. Prove me wrong. Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x 40G ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k. Am I missing some cheap switches with 100G? I ask this because the transport companies seem to have given up on 40G. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From saku at ytti.fi Sun Nov 25 15:45:58 2018 From: saku at ytti.fi (Saku Ytti) Date: Sun, 25 Nov 2018 17:45:58 +0200 Subject: Cheap switch with a couple 100G In-Reply-To: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> Message-ID: The argument should be 50G is cheaper than 40G. Because serdes is 25G typically, you get 25, 50, 100 without gearboxes and retimers, so less pincount, less thermal, higher density, lower cost. But BOM impact to pricing isn't high anyhow, unless we're talking about massive port counts. If box DOES support 10GE and 40GE then the cost benefit is not there, so you need to be targeting quite specific use case, use-case large scale DCs are targeting. On Sun, 25 Nov 2018 at 16:42, Mike Hammett wrote: > > I keep hearing how cheap 100G is compared to 40G and it doesn't seem to hold true. Prove me wrong. > > Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x 40G ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k. > > Am I missing some cheap switches with 100G? > > > I ask this because the transport companies seem to have given up on 40G. > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com -- ++ytti From chuckchurch at gmail.com Sun Nov 25 17:07:33 2018 From: chuckchurch at gmail.com (Chuck Church) Date: Sun, 25 Nov 2018 12:07:33 -0500 Subject: Cheap switch with a couple 100G In-Reply-To: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> Message-ID: <00ac01d484e1$5cbc9d80$1635d880$@gmail.com> Under 1K for 48 10G ports? Are you missing a decimal place? Chuck -----Original Message----- From: NANOG On Behalf Of Mike Hammett Sent: Sunday, November 25, 2018 9:39 AM To: 'North American Network Operators' Group' Subject: Cheap switch with a couple 100G I keep hearing how cheap 100G is compared to 40G and it doesn't seem to hold true. Prove me wrong. Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x 40G ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k. Am I missing some cheap switches with 100G? I ask this because the transport companies seem to have given up on 40G. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From morrowc.lists at gmail.com Sun Nov 25 17:08:01 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 25 Nov 2018 12:08:01 -0500 Subject: Internet diameter? In-Reply-To: <20181125014731.C27B040605C@ip-64-139-1-69.sjc.megapath.net> References: <9e0677d0b32dad4497d24af030293deb@mail.dessus.com> <20181125014731.C27B040605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: On Sat, Nov 24, 2018 at 8:48 PM Hal Murray < hgm+nanog at ip-64-139-1-69.sjc.megapath.net> wrote: > > Keith Medcalf said: > > "just static content" would be more accurate ... > > and using http rather than https > > > There were many attempts at this by Johhny-cum-lately ISPs back in the > 90's > > -- particularly Telco and Cableco's -- with their "transparent poxies". > > Eventually they discovered that it was more cost efficient to actually > > provide the customer with what the customer had purchased. > > One of the complications in this area is an extra layer of logging which > could > turn into privacy invasion. > > I'm pretty sure it was Comcast, but a quick search didn't find a good > reference. Many years ago, there were a lot of complaints when customers > did you mean the 'sandvine experiment' that happened ~10 yrs back? or did you mean the plan verizon had to proxy all http/https traffic from consumer (fios/dsl) links through their gear so they could replace ad content and such? or did you mean the various (barefruit/nominim/paxfire) dns fake-answer companies that dropped your customer on their "search platform" for monetization? fairly much all of those are a wreck for consumer privacy :( > discovered that their transparent proxy web site traffic was getting > logged. > Comcast said they weren't using it for anything beyond normal operations > work, > but nobody believed them. Shortly after that, they gave up on proxying. > > I'm sure the general reputation of modern Telcos and Cablecos for privacy > invasion didn't help. > > it's a rough business to be in, they say... but invading privacy of their users makes things seem a heck of a lot worse. > > -- > These are my opinions. I hate spam. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Nov 25 18:10:34 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 25 Nov 2018 12:10:34 -0600 (CST) Subject: Cheap switch with a couple 100G In-Reply-To: <00ac01d484e1$5cbc9d80$1635d880$@gmail.com> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <00ac01d484e1$5cbc9d80$1635d880$@gmail.com> Message-ID: <1334160922.11785.1543169431985.JavaMail.mhammett@ThunderFuck> No. Cisco Nexus 3064, Arista 7050sx, etc. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Chuck Church" To: "Mike Hammett" , "North American Network Operators' Group" Sent: Sunday, November 25, 2018 11:07:33 AM Subject: RE: Cheap switch with a couple 100G Under 1K for 48 10G ports? Are you missing a decimal place? Chuck -----Original Message----- From: NANOG On Behalf Of Mike Hammett Sent: Sunday, November 25, 2018 9:39 AM To: 'North American Network Operators' Group' Subject: Cheap switch with a couple 100G I keep hearing how cheap 100G is compared to 40G and it doesn't seem to hold true. Prove me wrong. Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x 40G ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k. Am I missing some cheap switches with 100G? I ask this because the transport companies seem to have given up on 40G. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Nov 25 18:13:50 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 25 Nov 2018 12:13:50 -0600 (CST) Subject: Cheap switch with a couple 100G In-Reply-To: <06295126-D51F-4FF1-A639-07DB50ED232F@gmail.com> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <06295126-D51F-4FF1-A639-07DB50ED232F@gmail.com> Message-ID: <555182123.11789.1543169626045.JavaMail.mhammett@ThunderFuck> I don't need 32 of them, though. 2 - 6 would be fine, 4 - 6 would be ideal. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "joel jaeggli" To: "Mike Hammett" Cc: "North American Network Operators' Group" Sent: Sunday, November 25, 2018 9:41:07 AM Subject: Re: Cheap switch with a couple 100G Sent from my iPhone > On Nov 25, 2018, at 06:38, Mike Hammett wrote: > > I keep hearing how cheap 100G is compared to 40G and it doesn't seem to hold true. Prove me wrong. > > Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x 40G ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k. > > Am I missing some cheap switches with 100G? 1 / 10 / 40 Gb/s switches are made with low end T2 parts like the 56450. A low end 100G switch is tomahawk 32x100 or tomawhawk 2 or T3 which are all basically 128x25Gb/s asics (or Qumran/Jericho) which’s is effectively more than one asic and is priced accordingly. So a mix of 1Gb/s copper ports backed by fast silicon is not immediately forthcoming at a low price. 32x100 switches are available at order of $200 a port which seems like pretty good deal to me but you’re amortizing the silicon across all the ports. > > I ask this because the transport companies seem to have given up on 40G. > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Nov 25 18:16:05 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 25 Nov 2018 12:16:05 -0600 (CST) Subject: Cheap switch with a couple 100G In-Reply-To: References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> Message-ID: <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> I haven't seen anyone selling 25G or 50G transport. ----- 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: nanog at nanog.org Sent: Sunday, November 25, 2018 9:45:58 AM Subject: Re: Cheap switch with a couple 100G The argument should be 50G is cheaper than 40G. Because serdes is 25G typically, you get 25, 50, 100 without gearboxes and retimers, so less pincount, less thermal, higher density, lower cost. But BOM impact to pricing isn't high anyhow, unless we're talking about massive port counts. If box DOES support 10GE and 40GE then the cost benefit is not there, so you need to be targeting quite specific use case, use-case large scale DCs are targeting. On Sun, 25 Nov 2018 at 16:42, Mike Hammett wrote: > > I keep hearing how cheap 100G is compared to 40G and it doesn't seem to hold true. Prove me wrong. > > Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x 40G ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k. > > Am I missing some cheap switches with 100G? > > > I ask this because the transport companies seem to have given up on 40G. > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com -- ++ytti -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Sun Nov 25 18:31:04 2018 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 25 Nov 2018 18:31:04 +0000 Subject: Cheap switch with a couple 100G In-Reply-To: <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> Message-ID: <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> On 25/11/2018 18:16, Mike Hammett wrote: > I haven't seen anyone selling 25G or 50G transport. That's because, in active transport at least, 100G makes far more sense. You may start seeing passive 25G WDM soon. Finisar have a DWDM tunable, I believe. -- Tom From ben at 6by7.net Sun Nov 25 18:37:03 2018 From: ben at 6by7.net (Ben Cannon) Date: Sun, 25 Nov 2018 10:37:03 -0800 Subject: Cheap switch with a couple 100G In-Reply-To: <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> Message-ID: <76910623-0EAA-4A06-9542-7220284A8FEB@6by7.net> That’s because the DWDM solutions (at least the good ones, wisely) use single-wavelength 100Ghz coherent light (like, you know, normal optics from the rest of history), and do not play this 4x25g lane splitting game. Unfortunately they are still quite expensive and physically large, smallest I know of right now is in CFP2. - Ben Cannon, AS15206 > On Nov 25, 2018, at 10:16 AM, Mike Hammett wrote: > > I haven't seen anyone selling 25G or 50G transport. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From: "Saku Ytti" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Sunday, November 25, 2018 9:45:58 AM > Subject: Re: Cheap switch with a couple 100G > > The argument should be 50G is cheaper than 40G. > > Because serdes is 25G typically, you get 25, 50, 100 without gearboxes > and retimers, so less pincount, less thermal, higher density, lower > cost. > > But BOM impact to pricing isn't high anyhow, unless we're talking > about massive port counts. > > If box DOES support 10GE and 40GE then the cost benefit is not there, > so you need to be targeting quite specific use case, use-case large > scale DCs are targeting. > > On Sun, 25 Nov 2018 at 16:42, Mike Hammett wrote: > > > > I keep hearing how cheap 100G is compared to 40G and it doesn't seem to hold true. Prove me wrong. > > > > Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x 40G ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k. > > > > Am I missing some cheap switches with 100G? > > > > > > I ask this because the transport companies seem to have given up on 40G. > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > -- > ++ytti -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Nov 25 18:59:39 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 25 Nov 2018 12:59:39 -0600 (CST) Subject: Cheap switch with a couple 100G In-Reply-To: <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> Message-ID: <840938914.11900.1543172375945.JavaMail.mhammett@ThunderFuck> It wouldn't be hard to do any standard wavelength, really. They just need an appropriate mux. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Tom Hill" To: nanog at nanog.org Sent: Sunday, November 25, 2018 12:31:04 PM Subject: Re: Cheap switch with a couple 100G On 25/11/2018 18:16, Mike Hammett wrote: > I haven't seen anyone selling 25G or 50G transport. That's because, in active transport at least, 100G makes far more sense. You may start seeing passive 25G WDM soon. Finisar have a DWDM tunable, I believe. -- Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Sun Nov 25 19:09:59 2018 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 25 Nov 2018 19:09:59 +0000 Subject: Cheap switch with a couple 100G In-Reply-To: <840938914.11900.1543172375945.JavaMail.mhammett@ThunderFuck> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> <840938914.11900.1543172375945.JavaMail.mhammett@ThunderFuck> Message-ID: On 25/11/2018 18:59, Mike Hammett wrote: > It wouldn't be hard to do any standard wavelength, really. They just > need an appropriate mux. I'm really not sure that your statement makes sense by itself. -- Tom From colton.conor at gmail.com Sun Nov 25 20:06:30 2018 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 25 Nov 2018 14:06:30 -0600 Subject: Cheap switch with a couple 100G In-Reply-To: <1334160922.11785.1543169431985.JavaMail.mhammett@ThunderFuck> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <00ac01d484e1$5cbc9d80$1635d880$@gmail.com> <1334160922.11785.1543169431985.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, Are you saying that you can buy a new Cisco Nexus 3064 or Arista 7050sx for $1,000 new from these vendors, or are you talking about used stuff on eBay? If you are comparing to used stuff on ebay pricing good luck. I doubt you will find many used 100G switches as they are too new of a technology unlike 10G. Hell you can barely buy a couple of 10KM 100G optics from FS.com for less than $1000. On Sun, Nov 25, 2018 at 12:11 PM Mike Hammett wrote: > No. > > Cisco Nexus 3064, Arista 7050sx, etc. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Chuck Church" > *To: *"Mike Hammett" , "North American Network > Operators' Group" > *Sent: *Sunday, November 25, 2018 11:07:33 AM > *Subject: *RE: Cheap switch with a couple 100G > > Under 1K for 48 10G ports? Are you missing a decimal place? > > Chuck > > -----Original Message----- > From: NANOG On Behalf Of Mike Hammett > Sent: Sunday, November 25, 2018 9:39 AM > To: 'North American Network Operators' Group' > Subject: Cheap switch with a couple 100G > > I keep hearing how cheap 100G is compared to 40G and it doesn't seem to > hold true. Prove me wrong. > > Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x > 40G ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k. > > Am I missing some cheap switches with 100G? > > > I ask this because the transport companies seem to have given up on 40G. > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Nov 25 20:16:22 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 25 Nov 2018 14:16:22 -0600 (CST) Subject: Cheap switch with a couple 100G In-Reply-To: References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <00ac01d484e1$5cbc9d80$1635d880$@gmail.com> <1334160922.11785.1543169431985.JavaMail.mhammett@ThunderFuck> Message-ID: <2014293487.11969.1543176977890.JavaMail.mhammett@ThunderFuck> No, not new. No need to buy new switches when there are so many used available (except for now needing 100G). Switches have an extremely long life. I have a client that has 15 year old Foundry switches that just work, though we're looking to replace them to get some 10G ports. The pricing was part of my point. For years everyone says just skip 40G and go to 100G. The price difference isn't that much.... but it is. "Everyone just skipped 40G and went for 100G." Then why is there such an availability of 40G switches? Obviously they weren't skipped, but purchased and then later replaced. Looks like $280 for an LR4 40G and $800 for an LR4 100G. Still a premium for 100G over 40G. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Colton Conor" To: "Mike Hammett" Cc: chuckchurch at gmail.com, "NANOG" Sent: Sunday, November 25, 2018 2:06:30 PM Subject: Re: Cheap switch with a couple 100G Mike, Are you saying that you can buy a new Cisco Nexus 3064 or Arista 7050sx for $1,000 new from these vendors, or are you talking about used stuff on eBay? If you are comparing to used stuff on ebay pricing good luck. I doubt you will find many used 100G switches as they are too new of a technology unlike 10G. Hell you can barely buy a couple of 10KM 100G optics from FS.com for less than $1000. On Sun, Nov 25, 2018 at 12:11 PM Mike Hammett < nanog at ics-il.net > wrote: No. Cisco Nexus 3064, Arista 7050sx, etc. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Chuck Church" < chuckchurch at gmail.com > To: "Mike Hammett" < nanog at ics-il.net >, "North American Network Operators' Group" < nanog at nanog.org > Sent: Sunday, November 25, 2018 11:07:33 AM Subject: RE: Cheap switch with a couple 100G Under 1K for 48 10G ports? Are you missing a decimal place? Chuck -----Original Message----- From: NANOG < nanog-bounces at nanog.org > On Behalf Of Mike Hammett Sent: Sunday, November 25, 2018 9:39 AM To: 'North American Network Operators' Group' < nanog at nanog.org > Subject: Cheap switch with a couple 100G I keep hearing how cheap 100G is compared to 40G and it doesn't seem to hold true. Prove me wrong. Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x 40G ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k. Am I missing some cheap switches with 100G? I ask this because the transport companies seem to have given up on 40G. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Sun Nov 25 20:20:15 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sun, 25 Nov 2018 15:20:15 -0500 Subject: Cheap switch with a couple 100G In-Reply-To: References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <00ac01d484e1$5cbc9d80$1635d880$@gmail.com> <1334160922.11785.1543169431985.JavaMail.mhammett@ThunderFuck> Message-ID: On 11/25/18 3:06 PM, Colton Conor wrote: > Arista 7050sx I've seen these and their friends on the fleabay for about $1000 in working condition. It does happen, though I'd not say you can just drop in and BIN one any time any day. I picked up a Ruckus/Arris ICX7650 with 40G module (so 2x 100G, 4x40G, 24x10G, 24x1G) for $700 a few months back on the fleabay, but that was a somewhat unusual deal, and that platform is not without its limitations (especially L3), but it's a perfectly capable box. Of course, you're buying on fleabay, but if that's compatible with your network operations, then why not. It usually works fine. Worst comes to worst, buy two or three for less than a new one costs, and you have on-hand spares. -- Brandon Martin From hugge at nordu.net Sun Nov 25 20:56:10 2018 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Sun, 25 Nov 2018 21:56:10 +0100 Subject: Cheap switch with a couple 100G In-Reply-To: <2014293487.11969.1543176977890.JavaMail.mhammett@ThunderFuck> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <00ac01d484e1$5cbc9d80$1635d880$@gmail.com> <1334160922.11785.1543169431985.JavaMail.mhammett@ThunderFuck> <2014293487.11969.1543176977890.JavaMail.mhammett@ThunderFuck> Message-ID: <507bebf7-3fbd-0333-0eb5-8933d36609d3@nordu.net> On 2018-11-25 21:16, Mike Hammett wrote: > No, not new. No need to buy new switches when there are so many used available (except for now needing 100G). Switches > have an extremely long life. I have a client that has 15 year old Foundry switches that just work, though we're looking > to replace them to get some 10G ports. > > The pricing was part of my point. For years everyone says just skip 40G and go to 100G. The price difference isn't that > much....  but it is. > > "Everyone just skipped 40G and went for 100G." Then why is there such an availability of 40G switches? Obviously they > weren't skipped, but purchased and then later replaced. > > Looks like $280 for an LR4 40G and $800 for an LR4 100G. Still a premium for 100G over 40G. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com Whole bunch of Apples and Oranges mixed here. * 40G in the ISP/Telco world is more or less non-existant. There was never a good uptake on any products aimed towards ISP/Telco that did 40G cost-effectively. This is partly because 40G was/is never a thing in the DWDM-world either. There was some STM256 built and some OTU3 built aswell but not nearly in the same density as 10G was and 100G is built today, it had a weird timing with being fairly close to 100G and abit to distant to cost-effective 10G so it never had any good usecase. So if you buy services from a Telco, its very likely that 40G handoff is the least preffered option for them. Or most likely not a option at all (like from every company ive been involved with) * You compare market-economics with what new stuff cost vs used stuff on ebay/liquidators cost. Thats not a sane way of doing math, the reason why old 10/40 nexus and arista etc is plentiful on ebay is because people switched it out to something newer, faster. There isn't currently anything faster on the market then 100G-switches so naturally there isn't much of that available used. Now that at least some product-families (spine switches) getting 400G with the new TH3-switches we can assume that there is a decent amount of older 100G spines getting decommisioned, and hence getting available in the second hand market (maybe even late next year). However there has been _a lot_ of datacenters being lifted from 10G/40G to 25/50/100G architecture the last year, so it makes sense that the predecessor is on ebay. If you are to buy *new* stuff id say that going for 100G of 40G architecture makes sense in almost every aspect, regardless of what products and usecase you have. If you rely on second-hand, then sure, 40G might be a decent choice. However i would cry if id have to buy 40G optics today since i know they be binned in a year anyway. (4x10G PIR is still usable optics in 100G land though). -- hugge From baldur.norddahl at gmail.com Sun Nov 25 21:22:18 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 25 Nov 2018 22:22:18 +0100 Subject: Cheap switch with a couple 100G In-Reply-To: <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> Message-ID: If it is passive, you could tell them it is for 10G but use it for 25G? søn. 25. nov. 2018 19.32 skrev Tom Hill : > On 25/11/2018 18:16, Mike Hammett wrote: > > I haven't seen anyone selling 25G or 50G transport. > > > That's because, in active transport at least, 100G makes far more sense. > > You may start seeing passive 25G WDM soon. Finisar have a DWDM tunable, > I believe. > > -- > Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Nov 25 21:31:49 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 25 Nov 2018 15:31:49 -0600 (CST) Subject: Cheap switch with a couple 100G In-Reply-To: <507bebf7-3fbd-0333-0eb5-8933d36609d3@nordu.net> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <00ac01d484e1$5cbc9d80$1635d880$@gmail.com> <1334160922.11785.1543169431985.JavaMail.mhammett@ThunderFuck> <2014293487.11969.1543176977890.JavaMail.mhammett@ThunderFuck> <507bebf7-3fbd-0333-0eb5-8933d36609d3@nordu.net> Message-ID: <1301476887.12041.1543181506468.JavaMail.mhammett@ThunderFuck> Used Cisco Nexus 93180YC (oh, I guess New, sorry, it was on eBay, so I assumed used) is about $6,500, though I've heard they go down to $4k from time to time. So then maybe that's the problem... not enough used 100G gear out there yet to make it affordable... leaving 40G as the biggest cost-effective option. Most people I know don't buy that kind of gear new, only used. It costs too much, otherwise. >From what I've gathered from active DWDM platform vendors, it doesn't matter what you throw at it (up to the latest and greatest), they just eat it up (assuming you have the right line cards). Maybe it only works that way when talking to sales\marketing? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Fredrik Korsbäck" To: nanog at nanog.org Sent: Sunday, November 25, 2018 2:56:10 PM Subject: Re: Cheap switch with a couple 100G On 2018-11-25 21:16, Mike Hammett wrote: > No, not new. No need to buy new switches when there are so many used available (except for now needing 100G). Switches > have an extremely long life. I have a client that has 15 year old Foundry switches that just work, though we're looking > to replace them to get some 10G ports. > > The pricing was part of my point. For years everyone says just skip 40G and go to 100G. The price difference isn't that > much.... but it is. > > "Everyone just skipped 40G and went for 100G." Then why is there such an availability of 40G switches? Obviously they > weren't skipped, but purchased and then later replaced. > > Looks like $280 for an LR4 40G and $800 for an LR4 100G. Still a premium for 100G over 40G. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com Whole bunch of Apples and Oranges mixed here. * 40G in the ISP/Telco world is more or less non-existant. There was never a good uptake on any products aimed towards ISP/Telco that did 40G cost-effectively. This is partly because 40G was/is never a thing in the DWDM-world either. There was some STM256 built and some OTU3 built aswell but not nearly in the same density as 10G was and 100G is built today, it had a weird timing with being fairly close to 100G and abit to distant to cost-effective 10G so it never had any good usecase. So if you buy services from a Telco, its very likely that 40G handoff is the least preffered option for them. Or most likely not a option at all (like from every company ive been involved with) * You compare market-economics with what new stuff cost vs used stuff on ebay/liquidators cost. Thats not a sane way of doing math, the reason why old 10/40 nexus and arista etc is plentiful on ebay is because people switched it out to something newer, faster. There isn't currently anything faster on the market then 100G-switches so naturally there isn't much of that available used. Now that at least some product-families (spine switches) getting 400G with the new TH3-switches we can assume that there is a decent amount of older 100G spines getting decommisioned, and hence getting available in the second hand market (maybe even late next year). However there has been _a lot_ of datacenters being lifted from 10G/40G to 25/50/100G architecture the last year, so it makes sense that the predecessor is on ebay. If you are to buy *new* stuff id say that going for 100G of 40G architecture makes sense in almost every aspect, regardless of what products and usecase you have. If you rely on second-hand, then sure, 40G might be a decent choice. However i would cry if id have to buy 40G optics today since i know they be binned in a year anyway. (4x10G PIR is still usable optics in 100G land though). -- hugge -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Sun Nov 25 21:40:47 2018 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 25 Nov 2018 21:40:47 +0000 Subject: Cheap switch with a couple 100G In-Reply-To: References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> Message-ID: On 25/11/2018 21:22, Baldur Norddahl wrote: > If it is passive, you could tell them it is for 10G but use it for 25G? The mux isn't the problem, it's that there aren't SFP28 optics commonly available in C/DWDM wavelengths. Yet. If they were, well maybe... ... However, your trouble then is that 25G will have similar loss characteristics to 4x25 100GBASE, which to put it simply, isn't as favourable as your existing 10G transceivers. You will *really* begin to care about how 'direct' your cross-connects are. Coherent optical transport has become far more common in recent years for the same reasons, and pizza-box solutions for this are even coming in whitebox guise now (see Facebook/Cumulus). On the retail side, if you're buying 'grey' wavelength services from optical network operators as opposed to running your own transport, they now tend to be bundling everything into coherent line sides through the use of muxponders. The problem with buying 25G services then becomes "our vendor doesn't discount as hard for the 4x25G muxponder part as they do for the 10x10G part!", or "we'll have to buy this for you especially, and so you're footing >25% of the bill". Chicken & egg: someone has to move first... And I don't see the ASR9k and Juniper MX BUs rushing to support 25 & 50G. -- Tom From ben at 6by7.net Sun Nov 25 21:43:17 2018 From: ben at 6by7.net (Ben Cannon) Date: Sun, 25 Nov 2018 13:43:17 -0800 Subject: Cheap switch with a couple 100G In-Reply-To: References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> Message-ID: <80C53657-C134-4770-BAA9-907DA5D8D07F@6by7.net> At this point, with 400g coherent in production never mind long-haul testing; why bother lighting with anything slower than 100g coherent, especially at essentially the same price. It just makes no sense. It got skipped. We’re better for it IMO. - Ben Cannon, AS15206 > On Nov 25, 2018, at 1:40 PM, Tom Hill wrote: > > On 25/11/2018 21:22, Baldur Norddahl wrote: >> If it is passive, you could tell them it is for 10G but use it for 25G? > > > The mux isn't the problem, it's that there aren't SFP28 optics commonly > available in C/DWDM wavelengths. Yet. If they were, well maybe... > > ... However, your trouble then is that 25G will have similar loss > characteristics to 4x25 100GBASE, which to put it simply, isn't as > favourable as your existing 10G transceivers. You will *really* begin to > care about how 'direct' your cross-connects are. > > Coherent optical transport has become far more common in recent years > for the same reasons, and pizza-box solutions for this are even coming > in whitebox guise now (see Facebook/Cumulus). > > On the retail side, if you're buying 'grey' wavelength services from > optical network operators as opposed to running your own transport, they > now tend to be bundling everything into coherent line sides through the > use of muxponders. The problem with buying 25G services then becomes > "our vendor doesn't discount as hard for the 4x25G muxponder part as > they do for the 10x10G part!", or "we'll have to buy this for you > especially, and so you're footing >25% of the bill". > > Chicken & egg: someone has to move first... And I don't see the ASR9k > and Juniper MX BUs rushing to support 25 & 50G. > > -- > Tom From tony at wicks.co.nz Sun Nov 25 21:50:58 2018 From: tony at wicks.co.nz (Tony Wicks) Date: Mon, 26 Nov 2018 10:50:58 +1300 Subject: Cheap switch with a couple 100G In-Reply-To: References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> Message-ID: <017601d48508$f4ebe580$dec3b080$@wicks.co.nz> Actually FS has SFP28 CWDM optics (1270-1330) available but they are not up on the website, just as an FYI. -----Original Message----- From: NANOG On Behalf Of Tom Hill Sent: Monday, 26 November 2018 10:41 AM To: nanog at nanog.org Subject: Re: Cheap switch with a couple 100G On 25/11/2018 21:22, Baldur Norddahl wrote: > If it is passive, you could tell them it is for 10G but use it for 25G? The mux isn't the problem, it's that there aren't SFP28 optics commonly available in C/DWDM wavelengths. Yet. If they were, well maybe... From ben at 6by7.net Sun Nov 25 21:52:58 2018 From: ben at 6by7.net (Ben Cannon) Date: Sun, 25 Nov 2018 13:52:58 -0800 Subject: Cheap switch with a couple 100G In-Reply-To: <017601d48508$f4ebe580$dec3b080$@wicks.co.nz> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> <017601d48508$f4ebe580$dec3b080$@wicks.co.nz> Message-ID: Single Wavelength Coherent or 4x10g coherent? - Ben Cannon, AS15206 > On Nov 25, 2018, at 1:50 PM, Tony Wicks wrote: > > Actually FS has SFP28 CWDM optics (1270-1330) available but they are not up on the website, just as an FYI. > > -----Original Message----- > From: NANOG On Behalf Of Tom Hill > Sent: Monday, 26 November 2018 10:41 AM > To: nanog at nanog.org > Subject: Re: Cheap switch with a couple 100G > > On 25/11/2018 21:22, Baldur Norddahl wrote: >> If it is passive, you could tell them it is for 10G but use it for 25G? > > > The mux isn't the problem, it's that there aren't SFP28 optics commonly available in C/DWDM wavelengths. Yet. If they were, well maybe... > > From tom at ninjabadger.net Sun Nov 25 21:56:01 2018 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 25 Nov 2018 21:56:01 +0000 Subject: Cheap switch with a couple 100G In-Reply-To: <80C53657-C134-4770-BAA9-907DA5D8D07F@6by7.net> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> <80C53657-C134-4770-BAA9-907DA5D8D07F@6by7.net> Message-ID: <36aeb676-530a-1574-93a7-4aea36ccca6f@ninjabadger.net> On 25/11/2018 21:43, Ben Cannon wrote: > At this point, with 400g coherent in production never mind long-haul > testing; why bother lighting with anything slower than 100g coherent, > especially at essentially the same price. It just makes no sense. > It got skipped. We’re better for it IMO. To be fair, I did say that to begin with. ;) Outside of the US, in our quaint little European countries, passive muxing with direct detect does often make more sense financially Those coherent hardware providers have some eye-watering price lists, and only begin to make sense on spans >100km. Or if you actually need 400G transport to make use of N*100G services. -- Tom From tom at ninjabadger.net Sun Nov 25 21:59:19 2018 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 25 Nov 2018 21:59:19 +0000 Subject: Cheap switch with a couple 100G In-Reply-To: References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> <017601d48508$f4ebe580$dec3b080$@wicks.co.nz> Message-ID: On 25/11/2018 21:52, Ben Cannon wrote: > Single Wavelength Coherent or 4x10g coherent? SFP28... So 1x25G, and direct detect. > Actually FS has SFP28 CWDM optics (1270-1330) available but they are > not up on the website, just as an FYI. Missed that original mail, Tony. Good to know, thank you. -- Tom From nanog at ics-il.net Sun Nov 25 22:17:33 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 25 Nov 2018 16:17:33 -0600 (CST) Subject: Cheap switch with a couple 100G In-Reply-To: <36aeb676-530a-1574-93a7-4aea36ccca6f@ninjabadger.net> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> <80C53657-C134-4770-BAA9-907DA5D8D07F@6by7.net> <36aeb676-530a-1574-93a7-4aea36ccca6f@ninjabadger.net> Message-ID: <632653320.12079.1543184247227.JavaMail.mhammett@ThunderFuck> FS has reasonable pricing on their amplification systems for DWDM. The problem in the states is the dark fiber consolidation, so it's difficult to find someone that'll sell it to you. Those that do, charge astronomically for it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Tom Hill" To: nanog at nanog.org Sent: Sunday, November 25, 2018 3:56:01 PM Subject: Re: Cheap switch with a couple 100G On 25/11/2018 21:43, Ben Cannon wrote: > At this point, with 400g coherent in production never mind long-haul > testing; why bother lighting with anything slower than 100g coherent, > especially at essentially the same price. It just makes no sense. > It got skipped. We’re better for it IMO. To be fair, I did say that to begin with. ;) Outside of the US, in our quaint little European countries, passive muxing with direct detect does often make more sense financially Those coherent hardware providers have some eye-watering price lists, and only begin to make sense on spans >100km. Or if you actually need 400G transport to make use of N*100G services. -- Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Sun Nov 25 22:38:04 2018 From: aled.w.morris at googlemail.com (Aled Morris) Date: Sun, 25 Nov 2018 22:38:04 +0000 Subject: Cheap switch with a couple 100G In-Reply-To: References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> Message-ID: On Sun, 25 Nov 2018 at 21:42, Tom Hill wrote: > Chicken & egg: someone has to move first... And I don't see the ASR9k > and Juniper MX BUs rushing to support 25 & 50G. > Juniper have launched a Trident based switch with 48 x 25G ports (the QFX5120-48Y.) But I agree the commercials aren't as simple with their in-house silicon platforms. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Sun Nov 25 22:42:41 2018 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 25 Nov 2018 22:42:41 +0000 Subject: Cheap switch with a couple 100G In-Reply-To: References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> Message-ID: <5dac595a-08bb-f76c-a4f7-dbff6a073f64@ninjabadger.net> On 25/11/2018 22:38, Aled Morris wrote: > Juniper have launched a Trident based switch with 48 x 25G ports (the > QFX5120-48Y.) I very specifically said "Juniper MX". ;) -- Tom From baldur.norddahl at gmail.com Sun Nov 25 23:47:11 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 26 Nov 2018 00:47:11 +0100 Subject: Cheap switch with a couple 100G In-Reply-To: <5dac595a-08bb-f76c-a4f7-dbff6a073f64@ninjabadger.net> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> <1407174586.11804.1543169759159.JavaMail.mhammett@ThunderFuck> <36491b38-6838-6c4e-2e65-d7c87dc59999@ninjabadger.net> <5dac595a-08bb-f76c-a4f7-dbff6a073f64@ninjabadger.net> Message-ID: The MX204 can split each 100G port into 4x10G. Why not 4x25G ? This would give you 16x 25G which seems quite reasonable. Regards Baldur søn. 25. nov. 2018 23.43 skrev Tom Hill : > On 25/11/2018 22:38, Aled Morris wrote: > > Juniper have launched a Trident based switch with 48 x 25G ports (the > > QFX5120-48Y.) > > > I very specifically said "Juniper MX". ;) > > -- > Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffm at iglou.com Mon Nov 26 00:07:14 2018 From: jeffm at iglou.com (Jeff McAdams) Date: Sun, 25 Nov 2018 19:07:14 -0500 Subject: RPKI publication In-Reply-To: References: <55132.162.155.102.254.1542995499.iglou@webmail.iglou.com> <6E4775C8-0107-41C9-A9CB-8DE6706E161F@nlnetlabs.nl> <27692.24.166.32.244.1543024261.iglou@webmail.iglou.com> Message-ID: <96FBF81B-8710-479A-8BAE-86EEEBFEDE37@iglou.com> Thanks, but as I mentioned, I've got the validation/relying party side pretty well covered which is what Routinator is. I'm looking for options for running a delegated CA and potentially providing a publishing point. -- Jeff On November 25, 2018 5:45:21 PM EST, Michael Gehrmann wrote: >Hi Jeff, > >I've worked on getting routinator installed via ansible recently and >had >some success. Seems to be the most actively supported/developed rpki I >have >seen out of the 3 options. > >https://bitbucket.org/mjgehrmann/ansible-role-routinator > >Regards >-- >MiCHAEL > >On Sat, 24 Nov 2018 at 12:52, Jeff McAdams wrote: > >> On Fri, November 23, 2018 18:20, Christopher Morrow wrote: >> > On Fri, Nov 23, 2018 at 6:12 PM Jeff McAdams >wrote: >> >> On November 23, 2018 4:48:14 PM EST, Christopher Morrow < >> >> morrowc.lists at gmail.com> wrote: >> >> >> >>> I think there are 3 options: >> >>> ripe validator v2 (potentially v3?) - >> >>> https://github.com/RIPE-NCC/rpki-validator >> >>> >> >>> >> >>> https://github.com/RIPE-NCC/rpki-validator-3 >> >>> rpki.net validator - https://github.com/dragonresearch/rpki.net >bbn >> >>> rpstir - https://github.com/bgpsecurity/rpstir >> >> >> >> Like I said, validation and caching, "relying party", has several >> >> options...several of which are relatively easy to run and manage. >It's >> >> the CA and publishing for which no really good options (that I've >found, >> >> at least) are available currently. >> >> >> > >> > the ca bits do exist in rpki.net's software set... they are a tad >fiddly >> > to setup/run though, yes. >> >> Oops, sorry, I missed the rpki.net reference in there (I read and >replied >> to that message from my phone). >> >> Yes, I spent several hours trying to even get the Ubuntu 18.04 >packages to >> even install without errors. I'm not particularly keen on installing >a 2 >> 1/2 year old distro to run no-longer-supported version of the django >> framework to support this, so I'm pretty much putting into the "not >> reasonably current and maintained" category. >> >> -- >> Jeff >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvandolson at esri.com Mon Nov 26 01:20:49 2018 From: rvandolson at esri.com (Ray Van Dolson) Date: Sun, 25 Nov 2018 17:20:49 -0800 Subject: OpenDNS Issue (US Cali or West Coast?) Message-ID: <20181126012049.GA9161@esri.com> Getting issues from west-coast US clients trying to access services like O365, Yahoo, GMail, etc. east-coast US doesn't seem to have the same issue. DNS servers are: 208.67.222.222 208.67.220.220 Switching to Google (8.8.8.8) fixes the issue. Anyone else seeing this? Ray PS: Also posted to dns-operations From nanog at ics-il.net Mon Nov 26 01:42:26 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 25 Nov 2018 19:42:26 -0600 (CST) Subject: Cheap switch with a couple 100G In-Reply-To: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> References: <190188160.390363.1543156734428.JavaMail.zimbra@ics-il.net> Message-ID: <435820608.12131.1543196544528.JavaMail.mhammett@ThunderFuck> An acceptable alternative would be a cheap muxponder to take say 2x40 + 2x10 and stuff it into a 100G. Fiberstore used to have one, but don't seem to carry it anymore. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "North American Network Operators' Group" Sent: Sunday, November 25, 2018 8:38:54 AM Subject: Cheap switch with a couple 100G I keep hearing how cheap 100G is compared to 40G and it doesn't seem to hold true. Prove me wrong. Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x 40G ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k. Am I missing some cheap switches with 100G? I ask this because the transport companies seem to have given up on 40G. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at temk.in Mon Nov 26 04:47:39 2018 From: dave at temk.in (Dave Temkin) Date: Mon, 26 Nov 2018 12:47:39 +0800 Subject: netflix OCA in a CG-NAT world In-Reply-To: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> Message-ID: FWIW (reviving an old thread)- Putting an OCA with bypass through the CGN with RFC1918 space will actually work just fine. We (Netflix) don't formally support it because of the vast number of non-standard CGN implementations out there, but if your clients are in RFC1918 space and the next hop router from the OCA knows how to reach them, it will just work. We only use BGP to inform our control plane, not for local routing. Any traffic not served via the OCA will go through CGN as usual and out peering/transit. Note that it does complicate troubleshooting for both sides. And yes, IPv6 is fully supported by every piece of our infrastructure; the issue is TVs and STBs that do not support v6 - but we have finally seen the largest device manufacturers commit to supporting it (if they don't already on their late model sets) so that should change year over year. -Dave On Mon, Sep 17, 2018 at 11:52 PM Jared Mauch wrote: > > > > On Sep 17, 2018, at 6:54 AM, Tom Ammon wrote: > > > > I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, > in an ISP environment. I see in Netflix's FAQ on the subject that traffic > sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this > simply a matter of deploying the OCA on the outside of the CGN layer? What > are the other consequences of CGN upon the OCA? > > > > Yes, you want to deploy it outside your CG-NAT. > > I also strongly suggest you look at how to get native IPv6 from your > clients behind the CG-NAT rolled out. I know many folks have had issues > with various CDNs and the number of devices that reach out. This is why > folks get the Google captcha, etc. > > Giving those end-users an alternate way out will help. I understand this > may take effort and is harder for folks using UBNT & Tik gear in a smaller > environment, but there is value for your end-users. > > - Jared > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Mon Nov 26 05:04:36 2018 From: aaron1 at gvtc.com (Aaron1) Date: Sun, 25 Nov 2018 23:04:36 -0600 Subject: netflix OCA in a CG-NAT world In-Reply-To: References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> Message-ID: Thanks Dave, so my local OCA will listen to my BGP advertisements for RFC1918 prefixes if I decided to advertise them? Aaron > On Nov 25, 2018, at 10:47 PM, Dave Temkin wrote: > > FWIW (reviving an old thread)- > > Putting an OCA with bypass through the CGN with RFC1918 space will actually work just fine. We (Netflix) don't formally support it because of the vast number of non-standard CGN implementations out there, but if your clients are in RFC1918 space and the next hop router from the OCA knows how to reach them, it will just work. We only use BGP to inform our control plane, not for local routing. Any traffic not served via the OCA will go through CGN as usual and out peering/transit. Note that it does complicate troubleshooting for both sides. > > And yes, IPv6 is fully supported by every piece of our infrastructure; the issue is TVs and STBs that do not support v6 - but we have finally seen the largest device manufacturers commit to supporting it (if they don't already on their late model sets) so that should change year over year. > > -Dave > >> On Mon, Sep 17, 2018 at 11:52 PM Jared Mauch wrote: >> >> >> > On Sep 17, 2018, at 6:54 AM, Tom Ammon wrote: >> > >> > I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this simply a matter of deploying the OCA on the outside of the CGN layer? What are the other consequences of CGN upon the OCA? >> > >> >> Yes, you want to deploy it outside your CG-NAT. >> >> I also strongly suggest you look at how to get native IPv6 from your clients behind the CG-NAT rolled out. I know many folks have had issues with various CDNs and the number of devices that reach out. This is why folks get the Google captcha, etc. >> >> Giving those end-users an alternate way out will help. I understand this may take effort and is harder for folks using UBNT & Tik gear in a smaller environment, but there is value for your end-users. >> >> - Jared >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at temk.in Mon Nov 26 05:09:53 2018 From: dave at temk.in (Dave Temkin) Date: Mon, 26 Nov 2018 13:09:53 +0800 Subject: netflix OCA in a CG-NAT world In-Reply-To: References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> Message-ID: Not exactly. You don't need to advertise the RFC1918 to the OCA - just make sure you advertise the CGN prefix to it, and make sure that the OCA's default gateway knows how to reach the RFC1918 clients. So long as the "outside" IP of your CGN is advertised to the OCA (the IP that clients who would be using the OCA would appear to the internet as) it should work. Regards, -Dave On Mon, Nov 26, 2018 at 1:04 PM Aaron1 wrote: > Thanks Dave, so my local OCA will listen to my BGP advertisements for > RFC1918 prefixes if I decided to advertise them? > > Aaron > > On Nov 25, 2018, at 10:47 PM, Dave Temkin wrote: > > FWIW (reviving an old thread)- > > Putting an OCA with bypass through the CGN with RFC1918 space will > actually work just fine. We (Netflix) don't formally support it because of > the vast number of non-standard CGN implementations out there, but if your > clients are in RFC1918 space and the next hop router from the OCA knows how > to reach them, it will just work. We only use BGP to inform our control > plane, not for local routing. Any traffic not served via the OCA will go > through CGN as usual and out peering/transit. Note that it does complicate > troubleshooting for both sides. > > And yes, IPv6 is fully supported by every piece of our infrastructure; the > issue is TVs and STBs that do not support v6 - but we have finally seen the > largest device manufacturers commit to supporting it (if they don't already > on their late model sets) so that should change year over year. > > -Dave > > On Mon, Sep 17, 2018 at 11:52 PM Jared Mauch > wrote: > >> >> >> > On Sep 17, 2018, at 6:54 AM, Tom Ammon wrote: >> > >> > I'm looking to understand the impact of CG-NAT on a set of netflix >> OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that >> traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. >> Is this simply a matter of deploying the OCA on the outside of the CGN >> layer? What are the other consequences of CGN upon the OCA? >> > >> >> Yes, you want to deploy it outside your CG-NAT. >> >> I also strongly suggest you look at how to get native IPv6 from your >> clients behind the CG-NAT rolled out. I know many folks have had issues >> with various CDNs and the number of devices that reach out. This is why >> folks get the Google captcha, etc. >> >> Giving those end-users an alternate way out will help. I understand this >> may take effort and is harder for folks using UBNT & Tik gear in a smaller >> environment, but there is value for your end-users. >> >> - Jared >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From crussell at kanren.net Mon Nov 26 14:18:36 2018 From: crussell at kanren.net (Casey Russell) Date: Mon, 26 Nov 2018 08:18:36 -0600 Subject: Internet diameter? In-Reply-To: References: <9e0677d0b32dad4497d24af030293deb@mail.dessus.com> <20181125014731.C27B040605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: It's not exactly a measurement of "user to content" but CAIDA has swarms of Raspberry Pi nodes all over the world, that constantly measure... well, a lot of things, but they continually also monitor traceroute paths to each other. If you're looking for a "average length from any one node to any other node on the Internet" you'd likely find some good data points here. https://www.caida.org/projects/ark/statistics/ Sincerely, Casey Russell Network Engineer [image: KanREN] [image: phone]785-856-9809 2029 Becker Drive, Suite 282 Lawrence, Kansas 66047 [image: linkedin] [image: twitter] [image: twitter] need support? On Sun, Nov 25, 2018 at 11:10 AM Christopher Morrow wrote: > > > On Sat, Nov 24, 2018 at 8:48 PM Hal Murray < > hgm+nanog at ip-64-139-1-69.sjc.megapath.net> wrote: > >> >> Keith Medcalf said: >> > "just static content" would be more accurate ... >> >> and using http rather than https >> >> > There were many attempts at this by Johhny-cum-lately ISPs back in the >> 90's >> > -- particularly Telco and Cableco's -- with their "transparent poxies". >> > Eventually they discovered that it was more cost efficient to actually >> > provide the customer with what the customer had purchased. >> >> One of the complications in this area is an extra layer of logging which >> could >> turn into privacy invasion. >> >> I'm pretty sure it was Comcast, but a quick search didn't find a good >> reference. Many years ago, there were a lot of complaints when customers >> > > did you mean the 'sandvine experiment' that happened ~10 yrs back? > or did you mean the plan verizon had to proxy all http/https traffic from > consumer (fios/dsl) links through their gear so they could replace ad > content and such? > or did you mean the various (barefruit/nominim/paxfire) dns fake-answer > companies that dropped your customer on their "search platform" for > monetization? > > fairly much all of those are a wreck for consumer privacy :( > > >> discovered that their transparent proxy web site traffic was getting >> logged. >> Comcast said they weren't using it for anything beyond normal operations >> work, >> but nobody believed them. Shortly after that, they gave up on proxying. >> >> I'm sure the general reputation of modern Telcos and Cablecos for privacy >> invasion didn't help. >> >> > it's a rough business to be in, they say... but invading privacy of their > users makes things seem a heck of a lot worse. > > >> >> -- >> These are my opinions. I hate spam. >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhuffake at caida.org Thu Nov 22 01:21:22 2018 From: bhuffake at caida.org (Bradley Huffaker) Date: Thu, 22 Nov 2018 10:21:22 +0900 Subject: Internet diameter? In-Reply-To: References: Message-ID: <8383D5FC-D9C0-47FD-91BF-971CA7A3B022@caida.org> Hi William, We don’t have the number sitting around, but you can get a pretty good feel by clicking through a few of the ark monitors (http://www.caida.org/projects/ark/locations). Click on “data” to the right of each monitor. Bradley On Nov 22, 2018, at 7:55 AM, William Herrin wrote: > > > Hi folks, > > Does anybody have more or less recent data on the average, median and > maximum diameter (ip hop count) of the Internet? My google fu is > failing me: I've only found stuff from the '90s. > > Thanks, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From vaibhav.bajpai at tum.de Thu Nov 22 12:53:50 2018 From: vaibhav.bajpai at tum.de (Bajpai, Vaibhav) Date: Thu, 22 Nov 2018 12:53:50 +0000 Subject: Internet diameter? In-Reply-To: References: Message-ID: Hello, > Does anybody have more or less recent data on the average, median and > maximum diameter (ip hop count) of the Internet? My google fu is > failing me: I've only found stuff from the ‘90s. In the past 2 years of running `traceroute` towards YouTube from home networks, the maximum IP path length we have seen is around 22 IP hops. details, see: https://vaibhavbajpai.com/documents/papers/proceedings/youtube-traceroutes-commag-2018.pdf > Thanks, > Bill Herrin PS: This (path lengths) is only towards YouTube destinations. -- Vaibhav ------------------------------ Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Fellow Technische Universität München ------------------------------ From lprehn at inet.tu-berlin.de Thu Nov 22 13:17:51 2018 From: lprehn at inet.tu-berlin.de (Lars Prehn) Date: Thu, 22 Nov 2018 14:17:51 +0100 Subject: Internet diameter? In-Reply-To: <1542880547.21228510@apps.rackspace.com> References: <4310633A-9ED4-4E37-892E-D5837EBDFF8A@gvtc.com> <1542880547.21228510@apps.rackspace.com> Message-ID: Hi, >> Does anybody have more or less recent data on the average, median and maximum diameter (ip hop count) of the Internet? First, to give some hints regarding the initial question: A year ago I did some analysis based on Caida's routed /24 topology data set (https://www.caida.org/data/active/ipv4_routed_24_topology_dataset.xml) for data at the beginning of Jan. 2015. Its not using all available data but rather only traceroutes that reached the destination. The attached figure shows violin plots for each day - vertically, they show the distribution of Hopcounts (looks a little weird due to Hopcounts only beeing Integers). However, please keep in mind: i.) the data set is collected from only few physical locations but has traceroutes towards every routed /24 prefix. ii.) only a subset of the entire data set is shown. iii.) its from 2015. iv.) there is a good chance that it is not representative for the "entire" Internet. Secondly, regarding the ongoing discussion: +1 for Tim's answer. IMHO, neither AS paths nor IP paths, in general, are reliable proxies for e.g. latency or physical distance. In addition, keep in mind that we are only able to observe a certain part of the Internet and thus it's hard to make claims about the "entire" Internet. best regards, Lars Am 22.11.18 um 10:55 schrieb tim at pelican.org: > > On Thursday, 22 November, 2018 05:30, "William Herrin" > said: > > > Good question! It matters because a little over two decades ago we had > > some angst as equipment configured to emit a TTL of 32 stopped being > > able to reach everybody. Today we have a lot of equipment configured > > to emit a TTL of 64. It's the default in Linux, for example. Are we > > getting close to the limit where that will cause problems? How close? > > If it's hop-count that's interesting, I think that raises a question > on the potential for a sudden large change in the answer, potentially > with unforeseen consequences if we do have a lot of devices with TTL=64. > > Imagine a "tier-1" carrying some non-trivial fraction of Internet > traffic who is label-switching global table, with no TTL-propagation > into MPLS, and so looks like a single layer-3 hop today.  In response > to traceroute-whingeing, they turn on TTL-propagation, and suddenly > look like 10 layer-3 hops. > > Having been in the show/hide MPLS hops internal debate at more than > one employer, I'd expect flipping the switch to "show" to generate a > certain support load from people complaining that they are now "more > hops" away from something they care about (although RTT, packet-loss, > throughput remain exactly the same).  I wouldn't have expected to > break connectivity for a whole class of devices. > > Regards, > > Tim. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignactro at gmail.com Thu Nov 22 19:48:46 2018 From: ignactro at gmail.com (Ignacio de castro) Date: Thu, 22 Nov 2018 19:48:46 +0000 Subject: Internet diameter? In-Reply-To: <9e0677d0b32dad4497d24af030293deb@mail.dessus.com> References: <9e0677d0b32dad4497d24af030293deb@mail.dessus.com> Message-ID: It is indeed hard to say how useful is to know hop counts when a large fraction of IXP member are remote and plenty of content is cached, but that question was bugging me too and I have been looking into it. From what we could see, pretty stable around 5 hops. https://arxiv.org/abs/1810.10963 Disclaimer this is an ongoing work. Feedback welcome! On Thu, Nov 22, 2018 at 7:33 PM Keith Medcalf wrote: > >> I'd argue that's just content (though admittedly a lot of it). > > "just static content" would be more accurate ... > > >I would further argue that you can't cache active Web content, like > >bank account statements, utility billing, help desk request/responses, > >equipment status, and other things that change constantly. > > There were many attempts at this by Johhny-cum-lately ISPs back in the > 90's -- particularly Telco and Cableco's -- with their "transparent > poxies". Eventually they discovered that it was more cost efficient to > actually provide the customer with what the customer had purchased. > > --- > 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 Stephen > >Satchell > >Sent: Wednesday, 21 November, 2018 20:45 > >To: nanog at nanog.org > >Subject: Re: Internet diameter? > > > >On 11/21/2018 07:32 PM, Ross Tajvar wrote: > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dp at datasoftcomnet.com Sun Nov 25 12:12:48 2018 From: dp at datasoftcomnet.com (DurgaPrasad - DatasoftComnet) Date: Sun, 25 Nov 2018 17:42:48 +0530 Subject: NANOG Digest, Vol 130, Issue 23 In-Reply-To: References: Message-ID: <63D59749-4491-4F6E-B501-DFF07F52A943@datasoftcomnet.com> Hi, It's better to copy and take help of the IXP team where you are physically connected. Rgds/DP 9849111010 Sent from my iPhone. Pls excuse brevity and typos if any. > On 25-Nov-2018, at 5:30 PM, nanog-request at nanog.org wrote: > > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Amazon Peering (Mike Hammett) > 2. Re: Amazon Peering (Darin Steffl) > 3. Re: Amazon Peering (JASON BOTHE) > 4. RE: Internet diameter? (Hal Murray) > 5. DWDM forums (Ben Cannon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 24 Nov 2018 10:38:49 -0600 (CST) > From: Mike Hammett > To: Darin Steffl > Cc: North American Network Operators' Group > Subject: Re: Amazon Peering > Message-ID: > <1966321065.11280.1543077528570.JavaMail.mhammett at ThunderFuck> > Content-Type: text/plain; charset="utf-8" > > I've e-mailed my contacts there a couple times on people's behalf. No response yet. > > It seems like a lot of organizations need 1 more person in their peering departments. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Darin Steffl" > To: "North American Network Operators' Group" > Sent: Friday, November 23, 2018 10:21:51 PM > Subject: Amazon Peering > > > Hey all, > > > Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. > > > I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. > > > > > > -- > > > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Sat, 24 Nov 2018 10:59:21 -0600 > From: Darin Steffl > To: Mike Hammett > Cc: "North American Network Operators' Group" > Subject: Re: Amazon Peering > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > It seems wasteful for Amazon to connect to an IX but then ignore peering > requests for a year. > > They have 40G of connectivity but are unresponsive. I'll try emailing all > the other contacts listed in peeringdb. > > Thanks > >> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett > >> I've e-mailed my contacts there a couple times on people's behalf. No >> response yet. >> >> It seems like a lot of organizations need 1 more person in their peering >> departments. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ------------------------------ >> *From: *"Darin Steffl" >> *To: *"North American Network Operators' Group" >> *Sent: *Friday, November 23, 2018 10:21:51 PM >> *Subject: *Amazon Peering >> >> Hey all, >> >> Does anyone have a direct contact to get a peering session established >> with Amazon at an IX? I sent a peering request Dec 2017 and two more times >> this Sept and Nov with no response. >> >> I sent to peering at amazon.com and received one automated response back so >> I know they received my email but nothing since. >> >> >> >> -- >> Darin Steffl >> Minnesota WiFi >> www.mnwifi.com >> 507-634-WiFi >> Like us on Facebook >> >> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Sat, 24 Nov 2018 11:29:57 -0600 > From: JASON BOTHE > To: Darin Steffl > Cc: Mike Hammett , North American Network Operators' > Group > Subject: Re: Amazon Peering > Message-ID: > Content-Type: text/plain; charset="utf-8" > > This is a note I received on Oct18 when checking on a peering request submitted on Aug7.. > > “Apologies for the delays here. We have temporarily frozen IX peering as we revise some of our automation processes. I’m hopeful this will be unblocked by early November. Thank you for your continued patience.” > >> On Nov 24, 2018, at 10:59, Darin Steffl wrote: >> >> It seems wasteful for Amazon to connect to an IX but then ignore peering requests for a year. >> >> They have 40G of connectivity but are unresponsive. I'll try emailing all the other contacts listed in peeringdb. >> >> Thanks >> >>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >> I've e-mailed my contacts there a couple times on people's behalf. No response yet. >>> >>> It seems like a lot of organizations need 1 more person in their peering departments. >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> From: "Darin Steffl" >>> To: "North American Network Operators' Group" >>> Sent: Friday, November 23, 2018 10:21:51 PM >>> Subject: Amazon Peering >>> >>> Hey all, >>> >>> Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. >>> >>> I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. >>> >>> >>> >>> -- >>> Darin Steffl >>> Minnesota WiFi >>> www.mnwifi.com >>> 507-634-WiFi >>> Like us on Facebook >>> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 4 > Date: Sat, 24 Nov 2018 17:47:31 -0800 > From: Hal Murray > To: nanog at nanog.org > Cc: hgm+nanog at ip-64-139-1-69.sjc.megapath.net > Subject: RE: Internet diameter? > Message-ID: > <20181125014731.C27B040605C at ip-64-139-1-69.sjc.megapath.net> > Content-Type: text/plain; charset=us-ascii > > > Keith Medcalf said: >> "just static content" would be more accurate ... > > and using http rather than https > >> There were many attempts at this by Johhny-cum-lately ISPs back in the 90's >> -- particularly Telco and Cableco's -- with their "transparent poxies". >> Eventually they discovered that it was more cost efficient to actually >> provide the customer with what the customer had purchased. > > One of the complications in this area is an extra layer of logging which could > turn into privacy invasion. > > I'm pretty sure it was Comcast, but a quick search didn't find a good > reference. Many years ago, there were a lot of complaints when customers > discovered that their transparent proxy web site traffic was getting logged. > Comcast said they weren't using it for anything beyond normal operations work, > but nobody believed them. Shortly after that, they gave up on proxying. > > I'm sure the general reputation of modern Telcos and Cablecos for privacy > invasion didn't help. > > > -- > These are my opinions. I hate spam. > > > > > > ------------------------------ > > Message: 5 > Date: Sat, 24 Nov 2018 22:05:05 -0800 > From: Ben Cannon > To: nanog list > Subject: DWDM forums > Message-ID: <5C6667D7-0CF2-4801-840F-C67F213D1F04 at 6by7.net> > Content-Type: text/plain; charset=us-ascii > > Apologies for the noise, but can anyone recommend some DWDM or other glass/laser/amplifier communities or forums? There has to be a ton of overlap with this group. > -Ben. > > End of NANOG Digest, Vol 130, Issue 23 > ************************************** From liamomurchu at gmail.com Sun Nov 25 20:30:17 2018 From: liamomurchu at gmail.com (Liam Murphy) Date: Sun, 25 Nov 2018 20:30:17 +0000 Subject: 6PE on ALU Message-ID: <05BA9EF9-D35A-4043-A480-DFD237472E58@gmail.com> Hi, I am having the same issue …. was there ever a solution posted? Cheers, Liam. From mgehrmann at atlassian.com Sun Nov 25 22:45:21 2018 From: mgehrmann at atlassian.com (Michael Gehrmann) Date: Mon, 26 Nov 2018 09:45:21 +1100 Subject: RPKI publication In-Reply-To: <27692.24.166.32.244.1543024261.iglou@webmail.iglou.com> References: <55132.162.155.102.254.1542995499.iglou@webmail.iglou.com> <6E4775C8-0107-41C9-A9CB-8DE6706E161F@nlnetlabs.nl> <27692.24.166.32.244.1543024261.iglou@webmail.iglou.com> Message-ID: Hi Jeff, I've worked on getting routinator installed via ansible recently and had some success. Seems to be the most actively supported/developed rpki I have seen out of the 3 options. https://bitbucket.org/mjgehrmann/ansible-role-routinator Regards -- MiCHAEL On Sat, 24 Nov 2018 at 12:52, Jeff McAdams wrote: > On Fri, November 23, 2018 18:20, Christopher Morrow wrote: > > On Fri, Nov 23, 2018 at 6:12 PM Jeff McAdams wrote: > >> On November 23, 2018 4:48:14 PM EST, Christopher Morrow < > >> morrowc.lists at gmail.com> wrote: > >> > >>> I think there are 3 options: > >>> ripe validator v2 (potentially v3?) - > >>> https://github.com/RIPE-NCC/rpki-validator > >>> > >>> > >>> https://github.com/RIPE-NCC/rpki-validator-3 > >>> rpki.net validator - https://github.com/dragonresearch/rpki.net bbn > >>> rpstir - https://github.com/bgpsecurity/rpstir > >> > >> Like I said, validation and caching, "relying party", has several > >> options...several of which are relatively easy to run and manage. It's > >> the CA and publishing for which no really good options (that I've found, > >> at least) are available currently. > >> > > > > the ca bits do exist in rpki.net's software set... they are a tad fiddly > > to setup/run though, yes. > > Oops, sorry, I missed the rpki.net reference in there (I read and replied > to that message from my phone). > > Yes, I spent several hours trying to even get the Ubuntu 18.04 packages to > even install without errors. I'm not particularly keen on installing a 2 > 1/2 year old distro to run no-longer-supported version of the django > framework to support this, so I'm pretty much putting into the "not > reasonably current and maintained" category. > > -- > Jeff > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Mon Nov 26 15:16:31 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 26 Nov 2018 09:16:31 -0600 (CST) Subject: NANOG Digest, Vol 130, Issue 23 In-Reply-To: <63D59749-4491-4F6E-B501-DFF07F52A943@datasoftcomnet.com> References: <63D59749-4491-4F6E-B501-DFF07F52A943@datasoftcomnet.com> Message-ID: <1897026737.145.1543245387503.JavaMail.mhammett@ThunderFuck> As an IX operator, that doesn't always get you anywhere. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "DurgaPrasad - DatasoftComnet" To: nanog at nanog.org Sent: Sunday, November 25, 2018 6:12:48 AM Subject: Re: NANOG Digest, Vol 130, Issue 23 Hi, It's better to copy and take help of the IXP team where you are physically connected. Rgds/DP 9849111010 Sent from my iPhone. Pls excuse brevity and typos if any. > On 25-Nov-2018, at 5:30 PM, nanog-request at nanog.org wrote: > > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Amazon Peering (Mike Hammett) > 2. Re: Amazon Peering (Darin Steffl) > 3. Re: Amazon Peering (JASON BOTHE) > 4. RE: Internet diameter? (Hal Murray) > 5. DWDM forums (Ben Cannon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 24 Nov 2018 10:38:49 -0600 (CST) > From: Mike Hammett > To: Darin Steffl > Cc: North American Network Operators' Group > Subject: Re: Amazon Peering > Message-ID: > <1966321065.11280.1543077528570.JavaMail.mhammett at ThunderFuck> > Content-Type: text/plain; charset="utf-8" > > I've e-mailed my contacts there a couple times on people's behalf. No response yet. > > It seems like a lot of organizations need 1 more person in their peering departments. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Darin Steffl" > To: "North American Network Operators' Group" > Sent: Friday, November 23, 2018 10:21:51 PM > Subject: Amazon Peering > > > Hey all, > > > Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. > > > I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. > > > > > > -- > > > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Sat, 24 Nov 2018 10:59:21 -0600 > From: Darin Steffl > To: Mike Hammett > Cc: "North American Network Operators' Group" > Subject: Re: Amazon Peering > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > It seems wasteful for Amazon to connect to an IX but then ignore peering > requests for a year. > > They have 40G of connectivity but are unresponsive. I'll try emailing all > the other contacts listed in peeringdb. > > Thanks > >> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett > >> I've e-mailed my contacts there a couple times on people's behalf. No >> response yet. >> >> It seems like a lot of organizations need 1 more person in their peering >> departments. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ------------------------------ >> *From: *"Darin Steffl" >> *To: *"North American Network Operators' Group" >> *Sent: *Friday, November 23, 2018 10:21:51 PM >> *Subject: *Amazon Peering >> >> Hey all, >> >> Does anyone have a direct contact to get a peering session established >> with Amazon at an IX? I sent a peering request Dec 2017 and two more times >> this Sept and Nov with no response. >> >> I sent to peering at amazon.com and received one automated response back so >> I know they received my email but nothing since. >> >> >> >> -- >> Darin Steffl >> Minnesota WiFi >> www.mnwifi.com >> 507-634-WiFi >> Like us on Facebook >> >> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Sat, 24 Nov 2018 11:29:57 -0600 > From: JASON BOTHE > To: Darin Steffl > Cc: Mike Hammett , North American Network Operators' > Group > Subject: Re: Amazon Peering > Message-ID: > Content-Type: text/plain; charset="utf-8" > > This is a note I received on Oct18 when checking on a peering request submitted on Aug7.. > > “Apologies for the delays here. We have temporarily frozen IX peering as we revise some of our automation processes. I’m hopeful this will be unblocked by early November. Thank you for your continued patience.” > >> On Nov 24, 2018, at 10:59, Darin Steffl wrote: >> >> It seems wasteful for Amazon to connect to an IX but then ignore peering requests for a year. >> >> They have 40G of connectivity but are unresponsive. I'll try emailing all the other contacts listed in peeringdb. >> >> Thanks >> >>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >> I've e-mailed my contacts there a couple times on people's behalf. No response yet. >>> >>> It seems like a lot of organizations need 1 more person in their peering departments. >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> From: "Darin Steffl" >>> To: "North American Network Operators' Group" >>> Sent: Friday, November 23, 2018 10:21:51 PM >>> Subject: Amazon Peering >>> >>> Hey all, >>> >>> Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. >>> >>> I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. >>> >>> >>> >>> -- >>> Darin Steffl >>> Minnesota WiFi >>> www.mnwifi.com >>> 507-634-WiFi >>> Like us on Facebook >>> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 4 > Date: Sat, 24 Nov 2018 17:47:31 -0800 > From: Hal Murray > To: nanog at nanog.org > Cc: hgm+nanog at ip-64-139-1-69.sjc.megapath.net > Subject: RE: Internet diameter? > Message-ID: > <20181125014731.C27B040605C at ip-64-139-1-69.sjc.megapath.net> > Content-Type: text/plain; charset=us-ascii > > > Keith Medcalf said: >> "just static content" would be more accurate ... > > and using http rather than https > >> There were many attempts at this by Johhny-cum-lately ISPs back in the 90's >> -- particularly Telco and Cableco's -- with their "transparent poxies". >> Eventually they discovered that it was more cost efficient to actually >> provide the customer with what the customer had purchased. > > One of the complications in this area is an extra layer of logging which could > turn into privacy invasion. > > I'm pretty sure it was Comcast, but a quick search didn't find a good > reference. Many years ago, there were a lot of complaints when customers > discovered that their transparent proxy web site traffic was getting logged. > Comcast said they weren't using it for anything beyond normal operations work, > but nobody believed them. Shortly after that, they gave up on proxying. > > I'm sure the general reputation of modern Telcos and Cablecos for privacy > invasion didn't help. > > > -- > These are my opinions. I hate spam. > > > > > > ------------------------------ > > Message: 5 > Date: Sat, 24 Nov 2018 22:05:05 -0800 > From: Ben Cannon > To: nanog list > Subject: DWDM forums > Message-ID: <5C6667D7-0CF2-4801-840F-C67F213D1F04 at 6by7.net> > Content-Type: text/plain; charset=us-ascii > > Apologies for the noise, but can anyone recommend some DWDM or other glass/laser/amplifier communities or forums? There has to be a ton of overlap with this group. > -Ben. > > End of NANOG Digest, Vol 130, Issue 23 > ************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Mon Nov 26 18:28:32 2018 From: john at essenz.com (John Von Essen) Date: Mon, 26 Nov 2018 13:28:32 -0500 Subject: CrownCastle/Lightower/Fibertech peering... Message-ID: <0fede8be-6754-78fc-d163-e8231094854b@essenz.com> Anyone on the list or no someone at CrownCastle AS46887 for peering relationships? They dont have anything listed on peeringdb.com. Thanks John From nanog at ics-il.net Mon Nov 26 18:46:36 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 26 Nov 2018 12:46:36 -0600 (CST) Subject: CrownCastle/Lightower/Fibertech peering... In-Reply-To: <0fede8be-6754-78fc-d163-e8231094854b@essenz.com> References: <0fede8be-6754-78fc-d163-e8231094854b@essenz.com> Message-ID: <703459256.561.1543257995786.JavaMail.mhammett@ThunderFuck> We've been working them to get them to join our IX. As Crown itself is mostly looking at the network as dark fiber to the tower, I wonder how long it'll be before the transit is sold to someone else. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "John Von Essen" To: nanog at nanog.org Sent: Monday, November 26, 2018 12:28:32 PM Subject: CrownCastle/Lightower/Fibertech peering... Anyone on the list or no someone at CrownCastle AS46887 for peering relationships? They dont have anything listed on peeringdb.com. Thanks John -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeroen.Wunnink at gtt.net Mon Nov 26 19:02:21 2018 From: Jeroen.Wunnink at gtt.net (Jeroen Wunnink) Date: Mon, 26 Nov 2018 19:02:21 +0000 Subject: Contractor in Sydney - Australia area for RFC/loop tests Message-ID: <043708e466844c009813dab07e4999e9@gtt.net> Can anyone recommend a contractor in the Australia - Sydney area that can do some line tests, so RFC, loop and power measurements at a local datacenter at fairly short notice? Our NOC is a bit in a tight spot and is looking for options. Jeroen Wunnink Sr. Manager - Integration Engineering www.gtt.net [id:image001.png at 01D37331.D1301F60] -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Mon Nov 26 19:46:02 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 26 Nov 2018 12:46:02 -0700 Subject: netflix OCA in a CG-NAT world In-Reply-To: References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> Message-ID: <7b8b7321-b2ef-312c-cedd-b80a4d179e96@spamtrap.tnetconsulting.net> On 11/25/2018 09:47 PM, Dave Temkin wrote: > Putting an OCA with bypass through the CGN with RFC1918 space will > actually work just fine. We (Netflix) don't formally support it because > of the vast number of non-standard CGN implementations out there, but if > your clients are in RFC1918 space and the next hop router from the OCA > knows how to reach them, it will just work. Does this include RFC 6598 Shared Address Space, 100.64.0.0/10? Or is it limited to RFC 1918 Address Space? Does it really matter what the private IPs are? (I've seen people re-use publicly allocated but not publicly used IP address space.) Or does it "just work" as long as the OCA's first hop knows how to reach the private IPs? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From dave at temk.in Mon Nov 26 20:57:06 2018 From: dave at temk.in (Dave Temkin) Date: Tue, 27 Nov 2018 04:57:06 +0800 Subject: netflix OCA in a CG-NAT world In-Reply-To: <7b8b7321-b2ef-312c-cedd-b80a4d179e96@spamtrap.tnetconsulting.net> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <7b8b7321-b2ef-312c-cedd-b80a4d179e96@spamtrap.tnetconsulting.net> Message-ID: On Tue, Nov 27, 2018 at 3:48 AM Grant Taylor via NANOG wrote: > On 11/25/2018 09:47 PM, Dave Temkin wrote: > > Putting an OCA with bypass through the CGN with RFC1918 space will > > actually work just fine. We (Netflix) don't formally support it because > > of the vast number of non-standard CGN implementations out there, but if > > your clients are in RFC1918 space and the next hop router from the OCA > > knows how to reach them, it will just work. > > Does this include RFC 6598 Shared Address Space, 100.64.0.0/10? Or is > it limited to RFC 1918 Address Space? > > Does it really matter what the private IPs are? (I've seen people > re-use publicly allocated but not publicly used IP address space.) Or > does it "just work" as long as the OCA's first hop knows how to reach > the private IPs? > > > The latter. -Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Mon Nov 26 22:04:06 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 26 Nov 2018 14:04:06 -0800 Subject: =?utf-8?B?UmU6IENoaW5hIOKAmXMgTWF4aW0g4oCTIExlYXZlIE5vIEFjY2VzcyBQb2ludCBVbmV4?= =?utf-8?B?cGxvaXRlZDogVGhlIEhpZGRlbiBTdG9yeSBvZiBDaGluYSBUZWxlY29t4oCZIHMgQg==?= =?utf-8?B?R1AgSGlqYWNraW5n?= Message-ID: <20181126140406.100450AC@m0117568.ppops.net> China Telecom's response: "The content of these reports was lack of factual evidence. The conclusion was ungrounded. Also, it did not match with the current status and technical principles of global Internet operation." http://www.irasia.com/listco/hk/chinatelecom/press/p181122.htm scott From jeremy at eff.org Tue Nov 27 00:00:58 2018 From: jeremy at eff.org (Jeremy Gillula) Date: Mon, 26 Nov 2018 16:00:58 -0800 Subject: Measurements of Internet traffic by protocol? Message-ID: Hi all, Are there statistics out there for the relative "popularity" of different application-layer protocols by network traffic (i.e. HTTP(S) vs SMTP(S) vs other protocols)? I realize it will be different from different vantage points (e.g. a transit provider vs a small residential ISP), but we'd love to find *any* sources of hard numbers out there. I've tried to search for data, but the best I could come up with is at least ten years out of date. Thanks in advance! -- | Jeremy Gillula, Ph.D. | Tech Projects Director | Electronic Frontier Foundation | (415) 436-9333 x158 | jeremy at eff.org | @the_zeroth_law | Want to support EFF? Donate! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Nov 27 04:07:59 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 26 Nov 2018 20:07:59 -0800 Subject: VPS/Gaming companies with backbone Message-ID: hi there, I do not know which gaming companies have backbone and which do not. I am trying to find a way to automate the https://dev.networkatlas.org backbone link up/down information using some gaming servers (i guess i am playing too much games nowadays as I came up with this idea) currently the model https://dev.networkatlas.org is following is basically crowd-sourced data input similar to wikipedia model where if a link is down, a user goes and reports that and once verified by a trusted member (editor/admin/ambassador whatever you wanna call the trusted source) the link changes. We are trying to think out of the box on how we can possible automate this. if you have any ideas beside telecom giants to share this information via email , let me know. If you are network admin/engineer/architect in a gaming company please ping me offline and see how this could be automated with a script running on multiple gaming servers. (can think out of the box , but not out of xbox apparently) thank you :) Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Tue Nov 27 05:11:37 2018 From: geier at geier.ne.tz (Frank Habicht) Date: Tue, 27 Nov 2018 08:11:37 +0300 Subject: =?UTF-8?Q?Re=3a_China_=e2=80=99s_Maxim_=e2=80=93_Leave_No_Access_Po?= =?UTF-8?Q?int_Unexploited=3a_The_Hidden_Story_of_China_Telecom=e2=80=99_s_B?= =?UTF-8?Q?GP_Hijacking?= In-Reply-To: <20181126140406.100450AC@m0117568.ppops.net> References: <20181126140406.100450AC@m0117568.ppops.net> Message-ID: On 27/11/2018 01:04, Scott Weeks wrote: > China Telecom's response: > ... > http://www.irasia.com/listco/hk/chinatelecom/press/p181122.htm They forgot to mention that it's technically possible to filter advertisements from their customer. Which apparently they were/are not really doing. So much for "working together for the healthy and orderly development of global Internet"... Not saying they get more blame than MainOne, but also not less. Frank From alfie at fdx.services Tue Nov 27 09:08:50 2018 From: alfie at fdx.services (Alfie Pates) Date: Tue, 27 Nov 2018 09:08:50 +0000 Subject: VPS/Gaming companies with backbone In-Reply-To: References: Message-ID: <1543309730.65648.1590164112.71808749@webmail.messagingengine.com> I would be hesitant to include this kind of information if you don't have a plan for keeping it recent and accurate - there's a real risk your data will become stale quickly, at which point it stops being useful to people. Perhaps ask providers if you can subscribe to those, and automatically parse their emails? Easier said than done, but it does provide much more useful information than "hearsay"/pinging some server you do not control that may or may not be on the other end of a specific link. -A On Tue, Nov 27, 2018, at 4:07 AM, Mehmet Akcin wrote: > hi there, > > I do not know which gaming companies have backbone and which do not. I > am trying to find a way to automate the https://dev.networkatlas.org > backbone link up/down information using some gaming servers (i guess i > am playing too much games nowadays as I came up with this idea)> > currently the model https://dev.networkatlas.org[1] is following is > basically crowd-sourced data input similar to wikipedia model where if > a link is down, a user goes and reports that and once verified by a > trusted member (editor/admin/ambassador whatever you wanna call the > trusted source) the link changes. We are trying to think out of the > box on how we can possible automate this.> > if you have any ideas beside telecom giants to share this information > via email , let me know. If you are network admin/engineer/architect > in a gaming company please ping me offline and see how this could be > automated with a script running on multiple gaming servers.> > (can think out of the box , but not out of xbox apparently) > > thank you :) > > Mehmet Links: 1. https://dev.networkatlas.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Nov 27 09:20:14 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 27 Nov 2018 01:20:14 -0800 Subject: VPS/Gaming companies with backbone In-Reply-To: <1543309730.65648.1590164112.71808749@webmail.messagingengine.com> References: <1543309730.65648.1590164112.71808749@webmail.messagingengine.com> Message-ID: I know the risk of having stale data. that is why I am trying to really focus on first enabling crowd sourcing abilities and then parsing emails, tweets, etc. Providers will most likely not want to share their outages due ti “bad marketing reasons” but you are right some might On Tue, Nov 27, 2018 at 1:09 AM Alfie Pates wrote: > I would be hesitant to include this kind of information if you don't have > a plan for keeping it recent and accurate - there's a real risk your data > will become stale quickly, at which point it stops being useful to people. > > Perhaps ask providers if you can subscribe to those, and automatically > parse their emails? Easier said than done, but it does provide much more > useful information than "hearsay"/pinging some server you do not control > that may or may not be on the other end of a specific link. > > > -A > > > On Tue, Nov 27, 2018, at 4:07 AM, Mehmet Akcin wrote: > > hi there, > > I do not know which gaming companies have backbone and which do not. I am > trying to find a way to automate the https://dev.networkatlas.org backbone > link up/down information using some gaming servers (i guess i am playing > too much games nowadays as I came up with this idea) > > currently the model https://dev.networkatlas.org is following is > basically crowd-sourced data input similar to wikipedia model where if a > link is down, a user goes and reports that and once verified by a trusted > member (editor/admin/ambassador whatever you wanna call the trusted source) > the link changes. We are trying to think out of the box on how we can > possible automate this. > > if you have any ideas beside telecom giants to share this information via > email , let me know. If you are network admin/engineer/architect in a > gaming company please ping me offline and see how this could be automated > with a script running on multiple gaming servers. > > (can think out of the box , but not out of xbox apparently) > > thank you :) > > Mehmet > > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed Nov 28 01:37:47 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 27 Nov 2018 17:37:47 -0800 Subject: Most peered AS per country Message-ID: Hello there, http://as-rank.caida.org/ is impressively showing ranking of ISPs and how well peered they are and I love this. Is there any research / page similar to this which shows similar data but per country basis breakdown instead of showing globally? thanks in advance for your help Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Wed Nov 28 01:40:56 2018 From: woody at pch.net (Bill Woodcock) Date: Wed, 28 Nov 2018 10:40:56 +0900 Subject: Most peered AS per country In-Reply-To: References: Message-ID: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> > On Nov 28, 2018, at 10:37 AM, Mehmet Akcin wrote: > http://as-rank.caida.org/ is impressively showing ranking of ISPs and how well peered they are No, it’s by how many customers they have. "ASes and Orgs are ranked by their customer cone size, which is the number of their direct and indirect customers.” Nothing to do with their peering. -Bill From mehmet at akcin.net Wed Nov 28 01:42:45 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 27 Nov 2018 17:42:45 -0800 Subject: Most peered AS per country In-Reply-To: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> Message-ID: Sorry what i meant with peering, their total as peer/customer count. I should have worded it correctly thanks Woody. Question still exists, is there any similar data set available per country basis? Mehmet On Tue, Nov 27, 2018 at 5:41 PM Bill Woodcock wrote: > > > > On Nov 28, 2018, at 10:37 AM, Mehmet Akcin wrote: > > http://as-rank.caida.org/ is impressively showing ranking of ISPs and > how well peered they are > > No, it’s by how many customers they have. > > "ASes and Orgs are ranked by their customer cone size, which is the number > of their direct and indirect customers.” > > Nothing to do with their peering. > > -Bill > > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Wed Nov 28 01:48:32 2018 From: woody at pch.net (Bill Woodcock) Date: Wed, 28 Nov 2018 10:48:32 +0900 Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> Message-ID: <890C598D-EB7D-4C19-B0C1-C9686C4E54C5@pch.net> > On Nov 28, 2018, at 10:42 AM, Mehmet Akcin wrote: > > Sorry what i meant with peering, their total as peer/customer count. I should have worded it correctly thanks Woody. > > Question still exists, is there any similar data set available per country basis? You want to know how big the per-country customer cones for each AS are? Like, for a given country, what AS has the most down-stream networks within that country? We used to generate those stats, but the code has probably broken long ago. We did it because we had bulk data agreements with all five RIRs, so we had the ASes databased by country-code. We still have that part up-to-date. -Bill From mehmet at akcin.net Wed Nov 28 01:56:34 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 27 Nov 2018 17:56:34 -0800 Subject: Most peered AS per country In-Reply-To: <890C598D-EB7D-4C19-B0C1-C9686C4E54C5@pch.net> References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> <890C598D-EB7D-4C19-B0C1-C9686C4E54C5@pch.net> Message-ID: Hi Bill I am just trying to see if there is some way to rank transit providers by the amount of peering+customers they have in a country. I am noticing provider A enters market X saying they are tier 1 network but they do not have a si ngle peering session in country and they backhaul everything back to market Z where they deliver traffic to the peer via high latency and low performance method. This is causing market to receive pricing targets which are unrealistic and hurting telecoms who are genuinely trying to do right thing and establish in country direct peering with peers. I would like to be able to see top 10 networks (top 10 as in adjutancies) a country which has most amount of routes they are advertising. bgp.he.net seems like a good place to see this info. Is there a way to get this data in a format which I can compile reports Rob? (Excel friendly format would be great) Mehmet On Tue, Nov 27, 2018 at 5:48 PM Bill Woodcock wrote: > > > > On Nov 28, 2018, at 10:42 AM, Mehmet Akcin wrote: > > > > Sorry what i meant with peering, their total as peer/customer count. I > should have worded it correctly thanks Woody. > > > > Question still exists, is there any similar data set available per > country basis? > > You want to know how big the per-country customer cones for each AS are? > Like, for a given country, what AS has the most down-stream networks within > that country? We used to generate those stats, but the code has probably > broken long ago. > > We did it because we had bulk data agreements with all five RIRs, so we > had the ASes databased by country-code. We still have that part up-to-date. > > -Bill > > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhuffake at caida.org Wed Nov 28 03:01:04 2018 From: bhuffake at caida.org (Bradley Huffaker) Date: Wed, 28 Nov 2018 12:01:04 +0900 Subject: Most peered AS per country In-Reply-To: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> Message-ID: Bill is correct. AS Rank’s ranks by customer cone, not peers. Although you can get an ASN’s list of peers. We are currently working on adding country level ranking to AS Rank, but will not have it ready until next year. Bradley > On Nov 28, 2018, at 10:40 AM, Bill Woodcock wrote: >> On Nov 28, 2018, at 10:37 AM, Mehmet Akcin wrote: >> http://as-rank.caida.org/ is impressively showing ranking of ISPs and how well peered they are > > No, it’s by how many customers they have. > > "ASes and Orgs are ranked by their customer cone size, which is the number of their direct and indirect customers.” > > Nothing to do with their peering. > > -Bill > > From mehmet at akcin.net Wed Nov 28 03:03:56 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 27 Nov 2018 19:03:56 -0800 Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> Message-ID: thank you. I am actually trying to see following, https://bgp.he.net/country/AU looking at this, and ranking list by amount of prefixes announced. I can see top 10 networks with amount of prefixes announced in AU, I assume these are the networks with most potential to generate traffic and these are eyeball networks. I would like to know if there is a way to see a transit provider's ASN ,let's say AS1 , and how AS1 is connecting to top 10 networks with amount of prefixes announced in Australia. is this something you are working on ? On Tue, Nov 27, 2018 at 7:01 PM Bradley Huffaker wrote: > Bill is correct. AS Rank’s ranks by customer cone, not peers. Although you > can get an ASN’s list of peers. We are currently working on adding country > level ranking to AS Rank, but will not have it ready until next year. > > Bradley > > > On Nov 28, 2018, at 10:40 AM, Bill Woodcock wrote: > >> On Nov 28, 2018, at 10:37 AM, Mehmet Akcin wrote: > >> http://as-rank.caida.org/ is impressively showing ranking of ISPs and > how well peered they are > > > > No, it’s by how many customers they have. > > > > "ASes and Orgs are ranked by their customer cone size, which is the > number of their direct and indirect customers.” > > > > Nothing to do with their peering. > > > > -Bill > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Nov 28 04:02:14 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 27 Nov 2018 22:02:14 -0600 (CST) Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> <890C598D-EB7D-4C19-B0C1-C9686C4E54C5@pch.net> Message-ID: <39124053.1696.1543377733952.JavaMail.mhammett@ThunderFuck> Renesys used to have a blog that went into that a bit, but I think Oracle killed it off. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mehmet Akcin" To: "Bill Woodcock" Cc: "nanog" Sent: Tuesday, November 27, 2018 7:56:34 PM Subject: Re: Most peered AS per country Hi Bill I am just trying to see if there is some way to rank transit providers by the amount of peering+customers they have in a country. I am noticing provider A enters market X saying they are tier 1 network but they do not have a si ngle peering session in country and they backhaul everything back to market Z where they deliver traffic to the peer via high latency and low performance method. This is causing market to receive pricing targets which are unrealistic and hurting telecoms who are genuinely trying to do right thing and establish in country direct peering with peers. I would like to be able to see top 10 networks (top 10 as in adjutancies) a country which has most amount of routes they are advertising. bgp.he.net seems like a good place to see this info. Is there a way to get this data in a format which I can compile reports Rob? (Excel friendly format would be great) Mehmet On Tue, Nov 27, 2018 at 5:48 PM Bill Woodcock < woody at pch.net > wrote: > On Nov 28, 2018, at 10:42 AM, Mehmet Akcin < mehmet at akcin.net > wrote: > > Sorry what i meant with peering, their total as peer/customer count. I should have worded it correctly thanks Woody. > > Question still exists, is there any similar data set available per country basis? You want to know how big the per-country customer cones for each AS are? Like, for a given country, what AS has the most down-stream networks within that country? We used to generate those stats, but the code has probably broken long ago. We did it because we had bulk data agreements with all five RIRs, so we had the ASes databased by country-code. We still have that part up-to-date. -Bill -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed Nov 28 06:27:49 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 28 Nov 2018 08:27:49 +0200 Subject: netflix OCA in a CG-NAT world In-Reply-To: References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> Message-ID: <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> On 26/Nov/18 06:47, Dave Temkin wrote: > > And yes, IPv6 is fully supported by every piece of our infrastructure; > the issue is TVs and STBs that do not support v6 - but we have finally > seen the largest device manufacturers commit to supporting it (if they > don't already on their late model sets) so that should change year > over year. Funny you should mention this... my Sony TV from 2014 has IPv6 support:     https://www.youtube.com/watch?v=la9G3bF6rYU    But I watch my Netflix on my Apple TV 4, PS4 and PS3, all of which don't currently support IPv6 in 2018 :-(... Mark. From mark.tinka at seacom.mu Wed Nov 28 06:31:24 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 28 Nov 2018 08:31:24 +0200 Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> <890C598D-EB7D-4C19-B0C1-C9686C4E54C5@pch.net> Message-ID: <1e15c809-61a9-dd88-738e-66e10d7c2199@seacom.mu> On 28/Nov/18 03:56, Mehmet Akcin wrote: > I am noticing provider A enters market X saying they are tier 1 > network but they do not have a si ngle peering session in country and > they backhaul everything back to market Z where they deliver traffic > to the peer via high latency and low performance method. This is > causing market to receive pricing targets which are unrealistic and > hurting telecoms who are genuinely trying to do right thing and > establish in country direct peering with peers. In my experience, the market quickly tends to correct itself once the fizz dies out and reality hits. Typical time span has been about 12 months. Mark. From bhuffake at caida.org Wed Nov 28 07:32:15 2018 From: bhuffake at caida.org (Bradley Huffaker) Date: Wed, 28 Nov 2018 16:32:15 +0900 Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> Message-ID: <470F67EB-3DDB-40B9-BB94-3A241CDCA7D5@caida.org> > On Nov 28, 2018, at 12:03 PM, Mehmet Akcin wrote: > > I would like to know if there is a way to see a transit provider's ASN ,let's say AS1 , and how AS1 is connecting to top 10 networks with amount of prefixes announced in Australia. is this something you are working on ? We are going to be providing a country view. This will provide a customer cone size and ranking for each AS using the AS paths to the country’s address space. So you will be able to view AS1’s neighbors ranked by the customer cone in that given region. We will not be providing an individual link break down. Bradley From baldur.norddahl at gmail.com Wed Nov 28 11:34:05 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 28 Nov 2018 12:34:05 +0100 Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> Message-ID: The number of peers appears to be unreliable. My network is listed with 14 peers but the actual number is much higher. Regards Baldur ons. 28. nov. 2018 04.02 skrev Bradley Huffaker : > Bill is correct. AS Rank’s ranks by customer cone, not peers. Although you > can get an ASN’s list of peers. We are currently working on adding country > level ranking to AS Rank, but will not have it ready until next year. > > Bradley > > > On Nov 28, 2018, at 10:40 AM, Bill Woodcock wrote: > >> On Nov 28, 2018, at 10:37 AM, Mehmet Akcin wrote: > >> http://as-rank.caida.org/ is impressively showing ranking of ISPs and > how well peered they are > > > > No, it’s by how many customers they have. > > > > "ASes and Orgs are ranked by their customer cone size, which is the > number of their direct and indirect customers.” > > > > Nothing to do with their peering. > > > > -Bill > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shopik+lists at nvcube.net Wed Nov 28 11:37:06 2018 From: shopik+lists at nvcube.net (Nikolay Shopik) Date: Wed, 28 Nov 2018 14:37:06 +0300 Subject: netflix OCA in a CG-NAT world In-Reply-To: <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> Message-ID: <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> Sony Entertainment is know to be slowpoke in this area. PS4 firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and thus apps doesn't use it at all. Are you sure about ATV4 netflix app? Support is there and I've seen traffic from it when recently did tcpdump from ATV4. On 28/11/18 9:27 am, Mark Tinka wrote: > But I watch my Netflix on my Apple TV 4, PS4 and PS3, all of which don't > currently support IPv6 in 2018 :-(... From tore at fud.no Wed Nov 28 12:37:20 2018 From: tore at fud.no (Tore Anderson) Date: Wed, 28 Nov 2018 13:37:20 +0100 Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> <890C598D-EB7D-4C19-B0C1-C9686C4E54C5@pch.net> Message-ID: * Mehmet Akcin > I am noticing provider A enters market X saying they are tier 1 network but they do not have a si ngle peering session in country and they backhaul everything back to market Z where they deliver traffic to the peer via high latency and low performance method. This is causing market to receive pricing targets which are unrealistic and hurting telecoms who are genuinely trying to do right thing and establish in country direct peering with peers. Yeah, don't fall for the marketing hyperbole. A transit provider's «tier» is an extremely poor indicator of its interconnectedness and quality, especially if your traffic is regional in nature. In most cases you'll be much better off buying your IP transit from a regional «tier-2» provider, which tends to give you much better connectivity to other networks in your region - in addition to all the global connectivity that the «tier-2»'s upstream(s) provide, of course. Tore From alessandro.improta at iit.cnr.it Wed Nov 28 12:56:25 2018 From: alessandro.improta at iit.cnr.it (alessandro.improta at iit.cnr.it) Date: Wed, 28 Nov 2018 13:56:25 +0100 Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> Message-ID: <6310c1a6aedd39a4ba5a550b2c2b7665@iit.cnr.it> Hello Baldur, if I'm not wrong, CAIDA are using Route Views and RIPE NCC RIS as data sources. If your AS (or any ASes in your customer cone) is not feeding any BGP route collector, your peers will never appear in their rank. Some of your peers may be seen if any of your peers are connected to a route collector though. Data available is extremely incomplete from that point of view... If you wish to have more reliable data from BGP analyzers using public data, I suggest you to join a collector. I run one of them (Isolario), if you need any more details about that (or about the data incompleteness) just drop me a mail! Best regards, Alessandro Improta IIT-CNR - Isolario project (www.isolario.it) Il 2018-11-28 12:34 Baldur Norddahl ha scritto: > The number of peers appears to be unreliable. My network is listed > with 14 peers but the actual number is much higher. > > Regards > Baldur > > ons. 28. nov. 2018 04.02 skrev Bradley Huffaker : > >> Bill is correct. AS Rank’s ranks by customer cone, not peers. >> Although you can get an ASN’s list of peers. We are currently >> working on adding country level ranking to AS Rank, but will not >> have it ready until next year. >> >> Bradley >> >>> On Nov 28, 2018, at 10:40 AM, Bill Woodcock wrote: >>>> On Nov 28, 2018, at 10:37 AM, Mehmet Akcin >> wrote: >>>> http://as-rank.caida.org/ is impressively showing ranking of ISPs >> and how well peered they are >>> >>> No, it’s by how many customers they have. >>> >>> "ASes and Orgs are ranked by their customer cone size, which is >> the number of their direct and indirect customers.” >>> >>> Nothing to do with their peering. >>> >>> -Bill >>> >>> From valdis.kletnieks at vt.edu Wed Nov 28 13:41:17 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 28 Nov 2018 08:41:17 -0500 Subject: netflix OCA in a CG-NAT world In-Reply-To: <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> Message-ID: <11326.1543412477@turing-police.cc.vt.edu> On Wed, 28 Nov 2018 14:37:06 +0300, Nikolay Shopik said: > Sony Entertainment is know to be slowpoke in this area. PS4 > firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and > thus apps doesn't use it at all. Odd. Mine does DHCPv6. It might do SLAC as well, my OpenWRT wouldn't notice an unused SLAC address.. -------------- 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 ics-il.net Wed Nov 28 13:56:03 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 28 Nov 2018 07:56:03 -0600 (CST) Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> Message-ID: <390366590.2071.1543413360398.JavaMail.mhammett@ThunderFuck> Peer with a Route-Views server somewhere. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Wednesday, November 28, 2018 5:34:05 AM Subject: Re: Most peered AS per country The number of peers appears to be unreliable. My network is listed with 14 peers but the actual number is much higher. Regards Baldur ons. 28. nov. 2018 04.02 skrev Bradley Huffaker < bhuffake at caida.org >: Bill is correct. AS Rank’s ranks by customer cone, not peers. Although you can get an ASN’s list of peers. We are currently working on adding country level ranking to AS Rank, but will not have it ready until next year. Bradley > On Nov 28, 2018, at 10:40 AM, Bill Woodcock < woody at pch.net > wrote: >> On Nov 28, 2018, at 10:37 AM, Mehmet Akcin < mehmet at akcin.net > wrote: >> http://as-rank.caida.org/ is impressively showing ranking of ISPs and how well peered they are > > No, it’s by how many customers they have. > > "ASes and Orgs are ranked by their customer cone size, which is the number of their direct and indirect customers.” > > Nothing to do with their peering. > > -Bill > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Nov 28 13:58:33 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 28 Nov 2018 07:58:33 -0600 (CST) Subject: Most peered AS per country In-Reply-To: <6310c1a6aedd39a4ba5a550b2c2b7665@iit.cnr.it> References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> <6310c1a6aedd39a4ba5a550b2c2b7665@iit.cnr.it> Message-ID: <770978027.2077.1543413509775.JavaMail.mhammett@ThunderFuck> Do CAIDA or similar major projects pull data from your project? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "alessandro improta" To: "Baldur Norddahl" Cc: nanog at nanog.org Sent: Wednesday, November 28, 2018 6:56:25 AM Subject: Re: Most peered AS per country Hello Baldur, if I'm not wrong, CAIDA are using Route Views and RIPE NCC RIS as data sources. If your AS (or any ASes in your customer cone) is not feeding any BGP route collector, your peers will never appear in their rank. Some of your peers may be seen if any of your peers are connected to a route collector though. Data available is extremely incomplete from that point of view... If you wish to have more reliable data from BGP analyzers using public data, I suggest you to join a collector. I run one of them (Isolario), if you need any more details about that (or about the data incompleteness) just drop me a mail! Best regards, Alessandro Improta IIT-CNR - Isolario project (www.isolario.it) Il 2018-11-28 12:34 Baldur Norddahl ha scritto: > The number of peers appears to be unreliable. My network is listed > with 14 peers but the actual number is much higher. > > Regards > Baldur > > ons. 28. nov. 2018 04.02 skrev Bradley Huffaker : > >> Bill is correct. AS Rank’s ranks by customer cone, not peers. >> Although you can get an ASN’s list of peers. We are currently >> working on adding country level ranking to AS Rank, but will not >> have it ready until next year. >> >> Bradley >> >>> On Nov 28, 2018, at 10:40 AM, Bill Woodcock wrote: >>>> On Nov 28, 2018, at 10:37 AM, Mehmet Akcin >> wrote: >>>> http://as-rank.caida.org/ is impressively showing ranking of ISPs >> and how well peered they are >>> >>> No, it’s by how many customers they have. >>> >>> "ASes and Orgs are ranked by their customer cone size, which is >> the number of their direct and indirect customers.” >>> >>> Nothing to do with their peering. >>> >>> -Bill >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.improta at iit.cnr.it Wed Nov 28 14:07:45 2018 From: alessandro.improta at iit.cnr.it (alessandro.improta at iit.cnr.it) Date: Wed, 28 Nov 2018 15:07:45 +0100 Subject: Most peered AS per country In-Reply-To: <770978027.2077.1543413509775.JavaMail.mhammett@ThunderFuck> References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> <6310c1a6aedd39a4ba5a550b2c2b7665@iit.cnr.it> <770978027.2077.1543413509775.JavaMail.mhammett@ThunderFuck> Message-ID: <28fb0d3bf86aef3a85237b3d09487387@iit.cnr.it> As far as I know, bgp.he.net is pulling data from Isolario, and some researchers are using our data for their analyses. I'm not aware if anyone else is doing anything with our data since data is freely accessible to everyone at https://www.isolario.it/Isolario_MRT_data/. Right now the MRT page is quite slow, so I beg your pardon in advance... we plan to change storage soon! If you plan to use our data, you have to know that we are collecting data from some feeders in ADDPATH (RFC 7911). So, please use a BGP-MRT data reader which is ADDPATH capable like RIPE bgpdump or bgpscanner (https://gitlab.com/Isolario/bgpscanner). Best regards, Ale Il 2018-11-28 14:58 Mike Hammett ha scritto: > Do CAIDA or similar major projects pull data from your project? > > ----- > Mike Hammett > Intelligent Computing Solutions [1] > [2] [3] [4] [5] > Midwest Internet Exchange [6] > [7] [8] [9] > The Brothers WISP [10] > [11] [12] > > ------------------------- > > FROM: "alessandro improta" > TO: "Baldur Norddahl" > CC: nanog at nanog.org > SENT: Wednesday, November 28, 2018 6:56:25 AM > SUBJECT: Re: Most peered AS per country > > Hello Baldur, > if I'm not wrong, CAIDA are using Route Views and RIPE NCC RIS as > data sources. If your AS (or any ASes in your customer cone) is not > feeding any BGP route collector, your peers will never appear in their > > rank. Some of your peers may be seen if any of your peers are > connected > to a route collector though. Data available is extremely incomplete > from > that point of view... If you wish to have more reliable data from BGP > analyzers using public data, I suggest you to join a collector. I run > one of them (Isolario), if you need any more details about that (or > about the data incompleteness) just drop me a mail! > > Best regards, > Alessandro Improta > IIT-CNR - Isolario project (www.isolario.it) > > Il 2018-11-28 12:34 Baldur Norddahl ha scritto: >> The number of peers appears to be unreliable. My network is listed >> with 14 peers but the actual number is much higher. >> >> Regards >> Baldur >> >> ons. 28. nov. 2018 04.02 skrev Bradley Huffaker > : >> >>> Bill is correct. AS Rank’s ranks by customer cone, not peers. >>> Although you can get an ASN’s list of peers. We are currently >>> working on adding country level ranking to AS Rank, but will not >>> have it ready until next year. >>> >>> Bradley >>> >>>> On Nov 28, 2018, at 10:40 AM, Bill Woodcock wrote: >>>>> On Nov 28, 2018, at 10:37 AM, Mehmet Akcin >>> wrote: >>>>> http://as-rank.caida.org/ is impressively showing ranking of ISPs >>> and how well peered they are >>>> >>>> No, it’s by how many customers they have. >>>> >>>> "ASes and Orgs are ranked by their customer cone size, which is >>> the number of their direct and indirect customers.” >>>> >>>> Nothing to do with their peering. >>>> >>>> -Bill >>>> >>>> > > > > Links: > ------ > [1] http://www.ics-il.com/ > [2] https://www.facebook.com/ICSIL > [3] https://plus.google.com/+IntelligentComputingSolutionsDeKalb > [4] https://www.linkedin.com/company/intelligent-computing-solutions > [5] https://twitter.com/ICSIL > [6] http://www.midwest-ix.com/ > [7] https://www.facebook.com/mdwestix > [8] https://www.linkedin.com/company/midwest-internet-exchange > [9] https://twitter.com/mdwestix > [10] http://www.thebrotherswisp.com/ > [11] https://www.facebook.com/thebrotherswisp > [12] https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg From nanog at radu-adrian.feurdean.net Wed Nov 28 14:15:36 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Wed, 28 Nov 2018 15:15:36 +0100 Subject: netflix OCA in a CG-NAT world In-Reply-To: <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> Message-ID: <1543414536.92882.1591815984.51A4006A@webmail.messagingengine.com> On Wed, Nov 28, 2018, at 12:37, Nikolay Shopik wrote: > Are you sure about ATV4 netflix app? Support is there and I've seen > traffic from it when recently did tcpdump from ATV4. Or there is some braindead wifi in-between that does not allow IPv6 to function (or makes it unreliable). Already seens a number of such devices from different vendors. From mark.tinka at seacom.mu Wed Nov 28 14:25:12 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 28 Nov 2018 16:25:12 +0200 Subject: netflix OCA in a CG-NAT world In-Reply-To: <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> Message-ID: <2a85e877-a644-bdc7-5df8-32826dbb73cc@seacom.mu> On 28/Nov/18 13:37, Nikolay Shopik wrote: > Sony Entertainment is know to be slowpoke in this area. PS4 > firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and > thus apps doesn't use it at all. Which is what really surprised me with this 2014 TV I have, considering it stopped getting updates about 2 or so years ago. > > Are you sure about ATV4 netflix app? Support is there and I've seen > traffic from it when recently did tcpdump from ATV4. Well, my Apple TV interface only has IPv4 bits to show. Are you saying IPv6 is hidden from the "Network Settings" tab? I haven't done an actual wire tap. Mark. From mark.tinka at seacom.mu Wed Nov 28 14:27:24 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 28 Nov 2018 16:27:24 +0200 Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> <890C598D-EB7D-4C19-B0C1-C9686C4E54C5@pch.net> Message-ID: On 28/Nov/18 14:37, Tore Anderson wrote: > Yeah, don't fall for the marketing hyperbole. A transit provider's «tier» > is an extremely poor indicator of its interconnectedness and quality, > especially if your traffic is regional in nature. In most cases you'll be > much better off buying your IP transit from a regional «tier-2» provider, > which tends to give you much better connectivity to other networks in your > region - in addition to all the global connectivity that the «tier-2»'s > upstream(s) provide, of course. I find the word "tier" quite awkward... when a large global provider deploys locally in a country/region that only/mostly deals with globally-small (local) providers, the assumption is that all traffic wants to go back to the global carrier's main market (typically Europe and North America). It takes about 12 months before folk realize that this a wrong assumption to bring into the local market. Mark. From mark.tinka at seacom.mu Wed Nov 28 14:28:25 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 28 Nov 2018 16:28:25 +0200 Subject: netflix OCA in a CG-NAT world In-Reply-To: <11326.1543412477@turing-police.cc.vt.edu> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> <11326.1543412477@turing-police.cc.vt.edu> Message-ID: On 28/Nov/18 15:41, valdis.kletnieks at vt.edu wrote: > Odd. Mine does DHCPv6. It might do SLAC as well, my OpenWRT wouldn't > notice an unused SLAC address.. On what Sony device? I know they have different OS's for different TV models, which could have an impact on this... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From mark.tinka at seacom.mu Wed Nov 28 14:30:15 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 28 Nov 2018 16:30:15 +0200 Subject: netflix OCA in a CG-NAT world In-Reply-To: <1543414536.92882.1591815984.51A4006A@webmail.messagingengine.com> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> <1543414536.92882.1591815984.51A4006A@webmail.messagingengine.com> Message-ID: <48786228-cabc-6dcf-33f5-840eb90fa3f1@seacom.mu> On 28/Nov/18 16:15, Radu-Adrian Feurdean wrote: > Or there is some braindead wifi in-between that does not allow IPv6 to function (or makes it unreliable). Already seens a number of such devices from different vendors. I have mine hooked into Cat-6 to my home switch (which has switching IPv6 traffic for all devices that support it). I have IPv6 working over wi-fi for all devices that support it, including iPhones and such. But like I said before, I've seen every device supporting IPv6 to have IPv6 setting bits. Apple TV 4 - my one anyway - does not have this. Only IPv4. Mark. From bryan at shout.net Wed Nov 28 15:22:53 2018 From: bryan at shout.net (Bryan Holloway) Date: Wed, 28 Nov 2018 09:22:53 -0600 Subject: netflix OCA in a CG-NAT world In-Reply-To: <2a85e877-a644-bdc7-5df8-32826dbb73cc@seacom.mu> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> <2a85e877-a644-bdc7-5df8-32826dbb73cc@seacom.mu> Message-ID: <8309c4c0-bd09-e246-b168-e0f81075c4eb@shout.net> On 11/28/18 8:25 AM, Mark Tinka wrote: > > > On 28/Nov/18 13:37, Nikolay Shopik wrote: > >> Sony Entertainment is know to be slowpoke in this area. PS4 >> firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and >> thus apps doesn't use it at all. > > Which is what really surprised me with this 2014 TV I have, considering > it stopped getting updates about 2 or so years ago. >> >> Are you sure about ATV4 netflix app? Support is there and I've seen >> traffic from it when recently did tcpdump from ATV4. > > Well, my Apple TV interface only has IPv4 bits to show. > > Are you saying IPv6 is hidden from the "Network Settings" tab? I haven't > done an actual wire tap. > > Mark. > Vizio also no joy with IPv6. Sigh. From shopik+lists at nvcube.net Wed Nov 28 15:23:55 2018 From: shopik+lists at nvcube.net (Nikolay Shopik) Date: Wed, 28 Nov 2018 18:23:55 +0300 Subject: netflix OCA in a CG-NAT world In-Reply-To: <2a85e877-a644-bdc7-5df8-32826dbb73cc@seacom.mu> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> <2a85e877-a644-bdc7-5df8-32826dbb73cc@seacom.mu> Message-ID: <2f388deb-5c7e-c9f5-f1a7-13473ee7539d@nvcube.net> On 28/11/18 5:25 pm, Mark Tinka wrote: > Well, my Apple TV interface only has IPv4 bits to show. > > Are you saying IPv6 is hidden from the "Network Settings" tab? I haven't > done an actual wire tap. tvOS doesn't expose IPv6 addresses but it fully supported just like all ios based systems since all apps now required to work in IPv6-only network, otherwise they won't able push update into app store. tvOS will only show IPv6 dns servers in their "Network Settings" tab. They just forgot to update interface for some reason, like they did in back ios10 iirc to show all network configuration including IPv6. From toebinoz at gmail.com Wed Nov 28 01:54:57 2018 From: toebinoz at gmail.com (Tashi Phuntsho) Date: Wed, 28 Nov 2018 10:54:57 +0900 Subject: Most peered AS per country In-Reply-To: References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> Message-ID: Try apnic’s viz-as: https://labs.apnic.net/vizas/ — Tashi On Wed, 28 Nov 2018 at 10:46, Mehmet Akcin wrote: > Sorry what i meant with peering, their total as peer/customer count. I > should have worded it correctly thanks Woody. > > Question still exists, is there any similar data set available per country > basis? > > Mehmet > > On Tue, Nov 27, 2018 at 5:41 PM Bill Woodcock wrote: > >> >> >> > On Nov 28, 2018, at 10:37 AM, Mehmet Akcin wrote: >> > http://as-rank.caida.org/ is impressively showing ranking of ISPs and >> how well peered they are >> >> No, it’s by how many customers they have. >> >> "ASes and Orgs are ranked by their customer cone size, which is the >> number of their direct and indirect customers.” >> >> Nothing to do with their peering. >> >> -Bill >> >> >> -- > Mehmet > +1-424-298-1903 > -- -- Tashi Phuntsho -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbateyko at gmail.com Wed Nov 28 05:13:34 2018 From: dbateyko at gmail.com (Dan Bateyko) Date: Wed, 28 Nov 2018 00:13:34 -0500 Subject: Most peered AS per country In-Reply-To: <39124053.1696.1543377733952.JavaMail.mhammett@ThunderFuck> References: <15373A2B-FB22-4E93-8461-98583BBA1865@pch.net> <890C598D-EB7D-4C19-B0C1-C9686C4E54C5@pch.net> <39124053.1696.1543377733952.JavaMail.mhammett@ThunderFuck> Message-ID: The Eyeball Jedi AS-to-AS in-country path metric might be of interest to you: https://www.eyeball-jedi.net/as-to-as-matrix.html On Tue, Nov 27, 2018 at 11:04 PM Mike Hammett wrote: > Renesys used to have a blog that went into that a bit, but I think Oracle > killed it off. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Mehmet Akcin" > *To: *"Bill Woodcock" > *Cc: *"nanog" > *Sent: *Tuesday, November 27, 2018 7:56:34 PM > *Subject: *Re: Most peered AS per country > > Hi Bill > > I am just trying to see if there is some way to rank transit providers by > the amount of peering+customers they have in a country. > > I am noticing provider A enters market X saying they are tier 1 network > but they do not have a si ngle peering session in country and they backhaul > everything back to market Z where they deliver traffic to the peer via high > latency and low performance method. This is causing market to receive > pricing targets which are unrealistic and hurting telecoms who are > genuinely trying to do right thing and establish in country direct peering > with peers. > > I would like to be able to see top 10 networks (top 10 as in adjutancies) > a country which has most amount of routes they are advertising. > > bgp.he.net seems like a good place to see this info. Is there a way to > get this data in a format which I can compile reports Rob? (Excel friendly > format would be great) > > Mehmet > > On Tue, Nov 27, 2018 at 5:48 PM Bill Woodcock wrote: > >> >> >> > On Nov 28, 2018, at 10:42 AM, Mehmet Akcin wrote: >> > >> > Sorry what i meant with peering, their total as peer/customer count. I >> should have worded it correctly thanks Woody. >> > >> > Question still exists, is there any similar data set available per >> country basis? >> >> You want to know how big the per-country customer cones for each AS are? >> Like, for a given country, what AS has the most down-stream networks within >> that country? We used to generate those stats, but the code has probably >> broken long ago. >> >> We did it because we had bulk data agreements with all five RIRs, so we >> had the ASes databased by country-code. We still have that part up-to-date. >> >> -Bill >> >> >> -- > Mehmet > +1-424-298-1903 > > -- Dan Bateyko https://dbateyko.info -------------- next part -------------- An HTML attachment was scrubbed... URL: From omer at chronos.com.tr Wed Nov 28 09:55:38 2018 From: omer at chronos.com.tr (M. Omer GOLGELI) Date: Wed, 28 Nov 2018 12:55:38 +0300 Subject: Most peered AS per country In-Reply-To: References: Message-ID: <3baa45c3b53946332906314017462abe@chronos.com.tr> Checking Isolario Project, I've noticed in Isolario has something country-related as they are displaying country statics on the main page (Screenshot attached) Even if they do not publicly display the data, maybe the guys have something! Alessandro might give you better insight I guess. M. OMER GOLGELI --- AS202365 [1] https://as202365.peeringdb.com [2] https://bgp.he.net/AS202365 [1] NOC: Phone: +90-533-2600533 Email: omer at chronos.com.tr On 2018-11-28 04:37, Mehmet Akcin wrote: > Hello there, > > http://as-rank.caida.org/ is impressively showing ranking of ISPs and how well peered they are and I love this. > > Is there any research / page similar to this which shows similar data but per country basis breakdown instead of showing globally? > > thanks in advance for your help > > Mehmet Links: ------ [1] https://bgp.he.net/AS202365 [2] https://as202365.peeringdb.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed Nov 28 20:10:41 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 28 Nov 2018 22:10:41 +0200 Subject: netflix OCA in a CG-NAT world In-Reply-To: <2f388deb-5c7e-c9f5-f1a7-13473ee7539d@nvcube.net> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> <2a85e877-a644-bdc7-5df8-32826dbb73cc@seacom.mu> <2f388deb-5c7e-c9f5-f1a7-13473ee7539d@nvcube.net> Message-ID: On 28/Nov/18 17:23, Nikolay Shopik wrote: > tvOS will only show IPv6 dns servers in their "Network Settings" tab. > They just forgot to update interface for some reason, like they did in > back ios10 iirc to show all network configuration including IPv6. I'm running tvOS 12.1 (16J602), and there is no display of anything IPv6 anywhere on the system. Mark. From micah at riseup.net Wed Nov 28 20:45:53 2018 From: micah at riseup.net (micah anderson) Date: Wed, 28 Nov 2018 15:45:53 -0500 Subject: Bulk IP abuse reporting Message-ID: <87in0horr2.fsf@riseup.net> Hi all, It seems that outdated CLDAP servers on the internet are being used again for DDoS amplification attacks. I've got about 16k IPs that have participated in several of these over the last several weeks and I'd like to report these to the relevant abuse departments so they can be properly handled. However, I am not finding a simple, or standardized way to look up the abuse contacts for a specific IP. Does someone have a suggestion? thanks! -- micah From damian at google.com Wed Nov 28 21:17:13 2018 From: damian at google.com (Damian Menscher) Date: Wed, 28 Nov 2018 13:17:13 -0800 Subject: Bulk IP abuse reporting In-Reply-To: <87in0horr2.fsf@riseup.net> References: <87in0horr2.fsf@riseup.net> Message-ID: Take a look at https://www.abusix.com/contactdb Damian On Wed, Nov 28, 2018 at 12:46 PM micah anderson wrote: > > Hi all, > > It seems that outdated CLDAP servers on the internet are being used > again for DDoS amplification attacks. I've got about 16k IPs that have > participated in several of these over the last several weeks and I'd > like to report these to the relevant abuse departments so they can be > properly handled. > > However, I am not finding a simple, or standardized way to look up the > abuse contacts for a specific IP. Does someone have a suggestion? > > thanks! > > -- > micah > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at iecc.com Wed Nov 28 22:41:41 2018 From: johnl at iecc.com (John Levine) Date: 28 Nov 2018 17:41:41 -0500 Subject: Bulk IP abuse reporting In-Reply-To: <87in0horr2.fsf@riseup.net> Message-ID: <20181128224142.3C3672008FA726@ary.qy> In article <87in0horr2.fsf at riseup.net> you write: >However, I am not finding a simple, or standardized way to look up the >abuse contacts for a specific IP. Does someone have a suggestion? The RIRs all have RDAP servers that will in theory give you the abuse contact for any IP address in an easy to parse json. I have a python script that works reasonably well to look them up and cache what it finds in a mysql database. R's, John From mark.tinka at seacom.mu Thu Nov 29 08:16:08 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 29 Nov 2018 10:16:08 +0200 Subject: netflix OCA in a CG-NAT world In-Reply-To: References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <232d38da-1d2d-80e0-9908-d99734794116@seacom.mu> <20ad9670-b035-2ab6-a3d9-448ee0095ca8@nvcube.net> <2a85e877-a644-bdc7-5df8-32826dbb73cc@seacom.mu> <2f388deb-5c7e-c9f5-f1a7-13473ee7539d@nvcube.net> Message-ID: <7086aacd-c3b9-af9e-87ef-b27f1824c01c@seacom.mu> So comparing the ARP and ND tables on my Mikrotik home router, I see that my Apple TV, indeed, does have an IPv6 address assigned to it (SLAAC), even though the device, itself, does not display any IPv6 information in its network settings. Then again, Apple never did think an "HDD is Active" blinker on their laptops was ever necessary :-). Mark. On 28/Nov/18 22:10, Mark Tinka wrote: > > On 28/Nov/18 17:23, Nikolay Shopik wrote: > >> tvOS will only show IPv6 dns servers in their "Network Settings" tab. >> They just forgot to update interface for some reason, like they did in >> back ios10 iirc to show all network configuration including IPv6. > I'm running tvOS 12.1 (16J602), and there is no display of anything IPv6 > anywhere on the system. > > Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nzurku at teraswitch.com Thu Nov 29 17:26:11 2018 From: nzurku at teraswitch.com (Nick Zurku) Date: Thu, 29 Nov 2018 09:26:11 -0800 Subject: Verizon: Extremely Strange CPE Routing in NYC/NJ Area Message-ID: Can anyone from Verizon take a look at this behavior for us? We’re having multiple Verizon FiOS users in the NYC/NJ area appear to teleport from their FiOS router to our IP in the Pittsburgh region. Users are seeing extreme slowness with TCP traffic, but ping times seem reasonable. User 1: 1 fios_quantum_gateway (192.168.1.1) 1.575 ms 2.426 ms 3.193 ms 2 204.16.244.8 (204.16.244.8) 2.269 ms 3.055 ms 2.727 ms User 2: 1 fios_quantum_gateway (192.168.1.1) 1.565 ms 1.048 ms 0.947 ms 2 204.16.244.8 (204.16.244.8) 2.162 ms 3.588 ms 3.048 ms I can provide end-user NYC/NJ IPs off-list if desirable. Here's a normal looking trace from an FiOS line locally in the Pittsburgh region: IP: 108.39.229.34 Tracing route to four.libsyn.com [204.16.244.8] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 5 ms 2 ms 7 ms lo0-100.PITBPA-VFTTP-301.verizon-gni.net [108.39.229.1] 3 5 ms 6 ms 6 ms B3301.PITBPA-LCR-22.verizon-gni.net [100.41.223.244] 4 * * * Request timed out. 5 * * * Request timed out. 6 13 ms 12 ms 13 ms 0.et-7-1-5.BR1.IAD8.ALTER.NET [140.222.226.17] 7 10 ms 10 ms 10 ms verizon.com.customer.alter.net [152.179.50.110] 8 12 ms 12 ms 13 ms be3084.ccr42.dca01.atlas.cogentco.com [154.54.30.65] 9 22 ms 22 ms 22 ms be2820.rcr21.pit02.atlas.cogentco.com [154.54.83.54] 10 22 ms 22 ms 21 ms 38.104.120.90 11 26 ms 21 ms 19 ms 204.16.241.133 12 * * * Request timed out. 13 21 ms 21 ms 21 ms 204.16.244.8 Is this a possible traffic engineering blip? I can’t say we’ve ever seen trace routes return such sparse results and actually make it to the destination. -- Nick Zurku Systems Engineer TeraSwitch, Inc. Cell: 412-953-0481 Office: 412-945-7048 nzurku at teraswitch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Thu Nov 29 22:02:34 2018 From: job at ntt.net (Job Snijders) Date: Thu, 29 Nov 2018 23:02:34 +0100 Subject: progress report: modernizing OpenBGPD Message-ID: <20181129220234.GQ900@hanna.meerval.net> Dear fellow BGP aficionados, Over the last few months we've spend considerable time modernizing the OpenBSD's BGP-4 implementation "OpenBGPD", with the explicit goal to offer more diversity in the IXP Route Server space. OpenBGPD now is faster, has RFC 8212 support, RFC 6811 Origin Validation support, and a bunch of other cool features that make life easier! Read the full report here: https://labs.ripe.net/Members/claudio_jeker/openbgpd-adding-diversity-to-route-server-landscape Kind regards, Job From ler762 at gmail.com Thu Nov 29 22:41:42 2018 From: ler762 at gmail.com (Lee) Date: Thu, 29 Nov 2018 17:41:42 -0500 Subject: Verizon: Extremely Strange CPE Routing in NYC/NJ Area In-Reply-To: References: Message-ID: On 11/29/18, Nick Zurku wrote: > Can anyone from Verizon take a look at this behavior for us? > > We’re having multiple Verizon FiOS users in the NYC/NJ area appear to > teleport from their FiOS router to our IP in the Pittsburgh region. Verizon is doing something seriously weird to windows traceroute: C:\Users\Lee>tracert www.yahoo.com Tracing route to atsv2-fp-shed.wg1.b.yahoo.com [98.138.219.232] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms fw.home.net 2 1 ms <1 ms <1 ms vbz-router.home.net [192.168.1.1] 3 8 ms 3 ms 6 ms media-router-fp2.prod1.media.vip.ne1.yahoo.com [98.138.219.232] Trace complete. C:\Users\Lee>ping -i 12 www.yahoo.com. Pinging atsv2-fp-shed.wg1.b.yahoo.com [98.138.219.232] with 32 bytes of data: Reply from 98.138.0.87: TTL expired in transit. Reply from 98.138.0.87: TTL expired in transit. Reply from 98.138.0.87: TTL expired in transit. Reply from 98.138.0.87: TTL expired in transit. Ping statistics for 98.138.219.232: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), C:\Users\Lee>ping -i 13 www.yahoo.com. Pinging atsv2-fp-shed.wg1.b.yahoo.com [98.138.219.232] with 32 bytes of data: Reply from 98.138.219.232: bytes=32 time=32ms TTL=54 Reply from 98.138.219.232: bytes=32 time=31ms TTL=54 Reply from 98.138.219.232: bytes=32 time=33ms TTL=54 Reply from 98.138.219.232: bytes=32 time=33ms TTL=54 Ping statistics for 98.138.219.232: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 31ms, Maximum = 33ms, Average = 32ms C:\Users\Lee> traceroute from a linux box works as expected.. Lee > Users > are seeing extreme slowness with TCP traffic, but ping times seem > reasonable. > > User 1: > 1 fios_quantum_gateway (192.168.1.1) 1.575 ms 2.426 ms 3.193 ms > 2 204.16.244.8 (204.16.244.8) 2.269 ms 3.055 ms 2.727 ms > > User 2: > 1 fios_quantum_gateway (192.168.1.1) 1.565 ms 1.048 ms 0.947 ms > 2 204.16.244.8 (204.16.244.8) 2.162 ms 3.588 ms 3.048 ms > > I can provide end-user NYC/NJ IPs off-list if desirable. > > > Here's a normal looking trace from an FiOS line locally in the Pittsburgh > region: > > > IP: 108.39.229.34 > Tracing route to four.libsyn.com [204.16.244.8] > over a maximum of 30 hops: > > 1 <1 ms <1 ms <1 ms 192.168.1.1 > 2 5 ms 2 ms 7 ms lo0-100.PITBPA-VFTTP-301.verizon-gni.net > [108.39.229.1] > 3 5 ms 6 ms 6 ms B3301.PITBPA-LCR-22.verizon-gni.net > [100.41.223.244] > 4 * * * Request timed out. > 5 * * * Request timed out. > 6 13 ms 12 ms 13 ms 0.et-7-1-5.BR1.IAD8.ALTER.NET > [140.222.226.17] > 7 10 ms 10 ms 10 ms verizon.com.customer.alter.net > [152.179.50.110] > 8 12 ms 12 ms 13 ms be3084.ccr42.dca01.atlas.cogentco.com > [154.54.30.65] > 9 22 ms 22 ms 22 ms be2820.rcr21.pit02.atlas.cogentco.com > [154.54.83.54] > 10 22 ms 22 ms 21 ms 38.104.120.90 > 11 26 ms 21 ms 19 ms 204.16.241.133 > 12 * * * Request timed out. > 13 21 ms 21 ms 21 ms 204.16.244.8 > > Is this a possible traffic engineering blip? I can’t say we’ve ever > seen trace routes return such sparse results and actually make it to the > destination. > > -- > Nick Zurku > Systems Engineer > TeraSwitch, Inc. > Cell: 412-953-0481 > Office: 412-945-7048 > nzurku at teraswitch.com > From jtk at depaul.edu Thu Nov 29 22:41:01 2018 From: jtk at depaul.edu (John Kristoff) Date: Thu, 29 Nov 2018 16:41:01 -0600 Subject: Security Track @ NANOG 75 Call for Participation Message-ID: <20181129164101.394c8833@p50.localdomain> [ Apologies if you saw this elsewhere already - jtk ] Friends, colleagues, fellow operators, The network security track, formerly known as the ISP security BoF, has plans to return at NANOG 75 in San Francisco February 18-20. I will be your track facilitator. I have a small handful of topics I'm soliciting from some folks directly, but options are good, and I may be missing something important. If you haven't heard from me already, then I want to hear your ideas or proposals. This is a good, casual place to go with netsec related ideas, tools, or case studies. Here is an incomplete list of relevant topics to stir your thoughts: * IRRs, BGPSEC, and RPKI * DDoS attacks and mitigation * Botnet case studies * ISP incident response tools * Network censorship and privacy * Threat sharing frameworks * Network equipment configuration/default BCPs * Spoofing, amplification, reflection threats * ...insert your idea here John From mhuff at ox.com Fri Nov 30 13:17:17 2018 From: mhuff at ox.com (Matthew Huff) Date: Fri, 30 Nov 2018 13:17:17 +0000 Subject: Verizon: Extremely Strange CPE Routing in NYC/NJ Area In-Reply-To: References: Message-ID: <2823ad18d59d4102bdae3047eb45a140@ox.com> Windows traceroute uses ICMP by default, Unix based systems use UDP. For example from my Mac on Fios in Westchester, NY (and yes, they are doing something with ICMP traceroutes, possibly within their gateway box): acpro:Documents mhuff$ sudo traceroute www.yahoo.com traceroute: Warning: www.yahoo.com has multiple addresses; using 72.30.35.9 traceroute to atsv2-fp-shed.wg1.b.yahoo.com (72.30.35.9), 64 hops max, 52 byte packets 1 firewall (10.1.1.1) 0.916 ms 0.419 ms 0.394 ms 2 * * * 3 b3369.nycmny-lcr-22.verizon-gni.net (130.81.16.102) 3.939 ms 10.172 ms b3369.nycmny-lcr-21.verizon-gni.net (130.81.16.100) 5.192 ms 4 * * * 5 0.ae4.xl2.buf4.alter.net (140.222.228.143) 13.500 ms * 12.970 ms 6 0.xe-5-3-0.gw1.buf4.alter.net (152.63.26.62) 12.390 ms 12.122 ms 0.ae4.xl2.buf4.alter.net (140.222.228.143) 12.704 ms 7 0.xe-4-2-0.gw1.buf4.alter.net (152.63.26.46) 14.326 ms 13.069 ms verizon.com.customer.alter.net (204.148.47.162) 14.436 ms 8 et-19-0-0.pat1.bfz.yahoo.com (216.115.97.103) 13.990 ms unknown-72-30-223-x.yahoo.com (72.30.223.3) 14.220 ms et-19-0-0.pat1.bfz.yahoo.com (216.115.97.103) 13.711 ms 9 et-0-0-0.msr2.bf1.yahoo.com (74.6.227.137) 12.098 ms et-0-0-0.msr1.bf1.yahoo.com (74.6.227.129) 13.388 ms et-18-0-1.msr1.bf1.yahoo.com (74.6.227.131) 14.457 ms 10 et-19-0-0.clr2-a-gdc.bf1.yahoo.com (74.6.122.37) 14.554 ms et-0-0-0.msr1.bf1.yahoo.com (74.6.227.129) 14.810 ms et-1-1-1.msr1.bf1.yahoo.com (74.6.227.135) 13.502 ms 11 eth-18-3.bas2-1-flk.bf1.yahoo.com (98.139.128.75) 14.607 ms 16.608 ms eth-18-3-bas1-1-flk.bf1.yahoo.com (98.139.128.73) 15.161 ms 12 media-router-fp1.prod1.media.vip.bf1.yahoo.com (72.30.35.9) 13.470 ms eth-17-3.bas2-1-flk.bf1.yahoo.com (98.139.128.71) 13.582 ms media-router-fp1.prod1.media.vip.bf1.yahoo.com (72.30.35.9) 12.952 ms macpro:Documents mhuff$ sudo traceroute -I www.yahoo.com traceroute: Warning: www.yahoo.com has multiple addresses; using 72.30.35.10 traceroute to atsv2-fp-shed.wg1.b.yahoo.com (72.30.35.10), 64 hops max, 72 byte packets 1 firewall (10.1.1.1) 0.675 ms 0.347 ms 0.322 ms 2 media-router-fp2.prod1.media.vip.bf1.yahoo.com (72.30.35.10) 2.456 ms 21.139 ms 12.834 ms ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lee Sent: Thursday, November 29, 2018 5:42 PM To: Nick Zurku Cc: Brendan Mannella ; nanog at nanog.org; Todd Kammerer Subject: Re: Verizon: Extremely Strange CPE Routing in NYC/NJ Area On 11/29/18, Nick Zurku wrote: > Can anyone from Verizon take a look at this behavior for us? > > We’re having multiple Verizon FiOS users in the NYC/NJ area appear to > teleport from their FiOS router to our IP in the Pittsburgh region. Verizon is doing something seriously weird to windows traceroute: C:\Users\Lee>tracert www.yahoo.com Tracing route to atsv2-fp-shed.wg1.b.yahoo.com [98.138.219.232] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms fw.home.net 2 1 ms <1 ms <1 ms vbz-router.home.net [192.168.1.1] 3 8 ms 3 ms 6 ms media-router-fp2.prod1.media.vip.ne1.yahoo.com [98.138.219.232] Trace complete. C:\Users\Lee>ping -i 12 www.yahoo.com. Pinging atsv2-fp-shed.wg1.b.yahoo.com [98.138.219.232] with 32 bytes of data: Reply from 98.138.0.87: TTL expired in transit. Reply from 98.138.0.87: TTL expired in transit. Reply from 98.138.0.87: TTL expired in transit. Reply from 98.138.0.87: TTL expired in transit. Ping statistics for 98.138.219.232: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), C:\Users\Lee>ping -i 13 www.yahoo.com. Pinging atsv2-fp-shed.wg1.b.yahoo.com [98.138.219.232] with 32 bytes of data: Reply from 98.138.219.232: bytes=32 time=32ms TTL=54 Reply from 98.138.219.232: bytes=32 time=31ms TTL=54 Reply from 98.138.219.232: bytes=32 time=33ms TTL=54 Reply from 98.138.219.232: bytes=32 time=33ms TTL=54 Ping statistics for 98.138.219.232: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 31ms, Maximum = 33ms, Average = 32ms C:\Users\Lee> traceroute from a linux box works as expected.. Lee > Users > are seeing extreme slowness with TCP traffic, but ping times seem > reasonable. > > User 1: > 1 fios_quantum_gateway (192.168.1.1) 1.575 ms 2.426 ms 3.193 ms > 2 204.16.244.8 (204.16.244.8) 2.269 ms 3.055 ms 2.727 ms > > User 2: > 1 fios_quantum_gateway (192.168.1.1) 1.565 ms 1.048 ms 0.947 ms > 2 204.16.244.8 (204.16.244.8) 2.162 ms 3.588 ms 3.048 ms > > I can provide end-user NYC/NJ IPs off-list if desirable. > > > Here's a normal looking trace from an FiOS line locally in the > Pittsburgh > region: > > > IP: 108.39.229.34 > Tracing route to four.libsyn.com [204.16.244.8] over a maximum of 30 > hops: > > 1 <1 ms <1 ms <1 ms 192.168.1.1 > 2 5 ms 2 ms 7 ms lo0-100.PITBPA-VFTTP-301.verizon-gni.net > [108.39.229.1] > 3 5 ms 6 ms 6 ms B3301.PITBPA-LCR-22.verizon-gni.net > [100.41.223.244] > 4 * * * Request timed out. > 5 * * * Request timed out. > 6 13 ms 12 ms 13 ms 0.et-7-1-5.BR1.IAD8.ALTER.NET > [140.222.226.17] > 7 10 ms 10 ms 10 ms verizon.com.customer.alter.net > [152.179.50.110] > 8 12 ms 12 ms 13 ms be3084.ccr42.dca01.atlas.cogentco.com > [154.54.30.65] > 9 22 ms 22 ms 22 ms be2820.rcr21.pit02.atlas.cogentco.com > [154.54.83.54] > 10 22 ms 22 ms 21 ms 38.104.120.90 > 11 26 ms 21 ms 19 ms 204.16.241.133 > 12 * * * Request timed out. > 13 21 ms 21 ms 21 ms 204.16.244.8 > > Is this a possible traffic engineering blip? I can’t say we’ve ever > seen trace routes return such sparse results and actually make it to > the destination. > > -- > Nick Zurku > Systems Engineer > TeraSwitch, Inc. > Cell: 412-953-0481 > Office: 412-945-7048 > nzurku at teraswitch.com > From adamv0025 at netconsultings.com Fri Nov 30 13:53:12 2018 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 30 Nov 2018 13:53:12 -0000 Subject: Anyone using AT&T's ECOMP/ONAP? Message-ID: <00c101d488b4$0906fa10$1b14ee30$@netconsultings.com> Hi gents, I'm looking for physical network services orchestration framework for network service providers that could later be used/extended to orchestrate other areas of the business (virtualized services in DC, etc..). So far it appears to me that there's no such ready-made commercial product on the market that would contain all the building blocks I'd be interested in (well especially the easy to use service designer tool). ECOMP and now OANP seem to have it all and much more I'm just curious if anyone is using it in anger (or parts of it for that matter) for orchestration/design/automation of services on physical network. I'd like to hear some stories from trenches with regards to the implementation, but I'd be also interested in your thoughts in case you just assessed the tool for implementation (why did liked not liked about it). Thank you adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: From cb.list6 at gmail.com Fri Nov 30 14:30:05 2018 From: cb.list6 at gmail.com (Ca By) Date: Fri, 30 Nov 2018 06:30:05 -0800 Subject: Anyone using AT&T's ECOMP/ONAP? In-Reply-To: <00c101d488b4$0906fa10$1b14ee30$@netconsultings.com> References: <00c101d488b4$0906fa10$1b14ee30$@netconsultings.com> Message-ID: On Fri, Nov 30, 2018 at 5:54 AM wrote: > Hi gents, > > I'm looking for physical network services orchestration framework for > network service providers that could later be used/extended to orchestrate > other areas of the business (virtualized services in DC, etc..). > So far it appears to me that there's no such ready-made commercial product > on the market that would contain all the building blocks I'd be interested > in (well especially the easy to use service designer tool). > ECOMP and now OANP seem to have it all and much more I'm just curious if > anyone is using it in anger (or parts of it for that matter) for > orchestration/design/automation of services on physical network. > I'd like to hear some stories from trenches with regards to the > implementation, but I'd be also interested in your thoughts in case you > just > assessed the tool for implementation (why did liked not liked about it). > > > Thank you > > adam > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: Can you share a link to ecomp source code and install guide? I recall at&t press releases about millions of lines of open source code , but never saw the code Thanks, CB > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdodd at salesforce.com Fri Nov 30 16:43:38 2018 From: sdodd at salesforce.com (Steve Dodd) Date: Fri, 30 Nov 2018 09:43:38 -0700 Subject: Anyone using AT&T's ECOMP/ONAP? In-Reply-To: References: <00c101d488b4$0906fa10$1b14ee30$@netconsultings.com> Message-ID: https://gerrit.onap.org/r/#/admin/projects/ecompsdkos On Fri, Nov 30, 2018 at 7:31 AM Ca By wrote: > > > On Fri, Nov 30, 2018 at 5:54 AM wrote: > >> Hi gents, >> >> I'm looking for physical network services orchestration framework for >> network service providers that could later be used/extended to orchestrate >> other areas of the business (virtualized services in DC, etc..). >> So far it appears to me that there's no such ready-made commercial >> product >> on the market that would contain all the building blocks I'd be interested >> in (well especially the easy to use service designer tool). >> ECOMP and now OANP seem to have it all and much more I'm just curious if >> anyone is using it in anger (or parts of it for that matter) for >> orchestration/design/automation of services on physical network. >> I'd like to hear some stories from trenches with regards to the >> implementation, but I'd be also interested in your thoughts in case you >> just >> assessed the tool for implementation (why did liked not liked about it). >> >> >> Thank you >> >> adam >> >> netconsultings.com >> ::carrier-class solutions for the telecommunications industry:: > > > Can you share a link to ecomp source code and install guide? I recall > at&t press releases about millions of lines of open source code , but never > saw the code > > Thanks, > CB > >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlk at thrashyour.com Fri Nov 30 17:48:51 2018 From: jlk at thrashyour.com (John Kinsella) Date: Fri, 30 Nov 2018 09:48:51 -0800 Subject: Anyone using AT&T's ECOMP/ONAP? In-Reply-To: <00c101d488b4$0906fa10$1b14ee30$@netconsultings.com> References: <00c101d488b4$0906fa10$1b14ee30$@netconsultings.com> Message-ID: A few of us at my startup worked with onap for a few months last year as part of a container security project for a large telco. It was a bit of a PIA to get going. Att open sourced it in name - an enterprise sw project that was built by a large team over several years with lots of people coming and going. So I’d say don’t expect an easy go if it. Onap was a popular topic at kubecon last year - lots of telcos medium and large looking at it, so due to popularity maybe the community support has improved in the last year. Excuse any typos - sent from mobile device > On Nov 30, 2018, at 5:53 AM, wrote: > > Hi gents, > > I'm looking for physical network services orchestration framework for > network service providers that could later be used/extended to orchestrate > other areas of the business (virtualized services in DC, etc..). > So far it appears to me that there's no such ready-made commercial product > on the market that would contain all the building blocks I'd be interested > in (well especially the easy to use service designer tool). > ECOMP and now OANP seem to have it all and much more I'm just curious if > anyone is using it in anger (or parts of it for that matter) for > orchestration/design/automation of services on physical network. > I'd like to hear some stories from trenches with regards to the > implementation, but I'd be also interested in your thoughts in case you just > assessed the tool for implementation (why did liked not liked about it). > > > Thank you > > adam > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: > From cscora at apnic.net Fri Nov 30 18:03:41 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Dec 2018 04:03:41 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181130180341.16B89C44B7@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 and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 01 Dec, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 726637 Prefixes after maximum aggregation (per Origin AS): 280070 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 349897 Total ASes present in the Internet Routing Table: 62579 Prefixes per ASN: 11.61 Origin-only ASes present in the Internet Routing Table: 53999 Origin ASes announcing only one prefix: 23452 Transit ASes present in the Internet Routing Table: 8580 Transit-only ASes present in the Internet Routing Table: 256 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 43 Max AS path prepend of ASN ( 22394) 40 Prefixes from unregistered ASNs in the Routing Table: 36 Number of instances of unregistered ASNs: 36 Number of 32-bit ASNs allocated by the RIRs: 25055 Number of 32-bit ASNs visible in the Routing Table: 20291 Prefixes from 32-bit ASNs in the Routing Table: 87059 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 255 Number of addresses announced to Internet: 2854067617 Equivalent to 170 /8s, 29 /16s and 157 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.1 Total number of prefixes smaller than registry allocations: 242499 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 198357 Total APNIC prefixes after maximum aggregation: 56634 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 195618 Unique aggregates announced from the APNIC address blocks: 80721 APNIC Region origin ASes present in the Internet Routing Table: 9250 APNIC Prefixes per ASN: 21.15 APNIC Region origin ASes announcing only one prefix: 2597 APNIC Region transit ASes present in the Internet Routing Table: 1385 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: 4254 Number of APNIC addresses announced to Internet: 768787328 Equivalent to 45 /8s, 210 /16s and 195 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 215529 Total ARIN prefixes after maximum aggregation: 102534 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 214899 Unique aggregates announced from the ARIN address blocks: 102746 ARIN Region origin ASes present in the Internet Routing Table: 18307 ARIN Prefixes per ASN: 11.74 ARIN Region origin ASes announcing only one prefix: 6802 ARIN Region transit ASes present in the Internet Routing Table: 1830 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 43 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2512 Number of ARIN addresses announced to Internet: 1093425568 Equivalent to 65 /8s, 44 /16s and 89 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 198658 Total RIPE prefixes after maximum aggregation: 94883 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 195035 Unique aggregates announced from the RIPE address blocks: 115624 RIPE Region origin ASes present in the Internet Routing Table: 25667 RIPE Prefixes per ASN: 7.60 RIPE Region origin ASes announcing only one prefix: 11478 RIPE Region transit ASes present in the Internet Routing Table: 3543 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7636 Number of RIPE addresses announced to Internet: 715962752 Equivalent to 42 /8s, 172 /16s and 185 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 94374 Total LACNIC prefixes after maximum aggregation: 21796 LACNIC Deaggregation factor: 4.33 Prefixes being announced from the LACNIC address blocks: 95750 Unique aggregates announced from the LACNIC address blocks: 41854 LACNIC Region origin ASes present in the Internet Routing Table: 7850 LACNIC Prefixes per ASN: 12.20 LACNIC Region origin ASes announcing only one prefix: 2162 LACNIC Region transit ASes present in the Internet Routing Table: 1483 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5392 Number of LACNIC addresses announced to Internet: 172999680 Equivalent to 10 /8s, 79 /16s and 196 /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: 19682 Total AfriNIC prefixes after maximum aggregation: 4193 AfriNIC Deaggregation factor: 4.69 Prefixes being announced from the AfriNIC address blocks: 25080 Unique aggregates announced from the AfriNIC address blocks: 8714 AfriNIC Region origin ASes present in the Internet Routing Table: 1226 AfriNIC Prefixes per ASN: 20.46 AfriNIC Region origin ASes announcing only one prefix: 413 AfriNIC Region transit ASes present in the Internet Routing Table: 241 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 497 Number of AfriNIC addresses announced to Internet: 102497536 Equivalent to 6 /8s, 27 /16s and 253 /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 7545 4620 515 518 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4256 4192 74 ERX-CERNET-BKB China Education and Rese 7552 2983 1150 88 VIETEL-AS-AP Viettel Group, VN 45899 2980 1705 113 VNPT-AS-VN VNPT Corp, VN 4766 2832 11131 767 KIXS-AS-KR Korea Telecom, KR 9829 2746 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2449 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2435 4907 30 CTTNET China TieTong Telecommunications 17974 2257 970 54 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2135 421 171 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 3501 1324 84 SHAW - Shaw Communications Inc., CA 11492 3471 224 617 CABLEONE - CABLE ONE, INC., US 22773 3293 2977 172 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2609 5245 961 AMAZON-02 - Amazon.com, Inc., US 16625 2200 1212 1668 AKAMAI-AS - Akamai Technologies, Inc., 18566 2152 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2145 2746 535 CHARTER-20115 - Charter Communications, 5650 2087 3074 1462 FRONTIER-FRTR - Frontier Communications 30036 2074 347 131 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2053 5080 598 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 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 5175 1617 133 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3035 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2587 563 1913 AKAMAI-ASN1, US 12389 2191 2195 613 ROSTELECOM-AS, RU 34984 2049 337 536 TELLCOM-AS, TR 9121 1811 1691 17 TTNET, TR 13188 1605 100 42 TRIOLAN, UA 8402 1297 544 17 CORBINA-AS OJSC "Vimpelcom", RU 6849 1218 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5444 3313 605 Uninet S.A. de C.V., MX 10620 3123 475 888 Telmex Colombia S.A., CO 11830 2676 371 71 Instituto Costarricense de Electricidad 6503 1661 449 54 Axtel, S.A.B. de C.V., MX 7303 1437 961 219 Telecom Argentina S.A., AR 28573 1182 2240 185 CLARO S.A., BR 6147 1117 377 29 Telefonica del Peru S.A.A., PE 3816 1023 511 115 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 943 145 69 Alestra, S. de R.L. de C.V., MX 13999 924 537 256 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 37611 908 107 9 Afrihost, ZA 36903 796 400 142 MT-MPLS, MA 36992 787 1411 44 ETISALAT-MISR, EG 24863 739 393 22 LINKdotNET-AS, EG 24835 683 632 20 RAYA-AS, EG 8452 644 1728 15 TE-AS TE-AS, EG 29571 474 70 12 ORANGE-COTE-IVOIRE, CI 37492 458 470 57 ORANGE-, TN 37342 421 32 1 MOVITEL, MZ 15399 411 45 11 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 5444 3313 605 Uninet S.A. de C.V., MX 12479 5175 1617 133 UNI2-AS, ES 7545 4620 515 518 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4256 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3501 1324 84 SHAW - Shaw Communications Inc., CA 11492 3471 224 617 CABLEONE - CABLE ONE, INC., US 22773 3293 2977 172 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3123 475 888 Telmex Colombia S.A., CO 8551 3035 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5175 5042 UNI2-AS, ES 4538 4256 4182 ERX-CERNET-BKB China Education and Research Net 7545 4620 4102 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3501 3417 SHAW - Shaw Communications Inc., CA 22773 3293 3121 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3035 2992 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2983 2895 VIETEL-AS-AP Viettel Group, VN 45899 2980 2867 VNPT-AS-VN VNPT Corp, VN 11492 3471 2854 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 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 65599 UNALLOCATED 103.14.27.0/24 134813 CYBERCOMM-BD Cyber Communicati 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 92937 UNALLOCATED 110.49.72.0/24 45458 SBN-AWN-AS-02-AP SBN-ISP/AWN-I 4230060012 PRIVATE 132.190.106.0/24 64673 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.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.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.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 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:13 /9:11 /10:36 /11:99 /12:291 /13:568 /14:1123 /15:1909 /16:13325 /17:7892 /18:13873 /19:25494 /20:39471 /21:46106 /22:90181 /23:73931 /24:410046 /25:827 /26:660 /27:643 /28:39 /29:20 /30:21 /31:4 /32:54 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3995 5175 UNI2-AS, ES 6327 3271 3501 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2759 3471 CABLEONE - CABLE ONE, INC., US 22773 2536 3293 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2491 3035 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2047 2152 MEGAPATH5-US - MegaPath Corporation, US 11830 2021 2676 Instituto Costarricense de Electricidad y Telec 30036 1823 2074 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2087 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1631 2:888 4:18 5:2736 6:43 7:1 8:1151 12:1869 13:296 14:1875 15:35 16:4 17:198 18:58 20:48 23:2529 24:2412 25:2 27:2530 31:2002 32:88 35:31 36:532 37:2972 38:1600 39:274 40:119 41:3144 42:730 43:1990 44:136 45:6239 46:3052 47:241 49:1320 50:1071 51:318 52:1109 54:362 55:1 56:6 57:41 58:1707 59:1075 60:462 61:2121 62:1904 63:1802 64:5059 65:2178 66:4782 67:2651 68:1154 69:3358 70:1150 71:601 72:2248 74:2714 75:399 76:526 77:1702 78:1744 79:2219 80:1588 81:1411 82:1056 83:825 84:1062 85:2132 86:558 87:1492 88:923 89:2399 90:211 91:6469 92:1277 93:2394 94:2458 95:3082 96:910 97:348 98:941 99:166 100:87 101:1159 102:293 103:19308 104:3579 105:227 106:903 107:1832 108:706 109:3434 110:1627 111:1830 112:1408 113:1333 114:1142 115:1707 116:1599 117:1871 118:2216 119:1671 120:1121 121:1033 122:2364 123:1675 124:1444 125:1930 128:1209 129:690 130:517 131:1644 132:717 133:193 134:1042 135:224 136:535 137:672 138:1949 139:757 140:564 141:757 142:802 143:1009 144:852 145:497 146:1240 147:761 148:1684 149:728 150:768 151:996 152:919 153:327 154:2199 155:971 156:1631 157:848 158:670 159:1888 160:1473 161:886 162:2648 163:763 164:1118 165:1589 166:462 167:1346 168:3168 169:866 170:4009 171:500 172:1058 173:2106 174:989 175:871 176:2234 177:3996 178:2522 179:1307 180:2108 181:2357 182:2607 183:1332 184:1145 185:14407 186:3639 187:2497 188:2936 189:2055 190:8293 191:1363 192:9926 193:6404 194:5265 195:4049 196:2995 197:1761 198:5683 199:5977 200:7444 201:5014 202:10193 203:10212 204:4566 205:3019 206:3224 207:3195 208:3955 209:4139 210:3876 211:2025 212:3067 213:2800 214:1059 215:55 216:6029 217:2177 218:871 219:506 220:1833 221:997 222:955 223:1406 End of report From kmedcalf at dessus.com Fri Nov 30 20:16:31 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 30 Nov 2018 13:16:31 -0700 Subject: [outages] facebook slow In-Reply-To: Message-ID: > From what I'm aware of the US is currently experiencing issues >with FB, Instagram and LastPass. The latter is impacting business for >us. Coincidence? Maybe. The root cause will certainly be >interesting. Why don't you just write all your password on big sheets of construction paper and put them on the front of the building or in the nearest Starbucks? That way you won't have it "impacting business" and you passwords will be more secure ... --- 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: Outages [mailto:outages-bounces at outages.org] On Behalf Of Brian >Ladd via Outages >Sent: Friday, 30 November, 2018 08:21 >To: outages at outages.org >Subject: Re: [outages] facebook slow > >Wouldn't it be faster to create a mail filter to ignore outage >notifications with social media platforms in the subject line than it >would to write up an email complaining about it? Good grief. > >Brian Ladd >Customer Care Manager >Voiceopia Communications > > > > >On Fri, Nov 30, 2018 at 9:28 AM Andrew R. LaPour via Outages > wrote: > > > Gentlemen, some of you complain more than help. To judge the >criticality of a service for other businesses is simply ignorant. An >issue with a service as vast as FB could certainly be related to >carrier services... As you all know, Cloud/SaaS services have >evolved to a degree in which outages have a larger impact on >businesses today than ever before and thus this list, like it or not, >has also evolved. > > From what I'm aware of the US is currently experiencing issues >with FB, Instagram and LastPass. The latter is impacting business for >us. Coincidence? Maybe. The root cause will certainly be >interesting. > > > Andrew LaPour > VP of Information Technology > > Sent from my phone. Forgive the brevity, the typos and the lack >of nuance. > > Confidentiality Notice: > > The information transmitted is intended only for the person(s) >or entity to which it is addressed and may contain confidential and >/or privileged material. Any review, retransmission, dissemination or >other use of, or taking of any action in reliance upon, this >information by persons or entities other than the intended recipient >is prohibited. If you receive this in error, please contact the >sender and delete the material from any computer. > > This email has been scanned for viruses and malware, and may >have been automatically archived. > Think Green! Before printing this e-mail ask the question, is it >necessary? > > > > -------- Original Message -------- > From: Outages on behalf of Nick >Pron via Outages > Date: Tue, November 20, 2018 9:38 AM -0600 > To: outages at outages.org > Subject: Re: [outages] facebook slow > > >Caution: The e-mail below originated from an external source. Please >do not open attachments or click links from an unknown or suspicious >origin. > >Report suspicious e-mails here . >PLEASE, DO NOT FORWARD POTENTIALLY SUSPICIOUS E-MAILS, DELETE THEM >INSTEAD. > > > Just saying that FB is integrated with a lot of applications >with their Connect platform... Knowing it could be down could be >useful for some folks… > > > > Just because you guys dislike/don’t use FB doesn’t mean it might >not be useful to some people > > > > > > Nick Pron | Senior Infrastructure Analyst, Computer Ops > > 1303 Yonge Street, Toronto, ON, M4T 2Y9, Canada > > P: 416-323-6610 ext. 6610 | Nick.Pron at cineplex.com > > Cineplex.com > > http://mediafiles.cineplex.com/emailsignature/HomeOffice_Cineple >x_Waterstone_EmailSignature_EN.jpg > > > > > > From: Outages On Behalf Of >Ferullo, Michael J. via Outages > Sent: Tuesday, November 20, 2018 10:25 AM > To: 'Steven McCrory' ; 'Mike Bolitho' >; outages at ics-il.net > Cc: 'outages at outages.org' > Subject: Re: [outages] facebook slow > > > > Also much in agreement here. I signed up for this list for >exactly what Mike stated: meaningful business critical services. I’d >suggest someone spearhead the creation of another list for anything >“social media” related. > > > > > > > > Michael J. Ferullo > Systems Administrator > > >________________________________ > > > Hinckley Allen > 28 State Street > Boston, MA 02109-1775 > p: 617-378-4226 | f: 617-345-9020 > mferullo at hinckleyallen.com > > > > From: Outages On Behalf Of Steven >McCrory via Outages > Sent: Tuesday, November 20, 2018 10:23 AM > To: 'Mike Bolitho' ; outages at ics-il.net; >outages at outages.org > Subject: Re: [outages] facebook slow > > > > Wholeheartedly agree > > > > From: Outages On Behalf Of Mike >Bolitho via Outages > Sent: 20 November 2018 15:18 > To: outages at ics-il.net > Cc: outages at outages.org > Subject: Re: [outages] facebook slow > > > > I would encourage everyone to revisit the info page for the >outages mailing list found here: >https://puck.nether.net/mailman/listinfo/outages > > > > "The purpose of this list is to have a central place to lookup >and report so that end users & network operators know why their >services (e-mail, phones, etc) went down eliminating the need to open >tons of trouble tickets during a major event. One master ticket - >such as fiber cut affect xxx OC48's would suffice. We hope this would >empower users and network operators to post such events so that >everyone could benefit from it. " > > > > The list is for reporting outages on carrier networks and has >grown to cloud services (AWS, Azure) as those have expanded. Facebook >is not a provider of any meaningful business critical services, and >therefore does not fit in this forum. > > > > - Mike Bolitho > > > > > > On Tue, Nov 20, 2018 at 7:57 AM Mike Hammett via Outages > wrote: > > Facebook is a fairly commonly used service. > > Also, it's currently broken and has been so for about an >hour. > > > > ----- > Mike Hammett > Intelligent Computing Solutions web.cisco.com/105opyZyNNLiLGlF1yoM0QSbPQe6gfXol140tqytrj_O9_I315Q9gSb >Bc6IkXVH0KC3dX0dYG24fw_k9pAxAM_75la4EK3fdJQnNzA- >CX7jitUzyNvVSsUAS5VjGe5ZMdCwUqoZgMV3ZtNhlyaiqmtxZY1- >Ohsq5peVy8bzzWe760lJB-HWUncs_P68XuXOUR0dOtK_nhy0Vk_qv57Poyz- >YdhwqcfEerMx4EBo- >3xB8baTgAzHz38b3T6MV5B9KSU4BdatFCaupPBL2qe9nzEg/http%3A%2F%2Fwww.ics- >il.com%2F> > > > > > Midwest Internet Exchange > > > > The Brothers WISP web.cisco.com/1FwZkVeDpigayFgrMjyqfZim4gJXMZM_XZAU1XIftns_qGv2KUfrt2U >E4E6j3Jr1TbfoEujIthggmUEzqeyJaQ7Bgg_94KTAbHyrAZei1CbpTdqjgpB5mEGD_VVn >RYlJhBrPfnvs2EbnK2JlaXB0XVuhe9JUzbPo6VDtK9G3o8RDHR01WbnFpG5sCsU3M4geB >aZa6Sm0QJSXU3VnsxP2LNw25IvEd4jAHOQQSybDraVRloPPSFFO1kREXDwyWACbZzAsNU >4YVPEpwZiwBvwjWDA/http%3A%2F%2Fwww.thebrotherswisp.com%2F> > > > > >________________________________ > > > From: "Tanner Ryan via Outages" > To: "jimmy keffer" > Cc: outages at outages.org > Sent: Tuesday, November 20, 2018 8:50:40 AM > Subject: Re: [outages] facebook slow > > I don’t see the point of sending this in the outages >mailing list. > > > > > > Best, > > Tanner Ryan web.cisco.com/1fu4ggC10rNErrmEU-eiRWzagI_-sDOnXaEYE-yYCufmkNEVyWpB- >2B3bayXrQSB7BeEsu2K4qOOYBgjPkgKsLUL- >lpZ0M40UaChX6Eolc8M8VNl7y4XdKHyLHjXjwdCXBxwrTAQPNrOSAoreVrnoEjEI0kX__ >LxATQuT6inaRDuT7SroUEAX8zVEOhHFQkl_eWD1trLCg7PLQqM5IGsN0xj_3kXb- >XsjmuDa4E59mj4- >RwCc5ZnjbubNfOENqoYEt7mhspR9XihsGh6U1T1Kxg/https%3A%2F%2FTannerRyan.c >a> > canadatechguy at gmail.com > > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > > > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > > > > > > _______________________________________________ > Outages mailing list > Outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > From valdis.kletnieks at vt.edu Fri Nov 30 21:12:27 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 30 Nov 2018 16:12:27 -0500 Subject: [outages] facebook slow In-Reply-To: References: Message-ID: <56093.1543612347@turing-police.cc.vt.edu> On Fri, 30 Nov 2018 13:16:31 -0700, "Keith Medcalf" said: > Why don't you just write all your password on big sheets of construction > paper and put them on the front of the building or in the nearest Starbucks? I'm going to go out on a limb and say that with all the problems inherent in using a social media account as an authenticator, for 95% of sites it's still more secure than if they attempted to create their own authentication system. Having even less security expertise than Facebook, they will probably get wrong (possibly in a subtle fashion that gets quietly exploited for years, and possibly in a spectacular fashion that makes it on the evening news). There's the additional factor that security is always about trade-offs - for many sites, the dangers of using social media logins are *far* outweighed by being able to just have a big shiny "Log in using Facebook" button instead of making the user set up an account, pick a password, send them a verification e-mail, then they have to read their e-mail and click on the link. Do that, and they just left for another site. Doesn't take many people leaving for another site before any added "security" added by doing authentication yourself is outweighed by lost traffic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From yanzhai at cs.wisc.edu Fri Nov 30 22:25:06 2018 From: yanzhai at cs.wisc.edu (Yan Zhai) Date: Fri, 30 Nov 2018 16:25:06 -0600 Subject: Research survey about cloud services operations Message-ID: Hi there, we are researchers from University of Wisconsin Madison. Our research is about cloud computing and system security. Currently we are surveying on a few facts about how cloud tenants operate their services. The purpose of the survey is to justify a few design questions so that our research can be practical for real world applications. I am wondering if you could kindly help us by filling out a few simple general questions hosted on Typeform: https://yanzhai.typeform.com/to/sZ0Yjm . The survey is fully anonymous. Any of your feedback would be greatly appreciated! Thank you very much! Yan -------------- next part -------------- An HTML attachment was scrubbed... URL: