From nanog at ics-il.net Mon Jan 1 16:17:43 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 1 Jan 2018 10:17:43 -0600 (CST) Subject: Carrier IRR Update Frequency In-Reply-To: <1688043287.11593.1514823353762.JavaMail.mhammett@ThunderFuck> Message-ID: <1489804618.11598.1514823461505.JavaMail.mhammett@ThunderFuck> Any idea how often Cogent, XO, and Level 3 update their prefix filters from the IRRDBs? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From nanog at ics-il.net Mon Jan 1 17:14:58 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 1 Jan 2018 11:14:58 -0600 (CST) Subject: Carrier IRR Update Frequency In-Reply-To: <7373693C-B4D8-40E1-B800-F280152FF589@lixfeld.ca> References: <1489804618.11598.1514823461505.JavaMail.mhammett@ThunderFuck> <7373693C-B4D8-40E1-B800-F280152FF589@lixfeld.ca> Message-ID: <1584066577.11667.1514826895201.JavaMail.mhammett@ThunderFuck> Maybe not. My client's upstream just said they released the prefix to their upstreams. They had previously referenced IRRs. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jason Lixfeld" To: "Mike Hammett" Cc: "NANOG list" Sent: Monday, January 1, 2018 10:58:00 AM Subject: Re: Carrier IRR Update Frequency Cogent does IRR filtering? Sent from my iPhone > On Jan 1, 2018, at 11:17 AM, Mike Hammett wrote: > > Any idea how often Cogent, XO, and Level 3 update their prefix filters from the IRRDBs? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com From bernat at luffy.cx Mon Jan 1 18:46:02 2018 From: bernat at luffy.cx (Vincent Bernat) Date: Mon, 01 Jan 2018 19:46:02 +0100 Subject: Carrier IRR Update Frequency In-Reply-To: <1489804618.11598.1514823461505.JavaMail.mhammett@ThunderFuck> (Mike Hammett's message of "Mon, 1 Jan 2018 10:17:43 -0600 (CST)") References: <1489804618.11598.1514823461505.JavaMail.mhammett@ThunderFuck> Message-ID: ❦ 1 janvier 2018 10:17 -0600, Mike Hammett  : > Any idea how often Cogent, XO, and Level 3 update their prefix filters > from the IRRDBs? I got a recent answer from Cogent support stating they don't use IRR (at least for their customers). -- Consider well the proportions of things. It is better to be a young June-bug than an old bird of paradise. -- Mark Twain, "Pudd'nhead Wilson's Calendar" From listas at kurtkraut.net Mon Jan 1 20:31:01 2018 From: listas at kurtkraut.net (Kurt Kraut) Date: Mon, 1 Jan 2018 18:31:01 -0200 Subject: Carrier IRR Update Frequency In-Reply-To: <1489804618.11598.1514823461505.JavaMail.mhammett@ThunderFuck> References: <1688043287.11593.1514823353762.JavaMail.mhammett@ThunderFuck> <1489804618.11598.1514823461505.JavaMail.mhammett@ThunderFuck> Message-ID: Hello, Seabone/LANautilus/TI Sparkle (AS6762), an italian Tier-1 with strong footprint in Latin America updates it once a day at 06:00 AM at Milan time. If I recall correctly, only during business days. Works like a charm. Best regards, Kurt Kraut 2018-01-01 14:17 GMT-02:00 Mike Hammett : > Any idea how often Cogent, XO, and Level 3 update their prefix filters > from the IRRDBs? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From nanog at ics-il.net Mon Jan 1 23:40:20 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 1 Jan 2018 17:40:20 -0600 (CST) Subject: XO Ping Pong Message-ID: <1368195353.12155.1514850018867.JavaMail.mhammett@ThunderFuck> 6 216.55.14.14 0% 1 23.4ms 23.4 23.4 23.4 0 7 216.55.14.13 0% 1 23.5ms 23.5 23.5 23.5 0 8 216.55.14.14 0% 1 23.8ms 23.8 23.8 23.8 0 9 216.55.14.13 0% 1 23.9ms 23.9 23.9 23.9 0 Can someone at XO contact me offlist for more specific path information? I'm not an XO customer, else I would use their looking glass (which is locked to customers only) or support to look into this further. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From valdis.kletnieks at vt.edu Tue Jan 2 01:13:02 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 01 Jan 2018 20:13:02 -0500 Subject: Threads that never end (was: Waste will kill ipv6 too) In-Reply-To: References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <603f760e-351d-af6b-0956-ddb1e145d416@satchell.net> <20171230154600.GB4208@sizone.org> <20171230233905.GK6349@sizone.org> Message-ID: <110489.1514855582@turing-police.cc.vt.edu> On Sun, 31 Dec 2017 13:36:32 +0900, Randy Bush said: > thomas watson: i think there is a world market for maybe five computers "The Yale Book of Quotations quotes an I.B.M. source that this '... is a misunderstanding of remarks made at I.B.M.'s annual stockholders meeting on April 28, 1953. In referring specifically and only to the I.B.M. 701 Electronic Data Processing Machine ... Thomas Watson, Jr., told stockholders that 'I.B.M. had developed a paper plan for such a machine and took this paper plan across the country to some 20 concerns that we thought could use such a machine. As a result of our trip, on which we expected to get orders for five machines, we came home with orders for 18.'" http://freakonomics.com/2008/04/17/our-daily-bleg-did-ibm-really-see-a-world-market-for-about-five-computers/ From trelane at trelane.net Tue Jan 2 03:09:15 2018 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 1 Jan 2018 22:09:15 -0500 Subject: Threads that never end (was: Waste will kill ipv6 too) In-Reply-To: References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <603f760e-351d-af6b-0956-ddb1e145d416@satchell.net> <20171230154600.GB4208@sizone.org> <20171230233905.GK6349@sizone.org> Message-ID: Lets say the worst case scenario is that we exhaust IPv6 at a rate MASSIVELY higher than planned. Can't we all just do this again in like 80 years? I don't get why anyone cares so much that this thread won't die. Speaking of dying, I'll be dead by then anyway. Andrew On Sat, Dec 30, 2017 at 11:36 PM, Randy Bush wrote: > > If anyone wants to TL;DR > > moe: 2^128 is effectively infinita > larry: we thought 2^32 was effectively infinite > curly: we'll never need more than 640k > thomas watson: i think there is a world market for maybe five computers > From Jeroen.Wunnink at gtt.net Tue Jan 2 09:09:10 2018 From: Jeroen.Wunnink at gtt.net (Jeroen Wunnink) Date: Tue, 2 Jan 2018 09:09:10 +0000 Subject: Foundry FastIron In-Reply-To: <483412848.471965.1513736318047.JavaMail.zimbra@ics-il.net> References: <483412848.471965.1513736318047.JavaMail.zimbra@ics-il.net> Message-ID: In my experience, Brocades in general aren’t very picky when it comes to working with any optic branding. It’s just the DOM that might or might not work. I’ve only ever had 1 vendor show issues with Brocade after an ironware upgrade. Can always grab a few brocade branded optics from Flexoptix Jeroen Wunnink Intergration Engineering www.gtt.net On 20/12/2017, 03:26, "NANOG on behalf of Mike Hammett" wrote: A client of mine has some Foundry FastIron Edge X424HFs. Brocade and Extreme don't seem overly ambitious to help. Anyone have any documentation they can scrounge up? SFP compatibility list? The ones I see in there already look substantially like the ones I get from FiberStore, but that doesn't mean much. Do they still sell support on these? I'm largely just interested in newer firmware for them. I don't think they were updated since they left the factory and there are a few quirks I'm hoping they addressed at some point. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From horsezip at earthlink.net Tue Jan 2 15:32:27 2018 From: horsezip at earthlink.net (jimmy keffer) Date: Tue, 02 Jan 2018 10:32:27 -0500 Subject: googhle voice hel Message-ID: any one here work for google voice or know any one who does i need to talk to some help pages aren't helping jimmy From bryan at shout.net Tue Jan 2 15:45:23 2018 From: bryan at shout.net (Bryan Holloway) Date: Tue, 2 Jan 2018 09:45:23 -0600 Subject: Carrier IRR Update Frequency In-Reply-To: <1489804618.11598.1514823461505.JavaMail.mhammett@ThunderFuck> References: <1489804618.11598.1514823461505.JavaMail.mhammett@ThunderFuck> Message-ID: <8191de66-6730-2d67-6b07-554039f1f979@shout.net> On 1/1/18 10:17 AM, Mike Hammett wrote: > Any idea how often Cogent, XO, and Level 3 update their prefix filters from the IRRDBs? > Back when I had Level3 circuits, they updated at midnight Mountain time. I don't know if that's still the case, especially now that CenturyLink has gobbled them up ... From mel at beckman.org Tue Jan 2 16:46:02 2018 From: mel at beckman.org (Mel Beckman) Date: Tue, 2 Jan 2018 16:46:02 +0000 Subject: Anyone else blacklisted this morning by rbl.iprange.net? Message-ID: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org> I woke up this morning to a barrage of complaints from users that our mail servers' outbound emails are bouncing due to a blacklisting. Sure enough, mxtoolbox.com reports that rbl.iprange.net has blacklisted us for more than a day. However, looking up our address on the rbl.iprange.net lookup webpage shows we're NOT listed. But a check of the RBL's DNS shows that we are. Then I found this on the rbl.iprange.net owner's website (): "rbl.iprange.net (is offline since 01-01-2018) please replace it with rbl.realtimeblacklist.com rbl.iprange.net will mark every ip address as listed to force removal of this server." What the heck? I've tried contacting realtimeblacklisk.com, but they're in the Netherlands and apparently fast asleep (in more ways than one, it seems). -mel beckman From DannSchuler at hotmail.com Tue Jan 2 16:57:51 2018 From: DannSchuler at hotmail.com (Dann Schuler) Date: Tue, 2 Jan 2018 16:57:51 +0000 Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org> References: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org> Message-ID: We had a Charter IP address we don’t actually send email from (it is a backup line that would only send mail if our primary line was down) Blacklisted by these guys at 10:50am EST on 1/1/18, then removed at 3:34pm EST on 1/1/18. MXToolBox alerted us to it, I ran a manual check on their portal, which is supposed to be http://iprange.net/rbl/lookup/ but redirects to https://realtimeblacklist.com/lookup/ and it came back not listed. Since it was a line I knew we were not mailing from anyways I figured I would just deal with it in the morning, but it had cleared itself up by then. First time I had ever even heard of this one. Good luck! -----Original Message----- From: NANOG [mailto:nanog-bounces+dannschuler=hotmail.com at nanog.org] On Behalf Of Mel Beckman Sent: Tuesday, January 2, 2018 11:46 AM To: nanog at nanog.org Subject: Anyone else blacklisted this morning by rbl.iprange.net? I woke up this morning to a barrage of complaints from users that our mail servers' outbound emails are bouncing due to a blacklisting. Sure enough, mxtoolbox.com reports that rbl.iprange.net has blacklisted us for more than a day. However, looking up our address on the rbl.iprange.net lookup webpage shows we're NOT listed. But a check of the RBL's DNS shows that we are. Then I found this on the rbl.iprange.net owner's website (): "rbl.iprange.net (is offline since 01-01-2018) please replace it with rbl.realtimeblacklist.com rbl.iprange.net will mark every ip address as listed to force removal of this server." What the heck? I've tried contacting realtimeblacklisk.com, but they're in the Netherlands and apparently fast asleep (in more ways than one, it seems). -mel beckman From rsk at gsp.org Tue Jan 2 17:04:09 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 2 Jan 2018 12:04:09 -0500 Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org> References: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org> Message-ID: <20180102170409.GA5619@gsp.org> On Tue, Jan 02, 2018 at 04:46:02PM +0000, Mel Beckman quoted: > "rbl.iprange.net will mark every ip address as listed to force removal of this server." Apparently they didn't read section 3.4 of RFC 6471: https://tools.ietf.org/html/rfc6471#page-15 Given this behavior on their part, it would seem best to not only immediately remove their old DNSBL from mail system configurations, but to never add their new one. ---rsk From jlewis at lewis.org Tue Jan 2 17:10:05 2018 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 2 Jan 2018 12:10:05 -0500 (EST) Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org> References: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org> Message-ID: On Tue, 2 Jan 2018, Mel Beckman wrote: > I woke up this morning to a barrage of complaints from users that our mail servers' outbound emails are bouncing due to a blacklisting. Sure enough, mxtoolbox.com reports that rbl.iprange.net has blacklisted us for more than a day. However, looking up our address on the rbl.iprange.net lookup webpage shows we're NOT listed. But a check of the RBL's DNS shows that we are. Then I found this on the rbl.iprange.net owner's website (): > > "rbl.iprange.net (is offline since 01-01-2018) please replace it with rbl.realtimeblacklist.com > rbl.iprange.net will mark every ip address as listed to force removal of this server." > > What the heck? I've tried contacting realtimeblacklisk.com, but they're in the Netherlands and apparently fast asleep (in more ways than one, it seems). If you do manage to get ahold of anyone there, you might suggest they read section 3.4 of https://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists-10 There's a right way to shut down a DNSBL that's been tested and used by others. Listing the world is not the right way. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mel at beckman.org Tue Jan 2 17:11:02 2018 From: mel at beckman.org (Mel Beckman) Date: Tue, 2 Jan 2018 17:11:02 +0000 Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: References: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org>, Message-ID: Apparently they're widely used by firewall-based anti spam, as we seem to be getting blocked a lot by Juniper, Sonicwall, and Palo Alto firewalls. The outfit is listed in https://en.m.wikipedia.org/wiki/Comparison_of_DNS_blacklists, but seem to have very poor communication options (e.g., WhoIs is obscured). Why don't they just quit answering DNS queries at rbl.iprange.net? Sheesh! -mel > On Jan 2, 2018, at 8:58 AM, Dann Schuler wrote: > > We had a Charter IP address we don’t actually send email from (it is a backup line that would only send mail if our primary line was down) Blacklisted by these guys at 10:50am EST on 1/1/18, then removed at 3:34pm EST on 1/1/18. > > MXToolBox alerted us to it, I ran a manual check on their portal, which is supposed to be http://iprange.net/rbl/lookup/ but redirects to https://realtimeblacklist.com/lookup/ and it came back not listed. Since it was a line I knew we were not mailing from anyways I figured I would just deal with it in the morning, but it had cleared itself up by then. > > First time I had ever even heard of this one. > > Good luck! > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+dannschuler=hotmail.com at nanog.org] On Behalf Of Mel Beckman > Sent: Tuesday, January 2, 2018 11:46 AM > To: nanog at nanog.org > Subject: Anyone else blacklisted this morning by rbl.iprange.net? > > I woke up this morning to a barrage of complaints from users that our mail servers' outbound emails are bouncing due to a blacklisting. Sure enough, mxtoolbox.com reports that rbl.iprange.net has blacklisted us for more than a day. However, looking up our address on the rbl.iprange.net lookup webpage shows we're NOT listed. But a check of the RBL's DNS shows that we are. Then I found this on the rbl.iprange.net owner's website (): > > "rbl.iprange.net (is offline since 01-01-2018) please replace it with rbl.realtimeblacklist.com > rbl.iprange.net will mark every ip address as listed to force removal of this server." > > What the heck? I've tried contacting realtimeblacklisk.com, but they're in the Netherlands and apparently fast asleep (in more ways than one, it seems). > > -mel beckman From mel at beckman.org Tue Jan 2 17:15:57 2018 From: mel at beckman.org (Mel Beckman) Date: Tue, 2 Jan 2018 17:15:57 +0000 Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: References: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org>, Message-ID: LOL! Apparently Level3 (my upstream) at least has blacklisted their IP, way before it gets anywhere near the Netherlands! traceroute rbl.iprange.net traceroute to rbl.iprange.net (80.127.112.180), 64 hops max, 40 byte packets 1 router1.sb.becknet.com (206.83.0.1) 0.862 ms 0.415 ms 0.365 ms 2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.817 ms 1.234 ms 0.734 ms 3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 2.933 ms 3.023 ms 2.928 ms 4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 3.040 ms 2.996 ms 3.040 ms 5 * * * 6 * * * 7 * * * Thank you Level3! Now if other major backbone providers will do the same, we might inoculate the Internet from this ignorant RBL operator quickly. -mel > On Jan 2, 2018, at 9:10 AM, Jon Lewis wrote: > >> On Tue, 2 Jan 2018, Mel Beckman wrote: >> >> I woke up this morning to a barrage of complaints from users that our mail servers' outbound emails are bouncing due to a blacklisting. Sure enough, mxtoolbox.com reports that rbl.iprange.net has blacklisted us for more than a day. However, looking up our address on the rbl.iprange.net lookup webpage shows we're NOT listed. But a check of the RBL's DNS shows that we are. Then I found this on the rbl.iprange.net owner's website (): >> >> "rbl.iprange.net (is offline since 01-01-2018) please replace it with rbl.realtimeblacklist.com >> rbl.iprange.net will mark every ip address as listed to force removal of this server." >> >> What the heck? I've tried contacting realtimeblacklisk.com, but they're in the Netherlands and apparently fast asleep (in more ways than one, it seems). > > If you do manage to get ahold of anyone there, you might suggest they read section 3.4 of > > https://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists-10 > > There's a right way to shut down a DNSBL that's been tested and used by others. Listing the world is not the right way. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bzs at theworld.com Tue Jan 2 18:37:22 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 2 Jan 2018 13:37:22 -0500 Subject: Threads that never end (was: Waste will kill ipv6 too) In-Reply-To: References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <603f760e-351d-af6b-0956-ddb1e145d416@satchell.net> <20171230154600.GB4208@sizone.org> <20171230233905.GK6349@sizone.org> Message-ID: <23115.53602.237157.64636@gargle.gargle.HOWL> On January 1, 2018 at 22:09 trelane at trelane.net (Andrew Kirch) wrote: > Lets say the worst case scenario is that we exhaust IPv6 at a rate > MASSIVELY higher than planned. Can't we all just do this again in like 80 > years? I don't get why anyone cares so much that this thread won't die. > > Speaking of dying, I'll be dead by then anyway. One more time, the concern is not running out of ~2^128 addresses per se. The concern is running out of 128 bits due to segmentation and sparse allocations. A few bits for this (my unfounded example was handing the ITU a /8 for re-allocation as they see fit), a few bits for that, etc. Who was it who owned 2 x /8s of IPv4 space? AT&T? HP? Someone, I could look it up. What was the utilization of those blocks? And multicast, and 1914 space, and on and on. When one thinks of it like that, as chunks of the 128 bits, it doesn't look so vast, and it feels more vulnerable to politics, for example some nation demanding they act as their own RIR with a large allocation block, or just some clever new use, address blocks as cryptocurrency, address blocks with special, magical security policies, experimental uses, etc. Time, and howlings of pain should it come to that, will tell. At this point in time it's just dark speculation. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From owen at delong.com Tue Jan 2 21:59:46 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Jan 2018 13:59:46 -0800 Subject: Threads that never end (was: Waste will kill ipv6 too) In-Reply-To: <23115.53602.237157.64636@gargle.gargle.HOWL> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <603f760e-351d-af6b-0956-ddb1e145d416@satchell.net> <20171230154600.GB4208@sizone.org> <20171230233905.GK6349@sizone.org> <23115.53602.237157.64636@gargle.gargle.HOWL> Message-ID: <4684D2CF-DEA6-4581-AB9C-591CE31B6C2A@delong.com> I agree we all have a responsibility to hold the line on addresses being network identifiers and to some extent network locators (unfortunately). I agree we have a responsibility to sparsely and liberally allocate within reason (where /8 to ITU isn’t within reason, but a /12 might be, and even if we have every country that wanted one a /16 to play with, that’s not likely to hurt much). You’re absolutely right that if we get completely stupid beyond the bounds of current address planning we can waste IPv6 into oblivion. However, in a realistic discussion of whether it’s harmful or not to allocate /48s to residences and allocate /64s to point to point links, I don’t think there’s any valid argument that being stingy and putting /127s densely on point to point links with residences getting only a /60 each will somehow miraculously save us from any such actions. Part of the reason threads like this don’t die is because people get so focused on their (poorly expressed) ideology that they often are agreeing without realizing it. Owen > On Jan 2, 2018, at 10:37, bzs at theworld.com wrote: > > >> On January 1, 2018 at 22:09 trelane at trelane.net (Andrew Kirch) wrote: >> Lets say the worst case scenario is that we exhaust IPv6 at a rate >> MASSIVELY higher than planned. Can't we all just do this again in like 80 >> years? I don't get why anyone cares so much that this thread won't die. >> >> Speaking of dying, I'll be dead by then anyway. > > One more time, the concern is not running out of ~2^128 addresses per se. > > The concern is running out of 128 bits due to segmentation and sparse > allocations. A few bits for this (my unfounded example was handing the > ITU a /8 for re-allocation as they see fit), a few bits for that, etc. > > Who was it who owned 2 x /8s of IPv4 space? AT&T? HP? Someone, I could > look it up. What was the utilization of those blocks? And multicast, > and 1914 space, and on and on. > > When one thinks of it like that, as chunks of the 128 bits, it doesn't > look so vast, and it feels more vulnerable to politics, for example > some nation demanding they act as their own RIR with a large > allocation block, or just some clever new use, address blocks as > cryptocurrency, address blocks with special, magical security > policies, experimental uses, etc. > > Time, and howlings of pain should it come to that, will tell. > > At this point in time it's just dark speculation. > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* From outsider at scarynet.org Tue Jan 2 22:02:38 2018 From: outsider at scarynet.org (Alexander Maassen) Date: Tue, 2 Jan 2018 23:02:38 +0100 Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: References: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org> Message-ID: As the message said, they use this to force mx admins to remove their entry to stop hammering. I remember other lists did the same. Contact the remote mx admin in order to get this fixed. > Op 2 jan. 2018 om 17:57 heeft Dann Schuler het volgende geschreven: > > We had a Charter IP address we don’t actually send email from (it is a backup line that would only send mail if our primary line was down) Blacklisted by these guys at 10:50am EST on 1/1/18, then removed at 3:34pm EST on 1/1/18. > > MXToolBox alerted us to it, I ran a manual check on their portal, which is supposed to be http://iprange.net/rbl/lookup/ but redirects to https://realtimeblacklist.com/lookup/ and it came back not listed. Since it was a line I knew we were not mailing from anyways I figured I would just deal with it in the morning, but it had cleared itself up by then. > > First time I had ever even heard of this one. > > Good luck! > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+dannschuler=hotmail.com at nanog.org] On Behalf Of Mel Beckman > Sent: Tuesday, January 2, 2018 11:46 AM > To: nanog at nanog.org > Subject: Anyone else blacklisted this morning by rbl.iprange.net? > > I woke up this morning to a barrage of complaints from users that our mail servers' outbound emails are bouncing due to a blacklisting. Sure enough, mxtoolbox.com reports that rbl.iprange.net has blacklisted us for more than a day. However, looking up our address on the rbl.iprange.net lookup webpage shows we're NOT listed. But a check of the RBL's DNS shows that we are. Then I found this on the rbl.iprange.net owner's website (): > > "rbl.iprange.net (is offline since 01-01-2018) please replace it with rbl.realtimeblacklist.com > rbl.iprange.net will mark every ip address as listed to force removal of this server." > > What the heck? I've tried contacting realtimeblacklisk.com, but they're in the Netherlands and apparently fast asleep (in more ways than one, it seems). > > -mel beckman From lists.nanog at monmotha.net Tue Jan 2 22:07:38 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 2 Jan 2018 17:07:38 -0500 Subject: Foundry FastIron In-Reply-To: References: <483412848.471965.1513736318047.JavaMail.zimbra@ics-il.net> Message-ID: On 01/02/2018 04:09 AM, Jeroen Wunnink wrote: > In my experience, Brocades in general aren’t very picky when it comes to working with any optic branding. It’s just the DOM that might or might not work. > I’ve only ever had 1 vendor show issues with Brocade after an ironware upgrade. This applies to the Foundry-lineage stuff. The Brocade-lineage stuff, especially anything having to do with Fibre Channel, is sometimes locked to Brocade-ROM'd parts only. The somewhat popular/cheap 10GbE/FCoE cards floating around exhibit this. -- Brandon Martin From mel at beckman.org Tue Jan 2 22:10:03 2018 From: mel at beckman.org (Mel Beckman) Date: Tue, 2 Jan 2018 22:10:03 +0000 Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: References: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org> , Message-ID: <79BF68AF-537C-4FE4-9323-AF99D55EAB70@beckman.org> I did finally reach someone at realtimeblacklist.com. They've just today shut down the bogus DNS RBL and said they realize now it was a terrible idea. They read and now understand the RBL RFC and promised not to do it again. I appreciate them taking the time to respond, and hopefully they'll also improve their communication channels (such as putting meaningful contact info in their WhoIs. It's ironic that an anti-spam operator, of all people, would hide this info!) -mel > On Jan 2, 2018, at 2:04 PM, Alexander Maassen wrote: > > As the message said, they use this to force mx admins to remove their entry to stop hammering. I remember other lists did the same. Contact the remote mx admin in order to get this fixed. > >> Op 2 jan. 2018 om 17:57 heeft Dann Schuler het volgende geschreven: >> >> We had a Charter IP address we don’t actually send email from (it is a backup line that would only send mail if our primary line was down) Blacklisted by these guys at 10:50am EST on 1/1/18, then removed at 3:34pm EST on 1/1/18. >> >> MXToolBox alerted us to it, I ran a manual check on their portal, which is supposed to be http://iprange.net/rbl/lookup/ but redirects to https://realtimeblacklist.com/lookup/ and it came back not listed. Since it was a line I knew we were not mailing from anyways I figured I would just deal with it in the morning, but it had cleared itself up by then. >> >> First time I had ever even heard of this one. >> >> Good luck! >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces+dannschuler=hotmail.com at nanog.org] On Behalf Of Mel Beckman >> Sent: Tuesday, January 2, 2018 11:46 AM >> To: nanog at nanog.org >> Subject: Anyone else blacklisted this morning by rbl.iprange.net? >> >> I woke up this morning to a barrage of complaints from users that our mail servers' outbound emails are bouncing due to a blacklisting. Sure enough, mxtoolbox.com reports that rbl.iprange.net has blacklisted us for more than a day. However, looking up our address on the rbl.iprange.net lookup webpage shows we're NOT listed. But a check of the RBL's DNS shows that we are. Then I found this on the rbl.iprange.net owner's website (): >> >> "rbl.iprange.net (is offline since 01-01-2018) please replace it with rbl.realtimeblacklist.com >> rbl.iprange.net will mark every ip address as listed to force removal of this server." >> >> What the heck? I've tried contacting realtimeblacklisk.com, but they're in the Netherlands and apparently fast asleep (in more ways than one, it seems). >> >> -mel beckman > From eyeronic.design at gmail.com Tue Jan 2 22:10:30 2018 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 2 Jan 2018 14:10:30 -0800 Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: References: <2076799A-9CFD-45E1-8AE7-7D7DC1A58673@beckman.org> Message-ID: But what other people have rightfully pointed out is that his behavior is stupid and against the RFC that covers DNSBLs. And it's not simply MX admins here. You have firewalls that are also affected. If you're going to run a DNSBL to advertise your mail software, perhaps do so in a way that doesn't flip the bird at everyone using it. On Tue, Jan 2, 2018 at 2:02 PM, Alexander Maassen wrote: > As the message said, they use this to force mx admins to remove their entry to stop hammering. I remember other lists did the same. Contact the remote mx admin in order to get this fixed. > >> Op 2 jan. 2018 om 17:57 heeft Dann Schuler het volgende geschreven: >> >> We had a Charter IP address we don’t actually send email from (it is a backup line that would only send mail if our primary line was down) Blacklisted by these guys at 10:50am EST on 1/1/18, then removed at 3:34pm EST on 1/1/18. >> >> MXToolBox alerted us to it, I ran a manual check on their portal, which is supposed to be http://iprange.net/rbl/lookup/ but redirects to https://realtimeblacklist.com/lookup/ and it came back not listed. Since it was a line I knew we were not mailing from anyways I figured I would just deal with it in the morning, but it had cleared itself up by then. >> >> First time I had ever even heard of this one. >> >> Good luck! >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces+dannschuler=hotmail.com at nanog.org] On Behalf Of Mel Beckman >> Sent: Tuesday, January 2, 2018 11:46 AM >> To: nanog at nanog.org >> Subject: Anyone else blacklisted this morning by rbl.iprange.net? >> >> I woke up this morning to a barrage of complaints from users that our mail servers' outbound emails are bouncing due to a blacklisting. Sure enough, mxtoolbox.com reports that rbl.iprange.net has blacklisted us for more than a day. However, looking up our address on the rbl.iprange.net lookup webpage shows we're NOT listed. But a check of the RBL's DNS shows that we are. Then I found this on the rbl.iprange.net owner's website (): >> >> "rbl.iprange.net (is offline since 01-01-2018) please replace it with rbl.realtimeblacklist.com >> rbl.iprange.net will mark every ip address as listed to force removal of this server." >> >> What the heck? I've tried contacting realtimeblacklisk.com, but they're in the Netherlands and apparently fast asleep (in more ways than one, it seems). >> >> -mel beckman > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From lists at mtin.net Tue Jan 2 22:25:18 2018 From: lists at mtin.net (Justin Wilson) Date: Tue, 2 Jan 2018 17:25:18 -0500 Subject: Xbox Live and Teredo Message-ID: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> Figured the collective here might have an answer. All of a sudden a network I manage started getting complaints from XBOX live users are getting error messages about “Can’t get Teredo IP address” on their consoles. Is anyone else seeing this wide spread? The Microsoft support default answer is “Your ISP is blocking ports” when I can do an nmap on each of these customers and all of the xbox live ports are open. As an FYI these are not netted customers, but have true publics. We have tried disabling IPV6 on their interfaces and that does not seem to have helped. We have had some customers power cycle everything in their home (CPE, router, xbox) and still no go. Anyone else running into this? Does Microsoft have a higher level support for talking with ISPs at all? Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com From James at arenalgroup.co Tue Jan 2 22:46:35 2018 From: James at arenalgroup.co (James Breeden) Date: Tue, 2 Jan 2018 22:46:35 +0000 Subject: AS Numbers unused/sitting for long periods of time Message-ID: Before I take this to the ARIN PPML, wanted to get NANOG's thoughts. I'm amazed at the number of AS numbers that are assigned, but not actively being used. I'm not talking just like they are offline for a week or month, this is complete non-use of the AS in the global routing table within *years*. They are completely abandoned resources - Whois data is inaccurate by 5-10 years, no routeviews data in the same time period, the owning organization (if you can find it) scratches their heads about responding whether they use it or not, etc. I know we're currently not in a push to get AS numbers or close to exhaustion, but I do believe that people who have global AS numbers should have a requirement to use them or return them to the global pool. Am I the only one thinking this? And before you come back with "Well they may be using it internally where it doesn't need to be in the GRT" - that's why we have Private AS numbers. I.e. some form of ARIN or global policy that basically says "If AS number not routed or whois updated or used in 24 months, said AS number can be public noticed via mailing list and website and then revoked and reissued to a pending, approved AS request" Just thinking aloud. Happy New Year all! James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co From cma at cmadams.net Tue Jan 2 22:56:13 2018 From: cma at cmadams.net (Chris Adams) Date: Tue, 2 Jan 2018 16:56:13 -0600 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: <20180102225613.GA4612@cmadams.net> Once upon a time, James Breeden said: > I'm amazed at the number of AS numbers that are assigned, but not actively being used. I'm not talking just like they are offline for a week or month, this is complete non-use of the AS in the global routing table within *years*. They are completely abandoned resources - Whois data is inaccurate by 5-10 years, no routeviews data in the same time period, the owning organization (if you can find it) scratches their heads about responding whether they use it or not, etc. I know of two (from a former job) that pre-date ARIN that haven't been used since 1999 because those two companies no longer exist (nor AFAIK does any successor company). The whois information is bogus at this point, but I couldn't prove that. I expect that AS numbers allocated by ARIN and other current RIRs are not abandoned like that (since they charge annual fees, and I assume they reclaim for non-payment), so the number of abandoned AS numbers is probably not growing significantly (and would not grow beyond the pre-RIR pool). With 32 bit AS numbers though, what's the point of making an effort to reclaim the old AS numbers? BGP4 has been shown to handle alternate length AS numbers, so if somehow 4 billion are allocated, it probably won't be a big deal to extend BGP again. -- Chris Adams From marka at isc.org Tue Jan 2 22:57:02 2018 From: marka at isc.org (Mark Andrews) Date: Wed, 3 Jan 2018 09:57:02 +1100 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: <0CEB1CEA-ECAA-4444-A679-14FD5FFF2B50@isc.org> Just because a number is NOT VISIBLE on the global Internet, it does NOT mean that it is not IN USE. This applies to IPv4 addresses, IPv6 addresses and AS numbers. Apart from legacy IPv4 addresses and legacy AS, these resources require annual payments to maintain the assignment from the RIR. Mark > On 3 Jan 2018, at 9:46 am, James Breeden wrote: > > Before I take this to the ARIN PPML, wanted to get NANOG's thoughts. > > > I'm amazed at the number of AS numbers that are assigned, but not actively being used. I'm not talking just like they are offline for a week or month, this is complete non-use of the AS in the global routing table within *years*. They are completely abandoned resources - Whois data is inaccurate by 5-10 years, no routeviews data in the same time period, the owning organization (if you can find it) scratches their heads about responding whether they use it or not, etc. > > > I know we're currently not in a push to get AS numbers or close to exhaustion, but I do believe that people who have global AS numbers should have a requirement to use them or return them to the global pool. Am I the only one thinking this? > > > And before you come back with "Well they may be using it internally where it doesn't need to be in the GRT" - that's why we have Private AS numbers. > > > I.e. some form of ARIN or global policy that basically says "If AS number not routed or whois updated or used in 24 months, said AS number can be public noticed via mailing list and website and then revoked and reissued to a pending, approved AS request" > > > Just thinking aloud. Happy New Year all! > > > James W. Breeden > > Managing Partner > > > > [logo_transparent_background] > > Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media > > PO Box 1063 | Smithville, TX 78957 > > Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Tue Jan 2 23:03:46 2018 From: marka at isc.org (Mark Andrews) Date: Wed, 3 Jan 2018 10:03:46 +1100 Subject: Xbox Live and Teredo In-Reply-To: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> References: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> Message-ID: <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> Given that you have IPv6 I would be looking at why the XBOXs are attempting Teredo at all. I would expect them to use the IPv6 addresses that you are assigning your customers. Mark > On 3 Jan 2018, at 9:25 am, Justin Wilson wrote: > > Figured the collective here might have an answer. All of a sudden a network I manage started getting complaints from XBOX live users are getting error messages about “Can’t get Teredo IP address” on their consoles. Is anyone else seeing this wide spread? The Microsoft support default answer is “Your ISP is blocking ports” when I can do an nmap on each of these customers and all of the xbox live ports are open. As an FYI these are not netted customers, but have true publics. > > We have tried disabling IPV6 on their interfaces and that does not seem to have helped. We have had some customers power cycle everything in their home (CPE, router, xbox) and still no go. > > Anyone else running into this? Does Microsoft have a higher level support for talking with ISPs at all? > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cma at cmadams.net Tue Jan 2 23:06:58 2018 From: cma at cmadams.net (Chris Adams) Date: Tue, 2 Jan 2018 17:06:58 -0600 Subject: Xbox Live and Teredo In-Reply-To: <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> References: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> Message-ID: <20180102230658.GB4612@cmadams.net> Once upon a time, Mark Andrews said: > Given that you have IPv6 I would be looking at why the XBOXs are attempting Teredo at all. I would expect them to use the IPv6 addresses that you are assigning your customers. The OP didn't say what type of Xbox. IIRC the Xbox 360 does not support IPv6, while the Xbox One does (but neither would explain the Teredo). -- Chris Adams From snoble at sonn.com Tue Jan 2 23:11:57 2018 From: snoble at sonn.com (Steve Noble) Date: Tue, 02 Jan 2018 15:11:57 -0800 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: <20180102225613.GA4612@cmadams.net> References: <20180102225613.GA4612@cmadams.net> Message-ID: <5A4C11BD.7070407@sonn.com> Inaccurate whois data from ARIN is not a good way to tell anything as ARIN is terrible to deal with when you need to update an address or phone number or anything. I know personally as I had to fight for years to update the data on an ASN that ARIN was billing me to manage the data for. > Chris Adams > January 2, 2018 at 2:56 PM > > I know of two (from a former job) that pre-date ARIN that haven't been > used since 1999 because those two companies no longer exist (nor AFAIK > does any successor company). The whois information is bogus at this > point, but I couldn't prove that. > > I expect that AS numbers allocated by ARIN and other current RIRs are > not abandoned like that (since they charge annual fees, and I assume > they reclaim for non-payment), so the number of abandoned AS numbers is > probably not growing significantly (and would not grow beyond the > pre-RIR pool). > > With 32 bit AS numbers though, what's the point of making an effort to > reclaim the old AS numbers? BGP4 has been shown to handle alternate > length AS numbers, so if somehow 4 billion are allocated, it probably > won't be a big deal to extend BGP again. > > James Breeden > January 2, 2018 at 2:46 PM > Before I take this to the ARIN PPML, wanted to get NANOG's thoughts. > > > I'm amazed at the number of AS numbers that are assigned, but not > actively being used. I'm not talking just like they are offline for a > week or month, this is complete non-use of the AS in the global > routing table within *years*. They are completely abandoned resources > - Whois data is inaccurate by 5-10 years, no routeviews data in the > same time period, the owning organization (if you can find it) > scratches their heads about responding whether they use it or not, etc. > > > I know we're currently not in a push to get AS numbers or close to > exhaustion, but I do believe that people who have global AS numbers > should have a requirement to use them or return them to the global > pool. Am I the only one thinking this? > > > And before you come back with "Well they may be using it internally > where it doesn't need to be in the GRT" - that's why we have Private > AS numbers. > > > I.e. some form of ARIN or global policy that basically says "If AS > number not routed or whois updated or used in 24 months, said AS > number can be public noticed via mailing list and website and then > revoked and reissued to a pending, approved AS request" > > > Just thinking aloud. Happy New Year all! > > > James W. Breeden > > Managing Partner > > > > [logo_transparent_background] > > Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media > > PO Box 1063 | Smithville, TX 78957 > > Email: james at arenalgroup.co | office > 512.360.0000 | cell 512.304.0745 | > www.arenalgroup.co From lists at mtin.net Tue Jan 2 23:15:28 2018 From: lists at mtin.net (Justin Wilson) Date: Tue, 2 Jan 2018 18:15:28 -0500 Subject: Xbox Live and Teredo In-Reply-To: <20180102230658.GB4612@cmadams.net> References: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> <20180102230658.GB4612@cmadams.net> Message-ID: <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> These are all Xbox one clients. We don’t hand out IPv6 on this network yet, so I made sure to disable any sort of IPV6 on the interfaces just to be sure because I figured Teredo is tied to v6. The only thing we have not done yet is disable any IPV6 stuff on the customer routers. Everyone has been getting link local addresses for the longest time. We just disabled ipv6 totally on the interfaces just to be safe. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On Jan 2, 2018, at 6:06 PM, Chris Adams wrote: > > Once upon a time, Mark Andrews said: >> Given that you have IPv6 I would be looking at why the XBOXs are attempting Teredo at all. I would expect them to use the IPv6 addresses that you are assigning your customers. > > The OP didn't say what type of Xbox. IIRC the Xbox 360 does not support > IPv6, while the Xbox One does (but neither would explain the Teredo). > -- > Chris Adams > From marka at isc.org Tue Jan 2 23:19:22 2018 From: marka at isc.org (Mark Andrews) Date: Wed, 3 Jan 2018 10:19:22 +1100 Subject: Xbox Live and Teredo In-Reply-To: <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> References: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> <20180102230658.GB4612@cmadams.net> <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> Message-ID: Time to buy a Xbox for the NOC so you can trouble shoot. All puns intended. Mark > On 3 Jan 2018, at 10:15 am, Justin Wilson wrote: > > These are all Xbox one clients. We don’t hand out IPv6 on this network yet, so I made sure to disable any sort of IPV6 on the interfaces just to be sure because I figured Teredo is tied to v6. The only thing we have not done yet is disable any IPV6 stuff on the customer routers. Everyone has been getting link local addresses for the longest time. We just disabled ipv6 totally on the interfaces just to be safe. > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > >> On Jan 2, 2018, at 6:06 PM, Chris Adams wrote: >> >> Once upon a time, Mark Andrews said: >>> Given that you have IPv6 I would be looking at why the XBOXs are attempting Teredo at all. I would expect them to use the IPv6 addresses that you are assigning your customers. >> >> The OP didn't say what type of Xbox. IIRC the Xbox 360 does not support >> IPv6, while the Xbox One does (but neither would explain the Teredo). >> -- >> Chris Adams >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From job at ntt.net Tue Jan 2 23:21:09 2018 From: job at ntt.net (Job Snijders) Date: Tue, 2 Jan 2018 23:21:09 +0000 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: <20180102232109.GD13458@vurt.meerval.net> Dear James, On Tue, Jan 02, 2018 at 10:46:35PM +0000, James Breeden wrote: > Before I take this to the ARIN PPML, wanted to get NANOG's thoughts. > > I'm amazed at the number of AS numbers that are assigned, but not > actively being used. I'm not talking just like they are offline for a > week or month, this is complete non-use of the AS in the global > routing table within *years*. They are completely abandoned resources > - Whois data is inaccurate by 5-10 years, no routeviews data in the > same time period, the owning organization (if you can find it) > scratches their heads about responding whether they use it or not, > etc. > > I know we're currently not in a push to get AS numbers or close to > exhaustion, but I do believe that people who have global AS numbers > should have a requirement to use them or return them to the global > pool. Am I the only one thinking this? The most important property of ASNs assigned by RIRs is that they are globally _unique_. This doesn't mean they are globally visible. I worry that a proposal like this will introduce quite some work for all parties involved, for no obvious benefit. As you point out yourself we are nowhere close to exhaustion. > And before you come back with "Well they may be using it internally > where it doesn't need to be in the GRT" - that's why we have Private > AS numbers. I beg to differ, private ASNs are useful when you control all aspects of the administrative domain, but with M&A in mind, using globally unique ASNs can be quite beneficial. Or, maybe as the result of M&A you end up having multiple ASNs inside your network, but globally only one ASN is visible (confederations). > I.e. some form of ARIN or global policy that basically says "If AS > number not routed or whois updated or used in 24 months, said AS > number can be public noticed via mailing list and website and then > revoked and reissued to a pending, approved AS request" Uses of invisible ASNs include: lab networks, route servers, GRX exchanges, route collectors, etc. The Internet is more than what routeviews/RIS can see. All pending, approved AS requests can immediately be fullfilled, there is no shortage of ASNs. > Just thinking aloud. Happy New Year all! Same to you :-) Kind regards, Job From SNaslund at medline.com Tue Jan 2 23:31:38 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 2 Jan 2018 23:31:38 +0000 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: <5A4C11BD.7070407@sonn.com> References: <20180102225613.GA4612@cmadams.net> <5A4C11BD.7070407@sonn.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402899C423C@WAUPRDMBXP1.medline.com> I think the real issue here will be this : 1. If you are paying an RIR to maintain the registration it is yours to use unless the terms change to require you to justify usage on a recurring basis. 2. If it is pre-RIR I am not sure how you could change the rules at this point to reclaim an AS number. For example, I am sure the government hold hundreds that they are not using. I am also sure that they were given to them in block form. How would you undo that? I have a little bit of a problem with the "not visible to the Internet as a whole" test. There are a number of valid engineering reasons why an AS might not be visible today but may need to be tomorrow or be dynamically routing or not routing. Maybe you were dual homed and now you temporarily are not. Maybe you are transitioning your architecture to your shiny new IPv6 address space instead of your service provider's space. It would have to be a case by case justification which would hardly be worth the effort. If it was pre-RIR I am not sure how you would establish definitive contacts for old AS numbers. Please don't tell me WHOIS because that is completely inadequate for reclaiming something this significant. I suppose I would not have a problem with you contacting an entity and asking them voluntarily to give up an unused AS number but you better make sure you have the right guy on the phone and I would think there would need to be some kind of incentive for them to do so otherwise your default answer will be no. All in all it is much easier to support larger AS space than to reclaim the oldest foggiest AS numbers. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Noble >Sent: Tuesday, January 02, 2018 5:12 PM >To: nanog at nanog.org >Subject: Re: AS Numbers unused/sitting for long periods of time > >Inaccurate whois data from ARIN is not a good way to tell anything as ARIN is terrible to deal with when you need to update an address or phone number or anything. I know personally as I had to fight for years to update the data on >an ASN that ARIN was billing me to manage the data for. From dveit at microsoft.com Tue Jan 2 23:40:09 2018 From: dveit at microsoft.com (Darrin Veit) Date: Tue, 2 Jan 2018 23:40:09 +0000 Subject: Xbox Live and Teredo In-Reply-To: <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> References: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> <20180102230658.GB4612@cmadams.net> <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> Message-ID: Hey, Justin. I'll ping you offline to take a closer look. For others on the list, Xbox One uses Teredo for IPv4 P2P NAT traversal for multiplayer and chat. If the consoles are unable to communicate with Teredo servers to generate a Teredo IPv6 address and detect the NAT type that is present, that can cause issues joining multiplayer games and Party Chat sessions. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin Wilson Sent: Tuesday, January 2, 2018 3:15 PM To: NANOG list Subject: Re: Xbox Live and Teredo These are all Xbox one clients. We don’t hand out IPv6 on this network yet, so I made sure to disable any sort of IPV6 on the interfaces just to be sure because I figured Teredo is tied to v6. The only thing we have not done yet is disable any IPV6 stuff on the customer routers. Everyone has been getting link local addresses for the longest time. We just disabled ipv6 totally on the interfaces just to be safe. Justin Wilson j2sw at mtin.net https://na01.safelinks.protection.outlook.com/?url=www.mtin.net&data=02%7C01%7Cdveit%40microsoft.com%7C991c6b77eb124e576dd808d55236e511%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636505318085908776&sdata=q5nSKZiUbB0K5VvmN2bcOJ%2Fi9OuRVFFyL%2BaqX7uea24%3D&reserved=0 https://na01.safelinks.protection.outlook.com/?url=www.midwest-ix.com&data=02%7C01%7Cdveit%40microsoft.com%7C991c6b77eb124e576dd808d55236e511%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636505318085908776&sdata=leIx4fqr1OZfXXn1Z3wPWDigni6pLuV3h7JqwIA1%2Bxs%3D&reserved=0 > On Jan 2, 2018, at 6:06 PM, Chris Adams wrote: > > Once upon a time, Mark Andrews said: >> Given that you have IPv6 I would be looking at why the XBOXs are attempting Teredo at all. I would expect them to use the IPv6 addresses that you are assigning your customers. > > The OP didn't say what type of Xbox. IIRC the Xbox 360 does not > support IPv6, while the Xbox One does (but neither would explain the Teredo). > -- > Chris Adams > From bill at herrin.us Tue Jan 2 23:43:45 2018 From: bill at herrin.us (William Herrin) Date: Tue, 2 Jan 2018 18:43:45 -0500 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: On Tue, Jan 2, 2018 at 5:46 PM, James Breeden wrote: > I'm amazed at the number of AS numbers that are assigned, but not actively > being used. I'm not talking just like they are offline for a week or month, > this is complete non-use of the AS in the global routing table within > *years*. They are completely abandoned resources - Whois data is inaccurate > by 5-10 years, no routeviews data in the same time period, the owning > organization (if you can find it) scratches their heads about responding > whether they use it or not, etc. > Hi James, What's it worth to you? Literally, whats the maximum amount of money you're willing to spend on an AS number recovery effort before you figure, "meh, it's not worth it?" And before you come back with "Well they may be using it internally where > it doesn't need to be in the GRT" - that's why we have Private AS numbers. > Private AS numbers suffer from the same interconnection collision issues as private IP addresses and if you have a private AS it's *because* you're interconnecting networks. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Tue Jan 2 23:58:36 2018 From: bill at herrin.us (William Herrin) Date: Tue, 2 Jan 2018 18:58:36 -0500 Subject: Threads that never end (was: Waste will kill ipv6 too) In-Reply-To: <4684D2CF-DEA6-4581-AB9C-591CE31B6C2A@delong.com> References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <603f760e-351d-af6b-0956-ddb1e145d416@satchell.net> <20171230154600.GB4208@sizone.org> <20171230233905.GK6349@sizone.org> <23115.53602.237157.64636@gargle.gargle.HOWL> <4684D2CF-DEA6-4581-AB9C-591CE31B6C2A@delong.com> Message-ID: On Tue, Jan 2, 2018 at 4:59 PM, Owen DeLong wrote: > I agree we all have a responsibility to hold the line on addresses being > network identifiers Hi Owen, The delicious irony here is that EUI-64 supporting SLAAC is exactly that: an identifier. If we hold the line there, there is no line. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From jsklein at gmail.com Wed Jan 3 00:12:54 2018 From: jsklein at gmail.com (Joe Klein) Date: Tue, 2 Jan 2018 19:12:54 -0500 Subject: Xbox Live and Teredo In-Reply-To: References: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> <20180102230658.GB4612@cmadams.net> <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> Message-ID: Are you aware: - Microsofts justification for Teredo is to support P2P during the transition to IPv6 dominant networks. - Xbox 360: Console - IPv4 preferred and requires the Microsoft 'custom STUN and security implementation." - Xbox One: Console - IPv6 preferred - Native IPv6+IPSec - Requires unsolicited inbound IPSec and IKEv2 - "Disables firewall capabilities if one exists" - UPNP+... - IPv4 preferred or no IPv6 = [IPv6+IPSec]+Teredo - Teredo is only necessary for Xbox Live party chat and multiplayer - Within the tunnel, it requires unsolicited inbound IPSec and IKEv2 - UDP long port mapping refresh intervals (60 seconds+) to avoid losing connections to xbox peers - Uses UPNP to "Disables firewall capabilities if one exists" - If NAT exists, here is the most successful strategy, left to right: - Open to the Internet > Address Restricted > Port Restricted > Symmetric > UDP Block - Teredo prefers UDP port 3074 vs. UDP port 3544 - XBOX - Windows 10 - Teredo is only necessary for Xbox Live party chat and multiplayer - Most common error: “Teredo is unable to qualify” https://support.xbox.com/en-US/xbox-on-windows/social/troubleshoot-party-chat - If a third party firewall is installed, good chance it is blocking teredo outbound ports or the Windows10 teredo is disabled. Hope this helps... And don't ask about the security --- It's "good enough for home users" :( Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Tue, Jan 2, 2018 at 6:19 PM, Mark Andrews wrote: > Time to buy a Xbox for the NOC so you can trouble shoot. All puns > intended. > > Mark > > > On 3 Jan 2018, at 10:15 am, Justin Wilson wrote: > > > > These are all Xbox one clients. We don’t hand out IPv6 on this network > yet, so I made sure to disable any sort of IPV6 on the interfaces just to > be sure because I figured Teredo is tied to v6. The only thing we have not > done yet is disable any IPV6 stuff on the customer routers. Everyone has > been getting link local addresses for the longest time. We just disabled > ipv6 totally on the interfaces just to be safe. > > > > > > Justin Wilson > > j2sw at mtin.net > > > > www.mtin.net > > www.midwest-ix.com > > > >> On Jan 2, 2018, at 6:06 PM, Chris Adams wrote: > >> > >> Once upon a time, Mark Andrews said: > >>> Given that you have IPv6 I would be looking at why the XBOXs are > attempting Teredo at all. I would expect them to use the IPv6 addresses > that you are assigning your customers. > >> > >> The OP didn't say what type of Xbox. IIRC the Xbox 360 does not support > >> IPv6, while the Xbox One does (but neither would explain the Teredo). > >> -- > >> Chris Adams > >> > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From sethm at rollernet.us Wed Jan 3 01:38:27 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 2 Jan 2018 17:38:27 -0800 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: <7b8a0df5-f5af-1807-ce92-e47be3d99835@rollernet.us> On 1/2/18 2:46 PM, James Breeden wrote: > And before you come back with "Well they may be using it internally where it doesn't need to be in the GRT" - that's why we have Private AS numbers. > > > I.e. some form of ARIN or global policy that basically says "If AS number not routed or whois updated or used in 24 months, said AS number can be public noticed via mailing list and website and then revoked and reissued to a pending, approved AS request" That's a very broken idea. Immediately to my mind is any internet exchange with route servers will have an AS number that will never show in a path, let alone a global table. Yet such a route server requires a real AS number. ~Seth From jmilko at gmail.com Wed Jan 3 01:50:01 2018 From: jmilko at gmail.com (James Milko) Date: Tue, 2 Jan 2018 20:50:01 -0500 Subject: Spectrum prefix hijacks Message-ID: Not sure if anyone from Spectrum is looking here at this hour, but someone is hijacking a few of your prefixes. It's causing problems in my area (NC) with reaching Google services. I'm sure there are other impacts, but that's what people are noticing. Sorry if this hits the list twice, I sent it from the wrong e-mail address the first go round. * 107.12.0.0/16 193.0.0.56 0 3333 1103 203040 10512 i *> 103.247.3.45 0 58511 203040 10512 i * 107.13.0.0/16 193.0.0.56 0 3333 1103 203040 10512 i *> 103.247.3.45 0 58511 203040 10512 i * 107.14.0.0/16 193.0.0.56 0 3333 1103 203040 10512 i Network Next Hop Metric LocPrf Weight Path *> 103.247.3.45 0 58511 203040 10512 i * 107.15.0.0/16 193.0.0.56 0 3333 1103 203040 10512 i * 103.247.3.45 0 58511 203040 10512 i From morrowc.lists at gmail.com Wed Jan 3 02:29:39 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Jan 2018 21:29:39 -0500 Subject: Spectrum prefix hijacks In-Reply-To: References: Message-ID: On Tue, Jan 2, 2018 at 8:50 PM, James Milko wrote: > Not sure if anyone from Spectrum is looking here at this hour, but someone > is hijacking a few of your prefixes. It's causing problems in my area (NC) > with reaching Google services. I'm sure there are other impacts, but > that's what people are noticing. > > Sorry if this hits the list twice, I sent it from the wrong e-mail address > the first go round. > > * 107.12.0.0/16 193.0.0.56 0 3333 1103 > 203040 10512 i > *> 103.247.3.45 0 58511 203040 > 10512 i > * 107.13.0.0/16 193.0.0.56 0 3333 1103 > 203040 10512 i > *> 103.247.3.45 0 58511 203040 > 10512 i > * 107.14.0.0/16 193.0.0.56 0 3333 1103 > 203040 10512 i > Network Next Hop Metric LocPrf Weight Path > *> 103.247.3.45 0 58511 203040 > 10512 i > * 107.15.0.0/16 193.0.0.56 0 3333 1103 > 203040 10512 i > * 103.247.3.45 0 58511 203040 > 10512 i > E-Forex you say? shocker: AS | BGP IPv4 Prefix | AS Name 10512 | 102.164.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 102.194.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 103.116.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 106.128.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 106.129.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 106.130.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 106.131.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 107.12.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 107.13.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 107.14.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 107.15.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 14.5.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 147.17.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 180.237.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.183.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.185.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.186.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.187.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.188.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.189.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.190.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.191.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.192.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.193.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.194.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 42.195.0.0/16 | EFOREX-AS - E-FOREX, US I'm going to guess they are hijacking a bunch of space and sending spam? (the 42/8 space is variously telecom malaysia and china unicom) the 102 space is un-allocated afrnic space... probably no good these folk are up to. From morrowc.lists at gmail.com Wed Jan 3 02:30:47 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Jan 2018 21:30:47 -0500 Subject: Spectrum prefix hijacks In-Reply-To: References: Message-ID: it looks like 203040 is a pure transit as (no originated prefixes) and 1103 - surfnet could squish what is your view anyway. On Tue, Jan 2, 2018 at 9:29 PM, Christopher Morrow wrote: > > > On Tue, Jan 2, 2018 at 8:50 PM, James Milko wrote: > >> Not sure if anyone from Spectrum is looking here at this hour, but someone >> is hijacking a few of your prefixes. It's causing problems in my area >> (NC) >> with reaching Google services. I'm sure there are other impacts, but >> that's what people are noticing. >> >> Sorry if this hits the list twice, I sent it from the wrong e-mail address >> the first go round. >> >> * 107.12.0.0/16 193.0.0.56 0 3333 1103 >> 203040 10512 i >> *> 103.247.3.45 0 58511 >> 203040 >> 10512 i >> * 107.13.0.0/16 193.0.0.56 0 3333 1103 >> 203040 10512 i >> *> 103.247.3.45 0 58511 >> 203040 >> 10512 i >> * 107.14.0.0/16 193.0.0.56 0 3333 1103 >> 203040 10512 i >> Network Next Hop Metric LocPrf Weight Path >> *> 103.247.3.45 0 58511 >> 203040 >> 10512 i >> * 107.15.0.0/16 193.0.0.56 0 3333 1103 >> 203040 10512 i >> * 103.247.3.45 0 58511 >> 203040 >> 10512 i >> > > E-Forex you say? shocker: > > AS | BGP IPv4 Prefix | AS Name > 10512 | 102.164.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 102.194.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 103.116.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 106.128.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 106.129.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 106.130.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 106.131.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 107.12.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 107.13.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 107.14.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 107.15.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 14.5.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 147.17.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 180.237.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.183.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.185.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.186.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.187.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.188.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.189.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.190.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.191.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.192.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.193.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.194.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 42.195.0.0/16 | EFOREX-AS - E-FOREX, US > > I'm going to guess they are hijacking a bunch of space and sending spam? > (the 42/8 space is variously telecom malaysia and china unicom) > the 102 space is un-allocated afrnic space... probably no good these folk > are up to. > > From jmilko at gmail.com Wed Jan 3 02:51:20 2018 From: jmilko at gmail.com (James Milko) Date: Tue, 2 Jan 2018 21:51:20 -0500 Subject: Spectrum prefix hijacks In-Reply-To: References: Message-ID: The output I dumped was from route-views.routeviews.org. On affected prefes you get 7843->6453->nothing unaffected prefixes get 7843->6453->15169. Unaffected prefixes don't have more specifics from 10512. My sample size is only 8 though with a mix of affected and unaffected users. JM On Tue, Jan 2, 2018 at 9:30 PM, Christopher Morrow wrote: > it looks like 203040 is a pure transit as (no originated prefixes) and > 1103 - surfnet could squish what is your view anyway. > > On Tue, Jan 2, 2018 at 9:29 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> >> >> On Tue, Jan 2, 2018 at 8:50 PM, James Milko wrote: >> >>> Not sure if anyone from Spectrum is looking here at this hour, but >>> someone >>> is hijacking a few of your prefixes. It's causing problems in my area >>> (NC) >>> with reaching Google services. I'm sure there are other impacts, but >>> that's what people are noticing. >>> >>> Sorry if this hits the list twice, I sent it from the wrong e-mail >>> address >>> the first go round. >>> >>> * 107.12.0.0/16 193.0.0.56 0 3333 1103 >>> 203040 10512 i >>> *> 103.247.3.45 0 58511 >>> 203040 >>> 10512 i >>> * 107.13.0.0/16 193.0.0.56 0 3333 1103 >>> 203040 10512 i >>> *> 103.247.3.45 0 58511 >>> 203040 >>> 10512 i >>> * 107.14.0.0/16 193.0.0.56 0 3333 1103 >>> 203040 10512 i >>> Network Next Hop Metric LocPrf Weight Path >>> *> 103.247.3.45 0 58511 >>> 203040 >>> 10512 i >>> * 107.15.0.0/16 193.0.0.56 0 3333 1103 >>> 203040 10512 i >>> * 103.247.3.45 0 58511 >>> 203040 >>> 10512 i >>> >> >> E-Forex you say? shocker: >> >> AS | BGP IPv4 Prefix | AS Name >> 10512 | 102.164.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 102.194.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 103.116.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 106.128.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 106.129.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 106.130.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 106.131.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 107.12.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 107.13.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 107.14.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 107.15.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 14.5.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 147.17.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 180.237.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.183.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.185.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.186.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.187.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.188.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.189.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.190.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.191.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.192.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.193.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.194.0.0/16 | EFOREX-AS - E-FOREX, US >> 10512 | 42.195.0.0/16 | EFOREX-AS - E-FOREX, US >> >> I'm going to guess they are hijacking a bunch of space and sending spam? >> (the 42/8 space is variously telecom malaysia and china unicom) >> the 102 space is un-allocated afrnic space... probably no good these folk >> are up to. >> >> > From dovid at telecurve.com Wed Jan 3 02:51:30 2018 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 2 Jan 2018 21:51:30 -0500 Subject: Attacks from poneytelecom.eu Message-ID: Hi All, Lately we have seen a lot of attacks from IPs where the PTR record ends in poneytelecom.eu to PBX systems. A quick search on twitter ( https://twitter.com/hashtag/poneytelecom) shows multiple people complaining that they reported the IP's yet nothing happens. Has anyone had the pleasure of dealing with them and have you gotten anywhere? I wonder if the only option is public shaming. I would rather not ban their AS as it may hurt legit traffic but I am out of ideas at this point.... TIA. Dovid From randy at psg.com Wed Jan 3 03:10:25 2018 From: randy at psg.com (Randy Bush) Date: Wed, 03 Jan 2018 12:10:25 +0900 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: if AS numbers are unused, what operational difference does it make? but if you have the gloves and long forceps needed to deal with the rir policy , then there is a real need for inter-region AS transfer. randy From ahad at swiftelnetworks.com Wed Jan 3 03:11:37 2018 From: ahad at swiftelnetworks.com (Ahad Aboss) Date: Wed, 03 Jan 2018 03:11:37 +0000 Subject: Attacks from poneytelecom.eu In-Reply-To: References: Message-ID: Have you emailed their abuse or NOC teams with the attack logs from their IPs? Sometimes ISP servers or their customer CPEs are compromised without their knowledge. On Wed, 3 Jan 2018 at 1:56 pm, Dovid Bender wrote: > Hi All, > > Lately we have seen a lot of attacks from IPs where the PTR record ends in > poneytelecom.eu to PBX systems. A quick search on twitter ( > https://twitter.com/hashtag/poneytelecom) shows multiple people > complaining > that they reported the IP's yet nothing happens. Has anyone had the > pleasure of dealing with them and have you gotten anywhere? I wonder if the > only option is public shaming. > > I would rather not ban their AS as it may hurt legit traffic but I am out > of ideas at this point.... > > TIA. > > Dovid > From martin at airwire.ie Wed Jan 3 03:19:33 2018 From: martin at airwire.ie (Martin List-Petersen) Date: Wed, 3 Jan 2018 03:19:33 +0000 Subject: Xbox Live and Teredo In-Reply-To: <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> References: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> <20180102230658.GB4612@cmadams.net> <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> Message-ID: On 02/01/18 23:15, Justin Wilson wrote: > These are all Xbox one clients. We don’t hand out IPv6 on this network yet, so I made sure to disable any sort of IPV6 on the interfaces just to be sure because I figured Teredo is tied to v6. The only thing we have not done yet is disable any IPV6 stuff on the customer routers. Everyone has been getting link local addresses for the longest time. We just disabled ipv6 totally on the interfaces just to be safe. Disabling anything IPv6 is counter productive. The way things are going is IPv6 and has been for many years. Now ... what could happen is that you've got a missconfigured torredo gateway upstream. Disabling IPv6 on customer routers etc won't solve your problem. IPv6 is here to stay. Your best bet: set up a Terredo gateway and facilitate these Xboxes as long as you don't give them native IPv6. Just my 2c. Kind regards, Martin List-Petersen -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 Registered Office: Moy, Kinvara, Co. Galway, 091-865 968 - Registered in Ireland No. 508961 From morrowc.lists at gmail.com Wed Jan 3 03:19:57 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Jan 2018 22:19:57 -0500 Subject: Spectrum prefix hijacks In-Reply-To: References: Message-ID: On Tue, Jan 2, 2018 at 9:51 PM, James Milko wrote: > The output I dumped was from route-views.routeviews.org. On affected > prefes you get 7843->6453->nothing unaffected prefixes get > 7843->6453->15169. Unaffected prefixes don't have more specifics from > 10512. My sample size is only 8 though with a mix of affected and > unaffected users. > > sadly I'm guessing that the peers of 203040 need to clamp down their prefix filters :( (since I see no data in radb, ripe, arin-rr for AS10512 ... I think their prefix-list should be zero length?) > JM > > On Tue, Jan 2, 2018 at 9:30 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> it looks like 203040 is a pure transit as (no originated prefixes) and >> 1103 - surfnet could squish what is your view anyway. >> >> On Tue, Jan 2, 2018 at 9:29 PM, Christopher Morrow < >> morrowc.lists at gmail.com> wrote: >> >>> >>> >>> On Tue, Jan 2, 2018 at 8:50 PM, James Milko wrote: >>> >>>> Not sure if anyone from Spectrum is looking here at this hour, but >>>> someone >>>> is hijacking a few of your prefixes. It's causing problems in my area >>>> (NC) >>>> with reaching Google services. I'm sure there are other impacts, but >>>> that's what people are noticing. >>>> >>>> Sorry if this hits the list twice, I sent it from the wrong e-mail >>>> address >>>> the first go round. >>>> >>>> * 107.12.0.0/16 193.0.0.56 0 3333 >>>> 1103 >>>> 203040 10512 i >>>> *> 103.247.3.45 0 58511 >>>> 203040 >>>> 10512 i >>>> * 107.13.0.0/16 193.0.0.56 0 3333 >>>> 1103 >>>> 203040 10512 i >>>> *> 103.247.3.45 0 58511 >>>> 203040 >>>> 10512 i >>>> * 107.14.0.0/16 193.0.0.56 0 3333 >>>> 1103 >>>> 203040 10512 i >>>> Network Next Hop Metric LocPrf Weight Path >>>> *> 103.247.3.45 0 58511 >>>> 203040 >>>> 10512 i >>>> * 107.15.0.0/16 193.0.0.56 0 3333 >>>> 1103 >>>> 203040 10512 i >>>> * 103.247.3.45 0 58511 >>>> 203040 >>>> 10512 i >>>> >>> >>> E-Forex you say? shocker: >>> >>> AS | BGP IPv4 Prefix | AS Name >>> 10512 | 102.164.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 102.194.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 103.116.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 106.128.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 106.129.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 106.130.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 106.131.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 107.12.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 107.13.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 107.14.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 107.15.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 14.5.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 147.17.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 180.237.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.183.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.185.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.186.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.187.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.188.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.189.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.190.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.191.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.192.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.193.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.194.0.0/16 | EFOREX-AS - E-FOREX, US >>> 10512 | 42.195.0.0/16 | EFOREX-AS - E-FOREX, US >>> >>> I'm going to guess they are hijacking a bunch of space and sending spam? >>> (the 42/8 space is variously telecom malaysia and china unicom) >>> the 102 space is un-allocated afrnic space... probably no good these >>> folk are up to. >>> >>> >> > From morrowc.lists at gmail.com Wed Jan 3 03:40:09 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Jan 2018 22:40:09 -0500 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: On Tue, Jan 2, 2018 at 5:46 PM, James Breeden wrote: > > I'm amazed at the number of AS numbers that are assigned, but not actively > being used. 'not actuvely being used' ... how would you (or anyone) know? what if they were used only on some internal part of a large public network which never leaked beyond their borders/uses? What if the ASN is used on a large private network? (for instance.. where I know of several such things). -chris (mark andrews makes this same, valid, point) From martin at airwire.ie Wed Jan 3 03:52:42 2018 From: martin at airwire.ie (Martin List-Petersen) Date: Wed, 3 Jan 2018 03:52:42 +0000 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: <0124e88c-61c2-c1da-3773-1f8764d000aa@airwire.ie> On 03/01/18 03:40, Christopher Morrow wrote: > On Tue, Jan 2, 2018 at 5:46 PM, James Breeden wrote: > >> >> I'm amazed at the number of AS numbers that are assigned, but not actively >> being used. > > > 'not actuvely being used' ... how would you (or anyone) know? what if they > were used only on some internal part of a large public network which never > leaked beyond their borders/uses? What if the ASN is used on a large > private network? (for instance.. where I know of several such things). I'd second those views. Just take IXPs as an example. Their AS does not necessarily get redistributed past the ISPs peering on these. Not only that, but smaller ones often have non-routable IPv4 allocations, like a /26. So saying, that an ASN is unused is never very accurate, when you don't have the full picture. And the global routing table certainly isn't the full picture. Kind regards, Martin List-Petersen -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 Registered Office: Moy, Kinvara, Co. Galway, 091-865 968 - Registered in Ireland No. 508961 From nanog at studio442.com.au Wed Jan 3 04:00:43 2018 From: nanog at studio442.com.au (Julien Goodwin) Date: Wed, 3 Jan 2018 15:00:43 +1100 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: Internet Exchange route servers would be another case that would appear unused to the broader internet, but shouldn't use a private ASN. On 03/01/18 14:40, Christopher Morrow wrote: > On Tue, Jan 2, 2018 at 5:46 PM, James Breeden wrote: > >> >> I'm amazed at the number of AS numbers that are assigned, but not actively >> being used. > > > 'not actuvely being used' ... how would you (or anyone) know? what if they > were used only on some internal part of a large public network which never > leaked beyond their borders/uses? What if the ASN is used on a large > private network? (for instance.. where I know of several such things). > > -chris > (mark andrews makes this same, valid, point) > From jsklein at gmail.com Wed Jan 3 05:16:58 2018 From: jsklein at gmail.com (Joe Klein) Date: Wed, 3 Jan 2018 00:16:58 -0500 Subject: Xbox Live and Teredo In-Reply-To: References: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> <20180102230658.GB4612@cmadams.net> <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> Message-ID: While you are at it, you might want to configure a STUN and ICE server, to address streaming UDP. Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Tue, Jan 2, 2018 at 10:19 PM, Martin List-Petersen wrote: > On 02/01/18 23:15, Justin Wilson wrote: > >> These are all Xbox one clients. We don’t hand out IPv6 on this network >> yet, so I made sure to disable any sort of IPV6 on the interfaces just to >> be sure because I figured Teredo is tied to v6. The only thing we have not >> done yet is disable any IPV6 stuff on the customer routers. Everyone has >> been getting link local addresses for the longest time. We just disabled >> ipv6 totally on the interfaces just to be safe. >> > > > Disabling anything IPv6 is counter productive. The way things are going is > IPv6 and has been for many years. > > Now ... what could happen is that you've got a missconfigured torredo > gateway upstream. > > Disabling IPv6 on customer routers etc won't solve your problem. IPv6 is > here to stay. > > Your best bet: set up a Terredo gateway and facilitate these Xboxes as > long as you don't give them native IPv6. > > Just my 2c. > > Kind regards, > Martin List-Petersen > -- > Airwire Ltd. - Ag Nascadh Pobail an Iarthair > http://www.airwire.ie > Phone: 091-865 968 > Registered Office: Moy, Kinvara, Co. Galway, 091-865 968 - Registered in > Ireland No. 508961 > From mysidia at gmail.com Wed Jan 3 07:16:28 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 3 Jan 2018 01:16:28 -0600 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: On Tue, Jan 2, 2018 at 4:46 PM, James Breeden wrote: > I.e. some form of ARIN or global policy that basically says "If AS number > not routed or whois updated or used in 24 months, said AS number can be > public noticed via mailing list and website and then revoked and reissued > to a pending, approved AS request" > Why? What is the justification for a reclamation project? Besides this is Outside the purview, scope, or powers that RIRs/ ARIN in particular have put into their public policy development process. of. Number resource policies govern management regarding number resources: allocation, assignment, and transfer. Policies are not able to set fees or conditions on any existing services. Revoking an unused resource would require a condition on existing services that cannot be defined by a number resource policy. EXISTING number resources in ARIN region in particular are serviced under the RSA contract that include terms specifically informs the end user that ARIN is disclaiming itself from having any ability or authority to revoke any unused resources or cancel any services for lack of use. > "ARIN will take no action to reduce the Services currently provided for Included Number Resources due to lack of utilization by the Holder, and (ii) ARIN has no right to revoke any included Number Resources under this Agreement due to lack of utilization by Holder. However, ARIN may refuse to permit transfers or additional allocations of number resources to Holder if Holder’s included Number Resources are not utilized in accordance with Policy." I'm amazed at the number of AS numbers that are assigned, but not actively > being used. "Actively being used" is determined only by the resource holder. And before you come back with "Well they may be using it internally where it doesn't need to be in the GRT" - that's why we have Private AS > numbers. > It is a valid technical decision to use AS numbers internally, and there are reasons Not to use the small pool of available Private AS numbers, Even if the private AS numbers might be available for some legitimate use cases; there is no reason to favor them when privately interconnecting networks across multiple organizations or policy domains, and it is perfectly valid to maintain uniquely-registered AS numbers for such internal purposes. -- -JH From troy at wolvtech.com Wed Jan 3 07:35:14 2018 From: troy at wolvtech.com (Troy Mursch) Date: Tue, 2 Jan 2018 23:35:14 -0800 Subject: Attacks from poneytelecom.eu In-Reply-To: References: Message-ID: Dovid, Back in September, I documented my poor experience with AS12876 here: https://badpackets.net/ongoing-large-scale-sip-attack- campaign-coming-from-online-sas-as12876/ Since then, their handling of abuse notifications (or lack thereof) has largely remained the same. The volume of malicious traffic from their network hasn't decreased either. As you noted, others have reported similar issues with AS12876, including my associate Dr. Neal Krawetz: https://twitter.com/h ackerfactor/status/932593355648667649. I've also compiled a list of complaints regarding AS12876 in this thread: https://twitter.com/ba d_packets/status/937220987371732992 Thanks, __ *Troy Mursch* @bad_packets On Tue, Jan 2, 2018 at 6:51 PM, Dovid Bender wrote: > Hi All, > > Lately we have seen a lot of attacks from IPs where the PTR record ends in > poneytelecom.eu to PBX systems. A quick search on twitter ( > https://twitter.com/hashtag/poneytelecom) shows multiple people > complaining > that they reported the IP's yet nothing happens. Has anyone had the > pleasure of dealing with them and have you gotten anywhere? I wonder if the > only option is public shaming. > > I would rather not ban their AS as it may hurt legit traffic but I am out > of ideas at this point.... > > TIA. > > Dovid > From dovid at telecurve.com Wed Jan 3 08:00:31 2018 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 3 Jan 2018 03:00:31 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> Message-ID: Mcikael, 1) As others have mentioned your AS seemingly has a history of tolerating abuse. I know some of the other VPS players such as DO have automated scripts that look for attacks and lock them out. I see you peer with them perhaps they can share some scripts ;) 2) I went to the abuse URL you have posted and it just lands at your main page. The offending IP was 195.154.182.242. I checked two different boxes (one our own range and another a hosted box elsewhere) and both have entries in the last 3 days from that IP. Scans have been going on for at least the last 48+ hours. On Wed, Jan 3, 2018 at 2:47 AM, Mickael Marchand wrote: > Hi Dovid, > > Just fill in our abuse form at https://abuse. > online.net > > I know people feel these are not processed but they actually are (and > human reviewed) > we are improving our automated tracking of bad guys > more reports come in, easier it is in the end. > > note that most IPs you report are rented per minute and it’s usually not > the same account (but often the same IP as they are reused quickly I agree), > we are working on killing these accounts as fast as we can > > we have a long awaited overall of our abuse system coming in the next > months and additional global scale network security in the pipe (automated > SIP scan detection and blocking is among them for example) > > regards > Mik > > > Le 3 janv. 2018 à 04:11, Ahad Aboss a écrit : > > Have you emailed their abuse or NOC teams with the attack logs from their > IPs? > > Sometimes ISP servers or their customer CPEs are compromised without their > knowledge. > > On Wed, 3 Jan 2018 at 1:56 pm, Dovid Bender wrote: > > Hi All, > > Lately we have seen a lot of attacks from IPs where the PTR record ends in > poneytelecom.eu to PBX systems. A quick search on twitter ( > https://twitter.com/hashtag/poneytelecom) shows multiple people > complaining > that they reported the IP's yet nothing happens. Has anyone had the > pleasure of dealing with them and have you gotten anywhere? I wonder if the > only option is public shaming. > > I would rather not ban their AS as it may hurt legit traffic but I am out > of ideas at this point.... > > TIA. > > Dovid > > > -- > Mickael Marchand, > VP Network Scaleway - Online.net > Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/ > > > > From tore at fud.no Wed Jan 3 08:57:12 2018 From: tore at fud.no (Tore Anderson) Date: Wed, 3 Jan 2018 09:57:12 +0100 Subject: Xbox Live and Teredo In-Reply-To: References: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> <20180102230658.GB4612@cmadams.net> <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> Message-ID: <20180103095712.42bf3fee@echo.ms.redpill-linpro.com> * Martin List-Petersen > Your best bet: set up a Terredo gateway and facilitate these Xboxes as > long as you don't give them native IPv6. This is unlikely to help, as the XB1 doesn't use Teredo relays at all. The XB1 uses Teredo to facilitate direct p2p communication between IPv4 consoles only. Essentially it is used an IPv4 NAT traversal mechanism. Its Teredo implementation does not allow communication between IPv4 and IPv6 peers. This is the only communication pattern which would normally require a third-party Teredo relay. This unfortunately also means that provisioning IPv6 is also unlikely to help, unless you're in a position to provision it to both peers. See: https://www.ietf.org/proceedings/88/slides/slides-88-v6ops-0.pdf Personally I'd start out by verifying the connectivity to and functionality of Microsoft's Teredo servers, which are used for NAT address discovery and port mapping during tunnel setup (unlike Teredo relays, Teredo servers aren't part of the Teredo «forwarding plane»). Tore From rsk at gsp.org Wed Jan 3 09:12:53 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 3 Jan 2018 04:12:53 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: References: Message-ID: <20180103091253.GA30566@gsp.org> On Tue, Jan 02, 2018 at 11:35:14PM -0800, Troy Mursch wrote: > Back in September, I documented my poor experience with AS12876 here: [snip] That AS has been originating brute-force attacks against ssh, pop, imap, etc. for at least four years (and likely longer, but I didn't have older logs handy). It's also a persistent high-volume source of spam. Its operators are either thoroughly incompetent or fully complicit; there's no way to tell from outside and operationally, it makes no difference. So at minimum I recommend blocking all connections from it to authenticated services and refusing all SMTP traffic from rev.poneytelecom.eu and rev.cloud.scaleway.com. ---rsk From nanog at ics-il.net Wed Jan 3 15:12:22 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 3 Jan 2018 09:12:22 -0600 (CST) Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: <5A4C11BD.7070407@sonn.com> References: <20180102225613.GA4612@cmadams.net> <5A4C11BD.7070407@sonn.com> Message-ID: <1520917122.14299.1514992337557.JavaMail.mhammett@ThunderFuck> I updated all applicable records for a new client in the past month. Didn't seem that difficult. *shrugs* I did have control of the email server for the domain in the POCs, though. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Steve Noble" To: nanog at nanog.org Sent: Tuesday, January 2, 2018 5:11:57 PM Subject: Re: AS Numbers unused/sitting for long periods of time Inaccurate whois data from ARIN is not a good way to tell anything as ARIN is terrible to deal with when you need to update an address or phone number or anything. I know personally as I had to fight for years to update the data on an ASN that ARIN was billing me to manage the data for. > Chris Adams > January 2, 2018 at 2:56 PM > > I know of two (from a former job) that pre-date ARIN that haven't been > used since 1999 because those two companies no longer exist (nor AFAIK > does any successor company). The whois information is bogus at this > point, but I couldn't prove that. > > I expect that AS numbers allocated by ARIN and other current RIRs are > not abandoned like that (since they charge annual fees, and I assume > they reclaim for non-payment), so the number of abandoned AS numbers is > probably not growing significantly (and would not grow beyond the > pre-RIR pool). > > With 32 bit AS numbers though, what's the point of making an effort to > reclaim the old AS numbers? BGP4 has been shown to handle alternate > length AS numbers, so if somehow 4 billion are allocated, it probably > won't be a big deal to extend BGP again. > > James Breeden > January 2, 2018 at 2:46 PM > Before I take this to the ARIN PPML, wanted to get NANOG's thoughts. > > > I'm amazed at the number of AS numbers that are assigned, but not > actively being used. I'm not talking just like they are offline for a > week or month, this is complete non-use of the AS in the global > routing table within *years*. They are completely abandoned resources > - Whois data is inaccurate by 5-10 years, no routeviews data in the > same time period, the owning organization (if you can find it) > scratches their heads about responding whether they use it or not, etc. > > > I know we're currently not in a push to get AS numbers or close to > exhaustion, but I do believe that people who have global AS numbers > should have a requirement to use them or return them to the global > pool. Am I the only one thinking this? > > > And before you come back with "Well they may be using it internally > where it doesn't need to be in the GRT" - that's why we have Private > AS numbers. > > > I.e. some form of ARIN or global policy that basically says "If AS > number not routed or whois updated or used in 24 months, said AS > number can be public noticed via mailing list and website and then > revoked and reissued to a pending, approved AS request" > > > Just thinking aloud. Happy New Year all! > > > James W. Breeden > > Managing Partner > > > > [logo_transparent_background] > > Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media > > PO Box 1063 | Smithville, TX 78957 > > Email: james at arenalgroup.co | office > 512.360.0000 | cell 512.304.0745 | > www.arenalgroup.co From bill at herrin.us Wed Jan 3 16:25:12 2018 From: bill at herrin.us (William Herrin) Date: Wed, 3 Jan 2018 11:25:12 -0500 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: On Wed, Jan 3, 2018 at 2:16 AM, Jimmy Hess wrote: > EXISTING number resources in ARIN region in particular are serviced under > the RSA contract that include terms specifically informs the end user that > ARIN is disclaiming itself from having any ability or authority to > revoke any unused resources or cancel any services for lack of use. > Hi Jimmy, That's not entirely correct. In this case there are two groups of AS numbers held by ARIN: 1. AS numbers held under a registration services agreement. ARIN has annual contact with these organizations in the form of a bill which, if they don't pay, eventually results in deregistration of the resource. No change to policy or process is necessary for this to happen. 2. Legacy AS numbers assigned by the registrars that existed prior to ARIN. ARIN asserts that they have the authority to deregister these resources, but the legal situation is murky. No explicit contract covering those AS numbers exists between ARIN and the registrants. ARIN's authority to refuse action outside of a contract has been only weakly tested in court: all cases were settled prior to the court ruling or the court ruled on some basis other than ARIN's authority over number resources. For example, the Nortel case was settled when Microsoft agreed to sign a negotiated contract with ARIN while the Kremen case was thrown out based on the statute of limitations: he waited too long after ARIN's refusal to sue. ARIN's authority to act absent a contract has never been tested in court. And in fact ARIN has never unilaterally deregistered a legacy resource. Practically speaking, this means that any action to revoke allegedly abandoned legacy resources places ARIN at legal risk. The prospective gain from such action would have to exceed the risk. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From owen at delong.com Wed Jan 3 16:44:06 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Jan 2018 08:44:06 -0800 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: <1520917122.14299.1514992337557.JavaMail.mhammett@ThunderFuck> References: <20180102225613.GA4612@cmadams.net> <5A4C11BD.7070407@sonn.com> <1520917122.14299.1514992337557.JavaMail.mhammett@ThunderFuck> Message-ID: <1A2BB9F0-A306-4C22-A114-C80C5DA31181@delong.com> Steve’s situation was relatively unique and arduous. It was also resolved several years ago. Yes, if you have difficulty authenticating as a legitimate administrator of the resource, it can be difficult to convince ARIN you should be updating the contact data on said resource. Hopefully everyone here can see how that is a desirable thing. I’m quite glad that ARIN makes it difficult for people who aren’t me to update my resource records. As to the issue raised regarding unused ASNs, there are several possibilities not yet considered IMHO: 1. There were private networks built before private ASNs existed. 2. There were private networks built that needed ASN coordination and include more ASNs than there were private 16-bit ASNs. 3. While private ASNs may be a solution for some private networks, there are other cases where they may not be well suited. Such cases can legitimately use public ASNs. 4. NO single view, nor even any collection of views available to any one entity can be considered a complete routing table for the entire internet. Are there ASNs that were issued prior to the creation of ARIN that may languish? Yes. Probably a few thousand. All ASNs issued since the creation of ARIN come with an annual fee being paid to ARIN which means that the ASN isn’t languishing unless someone is paying the fee for the ASN and/or related resources each year. So in the case of companies that no longer exist, if you report your suspicions to ARIN, they’ll investigate and reclaim the ASNs if they can be certain that the organizations are no longer valid. In the case of ASNs issued in the last 20 years, that’s as easy as checking that the invoice got paid by someone. ASNs issued prior to 1997 are a much harder problem to solve. Personally, I don’t think there’s enough value to the community in a few thousand ASNs to make it worth the cost involved in ARIN going out and reclaiming them aggressively. A few years ago, we added 4,294,901,760 ASNs to the original pool of 65,536 ASNs. (This includes both public and private in both cases). None of those 4 billion new ASNs will languish as they are all issued under an annual fee. As such, I see little or no value in trying to reclaim the few thousand ASNs that might be subject to such a policy. Owen > On Jan 3, 2018, at 07:12 , Mike Hammett wrote: > > I updated all applicable records for a new client in the past month. Didn't seem that difficult. *shrugs* > > I did have control of the email server for the domain in the POCs, though. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Steve Noble" > To: nanog at nanog.org > Sent: Tuesday, January 2, 2018 5:11:57 PM > Subject: Re: AS Numbers unused/sitting for long periods of time > > Inaccurate whois data from ARIN is not a good way to tell anything as > ARIN is terrible to deal with when you need to update an address or > phone number or anything. I know personally as I had to fight for years > to update the data on an ASN that ARIN was billing me to manage the data > for. > >> Chris Adams >> January 2, 2018 at 2:56 PM >> >> I know of two (from a former job) that pre-date ARIN that haven't been >> used since 1999 because those two companies no longer exist (nor AFAIK >> does any successor company). The whois information is bogus at this >> point, but I couldn't prove that. >> >> I expect that AS numbers allocated by ARIN and other current RIRs are >> not abandoned like that (since they charge annual fees, and I assume >> they reclaim for non-payment), so the number of abandoned AS numbers is >> probably not growing significantly (and would not grow beyond the >> pre-RIR pool). >> >> With 32 bit AS numbers though, what's the point of making an effort to >> reclaim the old AS numbers? BGP4 has been shown to handle alternate >> length AS numbers, so if somehow 4 billion are allocated, it probably >> won't be a big deal to extend BGP again. >> >> James Breeden >> January 2, 2018 at 2:46 PM >> Before I take this to the ARIN PPML, wanted to get NANOG's thoughts. >> >> >> I'm amazed at the number of AS numbers that are assigned, but not >> actively being used. I'm not talking just like they are offline for a >> week or month, this is complete non-use of the AS in the global >> routing table within *years*. They are completely abandoned resources >> - Whois data is inaccurate by 5-10 years, no routeviews data in the >> same time period, the owning organization (if you can find it) >> scratches their heads about responding whether they use it or not, etc. >> >> >> I know we're currently not in a push to get AS numbers or close to >> exhaustion, but I do believe that people who have global AS numbers >> should have a requirement to use them or return them to the global >> pool. Am I the only one thinking this? >> >> >> And before you come back with "Well they may be using it internally >> where it doesn't need to be in the GRT" - that's why we have Private >> AS numbers. >> >> >> I.e. some form of ARIN or global policy that basically says "If AS >> number not routed or whois updated or used in 24 months, said AS >> number can be public noticed via mailing list and website and then >> revoked and reissued to a pending, approved AS request" >> >> >> Just thinking aloud. Happy New Year all! >> >> >> James W. Breeden >> >> Managing Partner >> >> >> >> [logo_transparent_background] >> >> Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media >> >> PO Box 1063 | Smithville, TX 78957 >> >> Email: james at arenalgroup.co | office >> 512.360.0000 | cell 512.304.0745 | >> www.arenalgroup.co > From owen at delong.com Wed Jan 3 18:43:50 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Jan 2018 10:43:50 -0800 Subject: AS Numbers unused/sitting for long periods of time In-Reply-To: References: Message-ID: > On Jan 2, 2018, at 19:10 , Randy Bush wrote: > > if AS numbers are unused, what operational difference does it make? > > but if you have the gloves and long forceps needed to deal with the rir > policy , then there is a real need for inter-region AS transfer. > > randy Why? Seriously asking, not trying to be confrontational. I understand some people want it, but I’m trying to understand the actual “need” vs. want. Owen From dveit at microsoft.com Wed Jan 3 19:03:57 2018 From: dveit at microsoft.com (Darrin Veit) Date: Wed, 3 Jan 2018 19:03:57 +0000 Subject: Xbox Live and Teredo In-Reply-To: References: <7661D1A1-2823-4F96-B165-626C99E6870A@mtin.net> <8872019B-5EB4-4134-9FDC-402C63234FAC@isc.org> <20180102230658.GB4612@cmadams.net> <08254A6F-48ED-46F5-B2DE-118B7C019F2E@mtin.net> Message-ID: Small clarification: "- Teredo prefers UDP port 3074 vs. UDP port 3544" On Xbox One, the Teredo client is bound to UDP 3074 as the default and communicates to the Teredo servers on the standard Teredo port, UDP 3544. If UPnP is in play and an Xbox console attempts to port map UDP 3074 and receives a mapping conflict error from the gateway, the console will fall back to a pseudo-random port in the ephemeral range. We also introduced an update last year where customers could also manually configure the console to use a non-3074 port in case UPnP wasn't enabled on the local network and multiple consoles are present. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joe Klein Sent: Tuesday, January 2, 2018 4:13 PM To: Mark Andrews Cc: NANOG list Subject: Re: Xbox Live and Teredo Are you aware: - Microsofts justification for Teredo is to support P2P during the transition to IPv6 dominant networks. - Xbox 360: Console - IPv4 preferred and requires the Microsoft 'custom STUN and security implementation." - Xbox One: Console - IPv6 preferred - Native IPv6+IPSec - Requires unsolicited inbound IPSec and IKEv2 - "Disables firewall capabilities if one exists" - UPNP+... - IPv4 preferred or no IPv6 = [IPv6+IPSec]+Teredo - Teredo is only necessary for Xbox Live party chat and multiplayer - Within the tunnel, it requires unsolicited inbound IPSec and IKEv2 - UDP long port mapping refresh intervals (60 seconds+) to avoid losing connections to xbox peers - Uses UPNP to "Disables firewall capabilities if one exists" - If NAT exists, here is the most successful strategy, left to right: - Open to the Internet > Address Restricted > Port Restricted > Symmetric > UDP Block - Teredo prefers UDP port 3074 vs. UDP port 3544 - XBOX - Windows 10 - Teredo is only necessary for Xbox Live party chat and multiplayer - Most common error: “Teredo is unable to qualify” https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.xbox.com%2Fen-US%2Fxbox-on-windows%2Fsocial%2Ftroubleshoot-party-chat&data=02%7C01%7Cdveit%40microsoft.com%7C65a1a83fad664db4ea6308d5523ef9e9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636505352789854753&sdata=ArbsmYbrIPFlVG2ydBCw0jBa8m6WHyZirDT2Rgz7a1A%3D&reserved=0 - If a third party firewall is installed, good chance it is blocking teredo outbound ports or the Windows10 teredo is disabled. Hope this helps... And don't ask about the security --- It's "good enough for home users" :( Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Tue, Jan 2, 2018 at 6:19 PM, Mark Andrews wrote: > Time to buy a Xbox for the NOC so you can trouble shoot. All puns > intended. > > Mark > > > On 3 Jan 2018, at 10:15 am, Justin Wilson wrote: > > > > These are all Xbox one clients. We don’t hand out IPv6 on this > > network > yet, so I made sure to disable any sort of IPV6 on the interfaces just > to be sure because I figured Teredo is tied to v6. The only thing we > have not done yet is disable any IPV6 stuff on the customer routers. Everyone has > been getting link local addresses for the longest time. We just disabled > ipv6 totally on the interfaces just to be safe. > > > > > > Justin Wilson > > j2sw at mtin.net > > > > https://na01.safelinks.protection.outlook.com/?url=www.mtin.net&data > > =02%7C01%7Cdveit%40microsoft.com%7C65a1a83fad664db4ea6308d5523ef9e9% > > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636505352789854753&sdat > > a=P6GoT4YSwbQ%2FT9guweaTf25wy7J77UkoZqqGBiFXkVo%3D&reserved=0 > > https://na01.safelinks.protection.outlook.com/?url=www.midwest-ix.co > > m&data=02%7C01%7Cdveit%40microsoft.com%7C65a1a83fad664db4ea6308d5523 > > ef9e9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63650535278985475 > > 3&sdata=uCDl6dWK8vXzCOKkui0LV3RHwhEa8GRzj31xOGSKfXs%3D&reserved=0 > > > >> On Jan 2, 2018, at 6:06 PM, Chris Adams wrote: > >> > >> Once upon a time, Mark Andrews said: > >>> Given that you have IPv6 I would be looking at why the XBOXs are > attempting Teredo at all. I would expect them to use the IPv6 > addresses that you are assigning your customers. > >> > >> The OP didn't say what type of Xbox. IIRC the Xbox 360 does not > >> support IPv6, while the Xbox One does (but neither would explain the Teredo). > >> -- > >> Chris Adams > >> > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From owen at delong.com Wed Jan 3 19:40:10 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Jan 2018 11:40:10 -0800 Subject: Threads that never end (was: Waste will kill ipv6 too) In-Reply-To: References: <40c25b4e-46e1-2223-8755-4a018df39a40@alvarezp.org> <23109.17022.495829.617613@gargle.gargle.HOWL> <7D68D30A-3DAF-4FB3-9936-BFF1803E1C79@delong.com> <1814a5b3-5842-a678-8b03-f05ac220d104@nsc.liu.se> <69D9A870-2A0B-4FC0-BB36-395350451F24@consultant.com> <637db152-02ed-b49b-2c31-a313352698e4@bmwl.co> <603f760e-351d-af6b-0956-ddb1e145d416@satchell.net> <20171230154600.GB4208@sizone.org> <20171230233905.GK6349@sizone.org> <23115.53602.237157.64636@gargle.gargle.HOWL> <4684D2CF-DEA6-4581-AB9C-591CE31B6C2A@delong.com> Message-ID: <742BC45F-2EB6-4DDE-BBF1-7096CF71400E@delong.com> Huh? I’m saying they are network identifiers and not something else (like POP names, or geographical indexes, or inventory control numbers, or crypto currency or whatever else). So I’m not sure I understand your point here. Owen > On Jan 2, 2018, at 15:58 , William Herrin wrote: > > On Tue, Jan 2, 2018 at 4:59 PM, Owen DeLong > wrote: > I agree we all have a responsibility to hold the line on addresses being network identifiers > > Hi Owen, > > The delicious irony here is that EUI-64 supporting SLAAC is exactly that: an identifier. If we hold the line there, there is no line. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From nanog at ics-il.net Thu Jan 4 00:04:24 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 3 Jan 2018 18:04:24 -0600 (CST) Subject: Level 3 Voice In-Reply-To: <478001484.15252.1515024251941.JavaMail.mhammett@ThunderFuck> Message-ID: <665001790.15256.1515024259602.JavaMail.mhammett@ThunderFuck> I'm looking for a contact at Level 3's voice operations, preferably someone that knows about LNP. My client didn't get a port request to approve for their customer, yet operationally their customer's number has been ported to Level 3. Their customer wasn't aware of it going elsewhere as they called my client for support on the lack of inbound calling. Thank you. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From goemon at sasami.anime.net Thu Jan 4 03:57:50 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Wed, 3 Jan 2018 19:57:50 -0800 (PST) Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> Message-ID: On Wed, 3 Jan 2018, Dovid Bender wrote: > On Wed, Jan 3, 2018 at 2:47 AM, Mickael Marchand > wrote: >> Hi Dovid, >> >> Just fill in our abuse form at https://abuse. >> online.net I have no idea why anyone thinks it is acceptable to require victims to fill out online web forms. -Dan From tb at tburke.us Thu Jan 4 05:46:18 2018 From: tb at tburke.us (Tim Burke) Date: Thu, 4 Jan 2018 05:46:18 +0000 Subject: Attacks from poneytelecom.eu In-Reply-To: References: , Message-ID: <1AE73692-8E1F-4DC9-9144-4607BF26F133@tburke.us> AS12876 is online.net... home of the €2.99 physical server, perfect for all of your favorite illegitimate activity. I’m curious how much traffic originates from that ASN that is actually legitimate... probably close to none. Sent from my iPhone > On Jan 3, 2018, at 1:35 AM, Troy Mursch wrote: > > Dovid, > > Back in September, I documented my poor experience with AS12876 here: > https://badpackets.net/ongoing-large-scale-sip-attack- > campaign-coming-from-online-sas-as12876/ > Since then, their handling of abuse notifications (or lack thereof) has > largely remained the same. The volume of malicious traffic from their > network hasn't decreased either. > > As you noted, others have reported similar issues with AS12876, including > my associate Dr. Neal Krawetz: https://twitter.com/h > ackerfactor/status/932593355648667649. I've also compiled a list of > complaints regarding AS12876 in this thread: https://twitter.com/ba > d_packets/status/937220987371732992 > > > Thanks, > __ > > *Troy Mursch* > > @bad_packets > >> On Tue, Jan 2, 2018 at 6:51 PM, Dovid Bender wrote: >> >> Hi All, >> >> Lately we have seen a lot of attacks from IPs where the PTR record ends in >> poneytelecom.eu to PBX systems. A quick search on twitter ( >> https://twitter.com/hashtag/poneytelecom) shows multiple people >> complaining >> that they reported the IP's yet nothing happens. Has anyone had the >> pleasure of dealing with them and have you gotten anywhere? I wonder if the >> only option is public shaming. >> >> I would rather not ban their AS as it may hurt legit traffic but I am out >> of ideas at this point.... >> >> TIA. >> >> Dovid >> From fhr at fhrnet.eu Thu Jan 4 07:35:43 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Thu, 4 Jan 2018 07:35:43 +0000 Subject: Attacks from poneytelecom.eu In-Reply-To: <1AE73692-8E1F-4DC9-9144-4607BF26F133@tburke.us> References: Message-ID: <01020160c018dcb4-d66d10ed-ef67-48b7-9a91-c098b57b7c18-000000@eu-west-1.amazonses.com> Quite a lot actually. Those servers are fine seedboxes. People also use them for media storage, i.e. online galleries and smaller video streaming sites. Filip > > On 4 Jan 2018 at 6:46 am, wrote: > > > AS12876 is online.net... home of the €2.99 physical server, perfect for all of your favorite illegitimate activity. I’m curious how much traffic originates from that ASN that is actually legitimate... probably close to none. Sent from my iPhone > On Jan 3, 2018, at 1:35 AM, Troy Mursch wrote: > > Dovid, > > Back in September, I documented my poor experience with AS12876 here: > https://badpackets.net/ongoing-large-scale-sip-attack- > campaign-coming-from-online-sas-as12876/ > Since then, their handling of abuse notifications (or lack thereof) has > largely remained the same. The volume of malicious traffic from their > network hasn't decreased either. > > As you noted, others have reported similar issues with AS12876, including > my associate Dr. Neal Krawetz: https://twitter.com/h > ackerfactor/status/932593355648667649. I've also compiled a list of > complaints regarding AS12876 in this thread: https://twitter.com/ba > d_packets/status/937220987371732992 > > > Thanks, > __ > > *Troy Mursch* > > @bad_packets > >> On Tue, Jan 2, 2018 at 6:51 PM, Dovid Bender wrote: >> >> Hi All, >> >> Lately we have seen a lot of attacks from IPs where the PTR record ends in >> poneytelecom.eu to PBX systems. A quick search on twitter ( >> https://twitter.com/hashtag/poneytelecom) shows multiple people >> complaining >> that they reported the IP's yet nothing happens. Has anyone had the >> pleasure of dealing with them and have you gotten anywhere? I wonder if the >> only option is public shaming. >> >> I would rather not ban their AS as it may hurt legit traffic but I am out >> of ideas at this point.... >> >> TIA. >> >> Dovid >> > From hugge at nordu.net Thu Jan 4 08:15:19 2018 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Thu, 4 Jan 2018 09:15:19 +0100 Subject: Attacks from poneytelecom.eu In-Reply-To: <1AE73692-8E1F-4DC9-9144-4607BF26F133@tburke.us> References: <1AE73692-8E1F-4DC9-9144-4607BF26F133@tburke.us> Message-ID: <48c32bde-9bf0-b901-f771-7222eae7b305@nordu.net> Depends on what "legitimate" means. We have a decent amount of traffic to the network (like 2Gbps sustained in any afternoon). Its typically a mix of bittorrent, tor-relay traffic, ftp-transfers and of course the expected scanners, malware-hosts, ddos-bots and such. For me Poney/Illiad/Online.net/Scaleway has always been a bulletproof hoster (or bulletproof transit even), the response to abuse has always been NIL. I know tons of my customers just blocks out their whole ip-ranges in their SIP-servers and email-machines to lessen the white-noise. However - judging from the Online.net website it atleast seems that they are trying to up their game and look like something that would be attractive to a legitimate business to consider. On the other hand, looking at http://as12876.net/ it looks more like something that would rather fit as a place where i put the shady stuff, so not sure where on the map they fall these days. > AS12876 is online.net... home of the €2.99 physical server, perfect for all of your favorite illegitimate activity. I’m curious how much traffic originates from that ASN that is actually legitimate... probably close to none. > > Sent from my iPhone > >> On Jan 3, 2018, at 1:35 AM, Troy Mursch wrote: >> >> Dovid, >> >> Back in September, I documented my poor experience with AS12876 here: >> https://badpackets.net/ongoing-large-scale-sip-attack- >> campaign-coming-from-online-sas-as12876/ >> Since then, their handling of abuse notifications (or lack thereof) has >> largely remained the same. The volume of malicious traffic from their >> network hasn't decreased either. >> >> As you noted, others have reported similar issues with AS12876, including >> my associate Dr. Neal Krawetz: https://twitter.com/h >> ackerfactor/status/932593355648667649. I've also compiled a list of >> complaints regarding AS12876 in this thread: https://twitter.com/ba >> d_packets/status/937220987371732992 >> >> >> Thanks, >> __ >> >> *Troy Mursch* >> >> @bad_packets >> >>> On Tue, Jan 2, 2018 at 6:51 PM, Dovid Bender wrote: >>> >>> Hi All, >>> >>> Lately we have seen a lot of attacks from IPs where the PTR record ends in >>> poneytelecom.eu to PBX systems. A quick search on twitter ( >>> https://twitter.com/hashtag/poneytelecom) shows multiple people >>> complaining >>> that they reported the IP's yet nothing happens. Has anyone had the >>> pleasure of dealing with them and have you gotten anywhere? I wonder if the >>> only option is public shaming. >>> >>> I would rather not ban their AS as it may hurt legit traffic but I am out >>> of ideas at this point.... >>> >>> TIA. >>> >>> Dovid >>> -- hugge From bill at herrin.us Thu Jan 4 14:33:51 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Jan 2018 09:33:51 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> Message-ID: On Wed, Jan 3, 2018 at 10:57 PM, Dan Hollis wrote: > On Wed, 3 Jan 2018, Dovid Bender wrote: > >> On Wed, Jan 3, 2018 at 2:47 AM, Mickael Marchand >> wrote: >> >>> Hi Dovid, >>> >>> Just fill in our abuse form at https://abuse. >>> online.net >>> >> > I have no idea why anyone thinks it is acceptable to require victims to > fill out online web forms. Because the number of people who successfully provide actionable information without being prompted is vanishingly small and the number of people who fire off automated complaints to the best guess abuse address (also without actionable information) is disappointingly large? Why anyone thinks it's acceptable for the form submission to vanish in to the faceless support queue is more of a quandary. The form submission should provide a case number, the individual to whom it is assigned, direct contact information for that individual and a promise that your report will receive a response. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From list at satchell.net Thu Jan 4 14:39:58 2018 From: list at satchell.net (Stephen Satchell) Date: Thu, 4 Jan 2018 06:39:58 -0800 Subject: Attacks from poneytelecom.eu In-Reply-To: <1AE73692-8E1F-4DC9-9144-4607BF26F133@tburke.us> References: <1AE73692-8E1F-4DC9-9144-4607BF26F133@tburke.us> Message-ID: <569a16a8-703a-6e6b-1548-bdbb74f59bd7@satchell.net> On 01/03/2018 09:46 PM, Tim Burke wrote: > AS12876 is online.net... home of the €2.99 physical server, perfect > for all of your favorite illegitimate activity. I’m curious how much > traffic originates from that ASN that is actually legitimate... > probably close to none. SETI at home? Bitcoin mining? From dovid at telecurve.com Thu Jan 4 14:42:26 2018 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 4 Jan 2018 09:42:26 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> Message-ID: In their defense I was pleasantly surprised that I got a response back from them telling me the account was banned. Though it makes me wonder if this is just them trying to save face. I have spoken with the guys that run DO's network and they have an extensive amount of automation to weed out spammers, attackers etc. It makes you wonder why for years that are known in the spammer community as a safe heaven. On Thu, Jan 4, 2018 at 9:33 AM, William Herrin wrote: > On Wed, Jan 3, 2018 at 10:57 PM, Dan Hollis > wrote: > >> On Wed, 3 Jan 2018, Dovid Bender wrote: >> >>> On Wed, Jan 3, 2018 at 2:47 AM, Mickael Marchand >> > >>> wrote: >>> >>>> Hi Dovid, >>>> >>>> Just fill in our abuse form at https://abuse. >>>> online.net >>>> >>> >> I have no idea why anyone thinks it is acceptable to require victims to >> fill out online web forms. > > > Because the number of people who successfully provide actionable > information without being prompted is vanishingly small and the number of > people who fire off automated complaints to the best guess abuse address > (also without actionable information) is disappointingly large? > > Why anyone thinks it's acceptable for the form submission to vanish in to > the faceless support queue is more of a quandary. The form submission > should provide a case number, the individual to whom it is assigned, direct > contact information for that individual and a promise that your report will > receive a response. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From rsk at gsp.org Thu Jan 4 14:43:41 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 4 Jan 2018 09:43:41 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> Message-ID: <20180104144341.GA27850@gsp.org> On Thu, Jan 04, 2018 at 09:33:51AM -0500, William Herrin wrote: > Because the number of people who successfully provide actionable > information without being prompted is vanishingly small and the number of > people who fire off automated complaints to the best guess abuse address > (also without actionable information) is disappointingly large? Not a valid excuse. (1) It is a trivial matter for any "abuse desk" worthy of the title to priority-sort incoming traffic. (2) An excellent way for operations to reduce the volume of such complaints is to reduce the volume of the abuse they emit/support. ---rsk From valdis.kletnieks at vt.edu Thu Jan 4 16:12:19 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 04 Jan 2018 11:12:19 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> Message-ID: <195982.1515082339@turing-police.cc.vt.edu> On Thu, 04 Jan 2018 09:33:51 -0500, William Herrin said: > Why anyone thinks it's acceptable for the form submission to vanish in to > the faceless support queue is more of a quandary. The form submission > should provide a case number, the individual to whom it is assigned, direct > contact information for that individual and a promise that your report will > receive a response. The very real problem with direct contact info is that people latch onto it. Then, if there's another issue the person will bypass your form submission, send a direct e-mail - which would then not be dealt with if that particular person wasn't working, for reasons ranging from vacation to no longer being with the provider in an abuse desk role. Been there, done that. Been out of the country and offline for 36 hours, reconnect and there's a user with a problem that would have been dealt with 36 hours earlier if they had sent it to our help desk instead of to me directly. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From michael at wi-fiber.io Thu Jan 4 16:48:24 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Thu, 4 Jan 2018 09:48:24 -0700 Subject: Attacks from poneytelecom.eu In-Reply-To: <195982.1515082339@turing-police.cc.vt.edu> References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> Message-ID: I've never dealt with a support queue that resolved the issue faster than a direct contact. On 4 January 2018 at 09:12, wrote: > On Thu, 04 Jan 2018 09:33:51 -0500, William Herrin said: > > > Why anyone thinks it's acceptable for the form submission to vanish in to > > the faceless support queue is more of a quandary. The form submission > > should provide a case number, the individual to whom it is assigned, > direct > > contact information for that individual and a promise that your report > will > > receive a response. > > The very real problem with direct contact info is that people latch onto > it. > Then, if there's another issue the person will bypass your form submission, > send a direct e-mail - which would then not be dealt with if that > particular > person wasn't working, for reasons ranging from vacation to no longer being > with the provider in an abuse desk role. > > Been there, done that. Been out of the country and offline for 36 hours, > reconnect and there's a user with a problem that would have been dealt > with 36 hours earlier if they had sent it to our help desk instead of to me > directly. > > > From valdis.kletnieks at vt.edu Thu Jan 4 17:36:55 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 04 Jan 2018 12:36:55 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> Message-ID: <4101.1515087415@turing-police.cc.vt.edu> On Thu, 04 Jan 2018 09:48:24 -0700, Michael Crapse said: > I've never dealt with a support queue that resolved the issue faster than a > direct contact. Which would the user prefer - a guaranteed 15 minute response time from the queue, or 10 minute from a direct contact, unless it's an hour because they're in a meeting, or the next day because they're out sick, or 2 weeks because they're on vacation? Bonus points for recognizing there's a confirmation bias effect here - people will remember the 2 week response time more than they'll remember the 5 minutes faster the rest of the time. Hint: How many "I haven't heard back in a week" do we see here and on the mailop list, and how many "Congrats to so-n-so who fixed my problem in 5 minutes flat?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From rob at invaluement.com Thu Jan 4 17:49:21 2018 From: rob at invaluement.com (Rob McEwen) Date: Thu, 4 Jan 2018 12:49:21 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: <4101.1515087415@turing-police.cc.vt.edu> References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> <4101.1515087415@turing-police.cc.vt.edu> Message-ID: On 1/4/2018 12:36 PM, valdis.kletnieks at vt.edu wrote: > On Thu, 04 Jan 2018 09:48:24 -0700, Michael Crapse said: >> I've never dealt with a support queue that resolved the issue faster than a >> direct contact. > Which would the user prefer - a guaranteed 15 minute response time from the queue, > or 10 minute from a direct contact, unless it's an hour because they're in a meeting, > or the next day because they're out sick, or 2 weeks because they're on vacation? > > Bonus points for recognizing there's a confirmation bias effect here - people will > remember the 2 week response time more than they'll remember the 5 minutes > faster the rest of the time. > > Hint: How many "I haven't heard back in a week" do we see here and on the mailop > list, and how many "Congrats to so-n-so who fixed my problem in 5 minutes flat?" Also, unless the requester already has a close relationship with someone in that department at the company they are contacting - it is sort of offensive to contact them without FIRST filling out the form and allotting a reasonable time for a response. Then, if filling out the form didn't work as fast as expected - THEN it might be appropriate to contact someone directly to help escalate the form submission. That is the RIGHT way to do these things. The opposite of this produces insufficiency, miscommunication, legal entanglements (if things didn't get handled properly), lost audit-trails/metrics etc. Some larger companies FORBID their employees from doing such direct help that is entirely outside their regular support system. -- Rob McEwen From bill at herrin.us Thu Jan 4 18:29:49 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Jan 2018 13:29:49 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> Message-ID: On Thu, Jan 4, 2018 at 11:48 AM, Michael Crapse wrote: > I've never dealt with a support queue that resolved the issue faster than > a direct contact. > I've never dealt with a support queue that's more competent than the last direct contact I talked with. Navigating the support queue to the guy competent to deal with my problem is one of the more infuriating things about big company support. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From fhr at fhrnet.eu Thu Jan 4 19:13:02 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Thu, 4 Jan 2018 19:13:02 +0000 Subject: IPv4 smaller than /24 leasing? Message-ID: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Hi, I have stumbled upon this site [1] which seems to offer /27 IPv4 leasing. They also claim "All of our IPv4 address space can be used on any network in any location." I thought that the smallest prefix size one could get routed globally is /24? So how does this work? [1] http://www.forked.net/ip-address-leasing/ Thanks -- Filip Hruska Linux System Administrator From job at instituut.net Thu Jan 4 19:16:50 2018 From: job at instituut.net (Job Snijders) Date: Thu, 04 Jan 2018 19:16:50 +0000 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Message-ID: On Thu, 4 Jan 2018 at 20:13, Filip Hruska wrote: > I have stumbled upon this site [1] which seems to offer /27 IPv4 leasing. > They also claim "All of our IPv4 address space can be used on any network > in any location." > > I thought that the smallest prefix size one could get routed globally is > /24? Yes So how does this work? > Probably with GRE, IPIP or OpenVPN tunnels. Kind regards, Job From lguillory at reservetele.com Thu Jan 4 19:16:58 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Thu, 4 Jan 2018 19:16:58 +0000 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB40D12D@RTC-EXCH01.RESERVE.LDS> Notice that the LOA is only checked off on /24 or larger. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Filip Hruska Sent: Thursday, January 04, 2018 1:13 PM To: NANOG Subject: IPv4 smaller than /24 leasing? Hi, I have stumbled upon this site [1] which seems to offer /27 IPv4 leasing. They also claim "All of our IPv4 address space can be used on any network in any location." I thought that the smallest prefix size one could get routed globally is /24? So how does this work? [1] http://www.forked.net/ip-address-leasing/ Thanks -- Filip Hruska Linux System Administrator From chk at pobox.com Thu Jan 4 19:27:31 2018 From: chk at pobox.com (Harald Koch) Date: Thu, 4 Jan 2018 14:27:31 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Message-ID: "IPv6 available upon request. " LOL. -- Harald From fhr at fhrnet.eu Thu Jan 4 20:08:37 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Thu, 4 Jan 2018 20:08:37 +0000 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Message-ID: <01020160c2ca2b66-bacb2d96-34f9-41bf-be99-e34c904a4d78-000000@eu-west-1.amazonses.com> Thanks for all the responses! Seems like I was right about doubting this. Regards -- Filip Hruska Linux System Administrator Dne 1/4/18 v 20:20 Matt Harris napsal(a): > They're probably using GRE or other sorts of tunnels, I'd imagine?  It > would likely involve increased latency, as any packets coming to those > addresses would hit them first, and then be tunneled - either over the > public internet using gre or some kind of vpn, or perhaps via a > private connection or even an IX, to you?  As far as outgoing traffic > from those addresses, you'd probably need to make sure that any > upstreams you're sending packets to from those addresses are not > running urpf which would cause them to be discarded, or otherwise get > around such a configuration. > > Take care, > Matt > > > On Thu, Jan 4, 2018 at 1:13 PM, Filip Hruska > wrote: > > Hi, > > I have stumbled upon this site [1] which seems to offer /27 IPv4 > leasing. > They also claim "All of our IPv4 address space can be used on any > network in any location." > > I thought that the smallest prefix size one could get routed > globally is /24? > So how does this work? > > [1] http://www.forked.net/ip-address-leasing/ > > > > Thanks > > -- > Filip Hruska > Linux System Administrator > > > > > -- > Matt Harris - Chief Security Officer > Main: +1 855.696.3834 ext 103 > Mobile: +1 908.590.9472 > Email:matt at netfire.net From goemon at sasami.anime.net Thu Jan 4 20:58:48 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Thu, 4 Jan 2018 12:58:48 -0800 (PST) Subject: Attacks from poneytelecom.eu In-Reply-To: <195982.1515082339@turing-police.cc.vt.edu> References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> Message-ID: On Thu, 4 Jan 2018, valdis.kletnieks at vt.edu wrote: > On Thu, 04 Jan 2018 09:33:51 -0500, William Herrin said: >> Why anyone thinks it's acceptable for the form submission to vanish in to >> the faceless support queue is more of a quandary. The form submission >> should provide a case number, the individual to whom it is assigned, direct >> contact information for that individual and a promise that your report will >> receive a response. > The very real problem with direct contact info is that people latch onto it. > Then, if there's another issue the person will bypass your form submission, > send a direct e-mail - which would then not be dealt with if that particular > person wasn't working, for reasons ranging from vacation to no longer being > with the provider in an abuse desk role. > > Been there, done that. Been out of the country and offline for 36 hours, > reconnect and there's a user with a problem that would have been dealt > with 36 hours earlier if they had sent it to our help desk instead of to me > directly. They use your direct contact info because your help desk isn't responsive. They go where they get results. No results from help desk = direct contact to you. -Dan From goemon at sasami.anime.net Thu Jan 4 21:02:51 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Thu, 4 Jan 2018 13:02:51 -0800 (PST) Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> Message-ID: On Thu, 4 Jan 2018, William Herrin wrote: > On Thu, Jan 4, 2018 at 11:48 AM, Michael Crapse wrote: >> I've never dealt with a support queue that resolved the issue faster than >> a direct contact. > I've never dealt with a support queue that's more competent than the last > direct contact I talked with. Navigating the support queue to the guy > competent to deal with my problem is one of the more infuriating things > about big company support. it does get kind of old when you have to argue with first tier support on how to read smtp headers. or that an IP address registered to them in ARIN actually belongs to them. people reach out to nanog because first tier support is clueless and completely ineffective. when the first tier incompetence stops, the direct contacts will stop too. -Dan From bill at herrin.us Thu Jan 4 21:12:39 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Jan 2018 16:12:39 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Message-ID: On Thu, Jan 4, 2018 at 2:16 PM, Job Snijders wrote: > On Thu, 4 Jan 2018 at 20:13, Filip Hruska wrote: > > I thought that the smallest prefix size one could get routed globally is > > /24? So how does this work? > > > Probably with GRE, IPIP or OpenVPN tunnels. > Hi Flip, Job: With the cooperation of your local ISP, it's possible to get clever about this. If your ISP sets its filter to allow it, you can send packets from the /27 directly without having to transit the GRE tunnel. So, half the path has no latency hit at all. The tunnel ingress which takes the /24 off the Internet and sends the /27 to you does not have to be a single node in a single location. GRE and IPIP both support stateless multipoint tunnels where they can receive packets from multiple sources. The /24 can be anycasted from multiple nodes around the world allowing near-optimal routing from most origins. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mh at xalto.net Thu Jan 4 21:56:54 2018 From: mh at xalto.net (Michael Hallgren) Date: Thu, 04 Jan 2018 22:56:54 +0100 Subject: IPv4 smaller than /24 =?UTF-8?Q?leasing=3F?= In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Message-ID: <8f321b3202fc1538f3991132816251a7@webmail.xalto.net> Le 2018-01-04 20:27, Harald Koch a écrit : > "IPv6 available upon request. " > > LOL. +1 :-) mh From mh at xalto.net Thu Jan 4 22:07:08 2018 From: mh at xalto.net (Michael Hallgren) Date: Thu, 04 Jan 2018 23:07:08 +0100 Subject: IPv4 smaller than /24 =?UTF-8?Q?leasing=3F?= In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Message-ID: Le 2018-01-04 20:16, Job Snijders a écrit : > On Thu, 4 Jan 2018 at 20:13, Filip Hruska wrote: > >> I have stumbled upon this site [1] which seems to offer /27 IPv4 >> leasing. >> They also claim "All of our IPv4 address space can be used on any >> network >> in any location." >> >> I thought that the smallest prefix size one could get routed globally >> is >> /24? > > > Yes > > So how does this work? >> > Probably with GRE, IPIP or OpenVPN tunnels. > > Kind regards, > > Job IPv4 /24 is commonly the minimal chunk advertised to (and accepted by) neighbors. If I run a global (or regional) network, I may advertise this /24 -- or rather an aggregate covering it -- over my diverse interconnection with neighbors, your /27 being part of the chunk and routed to you internally (if you're va customer)-- no need for encapsulation efforts. Similar scenario may be multi-upstream, subject to acceptance of "punching holes in aggregates"... Am I missing something? What's the trigger for doing tunneling here? Happy New Year '18, by the way ! mh From bill at herrin.us Thu Jan 4 22:16:47 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Jan 2018 17:16:47 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Message-ID: On Thu, Jan 4, 2018 at 5:07 PM, Michael Hallgren wrote: > Am I missing something? What's the trigger for doing tunneling here? > With "IP address leasing" you aren't connected to the network which holds the address registration. For leasing less than a /24, they need a plan other than "advertise to your peers with BGP" because even if your peer accepts a /27, most of their peers will not. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mh at xalto.net Thu Jan 4 22:31:05 2018 From: mh at xalto.net (Michael Hallgren) Date: Thu, 04 Jan 2018 23:31:05 +0100 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> Message-ID: <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> Thanks Bill. Kinda ugly, but OK I see... Prefer v6 ;-) mh Le 4 janv. 2018 à 23:17, à 23:17, William Herrin a écrit: >On Thu, Jan 4, 2018 at 5:07 PM, Michael Hallgren wrote: > >> Am I missing something? What's the trigger for doing tunneling here? >> > >With "IP address leasing" you aren't connected to the network which >holds >the address registration. > >For leasing less than a /24, they need a plan other than "advertise to >your >peers with BGP" because even if your peer accepts a /27, most of their >peers will not. > >Regards, >Bill Herrin > > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: From lists at mtin.net Thu Jan 4 22:40:27 2018 From: lists at mtin.net (Justin Wilson) Date: Thu, 4 Jan 2018 17:40:27 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> Message-ID: Yes, we do this for several clients. We route them a smaller than 24 block over a tunnel. Which bring up an interesting question. Will there be a time where the smallest block size recognized will be something smaller than a /24? /25, /26 ? Most modern routers have the horsepower to deal with larger route tables. I know of dozens, if not hundreds of small ISPs that can’t participate in BGP because they don’t have big enough blocks. Many others who do are not utilizing their /24 so it just kinda sits there. They have to have their provider assigned IP space be advertised. Does not help them getting on to an IX though. I know I know IPV6 is the answer not going to accepting smaller blocks. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com www.fd-ix.com > On Jan 4, 2018, at 5:31 PM, Michael Hallgren wrote: > > Thanks Bill. Kinda ugly, but OK I see... Prefer v6 ;-) > mh > > Le 4 janv. 2018 à 23:17, à 23:17, William Herrin a écrit: >> On Thu, Jan 4, 2018 at 5:07 PM, Michael Hallgren wrote: >> >>> Am I missing something? What's the trigger for doing tunneling here? >>> >> >> With "IP address leasing" you aren't connected to the network which >> holds >> the address registration. >> >> For leasing less than a /24, they need a plan other than "advertise to >> your >> peers with BGP" because even if your peer accepts a /27, most of their >> peers will not. >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: > From bill at herrin.us Thu Jan 4 22:48:40 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Jan 2018 17:48:40 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> Message-ID: On Thu, Jan 4, 2018 at 5:40 PM, Justin Wilson wrote: > I know of dozens, if not hundreds of small ISPs that can’t participate in > BGP because they don’t have big enough blocks. Hi Justin, Not much of an ISP if they can't get a /24. We're talking about a one-time market purchase under $5000 and the ARIN justification for that small a block almost writes itself. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From valdis.kletnieks at vt.edu Thu Jan 4 22:51:20 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 04 Jan 2018 17:51:20 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> Message-ID: <167197.1515106280@turing-police.cc.vt.edu> On Thu, 04 Jan 2018 17:40:27 -0500, Justin Wilson said: > I know of dozens, if not hundreds of small ISPs that can’t participate in BGP > because they don’t have big enough blocks. What's the business model, if you have less than 120 customers? Selling value-add services on top of moving the packets? Or just be in a country where cost-of-everything is so cheap that you can make a profit on 120 customers at $20/mo? And hundreds? Is that "in the US", or "worldwide"? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From mh at xalto.net Thu Jan 4 22:56:21 2018 From: mh at xalto.net (Michael Hallgren) Date: Thu, 04 Jan 2018 23:56:21 +0100 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> Message-ID: By the way, RIPE still seems to provide fresh /22s to new LIRs. Same in the ARIN region? mh Le 4 janv. 2018 à 23:50, à 23:50, William Herrin a écrit: >On Thu, Jan 4, 2018 at 5:40 PM, Justin Wilson wrote: > >> I know of dozens, if not hundreds of small ISPs that can’t >participate in >> BGP because they don’t have big enough blocks. > > >Hi Justin, > >Not much of an ISP if they can't get a /24. We're talking about a >one-time >market purchase under $5000 and the ARIN justification for that small a >block almost writes itself. > >Regards, >Bill Herrin > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: From nanog at ics-il.net Thu Jan 4 23:06:31 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 4 Jan 2018 17:06:31 -0600 (CST) Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> Message-ID: <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> There are hundreds of ISPs with under 500 customers. More start up every week. No need to marginalize them. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "William Herrin" To: "Justin Wilson" Cc: "NANOG" Sent: Thursday, January 4, 2018 4:48:40 PM Subject: Re: IPv4 smaller than /24 leasing? On Thu, Jan 4, 2018 at 5:40 PM, Justin Wilson wrote: > I know of dozens, if not hundreds of small ISPs that can’t participate in > BGP because they don’t have big enough blocks. Hi Justin, Not much of an ISP if they can't get a /24. We're talking about a one-time market purchase under $5000 and the ARIN justification for that small a block almost writes itself. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nanog at ics-il.net Thu Jan 4 23:07:22 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 4 Jan 2018 17:07:22 -0600 (CST) Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> Message-ID: <726388215.16542.1515107240838.JavaMail.mhammett@ThunderFuck> No. ARIN is out of IPv4 other than IXes, critical infrastructure and IPv6 transition. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Michael Hallgren" To: "William Herrin" Cc: "NANOG" Sent: Thursday, January 4, 2018 4:56:21 PM Subject: Re: IPv4 smaller than /24 leasing? By the way, RIPE still seems to provide fresh /22s to new LIRs. Same in the ARIN region? mh Le 4 janv. 2018 à 23:50, à 23:50, William Herrin a écrit: >On Thu, Jan 4, 2018 at 5:40 PM, Justin Wilson wrote: > >> I know of dozens, if not hundreds of small ISPs that can’t >participate in >> BGP because they don’t have big enough blocks. > > >Hi Justin, > >Not much of an ISP if they can't get a /24. We're talking about a >one-time >market purchase under $5000 and the ARIN justification for that small a >block almost writes itself. > >Regards, >Bill Herrin > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: From nanog at ics-il.net Thu Jan 4 23:08:42 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 4 Jan 2018 17:08:42 -0600 (CST) Subject: IPv4 smaller than /24 leasing? In-Reply-To: <167197.1515106280@turing-police.cc.vt.edu> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <167197.1515106280@turing-police.cc.vt.edu> Message-ID: <293262883.16546.1515107320754.JavaMail.mhammett@ThunderFuck> Startups, people serving areas where there aren't a ton of people, etc. I'm sure they'd love to have /24s, but ARIN is out of them and the market is too pricey for most of these guys. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "valdis kletnieks" To: "Justin Wilson" Cc: "NANOG" Sent: Thursday, January 4, 2018 4:51:20 PM Subject: Re: IPv4 smaller than /24 leasing? On Thu, 04 Jan 2018 17:40:27 -0500, Justin Wilson said: > I know of dozens, if not hundreds of small ISPs that can’t participate in BGP > because they don’t have big enough blocks. What's the business model, if you have less than 120 customers? Selling value-add services on top of moving the packets? Or just be in a country where cost-of-everything is so cheap that you can make a profit on 120 customers at $20/mo? And hundreds? Is that "in the US", or "worldwide"? From bill at herrin.us Thu Jan 4 23:15:46 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Jan 2018 18:15:46 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> Message-ID: On Thu, Jan 4, 2018 at 4:02 PM, Dan Hollis wrote: > On Thu, 4 Jan 2018, William Herrin wrote: > >> On Thu, Jan 4, 2018 at 11:48 AM, Michael Crapse >> wrote: >> >>> I've never dealt with a support queue that resolved the issue faster than >>> a direct contact. >>> >> I've never dealt with a support queue that's more competent than the last >> direct contact I talked with. Navigating the support queue to the guy >> competent to deal with my problem is one of the more infuriating things >> about big company support. >> > > it does get kind of old when you have to argue with first tier support on > how to read smtp headers. or that an IP address registered to them in ARIN > actually belongs to them. > Those are the good ones. The bad ones are when the the support tech wanders down the script without understanding you at all. "Your email server at 1.2.3.4 gave me the following error message when my server at 6.7.8.9 tried to pass email to bob at yourcompany.com from joe at mycompany.com at 13:54:06 UTC." "Reboot your computer. Then please take this survey to let me know how I did." -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From list at satchell.net Thu Jan 4 23:34:35 2018 From: list at satchell.net (Stephen Satchell) Date: Thu, 4 Jan 2018 15:34:35 -0800 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> Message-ID: <7300b875-2eea-4f34-89f4-6ca984ff3b06@satchell.net> On 01/04/2018 01:02 PM, Dan Hollis wrote: > when the first tier incompetence stops, the direct contacts will stop too. But, but, but...when the first tier support person gets the training to not be incompetent, he is promoted to the second tier and the vacuum is filled with another incompetent first-tier person. So, by definition, the first tier of support will only be able to answer questions "from the book". Anything more complex than what's in "the book" is bumped to the second tier...where the problem is above the second-tier pay grade and it gets bumped further up the chain. It's a variation of the Peter Principal: ex-incompetents will rise up the promotion ladder. From bill at herrin.us Thu Jan 4 23:21:41 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Jan 2018 18:21:41 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, Jan 4, 2018 at 6:06 PM, Mike Hammett wrote: > There are hundreds of ISPs with under 500 customers. More start up every > week. No need to marginalize them. > Hi Mike, No disrespect, but anyone who can't afford to spend $5000 on resources critical to their activity is not in the Internet business or any other kind of business and should probably stop lying to themselves about that. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From dovid at telecurve.com Fri Jan 5 00:01:05 2018 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 4 Jan 2018 19:01:05 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> Message-ID: I can tell you that when we started (and there were IP's still available) we first leased from another company to get our feet when and run tests before we requested our own resources. On Thu, Jan 4, 2018 at 6:21 PM, William Herrin wrote: > On Thu, Jan 4, 2018 at 6:06 PM, Mike Hammett wrote: > > > There are hundreds of ISPs with under 500 customers. More start up every > > week. No need to marginalize them. > > > > Hi Mike, > > No disrespect, but anyone who can't afford to spend $5000 on resources > critical to their activity is not in the Internet business or any other > kind of business and should probably stop lying to themselves about that. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From lists at mtin.net Fri Jan 5 00:07:28 2018 From: lists at mtin.net (Justin Wilson) Date: Thu, 4 Jan 2018 19:07:28 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <167197.1515106280@turing-police.cc.vt.edu> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <167197.1515106280@turing-police.cc.vt.edu> Message-ID: Most of the ones I know personally are doing CGN and have no real need for IP addresses. I know of Wireless ISPs with 2000 customers and only about 50 IPv4 addresses in use for nat and the occasional Public IP customer. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On Jan 4, 2018, at 5:51 PM, valdis.kletnieks at vt.edu wrote: > > On Thu, 04 Jan 2018 17:40:27 -0500, Justin Wilson said: >> I know of dozens, if not hundreds of small ISPs that can’t participate in BGP >> because they don’t have big enough blocks. > > What's the business model, if you have less than 120 customers? Selling > value-add services on top of moving the packets? Or just be in a country > where cost-of-everything is so cheap that you can make a profit on 120 > customers at $20/mo? > > And hundreds? Is that "in the US", or "worldwide"? From lists at mtin.net Fri Jan 5 00:20:26 2018 From: lists at mtin.net (Justin Wilson) Date: Thu, 4 Jan 2018 19:20:26 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> Message-ID: <552980B6-5441-4F5A-BE6B-C173E82CD499@mtin.net> And this is exactly what other companies are doing. The traditional way of doing a startup ISP is: 1.You get provider assigned IP space 2.You grow big enough to get your own IP space, historically from ARIN. Nowadays you have to buy it on the open market. 3.You re-adddress your network for the IP space you have. 4.Chewing up the /24 when you may not too in order to meet justification. So now, we have a startups and growing ISPs. I have multiple clients who are in the exact same scenario I am going to describe. They are a startup and can’t justify a /24 so they hope to find two backbone providers to play ball. They hope one will assign them a full /24 so they can participate in BGP. That provider is probably charging them $1 per IP per month. Okay fine, pay it. As said in a previous e-mail, if they can’t afford it they shouldn’t be in business right? They go through the ARIN process to get an ASN and can now participate in BGP. Great, they bring up BGP and work towards having the cash flow to buy a /24 on the open market. Again, if they can’t afford to play they shouldn’t be in business right? Cash flow pays for the ability to buy a /24 in 8-14 months. $4,000 plus the $2500 they spent on leasing fees. Again, if they can’t afford it don’t play huh? So now, they have a /24 they really don’t need. In order to meet ARIN justification they hand out IPs to people who really aren’t in their business model just to meet justification. Before you know it they are using 80% of a /24 when they really only need half or less of it. The /24 is too small to scale of giving everyone publics, so their network design is centered around 1: many NAT, CGN, and other such things. How is this a good use of resources when they have to justify 80% of a /24 in which they only need half of? I have 5 ISPs I work with that have 300-500 customer and are using a /26 or smaller of IP space. They can’t have true redundancy they are able to manage because they can’t do BGP themselves. So they are tied to one ISP because thats where they get their space from. Or, going back to the original part of this thread, they lease from someone across a tunnel. Even then, they are still tied to someone. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On Jan 4, 2018, at 7:01 PM, Dovid Bender wrote: > > I can tell you that when we started (and there were IP's still available) > we first leased from another company to get our feet when and run tests > before we requested our own resources. > > On Thu, Jan 4, 2018 at 6:21 PM, William Herrin wrote: > >> On Thu, Jan 4, 2018 at 6:06 PM, Mike Hammett wrote: >> >>> There are hundreds of ISPs with under 500 customers. More start up every >>> week. No need to marginalize them. >>> >> >> Hi Mike, >> >> No disrespect, but anyone who can't afford to spend $5000 on resources >> critical to their activity is not in the Internet business or any other >> kind of business and should probably stop lying to themselves about that. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> > From johnl at iecc.com Fri Jan 5 00:41:26 2018 From: johnl at iecc.com (John Levine) Date: 4 Jan 2018 19:41:26 -0500 Subject: making the queries go away, was Re: Anyone else blacklisted this morning In-Reply-To: <20180102170409.GA5619@gsp.org> Message-ID: <20180105004127.A1EFF18D65F4@ary.qy> In article <20180102170409.GA5619 at gsp.org> you write: >On Tue, Jan 02, 2018 at 04:46:02PM +0000, Mel Beckman quoted: >> "rbl.iprange.net will mark every ip address as listed to force removal of this server." > >Apparently they didn't read section 3.4 of RFC 6471: I agree that listing the world is a bad idea but I feel their pain, having a few DNSBL-like things here that are hammered on at great length by broken clients. If you want the traffic to go away, what do you do? I run a little DNS server at contacts.abuse.net that provides abuse contact information in TXT records. For reasons I can only imagine, a few hosts hammer on them like crazy (one seems to have the goal of looking up every 2ld in the .at domain) which is a pain. So I've started doing nameserver poisoining. If one of those annoying hosts asks for, say, foo.bar.contacts.abuse.net which is how you ask for the contacts for domain foo.bar, it returns bar.contacts.abuse.net. NS 604800 abcde.n.contacts.abuse.net. ... bar.contacts.abuse.net. NS 604800 qwert.n.contacts.abuse.net. with 12 fake NS records with randomish hostnames. Then when they do A or AAAA lookups for those host names, I send back a couple of dozen fake A or AAAA records. In my experience that makes them go away pretty fast, with only the occasional revisit when they want something in an obscure TLD that I haven't poisoned yet. This is all written in perl, which turned out to be pretty easy, and not using Net::DNS or anything like that, either. I suppose if I wanted to do this on behalf of a normal nameserver I could use some packet filters to divert traffic from annoying hosts to the poison server. R's, John From johnl at iecc.com Fri Jan 5 00:43:02 2018 From: johnl at iecc.com (John Levine) Date: 4 Jan 2018 19:43:02 -0500 Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: Message-ID: <20180105004303.565C418D666D@ary.qy> In article you write: >If you're going to run a DNSBL to advertise your mail software, >perhaps do so in a way that doesn't flip the bird at everyone using it. On the other hand if you're going to use DNSBLs, you really should do the tests in RFC 5782 every once in a while so you stop using BLs that don't exist any more. It's not hard. R's, John From valdis.kletnieks at vt.edu Fri Jan 5 01:08:58 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 04 Jan 2018 20:08:58 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> Message-ID: <16399.1515114538@turing-police.cc.vt.edu> On Thu, 04 Jan 2018 12:58:48 -0800, Dan Hollis said: > On Thu, 4 Jan 2018, valdis.kletnieks at vt.edu wrote: > > Been there, done that. Been out of the country and offline for 36 hours, > > reconnect and there's a user with a problem that would have been dealt > > with 36 hours earlier if they had sent it to our help desk instead of to me > > directly. > > They use your direct contact info because your help desk isn't responsive. Not really - because a big chunk of the time, I end up opening a ticket with the help desk in their behalf, because I wasn't even the person who was actually responsible for fixing their problem (I do infrastructure, not user services). They just splat out a mail to a name they recognize because I've been here almost 3 decades now. Why they think I can help with a NetApp CIFS permission issue just because they remember I fixed their SGI system in the late 90s is beyond me... Plus, I know for a fact that if they called our help desk, they'd probably have a ticket open and called back by somebody faster than I would reply, because the help desk's SLA is measured in "reply in hours", while mine is "within 2 business days" for non-system-down situations. Hell, took me 4 hours to respond to your mail. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From mel at beckman.org Fri Jan 5 01:19:55 2018 From: mel at beckman.org (Mel Beckman) Date: Fri, 5 Jan 2018 01:19:55 +0000 Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: <20180105004303.565C418D666D@ary.qy> References: , <20180105004303.565C418D666D@ary.qy> Message-ID: <530C5793-4D51-43D2-A79D-D7EA654AD7BC@beckman.org> Alas, these RBLs are often hard-coded into firewalls. Non-sophisticated users just think they have a check box saying "block spam". Fixing those IS hard. -mel > On Jan 4, 2018, at 4:45 PM, John Levine wrote: > > In article you write: >> If you're going to run a DNSBL to advertise your mail software, >> perhaps do so in a way that doesn't flip the bird at everyone using it. > > On the other hand if you're going to use DNSBLs, you really should do > the tests in RFC 5782 every once in a while so you stop using BLs that > don't exist any more. It's not hard. > > R's, > John From valdis.kletnieks at vt.edu Fri Jan 5 01:24:44 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 04 Jan 2018 20:24:44 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <552980B6-5441-4F5A-BE6B-C173E82CD499@mtin.net> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> <552980B6-5441-4F5A-BE6B-C173E82CD499@mtin.net> Message-ID: <17538.1515115484@turing-police.cc.vt.edu> On Thu, 04 Jan 2018 19:20:26 -0500, Justin Wilson said: > How is this a good use of resources when they have to justify 80% of a /24 in > which they only need half of? I have 5 ISPs I work with that have 300-500 > customer and are using a /26 or smaller of IP space. They can���t have true > redundancy they are able to manage because they can���t do BGP themselves. So > they are tied to one ISP because thats where they get their space from. Or, > going back to the original part of this thread, they lease from someone across > a tunnel. Even then, they are still tied to someone. So you CGNAT 500 users that would easily qualify you for a /22 into a ./26, and then complain you can't get a /24. "Doctor, it hurts when I do this" "Don't do that then", -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From johnl at iecc.com Fri Jan 5 01:43:08 2018 From: johnl at iecc.com (John R. Levine) Date: 4 Jan 2018 20:43:08 -0500 Subject: Anyone else blacklisted this morning by rbl.iprange.net? In-Reply-To: <530C5793-4D51-43D2-A79D-D7EA654AD7BC@beckman.org> References: , <20180105004303.565C418D666D@ary.qy> <530C5793-4D51-43D2-A79D-D7EA654AD7BC@beckman.org> Message-ID: > Alas, these RBLs are often hard-coded into firewalls. Non-sophisticated > users just think they have a check box saying "block spam". Fixing those > IS hard. I believe there are cases where people have made it hard, but there are limits on how much I believe in protecting people from the consequences of their ineptness. Perhaps we should spin up a little DNS cache just for DNSBL queries. R's, John >> In article you write: >>> If you're going to run a DNSBL to advertise your mail software, >>> perhaps do so in a way that doesn't flip the bird at everyone using it. >> >> On the other hand if you're going to use DNSBLs, you really should do >> the tests in RFC 5782 every once in a while so you stop using BLs that >> don't exist any more. It's not hard. From math at sizone.org Fri Jan 5 03:53:03 2018 From: math at sizone.org (Ken Chase) Date: Thu, 4 Jan 2018 22:53:03 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <17538.1515115484@turing-police.cc.vt.edu> References: <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> <552980B6-5441-4F5A-BE6B-C173E82CD499@mtin.net> <17538.1515115484@turing-police.cc.vt.edu> Message-ID: <20180105035303.GG3157@sizone.org> $5k aint nothing. I started with less than that (but hung off the colo's in house bw through NAC.net til I could wean off it). I imagine tiny communities (and say on remote native reserves for eg) that $5k additional expense could be limiting. And soon to become even harder to setup an isp? ttps://np.reddit.com/r/technology/comments/7o41rf/the_fcc_is_preparing_to_weaken_the_definition_of/ds6w3aw/ /kc -- Ken Chase - math at sizone.org GUelph Canada From nanog at ics-il.net Fri Jan 5 12:57:51 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 5 Jan 2018 06:57:51 -0600 (CST) Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> Message-ID: <280709150.16731.1515157069711.JavaMail.mhammett@ThunderFuck> No disrespect, but here's some disrespect? $5k for some numbers or $5k for the equipment to bring Internet to another hundred people? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "William Herrin" To: "Mike Hammett" Cc: "NANOG" Sent: Thursday, January 4, 2018 5:21:41 PM Subject: Re: IPv4 smaller than /24 leasing? On Thu, Jan 4, 2018 at 6:06 PM, Mike Hammett < nanog at ics-il.net > wrote: There are hundreds of ISPs with under 500 customers. More start up every week. No need to marginalize them. Hi Mike, No disrespect, but anyone who can't afford to spend $5000 on resources critical to their activity is not in the Internet business or any other kind of business and should probably stop lying to themselves about that. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: < http://www.dirtside.com/ > From mh at xalto.net Fri Jan 5 13:01:33 2018 From: mh at xalto.net (Michael Hallgren) Date: Fri, 05 Jan 2018 14:01:33 +0100 Subject: IPv4 smaller than /24 =?UTF-8?Q?leasing=3F?= In-Reply-To: <726388215.16542.1515107240838.JavaMail.mhammett@ThunderFuck> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <726388215.16542.1515107240838.JavaMail.mhammett@ThunderFuck> Message-ID: Le 2018-01-05 00:07, Mike Hammett a écrit : > No. ARIN is out of IPv4 other than IXes, critical infrastructure and > IPv6 transition. > Thanks. Good argument for going IPv6. :-) mh > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Michael Hallgren" > To: "William Herrin" > Cc: "NANOG" > Sent: Thursday, January 4, 2018 4:56:21 PM > Subject: Re: IPv4 smaller than /24 leasing? > > By the way, RIPE still seems to provide fresh /22s to new LIRs. Same > in the ARIN region? > mh > > Le 4 janv. 2018 à 23:50, à 23:50, William Herrin a > écrit: >> On Thu, Jan 4, 2018 at 5:40 PM, Justin Wilson wrote: >> >>> I know of dozens, if not hundreds of small ISPs that can’t >> participate in >>> BGP because they don’t have big enough blocks. >> >> >> Hi Justin, >> >> Not much of an ISP if they can't get a /24. We're talking about a >> one-time >> market purchase under $5000 and the ARIN justification for that small >> a >> block almost writes itself. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: From nanog at ics-il.net Fri Jan 5 13:02:21 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 5 Jan 2018 07:02:21 -0600 (CST) Subject: IPv4 smaller than /24 leasing? In-Reply-To: <20180105035303.GG3157@sizone.org> References: <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> <552980B6-5441-4F5A-BE6B-C173E82CD499@mtin.net> <17538.1515115484@turing-police.cc.vt.edu> <20180105035303.GG3157@sizone.org> Message-ID: <1176917401.16740.1515157339360.JavaMail.mhammett@ThunderFuck> The topic of the Reddit thread won't really have any impact on anything. That 25 megabit definition wasn't used for anything other than reporting anyway. It had no impact on funding, deployment, etc. It wasn't necessary in the first place, but probably not smart to remove. Getting too far into politics now, me thinks. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ken Chase" To: "valdis kletnieks" Cc: "NANOG" Sent: Thursday, January 4, 2018 9:53:03 PM Subject: Re: IPv4 smaller than /24 leasing? $5k aint nothing. I started with less than that (but hung off the colo's in house bw through NAC.net til I could wean off it). I imagine tiny communities (and say on remote native reserves for eg) that $5k additional expense could be limiting. And soon to become even harder to setup an isp? ttps://np.reddit.com/r/technology/comments/7o41rf/the_fcc_is_preparing_to_weaken_the_definition_of/ds6w3aw/ /kc -- Ken Chase - math at sizone.org GUelph Canada From bill at herrin.us Fri Jan 5 14:08:38 2018 From: bill at herrin.us (William Herrin) Date: Fri, 5 Jan 2018 09:08:38 -0500 Subject: IPv4 smaller than /24 leasing? In-Reply-To: <280709150.16731.1515157069711.JavaMail.mhammett@ThunderFuck> References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> <280709150.16731.1515157069711.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, Jan 5, 2018 at 7:57 AM, Mike Hammett wrote: > No disrespect, but here's some disrespect? > > $5k for some numbers or $5k for the equipment to bring Internet to another > hundred people? > "It's not worth spending $5k" is a very different statement than "I can't afford $5k." The former is a legitimate business decision that businesses make every day. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From baldur.norddahl at gmail.com Fri Jan 5 15:35:37 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 5 Jan 2018 16:35:37 +0100 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> <280709150.16731.1515157069711.JavaMail.mhammett@ThunderFuck> Message-ID: Joining an IX is in most cases much more expensive than buying a /24. You can get a /26 from your upstream. Having multiple upstreams is in most cases much more expensive than buying a /24. I do not see a real problem here. Aside from the irritation of having to pay for resources others got for free and then horded. Regards Baldur From SNaslund at medline.com Fri Jan 5 16:22:03 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 5 Jan 2018 16:22:03 +0000 Subject: IPv4 smaller than /24 leasing? In-Reply-To: References: <01020160c29746c7-36b32ef0-2312-4d28-ade9-dab0d008b31d-000000@eu-west-1.amazonses.com> <332ad84a-d713-4cff-9a8b-1afd6b71f085@xalto.net> <1229248664.16539.1515107190964.JavaMail.mhammett@ThunderFuck> <280709150.16731.1515157069711.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B402899CC210@MUNPRDMBXA1.medline.com> Agreed having been in the ISP business since there were ISPs, the most common way to get started is to get an allocation from your upstream provider. A bigger Tier 1 ish provider is more likely to give you a larger allocation since they hold a lot of resources they are not costing them much to retain. While you are at it, get an IP V6 allocation and AS to start going that way as much as possible. I wouldn't go with an IX initially (they become a more attractive option once you get to the size where peering would be an option). Most startups I have worked with get going with two upstream providers and a block provided by one of them. Make sure you check with both carriers on their policy regarding advertisement of the block from both upstreams. In order to get the two upstreams even close to balanced you will probably have to have the upstream that owns the block break the supernet for you (if one carrier is advertising the /24 you will get more traffic that way since it is a more specific route). I would also recommend getting upstream carriers that are similar in tier because if you have a very well connected upstream and a much smaller one, you will be less likely to use both connections effectively. Make sure your upstream will support V4 and V6 on the same transport circuit (most will now). Be sure you like the carrier that gives you the initial allocation since you are going to be a voluntary hostage for a while. Trust me, you want two upstreams even if you have to sell your dog to do it. You do not want your fragile new business to get wiped out by a single upstream outage (remember to them you are just a single customer, to you it is your whole ball game). You are in for some engineering work trying to squeeze the most out of the very limited V4 resources and are going to have to push back hard on allocations to customers to avoid ripping through them quickly. You are going to have to do the heavy lifting of NAT to get the customers the connectivity to the V4 world (until you can get them to V6). The most important factor will be whether the majority of your customers are business vs residential. Another big start up question is how much CPE do you want to manage. If you own the CPE you can get fancier with it and not have to worry about customers having to deal with V6 configuration. If they own the CPE you have to make it as easy as possible for them. Having worked in both environments I have to say that customer owned CPE costs the small ISP a lot of time and effort in support (way more than home CPE costs). Do NOT charge a customer less for using their own CPE, discourage that as much as possible. It is more pain for you when they provide the CPE for sure. Business = usually less churn but more likely to want a V4 static address Residential = more churn and the majority don't care whether they are running V4 or V6 as long as it all works automagically. The most successful ISPs I have worked with have a mix of business and residential which gives you better traffic patterns throughout the day. Business oriented ISPs tend to be underutilized after hours and residential ISPs tend to get hammered in prime hours. Business customers give you great stability in regular cash flow and residential tends to up the customer count to smooth out the churn percentage. Churn is your biggest enemy. Figure out how long you need to retain a customer to achieve positive cash flow after provisioning costs are factored in. Most times this number comes as a shock to a new ISP. If cash is so tight that a $5k expense is an issue you need to carefully examine whether you can survive the original provisioning of the network to get to positive cash flow. I have been out of the finance side for quite some time now but I don't think it would be unusual to find that you have to keep a customer for 18 months or so before you are making a dime on them. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baldur Norddahl >Sent: Friday, January 05, 2018 9:36 AM >To: nanog at nanog.org >Subject: Re: IPv4 smaller than /24 leasing? > >Joining an IX is in most cases much more expensive than buying a /24. You can get a /26 from your upstream. Having multiple upstreams is in most cases much more expensive than buying a /24. > >I do not see a real problem here. Aside from the irritation of having to pay for resources others got for free and then horded. > >Regards > >Baldur From cscora at apnic.net Fri Jan 5 18:02:39 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Jan 2018 04:02:39 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180105180239.74F75F5267@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, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 06 Jan, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 677605 Prefixes after maximum aggregation (per Origin AS): 263671 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 327932 Total ASes present in the Internet Routing Table: 59484 Prefixes per ASN: 11.39 Origin-only ASes present in the Internet Routing Table: 51353 Origin ASes announcing only one prefix: 22635 Transit ASes present in the Internet Routing Table: 8131 Transit-only ASes present in the Internet Routing Table: 244 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 30 Max AS path prepend of ASN ( 29046) 25 Prefixes from unregistered ASNs in the Routing Table: 88 Number of instances of unregistered ASNs: 89 Number of 32-bit ASNs allocated by the RIRs: 21091 Number of 32-bit ASNs visible in the Routing Table: 16887 Prefixes from 32-bit ASNs in the Routing Table: 69434 Number of bogon 32-bit ASNs visible in the Routing Table: 14 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 334 Number of addresses announced to Internet: 2860024994 Equivalent to 170 /8s, 120 /16s and 132 /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: 98.8 Total number of prefixes smaller than registry allocations: 224483 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 186127 Total APNIC prefixes after maximum aggregation: 53465 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 185206 Unique aggregates announced from the APNIC address blocks: 77299 APNIC Region origin ASes present in the Internet Routing Table: 8570 APNIC Prefixes per ASN: 21.61 APNIC Region origin ASes announcing only one prefix: 2430 APNIC Region transit ASes present in the Internet Routing Table: 1243 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3452 Number of APNIC addresses announced to Internet: 770308898 Equivalent to 45 /8s, 233 /16s and 251 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 202522 Total ARIN prefixes after maximum aggregation: 97512 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 203785 Unique aggregates announced from the ARIN address blocks: 95631 ARIN Region origin ASes present in the Internet Routing Table: 18045 ARIN Prefixes per ASN: 11.29 ARIN Region origin ASes announcing only one prefix: 6679 ARIN Region transit ASes present in the Internet Routing Table: 1784 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2289 Number of ARIN addresses announced to Internet: 1107523104 Equivalent to 66 /8s, 3 /16s and 118 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 183210 Total RIPE prefixes after maximum aggregation: 89257 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 179162 Unique aggregates announced from the RIPE address blocks: 107873 RIPE Region origin ASes present in the Internet Routing Table: 24791 RIPE Prefixes per ASN: 7.23 RIPE Region origin ASes announcing only one prefix: 11325 RIPE Region transit ASes present in the Internet Routing Table: 3514 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6535 Number of RIPE addresses announced to Internet: 714008704 Equivalent to 42 /8s, 142 /16s and 232 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 87728 Total LACNIC prefixes after maximum aggregation: 19441 LACNIC Deaggregation factor: 4.51 Prefixes being announced from the LACNIC address blocks: 89021 Unique aggregates announced from the LACNIC address blocks: 39646 LACNIC Region origin ASes present in the Internet Routing Table: 6689 LACNIC Prefixes per ASN: 13.31 LACNIC Region origin ASes announcing only one prefix: 1835 LACNIC Region transit ASes present in the Internet Routing Table: 1246 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4222 Number of LACNIC addresses announced to Internet: 172507104 Equivalent to 10 /8s, 72 /16s and 63 /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: 17928 Total AfriNIC prefixes after maximum aggregation: 3932 AfriNIC Deaggregation factor: 4.56 Prefixes being announced from the AfriNIC address blocks: 20097 Unique aggregates announced from the AfriNIC address blocks: 7210 AfriNIC Region origin ASes present in the Internet Routing Table: 1114 AfriNIC Prefixes per ASN: 18.04 AfriNIC Region origin ASes announcing only one prefix: 365 AfriNIC Region transit ASes present in the Internet Routing Table: 225 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 389 Number of AfriNIC addresses announced to Internet: 95278336 Equivalent to 5 /8s, 173 /16s and 213 /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 5411 4192 74 ERX-CERNET-BKB China Education and Rese 7545 3271 403 389 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2884 11132 772 KIXS-AS-KR Korea Telecom, KR 17974 2783 918 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2769 1499 540 BSNL-NIB National Internet Backbone, IN 7552 2509 1159 49 VIETEL-AS-AP Viettel Group, VN 45899 2253 1524 119 VNPT-AS-VN VNPT Corp, VN 9394 2168 4923 26 CTTNET China TieTong Telecommunications 9808 2097 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2082 417 209 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 3333 1323 86 SHAW - Shaw Communications Inc., CA 22773 3280 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2169 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2066 2328 465 CHARTER-NET-HKY-NC - Charter Communicat 16509 1988 4145 586 AMAZON-02 - Amazon.com, Inc., US 6389 1959 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1916 5061 623 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1871 332 246 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1723 233 571 CABLEONE - CABLE ONE, INC., US 7018 1675 20197 1247 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 20940 2856 846 2059 AKAMAI-ASN1, US 8551 2282 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2091 1830 688 ROSTELECOM-AS, RU 12479 1991 1068 127 UNI2-AS, ES 9121 1981 1691 17 TTNET, TR 34984 1979 330 477 TELLCOM-AS, TR 13188 1605 100 46 TRIOLAN, UA 6849 1228 355 21 UKRTELNET, UA 8402 1225 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 3752 3433 602 Uninet S.A. de C.V., MX 10620 3577 539 262 Telmex Colombia S.A., CO 11830 2632 370 66 Instituto Costarricense de Electricidad 6503 1617 437 53 Axtel, S.A.B. de C.V., MX 7303 1498 1023 192 Telecom Argentina S.A., AR 6147 1195 377 27 Telefonica del Peru S.A.A., PE 28573 1022 2246 194 CLARO S.A., BR 3816 1015 509 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 919 126 85 Alestra, S. de R.L. de C.V., MX 18881 904 1065 27 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1190 398 50 LINKdotNET-AS, EG 37611 781 91 8 Afrihost, ZA 36903 741 372 137 MT-MPLS, MA 36992 688 1383 31 ETISALAT-MISR, EG 8452 520 1730 18 TE-AS TE-AS, EG 24835 487 786 17 RAYA-AS, EG 29571 444 36 13 ORANGE-COTE-IVOIRE, CI 37492 440 367 77 ORANGE-, TN 37342 356 32 1 MOVITEL, MZ 15399 349 35 7 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 4538 5411 4192 74 ERX-CERNET-BKB China Education and Rese 8151 3752 3433 602 Uninet S.A. de C.V., MX 10620 3577 539 262 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3333 1323 86 SHAW - Shaw Communications Inc., CA 22773 3280 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3271 403 389 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2884 11132 772 KIXS-AS-KR Korea Telecom, KR 20940 2856 846 2059 AKAMAI-ASN1, US 17974 2783 918 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 39891 3520 3499 ALJAWWALSTC-AS, SA 10620 3577 3315 Telmex Colombia S.A., CO 6327 3333 3247 SHAW - Shaw Communications Inc., CA 8151 3752 3150 Uninet S.A. de C.V., MX 22773 3280 3134 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3271 2882 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2783 2706 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 11830 2632 2566 Instituto Costarricense de Electricidad y Telec 7552 2509 2460 VIETEL-AS-AP Viettel Group, VN 8551 2282 2240 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64609 PRIVATE 94.245.126.0/24 6584 MICROSOFT-GP-AS - Microsoft Co 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:12 /10:37 /11:99 /12:279 /13:558 /14:1088 /15:1896 /16:13416 /17:7769 /18:13670 /19:25260 /20:38892 /21:44620 /22:82804 /23:66621 /24:378323 /25:844 /26:608 /27:657 /28:36 /29:20 /30:17 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3125 3333 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2526 3280 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2063 2169 MEGAPATH5-US - MegaPath Corporation, US 11830 1978 2632 Instituto Costarricense de Electricidad y Telec 8551 1746 2282 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1635 1871 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1577 3577 Telmex Colombia S.A., CO 11492 1520 1723 CABLEONE - CABLE ONE, INC., US 9121 1457 1981 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1573 2:819 4:18 5:2636 6:39 8:1094 9:1 12:1854 13:198 14:1749 15:29 16:3 17:185 18:76 20:53 21:1 23:2502 24:1927 25:2 27:2340 31:1951 32:87 35:22 36:458 37:2464 38:1430 39:224 40:101 41:3027 42:549 43:1929 44:93 45:3491 46:2986 47:193 49:1371 50:1051 51:47 52:916 54:355 55:5 56:7 57:42 58:1569 59:1010 60:372 61:1997 62:1778 63:1825 64:4638 65:2239 66:4486 67:2311 68:1194 69:3165 70:1132 71:588 72:2115 74:2693 75:392 76:423 77:1553 78:1617 79:1960 80:1480 81:1406 82:1070 83:792 84:1005 85:1989 86:565 87:1210 88:917 89:2318 90:177 91:6255 92:1085 93:2345 94:2370 95:2738 96:667 97:356 98:909 99:107 100:152 101:1535 102:14 103:16628 104:3213 105:212 106:521 107:1800 108:816 109:2727 110:1549 111:1722 112:1283 113:1380 114:1115 115:1603 116:1621 117:1669 118:2241 119:1660 120:913 121:1050 122:2419 123:1760 124:1479 125:1840 128:963 129:580 130:440 131:1627 132:588 133:194 134:1000 135:220 136:447 137:465 138:1983 139:549 140:388 141:677 142:768 143:942 144:799 145:195 146:1142 147:687 148:1471 149:711 150:712 151:982 152:749 153:309 154:959 155:744 156:742 157:743 158:599 159:1621 160:849 161:733 162:2531 163:522 164:981 165:1490 166:398 167:1377 168:3111 169:789 170:3641 171:403 172:1027 173:1909 174:862 175:772 176:1858 177:3939 178:2442 179:1155 180:2226 181:2133 182:2418 183:1059 184:895 185:11955 186:3475 187:2369 188:2624 189:1970 190:8220 191:1364 192:9756 193:5873 194:4779 195:3985 196:2321 197:1440 198:5525 199:5882 200:7280 201:4918 202:10378 203:9917 204:4560 205:2871 206:3043 207:3112 208:3994 209:3938 210:4002 211:2151 212:2938 213:2618 214:858 215:63 216:5748 217:2111 218:900 219:626 220:1728 221:956 222:696 223:1225 End of report From bryan at shout.net Fri Jan 5 18:50:42 2018 From: bryan at shout.net (Bryan Holloway) Date: Fri, 5 Jan 2018 12:50:42 -0600 Subject: Any experience with FS hardware out there? Message-ID: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm curious if anyone in the community has any thoughts or real-life world experience with them. E.g.: https://www.fs.com/products/69340.html For the price point, it's almost in the "too good to be true" category. Naturally it claims to support an impressive range of features including BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. There was an earlier discussion about packet buffer issues, but, assuming for a second that it's not an issue, can anyone say they've used these and/or the L2/L3 features that they purportedly support? Thanks! - bryan From michael at wi-fiber.io Fri Jan 5 19:14:03 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 5 Jan 2018 12:14:03 -0700 Subject: Any experience with FS hardware out there? In-Reply-To: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> Message-ID: No telecom power unfortunately On 5 January 2018 at 11:50, Bryan Holloway wrote: > Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm > curious if anyone in the community has any thoughts or real-life world > experience with them. > > E.g.: https://www.fs.com/products/69340.html > > For the price point, it's almost in the "too good to be true" category. > > Naturally it claims to support an impressive range of features including > BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. > > There was an earlier discussion about packet buffer issues, but, assuming > for a second that it's not an issue, can anyone say they've used these > and/or the L2/L3 features that they purportedly support? > > Thanks! > - bryan > > From bryan at shout.net Fri Jan 5 19:16:34 2018 From: bryan at shout.net (Bryan Holloway) Date: Fri, 5 Jan 2018 13:16:34 -0600 Subject: Any experience with FS hardware out there? In-Reply-To: References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> Message-ID: Yeah, I noticed that, although they have a "high-voltage DC" option, which I found more curious than anything. On 1/5/18 1:14 PM, Michael Crapse wrote: > No telecom power unfortunately > > > On 5 January 2018 at 11:50, Bryan Holloway > wrote: > > Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm > curious if anyone in the community has any thoughts or real-life > world experience with them. > > E.g.: https://www.fs.com/products/69340.html > > > For the price point, it's almost in the "too good to be true" category. > > Naturally it claims to support an impressive range of features > including BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. > > There was an earlier discussion about packet buffer issues, but, > assuming for a second that it's not an issue, can anyone say they've > used these and/or the L2/L3 features that they purportedly support? > > Thanks! >                         - bryan > > From bzs at theworld.com Fri Jan 5 19:20:09 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 5 Jan 2018 14:20:09 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: <7300b875-2eea-4f34-89f4-6ca984ff3b06@satchell.net> References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> <7300b875-2eea-4f34-89f4-6ca984ff3b06@satchell.net> Message-ID: <23119.53225.860703.268587@gargle.gargle.HOWL> It's classic Max Weber's formal description of bureaucracy, in the good sense, ca 1900-1920 as an administrative/management structure. You try to set up the local office (call it first-tier) so they can answer about 90% of all questions. The other 10% are kicked up to the regional (call it 2nd tier) who one hopes can answer 90% of those questions, and so on. Or as I used to say as an academic: If you (students) have any questions about majoring etc please don't hesitate to ask me. If I don't know the answer we can go to the dept head and ask again. If the dept head doesn't know the answer we can all go to the dean who, if s/he does not know the answer, will no doubt make one up on the spot! On January 4, 2018 at 15:34 list at satchell.net (Stephen Satchell) wrote: > On 01/04/2018 01:02 PM, Dan Hollis wrote: > > when the first tier incompetence stops, the direct contacts will stop too. > > But, but, but...when the first tier support person gets the training to > not be incompetent, he is promoted to the second tier and the vacuum is > filled with another incompetent first-tier person. > > So, by definition, the first tier of support will only be able to answer > questions "from the book". Anything more complex than what's in "the > book" is bumped to the second tier...where the problem is above the > second-tier pay grade and it gets bumped further up the chain. > > It's a variation of the Peter Principal: ex-incompetents will rise up > the promotion ladder. > -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From dovid at telecurve.com Fri Jan 5 19:38:03 2018 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 5 Jan 2018 14:38:03 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> Message-ID: I may have to take back what I said. Yes the attacks stopped from what IP but they magically started again from another IP of theirs in a different. Range. seems like the attacker picked up where they left off just from a new UP. Almost as if they told the attacker they got complaints and they would need to just simply switch their IP to keep them as a customer...... On Thu, Jan 4, 2018 at 9:42 AM, Dovid Bender wrote: > In their defense I was pleasantly surprised that I got a response back > from them telling me the account was banned. Though it makes me wonder if > this is just them trying to save face. I have spoken with the guys that run > DO's network and they have an extensive amount of automation to weed out > spammers, attackers etc. It makes you wonder why for years that are known > in the spammer community as a safe heaven. > > On Thu, Jan 4, 2018 at 9:33 AM, William Herrin wrote: > >> On Wed, Jan 3, 2018 at 10:57 PM, Dan Hollis >> wrote: >> >>> On Wed, 3 Jan 2018, Dovid Bender wrote: >>> >>>> On Wed, Jan 3, 2018 at 2:47 AM, Mickael Marchand < >>>> mmarchand at corp.free.fr> >>>> wrote: >>>> >>>>> Hi Dovid, >>>>> >>>>> Just fill in our abuse form at https://abuse. >>>>> online.net >>>>> >>>> >>> I have no idea why anyone thinks it is acceptable to require victims to >>> fill out online web forms. >> >> >> Because the number of people who successfully provide actionable >> information without being prompted is vanishingly small and the number of >> people who fire off automated complaints to the best guess abuse address >> (also without actionable information) is disappointingly large? >> >> Why anyone thinks it's acceptable for the form submission to vanish in to >> the faceless support queue is more of a quandary. The form submission >> should provide a case number, the individual to whom it is assigned, direct >> contact information for that individual and a promise that your report will >> receive a response. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> > > From list at satchell.net Fri Jan 5 20:27:30 2018 From: list at satchell.net (Stephen Satchell) Date: Fri, 5 Jan 2018 12:27:30 -0800 Subject: Attacks from poneytelecom.eu In-Reply-To: References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> Message-ID: On 01/05/2018 11:38 AM, Dovid Bender wrote: > I may have to take back what I said. Yes the attacks stopped from what IP > but they magically started again from another IP of theirs in a different. > Range. seems like the attacker picked up where they left off just from a > new UP. Almost as if they told the attacker they got complaints and they > would need to just simply switch their IP to keep them as a customer...... Back when I joined a Web hosting company after the freelance-writing market collapsed, I was astonished to learn that the usual response to an abuse complaint was to move the customer to a new IP address. And the owner of the company wondered why his entire netblock was in SORBS. So, I took over the abuse desk. Closed four accounts out of several thousand. And, lo and behold, I got the company out of SORBS. ("You've got to be kidding me! And in only six weeks!" -- NANAE contributor.) Not only did my $DAYJOB stop being a spam source, I was able to do some things about the inflow to my customers as well. Then there was the subpoena from the IRS, the cease-and-desist order from a major watch company, and other fun stuff. Oh, and the court order brought in by the Nevada Gaming Commission...and the hapless "expert"* they brought in to do the forensic capture of the disk image. An expert who knew NOTHING about Unix, let alone Linux. Fun times, indeed. I revel in my dull, dull professional life now. Lift a glass, make a toast, sing a ditty. * X is a mathematical quantity denoting the unknown. "Spurt" is a drip of water under pressure. So an X-Spurt is an unknown drip under pressure. From eric.kuhnke at gmail.com Fri Jan 5 20:37:14 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 5 Jan 2018 12:37:14 -0800 Subject: Any experience with FS hardware out there? In-Reply-To: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> Message-ID: To my eyes that looks like an Accton/Edgecore whitebox switch. The prices for the Edgecore equivalent product are about the same. On Fri, Jan 5, 2018 at 10:50 AM, Bryan Holloway wrote: > Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm > curious if anyone in the community has any thoughts or real-life world > experience with them. > > E.g.: https://www.fs.com/products/69340.html > > For the price point, it's almost in the "too good to be true" category. > > Naturally it claims to support an impressive range of features including > BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. > > There was an earlier discussion about packet buffer issues, but, assuming > for a second that it's not an issue, can anyone say they've used these > and/or the L2/L3 features that they purportedly support? > > Thanks! > - bryan > > From eric.kuhnke at gmail.com Fri Jan 5 20:38:10 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 5 Jan 2018 12:38:10 -0800 Subject: Any experience with FS hardware out there? In-Reply-To: References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> Message-ID: With DC-DC power supplies there's a number of things that actually have input ranges of 36-72VDC. Way higher DC voltage than you'll ever see a 48VDC telecom battery system at "float" voltage, anyhow. On Fri, Jan 5, 2018 at 11:16 AM, Bryan Holloway wrote: > Yeah, I noticed that, although they have a "high-voltage DC" option, which > I found more curious than anything. > > > On 1/5/18 1:14 PM, Michael Crapse wrote: > >> No telecom power unfortunately >> >> >> On 5 January 2018 at 11:50, Bryan Holloway > bryan at shout.net>> wrote: >> >> Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm >> curious if anyone in the community has any thoughts or real-life >> world experience with them. >> >> E.g.: https://www.fs.com/products/69340.html >> >> >> For the price point, it's almost in the "too good to be true" >> category. >> >> Naturally it claims to support an impressive range of features >> including BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. >> >> There was an earlier discussion about packet buffer issues, but, >> assuming for a second that it's not an issue, can anyone say they've >> used these and/or the L2/L3 features that they purportedly support? >> >> Thanks! >> - bryan >> >> >> From joelja at bogus.com Fri Jan 5 20:46:21 2018 From: joelja at bogus.com (joel jaeggli) Date: Fri, 5 Jan 2018 12:46:21 -0800 Subject: Any experience with FS hardware out there? In-Reply-To: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> Message-ID: On 1/5/18 10:50 AM, Bryan Holloway wrote: > Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm > curious if anyone in the community has any thoughts or real-life world > experience with them. > > E.g.: https://www.fs.com/products/69340.html > > For the price point, it's almost in the "too good to be true" category. The COGS on a single ASIC tomahawk switch was is in $5000-7000 range. so it's consistent with a low value add reseller of merchant silicon. that silicon is getting older (tomahawk 3 was announced in anticipation of 2018) so we can presume they are getting cheaper. I generally have a favorable experience of FS but then I buy optics and cables, not switches so your mileage may vary. > Naturally it claims to support an impressive range of features > including BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. The software stack is Broadcom ICOS. if you're not familiar with that I start looking at that. if it meets you needs that's cool. if not you might be looking at cumulus or onos. That said Broadcom does enough to get their customers (whitebox odms) out the door, not necessarily the customers of those odms so your recourse to a developer is kind of limited which you get a from a vendor more involved in the software stack. A lot of those choices here depend on how responsible you want to be for what's running inside the box. > There was an earlier discussion about packet buffer issues, but, > assuming for a second that it's not an issue, It can be avoided, but for people used to running all 10Gb/s cut-through trident 2s kind of hot, some of consequences are kind of impressive. 4 much smaller buffers and the virtual assurance that you'll be doing rate conversion eats into the forwarding budget. > can anyone say they've used these and/or the L2/L3 features that they > purportedly support? > > Thanks! >             - bryan > From hugo at slabnet.com Fri Jan 5 19:19:26 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 5 Jan 2018 11:19:26 -0800 Subject: Any experience with FS hardware out there? In-Reply-To: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> Message-ID: <20180105191926.GB25899@bamboo.slabnet.com> On Fri 2018-Jan-05 12:50:42 -0600, Bryan Holloway wrote: >Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm >curious if anyone in the community has any thoughts or real-life >world experience with them. > >E.g.: https://www.fs.com/products/69340.html > >For the price point, it's almost in the "too good to be true" category. The price is on par with the hardware cost of other whitebox Tomahawks, e.g. Edge-Core 32x100G models like the AS7712 or AS7716 that also runs the BCM56960, so the primary distinction seems to be that you get a NOS included in that price. I have zero experience with Broadcom's ICOS as opposed to the other options on the market, so it seems to be a question of whether you're happy with that or would be e.g. paying Cumulus or $vendor a few K USD for a license for their NOS on it. >Naturally it claims to support an impressive range of features including >BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. > >There was an earlier discussion about packet buffer issues, but, >assuming for a second that it's not an issue, can anyone say they've >used these and/or the L2/L3 features that they purportedly support? > >Thanks! > - bryan > -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bryan at shout.net Fri Jan 5 21:46:52 2018 From: bryan at shout.net (Bryan Holloway) Date: Fri, 5 Jan 2018 15:46:52 -0600 Subject: Any experience with Broadcom ICOS out there? In-Reply-To: References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> Message-ID: <50329b04-5a96-4c3b-b63c-aba0c14e40ec@shout.net> Thank you everyone for the responses so far; I should probably re-phrase the question at this point ... Has anyone had production experience with Broadcom ICOS and the features it claims to support? Positive or negative? On 1/5/18 2:46 PM, joel jaeggli wrote: > > > On 1/5/18 10:50 AM, Bryan Holloway wrote: >> Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm >> curious if anyone in the community has any thoughts or real-life world >> experience with them. >> >> E.g.: https://www.fs.com/products/69340.html >> >> For the price point, it's almost in the "too good to be true" category. > The COGS on a single ASIC tomahawk switch was is in $5000-7000 range. so > it's consistent with a low value add reseller of merchant silicon. that > silicon is getting older (tomahawk 3 was announced in anticipation of > 2018) so we can presume they are getting cheaper. I generally have a > favorable experience of FS but then I buy optics and cables, not > switches so your mileage may vary. > >> Naturally it claims to support an impressive range of features >> including BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. > The software stack is Broadcom ICOS. if you're not familiar with that I > start looking at that. if it meets you needs that's cool. if not you > might be looking at cumulus or onos. That said Broadcom does enough to > get their customers (whitebox odms) out the door, not necessarily the > customers of those odms so your recourse to a developer is kind of > limited which you get a from a vendor more involved in the software > stack. A lot of those choices here depend on how responsible you want to > be for what's running inside the box. >> There was an earlier discussion about packet buffer issues, but, >> assuming for a second that it's not an issue, > It can be avoided, but for people used to running all 10Gb/s cut-through > trident 2s kind of hot, some of consequences are kind of impressive. 4 > much smaller buffers and the virtual assurance that you'll be doing rate > conversion eats into the forwarding budget. >> can anyone say they've used these and/or the L2/L3 features that they >> purportedly support? >> >> Thanks! >>             - bryan >> > From eric.kuhnke at gmail.com Fri Jan 5 21:54:59 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 5 Jan 2018 13:54:59 -0800 Subject: Any experience with Broadcom ICOS out there? In-Reply-To: <50329b04-5a96-4c3b-b63c-aba0c14e40ec@shout.net> References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> <50329b04-5a96-4c3b-b63c-aba0c14e40ec@shout.net> Message-ID: You may have better results with the same question on OCP (open compute platform) related forums and mailing lists. The Quanta version of that switch sold by FS is pretty much the same thing: https://linustechtips.com/main/topic/801037-qct-reveals-their-quantamesh-network-switches/ Quanta has been very active in the OCP community for whitebox switches. I have heard that they are the switch manufacturer for a great deal of Facebook's hyperscale stuff. On Fri, Jan 5, 2018 at 1:46 PM, Bryan Holloway wrote: > Thank you everyone for the responses so far; I should probably re-phrase > the question at this point ... > > Has anyone had production experience with Broadcom ICOS and the features > it claims to support? Positive or negative? > > > On 1/5/18 2:46 PM, joel jaeggli wrote: > >> >> >> On 1/5/18 10:50 AM, Bryan Holloway wrote: >> >>> Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm >>> curious if anyone in the community has any thoughts or real-life world >>> experience with them. >>> >>> E.g.: https://www.fs.com/products/69340.html >>> >>> For the price point, it's almost in the "too good to be true" category. >>> >> The COGS on a single ASIC tomahawk switch was is in $5000-7000 range. so >> it's consistent with a low value add reseller of merchant silicon. that >> silicon is getting older (tomahawk 3 was announced in anticipation of 2018) >> so we can presume they are getting cheaper. I generally have a favorable >> experience of FS but then I buy optics and cables, not switches so your >> mileage may vary. >> >> Naturally it claims to support an impressive range of features including >>> BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. >>> >> The software stack is Broadcom ICOS. if you're not familiar with that I >> start looking at that. if it meets you needs that's cool. if not you might >> be looking at cumulus or onos. That said Broadcom does enough to get their >> customers (whitebox odms) out the door, not necessarily the customers of >> those odms so your recourse to a developer is kind of limited which you get >> a from a vendor more involved in the software stack. A lot of those choices >> here depend on how responsible you want to be for what's running inside the >> box. >> >>> There was an earlier discussion about packet buffer issues, but, >>> assuming for a second that it's not an issue, >>> >> It can be avoided, but for people used to running all 10Gb/s cut-through >> trident 2s kind of hot, some of consequences are kind of impressive. 4 much >> smaller buffers and the virtual assurance that you'll be doing rate >> conversion eats into the forwarding budget. >> >>> can anyone say they've used these and/or the L2/L3 features that they >>> purportedly support? >>> >>> Thanks! >>> - bryan >>> >>> >> From bryan at shout.net Fri Jan 5 22:25:25 2018 From: bryan at shout.net (Bryan Holloway) Date: Fri, 5 Jan 2018 16:25:25 -0600 Subject: Any experience with Broadcom ICOS out there? In-Reply-To: References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> <50329b04-5a96-4c3b-b63c-aba0c14e40ec@shout.net> Message-ID: > On Jan 5, 2018, at 15:54, Eric Kuhnke wrote: > > You may have better results with the same question on OCP (open compute platform) related forums and mailing lists. A valid suggestion, but I am looking for opinions from network operators who have actually used this gear in a production environment. If there are none, well, that tells me something. From chuckchurch at gmail.com Sat Jan 6 05:15:46 2018 From: chuckchurch at gmail.com (Chuck Church) Date: Sat, 6 Jan 2018 00:15:46 -0500 Subject: Any experience with Broadcom ICOS out there? In-Reply-To: References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> <50329b04-5a96-4c3b-b63c-aba0c14e40ec@shout.net> Message-ID: <00fa01d386ad$69bd1560$3d374020$@gmail.com> I smell some BS here, at least in their 'Verified Purchase' reviews: "It is installed as a network hub in my basement and it is working fine. Great quality product. I've had a lot of business with FS for years. This is a very reliable company and they stand behind their company's products with a first class warranty! I highly recommend." "It just takes several days to receive my 100G switch with Broadcom ICOS which is packaged safely and intactly. I followed the instruction and seems simple for a non-tech user. Three steps would be done: plug it in, cable it up, turn it on. Just the way a good product should be. I would like to recommend both the product and the seller." Non tech user, network hub in my basement. $10K L3 switch. Jesus. The Tactical Flashlight seems more believable right now. Chuck. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke Sent: Friday, January 05, 2018 4:55 PM To: Bryan Holloway ; nanog at nanog.org list Subject: Re: Any experience with Broadcom ICOS out there? You may have better results with the same question on OCP (open compute platform) related forums and mailing lists. The Quanta version of that switch sold by FS is pretty much the same thing: https://linustechtips.com/main/topic/801037-qct-reveals-their-quantamesh-network-switches/ Quanta has been very active in the OCP community for whitebox switches. I have heard that they are the switch manufacturer for a great deal of Facebook's hyperscale stuff. On Fri, Jan 5, 2018 at 1:46 PM, Bryan Holloway wrote: > Thank you everyone for the responses so far; I should probably > re-phrase the question at this point ... > > Has anyone had production experience with Broadcom ICOS and the > features it claims to support? Positive or negative? > > > On 1/5/18 2:46 PM, joel jaeggli wrote: > >> >> >> On 1/5/18 10:50 AM, Bryan Holloway wrote: >> >>> Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm >>> curious if anyone in the community has any thoughts or real-life >>> world experience with them. >>> >>> E.g.: https://www.fs.com/products/69340.html >>> >>> For the price point, it's almost in the "too good to be true" category. >>> >> The COGS on a single ASIC tomahawk switch was is in $5000-7000 range. >> so it's consistent with a low value add reseller of merchant silicon. >> that silicon is getting older (tomahawk 3 was announced in >> anticipation of 2018) so we can presume they are getting cheaper. I >> generally have a favorable experience of FS but then I buy optics and >> cables, not switches so your mileage may vary. >> >> Naturally it claims to support an impressive range of features >> including >>> BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. >>> >> The software stack is Broadcom ICOS. if you're not familiar with that >> I start looking at that. if it meets you needs that's cool. if not >> you might be looking at cumulus or onos. That said Broadcom does >> enough to get their customers (whitebox odms) out the door, not >> necessarily the customers of those odms so your recourse to a >> developer is kind of limited which you get a from a vendor more >> involved in the software stack. A lot of those choices here depend on >> how responsible you want to be for what's running inside the box. >> >>> There was an earlier discussion about packet buffer issues, but, >>> assuming for a second that it's not an issue, >>> >> It can be avoided, but for people used to running all 10Gb/s >> cut-through trident 2s kind of hot, some of consequences are kind of >> impressive. 4 much smaller buffers and the virtual assurance that >> you'll be doing rate conversion eats into the forwarding budget. >> >>> can anyone say they've used these and/or the L2/L3 features that >>> they purportedly support? >>> >>> Thanks! >>> - bryan >>> >>> >> From gem at rellim.com Sat Jan 6 07:17:26 2018 From: gem at rellim.com (Gary E. Miller) Date: Fri, 5 Jan 2018 23:17:26 -0800 Subject: =?UTF-8?B?4pyYTmV0ZmxpeA==?= Message-ID: <20180105231726.34e646f6@spidey.rellim.com> Yo All! Sorry to bother, but... Netflis is blocking my IP range. 1st line support useless. Months and can not reah anyone with a clue. Anyone got a Netflix contact? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From EPers at ansencorp.com Sat Jan 6 08:37:07 2018 From: EPers at ansencorp.com (Edwin Pers) Date: Sat, 6 Jan 2018 08:37:07 +0000 Subject: Any experience with Broadcom ICOS out there? In-Reply-To: <50329b04-5a96-4c3b-b63c-aba0c14e40ec@shout.net> References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> <50329b04-5a96-4c3b-b63c-aba0c14e40ec@shout.net> Message-ID: <2c0f6498db3e4337849ff4ce9e1bc5ad@ansencorp.com> I've got a few older quanta switches still around, they're running a fairly old version of Broadcom's Fastpath software on top of vxworks 5.x. Fastpath runs ospf and ospfv3 just fine, exports sflow, makes the hardware do everything you'd expect a l3 switch to do. The CLI is kinda quirky, but it works. I'm not sure how much they've changed since then, but from what I understand the software is mainly just a reference spec to go along with the reference hardware designs you can get from Broadcom. Then the company designing/manufacturing the actual switch could/would build something on top that, tailored to any customizations beyond the ref design they added. Haven't had any problems with them, although the documentation Quanta provided was almost useless - par for the course with them from what I've heard.. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bryan Holloway Sent: Friday, January 5, 2018 4:47 PM To: joel jaeggli ; NANOG list Subject: Re: Any experience with Broadcom ICOS out there? Thank you everyone for the responses so far; I should probably re-phrase the question at this point ... Has anyone had production experience with Broadcom ICOS and the features it claims to support? Positive or negative? From nanog at radu-adrian.feurdean.net Sat Jan 6 11:56:27 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sat, 06 Jan 2018 12:56:27 +0100 Subject: Attacks from poneytelecom.eu In-Reply-To: <1AE73692-8E1F-4DC9-9144-4607BF26F133@tburke.us> References: <1AE73692-8E1F-4DC9-9144-4607BF26F133@tburke.us> Message-ID: <1515239787.3520364.1226191328.20A8D028@webmail.messagingengine.com> On Thu, Jan 4, 2018, at 06:46, Tim Burke wrote: > AS12876 is online.net... home of the €2.99 physical server, perfect for > all of your favorite illegitimate activity. I’m curious how much traffic > originates from that ASN that is actually legitimate... probably close > to none. For you, in US, probably not so much, but you should really check. For us, here in France, Online is one of the 2 top hosting providers (they even have several neutral datacenters where they lease racks/cages/datarooms) with a quite enough of legitimate traffic. I say enough, since 10's of MBps of traffic to classic (locally) well-known sites is easily hidden by spikes due to file transfer (they are also popular here for hosting private off-site backups - they actually even have an archiving service) or bittorrent. I also saw a mention of Iliad, their parent company, stock-listed (ILD on EuroNext Paris), as "buletproof hosting". You should note that they also own one of the top 4 ISPs here in France and one of the 4 frequence-owning mobile operators. But those run each on separate networks. One should probably do some minimal research on non-US companies before accusing. PS: No, I don't work for them. Just happen to be personally a customer of 3 of the Iliad-owned companies (Online.net being one of them). From nanog at radu-adrian.feurdean.net Sat Jan 6 12:32:55 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sat, 06 Jan 2018 13:32:55 +0100 Subject: Attacks from poneytelecom.eu In-Reply-To: <7300b875-2eea-4f34-89f4-6ca984ff3b06@satchell.net> References: <1D88D1AF-39A5-406B-85F3-D4179D66C0FB@corp.free.fr> <195982.1515082339@turing-police.cc.vt.edu> <7300b875-2eea-4f34-89f4-6ca984ff3b06@satchell.net> Message-ID: <1515241975.3530610.1226209096.0166D266@webmail.messagingengine.com> On Fri, Jan 5, 2018, at 00:34, Stephen Satchell wrote: > On 01/04/2018 01:02 PM, Dan Hollis wrote: > > when the first tier incompetence stops, the direct contacts will stop too. > > But, but, but...when the first tier support person gets the training to > not be incompetent, he is promoted to the second tier and the vacuum is > filled with another incompetent first-tier person. > > So, by definition, the first tier of support will only be able to answer > questions "from the book". Anything more complex than what's in "the > book" is bumped to the second tier...where the problem is above the > second-tier pay grade and it gets bumped further up the chain. Yes and no. You need to have a good "script" for the first-level support, and then you need to have people that understand what they are trying to do: take the information from the requester, do minimal (ideally script-defined) checks, run through it the script, then either fix (and confirm that it's fixed) or escalate. For smaller business structures, you may seriously loosen the script and go as far as require that people answering the phone or treating the support queue have an understanding of everything that the company does and how it does it. This does not scale. You cannot expect this for companies with more than (10s of) thousands of customers. You cannot expect to only have technically competent people to handle 100s or 1000s of tickets per day. Then you compare this with contacting directly someone that only receives a few requests a week because he/she is usually doing something else. That's obviously more effective as long as: - the person in question is still in a position to help or at least to escalate/forward properly - the person in question is still willing to help - the person in question is not flooded with requests impacting his/her normal duties, in which case the willingness to help may decrease to zero (or even make sure that a direct contact is counter-productive). Particularly for abuse management, thinks are a little more complex. Arbitration needs to be done between what you (the requestor) think is abuse, what the provider thinks about it, what the customer thinks about it, what the laws says and what does the contract/T&C/AUP says about it (and about how to deal with it). This may take time, involve non-technical persons and may not give the expected outcome even when dealt with by a good-faith service provider. From jlightfoot at gmail.com Sat Jan 6 14:38:49 2018 From: jlightfoot at gmail.com (John Lightfoot) Date: Sat, 06 Jan 2018 09:38:49 -0500 Subject: =?UTF-8?B?4pyYTmV0ZmxpeA==?= In-Reply-To: <20180105231726.34e646f6@spidey.rellim.com> References: <20180105231726.34e646f6@spidey.rellim.com> Message-ID: <5BED4324-63DB-4028-A540-12694195C184@gmail.com> If your IP range includes an ipv6 tunnel, Netflix blocks it thinking it's a vpn. You need to block the ipv6 routes to Netflix and force it to fall back to ipv4. On 1/6/18, 2:19 AM, "NANOG on behalf of Gary E. Miller" wrote: Yo All! Sorry to bother, but... Netflis is blocking my IP range. 1st line support useless. Months and can not reah anyone with a clue. Anyone got a Netflix contact? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin From nanog at ics-il.net Sat Jan 6 14:50:44 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 6 Jan 2018 08:50:44 -0600 (CST) Subject: Level 3 IRR In-Reply-To: <1003433603.17733.1515250152770.JavaMail.mhammett@ThunderFuck> Message-ID: <1325480756.17740.1515250243250.JavaMail.mhammett@ThunderFuck> I've tried an assortment of e-mail addresses for Level 3 and LightCore (the ASN that placed the entry, conveniently now all under the same roof) to get a record removed from their IRR. I appreciate any good contacts offline. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From michael at wi-fiber.io Sat Jan 6 15:09:22 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Sat, 06 Jan 2018 15:09:22 +0000 Subject: =?UTF-8?B?UmU6IOKcmE5ldGZsaXg=?= In-Reply-To: <5BED4324-63DB-4028-A540-12694195C184@gmail.com> References: <20180105231726.34e646f6@spidey.rellim.com> <5BED4324-63DB-4028-A540-12694195C184@gmail.com> Message-ID: geolocation at netflix.com On Sat, Jan 6, 2018, 7:41 AM John Lightfoot wrote: > If your IP range includes an ipv6 tunnel, Netflix blocks it thinking it's > a vpn. You need to block the ipv6 routes to Netflix and force it to fall > back to ipv4. > > On 1/6/18, 2:19 AM, "NANOG on behalf of Gary E. Miller" < > nanog-bounces at nanog.org on behalf of gem at rellim.com> wrote: > > Yo All! > > Sorry to bother, but... > > Netflis is blocking my IP range. 1st line support useless. Months and > can not reah anyone with a clue. Anyone got a Netflix contact? > > RGDS > GARY > > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > > gem at rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? > "If you can’t measure it, you can’t improve it." - Lord Kelvin > > > > From lists at silverlakeinternet.com Sat Jan 6 16:01:00 2018 From: lists at silverlakeinternet.com (Brett A Mansfield) Date: Sat, 6 Jan 2018 09:01:00 -0700 Subject: =?utf-8?Q?Re:_=E2=9C=98Netflix?= In-Reply-To: References: <20180105231726.34e646f6@spidey.rellim.com> <5BED4324-63DB-4028-A540-12694195C184@gmail.com> Message-ID: <29B2EBD0-9FAA-4DDC-B69E-79BF95DE8AB8@silverlakeinternet.com> I got a delivery failure for that email address. Thank you, Brett A Mansfield > On Jan 6, 2018, at 8:09 AM, Michael Crapse wrote: > > geolocation at netflix.com > >> On Sat, Jan 6, 2018, 7:41 AM John Lightfoot wrote: >> >> If your IP range includes an ipv6 tunnel, Netflix blocks it thinking it's >> a vpn. You need to block the ipv6 routes to Netflix and force it to fall >> back to ipv4. >> >> On 1/6/18, 2:19 AM, "NANOG on behalf of Gary E. Miller" < >> nanog-bounces at nanog.org on behalf of gem at rellim.com> wrote: >> >> Yo All! >> >> Sorry to bother, but... >> >> Netflis is blocking my IP range. 1st line support useless. Months and >> can not reah anyone with a clue. Anyone got a Netflix contact? >> >> RGDS >> GARY >> >> --------------------------------------------------------------------------- >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >> >> gem at rellim.com Tel:+1 541 382 8588 >> >> Veritas liberabit vos. -- Quid est veritas? >> "If you can’t measure it, you can’t improve it." - Lord Kelvin >> >> >> >> From fhr at fhrnet.eu Sat Jan 6 20:43:36 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Sat, 6 Jan 2018 20:43:36 +0000 Subject: Any experience with Broadcom ICOS out there? In-Reply-To: <00fa01d386ad$69bd1560$3d374020$@gmail.com> References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> <50329b04-5a96-4c3b-b63c-aba0c14e40ec@shout.net> <00fa01d386ad$69bd1560$3d374020$@gmail.com> Message-ID: <01020160cd36e8ae-f2192104-02ba-4b51-9650-37918f66e42b-000000@eu-west-1.amazonses.com> I think FS reviews are simply fake. Check out reviews on this bag of connectors: https://www.fs.com/products/10964.html#all_reviews 3 different people from supposedly 3 countries added pictures of the bag. To me it looks like the bag is on the exact same table in all photos, under totally same lighting conditions, just shot from different angles. Also, there is a dent in the table, which is visible in 2 of the photos. I wonder, why would they do this? Doesn't instill a lot of confidence in me. Regards -- Filip Hruska Linux System Administrator Dne 1/6/18 v 06:15 Chuck Church napsal(a): > I smell some BS here, at least in their 'Verified Purchase' reviews: > > "It is installed as a network hub in my basement and it is working fine. Great quality product. I've had a lot of business with FS for years. This is a very reliable company and they stand behind their company's products with a first class warranty! I highly recommend." > > "It just takes several days to receive my 100G switch with Broadcom ICOS which is packaged safely and intactly. I followed the instruction and seems simple for a non-tech user. Three steps would be done: plug it in, cable it up, turn it on. Just the way a good product should be. I would like to recommend both the product and the seller." > > > Non tech user, network hub in my basement. $10K L3 switch. Jesus. The Tactical Flashlight seems more believable right now. > > Chuck. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke > Sent: Friday, January 05, 2018 4:55 PM > To: Bryan Holloway ; nanog at nanog.org list > Subject: Re: Any experience with Broadcom ICOS out there? > > You may have better results with the same question on OCP (open compute > platform) related forums and mailing lists. The Quanta version of that switch sold by FS is pretty much the same thing: > > https://linustechtips.com/main/topic/801037-qct-reveals-their-quantamesh-network-switches/ > > Quanta has been very active in the OCP community for whitebox switches. I have heard that they are the switch manufacturer for a great deal of Facebook's hyperscale stuff. > > > > On Fri, Jan 5, 2018 at 1:46 PM, Bryan Holloway wrote: > >> Thank you everyone for the responses so far; I should probably >> re-phrase the question at this point ... >> >> Has anyone had production experience with Broadcom ICOS and the >> features it claims to support? Positive or negative? >> >> >> On 1/5/18 2:46 PM, joel jaeggli wrote: >> >>> >>> On 1/5/18 10:50 AM, Bryan Holloway wrote: >>> >>>> Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm >>>> curious if anyone in the community has any thoughts or real-life >>>> world experience with them. >>>> >>>> E.g.: https://www.fs.com/products/69340.html >>>> >>>> For the price point, it's almost in the "too good to be true" category. >>>> >>> The COGS on a single ASIC tomahawk switch was is in $5000-7000 range. >>> so it's consistent with a low value add reseller of merchant silicon. >>> that silicon is getting older (tomahawk 3 was announced in >>> anticipation of 2018) so we can presume they are getting cheaper. I >>> generally have a favorable experience of FS but then I buy optics and >>> cables, not switches so your mileage may vary. >>> >>> Naturally it claims to support an impressive range of features >>> including >>>> BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. >>>> >>> The software stack is Broadcom ICOS. if you're not familiar with that >>> I start looking at that. if it meets you needs that's cool. if not >>> you might be looking at cumulus or onos. That said Broadcom does >>> enough to get their customers (whitebox odms) out the door, not >>> necessarily the customers of those odms so your recourse to a >>> developer is kind of limited which you get a from a vendor more >>> involved in the software stack. A lot of those choices here depend on >>> how responsible you want to be for what's running inside the box. >>> >>>> There was an earlier discussion about packet buffer issues, but, >>>> assuming for a second that it's not an issue, >>>> >>> It can be avoided, but for people used to running all 10Gb/s >>> cut-through trident 2s kind of hot, some of consequences are kind of >>> impressive. 4 much smaller buffers and the virtual assurance that >>> you'll be doing rate conversion eats into the forwarding budget. >>> >>>> can anyone say they've used these and/or the L2/L3 features that >>>> they purportedly support? >>>> >>>> Thanks! >>>> - bryan >>>> >>>> From baldur.norddahl at gmail.com Sat Jan 6 23:42:53 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 7 Jan 2018 00:42:53 +0100 Subject: Any experience with Broadcom ICOS out there? In-Reply-To: <01020160cd36e8ae-f2192104-02ba-4b51-9650-37918f66e42b-000000@eu-west-1.amazonses.com> References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> <50329b04-5a96-4c3b-b63c-aba0c14e40ec@shout.net> <00fa01d386ad$69bd1560$3d374020$@gmail.com> <01020160cd36e8ae-f2192104-02ba-4b51-9650-37918f66e42b-000000@eu-west-1.amazonses.com> Message-ID: Yes please please Fiberstore get rid of the fake reviews. You are better than this. Den 06/01/2018 kl. 21.43 skrev Filip Hruska: > I think FS reviews are simply fake. > > Check out reviews on this bag of connectors: > https://www.fs.com/products/10964.html#all_reviews > > 3 different people from supposedly 3 countries added pictures of the > bag. To me it looks like the bag is on the exact same table in all > photos, > under totally same lighting conditions, just shot from different > angles. Also, there is a dent in the table, which is visible in 2 of > the photos. > > I wonder, why would they do this? Doesn't instill a lot of confidence > in me. > > > Regards > > -- > Filip Hruska > Linux System Administrator > > Dne 1/6/18 v 06:15 Chuck Church napsal(a): >> I smell some BS here, at least in their 'Verified Purchase' reviews: >> >> "It is installed as a network hub in my basement and it is working >> fine. Great quality product. I've had a lot of business with FS for >> years. This is a very reliable company and they stand behind their >> company's products with a first class warranty! I highly recommend." >> >> "It just takes several days to receive my 100G switch with Broadcom >> ICOS which is packaged safely and intactly. I followed the >> instruction and seems simple for a non-tech user. Three steps would >> be done: plug it in, cable it up, turn it on. Just the way a good >> product should be. I would like to recommend both the product and the >> seller." >> >> >> Non tech user, network hub in my basement. $10K L3 switch. Jesus. >> The Tactical Flashlight seems more believable right now. >> >> Chuck. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke >> Sent: Friday, January 05, 2018 4:55 PM >> To: Bryan Holloway ; nanog at nanog.org list >> >> Subject: Re: Any experience with Broadcom ICOS out there? >> >> You may have better results with the same question on OCP (open compute >> platform) related forums and mailing lists. The Quanta version of >> that switch sold by FS is pretty much the same thing: >> >> https://linustechtips.com/main/topic/801037-qct-reveals-their-quantamesh-network-switches/ >> >> >> Quanta has been very active in the OCP community for whitebox >> switches. I have heard that they are the switch manufacturer for a >> great deal of Facebook's hyperscale stuff. >> >> >> >> On Fri, Jan 5, 2018 at 1:46 PM, Bryan Holloway wrote: >> >>> Thank you everyone for the responses so far; I should probably >>> re-phrase the question at this point ... >>> >>> Has anyone had production experience with Broadcom ICOS and the >>> features it claims to support? Positive or negative? >>> >>> >>> On 1/5/18 2:46 PM, joel jaeggli wrote: >>> >>>> >>>> On 1/5/18 10:50 AM, Bryan Holloway wrote: >>>> >>>>> Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm >>>>> curious if anyone in the community has any thoughts or real-life >>>>> world experience with them. >>>>> >>>>> E.g.: https://www.fs.com/products/69340.html >>>>> >>>>> For the price point, it's almost in the "too good to be true" >>>>> category. >>>>> >>>> The COGS on a single ASIC tomahawk switch was is in $5000-7000 range. >>>> so it's consistent with a low value add reseller of merchant silicon. >>>> that silicon is getting older (tomahawk 3 was announced in >>>> anticipation of 2018) so we can presume they are getting cheaper. I >>>> generally have a favorable experience of FS but then I buy optics and >>>> cables, not switches so your mileage may vary. >>>> >>>> Naturally it claims to support an impressive range of features >>>> including >>>>> BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. >>>>> >>>> The software stack is Broadcom ICOS. if you're not familiar with that >>>> I start looking at that. if it meets you needs that's cool. if not >>>> you might be looking at cumulus or onos. That said Broadcom does >>>> enough to get their customers (whitebox odms) out the door, not >>>> necessarily the customers of those odms so your recourse to a >>>> developer is kind of limited which you get a from a vendor more >>>> involved in the software stack. A lot of those choices here depend on >>>> how responsible you want to be for what's running inside the box. >>>> >>>>> There was an earlier discussion about packet buffer issues, but, >>>>> assuming for a second that it's not an issue, >>>>> >>>> It can be avoided, but for people used to running all 10Gb/s >>>> cut-through trident 2s kind of hot, some of consequences are kind of >>>> impressive. 4 much smaller buffers and the virtual assurance that >>>> you'll be doing rate conversion eats into the forwarding budget. >>>> >>>>> can anyone say they've used these and/or the L2/L3 features that >>>>> they purportedly support? >>>>> >>>>> Thanks! >>>>> - bryan >>>>> >>>>> > From nanog at ics-il.net Sun Jan 7 17:10:11 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 7 Jan 2018 11:10:11 -0600 (CST) Subject: DSL Operators Mailing List? In-Reply-To: <679618541.18697.1515344927188.JavaMail.mhammett@ThunderFuck> Message-ID: <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> Is there a good mailing list for DSL operators? A cursory search really only came up with DSL Reports, which is far from what I'm looking for. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From jean at ddostest.me Sun Jan 7 19:02:24 2018 From: jean at ddostest.me (Jean | ddostest.me) Date: Sun, 7 Jan 2018 14:02:24 -0500 Subject: Spectre/Meltdown impact on network devices Message-ID: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> Hello, I'm curious to hear the impact on network devices of this new hardware flaws that everybody talk about. Yes, the Meltdown/Spectre flaws. I know that some Arista devices seem to use AMD chips and some say that they might be immune to one of these vulnerability. Still, it's possible to spawn a bash shell in these and one with limited privileges could maybe find some BGP/Ospf/SNMP passwords. Maybe it's also possible to leak a full config. I understand that one need access but still it could be possible for one to social engineer a NOC user, hijack the account with limited access and maybe run the "exploit". I know it's a lot of "if" and "maybe", but still I'm curious what is the status of big networking systems? Are they vulnerable? Thanks Jean From josh at kyneticwifi.com Sun Jan 7 19:14:09 2018 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sun, 7 Jan 2018 13:14:09 -0600 Subject: Spectre/Meltdown impact on network devices In-Reply-To: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> References: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> Message-ID: https://www.reddit.com/r/networking/comments/7o4y40/meltdownspectre_vulnerability_tracker/ On Sun, Jan 7, 2018 at 1:02 PM, Jean | ddostest.me via NANOG wrote: > Hello, > > I'm curious to hear the impact on network devices of this new hardware > flaws that everybody talk about. Yes, the Meltdown/Spectre flaws. > > I know that some Arista devices seem to use AMD chips and some say that > they might be immune to one of these vulnerability. Still, it's possible > to spawn a bash shell in these and one with limited privileges could > maybe find some BGP/Ospf/SNMP passwords. Maybe it's also possible to > leak a full config. > > I understand that one need access but still it could be possible for one > to social engineer a NOC user, hijack the account with limited access > and maybe run the "exploit". > > I know it's a lot of "if" and "maybe", but still I'm curious what is the > status of big networking systems? Are they vulnerable? > > Thanks > > Jean From bill at herrin.us Sun Jan 7 22:36:56 2018 From: bill at herrin.us (William Herrin) Date: Sun, 7 Jan 2018 17:36:56 -0500 Subject: Spectre/Meltdown impact on network devices In-Reply-To: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> References: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> Message-ID: On Sun, Jan 7, 2018 at 2:02 PM, Jean | ddostest.me via NANOG < nanog at nanog.org> wrote: > I'm curious to hear the impact on network devices of this new hardware > flaws that everybody talk about. Yes, the Meltdown/Spectre flaws. > Hi Jean, Meltdown and Spectre are privilege escalation flaws. If you can induce the physical hardware to run arbitrary code you provide at an unprivileged level, they can be used to extract information from other processes or virtual machine containers running at different (higher) privilege levels. Network appliances like routers and switches generally do not run untrusted code so the preconditions for Meltdown and Spectre generally aren't there. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From michael at wi-fiber.io Sun Jan 7 23:12:10 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Sun, 7 Jan 2018 16:12:10 -0700 Subject: Customer woes and ps3 network Message-ID: I have a customer on a ps3, and he can't seem to connect to the psn. Keeps getting the 80710016 error. If there is anyone that can help me troubleshoot this issue, that would be great. From gtaylor at tnetconsulting.net Sun Jan 7 23:58:30 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 7 Jan 2018 16:58:30 -0700 Subject: Customer woes and ps3 network In-Reply-To: References: Message-ID: <0b43ba20-fe9f-38d8-355b-91be8d7a084c@spamtrap.tnetconsulting.net> On 01/07/2018 04:12 PM, Michael Crapse wrote: > I have a customer on a ps3, and he can't seem to connect to the > psn. Keeps getting the 80710016 error. If there is anyone that can help > me troubleshoot this issue, that would be great. I have yet to see the packets on the wire lie. Further, the packets on the wire will likely give you a starting point. After searching for the error, this may not be a problem with the network at all. One report I saw says that the error can come from banned / blacklisted IPs. So you may be looking for a non-existent network problem. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From michael at wi-fiber.io Mon Jan 8 00:14:10 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Sun, 7 Jan 2018 17:14:10 -0700 Subject: Customer woes and ps3 network In-Reply-To: <0b43ba20-fe9f-38d8-355b-91be8d7a084c@spamtrap.tnetconsulting.net> References: <0b43ba20-fe9f-38d8-355b-91be8d7a084c@spamtrap.tnetconsulting.net> Message-ID: I will be on site with the customer tomorrow to do packet captures. It may be a weak wireless signal(he claims). I also saw such a report, and changed his IP to one of our known good IPs, and the issue persists. We are running over PPPoE, so packet size is diminished from 1500 to 1492. I have DMZed his console, issue persists. I have given his router 3 different public IPs to no avail. This(ps3) was working yesterday on hughesnet, until we did our installation. On 7 January 2018 at 16:58, Grant Taylor via NANOG wrote: > On 01/07/2018 04:12 PM, Michael Crapse wrote: > >> I have a customer on a ps3, and he can't seem to connect to the psn. >> Keeps getting the 80710016 error. If there is anyone that can help me >> troubleshoot this issue, that would be great. >> > > I have yet to see the packets on the wire lie. > > Further, the packets on the wire will likely give you a starting point. > > After searching for the error, this may not be a problem with the network > at all. One report I saw says that the error can come from banned / > blacklisted IPs. So you may be looking for a non-existent network problem. > > > > -- > Grant. . . . > unix || die > > From denys at visp.net.lb Mon Jan 8 00:14:25 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Mon, 08 Jan 2018 02:14:25 +0200 Subject: Spectre/Meltdown impact on network devices In-Reply-To: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> References: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> Message-ID: <9913514e81eb3995e92c5bc622e44133@visp.net.lb> AFAIK, Meltdown/Spectre require access to some proper programming language and ability to run attacker own code. If underprivileged user can't spawn shell on device or run some python code - i guess you are safe. I guess people need to push support of vendors, for equipment who has programming languages/shell, to release statement about possibility of vulnerability. As fixing require significant changes in "memory" operation model, i doubt they will do such thing, i guess in best case they will restrict access to insert code under nonprivileged users (if it is allowed now). For example, even old Cisco IOS has TCL, but logically under level 15, so i assume it is safe. On 2018-01-07 21:02, Jean | ddostest.me via NANOG wrote: > Hello, > > I'm curious to hear the impact on network devices of this new hardware > flaws that everybody talk about. Yes, the Meltdown/Spectre flaws. > > I know that some Arista devices seem to use AMD chips and some say that > they might be immune to one of these vulnerability. Still, it's > possible > to spawn a bash shell in these and one with limited privileges could > maybe find some BGP/Ospf/SNMP passwords. Maybe it's also possible to > leak a full config. > > I understand that one need access but still it could be possible for > one > to social engineer a NOC user, hijack the account with limited access > and maybe run the "exploit". > > I know it's a lot of "if" and "maybe", but still I'm curious what is > the > status of big networking systems? Are they vulnerable? > > Thanks > > Jean From mohta at necom830.hpcl.titech.ac.jp Mon Jan 8 01:57:21 2018 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 8 Jan 2018 10:57:21 +0900 Subject: Spectre/Meltdown impact on network devices In-Reply-To: References: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> Message-ID: William Herrin wrote: > Meltdown and Spectre are privilege escalation flaws. If you can induce the > physical hardware to run arbitrary code you provide at an unprivileged > level, they can be used to extract information from other processes or > virtual machine containers running at different (higher) privilege levels. So, spectre should be fatal to cloud business. Masataka Ohta From glen.kent at gmail.com Mon Jan 8 05:26:47 2018 From: glen.kent at gmail.com (Glen Kent) Date: Mon, 8 Jan 2018 10:56:47 +0530 Subject: Blockchain and Networking Message-ID: Hi, Do folks on this list see blockchain technology making inroads into the networking? I can see blockchain being used to secure the SDN environment where blockchain will allow encrypted data transfers between nodes (ones hosting different applications, the SDN controller, the data plane devices) regardless of the network size or its geographical distribution. Where else can blockchain be used in networking? Glen. From hugo at slabnet.com Mon Jan 8 05:38:53 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Sun, 07 Jan 2018 21:38:53 -0800 Subject: Blockchain and Networking In-Reply-To: References: Message-ID: >Where else can blockchain be used in networking? Other uses notwithstanding, it should be good for inflating the share price of any network vendor that adds "now with block chain!" somewhere into their product portfolio. /snark -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On January 7, 2018 9:26:47 PM PST, Glen Kent wrote: >Hi, > >Do folks on this list see blockchain technology making inroads into the >networking? I can see blockchain being used to secure the SDN >environment >where blockchain will allow encrypted data transfers between nodes >(ones >hosting different applications, the SDN controller, the data plane >devices) >regardless of the network size or its geographical distribution. > >Where else can blockchain be used in networking? > >Glen. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 850 bytes Desc: not available URL: From bill at herrin.us Mon Jan 8 05:47:35 2018 From: bill at herrin.us (William Herrin) Date: Mon, 8 Jan 2018 00:47:35 -0500 Subject: Spectre/Meltdown impact on network devices In-Reply-To: References: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> Message-ID: On Sun, Jan 7, 2018 at 8:57 PM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > William Herrin wrote: > >> Meltdown and Spectre are privilege escalation flaws. If you can induce the >> physical hardware to run arbitrary code you provide at an unprivileged >> level, they can be used to extract information from other processes or >> virtual machine containers running at different (higher) privilege levels. >> > > So, spectre should be fatal to cloud business. Doubt it. But they are the ones who'll have to scramble fastest to patch. It's also really giving browser devs a bad day since it provides yet another escalation out of the javascript sandbox. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Mon Jan 8 05:52:55 2018 From: bill at herrin.us (William Herrin) Date: Mon, 8 Jan 2018 00:52:55 -0500 Subject: Blockchain and Networking In-Reply-To: References: Message-ID: On Mon, Jan 8, 2018 at 12:26 AM, Glen Kent wrote: > Do folks on this list see blockchain technology making inroads into the > networking? I can see blockchain being used to secure the SDN environment > where blockchain will allow encrypted data transfers between nodes (ones > hosting different applications, the SDN controller, the data plane devices) > regardless of the network size or its geographical distribution. > Hi Glen, I'm having trouble envisioning a scenario where blockchain does that any better than plain old PKI. Blockchain is great at proving chain of custody, but when do you need to do that in computer networking? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From tknchris at gmail.com Mon Jan 8 06:23:08 2018 From: tknchris at gmail.com (chris) Date: Mon, 8 Jan 2018 01:23:08 -0500 Subject: Blockchain and Networking In-Reply-To: References: Message-ID: agreed this could have potential to be the next "devops" style buzzword On Mon, Jan 8, 2018 at 12:38 AM, Hugo Slabbert wrote: > >Where else can blockchain be used in networking? > > Other uses notwithstanding, it should be good for inflating the share > price of any network vendor that adds "now with block chain!" somewhere > into their product portfolio. > > /snark > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > > On January 7, 2018 9:26:47 PM PST, Glen Kent wrote: > >Hi, > > > >Do folks on this list see blockchain technology making inroads into the > >networking? I can see blockchain being used to secure the SDN > >environment > >where blockchain will allow encrypted data transfers between nodes > >(ones > >hosting different applications, the SDN controller, the data plane > >devices) > >regardless of the network size or its geographical distribution. > > > >Where else can blockchain be used in networking? > > > >Glen. > From alter3d at alter3d.ca Mon Jan 8 06:59:11 2018 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Mon, 8 Jan 2018 01:59:11 -0500 Subject: Blockchain and Networking In-Reply-To: References: Message-ID: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> On 2018-01-08 12:52 AM, William Herrin wrote: > I'm having trouble envisioning a scenario where blockchain does that any > better than plain old PKI. > > Blockchain is great at proving chain of custody, but when do you need to do > that in computer networking? > > Regards, > Bill Herrin There's probably some potential in using a blockchain for things like configuration management.  You can authenticate who made what change and when (granted, we can kinda-sorta do this already with the various authentication and logging mechanisms, but the blockchain is an immutable, permanent record inherently required for the system to work at all). That immutable, sequenced chain of events would let you do things like "make my test environment look like production did last Thursday at 9AM" trivially by reading the blockchain up until that timestamp, then running a fork of the chain for the new test environment to track its own changes during testing. Or when you know you did something 2 months ago for client A, and you need your new NOC guy to now do it for client B -- the blockchain becomes the documentation of what was done. We can build all of the above in other ways today, of course.  But there's certainly something to be said for a vendor-supported solution that is inherent in the platform and requires no additional infrastructure.  Whether or not that's worth the complexities of managing a blockchain on networking devices is, perhaps, a whole other discussion.   :) - Peter From denys at visp.net.lb Mon Jan 8 07:03:43 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Mon, 08 Jan 2018 09:03:43 +0200 Subject: Blockchain and Networking In-Reply-To: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> Message-ID: <8c8a3652aed849dbe9eff2956fa7be23@visp.net.lb> On 2018-01-08 08:59, Peter Kristolaitis wrote: > On 2018-01-08 12:52 AM, William Herrin wrote: >> I'm having trouble envisioning a scenario where blockchain does that >> any >> better than plain old PKI. >> >> Blockchain is great at proving chain of custody, but when do you need >> to do >> that in computer networking? >> >> Regards, >> Bill Herrin > > There's probably some potential in using a blockchain for things like > configuration management.  You can authenticate who made what change > and when (granted, we can kinda-sorta do this already with the various > authentication and logging mechanisms, but the blockchain is an > immutable, permanent record inherently required for the system to work > at all). > > That immutable, sequenced chain of events would let you do things like > "make my test environment look like production did last Thursday at > 9AM" trivially by reading the blockchain up until that timestamp, then > running a fork of the chain for the new test environment to track its > own changes during testing. > > Or when you know you did something 2 months ago for client A, and you > need your new NOC guy to now do it for client B -- the blockchain > becomes the documentation of what was done. > > We can build all of the above in other ways today, of course.  But > there's certainly something to be said for a vendor-supported solution > that is inherent in the platform and requires no additional > infrastructure.  Whether or not that's worth the complexities of > managing a blockchain on networking devices is, perhaps, a whole other > discussion.   :) > > - Peter Why to reinvent git? :) Lot of tools available also, to see diff on git commits, to see who did commit, and what exactly he changed. (it is possible to cryptographically sign commits, as well, and yes, they are chain signed, as "blockchain") From denys at visp.net.lb Mon Jan 8 08:57:57 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Mon, 08 Jan 2018 10:57:57 +0200 Subject: Blockchain and Networking In-Reply-To: References: Message-ID: <0b19ac5a76d3001c454e891f55d61655@visp.net.lb> Each offsite copy of git repository will give alert then, as all hashes in chain changed at some moment. Same principle as blockchain. On 2018-01-08 09:54, tglassey at earthlink.net wrote: > Uh since MITM Bill perk of custody is key. > > //tsg > > Sent from my HTC > ----- Reply message ----- > From: "Denys Fedoryshchenko" > To: > Subject: Blockchain and Networking > Date: Mon, Jan 8, 2018 10:03 > > On 2018-01-08 08:59, Peter Kristolaitis wrote: >> On 2018-01-08 12:52 AM, William Herrin wrote: >>> I'm having trouble envisioning a scenario where blockchain does > that >> any >>> better than plain old PKI. >>> >> Blockchain is great at proving chain of custody, but when do you > need >> to do >>> that in computer networking? >>> >> Regards, >>> Bill Herrin >> > There's probably some potential in using a blockchain for things > like >> configuration management. You can authenticate who made what change >> and when (granted, we can kinda-sorta do this already with the > various >> authentication and logging mechanisms, but the blockchain is an >> immutable, permanent record inherently required for the system to > work >> at all). >> > That immutable, sequenced chain of events would let you do things > like >> "make my test environment look like production did last Thursday at >> 9AM" trivially by reading the blockchain up until that timestamp, > then >> running a fork of the chain for the new test environment to track > its >> own changes during testing. >> > Or when you know you did something 2 months ago for client A, and > you >> need your new NOC guy to now do it for client B -- the blockchain >> becomes the documentation of what was done. >> > We can build all of the above in other ways today, of course. But >> there's certainly something to be said for a vendor-supported > solution >> that is inherent in the platform and requires no additional >> infrastructure. Whether or not that's worth the complexities of >> managing a blockchain on networking devices is, perhaps, a whole > other >> discussion. :) >> > - Peter > Why to reinvent git? :) > Lot of tools available also, to see diff on git commits, to see who > did commit, and what exactly he changed. > (it is possible to cryptographically sign commits, as well, and yes, > they are chain signed, as "blockchain") From jk at ip-clear.de Mon Jan 8 09:41:11 2018 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Mon, 08 Jan 2018 10:41:11 +0100 Subject: Blockchain and Networking In-Reply-To: <8c8a3652aed849dbe9eff2956fa7be23@visp.net.lb> References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <8c8a3652aed849dbe9eff2956fa7be23@visp.net.lb> Message-ID: <6606E265-6B0C-4A29-8D6B-99FBFF3A0B13@ip-clear.de> Hi, its not only about PKI. There are some currencies in the wild right now, that are more scalable than bitcoin and are made for the "ddos" world of IoT. For example a possible BGP extension could use smart contracts to form and confirm peering and also handle the direct payment process to the upstreams. Things like the DirectCloud of DE-CIX could be replaced by a "BGP-Exchange", where "routers" can sell and order services on their own and on-demand, for example if the "router" needs suddenly more bits to AS$X on a cold winter night. Also a "$IoT" device like a streaming dongle could order and pay by itself and may book the nearest data-"highway" for a PPV-event. Jörg > On 2018-01-08 08:59, Peter Kristolaitis wrote: >> On 2018-01-08 12:52 AM, William Herrin wrote: >>> I'm having trouble envisioning a scenario where blockchain does that >>> any >>> better than plain old PKI. >>> >>> Blockchain is great at proving chain of custody, but when do you >>> need to do >>> that in computer networking? >>> >>> Regards, >>> Bill Herrin From mohta at necom830.hpcl.titech.ac.jp Mon Jan 8 09:49:34 2018 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 8 Jan 2018 18:49:34 +0900 Subject: Spectre/Meltdown impact on network devices In-Reply-To: <8afc7733-a1e5-6bbb-23a2-2e3dac0bfe5a@gmail.com> References: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> <8afc7733-a1e5-6bbb-23a2-2e3dac0bfe5a@gmail.com> Message-ID: Jason Gmail wrote: > The only business I've been looking at is AWS > > https://aws.amazon.com/security/security-bulletins/AWS-2018-013/ It merely says: All instances across the Amazon EC2 fleet are protected from all known threat vectors from the CVEs previously listed. not spectre in general. But, as mentioned in: https://access.redhat.com/security/cve/cve-2017-5715 It relies on the presence of a precisely-defined instruction sequence in the privileged code and https://access.redhat.com/security/cve/cve-2017-5753 It relies on the presence of a precisely-defined instruction sequence in the privileged code CVEs previously listed are spectre attacks between privileged and unprivileged codes, which means spectre attack between unprivileged codes is still possible with AWS, which is why we should avoid cloud servers, until CPU hardware is fixed. Masataka Ohta From hibaysal at gmail.com Mon Jan 8 10:09:14 2018 From: hibaysal at gmail.com (H I Baysal) Date: Mon, 8 Jan 2018 11:09:14 +0100 Subject: Customer woes and ps3 network In-Reply-To: References: <0b43ba20-fe9f-38d8-355b-91be8d7a084c@spamtrap.tnetconsulting.net> Message-ID: Hi, So first of all, PS3 in 2018...... :P But kidding aside, some application require TCP-MSS (maximum segment size) to be set to a lower value than the default. You can play with the size but i settled for 1450 at the time. good luck 2018-01-08 1:14 GMT+01:00 Michael Crapse : > I will be on site with the customer tomorrow to do packet captures. > It may be a weak wireless signal(he claims). > I also saw such a report, and changed his IP to one of our known good IPs, > and the issue persists. > We are running over PPPoE, so packet size is diminished from 1500 to 1492. > I have DMZed his console, issue persists. I have given his router 3 > different public IPs to no avail. > This(ps3) was working yesterday on hughesnet, until we did our > installation. > > On 7 January 2018 at 16:58, Grant Taylor via NANOG > wrote: > > > On 01/07/2018 04:12 PM, Michael Crapse wrote: > > > >> I have a customer on a ps3, and he can't seem to connect to the psn. > >> Keeps getting the 80710016 error. If there is anyone that can help me > >> troubleshoot this issue, that would be great. > >> > > > > I have yet to see the packets on the wire lie. > > > > Further, the packets on the wire will likely give you a starting point. > > > > After searching for the error, this may not be a problem with the network > > at all. One report I saw says that the error can come from banned / > > blacklisted IPs. So you may be looking for a non-existent network > problem. > > > > > > > > -- > > Grant. . . . > > unix || die > > > > > -- Met vriendelijke groet / kind regards, Halil Ibrahim Baysal T: +31 (0)6 20 14 20 79 E: hibaysal at gmail.com From hibaysal at gmail.com Mon Jan 8 10:10:33 2018 From: hibaysal at gmail.com (H I Baysal) Date: Mon, 8 Jan 2018 11:10:33 +0100 Subject: Customer woes and ps3 network In-Reply-To: References: <0b43ba20-fe9f-38d8-355b-91be8d7a084c@spamtrap.tnetconsulting.net> Message-ID: Sorry for the spam, but it should have been "Some application, with a PPPoE connection, require TCP-MSS (maximum segment size) to be set to a lower value than the default." 2018-01-08 11:09 GMT+01:00 H I Baysal : > Hi, > > So first of all, PS3 in 2018...... :P > But kidding aside, > some application require TCP-MSS (maximum segment size) to be set to a > lower value than the default. > > You can play with the size but i settled for 1450 at the time. > > good luck > > > > 2018-01-08 1:14 GMT+01:00 Michael Crapse : > >> I will be on site with the customer tomorrow to do packet captures. >> It may be a weak wireless signal(he claims). >> I also saw such a report, and changed his IP to one of our known good IPs, >> and the issue persists. >> We are running over PPPoE, so packet size is diminished from 1500 to 1492. >> I have DMZed his console, issue persists. I have given his router 3 >> different public IPs to no avail. >> This(ps3) was working yesterday on hughesnet, until we did our >> installation. >> >> On 7 January 2018 at 16:58, Grant Taylor via NANOG >> wrote: >> >> > On 01/07/2018 04:12 PM, Michael Crapse wrote: >> > >> >> I have a customer on a ps3, and he can't seem to connect to the psn. >> >> Keeps getting the 80710016 error. If there is anyone that can help me >> >> troubleshoot this issue, that would be great. >> >> >> > >> > I have yet to see the packets on the wire lie. >> > >> > Further, the packets on the wire will likely give you a starting point. >> > >> > After searching for the error, this may not be a problem with the >> network >> > at all. One report I saw says that the error can come from banned / >> > blacklisted IPs. So you may be looking for a non-existent network >> problem. >> > >> > >> > >> > -- >> > Grant. . . . >> > unix || die >> > >> > >> > > > > -- > Met vriendelijke groet / kind regards, > > Halil Ibrahim Baysal > > T: +31 (0)6 20 14 20 79 > E: hibaysal at gmail.com > -- Met vriendelijke groet / kind regards, Halil Ibrahim Baysal T: +31 (0)6 20 14 20 79 E: hibaysal at gmail.com From bortzmeyer at nic.fr Mon Jan 8 10:41:04 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 8 Jan 2018 11:41:04 +0100 Subject: Spectre/Meltdown impact on network devices In-Reply-To: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> References: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> Message-ID: <20180108104104.e4jrnka5b75a2k7u@nic.fr> On Sun, Jan 07, 2018 at 02:02:24PM -0500, Jean | ddostest.me via NANOG wrote a message of 21 lines which said: > I'm curious to hear the impact on network devices of this new hardware > flaws that everybody talk about. Yes, the Meltdown/Spectre flaws. https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180104-cpusidechannel > I understand that one need access but still it could be possible for one > to social engineer a NOC user, hijack the account with limited access > and maybe run the "exploit". There are other ways to tun code on the target machine. JavaScript is the most obvious one (and there are JavaScript exploits for Meltdown) but, of course, the typical router does not have a Web browser. So, the best solution, for the attacker, is probably to exploit a bug in the BGP parser (as we have seen with attribute 99, BGP parsers have bugs): with a buffer overflow, you may be able to run code you choose. Purely theoretical at this stage, I didn't try. From saku at ytti.fi Mon Jan 8 11:30:44 2018 From: saku at ytti.fi (Saku Ytti) Date: Mon, 8 Jan 2018 13:30:44 +0200 Subject: Spectre/Meltdown impact on network devices In-Reply-To: <20180108104104.e4jrnka5b75a2k7u@nic.fr> References: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> <20180108104104.e4jrnka5b75a2k7u@nic.fr> Message-ID: On 8 January 2018 at 12:41, Stephane Bortzmeyer wrote: > the best solution, for the attacker, is probably to exploit a bug in > the BGP parser (as we have seen with attribute 99, BGP parsers have > bugs): with a buffer overflow, you may be able to run code you > choose. Purely theoretical at this stage, I didn't try. BGP runs as a privileged user, if you're already executing code as BGP, why do you need Spectre or Meltdown? Just read the memory you're interested in, or setup port mirror, or reroute traffic. -- ++ytti From jwbensley at gmail.com Mon Jan 8 14:21:25 2018 From: jwbensley at gmail.com (James Bensley) Date: Mon, 8 Jan 2018 14:21:25 +0000 Subject: DSL Operators Mailing List? In-Reply-To: <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> References: <679618541.18697.1515344927188.JavaMail.mhammett@ThunderFuck> <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> Message-ID: On 7 January 2018 at 17:10, Mike Hammett wrote: > Is there a good mailing list for DSL operators? A cursory search really only came up with DSL Reports, which is far from what I'm looking for. Hi Mike, I only know of the https://puck.nether.net/mailman/listinfo/cisco-bba list. It is Cisco specific list and very low volume (see the archives) however, people might not mind you talking about DSL operations in general as long as it isn't specific to another vendor. Cheers, James. From jwbensley at gmail.com Mon Jan 8 14:29:51 2018 From: jwbensley at gmail.com (James Bensley) Date: Mon, 8 Jan 2018 14:29:51 +0000 Subject: Spectre/Meltdown impact on network devices In-Reply-To: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> References: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> Message-ID: On 7 January 2018 at 19:02, Jean | ddostest.me via NANOG wrote: > Hello, > > I'm curious to hear the impact on network devices of this new hardware > flaws that everybody talk about. Yes, the Meltdown/Spectre flaws. > > I know that some Arista devices seem to use AMD chips and some say that > they might be immune to one of these vulnerability. Still, it's possible > to spawn a bash shell in these and one with limited privileges could > maybe find some BGP/Ospf/SNMP passwords. Maybe it's also possible to > leak a full config. > > I understand that one need access but still it could be possible for one > to social engineer a NOC user, hijack the account with limited access > and maybe run the "exploit". > > I know it's a lot of "if" and "maybe", but still I'm curious what is the > status of big networking systems? Are they vulnerable? > > Thanks > > Jean Some devices run affected Intel chips like the Cisco ASR9000 series and they run Perl and Python so very exploitable I would expect, IF you have shell access. There are much more serious security issues out there to worry about for networking gear than Meltdown/Spectre, e.g. this great CCC34 preso where the attacker runs remote code on a Cisco device and removes the password authentication for Telnet: https://events.ccc.de/congress/2017/Fahrplan/events/8936.html The video is on the CCC YouTube channel: https://www.youtube.com/watch?v=fA6W9_zLCeA If somebody has shell access you're basically knackered, I'm more concerned about these kinds of remote exploits as demonstrated. Proper iACLs/CoPPs and IDS/IPS, good patching cycles etc. Cheers, James. From bortzmeyer at nic.fr Mon Jan 8 14:45:14 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 8 Jan 2018 15:45:14 +0100 Subject: Spectre/Meltdown impact on network devices In-Reply-To: <20180108104104.e4jrnka5b75a2k7u@nic.fr> References: <94ed3010-84f2-db0d-bf82-d4453d9cc4b9@ddostest.me> <20180108104104.e4jrnka5b75a2k7u@nic.fr> Message-ID: <20180108144514.n4lem26l76k7eg4l@nic.fr> On Mon, Jan 08, 2018 at 11:41:04AM +0100, Stephane Bortzmeyer wrote a message of 20 lines which said: > > I'm curious to hear the impact on network devices of this new hardware > > flaws that everybody talk about. Yes, the Meltdown/Spectre flaws. > > https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180104-cpusidechannel And for Juniper : https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10842&actp=RSS From nwarren at barryelectric.com Mon Jan 8 17:03:14 2018 From: nwarren at barryelectric.com (Nicholas Warren) Date: Mon, 8 Jan 2018 17:03:14 +0000 Subject: Site-Local/Unique-Local Addressing (IPv6) Message-ID: Layman here, I was reviewing RFCs for a local address for IPv6. I came across two RFCs that seem interesting. 3879 Which deprecates Site Local Addresses. 4193 Which seems to add Unique Local Addresses. What is the main difference here? Why was this standard removed then added back? Thanks, Nich Warren From cra at WPI.EDU Mon Jan 8 17:09:09 2018 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 8 Jan 2018 12:09:09 -0500 Subject: Site-Local/Unique-Local Addressing (IPv6) In-Reply-To: References: Message-ID: <20180108170909.GJ1561@angus.ind.wpi.edu> On Mon, Jan 08, 2018 at 05:03:14PM +0000, Nicholas Warren wrote: > Layman here, I was reviewing RFCs for a local address for IPv6. I came across two RFCs that seem interesting. > > 3879 Which deprecates Site Local Addresses. > 4193 Which seems to add Unique Local Addresses. > > What is the main difference here? Why was this standard removed then added back? Site Local Addresses are/were Site Scope, similar to how Link-Local are Link-Local Scope and others are Global Scope. ULA are Global Scope--but that doesn't mean they are globally routable. The problem with Scopes being built-in to the addressing model is that software has to be coded to treat different scopes differently. It is hard enough to deal with Link-Local scope, and it was deemed too hard to deal with yet another scope--Site Local. For an example of the pain, try using Link-Local addresses in a web browser, or even with "ping" on the command line. From nanog at ics-il.net Mon Jan 8 17:49:10 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 8 Jan 2018 11:49:10 -0600 (CST) Subject: Level 3 IRR In-Reply-To: <1325480756.17740.1515250243250.JavaMail.mhammett@ThunderFuck> References: <1325480756.17740.1515250243250.JavaMail.mhammett@ThunderFuck> Message-ID: <1413242081.206.1515433747267.JavaMail.mhammett@ThunderFuck> r0utingatlevel3dotcom (unobfuscated) worked. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG" Sent: Saturday, January 6, 2018 8:50:44 AM Subject: Level 3 IRR I've tried an assortment of e-mail addresses for Level 3 and LightCore (the ASN that placed the entry, conveniently now all under the same roof) to get a record removed from their IRR. I appreciate any good contacts offline. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From bill at herrin.us Mon Jan 8 18:12:33 2018 From: bill at herrin.us (William Herrin) Date: Mon, 8 Jan 2018 13:12:33 -0500 Subject: Site-Local/Unique-Local Addressing (IPv6) In-Reply-To: References: Message-ID: On Mon, Jan 8, 2018 at 12:03 PM, Nicholas Warren wrote: > Layman here, I was reviewing RFCs for a local address for IPv6. I came > across two RFCs that seem interesting. > > 3879 Which deprecates Site Local Addresses. > 4193 Which seems to add Unique Local Addresses. > > What is the main difference here? Why was this standard removed then added > back? > Hi Nich, ULA is the IPv6 equivalent to RFC1918. If assigned as instructed (randomly), it can be used to build multi-organziation private networks with a relatively low risk of collision, a property lacking in RFC1918. Other than that, it's exactly the same as RFC 1918. Site local is deprecated. As explained in the RFC, the concept of a "site" could not be usefully defined for the purpose of private addressing. You can safely ignore it. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From dovid at telecurve.com Mon Jan 8 22:55:55 2018 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 8 Jan 2018 17:55:55 -0500 Subject: MTU to CDN's Message-ID: Hi, N00b here trying to understand why certain CDN's such as Cloudfare have issues where my MTU is low. For instance if I am using pptp and the MTU is at 1300 it wont work. If I increase to 1478 it may or may not work. TIA. From joelja at bogus.com Mon Jan 8 23:08:51 2018 From: joelja at bogus.com (joel jaeggli) Date: Mon, 8 Jan 2018 15:08:51 -0800 Subject: MTU to CDN's In-Reply-To: References: Message-ID: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> On 1/8/18 2:55 PM, Dovid Bender wrote: > Hi, > > N00b here trying to understand why certain CDN's such as Cloudfare have > issues where my MTU is low. For instance if I am using pptp and the MTU is > at 1300 it wont work. If I increase to 1478 it may or may not work. PMTUD has a lot of trouble working reliability when the destination of the PTB  is a stateless load-balancer. If your tunnel or host clamps the mss  to the appropriate value it can support. it is highly likely that connection attempts to the same destination will work fine. > TIA. > From jared at puck.Nether.net Tue Jan 9 00:54:03 2018 From: jared at puck.Nether.net (Jared Mauch) Date: Mon, 8 Jan 2018 19:54:03 -0500 Subject: MTU to CDN's In-Reply-To: References: Message-ID: <20180109005402.GC14165@puck.nether.net> On Mon, Jan 08, 2018 at 05:55:55PM -0500, Dovid Bender wrote: > Hi, > > N00b here trying to understand why certain CDN's such as Cloudfare have > issues where my MTU is low. For instance if I am using pptp and the MTU is > at 1300 it wont work. If I increase to 1478 it may or may not work. I've done some measurements over the internet in the past year or so and 1400 byte packets with DF bit seem to make it just fine. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From marka at isc.org Tue Jan 9 01:49:24 2018 From: marka at isc.org (Mark Andrews) Date: Tue, 9 Jan 2018 12:49:24 +1100 Subject: MTU to CDN's In-Reply-To: <20180109005402.GC14165@puck.nether.net> References: <20180109005402.GC14165@puck.nether.net> Message-ID: <41463964-5A0F-400A-A61E-7AFCDB8DA61A@isc.org> CDN’s (or anyone using a load balancer to multiple server instances) needs to assume that traffic may be encapsulated (4in6, 6in4, 464XLAT) and lower the interface MTU’s so that all traffic generated can be encapsulated without fragmentation or PTB’s being generated. This is only going to get worse as more and more eyeballs are being forced into using IPv4 as a service scenarios. > On 9 Jan 2018, at 11:54 am, Jared Mauch wrote: > > On Mon, Jan 08, 2018 at 05:55:55PM -0500, Dovid Bender wrote: >> Hi, >> >> N00b here trying to understand why certain CDN's such as Cloudfare have >> issues where my MTU is low. For instance if I am using pptp and the MTU is >> at 1300 it wont work. If I increase to 1478 it may or may not work. > > I've done some measurements over the internet in the past year or > so and 1400 byte packets with DF bit seem to make it just fine. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From colton.conor at gmail.com Tue Jan 9 02:24:35 2018 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 8 Jan 2018 20:24:35 -0600 Subject: DSL Operators Mailing List? In-Reply-To: References: <679618541.18697.1515344927188.JavaMail.mhammett@ThunderFuck> <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, Lots of people on this list have DSL experience. What are you looking for? On Mon, Jan 8, 2018 at 8:21 AM, James Bensley wrote: > On 7 January 2018 at 17:10, Mike Hammett wrote: > > Is there a good mailing list for DSL operators? A cursory search really > only came up with DSL Reports, which is far from what I'm looking for. > > Hi Mike, > > I only know of the https://puck.nether.net/mailman/listinfo/cisco-bba > list. It is Cisco specific list and very low volume (see the archives) > however, people might not mind you talking about DSL operations in > general as long as it isn't specific to another vendor. > > Cheers, > James. > From colton.conor at gmail.com Tue Jan 9 02:30:01 2018 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 8 Jan 2018 20:30:01 -0600 Subject: Any experience with FS hardware out there? In-Reply-To: <20180105191926.GB25899@bamboo.slabnet.com> References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> <20180105191926.GB25899@bamboo.slabnet.com> Message-ID: Where do you get wholesale pricing from Edgecore? Simple google searches only bring up https://bm-switch.com/index.php/edge-core-as7712-32x-100g-bm-switch-preloaded-with-onie.html On Fri, Jan 5, 2018 at 1:19 PM, Hugo Slabbert wrote: > > On Fri 2018-Jan-05 12:50:42 -0600, Bryan Holloway wrote: > > Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm >> curious if anyone in the community has any thoughts or real-life world >> experience with them. >> >> E.g.: https://www.fs.com/products/69340.html >> >> For the price point, it's almost in the "too good to be true" category. >> > > The price is on par with the hardware cost of other whitebox Tomahawks, > e.g. Edge-Core 32x100G models like the AS7712 or AS7716 that also runs the > BCM56960, so the primary distinction seems to be that you get a NOS > included in that price. I have zero experience with Broadcom's ICOS as > opposed to the other options on the market, so it seems to be a question of > whether you're happy with that or would be e.g. paying Cumulus or $vendor a > few K USD for a license for their NOS on it. > > > Naturally it claims to support an impressive range of features including >> BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. >> >> There was an earlier discussion about packet buffer issues, but, assuming >> for a second that it's not an issue, can anyone say they've used these >> and/or the L2/L3 features that they purportedly support? >> >> Thanks! >> - bryan >> >> > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > From rwoolleynanog at gmail.com Tue Jan 9 03:16:05 2018 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Mon, 8 Jan 2018 22:16:05 -0500 Subject: =?UTF-8?B?UmU6IOKcmE5ldGZsaXg=?= In-Reply-To: <20180105231726.34e646f6@spidey.rellim.com> References: <20180105231726.34e646f6@spidey.rellim.com> Message-ID: Hi Gary, geosupport at netflix.com are the right folks to help you with this. In the unlikely event that doesn't get you what you need, or if you otherwise need to reach someone at Netflix on the CDN side, please use cdnetops at netflix.com Regards, Ryan Woolley Netflix On Sat, Jan 6, 2018 at 2:17 AM, Gary E. Miller wrote: > Yo All! > > Sorry to bother, but... > > Netflis is blocking my IP range. 1st line support useless. Months and > can not reah anyone with a clue. Anyone got a Netflix contact? > > RGDS > GARY > ------------------------------------------------------------ > --------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem at rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? > "If you can’t measure it, you can’t improve it." - Lord Kelvin > From johnl at iecc.com Tue Jan 9 03:19:24 2018 From: johnl at iecc.com (John Levine) Date: 9 Jan 2018 11:19:24 +0800 Subject: Blockchain and Networking In-Reply-To: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> Message-ID: <20180109031925.2CC1818EC6E9@ary.local> In article <0c45eee2-ffcb-2066-1456-eb2d38075007 at alter3d.ca>, Peter Kristolaitis wrote: >We can build all of the above in other ways today, of course.  But >there's certainly something to be said for a vendor-supported solution >that is inherent in the platform and requires no additional >infrastructure. ... No additional infrastructure? Blockchains need multiple devices that are online and have enough storage to keep a full copy of the chain. They make sense in an environment with multiple sophisticated parties that sort of but not entirely trust each other, but there aren't as many of those as you might think. -- Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From johnl at iecc.com Tue Jan 9 06:07:20 2018 From: johnl at iecc.com (John R. Levine) Date: 9 Jan 2018 14:07:20 +0800 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: > How about validating whether a given AS is an acceptable origin for a set > of prefixes? Seems like a problem (route hijacking) that's still been > looking for a solution. Lots of BGP routers, RRs, prefix databases are > around, maintained and generally online. Current practices are incomplete > and for many large carriers, operate on a 24 hour cycle which might not be > acceptable if the world had a more instant option in place. It is not my impression that maintaining an updatable database of (AS, prefix) pairs is particularly difficult. What's hard is figuring out who's allowed to put what into the database, and blockchains offer no help at all there. See https://xkcd.com/927/ Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From valdis.kletnieks at vt.edu Tue Jan 9 06:23:41 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 09 Jan 2018 01:23:41 -0500 Subject: MTU to CDN's In-Reply-To: References: Message-ID: <77795.1515479021@turing-police.cc.vt.edu> On Mon, 08 Jan 2018 17:55:55 -0500, Dovid Bender said: > Hi, > > N00b here trying to understand why certain CDN's such as Cloudfare have > issues where my MTU is low. For instance if I am using pptp and the MTU is > at 1300 it wont work. If I increase to 1478 it may or may not work. Wait, what? MTU 1300 fails but 1478 sometimes works? Or was 1300 a typo and you meant 1500? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From swmike at swm.pp.se Tue Jan 9 06:33:06 2018 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 9 Jan 2018 07:33:06 +0100 (CET) Subject: MTU to CDN's In-Reply-To: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: On Mon, 8 Jan 2018, joel jaeggli wrote: > PMTUD has a lot of trouble working reliability when the destination of > the PTB  is a stateless load-balancer. > > If your tunnel or host clamps the mss  to the appropriate value it can > support. it is highly likely that connection attempts to the same > destination will work fine. This is understandable, but if this is also an operational practice we as the operational community want to condone (people using solutions where PMTUD doesn't work), then we also need to make sure that all applications do PLMTUD (RFC4821, Packet Level MTU Discovery). This is currently NOT the case, and from what I can tell, there isn't even an IETF document saying this is the best current practice. So, is this something we want to say? We should talk about that. -- Mikael Abrahamsson email: swmike at swm.pp.se From hank at efes.iucc.ac.il Tue Jan 9 07:17:59 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 9 Jan 2018 09:17:59 +0200 Subject: Comparison of freeware open source switch software? Message-ID: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> I have seen numerous comparisons and RIPE presentations on performance issues of BIRD vs Quagga vs FRR. I am looking for the same thing for freeware switch software. Has anyone done a feature comparison between: http://openvswitch.org/ https://www.openswitch.net/ https://cumulusnetworks.com/products/cumulus-linux/ ...any other I am missing... I am familiar with: http://packetpushers.net/open-networking-cheat-sheet/ https://www.networkworld.com/article/2919599/cisco-subnet/clearing-the-fog-around-open-switching-terminology.html so to clarify I am interested only in bare-metal or whitebox swicthes and freeware, open source software. And even better - has anyone done a benchmark to see which performs best? Thanks, Hank From alter3d at alter3d.ca Tue Jan 9 07:39:22 2018 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 9 Jan 2018 02:39:22 -0500 Subject: Blockchain and Networking In-Reply-To: <20180109031925.2CC1818EC6E9@ary.local> References: <20180109031925.2CC1818EC6E9@ary.local> Message-ID: On 2018-01-08 10:19 PM, John Levine wrote: > In article <0c45eee2-ffcb-2066-1456-eb2d38075007 at alter3d.ca>, > Peter Kristolaitis wrote: >> We can build all of the above in other ways today, of course.  But >> there's certainly something to be said for a vendor-supported solution >> that is inherent in the platform and requires no additional >> infrastructure. ... > No additional infrastructure? Blockchains need multiple devices that > are online and have enough storage to keep a full copy of the chain. There is absolutely no reason that the networking equipment itself can't both operate the blockchain and keep a full copy.  It's a pretty good bet that your own routers will probably be online;  if not, you have bigger problems. The storage requirements aren't particularly onerous.  The entire Bitcoin blockchain is around 150GB, with several orders of magnitude more transactions (read: config changes) than you're likely to see even on a very large network.  SSDs are small enough and reliable enough now that the physical space requirements are quite small. > They make sense in an environment with multiple sophisticated parties > that sort of but not entirely trust each other, but there aren't as > many of those as you might think. You (presumably) trust your own routers.  There is absolutely no reason that your own little network can't run your own private blockchain.   In fact, for my use case of configuration management, you wouldn't WANT to use a single global public blockchain. - Peter From bernat at luffy.cx Tue Jan 9 08:11:55 2018 From: bernat at luffy.cx (Vincent Bernat) Date: Tue, 09 Jan 2018 09:11:55 +0100 Subject: MTU to CDN's In-Reply-To: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> (joel jaeggli's message of "Mon, 8 Jan 2018 15:08:51 -0800") References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: ❦ 8 janvier 2018 15:08 -0800, joel jaeggli  : >> N00b here trying to understand why certain CDN's such as Cloudfare have >> issues where my MTU is low. For instance if I am using pptp and the MTU is >> at 1300 it wont work. If I increase to 1478 it may or may not work. > PMTUD has a lot of trouble working reliability when the destination of > the PTB  is a stateless load-balancer. More explanations are available here: https://blog.cloudflare.com/path-mtu-discovery-in-practice/ -- Don't comment bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger) From ramy.ihashish at gmail.com Tue Jan 9 10:13:48 2018 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Tue, 9 Jan 2018 12:13:48 +0200 Subject: Courses/Trainings for NOC leaders Message-ID: Hello there, I am looking for recommendations -preferably based on experience- for training/workshops for NOC engineers that have made significant difference in root cause analysis, analytical thinking, troubleshooting skills and problem solving skills. Thanks, Ramy From ops.lists at gmail.com Tue Jan 9 10:28:31 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 09 Jan 2018 15:58:31 +0530 Subject: Courses/Trainings for NOC leaders In-Reply-To: References: Message-ID: <6A29D4A8-75F0-491A-9EB4-06088B290DF4@gmail.com> These books. https://www.amazon.com/UNIX-Linux-System-Administration-Handbook/dp/0131480057 https://www.amazon.com/Practice-System-Network-Administration-Enterprise/dp/0321919165/ https://www.amazon.com/Practice-Cloud-System-Administration-Practices/dp/032194318X/ https://www.amazon.com/Time-Management-System-Administrators-Working/dp/0596007833/ Lots of SAGE workshops too, but these distil them quite well indeed. --srs On 09/01/18, 3:45 PM, "NANOG on behalf of Ramy Hashish" wrote: Hello there, I am looking for recommendations -preferably based on experience- for training/workshops for NOC engineers that have made significant difference in root cause analysis, analytical thinking, troubleshooting skills and problem solving skills. Thanks, Ramy From EPers at ansencorp.com Tue Jan 9 13:14:10 2018 From: EPers at ansencorp.com (Edwin Pers) Date: Tue, 9 Jan 2018 13:14:10 +0000 Subject: Comparison of freeware open source switch software? In-Reply-To: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> Message-ID: <98aaeca5d18744a698184eaec237f851@ansencorp.com> Here's one you missed: http://www.projectfloodlight.org/indigo/ If you're only interested in stuff that goes on iron, openvswitch is out - it's pure software meant to run on hypervisors -Ed -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Nussbacher Sent: Tuesday, January 9, 2018 2:18 AM To: nanog at nanog.org Subject: Comparison of freeware open source switch software? I have seen numerous comparisons and RIPE presentations on performance issues of BIRD vs Quagga vs FRR. I am looking for the same thing for freeware switch software. Has anyone done a feature comparison between: http://openvswitch.org/ https://www.openswitch.net/ https://cumulusnetworks.com/products/cumulus-linux/ ...any other I am missing... I am familiar with: http://packetpushers.net/open-networking-cheat-sheet/ https://www.networkworld.com/article/2919599/cisco-subnet/clearing-the-fog-around-open-switching-terminology.html so to clarify I am interested only in bare-metal or whitebox swicthes and freeware, open source software. And even better - has anyone done a benchmark to see which performs best? Thanks, Hank From jcurran at arin.net Tue Jan 9 13:29:40 2018 From: jcurran at arin.net (John Curran) Date: Tue, 9 Jan 2018 13:29:40 +0000 Subject: ARIN on the Road events - San Diego (23 Jan) and Albuquerque (25 Jan) Message-ID: <6BE01F54-FE1D-4DC6-B67C-D5E44675385B@arin.net> NANOGers - If you know of anyone who would benefit from learning more about the ARIN registry and related services, feel free to direct them to one of these upcoming "ARIN on the Road” events taking place later this month in San Diego and Albuquerque - registration now open and there is no charge for participation. Thank you! /John John Curran President and CEO American Registry for Internet Numbers (ARIN) === ARIN on the Road: San Diego Tuesday, 23 January 2018 9:30 AM – 3:45 PM PST; Registration and Continental Breakfast at 9:00 AM PST Register at: https://www.arin.net/sandiego ARIN on the Road: Albuquerque Thursday, 25 January 2018 9:30 AM – 3:45 PM MST; Registration and Continental Breakfast at 9:00 AM MST Register at: https://www.arin.net/albuquerque Each one-day event is an opportunity to learn about topics like: • ARIN Technical Services • Policy Development at ARIN • IPv4 Services – Waiting List, Transfers, and more • ARIN Security Services – DNSSEC, RPKI, and more • ARIN Directory Services – RDAP, Whois, Whowas, Data Accuracy • IPv6 Services – Obtaining Resources, Networking Plans • Community Engagement with ARIN Connect with colleagues and ARIN staff. Registration is free and lunch is included! Seating is limited so register today. If you know other individuals whom you feel may benefit from attending these events, please extend this invitation to them as well. Feel free to contact us at meetings at arin.net if you have any questions. === From nanog at ics-il.net Tue Jan 9 13:38:50 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 9 Jan 2018 07:38:50 -0600 (CST) Subject: DSL Operators Mailing List? In-Reply-To: References: <679618541.18697.1515344927188.JavaMail.mhammett@ThunderFuck> <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> Message-ID: <794411794.1289.1515505126551.JavaMail.mhammett@ThunderFuck> Nothing specific at this time, just always on the look out for appropriate venues for discussion. The more generic the question, the more I'd rather lurk to get an answer vs. posting about it and I haven't seen too many (any?) on DSL lately. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Colton Conor" To: "James Bensley" Cc: "Mike Hammett" , "NANOG" Sent: Monday, January 8, 2018 8:24:35 PM Subject: Re: DSL Operators Mailing List? Mike, Lots of people on this list have DSL experience. What are you looking for? On Mon, Jan 8, 2018 at 8:21 AM, James Bensley < jwbensley at gmail.com > wrote: On 7 January 2018 at 17:10, Mike Hammett < nanog at ics-il.net > wrote: > Is there a good mailing list for DSL operators? A cursory search really only came up with DSL Reports, which is far from what I'm looking for. Hi Mike, I only know of the https://puck.nether.net/mailman/listinfo/cisco-bba list. It is Cisco specific list and very low volume (see the archives) however, people might not mind you talking about DSL operations in general as long as it isn't specific to another vendor. Cheers, James. From nanog at ics-il.net Tue Jan 9 13:50:37 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 9 Jan 2018 07:50:37 -0600 (CST) Subject: DSL CPE In-Reply-To: <1305205298.1294.1515505296855.JavaMail.mhammett@ThunderFuck> Message-ID: <1427825328.1322.1515505834972.JavaMail.mhammett@ThunderFuck> After a few off-list responses (and a couple on) encouraging me to use NANOG, here we go... I've recently walked in to a voice\DSL CLEC that has basically been left to entropy for the last ten years. A lot of the core systems just work, but a lot of things aren't exactly managed the best. They run a Calix\Occam ADSL2+\VDSL infrastructure. For those of you doing DSL, what CPE are you using? I'm looking at one that's just a basic modem where I have a more sophisticated router (or ATA\voice gateway) behind it and then one more generic for residential settings with WiFi and all that jazz. We're kinda debating whether we go just dumb Wi-Fi or something more advanced\powerful. I've heard a lot of good about the Calix GigaFamily in that regard. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From lists at snowpondtech.com Tue Jan 9 14:13:12 2018 From: lists at snowpondtech.com (Joshua Zukerman) Date: Tue, 9 Jan 2018 09:13:12 -0500 Subject: DSL CPE In-Reply-To: <1427825328.1322.1515505834972.JavaMail.mhammett@ThunderFuck> References: <1305205298.1294.1515505296855.JavaMail.mhammett@ThunderFuck> <1427825328.1322.1515505834972.JavaMail.mhammett@ThunderFuck> Message-ID: The CLEC that I do some contract work for uses a basic single port ethernet only Comtrend 5072T ADSL2+ modem for all residential customers and business customers who don't have a bonded connection. Very reliable modem. The 5071 had bad powersupplies, but seemed worked better on loops with lousy stats. I think their idea is less tech support calls when a customer complains that they cannot connect a wifi device or doesn't know what the password is. Less things to break or have to maintain. The CLEC tells the customer to buy their own wireless router which 95% of the customers already have or have no issues in buying. For the business customers who have a bonded ADSL2+ connection, they use a Zyxel VMG4325 modem/router/wifi CPE device. It has a lot of configuration options. I'm not sure how reliable they are. I've been on a few trouble calls where I had to replace a questionable modem or the modem didn't like when one of the two bonded loops had issues (modem wouldn't pass upstream traffic instead of just knocking out the bad loop). The CLEC doesn't use PPPoE at all. The LEC in this state (Fairpoint) uses similar hardware. I think Fairpoint has a Comtrend provisioning box to push out the PPPoE settings for Comtrend modems which is really handy for them. Hope this helps in some limited way. Regards, Joshua Zukerman Snow Pond Technology Group Inc. www.snowpondtech.com On Tue, Jan 9, 2018 at 8:50 AM, Mike Hammett wrote: > After a few off-list responses (and a couple on) encouraging me to use > NANOG, here we go... > > > I've recently walked in to a voice\DSL CLEC that has basically been left > to entropy for the last ten years. A lot of the core systems just work, but > a lot of things aren't exactly managed the best. They run a Calix\Occam > ADSL2+\VDSL infrastructure. For those of you doing DSL, what CPE are you > using? I'm looking at one that's just a basic modem where I have a more > sophisticated router (or ATA\voice gateway) behind it and then one more > generic for residential settings with WiFi and all that jazz. We're kinda > debating whether we go just dumb Wi-Fi or something more advanced\powerful. > I've heard a lot of good about the Calix GigaFamily in that regard. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From bryonadams at fastmail.com Tue Jan 9 14:17:16 2018 From: bryonadams at fastmail.com (Bryon Adams) Date: Tue, 09 Jan 2018 09:17:16 -0500 Subject: DSL CPE In-Reply-To: <1427825328.1322.1515505834972.JavaMail.mhammett@ThunderFuck> References: <1427825328.1322.1515505834972.JavaMail.mhammett@ThunderFuck> Message-ID: <6AFE5B89-15AB-4C21-8099-A07A1118FEE1@fastmail.com> We're using Visionnet m505+. They seem to do well enough for our users. Our DSL footprint more rural than not and a few have needed range extenders for larger houses as these only have N wireless. I can get pretty much any stats I need from them by logging in and poking around the statistics pages except for how often the modem is resynchronizing with our Calix. I can get that stat from the Calix shelf though or make a rough guess based on an internal tool we made. I have no complaints with the modem. If you get a lot of calls from people with security cameras that use internal/external IPs and port forwarding you may have some trouble, I haven't been able to figure out how to make it do a hairpin gracefully. On January 9, 2018 8:50:37 AM EST, Mike Hammett wrote: >After a few off-list responses (and a couple on) encouraging me to use >NANOG, here we go... > > >I've recently walked in to a voice\DSL CLEC that has basically been >left to entropy for the last ten years. A lot of the core systems just >work, but a lot of things aren't exactly managed the best. They run a >Calix\Occam ADSL2+\VDSL infrastructure. For those of you doing DSL, >what CPE are you using? I'm looking at one that's just a basic modem >where I have a more sophisticated router (or ATA\voice gateway) behind >it and then one more generic for residential settings with WiFi and all >that jazz. We're kinda debating whether we go just dumb Wi-Fi or >something more advanced\powerful. I've heard a lot of good about the >Calix GigaFamily in that regard. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com From shawnl at up.net Tue Jan 9 14:22:07 2018 From: shawnl at up.net (Shawn L) Date: Tue, 9 Jan 2018 09:22:07 -0500 (EST) Subject: DSL CPE In-Reply-To: <1427825328.1322.1515505834972.JavaMail.mhammett@ThunderFuck> References: <1427825328.1322.1515505834972.JavaMail.mhammett@ThunderFuck> Message-ID: <1515507727.403514769@upnet.mymailsrvr.com> At $dayjob we use both Comtrend and Zyxel modems. Both have a 1-port modem that can be deployed in bridged mode. They both seem to work well with Calix gear. We've found the Zyxel modems tend to work a little better at longer loop lengths. But, for us at least, it's very easy to get custom firmware created and pre-deployed to comtrend modems at the factory / distributor. So we haven't completely decided between one brand and the other. We started looking at Zyxel for increased speed at longer loop lengths and better wifi support. There's a company a few exchanges over from us that has deployed the caix giga family and really likes it. We haven't deployed them yet because they only work on the Calix E7 series (E7-2 and E7-20) and we still have a lot of C7 series dslams in the network. Shawn -----Original Message----- From: "Mike Hammett" Sent: Tuesday, January 9, 2018 8:50am To: "NANOG" Subject: DSL CPE After a few off-list responses (and a couple on) encouraging me to use NANOG, here we go... I've recently walked in to a voice\DSL CLEC that has basically been left to entropy for the last ten years. A lot of the core systems just work, but a lot of things aren't exactly managed the best. They run a Calix\Occam ADSL2+\VDSL infrastructure. For those of you doing DSL, what CPE are you using? I'm looking at one that's just a basic modem where I have a more sophisticated router (or ATA\voice gateway) behind it and then one more generic for residential settings with WiFi and all that jazz. We're kinda debating whether we go just dumb Wi-Fi or something more advanced\powerful. I've heard a lot of good about the Calix GigaFamily in that regard. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From morrowc.lists at gmail.com Tue Jan 9 14:58:43 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 9 Jan 2018 09:58:43 -0500 Subject: Blockchain and Networking In-Reply-To: References: <20180109031925.2CC1818EC6E9@ary.local> Message-ID: (watching this thread and wondering..) On Tue, Jan 9, 2018 at 2:39 AM, Peter Kristolaitis wrote: > On 2018-01-08 10:19 PM, John Levine wrote: > >> In article <0c45eee2-ffcb-2066-1456-eb2d38075007 at alter3d.ca>, >> Peter Kristolaitis wrote: >> >>> We can build all of the above in other ways today, of course. But >>> there's certainly something to be said for a vendor-supported solution >>> that is inherent in the platform and requires no additional >>> infrastructure. ... >>> >> No additional infrastructure? Blockchains need multiple devices that >> are online and have enough storage to keep a full copy of the chain. >> > There is absolutely no reason that the networking equipment itself can't > both operate the blockchain and keep a full copy. It's a pretty good bet > that your own routers will probably be online; if not, you have bigger > problems. > > I don't know that offloading computation on already busy network devices is a win for the rest of the network though. I don't know that you want to depend on local storage on devices which could be thousands of miles away from the people who can replace the hdd/ssd/storage-item.. especially when that storage is critical to the operations of the device. It turns out it's both expensive in time and pesos to fly someone into west-africa/east-asia/china/texas to repair a device in an emergency (unplanned work). The storage requirements aren't particularly onerous. The entire Bitcoin > blockchain is around 150GB, with several orders of magnitude more > transactions (read: config changes) than you're likely to see even on a > very large network. SSDs are small enough and reliable enough now that the > physical space requirements are quite small. > > I really don't think storage is the only problem here, and 'aren't particularly onerous' overlooks a whole host of actual problems in operations with blockchains... which just using git/sccs/cvs/etc fixes for your standard configuration management concerns. All of the git/sccs/cvs/etc avoid 'lots of storage necessary on remote devices' and 'lots of compute required on remote deices'. > They make sense in an environment with multiple sophisticated parties >> that sort of but not entirely trust each other, but there aren't as >> many of those as you might think. >> > You (presumably) trust your own routers. There is absolutely no reason > that your own little network can't run your own private blockchain. In > fact, for my use case of configuration management, you wouldn't WANT to use > a single global public blockchain. > > someone 12 messages back asked: "why is this better/different/etc from just using git/sccs/cvs/etc for configuration management/revision-control?" I've not seen that answered, except by the speculative: "well, it's a cool buzzword" comment. > - Peter > From hugo at slabnet.com Tue Jan 9 15:16:09 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 9 Jan 2018 07:16:09 -0800 Subject: Blockchain and Networking In-Reply-To: References: <20180109031925.2CC1818EC6E9@ary.local> Message-ID: <20180109151609.GC25899@bamboo.slabnet.com> A slightly more pessimistic view: https://hackernoon.com/ten-years-in-nobody-has-come-up-with-a-use-case-for-blockchain-ee98c180100 -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From hugo at slabnet.com Tue Jan 9 15:24:43 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 9 Jan 2018 07:24:43 -0800 Subject: Any experience with FS hardware out there? In-Reply-To: References: <25cd9ad3-fdb2-eb4c-5f3e-2a4aa9cde769@shout.net> <20180105191926.GB25899@bamboo.slabnet.com> Message-ID: <20180109152443.GC532@bamboo.slabnet.com> Largely from web searches, the price seemed to shake out around there. This wasn't from wholesale / direct Edge-Core pricing. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Mon 2018-Jan-08 20:30:01 -0600, Colton Conor wrote: >Where do you get wholesale pricing from Edgecore? Simple google searches >only bring up >https://bm-switch.com/index.php/edge-core-as7712-32x-100g-bm-switch-preloaded-with-onie.html > > >On Fri, Jan 5, 2018 at 1:19 PM, Hugo Slabbert wrote: > >> >> On Fri 2018-Jan-05 12:50:42 -0600, Bryan Holloway wrote: >> >> Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm >>> curious if anyone in the community has any thoughts or real-life world >>> experience with them. >>> >>> E.g.: https://www.fs.com/products/69340.html >>> >>> For the price point, it's almost in the "too good to be true" category. >>> >> >> The price is on par with the hardware cost of other whitebox Tomahawks, >> e.g. Edge-Core 32x100G models like the AS7712 or AS7716 that also runs the >> BCM56960, so the primary distinction seems to be that you get a NOS >> included in that price. I have zero experience with Broadcom's ICOS as >> opposed to the other options on the market, so it seems to be a question of >> whether you're happy with that or would be e.g. paying Cumulus or $vendor a >> few K USD for a license for their NOS on it. >> >> >> Naturally it claims to support an impressive range of features including >>> BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah. >>> >>> There was an earlier discussion about packet buffer issues, but, assuming >>> for a second that it's not an issue, can anyone say they've used these >>> and/or the L2/L3 features that they purportedly support? >>> >>> Thanks! >>> - bryan >>> >>> >> -- >> Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com >> pgp key: B178313E | also on Signal >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From SNaslund at medline.com Tue Jan 9 15:31:03 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 9 Jan 2018 15:31:03 +0000 Subject: Blockchain and Networking In-Reply-To: References: <20180109031925.2CC1818EC6E9@ary.local> Message-ID: <9578293AE169674F9A048B2BC9A081B4028C2FA9AF@WAUPRDMBXP1.medline.com> Sure but there are lots of blockchains other than bitcoin. A lot of real smart people do not even suspect that bitcoin is a long term survivor due to its long transaction times. Which blockchains do you want to support? 150GB may not seem like a lot (although a lot of my gear does not have the memory to cache that) but 10 of those is beyond the memory on the vast majority of network gear I am aware of. That sure looks like a slippery slope to me. Now that a lot of network switching and routers can support applications, you could just host all of your apps on them just like you could do all of your routing in your servers. The question for you is what responsibilities do you want to take on. That probably depends on what business you are in. >There is absolutely no reason that the networking equipment itself can't both operate the blockchain and keep a full copy.  It's a pretty good bet that your own routers will probably be online;  if not, you have bigger problems. > >The storage requirements aren't particularly onerous.  The entire Bitcoin blockchain is around 150GB, with several orders of magnitude more transactions (read: config changes) than you're likely to see even on a very large network.  SSDs are small >enough and reliable enough now that the physical space requirements are quite small. Steven Naslund Chicago IL From hugo at slabnet.com Tue Jan 9 15:49:05 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 9 Jan 2018 07:49:05 -0800 Subject: Comparison of freeware open source switch software? In-Reply-To: <98aaeca5d18744a698184eaec237f851@ansencorp.com> References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> <98aaeca5d18744a698184eaec237f851@ansencorp.com> Message-ID: <20180109154905.GD25899@bamboo.slabnet.com> Just a note that Cumulus is disaggregated and built on FOSS, but it is not free (costs dollars). Some of the below lifted from http://packetpushers.net/virtual-toolbox/list-network-operating-systems/ Other somewhat free options, some user assembly required at times: https://snaproute.com/ https://azure.github.io/SONiC/ http://opennetlinux.org/ https://github.com/facebook/fboss Others that play in this space while not necessarily free: http://www.pica8.com/products/picos https://www.ipinfusion.com/products/ocnos/ -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Tue 2018-Jan-09 13:14:10 +0000, Edwin Pers wrote: >Here's one you missed: >http://www.projectfloodlight.org/indigo/ > >If you're only interested in stuff that goes on iron, openvswitch is out - it's pure software meant to run on hypervisors > >-Ed > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Nussbacher >Sent: Tuesday, January 9, 2018 2:18 AM >To: nanog at nanog.org >Subject: Comparison of freeware open source switch software? > >I have seen numerous comparisons and RIPE presentations on performance issues of BIRD vs Quagga vs FRR. > >I am looking for the same thing for freeware switch software. >Has anyone done a feature comparison between: >http://openvswitch.org/ >https://www.openswitch.net/ >https://cumulusnetworks.com/products/cumulus-linux/ >...any other I am missing... > >I am familiar with: >http://packetpushers.net/open-networking-cheat-sheet/ >https://www.networkworld.com/article/2919599/cisco-subnet/clearing-the-fog-around-open-switching-terminology.html >so to clarify I am interested only in bare-metal or whitebox swicthes and freeware, open source software. > >And even better - has anyone done a benchmark to see which performs best? > >Thanks, >Hank > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From jean at ddostest.me Tue Jan 9 15:49:52 2018 From: jean at ddostest.me (Jean | ddostest.me) Date: Tue, 9 Jan 2018 10:49:52 -0500 Subject: Blockchain and Networking In-Reply-To: <9578293AE169674F9A048B2BC9A081B4028C2FA9AF@WAUPRDMBXP1.medline.com> References: <20180109031925.2CC1818EC6E9@ary.local> <9578293AE169674F9A048B2BC9A081B4028C2FA9AF@WAUPRDMBXP1.medline.com> Message-ID: <8caa1501-697b-7a61-4e67-d1ba9d9d64a0@ddostest.me> BTC miners use asics. Big switches/routers use 100Gb asics. Some switches have multiple 100 Gb asics and sometimes only half is use or even less. I guess it could be nice for some smaller telcos to generate some profit during off peak period. I don't know how feasible and I fully understand that the vendor warranty should be instantly void. Also, sometimes telcos have off the shelves spare that gather dust for years... It could be interesting to also generate few coins. Jean On 18-01-09 10:31 AM, Naslund, Steve wrote: > Sure but there are lots of blockchains other than bitcoin. A lot of real smart people do not even suspect that bitcoin is a long term survivor due to its long transaction times. Which blockchains do you want to support? 150GB may not seem like a lot (although a lot of my gear does not have the memory to cache that) but 10 of those is beyond the memory on the vast majority of network gear I am aware of. That sure looks like a slippery slope to me. Now that a lot of network switching and routers can support applications, you could just host all of your apps on them just like you could do all of your routing in your servers. The question for you is what responsibilities do you want to take on. That probably depends on what business you are in. > >> There is absolutely no reason that the networking equipment itself can't both operate the blockchain and keep a full copy.  It's a pretty good bet that your own routers will probably be online;  if not, you have bigger problems. >> >> The storage requirements aren't particularly onerous.  The entire Bitcoin blockchain is around 150GB, with several orders of magnitude more transactions (read: config changes) than you're likely to see even on a very large network.  SSDs are small >enough and reliable enough now that the physical space requirements are quite small. > > Steven Naslund > Chicago IL > From michael at wi-fiber.io Tue Jan 9 16:02:59 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 9 Jan 2018 09:02:59 -0700 Subject: Blockchain and Networking In-Reply-To: <8caa1501-697b-7a61-4e67-d1ba9d9d64a0@ddostest.me> References: <20180109031925.2CC1818EC6E9@ary.local> <9578293AE169674F9A048B2BC9A081B4028C2FA9AF@WAUPRDMBXP1.medline.com> <8caa1501-697b-7a61-4e67-d1ba9d9d64a0@ddostest.me> Message-ID: The definition of an ASIC is that it has only one use. Just because half of a 100gb switch is not in use doesn't mean that you can mine bitcoin, or run a blockchain with the asics not in use.. On 9 January 2018 at 08:49, Jean | ddostest.me via NANOG wrote: > BTC miners use asics. Big switches/routers use 100Gb asics. Some > switches have multiple 100 Gb asics and sometimes only half is use or > even less. > > I guess it could be nice for some smaller telcos to generate some profit > during off peak period. I don't know how feasible and I fully understand > that the vendor warranty should be instantly void. > > Also, sometimes telcos have off the shelves spare that gather dust for > years... It could be interesting to also generate few coins. > > Jean > > On 18-01-09 10:31 AM, Naslund, Steve wrote: > > Sure but there are lots of blockchains other than bitcoin. A lot of > real smart people do not even suspect that bitcoin is a long term survivor > due to its long transaction times. Which blockchains do you want to > support? 150GB may not seem like a lot (although a lot of my gear does not > have the memory to cache that) but 10 of those is beyond the memory on the > vast majority of network gear I am aware of. That sure looks like a > slippery slope to me. Now that a lot of network switching and routers can > support applications, you could just host all of your apps on them just > like you could do all of your routing in your servers. The question for > you is what responsibilities do you want to take on. That probably > depends on what business you are in. > > > >> There is absolutely no reason that the networking equipment itself > can't both operate the blockchain and keep a full copy. It's a pretty good > bet that your own routers will probably be online; if not, you have bigger > problems. > >> > >> The storage requirements aren't particularly onerous. The entire > Bitcoin blockchain is around 150GB, with several orders of magnitude more > transactions (read: config changes) than you're likely to see even on a > very large network. SSDs are small >enough and reliable enough now that > the physical space requirements are quite small. > > > > Steven Naslund > > Chicago IL > > > From Brian at ampr.org Tue Jan 9 16:04:24 2018 From: Brian at ampr.org (Brian Kantor) Date: Tue, 9 Jan 2018 08:04:24 -0800 Subject: Blockchain and Networking In-Reply-To: <8caa1501-697b-7a61-4e67-d1ba9d9d64a0@ddostest.me> References: <20180109031925.2CC1818EC6E9@ary.local> <9578293AE169674F9A048B2BC9A081B4028C2FA9AF@WAUPRDMBXP1.medline.com> <8caa1501-697b-7a61-4e67-d1ba9d9d64a0@ddostest.me> Message-ID: <20180109160424.GA21538@meow.BKantor.net> It seems to me that at the current moment in the evolution of bitcoin, the only way to make money from it is to sell the equipment to mine coins, as the chances of ever making any money from mining coins yourself are vanishingly small. And then only if you get your electricity and cooling for free. It has been estimated that the amount of electricity being consumed worldwide in the attempt to mine bitcoins exceeds the consumption of several smaller European countries. Since little of this power is generated from renewable sources, it could represent a significant consumption of fossil fuels. - Brian On Tue, Jan 09, 2018 at 10:49:52AM -0500, Jean | ddostest.me via NANOG wrote: > BTC miners use asics. Big switches/routers use 100Gb asics. Some > switches have multiple 100 Gb asics and sometimes only half is use or > even less. > > I guess it could be nice for some smaller telcos to generate some profit > during off peak period. I don't know how feasible and I fully understand > that the vendor warranty should be instantly void. > > Also, sometimes telcos have off the shelves spare that gather dust for > years... It could be interesting to also generate few coins. > > Jean From ray at oneunified.net Tue Jan 9 16:12:16 2018 From: ray at oneunified.net (Raymond Burkholder) Date: Tue, 9 Jan 2018 12:12:16 -0400 Subject: Comparison of freeware open source switch software? In-Reply-To: <98aaeca5d18744a698184eaec237f851@ansencorp.com> References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> <98aaeca5d18744a698184eaec237f851@ansencorp.com> Message-ID: <391901d38964$9edd8950$dc989bf0$@oneunified.net> > > If you're only interested in stuff that goes on iron, openvswitch is out - it's > pure software meant to run on hypervisors > Not necessarily true anymore. Look for SwitchDev, which is incorporated into the Linux kernel , is undergoing continuous improvement, and allows the kernel to offload forwarding rules to the hardware. This allows open source software like Open vSwitch and Free Range Routing to work natively/directly with hardware. http://www.mellanox.com/page/press_release_item?id=1983 https://www.kernel.org/doc/Documentation/networking/switchdev.txt https://blog.raymond.burkholder.net/ Raymond Burkholder. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From 7riw77 at gmail.com Tue Jan 9 16:18:53 2018 From: 7riw77 at gmail.com (7riw77 at gmail.com) Date: Tue, 9 Jan 2018 11:18:53 -0500 Subject: Comparison of freeware open source switch software? In-Reply-To: <391901d38964$9edd8950$dc989bf0$@oneunified.net> References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> <98aaeca5d18744a698184eaec237f851@ansencorp.com> <391901d38964$9edd8950$dc989bf0$@oneunified.net> Message-ID: <056801d38965$8af0b790$a0d226b0$@gmail.com> > > If you're only interested in stuff that goes on iron, openvswitch is > > out - it's pure software meant to run on hypervisors > > Not necessarily true anymore. Look for SwitchDev, which is incorporated into > the Linux kernel , is undergoing continuous improvement, and allows the kernel > to offload forwarding rules to the hardware. The overall architecture of openswitch, however, seems (to me) to be focused on software implementations, rather than hardware. You probably want to look at SONiC as well, as this is what LinkedIn is using; there are a lot of improvements currently going into code. For FR Routing, the performance is changing rapidly, as there are a lot of commits going in just about every week, and the community is quite active. :-) /r http://rule11.tech From bill at herrin.us Tue Jan 9 16:22:22 2018 From: bill at herrin.us (William Herrin) Date: Tue, 9 Jan 2018 11:22:22 -0500 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine wrote: > How about validating whether a given AS is an acceptable origin for a set >> of prefixes? > > That's a job for ordinary PKI. Any time you have a trusted central authority to serve as an anchor, ordinary PKI works fine. The RIRs serve as anchors for who has the right to authorize which prefixes. A harder task is validating whether your peer is part of a legitimate AS path to that origin. It's not obvious to me that blockchain could help solve that problem, but it's at least a problem that isn't solved by ordinary PKI. Now, if we wanted to replace the RIRs and allow people to self-assign IPv6 addresses out of ULA space which we'd then honor in the global BGP table, blockchain could have a role. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From jk at ip-clear.de Tue Jan 9 16:33:15 2018 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Tue, 09 Jan 2018 17:33:15 +0100 Subject: Blockchain and Networking In-Reply-To: <9578293AE169674F9A048B2BC9A081B4028C2FA9AF@WAUPRDMBXP1.medline.com> References: <20180109031925.2CC1818EC6E9@ary.local> <9578293AE169674F9A048B2BC9A081B4028C2FA9AF@WAUPRDMBXP1.medline.com> Message-ID: New devices like the former Brocade SLX even has its own hypervisor on x86-intel and runs an Ubuntu VM for management and monitoring. You can even install your own things, therefore new applications and purposes will rise in the future. I also believe that dockerization will come to the networks and we will handle routing protocols more like containers that will be linked to the host-os, adding reseller and namespace capabilities and so on. There will be room for blockchain typeof-handlers that does not need to be a "full node" or a "miner". It could just be a "wallet"-type, that is linked to companies-internal-"light" nodes, to exchanges or registries or $y for purposes, that we might not even think of right now or still need to write PoC for (remind me in $x years). Jörg On 9 Jan 2018, at 16:31, Naslund, Steve wrote: > Sure but there are lots of blockchains other than bitcoin. A lot of > real smart people do not even suspect that bitcoin is a long term > survivor due to its long transaction times. Which blockchains do you > want to support? 150GB may not seem like a lot (although a lot of my > gear does not have the memory to cache that) but 10 of those is beyond > the memory on the vast majority of network gear I am aware of. That > sure looks like a slippery slope to me. Now that a lot of network > switching and routers can support applications, you could just host > all of your apps on them just like you could do all of your routing in > your servers. The question for you is what responsibilities do you > want to take on. That probably depends on what business you are in. > >> There is absolutely no reason that the networking equipment itself >> can't both operate the blockchain and keep a full copy.  It's a >> pretty good bet that your own routers will probably be online;  if >> not, you have bigger problems. >> >> The storage requirements aren't particularly onerous.  The entire >> Bitcoin blockchain is around 150GB, with several orders of magnitude >> more transactions (read: config changes) than you're likely to see >> even on a very large network.  SSDs are small >enough and reliable >> enough now that the physical space requirements are quite small. > > Steven Naslund > Chicago IL From morrowc.lists at gmail.com Tue Jan 9 16:34:53 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 9 Jan 2018 11:34:53 -0500 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: On Tue, Jan 9, 2018 at 11:22 AM, William Herrin wrote: > On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine wrote: > > > How about validating whether a given AS is an acceptable origin for a set > >> of prefixes? > > > > > That's a job for ordinary PKI. Any time you have a trusted central > in particular RPKI -> https://tools.ietf.org/html/rfc6810 > authority to serve as an anchor, ordinary PKI works fine. The RIRs serve as > anchors for who has the right to authorize which prefixes. > > A harder task is validating whether your peer is part of a legitimate AS > path to that origin. It's not obvious to me that blockchain could help > solve that problem, but it's at least a problem that isn't solved by > ordinary PKI. > > this part of the problem is BGPsec -> https://tools.ietf.org/html/rfc8205 > > Now, if we wanted to replace the RIRs and allow people to self-assign IPv6 > addresses out of ULA space which we'd then honor in the global BGP table, > blockchain could have a role. > > yes, here's a useful use for blockchains... allocation of random numbers, and logging of same in a globally available fashion. > -Bill > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From ray at oneunified.net Tue Jan 9 16:52:07 2018 From: ray at oneunified.net (Raymond Burkholder) Date: Tue, 9 Jan 2018 12:52:07 -0400 Subject: Comparison of freeware open source switch software? In-Reply-To: <056801d38965$8af0b790$a0d226b0$@gmail.com> References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> <98aaeca5d18744a698184eaec237f851@ansencorp.com> <391901d38964$9edd8950$dc989bf0$@oneunified.net> <056801d38965$8af0b790$a0d226b0$@gmail.com> Message-ID: <392f01d3896a$3021da60$90658f20$@oneunified.net> > > Not necessarily true anymore. Look for SwitchDev, which is > > incorporated into the Linux kernel , is undergoing continuous > > improvement, and allows the kernel to offload forwarding rules to the > hardware. > > The overall architecture of openswitch, however, seems (to me) to be > focused on software implementations, rather than hardware. I suppose that could be a fair statement, to a certain degree. But when you strip away all the abstracted things it does, and get into the core of the product, you find an OpenFlow engine, which at the heart, is a mechanism for defining traffic rules. Many of those rules translate easily into the kernel's forwarding information base. And the kernel's FIB can easily be two-way sync'd with hardware. So, to take this to the logical conclusion, other than for the interesting rules which can be created in OVS or FRR, it is possible to do away with OVS/FRR, and use only Linux itself with iproute2 and bridge commands to drive the hardware directly with no further abstraction or vendor black boxes. And, rather than using a J or a C syntax, you use an /etc/network/interfaces syntax for permanence. https://blog.raymond.burkholder.net/ Raymond Burkholder -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From EPers at ansencorp.com Tue Jan 9 18:29:35 2018 From: EPers at ansencorp.com (Edwin Pers) Date: Tue, 9 Jan 2018 18:29:35 +0000 Subject: Comparison of freeware open source switch software? In-Reply-To: <391901d38964$9edd8950$dc989bf0$@oneunified.net> References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> <98aaeca5d18744a698184eaec237f851@ansencorp.com> <391901d38964$9edd8950$dc989bf0$@oneunified.net> Message-ID: <99a8133480eb43f3954bf2f640dab636@ansencorp.com> > SwitchDev, which is incorporated into the Linux kernel Neat! I'll have to keep my eyes on this in the future, it'd be cool if we could have VyOS handling routing on the hardware and the vm hosts, would save me a bit of brainpower -Ed -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Raymond Burkholder Sent: Tuesday, January 9, 2018 11:12 AM To: nanog at nanog.org Subject: RE: Comparison of freeware open source switch software? From rvandolson at esri.com Tue Jan 9 18:57:49 2018 From: rvandolson at esri.com (Ray Van Dolson) Date: Tue, 9 Jan 2018 10:57:49 -0800 Subject: GTV-ETH-2-COAX - Is this HomePNA? Message-ID: <20180109185749.GA15466@esri.com> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amazon.com_GefenTV-2DEthernet-2DExtender-2DDiscontinued-2DManufacturer_dp_B0013LYMQ8&d=DwIBAg&c=n6-cguzQvX_tUIrZOS_4Og&r=r4NBNYp4yEcJxC11Po5I-w&m=MLZzcgCKfcPGBwKCi3lSUygoJ78g6KFaevQZoryCq9s&s=HwKmGRftJEcyn2of9m9-zXwj2WV33LsB0QM-dB4cgWU&e= Looking at doing a one-off extension over RG6 and have these devices in hand. Anyone know if they're HPNA? Manual I have found doesn't specify, but frequency ranges don't appear to be MoCA (but also don't appear to be HPNA 1.3). Comparing to these: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amazon.com_TRENDnet-2DMid-2DBand-2DTransmission-2DDistances-2DTPA-2D311_dp_B00684E0UI&d=DwIBAg&c=n6-cguzQvX_tUIrZOS_4Og&r=r4NBNYp4yEcJxC11Po5I-w&m=MLZzcgCKfcPGBwKCi3lSUygoJ78g6KFaevQZoryCq9s&s=yQVnjc4gedaqBM_23_96Q5brEIPekkOjPUE6GRQDT8s&e= Ray From rvandolson at esri.com Tue Jan 9 21:10:17 2018 From: rvandolson at esri.com (Ray Van Dolson) Date: Tue, 9 Jan 2018 13:10:17 -0800 Subject: GTV-ETH-2-COAX - Is this HomePNA? In-Reply-To: <20180109185749.GA15466@esri.com> References: <20180109185749.GA15466@esri.com> Message-ID: <20180109211017.GA17562@esri.com> On Tue, Jan 09, 2018 at 10:57:49AM -0800, Ray Van Dolson wrote: > Looking at doing a one-off extension over RG6 and have these devices in > hand. Anyone know if they're HPNA? Manual I have found doesn't > specify, but frequency ranges don't appear to be MoCA (but also don't > appear to be HPNA 1.3). > > Comparing to these: > > Ray Apologies for the corporatized email links. Stumbled across the manual for this device and appears to be UPA DHS based (Powerline -- extended to work over coax). Ray From jfbeam at gmail.com Tue Jan 9 23:09:49 2018 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 09 Jan 2018 18:09:49 -0500 Subject: Comparison of freeware open source switch software? In-Reply-To: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> Message-ID: On Tue, 09 Jan 2018 02:17:59 -0500, Hank Nussbacher wrote: > so to clarify I am interested only in bare-metal or whitebox swicthes > and freeware, open source software. It's my understanding that there simply is no such thing. Because none of the HARDWARE has open source code. Sure, anyone can write software to spirit packets between NICs (linux and *BSD has had that capability for decades.) But doing that "at scale" with the various manufacturers SoCs requires vendor specific code to setup and control the chip. The broadcom "NDK" is just a shim on top of a pre-compiled proprietary SDK blob. --Ricky From oliver.oboyle at gmail.com Wed Jan 10 02:23:29 2018 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Tue, 9 Jan 2018 21:23:29 -0500 Subject: Comparison of freeware open source switch software? In-Reply-To: References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> Message-ID: https://www.opennetworking.org/ Hardware works quite well. I have a number of whitebox units deployed based off their designs and will be ordering more. On Tue, Jan 9, 2018 at 6:09 PM, Ricky Beam wrote: > On Tue, 09 Jan 2018 02:17:59 -0500, Hank Nussbacher > wrote: > >> so to clarify I am interested only in bare-metal or whitebox swicthes >> and freeware, open source software. >> > > It's my understanding that there simply is no such thing. Because none of > the HARDWARE has open source code. Sure, anyone can write software to > spirit packets between NICs (linux and *BSD has had that capability for > decades.) But doing that "at scale" with the various manufacturers SoCs > requires vendor specific code to setup and control the chip. The broadcom > "NDK" is just a shim on top of a pre-compiled proprietary SDK blob. > > --Ricky > -- :o@> From khomyakov.andrey at gmail.com Wed Jan 10 02:46:32 2018 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Tue, 9 Jan 2018 18:46:32 -0800 Subject: Comparison of freeware open source switch software? In-Reply-To: References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> Message-ID: My understanding is the same as Ricky's. At least in the Broadcom word, you have to license the SDK from Broadcom in order to develop against it and, more importantly, have documentation of which register does what. I don't know if you need to license it to program the ASIC (assuming you can do it without SDK in a sensible fashion). My understanding was that when you buy software such as Cumulus Linux, what you are actually paying for is the Broadcom license. You can actually go and download Cumulus Linux and it's all open source except, you guessed it, switchd, which is what takes the info from the linux kernel and programs it into the hardware. My understanding was that the rest the "open source" OSs operate the same way. Please, correct me if it is at all possible to buy a whitebox switch and then load a "no cost OS" on it and it starts switching packets through hardware. -Andrey --Andrey On Tue, Jan 9, 2018 at 6:23 PM, Oliver O'Boyle wrote: > https://www.opennetworking.org/ > > Hardware works quite well. I have a number of whitebox units deployed based > off their designs and will be ordering more. > > On Tue, Jan 9, 2018 at 6:09 PM, Ricky Beam wrote: > > > On Tue, 09 Jan 2018 02:17:59 -0500, Hank Nussbacher < > hank at efes.iucc.ac.il> > > wrote: > > > >> so to clarify I am interested only in bare-metal or whitebox swicthes > >> and freeware, open source software. > >> > > > > It's my understanding that there simply is no such thing. Because none of > > the HARDWARE has open source code. Sure, anyone can write software to > > spirit packets between NICs (linux and *BSD has had that capability for > > decades.) But doing that "at scale" with the various manufacturers SoCs > > requires vendor specific code to setup and control the chip. The broadcom > > "NDK" is just a shim on top of a pre-compiled proprietary SDK blob. > > > > --Ricky > > > > > > -- > :o@> > From ray at oneunified.net Wed Jan 10 05:06:20 2018 From: ray at oneunified.net (Raymond Burkholder) Date: Wed, 10 Jan 2018 01:06:20 -0400 Subject: Comparison of freeware open source switch software? In-Reply-To: References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> Message-ID: <125cd73a-d5a3-de6d-cc2a-2990c9f6e8f3@oneunified.net> On 01/09/2018 10:46 PM, Andrey Khomyakov wrote: > My understanding was that when you buy software such as Cumulus Linux, what > you are actually paying for is the Broadcom license. You can actually go > and download Cumulus Linux and it's all open source except, you guessed it, > switchd, which is what takes the info from the linux kernel and programs it > into the hardware. I believe that is Cumulus' business model where they ride the requirement for the Broadcom license. So part of the license fee is for Broadcom and part is for Cumulus. Cumulus has used their licensing fees to develop and maintain tooling for their ecosystem. In that process, they have released many of their tools to the opensource world. Things like ifupdown2 and Free Range Routing are a result of that model. > > My understanding was that the rest the "open source" OSs operate the same > way. Pica8 does something similar. > > Please, correct me if it is at all possible to buy a whitebox switch and > then load a "no cost OS" on it and it starts switching packets through > hardware. The only case in which I know that you can purchase a bare metal switch and put a 'no cost OS' such as Linux on is Mellanox. They are the ones who have developed the switchdev module I mentioned in an earlier post. There is _no_ requirement for a black box module to interface between the software and the hardware. That whole path down to but not including the hardware is opensource. There is a large carrier who is making use of switchdev: https://lwn.net/Articles/675826/ >>>> so to clarify I am interested only in bare-metal or whitebox switches >>>> and freeware, open source software. There is something else called SAI, which may do something similar to switchdev: http://packetpushers.net/sai-and-switchdev-need-to-succeed/ >>>> >>> >>> It's my understanding that there simply is no such thing. Because none of >>> the HARDWARE has open source code. Sure, anyone can write software to >>> spirit packets between NICs (linux and *BSD has had that capability for >>> decades.) But doing that "at scale" with the various manufacturers SoCs >>> requires vendor specific code to setup and control the chip. The broadcom >>> "NDK" is just a shim on top of a pre-compiled proprietary SDK blob. As mentioned above, and in another message, Mellanox is the only one, that I know of, for providing a mechanism to drive the hardware (both switch and network cards) from the OS, without a pre-compiled proprietary SDK blob (black box). http://www.mellanox.com/related-docs/prod_switch_software/PB_Spectrum_Linux_Switch.pdf Disclaimer: I not affiliated with Mellanox, only a customer. -- Raymond Burkholder ray at oneunified.net https://blog.raymond.burkholder.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From Jacques.Latour at cira.ca Wed Jan 10 16:15:53 2018 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Wed, 10 Jan 2018 16:15:53 +0000 Subject: ICANN 61 San Juan - TechDay Call for Presentations Message-ID: Call for Presentations TechDay at ICANN 61 in San Juan, PR The ICANN Tech Working Group is again planning a technical workshop at the ICANN 61 meeting on Monday 2018-03-12 in San Juan, Puerto Rico. The TechDay workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss technical topics related to registry and DNS work and security. We are specially interested in: 1. Continuity of Operations Preparedness and Mitigation 2. In addition, we welcome suggestions for additional topics, such as; * Registry security, services and systems * DNS & anycast security, services and systems * Big Data & associated data analysis * IETF DNS protocol updates (Privacy, Encryption) * (Recent) DDOS Attacks and Mitigation If you are interested in presenting, please email ccNSO-techday at icann.org We hope that you can join us and request that you disseminate this Request to other lists where it might of interest. Jacques Regards, On behalf of the TechDay Planning Committee From sean at donelan.com Wed Jan 10 16:33:17 2018 From: sean at donelan.com (Sean Donelan) Date: Wed, 10 Jan 2018 11:33:17 -0500 (EST) Subject: GAO Report: FCC Should Improve Monitoring of Industry Efforts to Strengthen Wireless Network Resiliency Message-ID: https://www.gao.gov/products/gao-18-198 FCC Should Improve Monitoring of Industry Efforts to Strengthen Wireless Network Resiliency What GAO Found The number of wireless outages attributed to a physical incident—a natural disaster, accident, or other manmade event, such as vandalism—increased from 2009 to 2016, as reported to the Federal Communications Commission (FCC). During this time, the number of outages substantially increased from 189 to 1,079 outages, with most of the increase occurring from 2009 to 2011. FCC officials said this increase was due in part to growth in wireless customers and wireless infrastructure. Almost all outages attributed to a physical incident were due to an accident, such as damage to a cable due to a digging error (74 percent) or a natural disaster (25 percent). However, outages due to a natural disaster had a longer median duration (ranging from 19 to 36 hours), which was more than twice as long as outages caused by an accident. Power failures and failures in other providers' networks also play a role in wireless outages attributed to physical incidents. For instance, carriers reported that 87 percent of wireless outages attributed to a physical incident were due to a failure in another provider's network on which they rely. From fhr at fhrnet.eu Wed Jan 10 22:54:14 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Wed, 10 Jan 2018 22:54:14 +0000 Subject: Blockchain and Networking In-Reply-To: References: <20180109031925.2CC1818EC6E9@ary.local> <9578293AE169674F9A048B2BC9A081B4028C2FA9AF@WAUPRDMBXP1.medline.com> <8caa1501-697b-7a61-4e67-d1ba9d9d64a0@ddostest.me> Message-ID: <01020160e247f32f-ce0052ea-773a-4863-bd49-b4448cfd7579-000000@eu-west-1.amazonses.com> Application Specific Integrated Circuit. It's even in the name! You can't just run normal software on ASICs. It's not a computer. They're literally hard-wired to do one thing - and do it well. Switch ASICs, for example, are good for switching network packets around. Though (I would assume) they can't do any kind of hashing, much less Bitcoin-specific stuff. Trying to mine Bitcoin on switch ASICs would be like trying to transfer water through a 2.4GHz WiFi connection - both are absolutely preposterous ideas. Regards -- Filip Hruska Linux System Administrator Dne 1/9/18 v 17:02 Michael Crapse napsal(a): > The definition of an ASIC is that it has only one use. Just because half of > a 100gb switch is not in use doesn't mean that you can mine bitcoin, or run > a blockchain with the asics not in use.. > > On 9 January 2018 at 08:49, Jean | ddostest.me via NANOG > wrote: > >> BTC miners use asics. Big switches/routers use 100Gb asics. Some >> switches have multiple 100 Gb asics and sometimes only half is use or >> even less. >> >> I guess it could be nice for some smaller telcos to generate some profit >> during off peak period. I don't know how feasible and I fully understand >> that the vendor warranty should be instantly void. >> >> Also, sometimes telcos have off the shelves spare that gather dust for >> years... It could be interesting to also generate few coins. >> >> Jean >> >> On 18-01-09 10:31 AM, Naslund, Steve wrote: >>> Sure but there are lots of blockchains other than bitcoin. A lot of >> real smart people do not even suspect that bitcoin is a long term survivor >> due to its long transaction times. Which blockchains do you want to >> support? 150GB may not seem like a lot (although a lot of my gear does not >> have the memory to cache that) but 10 of those is beyond the memory on the >> vast majority of network gear I am aware of. That sure looks like a >> slippery slope to me. Now that a lot of network switching and routers can >> support applications, you could just host all of your apps on them just >> like you could do all of your routing in your servers. The question for >> you is what responsibilities do you want to take on. That probably >> depends on what business you are in. >>>> There is absolutely no reason that the networking equipment itself >> can't both operate the blockchain and keep a full copy. It's a pretty good >> bet that your own routers will probably be online; if not, you have bigger >> problems. >>>> The storage requirements aren't particularly onerous. The entire >> Bitcoin blockchain is around 150GB, with several orders of magnitude more >> transactions (read: config changes) than you're likely to see even on a >> very large network. SSDs are small >enough and reliable enough now that >> the physical space requirements are quite small. >>> Steven Naslund >>> Chicago IL >>> From network at cwo.com Wed Jan 10 23:06:22 2018 From: network at cwo.com (Jorg Bielak) Date: Wed, 10 Jan 2018 15:06:22 -0800 Subject: Cisco switch recommendations Message-ID: <7261FEBA-A535-47AC-8C81-66183559A804@cwo.com> I’m currently using Cisco WS-4948-10GE switches on some of my sites. Since I need more than two 10-Gig ports the Cisco 4948s have reached end-of-life for me. The current Cisco 4948 switches are doing my OSPF and BGP routing, as well as some ACLs and actually work great for us…. I’m looking to replace the current switches with Cisco 3850-12XS switches (using the IP Services OS). Does anyone have experience with the Cisco 3850-12XS switches, in comparison to the WS-4948-10GE switches? Or other recommendations? Thanks JB From jbothe at me.com Wed Jan 10 23:17:29 2018 From: jbothe at me.com (JASON BOTHE) Date: Wed, 10 Jan 2018 17:17:29 -0600 Subject: Cisco switch recommendations In-Reply-To: <7261FEBA-A535-47AC-8C81-66183559A804@cwo.com> References: <7261FEBA-A535-47AC-8C81-66183559A804@cwo.com> Message-ID: They work pretty well as do the new 9300s. They handle ldp nicely as well and are a tad bit shallower than the 3850 of that’s of benefit. Jason > On Jan 10, 2018, at 17:06, Jorg Bielak wrote: > > I’m currently using Cisco WS-4948-10GE switches on some of my sites. > Since I need more than two 10-Gig ports the Cisco 4948s have reached end-of-life for me. > The current Cisco 4948 switches are doing my OSPF and BGP routing, as well as some ACLs and actually work great for us…. > I’m looking to replace the current switches with Cisco 3850-12XS switches (using the IP Services OS). > Does anyone have experience with the Cisco 3850-12XS switches, in comparison to the WS-4948-10GE switches? Or other recommendations? > > Thanks > JB From saku at ytti.fi Wed Jan 10 23:24:48 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 11 Jan 2018 01:24:48 +0200 Subject: Blockchain and Networking In-Reply-To: <01020160e247f32f-ce0052ea-773a-4863-bd49-b4448cfd7579-000000@eu-west-1.amazonses.com> References: <20180109031925.2CC1818EC6E9@ary.local> <9578293AE169674F9A048B2BC9A081B4028C2FA9AF@WAUPRDMBXP1.medline.com> <8caa1501-697b-7a61-4e67-d1ba9d9d64a0@ddostest.me> <01020160e247f32f-ce0052ea-773a-4863-bd49-b4448cfd7579-000000@eu-west-1.amazonses.com> Message-ID: On 11 January 2018 at 00:54, Filip Hruska wrote: > You can't just run normal software on ASICs. It's not a computer. They're > literally hard-wired to do one thing - and do it well. > Switch ASICs, for example, are good for switching network packets around. > Though (I would assume) they > can't do any kind of hashing, much less Bitcoin-specific stuff. You're probably right that Switch ASICs would not be able to do any BTC stuff. But most of them do use hashes, MACs are in hash tables often, balancing requires hashes. There is also somewhat hazy definition what is ASIC and what is NPU, NPU boxes are large collection of same chips, and chips are executing same software to completion, they can do anything, just matter of how long it takes and how effective they are doing it, they certainly wouldn't be practical BTC miners.. -- ++ytti From nanog-announce at nanog.org Wed Jan 10 23:41:50 2018 From: nanog-announce at nanog.org (Ryan Woolley via NANOG-announce) Date: Wed, 10 Jan 2018 17:41:50 -0600 (CST) Subject: [NANOG-announce] NANOG 72 Agenda is Published Message-ID: This message has been wrapped due to the DMARC policy setting to prevent NANOG subscribers from being unsubscribed due to bounces. -------------- next part -------------- An embedded message was scrubbed... From: Ryan Woolley Subject: NANOG 72 Agenda is Published Date: Wed, 10 Jan 2018 18:41:47 -0500 Size: 6356 URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From blake at ispn.net Thu Jan 11 16:25:04 2018 From: blake at ispn.net (Blake Hudson) Date: Thu, 11 Jan 2018 10:25:04 -0600 Subject: Cisco switch recommendations In-Reply-To: <7261FEBA-A535-47AC-8C81-66183559A804@cwo.com> References: <7261FEBA-A535-47AC-8C81-66183559A804@cwo.com> Message-ID: The 38xx, 37xx, 36xx, 35xx, etc line have generally not been wirespeed on all ports and have had smaller buffers. For applications where we wanted to guarantee wirespeed I've generally stuck to the 4948 lineup or a switch based on the 4500 family. Any reason you don't mention the 4948E(-F) (4x 10gig ports) or 4500-X (all ports 10gig) as these are Cisco's replacement for the model you currently have in use and have been happy with? Jorg Bielak wrote on 1/10/2018 5:06 PM: > I’m currently using Cisco WS-4948-10GE switches on some of my sites. > Since I need more than two 10-Gig ports the Cisco 4948s have reached end-of-life for me. > The current Cisco 4948 switches are doing my OSPF and BGP routing, as well as some ACLs and actually work great for us…. > I’m looking to replace the current switches with Cisco 3850-12XS switches (using the IP Services OS). > Does anyone have experience with the Cisco 3850-12XS switches, in comparison to the WS-4948-10GE switches? Or other recommendations? > > Thanks > JB From beecher at beecher.cc Thu Jan 11 17:22:43 2018 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 11 Jan 2018 12:22:43 -0500 Subject: Blockchain and Networking In-Reply-To: References: Message-ID: "Blockchain is great at proving chain of custody, but when do you need to do that in computer networking?" This is the most important question to ask. Everything else is just buzzwordy shenanigans. On Mon, Jan 8, 2018 at 12:52 AM, William Herrin wrote: > On Mon, Jan 8, 2018 at 12:26 AM, Glen Kent wrote: > > > Do folks on this list see blockchain technology making inroads into the > > networking? I can see blockchain being used to secure the SDN environment > > where blockchain will allow encrypted data transfers between nodes (ones > > hosting different applications, the SDN controller, the data plane > devices) > > regardless of the network size or its geographical distribution. > > > > Hi Glen, > > I'm having trouble envisioning a scenario where blockchain does that any > better than plain old PKI. > > Blockchain is great at proving chain of custody, but when do you need to do > that in computer networking? > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From mfidelman at meetinghouse.net Thu Jan 11 19:44:09 2018 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 11 Jan 2018 12:44:09 -0700 Subject: Blockchain and Networking In-Reply-To: References: Message-ID: <8fae3af3-c8c9-729c-0bf7-286dabf0b45f@meetinghouse.net> Transferring log files, used as forensic evidence, comes to mind. Any kind of paperwork, tables, etc. associated with network configuration - particularly if you're trying to preserve changes. On 1/11/18 10:22 AM, Tom Beecher wrote: > "Blockchain is great at proving chain of custody, but when do you need to do > that in computer networking?" > > This is the most important question to ask. Everything else is just > buzzwordy shenanigans. > > On Mon, Jan 8, 2018 at 12:52 AM, William Herrin wrote: > >> On Mon, Jan 8, 2018 at 12:26 AM, Glen Kent wrote: >> >>> Do folks on this list see blockchain technology making inroads into the >>> networking? I can see blockchain being used to secure the SDN environment >>> where blockchain will allow encrypted data transfers between nodes (ones >>> hosting different applications, the SDN controller, the data plane >> devices) >>> regardless of the network size or its geographical distribution. >>> >> Hi Glen, >> >> I'm having trouble envisioning a scenario where blockchain does that any >> better than plain old PKI. >> >> Blockchain is great at proving chain of custody, but when do you need to do >> that in computer networking? >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From dwcarder at es.net Thu Jan 11 19:46:35 2018 From: dwcarder at es.net (Dale W. Carder) Date: Thu, 11 Jan 2018 13:46:35 -0600 Subject: Blockchain and Networking In-Reply-To: References: Message-ID: <20180111194635.GA10384@cs-it-6805697.local> Traceroute or any other path diagnostics comes to mind. Dale Thus spake Tom Beecher (beecher at beecher.cc) on Thu, Jan 11, 2018 at 12:22:43PM -0500: > "Blockchain is great at proving chain of custody, but when do you need to do > that in computer networking?" > > This is the most important question to ask. Everything else is just > buzzwordy shenanigans. > > On Mon, Jan 8, 2018 at 12:52 AM, William Herrin wrote: > > > On Mon, Jan 8, 2018 at 12:26 AM, Glen Kent wrote: > > > > > Do folks on this list see blockchain technology making inroads into the > > > networking? I can see blockchain being used to secure the SDN environment > > > where blockchain will allow encrypted data transfers between nodes (ones > > > hosting different applications, the SDN controller, the data plane > > devices) > > > regardless of the network size or its geographical distribution. > > > > > > > Hi Glen, > > > > I'm having trouble envisioning a scenario where blockchain does that any > > better than plain old PKI. > > > > Blockchain is great at proving chain of custody, but when do you need to do > > that in computer networking? > > > > Regards, > > Bill Herrin > > > > > > -- > > William Herrin ................ herrin at dirtside.com bill at herrin.us > > Dirtside Systems ......... Web: > > From bill at herrin.us Thu Jan 11 20:28:19 2018 From: bill at herrin.us (William Herrin) Date: Thu, 11 Jan 2018 15:28:19 -0500 Subject: Blockchain and Networking In-Reply-To: <8fae3af3-c8c9-729c-0bf7-286dabf0b45f@meetinghouse.net> References: <8fae3af3-c8c9-729c-0bf7-286dabf0b45f@meetinghouse.net> Message-ID: On Thu, Jan 11, 2018 at 2:44 PM, Miles Fidelman wrote: > Transferring log files, used as forensic evidence, comes to mind. > Blockchain is no better at transferring log files than regular PKI. Blockchain could be used to authenticate that forensic evidence presented later is the same evidence that was originally logged by the individual who collected it where the agency responsible for custody of the evidence is not trusted or where there have been claims evidence tampering. Interesting law enforcement application. Dubious utility in networking where the networking staff are a trusted authority. Any kind of paperwork, tables, etc. associated with network configuration - > particularly if you're trying to preserve changes. AFAICT, blockchain is no better at this than regular PKI and regular PKI is much less expensive to operate. On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder wrote: > > Traceroute or any other path diagnostics comes to mind. That's not obvious to me. Assuming the time-exceeded message was modified to include the necessary data, how would blockchain authenticate the responding router? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From 7riw77 at gmail.com Fri Jan 12 03:46:59 2018 From: 7riw77 at gmail.com (7riw77 at gmail.com) Date: Thu, 11 Jan 2018 22:46:59 -0500 Subject: Comparison of freeware open source switch software? In-Reply-To: References: <7fe9f1d5-2373-10e3-370e-b52274467d7a@efes.iucc.ac.il> Message-ID: <03aa01d38b58$00a6ca30$01f45e90$@gmail.com> > My understanding is the same as Ricky's. At least in the Broadcom word, you > have to license the SDK from Broadcom in order to develop against it and, more > importantly, have documentation of which register does what. I don't know if > you need to license it to program the ASIC (assuming you can do it without SDK > in a sensible fashion). If you can live within SAI's capabilities, SAI is freely available for Broadcom. This is what SONiC uses to communicate to the Broadcom chipset, and it works well. If you really want a rundown, please ping me off list; I have a good bit of information I could share from prior presentations... You can also look up my presentations at nanog/lacnog on the topic, but I'm glad to fill in what I know beyond what's there if it's helpful. 😊 Russ From listas at kurtkraut.net Fri Jan 12 12:38:46 2018 From: listas at kurtkraut.net (Kurt Kraut) Date: Fri, 12 Jan 2018 10:38:46 -0200 Subject: Any IP Transit provider currently offering BGP FlowSpec? Message-ID: Hello, I'm looking for an IP Transit provider (in the Americas region preferrably) that provides BGP FlowSpec capabilities. I've found some that accept filtering rules at the IP Transit level but changes are done by support ticket, which is subpar to me. I must have autonomy to change rules at will. Could anyone mention known providers publically? If you work for an IP Transit provider, feel free to contact me privately/directly. Best regards, Kurt Kraut From cscora at apnic.net Fri Jan 12 18:02:48 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Jan 2018 04:02:48 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180112180248.83149F5272@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, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 13 Jan, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 679665 Prefixes after maximum aggregation (per Origin AS): 263982 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 328696 Total ASes present in the Internet Routing Table: 59575 Prefixes per ASN: 11.41 Origin-only ASes present in the Internet Routing Table: 51428 Origin ASes announcing only one prefix: 22672 Transit ASes present in the Internet Routing Table: 8147 Transit-only ASes present in the Internet Routing Table: 242 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 30 Max AS path prepend of ASN ( 29046) 25 Prefixes from unregistered ASNs in the Routing Table: 86 Number of instances of unregistered ASNs: 87 Number of 32-bit ASNs allocated by the RIRs: 21152 Number of 32-bit ASNs visible in the Routing Table: 16973 Prefixes from 32-bit ASNs in the Routing Table: 69846 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 401 Number of addresses announced to Internet: 2860951458 Equivalent to 170 /8s, 134 /16s and 167 /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: 98.8 Total number of prefixes smaller than registry allocations: 224867 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 187440 Total APNIC prefixes after maximum aggregation: 53596 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 186513 Unique aggregates announced from the APNIC address blocks: 77710 APNIC Region origin ASes present in the Internet Routing Table: 8580 APNIC Prefixes per ASN: 21.74 APNIC Region origin ASes announcing only one prefix: 2440 APNIC Region transit ASes present in the Internet Routing Table: 1250 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3464 Number of APNIC addresses announced to Internet: 770376482 Equivalent to 45 /8s, 235 /16s and 3 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 202342 Total ARIN prefixes after maximum aggregation: 97452 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 203568 Unique aggregates announced from the ARIN address blocks: 95703 ARIN Region origin ASes present in the Internet Routing Table: 18049 ARIN Prefixes per ASN: 11.28 ARIN Region origin ASes announcing only one prefix: 6678 ARIN Region transit ASes present in the Internet Routing Table: 1790 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2291 Number of ARIN addresses announced to Internet: 1108559904 Equivalent to 66 /8s, 19 /16s and 72 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 183930 Total RIPE prefixes after maximum aggregation: 89501 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 179866 Unique aggregates announced from the RIPE address blocks: 107940 RIPE Region origin ASes present in the Internet Routing Table: 24810 RIPE Prefixes per ASN: 7.25 RIPE Region origin ASes announcing only one prefix: 11342 RIPE Region transit ASes present in the Internet Routing Table: 3515 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6558 Number of RIPE addresses announced to Internet: 713678464 Equivalent to 42 /8s, 137 /16s and 222 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 87875 Total LACNIC prefixes after maximum aggregation: 19428 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 89170 Unique aggregates announced from the LACNIC address blocks: 39818 LACNIC Region origin ASes present in the Internet Routing Table: 6746 LACNIC Prefixes per ASN: 13.22 LACNIC Region origin ASes announcing only one prefix: 1846 LACNIC Region transit ASes present in the Internet Routing Table: 1255 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4270 Number of LACNIC addresses announced to Internet: 172560096 Equivalent to 10 /8s, 73 /16s and 14 /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: 17990 Total AfriNIC prefixes after maximum aggregation: 3939 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 20147 Unique aggregates announced from the AfriNIC address blocks: 7227 AfriNIC Region origin ASes present in the Internet Routing Table: 1116 AfriNIC Prefixes per ASN: 18.05 AfriNIC Region origin ASes announcing only one prefix: 365 AfriNIC Region transit ASes present in the Internet Routing Table: 221 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 390 Number of AfriNIC addresses announced to Internet: 95352064 Equivalent to 5 /8s, 174 /16s and 245 /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 5438 4195 92 ERX-CERNET-BKB China Education and Rese 7545 3272 403 389 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2866 11131 762 KIXS-AS-KR Korea Telecom, KR 17974 2784 918 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2770 1499 540 BSNL-NIB National Internet Backbone, IN 9394 2636 4923 27 CTTNET China TieTong Telecommunications 45899 2554 1542 157 VNPT-AS-VN VNPT Corp, VN 7552 2507 1159 50 VIETEL-AS-AP Viettel Group, VN 9808 2105 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2083 417 209 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 3337 1323 86 SHAW - Shaw Communications Inc., CA 22773 3267 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2168 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2072 2334 449 CHARTER-NET-HKY-NC - Charter Communicat 16509 1998 4148 575 AMAZON-02 - Amazon.com, Inc., US 6389 1957 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1913 5061 623 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1874 332 232 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1721 232 570 CABLEONE - CABLE ONE, INC., US 7018 1680 20198 1250 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 20940 2853 842 2060 AKAMAI-ASN1, US 8551 2273 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2096 1832 693 ROSTELECOM-AS, RU 12479 2036 1082 159 UNI2-AS, ES 9121 1993 1691 17 TTNET, TR 34984 1977 330 472 TELLCOM-AS, TR 13188 1605 100 46 TRIOLAN, UA 8402 1235 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1228 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 3758 3433 598 Uninet S.A. de C.V., MX 10620 3584 541 248 Telmex Colombia S.A., CO 11830 2634 370 66 Instituto Costarricense de Electricidad 6503 1626 437 53 Axtel, S.A.B. de C.V., MX 7303 1498 1023 192 Telecom Argentina S.A., AR 6147 1112 377 27 Telefonica del Peru S.A.A., PE 28573 1020 2246 194 CLARO S.A., BR 3816 1014 509 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 919 126 85 Alestra, S. de R.L. de C.V., MX 18881 904 1065 27 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1185 398 50 LINKdotNET-AS, EG 37611 781 91 8 Afrihost, ZA 36903 739 371 140 MT-MPLS, MA 36992 688 1383 31 ETISALAT-MISR, EG 8452 527 1730 18 TE-AS TE-AS, EG 24835 487 786 17 RAYA-AS, EG 37492 449 367 77 ORANGE-, TN 29571 446 36 13 ORANGE-COTE-IVOIRE, CI 37342 357 32 1 MOVITEL, MZ 15399 350 35 7 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 4538 5438 4195 92 ERX-CERNET-BKB China Education and Rese 8151 3758 3433 598 Uninet S.A. de C.V., MX 10620 3584 541 248 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3337 1323 86 SHAW - Shaw Communications Inc., CA 7545 3272 403 389 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3267 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2866 11131 762 KIXS-AS-KR Korea Telecom, KR 20940 2853 842 2060 AKAMAI-ASN1, US 17974 2784 918 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 39891 3520 3499 ALJAWWALSTC-AS, SA 10620 3584 3336 Telmex Colombia S.A., CO 6327 3337 3251 SHAW - Shaw Communications Inc., CA 8151 3758 3160 Uninet S.A. de C.V., MX 22773 3267 3121 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3272 2883 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2784 2707 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9394 2636 2609 CTTNET China TieTong Telecommunications Corpora 11830 2634 2568 Instituto Costarricense de Electricidad y Telec 7552 2507 2457 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64609 PRIVATE 94.245.126.0/24 6584 MICROSOFT-GP-AS - Microsoft Co 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 23.159.192.0/24 54726 AET - AET Hosting Solutions, Inc., US 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:12 /10:37 /11:99 /12:279 /13:558 /14:1088 /15:1894 /16:13413 /17:7770 /18:13689 /19:25277 /20:38805 /21:44726 /22:83021 /23:67064 /24:379677 /25:838 /26:606 /27:660 /28:36 /29:20 /30:17 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3129 3337 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2528 3267 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2062 2168 MEGAPATH5-US - MegaPath Corporation, US 11830 1980 2634 Instituto Costarricense de Electricidad y Telec 8551 1736 2273 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1637 1874 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1578 3584 Telmex Colombia S.A., CO 11492 1519 1721 CABLEONE - CABLE ONE, INC., US 9121 1469 1993 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1579 2:822 4:18 5:2635 6:39 8:1098 9:1 12:1854 13:198 14:1762 15:29 16:3 17:186 18:76 20:51 21:1 23:2517 24:1927 25:2 27:2359 31:1959 32:88 35:22 36:475 37:2482 38:1439 39:228 40:100 41:3037 42:536 43:1935 44:89 45:3537 46:2968 47:192 49:1367 50:1055 51:47 52:918 54:354 55:4 56:7 57:43 58:1574 59:1010 60:370 61:2058 62:1781 63:1819 64:4667 65:2238 66:4477 67:2322 68:1174 69:3176 70:1132 71:562 72:2083 74:2664 75:395 76:423 77:1567 78:1625 79:1925 80:1477 81:1398 82:1101 83:875 84:1004 85:1983 86:568 87:1290 88:972 89:2516 90:179 91:6233 92:1098 93:2347 94:2510 95:2730 96:647 97:356 98:925 99:111 100:79 101:1535 102:14 103:16753 104:3228 105:212 106:522 107:1803 108:707 109:2755 110:1590 111:1729 112:1283 113:1384 114:1111 115:1593 116:1625 117:1675 118:2186 119:1677 120:914 121:1047 122:2450 123:1880 124:1482 125:1837 128:984 129:583 130:440 131:1640 132:601 133:194 134:1000 135:227 136:448 137:466 138:1974 139:548 140:388 141:684 142:768 143:966 144:799 145:196 146:1153 147:688 148:1487 149:712 150:714 151:980 152:753 153:310 154:970 155:744 156:743 157:752 158:602 159:1621 160:839 161:721 162:2546 163:522 164:975 165:1493 166:399 167:1381 168:3111 169:793 170:3641 171:403 172:1029 173:1885 174:863 175:777 176:1862 177:3965 178:2440 179:1184 180:2233 181:2139 182:2422 183:1066 184:900 185:12023 186:3487 187:2366 188:2610 189:1965 190:8179 191:1338 192:9746 193:5874 194:4772 195:3986 196:2346 197:1439 198:5517 199:5889 200:7279 201:4894 202:10367 203:9943 204:4538 205:2863 206:3040 207:3109 208:4006 209:3924 210:4003 211:2145 212:2952 213:2613 214:777 215:64 216:5778 217:2111 218:900 219:626 220:1729 221:997 222:1060 223:1226 End of report From tdurack at gmail.com Fri Jan 12 19:43:04 2018 From: tdurack at gmail.com (Tim Durack) Date: Fri, 12 Jan 2018 19:43:04 +0000 Subject: AS15133 (EdgeCast)? Message-ID: Anybody here from AS15133 (EdgeCast) engineering? We peer with you at DE-CIX NY. Seeing a packet loss issue which is impacting O365 & MS CDN assets. Trying to resolve but email to peering@ generated a Verizon ticket which isn't inspiring confidence... Thanks, Tim:> From aaron1 at gvtc.com Fri Jan 12 20:35:25 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 12 Jan 2018 14:35:25 -0600 Subject: cisco ip vrf autoclassify source Message-ID: <000401d38be4$e0ab3f80$a201be80$@gvtc.com> The "ip vrf autoclassify source" feature looks to be a very nice auto-pbr solution for allowing multiple vrf's on one interface! I'd like to know if anyone has used it and what you think about it, particularly in the cable modem world...on Cisco uBR7246VXR, uBR10k, cbr8 -Aaron From tdurack at gmail.com Fri Jan 12 21:38:17 2018 From: tdurack at gmail.com (Tim Durack) Date: Fri, 12 Jan 2018 21:38:17 +0000 Subject: AS15133 (EdgeCast)? In-Reply-To: References: Message-ID: Problem seems resolved. If somebody somewhere did something - thanks! :) On Fri, Jan 12, 2018 at 2:43 PM Tim Durack wrote: > Anybody here from AS15133 (EdgeCast) engineering? > > We peer with you at DE-CIX NY. Seeing a packet loss issue which is > impacting O365 & MS CDN assets. > > Trying to resolve but email to peering@ generated a Verizon ticket which > isn't inspiring confidence... > > Thanks, > > Tim:> > From valdis.kletnieks at vt.edu Fri Jan 12 22:20:28 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 12 Jan 2018 17:20:28 -0500 Subject: Blockchain and Networking In-Reply-To: References: <8fae3af3-c8c9-729c-0bf7-286dabf0b45f@meetinghouse.net> Message-ID: <196162.1515795628@turing-police.cc.vt.edu> On Thu, 11 Jan 2018 15:28:19 -0500, William Herrin said: > On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder wrote: > > > > Traceroute or any other path diagnostics comes to mind. > That's not obvious to me. Assuming the time-exceeded message was modified > to include the necessary data, how would blockchain authenticate the > responding router? And do you really want to do *all* that on every single 'TTL Exceeded' ICMP? Sounds like a *really* easy way to DDoS a router.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From morrowc.lists at gmail.com Sat Jan 13 02:26:14 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 12 Jan 2018 21:26:14 -0500 Subject: Blockchain and Networking In-Reply-To: <196162.1515795628@turing-police.cc.vt.edu> References: <8fae3af3-c8c9-729c-0bf7-286dabf0b45f@meetinghouse.net> <196162.1515795628@turing-police.cc.vt.edu> Message-ID: On Fri, Jan 12, 2018 at 5:20 PM, wrote: > On Thu, 11 Jan 2018 15:28:19 -0500, William Herrin said: > > On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder wrote: > > > > > > Traceroute or any other path diagnostics comes to mind. > > > That's not obvious to me. Assuming the time-exceeded message was modified > > to include the necessary data, how would blockchain authenticate the > > responding router? > > And do you really want to do *all* that on every single 'TTL Exceeded' > ICMP? Sounds like > a *really* easy way to DDoS a router.... > pish-posh! the asics will do it. From rsk at gsp.org Sat Jan 13 13:49:56 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 13 Jan 2018 08:49:56 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: <48c32bde-9bf0-b901-f771-7222eae7b305@nordu.net> References: <1AE73692-8E1F-4DC9-9144-4607BF26F133@tburke.us> <48c32bde-9bf0-b901-f771-7222eae7b305@nordu.net> Message-ID: <20180113134956.GA29520@gsp.org> On Thu, Jan 04, 2018 at 09:15:19AM +0100, Fredrik Korsb??ck wrote: > For me Poney/Illiad/Online.net/Scaleway has always been a bulletproof hoster > (or bulletproof transit even), the response to abuse has always been NIL. They're still a bulletproof hoster, and they fully support, endorse, and encourage abuse. Not that we really need any more evidence, since they've been furnishing it for years, but this (below) caught my attention this morning. ---rsk > From: Sam > Newsgroups: news.admin.net-abuse.email > Subject: Clue level of online.net has been established > Date: Mon, 08 Jan 2018 06:24:36 -0500 > > The following E-mail response firmly establishes the clue level of this > outfit: > > > From: noreply at online.net > To: postmaster at email-scan.com > Subject: [Online] Abuse #200181 - abuse for failover ip address 212.129.49.22 resolved > > ONLINE SAS > Technical assistance > BP 438 - 75366 Paris CEDEX 08 > France > > Tel: 01 84 13 00 00 > > Subject : Abuse notification resolved > > Dear Sir or Madam, > > Your abuse number 200181 is now closed. > > Here is a comment left by our customer: > ---------------------------------------------------------------- > > not spam, marketing mail only > > ---------------------------------------------------------------- > > If you have any questions, please contact our assistance > https://console.online.net/assistance/ > > Best regards, > From beecher at beecher.cc Sun Jan 14 21:31:02 2018 From: beecher at beecher.cc (Tom Beecher) Date: Sun, 14 Jan 2018 16:31:02 -0500 Subject: Attacks from poneytelecom.eu In-Reply-To: <20180113134956.GA29520@gsp.org> References: <1AE73692-8E1F-4DC9-9144-4607BF26F133@tburke.us> <48c32bde-9bf0-b901-f771-7222eae7b305@nordu.net> <20180113134956.GA29520@gsp.org> Message-ID: Most VPS / hosting abuse departments are understaffed (if they exist at all), and even when they do dig in, the last thing most of them want to do with razor thin margins is to shut off a paying customer unless they REALLY REALLY have to. Noe of this should be a surprise. On Sat, Jan 13, 2018 at 8:49 AM, Rich Kulawiec wrote: > On Thu, Jan 04, 2018 at 09:15:19AM +0100, Fredrik Korsb??ck wrote: > > For me Poney/Illiad/Online.net/Scaleway has always been a bulletproof > hoster > > (or bulletproof transit even), the response to abuse has always been NIL. > > They're still a bulletproof hoster, and they fully support, endorse, > and encourage abuse. Not that we really need any more evidence, since > they've been furnishing it for years, but this (below) caught my attention > this morning. > > ---rsk > > > > From: Sam > > Newsgroups: news.admin.net-abuse.email > > Subject: Clue level of online.net has been established > > Date: Mon, 08 Jan 2018 06:24:36 -0500 > > > > The following E-mail response firmly establishes the clue level of this > > outfit: > > > > > > From: noreply at online.net > > To: postmaster at email-scan.com > > Subject: [Online] Abuse #200181 - abuse for failover ip address > 212.129.49.22 resolved > > > > ONLINE SAS > > Technical assistance > > BP 438 - 75366 Paris CEDEX 08 > > France > > > > Tel: 01 84 13 00 00 > > > > Subject : Abuse notification resolved > > > > Dear Sir or Madam, > > > > Your abuse number 200181 is now closed. > > > > Here is a comment left by our customer: > > ---------------------------------------------------------------- > > > > not spam, marketing mail only > > > > ---------------------------------------------------------------- > > > > If you have any questions, please contact our assistance > > https://console.online.net/assistance/ > > > > Best regards, > > > From nanog at ics-il.net Mon Jan 15 02:48:56 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 14 Jan 2018 20:48:56 -0600 (CST) Subject: DSL CPE In-Reply-To: <1515507727.403514769@upnet.mymailsrvr.com> References: <1427825328.1322.1515505834972.JavaMail.mhammett@ThunderFuck> <1515507727.403514769@upnet.mymailsrvr.com> Message-ID: <1311853825.2165.1515984533132.JavaMail.mhammett@ThunderFuck> Any particular Zyxel models or just Zyxel in general perform better at longer lengths? ----- Original Message ----- From: "Shawn L" To: "Mike Hammett" Cc: "NANOG" Sent: Tuesday, January 9, 2018 8:22:07 AM Subject: RE: DSL CPE At $dayjob we use both Comtrend and Zyxel modems. Both have a 1-port modem that can be deployed in bridged mode. They both seem to work well with Calix gear. We've found the Zyxel modems tend to work a little better at longer loop lengths. But, for us at least, it's very easy to get custom firmware created and pre-deployed to comtrend modems at the factory / distributor. So we haven't completely decided between one brand and the other. We started looking at Zyxel for increased speed at longer loop lengths and better wifi support. There's a company a few exchanges over from us that has deployed the caix giga family and really likes it. We haven't deployed them yet because they only work on the Calix E7 series (E7-2 and E7-20) and we still have a lot of C7 series dslams in the network. Shawn -----Original Message----- From: "Mike Hammett" Sent: Tuesday, January 9, 2018 8:50am To: "NANOG" Subject: DSL CPE After a few off-list responses (and a couple on) encouraging me to use NANOG, here we go... I've recently walked in to a voice\DSL CLEC that has basically been left to entropy for the last ten years. A lot of the core systems just work, but a lot of things aren't exactly managed the best. They run a Calix\Occam ADSL2+\VDSL infrastructure. For those of you doing DSL, what CPE are you using? I'm looking at one that's just a basic modem where I have a more sophisticated router (or ATA\voice gateway) behind it and then one more generic for residential settings with WiFi and all that jazz. We're kinda debating whether we go just dumb Wi-Fi or something more advanced\powerful. I've heard a lot of good about the Calix GigaFamily in that regard. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From colton.conor at gmail.com Mon Jan 15 03:51:00 2018 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 14 Jan 2018 21:51:00 -0600 Subject: DSL CPE In-Reply-To: <1311853825.2165.1515984533132.JavaMail.mhammett@ThunderFuck> References: <1427825328.1322.1515505834972.JavaMail.mhammett@ThunderFuck> <1515507727.403514769@upnet.mymailsrvr.com> <1311853825.2165.1515984533132.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, You want to look at what Broadcom chipsets are in this DSL CPEs. Broadcom is the king and leader in the DSL space. We used the Comtrend 3120 as it has one of the latest Broadcom chipsets on the market. I know you love to check FCC ID's so this should be helpful for you: https://wikidevi.com/wiki/Broadcom#xDSL The Comtrend 3120 uses the BCM63138. Dual core 1Ghz. It makes a difference even if the mode is in pure bridge mode. There aren't many bonded modems that don't have wifi built in as the chipset includes wifi. On Sun, Jan 14, 2018 at 8:48 PM, Mike Hammett wrote: > Any particular Zyxel models or just Zyxel in general perform better at > longer lengths? > > ----- Original Message ----- > > From: "Shawn L" > To: "Mike Hammett" > Cc: "NANOG" > Sent: Tuesday, January 9, 2018 8:22:07 AM > Subject: RE: DSL CPE > > > At $dayjob we use both Comtrend and Zyxel modems. Both have a 1-port modem > that can be deployed in bridged mode. They both seem to work well with > Calix gear. We've found the Zyxel modems tend to work a little better at > longer loop lengths. But, for us at least, it's very easy to get custom > firmware created and pre-deployed to comtrend modems at the factory / > distributor. So we haven't completely decided between one brand and the > other. We started looking at Zyxel for increased speed at longer loop > lengths and better wifi support. > > There's a company a few exchanges over from us that has deployed the caix > giga family and really likes it. We haven't deployed them yet because they > only work on the Calix E7 series (E7-2 and E7-20) and we still have a lot > of C7 series dslams in the network. > > Shawn > > > > -----Original Message----- > From: "Mike Hammett" > Sent: Tuesday, January 9, 2018 8:50am > To: "NANOG" > Subject: DSL CPE > > > > After a few off-list responses (and a couple on) encouraging me to use > NANOG, here we go... > > > I've recently walked in to a voice\DSL CLEC that has basically been left > to entropy for the last ten years. A lot of the core systems just work, but > a lot of things aren't exactly managed the best. They run a Calix\Occam > ADSL2+\VDSL infrastructure. For those of you doing DSL, what CPE are you > using? I'm looking at one that's just a basic modem where I have a more > sophisticated router (or ATA\voice gateway) behind it and then one more > generic for residential settings with WiFi and all that jazz. We're kinda > debating whether we go just dumb Wi-Fi or something more advanced\powerful. > I've heard a lot of good about the Calix GigaFamily in that regard. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > > From ryan at nanog.org Mon Jan 15 18:19:28 2018 From: ryan at nanog.org (Ryan Donnelly) Date: Mon, 15 Jan 2018 13:19:28 -0500 Subject: 2018 Program Committee Nominations Message-ID: Fellow NANOG Aficionados, If you’ve ever asked or wondered how you can make a significant contribution to the NANOG organization, I have good news. Nominations are now open for the NANOG Program Committee ! This committee is wholly responsible for the construction and curation of the program content that attendees experience at each of the three yearly NANOG conferences. You’ll join a highly skilled, dedicated and diverse group of people that are united in their desire not only to improve the NANOG organization, but to make our industry, as a whole, better. More specific detail surrounding committee member responsibilities is available here . Committee nominations will close at 9:00 PM ET on Tuesday, February 20, 2018. The NANOG Board of Directors will make appointments on the afternoon of February 21, 2018. Emails detailing the selection results will be sent to candidates shortly thereafter, and a full announcement will be sent to the nanog-announce distribution list during the following week. Volunteer participation on NANOG committees isn’t just critical to our success -- it is our lifeblood. If you are interested, please consider running for a position. If you know someone that you believe would be interested, please nominate them. The nomination form accepts either self or 3rd party nominations. For those of you that are interested but uncertain, please feel free to approach me, or any of the other board members personally. We’d love to hear from you, and sincerely hope that our collective enthusiasm for contributing to this organization will help sway you to join us on our journey. As always, our dedicated professional staff stands ready to answer your questions at operations at nanog.org. Finally (I know I’m a bit late), I’d like to extend my best wishes to each of you for a happy and healthy 2018. I look forward to seeing you on February 19 in Atlanta for NANOG 72 . Thanks, --ryan (for the NANOG Board of Directors) From James at arenalgroup.co Tue Jan 16 23:14:19 2018 From: James at arenalgroup.co (James Breeden) Date: Tue, 16 Jan 2018 23:14:19 +0000 Subject: MultiCarrier Fiber Mapping Tools Message-ID: Anyone aware of competitors to the NEF FiberLocator tool out there? Fiberlocator has gotten way too pricey in my mind. They used to give a free seat for giving them your map but they only give like 10% off now. Thanks in advance. James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co From hugge at nordu.net Wed Jan 17 13:20:59 2018 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Wed, 17 Jan 2018 14:20:59 +0100 Subject: Blockchain and Networking In-Reply-To: References: <8fae3af3-c8c9-729c-0bf7-286dabf0b45f@meetinghouse.net> <196162.1515795628@turing-police.cc.vt.edu> Message-ID: <9d553c67-33b8-8669-13b1-16a63eed49ef@nordu.net> On 2018-01-13 03:26, Christopher Morrow wrote: > On Fri, Jan 12, 2018 at 5:20 PM, wrote: > >> On Thu, 11 Jan 2018 15:28:19 -0500, William Herrin said: >>> On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder wrote: >>>> >>>> Traceroute or any other path diagnostics comes to mind. >> >>> That's not obvious to me. Assuming the time-exceeded message was modified >>> to include the necessary data, how would blockchain authenticate the >>> responding router? >> >> And do you really want to do *all* that on every single 'TTL Exceeded' >> ICMP? Sounds like >> a *really* easy way to DDoS a router.... >> > > pish-posh! the asics will do it. > Apparently we are not keeping up with the cool kids here. https://www.openct.io/ * Open in the name * .IO TLD * A scrolling website It all checks out as a legitimate web3.0 biz ########################################### * Blockchain as a Transport (BaaT): BaaT leverages blockchain to create an architecture that can connect geographically dispersed Layer 2 islands over any available infrastructure, including the public Internet. As the resulting solution securely supports all kinds of traffic: Unicast, Multicast and Broadcast - BaaT will become the transport service of choice for all businesses. * Blockchain-Defined Wide Area Networks (BD-WAN): BD-WAN integrates blockchain with Software-Defined WAN (SD-WAN) for a secure, scalable virtualization of WAN transport technologies. Among the unique features (not available with most SD-WAN architectures): The ability to dynamically establish and tear down logical and physical circuits so customers pay only for what they consume. * Inter-Domain MPLS Traffic Engineering via blockchain (near zero time delay). Trusted per-usage billings that are verified and hard-coded over the blockchain. Full visibility and control over all transport facilities either via Fiber to the Premises (FTTP) or via partnership with key telco operators and metro Ethernet providers worldwide. Bringing public cloud and content services seamlessly to the customers' doorstep as part of the standard offering. ########################################### I wanna buy all of these stuff right now! -- hugge From colton.conor at gmail.com Wed Jan 17 14:28:13 2018 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 17 Jan 2018 08:28:13 -0600 Subject: Open Souce Network Operating Systems Message-ID: If one were to deploy whitebox switches, X86 servers, low cost ARM and MIBPS CPE devices, and basically anything that can run linux today, what network operating system would you recommend? The goal would be to have a universal network operating system that runs across a variety of devices. >From low cost residential CPE's with wifi to switches to BGP speaking routers. Is there anything that can do it all today? I will use something like OpenWRT as an example. I don't consider this anywhere near carrier grade, but it runs on X86 and low cost routers. I don't think it will run on whitebox switches though. Mikrotik RouterOS would be another example as it can run on low cost Routerboards, and X86 servers. But it is not opensouce. Is there any up and coming projects to look into? From ruairi.carroll at gmail.com Wed Jan 17 14:35:09 2018 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Wed, 17 Jan 2018 14:35:09 +0000 Subject: Open Souce Network Operating Systems In-Reply-To: References: Message-ID: Hey, Have a look at a similar thread from recently: http://seclists.org/nanog/2018/Jan/180 /Ruairi On 17 January 2018 at 14:28, Colton Conor wrote: > If one were to deploy whitebox switches, X86 servers, low cost ARM and > MIBPS CPE devices, and basically anything that can run linux today, what > network operating system would you recommend? The goal would be to have a > universal network operating system that runs across a variety of devices. > From low cost residential CPE's with wifi to switches to BGP speaking > routers. Is there anything that can do it all today? > > > I will use something like OpenWRT as an example. I don't consider this > anywhere near carrier grade, but it runs on X86 and low cost routers. I > don't think it will run on whitebox switches though. > > Mikrotik RouterOS would be another example as it can run on low cost > Routerboards, and X86 servers. But it is not opensouce. > > Is there any up and coming projects to look into? > From hugo at slabnet.com Wed Jan 17 16:09:28 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 17 Jan 2018 08:09:28 -0800 Subject: Open Souce Network Operating Systems In-Reply-To: References: Message-ID: <20180117160928.GE25899@bamboo.slabnet.com> There's AT&T's dNOS effort[1], though I think that wasn't really targeting CPE so much as DC and carrier type WAN gear. A single platform for DC, aggregation, and other SP roles is already pretty ambitious. Adding CPE into the mix as well is another big stretch even beyond that. It's also more at the "initiative" stage than anything fully fledged, afaict. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal [1] https://about.att.com/content/dam/innovationblogdocs/att-routing-nos-open-architecture_FINAL%20whitepaper.pdf On Wed 2018-Jan-17 14:35:09 +0000, Ruairi Carroll wrote: >Hey, > >Have a look at a similar thread from recently: >http://seclists.org/nanog/2018/Jan/180 > >/Ruairi > >On 17 January 2018 at 14:28, Colton Conor wrote: > >> If one were to deploy whitebox switches, X86 servers, low cost ARM and >> MIBPS CPE devices, and basically anything that can run linux today, what >> network operating system would you recommend? The goal would be to have a >> universal network operating system that runs across a variety of devices. >> From low cost residential CPE's with wifi to switches to BGP speaking >> routers. Is there anything that can do it all today? >> >> >> I will use something like OpenWRT as an example. I don't consider this >> anywhere near carrier grade, but it runs on X86 and low cost routers. I >> don't think it will run on whitebox switches though. >> >> Mikrotik RouterOS would be another example as it can run on low cost >> Routerboards, and X86 servers. But it is not opensouce. >> >> Is there any up and coming projects to look into? >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From EPers at ansencorp.com Wed Jan 17 16:30:39 2018 From: EPers at ansencorp.com (Edwin Pers) Date: Wed, 17 Jan 2018 16:30:39 +0000 Subject: Open Souce Network Operating Systems In-Reply-To: References: Message-ID: > Is there anything that can do it all today? VyOS, maybe. You'd have a fun time getting it working across the full set of hardware you're thinking of though From rsk at gsp.org Wed Jan 17 17:03:13 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 17 Jan 2018 12:03:13 -0500 Subject: Open Souce Network Operating Systems In-Reply-To: References: Message-ID: <20180117170313.GA18962@gsp.org> On Wed, Jan 17, 2018 at 08:28:13AM -0600, Colton Conor wrote: > The goal would be to have a universal network operating system that > runs across a variety of devices. And for certain uses, that would be handy. Of course it would also be handy to an attacker who found or purchased or was given an exploitable hole in that OS, because then they could pwn the entire intrastructure simultaneously. One-stop shopping, as it were. ---rsk From dave at temk.in Wed Jan 17 18:48:20 2018 From: dave at temk.in (Dave Temkin) Date: Wed, 17 Jan 2018 10:48:20 -0800 Subject: Promoting Exchanges for Enhanced Routing of Information So Networks are Great (PEERING) Act Message-ID: New bill out today as part of a larger set of broadband infrastructure bills, the result of some of the NANOG community's conversations with House staffers (and likely other 3rd parties influence): H.R. ____, “Promoting Exchanges for Enhanced Routing of Information So Networks are Great (PEERING) Act,” sponsored by Representative Billy Long (MO-07) • Internet Exchanges (or peering centers) are the physical locations where networks come together, and where content providers cache content closer to end users to increase speed and efficiency of networks. • The bill would authorize a matching a grant program through the National Telecommunications and Information Administration (NTIA) to promote peering centers where none exist, or to help an existing one expand if it is the only such facility in a core-based statistical area. • The bill would also authorize eligible recipients under the Universal Service Fund’s E-Rate program (schools and libraries) and Telehealth program to use such funds to contract with a broadband provider to obtain a connection to a peering facility, or to pay costs of maintaining a point of presence at a peering facility. From matthew.smee at sydney.edu.au Wed Jan 17 23:11:14 2018 From: matthew.smee at sydney.edu.au (Matthew Smee) Date: Wed, 17 Jan 2018 23:11:14 +0000 Subject: Open Souce Network Operating Systems In-Reply-To: <20180117170313.GA18962@gsp.org> References: <20180117170313.GA18962@gsp.org> Message-ID: Yeah, it'd be silly for organisations to try and standardise their environments for services or infrastructure. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rich Kulawiec Sent: Thursday, 18 January 2018 4:03 AM To: nanog at nanog.org Subject: Re: Open Souce Network Operating Systems On Wed, Jan 17, 2018 at 08:28:13AM -0600, Colton Conor wrote: > The goal would be to have a universal network operating system that > runs across a variety of devices. And for certain uses, that would be handy. Of course it would also be handy to an attacker who found or purchased or was given an exploitable hole in that OS, because then they could pwn the entire intrastructure simultaneously. One-stop shopping, as it were. ---rsk From hugo at slabnet.com Wed Jan 17 23:48:47 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 17 Jan 2018 15:48:47 -0800 Subject: Open Souce Network Operating Systems In-Reply-To: References: <20180117170313.GA18962@gsp.org> Message-ID: <20180117234847.GF25899@bamboo.slabnet.com> On Wed 2018-Jan-17 23:11:14 +0000, Matthew Smee wrote: >Yeah, it'd be silly for organisations to try and standardise their environments for services or infrastructure. I'm somewhat in two minds there. Options to tackle operational complexity/expense: Option 1: Require a homogeneous environment or minimize vendors/platforms as much as possible. Option 2: Accept vendor/platform diversity as inevitable and build systems/abstractions around that. Is #1 achievable? If you're expending time/effort/resources achieving #1 and fall short, don't you have to do #2 anyway? Much has also been said on monocultures in infrastructure: having a single bug impact all of your gear sucks. If I can manage a pair of border routers, for instance, from two different vendors in an abstracted/consistent enough manner that I don't deal with their idiosyncrasies on a daily basis, am I not better off than running a single platform / code train in that function? -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From ray at oneunified.net Thu Jan 18 03:18:21 2018 From: ray at oneunified.net (Raymond Burkholder) Date: Wed, 17 Jan 2018 23:18:21 -0400 Subject: Open Souce Network Operating Systems In-Reply-To: <20180117234847.GF25899@bamboo.slabnet.com> References: <20180117170313.GA18962@gsp.org> <20180117234847.GF25899@bamboo.slabnet.com> Message-ID: On 01/17/2018 07:48 PM, Hugo Slabbert wrote: > On Wed 2018-Jan-17 23:11:14 +0000, Matthew Smee > wrote: >> Yeah, it'd be silly for organisations to try and standardise their >> environments for services or infrastructure. Was this spoken tongue-in-check, or in all seriousness? I would say there is power in standardization. And, yes, there is risk depending upon your attack surface. When we concern ourselves with the attack service, how much time do we spend on mitigating issues on the edge (the attacked surface), vs internal infrastructure where we can apply labour and effort saving automation and orchestration? > > I'm somewhat in two minds there.  Options to tackle operational > complexity/expense: > > Option 1: Require a homogeneous environment or minimize > vendors/platforms as much as possible. Maybe deal with on a case by case basis? Or implement solutions which are 'easy' to mitigate? > > Option 2: Accept vendor/platform diversity as inevitable and build > systems/abstractions around that. And do this in an intelligent manner, depending upon management and risk profiles. Infrastructure tends to be wide ranging. When one thinks about the big picture, where do you _really_ need the diversity, and where you can you gain the most by standardization? Standard engineering response: it depends. And I hope that readers are not trying to draw a line in the sand. I'm hoping that we are open to optimization and orchestration based upon the infrastructure at hand. > > Is #1 achievable?  If you're expending time/effort/resources achieving > #1 and fall short, don't you have to do #2 anyway? Doesn't this go the other way? ... that if you are spending so much effort that building infrastructure, and you can't get a maintainable/upgradeable/orchestratable solution in place, is #2 relevant? > > Much has also been said on monocultures in infrastructure: having a > single bug impact all of your gear sucks.  If I can manage a pair of > border routers, for instance, from two different vendors in an but when I think about this, I'm not thinking about just border routers, I'm thinking about core routing, virtualization infrastructure, carrying customer private circuits, delivering traffic to individual customers, gear for telemetry, implementing security, .... When you think about all the devices involved in various levels and styles of service delivery, there are ways to make that homogenous, and much of it has various attack surfaces, and, well, vendors have their strengths and their weaknesses, so ... #1 a homogenous network makes it easier to intimately understand the possible weaknesses, and attempt protection mechansims, but for #2 with multiple vendors, the effort on platform education increases, depending upon the size of your shop, ... > abstracted/consistent enough manner that I don't deal with their > idiosyncrasies on a daily basis, am I not better off than running a > single platform / code train in that function? or across many functions? > -- Raymond Burkholder ray at oneunified.net https://blog.raymond.burkholder.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From gtaylor at tnetconsulting.net Thu Jan 18 03:47:47 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 17 Jan 2018 20:47:47 -0700 Subject: Open Souce Network Operating Systems In-Reply-To: References: Message-ID: #Devil'sAdvocate On 01/17/2018 07:28 AM, Colton Conor wrote: > If one were to deploy whitebox switches, X86 servers, low cost ARM and > MIBPS CPE devices, and basically anything that can run linux today, what > network operating system would you recommend? Linux. I fail to see the need for various packages that act like something else (or their own entity) to translate to underlying Linux configuration. Why not just put things in the various configuration files that Linux uses? Why have something that translates? If you are going to have a translation layer, why not do it with standard automation layers that you're likely already using. I.e. Ansible / Puppet / Chef / Salt et al. > The goal would be to have a universal network operating system that runs > across a variety of devices. >From low cost residential CPE's with wifi > to switches to BGP speaking routers. Is there anything that can do it > all today? Aside from the concern that others have mentioned about the same vuln on many pieces of equipment, I don't see a problem. Use a standard (or at least consistent in your org) kernel configuration (as necessary & appropriate for the hardware) and standard configuration of application & configuration. Compile as necessary for the architecture that you're on. > I will use something like OpenWRT as an example. I don't consider this > anywhere near carrier grade, but it runs on X86 and low cost routers. I > don't think it will run on whitebox switches though. What is different about OpenWRT vs VyOS? It's my understanding that they are both running Linux and have some sort of (proprietary) configuration layer abstracting away the kernel. > Mikrotik RouterOS would be another example as it can run on low cost > Routerboards, and X86 servers. But it is not opensouce. Is open source a requirement? I consider it a strong desire, but not a requirement. > Is there any up and coming projects to look into? Linux. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From bengelly at gmail.com Thu Jan 18 10:52:58 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Thu, 18 Jan 2018 11:52:58 +0100 Subject: Cogent ops contact Message-ID: Dear Nanog community, I have an issue with a client trying to reach an IP that has been blackholed on Cogent backbone for shady "security reasons". Can someone reach out in MP please ? Thank you. From rudi.daniel at gmail.com Thu Jan 18 12:24:17 2018 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 18 Jan 2018 08:24:17 -0400 Subject: connection to ix Message-ID: How do i remotely connect to an ix? In the en. speaking caribbean we have probably six to eight small national ixps. I want to be present at all of them, & its been suggested i can make some cost savings by remote connection using mpls. Is this a viable option? Is there a disadvantage in doing this? Thx. Rudi From olivier.benghozi at wifirst.fr Thu Jan 18 13:12:10 2018 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Thu, 18 Jan 2018 14:12:10 +0100 Subject: connection to ix In-Reply-To: References: Message-ID: <10F7C058-FDE0-4C06-841B-BBCA84B040F8@wifirst.fr> Sure, plenty of people use such service. If you have much traffic, you'll rely on one dedicated port for each IX, and maybe one full 10G wave or more toward each one (so the remote service is only transport, you have your own port at each IX). If not, you'll use ethernet over MPLS service for remote peering, provided by guys like IX-Reach, who will provide you shared bandwidth over their own connection at each IX, delivered on one single port (or more) toward you. It's shared bandwidth, so you must trust the provider network, in case of DDoS on its ports your traffic will be at risk, you don't see if the remote port is down. But the price can be quite more interesting, you don't have to deal with the remote physical interco, and so on. Now, you have to find someone providing remote peering to the IXs you want, to check the price... > Le 18 janv. 2018 à 13:24, Rudolph Daniel a écrit : > > How do i remotely connect to an ix? > In the en. speaking caribbean we have probably six to eight small national > ixps. I want to be present at all of them, & its been suggested i can make > some cost savings by remote connection using mpls. Is this a viable > option? Is there a disadvantage in doing this? Thx. > > Rudi From nanog at ics-il.net Thu Jan 18 13:36:36 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 18 Jan 2018 07:36:36 -0600 (CST) Subject: connection to ix In-Reply-To: <10F7C058-FDE0-4C06-841B-BBCA84B040F8@wifirst.fr> References: <10F7C058-FDE0-4C06-841B-BBCA84B040F8@wifirst.fr> Message-ID: <1069267999.55.1516282592963.JavaMail.mhammett@ThunderFuck> I doubt you're going to find IX-specific services among Caribbean islands. I also doubt that there is 10G wave-level of capacity needs to each IX, given that AMS-IX Caribbean has a peak of 19 Gb/s. Finding someone that does Carrier Ethernet or VPLS services to do aggregation would be the best hope, but even that is limited given the limited carrier selection in the Caribbean. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Olivier Benghozi" To: "NANOG list" Sent: Thursday, January 18, 2018 7:12:10 AM Subject: Re: connection to ix Sure, plenty of people use such service. If you have much traffic, you'll rely on one dedicated port for each IX, and maybe one full 10G wave or more toward each one (so the remote service is only transport, you have your own port at each IX). If not, you'll use ethernet over MPLS service for remote peering, provided by guys like IX-Reach, who will provide you shared bandwidth over their own connection at each IX, delivered on one single port (or more) toward you. It's shared bandwidth, so you must trust the provider network, in case of DDoS on its ports your traffic will be at risk, you don't see if the remote port is down. But the price can be quite more interesting, you don't have to deal with the remote physical interco, and so on. Now, you have to find someone providing remote peering to the IXs you want, to check the price... > Le 18 janv. 2018 à 13:24, Rudolph Daniel a écrit : > > How do i remotely connect to an ix? > In the en. speaking caribbean we have probably six to eight small national > ixps. I want to be present at all of them, & its been suggested i can make > some cost savings by remote connection using mpls. Is this a viable > option? Is there a disadvantage in doing this? Thx. > > Rudi From magicsata at gmail.com Thu Jan 18 20:04:14 2018 From: magicsata at gmail.com (Alistair Mackenzie) Date: Thu, 18 Jan 2018 20:04:14 +0000 Subject: Cogent ops contact In-Reply-To: References: Message-ID: I've had no problem dealing with their noc on these sort of issues in the past. On 18 Jan 2018 10:54, "Youssef Bengelloun-Zahr" wrote: > Dear Nanog community, > > I have an issue with a client trying to reach an IP that has been > blackholed on Cogent backbone for shady "security reasons". > > Can someone reach out in MP please ? > > Thank you. > From bengelly at gmail.com Thu Jan 18 20:11:39 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Thu, 18 Jan 2018 21:11:39 +0100 Subject: Cogent ops contact In-Reply-To: References: Message-ID: <7E4445F5-1E30-43C2-BA52-889D84F03BD7@gmail.com> Hi, Issue is I’m not a cogent customer. Best regards. > Le 18 janv. 2018 à 21:04, Alistair Mackenzie a écrit : > > I've had no problem dealing with their noc on these sort of issues in the past. > >> On 18 Jan 2018 10:54, "Youssef Bengelloun-Zahr" wrote: >> Dear Nanog community, >> >> I have an issue with a client trying to reach an IP that has been >> blackholed on Cogent backbone for shady "security reasons". >> >> Can someone reach out in MP please ? >> >> Thank you. From dovid at telecurve.com Thu Jan 18 20:21:53 2018 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 18 Jan 2018 15:21:53 -0500 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: Vincent, Thanks. That URL explained a lot. On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat wrote: > ❦ 8 janvier 2018 15:08 -0800, joel jaeggli : > > >> N00b here trying to understand why certain CDN's such as Cloudfare have > >> issues where my MTU is low. For instance if I am using pptp and the MTU > is > >> at 1300 it wont work. If I increase to 1478 it may or may not work. > > PMTUD has a lot of trouble working reliability when the destination of > > the PTB is a stateless load-balancer. > > More explanations are available here: > https://blog.cloudflare.com/path-mtu-discovery-in-practice/ > -- > Don't comment bad code - rewrite it. > - The Elements of Programming Style (Kernighan & Plauger) > From aaron1 at gvtc.com Thu Jan 18 20:22:35 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 18 Jan 2018 14:22:35 -0600 Subject: Cogent ops contact In-Reply-To: References: Message-ID: <002301d3909a$1402d690$3c0883b0$@gvtc.com> Going off of old notes... 1-877-726-4368 Prompts 2,2 support at cogentco.com -Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Youssef Bengelloun-Zahr Sent: Thursday, January 18, 2018 4:53 AM To: NANOG ‎[nanog at nanog.org]‎ Subject: Cogent ops contact Dear Nanog community, I have an issue with a client trying to reach an IP that has been blackholed on Cogent backbone for shady "security reasons". Can someone reach out in MP please ? Thank you. From arivera at pccwglobal.com Thu Jan 18 20:24:43 2018 From: arivera at pccwglobal.com (Rivera, Alberto) Date: Thu, 18 Jan 2018 20:24:43 +0000 (GMT+00:00) Subject: Greenland DSL or Internet service provider? Message-ID: <01b101d3909a$61e7a250$25b6e6f0$@pccwglobal.com> We are searching for a provider who can deliver MPLS, dedicated circuit, DSL or Internet by cable access to the following GPS information address: Greenland Quanaaq GPS: 76°30'58.4"N 68°36'03.7"W Any ideas? Thank you! Alberto Rivera PreSales Engineer – Enterprise Sales PCCW Global 450 Spring Park Place Suite 100 Herndon, VA 20170 Tel: +1(703)774-9459 Office | + 1(571)315-5309 Cell Email: arivera at pccwglobal.com Website: www.pccwglobal.com To view PCCW Global’s communication videos click here cid:9f4812ce-f4a5-4441-a4e4-1d77c1ee1ad7 cid:21f87991-196a-41be-a978-deb2e5059c9b cid:1d9fa650-71e3-4e53-a84f-f92859afadfa cid:e396fb8d-688f-4d85-befe-85c9f88f81c9 cid:0e7d23dc-f767-4fec-b036-a8410443413f From edugas at unknowndevice.ca Thu Jan 18 20:38:07 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Thu, 18 Jan 2018 15:38:07 -0500 Subject: Greenland DSL or Internet service provider? In-Reply-To: <01b101d3909a$61e7a250$25b6e6f0$@pccwglobal.com> References: <01b101d3909a$61e7a250$25b6e6f0$@pccwglobal.com> Message-ID: Pretty sure there's not a lot of provider and there's probably one national infrastructure (a bit like Iceland). Try contacting Telepost as they seem to be the only provider in the country: https://telepost.gl/en/english/liberalized-wholesale On Thu, Jan 18, 2018 at 3:24 PM, Rivera, Alberto wrote: > We are searching for a provider who can deliver MPLS, dedicated circuit, > DSL or Internet by cable access to the following GPS information address: > > > > Greenland > > Quanaaq > > GPS: 76°30'58.4"N 68°36'03.7"W > > > > Any ideas? > > > > Thank you! > > > > Alberto Rivera > > PreSales Engineer – Enterprise Sales > > PCCW Global > > 450 Spring Park Place > > Suite 100 > > Herndon, VA 20170 > > Tel: +1(703)774-9459 Office | + 1(571)315-5309 Cell > > Email: arivera at pccwglobal.com > > Website: www.pccwglobal.com > > To view PCCW Global’s communication videos > click here > > > cid:9f4812ce-f4a5-4441-a4e4-1d77c1ee1ad7 > > > cid:21f87991-196a-41be-a978-deb2e5059c9b > > > cid:1d9fa650-71e3-4e53-a84f-f92859afadfa > > > cid:e396fb8d-688f-4d85-befe-85c9f88f81c9 > > > cid:0e7d23dc-f767-4fec-b036-a8410443413f > > > > From johnl at iecc.com Thu Jan 18 20:56:09 2018 From: johnl at iecc.com (John Levine) Date: 18 Jan 2018 15:56:09 -0500 Subject: Greenland DSL or Internet service provider? In-Reply-To: <01b101d3909a$61e7a250$25b6e6f0$@pccwglobal.com> Message-ID: <20180118205610.A554419477F7@ary.qy> In article <01b101d3909a$61e7a250$25b6e6f0$@pccwglobal.com> you write: >We are searching for a provider who can deliver MPLS, dedicated circuit, >DSL or Internet by cable access to the following GPS information address: > >Quanaaq Assuming you mean Qaanaaq, the place formerly known as Thule, your only option is the national carrier Telepost. They claim to provide broadband service to every community with a population of 70 or more, and there are 650 in Qaanaaq, so you should be in good shape. There are only about 50,000 people in all of Greenland, which is consierably larger than Alaska, so it's not like it's a highly competitive market. R's, John From ggm at algebras.org Thu Jan 18 22:53:36 2018 From: ggm at algebras.org (George Michaelson) Date: Fri, 19 Jan 2018 08:53:36 +1000 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: if I was an ISP (Im not) and a CDN came and said "we want to be inside you" (ewww) why wouldn't I say "sure: lets jumbo" not even "asking for a friend" I genuinely don't understand why a CDN who colocates and is not using public exchange, but is inside your transit boundary (which I am told is actually a bit thing now) would not drive to the packet size which works in your switching gear. I understand that CDN/DC praxis now drives to cheap dumb switches, but even dumb switches like bigger packets dont they? less forwarding decision cost, for more throughput? On Fri, Jan 19, 2018 at 6:21 AM, Dovid Bender wrote: > Vincent, > > Thanks. That URL explained a lot. > > On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat wrote: > >> ❦ 8 janvier 2018 15:08 -0800, joel jaeggli : >> >> >> N00b here trying to understand why certain CDN's such as Cloudfare have >> >> issues where my MTU is low. For instance if I am using pptp and the MTU >> is >> >> at 1300 it wont work. If I increase to 1478 it may or may not work. >> > PMTUD has a lot of trouble working reliability when the destination of >> > the PTB is a stateless load-balancer. >> >> More explanations are available here: >> https://blog.cloudflare.com/path-mtu-discovery-in-practice/ >> -- >> Don't comment bad code - rewrite it. >> - The Elements of Programming Style (Kernighan & Plauger) >> From marka at isc.org Thu Jan 18 23:50:42 2018 From: marka at isc.org (Mark Andrews) Date: Fri, 19 Jan 2018 10:50:42 +1100 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: Because the CDN delivers to your customers not you. It’s your customers link requirements that are the ones you need to worry about. If you support jumbo frames to all of your customers and their gear also supports jumbo frame then sure go ahead and use jumbo frames otherwise use the lowest common denominator MTU when transmitting. This is less than 1500 on today Internet and encapsulated traffic is reasonable common. embedded CND <--> NAT64 <--> CLAT <--> client 1500 14XX 1500 embedded CDN <--> B4 <— > 6RD <— > client 1500. 14XX 1500 Now you can increase the first 1500 easily. The rest of the path not so easily. > On 19 Jan 2018, at 9:53 am, George Michaelson wrote: > > if I was an ISP (Im not) and a CDN came and said "we want to be inside > you" (ewww) why wouldn't I say "sure: lets jumbo" > > not even "asking for a friend" I genuinely don't understand why a CDN > who colocates and is not using public exchange, but is inside your > transit boundary (which I am told is actually a bit thing now) would > not drive to the packet size which works in your switching gear. > > I understand that CDN/DC praxis now drives to cheap dumb switches, but > even dumb switches like bigger packets dont they? less forwarding > decision cost, for more throughput? > > On Fri, Jan 19, 2018 at 6:21 AM, Dovid Bender wrote: >> Vincent, >> >> Thanks. That URL explained a lot. >> >> On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat wrote: >> >>> ❦ 8 janvier 2018 15:08 -0800, joel jaeggli : >>> >>>>> N00b here trying to understand why certain CDN's such as Cloudfare have >>>>> issues where my MTU is low. For instance if I am using pptp and the MTU >>> is >>>>> at 1300 it wont work. If I increase to 1478 it may or may not work. >>>> PMTUD has a lot of trouble working reliability when the destination of >>>> the PTB is a stateless load-balancer. >>> >>> More explanations are available here: >>> https://blog.cloudflare.com/path-mtu-discovery-in-practice/ >>> -- >>> Don't comment bad code - rewrite it. >>> - The Elements of Programming Style (Kernighan & Plauger) >>> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ggm at algebras.org Thu Jan 18 23:56:09 2018 From: ggm at algebras.org (George Michaelson) Date: Fri, 19 Jan 2018 09:56:09 +1000 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: thanks. good answer. low risk answer. "it will work" answer. If its a variant of "the last mile is your problem" problem, I'm ok with that. If its a consequence of the middleware deployment I feel like its more tangibly bad decision logic, but its real. -G On Fri, Jan 19, 2018 at 9:50 AM, Mark Andrews wrote: > Because the CDN delivers to your customers not you. It’s your customers link > requirements that are the ones you need to worry about. If you support > jumbo frames to all of your customers and their gear also supports jumbo > frame then sure go ahead and use jumbo frames otherwise use the lowest > common denominator MTU when transmitting. This is less than 1500 on > today Internet and encapsulated traffic is reasonable common. > > embedded CND <--> NAT64 <--> CLAT <--> client > 1500 14XX 1500 > embedded CDN <--> B4 <— > 6RD <— > client > 1500. 14XX 1500 > > Now you can increase the first 1500 easily. The rest of the path not so > easily. > >> On 19 Jan 2018, at 9:53 am, George Michaelson wrote: >> >> if I was an ISP (Im not) and a CDN came and said "we want to be inside >> you" (ewww) why wouldn't I say "sure: lets jumbo" >> >> not even "asking for a friend" I genuinely don't understand why a CDN >> who colocates and is not using public exchange, but is inside your >> transit boundary (which I am told is actually a bit thing now) would >> not drive to the packet size which works in your switching gear. >> >> I understand that CDN/DC praxis now drives to cheap dumb switches, but >> even dumb switches like bigger packets dont they? less forwarding >> decision cost, for more throughput? >> >> On Fri, Jan 19, 2018 at 6:21 AM, Dovid Bender wrote: >>> Vincent, >>> >>> Thanks. That URL explained a lot. >>> >>> On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat wrote: >>> >>>> ❦ 8 janvier 2018 15:08 -0800, joel jaeggli : >>>> >>>>>> N00b here trying to understand why certain CDN's such as Cloudfare have >>>>>> issues where my MTU is low. For instance if I am using pptp and the MTU >>>> is >>>>>> at 1300 it wont work. If I increase to 1478 it may or may not work. >>>>> PMTUD has a lot of trouble working reliability when the destination of >>>>> the PTB is a stateless load-balancer. >>>> >>>> More explanations are available here: >>>> https://blog.cloudflare.com/path-mtu-discovery-in-practice/ >>>> -- >>>> Don't comment bad code - rewrite it. >>>> - The Elements of Programming Style (Kernighan & Plauger) >>>> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From jared at puck.nether.net Fri Jan 19 00:14:00 2018 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 18 Jan 2018 19:14:00 -0500 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: > On Jan 18, 2018, at 5:53 PM, George Michaelson wrote: > > if I was an ISP (Im not) and a CDN came and said "we want to be inside > you" (ewww) why wouldn't I say "sure: lets jumbo" > > not even "asking for a friend" I genuinely don't understand why a CDN > who colocates and is not using public exchange, but is inside your > transit boundary (which I am told is actually a bit thing now) would > not drive to the packet size which works in your switching gear. > > I understand that CDN/DC praxis now drives to cheap dumb switches, but > even dumb switches like bigger packets dont they? less forwarding > decision cost, for more throughput? The reason is most customers are at a lower MTU size. lets say i can send you a 9K packet. If you receive that frame, and realize you need to fragment, then it’s your routers job to slice 9000 into 5 x 1500. I may have caused you to hit your exception path (which could be expensive) as well as made your PPS load 5x larger downstream. This doesn’t even account for the fact that you may need to have a speed mismatch, whereby I am sending 100Gb+ and your outputs may be only 10G. If you’re then doing DSL + PPPoE and your customers really see a MTU of 1492 or less, then another device has to fragment 5x again. For server to server, 9K makes a lot of sense, it reduces the packet processing and increases the throughput. If your consumer electronic wifi gear or switch can’t handle >1500, and doesn’t even have a setting for layer-2 > 1500, the cost is just too high. Much easier for me to send 5x packets in the first place and be more compatible. Like many things, I’d love for this to be as simple and purist as you purport. I might even be willing to figure out if at $DayJob we could see a benefit from doing this, but from the servers to switches to routers then a partner interface.. it’s a lot of things to make sure are just right. Plus.. can your phone do > 1500 MTU on the Wifi? Where’s that setting? (mumbling person about CSLIP and MRUs from back in the day) - Jared From bill at herrin.us Fri Jan 19 00:32:43 2018 From: bill at herrin.us (William Herrin) Date: Thu, 18 Jan 2018 19:32:43 -0500 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch wrote: > lets say i can > send you a 9K packet. If you receive that frame, and realize you need > to fragment, then it’s your routers job to slice 9000 into 5 x 1500. In practice, no, because the packet you sent had the "don't fragment" bit set. That means my router is not allowed to fragment the packet. Instead, I must send the originating host an ICMP destination unreachable packet stating that the largest packet I can send further is 1500 bytes. You might receive my ICMP message. You might not. After all, I am not the host you were looking for. Good luck. Regards, Bill Herrin P.S. This makes Linux servers happy: iptables -t mangle --insert POSTROUTING --proto tcp \ --tcp-flags SYN,RST,FIN SYN --match tcpmss --mss 1241:65535 \ --jump TCPMSS --set-mss 1240 -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From owen at delong.com Fri Jan 19 00:37:17 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Jan 2018 16:37:17 -0800 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: > On Jan 18, 2018, at 4:32 PM, William Herrin wrote: > > On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch wrote: >> lets say i can >> send you a 9K packet. If you receive that frame, and realize you need >> to fragment, then it’s your routers job to slice 9000 into 5 x 1500. > > In practice, no, because the packet you sent had the "don't fragment" > bit set. That means my router is not allowed to fragment the packet. > Instead, I must send the originating host an ICMP destination > unreachable packet stating that the largest packet I can send further > is 1500 bytes. > > You might receive my ICMP message. You might not. After all, I am not > the host you were looking for. This gets especially bad in cases such as anycast where the return path may be asymmetrical and could result in delivery of the ICMP PTB message to a different anycast instance or to a stateless load balancer that is incapable of determining which machine originated the packet being referenced. One of the many reasons I continue to question the wisdom of using anycast for multi-packet transactions. Owen > > Good luck. > > Regards, > Bill Herrin > > > P.S. This makes Linux servers happy: > > iptables -t mangle --insert POSTROUTING --proto tcp \ > --tcp-flags SYN,RST,FIN SYN --match tcpmss --mss 1241:65535 \ > --jump TCPMSS --set-mss 1240 > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From jared at puck.nether.net Fri Jan 19 00:41:37 2018 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 18 Jan 2018 19:41:37 -0500 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: <3FCDA91E-2602-4911-AB08-C93E1A18EE70@puck.nether.net> > On Jan 18, 2018, at 7:32 PM, William Herrin wrote: > > On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch wrote: >> lets say i can >> send you a 9K packet. If you receive that frame, and realize you need >> to fragment, then it’s your routers job to slice 9000 into 5 x 1500. > > In practice, no, because the packet you sent had the "don't fragment" > bit set. Which packet? Is there a specific CDN that does this? I’d be curious to see data vs speculation. > That means my router is not allowed to fragment the packet. > Instead, I must send the originating host an ICMP destination > unreachable packet stating that the largest packet I can send further > is 1500 bytes. > > You might receive my ICMP message. You might not. After all, I am not > the host you were looking for. :-) Nor is it likely the reply. - Jared From bill at herrin.us Fri Jan 19 01:44:20 2018 From: bill at herrin.us (William Herrin) Date: Thu, 18 Jan 2018 20:44:20 -0500 Subject: MTU to CDN's In-Reply-To: <3FCDA91E-2602-4911-AB08-C93E1A18EE70@puck.nether.net> References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> <3FCDA91E-2602-4911-AB08-C93E1A18EE70@puck.nether.net> Message-ID: On Thu, Jan 18, 2018 at 7:41 PM, Jared Mauch wrote: >> On Jan 18, 2018, at 7:32 PM, William Herrin wrote: >> >> On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch wrote: >>> lets say i can >>> send you a 9K packet. If you receive that frame, and realize you need >>> to fragment, then it’s your routers job to slice 9000 into 5 x 1500. >> >> In practice, no, because the packet you sent had the "don't fragment" >> bit set. > > Which packet? Is there a specific CDN that does this? I’d be curious to see > data vs speculation. Howdy, Path MTU discovery (which sets the DF bit on TCP packets) is enabled by default on -every- operating system that's shipped for decades now. If you don't want it, you have to explicitly disable it. Disabling it for any significant quantity of traffic is considered antisocial since routers generally can't fragment in the hardware fast path. Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From eron at mawcom.com Fri Jan 19 03:25:56 2018 From: eron at mawcom.com (Eron Lloyd) Date: Thu, 18 Jan 2018 22:25:56 -0500 (EST) Subject: Open Souce Network Operating Systems In-Reply-To: References: Message-ID: <1413312135.78963.1516332356885.JavaMail.zimbra@mawcom.com> I would start with following the Free Range Routing project, and related but independent (and more tangible) projects like pfSense (esp. the upcoming 3.0 release) and Cumulus Linux. Going deeper, perhaps Carrier Grade Linux, DPDK, and ONOS (all Linux Foundation projects). I think scaling vertically from CPEs to core stack is a stretch, especially if you mean a DIY approach, however. ----- Original Message ----- From: "Colton Conor" To: "nanog" Sent: Wednesday, January 17, 2018 9:28:13 AM Subject: Open Souce Network Operating Systems If one were to deploy whitebox switches, X86 servers, low cost ARM and MIBPS CPE devices, and basically anything that can run linux today, what network operating system would you recommend? The goal would be to have a universal network operating system that runs across a variety of devices. >From low cost residential CPE's with wifi to switches to BGP speaking routers. Is there anything that can do it all today? I will use something like OpenWRT as an example. I don't consider this anywhere near carrier grade, but it runs on X86 and low cost routers. I don't think it will run on whitebox switches though. Mikrotik RouterOS would be another example as it can run on low cost Routerboards, and X86 servers. But it is not opensouce. Is there any up and coming projects to look into? -- Eron Lloyd Information Technology Director 717-344-5958 eron at mawcom.com MAW Communications, Inc. From bernat at luffy.cx Fri Jan 19 04:47:50 2018 From: bernat at luffy.cx (Vincent Bernat) Date: Fri, 19 Jan 2018 05:47:50 +0100 Subject: MTU to CDN's In-Reply-To: (George Michaelson's message of "Fri, 19 Jan 2018 08:53:36 +1000") References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: <87o9lqwj2h.fsf@luffy.cx> ❦ 19 janvier 2018 08:53 +1000, George Michaelson  : > if I was an ISP (Im not) and a CDN came and said "we want to be inside > you" (ewww) why wouldn't I say "sure: lets jumbo" Most traffic would be with clients limited to at most 1500 bytes. -- Its name is Public Opinion. It is held in reverence. It settles everything. Some think it is the voice of God. -- Mark Twain From michael at wi-fiber.io Fri Jan 19 06:46:29 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Thu, 18 Jan 2018 23:46:29 -0700 Subject: MTU to CDN's In-Reply-To: <87k1wewe98.fsf@luffy.cx> References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> Message-ID: I don't mind letting the client premises routers break down 9000 byte packets. My ISP controls end to end connectivity. 80% of people even let our techs change settings on their computer, this would allow me to give ~5% increase in speeds, and less network congestion for end users for a one time $60 service many people would want. It's also where the internet should be heading... Not to beat a dead horse(re:ipv6 ) but why hasn't the entire internet just moved to 9000(or 9600 L2) byte MTU? It was created for the jump to gigabit... That's 4 orders of magnitude ago. The internet backbone shouldn't be shuffling around 1500byte packets at 1tbps. That means if you want to layer 3 that data, you need a router capable of more than half a billion packets/s forwarding capacity. On the other hand, with even just a 9000 byte MTU, TCP/IP overhead is reduced 6 fold, and forwarding capacity needs just 100 or so mpps capacity. Routers that forward at that rate are found for less than $2k. On 18 January 2018 at 23:31, Vincent Bernat wrote: > ❦ 18 janvier 2018 22:06 -0700, Michael Crapse : > > > Why though? If i could get the major CDNs all inside my network willing > to > > run 9000 byte packets, My routers just got that much cheaper and less > > loaded. The Routing capacity of x86 is hindered only by forwarding > > capacity(PPS), not data line rate. > > Unless your clients use a 9000-byte MTU, you won't see a difference but > you'll have to deal with broken PMTUD (or have your routers fragment). > -- > Many a writer seems to think he is never profound except when he can't > understand his own meaning. > -- George D. Prentice > From swmike at swm.pp.se Fri Jan 19 07:22:02 2018 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 19 Jan 2018 08:22:02 +0100 (CET) Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> Message-ID: On Thu, 18 Jan 2018, Michael Crapse wrote: > I don't mind letting the client premises routers break down 9000 byte > packets. My ISP controls end to end connectivity. 80% of people even let > our techs change settings on their computer, this would allow me to give > ~5% increase in speeds, and less network congestion for end users for a one > time $60 service many people would want. It's also where the internet > should be heading... Not to beat a dead horse(re:ipv6 ) but why hasn't the > entire internet just moved to 9000(or 9600 L2) byte MTU? It was created for > the jump to gigabit... That's 4 orders of magnitude ago. The internet > backbone shouldn't be shuffling around 1500byte packets at 1tbps. That > means if you want to layer 3 that data, you need a router capable of more > than half a billion packets/s forwarding capacity. On the other hand, with > even just a 9000 byte MTU, TCP/IP overhead is reduced 6 fold, and > forwarding capacity needs just 100 or so mpps capacity. Routers that > forward at that rate are found for less than $2k. As usual, there are 5-10 (or more) factors playing into this. Some, in random order: 1. IEEE hasn't standardised > 1500 byte ethernet packets 2. DSL/WIFI chips typically don't support > ~2300 because reasons. 3. Because 2, most SoC ethernet chips don't either 4. There is no standardised way to understand/probe the L2 MTU to your next hop (ARP/ND and probing if the value actually works) 5. PMTUD doesn't always work. 6. PLPMTUD hasn't been implemented neither in protocols nor hosts generally. 7. Some implementations have been optimized to work on packets < 2000 bytes and actually has less performance than if they have to support larger packets (they will allocate 2k buffer memory per packet), 9k is ill-fitting across 2^X values 8. Because of all above reasons, mixed-MTU LAN doesn't work, and it's going to be mixed-MTU unless you control all devices (which is typically not the case outside of the datacenter). 9. The PPS problem in hosts and routers was solved by hardware offloading to NICs and forwarding NPUs/ASICs with very high lookup speeds where PPS no longer was a big problem. On the value to choose for "large MTU", 9000 for edge and 9180 for core is what I advocate, after non-trivial amount of looking into this. All major core routing platforms work with 9180 (with JunOS only supporting this after 2015 or something). So if we'd want to standardise on MTU that all devices should support, then it's 9180, but we'd typically use 9000 in RA to send to devices. If we want a higher MTU to be deployable across the Internet, we need to make it incrementally deployable. Some key things to achieve that: 1. Get something like https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 implemented. 2. Go to the IETF and get a document published that advises all protocols to support PLMTUD (RFC4821) 1 to enable mixed-MTU lans. 2 to enable large MTU hosts to actually be able to communicate when PMTUD doesn't work. With this in place (wait ~10 years), larger MTU is now incrementally deployable which means it'll be deployable on the Internet, and IEEE might actually accept to standardise > 1500 byte packets for ethernet. -- Mikael Abrahamsson email: swmike at swm.pp.se From arturo.servin at gmail.com Fri Jan 19 11:50:10 2018 From: arturo.servin at gmail.com (Arturo Servin) Date: Fri, 19 Jan 2018 12:50:10 +0100 Subject: Peering Forum LAC: Call for Presentations Message-ID: The Latin American and Caribbean Peering Forum LACPF-2018 will be held in Panama City, Panama on the April 30th, 2018. The goal of the LACPF is to promote and provide collaboration spaces in topics related to interconnection and peering, IXPs, CDNs, transport capacity, and colo facilities among others. >From this edition, the LACPF will change to the more know format that other Peering Forums have. The event will be a day long, the first half for talks and presentations and the second half for work and negotiation sessions. The LACPF-2018 Program Committee invites the Internet community to submit their presentations for the event. The topics of interest to LACNOG 2017 include, but are not limited to: - Topics related to interconnection, peering, routing, and content distribution networks - Best Practices - Success cases - IPv6 Deployment - Scalability - Challenges - Deployment projects - Monitoring and network management - Network operation and professional experiences, success stories - Infrastructure - Critical Systems - Disaster recovery - SDX - Services - DNS / DNSSEC / IDNs. - CDNs. - Cooperation - Synergies with operators and government - Relation between universities and network operators Presentations must be submitted according to the following schedule:: - Reception of drafts and abstracts: 23 March 2018 - Evaluation by the Program Committee: By April 6th 2018 - Submission of the final presentation: April 16th 2018 - Event date: April 30th 2018 All submissions must meet the following requirements: - Proposals must be submitted in English, Portuguese or Spanish. - Accepted formats: Microsoft Powerpoint (PPT, PPTX), Apache OpenOffice Presentation (ODP), LibreOffice Impress (ODP), or Portable Document Format (PDF). - The number of slides must be appropriate for the time assigned for the presentation. As a rule of thumb, estimate 1-2 minutes per slide. Please send works to cp-pf-lac at googlegroups.com with the following: - Title - Summary or Extended Abstract. No more than 500 words. - Name, email, organization Program Committee - Gabriel Adonaylo - Flavio Amaral - Hernán Arcidiacono - Guillermo Cicileo - Milton Kashiwakura - Fabian Mejia - Christian O’Flaherty - Mauricio Oviedo - From nanog at ics-il.net Fri Jan 19 13:48:07 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 19 Jan 2018 07:48:07 -0600 (CST) Subject: MTU to CDN's In-Reply-To: References: <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> Message-ID: <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> Other than people improperly blocking ICMP, when does PMTUD not work? Honest question, not troll. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mikael Abrahamsson" To: "Michael Crapse" Cc: "NANOG list" Sent: Friday, January 19, 2018 1:22:02 AM Subject: Re: MTU to CDN's On Thu, 18 Jan 2018, Michael Crapse wrote: > I don't mind letting the client premises routers break down 9000 byte > packets. My ISP controls end to end connectivity. 80% of people even let > our techs change settings on their computer, this would allow me to give > ~5% increase in speeds, and less network congestion for end users for a one > time $60 service many people would want. It's also where the internet > should be heading... Not to beat a dead horse(re:ipv6 ) but why hasn't the > entire internet just moved to 9000(or 9600 L2) byte MTU? It was created for > the jump to gigabit... That's 4 orders of magnitude ago. The internet > backbone shouldn't be shuffling around 1500byte packets at 1tbps. That > means if you want to layer 3 that data, you need a router capable of more > than half a billion packets/s forwarding capacity. On the other hand, with > even just a 9000 byte MTU, TCP/IP overhead is reduced 6 fold, and > forwarding capacity needs just 100 or so mpps capacity. Routers that > forward at that rate are found for less than $2k. As usual, there are 5-10 (or more) factors playing into this. Some, in random order: 1. IEEE hasn't standardised > 1500 byte ethernet packets 2. DSL/WIFI chips typically don't support > ~2300 because reasons. 3. Because 2, most SoC ethernet chips don't either 4. There is no standardised way to understand/probe the L2 MTU to your next hop (ARP/ND and probing if the value actually works) 5. PMTUD doesn't always work. 6. PLPMTUD hasn't been implemented neither in protocols nor hosts generally. 7. Some implementations have been optimized to work on packets < 2000 bytes and actually has less performance than if they have to support larger packets (they will allocate 2k buffer memory per packet), 9k is ill-fitting across 2^X values 8. Because of all above reasons, mixed-MTU LAN doesn't work, and it's going to be mixed-MTU unless you control all devices (which is typically not the case outside of the datacenter). 9. The PPS problem in hosts and routers was solved by hardware offloading to NICs and forwarding NPUs/ASICs with very high lookup speeds where PPS no longer was a big problem. On the value to choose for "large MTU", 9000 for edge and 9180 for core is what I advocate, after non-trivial amount of looking into this. All major core routing platforms work with 9180 (with JunOS only supporting this after 2015 or something). So if we'd want to standardise on MTU that all devices should support, then it's 9180, but we'd typically use 9000 in RA to send to devices. If we want a higher MTU to be deployable across the Internet, we need to make it incrementally deployable. Some key things to achieve that: 1. Get something like https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 implemented. 2. Go to the IETF and get a document published that advises all protocols to support PLMTUD (RFC4821) 1 to enable mixed-MTU lans. 2 to enable large MTU hosts to actually be able to communicate when PMTUD doesn't work. With this in place (wait ~10 years), larger MTU is now incrementally deployable which means it'll be deployable on the Internet, and IEEE might actually accept to standardise > 1500 byte packets for ethernet. -- Mikael Abrahamsson email: swmike at swm.pp.se From jared at puck.nether.net Fri Jan 19 13:58:19 2018 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 19 Jan 2018 08:58:19 -0500 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> <3FCDA91E-2602-4911-AB08-C93E1A18EE70@puck.nether.net> Message-ID: > On Jan 18, 2018, at 8:44 PM, William Herrin wrote: > >> Which packet? Is there a specific CDN that does this? I’d be curious to see >> data vs speculation. > > Howdy, > > Path MTU discovery (which sets the DF bit on TCP packets) is enabled > by default on -every- operating system that's shipped for decades now. > If you don't want it, you have to explicitly disable it. Disabling it > for any significant quantity of traffic is considered antisocial since > routers generally can't fragment in the hardware fast path. I’m not seeing this in a PCAP capture to at least one CDN, either from my host or from the CDN endpoint. I suspect you’re mistaken. - Jared PCAP: https://puck.nether.net/~jared/akamai.pcap From jared at puck.nether.net Fri Jan 19 14:01:11 2018 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 19 Jan 2018 09:01:11 -0500 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> <3FCDA91E-2602-4911-AB08-C93E1A18EE70@puck.nether.net> Message-ID: Bah, never mind.. reading my PCAP wrong :-( > On Jan 19, 2018, at 8:58 AM, Jared Mauch wrote: > > > >> On Jan 18, 2018, at 8:44 PM, William Herrin wrote: >> >>> Which packet? Is there a specific CDN that does this? I’d be curious to see >>> data vs speculation. >> >> Howdy, >> >> Path MTU discovery (which sets the DF bit on TCP packets) is enabled >> by default on -every- operating system that's shipped for decades now. >> If you don't want it, you have to explicitly disable it. Disabling it >> for any significant quantity of traffic is considered antisocial since >> routers generally can't fragment in the hardware fast path. > > I’m not seeing this in a PCAP capture to at least one CDN, either from my > host or from the CDN endpoint. > > I suspect you’re mistaken. > > - Jared > > PCAP: https://puck.nether.net/~jared/akamai.pcap From swmike at swm.pp.se Fri Jan 19 14:05:17 2018 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 19 Jan 2018 15:05:17 +0100 (CET) Subject: MTU to CDN's In-Reply-To: <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> References: <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, 19 Jan 2018, Mike Hammett wrote: > Other than people improperly blocking ICMP, when does PMTUD not work? > Honest question, not troll. Mismatch of MTU interface settings between interfaces, mismatch of MTU between L3 devices and intermediate L2 devices, anycast services, ECMP based services where the ICMP error is delivered to the wrong node. So yes, there are plenty reasons that PMTUD doesn't work without anyone doing it because of ill will or incompetence. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at ics-il.net Fri Jan 19 14:07:09 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 19 Jan 2018 08:07:09 -0600 (CST) Subject: MTU to CDN's In-Reply-To: References: <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> Message-ID: <1786714545.880.1516370827342.JavaMail.mhammett@ThunderFuck> Wouldn't those situations be causing issues now, given the likelihood that someone with a less than 1,500 byte MTU is communicating with you now? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mikael Abrahamsson" To: "Mike Hammett" Cc: "NANOG list" Sent: Friday, January 19, 2018 8:05:17 AM Subject: Re: MTU to CDN's On Fri, 19 Jan 2018, Mike Hammett wrote: > Other than people improperly blocking ICMP, when does PMTUD not work? > Honest question, not troll. Mismatch of MTU interface settings between interfaces, mismatch of MTU between L3 devices and intermediate L2 devices, anycast services, ECMP based services where the ICMP error is delivered to the wrong node. So yes, there are plenty reasons that PMTUD doesn't work without anyone doing it because of ill will or incompetence. -- Mikael Abrahamsson email: swmike at swm.pp.se From bengelly at gmail.com Fri Jan 19 14:09:07 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Fri, 19 Jan 2018 15:09:07 +0100 Subject: China is beefing up filtering measures Message-ID: Dear Nanogers, By now, I'm pretty that the community has heard that china is planning to increase (once again) filtering measures by limiting ports 80 / 443 / 8080 : https://www.reddit.com/r/China/comments/7opv4f/china_to_block_sdwan_and_vpn_traffic_by_jan_11/ https://www.goldenfrog.com/blog/article-claims-china-block-vpns-causing-confusion https://www.sd-wan-experts.com/blog/china-stops-sd-wans-cold-register/ https://www.networkworld.com/article/3247705/sd-wan/will-china-start-blocking-sd-wan-traffic-today.html I've been doing some googling (read above) and I have come to the following conclusions : - Only clear thing is that a "commercial" ISP can register with CN gov to lift that filtering ? - This should be enforced by Feb, 1st. - Pretty much all the rest is unclear when it comes to the : who ? what ? how ? I'm trying to understand exactly what we might be dealing with here. Do anyone happen to have a clear view on this ? Are some of you already affected by this ? Thank you for your feedbacks. Best regards. From ruairi.carroll at gmail.com Fri Jan 19 14:13:04 2018 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Fri, 19 Jan 2018 14:13:04 +0000 Subject: MTU to CDN's In-Reply-To: <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> References: <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> Message-ID: On 19 January 2018 at 13:48, Mike Hammett wrote: > Other than people improperly blocking ICMP, when does PMTUD not work? > Honest question, not troll. > > It can break under _certain_ scenarios with Anycast. It can break under _certain_ scenarios in v6 with ECMP. It can break across an LB in L4 mode, when a real behind the LB has an unexpected MSS. None of these scenarios are the normal, obviously, however PMTUD does have some edge-cases. /Ruairi > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Mikael Abrahamsson" > To: "Michael Crapse" > Cc: "NANOG list" > Sent: Friday, January 19, 2018 1:22:02 AM > Subject: Re: MTU to CDN's > > On Thu, 18 Jan 2018, Michael Crapse wrote: > > > I don't mind letting the client premises routers break down 9000 byte > > packets. My ISP controls end to end connectivity. 80% of people even let > > our techs change settings on their computer, this would allow me to give > > ~5% increase in speeds, and less network congestion for end users for a > one > > time $60 service many people would want. It's also where the internet > > should be heading... Not to beat a dead horse(re:ipv6 ) but why hasn't > the > > entire internet just moved to 9000(or 9600 L2) byte MTU? It was created > for > > the jump to gigabit... That's 4 orders of magnitude ago. The internet > > backbone shouldn't be shuffling around 1500byte packets at 1tbps. That > > means if you want to layer 3 that data, you need a router capable of more > > than half a billion packets/s forwarding capacity. On the other hand, > with > > even just a 9000 byte MTU, TCP/IP overhead is reduced 6 fold, and > > forwarding capacity needs just 100 or so mpps capacity. Routers that > > forward at that rate are found for less than $2k. > > As usual, there are 5-10 (or more) factors playing into this. Some, in > random order: > > 1. IEEE hasn't standardised > 1500 byte ethernet packets > 2. DSL/WIFI chips typically don't support > ~2300 because reasons. > 3. Because 2, most SoC ethernet chips don't either > 4. There is no standardised way to understand/probe the L2 MTU to your > next hop (ARP/ND and probing if the value actually works) > 5. PMTUD doesn't always work. > 6. PLPMTUD hasn't been implemented neither in protocols nor hosts > generally. > 7. Some implementations have been optimized to work on packets < 2000 > bytes and actually has less performance than if they have to support > larger packets (they will allocate 2k buffer memory per packet), 9k is > ill-fitting across 2^X values > 8. Because of all above reasons, mixed-MTU LAN doesn't work, and it's > going to be mixed-MTU unless you control all devices (which is typically > not the case outside of the datacenter). > 9. The PPS problem in hosts and routers was solved by hardware offloading > to NICs and forwarding NPUs/ASICs with very high lookup speeds where PPS > no longer was a big problem. > > On the value to choose for "large MTU", 9000 for edge and 9180 for core is > what I advocate, after non-trivial amount of looking into this. All major > core routing platforms work with 9180 (with JunOS only supporting this > after 2015 or something). So if we'd want to standardise on MTU that all > devices should support, then it's 9180, but we'd typically use 9000 in RA > to send to devices. > > If we want a higher MTU to be deployable across the Internet, we need to > make it incrementally deployable. Some key things to achieve that: > > 1. Get something like > https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 implemented. > 2. Go to the IETF and get a document published that advises all protocols > to support PLMTUD (RFC4821) > > 1 to enable mixed-MTU lans. > 2 to enable large MTU hosts to actually be able to communicate when PMTUD > doesn't work. > > With this in place (wait ~10 years), larger MTU is now incrementally > deployable which means it'll be deployable on the Internet, and IEEE might > actually accept to standardise > 1500 byte packets for ethernet. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > From jared at puck.nether.net Fri Jan 19 14:13:02 2018 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 19 Jan 2018 09:13:02 -0500 Subject: MTU to CDN's In-Reply-To: <1786714545.880.1516370827342.JavaMail.mhammett@ThunderFuck> References: <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> <1786714545.880.1516370827342.JavaMail.mhammett@ThunderFuck> Message-ID: > On Jan 19, 2018, at 9:07 AM, Mike Hammett wrote: > > Wouldn't those situations be causing issues now, given the likelihood that someone with a less than 1,500 byte MTU is communicating with you now? > Tends to be more localized and less visible in many cases. I’m aware of at least one regional network that has duplicate packet issues going on and they’ve yet to understand the root cause. This can have performance impacts that are not always understood. Things get harder to diagnose when there’s multiple paths, etc.. involved. Many folks these days just fail away from a seemingly problematic link quickly and don’t always identify the root cause. - jared From nanog at ics-il.net Fri Jan 19 14:14:40 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 19 Jan 2018 08:14:40 -0600 (CST) Subject: MTU to CDN's In-Reply-To: References: <87k1wewe98.fsf@luffy.cx> <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> <1786714545.880.1516370827342.JavaMail.mhammett@ThunderFuck> Message-ID: <1732355973.889.1516371277668.JavaMail.mhammett@ThunderFuck> "Many folks these days just fail away from a seemingly problematic link quickly and don’t always identify the root cause." Agreed. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Mike Hammett" Cc: "NANOG list" Sent: Friday, January 19, 2018 8:13:02 AM Subject: Re: MTU to CDN's > On Jan 19, 2018, at 9:07 AM, Mike Hammett wrote: > > Wouldn't those situations be causing issues now, given the likelihood that someone with a less than 1,500 byte MTU is communicating with you now? > Tends to be more localized and less visible in many cases. I’m aware of at least one regional network that has duplicate packet issues going on and they’ve yet to understand the root cause. This can have performance impacts that are not always understood. Things get harder to diagnose when there’s multiple paths, etc.. involved. Many folks these days just fail away from a seemingly problematic link quickly and don’t always identify the root cause. - jared From swmike at swm.pp.se Fri Jan 19 14:18:47 2018 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 19 Jan 2018 15:18:47 +0100 (CET) Subject: MTU to CDN's In-Reply-To: <1786714545.880.1516370827342.JavaMail.mhammett@ThunderFuck> References: <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> <1786714545.880.1516370827342.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, 19 Jan 2018, Mike Hammett wrote: > Wouldn't those situations be causing issues now, given the likelihood > that someone with a less than 1,500 byte MTU is communicating with you > now? If the issue is that you're letting 8996 byte packets through but not 9000 byte packets, then no. -- Mikael Abrahamsson email: swmike at swm.pp.se From bill at herrin.us Fri Jan 19 14:36:31 2018 From: bill at herrin.us (William Herrin) Date: Fri, 19 Jan 2018 09:36:31 -0500 Subject: MTU to CDN's In-Reply-To: <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> References: <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, Jan 19, 2018 at 8:48 AM, Mike Hammett wrote: > Other than people improperly blocking ICMP, when does PMTUD not work? > Honest question, not troll. > Hi Mike, One common scenario: the router's interface is numbered with an RFC 1918 private IP address. The packet is dropped because it tries to enter an adjacent system with a source address that isn't valid for the transit. Another common scenario: the packet is encapsulated in MPLS when it reaches the segment which can't handle the large packet. That particular router is not set up to decapsulate the MPLS packet and act on the IPv4 packet inside. A third scenario: asymmetric routing. A particular router is capable of moving packets to your destination but either intentionally or due to a configuration error is unable to route packets back to the source. A fourth scenario: for security reasons (part of defense in depth), a host is only permitted to communicate with whitelisted IP addresses. Random Internet routers are not on the whitelist. PMTUD's routine failure demonstrates the wisdom of the end to end principle. It's the one critical place in base IPv4 that doesn't follow it. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From olivier.benghozi at wifirst.fr Fri Jan 19 14:37:40 2018 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Fri, 19 Jan 2018 15:37:40 +0100 Subject: MTU to CDN's In-Reply-To: References: <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> Message-ID: And also: When the router generates the ICMP by punting the packet to its CPU and such traffic is - legitimately - rate-limited to avoir crashing the router. When the ICMP is sourced by a private IP on the router for various legitimate reasons (not enough public IPv4 addresses, from within a VRF, or whatever), while packets from private IPs are legitimately filtered when entering the target network. > Le 19 janv. 2018 à 15:05, Mikael Abrahamsson a écrit : > > On Fri, 19 Jan 2018, Mike Hammett wrote: > >> Other than people improperly blocking ICMP, when does PMTUD not work? Honest question, not troll. > > Mismatch of MTU interface settings between interfaces, mismatch of MTU between L3 devices and intermediate L2 devices, anycast services, ECMP based services where the ICMP error is delivered to the wrong node. > > So yes, there are plenty reasons that PMTUD doesn't work without anyone doing it because of ill will or incompetence. From bill at herrin.us Fri Jan 19 15:51:02 2018 From: bill at herrin.us (William Herrin) Date: Fri, 19 Jan 2018 10:51:02 -0500 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> <3FCDA91E-2602-4911-AB08-C93E1A18EE70@puck.nether.net> Message-ID: On Fri, Jan 19, 2018 at 8:58 AM, Jared Mauch wrote: >> On Jan 18, 2018, at 8:44 PM, William Herrin wrote: >>> Which packet? Is there a specific CDN that does this? I’d be curious to see >>> data vs speculation. >> >> Path MTU discovery (which sets the DF bit on TCP packets) is enabled >> by default on -every- operating system that's shipped for decades now. > > I’m not seeing this in a PCAP capture to at least one CDN, either from my > host or from the CDN endpoint. > PCAP: https://puck.nether.net/~jared/akamai.pcap Hi Jared, tcpdump -v -n -nn -r akamai.pcap |more reading from file akamai.pcap, link-type EN10MB (Ethernet) 08:54:48.611321 IP (tos 0x0, ttl 64, id 12596, offset 0, flags [DF], proto TCP (6), length 60) 204.42.254.5.60262 > 23.0.51.165.80: Flags [S], cksum 0x1504 (incorrect -> 0x5a14), seq 3315894416, win 29200, options [mss 1460,sackOK,TS val 3822930236 ecr 0,nop,wscale 7], length 0 08:54:48.633286 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto TCP (6), length 60) 23.0.51.165.80 > 204.42.254.5.60262: Flags [S.], cksum 0x0972 (correct), seq 3383397658, ack 3315894417, win 28960, options [mss 1460,sackOK,TS val 2906475904 ecr 3822930236,nop,wscale 5], length 0 Note: "flags [DF]" That means the don't fragment bit is set. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bernat at luffy.cx Fri Jan 19 15:54:17 2018 From: bernat at luffy.cx (Vincent Bernat) Date: Fri, 19 Jan 2018 16:54:17 +0100 Subject: MTU to CDN's In-Reply-To: <1786714545.880.1516370827342.JavaMail.mhammett@ThunderFuck> (Mike Hammett's message of "Fri, 19 Jan 2018 08:07:09 -0600 (CST)") References: <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> <1786714545.880.1516370827342.JavaMail.mhammett@ThunderFuck> Message-ID: ❦ 19 janvier 2018 08:07 -0600, Mike Hammett  : > Wouldn't those situations be causing issues now, given the likelihood > that someone with a less than 1,500 byte MTU is communicating with you > now? Those situations are causing issues now. If you have a MTU less than 1500 bytes, it is likely some destination are unreachable to you if you only rely on PMTUD. People usually rely on TCP MSS for those cases. -- I'll burn my books. -- Christopher Marlowe From bill at herrin.us Fri Jan 19 15:57:16 2018 From: bill at herrin.us (William Herrin) Date: Fri, 19 Jan 2018 10:57:16 -0500 Subject: MTU to CDN's In-Reply-To: <1786714545.880.1516370827342.JavaMail.mhammett@ThunderFuck> References: <87o9lqwj2h.fsf@luffy.cx> <87k1wewe98.fsf@luffy.cx> <2016421856.844.1516369686950.JavaMail.mhammett@ThunderFuck> <1786714545.880.1516370827342.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, Jan 19, 2018 at 9:07 AM, Mike Hammett wrote: > Wouldn't those situations be causing issues now, given the likelihood that someone with a less than 1,500 byte MTU is communicating with you now? Hi Mike, They do. These are the people calling your support line with the complaint that they can't get to your web site from home, but can from work (or vice versa). Your web site is "obviously" working and the calls are infrequent, so support advises there's a problem with the customer's ISP. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nanog at radu-adrian.feurdean.net Fri Jan 19 16:35:14 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Fri, 19 Jan 2018 17:35:14 +0100 Subject: MTU to CDN's In-Reply-To: References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> Message-ID: <1516379714.3410368.1241238760.0EE7863D@webmail.messagingengine.com> On Fri, Jan 19, 2018, at 01:14, Jared Mauch wrote: > If you’re then doing DSL + PPPoE and your customers really see a MTU > of 1492 or less, then another device has to fragment 5x again. In this part of the world we have even worse stuff around: PPP over L2TP over over IP with 1500 MTU interconnection. Remove another 40 bytes. Add some more headers for various tunneling scenarios and you may get into a situation where even 1400 is too much. But it usually works with MSS clamping to the correct value. Some small ISPs don't even make the effort to check if the transport supports "more than 1500" in order to give the 1500 bytes to the customer - they just clamp down MSS. From cscora at apnic.net Fri Jan 19 18:02:46 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Jan 2018 04:02:46 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180119180246.154FA1678@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, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 20 Jan, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 680586 Prefixes after maximum aggregation (per Origin AS): 264534 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 329232 Total ASes present in the Internet Routing Table: 59612 Prefixes per ASN: 11.42 Origin-only ASes present in the Internet Routing Table: 51475 Origin ASes announcing only one prefix: 22666 Transit ASes present in the Internet Routing Table: 8137 Transit-only ASes present in the Internet Routing Table: 237 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN ( 30873) 27 Prefixes from unregistered ASNs in the Routing Table: 70 Number of instances of unregistered ASNs: 71 Number of 32-bit ASNs allocated by the RIRs: 21228 Number of 32-bit ASNs visible in the Routing Table: 17018 Prefixes from 32-bit ASNs in the Routing Table: 70136 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 378 Number of addresses announced to Internet: 2863744674 Equivalent to 170 /8s, 177 /16s and 70 /24s Percentage of available address space announced: 77.4 Percentage of allocated address space announced: 77.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 224686 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 187938 Total APNIC prefixes after maximum aggregation: 53804 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 186983 Unique aggregates announced from the APNIC address blocks: 77824 APNIC Region origin ASes present in the Internet Routing Table: 8597 APNIC Prefixes per ASN: 21.75 APNIC Region origin ASes announcing only one prefix: 2437 APNIC Region transit ASes present in the Internet Routing Table: 1261 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3480 Number of APNIC addresses announced to Internet: 771640098 Equivalent to 45 /8s, 254 /16s and 75 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 202912 Total ARIN prefixes after maximum aggregation: 97721 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 204128 Unique aggregates announced from the ARIN address blocks: 95906 ARIN Region origin ASes present in the Internet Routing Table: 18064 ARIN Prefixes per ASN: 11.30 ARIN Region origin ASes announcing only one prefix: 6688 ARIN Region transit ASes present in the Internet Routing Table: 1786 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2295 Number of ARIN addresses announced to Internet: 1110297632 Equivalent to 66 /8s, 45 /16s and 204 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 183620 Total RIPE prefixes after maximum aggregation: 89617 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 179616 Unique aggregates announced from the RIPE address blocks: 108139 RIPE Region origin ASes present in the Internet Routing Table: 24826 RIPE Prefixes per ASN: 7.23 RIPE Region origin ASes announcing only one prefix: 11350 RIPE Region transit ASes present in the Internet Routing Table: 3508 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6576 Number of RIPE addresses announced to Internet: 713698944 Equivalent to 42 /8s, 138 /16s and 46 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 88059 Total LACNIC prefixes after maximum aggregation: 19402 LACNIC Deaggregation factor: 4.54 Prefixes being announced from the LACNIC address blocks: 89356 Unique aggregates announced from the LACNIC address blocks: 39848 LACNIC Region origin ASes present in the Internet Routing Table: 6752 LACNIC Prefixes per ASN: 13.23 LACNIC Region origin ASes announcing only one prefix: 1829 LACNIC Region transit ASes present in the Internet Routing Table: 1246 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4280 Number of LACNIC addresses announced to Internet: 172233952 Equivalent to 10 /8s, 68 /16s and 20 /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: 17985 Total AfriNIC prefixes after maximum aggregation: 3939 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 20125 Unique aggregates announced from the AfriNIC address blocks: 7240 AfriNIC Region origin ASes present in the Internet Routing Table: 1112 AfriNIC Prefixes per ASN: 18.10 AfriNIC Region origin ASes announcing only one prefix: 361 AfriNIC Region transit ASes present in the Internet Routing Table: 223 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 387 Number of AfriNIC addresses announced to Internet: 95472640 Equivalent to 5 /8s, 176 /16s and 204 /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 5427 4195 92 ERX-CERNET-BKB China Education and Rese 7545 3278 403 390 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2874 11130 768 KIXS-AS-KR Korea Telecom, KR 17974 2784 934 78 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2770 1499 540 BSNL-NIB National Internet Backbone, IN 9394 2636 4923 27 CTTNET China TieTong Telecommunications 45899 2569 1546 154 VNPT-AS-VN VNPT Corp, VN 7552 2535 1159 50 VIETEL-AS-AP Viettel Group, VN 9808 2117 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2083 417 209 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 3352 1323 86 SHAW - Shaw Communications Inc., CA 22773 3270 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2077 2351 443 CHARTER-NET-HKY-NC - Charter Communicat 16509 2002 4164 578 AMAZON-02 - Amazon.com, Inc., US 6389 1957 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1934 5060 622 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1881 333 234 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1715 231 568 CABLEONE - CABLE ONE, INC., US 7018 1684 20183 1254 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 20940 2848 839 2057 AKAMAI-ASN1, US 8551 2222 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2107 1858 696 ROSTELECOM-AS, RU 12479 2048 1082 158 UNI2-AS, ES 34984 2002 331 475 TELLCOM-AS, TR 9121 1993 1691 17 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 8402 1254 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1228 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 3848 3348 579 Uninet S.A. de C.V., MX 10620 3589 542 241 Telmex Colombia S.A., CO 11830 2634 370 66 Instituto Costarricense de Electricidad 6503 1627 437 53 Axtel, S.A.B. de C.V., MX 7303 1500 1023 192 Telecom Argentina S.A., AR 6147 1112 377 27 Telefonica del Peru S.A.A., PE 28573 1015 2244 190 CLARO S.A., BR 3816 1014 509 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 919 126 85 Alestra, S. de R.L. de C.V., MX 18881 904 1065 27 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1120 398 50 LINKdotNET-AS, EG 37611 783 91 8 Afrihost, ZA 36903 737 370 140 MT-MPLS, MA 36992 665 1379 35 ETISALAT-MISR, EG 8452 527 1730 18 TE-AS TE-AS, EG 24835 475 786 17 RAYA-AS, EG 37492 449 367 77 ORANGE-, TN 29571 446 36 13 ORANGE-COTE-IVOIRE, CI 37342 373 32 1 MOVITEL, MZ 15399 352 35 7 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 4538 5427 4195 92 ERX-CERNET-BKB China Education and Rese 8151 3848 3348 579 Uninet S.A. de C.V., MX 10620 3589 542 241 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3352 1323 86 SHAW - Shaw Communications Inc., CA 7545 3278 403 390 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3270 2951 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2874 11130 768 KIXS-AS-KR Korea Telecom, KR 20940 2848 839 2057 AKAMAI-ASN1, US 17974 2784 934 78 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 39891 3520 3499 ALJAWWALSTC-AS, SA 10620 3589 3348 Telmex Colombia S.A., CO 8151 3848 3269 Uninet S.A. de C.V., MX 6327 3352 3266 SHAW - Shaw Communications Inc., CA 22773 3270 3124 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3278 2888 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2784 2706 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9394 2636 2609 CTTNET China TieTong Telecommunications Corpora 11830 2634 2568 Instituto Costarricense de Electricidad y Telec 7552 2535 2485 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.69.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.70.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.92.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.93.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 23.159.192.0/24 54726 AET - AET Hosting Solutions, Inc., US 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:12 /10:37 /11:99 /12:279 /13:558 /14:1089 /15:1896 /16:13444 /17:7758 /18:13681 /19:25257 /20:38859 /21:44865 /22:83219 /23:67301 /24:379973 /25:840 /26:605 /27:662 /28:36 /29:20 /30:17 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3144 3352 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2530 3270 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1980 2634 Instituto Costarricense de Electricidad y Telec 8551 1686 2222 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1644 1881 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1582 3589 Telmex Colombia S.A., CO 11492 1512 1715 CABLEONE - CABLE ONE, INC., US 9121 1468 1993 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1578 2:826 4:18 5:2653 6:39 8:1093 9:1 12:1853 13:201 14:1758 15:28 16:3 17:186 18:65 20:53 21:1 23:2546 24:1928 25:2 27:2363 31:1961 32:88 35:22 36:476 37:2474 38:1439 39:235 40:100 41:3056 42:537 43:1944 44:91 45:3557 46:2991 47:192 49:1370 50:1041 51:47 52:921 54:354 55:5 56:7 57:42 58:1591 59:1014 60:368 61:2065 62:1793 63:1818 64:4691 65:2229 66:4480 67:2334 68:1179 69:3184 70:1133 71:562 72:2080 74:2666 75:398 76:419 77:1572 78:1633 79:1681 80:1489 81:1408 82:1060 83:775 84:1007 85:1985 86:528 87:1210 88:923 89:2365 90:179 91:6296 92:1052 93:2352 94:2394 95:2754 96:647 97:356 98:924 99:110 100:79 101:1534 102:13 103:16849 104:3252 105:207 106:524 107:1805 108:706 109:2941 110:1588 111:1735 112:1290 113:1383 114:1109 115:1595 116:1624 117:1691 118:2195 119:1678 120:948 121:1053 122:2463 123:1884 124:1487 125:1848 128:989 129:586 130:440 131:1628 132:599 133:195 134:1001 135:226 136:444 137:475 138:1977 139:556 140:394 141:684 142:773 143:988 144:797 145:196 146:1159 147:756 148:1480 149:709 150:717 151:980 152:758 153:309 154:980 155:743 156:748 157:758 158:601 159:1635 160:838 161:725 162:2548 163:521 164:975 165:1500 166:400 167:1376 168:3129 169:793 170:3659 171:404 172:1029 173:1899 174:863 175:761 176:1882 177:3932 178:2429 179:1181 180:2231 181:2156 182:2431 183:1082 184:901 185:12153 186:3493 187:2327 188:2597 189:1944 190:8106 191:1338 192:9766 193:5873 194:4768 195:3993 196:2353 197:1460 198:5528 199:5891 200:7271 201:4886 202:10397 203:9959 204:4545 205:2864 206:3043 207:3109 208:4006 209:3922 210:4010 211:2146 212:2956 213:2618 214:886 215:66 216:5790 217:2118 218:897 219:625 220:1727 221:997 222:1062 223:1227 End of report From ryangard at gmail.com Fri Jan 19 21:57:19 2018 From: ryangard at gmail.com (Ryan Gard) Date: Fri, 19 Jan 2018 16:57:19 -0500 Subject: Leasing /22 Message-ID: We're on the hunt yet again for an additional /22 to lease, and are wondering what the best options are out there? Our usual suspects that we've reached out to in the past seem to be plum out... Any recommendations? Thanks! -- Ryan Gard From Bryan at bryanfields.net Fri Jan 19 22:18:29 2018 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 19 Jan 2018 17:18:29 -0500 Subject: China is beefing up filtering measures In-Reply-To: References: Message-ID: <088b7a45-d42a-43e9-2f40-85783d5c2182@bryanfields.net> On 1/19/18 9:09 AM, Youssef Bengelloun-Zahr wrote: > I'm trying to understand exactly what we might be dealing with here. Evil. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From michael at wi-fiber.io Fri Jan 19 22:33:57 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 19 Jan 2018 15:33:57 -0700 Subject: Leasing /22 In-Reply-To: References: Message-ID: We got ours from logicweb, but all the IPs originated from AfriNIC and were blacklisted in several different places. On 19 January 2018 at 14:57, Ryan Gard wrote: > We're on the hunt yet again for an additional /22 to lease, and are > wondering what the best options are out there? > > Our usual suspects that we've reached out to in the past seem to be plum > out... Any recommendations? > > Thanks! > > -- > Ryan Gard > From mel at beckman.org Fri Jan 19 23:02:37 2018 From: mel at beckman.org (Mel Beckman) Date: Fri, 19 Jan 2018 23:02:37 +0000 Subject: Leasing /22 In-Reply-To: References: , Message-ID: No, nanog.org is a trade association. -mel via cell > On Jan 19, 2018, at 2:34 PM, Michael Crapse wrote: > > We got ours from logicweb, but all the IPs originated from AfriNIC and were > blacklisted in several different places. > >> On 19 January 2018 at 14:57, Ryan Gard wrote: >> >> We're on the hunt yet again for an additional /22 to lease, and are >> wondering what the best options are out there? >> >> Our usual suspects that we've reached out to in the past seem to be plum >> out... Any recommendations? >> >> Thanks! >> >> -- >> Ryan Gard >> From trelane at trelane.net Sat Jan 20 01:38:53 2018 From: trelane at trelane.net (Andrew Kirch) Date: Sat, 20 Jan 2018 01:38:53 +0000 Subject: Leasing /22 In-Reply-To: References: Message-ID: On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: > We're on the hunt yet again for an additional /22 to lease, and are > wondering what the best options are out there? > > Our usual suspects that we've reached out to in the past seem to be plum > out... Any recommendations? > > Thanks! > > -- > Ryan Gard > Have you considered IPv6? From michael at wi-fiber.io Sat Jan 20 01:47:04 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 19 Jan 2018 18:47:04 -0700 Subject: Leasing /22 In-Reply-To: References: Message-ID: Has Hulu, or a thousand other content distributors considered IPv6? Because you can't even tunnel to ipv4 without setting off VPN alarms with HULU. On 19 January 2018 at 18:38, Andrew Kirch wrote: > On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: > > > We're on the hunt yet again for an additional /22 to lease, and are > > wondering what the best options are out there? > > > > Our usual suspects that we've reached out to in the past seem to be plum > > out... Any recommendations? > > > > Thanks! > > > > -- > > Ryan Gard > > > Have you considered IPv6? > From johnl at iecc.com Sat Jan 20 02:08:53 2018 From: johnl at iecc.com (John Levine) Date: 19 Jan 2018 21:08:53 -0500 Subject: Leasing /22 In-Reply-To: Message-ID: <20180120020853.CE94919523D9@ary.qy> In article you write: >We're on the hunt yet again for an additional /22 to lease, and are >wondering what the best options are out there? It's been a long time since I've seen IP space for lease that wasn't either a scam or totally poisoned. If it were actually usable, it'd be for sale, not for lease. R's, John From morrowc.lists at gmail.com Sat Jan 20 03:13:42 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 19 Jan 2018 22:13:42 -0500 Subject: Leasing /22 In-Reply-To: <20180120020853.CE94919523D9@ary.qy> References: <20180120020853.CE94919523D9@ary.qy> Message-ID: On Fri, Jan 19, 2018 at 9:08 PM, John Levine wrote: > In article mail.gmail.com> you write: > >We're on the hunt yet again for an additional /22 to lease, and are > >wondering what the best options are out there? > > It's been a long time since I've seen IP space for lease that wasn't > either a scam or totally poisoned. > > If it were actually usable, it'd be for sale, not for lease. > > > is it possible that the OP means: "sale" which I think in arin region still really means: "Transfer" ? otherwise, I'd think: "get a link to an ISP, put forth the justification for a /22 and ... rock on" From cb.list6 at gmail.com Sat Jan 20 03:54:23 2018 From: cb.list6 at gmail.com (Ca By) Date: Sat, 20 Jan 2018 03:54:23 +0000 Subject: Leasing /22 In-Reply-To: References: Message-ID: On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse wrote: > Has Hulu, or a thousand other content distributors considered IPv6? Because > you can't even tunnel to ipv4 without setting off VPN alarms with HULU. > Hulu? Really scraping the bottom of the barrel of content providers that dont use ipv6 these days. Netflix and Youtube support v6 ... and thousand of others (thousands just on Cloudflare where v6 is default on) About 80% of my traffic is native e2e v6, mostly google / youtube / fb / netflix / apple / amazon — but your mix may vary. > > > On 19 January 2018 at 18:38, Andrew Kirch wrote: > > > On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: > > > > > We're on the hunt yet again for an additional /22 to lease, and are > > > wondering what the best options are out there? > > > > > > Our usual suspects that we've reached out to in the past seem to be > plum > > > out... Any recommendations? > > > > > > Thanks! > > > > > > -- > > > Ryan Gard > > > > > Have you considered IPv6? > > > From josh at kyneticwifi.com Sat Jan 20 04:50:09 2018 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 19 Jan 2018 22:50:09 -0600 Subject: Leasing /22 In-Reply-To: References: Message-ID: Not hard to do in the US where most access networks still aren't supporting IPv6. On Fri, Jan 19, 2018 at 9:54 PM, Ca By wrote: > On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse wrote: > >> Has Hulu, or a thousand other content distributors considered IPv6? Because >> you can't even tunnel to ipv4 without setting off VPN alarms with HULU. >> > > Hulu? Really scraping the bottom of the barrel of content providers that > dont use ipv6 these days. > > Netflix and Youtube support v6 ... and thousand of others (thousands just > on Cloudflare where v6 is default on) > > About 80% of my traffic is native e2e v6, mostly google / youtube / fb / > netflix / apple / amazon — but your mix may vary. > > > >> >> >> On 19 January 2018 at 18:38, Andrew Kirch wrote: >> >> > On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: >> > >> > > We're on the hunt yet again for an additional /22 to lease, and are >> > > wondering what the best options are out there? >> > > >> > > Our usual suspects that we've reached out to in the past seem to be >> plum >> > > out... Any recommendations? >> > > >> > > Thanks! >> > > >> > > -- >> > > Ryan Gard >> > > >> > Have you considered IPv6? >> > >> From cb.list6 at gmail.com Sat Jan 20 05:00:28 2018 From: cb.list6 at gmail.com (Ca By) Date: Sat, 20 Jan 2018 05:00:28 +0000 Subject: Leasing /22 In-Reply-To: References: Message-ID: On Fri, Jan 19, 2018 at 8:50 PM Josh Reynolds wrote: > Not hard to do in the US where most access networks still aren't > supporting IPv6. > I hear ya, some places are behind. Check this out, close to 80% of mobile subs are on ipv6 across the 4 major carriers http://www.worldipv6launch.org/new-years-resolution-deploy-ipv6/ > On Fri, Jan 19, 2018 at 9:54 PM, Ca By wrote: > > On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse > wrote: > > > >> Has Hulu, or a thousand other content distributors considered IPv6? > Because > >> you can't even tunnel to ipv4 without setting off VPN alarms with HULU. > >> > > > > Hulu? Really scraping the bottom of the barrel of content providers that > > dont use ipv6 these days. > > > > Netflix and Youtube support v6 ... and thousand of others (thousands just > > on Cloudflare where v6 is default on) > > > > About 80% of my traffic is native e2e v6, mostly google / youtube / fb / > > netflix / apple / amazon — but your mix may vary. > > > > > > > >> > >> > >> On 19 January 2018 at 18:38, Andrew Kirch wrote: > >> > >> > On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: > >> > > >> > > We're on the hunt yet again for an additional /22 to lease, and are > >> > > wondering what the best options are out there? > >> > > > >> > > Our usual suspects that we've reached out to in the past seem to be > >> plum > >> > > out... Any recommendations? > >> > > > >> > > Thanks! > >> > > > >> > > -- > >> > > Ryan Gard > >> > > > >> > Have you considered IPv6? > >> > > >> > From marka at isc.org Sat Jan 20 06:01:18 2018 From: marka at isc.org (Mark Andrews) Date: Sat, 20 Jan 2018 17:01:18 +1100 Subject: MTU to CDN's In-Reply-To: <1516379714.3410368.1241238760.0EE7863D@webmail.messagingengine.com> References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> <1516379714.3410368.1241238760.0EE7863D@webmail.messagingengine.com> Message-ID: <815266AA-3C83-45B2-BCC0-68B294691D2F@isc.org> Which doesn’t work with IPv6 as UDP doesn’t have the field to clamp. -- Mark Andrews > On 20 Jan 2018, at 03:35, Radu-Adrian Feurdean wrote: > >> On Fri, Jan 19, 2018, at 01:14, Jared Mauch wrote: >> If you’re then doing DSL + PPPoE and your customers really see a MTU >> of 1492 or less, then another device has to fragment 5x again. > > In this part of the world we have even worse stuff around: PPP over L2TP over over IP with 1500 MTU interconnection. Remove another 40 bytes. Add some more headers for various tunneling scenarios and you may get into a situation where even 1400 is too much. But it usually works with MSS clamping to the correct value. Some small ISPs don't even make the effort to check if the transport supports "more than 1500" in order to give the 1500 bytes to the customer - they just clamp down MSS. From swmike at swm.pp.se Sat Jan 20 07:30:23 2018 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 20 Jan 2018 08:30:23 +0100 (CET) Subject: MTU to CDN's In-Reply-To: <815266AA-3C83-45B2-BCC0-68B294691D2F@isc.org> References: <44683110-4cbc-a4e7-03b7-b2ebef2eaaf8@bogus.com> <1516379714.3410368.1241238760.0EE7863D@webmail.messagingengine.com> <815266AA-3C83-45B2-BCC0-68B294691D2F@isc.org> Message-ID: On Sat, 20 Jan 2018, Mark Andrews wrote: > Which doesn’t work with IPv6 as UDP doesn’t have the field to clamp. Well, not with UDP/IPv4 either. Actually, the only protocol I know out there that has this kind of clamping (and is in wide use for clamping), is TCP. Thus, my earlier comment about making strong advise for protocols using PLMTUD. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at ics-il.net Sat Jan 20 15:20:27 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 20 Jan 2018 09:20:27 -0600 (CST) Subject: Leasing /22 In-Reply-To: References: Message-ID: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> It's not really scraping the bottom of the barrel if your customers are using Hulu and they're complaining because Hulu isn't responsive to fixing their problems (geo-location, v6, etc.). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ca By" To: "Michael Crapse" Cc: "NANOG list" Sent: Friday, January 19, 2018 9:54:23 PM Subject: Re: Leasing /22 On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse wrote: > Has Hulu, or a thousand other content distributors considered IPv6? Because > you can't even tunnel to ipv4 without setting off VPN alarms with HULU. > Hulu? Really scraping the bottom of the barrel of content providers that dont use ipv6 these days. Netflix and Youtube support v6 ... and thousand of others (thousands just on Cloudflare where v6 is default on) About 80% of my traffic is native e2e v6, mostly google / youtube / fb / netflix / apple / amazon — but your mix may vary. > > > On 19 January 2018 at 18:38, Andrew Kirch wrote: > > > On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: > > > > > We're on the hunt yet again for an additional /22 to lease, and are > > > wondering what the best options are out there? > > > > > > Our usual suspects that we've reached out to in the past seem to be > plum > > > out... Any recommendations? > > > > > > Thanks! > > > > > > -- > > > Ryan Gard > > > > > Have you considered IPv6? > > > From morrowc.lists at gmail.com Sat Jan 20 16:58:20 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 20 Jan 2018 11:58:20 -0500 Subject: Leasing /22 In-Reply-To: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> References: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> Message-ID: On Sat, Jan 20, 2018 at 10:20 AM, Mike Hammett wrote: > It's not really scraping the bottom of the barrel if your customers are > using Hulu and they're complaining because Hulu isn't responsive to fixing > their problems (geo-location, v6, etc.). > > hulu is on akamai akamai does provide ipv6 frontends (in fact they do v6 on the front and v4 out the back) so... it really should be pretty easy at this point for hulu to move traffic to ipv6. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Ca By" > To: "Michael Crapse" > Cc: "NANOG list" > Sent: Friday, January 19, 2018 9:54:23 PM > Subject: Re: Leasing /22 > > On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse > wrote: > > > Has Hulu, or a thousand other content distributors considered IPv6? > Because > > you can't even tunnel to ipv4 without setting off VPN alarms with HULU. > > > > Hulu? Really scraping the bottom of the barrel of content providers that > dont use ipv6 these days. > > Netflix and Youtube support v6 ... and thousand of others (thousands just > on Cloudflare where v6 is default on) > > About 80% of my traffic is native e2e v6, mostly google / youtube / fb / > netflix / apple / amazon — but your mix may vary. > > > > > > > > > On 19 January 2018 at 18:38, Andrew Kirch wrote: > > > > > On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: > > > > > > > We're on the hunt yet again for an additional /22 to lease, and are > > > > wondering what the best options are out there? > > > > > > > > Our usual suspects that we've reached out to in the past seem to be > > plum > > > > out... Any recommendations? > > > > > > > > Thanks! > > > > > > > > -- > > > > Ryan Gard > > > > > > > Have you considered IPv6? > > > > > > > From colton.conor at gmail.com Sat Jan 20 17:32:57 2018 From: colton.conor at gmail.com (Colton Conor) Date: Sat, 20 Jan 2018 11:32:57 -0600 Subject: Open Souce Network Operating Systems In-Reply-To: <1413312135.78963.1516332356885.JavaMail.zimbra@mawcom.com> References: <1413312135.78963.1516332356885.JavaMail.zimbra@mawcom.com> Message-ID: Eron, Thanks for the advice. My understanding if Free Range Routing is a package of software that runs in linux, but not a full and true NOS right? Is pfSense 3.0 going to be dramatically different that the current version? I never considered this a NOS but more of a firewall platform with some routing capabilities. I looked into Cumulus Linux, but it seems to only run on the supported hardware which is while box switches. Can you run Cumulus Linux on a X86 server with intel NICs? Can you run Cumulus on a raspberry pi? Ideally I think I am looking to a Linux operating system that can run on multiple CPU architectures, has device support for Broadcom and other Merchant silicon switching and wifi adapters. On Thu, Jan 18, 2018 at 9:25 PM, Eron Lloyd wrote: > I would start with following the Free Range Routing project, and related > but independent (and more tangible) projects like pfSense (esp. the > upcoming 3.0 release) and Cumulus Linux. Going deeper, perhaps Carrier > Grade Linux, DPDK, and ONOS (all Linux Foundation projects). I think > scaling vertically from CPEs to core stack is a stretch, especially if you > mean a DIY approach, however. > > ----- Original Message ----- > From: "Colton Conor" > To: "nanog" > Sent: Wednesday, January 17, 2018 9:28:13 AM > Subject: Open Souce Network Operating Systems > > If one were to deploy whitebox switches, X86 servers, low cost ARM and > MIBPS CPE devices, and basically anything that can run linux today, what > network operating system would you recommend? The goal would be to have a > universal network operating system that runs across a variety of devices. > From low cost residential CPE's with wifi to switches to BGP speaking > routers. Is there anything that can do it all today? > > > I will use something like OpenWRT as an example. I don't consider this > anywhere near carrier grade, but it runs on X86 and low cost routers. I > don't think it will run on whitebox switches though. > > Mikrotik RouterOS would be another example as it can run on low cost > Routerboards, and X86 servers. But it is not opensouce. > > Is there any up and coming projects to look into? > -- > Eron Lloyd > Information Technology Director > 717-344-5958 > eron at mawcom.com > MAW Communications, Inc. > From peter.phaal at gmail.com Sat Jan 20 19:11:34 2018 From: peter.phaal at gmail.com (Peter Phaal) Date: Sat, 20 Jan 2018 11:11:34 -0800 Subject: Open Souce Network Operating Systems In-Reply-To: References: <1413312135.78963.1516332356885.JavaMail.zimbra@mawcom.com> Message-ID: On Sat, Jan 20, 2018 at 9:32 AM, Colton Conor wrote: > > My understanding if Free Range Routing is a package of software that runs > in linux, but not a full and true NOS right? > Why not consider Linux a NOS? Installing Free Range Routing adds control plane protocols: BGP, OSPF, ISIS, etc. > I looked into Cumulus Linux, but it seems to only run on the supported > hardware which is while box switches. Can you run Cumulus Linux on a X86 > server with intel NICs? Can you run Cumulus on a raspberry pi? > Cumulus Linux is basically Ubuntu with Free Range Routing pre-installed along with a daemon that offloads forwarding from the Linux kernel to an ASIC. CumulusVX is a free Cumulus Linux virtual machine that is useful for staging / testing configurations since it has the same behavior as the hardware switch. On X86 servers with Intel NICs, just run Linux. Cumulus Host Pack can be installed to add Free Range Routing and other Cumulus tools on the server. Alternatively, you can choose any Linux control plane, automation, or monitoring tools and install them on the hosts and Cumulus Linux switches to unify management and control, e.g. Bird, collectd, telegraf, Puppet, Chef, Ansible, etc. Linux distros (including Ubuntu) are available for non-X86 hardware like Raspberry Pi etc. > > Ideally I think I am looking to a Linux operating system that can run on > multiple CPU architectures, has device support for Broadcom and other > Merchant silicon switching and wifi adapters. If you consider Linux as the NOS then it already meets these requirements. From colton.conor at gmail.com Sat Jan 20 19:26:15 2018 From: colton.conor at gmail.com (Colton Conor) Date: Sat, 20 Jan 2018 13:26:15 -0600 Subject: Open Souce Network Operating Systems In-Reply-To: References: <1413312135.78963.1516332356885.JavaMail.zimbra@mawcom.com> Message-ID: Peter, Thanks for the information. Do you have a recommendation of which distribution of Linux to use for this? Is there one that is more network centric than another? On Sat, Jan 20, 2018 at 1:11 PM, Peter Phaal wrote: > On Sat, Jan 20, 2018 at 9:32 AM, Colton Conor > wrote: >> >> My understanding if Free Range Routing is a package of software that runs >> in linux, but not a full and true NOS right? >> > > Why not consider Linux a NOS? Installing Free Range Routing adds control > plane protocols: BGP, OSPF, ISIS, etc. > > >> I looked into Cumulus Linux, but it seems to only run on the supported >> hardware which is while box switches. Can you run Cumulus Linux on a X86 >> server with intel NICs? Can you run Cumulus on a raspberry pi? >> > > Cumulus Linux is basically Ubuntu with Free Range Routing pre-installed > along with a daemon that offloads forwarding from the Linux kernel to an > ASIC. CumulusVX is a free Cumulus Linux virtual machine that is useful for > staging / testing configurations since it has the same behavior as the > hardware switch. > > On X86 servers with Intel NICs, just run Linux. Cumulus Host Pack can be > installed to add Free Range Routing and other Cumulus tools on the server. > Alternatively, you can choose any Linux control plane, automation, or > monitoring tools and install them on the hosts and Cumulus Linux switches > to unify management and control, e.g. Bird, collectd, telegraf, Puppet, > Chef, Ansible, etc. > > Linux distros (including Ubuntu) are available for non-X86 hardware like > Raspberry Pi etc. > > >> >> Ideally I think I am looking to a Linux operating system that can run on >> multiple CPU architectures, has device support for Broadcom and other >> Merchant silicon switching and wifi adapters. > > > If you consider Linux as the NOS then it already meets these requirements. > From imawsog at yahoo.com Sat Jan 20 19:41:00 2018 From: imawsog at yahoo.com (i mawsog) Date: Sat, 20 Jan 2018 19:41:00 +0000 (UTC) Subject: Open Souce Network Operating Systems In-Reply-To: References: <1413312135.78963.1516332356885.JavaMail.zimbra@mawcom.com> Message-ID: <1235877775.2081902.1516477260749@mail.yahoo.com> I would second Peter's  advise.  Colton, for  you I would recommended you visit Cumulus' web site and follow their tutorials.  That should provide you with enough insights  for your next step.  On Saturday, January 20, 2018, 11:27:38 AM PST, Colton Conor wrote: Peter, Thanks for the information. Do you have a recommendation of which distribution of Linux to use for this? Is there one that is more network centric than another? On Sat, Jan 20, 2018 at 1:11 PM, Peter Phaal wrote: > On Sat, Jan 20, 2018 at 9:32 AM, Colton Conor > wrote: >> >> My understanding if Free Range Routing is a package of software that runs >> in linux, but not a full and true NOS right? >> > > Why not consider Linux a NOS? Installing Free Range Routing adds control > plane protocols: BGP, OSPF, ISIS, etc. > > >> I looked into Cumulus Linux, but it seems to only run on the supported >> hardware which is while box switches. Can you run Cumulus Linux on a X86 >> server with intel NICs? Can you run Cumulus on a raspberry pi? >> > > Cumulus Linux is basically Ubuntu with Free Range Routing pre-installed > along with a daemon that offloads forwarding from the Linux kernel to an > ASIC. CumulusVX is a free Cumulus Linux virtual machine that is useful for > staging / testing configurations since it has the same behavior as the > hardware switch. > > On X86 servers with Intel NICs, just run Linux. Cumulus Host Pack can be > installed to add Free Range Routing and other Cumulus tools on the server. > Alternatively, you can choose any Linux control plane, automation, or > monitoring tools and install them on the hosts and Cumulus Linux switches > to unify management and control, e.g. Bird, collectd, telegraf, Puppet, > Chef, Ansible, etc. > > Linux distros (including Ubuntu) are available for non-X86 hardware like > Raspberry Pi etc. > > >> >> Ideally I think I am looking to a Linux operating system that can run on >> multiple CPU architectures, has device support for Broadcom and other >> Merchant silicon switching and wifi adapters. > > > If you consider Linux as the NOS then it already meets these requirements. > From peter.phaal at gmail.com Sat Jan 20 19:45:40 2018 From: peter.phaal at gmail.com (Peter Phaal) Date: Sat, 20 Jan 2018 11:45:40 -0800 Subject: Open Souce Network Operating Systems In-Reply-To: References: <1413312135.78963.1516332356885.JavaMail.zimbra@mawcom.com> Message-ID: On Sat, Jan 20, 2018 at 11:26 AM, Colton Conor wrote: > > Thanks for the information. Do you have a recommendation of which > distribution of Linux to use for this? Is there one that is more network > centric than another? > Cumulus Linux, OpenSwitch, and Open Network Linux are all Debian based so there is probably a greater ecosystem of developers and network centric tools being built for Debian. From nanog at ics-il.net Mon Jan 22 20:05:37 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 22 Jan 2018 14:05:37 -0600 (CST) Subject: Anyone using Cogent Ethernet In-Reply-To: <1167689323.4232.1516651422506.JavaMail.mhammett@ThunderFuck> Message-ID: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> I much prefer using WDM transport as opposed to Ethernet\VPLS transport due to it being significantly harder (I try not to say impossible) to oversubscribe. That said, it isn't always available at a decent rate at a given location. Cogent has a reputation (right or wrong) for running things a little hot. Have any of you used Cogent Ethernet\VPLS services? What are you experiences? Offlist is fine if you don't want it public. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From lee at asgard.org Mon Jan 22 22:05:10 2018 From: lee at asgard.org (Lee Howard) Date: Mon, 22 Jan 2018 17:05:10 -0500 Subject: Leasing /22 In-Reply-To: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> References: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> Message-ID: IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat, MAP-T, MAP-E. Yes, you’re NATing, but only the traffic to places like Hulu, and it will decrease over time. And while you need addresses for the outside of the translator, you don’t need as many (or to get more as frequently). Lee On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett" wrote: >It's not really scraping the bottom of the barrel if your customers are >using Hulu and they're complaining because Hulu isn't responsive to >fixing their problems (geo-location, v6, etc.). > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com > >----- Original Message ----- > >From: "Ca By" >To: "Michael Crapse" >Cc: "NANOG list" >Sent: Friday, January 19, 2018 9:54:23 PM >Subject: Re: Leasing /22 > >On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse >wrote: > >> Has Hulu, or a thousand other content distributors considered IPv6? >>Because >> you can't even tunnel to ipv4 without setting off VPN alarms with HULU. >> > >Hulu? Really scraping the bottom of the barrel of content providers that >dont use ipv6 these days. > >Netflix and Youtube support v6 ... and thousand of others (thousands just >on Cloudflare where v6 is default on) > >About 80% of my traffic is native e2e v6, mostly google / youtube / fb / >netflix / apple / amazon — but your mix may vary. > > > >> >> >> On 19 January 2018 at 18:38, Andrew Kirch wrote: >> >> > On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: >> > >> > > We're on the hunt yet again for an additional /22 to lease, and are >> > > wondering what the best options are out there? >> > > >> > > Our usual suspects that we've reached out to in the past seem to be >> plum >> > > out... Any recommendations? >> > > >> > > Thanks! >> > > >> > > -- >> > > Ryan Gard >> > > >> > Have you considered IPv6? >> > >> > > From marka at isc.org Mon Jan 22 22:23:42 2018 From: marka at isc.org (Mark Andrews) Date: Tue, 23 Jan 2018 09:23:42 +1100 Subject: Leasing /22 In-Reply-To: References: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> Message-ID: Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that reaches its limit at ~4M customers. Native IPv4 with a GUA to customers is essentially unavailable for new ISPs. It’s a matter of picking which flavour of NAT you and your customers are going to use. The sooner ALL ISP’s provide IPv6 to their customers the sooner we restore delivering the Internet to the customers. Mark > On 23 Jan 2018, at 9:05 am, Lee Howard wrote: > > IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat, > MAP-T, MAP-E. > > Yes, you’re NATing, but only the traffic to places like Hulu, and it will > decrease over time. And while you need addresses for the outside of the > translator, you don’t need as many (or to get more as frequently). > > Lee > > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett" > wrote: > >> It's not really scraping the bottom of the barrel if your customers are >> using Hulu and they're complaining because Hulu isn't responsive to >> fixing their problems (geo-location, v6, etc.). >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Ca By" >> To: "Michael Crapse" >> Cc: "NANOG list" >> Sent: Friday, January 19, 2018 9:54:23 PM >> Subject: Re: Leasing /22 >> >> On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse >> wrote: >> >>> Has Hulu, or a thousand other content distributors considered IPv6? >>> Because >>> you can't even tunnel to ipv4 without setting off VPN alarms with HULU. >>> >> >> Hulu? Really scraping the bottom of the barrel of content providers that >> dont use ipv6 these days. >> >> Netflix and Youtube support v6 ... and thousand of others (thousands just >> on Cloudflare where v6 is default on) >> >> About 80% of my traffic is native e2e v6, mostly google / youtube / fb / >> netflix / apple / amazon — but your mix may vary. >> >> >> >>> >>> >>> On 19 January 2018 at 18:38, Andrew Kirch wrote: >>> >>>> On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: >>>> >>>>> We're on the hunt yet again for an additional /22 to lease, and are >>>>> wondering what the best options are out there? >>>>> >>>>> Our usual suspects that we've reached out to in the past seem to be >>> plum >>>>> out... Any recommendations? >>>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> Ryan Gard >>>>> >>>> Have you considered IPv6? >>>> >>> >> >> > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From michael at wi-fiber.io Mon Jan 22 22:27:49 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Mon, 22 Jan 2018 15:27:49 -0700 Subject: Leasing /22 In-Reply-To: References: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> Message-ID: Customers on ps4s and xboxes will hate you. They will always get "strict" nat, and it's your fault not mega corporation X's fault for not releasing IPv4s On 22 January 2018 at 15:23, Mark Andrews wrote: > Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that > reaches its limit at ~4M customers. > > Native IPv4 with a GUA to customers is essentially unavailable for new > ISPs. It’s a matter of picking which flavour of NAT you and your > customers are going to use. The sooner ALL ISP’s provide IPv6 to their > customers the sooner we restore delivering the Internet to the customers. > > Mark > > > On 23 Jan 2018, at 9:05 am, Lee Howard wrote: > > > > IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat, > > MAP-T, MAP-E. > > > > Yes, you’re NATing, but only the traffic to places like Hulu, and it will > > decrease over time. And while you need addresses for the outside of the > > translator, you don’t need as many (or to get more as frequently). > > > > Lee > > > > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett" > > wrote: > > > >> It's not really scraping the bottom of the barrel if your customers are > >> using Hulu and they're complaining because Hulu isn't responsive to > >> fixing their problems (geo-location, v6, etc.). > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> Midwest-IX > >> http://www.midwest-ix.com > >> > >> ----- Original Message ----- > >> > >> From: "Ca By" > >> To: "Michael Crapse" > >> Cc: "NANOG list" > >> Sent: Friday, January 19, 2018 9:54:23 PM > >> Subject: Re: Leasing /22 > >> > >> On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse > >> wrote: > >> > >>> Has Hulu, or a thousand other content distributors considered IPv6? > >>> Because > >>> you can't even tunnel to ipv4 without setting off VPN alarms with HULU. > >>> > >> > >> Hulu? Really scraping the bottom of the barrel of content providers that > >> dont use ipv6 these days. > >> > >> Netflix and Youtube support v6 ... and thousand of others (thousands > just > >> on Cloudflare where v6 is default on) > >> > >> About 80% of my traffic is native e2e v6, mostly google / youtube / fb / > >> netflix / apple / amazon — but your mix may vary. > >> > >> > >> > >>> > >>> > >>> On 19 January 2018 at 18:38, Andrew Kirch wrote: > >>> > >>>> On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: > >>>> > >>>>> We're on the hunt yet again for an additional /22 to lease, and are > >>>>> wondering what the best options are out there? > >>>>> > >>>>> Our usual suspects that we've reached out to in the past seem to be > >>> plum > >>>>> out... Any recommendations? > >>>>> > >>>>> Thanks! > >>>>> > >>>>> -- > >>>>> Ryan Gard > >>>>> > >>>> Have you considered IPv6? > >>>> > >>> > >> > >> > > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From nanog-post at rsuc.gweep.net Mon Jan 22 22:44:56 2018 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 22 Jan 2018 17:44:56 -0500 Subject: Leasing /22 In-Reply-To: References: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> Message-ID: <20180122224456.GA31202@gweep.net> On Mon, Jan 22, 2018 at 03:27:49PM -0700, Michael Crapse wrote: > Customers on ps4s and xboxes will hate you. They will always get "strict" > nat, and it's your fault not mega corporation X's fault for not releasing > IPv4s I think you misspelled "those console platforms' fault for being bad network citizens": "(10/13/17) As of PS4 update 5.00 no offical IPv6 support has been added." from https://community.playstation.com/content/pdc/us/en_US/pdc-communities/playstation-general.topic.html/ipv6_psn_and_youc-bUKX.html Xbox one actually seems to DTRT: https://support.xbox.com/en-US/xbox-one/networking/ipv6-on-xbox-one Cheers! Joe > On 22 January 2018 at 15:23, Mark Andrews wrote: > > > Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that > > reaches its limit at ~4M customers. > > > > Native IPv4 with a GUA to customers is essentially unavailable for new > > ISPs. It???s a matter of picking which flavour of NAT you and your > > customers are going to use. The sooner ALL ISP???s provide IPv6 to their > > customers the sooner we restore delivering the Internet to the customers. > > > > Mark > > > > > On 23 Jan 2018, at 9:05 am, Lee Howard wrote: > > > > > > IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat, > > > MAP-T, MAP-E. > > > > > > Yes, you???re NATing, but only the traffic to places like Hulu, and it will > > > decrease over time. And while you need addresses for the outside of the > > > translator, you don???t need as many (or to get more as frequently). > > > > > > Lee > > > > > > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett" > > > wrote: > > > > > >> It's not really scraping the bottom of the barrel if your customers are > > >> using Hulu and they're complaining because Hulu isn't responsive to > > >> fixing their problems (geo-location, v6, etc.). > > >> > > >> > > >> > > >> > > >> ----- > > >> Mike Hammett > > >> Intelligent Computing Solutions > > >> http://www.ics-il.com > > >> > > >> Midwest-IX > > >> http://www.midwest-ix.com > > >> > > >> ----- Original Message ----- > > >> > > >> From: "Ca By" > > >> To: "Michael Crapse" > > >> Cc: "NANOG list" > > >> Sent: Friday, January 19, 2018 9:54:23 PM > > >> Subject: Re: Leasing /22 > > >> > > >> On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse > > >> wrote: > > >> > > >>> Has Hulu, or a thousand other content distributors considered IPv6? > > >>> Because > > >>> you can't even tunnel to ipv4 without setting off VPN alarms with HULU. > > >>> > > >> > > >> Hulu? Really scraping the bottom of the barrel of content providers that > > >> dont use ipv6 these days. > > >> > > >> Netflix and Youtube support v6 ... and thousand of others (thousands > > just > > >> on Cloudflare where v6 is default on) > > >> > > >> About 80% of my traffic is native e2e v6, mostly google / youtube / fb / > > >> netflix / apple / amazon ??? but your mix may vary. > > >> > > >> > > >> > > >>> > > >>> > > >>> On 19 January 2018 at 18:38, Andrew Kirch wrote: > > >>> > > >>>> On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard wrote: > > >>>> > > >>>>> We're on the hunt yet again for an additional /22 to lease, and are > > >>>>> wondering what the best options are out there? > > >>>>> > > >>>>> Our usual suspects that we've reached out to in the past seem to be > > >>> plum > > >>>>> out... Any recommendations? > > >>>>> > > >>>>> Thanks! > > >>>>> > > >>>>> -- > > >>>>> Ryan Gard > > >>>>> > > >>>> Have you considered IPv6? > > >>>> > > >>> > > >> > > >> > > > > > > > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From lee at asgard.org Tue Jan 23 00:57:04 2018 From: lee at asgard.org (Lee Howard) Date: Mon, 22 Jan 2018 19:57:04 -0500 Subject: Leasing /22 In-Reply-To: References: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> Message-ID: From: Michael Crapse Date: Monday, January 22, 2018 at 5:27 PM To: Mark Andrews Cc: Lee Howard , NANOG list Subject: Re: Leasing /22 > Customers on ps4s and xboxes will hate you. They will always get "strict" nat, > and it's your fault not mega corporation X's fault for not releasing IPv4s Maybe. You don’t have to configure strict NAT on your translator (DS-Lite’s pretty good at this, and although I’m a few weeks away from testing consoles through 464xlat and MAP, they should work, too). And their NAT workarounds are pretty sophisticated now. There comes a point when winning your customers’ love isn’t profitable. I don’t know if that point is $16/address for you, or $30, or $40, or $90. Maybe it varies, depending on the customer. That’s why I suggested in “TCO of CGN”[1] that everyone figure out for themselves how much money you might lose to unhappy customers via CGN, and compare it to how much addresses cost, and at what price point you might turn around and sell addresses. My findings then, based on assumptions that almost certainly are not true for any particular network, and which may have changed, suggest that buying addresses still makes sense. Lee [1] http://ipv6.nanog.org/meetings/abstract?id=2025 > > On 22 January 2018 at 15:23, Mark Andrews wrote: >> Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that >> reaches its limit at ~4M customers. >> >> Native IPv4 with a GUA to customers is essentially unavailable for new >> ISPs. It’s a matter of picking which flavour of NAT you and your >> customers are going to use. The sooner ALL ISP’s provide IPv6 to their >> customers the sooner we restore delivering the Internet to the customers. >> >> Mark >> >>> > On 23 Jan 2018, at 9:05 am, Lee Howard wrote: >>> > >>> > IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat, >>> > MAP-T, MAP-E. >>> > >>> > Yes, you’re NATing, but only the traffic to places like Hulu, and it will >>> > decrease over time. And while you need addresses for the outside of the >>> > translator, you don’t need as many (or to get more as frequently). >>> > >>> > Lee >>> > >>> > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett" >>> > wrote: >>> > >>>> >> It's not really scraping the bottom of the barrel if your customers are >>>> >> using Hulu and they're complaining because Hulu isn't responsive to >>>> >> fixing their problems (geo-location, v6, etc.). >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> ----- >>>> >> Mike Hammett >>>> >> Intelligent Computing Solutions >>>> >> http://www.ics-il.com >>>> >> >>>> >> Midwest-IX >>>> >> http://www.midwest-ix.com >>>> >> >>>> >> ----- Original Message ----- >>>> >> >>>> >> From: "Ca By" >>>> >> To: "Michael Crapse" >>>> >> Cc: "NANOG list" >>>> >> Sent: Friday, January 19, 2018 9:54:23 PM >>>> >> Subject: Re: Leasing /22 >>>> >> >>>> >> On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse >>>> >> wrote: >>>> >> >>>>> >>> Has Hulu, or a thousand other content distributors considered IPv6? >>>>> >>> Because >>>>> >>> you can't even tunnel to ipv4 without setting off VPN alarms with >>>>> HULU. >>>>> >>> >>>> >> >>>> >> Hulu? Really scraping the bottom of the barrel of content providers that >>>> >> dont use ipv6 these days. >>>> >> >>>> >> Netflix and Youtube support v6 ... and thousand of others (thousands >>>> just >>>> >> on Cloudflare where v6 is default on) >>>> >> >>>> >> About 80% of my traffic is native e2e v6, mostly google / youtube / fb / >>>> >> netflix / apple / amazon — but your mix may vary. >>>> >> >>>> >> >>>> >> >>>>> >>> >>>>> >>> >>>>> >>> On 19 January 2018 at 18:38, Andrew Kirch wrote: >>>>> >>> >>>>>> >>>> On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard >>>>>> wrote: >>>>>> >>>> >>>>>>> >>>>> We're on the hunt yet again for an additional /22 to lease, and are >>>>>>> >>>>> wondering what the best options are out there? >>>>>>> >>>>> >>>>>>> >>>>> Our usual suspects that we've reached out to in the past seem to be >>>>> >>> plum >>>>>>> >>>>> out... Any recommendations? >>>>>>> >>>>> >>>>>>> >>>>> Thanks! >>>>>>> >>>>> >>>>>>> >>>>> -- >>>>>>> >>>>> Ryan Gard >>>>>>> >>>>> >>>>>> >>>> Have you considered IPv6? >>>>>> >>>> >>>>> >>> >>>> >> >>>> >> >>> > >>> > >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: >> marka at isc.org >> > From martin at airwire.ie Tue Jan 23 02:07:41 2018 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 23 Jan 2018 02:07:41 +0000 Subject: Anyone using Cogent Ethernet In-Reply-To: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> Message-ID: <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> On 22/01/18 20:05, Mike Hammett wrote: > I much prefer using WDM transport as opposed to Ethernet\VPLS transport due to it being significantly harder (I try not to say impossible) to oversubscribe. That said, it isn't always available at a decent rate at a given location. > > Cogent has a reputation (right or wrong) for running things a little hot. > > Have any of you used Cogent Ethernet\VPLS services? What are you experiences? Offlist is fine if you don't want it public. Never use them without a backup alternative. I've seen more outages, that one would want to ever see from a provider, that would like to be categorised as Tier1. Especially, when some of these are longer than expected, because there were no cold-spares in the country and the cold-spare needed missed the flight. /M -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961 From michael at wi-fiber.io Tue Jan 23 02:12:43 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Mon, 22 Jan 2018 19:12:43 -0700 Subject: Anyone using Cogent Ethernet In-Reply-To: <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> Message-ID: Tier 1 just means they don't pay for ip transit themselves, only Peering. Doesn't mean that it's good transit. Best provider i've ever used is hurricane electric, actually a tier 2 provider, but bigger/better than many tier 1s. On 22 January 2018 at 19:07, Martin List-Petersen wrote: > On 22/01/18 20:05, Mike Hammett wrote: > >> I much prefer using WDM transport as opposed to Ethernet\VPLS transport >> due to it being significantly harder (I try not to say impossible) to >> oversubscribe. That said, it isn't always available at a decent rate at a >> given location. >> >> Cogent has a reputation (right or wrong) for running things a little hot. >> >> Have any of you used Cogent Ethernet\VPLS services? What are you >> experiences? Offlist is fine if you don't want it public. >> > > Never use them without a backup alternative. I've seen more outages, that > one would want to ever see from a provider, that would like to be > categorised as Tier1. > > Especially, when some of these are longer than expected, because there > were no cold-spares in the country and the cold-spare needed missed the > flight. > > /M > -- > Airwire Ltd. - Ag Nascadh Pobail an Iarthair > http://www.airwire.ie > Phone: 091-395 000 > Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in > Ireland No. 508961 > From martin at airwire.ie Tue Jan 23 02:24:46 2018 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 23 Jan 2018 02:24:46 +0000 Subject: Anyone using Cogent Ethernet In-Reply-To: References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> Message-ID: On 23/01/18 02:12, Michael Crapse wrote: > Tier 1 just means they don't pay for ip transit themselves, only Peering. > Doesn't mean that it's good transit. > Best provider i've ever used is hurricane electric, actually a tier 2 > provider, but bigger/better than many tier 1s. I'd still categorise Hurricane a lot better than Cogent. Both quality and customer service wise. /M > On 22 January 2018 at 19:07, Martin List-Petersen wrote: > >> On 22/01/18 20:05, Mike Hammett wrote: >> >>> I much prefer using WDM transport as opposed to Ethernet\VPLS transport >>> due to it being significantly harder (I try not to say impossible) to >>> oversubscribe. That said, it isn't always available at a decent rate at a >>> given location. >>> >>> Cogent has a reputation (right or wrong) for running things a little hot. >>> >>> Have any of you used Cogent Ethernet\VPLS services? What are you >>> experiences? Offlist is fine if you don't want it public. >>> >> >> Never use them without a backup alternative. I've seen more outages, that >> one would want to ever see from a provider, that would like to be >> categorised as Tier1. >> >> Especially, when some of these are longer than expected, because there >> were no cold-spares in the country and the cold-spare needed missed the >> flight. >> >> /M >> -- >> Airwire Ltd. - Ag Nascadh Pobail an Iarthair >> http://www.airwire.ie >> Phone: 091-395 000 >> Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in >> Ireland No. 508961 >> > -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961 From alexwr at gmail.com Tue Jan 23 05:02:26 2018 From: alexwr at gmail.com (Alex White-Robinson) Date: Tue, 23 Jan 2018 18:02:26 +1300 Subject: Blockchain and Networking In-Reply-To: <9d553c67-33b8-8669-13b1-16a63eed49ef@nordu.net> References: <8fae3af3-c8c9-729c-0bf7-286dabf0b45f@meetinghouse.net> <196162.1515795628@turing-police.cc.vt.edu> <9d553c67-33b8-8669-13b1-16a63eed49ef@nordu.net> Message-ID: I'd be interested in applications around ownership of IP space or ASNs, but there's so many ways to skin that cat already that people don't do because it's 'hard' or 'reduces our flexibility' or sometimes because it involves hardware upgrades as Christopher Morrow pointed out with RPKI and BGPsec. On Thu, Jan 18, 2018 at 2:20 AM, Fredrik Korsbäck wrote: > On 2018-01-13 03:26, Christopher Morrow wrote: > >> On Fri, Jan 12, 2018 at 5:20 PM, wrote: >> >> On Thu, 11 Jan 2018 15:28:19 -0500, William Herrin said: >>> >>>> On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder >>>> wrote: >>>> >>>>> >>>>> Traceroute or any other path diagnostics comes to mind. >>>>> >>>> >>> That's not obvious to me. Assuming the time-exceeded message was modified >>>> to include the necessary data, how would blockchain authenticate the >>>> responding router? >>>> >>> >>> And do you really want to do *all* that on every single 'TTL Exceeded' >>> ICMP? Sounds like >>> a *really* easy way to DDoS a router.... >>> >>> >> pish-posh! the asics will do it. >> >> > Apparently we are not keeping up with the cool kids here. > > https://www.openct.io/ > > * Open in the name > * .IO TLD > * A scrolling website > > It all checks out as a legitimate web3.0 biz > > ########################################### > > * Blockchain as a Transport (BaaT): BaaT leverages blockchain to create an > architecture that can connect geographically dispersed Layer 2 islands over > any available infrastructure, including the public Internet. As the > resulting solution securely supports all kinds of traffic: Unicast, > Multicast and Broadcast - BaaT will become the transport service of choice > for all businesses. > > * Blockchain-Defined Wide Area Networks (BD-WAN): BD-WAN integrates > blockchain with Software-Defined WAN (SD-WAN) for a secure, scalable > virtualization of WAN transport technologies. Among the unique features > (not available with most SD-WAN architectures): > > The ability to dynamically establish and tear down logical and physical > circuits so customers pay only for what they consume. > > * Inter-Domain MPLS Traffic Engineering via blockchain (near zero time > delay). > > Trusted per-usage billings that are verified and hard-coded over the > blockchain. > > Full visibility and control over all transport facilities either via Fiber > to the Premises (FTTP) or via partnership with key telco operators and > metro Ethernet providers worldwide. > > Bringing public cloud and content services seamlessly to the customers' > doorstep as part of the standard offering. > > > ########################################### > > > I wanna buy all of these stuff right now! > > > -- > hugge > > From jfmezei_nanog at vaxination.ca Tue Jan 23 07:33:15 2018 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 23 Jan 2018 02:33:15 -0500 Subject: End of 2017 hurricane season In-Reply-To: References: Message-ID: <85846bae-76b7-e69c-b7fa-6be368c21196@vaxination.ca> On 2017-11-30 22:34, Sean Donelan wrote: > The #(provider name)sucks tweets on twitter in South Florida and South > Texas have essentially stopped. I assume this means that providers > have repaired almost all Hurricane Harvey and Hurricane Irma damage. Sorry for delay in this old topic. In early december, I bicycled the florida keys. Some of the old railway bridges have been rehabilitated and turned into bike paths. One of these, Toms Harbor Cut Bridge, between Duck Key and Conch key (between Marathon and Isla Morada) (24.7833 -80.9057) There was an AT&T fibre optic cable clearly temporarily hung from the concrete railing through the bike bridge, and then hung in free air for some distance before going underground. This was in an area with much damage. picture: http://www.vaxination.ca/temp/virb0095.jpg (and yes, bike was leaning against the cable :-( So just because service has been restored from the point of view of remote network managers does not mean that the reconstruction is complete. You may find much temporary setups. When one side of the road has been partly washed out by the ocean, chances are that underground cables were damaged if they were on that side. To put things in perspective: In an area that is evacuated, such as the Keys, it takes time before a resident that had been assumed evacuated never returns and is then switched to "missing" (at which point his/her/their home has already been bulldozed and debris moved to side of road for pickup). This means specialized workers to comb through debris to look for human remains. This is long after the media has left. (and yes, I saw that in the Keys). Initial reports of loss of life are totally meaningless. Meanwhile Key West was mostly spared and most of the sunken boats had already been removed. So the average tourist wouldn't really see what Irma did there. It was business as usual with cruise ships etc. The major damage was in the middle keys where media never put much attention. From jfmezei_nanog at vaxination.ca Tue Jan 23 07:42:57 2018 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 23 Jan 2018 02:42:57 -0500 Subject: End of 2017 hurricane season In-Reply-To: <000501d36a6b$b8ab10e0$2a0132a0$@Souvestre.com> References: <000501d36a6b$b8ab10e0$2a0132a0$@Souvestre.com> Message-ID: <139bc14b-2c46-0e98-23f9-1f9bd6298fc0@vaxination.ca> On 2017-12-01 01:15, John Souvestre wrote: > The #(provider name)sucks tweets on twitter in South Florida and South > Texas have essentially stopped. I assume this means that providers > have repaired almost all Hurricane Harvey and Hurricane Irma damage. In an area touched by freezing rain, homes are not damaged and people expect services back within hours and issue "#provider sucks" tweets if they don't. But in an area where homes are rendered uninhabitable, it takes a while before residents can return to their address (either new or repaired home) and then ask for services to be restored. The advantage of this is this is more of a staggered restauration process so less load on utilities who have more time to repair the shared infrastructure before dealing with individual homes. From mysidia at gmail.com Tue Jan 23 13:17:57 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 23 Jan 2018 07:17:57 -0600 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: On Tue, Jan 9, 2018 at 10:22 AM, William Herrin wrote: > On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine wrote: > > The promise of blockchain is fraud-resistant recordkeeping, database management, AND resource management maintained by a distributed decentralized network which eliminates or reduces the extent to which there are central points of trust involved in the recordkeeping, AND can implement resource-management rules or policies programmatically and in an unbiased way (E.G. "Smart Contracts"). For example: A decentralized internet number registry could use a blockchain as the means of making the public records showing the transferrence of the ownership of a particular internet number from the originator to the registrant. The potential is there to go a step beyond replacing RPKI, as a blockchain could be the AS number authority itself, thus eliminating the need to have any centralized organizations for tracking and managing number resource assignments. > How about validating whether a given AS is an acceptable origin for a set > >> of prefixes? > That's a job for ordinary PKI. Any time you have a trusted central > authority to serve as an anchor, ordinary PKI works fine. The RIRs serve as > See: That's the problem. Ordinary PKI DEPENDS on centralized trust -- that is, with PKI there are corruptible or potentially corruptible or compromisable entities in your system that you assign an unwarranted or unnecessary level of trust to. That would include organizations such AS Number and IP Address registries. Under the current system, they retain an Unwarranted level of trust, for example: ARIN Could Delete an IP address allocation or an AS number allocation after it was assigned, because someone else told them to, or maybe someone didn't like the content on your website and coerced/tricked someone who manipulated or legally forced the central figure to do so. This would include whatever entities can be signing authorities of your PKI. This includes any organization with unsecured resource management capabilities, such as the DNS Root server, TLD Server operators, and Domain registrars. Which includes the risks: (1) The signing authority could be breached by an outsider or insider attack (2) The signing authority could prove untrustworthy or later change the rules. (3) The signing authority could be covertly corrupted by a government authority or foreign power: to support nefarious goals or surveilance or censorship. For example: A DNS Registrar or TLD Registry could make a change to the DS Key or remove the DS Key and confiscate a domain to intercept traffic, without even the permission of the original registrant. -- -JH From brock at bmwl.co Tue Jan 23 13:39:29 2018 From: brock at bmwl.co (Brock Tice) Date: Tue, 23 Jan 2018 06:39:29 -0700 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: <5de59750-84b3-21c5-50e6-d55d6fcc733b@bmwl.co> On 1/23/2018 6:17 AM, Jimmy Hess wrote: > The potential is there to go a step beyond replacing RPKI, as a blockchain > could be the AS number authority itself, thus eliminating the need to > have any centralized organizations for tracking and managing > number resource assignments. I am a long-time follower and fan of Bitcoin and I have a lot of skepticism of most of the ideas for using blockchain tech for other things. They seem like ill-thought-out solutions in search of a problem. HOWEVER, various Internet/number authorities are sometimes a big point of contention, subject to government pressure, etc, and this is one case where I can see a trustless, distributed blockchain architecture actually improving things. I think your email (not just the quoted part) was a good insight on the subject. --Brock From nanog at ics-il.net Tue Jan 23 14:12:07 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 23 Jan 2018 08:12:07 -0600 (CST) Subject: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet In-Reply-To: References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> Message-ID: <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> If only they had decent BGP community support. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Martin List-Petersen" To: "Michael Crapse" Cc: "Mike Hammett" , "NANOG list" Sent: Monday, January 22, 2018 8:24:46 PM Subject: Re: Anyone using Cogent Ethernet On 23/01/18 02:12, Michael Crapse wrote: > Tier 1 just means they don't pay for ip transit themselves, only Peering. > Doesn't mean that it's good transit. > Best provider i've ever used is hurricane electric, actually a tier 2 > provider, but bigger/better than many tier 1s. I'd still categorise Hurricane a lot better than Cogent. Both quality and customer service wise. /M > On 22 January 2018 at 19:07, Martin List-Petersen wrote: > >> On 22/01/18 20:05, Mike Hammett wrote: >> >>> I much prefer using WDM transport as opposed to Ethernet\VPLS transport >>> due to it being significantly harder (I try not to say impossible) to >>> oversubscribe. That said, it isn't always available at a decent rate at a >>> given location. >>> >>> Cogent has a reputation (right or wrong) for running things a little hot. >>> >>> Have any of you used Cogent Ethernet\VPLS services? What are you >>> experiences? Offlist is fine if you don't want it public. >>> >> >> Never use them without a backup alternative. I've seen more outages, that >> one would want to ever see from a provider, that would like to be >> categorised as Tier1. >> >> Especially, when some of these are longer than expected, because there >> were no cold-spares in the country and the cold-spare needed missed the >> flight. >> >> /M >> -- >> Airwire Ltd. - Ag Nascadh Pobail an Iarthair >> http://www.airwire.ie >> Phone: 091-395 000 >> Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in >> Ireland No. 508961 >> > -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961 From benno at NLnetLabs.nl Tue Jan 23 14:21:24 2018 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 23 Jan 2018 15:21:24 +0100 Subject: Call for presentations RIPE 76 Message-ID: <909d5e68-5689-4428-9ee8-238ba2b1f78e@NLnetLabs.nl> Dear colleagues, Please find the CFP for RIPE 76 below or at: https://ripe76.ripe.net/submit-topic/cfp/. The deadline for submissions is *11 March 2018*. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings, see the "Speakers" paragraph in CFP for more information. Kind regards, Benno Overeinder RIPE PC Chair https://ripe76.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 76 will take place from 14-18 May in Marseille, France. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 76. See the full descriptions of the different presentation formats, https://ripe76.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *11 March 2018*. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Speakers Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc at ripe.net. Also note that, on an individual basis, participants can apply for a RIPE Fellowship to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship Submissions Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe76.ripe.net/plenary-or-wg/ RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour (during evening sessions) - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe76.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe76.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. If you have any questions or requests concerning content submissions, please email pc at ripe.net. -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ From johnl at iecc.com Tue Jan 23 15:39:08 2018 From: johnl at iecc.com (John R. Levine) Date: 23 Jan 2018 10:39:08 -0500 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: Thanks for this note -- I couldn't ask for a better explanation of why blockchains don't solve any actual real world problems. Trust problems are difficult, and waving hands and saying decentralize! solves nothing. For the nanog-related example of validating AS origin, the problem isn't keeping the database, it's figuring out who can make authoritative statements about each block of IP addresses. That is an inherently hierarchical question since all IP blocks originally trace back to allocations from IANA. We can have arguments about the best way to document the chain of ownership, and conspiracy theories about how the evil RIRs are planning to steal our precious bodily flu^W^WIPs, but "put it in a blockchain!" Puhleeze. R's, John On Tue, 23 Jan 2018, Jimmy Hess wrote: > On Tue, Jan 9, 2018 at 10:22 AM, William Herrin wrote: > >> On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine wrote: >> > The promise of blockchain is fraud-resistant recordkeeping, database > management, AND > resource management maintained by a distributed decentralized network which > eliminates or reduces the extent to which there are central points of trust > involved in the recordkeeping, > > AND can implement resource-management rules or policies programmatically > and in an unbiased way (E.G. "Smart Contracts"). > > For example: A decentralized internet number registry could use a blockchain > as the means of making the public records showing the transferrence of the > ownership of a particular internet number from the originator to the > registrant. > > The potential is there to go a step beyond replacing RPKI, as a blockchain > could be the AS number authority itself, thus eliminating the need to > have any centralized organizations for tracking and managing > number resource assignments. > >> How about validating whether a given AS is an acceptable origin for a set >>>> of prefixes? >> That's a job for ordinary PKI. Any time you have a trusted central >> authority to serve as an anchor, ordinary PKI works fine. The RIRs serve as >> > > See: That's the problem. Ordinary PKI DEPENDS on centralized trust -- > that is, with PKI there are corruptible or potentially corruptible or > compromisable entities in your system that you assign an unwarranted or > unnecessary level of trust to. > > That would include organizations such AS Number and IP Address registries. > Under the current system, they retain an Unwarranted level of trust, for > example: ARIN Could Delete an IP address allocation or an AS number > allocation after it was assigned, because someone else told them to, > or maybe someone didn't like the content on your website and > coerced/tricked > someone who manipulated or legally forced the central figure to do so. > > This would include whatever entities can be signing authorities of your PKI. > This includes any organization with unsecured resource management > capabilities, > such as the DNS Root server, TLD Server operators, and Domain registrars. > > Which includes the risks: > (1) The signing authority could be breached by an outsider or insider > attack > (2) The signing authority could prove untrustworthy or later change > the rules. > (3) The signing authority could be covertly corrupted by a government > authority > or foreign power: to support nefarious goals or surveilance or > censorship. > > For example: A DNS Registrar or TLD Registry could make a change to the DS > Key or remove > the DS Key and confiscate a domain to intercept traffic, without even the > permission > of the original registrant. > > > Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From bill at herrin.us Tue Jan 23 15:54:10 2018 From: bill at herrin.us (William Herrin) Date: Tue, 23 Jan 2018 10:54:10 -0500 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: On Tue, Jan 23, 2018 at 8:17 AM, Jimmy Hess wrote: > On Tue, Jan 9, 2018 at 10:22 AM, William Herrin wrote: > >> On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine wrote: >> >> > The promise of blockchain is fraud-resistant recordkeeping, database > management, > Hi Jimmy, That is -so- not the case. The single most important concept in fraud resistance is reversibility. Once a transaction is determined to be fraudulent, the authority making the determination must be able to reverse the transaction. Banks bouncing a check. The tax records office restoring ownership of a house upon order by the court. Blockchain's objective was to make transactions non-repudiable and they succeeded. However, that interacts with its decentralized nature to make those transactions irreversible as well. Bitcoins have been stolen from exchanges. The fraud can't be reversed. Blockchain is not resistant to fraud. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From michael.holstein at csuohio.edu Tue Jan 23 16:12:15 2018 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Tue, 23 Jan 2018 16:12:15 +0000 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> , Message-ID: > Blockchain's objective was to make transactions non-repudiable and > they succeeded. However, that interacts with its decentralized > nature to make those transactions irreversible as well. To re-use your example, banks don't "delete" the record of the bad check, they just create an offsetting journal entry, as both records are important to preserve. A transaction ledger is supposed to authenticate *every* transaction, and if you need to create an offsetting transaction, you do so in the same manner, and process the result in your code .. but the "bad" transaction DID happen as did your "deletion" of it, and as such, both actions are recorded. To apply to a real-world example .. Betty votes for X, but it's later determined that Betty was ineligible because (whatever). Betty's vote is recorded, as is the administrative cancellation thereof. It's critical that both transactions be recorded, attributed, non-reputeable. The system isn't designed to prevent fraud *itself*, it's designed to prevent alteration of the ledger. Regards, Michael Holstein CISSP Mgr. Network & Data Security Cleveland State University From mel at beckman.org Tue Jan 23 16:21:05 2018 From: mel at beckman.org (Mel Beckman) Date: Tue, 23 Jan 2018 16:21:05 +0000 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> , , Message-ID: You're precisely right Michael. People who say blockchain doesn't solve any real world problems, haven't tried solving the problems Block chain so handily tackles using some other method. Trust is a huge vulnerability, as we have seen over and over in the crypto biz. In aviation, for example, we use blockchain now to authenticate parts used in maintenance, repair, and overhaul (MRO). Because trust (in the supply chain) failed us, and unsafe counterfeit parts have flooded the market, making this a life or death problem. -mel beckman On Jan 23, 2018, at 8:12 AM, Michael O Holstein wrote: >> Blockchain's objective was to make transactions non-repudiable and > they succeeded. However, that interacts with its decentralized > >> nature to make those transactions irreversible as well. > > To re-use your example, banks don't "delete" the record of the bad check, they just create an offsetting journal entry, as both records are important to preserve. > > A transaction ledger is supposed to authenticate *every* transaction, and if you need to create an offsetting transaction, you do so in the same manner, and process the result in your code .. but the "bad" transaction DID happen as did your "deletion" of it, and as such, both actions are recorded. > > To apply to a real-world example .. Betty votes for X, but it's later determined that Betty was ineligible because (whatever). Betty's vote is recorded, as is the administrative cancellation thereof. It's critical that both transactions be recorded, attributed, non-reputeable. > > The system isn't designed to prevent fraud *itself*, it's designed to prevent alteration of the ledger. > > Regards, > > Michael Holstein CISSP > Mgr. Network & Data Security > Cleveland State University From ryangard at gmail.com Tue Jan 23 16:56:58 2018 From: ryangard at gmail.com (Ryan Gard) Date: Tue, 23 Jan 2018 11:56:58 -0500 Subject: Leasing /22 In-Reply-To: References: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> Message-ID: The biggest problems that start to run with cases of CGN or any other v4 aggregation method are services that still continue to treat single IP addresses as a single entity (a certain event ticket vendor comes to mind). Until these organizations either start opening a line of communications with ISPs, changing their methodology when handling traffic from v4 addresses, and/or deploying v6, the song and dance for v4 addressing will continue. On Mon, Jan 22, 2018 at 7:57 PM, Lee Howard wrote: > > > From: Michael Crapse > Date: Monday, January 22, 2018 at 5:27 PM > To: Mark Andrews > Cc: Lee Howard , NANOG list > Subject: Re: Leasing /22 > > > Customers on ps4s and xboxes will hate you. They will always get > "strict" nat, > > and it's your fault not mega corporation X's fault for not releasing > IPv4s > > Maybe. You don’t have to configure strict NAT on your translator (DS-Lite’s > pretty good at this, and although I’m a few weeks away from testing > consoles > through 464xlat and MAP, they should work, too). And their NAT workarounds > are pretty sophisticated now. > > There comes a point when winning your customers’ love isn’t profitable. I > don’t know if that point is $16/address for you, or $30, or $40, or $90. > Maybe it varies, depending on the customer. > > That’s why I suggested in “TCO of CGN”[1] that everyone figure out for > themselves how much money you might lose to unhappy customers via CGN, and > compare it to how much addresses cost, and at what price point you might > turn around and sell addresses. My findings then, based on assumptions that > almost certainly are not true for any particular network, and which may > have > changed, suggest that buying addresses still makes sense. > > > Lee > > [1] http://ipv6.nanog.org/meetings/abstract?id=2025 > > > > > > On 22 January 2018 at 15:23, Mark Andrews wrote: > >> Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that > >> reaches its limit at ~4M customers. > >> > >> Native IPv4 with a GUA to customers is essentially unavailable for new > >> ISPs. It’s a matter of picking which flavour of NAT you and your > >> customers are going to use. The sooner ALL ISP’s provide IPv6 to their > >> customers the sooner we restore delivering the Internet to the > customers. > >> > >> Mark > >> > >>> > On 23 Jan 2018, at 9:05 am, Lee Howard wrote: > >>> > > >>> > IPv6 still solves your problem if you add any of NAT64, DS-Lite, > 464xlat, > >>> > MAP-T, MAP-E. > >>> > > >>> > Yes, you’re NATing, but only the traffic to places like Hulu, and it > will > >>> > decrease over time. And while you need addresses for the outside of > the > >>> > translator, you don’t need as many (or to get more as frequently). > >>> > > >>> > Lee > >>> > > >>> > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett" > >>> > wrote: > >>> > > >>>> >> It's not really scraping the bottom of the barrel if your > customers are > >>>> >> using Hulu and they're complaining because Hulu isn't responsive to > >>>> >> fixing their problems (geo-location, v6, etc.). > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> ----- > >>>> >> Mike Hammett > >>>> >> Intelligent Computing Solutions > >>>> >> http://www.ics-il.com > >>>> >> > >>>> >> Midwest-IX > >>>> >> http://www.midwest-ix.com > >>>> >> > >>>> >> ----- Original Message ----- > >>>> >> > >>>> >> From: "Ca By" > >>>> >> To: "Michael Crapse" > >>>> >> Cc: "NANOG list" > >>>> >> Sent: Friday, January 19, 2018 9:54:23 PM > >>>> >> Subject: Re: Leasing /22 > >>>> >> > >>>> >> On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse < > michael at wi-fiber.io> > >>>> >> wrote: > >>>> >> > >>>>> >>> Has Hulu, or a thousand other content distributors considered > IPv6? > >>>>> >>> Because > >>>>> >>> you can't even tunnel to ipv4 without setting off VPN alarms with > >>>>> HULU. > >>>>> >>> > >>>> >> > >>>> >> Hulu? Really scraping the bottom of the barrel of content > providers that > >>>> >> dont use ipv6 these days. > >>>> >> > >>>> >> Netflix and Youtube support v6 ... and thousand of others > (thousands > >>>> just > >>>> >> on Cloudflare where v6 is default on) > >>>> >> > >>>> >> About 80% of my traffic is native e2e v6, mostly google / youtube > / fb / > >>>> >> netflix / apple / amazon — but your mix may vary. > >>>> >> > >>>> >> > >>>> >> > >>>>> >>> > >>>>> >>> > >>>>> >>> On 19 January 2018 at 18:38, Andrew Kirch > wrote: > >>>>> >>> > >>>>>> >>>> On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard > >>>>>> wrote: > >>>>>> >>>> > >>>>>>> >>>>> We're on the hunt yet again for an additional /22 to lease, > and > are > >>>>>>> >>>>> wondering what the best options are out there? > >>>>>>> >>>>> > >>>>>>> >>>>> Our usual suspects that we've reached out to in the past > seem to > be > >>>>> >>> plum > >>>>>>> >>>>> out... Any recommendations? > >>>>>>> >>>>> > >>>>>>> >>>>> Thanks! > >>>>>>> >>>>> > >>>>>>> >>>>> -- > >>>>>>> >>>>> Ryan Gard > >>>>>>> >>>>> > >>>>>> >>>> Have you considered IPv6? > >>>>>> >>>> > >>>>> >>> > >>>> >> > >>>> >> > >>> > > >>> > > >> > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 > INTERNET: > >> marka at isc.org > >> > > > > > -- Ryan Gard From michael at wi-fiber.io Tue Jan 23 16:59:45 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 23 Jan 2018 09:59:45 -0700 Subject: Leasing /22 In-Reply-To: References: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> Message-ID: The funnest part is telling DMCA/RIAA that an IP address means nothing, not without a port and exact time, someitmes down to a 10 minute mark. CGNAT + NAT64/464 xlat using the fewest ipv4s as possible(as suggested) also requires a large database to retain all records of every port and ipv4 address connected with every new connection. On 23 January 2018 at 09:56, Ryan Gard wrote: > The biggest problems that start to run with cases of CGN or any other v4 > aggregation method are services that still continue to treat single IP > addresses as a single entity (a certain event ticket vendor comes to mind). > Until these organizations either start opening a line of communications > with ISPs, changing their methodology when handling traffic from v4 > addresses, and/or deploying v6, the song and dance for v4 addressing will > continue. > > On Mon, Jan 22, 2018 at 7:57 PM, Lee Howard wrote: > >> >> >> From: Michael Crapse >> Date: Monday, January 22, 2018 at 5:27 PM >> To: Mark Andrews >> Cc: Lee Howard , NANOG list >> Subject: Re: Leasing /22 >> >> > Customers on ps4s and xboxes will hate you. They will always get >> "strict" nat, >> > and it's your fault not mega corporation X's fault for not releasing >> IPv4s >> >> Maybe. You don’t have to configure strict NAT on your translator >> (DS-Lite’s >> pretty good at this, and although I’m a few weeks away from testing >> consoles >> through 464xlat and MAP, they should work, too). And their NAT workarounds >> are pretty sophisticated now. >> >> There comes a point when winning your customers’ love isn’t profitable. I >> don’t know if that point is $16/address for you, or $30, or $40, or $90. >> Maybe it varies, depending on the customer. >> >> That’s why I suggested in “TCO of CGN”[1] that everyone figure out for >> themselves how much money you might lose to unhappy customers via CGN, and >> compare it to how much addresses cost, and at what price point you might >> turn around and sell addresses. My findings then, based on assumptions >> that >> almost certainly are not true for any particular network, and which may >> have >> changed, suggest that buying addresses still makes sense. >> >> >> Lee >> >> [1] http://ipv6.nanog.org/meetings/abstract?id=2025 >> >> >> > >> > On 22 January 2018 at 15:23, Mark Andrews wrote: >> >> Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that >> >> reaches its limit at ~4M customers. >> >> >> >> Native IPv4 with a GUA to customers is essentially unavailable for new >> >> ISPs. It’s a matter of picking which flavour of NAT you and your >> >> customers are going to use. The sooner ALL ISP’s provide IPv6 to their >> >> customers the sooner we restore delivering the Internet to the >> customers. >> >> >> >> Mark >> >> >> >>> > On 23 Jan 2018, at 9:05 am, Lee Howard wrote: >> >>> > >> >>> > IPv6 still solves your problem if you add any of NAT64, DS-Lite, >> 464xlat, >> >>> > MAP-T, MAP-E. >> >>> > >> >>> > Yes, you’re NATing, but only the traffic to places like Hulu, and >> it will >> >>> > decrease over time. And while you need addresses for the outside of >> the >> >>> > translator, you don’t need as many (or to get more as frequently). >> >>> > >> >>> > Lee >> >>> > >> >>> > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett" >> >>> > wrote: >> >>> > >> >>>> >> It's not really scraping the bottom of the barrel if your >> customers are >> >>>> >> using Hulu and they're complaining because Hulu isn't responsive >> to >> >>>> >> fixing their problems (geo-location, v6, etc.). >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> ----- >> >>>> >> Mike Hammett >> >>>> >> Intelligent Computing Solutions >> >>>> >> http://www.ics-il.com >> >>>> >> >> >>>> >> Midwest-IX >> >>>> >> http://www.midwest-ix.com >> >>>> >> >> >>>> >> ----- Original Message ----- >> >>>> >> >> >>>> >> From: "Ca By" >> >>>> >> To: "Michael Crapse" >> >>>> >> Cc: "NANOG list" >> >>>> >> Sent: Friday, January 19, 2018 9:54:23 PM >> >>>> >> Subject: Re: Leasing /22 >> >>>> >> >> >>>> >> On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse < >> michael at wi-fiber.io> >> >>>> >> wrote: >> >>>> >> >> >>>>> >>> Has Hulu, or a thousand other content distributors considered >> IPv6? >> >>>>> >>> Because >> >>>>> >>> you can't even tunnel to ipv4 without setting off VPN alarms >> with >> >>>>> HULU. >> >>>>> >>> >> >>>> >> >> >>>> >> Hulu? Really scraping the bottom of the barrel of content >> providers that >> >>>> >> dont use ipv6 these days. >> >>>> >> >> >>>> >> Netflix and Youtube support v6 ... and thousand of others >> (thousands >> >>>> just >> >>>> >> on Cloudflare where v6 is default on) >> >>>> >> >> >>>> >> About 80% of my traffic is native e2e v6, mostly google / youtube >> / fb / >> >>>> >> netflix / apple / amazon — but your mix may vary. >> >>>> >> >> >>>> >> >> >>>> >> >> >>>>> >>> >> >>>>> >>> >> >>>>> >>> On 19 January 2018 at 18:38, Andrew Kirch >> wrote: >> >>>>> >>> >> >>>>>> >>>> On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard > > >> >>>>>> wrote: >> >>>>>> >>>> >> >>>>>>> >>>>> We're on the hunt yet again for an additional /22 to lease, >> and >> are >> >>>>>>> >>>>> wondering what the best options are out there? >> >>>>>>> >>>>> >> >>>>>>> >>>>> Our usual suspects that we've reached out to in the past >> seem to >> be >> >>>>> >>> plum >> >>>>>>> >>>>> out... Any recommendations? >> >>>>>>> >>>>> >> >>>>>>> >>>>> Thanks! >> >>>>>>> >>>>> >> >>>>>>> >>>>> -- >> >>>>>>> >>>>> Ryan Gard >> >>>>>>> >>>>> >> >>>>>> >>>> Have you considered IPv6? >> >>>>>> >>>> >> >>>>> >>> >> >>>> >> >> >>>> >> >> >>> > >> >>> > >> >> >> >> -- >> >> Mark Andrews, ISC >> >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> >> >> PHONE: +61 2 9871 4742 >> INTERNET: >> >> marka at isc.org >> >> >> > >> >> >> > > > -- > Ryan Gard > From James at arenalgroup.co Tue Jan 23 18:38:36 2018 From: James at arenalgroup.co (James Breeden) Date: Tue, 23 Jan 2018 18:38:36 +0000 Subject: BGP Community Support WAS: Re: Cogent vs. HE ; -) WAS: Anyone using Cogent Ethernet In-Reply-To: <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> , <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> Message-ID: While we're on the topic of BGP community support, I'd be interested in the greater group's favorites, pros, and cons of what you want to see in a BGP community support table/system from a provider. Taking notes for a customer.. James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co ________________________________ From: NANOG on behalf of Mike Hammett Sent: Tuesday, January 23, 2018 8:12 AM Cc: NANOG list Subject: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet If only they had decent BGP community support. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Martin List-Petersen" To: "Michael Crapse" Cc: "Mike Hammett" , "NANOG list" Sent: Monday, January 22, 2018 8:24:46 PM Subject: Re: Anyone using Cogent Ethernet On 23/01/18 02:12, Michael Crapse wrote: > Tier 1 just means they don't pay for ip transit themselves, only Peering. > Doesn't mean that it's good transit. > Best provider i've ever used is hurricane electric, actually a tier 2 > provider, but bigger/better than many tier 1s. I'd still categorise Hurricane a lot better than Cogent. Both quality and customer service wise. /M > On 22 January 2018 at 19:07, Martin List-Petersen wrote: > >> On 22/01/18 20:05, Mike Hammett wrote: >> >>> I much prefer using WDM transport as opposed to Ethernet\VPLS transport >>> due to it being significantly harder (I try not to say impossible) to >>> oversubscribe. That said, it isn't always available at a decent rate at a >>> given location. >>> >>> Cogent has a reputation (right or wrong) for running things a little hot. >>> >>> Have any of you used Cogent Ethernet\VPLS services? What are you >>> experiences? Offlist is fine if you don't want it public. >>> >> >> Never use them without a backup alternative. I've seen more outages, that >> one would want to ever see from a provider, that would like to be >> categorised as Tier1. >> >> Especially, when some of these are longer than expected, because there >> were no cold-spares in the country and the cold-spare needed missed the >> flight. >> >> /M >> -- >> Airwire Ltd. - Ag Nascadh Pobail an Iarthair >> http://www.airwire.ie >> Phone: 091-395 000 >> Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in >> Ireland No. 508961 >> > -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961 From nanog at ics-il.net Tue Jan 23 18:40:12 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 23 Jan 2018 12:40:12 -0600 (CST) Subject: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet In-Reply-To: References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> Message-ID: <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> These? :-) https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "James Breeden" To: "Mike Hammett" Cc: "NANOG list" Sent: Tuesday, January 23, 2018 12:38:36 PM Subject: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet While we're on the topic of BGP community support, I'd be interested in the greater group's favorites, pros, and cons of what you want to see in a BGP community support table/system from a provider. Taking notes for a customer.. James W. Breeden Managing Partner logo_transparent_background Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co From: NANOG on behalf of Mike Hammett Sent: Tuesday, January 23, 2018 8:12 AM Cc: NANOG list Subject: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet If only they had decent BGP community support. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Martin List-Petersen" To: "Michael Crapse" Cc: "Mike Hammett" , "NANOG list" Sent: Monday, January 22, 2018 8:24:46 PM Subject: Re: Anyone using Cogent Ethernet On 23/01/18 02:12, Michael Crapse wrote: > Tier 1 just means they don't pay for ip transit themselves, only Peering. > Doesn't mean that it's good transit. > Best provider i've ever used is hurricane electric, actually a tier 2 > provider, but bigger/better than many tier 1s. I'd still categorise Hurricane a lot better than Cogent. Both quality and customer service wise. /M > On 22 January 2018 at 19:07, Martin List-Petersen wrote: > >> On 22/01/18 20:05, Mike Hammett wrote: >> >>> I much prefer using WDM transport as opposed to Ethernet\VPLS transport >>> due to it being significantly harder (I try not to say impossible) to >>> oversubscribe. That said, it isn't always available at a decent rate at a >>> given location. >>> >>> Cogent has a reputation (right or wrong) for running things a little hot. >>> >>> Have any of you used Cogent Ethernet\VPLS services? What are you >>> experiences? Offlist is fine if you don't want it public. >>> >> >> Never use them without a backup alternative. I've seen more outages, that >> one would want to ever see from a provider, that would like to be >> categorised as Tier1. >> >> Especially, when some of these are longer than expected, because there >> were no cold-spares in the country and the cold-spare needed missed the >> flight. >> >> /M >> -- >> Airwire Ltd. - Ag Nascadh Pobail an Iarthair >> http://www.airwire.ie >> Phone: 091-395 000 >> Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in >> Ireland No. 508961 >> > -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961 From morrowc.lists at gmail.com Tue Jan 23 19:07:29 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 23 Jan 2018 14:07:29 -0500 Subject: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet In-Reply-To: <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> Message-ID: On Tue, Jan 23, 2018 at 1:40 PM, Mike Hammett wrote: > These? :-) > > https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf > > you could also probably get some good examples cribbed from the collection: https://onestep.net/communities/ From James at arenalgroup.co Tue Jan 23 19:17:45 2018 From: James at arenalgroup.co (James Breeden) Date: Tue, 23 Jan 2018 19:17:45 +0000 Subject: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet In-Reply-To: References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck>, Message-ID: I've seen the onestep list but the presentation is helpful. I guess my question was moreso to the people side of communities vs the technicalities of communities - what ones do people find themselves using most often and what do they wish was available from providers that really isn't otherwise out there? James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co ________________________________ From: christopher.morrow at gmail.com on behalf of Christopher Morrow Sent: Tuesday, January 23, 2018 1:07:29 PM To: Mike Hammett Cc: James Breeden; NANOG list Subject: Re: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet On Tue, Jan 23, 2018 at 1:40 PM, Mike Hammett > wrote: These? :-) https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf you could also probably get some good examples cribbed from the collection: https://onestep.net/communities/ From jfmezei_nanog at vaxination.ca Tue Jan 23 20:39:12 2018 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 23 Jan 2018 15:39:12 -0500 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: On 2018-01-23 08:17, Jimmy Hess wrote: > The promise of blockchain is fraud-resistant recordkeeping, database > management, AND > resource management maintained by a distributed decentralized network which > eliminates or reduces the extent to which there are central points of trust > involved in > the recordkeeping, Current distributed "block chain" systems are architecturally insecure, but with the requirement of computationally intensive "proof of work", reduce risk of someone succesfully tampering a block to near 0. However, to put things in perspective: Hydro Québec recently revealed that it was not interested in "bitcoin mining" operations in Québec which consume inordinate amount of power without producing anything of value. > Under the current system, they retain an Unwarranted level of trust, for > example: ARIN Could Delete an IP address allocation or an AS number > allocation after it was assigned, because someone else told them to, A recent case in Canada had the supreme court order Google to remove a domain name from worldwide searches (so extra territorial court powers). (rogue company stole product design freom real company, refused to appear in court, so real company went to court asking Google to remove that rogue compamy from searches). The correct way would have been to get warrant on the registrar to take the domain name out of the onwer's hands. Or go after the web site provider. When the legal system starts to go after the wrong people"/process to enforce law, you get problems. There may be impulse to make the Internet "government proof", but this will simply shift government actions to more inappropriate but still avaialble methods of trying to enforce the law. > For example: A DNS Registrar or TLD Registry could make a change to the DS > Key or remove > the DS Key and confiscate a domain to intercept traffic, without even the > permission > of the original registrant. Choose your registrar/regitry who will only take actiosn with valid court orders and otherwise protect your privacy. From bill at herrin.us Tue Jan 23 20:45:11 2018 From: bill at herrin.us (William Herrin) Date: Tue, 23 Jan 2018 15:45:11 -0500 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: On Tue, Jan 23, 2018 at 11:12 AM, Michael O Holstein wrote: >> Blockchain's objective was to make transactions non-repudiable and > they >> succeeded. However, that interacts with its decentralized >> nature to make those transactions irreversible as well. > > To re-use your example, banks don't "delete" the record of the bad check, > they just create an offsetting journal entry, as both records are important > to preserve. > > The system isn't designed to prevent fraud *itself*, it's designed to > prevent alteration of the ledger. Hi Michael, That's correct, and in the bank scenario the bank acting as an authority is able make additions the the ledger which reverse the transaction. In blockchain, there is no central authority and there's a cryptographic guarantee than only the most recent holder of the block may add to the block's ledger. As a consequence, non-repudiability escalates to irreversibility making the system vulnerable to fraud perpetrated by anyone who can briefly gain access to a block's current credentials. If someone steals my credit card, I don't end up paying a nickel. If someone steals my bitcoin wallet, I'm f******. Given the cost of renumbering, we'd have to be insane to depend on blockchain for address management. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From clinton at scripty.com Tue Jan 23 21:15:35 2018 From: clinton at scripty.com (Clinton Work) Date: Tue, 23 Jan 2018 14:15:35 -0700 Subject: BGP Community Support WAS: Re: Cogent vs. HE ; -) WAS: Anyone using Cogent Ethernet In-Reply-To: References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> Message-ID: <1516742135.1891386.1245705504.300D82BC@webmail.messagingengine.com> BGP communities I use the most: - Influence the transit provider BGP local-preference: customer preferred, customer backup, peer, and transit LP values - Only advertise routes to the transit provider customers and not their peers - Don't advertise routes to transit providers' peer ASx. - AS-prepend X times to transit providers' peer ASx. I've had a couple of situations where a CDN provider is sending all their traffic via one transit provider. A BGP community to not advertise or as-prepend our routes to that CDN provider would have been handy. Most transit providers only allow you to not advertise or as-prepend to their peers and not other customers. On Tue, Jan 23, 2018, at 12:17 PM, James Breeden wrote: > I've seen the onestep list but the presentation is helpful. I guess my > question was moreso to the people side of communities vs the > technicalities of communities - what ones do people find themselves > using most often and what do they wish was available from providers that > really isn't otherwise out there? > From dwhite at olp.net Tue Jan 23 21:35:18 2018 From: dwhite at olp.net (Dan White) Date: Tue, 23 Jan 2018 15:35:18 -0600 Subject: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet In-Reply-To: References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> Message-ID: <20180123213518.rriw23xe3tfu2nwx@dan.olp.net> On 01/23/18 19:17 +0000, James Breeden wrote: >I've seen the onestep list but the presentation is helpful. I guess my >question was moreso to the people side of communities vs the >technicalities of communities - what ones do people find themselves using >most often and what do they wish was available from providers that really >isn't otherwise out there? The most useful to me: Blackhole this prefix Only advertise this prefix to your customers Prepend my/your ASN to this prefix X number of times Do not readvertise this prefix to any content caches you host and I'd like to see more transits offer BFD. -- Dan White From bryan at shout.net Tue Jan 23 22:22:28 2018 From: bryan at shout.net (Bryan Holloway) Date: Tue, 23 Jan 2018 16:22:28 -0600 Subject: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet In-Reply-To: <20180123213518.rriw23xe3tfu2nwx@dan.olp.net> References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> <20180123213518.rriw23xe3tfu2nwx@dan.olp.net> Message-ID: <38d173e4-1de1-1224-99ea-cbedb9f1b168@shout.net> +1 on BFD ... On 1/23/18 3:35 PM, Dan White wrote: > On 01/23/18 19:17 +0000, James Breeden wrote: >> I've seen the onestep list but the presentation is helpful. I guess my >> question was moreso to the people side of communities vs the >> technicalities of communities - what ones do people find themselves using >> most often and what do they wish was available from providers that really >> isn't otherwise out there? > > The most useful to me: > > Blackhole this prefix > Only advertise this prefix to your customers > Prepend my/your ASN to this prefix X number of times > Do not readvertise this prefix to any content caches you host > > and I'd like to see more transits offer BFD. > From marka at isc.org Tue Jan 23 22:47:19 2018 From: marka at isc.org (Mark Andrews) Date: Wed, 24 Jan 2018 09:47:19 +1100 Subject: Leasing /22 In-Reply-To: References: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> Message-ID: <56118119-C7F5-4557-AA12-6B46379AE742@isc.org> Which is where MAP-T and MAP-E help as they reduce the amount of logging required. > On 24 Jan 2018, at 3:59 am, Michael Crapse wrote: > > The funnest part is telling DMCA/RIAA that an IP address means nothing, not without a port and exact time, someitmes down to a 10 minute mark. CGNAT + NAT64/464 xlat using the fewest ipv4s as possible(as suggested) also requires a large database to retain all records of every port and ipv4 address connected with every new connection. > > On 23 January 2018 at 09:56, Ryan Gard wrote: > The biggest problems that start to run with cases of CGN or any other v4 aggregation method are services that still continue to treat single IP addresses as a single entity (a certain event ticket vendor comes to mind). Until these organizations either start opening a line of communications with ISPs, changing their methodology when handling traffic from v4 addresses, and/or deploying v6, the song and dance for v4 addressing will continue. > > On Mon, Jan 22, 2018 at 7:57 PM, Lee Howard wrote: > > > From: Michael Crapse > Date: Monday, January 22, 2018 at 5:27 PM > To: Mark Andrews > Cc: Lee Howard , NANOG list > Subject: Re: Leasing /22 > > > Customers on ps4s and xboxes will hate you. They will always get "strict" nat, > > and it's your fault not mega corporation X's fault for not releasing IPv4s > > Maybe. You don’t have to configure strict NAT on your translator (DS-Lite’s > pretty good at this, and although I’m a few weeks away from testing consoles > through 464xlat and MAP, they should work, too). And their NAT workarounds > are pretty sophisticated now. > > There comes a point when winning your customers’ love isn’t profitable. I > don’t know if that point is $16/address for you, or $30, or $40, or $90. > Maybe it varies, depending on the customer. > > That’s why I suggested in “TCO of CGN”[1] that everyone figure out for > themselves how much money you might lose to unhappy customers via CGN, and > compare it to how much addresses cost, and at what price point you might > turn around and sell addresses. My findings then, based on assumptions that > almost certainly are not true for any particular network, and which may have > changed, suggest that buying addresses still makes sense. > > > Lee > > [1] http://ipv6.nanog.org/meetings/abstract?id=2025 > > > > > > On 22 January 2018 at 15:23, Mark Andrews wrote: > >> Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that > >> reaches its limit at ~4M customers. > >> > >> Native IPv4 with a GUA to customers is essentially unavailable for new > >> ISPs. It’s a matter of picking which flavour of NAT you and your > >> customers are going to use. The sooner ALL ISP’s provide IPv6 to their > >> customers the sooner we restore delivering the Internet to the customers. > >> > >> Mark > >> > >>> > On 23 Jan 2018, at 9:05 am, Lee Howard wrote: > >>> > > >>> > IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat, > >>> > MAP-T, MAP-E. > >>> > > >>> > Yes, you’re NATing, but only the traffic to places like Hulu, and it will > >>> > decrease over time. And while you need addresses for the outside of the > >>> > translator, you don’t need as many (or to get more as frequently). > >>> > > >>> > Lee > >>> > > >>> > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett" > >>> > wrote: > >>> > > >>>> >> It's not really scraping the bottom of the barrel if your customers are > >>>> >> using Hulu and they're complaining because Hulu isn't responsive to > >>>> >> fixing their problems (geo-location, v6, etc.). > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> ----- > >>>> >> Mike Hammett > >>>> >> Intelligent Computing Solutions > >>>> >> http://www.ics-il.com > >>>> >> > >>>> >> Midwest-IX > >>>> >> http://www.midwest-ix.com > >>>> >> > >>>> >> ----- Original Message ----- > >>>> >> > >>>> >> From: "Ca By" > >>>> >> To: "Michael Crapse" > >>>> >> Cc: "NANOG list" > >>>> >> Sent: Friday, January 19, 2018 9:54:23 PM > >>>> >> Subject: Re: Leasing /22 > >>>> >> > >>>> >> On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse > >>>> >> wrote: > >>>> >> > >>>>> >>> Has Hulu, or a thousand other content distributors considered IPv6? > >>>>> >>> Because > >>>>> >>> you can't even tunnel to ipv4 without setting off VPN alarms with > >>>>> HULU. > >>>>> >>> > >>>> >> > >>>> >> Hulu? Really scraping the bottom of the barrel of content providers that > >>>> >> dont use ipv6 these days. > >>>> >> > >>>> >> Netflix and Youtube support v6 ... and thousand of others (thousands > >>>> just > >>>> >> on Cloudflare where v6 is default on) > >>>> >> > >>>> >> About 80% of my traffic is native e2e v6, mostly google / youtube / fb / > >>>> >> netflix / apple / amazon — but your mix may vary. > >>>> >> > >>>> >> > >>>> >> > >>>>> >>> > >>>>> >>> > >>>>> >>> On 19 January 2018 at 18:38, Andrew Kirch wrote: > >>>>> >>> > >>>>>> >>>> On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard > >>>>>> wrote: > >>>>>> >>>> > >>>>>>> >>>>> We're on the hunt yet again for an additional /22 to lease, and > are > >>>>>>> >>>>> wondering what the best options are out there? > >>>>>>> >>>>> > >>>>>>> >>>>> Our usual suspects that we've reached out to in the past seem to > be > >>>>> >>> plum > >>>>>>> >>>>> out... Any recommendations? > >>>>>>> >>>>> > >>>>>>> >>>>> Thanks! > >>>>>>> >>>>> > >>>>>>> >>>>> -- > >>>>>>> >>>>> Ryan Gard > >>>>>>> >>>>> > >>>>>> >>>> Have you considered IPv6? > >>>>>> >>>> > >>>>> >>> > >>>> >> > >>>> >> > >>> > > >>> > > >> > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 INTERNET: > >> marka at isc.org > >> > > > > > > > > -- > Ryan Gard > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mysidia at gmail.com Tue Jan 23 23:27:45 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 23 Jan 2018 17:27:45 -0600 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: On Tue, Jan 23, 2018 at 9:39 AM, John R. Levine wrote: > > the problem isn't keeping the database, it's figuring out who can make > authoritative statements about each block of IP addresses. That is an inherently hierarchical question since all IP blocks originally > trace back to allocations from IANA. > Well; It's a hierarchical question only because the current registration scheme is defined in a hierarchical manner. If BGP were being designed today, we could choose 256-Bit AS numbers, and allow each mined or staked block to yield a block of AS numbers prepended by some random previously-unused 128-bit GUID. However, a blockchain could also be used to allow an authority to make a statement representing a resource that can be made a non-withdrawable statement --- in other words, the authority's role or job in the registration process is to originate the registration, and after that is done: their authoritative statement is accepted ONCE per resource. The registration is permanent --- the authority has no ongoing role and no ability to later make a new conflicting statement about that same resource, and the authority has no operational role except to originate new registrations. This would mean that a foreign government could not coerce the authority to "cancel" or mangle a registration to meet a political or adversarial objective of disrupting the ability to co-ordinate networks, since the number registry is an authority of limited power: not an authority of complete power. We can have arguments about the best way to document the chain of > ownership, and conspiracy theories about how the evil RIRs are planning to > steal our precious bodily flu^W^WIPs, but "put it in a blockchain!" > Puhleeze. > R's, > John > -- -JH From kscotthelms at gmail.com Wed Jan 24 00:30:13 2018 From: kscotthelms at gmail.com (K. Scott Helms) Date: Tue, 23 Jan 2018 19:30:13 -0500 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: That sounds like giving up an awful lot of utility for a (at least in most places) something that's an exceedingly rare corner case. The other problem is that even if the record is immutable there's nothing that prevents governments from being coercive in other ways. At the end of the day there's no technology that prevents authoritarian governments from behaving badly. On Tue, Jan 23, 2018 at 6:27 PM, Jimmy Hess wrote: > On Tue, Jan 23, 2018 at 9:39 AM, John R. Levine wrote: > > > > > the problem isn't keeping the database, it's figuring out who can make > > authoritative statements about each block of IP addresses. > > That is an inherently hierarchical question since all IP blocks originally > > trace back to allocations from IANA. > > > > Well; It's a hierarchical question only because the current registration > scheme is defined in > a hierarchical manner. If BGP were being designed today, we could > choose 256-Bit AS numbers, > and allow each mined or staked block to yield a block of AS numbers > prepended by some > random previously-unused 128-bit GUID. > > However, a blockchain could also be used to allow an authority to make a > statement representing > a resource that can be made a non-withdrawable statement --- in other > words, the authority's role > or job in the registration process is to originate the registration, and > after that is done: > their authoritative statement is accepted ONCE per resource. > > The registration is permanent --- the authority has no ongoing role and no > ability to later make > a new conflicting statement about that same resource, and the > authority has no operational role > except to originate new registrations. > > This would mean that a foreign government could not coerce the authority > to "cancel" or mangle > a registration to meet a political or adversarial objective of disrupting > the ability to co-ordinate networks, > since the number registry is an authority of limited power: not an > authority of complete power. > > > We can have arguments about the best way to document the chain of > > ownership, and conspiracy theories about how the evil RIRs are planning > to > > steal our precious bodily flu^W^WIPs, but "put it in a blockchain!" > > Puhleeze. > > R's, > > John > > > > -- > -JH > From morrowc.lists at gmail.com Wed Jan 24 01:19:53 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 23 Jan 2018 20:19:53 -0500 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: On Tue, Jan 23, 2018 at 6:27 PM, Jimmy Hess wrote: > > since the number registry is an authority of limited power: not an > authority of complete power. > Oh, the RIR's went and got complete power? When did that happen? Can they now stop hijacked ip space and announcements like in the case of: "Subject: Spectrum prefix hijacks" AS | BGP IPv4 Prefix | AS Name 10512 | 102.196.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 103.119.0.0/16 | EFOREX-AS - E-FOREX, US (forex seemed to have removed their previous other hijacked ip announcements) From morrowc.lists at gmail.com Wed Jan 24 01:21:02 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 23 Jan 2018 20:21:02 -0500 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: On Tue, Jan 23, 2018 at 8:19 PM, Christopher Morrow wrote: > > > On Tue, Jan 23, 2018 at 6:27 PM, Jimmy Hess wrote: > >> >> since the number registry is an authority of limited power: not an >> authority of complete power. >> > > Oh, the RIR's went and got complete power? When did that happen? > Can they now stop hijacked ip space and announcements like in the case of: > > "Subject: Spectrum prefix hijacks" > > AS | BGP IPv4 Prefix | AS Name > 10512 | 102.196.0.0/16 | EFOREX-AS - E-FOREX, US > 10512 | 103.119.0.0/16 | EFOREX-AS - E-FOREX, US > > (forex seemed to have removed their previous other hijacked ip > announcements) > note that 'hilariously' neither of those 2 address blocks are registered to anyone, at all... From nanog at ics-il.net Wed Jan 24 07:53:18 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 24 Jan 2018 01:53:18 -0600 (CST) Subject: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet In-Reply-To: References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> Message-ID: <1225235684.912.1516780393799.JavaMail.mhammett@ThunderFuck> Knowing the relationship between my provider and whomever they are learning the route from is handy. It allows me to do things such as filter on those communities for passing prefixes down into less capable hardware. I may elect to pass customer or customer and peering routes from a given provider down into routers throughout my network with limited FIB capability. They can decide which way to send traffic that should be immediately apparent where the best path is, while leaving the provider edge routers to decide for prefixes beyond that. Say a CCR or a switch with some layer 3 capabilities. Then obviously things like blackhole and (local_pref, prepend, no export, etc. per AS). The above I'd say is rather important. The next step would be location-aware stuff in the presentation that would be nice to have. If your provider is having an issue with an upstream or peer in a given city\region, being able to avoid that would be nice. Of course that assumes you figure out their problem and the work-around before they're able to fix it themselves. Well, assuming it's a short-term issue, anyway. If it's a constant issue, your provider isn't likely to fix it faster than you because they're not fixing it at all. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "James Breeden" To: "NANOG list" Sent: Tuesday, January 23, 2018 1:17:45 PM Subject: Re: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet I've seen the onestep list but the presentation is helpful. I guess my question was moreso to the people side of communities vs the technicalities of communities - what ones do people find themselves using most often and what do they wish was available from providers that really isn't otherwise out there? James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co ________________________________ From: christopher.morrow at gmail.com on behalf of Christopher Morrow Sent: Tuesday, January 23, 2018 1:07:29 PM To: Mike Hammett Cc: James Breeden; NANOG list Subject: Re: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet On Tue, Jan 23, 2018 at 1:40 PM, Mike Hammett > wrote: These? :-) https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf you could also probably get some good examples cribbed from the collection: https://onestep.net/communities/ From jared at puck.nether.net Wed Jan 24 12:15:55 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 24 Jan 2018 07:15:55 -0500 Subject: Twitter Netops Contact Message-ID: <1D255497-E741-4342-9EAE-32D2B1E9D8D4@puck.nether.net> Is there someone from twitter who can contact me about the route leak that just occurred? Thanks, - Jared From shawnl at up.net Wed Jan 24 13:50:19 2018 From: shawnl at up.net (Shawn L) Date: Wed, 24 Jan 2018 08:50:19 -0500 (EST) Subject: DSL CPE In-Reply-To: <1311853825.2165.1515984533132.JavaMail.mhammett@ThunderFuck> References: <1427825328.1322.1515505834972.JavaMail.mhammett@ThunderFuck> <1515507727.403514769@upnet.mymailsrvr.com> <1311853825.2165.1515984533132.JavaMail.mhammett@ThunderFuck> Message-ID: <1516801819.626213796@upnet.mymailsrvr.com> Sorry -- this got lost in the shuffle. We were specifically comparing Comtrend AR5381u vs Zyxel 660HN being fed with either Calix ADSL 2+ or Paradyne/Zhone Bitstorm ADSL2+. All use the broadcom chipset but seem to interop slightly differently. From our limited testing we determined that for the best speeds / quality on long loops order was like this Zhone Bitstorm -> Zyxel 660HN Zhone Bitstorm -> Comtrend AR5381u Calix ADSL 2+ -> Zyxel 660HN Calix ADSL 2+ -> Comtrend AR5381u -----Original Message----- From: "Mike Hammett" Sent: Sunday, January 14, 2018 9:48pm To: "Shawn L" Cc: "NANOG" Subject: Re: DSL CPE Any particular Zyxel models or just Zyxel in general perform better at longer lengths? From: "Shawn L" To: "Mike Hammett" Cc: "NANOG" Sent: Tuesday, January 9, 2018 8:22:07 AM Subject: RE: DSL CPE At $dayjob we use both Comtrend and Zyxel modems. Both have a 1-port modem that can be deployed in bridged mode. They both seem to work well with Calix gear. We've found the Zyxel modems tend to work a little better at longer loop lengths. But, for us at least, it's very easy to get custom firmware created and pre-deployed to comtrend modems at the factory / distributor. So we haven't completely decided between one brand and the other. We started looking at Zyxel for increased speed at longer loop lengths and better wifi support. There's a company a few exchanges over from us that has deployed the caix giga family and really likes it. We haven't deployed them yet because they only work on the Calix E7 series (E7-2 and E7-20) and we still have a lot of C7 series dslams in the network. Shawn -----Original Message----- From: "Mike Hammett" Sent: Tuesday, January 9, 2018 8:50am To: "NANOG" Subject: DSL CPE After a few off-list responses (and a couple on) encouraging me to use NANOG, here we go... I've recently walked in to a voice\DSL CLEC that has basically been left to entropy for the last ten years. A lot of the core systems just work, but a lot of things aren't exactly managed the best. They run a Calix\Occam ADSL2+\VDSL infrastructure. For those of you doing DSL, what CPE are you using? I'm looking at one that's just a basic modem where I have a more sophisticated router (or ATA\voice gateway) behind it and then one more generic for residential settings with WiFi and all that jazz. We're kinda debating whether we go just dumb Wi-Fi or something more advanced\powerful. I've heard a lot of good about the Calix GigaFamily in that regard. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From ahebert at pubnix.net Wed Jan 24 14:21:15 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 24 Jan 2018 09:21:15 -0500 Subject: IRR AS-SET best practices - AS-SET Clash In-Reply-To: <38d173e4-1de1-1224-99ea-cbedb9f1b168@shout.net> References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> <20180123213518.rriw23xe3tfu2nwx@dan.olp.net> <38d173e4-1de1-1224-99ea-cbedb9f1b168@shout.net> Message-ID:     Hi,     We have a case when someone decided to create an AS-SET of the same name as ours.     It kinda messed up with our peering (hopefully he got it worst).     Management feedback was mostly "who do we sue?" and we know it isn't that simple.     So,         Any feedback on best practices and "other avenue" about IRR naming?     PS: I have to understand that we're not in the 90's anymore and younglings just don't give a damn :( ----- 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 From nick at foobar.org Wed Jan 24 14:23:48 2018 From: nick at foobar.org (Nick Hilliard) Date: Wed, 24 Jan 2018 14:23:48 +0000 Subject: IRR AS-SET best practices - AS-SET Clash In-Reply-To: References: <2069247883.4243.1516651532732.JavaMail.mhammett@ThunderFuck> <858eb3cf-8445-e9da-8fd1-e9eaf977f0a9@airwire.ie> <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> <20180123213518.rriw23xe3tfu2nwx@dan.olp.net> <38d173e4-1de1-1224-99ea-cbedb9f1b168@shout.net> Message-ID: <5A6896F4.6040308@foobar.org> Alain Hebert wrote: > Any feedback on best practices and "other avenue" about IRR naming? Known problem - you're asking for trouble unless you filter IRRDB queries by source: There isn't a global namespace for as-set names, unless you use source: as a database key element. Nick From job at ntt.net Wed Jan 24 14:48:58 2018 From: job at ntt.net (Job Snijders) Date: Wed, 24 Jan 2018 14:48:58 +0000 Subject: IRR AS-SET best practices - AS-SET Clash In-Reply-To: <5A6896F4.6040308@foobar.org> References: <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> <20180123213518.rriw23xe3tfu2nwx@dan.olp.net> <38d173e4-1de1-1224-99ea-cbedb9f1b168@shout.net> <5A6896F4.6040308@foobar.org> Message-ID: <20180124144858.GC35164@vurt.meerval.net> On Wed, Jan 24, 2018 at 02:23:48PM +0000, Nick Hilliard wrote: > Alain Hebert wrote: > > Any feedback on best practices and "other avenue" about IRR naming? > > Known problem - you're asking for trouble unless you filter IRRDB > queries by source: > > There isn't a global namespace for as-set names, unless you use > source: as a database key element. In addition to the above, one could use "hierarchical" AS-SET names, in some databases (from the top of my head: APNIC, AfriNIC, RIPE) only the owner of the ASN can create AS-SETs under that ASN's namespace. But more importantly: using the ASN in the AS-SET name chances of collision are reduced. Example: I defined "AS15562:AS-SNIJDERS" in the RIPE database, instead of "AS-SNIJDERS". Same for "AS2914:AS-GLOBAL" in NTTCOM. --- thread hijack --- Coincidentally, I'm working to define something like "AS-SETs in RPKI". There are a number of downsides to "AS-SETs in IRR": collisions between databases can exist, it is hard to figure out what AS-SET to use for what ASN (we rely on service order forms, peeringdb or guessing for that), and the way the recursion was done can too easily result in gigantic sets. I'd be interested to know what others think about improving feature parity between IRR and RPKI, and while doing that make the bad aspects of AS-SETs go away and keep the good parts. Thoughts? Kind regards, Job ps. raised the question here too https://mail.lacnic.net/pipermail/lacnog/2018-January/005845.html From valdis.kletnieks at vt.edu Wed Jan 24 20:28:47 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 24 Jan 2018 15:28:47 -0500 Subject: Blockchain and Networking In-Reply-To: References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> Message-ID: <50155.1516825727@turing-police.cc.vt.edu> On Tue, 23 Jan 2018 17:27:45 -0600, Jimmy Hess said: > However, a blockchain could also be used to allow an authority to make a statement representing > a resource that can be made a non-withdrawable statement --- in other words, the authority's role > or job in the registration process is to originate the registration, and after that is done: > their authoritative statement is accepted ONCE per resource. > The registration is permanent --- the authority has no ongoing role and no ability to later make > a new conflicting statement about that same resource, and the authority has no operational role > except to originate new registration. How do you express the conflicting statement "We are hereby revoking the registration of CyberFoo.com due to (insert valid reason here)"? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From anthony at handynetworks.com Wed Jan 24 20:39:57 2018 From: anthony at handynetworks.com (Anthony Kolka - Handy Networks LLC) Date: Wed, 24 Jan 2018 20:39:57 +0000 Subject: Blockchain and Networking In-Reply-To: <50155.1516825727@turing-police.cc.vt.edu> References: <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca> <20180109031925.2CC1818EC6E9@ary.local> <50155.1516825727@turing-police.cc.vt.edu> Message-ID: <0F9D6932-73A6-43C3-A73A-ADA6D7C63292@handynetworks.com> When your trying to find a use for your new hammer; everything tends to look like nails. Anthony Kolka Systems Engineer 303-414-6904 anthony at handynetworks.com https://www.handynetworks.com On Jan 24, 2018, at 1:28 PM, Valdis.Kletnieks at vt.edu wrote: On Tue, 23 Jan 2018 17:27:45 -0600, Jimmy Hess said: However, a blockchain could also be used to allow an authority to make a statement representing a resource that can be made a non-withdrawable statement --- in other words, the authority's role or job in the registration process is to originate the registration, and after that is done: their authoritative statement is accepted ONCE per resource. The registration is permanent --- the authority has no ongoing role and no ability to later make a new conflicting statement about that same resource, and the authority has no operational role except to originate new registration. How do you express the conflicting statement "We are hereby revoking the registration of CyberFoo.com due to (insert valid reason here)"? From andy at newslink.com Thu Jan 25 19:05:49 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Thu, 25 Jan 2018 13:05:49 -0600 Subject: TimeWarner (Spectrum) Voice contact Message-ID: Anyone have a contact at TimeWarner (aka Spectrum) Voice services that you could pass along to me? MUCH appreciated! ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From nanog-announce at nanog.org Thu Jan 25 21:26:27 2018 From: nanog-announce at nanog.org (Ryan Woolley via NANOG-announce) Date: Thu, 25 Jan 2018 15:26:27 -0600 (CST) Subject: [NANOG-announce] NANOG 72 agenda update and Hackathon Message-ID: This message has been wrapped due to the DMARC policy setting to prevent NANOG subscribers from being unsubscribed due to bounces. -------------- next part -------------- An embedded message was scrubbed... From: Ryan Woolley Subject: NANOG 72 agenda update and Hackathon Date: Thu, 25 Jan 2018 16:26:24 -0500 Size: 5541 URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From sean at donelan.com Fri Jan 26 03:10:23 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 25 Jan 2018 22:10:23 -0500 (EST) Subject: Reminer: FCC seeks comments on 2017 hurricane season respons Message-ID: Just a reminder, the Federal Communications Committee is still collecting comments on the 2017 hurricane season. https://apps.fcc.gov/edocs_public/attachmatch/DA-17-1180A1.pdf PUBLIC SAFETY AND HOMELAND SECURITY BUREAU SEEKS COMMENT ON RESPONSE EFFORTS UNDERTAKEN DURING 2017 HURRICANE SEASON PS Docket No. 17-344 Comments Due: January 22, 2018 Reply Comments Due: February 21, 2018 The Public Safety and Homeland Security Bureau (PSHSB or Bureau) of the Federal Communications Commission (FCC or Commission) seeks comment on the resiliency of the communications infrastructure, the effectiveness of emergency communications, and government and industry responses to the 2017 hurricane season. [...] From baldur.norddahl at gmail.com Fri Jan 26 03:50:49 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 26 Jan 2018 04:50:49 +0100 Subject: evil ipv6 bit? Message-ID: <2cba0e4d-949f-e44d-bea3-fa278632b421@gmail.com> Hello After some apparently unrelated changes, one of my routers stopped routing traffic to a few IPv6 destinations. After a lot of experimentation, including rebooting (did not help), I found this: archive.ubuntu.com: 2001:67c:1360:8001::17 "ping6 vrf internet 2001:67c:1360:8001::17" from the router shell works. ping6/traceroute from a customer connection has the packet dropped by the router. Traceroute gets nothing back at all. 2001:67c:1360:7fff:: is ok. Does not reply to ping because I just made up that address. But I get a valid traceroute all the way to the destination. Anything between 2001:67c:1360:8000:: and 2001:67c:1360:ffff:ffff:ffff:ffff:ffff is dropped. My route table looks like this: albertslund-edge1#show ipv6 forwarding route vrf internet 2001:67c:1360:8001::17 IPv6 Routing Table: Headers: Dest: Destination, Gw: Gateway, Pri: Priority; Codes : K: kernel, I1: isis-l1, SFN: sf-nat64, R: ripng, AF: aftr, B: bgp, D: direct, I2: isis-l2, SLN: sl-nat64, O: ospfv3, D6: dhcp, P: ppp, S: static, N: nd, V: vrrp, A: address, M: multicast, UI: user-ipaddr, GW-FWD: PS-BUSI,GW-UE: PS-USER,LDP-A: LDP-AREA, UN: user-network, US: user-special; Dest Owner Metric Interface Pri Gw 2001:67c:1360::/48 B 0 xgei-0/0/0/6 200 ::ffff:185.24.168.254 ::/0 B 0 xgei-0/0/0/6 200 ::ffff:185.24.168.254 Notice how this is a /48 route and one bit at the /49 level changes how it is routed. That is not right. I tried adding a /128 static route but that does not do anything. The packet is still dropped. I just now discovered this: google.com: 2a00:1450:400e:807::200e That address works fine. But then I changed that one bit in the address: 2a00:1450:400e:8807::200e and voila, the router drops the packet. Now I am stumbled. What could the 49th bit in the destination IPv6 address field in a packet mean to the router, that would make it drop the packet? Some extra information about the network: We are using MPLS with l3vpn (vrf) and l2vpn (vpls). The traffic is qinq tagged before being transported in a l2vpn towards the router in question. The l2vpn does not transport the outer vlan tag. The l2vpn is then terminated on a loopback cable. On the other end of that loopback cable we receive the traffic as ordinary qinq tagged without MPLS tagging. It is on this interface the router apparently drops the packet. It might conceivably also drop the packet on the way out of the l2vpn. I have a similar setup, but instead of a loopback cable, the l2vpn is terminated on another MPLS switch, which then connects to a router of the same model. This setup does not have the problem. The change I introduced was changing from an internal interface called "bvi" to the loopback cable. The bvi interface is a simulated loopback cable construct. We are dropping the bvi interface because it is very buggy. We did not have this problem with the bvi interface however. The hardware is ZTE M6000-S V3.00.20(3.40.1). Thanks, Baldur From jmaimon at jmaimon.com Fri Jan 26 04:10:02 2018 From: jmaimon at jmaimon.com (Joe Maimon) Date: Thu, 25 Jan 2018 23:10:02 -0500 Subject: improving signal to noise ratio from centralized network syslogs Message-ID: <5A6AAA1A.2040906@jmaimon.com> Hey All, Centralized logging is a good thing. However, what happens is that every repetitive, annoying but not (usually) important thing fills up the log with reams of what you are not looking for. Networks are a noisy place and silencing every logged condition is impractical and sometimes undesirable. What I am interested in is an automated zoom-in zoom-out tool to mask the repetition of "normal" events and allow the unusual to stand out. Add to that an ability to identify gaps in the background noise. (The dog that didnt bark) What I am not interested in are solutions based upon preconfigured filters and definitions and built in analysis for supported (prepopulated definitions) platforms, this is all about pattern mining/masking and should be self discoverable. Ideally a command tool to generate static versions of the analysis coupled with a web platform (with zoom +- buttons) for realtime. I made a crude run of it with SLCT, using its generated patterns to grep -v, and that in and of itself was useful, but needs a bit of work. Also, its not quite real time. Any ideas would be greatly appreciated. Joe From mloftis at wgops.com Fri Jan 26 06:01:11 2018 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 26 Jan 2018 06:01:11 +0000 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: <5A6AAA1A.2040906@jmaimon.com> References: <5A6AAA1A.2040906@jmaimon.com> Message-ID: On Thu, Jan 25, 2018 at 8:11 PM Joe Maimon wrote: > Hey All, > > Centralized logging is a good thing. However, what happens is that every > repetitive, annoying but not (usually) important thing fills up the log > with reams of what you are not looking for. > > Networks are a noisy place and silencing every logged condition is > impractical and sometimes undesirable. > > What I am interested in is an automated zoom-in zoom-out tool to mask > the repetition of "normal" events and allow the unusual to stand out. > > Add to that an ability to identify gaps in the background noise. (The > dog that didnt bark) > > What I am not interested in are solutions based upon preconfigured > filters and definitions and built in analysis for supported > (prepopulated definitions) platforms, this is all about pattern > mining/masking and should be self discoverable. Ideally a command tool > to generate static versions of the analysis coupled with a web platform > (with zoom +- buttons) for realtime. > > I made a crude run of it with SLCT, using its generated patterns to grep > -v, and that in and of itself was useful, but needs a bit of work. Also, > its not quite real time. > > Any ideas would be greatly appreciated. Not cheap, but Splunk comes to mind. > > > Joe > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From mianosm at gmail.com Fri Jan 26 11:30:46 2018 From: mianosm at gmail.com (Steven Miano) Date: Fri, 26 Jan 2018 06:30:46 -0500 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: References: <5A6AAA1A.2040906@jmaimon.com> Message-ID: Splunk is the obvious solution that most organizations with a mature security group will likely already have in their portfolio. Going a step further, and with an abundance of skill, ability, and forethought: either ELK (or any derivative there of such as: Elasticache, Fluentd, Kibana), or rsyslog|syslog-ng + database + loganalzyer. Grep-fu will pay dividends in any of the three options (do nothing, go proprietary, go open). ~Steven On Fri, Jan 26, 2018 at 1:01 AM, Michael Loftis wrote: > On Thu, Jan 25, 2018 at 8:11 PM Joe Maimon wrote: > > > Hey All, > > > > Centralized logging is a good thing. However, what happens is that every > > repetitive, annoying but not (usually) important thing fills up the log > > with reams of what you are not looking for. > > > > Networks are a noisy place and silencing every logged condition is > > impractical and sometimes undesirable. > > > > What I am interested in is an automated zoom-in zoom-out tool to mask > > the repetition of "normal" events and allow the unusual to stand out. > > > > Add to that an ability to identify gaps in the background noise. (The > > dog that didnt bark) > > > > What I am not interested in are solutions based upon preconfigured > > filters and definitions and built in analysis for supported > > (prepopulated definitions) platforms, this is all about pattern > > mining/masking and should be self discoverable. Ideally a command tool > > to generate static versions of the analysis coupled with a web platform > > (with zoom +- buttons) for realtime. > > > > I made a crude run of it with SLCT, using its generated patterns to grep > > -v, and that in and of itself was useful, but needs a bit of work. Also, > > its not quite real time. > > > > Any ideas would be greatly appreciated. > > > Not cheap, but Splunk comes to mind. > > > > > > > Joe > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler > -- Steven M. Miano http://stevenmiano.com From EPers at ansencorp.com Fri Jan 26 12:31:00 2018 From: EPers at ansencorp.com (Edwin Pers) Date: Fri, 26 Jan 2018 12:31:00 +0000 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: References: <5A6AAA1A.2040906@jmaimon.com> Message-ID: <20c1fe9d2a8a4adfb4a6a8ff374aa21f@ansencorp.com> On Fri, Jan 26, 2018 at 6:30 AM, Steven Miano wrote: >either ELK (or any derivative there of such as: Elasticache, Fluentd, Kibana) I'm partial to graylog - it does some of the heavy lifting of getting a logging-centric ELK stack up and running -Ed From saku at ytti.fi Fri Jan 26 15:55:58 2018 From: saku at ytti.fi (Saku Ytti) Date: Fri, 26 Jan 2018 15:55:58 +0000 Subject: evil ipv6 bit? In-Reply-To: <2cba0e4d-949f-e44d-bea3-fa278632b421@gmail.com> References: <2cba0e4d-949f-e44d-bea3-fa278632b421@gmail.com> Message-ID: On 26 January 2018 at 03:50, Baldur Norddahl wrote: > I just now discovered this: > > google.com: 2a00:1450:400e:807::200e > > That address works fine. But then I changed that one bit in the address: > 2a00:1450:400e:8807::200e and voila, the router drops the packet. > > Now I am stumbled. What could the 49th bit in the destination IPv6 address > field in a packet mean to the router, that would make it drop the packet? Are you sure it is dropped? Can you see some drop counter increase? Have you observed nothing coming out from any port? My guess is bad memory, and that bit is statically set or statically unset and cannot be changed. Might cause CRC error, IP checksum error or just mangled packet coming out of the router -- ++ytti From ahebert at pubnix.net Fri Jan 26 16:41:51 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 26 Jan 2018 11:41:51 -0500 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: References: <5A6AAA1A.2040906@jmaimon.com> Message-ID: <7084d3d4-4289-903e-d78f-f91656ed4c72@pubnix.net>     ELK stack.     Java RAM devoring monster but Kibana makes indexing easy. ----- 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 01/26/18 01:01, Michael Loftis wrote: > On Thu, Jan 25, 2018 at 8:11 PM Joe Maimon wrote: > >> Hey All, >> >> Centralized logging is a good thing. However, what happens is that every >> repetitive, annoying but not (usually) important thing fills up the log >> with reams of what you are not looking for. >> >> Networks are a noisy place and silencing every logged condition is >> impractical and sometimes undesirable. >> >> What I am interested in is an automated zoom-in zoom-out tool to mask >> the repetition of "normal" events and allow the unusual to stand out. >> >> Add to that an ability to identify gaps in the background noise. (The >> dog that didnt bark) >> >> What I am not interested in are solutions based upon preconfigured >> filters and definitions and built in analysis for supported >> (prepopulated definitions) platforms, this is all about pattern >> mining/masking and should be self discoverable. Ideally a command tool >> to generate static versions of the analysis coupled with a web platform >> (with zoom +- buttons) for realtime. >> >> I made a crude run of it with SLCT, using its generated patterns to grep >> -v, and that in and of itself was useful, but needs a bit of work. Also, >> its not quite real time. >> >> Any ideas would be greatly appreciated. > > Not cheap, but Splunk comes to mind. > >> >> Joe >> From crussell at kanren.net Fri Jan 26 17:17:31 2018 From: crussell at kanren.net (Casey Russell) Date: Fri, 26 Jan 2018 11:17:31 -0600 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: <7084d3d4-4289-903e-d78f-f91656ed4c72@pubnix.net> References: <5A6AAA1A.2040906@jmaimon.com> <7084d3d4-4289-903e-d78f-f91656ed4c72@pubnix.net> Message-ID: +1 for Graylog, you can pour ALL your syslog data into it, and then configure what are called streams. Streams are a way to whittle down the incoming log flows and see something LESS than everything. You can create a stream that only shows these 6 devices, or one that only shows log info from the RPD daemon on your Juniper routers. In your case, you could use the stream rules to create a stream that filters out the background noise with regex expressions. You're not losing anything, you still have the full log data captured, and you can see it in the portal, but if you click on one of your streams, you see filtered data based, on your rulesets. We've been using it for about 2 years now I think. It's open source, easy to set up, supports LDAP, multiple input types (beyond just udp syslog), and the community is pretty solid. 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 Fri, Jan 26, 2018 at 10:41 AM, Alain Hebert wrote: > ELK stack. > > Java RAM devoring monster but Kibana makes indexing easy. > > ----- > 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 01/26/18 01:01, Michael Loftis wrote: > >> On Thu, Jan 25, 2018 at 8:11 PM Joe Maimon wrote: >> >> Hey All, >>> >>> Centralized logging is a good thing. However, what happens is that every >>> repetitive, annoying but not (usually) important thing fills up the log >>> with reams of what you are not looking for. >>> >>> Networks are a noisy place and silencing every logged condition is >>> impractical and sometimes undesirable. >>> >>> What I am interested in is an automated zoom-in zoom-out tool to mask >>> the repetition of "normal" events and allow the unusual to stand out. >>> >>> Add to that an ability to identify gaps in the background noise. (The >>> dog that didnt bark) >>> >>> What I am not interested in are solutions based upon preconfigured >>> filters and definitions and built in analysis for supported >>> (prepopulated definitions) platforms, this is all about pattern >>> mining/masking and should be self discoverable. Ideally a command tool >>> to generate static versions of the analysis coupled with a web platform >>> (with zoom +- buttons) for realtime. >>> >>> I made a crude run of it with SLCT, using its generated patterns to grep >>> -v, and that in and of itself was useful, but needs a bit of work. Also, >>> its not quite real time. >>> >>> Any ideas would be greatly appreciated. >>> >> >> Not cheap, but Splunk comes to mind. >> >> >>> Joe >>> >>> > From hugo at slabnet.com Fri Jan 26 17:35:45 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 26 Jan 2018 09:35:45 -0800 Subject: evil ipv6 bit? In-Reply-To: References: <2cba0e4d-949f-e44d-bea3-fa278632b421@gmail.com> Message-ID: <20180126173545.GH25899@bamboo.slabnet.com> On Fri 2018-Jan-26 15:55:58 +0000, Saku Ytti wrote: >On 26 January 2018 at 03:50, Baldur Norddahl wrote: > > >> I just now discovered this: >> >> google.com: 2a00:1450:400e:807::200e >> >> That address works fine. But then I changed that one bit in the address: >> 2a00:1450:400e:8807::200e and voila, the router drops the packet. >> >> Now I am stumbled. What could the 49th bit in the destination IPv6 address >> field in a packet mean to the router, that would make it drop the packet? > >Are you sure it is dropped? Can you see some drop counter increase? >Have you observed nothing coming out from any port? > >My guess is bad memory, and that bit is statically set or statically >unset and cannot be changed. Might cause CRC error, IP checksum error >or just mangled packet coming out of the router > >-- > ++ytti There was also this example from a while ago: *Juniper MX80 strange dst MAC address behavior* https://mailman.nanog.org/pipermail/nanog/2017-November/092954.html And then this: *Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)* https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html Those are both related to _MACs_, though, rather than IPs. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From cscora at apnic.net Fri Jan 26 18:03:07 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Jan 2018 04:03:07 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180126180307.47DCEC450F@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, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 27 Jan, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 681768 Prefixes after maximum aggregation (per Origin AS): 264615 Deaggregation factor: 2.58 Unique aggregates announced (without unneeded subnets): 329600 Total ASes present in the Internet Routing Table: 59686 Prefixes per ASN: 11.42 Origin-only ASes present in the Internet Routing Table: 51539 Origin ASes announcing only one prefix: 22682 Transit ASes present in the Internet Routing Table: 8147 Transit-only ASes present in the Internet Routing Table: 244 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 56 Number of instances of unregistered ASNs: 57 Number of 32-bit ASNs allocated by the RIRs: 21301 Number of 32-bit ASNs visible in the Routing Table: 17091 Prefixes from 32-bit ASNs in the Routing Table: 70682 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 382 Number of addresses announced to Internet: 2864141986 Equivalent to 170 /8s, 183 /16s and 86 /24s Percentage of available address space announced: 77.4 Percentage of allocated address space announced: 77.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.8 Total number of prefixes smaller than registry allocations: 225073 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 188350 Total APNIC prefixes after maximum aggregation: 53700 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 187417 Unique aggregates announced from the APNIC address blocks: 77419 APNIC Region origin ASes present in the Internet Routing Table: 8612 APNIC Prefixes per ASN: 21.76 APNIC Region origin ASes announcing only one prefix: 2445 APNIC Region transit ASes present in the Internet Routing Table: 1266 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3505 Number of APNIC addresses announced to Internet: 772118050 Equivalent to 46 /8s, 5 /16s and 150 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 203112 Total ARIN prefixes after maximum aggregation: 97653 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 204292 Unique aggregates announced from the ARIN address blocks: 96430 ARIN Region origin ASes present in the Internet Routing Table: 18065 ARIN Prefixes per ASN: 11.31 ARIN Region origin ASes announcing only one prefix: 6688 ARIN Region transit ASes present in the Internet Routing Table: 1793 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2297 Number of ARIN addresses announced to Internet: 1110265632 Equivalent to 66 /8s, 45 /16s and 79 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 184061 Total RIPE prefixes after maximum aggregation: 89767 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 180043 Unique aggregates announced from the RIPE address blocks: 108365 RIPE Region origin ASes present in the Internet Routing Table: 24847 RIPE Prefixes per ASN: 7.25 RIPE Region origin ASes announcing only one prefix: 11347 RIPE Region transit ASes present in the Internet Routing Table: 3493 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6597 Number of RIPE addresses announced to Internet: 713684608 Equivalent to 42 /8s, 137 /16s and 246 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 88156 Total LACNIC prefixes after maximum aggregation: 19458 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 89462 Unique aggregates announced from the LACNIC address blocks: 39903 LACNIC Region origin ASes present in the Internet Routing Table: 6782 LACNIC Prefixes per ASN: 13.19 LACNIC Region origin ASes announcing only one prefix: 1841 LACNIC Region transit ASes present in the Internet Routing Table: 1255 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4306 Number of LACNIC addresses announced to Internet: 172245984 Equivalent to 10 /8s, 68 /16s and 67 /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: 18031 Total AfriNIC prefixes after maximum aggregation: 3994 AfriNIC Deaggregation factor: 4.51 Prefixes being announced from the AfriNIC address blocks: 20172 Unique aggregates announced from the AfriNIC address blocks: 7212 AfriNIC Region origin ASes present in the Internet Routing Table: 1111 AfriNIC Prefixes per ASN: 18.16 AfriNIC Region origin ASes announcing only one prefix: 360 AfriNIC Region transit ASes present in the Internet Routing Table: 224 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 386 Number of AfriNIC addresses announced to Internet: 95422720 Equivalent to 5 /8s, 176 /16s and 9 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5439 4195 92 ERX-CERNET-BKB China Education and Rese 7545 3802 407 412 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2881 11132 770 KIXS-AS-KR Korea Telecom, KR 9829 2770 1499 540 BSNL-NIB National Internet Backbone, IN 17974 2766 934 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9394 2655 4923 27 CTTNET China TieTong Telecommunications 7552 2582 1157 63 VIETEL-AS-AP Viettel Group, VN 45899 2549 1550 154 VNPT-AS-VN VNPT Corp, VN 9808 2118 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2083 417 209 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 3369 1323 86 SHAW - Shaw Communications Inc., CA 22773 3264 2951 143 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2080 2363 436 CHARTER-NET-HKY-NC - Charter Communicat 16509 2009 4163 574 AMAZON-02 - Amazon.com, Inc., US 6389 1957 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1933 5059 619 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1888 333 227 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1724 230 566 CABLEONE - CABLE ONE, INC., US 7018 1677 20167 1247 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3520 187 21 ALJAWWALSTC-AS, SA 20940 2839 833 2056 AKAMAI-ASN1, US 8551 2235 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12479 2129 1108 216 UNI2-AS, ES 12389 2114 1859 698 ROSTELECOM-AS, RU 34984 2002 332 477 TELLCOM-AS, TR 9121 1939 1691 17 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 8402 1271 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1228 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 3857 3350 577 Uninet S.A. de C.V., MX 10620 3579 540 252 Telmex Colombia S.A., CO 11830 2635 370 66 Instituto Costarricense de Electricidad 6503 1629 437 53 Axtel, S.A.B. de C.V., MX 7303 1502 1024 193 Telecom Argentina S.A., AR 6147 1075 377 27 Telefonica del Peru S.A.A., PE 3816 1014 509 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1014 2241 189 CLARO S.A., BR 11172 919 126 85 Alestra, S. de R.L. de C.V., MX 18881 904 1065 27 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1192 398 50 LINKdotNET-AS, EG 37611 786 91 8 Afrihost, ZA 36903 714 358 186 MT-MPLS, MA 36992 667 1379 36 ETISALAT-MISR, EG 8452 531 1730 18 TE-AS TE-AS, EG 24835 478 786 17 RAYA-AS, EG 29571 458 36 13 ORANGE-COTE-IVOIRE, CI 37492 449 367 77 ORANGE-, TN 15399 352 35 7 WANANCHI-, KE 23889 313 103 14 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5439 4195 92 ERX-CERNET-BKB China Education and Rese 8151 3857 3350 577 Uninet S.A. de C.V., MX 7545 3802 407 412 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3579 540 252 Telmex Colombia S.A., CO 39891 3520 187 21 ALJAWWALSTC-AS, SA 6327 3369 1323 86 SHAW - Shaw Communications Inc., CA 22773 3264 2951 143 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2881 11132 770 KIXS-AS-KR Korea Telecom, KR 20940 2839 833 2056 AKAMAI-ASN1, US 9829 2770 1499 540 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 39891 3520 3499 ALJAWWALSTC-AS, SA 7545 3802 3390 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3579 3327 Telmex Colombia S.A., CO 6327 3369 3283 SHAW - Shaw Communications Inc., CA 8151 3857 3280 Uninet S.A. de C.V., MX 22773 3264 3121 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2766 2689 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9394 2655 2628 CTTNET China TieTong Telecommunications Corpora 11830 2635 2569 Instituto Costarricense de Electricidad y Telec 7552 2582 2519 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65249 PRIVATE 5.42.234.0/23 35753 ITC ITC AS number, SA 65249 PRIVATE 5.42.234.0/24 35753 ITC ITC AS number, SA 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.69.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.70.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 23.159.192.0/24 54726 AET - AET Hosting Solutions, Inc., US 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:12 /10:37 /11:99 /12:279 /13:563 /14:1092 /15:1894 /16:13432 /17:7761 /18:13621 /19:25241 /20:38818 /21:44734 /22:83691 /23:67832 /24:380401 /25:842 /26:605 /27:661 /28:36 /29:20 /30:18 /31:4 /32:60 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3161 3369 SHAW - Shaw Communications Inc., CA 39891 2946 3520 ALJAWWALSTC-AS, SA 22773 2527 3264 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1981 2635 Instituto Costarricense de Electricidad y Telec 8551 1699 2235 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1648 1888 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1580 3579 Telmex Colombia S.A., CO 11492 1507 1724 CABLEONE - CABLE ONE, INC., US 9121 1419 1939 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1574 2:837 4:18 5:2644 6:40 8:1090 9:1 12:1853 13:194 14:1756 15:27 16:3 17:184 18:65 20:53 21:3 23:2546 24:1737 25:2 27:2372 31:1948 32:88 35:23 36:479 37:2625 38:1443 39:188 40:101 41:3057 42:539 43:1951 44:94 45:3641 46:2990 47:194 49:1387 50:1041 51:47 52:939 54:353 55:4 56:7 57:42 58:1598 59:1014 60:389 61:2087 62:1823 63:1825 64:4695 65:2229 66:4470 67:2340 68:1177 69:3175 70:1135 71:560 72:2089 74:2625 75:398 76:420 77:1556 78:1629 79:1685 80:1494 81:1405 82:1062 83:780 84:1013 85:1973 86:553 87:1228 88:912 89:2344 90:180 91:6262 92:1161 93:2358 94:2389 95:2712 96:647 97:358 98:925 99:110 100:79 101:1528 102:15 103:16945 104:3267 105:209 106:525 107:1810 108:705 109:2952 110:1593 111:1747 112:1292 113:1388 114:1110 115:1581 116:1629 117:1695 118:2209 119:1679 120:949 121:1049 122:2479 123:1762 124:1466 125:1848 128:1016 129:599 130:440 131:1650 132:603 133:196 134:1002 135:228 136:441 137:476 138:1960 139:563 140:401 141:681 142:777 143:1006 144:801 145:197 146:1150 147:754 148:1474 149:698 150:728 151:981 152:758 153:309 154:984 155:747 156:753 157:762 158:607 159:1632 160:853 161:739 162:2558 163:519 164:976 165:1502 166:398 167:1381 168:3107 169:796 170:3656 171:406 172:1031 173:1903 174:860 175:765 176:1880 177:3932 178:2433 179:1183 180:2237 181:2148 182:2437 183:1092 184:906 185:12221 186:3488 187:2327 188:2631 189:1958 190:8097 191:1353 192:9789 193:5878 194:4761 195:3996 196:2346 197:1377 198:5523 199:5911 200:7271 201:4869 202:10411 203:9969 204:4539 205:2867 206:3016 207:3119 208:4013 209:3912 210:4009 211:2150 212:2969 213:2597 214:899 215:62 216:5861 217:2121 218:900 219:625 220:1728 221:996 222:1056 223:1238 End of report From theodore at ciscodude.net Fri Jan 26 23:10:06 2018 From: theodore at ciscodude.net (Theodore Baschak) Date: Fri, 26 Jan 2018 17:10:06 -0600 Subject: evil ipv6 bit? In-Reply-To: <2cba0e4d-949f-e44d-bea3-fa278632b421@gmail.com> References: <2cba0e4d-949f-e44d-bea3-fa278632b421@gmail.com> Message-ID: <887EA8F3-AEAC-4D85-815D-4E7257340953@ciscodude.net> > On Jan 25, 2018, at 9:50 PM, Baldur Norddahl wrote: > > archive.ubuntu.com: 2001:67c:1360:8001::17 Not sure if this is related or not, but in this[1] thread over on pdns-users, there was talk about subdomains under clouds.archive.ubuntu.com only having a single NS, which may have been having connectivity issues as recently as yesterday. 1: https://mailman.powerdns.com/pipermail/pdns-users/2018-January/025197.html Theodore Baschak - AS395089 - Hextet Systems https://bgp.guru/ - https://hextet.net/ http://mbix.ca/ - http://mbnog.ca/ From jared at puck.Nether.net Sat Jan 27 21:20:55 2018 From: jared at puck.Nether.net (Jared Mauch) Date: Sat, 27 Jan 2018 16:20:55 -0500 Subject: IRR AS-SET best practices - AS-SET Clash In-Reply-To: <5A6896F4.6040308@foobar.org> References: <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> <20180123213518.rriw23xe3tfu2nwx@dan.olp.net> <38d173e4-1de1-1224-99ea-cbedb9f1b168@shout.net> <5A6896F4.6040308@foobar.org> Message-ID: <20180127212054.GA19410@puck.nether.net> On Wed, Jan 24, 2018 at 02:23:48PM +0000, Nick Hilliard wrote: > Alain Hebert wrote: > > Any feedback on best practices and "other avenue" about IRR naming? > > Known problem - you're asking for trouble unless you filter IRRDB > queries by source: > > There isn't a global namespace for as-set names, unless you use source: > as a database key element. I've found best practice to be use AS23456 to identify the owner. (assuming you are 23456). Using something else like AS-CLOUD is likely to cause conflicts as there are many clouds out there. Much of the problem here is the limited namespace/concept space and people get stuck saying IRR sucks when IRR/whois is often a method to access a database. We have advanced quite far in the past 20 years in how to build databases, realtime query methods, etc.. but it's not made it to the routing ecosystem. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From jared at puck.Nether.net Sat Jan 27 21:30:56 2018 From: jared at puck.Nether.net (Jared Mauch) Date: Sat, 27 Jan 2018 16:30:56 -0500 Subject: IRR AS-SET best practices - AS-SET Clash In-Reply-To: <20180124144858.GC35164@vurt.meerval.net> References: <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> <20180123213518.rriw23xe3tfu2nwx@dan.olp.net> <38d173e4-1de1-1224-99ea-cbedb9f1b168@shout.net> <5A6896F4.6040308@foobar.org> <20180124144858.GC35164@vurt.meerval.net> Message-ID: <20180127213056.GB19410@puck.nether.net> On Wed, Jan 24, 2018 at 02:48:58PM +0000, Job Snijders wrote: > --- thread hijack --- > > Coincidentally, I'm working to define something like "AS-SETs in RPKI". > There are a number of downsides to "AS-SETs in IRR": collisions between > databases can exist, it is hard to figure out what AS-SET to use for > what ASN (we rely on service order forms, peeringdb or guessing for > that), and the way the recursion was done can too easily result in > gigantic sets. Obviously you have to prune once you hit a loop, but this is how you can traverse a edge-node graph to find the leaves given a starting point. > I'd be interested to know what others think about improving feature > parity between IRR and RPKI, and while doing that make the bad aspects > of AS-SETs go away and keep the good parts. Thoughts? I've found that saying RR, IRR and RPKI overloads one technology with another. One needs a standards based method to access a database about routing information. We can federate databases together or come up with methods to do this. RPKI is another database you can validate against but it also has limits. If I were a backbone, I would be asking myself: How can customers effectively communicate with me their intent? RPKI and IRR have weknesses and the networks with automation and tooling here are light years ahead of those that have nothing. We as an industry must get better so the impact is less when bad things happen. It's clear to me a decade later even asking people to filter out so called tier-1 networks with as-paths is still a major problem. 6453 & 5511 are still accepting their peering partner ASNs from customers (for example) and it shows. 701 still accepts peer ASNs from peers. (example AS_PATHs in postscript).. There's no universal way to communicate these relationships yet we have web based platforms where I can tell you what many list members ate for dinner last night. There is a lack of will to take action here and a lack of common toolchains that can be integrated to perform the tasks. - Jared > ps. raised the question here too https://mail.lacnic.net/pipermail/lacnog/2018-January/005845.html A few interesting AS_Paths: 2497 701 5511 59378 7473 2914 132602 38203 137038 3356 6453 21502 1299 6848 44216 701 6453 21502 1299 6848 44216 -- 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 job at ntt.net Sun Jan 28 02:36:05 2018 From: job at ntt.net (Job Snijders) Date: Sun, 28 Jan 2018 02:36:05 +0000 Subject: IRR AS-SET best practices - AS-SET Clash In-Reply-To: <20180127213056.GB19410@puck.nether.net> References: <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> <20180123213518.rriw23xe3tfu2nwx@dan.olp.net> <38d173e4-1de1-1224-99ea-cbedb9f1b168@shout.net> <5A6896F4.6040308@foobar.org> <20180124144858.GC35164@vurt.meerval.net> <20180127213056.GB19410@puck.nether.net> Message-ID: <20180128023605.GE11617@vurt.meerval.net> On Sat, Jan 27, 2018 at 04:30:56PM -0500, Jared Mauch wrote: > On Wed, Jan 24, 2018 at 02:48:58PM +0000, Job Snijders wrote: > > --- thread hijack --- > > > > Coincidentally, I'm working to define something like "AS-SETs in > > RPKI". There are a number of downsides to "AS-SETs in IRR": > > collisions between databases can exist, it is hard to figure out > > what AS-SET to use for what ASN (we rely on service order forms, > > peeringdb or guessing for that), and the way the recursion was done > > can too easily result in gigantic sets. > > Obviously you have to prune once you hit a loop, but this is how you > can traverse a edge-node graph to find the leaves given a starting > point. > > > I'd be interested to know what others think about improving feature > > parity between IRR and RPKI, and while doing that make the bad > > aspects of AS-SETs go away and keep the good parts. Thoughts? > > I've found that saying RR, IRR and RPKI overloads one technology > with another. One needs a standards based method to access a > database about routing information. We can federate databases > together or come up with methods to do this. RPKI is another > database you can validate against but it also has limits. Yes, I'm moving away from "let us all use this one thing", and rather explore how to integrate all the available data sources (IRR, WHOIS, RPKI, our internal DB, and $the_next_thing) and create more choice for customers. Addressing the various threats that one can model may be resolved through local policy ("data type X from source A overrides data type Y from source B", or merge, or prune actions, etc). > If I were a backbone, I would be asking myself: How can customers > effectively communicate with me their intent? RPKI and IRR have > weknesses and the networks with automation and tooling here are > light years ahead of those that have nothing. [ snip ] Yeah, a real problem for ISPs is that it isn't clear wat AS-SET to use for what neighbor. - The discovery mechanism that RPSL was to provide is broken beyond repair: import/export lines are unparsable. - I know of route server config generators that query PeeringDB to fetch the "IRR Record" as a starting point to generate filters, but that is sometimes problematic because (a) we may be using the wrong IRR DB in case of duplicate AS-SET names and (b) there is a lack of granularity (you may not want to announce the same as-set to all route-servers). - NTT simply asks customers/peers what as-set to use during the turn-up process, but that as-set name may be deprecated by the peer over time, and the mechanism to inform us is a bit archaic "email us". What I think could be done with RPKI: A mechanism that addresses the autodiscovery, and allows a degree of granularity by allowing you to specify on a per-ASN basis what should be used as the starting point to create a filter will make things better. Toolchains (COTS, closed, and open source) would increase their chances of finding the right starting point if they first try to query the RPKI for information, and if that fails, fall back to either a database record from a service order form or a query to PeeringDB. With "right" I mean the most up to date and most likely intended one. An 'AS-SET in RPKI' statement could also be published in IRR format (by RIRs publishing it under a new "source:" name) to provide some backwards compatibility. This helps address challenges in geographical regions where the whole concept of "IRR" never took off, but RPKI is popular (LATAM comes to mind). > There's no universal way to communicate these relationships yet we > have web based platforms where I can tell you what many list members > ate for dinner last night. There is a lack of will to take action > here and a lack of common toolchains that can be integrated to > perform the tasks. Any platform under end-to-end control of a single entity will be able to innovate and deliver at a much faster pace than something that'll need to facilitate coordination across administrative domains :-) > A few interesting AS_Paths: > > 2497 701 5511 59378 7473 2914 132602 38203 137038 > 3356 6453 21502 1299 6848 44216 > 701 6453 21502 1299 6848 44216 I'll make some phone calls Monday. Kind regards, Job From baldur.norddahl at gmail.com Sun Jan 28 03:02:44 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 28 Jan 2018 04:02:44 +0100 Subject: IRR AS-SET best practices - AS-SET Clash In-Reply-To: <20180124144858.GC35164@vurt.meerval.net> References: <1223319464.4903.1516716725053.JavaMail.mhammett@ThunderFuck> <2083918305.544.1516732808724.JavaMail.mhammett@ThunderFuck> <20180123213518.rriw23xe3tfu2nwx@dan.olp.net> <38d173e4-1de1-1224-99ea-cbedb9f1b168@shout.net> <5A6896F4.6040308@foobar.org> <20180124144858.GC35164@vurt.meerval.net> Message-ID: The hierarchical as-set strategy has the problem that many fails to parse it correctly. We use it at NL-IX with the result that their portal believe we have no peers. Den 24. jan. 2018 15.50 skrev "Job Snijders" : On Wed, Jan 24, 2018 at 02:23:48PM +0000, Nick Hilliard wrote: > Alain Hebert wrote: > > Any feedback on best practices and "other avenue" about IRR naming? > > Known problem - you're asking for trouble unless you filter IRRDB > queries by source: > > There isn't a global namespace for as-set names, unless you use > source: as a database key element. In addition to the above, one could use "hierarchical" AS-SET names, in some databases (from the top of my head: APNIC, AfriNIC, RIPE) only the owner of the ASN can create AS-SETs under that ASN's namespace. But more importantly: using the ASN in the AS-SET name chances of collision are reduced. Example: I defined "AS15562:AS-SNIJDERS" in the RIPE database, instead of "AS-SNIJDERS". Same for "AS2914:AS-GLOBAL" in NTTCOM. --- thread hijack --- Coincidentally, I'm working to define something like "AS-SETs in RPKI". There are a number of downsides to "AS-SETs in IRR": collisions between databases can exist, it is hard to figure out what AS-SET to use for what ASN (we rely on service order forms, peeringdb or guessing for that), and the way the recursion was done can too easily result in gigantic sets. I'd be interested to know what others think about improving feature parity between IRR and RPKI, and while doing that make the bad aspects of AS-SETs go away and keep the good parts. Thoughts? Kind regards, Job ps. raised the question here too https://mail.lacnic.net/ pipermail/lacnog/2018-January/005845.html From job at ntt.net Sun Jan 28 03:14:56 2018 From: job at ntt.net (Job Snijders) Date: Sun, 28 Jan 2018 03:14:56 +0000 Subject: IRR AS-SET best practices - AS-SET Clash In-Reply-To: References: <5A6896F4.6040308@foobar.org> <20180124144858.GC35164@vurt.meerval.net> Message-ID: <20180128031456.GF11617@vurt.meerval.net> On Sun, Jan 28, 2018 at 04:02:44AM +0100, Baldur Norddahl wrote: > The hierarchical as-set strategy has the problem that many fails to > parse it correctly. We use it at NL-IX with the result that their > portal believe we have no peers. That sounds like a simple bug in that specific portal. If you want, please share details with me off list. I don't believe this to be a common issue. Kind regards, Job From randy at psg.com Sun Jan 28 04:48:16 2018 From: randy at psg.com (Randy Bush) Date: Sun, 28 Jan 2018 13:48:16 +0900 Subject: Leasing /22 In-Reply-To: References: <1692949565.1569.1516461624805.JavaMail.mhammett@ThunderFuck> Message-ID: > IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat, > MAP-T, MAP-E. you forgot the sarcasm emoji randy From randy at psg.com Sun Jan 28 04:52:44 2018 From: randy at psg.com (Randy Bush) Date: Sun, 28 Jan 2018 13:52:44 +0900 Subject: list blockchain Message-ID: why is no one exploring converting this mailing list to a blockchain? major missed opportunity. randy From mh at xalto.net Sun Jan 28 13:22:54 2018 From: mh at xalto.net (Michael Hallgren) Date: Sun, 28 Jan 2018 14:22:54 +0100 Subject: list blockchain In-Reply-To: References: Message-ID: :-) mh Le 2018-01-28 05:52, Randy Bush a écrit : > why is no one exploring converting this mailing list to a blockchain? > major missed opportunity. > > randy From oliver.oboyle at gmail.com Sun Jan 28 13:32:39 2018 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Sun, 28 Jan 2018 08:32:39 -0500 Subject: list blockchain In-Reply-To: References: Message-ID: Because we'd all have to show work to prove our comments are legit... On Sat, Jan 27, 2018 at 11:52 PM, Randy Bush wrote: > why is no one exploring converting this mailing list to a blockchain? > major missed opportunity. > > randy -- :o@> From johnl at iecc.com Sun Jan 28 17:50:27 2018 From: johnl at iecc.com (John Levine) Date: 28 Jan 2018 12:50:27 -0500 Subject: list blockchain In-Reply-To: Message-ID: <20180128175027.935EF19E701E@ary.qy> In article you write: >why is no one exploring converting this mailing list to a blockchain? >major missed opportunity. Ssshhh, we're in the quiet period before the IPO. From trelane at trelane.net Sun Jan 28 18:02:26 2018 From: trelane at trelane.net (Andrew Kirch) Date: Sun, 28 Jan 2018 18:02:26 +0000 Subject: list blockchain In-Reply-To: <20180128175027.935EF19E701E@ary.qy> References: <20180128175027.935EF19E701E@ary.qy> Message-ID: On Sun, Jan 28, 2018 at 12:52 PM John Levine wrote: > In article you write: > >why is no one exploring converting this mailing list to a blockchain? > >major missed opportunity. > > Ssshhh, we're in the quiet period before the IPO. > > Block chain? We can’t get half these people to adopt IPv6. From toddunder at gmail.com Sun Jan 28 18:38:25 2018 From: toddunder at gmail.com (Todd Underwood) Date: Sun, 28 Jan 2018 13:38:25 -0500 Subject: list blockchain In-Reply-To: References: <20180128175027.935EF19E701E@ary.qy> Message-ID: This isn't off-topic noise at all. Nope. Nothing to see here. Move along. Moderators: even when posts are by long term members of the community can you remind them of the list purpose when they forget, please? Thanks! T On Jan 28, 2018 13:04, "Andrew Kirch" wrote: > On Sun, Jan 28, 2018 at 12:52 PM John Levine wrote: > > > In article you write: > > >why is no one exploring converting this mailing list to a blockchain? > > >major missed opportunity. > > > > Ssshhh, we're in the quiet period before the IPO. > > > > Block chain? We can’t get half these people to adopt IPv6. > From mfidelman at meetinghouse.net Sun Jan 28 19:03:07 2018 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 28 Jan 2018 12:03:07 -0700 Subject: list blockchain In-Reply-To: <20180128175027.935EF19E701E@ary.qy> References: <20180128175027.935EF19E701E@ary.qy> Message-ID: <710d8801-7436-f922-b65e-7629b22b1249@meetinghouse.net> On 1/28/18 10:50 AM, John Levine wrote: > In article you write: >> why is no one exploring converting this mailing list to a blockchain? >> major missed opportunity. Really?  We're operators, we're supposed to be conservative. Why haven't we converted list to a DHT?  (FYI: That was tested rather effectively for some USENET groups.  Kind of an interesting approach for traffic with large attachments.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From tom at ninjabadger.net Mon Jan 29 12:05:28 2018 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 29 Jan 2018 12:05:28 +0000 Subject: list blockchain In-Reply-To: References: <20180128175027.935EF19E701E@ary.qy> Message-ID: <8832e563-4dff-e072-3898-910fdf39cbec@ninjabadger.net> On 28/01/18 18:38, Todd Underwood wrote: > Moderators: even when posts are by long term members of the community can > you remind them of the list purpose when they forget, please? Thanks! Randy's post has provided more commentary on our industry than most of the other drivelling nonsense that befalls this mailing list every other day. Reminder: satire can be relevant. -- Tom From toddunder at gmail.com Mon Jan 29 19:04:00 2018 From: toddunder at gmail.com (Todd Underwood) Date: Mon, 29 Jan 2018 14:04:00 -0500 Subject: list blockchain In-Reply-To: <8832e563-4dff-e072-3898-910fdf39cbec@ninjabadger.net> References: <20180128175027.935EF19E701E@ary.qy> <8832e563-4dff-e072-3898-910fdf39cbec@ninjabadger.net> Message-ID: On Mon, Jan 29, 2018 at 7:05 AM, Tom Hill wrote: > On 28/01/18 18:38, Todd Underwood wrote: > > Moderators: even when posts are by long term members of the community can > > you remind them of the list purpose when they forget, please? Thanks! > > Randy's post has provided more commentary on our industry than most of > the other drivelling nonsense that befalls this mailing list every other day. > disagree. it was a zero-content offhand snipe. it was funny, but clearly off-topic and useless. i suspect even randy would agree with that. > > Reminder: satire can be relevant. > agree. this time it managed to not be. t > > -- > Tom > From rsk at gsp.org Wed Jan 31 15:17:46 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 31 Jan 2018 10:17:46 -0500 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: <5A6AAA1A.2040906@jmaimon.com> References: <5A6AAA1A.2040906@jmaimon.com> Message-ID: <20180131151746.GC1779@gsp.org> On Thu, Jan 25, 2018 at 11:10:02PM -0500, Joe Maimon wrote: > What I am interested in is an automated zoom-in zoom-out tool to mask the > repetition of "normal" events and allow the unusual to stand out. This is an approach outlined by Marcus Ranum years ago; he called it "artificial stupidity", and it works. (Of course, an inverse check that makes sure routine boring things are still happening is also a good idea.) You could use any number of elaborate (and sometimes expensive) tools to do this, but I recommend rolling your own with Perl or similar. This is goodness for two reasons: first, it forces you to look at your own data, which is really helpful. You'll be surprised at what you find if you've never done it before. Second, it lets you customize for your environment at every step. I have written dozens of these, some as trivial as a few lines of code, some quite extensive. None of them "solve" the problem per se, they just all take bites out of it. But this admittedly-simplistic (and deliberately so) approach has flagged a lot of issues, and because it's simple, it's easy to connect to other monitoring/alerting plumbing. ---rsk From george.herbert at gmail.com Wed Jan 31 19:59:52 2018 From: george.herbert at gmail.com (George William Herbert) Date: Wed, 31 Jan 2018 11:59:52 -0800 Subject: improving signal to noise ratio from centralized network syslogs In-Reply-To: <20180131151746.GC1779@gsp.org> References: <5A6AAA1A.2040906@jmaimon.com> <20180131151746.GC1779@gsp.org> Message-ID: <2C1B6BAE-4C29-49E0-A37F-FF5F22B353FB@gmail.com> From the systems side we got HoneycombIO which shifts a bit to calling itself events rather than logs management. I don't know anyone else who's tried using it for networks per se but that's on my "interesting tech tools explorations" medium length list. -george Sent from my iPhone > On Jan 31, 2018, at 7:17 AM, Rich Kulawiec wrote: > >> On Thu, Jan 25, 2018 at 11:10:02PM -0500, Joe Maimon wrote: >> What I am interested in is an automated zoom-in zoom-out tool to mask the >> repetition of "normal" events and allow the unusual to stand out. > > This is an approach outlined by Marcus Ranum years ago; he called it > "artificial stupidity", and it works. (Of course, an inverse check > that makes sure routine boring things are still happening is also > a good idea.) > > You could use any number of elaborate (and sometimes expensive) tools > to do this, but I recommend rolling your own with Perl or similar. > This is goodness for two reasons: first, it forces you to look at your > own data, which is really helpful. You'll be surprised at what you > find if you've never done it before. Second, it lets you customize for > your environment at every step. > > I have written dozens of these, some as trivial as a few lines of code, > some quite extensive. None of them "solve" the problem per se, they just > all take bites out of it. But this admittedly-simplistic (and deliberately > so) approach has flagged a lot of issues, and because it's simple, > it's easy to connect to other monitoring/alerting plumbing. > > ---rsk