From danm at prime.gushi.org Sun Oct 1 00:12:52 2017 From: danm at prime.gushi.org (Dan Mahoney (Gushi)) Date: Sat, 30 Sep 2017 17:12:52 -0700 (PDT) Subject: ISC DLV Registry now running a signed empty zone Message-ID: All, Just to let people know via this list: As of DNS-OARC 27 (where the change was done live) ISC's DLV Registry has now been replaced with a signed empty zone (SOA/NS/A/TXT/DNSKEY/RRSIG), which will be auto-re-signed with the same keys for the forseeable future. The IP address for the old DLV web-ui now redirects to ISC's main page, but if anyone needs a copy of the last-known zone contents for historical purposes, please reach out. Thanks to the community for your support. -Dan Mahoney ISC Operations Group -- Notes: This was sent from my personal domain because that's what I keep subscribed to NANOG, but I'm speaking in this post as an ISC Employee. I will be at NANOG San Jose, I have blue hair and am hard to miss. (Also sent to a couple dns-related lists, apologies for duplicates). From morrowc.lists at gmail.com Sun Oct 1 01:28:28 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 30 Sep 2017 21:28:28 -0400 Subject: AS PATH limits In-Reply-To: <20170930164726.GY17040@sizone.org> References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> <250E7C00-8917-46AA-8581-C74933BE75B0@fusix.nl> <20170930164726.GY17040@sizone.org> Message-ID: On Sat, Sep 30, 2017 at 12:47 PM, Ken Chase wrote: > I dont see that as the solution. Someone else will offend again. > > However, I also don't see trusting major backbones as our filters (for many > other reasons). Our software should be handling what's effectively a > buffer overflow > or equivalent (beware long paths that are actually shellcode). > > Quagga among others seems to be subject to this bug, pre 0.99.23 or so > (.99.24+ seems ok). So upgrading is a solution. > > ii quagga 0.99.22.4-3ubu i386 BGP/OSPF/RIP routing daemon interestingly enough that isn't crashlooping nor is it bouncing bgp sessions: 192.168.100.100 4 MYASN 1642717 8864 0 0 0 2d23h32m 672475 and it's happily showing me the route even... There was also some chatter on the quagga mailing list on how it's more > pleasant to stab your eyeballs out rather than constructing extremely long > regexp's that might work as a filter. > > https://lists.quagga.net/pipermail/quagga-users/2017-September/thread.html > > /kc > > > On Sat, Sep 30, 2017 at 05:30:03PM +0200, Niels Raijer said: > >My message to NANOG about this from 12:31 UTC today is still in the > moderation queue. I had opened a support case with Cogent before writing my > message to NANOG and Cogent has let me know approximately 40 minutes ago > that they have contacted their customer. > > > >Niels > > > > > > > >On 30 Sep 2017, at 17:09, sthaug at nethelp.no wrote: > > > >>> If you're on cogent, since 22:30 UTC yesterday or so this has been > happening > >>> (or happened). > >> > >> Still happening here. I count 562 prepends (563 * 262197) in the > >> advertisement we receive from Cogent. I see no good reason why we > >> should accept that many prepends. > >> > >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > > > -- > Ken Chase - math at sizone.org Guelph Canada > From math at sizone.org Sun Oct 1 05:05:46 2017 From: math at sizone.org (Ken Chase) Date: Sun, 1 Oct 2017 01:05:46 -0400 Subject: AS PATH limits In-Reply-To: References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> <250E7C00-8917-46AA-8581-C74933BE75B0@fusix.nl> <20170930164726.GY17040@sizone.org> Message-ID: <20171001050546.GG17040@sizone.org> I don't quite understand the exact situation that causes the issue - our cogent facing router (quagga .99.22 debian) was receiving the route but that session stayed up - it was it while sending or the other igp router (also quagga .99.22) receiving (I think the latter) that was crashing their session. Not quite sure why the cogent session didn't crash as well (or first, before propagating the bad route). At any rate, we should likely take this discussion to the quagga-users-l /kc On Sat, Sep 30, 2017 at 09:28:28PM -0400, Christopher Morrow said: >ii quagga 0.99.22.4-3ubu i386 BGP/OSPF/RIP routing >daemon > >interestingly enough that isn't crashlooping nor is it bouncing bgp >sessions: >192.168.100.100 4 MYASN 1642717 8864 0 0 0 2d23h32m >672475 > >and it's happily showing me the route even... -- Ken Chase - math at sizone.org Guelph Canada From hank at efes.iucc.ac.il Sun Oct 1 05:17:53 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 1 Oct 2017 08:17:53 +0300 Subject: AS PATH limits In-Reply-To: References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> <250E7C00-8917-46AA-8581-C74933BE75B0@fusix.nl> <20170930164726.GY17040@sizone.org> Message-ID: On 01/10/2017 04:28, Christopher Morrow wrote: > On Sat, Sep 30, 2017 at 12:47 PM, Ken Chase wrote: > >> I dont see that as the solution. Someone else will offend again. >> >> However, I also don't see trusting major backbones as our filters (for many >> other reasons). Our software should be handling what's effectively a >> buffer overflow >> or equivalent (beware long paths that are actually shellcode). >> >> Quagga among others seems to be subject to this bug, pre 0.99.23 or so >> (.99.24+ seems ok). So upgrading is a solution. >> >> > ii quagga 0.99.22.4-3ubu i386 BGP/OSPF/RIP routing > daemon > > interestingly enough that isn't crashlooping nor is it bouncing bgp > sessions: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-1572 Quagga 0.99.11 and earlier affected. Fixed in 2009. -Hank > 192.168.100.100 4 MYASN 1642717 8864 0 0 0 2d23h32m > 672475 > > and it's happily showing me the route even... > > There was also some chatter on the quagga mailing list on how it's more >> pleasant to stab your eyeballs out rather than constructing extremely long >> regexp's that might work as a filter. >> >> https://lists.quagga.net/pipermail/quagga-users/2017-September/thread.html >> >> /kc >> >> >> On Sat, Sep 30, 2017 at 05:30:03PM +0200, Niels Raijer said: >> >My message to NANOG about this from 12:31 UTC today is still in the >> moderation queue. I had opened a support case with Cogent before writing my >> message to NANOG and Cogent has let me know approximately 40 minutes ago >> that they have contacted their customer. >> > >> >Niels >> > >> > >> > >> >On 30 Sep 2017, at 17:09, sthaug at nethelp.no wrote: >> > >> >>> If you're on cogent, since 22:30 UTC yesterday or so this has been >> happening >> >>> (or happened). >> >> >> >> Still happening here. I count 562 prepends (563 * 262197) in the >> >> advertisement we receive from Cogent. I see no good reason why we >> >> should accept that many prepends. >> >> >> >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no >> > >> >> -- >> Ken Chase - math at sizone.org Guelph Canada >> From swmike at swm.pp.se Sun Oct 1 05:23:16 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 1 Oct 2017 07:23:16 +0200 (CEST) Subject: AS PATH limits In-Reply-To: References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> <250E7C00-8917-46AA-8581-C74933BE75B0@fusix.nl> <20170930164726.GY17040@sizone.org> Message-ID: On Sun, 1 Oct 2017, Hank Nussbacher wrote: > https://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-1572 > Quagga 0.99.11 and earlier affected. > Fixed in 2009. It was fixed in other OSes as well after this, I presume: http://blog.ipspace.net/2009/02/root-cause-analysis-oversized-as-paths.html -- Mikael Abrahamsson email: swmike at swm.pp.se From bill at herrin.us Sun Oct 1 05:24:46 2017 From: bill at herrin.us (William Herrin) Date: Sun, 1 Oct 2017 01:24:46 -0400 Subject: AS PATH limits In-Reply-To: <20171001050546.GG17040@sizone.org> References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> <250E7C00-8917-46AA-8581-C74933BE75B0@fusix.nl> <20170930164726.GY17040@sizone.org> <20171001050546.GG17040@sizone.org> Message-ID: On Sun, Oct 1, 2017 at 1:05 AM, Ken Chase wrote: > I don't quite understand the exact situation that causes the issue - our > cogent facing router (quagga .99.22 debian) was receiving the route but > that > session stayed up - it was it while sending or the other igp router (also > quagga .99.22) receiving (I think the latter) that was crashing their > session. > Not quite sure why the cogent session didn't crash as well (or first, > before > propagating the bad route). > Hi Ken, Technically the route is not bad, just really inconsiderate. The bug happens when quagga sends the the long-AS path route to a peer. As I understand it, when the announcement is larger than one segment, Quagga double-counts the some of the bytes when computing the number of bytes in the AS path. It receives the announcement just fine, but then it corrupts what it sends to the neighbor who then chokes. Bug and patch here: https://lists.quagga.net/pipermail/quagga-dev/2017-September/033284.html Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From marcel.duregards at yahoo.fr Sun Oct 1 16:16:09 2017 From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr) Date: Sun, 01 Oct 2017 18:16:09 +0200 Subject: Long BGP AS paths In-Reply-To: References: Message-ID: <59D114C9.8010100@yahoo.fr> What would be a recommended value for a maximum as-path filter ? 50 ? On the DFZ I've only 11 prefixes longer than 30 as-path, so for safety I would also assume 50 as a max is well enough. Any advice ? Regards, - Marcel On 01.10.2017 00:29, William Herrin wrote: > To the chucklehead who started announcing a 2200+ byte AS path yesterday > around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga > that's present in all versions released in the last decade. Your > announcement causes routers based on Quagga to send a malformed update to > their neighbors, collapsing the entire BGP session. Every 30 seconds or so. > > For everyone else: please consider filtering BGP announcements with > stupidly long AS paths. There's no need nor excuse for them to be present > in the DFZ and you could have saved me a painful Saturday. > > Cisco: > > router bgp XXX > bgp maxas-limit 50 > > > Juniper: > https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 > > > Quagga: > > ip as-path access-list maxas-limit50 deny ^([{},0-9]+ ){50} > ip as-path access-list maxas-limit50 permit .* > > > Regards, > Bill Herrin > > . From mprice at tqhosting.com Sun Oct 1 04:32:21 2017 From: mprice at tqhosting.com (Mark Price) Date: Sun, 1 Oct 2017 00:32:21 -0400 Subject: Long BGP AS paths In-Reply-To: References: Message-ID: Hi Bill, Could you list which prefix(es) you saw were being announced with these long AS paths? Mark On Sat, Sep 30, 2017 at 6:29 PM, William Herrin wrote: > To the chucklehead who started announcing a 2200+ byte AS path yesterday > around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga > that's present in all versions released in the last decade. Your > announcement causes routers based on Quagga to send a malformed update to > their neighbors, collapsing the entire BGP session. Every 30 seconds or so. > > For everyone else: please consider filtering BGP announcements with > stupidly long AS paths. There's no need nor excuse for them to be present > in the DFZ and you could have saved me a painful Saturday. > > Cisco: > > router bgp XXX > bgp maxas-limit 50 > > > Juniper: > https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 > > > Quagga: > > ip as-path access-list maxas-limit50 deny ^([{},0-9]+ ){50} > ip as-path access-list maxas-limit50 permit .* > > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From sthaug at nethelp.no Sun Oct 1 17:59:26 2017 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 01 Oct 2017 19:59:26 +0200 (CEST) Subject: Long BGP AS paths In-Reply-To: References: Message-ID: <20171001.195926.74735175.sthaug@nethelp.no> > Could you list which prefix(es) you saw were being announced with these > long AS paths? 186.177.184.0/23 - still being announced with 533 occurrences of 262197 in the AS path. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jlewis at lewis.org Sun Oct 1 18:42:22 2017 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 1 Oct 2017 14:42:22 -0400 (EDT) Subject: Long BGP AS paths In-Reply-To: <20171001.195926.74735175.sthaug@nethelp.no> References: <20171001.195926.74735175.sthaug@nethelp.no> Message-ID: On Sun, 1 Oct 2017, sthaug at nethelp.no wrote: >> Could you list which prefix(es) you saw were being announced with these >> long AS paths? > > 186.177.184.0/23 - still being announced with 533 occurrences of 262197 > in the AS path. aut-num: AS262197 owner: MILLICOM CABLE COSTA RICA S.A. ownerid: CR-ACCR1-LACNIC responsible: Jonathan Cisneros address: 350mts Oeste del Ministerio de Agricultura, frente a entrada principal UCIMED, Sabana Oeste, 0, 0 address: 10108 - San Jos� - SJ country: CR phone: +50 2 2790099 [] owner-c: JOC63 routing-c: JOC63 abuse-c: ATR9 created: 20130709 changed: 20140804 Anyone care to bet on whether they're using a Mikrotik and did /routing filter add set-bgp-prepend=262197 and this somehow got truncated to fewer than the "requested" 262197 prepends? I'm seeing 562 prepends...which doesn't seem to work out to any obvious amount of bitwise truncation/wrap. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rod.beck at unitedcablecompany.com Sun Oct 1 20:18:33 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Sun, 1 Oct 2017 20:18:33 +0000 Subject: Terminology Clarification - "Active Wave" Message-ID: A financial firm asked me if a 10 gig wave offer was an "active wave". 😨 LAN PHY 10 GigE, WAN PHY 10 GigE, transparent, STM64, OC192. Yes. Active? Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From tony at wicks.co.nz Sun Oct 1 20:33:54 2017 From: tony at wicks.co.nz (Tony Wicks) Date: Mon, 2 Oct 2017 09:33:54 +1300 Subject: Terminology Clarification - "Active Wave" In-Reply-To: References: Message-ID: <00cc01d33af4$9af5af20$d0e10d60$@wicks.co.nz> I would suggest they are asking if it is to be carried on an active (Powered) DWDM ADM (Add Drop Mux), or over passive optical Mux's (short range). -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rod Beck Sent: Monday, 2 October 2017 9:19 AM To: nanog at nanog.org Subject: Terminology Clarification - "Active Wave" A financial firm asked me if a 10 gig wave offer was an "active wave". 😨 LAN PHY 10 GigE, WAN PHY 10 GigE, transparent, STM64, OC192. Yes. Active? Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From rod.beck at unitedcablecompany.com Sun Oct 1 20:50:48 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Sun, 1 Oct 2017 20:50:48 +0000 Subject: Terminology Clarification - "Active Wave" In-Reply-To: <00cc01d33af4$9af5af20$d0e10d60$@wicks.co.nz> References: , <00cc01d33af4$9af5af20$d0e10d60$@wicks.co.nz> Message-ID: Thanks. I think that makes sense. - R. ________________________________ From: Tony Wicks Sent: Sunday, October 1, 2017 10:33 PM To: Rod Beck Cc: nanog at nanog.org Subject: RE: Terminology Clarification - "Active Wave" I would suggest they are asking if it is to be carried on an active (Powered) DWDM ADM (Add Drop Mux), or over passive optical Mux's (short range). -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rod Beck Sent: Monday, 2 October 2017 9:19 AM To: nanog at nanog.org Subject: Terminology Clarification - "Active Wave" A financial firm asked me if a 10 gig wave offer was an "active wave". 😨 LAN PHY 10 GigE, WAN PHY 10 GigE, transparent, STM64, OC192. Yes. Active? Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com> 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From tim at snas.io Sun Oct 1 21:29:50 2017 From: tim at snas.io (Tim Evens) Date: Sun, 01 Oct 2017 14:29:50 -0700 Subject: Long BGP AS paths In-Reply-To: <59D114C9.8010100@yahoo.fr> References: <59D114C9.8010100@yahoo.fr> Message-ID: The outliers are >100. Based on several peering points, <= 60 should be fine. See attached CSV file that shows the top 120 distinct AS Paths seen for the past month. Looks like 55644 likes to prepend a lot which is pushing the length above 50. --Tim On 01.10.2017 09:16, marcel.duregards--- via NANOG wrote: > What would be a recommended value for a maximum as-path filter ? > > 50 ? > > On the DFZ I've only 11 prefixes longer than 30 as-path, so for safety I > would also assume 50 as a max is well enough. Any advice ? > > Regards, > - > Marcel > > On 01.10.2017 00:29, William Herrin wrote: > >> To the chucklehead who started announcing a 2200+ byte AS path yesterday around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga that's present in all versions released in the last decade. Your announcement causes routers based on Quagga to send a malformed update to their neighbors, collapsing the entire BGP session. Every 30 seconds or so. For everyone else: please consider filtering BGP announcements with stupidly long AS paths. There's no need nor excuse for them to be present in the DFZ and you could have saved me a painful Saturday. Cisco: router bgp XXX bgp maxas-limit 50 Juniper: https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 [1] Quagga: ip as-path access-list maxas-limit50 deny ^([{},0-9]+ ){50} ip as-path access-list maxas-limit50 permit .* Regards, Bill Herrin > > . Links: ------ [1] https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 From bill at herrin.us Sun Oct 1 22:17:10 2017 From: bill at herrin.us (William Herrin) Date: Sun, 1 Oct 2017 18:17:10 -0400 Subject: Long BGP AS paths In-Reply-To: References: Message-ID: On Sun, Oct 1, 2017 at 1:06 PM, Kelly Dowd wrote: > On Sun, Oct 1, 2017 at 12:29 AM, William Herrin wrote: > >> To the chucklehead who started announcing a 2200+ byte AS path yesterday >> around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga >> > > Is this better or worse than the "chucklehead" who is running buggy > routing kit and complaining about what is a perfectly valid configuration? > Hi Kelly, Show me a reasonable use case for an AS path that's much longer than the Internet is wide and I'll withdraw my complaint. Your software has bugs too. You just didn't get bitten. This time. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From randy at psg.com Sun Oct 1 22:43:11 2017 From: randy at psg.com (Randy Bush) Date: Mon, 02 Oct 2017 07:43:11 +0900 Subject: AS PATH limits In-Reply-To: References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> <250E7C00-8917-46AA-8581-C74933BE75B0@fusix.nl> <20170930164726.GY17040@sizone.org> Message-ID: looks to me as if 262206 is trying a silly tactic to down-pref inbound from cogent. as cogent probably prefers customers to peers, it may not be working as 262206 expected, so they keep pounding with the same hammer hoping for a miracle. cogent accepts it as they are being paid to do so; normal practice. perhaps our ire should be directed at 262206, not cogent? has anyone tried to contact them? randy From randy at psg.com Sun Oct 1 22:45:20 2017 From: randy at psg.com (Randy Bush) Date: Mon, 02 Oct 2017 07:45:20 +0900 Subject: Long BGP AS paths In-Reply-To: References: Message-ID: > Nowhere in the BGP RFCs it says it is okay for the software to crash. we could send a community to signal that it's ok to crash randy From surfer at mauigateway.com Mon Oct 2 01:22:18 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 1 Oct 2017 18:22:18 -0700 Subject: Long BGP AS paths Message-ID: <20171001182218.33A10F46@m0117458.ppops.net> > Nowhere in the BGP RFCs it says it is okay for the > software to crash. :: we could send a community to signal that it's ok :: to crash Call it the ECB. (Evil Crash Bit). ;-) scott From herbeljs at gmail.com Sun Oct 1 20:29:40 2017 From: herbeljs at gmail.com (jeff herbel) Date: Sun, 01 Oct 2017 20:29:40 +0000 Subject: Terminology Clarification - "Active Wave" In-Reply-To: References: Message-ID: Yes. They might be thinking of dark fiber.. On Sun, Oct 1, 2017, 4:20 PM Rod Beck wrote: > A financial firm asked me if a 10 gig wave offer was an "active wave". 😨 > > > LAN PHY 10 GigE, WAN PHY 10 GigE, transparent, STM64, OC192. Yes. > > > Active? > > > Roderick Beck > > Director of Global Sales > > United Cable Company > > www.unitedcablecompany.com > > 85 Király utca > , > 1077 Budapest > > rod.beck at unitedcablecompany.com > > 36-30-859-5144 > > > [1467221477350_image005.png] > From tim at snas.io Sun Oct 1 21:40:18 2017 From: tim at snas.io (Tim Evens) Date: Sun, 01 Oct 2017 14:40:18 -0700 Subject: Long BGP AS paths In-Reply-To: References: <59D114C9.8010100@yahoo.fr> Message-ID: Looks like attachments do not work in the mailer. See below, a bit ugly, but it's CSV so you should be able to cut/paste it to check it out. timestamp,as_path_length,as_path 2017-09-29 22:26:40.000000,568, 2518 2914 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:39.000000,568, 393406 6453 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:32.000000,568, 393406 1299 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:43.000000,568, 63956 1299 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:46.000000,568, 200130 2914 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:28:04.000000,568, 1221 4637 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:31.000000,568, 202018 2914 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:39.000000,568, 40191 3257 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:39.000000,568, 47872 1299 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:39.000000,568, 62567 6453 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:33.000000,568, 40387 23473 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:33.000000,567, 59469 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:40.000000,567, 1299 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:23.000000,567, 5645 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:42.000000,567, 38726 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:27:06.000000,567, 48526 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:40.000000,567, 46450 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:21.000000,567, 2914 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:29.000000,567, 3257 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:33.000000,567, 1351 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:39.000000,567, 40191 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:27:09.000000,567, 22652 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:26:39.000000,567, 1403 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-30 23:45:14.000000,567, 40387 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 22:25:35.000000,287, 40387 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 2017-09-29 19:05:44.131277,57, 48285 16150 12552 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:13:05.243778,57, 6539 577 6461 7473 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 18:38:19.000000,57, 1351 10578 11164 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-30 08:10:54.000000,57, 36236 13647 3257 7473 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-30 14:16:12.477538,57, 15008 40805 3257 7473 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:04:17.815514,56, 59469 1299 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-10-01 16:41:20.000000,56, 6082 174 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:10:25.584084,56, 45177 6461 7473 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:10:27.255566,56, 3267 1299 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:17:57.998200,56, 53767 3257 7473 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:15:12.817326,56, 2152 11164 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:14:43.569087,56, 7660 2516 4637 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:12:24.450289,56, 40191 3257 7473 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:09:56.936370,56, 49788 12552 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 18:48:25.000000,56, 1239 6461 7473 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:14:32.443700,56, 3741 6461 7473 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 18:11:08.000000,56, 1403 6461 7473 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 18:48:17.000000,56, 1403 174 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:04:52.557506,56, 19754 1299 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:02:00.209997,56, 40387 11164 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:07:51.131915,55, 58511 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:03:01.991393,55, 5650 2914 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:08:22.729136,55, 37100 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:15:39.591809,55, 3130 2914 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:19:06.152854,55, 8492 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:10:08.357636,55, 1299 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-30 17:28:04.000000,55, 38883 4826 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:13:57.686457,55, 34224 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-30 05:23:16.307641,55, 30844 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:12:01.440707,55, 54728 6939 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:03:09.616578,55, 3257 7473 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:11:16.061315,55, 57463 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 18:37:06.000000,55, 1351 6939 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:05:50.916311,55, 63956 2914 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:07:50.223935,55, 31019 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-30 05:23:11.212948,55, 37497 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:15:44.743024,55, 22652 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-30 14:16:52.014581,55, 53828 6939 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:17:19.557775,54, 18106 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:16:34.827094,54, 6939 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:03:06.834563,54, 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:02:54.359349,54, 45352 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:10:27.852368,54, 2914 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:13:01.862635,51, 58511 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-10-01 16:41:20.000000,51, 6082 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:05:58.265775,51, 45896 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:05:27.542054,51, 5645 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:09:28.496430,51, 63956 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:04:08.220054,51, 38726 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-10-01 04:41:23.000000,51, 24516 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:04:26.360140,51, 46450 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:15:55.815415,51, 54728 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 18:37:13.000000,51, 1351 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:05:32.763703,51, 38880 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 20:43:10.000000,51, 24441 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-30 19:37:17.000000,51, 9902 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-30 08:10:33.000000,51, 36236 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:03:45.368382,51, 19754 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:10:36.206310,50, 6939 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-09-29 19:12:55.367919,50, 47872 15412 18101 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 2017-10-01 04:54:34.000000,39, 3277 39710 20632 31133 2914 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:39.000000,39, 38726 9957 38091 9318 3491 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-30 23:48:56.000000,38, 34288 15576 3303 3320 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:38.000000,38, 6082 174 174 174 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-30 07:42:51.000000,38, 8492 20764 3216 1273 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-29 20:34:55.000000,38, 8492 20764 8732 1299 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:37.000000,38, 48285 16150 12552 3356 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:53:37.000000,38, 48285 16150 12552 1299 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:56:03.000000,38, 45352 38001 41095 3491 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:52:47.000000,38, 24516 7474 7473 3257 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 2017-10-01 04:52:51.000000,38, 24516 7474 7473 1299 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 2017-10-01 04:54:24.000000,38, 24516 1221 4637 1239 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 2017-09-29 20:34:33.000000,38, 3277 39710 8359 3356 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:09.000000,38, 38726 9957 15412 2914 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-30 07:42:12.000000,37, 18106 4657 3356 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:38.000000,37, 18106 4657 3491 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:21.000000,37, 18106 4657 2914 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:52:44.000000,37, 34288 3257 12956 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:29.000000,37, 34288 15576 174 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-30 07:42:17.000000,37, 34288 13030 1299 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:02.000000,37, 34288 9002 2914 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-29 20:34:12.000000,37, 34288 15576 6453 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:59.000000,37, 11686 19151 174 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:10.000000,37, 8492 20764 174 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-29 18:16:12.000000,37, 8492 12389 3257 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-30 07:43:34.000000,37, 8492 12389 6453 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:52.000000,37, 8492 12389 3491 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-30 23:48:35.000000,37, 8492 9002 3356 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:53:48.000000,37, 8492 9002 2914 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:39.000000,37, 8492 12389 174 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-30 23:48:36.000000,37, 8492 20764 3356 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:33.000000,37, 38883 4826 174 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:52:58.000000,37, 38883 2764 7545 6939 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-09-30 23:48:37.000000,37, 7500 2497 2914 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 2017-10-01 04:54:17.000000,37, 7500 2516 701 12956 52873 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 53004 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 264548 On 01.10.2017 14:29, Tim Evens wrote: > The outliers are >100. Based on several peering points, <= 60 should be > fine. See attached CSV file that shows the top 120 distinct AS Paths > seen for the past month. Looks like 55644 likes to prepend a lot which > is pushing the length above 50. > > --Tim > > On 01.10.2017 09:16, marcel.duregards--- via NANOG wrote: > What would be a recommended value for a maximum as-path filter ? 50 ? On the DFZ I've only 11 prefixes longer than 30 as-path, so for safety I would also assume 50 as a max is well enough. Any advice ? Regards, - Marcel On 01.10.2017 00:29, William Herrin wrote: To the chucklehead who started announcing a 2200+ byte AS path yesterday around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga that's present in all versions released in the last decade. Your announcement causes routers based on Quagga to send a malformed update to their neighbors, collapsing the entire BGP session. Every 30 seconds or so. For everyone else: please consider filtering BGP announcements with stupidly long AS paths. There's no need nor excuse for them to be present in the DFZ and you could have saved me a painful Saturday. Cisco: router bgp XXX bgp maxas-limit 50 Juniper: https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 [1] [1] Quagga: ip as-path access-list maxas-limit50 deny ^([{},0-9]+ ){50} ip as-path access-list maxas-limit50 permit .* Regards, Bill Herrin . Links: ------ [1] https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 [2] Links: ------ [1] https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 [2] https://kb.juniper.net/InfoCenter/index?page=content&amp;id=KB29321 From javier at advancedmachines.us Mon Oct 2 02:28:31 2017 From: javier at advancedmachines.us (Javier J) Date: Sun, 1 Oct 2017 22:28:31 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Message-ID: At this point, I wouldn't trust status.pr and any media reports without verifying information. As far as LibertyPR is concerned my cousin who lives in Carolina, PR told me thieves were stealing fiber optic cable after the storm. I trust the Seon Donelan, FCC, US Military, FEMA reports in that order. There was a report that 33% of cell phone service was reported. That is BS. We know from FCC reports it is still at ~90% out as far as number of operational cell sites. The media here in the states is no better. I have multiple confirmations and am looking for hard proof but the Teamsters Puerto Rico trucking union is refusing to move containers out of the port. Only 20% of truckers showed up for work. Perhaps someone who works at Crowley can give us more concrete info but if you can't even move supplies out of the port, how the heck are you supposed to replace wires/fiber/fuel etc? Here is a CNBC report: https://www.youtube.com/watch?v=f4Z01o4tBlI - Javier On Sat, Sep 30, 2017 at 4:39 PM, Sean Donelan wrote: > On Sat, 30 Sep 2017, Sean Donelan wrote: > >> The first public statement I've seen from LibertyPR was yesterday. Their >> network was completely down. They've restored some of their main >> infrastructure, i.e. cable headends and main fiber connections. >> 100% of subscribers are out of service. >> >> I've seen pictures on twitter of LibertyPR crews fixing cables and poles >> on the island. >> > > Liberty cable Puerto Rico has put out a press release today. > > LibertyPR is opening one public WiFi hot spot in Bahia Urbana in San Juan > from 3pm to 7pm Saturday, and 8am to 7pm daily starting Sunday. > > Additional hot spots will be announced by LibertyPR via press release in > the future. > > I guess this is a sign LibertyPR's public relations office is back in > operation. > From jason at thebaughers.com Mon Oct 2 03:09:55 2017 From: jason at thebaughers.com (Jason Baugher) Date: Sun, 1 Oct 2017 22:09:55 -0500 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Message-ID: The more I read about this, the more disturbed I get. On the one hand, we keep hearing that the trucks aren't moving because roads are impassable. Then I read that government officials are driving from their remote areas to San Juan to ask why no aid is coming, disputing the claims about the roads. We hear that there isn't fuel for the trucks, then a reporter from CNBC disputes that claim as well. The only thing that seems to be a common thread is that there are massive amounts of supplies sitting in San Juan and that they can't get truck drivers to deliver them. Do FEMA and the National Guard have the authority to commandeer the trucks and deliver the containers themselves? The telcom companies aren't going to be able to do much by way of repairs without supplies. On Sun, Oct 1, 2017 at 9:28 PM, Javier J wrote: > At this point, I wouldn't trust status.pr and any media reports without > verifying information. As far as LibertyPR is concerned my cousin who lives > in Carolina, PR told me thieves were stealing fiber optic cable after the > storm. I trust the Seon Donelan, FCC, US Military, FEMA reports in that > order. There was a report that 33% of cell phone service was reported. That > is BS. We know from FCC reports it is still at ~90% out as far as number of > operational cell sites. > > > The media here in the states is no better. I have multiple confirmations > and am looking for hard proof but the Teamsters Puerto Rico trucking union > is refusing to move containers out of the port. Only 20% of truckers showed > up for work. Perhaps someone who works at Crowley can give us more concrete > info but if you can't even move supplies out of the port, how the heck are > you supposed to replace wires/fiber/fuel etc? > > > Here is a CNBC report: https://www.youtube.com/watch?v=f4Z01o4tBlI > > - Javier > > > > > > > > On Sat, Sep 30, 2017 at 4:39 PM, Sean Donelan wrote: > > > On Sat, 30 Sep 2017, Sean Donelan wrote: > > > >> The first public statement I've seen from LibertyPR was yesterday. Their > >> network was completely down. They've restored some of their main > >> infrastructure, i.e. cable headends and main fiber connections. > >> 100% of subscribers are out of service. > >> > >> I've seen pictures on twitter of LibertyPR crews fixing cables and poles > >> on the island. > >> > > > > Liberty cable Puerto Rico has put out a press release today. > > > > LibertyPR is opening one public WiFi hot spot in Bahia Urbana in San Juan > > from 3pm to 7pm Saturday, and 8am to 7pm daily starting Sunday. > > > > Additional hot spots will be announced by LibertyPR via press release in > > the future. > > > > I guess this is a sign LibertyPR's public relations office is back in > > operation. > > > From valdis.kletnieks at vt.edu Mon Oct 2 03:11:46 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 01 Oct 2017 23:11:46 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Message-ID: <176339.1506913906@turing-police.cc.vt.edu> On Sun, 01 Oct 2017 22:28:31 -0400, Javier J said: > The media here in the states is no better. I have multiple confirmations > and am looking for hard proof but the Teamsters Puerto Rico trucking union > is refusing to move containers out of the port. Only 20% of truckers showed > up for work. I haven't seen any reports of a Teamster union refusal. I *have* seen reports that only 10-30% of truck drivers are operational, because of one or more of: 1) Their rigs are stuck behind a highway outage due to washout or downed trees. 2) Their rigs are stuck due to lack of diesel. 3) Rigs are fine, but drivers are stuck due to 1) or 2), or they are too busy trying to save their families/etc to show up to work. I've seen too many reports of "I have been waiting in line for 5 hours for water / gasoline / ice for 's insulin" to get too irate at people who fail to show up for work. From jfmezei_nanog at vaxination.ca Mon Oct 2 04:23:57 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 2 Oct 2017 00:23:57 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Message-ID: On 2017-10-01 23:09, Jason Baugher wrote: > The more I read about this, the more disturbed I get. On the one hand, we > keep hearing that the trucks aren't moving because roads are impassable. Note: media NEVER shows places that are up and running, only shows disaster zones, so one may not get full story by looking at media. Just saw a report on Al Jazeera. 2 sisters trying to get to their father who lives up in the hills. They show some main roads now open, but they get to a "road closed" by a huge landslide (with diggers working to clear it) and have to walk from there, including fording rivers. They eventially get to their dad who is still alive. If there are many cell towers on top of hills where the roads are blocked by landslides, trees, restoration would take a long time before ground crews get to clear those remote roads that might be considered low priority. (and it isn't clear that a helicopter could land there either). > Do FEMA and the National Guard have the authority to commandeer the trucks > and deliver the containers themselves? The telcom companies aren't going to > be able to do much by way of repairs without supplies. Where telecom wiring is underground, it may be easier to light the links back up. But where it is aerial, they would have to wait for the electric utility to fix the poles before stringing new wiring. Not clear how much of aerial plant needs rebuild, or mere fixes. After Sandy, Verizon saw the state of corrosion in lower Manhattan and decided to not fix the copper and string fibre instead. If enough of the copper plant is destroyed, would Claro (or govt) consider stringing FTTH instead of stringing copper? From javier at advancedmachines.us Mon Oct 2 04:32:12 2017 From: javier at advancedmachines.us (Javier J) Date: Mon, 2 Oct 2017 00:32:12 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Message-ID: > Do FEMA and the National Guard have the authority to commandeer the trucks and deliver the containers themselves? I hope they do. There doesn't seem to be a shortage of FEMA, Army, etc personnel on the ground or a shortage of truck drivers in the US willing to help. If 80% of Truck drivers that pick up containers from the ports can't make it, then this needs to be supplemented any way possible to get things moving. On Sun, Oct 1, 2017 at 11:09 PM, Jason Baugher wrote: > The more I read about this, the more disturbed I get. On the one hand, we > keep hearing that the trucks aren't moving because roads are impassable. > Then I read that government officials are driving from their remote areas > to San Juan to ask why no aid is coming, disputing the claims about the > roads. We hear that there isn't fuel for the trucks, then a reporter from > CNBC disputes that claim as well. The only thing that seems to be a common > thread is that there are massive amounts of supplies sitting in San Juan > and that they can't get truck drivers to deliver them. > > Do FEMA and the National Guard have the authority to commandeer the trucks > and deliver the containers themselves? The telcom companies aren't going to > be able to do much by way of repairs without supplies. > > On Sun, Oct 1, 2017 at 9:28 PM, Javier J > wrote: > >> At this point, I wouldn't trust status.pr and any media reports without >> verifying information. As far as LibertyPR is concerned my cousin who >> lives >> in Carolina, PR told me thieves were stealing fiber optic cable after the >> storm. I trust the Seon Donelan, FCC, US Military, FEMA reports in that >> order. There was a report that 33% of cell phone service was reported. >> That >> is BS. We know from FCC reports it is still at ~90% out as far as number >> of >> operational cell sites. >> >> >> The media here in the states is no better. I have multiple confirmations >> and am looking for hard proof but the Teamsters Puerto Rico trucking union >> is refusing to move containers out of the port. Only 20% of truckers >> showed >> up for work. Perhaps someone who works at Crowley can give us more >> concrete >> info but if you can't even move supplies out of the port, how the heck are >> you supposed to replace wires/fiber/fuel etc? >> >> >> Here is a CNBC report: https://www.youtube.com/watch?v=f4Z01o4tBlI >> >> - Javier >> >> >> >> >> >> >> >> On Sat, Sep 30, 2017 at 4:39 PM, Sean Donelan wrote: >> >> > On Sat, 30 Sep 2017, Sean Donelan wrote: >> > >> >> The first public statement I've seen from LibertyPR was yesterday. >> Their >> >> network was completely down. They've restored some of their main >> >> infrastructure, i.e. cable headends and main fiber connections. >> >> 100% of subscribers are out of service. >> >> >> >> I've seen pictures on twitter of LibertyPR crews fixing cables and >> poles >> >> on the island. >> >> >> > >> > Liberty cable Puerto Rico has put out a press release today. >> > >> > LibertyPR is opening one public WiFi hot spot in Bahia Urbana in San >> Juan >> > from 3pm to 7pm Saturday, and 8am to 7pm daily starting Sunday. >> > >> > Additional hot spots will be announced by LibertyPR via press release in >> > the future. >> > >> > I guess this is a sign LibertyPR's public relations office is back in >> > operation. >> > >> > > From jfmezei_nanog at vaxination.ca Mon Oct 2 04:56:56 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 2 Oct 2017 00:56:56 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Message-ID: <13feec4f-dfe8-595e-d2e8-eb90e50c20be@vaxination.ca> On 2017-10-02 00:32, Javier J wrote: > I hope they do. There doesn't seem to be a shortage of FEMA, Army, etc > personnel on the ground or a shortage of truck drivers in the US willing to > help. If 80% of Truck drivers that pick up containers from the ports can't > make it, then this needs to be supplemented any way possible to get things > moving. When disaster is in focused area (Like Houston), truck drivers can easily return to functional cities after delivering goods to the diaster zone (so not a strain on food/lodging in diaster zone). If you bring truck drivers (and telecom, electrical etc) workiers into Puerto Rico, they can't go home every night, so become a strain on shelter/food resources. And you can't "steal" your local workers if they are busy pickup up their belongings from collapsed homes, waiting in long queues for food and caring for their families. In 1998 Ice Storm, Bombardier in Montréal had full power and got a lot of bad publicity when it threatened to fire employees who didn't show up for work. Seesm like mamnagement lived in areas that had power and didn't realise how life changes when you have no power, queue up for wood provided by city etc. (and that is nothing compared to what people on Puerto Rico are dealing with). From valdis.kletnieks at vt.edu Mon Oct 2 05:38:19 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 02 Oct 2017 01:38:19 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> Message-ID: <184865.1506922699@turing-police.cc.vt.edu> On Sun, 01 Oct 2017 22:09:55 -0500, Jason Baugher said: > The more I read about this, the more disturbed I get. On the one hand, we > keep hearing that the trucks aren't moving because roads are impassable. > Then I read that government officials are driving from their remote areas > to San Juan to ask why no aid is coming, disputing the claims about the > roads. It's quite possible for both to be true. The fact that some government officials are able to make it to San Juan isn't proof that nobody on the island is stuck behind an impassable road. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From brooks at firestormnetworks.net Mon Oct 2 05:55:07 2017 From: brooks at firestormnetworks.net (Brooks Bridges) Date: Sun, 1 Oct 2017 22:55:07 -0700 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: <184865.1506922699@turing-police.cc.vt.edu> References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> <184865.1506922699@turing-police.cc.vt.edu> Message-ID: <0e1de1c3-1232-3fa3-a0be-1e1d33495a6e@firestormnetworks.net> It's also quite possible that many of the roads are perfectly passable by a 5000 to 7500# car however aren't cleared enough or stable enough for a 60,000 to 80,000# tractor-trailer. On 10/1/2017 10:38 PM, valdis.kletnieks at vt.edu wrote: > On Sun, 01 Oct 2017 22:09:55 -0500, Jason Baugher said: >> The more I read about this, the more disturbed I get. On the one hand, we >> keep hearing that the trucks aren't moving because roads are impassable. >> Then I read that government officials are driving from their remote areas >> to San Juan to ask why no aid is coming, disputing the claims about the >> roads. > It's quite possible for both to be true. The fact that some government > officials are able to make it to San Juan isn't proof that nobody on the > island is stuck behind an impassable road. From web at typo.org Mon Oct 2 06:58:29 2017 From: web at typo.org (Wayne Bouchard) Date: Sun, 1 Oct 2017 23:58:29 -0700 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: <13feec4f-dfe8-595e-d2e8-eb90e50c20be@vaxination.ca> References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> <13feec4f-dfe8-595e-d2e8-eb90e50c20be@vaxination.ca> Message-ID: <20171002065829.GA6938@spider.typo.org> Well, that's why recovery efforts in broad scale events like this have to go from a central point to pushing a perimiter farther and farther out. Create a habital, functional zone where workers can return to both to organize and recouperate and then go back out and push farther afield. First restoring main arteries (whether that is in the form of roads, electrical dstribution, communications, water, or sewer) and then branch out from there. All of that takes time. It does no good, afterall, to repair the services in a neighborhood if the feeds into that neighborhood aren't going to be functional for weeks. And always remember that the first duty is to life and limb. The rest is of far less importance until that situation has been stabilized. On Mon, Oct 02, 2017 at 12:56:56AM -0400, Jean-Francois Mezei wrote: > On 2017-10-02 00:32, Javier J wrote: > > > I hope they do. There doesn't seem to be a shortage of FEMA, Army, etc > > personnel on the ground or a shortage of truck drivers in the US willing to > > help. If 80% of Truck drivers that pick up containers from the ports can't > > make it, then this needs to be supplemented any way possible to get things > > moving. > > > When disaster is in focused area (Like Houston), truck drivers can > easily return to functional cities after delivering goods to the diaster > zone (so not a strain on food/lodging in diaster zone). > > If you bring truck drivers (and telecom, electrical etc) workiers into > Puerto Rico, they can't go home every night, so become a strain on > shelter/food resources. > > And you can't "steal" your local workers if they are busy pickup up > their belongings from collapsed homes, waiting in long queues for food > and caring for their families. > > In 1998 Ice Storm, Bombardier in Montr??al had full power and got a lot > of bad publicity when it threatened to fire employees who didn't show up > for work. Seesm like mamnagement lived in areas that had power and > didn't realise how life changes when you have no power, queue up for > wood provided by city etc. (and that is nothing compared to what people > on Puerto Rico are dealing with). --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From baldur.norddahl at gmail.com Mon Oct 2 07:08:48 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 2 Oct 2017 09:08:48 +0200 Subject: AS PATH limits In-Reply-To: References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> <250E7C00-8917-46AA-8581-C74933BE75B0@fusix.nl> <20170930164726.GY17040@sizone.org> Message-ID: Den 2. okt. 2017 00.44 skrev "Randy Bush" : looks to me as if 262206 is trying a silly tactic to down-pref inbound from cogent. as cogent probably prefers customers to peers, it may not be working as 262206 expected, so they keep pounding with the same hammer hoping for a miracle. cogent accepts it as they are being paid to do so; normal practice. perhaps our ire should be directed at 262206, not cogent? has anyone tried to contact them? randy It is amazing how well the DFZ works given half the participants (*) have no clue how. If that is what they want, all they need is to split that /23 into two /24 and only announce that on their other transit. (*) I should probably include myself in that half. Regards Baldur From jk at ip-clear.de Mon Oct 2 07:53:59 2017 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Mon, 02 Oct 2017 09:53:59 +0200 Subject: AS PATH limits In-Reply-To: <20170930.170942.74741203.sthaug@nethelp.no> References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> Message-ID: Its also happily announced onwards, e.g. by Telia: Oct 2 07:25:09:E:BGP: From Peer ... received Long AS_PATH= AS_SEQ(2) 1299 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 ... attribute length (567) More than configured MAXAS-LIMIT 64 On 30 Sep 2017, at 17:09, sthaug at nethelp.no wrote: >> If you're on cogent, since 22:30 UTC yesterday or so this has been >> happening >> (or happened). > > Still happening here. I count 562 prepends (563 * 262197) in the > advertisement we receive from Cogent. I see no good reason why we > should accept that many prepends. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jfmezei_nanog at vaxination.ca Mon Oct 2 08:15:44 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 2 Oct 2017 04:15:44 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: <20171002065829.GA6938@spider.typo.org> References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> <13feec4f-dfe8-595e-d2e8-eb90e50c20be@vaxination.ca> <20171002065829.GA6938@spider.typo.org> Message-ID: <4f045474-02a8-199c-e779-01e4aa4a49fd@vaxination.ca> On 2017-10-02 02:58, Wayne Bouchard wrote: > Well, that's why recovery efforts in broad scale events like this have > to go from a central point to pushing a perimiter farther and farther > out. Create a habital, functional zone where workers can return to > both to organize and recouperate and then go back out and push farther > afield. Logic yes. But... I have read stories of sick people in shelters dying because of lack of electricity, lack of O2. Stories of FEMA sending water/food for only half of population of a village. This is where telecom plays a role. If the shelter had comms, it could have told mayor "we need generator, we need 5 tabks of O2 for sick people". Mayor could have sent request to FEMA ASAP. My **guess** is that by the time FEMA got the requests, it was too late and people died. In hindsight, every village should have been given a sat-phone BEFORE the hurricane, Ajit Pai complained about iPhone not having FM radio. But it is more important for reverse communication from villages to headquarters/FEMA to be able to transmit urgent needs, status reports, how much food/water needed etc. I suspect that if such comms had happened right off the bat, they would have known that waiting for roads to be cleared wasn't sufficient and taken a different philosophy for immediate help. I think that disaster planners have made wrong assumptions about cellular and terrestrial communications being robust enough to survive cyclones. From math at sizone.org Mon Oct 2 13:33:01 2017 From: math at sizone.org (Ken Chase) Date: Mon, 2 Oct 2017 09:33:01 -0400 Subject: AS PATH limits In-Reply-To: References: <20170930144134.GU17040@sizone.org> <20170930.170942.74741203.sthaug@nethelp.no> Message-ID: <20171002133301.GS17040@sizone.org> Got this reply from cogent: "We have isolated a BGP Routing discrepancy on the Backbone. That routing has been removed from the Network." So apparently they agree they shouldn't just accept this bogosity. Good on em. /kc -- Ken Chase - math at sizone.org Guelph Canada From jcurran at arin.net Mon Oct 2 16:08:28 2017 From: jcurran at arin.net (John Curran) Date: Mon, 2 Oct 2017 16:08:28 +0000 Subject: Which one(s) of SWIP, RWhois, RDAP? (Fwd: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information) References: <381c089a-e807-f684-f1a8-0b47e6982846@arin.net> Message-ID: <5DFC7344-0676-486B-A77B-5605BA3D37A7@arin.net> NANOGers! Apologies (as some of you have already seen this) but it has more relevance to network operations than most IP number policy matters, so out of avoidance of any doubt, I call this to your attention. ARIN has opened a community consultation on the question of which methods for reporting network sub-delegations should be supported by ARIN. If you have views on this matter, please read the attached and take the time to comment on the arin-consult mailing list (which is the mailing list which ARIN uses for discussion of community suggestions & consultations and is open to the public.) Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information Date: 2 October 2017 at 8:19:36 AM PDT To: > ARIN was previously requested via the ARIN Consultation and Suggestion Process (ACSP) to open a consultation to generate discussion about the possibility of sun-setting RWhois support by the ARIN organization. ARIN's initial response to the ACSP indicated we would open a consultation following the completion of the Registration Data Access Protocol (RDAP) specification inside the IETF processes. This work has been completed and the RFC has been published. ARIN took the additional step of implementing RDAP inside its own directory services offering with referral support to the other Regional Internet Registries (RIRs). With this work complete, we are following through with the formalized request to open a consultation on this topic. https://www.arin.net/participate/acsp/suggestions/2013-22.html In accordance with ARIN's Number Resource Policy Manual (NRPM), Organizations are required to report certain types of customer network sub-delegation information (reassignments and reallocations) to ARIN. Currently there are two reporting methods available. Both are delineated in the NRPM and supported by ARIN's production services. There is also a third possible method of reporting sub-delegation information that could be made available, but is not yet offered. Method 1: SWIP (currently available): The reporting of sub-delegation information using ARIN's database. This can be done either by submitting a SWIP template, interfacing with ARIN's RESTful API, or by creating a sub-delegation inside ARIN Online using ARIN's SWIP-EZ functionality. https://www.arin.net/resources/request/reassignments.html Method 2: RWhois (currently available): The reporting of sub-delegation information on your own hosted and operated RWhois server with referral link information provided in ARIN Whois as part of your own organization's Whois records. In order for a user of ARIN's directory services to view sub-delegation information hosted by an RWhois server, they would have to submit a separate query to that RWhois server, and are not referred in an automated fashion. https://www.arin.net/resources/request/reassignments_rwhois.html Method 3: RDAP: The five RIRs currently use RDAP for referrals to each other's Whois data. Although the specification language of the RDAP could allow it to be used as a third method for the reporting of sub-delegation information to ARIN, it is not currently offered as an option. In order to make this option available, associated registry software would need to be created. This possible method would allow users of ARIN's directory services to view sub-delegation information available on customer hosted RDAP servers in an automated fashion. This RDAP method may also be viewed as redundant to RWhois. https://tools.ietf.org/html/rfc7482 https://www.arin.net/resources/rdap.html Options Going Forward ARIN expects to continue offering Method 1 (SWIP) into the foreseeable future. As previously described, we are acting on a formal suggestion to consult with the community about the future of RWhois support, and also have potential options with RDAP. * Question (general): Of the three sub-delegation reporting methods listed (SWIP, RWhois, RDAP), which should ARIN support in the future? * Question (SWIP/RESTful API specific): The existing RESTful API allows users to report (SWIP) one sub-delegation at a time to be added to ARIN Whois. Should ARIN add bulk-upload features to the RESTful API? * Question (RWhois specific): As noted, RWhois servers are not referred to in an automated fashion when users query ARIN Whois. Should ARIN automate referrals to RWhois servers from ARIN's Whois service? * Question (RDAP specific): If ARIN was to allow the reporting of network sub-delegation information using RDAP, associated enabling software would be required. Should ARIN enable this method by creating an RDAP software suite that would allow ARIN registrants to run RDAP service locally? The feedback you provide during this consultation will help inform decisions about software tools and support for the reporting of network sub-delegation information to ARIN in the future. Thank you for your participation in the ARIN Consultation and Suggestion Process. Discussion on arin-consult at arin.net will close on 27 October 2017. If you have any questions, please contact us at info at arin.net. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From tim at snas.io Mon Oct 2 17:31:53 2017 From: tim at snas.io (Tim Evens) Date: Mon, 02 Oct 2017 10:31:53 -0700 Subject: Long BGP AS paths In-Reply-To: References: <59D114C9.8010100@yahoo.fr> Message-ID: Yikes, my bad. In the CSV file it didn't seem so large. I setup a dashboard where you can browse the longest as paths for the selected time period. check out demo-rv.snas.io:3000/dashboard/db/top-as-paths?orgId=2 [3]. Change the time range to see those longer paths. They are no longer current in the last hour since cogent filtered them. --Tim On 01.10.2017 14:29, Tim Evens wrote: > The outliers are >100. Based on several peering points, <= 60 should be > fine. See attached CSV file that shows the top 120 distinct AS Paths > seen for the past month. Looks like 55644 likes to prepend a lot which > is pushing the length above 50. > > --Tim > > On 01.10.2017 09:16, marcel.duregards--- via NANOG wrote: > What would be a recommended value for a maximum as-path filter ? 50 ? On the DFZ I've only 11 prefixes longer than 30 as-path, so for safety I would also assume 50 as a max is well enough. Any advice ? Regards, - Marcel On 01.10.2017 00:29, William Herrin wrote: To the chucklehead who started announcing a 2200+ byte AS path yesterday around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga that's present in all versions released in the last decade. Your announcement causes routers based on Quagga to send a malformed update to their neighbors, collapsing the entire BGP session. Every 30 seconds or so. For everyone else: please consider filtering BGP announcements with stupidly long AS paths. There's no need nor excuse for them to be present in the DFZ and you could have saved me a painful Saturday. Cisco: router bgp XXX bgp maxas-limit 50 Juniper: https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 [1] [1] Quagga: ip as-path access-list maxas-limit50 deny ^([{},0-9]+ ){50} ip as-path access-list maxas-limit50 permit .* Regards, Bill Herrin . Links: ------ [1] https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 [2] Links: ------ [1] https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 [2] https://kb.juniper.net/InfoCenter/index?page=content&amp;id=KB29321 [3] demo-rv.snas.io:3000/dashboard/db/top-as-paths?orgId=2 From sean at donelan.com Mon Oct 2 17:43:12 2017 From: sean at donelan.com (Sean Donelan) Date: Mon, 2 Oct 2017 13:43:12 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: <176339.1506913906@turing-police.cc.vt.edu> References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> <176339.1506913906@turing-police.cc.vt.edu> Message-ID: On Sun, 1 Oct 2017, valdis.kletnieks at vt.edu wrote: > I haven't seen any reports of a Teamster union refusal. I *have* seen > reports that only 10-30% of truck drivers are operational, because of > one or more of: You're lucky. The bots have been pushing this very hard for several days. I don't know the local context or groups involved. There are at least two different groups 1. Frente Amplio de Camioneros led by Victor Rodriguez There are a couple of videos of interviews with Mr. Rodriguez. Like many people in Puerto Rico, Mr. Rodriguez is very upset. I don't know him well enough to understand if those videos were in the heat of the moment, or accurately reflect what's happening. 2. Union de Tronquistas de Puerto Rico local 901 afiliada I.B.T. led by Alexis Rodriguez The AFL-CIO teamsters put out a statement today: https://teamster.org/news/2017/10/teamsters-denounce-false-reports-work-stoppage-union-drivers-puerto-rico Some of the re-posts are using a partial quote from Colonel Michael A. Valle, responsible for military logistics in Puerto Rico, that only 20% of the drivers are showing up for work. What the re-posts omitted is the rest of Col. Valle's quote: “There should be zero blame on the drivers. They can’t get to work, the infrastructure is destroyed, they can’t get fuel themselves, and they can’t call us for help because there’s no communication. The will of the people of Puerto Rico is off the charts. The truck drivers have families to take care of, many of them have no food or water. They have to take care of their family’s needs before they go off to work, and once they do go, they can’t call home.” http://www.huffingtonpost.com/entry/us-military-on-puerto-rico-the-problem-is-distribution_us_59ce5906e4b0f3c468060dee In a disaster situation, even simple problems become much more complicated. Just as important during a disaster, don't attribute to malice what could be a misunderstanding or communication problem. People in the disaster zone are under a lot of stress. From tom at cloudflare.com Mon Oct 2 18:21:10 2017 From: tom at cloudflare.com (Tom Paseka) Date: Mon, 2 Oct 2017 11:21:10 -0700 Subject: isp/cdn caching In-Reply-To: <1376887C-D0FC-403D-819C-BBA1D155B0E7@marcoslater.com> References: <001a01d3386d$fcd710a0$f68531e0$@gvtc.com> <4f33d5950a5d4c27ada387560e115c44@DASMAIL01.corp.cyta> <1376887C-D0FC-403D-819C-BBA1D155B0E7@marcoslater.com> Message-ID: Hi, Cloudflare does deploy caches, however we usually look to do so in unique locations, ie. where an ISPs network isn't already in reach of one of our existing deployments/peering points. You can email peering at cloudflare.com directly if seeking this. -Tom On Fri, Sep 29, 2017 at 7:22 AM, Marco Slater wrote: > Do they publicly have any more info on this? > > I thought CloudFlare didn’t consider doing that because of their vast > coverage and peering arrangements provided by their PoPs. > > Regards, > Marco Slater > > > On 29 Sep 2017, at 14:38, < > michalis.bersimis at hq.cyta.gr> wrote: > > > > I think that Cloudflare has a caching solution, but I think they have > strict requirements towards the isp in order to install them on their > premises. > > > > Best Regards, > > > > Michalis Bersimis > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould > > Sent: Thursday, September 28, 2017 6:25 PM > > To: Nanog at nanog.org > > Subject: isp/cdn caching > > > > Hi, I've been aware of a few caching providers for a few years now, but > I'm learning of others as time goes on. which makes me curious if there are > more springing up and gaining popularity. I'm speaking of ISP-type caching > whereas the cache provider sends hardware servers and perhaps a switch to > the local ISP to install locally in their network. Can someone please send > a simple list of what they know is the current players in this ISP Caching > space? I'll list the ones I know about and you please let me know of > others. This seems to be an evolving/growing thing and I'm curious of > where we are today for significant providers and possibly up-and-coming > ones that I should know about. (amazon prime has my wondering also.) > > > > > > > > Google (GGC) > > > > Netflix (OCA) > > > > Akamai (AANP) > > > > Facebook (FNA) > > > > Apple (I heard this isn't isp-located like the others, but unsure) > > > > ? others ? > > > > ? others ? > > > > ? others ? > > > > > > > > -Aaron Gould > > > > From nanog at ics-il.net Mon Oct 2 18:49:11 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 2 Oct 2017 13:49:11 -0500 (CDT) Subject: isp/cdn caching In-Reply-To: References: <001a01d3386d$fcd710a0$f68531e0$@gvtc.com> <4f33d5950a5d4c27ada387560e115c44@DASMAIL01.corp.cyta> <1376887C-D0FC-403D-819C-BBA1D155B0E7@marcoslater.com> Message-ID: <1165541554.1554.1506970147563.JavaMail.mhammett@ThunderFuck> *nods* I'm obviously a bit biased, but I have some reasoning behind it. Also, this is excluding large scale networks like Comcast, AT&T, Charter, etc. that do have the scale to have on-net solutions. It's also excluding remote locations where there may not be another node for hundreds or thousands of miles (Alaska, Hawaii, Caribbean, etc.) There are some CDNs that are pushing out on-net boxes and PNIs to networks with relatively low usage. We've had networks that were in the process of joining the IX get approached by one of the CDNs for a box right on their network. That network had under 1G of usage (IIRC) and was joining an IX where the CDN was already present. The network declined the box because they didn't want something else to manage and would already get the service anyway once on the IX. Also, from my understanding of multiple CDNs (nothing really proprietary, just whatever's been made public) is that different nodes have different content. The more traffic a node gets, the more likely they are to have the content the end user seeks. Some CDNs also have different platforms on different boxes. If an ISP has one box, they may not even have access to all of the platforms that would be available in a several box deployment. In these cases, an IX makes more sense. We've also had CDNs go the PNI route to a network. Sure, a PNI beats an IX in that it cuts out a middle man (fiscally and point of failure). However, if the networks wouldn't use a substantial portion of the IX port in the first place, it's an extra cost that small networks may not have room for or have to choose between a PNI and an IX. Per the last message, Cloudflare seems to have a similar philosophy. Join existing infrastructure where it makes sense, deploy additional nodes otherwise. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tom Paseka via NANOG" To: "Marco Slater" Cc: "NANOG list" Sent: Monday, October 2, 2017 1:21:10 PM Subject: Re: isp/cdn caching Hi, Cloudflare does deploy caches, however we usually look to do so in unique locations, ie. where an ISPs network isn't already in reach of one of our existing deployments/peering points. You can email peering at cloudflare.com directly if seeking this. -Tom On Fri, Sep 29, 2017 at 7:22 AM, Marco Slater wrote: > Do they publicly have any more info on this? > > I thought CloudFlare didn’t consider doing that because of their vast > coverage and peering arrangements provided by their PoPs. > > Regards, > Marco Slater > > > On 29 Sep 2017, at 14:38, < > michalis.bersimis at hq.cyta.gr> wrote: > > > > I think that Cloudflare has a caching solution, but I think they have > strict requirements towards the isp in order to install them on their > premises. > > > > Best Regards, > > > > Michalis Bersimis > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould > > Sent: Thursday, September 28, 2017 6:25 PM > > To: Nanog at nanog.org > > Subject: isp/cdn caching > > > > Hi, I've been aware of a few caching providers for a few years now, but > I'm learning of others as time goes on. which makes me curious if there are > more springing up and gaining popularity. I'm speaking of ISP-type caching > whereas the cache provider sends hardware servers and perhaps a switch to > the local ISP to install locally in their network. Can someone please send > a simple list of what they know is the current players in this ISP Caching > space? I'll list the ones I know about and you please let me know of > others. This seems to be an evolving/growing thing and I'm curious of > where we are today for significant providers and possibly up-and-coming > ones that I should know about. (amazon prime has my wondering also.) > > > > > > > > Google (GGC) > > > > Netflix (OCA) > > > > Akamai (AANP) > > > > Facebook (FNA) > > > > Apple (I heard this isn't isp-located like the others, but unsure) > > > > ? others ? > > > > ? others ? > > > > ? others ? > > > > > > > > -Aaron Gould > > > > From Jacques.Latour at cira.ca Mon Oct 2 19:57:25 2017 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Mon, 2 Oct 2017 19:57:25 +0000 Subject: Question about Customer Population by ASN for Canada Message-ID: Hi all! I'm working on our IPv6 and DNSSEC adoption report for Canada and the data I use comes largely from APNIC (https://stats.labs.apnic.net/dnssec/CA) and (https://stats.labs.apnic.net/ipv6/CA). Labs.APNIC has a pretty cool system to measure this kind of stuff by deploying specially crafted google ads, see "How Big is that Network?" https://labs.apnic.net/?p=526, and APNIC is able to assess the population behind a network based on ad placement distribution. See https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada. The question I have is why does OVH come #6 with an estimated population of 1,480,927 behind its ASN? Remember these are actual placement of ads. Should I count those users as part of my stats? Rank ASN AS Name CC Users (est.) % of country % of Internet Samples 1 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. CA 5,420,034 16.72 0.16 555,718 2 AS577 BACOM - Bell Canada CA 4,474,012 13.8 0.132 458,722 3 AS6327 SHAW - Shaw Communications Inc. CA 3,708,414 11.44 0.109 380,225 4 AS852 ASN852 - TELUS Communications Inc. CA 2,914,405 8.99 0.086 298,815 5 AS5769 VIDEOTRON - Videotron Telecom Ltee CA 2,189,946 6.76 0.065 224,536 6 AS16276 OVH CA 1,480,927 4.57 0.044 151,840 7 AS15290 ALLST-15290 - Allstream Corp. CA 1,272,374 3.93 0.038 130,457 8 AS855 CANET-ASN-4 - Bell Aliant Regional Communications, Inc. CA 1,211,485 3.74 0.036 124,214 9 AS7992 COGECOWAVE - Cogeco Cable CA 1,112,002 3.43 0.033 114,014 10 AS5645 TEKSAVVY - TekSavvy Solutions, Inc. CA 967,401 2.98 0.029 99,188 11 AS11260 EASTLINK-HSI - EastLink CA 695,598 2.15 0.021 71,320 12 AS47027 SEASIDE-COMM - Seaside Communications, Inc. CA 425,561 1.31 0.013 43,633 13 AS803 SASKTEL - Saskatchewan Telecommunications CA 392,186 1.21 0.012 40,211 14 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. CA 370,348 1.14 0.011 37,972 Jack From sf at lists.esoteric.ca Mon Oct 2 20:05:23 2017 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Mon, 2 Oct 2017 16:05:23 -0400 Subject: Question about Customer Population by ASN for Canada In-Reply-To: References: Message-ID: <89bfb35b-fe89-98ff-95e9-985c84dd16f6@lists.esoteric.ca> Hi Jack, As OVH is a data centre, I find that extraordinary if eyeballs were the cost. VPN's may be popular but that seems excessive. Probably bots of some sort, scraping the internet. -- Stephen On 2017-10-02 3:57 PM, Jacques Latour wrote: > Hi all! > > I'm working on our IPv6 and DNSSEC adoption report for Canada and the data I use comes largely from APNIC (https://stats.labs.apnic.net/dnssec/CA) and (https://stats.labs.apnic.net/ipv6/CA). > > Labs.APNIC has a pretty cool system to measure this kind of stuff by deploying specially crafted google ads, see "How Big is that Network?" https://labs.apnic.net/?p=526, and APNIC is able to assess the population behind a network based on ad placement distribution. See https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada. > > The question I have is why does OVH come #6 with an estimated population of 1,480,927 behind its ASN? Remember these are actual placement of ads. Should I count those users as part of my stats? > > Rank ASN AS Name CC Users (est.) % of country % of Internet Samples > 1 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. CA 5,420,034 16.72 0.16 555,718 > 2 AS577 BACOM - Bell Canada CA 4,474,012 13.8 0.132 458,722 > 3 AS6327 SHAW - Shaw Communications Inc. CA 3,708,414 11.44 0.109 380,225 > 4 AS852 ASN852 - TELUS Communications Inc. CA 2,914,405 8.99 0.086 298,815 > 5 AS5769 VIDEOTRON - Videotron Telecom Ltee CA 2,189,946 6.76 0.065 224,536 > 6 AS16276 OVH CA 1,480,927 4.57 0.044 151,840 > 7 AS15290 ALLST-15290 - Allstream Corp. CA 1,272,374 3.93 0.038 130,457 > 8 AS855 CANET-ASN-4 - Bell Aliant Regional Communications, Inc. CA 1,211,485 3.74 0.036 124,214 > 9 AS7992 COGECOWAVE - Cogeco Cable CA 1,112,002 3.43 0.033 114,014 > 10 AS5645 TEKSAVVY - TekSavvy Solutions, Inc. CA 967,401 2.98 0.029 99,188 > 11 AS11260 EASTLINK-HSI - EastLink CA 695,598 2.15 0.021 71,320 > 12 AS47027 SEASIDE-COMM - Seaside Communications, Inc. CA 425,561 1.31 0.013 43,633 > 13 AS803 SASKTEL - Saskatchewan Telecommunications CA 392,186 1.21 0.012 40,211 > 14 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. CA 370,348 1.14 0.011 37,972 > > Jack > > > > From edugas at unknowndevice.ca Mon Oct 2 20:06:45 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Mon, 02 Oct 2017 20:06:45 +0000 Subject: Question about Customer Population by ASN for Canada In-Reply-To: <89bfb35b-fe89-98ff-95e9-985c84dd16f6@lists.esoteric.ca> References: <89bfb35b-fe89-98ff-95e9-985c84dd16f6@lists.esoteric.ca> Message-ID: From Grzegorz at Janoszka.pl Mon Oct 2 20:10:30 2017 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Mon, 2 Oct 2017 22:10:30 +0200 Subject: Question about Customer Population by ASN for Canada In-Reply-To: References: Message-ID: On 2017-10-02 21:57, Jacques Latour wrote: > The question I have is why does OVH come #6 with an estimated population of 1,480,927 behind its ASN? Remember these are actual placement of ads. Should I count those users as part of my stats? I would say VPN - OVH has cheap servers and is quite popular in this industry. There are countries where many active users have to use a sort of VPN to access banned sites. So they are users, but rather not from Canada. -- Grzegorz Janoszka From fhr at fhrnet.eu Mon Oct 2 20:15:45 2017 From: fhr at fhrnet.eu (Filip Hruska) Date: Mon, 2 Oct 2017 22:15:45 +0200 Subject: Question about Customer Population by ASN for Canada In-Reply-To: <89bfb35b-fe89-98ff-95e9-985c84dd16f6@lists.esoteric.ca> References: <89bfb35b-fe89-98ff-95e9-985c84dd16f6@lists.esoteric.ca> Message-ID: Hi, There are various reasons that might be causing this: * Lots of VPNs on OVH network * OVH offers "desktop-as-a-service" and from what I understand it's quite popular * OVH is also a home ISP - just in France though; but not sure if/how APNIC separated OVH as an ISP and OVH as a server provider. I think it's all under the same ASN (might be wrong though) * There are some scrapers on the OVH network - definitely not half a million though Best Regards, Filip Hruska Dne 10/2/17 v 22:05 Stephen Fulton napsal(a): > Hi Jack, > > As OVH is a data centre, I find that extraordinary if eyeballs were > the cost.  VPN's may be popular but that seems excessive. Probably > bots of some sort, scraping the internet. > > -- Stephen > > On 2017-10-02 3:57 PM, Jacques Latour wrote: >> Hi all! >> >> I'm working on our IPv6 and DNSSEC adoption report for Canada and the >> data I use comes largely from APNIC >> (https://stats.labs.apnic.net/dnssec/CA) and >> (https://stats.labs.apnic.net/ipv6/CA). >> >> Labs.APNIC has a pretty cool system to measure this kind of stuff by >> deploying specially crafted google ads, see "How Big is that >> Network?"  https://labs.apnic.net/?p=526, and APNIC is able to assess >> the population behind a network based on ad placement distribution. >> See https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada. >> >> The question I have is why does OVH come #6 with an estimated >> population of 1,480,927 behind its ASN? Remember these are actual >> placement of ads.  Should I count those users as part of my stats? >> >> Rank    ASN     AS Name CC      Users (est.)    % of country % of >> Internet   Samples >> 1       AS812   ROGERS-CABLE - Rogers Cable Communications Inc. >> CA 5,420,034       >> 16.72   0.16    555,718 >> 2       AS577   BACOM - Bell Canada >> CA 4,474,012       >> 13.8    0.132   458,722 >> 3       AS6327  SHAW - Shaw Communications Inc. >> CA 3,708,414       >> 11.44   0.109   380,225 >> 4       AS852   ASN852 - TELUS Communications Inc. >> CA 2,914,405       >> 8.99    0.086   298,815 >> 5       AS5769  VIDEOTRON - Videotron Telecom Ltee >> CA 2,189,946       >> 6.76    0.065   224,536 >> 6       AS16276 OVH >> CA 1,480,927       >> 4.57    0.044   151,840 >> 7       AS15290 ALLST-15290 - Allstream Corp. >> CA 1,272,374       >> 3.93    0.038   130,457 >> 8       AS855   CANET-ASN-4 - Bell Aliant Regional Communications, >> Inc. CA >> 1,211,485       3.74    0.036   124,214 >> 9       AS7992  COGECOWAVE - Cogeco Cable >> CA 1,112,002       >> 3.43    0.033   114,014 >> 10      AS5645  TEKSAVVY - TekSavvy Solutions, Inc. >> CA 967,401 2.98    >> 0.029   99,188 >> 11      AS11260 EASTLINK-HSI - EastLink >> CA 695,598 2.15    >> 0.021   71,320 >> 12      AS47027 SEASIDE-COMM - Seaside Communications, Inc. >> CA 425,561 1.31    >> 0.013   43,633 >> 13      AS803   SASKTEL - Saskatchewan Telecommunications >> CA 392,186 1.21    >> 0.012   40,211 >> 14      AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. >> CA 370,348 1.14    >> 0.011   37,972 >> >> Jack >> >> >> >> > -- Best Regards, Filip Hruska Linux System Administrator From edugas at unknowndevice.ca Mon Oct 2 20:17:50 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Mon, 2 Oct 2017 16:17:50 -0400 Subject: Question about Customer Population by ASN for Canada In-Reply-To: References: <89bfb35b-fe89-98ff-95e9-985c84dd16f6@lists.esoteric.ca> Message-ID: For some reason my previous email was empty. What I wrote: "Some of these numbers are largely inflated... e.g. Teksavvy at 937,855 estimated users. How can they have 937,855 users if they "only" have 686,848 IPv4 (https://bgp.he.net/AS5645)? Also, Allstream/Zayo AS15290 has a lot of IPs but it's mostly corps/govs. So it's a mix of inflated and false positives. Eric" Eric On October 2, 2017 at 4:15:53 PM, Filip Hruska (fhr at fhrnet.eu) wrote: Hi, There are various reasons that might be causing this: * Lots of VPNs on OVH network * OVH offers "desktop-as-a-service" and from what I understand it's quite popular * OVH is also a home ISP - just in France though; but not sure if/how APNIC separated OVH as an ISP and OVH as a server provider. I think it's all under the same ASN (might be wrong though) * There are some scrapers on the OVH network - definitely not half a million though Best Regards, Filip Hruska Dne 10/2/17 v 22:05 Stephen Fulton napsal(a): > Hi Jack, > > As OVH is a data centre, I find that extraordinary if eyeballs were > the cost. VPN's may be popular but that seems excessive. Probably > bots of some sort, scraping the internet. > > -- Stephen > > On 2017-10-02 3:57 PM, Jacques Latour wrote: >> Hi all! >> >> I'm working on our IPv6 and DNSSEC adoption report for Canada and the >> data I use comes largely from APNIC >> (https://stats.labs.apnic.net/dnssec/CA) and >> (https://stats.labs.apnic.net/ipv6/CA). >> >> Labs.APNIC has a pretty cool system to measure this kind of stuff by >> deploying specially crafted google ads, see "How Big is that >> Network?" https://labs.apnic.net/?p=526, and APNIC is able to assess >> the population behind a network based on ad placement distribution. >> See https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada. >> >> The question I have is why does OVH come #6 with an estimated >> population of 1,480,927 behind its ASN? Remember these are actual >> placement of ads. Should I count those users as part of my stats? >> >> Rank ASN AS Name CC Users (est.) % of country % of >> Internet Samples >> 1 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. >> CA 5,420,034 >> 16.72 0.16 555,718 >> 2 AS577 BACOM - Bell Canada >> CA 4,474,012 >> 13.8 0.132 458,722 >> 3 AS6327 SHAW - Shaw Communications Inc. >> CA 3,708,414 >> 11.44 0.109 380,225 >> 4 AS852 ASN852 - TELUS Communications Inc. >> CA 2,914,405 >> 8.99 0.086 298,815 >> 5 AS5769 VIDEOTRON - Videotron Telecom Ltee >> CA 2,189,946 >> 6.76 0.065 224,536 >> 6 AS16276 OVH >> CA 1,480,927 >> 4.57 0.044 151,840 >> 7 AS15290 ALLST-15290 - Allstream Corp. >> CA 1,272,374 >> 3.93 0.038 130,457 >> 8 AS855 CANET-ASN-4 - Bell Aliant Regional Communications, >> Inc. CA >> 1,211,485 3.74 0.036 124,214 >> 9 AS7992 COGECOWAVE - Cogeco Cable >> CA 1,112,002 >> 3.43 0.033 114,014 >> 10 AS5645 TEKSAVVY - TekSavvy Solutions, Inc. >> CA 967,401 2.98 >> 0.029 99,188 >> 11 AS11260 EASTLINK-HSI - EastLink >> CA 695,598 2.15 >> 0.021 71,320 >> 12 AS47027 SEASIDE-COMM - Seaside Communications, Inc. >> CA 425,561 1.31 >> 0.013 43,633 >> 13 AS803 SASKTEL - Saskatchewan Telecommunications >> CA 392,186 1.21 >> 0.012 40,211 >> 14 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. >> CA 370,348 1.14 >> 0.011 37,972 >> >> Jack >> >> >> >> > -- Best Regards, Filip Hruska Linux System Administrator From chk at pobox.com Mon Oct 2 20:33:50 2017 From: chk at pobox.com (Harald Koch) Date: Mon, 2 Oct 2017 16:33:50 -0400 Subject: Question about Customer Population by ASN for Canada In-Reply-To: References: <89bfb35b-fe89-98ff-95e9-985c84dd16f6@lists.esoteric.ca> Message-ID: On 2 October 2017 at 16:17, Eric Dugas wrote: > > > e.g. Teksavvy at 937,855 estimated users. How can they have 937,855 users > if they "only" have 686,848 IPv4 (https://bgp.he.net/AS5645)? > I have one IPv4 and five users in my household... -- Harald (teksavvy customer) From Jacques.Latour at cira.ca Mon Oct 2 20:42:39 2017 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Mon, 2 Oct 2017 20:42:39 +0000 Subject: Question about Customer Population by ASN for Canada In-Reply-To: References: <89bfb35b-fe89-98ff-95e9-985c84dd16f6@lists.esoteric.ca> Message-ID: Right, forgot to mention, it's population, not IP addresses, the average is 2.2 person / household in Canada I believe. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Harald > Koch > Sent: October 2, 2017 4:34 PM > To: NANOG list > Subject: Re: Question about Customer Population by ASN for Canada > > On 2 October 2017 at 16:17, Eric Dugas > wrote: > > > > > > e.g. Teksavvy at 937,855 estimated users. How can they have 937,855 > > users if they "only" have 686,848 IPv4 (https://bgp.he.net/AS5645)? > > > > I have one IPv4 and five users in my household... > > -- > Harald > (teksavvy customer) From sean at donelan.com Mon Oct 2 20:44:28 2017 From: sean at donelan.com (Sean Donelan) Date: Mon, 2 Oct 2017 16:44:28 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <6A0A3AB3-5380-4FD4-8BA0-D6376314BCEE@isprime.com> <176339.1506913906@turing-police.cc.vt.edu> Message-ID: On Mon, 2 Oct 2017, Sean Donelan wrote: > On Sun, 1 Oct 2017, valdis.kletnieks at vt.edu wrote: >> I haven't seen any reports of a Teamster union refusal. I *have* seen >> reports that only 10-30% of truck drivers are operational, because of >> one or more of: > > You're lucky. The bots have been pushing this very hard for several days. I > don't know the local context or groups involved. There are at least two > different groups Snopes has published an article debunking this. But bots are still pushing it. Did Puerto Rico's Teamsters Union Go on Strike During Hurricane Maria Relief Efforts? Reports that truck drivers are on strike in Puerto Rico are false -- Teamsters have asked mainland truckers to distribute supplies in the U.S. territory. http://www.snopes.com/puerto-rico-teamsters/ From gih at apnic.net Mon Oct 2 21:53:59 2017 From: gih at apnic.net (Geoff Huston) Date: Tue, 3 Oct 2017 08:53:59 +1100 Subject: Question about Customer Population by ASN for Canada In-Reply-To: References: Message-ID: > On 3 Oct 2017, at 6:57 am, Jacques Latour wrote: > > Hi all! > > I'm working on our IPv6 and DNSSEC adoption report for Canada and the data I use comes largely from APNIC (https://stats.labs.apnic.net/dnssec/CA) and (https://stats.labs.apnic.net/ipv6/CA). > > Labs.APNIC has a pretty cool system to measure this kind of stuff by deploying specially crafted google ads, see "How Big is that Network?" https://labs.apnic.net/?p=526, and APNIC is able to assess the population behind a network based on ad placement distribution. See https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada. > > The question I have is why does OVH come #6 with an estimated population of 1,480,927 behind its ASN? Remember these are actual placement of ads. Should I count those users as part of my stats? > > Rank ASN AS Name CC Users (est.) % of country % of Internet Samples > 1 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. CA 5,420,034 16.72 0.16 555,718 > 2 AS577 BACOM - Bell Canada CA 4,474,012 13.8 0.132 458,722 > 3 AS6327 SHAW - Shaw Communications Inc. CA 3,708,414 11.44 0.109 380,225 > 4 AS852 ASN852 - TELUS Communications Inc. CA 2,914,405 8.99 0.086 298,815 > 5 AS5769 VIDEOTRON - Videotron Telecom Ltee CA 2,189,946 6.76 0.065 224,536 > 6 AS16276 OVH CA 1,480,927 4.57 0.044 151,840 > 7 AS15290 ALLST-15290 - Allstream Corp. CA 1,272,374 3.93 0.038 130,457 > 8 AS855 CANET-ASN-4 - Bell Aliant Regional Communications, Inc. CA 1,211,485 3.74 0.036 124,214 > 9 AS7992 COGECOWAVE - Cogeco Cable CA 1,112,002 3.43 0.033 114,014 > 10 AS5645 TEKSAVVY - TekSavvy Solutions, Inc. CA 967,401 2.98 0.029 99,188 > 11 AS11260 EASTLINK-HSI - EastLink CA 695,598 2.15 0.021 71,320 > 12 AS47027 SEASIDE-COMM - Seaside Communications, Inc. CA 425,561 1.31 0.013 43,633 > 13 AS803 SASKTEL - Saskatchewan Telecommunications CA 392,186 1.21 0.012 40,211 > 14 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. CA 370,348 1.14 0.011 37,972 Let me explain our system in a little more detail. When we serve an ad we note the origin AS of the Ad. Now we assume (probably wrongly but we have no better data) that the ad’s are smeared evenly across the user population of each country. So we assume that the relative weight of ad placement within an AS is proportionate to the relative number of users in that same country. So if AS 131072 receives 50% of the Ads in a country then we assume that AS131072 holds one half of the number of users of the same country. Thats the first piece of data and the first assumption The second assumption is that your government is not lying! That means that whatever stats your government lodged with the ITU-T relating to the number of Internet users in your country we believe. (and we actually use the world population data to update these numbers to represent the estimated user population today.) Mashing the two togeether gives the table per country that you are citing here. So your question is “:Why is Google delivering 4.57% of the ads in Canada into a network ASN that is the ASN registered against OVH” OVH is an overlay network, but its certainly clear that it is used by a lot of folk and Google appear to find their users to be an attractive target to ad placement. So we get a high placement count of Ads coming from OVH and we geolocate those users to CA. Maybe there is a geolocation issue and IVH should not be CA. Of there really are a lot of eyeballs behind OVH in Canada. regards, Geoff From nharland at gmail.com Mon Oct 2 21:55:51 2017 From: nharland at gmail.com (Nicholas Harland) Date: Mon, 2 Oct 2017 14:55:51 -0700 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <1264907839.2452.1506283758921.JavaMail.mhammett@ThunderFuck> Message-ID: Hi Sean, Thank you for all of your updates. I am just catching up on them because I only recently got back from the virgin islands. I am one of those volunteers working in the USVI. St John specifically. We are building out a wireless network, and had our first hotspot up in Cruz Bay 4 days after Maria, with connectivity to NPS/FEMA/Red Cross/St John Rescue/Fire/Police just a few days after that. If there are technical minded and physically able bodied people would like to join the effort on St John, even just for a 1-2 week rotation, I would be happy to discuss what we need in terms of support and can make all arrangements on the island for housing etc. Getting some relief and fresh minds in would be a great help as our team is primarily St John residents who have been on the island through both hurricanes and have had to deal with their own personal situations while also trying to get internet up where it's needed. St John was hit directly by Irma, infrastructure was completely destroyed, but it's a very small island and so the humanitarian situation there is much more stable than Puerto Rico, but many of the resources that were assisting on STJ are now rightfully being diverted to SJU. You could expect to sleep somewhere that has a generator running overnight, have access to refrigeration/freezer (though cannot open fridge during day). Food/water situation is fine there, we have a beach volleyball game on Sundays, more generators are appearing on the island and some businesses are opening. Regards, Nick Harland On Sun, Sep 24, 2017 at 2:13 PM, Sean Donelan wrote: > On Sun, 24 Sep 2017, Mike Hammett wrote: > >> There are a bunch of WISPs waiting to go rebuild, but waiting for the >> clearance to do so. >> > > I'm not sure what clearances they are waiting for. If they are already in > Puerto Rico, self-sufficient, and respect curfews and other emergency > responders, they should be able to start local restoration and recovery > activities. > > Several local ISPs and communication providers have announced open public > WiFi hotspots outside their Puerto Rico offices during non-curfew hours. > I've also seen reports from individuals volunteering on the Virigin Islands > setting up internet access. > > If they are not already on the island, most Puerto Rican airports and > ports are still closed to non-military or relief activities. There is no > U.S. mail or freight service. Only one airport was open for limited > commercial flights. They will need to bring everything neccessary to > support themselves, including food, water, shelter, etc. > > Managing volunteers who want to help is difficult in all disasters. Unless > they have training how to survive and take care of themselves in such a > situation, letting in outside well-meaning volunteers sometimes become > additional people who need to rescue. > > WISPs already on Puerto Rico or U.S. Virigin Islands, with resources for > recovery and restoration of communications; can contact the FCC Operations > Center, (202) 418-1122, FCCOperationCenter at fcc.gov > > http://transition.fcc.gov/Daily_Releases/Daily_Business/2017 > /db0920/DA-17-913A1.pdf > > From gih at apnic.net Mon Oct 2 22:38:20 2017 From: gih at apnic.net (Geoff Huston) Date: Tue, 3 Oct 2017 09:38:20 +1100 Subject: Question about Customer Population by ASN for Canada In-Reply-To: References: <89bfb35b-fe89-98ff-95e9-985c84dd16f6@lists.esoteric.ca> Message-ID: <9E39F4B6-D5A0-4F1E-8A15-C644A48ABFE7@apnic.net> > On 3 Oct 2017, at 7:17 am, Eric Dugas wrote: > > For some reason my previous email was empty. > > What I wrote: > > "Some of these numbers are largely inflated... > > e.g. Teksavvy at 937,855 estimated users. How can they have 937,855 users > if they "only" have 686,848 IPv4 (https://bgp.he.net/AS5645)? > > Also, Allstream/Zayo AS15290 has a lot of IPs but it's mostly corps/govs. > So it's a mix of inflated and false positives. I wish there was better public data we could use here to generate these numbers. But there is a dearth of such numbers that are vaguely current relatively inclusive and not completely stupid. So we use the ad placement mechanism as an indirect pointer to user count. Its very rough, and at best one can say that there are large, medium and small eyeball networks, and to a first order the algorithm appears to identify networks into these three categories. I am not trying to tie in address density here - I’m not even sure that would be wise because, as you well know, NATs hide all kinds of sins and virtues. Geoff From randy at psg.com Mon Oct 2 22:51:51 2017 From: randy at psg.com (Randy Bush) Date: Tue, 03 Oct 2017 07:51:51 +0900 Subject: Question about Customer Population by ASN for Canada In-Reply-To: References: Message-ID: > Labs.APNIC has a pretty cool system to measure this kind of stuff by > deploying specially crafted google ads, see "How Big is that Network?" which should have been titled "how many eyeballs in that network" From javier at advancedmachines.us Tue Oct 3 01:59:11 2017 From: javier at advancedmachines.us (Javier J) Date: Mon, 2 Oct 2017 21:59:11 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: <1264907839.2452.1506283758921.JavaMail.mhammett@ThunderFuck> Message-ID: This is great to hear Nicholas. On Mon, Oct 2, 2017 at 5:55 PM, Nicholas Harland wrote: > Hi Sean, > > Thank you for all of your updates. I am just catching up on them because I > only recently got back from the virgin islands. I am one of those > volunteers working in the USVI. St John specifically. We are building out a > wireless network, and had our first hotspot up in Cruz Bay 4 days after > Maria, with connectivity to NPS/FEMA/Red Cross/St John Rescue/Fire/Police > just a few days after that. > > If there are technical minded and physically able bodied people would like > to join the effort on St John, even just for a 1-2 week rotation, I would > be happy to discuss what we need in terms of support and can make all > arrangements on the island for housing etc. Getting some relief and fresh > minds in would be a great help as our team is primarily St John residents > who have been on the island through both hurricanes and have had to deal > with their own personal situations while also trying to get internet up > where it's needed. > > St John was hit directly by Irma, infrastructure was completely destroyed, > but it's a very small island and so the humanitarian situation there is > much more stable than Puerto Rico, but many of the resources that were > assisting on STJ are now rightfully being diverted to SJU. You could expect > to sleep somewhere that has a generator running overnight, have access to > refrigeration/freezer (though cannot open fridge during day). Food/water > situation is fine there, we have a beach volleyball game on Sundays, more > generators are appearing on the island and some businesses are opening. > > Regards, > > Nick Harland > > > > > On Sun, Sep 24, 2017 at 2:13 PM, Sean Donelan wrote: > > > On Sun, 24 Sep 2017, Mike Hammett wrote: > > > >> There are a bunch of WISPs waiting to go rebuild, but waiting for the > >> clearance to do so. > >> > > > > I'm not sure what clearances they are waiting for. If they are already > in > > Puerto Rico, self-sufficient, and respect curfews and other emergency > > responders, they should be able to start local restoration and recovery > > activities. > > > > Several local ISPs and communication providers have announced open public > > WiFi hotspots outside their Puerto Rico offices during non-curfew hours. > > I've also seen reports from individuals volunteering on the Virigin > Islands > > setting up internet access. > > > > If they are not already on the island, most Puerto Rican airports and > > ports are still closed to non-military or relief activities. There is no > > U.S. mail or freight service. Only one airport was open for limited > > commercial flights. They will need to bring everything neccessary to > > support themselves, including food, water, shelter, etc. > > > > Managing volunteers who want to help is difficult in all disasters. > Unless > > they have training how to survive and take care of themselves in such a > > situation, letting in outside well-meaning volunteers sometimes become > > additional people who need to rescue. > > > > WISPs already on Puerto Rico or U.S. Virigin Islands, with resources for > > recovery and restoration of communications; can contact the FCC > Operations > > Center, (202) 418-1122, FCCOperationCenter at fcc.gov > > > > http://transition.fcc.gov/Daily_Releases/Daily_Business/2017 > > /db0920/DA-17-913A1.pdf > > > > > From markjr at easydns.com Tue Oct 3 16:30:58 2017 From: markjr at easydns.com (Mark Jeftovic) Date: Tue, 03 Oct 2017 12:30:58 -0400 Subject: BGP hijack: 64.68.207.0/24 from as133955 Message-ID: <59D3BB42.9070107@easydns.com> as133955 is broadcasting bogus BGP announcement for our netblock 64.68.207.0/24 It's in China, and we're trying to contact as24155 but they are also in China and we're just emailing their whois record address. If you're nearby and in a position to block/dampen that might be helpful. Thx - mark -- Mark Jeftovic Founder & CEO, easyDNS Technologies Inc. http://www.easyDNS.com From sean at donelan.com Tue Oct 3 17:55:48 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 3 Oct 2017 13:55:48 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: After two weeks it appears the situation is stabilizing (not getting worse) on Puerto Rico and U.S. Virgin Islands. But recovery and logistics still seems very slow in both territories. A reminder, I am focusing on U.S. Territories, but other Caribbean islands are still recovering from Hurricane Irma and Maria. Fatalities Puerto Rico: 16 storm related (last report Sept. 27) Media estimate at least 60 storm related deaths CDC mortatility rate for PR: average 80 deaths per day all causes U.S. Virgin Islands: 5 storm related (last report Oct. 3) 30 deaths from all causes (natural causes, accidents, homicides) Telecommunications Satellite phones Iridium reports over 2,000 non-military satellite phones active, normally less than 10 non-military satellite phones active in Puerto Rico and U.S. Virgin Islands area. Iridium does not release military usage. Landline phones 813,546 landlines (CIA World Factbook) ILEC (Claro) reports all Central Offices have voice, data and long distance working. Estimate 40% of landline subscriber local loops are in service, mostly in metro areas. CLECs - no reports Cable - all cable subscribers currently out of service Wireless mobile phones 3,227,281 (CIA World Factbook) AT&T, Claro and T-Mobile announced extension of "open roaming" agreement between networks. I expect Sprint and Open Mobile will also extend their participation. Because open roaming makes accurate billing impossible, all carriers also announced they are waiving charges in Puerto Rico. Puerto Rico Telecommunications Regulatory Board announced carriers have continued their joint restoration agreement. PRTRB expects 60% restoration of service by end of October, and 100% restoration of service before Christmas. I can not evaluate this forecast, but it seems aggressive; or the level of service will be the bare minimum and capacity will be very congested. Claro reports it has at least one cell site active in 28 of 78 municipalities, covering about 310,000 subscribers. It may not be high-quality service, but its some service. AT&T, Open Mobile, Sprint and T-Mobile have not disclosed how much of their networks are operating. AT&T stated it is carrying 8 million calls and 4 million texts per day. FCC reports 2359 out of 2671 (88%) cell sites on Puerto Rico are out of service. PRTRB reports 1254 out of 1619 (77%) cell sites on Puerto Rico are out of service. I still do not understand the different statistics being reported by FCC and PRTRB or how they calculate their statistics. ROK Mobile and M2Catalyst, mobile metrics platforms, have published estimates of cell tower damage in Puerto Rico Claro: 14% cell sites operating Open Mobile: 8% cell sites operating Extended Network: 7% cell sites operating T-Mobile: 31% cell sites operating CLARO|TELCEL: 6% cell sites operating AT&T: 18% cell sites operating Percentages are affected by the denominators, i.e. share, which wasn't released. But it does show all carriers experienced a lot of damage. http://www.prnewswire.com/news-releases/presently-over-86-of-cell-sites-in-puerto-rico-are-still-not-operating-in-aftermath-of-hurricane-maria-300530074.html American Tower, Crown Castle and SBA, which collectively own many physical towers leased by mobile carriers on Puerto Rico, report little material structural damage to the towers themselves. But there was substantial damage to carrier customer equipment on the towers and lack of electric power at almost all towers. Note: there are twitter photos of at least two collapsed towers, but I don't know those tower owners. U.S. Virgin Islands has almost no change (or getting slightly worse) in number of working cell sites during the last week. Internet Services 647 IP networks out of 1205 are routed from Puerto Rico (RIPE) 66 IP networks out of 70 are routed from U.S. Virgin Islands (RIPE) From clinton at scripty.com Tue Oct 3 23:29:14 2017 From: clinton at scripty.com (Clinton Work) Date: Tue, 03 Oct 2017 17:29:14 -0600 Subject: BGP hijack: 64.68.207.0/24 from as133955 In-Reply-To: <59D3BB42.9070107@easydns.com> References: <59D3BB42.9070107@easydns.com> Message-ID: <1507073354.2436839.1126952192.57706E69@webmail.messagingengine.com> TELUS AS852 has three address blocks hijacked by AS133955 as well. We have not been able to get in contact with AS24155. It looks like they are buying transit from PCCW AS3491 and Taiwan Internet Gateway AS9505. 68.182.255.0/24 74.49.255.0/24 96.1.255.0/24 On Tue, Oct 3, 2017, at 10:30 AM, Mark Jeftovic wrote: > > as133955 is broadcasting bogus BGP announcement for our netblock > 64.68.207.0/24 > > It's in China, and we're trying to contact as24155 but they are also in > China and we're just emailing their whois record address. > > If you're nearby and in a position to block/dampen that might be helpful. > > Thx > > - mark > > -- > Mark Jeftovic > Founder & CEO, easyDNS Technologies Inc. > http://www.easyDNS.com > > From sean at donelan.com Wed Oct 4 01:24:33 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 3 Oct 2017 21:24:33 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: Fatalities Puerto Rico: 34 storm related (last report Oct. 3) Media estimate at least 60 storm related deaths CDC mortatility rate for PR: average 80 deaths per day all causes U.S. Virgin Islands: 5 storm related (last report Oct. 3) 30 deaths from all causes (natural causes, accidents, homicides) Telecommunications Landline phones 813,546 landlines (CIA World Factbook) ILEC (Claro) reports all Central Offices have voice, data and long distance working. Estimate 40% of landline subscriber local loops are in service, mostly in metro areas. CLECs - no reports Cable - Liberty Cable PR is reporting some restoration of service in San Juan, Luquillo, Caguas, Levittown and Mayaguez areas. LibertyPR is also providing free wifi in several public locations: Bahia Urbana in San Juandes, Luquillo offices, and accross from Purto Rico Coliseum in Hato Rey. Wireless mobile phones 3,227,281 (CIA World Factbook) The Puerto Rico Telecommunications Regulary Board announced Electric Energy Authority (AEE) is providing a copy of its schedule of work areas so telecommunication companies can coordinate restoration work in the same areas. Electric restoration is in Bayamon, Toa Baja, Guaynabo and San Juan. The PRTRB announced 15 Cell on Wheels temporary cell sites will be installed in municipalities around the island by the end of October. The PRTRB also confirmed these are supplementary emergency communications, and only provide voice and text service. PRTRB estimates 60% coverage by the end of October and 100% before Christmas. I still believe 100% does not means full capacity, only minimum services; but haven't found an authoritative statement. 365 cell sites of 1619 are operational according to the PRTRB 320 cell sites of 2644 are operational according to the FCC U.S. Virgin Islands 35 cell sites of 106 are operational according to the FCC, essentially unchanged for the last week From jwm at horde.net Tue Oct 3 21:19:12 2017 From: jwm at horde.net (John Morrissey) Date: Tue, 3 Oct 2017 17:19:12 -0400 Subject: Contact at Proofpoint? Message-ID: <20171003211912.unoaqqdvgklf5qk2@boost.horde.net> Anyone have a clueful contact at Proofpoint? One of our e-mail domains is being blackholed by their products, and we're striking out via normal channels. -john From jarenangerbauer at gmail.com Wed Oct 4 15:13:04 2017 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Wed, 4 Oct 2017 11:13:04 -0400 Subject: Contact at Proofpoint? In-Reply-To: <20171003211912.unoaqqdvgklf5qk2@boost.horde.net> References: <20171003211912.unoaqqdvgklf5qk2@boost.horde.net> Message-ID: Replied off list. --Jaren On Tue, Oct 3, 2017 at 5:19 PM, John Morrissey wrote: > Anyone have a clueful contact at Proofpoint? > > One of our e-mail domains is being blackholed by their products, and > we're striking out via normal channels. > > -john > From theodore at ciscodude.net Wed Oct 4 15:29:55 2017 From: theodore at ciscodude.net (Theodore Baschak) Date: Wed, 4 Oct 2017 10:29:55 -0500 Subject: BGP hijack: 64.68.207.0/24 from as133955 In-Reply-To: <1507073354.2436839.1126952192.57706E69@webmail.messagingengine.com> References: <59D3BB42.9070107@easydns.com> <1507073354.2436839.1126952192.57706E69@webmail.messagingengine.com> Message-ID: I noticed when I looked into both of these leaks 3 hours after Clinton's message yesterday that I couldn't see them in any of the looking glasses I was looking in (including the NLNOG looking glass) Looks like things were able to be cleaned up very quickly. Theodore Baschak - AS395089 - Hextet Systems https://bgp.guru/ - https://hextet.net/ http://mbix.ca/ - http://mbnog.ca/ On Tue, Oct 3, 2017 at 6:29 PM, Clinton Work wrote: > TELUS AS852 has three address blocks hijacked by AS133955 as well. We > have not been able to get in contact with AS24155. It looks like they > are buying transit from PCCW AS3491 and Taiwan Internet Gateway AS9505. > > 68.182.255.0/24 > 74.49.255.0/24 > 96.1.255.0/24 > > > On Tue, Oct 3, 2017, at 10:30 AM, Mark Jeftovic wrote: > > > > as133955 is broadcasting bogus BGP announcement for our netblock > > 64.68.207.0/24 > > > > It's in China, and we're trying to contact as24155 but they are also in > > China and we're just emailing their whois record address. > > > > If you're nearby and in a position to block/dampen that might be helpful. > > > > Thx > > > > - mark > > > > -- > > Mark Jeftovic > > Founder & CEO, easyDNS Technologies Inc. > > http://www.easyDNS.com > > > > > From sandy at tislabs.com Wed Oct 4 17:45:41 2017 From: sandy at tislabs.com (Sandra Murphy) Date: Wed, 4 Oct 2017 13:45:41 -0400 Subject: BGP hijack: 64.68.207.0/24 from as133955 In-Reply-To: References: <59D3BB42.9070107@easydns.com> <1507073354.2436839.1126952192.57706E69@webmail.messagingengine.com> Message-ID: > On Oct 4, 2017, at 11:29 AM, Theodore Baschak wrote: > > I noticed when I looked into both of these leaks 3 hours after Clinton's > message yesterday that I couldn't see them in any of the looking glasses I > was looking in (including the NLNOG looking glass) > > Looks like things were able to be cleaned up very quickly. Interesting. bgp.he.net is still reporting AS133955 as the originator of 64.68.207.0/24. I don’t know what their refresh cycle is. And, oh look, bgp.he.net points to an RADB proxy registration for the AS133955 origination. RADB no longer reports that route object. But it must have been there at some point. RADB route: 64.68.207.0/24 descr: Fleg Asia Telecom Ltd Proxy-registered route object origin: AS133955 notify: ipbb-apol at aptg.com.tw mnt-by: MAINT-AS17709 changed: kiayang at aptg.com.tw 20170830 #05:45:57Z source: RADB stat.ripe.net (bless you, RIPE!) shows that 64.68.207.0/24 has been originated by AS133955 off and on for the last month (since the RADB route object’s change date?) in the BGP Update Activity and Routing History graphs. And a huge flurry of activity yesterday. Could I be reading all this wrong? Seems to have been going on for quite a while. —Sandy P.S. The other three prefixes mentioned below show similar results in bgp.he.net, with route objects proxy registered on 9/25, and similar results in stats.ripe.net, with off-and-on announcements, more off than on for these, closely timed with the route object registration. > > > > Theodore Baschak - AS395089 - Hextet Systems > https://bgp.guru/ - https://hextet.net/ > http://mbix.ca/ - http://mbnog.ca/ > > > > > On Tue, Oct 3, 2017 at 6:29 PM, Clinton Work wrote: > >> TELUS AS852 has three address blocks hijacked by AS133955 as well. We >> have not been able to get in contact with AS24155. It looks like they >> are buying transit from PCCW AS3491 and Taiwan Internet Gateway AS9505. >> >> 68.182.255.0/24 >> 74.49.255.0/24 >> 96.1.255.0/24 >> >> >> On Tue, Oct 3, 2017, at 10:30 AM, Mark Jeftovic wrote: >>> >>> as133955 is broadcasting bogus BGP announcement for our netblock >>> 64.68.207.0/24 >>> >>> It's in China, and we're trying to contact as24155 but they are also in >>> China and we're just emailing their whois record address. >>> >>> If you're nearby and in a position to block/dampen that might be helpful. >>> >>> Thx >>> >>> - mark >>> >>> -- >>> Mark Jeftovic >>> Founder & CEO, easyDNS Technologies Inc. >>> http://www.easyDNS.com >>> >>> >> From jwm at horde.net Wed Oct 4 17:30:10 2017 From: jwm at horde.net (John Morrissey) Date: Wed, 4 Oct 2017 13:30:10 -0400 Subject: Contact at Proofpoint? In-Reply-To: <20171003211912.unoaqqdvgklf5qk2@boost.horde.net> References: <20171003211912.unoaqqdvgklf5qk2@boost.horde.net> Message-ID: <20171004173010.lhlh3wispa4ebkye@boost.horde.net> On Tue, Oct 03, 2017 at 05:19:12PM -0400, John Morrissey wrote: > Anyone have a clueful contact at Proofpoint? Think we're all set on this. Thanks, everyone. -john From sandy at tislabs.com Wed Oct 4 18:32:08 2017 From: sandy at tislabs.com (Sandra Murphy) Date: Wed, 4 Oct 2017 14:32:08 -0400 Subject: BGP hijack: 64.68.207.0/24 from as133955 In-Reply-To: References: <59D3BB42.9070107@easydns.com> <1507073354.2436839.1126952192.57706E69@webmail.messagingengine.com> Message-ID: <987225A7-FB7D-4C3C-BD44-E27D6CFDE2D8@tislabs.com> Not to respond to my own post, or anything. But. Another interesting thing. bgp.he.net reports show that AS133955 is/was also announcing 69.172.127.0/24 "WiMore S.r.l.". bgp.he.net shows a red key icon on that origination, meaning that there’s an RPKI ROA that does not match that origination. And bgp.he.net reports an RADP route object with a proxy registration for AS133955 to originate 69.172.127.0/24, registered on 9/25 like the three prefixes below. RADB still reports that route object (along with a very old one) route: 69.172.127.0/24 descr: Fleg Asia Telecom Ltd Proxy-registered route object origin: AS133955 notify: ipbb-apol at aptg.com.tw mnt-by: MAINT-AS17709 changed: kiayang at aptg.com.tw 20170925 #00:31:36Z source: RADB route: 69.172.64.0/18 descr: Canaca-Com Inc descr: 1650 Dundas Street East Unit 203 descr: Mississauga, Ontario descr: CA origin: AS33139 mnt-by: MNT-CANAC changed: peering at canaca.com 20100624 source: ARIN stats.ripe.net shows 69.172.127.0/24 is presently being announced - "Originated by: AS133955 (valid route object in RADB)”, "100% visible (by 157 of 157 RIS full peers)" The RPKI says that AS34526 (WiMore S.r.l.) is authorized to originate 69.172.96.0/19. But the aggregate prefix is not being announced. If the AS133955 origination is valid, they really ought to update their ROA. Hm. I am curious about that prefix. Is it being hijacked? Or am I just reading everything wrong? —Sandy > On Oct 4, 2017, at 1:45 PM, Sandra Murphy wrote: > > >> On Oct 4, 2017, at 11:29 AM, Theodore Baschak wrote: >> >> I noticed when I looked into both of these leaks 3 hours after Clinton's >> message yesterday that I couldn't see them in any of the looking glasses I >> was looking in (including the NLNOG looking glass) >> >> Looks like things were able to be cleaned up very quickly. > > Interesting. > > bgp.he.net is still reporting AS133955 as the originator of 64.68.207.0/24. I don’t know what their refresh cycle is. > > And, oh look, bgp.he.net points to an RADB proxy registration for the AS133955 origination. RADB no longer reports that route object. But it must have been there at some point. > > RADB > route: 64.68.207.0/24 > > descr: Fleg Asia Telecom Ltd > Proxy-registered route object > origin: AS133955 > notify: ipbb-apol at aptg.com.tw > mnt-by: MAINT-AS17709 > changed: kiayang at aptg.com.tw 20170830 #05:45:57Z > source: RADB > > stat.ripe.net (bless you, RIPE!) shows that 64.68.207.0/24 has been originated by AS133955 off and on for the last month (since the RADB route object’s change date?) in the BGP Update Activity and Routing History graphs. And a huge flurry of activity yesterday. > > Could I be reading all this wrong? Seems to have been going on for quite a while. > > —Sandy > > P.S. The other three prefixes mentioned below show similar results in bgp.he.net, with route objects proxy registered on 9/25, and similar results in stats.ripe.net, with off-and-on announcements, more off than on for these, closely timed with the route object registration. > > >> >> >> >> Theodore Baschak - AS395089 - Hextet Systems >> https://bgp.guru/ - https://hextet.net/ >> http://mbix.ca/ - http://mbnog.ca/ >> >> >> >> >> On Tue, Oct 3, 2017 at 6:29 PM, Clinton Work wrote: >> >>> TELUS AS852 has three address blocks hijacked by AS133955 as well. We >>> have not been able to get in contact with AS24155. It looks like they >>> are buying transit from PCCW AS3491 and Taiwan Internet Gateway AS9505. >>> >>> 68.182.255.0/24 >>> 74.49.255.0/24 >>> 96.1.255.0/24 >>> >>> >>> On Tue, Oct 3, 2017, at 10:30 AM, Mark Jeftovic wrote: >>>> >>>> as133955 is broadcasting bogus BGP announcement for our netblock >>>> 64.68.207.0/24 >>>> >>>> It's in China, and we're trying to contact as24155 but they are also in >>>> China and we're just emailing their whois record address. >>>> >>>> If you're nearby and in a position to block/dampen that might be helpful. >>>> >>>> Thx >>>> >>>> - mark >>>> >>>> -- >>>> Mark Jeftovic >>>> Founder & CEO, easyDNS Technologies Inc. >>>> http://www.easyDNS.com >>>> >>>> >>> From mpeterman at apple.com Thu Oct 5 02:43:01 2017 From: mpeterman at apple.com (Matt Peterman) Date: Wed, 04 Oct 2017 22:43:01 -0400 Subject: Anyone from AT&T DNS? Message-ID: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> The PTR record CNAMEs for my /25 allocated prefix are all messed up. They are returning as $ dig +short CNAME 128.168.207.107.in-addr.arpa 128.128/25.168.207.107.in-addr.arpa. Which is obviously a completely invalid DNS entry. I have opened a ticket through the web portal for “prov-dns” but Haven’t gotten a response for 7 days. If anyone from AT&T DNS or knows anyone from AT&T DNS that can help it would be appreciated! Matt From morrowc.lists at gmail.com Thu Oct 5 02:53:55 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Oct 2017 22:53:55 -0400 Subject: Anyone from AT&T DNS? In-Reply-To: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> Message-ID: On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman wrote: > The PTR record CNAMEs for my /25 allocated prefix are all messed up. They > are returning as > $ dig +short CNAME 128.168.207.107.in-addr.arpa > 128.128/25.168.207.107.in-addr.arpa. > > Which is obviously a completely invalid DNS entry. I have opened a ticket > through the web portal for “prov-dns” but Haven’t gotten a response for 7 > days. > > If anyone from AT&T DNS or knows anyone from AT&T DNS that can help it > would be appreciated! > > isn't this one of the proper forms of reverse delegation in CIDR land? like: http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.aspx describes, or in a (perhaps more wordy fashion) in RFC2317? http://tools.ietf.org/html/rfc2317 I think it may be the case that the NS hosts are not prepared for such a domain/record mapping though... the nameservers that would need to to be authoritative for a zone like: 128/25.168.207.107.in-addr.arpa. and have a bunch of PTR records like: 128 IN PTR foo.you.com. 129 IN PTR bar.you.com. etc... From mpeterman at apple.com Thu Oct 5 03:03:38 2017 From: mpeterman at apple.com (Matt Peterman) Date: Wed, 04 Oct 2017 23:03:38 -0400 Subject: Anyone from AT&T DNS? In-Reply-To: References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> Message-ID: <08A75B52-5FD7-4D6D-918D-F13936AA5443@apple.com> The correct format is as shown below (this is from another /25 I have from AT&T that has DNS setup correctly) $ dig +short CNAME 1.120.232.108.in-addr.arpa 1.0.120.232.108.in-addr.arpa. So for the block I am having an issue with the CNAME records should be For 107.207.168.128 should be 128.128.168.207.107.in-addr.arpa (it shouldn't have “/25” in the middle of it - you can’t even have “/“ in a DNS entry AFAIK) If I do another address from my block I get $ dig +short CNAME 191.168.207.107.in-addr.arpa 191.128/25.168.207.107.in-addr.arpa. Again that would should be 191.128.168.207.107in-addr.arpa. Somehow AT&T DNS got the “/25” prefix length in all of the DNS entries… Matt > On Oct 4, 2017, at 10:53 PM, Christopher Morrow wrote: > > > > On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman > wrote: > The PTR record CNAMEs for my /25 allocated prefix are all messed up. They are returning as > $ dig +short CNAME 128.168.207.107.in-addr.arpa > 128.128/25.168.207.107.in-addr.arpa. > > Which is obviously a completely invalid DNS entry. I have opened a ticket through the web portal for “prov-dns” but Haven’t gotten a response for 7 days. > > If anyone from AT&T DNS or knows anyone from AT&T DNS that can help it would be appreciated! > > > isn't this one of the proper forms of reverse delegation in CIDR land? > > like: > http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.aspx > > describes, or in a (perhaps more wordy fashion) in RFC2317? > http://tools.ietf.org/html/rfc2317 > > I think it may be the case that the NS hosts are not prepared for such a domain/record mapping though... the nameservers that would need to to be authoritative for a zone like: > > > 128/25.168.207.107.in-addr.arpa. > > and have a bunch of PTR records like: > > 128 IN PTR foo.you.com . > 129 IN PTR bar.you.com . > > etc... > > From mpeterman at apple.com Thu Oct 5 03:07:35 2017 From: mpeterman at apple.com (Matt Peterman) Date: Wed, 04 Oct 2017 23:07:35 -0400 Subject: Anyone from AT&T DNS? In-Reply-To: References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> Message-ID: <252DB6B0-3537-4DC4-A43B-E20CAB5CEB52@apple.com> You are correct through that that link does show having the CIDR prefix length in the CNAME which is weird because AT&T did not do this on my other /25 block. Interesting… Guess I need to do more digging. Matt > On Oct 4, 2017, at 10:53 PM, Christopher Morrow wrote: > > > > On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman > wrote: > The PTR record CNAMEs for my /25 allocated prefix are all messed up. They are returning as > $ dig +short CNAME 128.168.207.107.in-addr.arpa > 128.128/25.168.207.107.in-addr.arpa. > > Which is obviously a completely invalid DNS entry. I have opened a ticket through the web portal for “prov-dns” but Haven’t gotten a response for 7 days. > > If anyone from AT&T DNS or knows anyone from AT&T DNS that can help it would be appreciated! > > > isn't this one of the proper forms of reverse delegation in CIDR land? > > like: > http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.aspx > > describes, or in a (perhaps more wordy fashion) in RFC2317? > http://tools.ietf.org/html/rfc2317 > > I think it may be the case that the NS hosts are not prepared for such a domain/record mapping though... the nameservers that would need to to be authoritative for a zone like: > > > 128/25.168.207.107.in-addr.arpa. > > and have a bunch of PTR records like: > > 128 IN PTR foo.you.com . > 129 IN PTR bar.you.com . > > etc... > > From morrowc.lists at gmail.com Thu Oct 5 03:08:16 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Oct 2017 23:08:16 -0400 Subject: Anyone from AT&T DNS? In-Reply-To: <08A75B52-5FD7-4D6D-918D-F13936AA5443@apple.com> References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> <08A75B52-5FD7-4D6D-918D-F13936AA5443@apple.com> Message-ID: On Wed, Oct 4, 2017 at 11:03 PM, Matt Peterman wrote: > The correct format is as shown below (this is from another /25 I have from > AT&T that has DNS setup correctly) > > $ dig +short CNAME 1.120.232.108.in-addr.arpa > 1.0.120.232.108.in-addr.arpa. > > there are more than 1 way to skin the cat, sadly. This tripped me up on a customer connection for a while as well, the RFC example I provided earlier is also valid. > So for the block I am having an issue with the CNAME records should be > For 107.207.168.128 should be 128.128.168.207.107.in-addr.arpa (it > shouldn't have “/25” in the middle of it - you can’t even have “/“ in a DNS > entry AFAIK) > according to the rfc you can. > If I do another address from my block I get $ dig +short CNAME > 191.168.207.107.in-addr.arpa > 191.128/25.168.207.107.in-addr.arpa. > > Again that would should be 191.128.168.207.107in-addr.arpa. > > Somehow AT&T DNS got the “/25” prefix length in all of the DNS entries… > > nope, they are just following the rfc provided path for this. yes it looks screwy, yes it also works fine. > Matt > > > > On Oct 4, 2017, at 10:53 PM, Christopher Morrow > wrote: > > > > On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman > wrote: > >> The PTR record CNAMEs for my /25 allocated prefix are all messed up. They >> are returning as >> $ dig +short CNAME 128.168.207.107.in-addr.arpa >> 128.128/25.168.207.107.in-addr.arpa. >> >> Which is obviously a completely invalid DNS entry. I have opened a ticket >> through the web portal for “prov-dns” but Haven’t gotten a response for 7 >> days. >> >> If anyone from AT&T DNS or knows anyone from AT&T DNS that can help it >> would be appreciated! >> >> > isn't this one of the proper forms of reverse delegation in CIDR land? > > like: > http://support.simpledns.com/kb/a146/how-to-sub-delegate-a- > reverse-zone.aspx > > describes, or in a (perhaps more wordy fashion) in RFC2317? > http://tools.ietf.org/html/rfc2317 > > I think it may be the case that the NS hosts are not prepared for such a > domain/record mapping though... the nameservers that would need to to be > authoritative for a zone like: > > > 128/25.168.207.107.in-addr.arpa. > > and have a bunch of PTR records like: > > 128 IN PTR foo.you.com. > 129 IN PTR bar.you.com. > > etc... > > > > From morrowc.lists at gmail.com Thu Oct 5 03:11:16 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Oct 2017 23:11:16 -0400 Subject: Anyone from AT&T DNS? In-Reply-To: <252DB6B0-3537-4DC4-A43B-E20CAB5CEB52@apple.com> References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> <252DB6B0-3537-4DC4-A43B-E20CAB5CEB52@apple.com> Message-ID: On Wed, Oct 4, 2017 at 11:07 PM, Matt Peterman wrote: > You are correct through that that link does show having the CIDR prefix > length in the CNAME which is weird because AT&T did not do this on my other > /25 block. Interesting… Guess I need to do more digging. > > if I had to guess I'd say that 'sometime long ago' they did one way, then decided to just follow the RFC ... which probably also makes their provisioning automation much simpler. as I said, there are more than 1 way to skin the cat :( sadly you (and I, at least) were used to the 'old fashioned method' welcome to 1998 (apparently!) :) > Matt > > > > On Oct 4, 2017, at 10:53 PM, Christopher Morrow > wrote: > > > > On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman > wrote: > >> The PTR record CNAMEs for my /25 allocated prefix are all messed up. They >> are returning as >> $ dig +short CNAME 128.168.207.107.in-addr.arpa >> 128.128/25.168.207.107.in-addr.arpa. >> >> Which is obviously a completely invalid DNS entry. I have opened a ticket >> through the web portal for “prov-dns” but Haven’t gotten a response for 7 >> days. >> >> If anyone from AT&T DNS or knows anyone from AT&T DNS that can help it >> would be appreciated! >> >> > isn't this one of the proper forms of reverse delegation in CIDR land? > > like: > http://support.simpledns.com/kb/a146/how-to-sub-delegate-a- > reverse-zone.aspx > > describes, or in a (perhaps more wordy fashion) in RFC2317? > http://tools.ietf.org/html/rfc2317 > > I think it may be the case that the NS hosts are not prepared for such a > domain/record mapping though... the nameservers that would need to to be > authoritative for a zone like: > > > 128/25.168.207.107.in-addr.arpa. > > and have a bunch of PTR records like: > > 128 IN PTR foo.you.com. > 129 IN PTR bar.you.com. > > etc... > > > > From mpeterman at apple.com Thu Oct 5 03:18:25 2017 From: mpeterman at apple.com (Matt Peterman) Date: Wed, 04 Oct 2017 23:18:25 -0400 Subject: Anyone from AT&T DNS? In-Reply-To: References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> <252DB6B0-3537-4DC4-A43B-E20CAB5CEB52@apple.com> Message-ID: <50298399-672D-4BA1-A726-7128B84B89FF@apple.com> Got it! You’re the winner here. I just setup both of my zones the name way and obviously AT&T changed the way they did RDNS entries from when I got a /25 last November and this second /25 in June. Oh well! Now I am running into the challenge of Route53 does seem to support creating an authoritative zone for "128/25.168.207.107.in-addr.arpa.” It changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If it isn't one thing its something else. > On Oct 4, 2017, at 11:11 PM, Christopher Morrow wrote: > > > > On Wed, Oct 4, 2017 at 11:07 PM, Matt Peterman > wrote: > You are correct through that that link does show having the CIDR prefix length in the CNAME which is weird because AT&T did not do this on my other /25 block. Interesting… Guess I need to do more digging. > > > if I had to guess I'd say that 'sometime long ago' they did one way, then decided to just follow the RFC ... which probably also makes their provisioning automation much simpler. > > as I said, there are more than 1 way to skin the cat :( sadly you (and I, at least) were used to the 'old fashioned method' welcome to 1998 (apparently!) :) > > Matt > > > >> On Oct 4, 2017, at 10:53 PM, Christopher Morrow > wrote: >> >> >> >> On Wed, Oct 4, 2017 at 10:43 PM, Matt Peterman > wrote: >> The PTR record CNAMEs for my /25 allocated prefix are all messed up. They are returning as >> $ dig +short CNAME 128.168.207.107.in-addr.arpa >> 128.128/25.168.207.107.in-addr.arpa. >> >> Which is obviously a completely invalid DNS entry. I have opened a ticket through the web portal for “prov-dns” but Haven’t gotten a response for 7 days. >> >> If anyone from AT&T DNS or knows anyone from AT&T DNS that can help it would be appreciated! >> >> >> isn't this one of the proper forms of reverse delegation in CIDR land? >> >> like: >> http://support.simpledns.com/kb/a146/how-to-sub-delegate-a-reverse-zone.aspx >> >> describes, or in a (perhaps more wordy fashion) in RFC2317? >> http://tools.ietf.org/html/rfc2317 >> >> I think it may be the case that the NS hosts are not prepared for such a domain/record mapping though... the nameservers that would need to to be authoritative for a zone like: >> >> >> 128/25.168.207.107.in-addr.arpa. >> >> and have a bunch of PTR records like: >> >> 128 IN PTR foo.you.com . >> 129 IN PTR bar.you.com . >> >> etc... >> >> > > From morrowc.lists at gmail.com Thu Oct 5 03:20:36 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Oct 2017 23:20:36 -0400 Subject: Anyone from AT&T DNS? In-Reply-To: <50298399-672D-4BA1-A726-7128B84B89FF@apple.com> References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> <252DB6B0-3537-4DC4-A43B-E20CAB5CEB52@apple.com> <50298399-672D-4BA1-A726-7128B84B89FF@apple.com> Message-ID: On Wed, Oct 4, 2017 at 11:18 PM, Matt Peterman wrote: > Got it! You’re the winner here. I just setup both of my zones the name way > and obviously AT&T changed the way they did RDNS entries from when I got a > /25 last November and this second /25 in June. Oh well! > > Now I am running into the challenge of Route53 does seem to support > creating an authoritative zone for "128/25.168.207.107.in-addr.arpa.” It > changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If > it isn't one thing its something else. > > I've not messed with route53 but fortunately you are treading on well trodden ground: https://forums.aws.amazon.com/thread.jspa?messageID=674778 have a happy evening! (and I hope that the above works.. again I haven't and can't actually try it) From mpeterman at apple.com Thu Oct 5 03:33:00 2017 From: mpeterman at apple.com (Matt Peterman) Date: Wed, 04 Oct 2017 23:33:00 -0400 Subject: Anyone from AT&T DNS? In-Reply-To: References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> <252DB6B0-3537-4DC4-A43B-E20CAB5CEB52@apple.com> <50298399-672D-4BA1-A726-7128B84B89FF@apple.com> Message-ID: <41BF05F7-FEF7-45AB-BF43-E30C57D0DB1E@apple.com> I can now confirm that Christopher is right about everything (not that I had any doubts! Just wanted to confirm all is working!!) ATT is now following the RFC (apparently has changed since November 2016 and June 2017 allocations and DNS changes) and that Route53 WebUI displays things strangely, however technically works fine on the backend. rDNS is now working properly. Thank you Christopher very much! I learned a lot in the last hour I can sure say that! Matt > On Oct 4, 2017, at 11:20 PM, Christopher Morrow wrote: > > > > On Wed, Oct 4, 2017 at 11:18 PM, Matt Peterman > wrote: > Got it! You’re the winner here. I just setup both of my zones the name way and obviously AT&T changed the way they did RDNS entries from when I got a /25 last November and this second /25 in June. Oh well! > > Now I am running into the challenge of Route53 does seem to support creating an authoritative zone for "128/25.168.207.107.in-addr.arpa.” It changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If it isn't one thing its something else. > > > I've not messed with route53 but fortunately you are treading on well trodden ground: > https://forums.aws.amazon.com/thread.jspa?messageID=674778 > > have a happy evening! (and I hope that the above works.. again I haven't and can't actually try it) From jayfar at jayfar.com Thu Oct 5 08:12:30 2017 From: jayfar at jayfar.com (Jay Farrell) Date: Thu, 5 Oct 2017 04:12:30 -0400 Subject: Anyone from AT&T DNS? In-Reply-To: <41BF05F7-FEF7-45AB-BF43-E30C57D0DB1E@apple.com> References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> <252DB6B0-3537-4DC4-A43B-E20CAB5CEB52@apple.com> <50298399-672D-4BA1-A726-7128B84B89FF@apple.com> <41BF05F7-FEF7-45AB-BF43-E30C57D0DB1E@apple.com> Message-ID: Yep, the notation with the slash used to be ATT's standard method. At my job (where we had some customers with ATT MIS T1 circuits) we transitioned to a web front end for our DNS that didn't allow for the slash, so we had to nudge ATT to allow us to use a dash notation instead for delegations. As far as to what can appear in a DNS entry, you'd be amazed. I encountered a PTR record containing a full URL, http:// and everything; it didn't actually work of course, but bind allowed it to exist. When I tracked down the cow-orker who had entered it, he said he knew it wasn't valid, but he did it that way when the customer insisted it had to be thus. :-D On Wed, Oct 4, 2017 at 11:33 PM, Matt Peterman wrote: > I can now confirm that Christopher is right about everything (not that I > had any doubts! Just wanted to confirm all is working!!) > > ATT is now following the RFC (apparently has changed since November 2016 > and June 2017 allocations and DNS changes) and that Route53 WebUI displays > things strangely, however technically works fine on the backend. rDNS is > now working properly. Thank you Christopher very much! I learned a lot in > the last hour I can sure say that! > > Matt > > > > > On Oct 4, 2017, at 11:20 PM, Christopher Morrow > wrote: > > > > > > > > On Wed, Oct 4, 2017 at 11:18 PM, Matt Peterman > wrote: > > Got it! You’re the winner here. I just setup both of my zones the name > way and obviously AT&T changed the way they did RDNS entries from when I > got a /25 last November and this second /25 in June. Oh well! > > > > Now I am running into the challenge of Route53 does seem to support > creating an authoritative zone for "128/25.168.207.107.in-addr.arpa.” It > changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If > it isn't one thing its something else. > > > > > > I've not messed with route53 but fortunately you are treading on well > trodden ground: > > https://forums.aws.amazon.com/thread.jspa?messageID=674778 < > https://forums.aws.amazon.com/thread.jspa?messageID=674778> > > > > have a happy evening! (and I hope that the above works.. again I haven't > and can't actually try it) > > From colinj at gt86car.org.uk Thu Oct 5 12:39:30 2017 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 5 Oct 2017 13:39:30 +0100 Subject: Charity IT Pulse :) one more sleep till Bytenight Action for Children 2017 References: Message-ID: >> >> Dear all, one more sleep until ByteNight events across the UK on Friday night. >> Please donate if you can electronically >> >> >> See mydonate page linked to Byte Night https://mydonate.bt.com/fundraisers/colinjohnston1 >> >> For more information go to www.bytenight.org.uk or to donate Text Byte17 and the amount to 70070. >> >> In just 1 days time, on Friday 6 October, I am spending one night sleeping rough for Byte Night. Byte Night works to support some of the 83,000 young people who are homeless in the UK. One in four young people who are homeless have been diagnosed with mental health issues and one in five will have self-harmed due to their situation at home. £10 could provide an hour’s support with a mental health practitioner for 1 young people to help them get through their issues. Action for Children has supported many young people to a safe and happy future. Unfortunately, so many more still need our help. You can help support young people across the UK by generously donating to my page >> >> >> >> Yours >> >> Colin Johnston >> >> Colin Johnston >> IT Support Senior Professional, Core IT Infrastructure >> BT Technology Service & Operations  | Tel: 01313001324  | MyProfile  | colin.johnstone at bt.com  | http://fixit.bt.com/ >> >> BT Group plc Registered office: 81 Newgate Street London EC1A 7AJ. Registered in England and Wales no. 4190816 This electronic message contains information from BT Group plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please delete it and notify me immediately by telephone or email. > From jra at baylink.com Thu Oct 5 14:40:57 2017 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 5 Oct 2017 14:40:57 +0000 (UTC) Subject: RFC 1918 network range choices Message-ID: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Does anyone have a pointer to an *authoritative* source on why 10/8 172.16/12 and 192.168/16 were the ranges chosen to enshrine in the RFC? Came up elsewhere, and I can't find a good citation either. To list or I'll summarize. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From akshay at mongodb.com Thu Oct 5 14:53:54 2017 From: akshay at mongodb.com (Akshay Kumar) Date: Thu, 5 Oct 2017 10:53:54 -0400 Subject: RFC 1918 network range choices In-Reply-To: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID: https://superuser.com/questions/784978/why-did-the-ietf-specifically-choose-192-168-16-to-be-a-private-ip-address-class/785641 On Thu, Oct 5, 2017 at 10:40 AM, Jay R. Ashworth wrote: > Does anyone have a pointer to an *authoritative* source on why > > 10/8 > 172.16/12 and > 192.168/16 > > were the ranges chosen to enshrine in the RFC? Came up elsewhere, and I > can't > find a good citation either. > > To list or I'll summarize. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > From jra at baylink.com Thu Oct 5 15:03:58 2017 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 5 Oct 2017 15:03:58 +0000 (UTC) Subject: RFC 1918 network range choices In-Reply-To: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID: <594960658.49115.1507215838058.JavaMail.zimbra@baylink.com> The answer seems to be "no, Jon's not answering his email anymore". This seems semi-authoritative, though, and probably as close as we're going to get: https://superuser.com/questions/784978/why-did-the-ietf-specifically-choose-192-168-16-to-be-a-private-ip-address-class/785641 Thanks, Akshay. Cheers, -- jra ----- Original Message ----- > From: "jra" > To: "North American Network Operators' Group" > Sent: Thursday, October 5, 2017 10:40:57 AM > Subject: RFC 1918 network range choices > Does anyone have a pointer to an *authoritative* source on why > > 10/8 > 172.16/12 and > 192.168/16 > > were the ranges chosen to enshrine in the RFC? Came up elsewhere, and I can't > find a good citation either. > > To list or I'll summarize. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jtk at depaul.edu Thu Oct 5 15:20:03 2017 From: jtk at depaul.edu (John Kristoff) Date: Thu, 5 Oct 2017 10:20:03 -0500 Subject: RFC 1918 network range choices In-Reply-To: <9caecccfb43b41198cfc4326621a4a3b@XCASPRD02-DFT.dpu.depaul.edu> References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> <9caecccfb43b41198cfc4326621a4a3b@XCASPRD02-DFT.dpu.depaul.edu> Message-ID: <20171005102003.09909c5f@p50.localdomain> On Thu, 5 Oct 2017 15:03:58 +0000 "Jay R. Ashworth" wrote: > The answer seems to be "no, Jon's not answering his email anymore". You might get a better answer over on the internet-history list. Lots of people are still around that could probably shed some light on it. John From outsider at scarynet.org Thu Oct 5 15:36:38 2017 From: outsider at scarynet.org (Alexander Maassen) Date: Thu, 05 Oct 2017 17:36:38 +0200 Subject: Contact at Proofpoint? Message-ID: ecarbonel at proofpoint.com Kind regards, Alexander Maassen - Maintainer DroneBL- Peplink Certified Engineer -------- Oorspronkelijk bericht --------Van: John Morrissey Datum: 03-10-17 23:19 (GMT+01:00) Aan: nanog at nanog.org Onderwerp: Contact at Proofpoint? Anyone have a clueful contact at Proofpoint? One of our e-mail domains is being blackholed by their products, and we're striking out via normal channels. -john From hugo at slabnet.com Thu Oct 5 16:00:40 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 5 Oct 2017 09:00:40 -0700 Subject: Charity IT Pulse :) one more sleep till Bytenight Action for Children 2017 In-Reply-To: References: Message-ID: <20171005160040.GB2845@bamboo.slabnet.com> You've done this before[1] and you've been advised before[2][3] that plugging charities is not appropriate for this list[4]. Plug it on Twitter or Facebook or wherever else these things generally go. At which point is this mod territory to deal with? -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal [1] https://mailman.nanog.org/pipermail/nanog/2017-June/091639.html [2] https://mailman.nanog.org/pipermail/nanog/2017-June/091640.html [3] https://mailman.nanog.org/pipermail/nanog/2017-June/091642.html [4] https://www.nanog.org/list On Thu 2017-Oct-05 13:39:30 +0100, Colin Johnston wrote: >>> >>> Dear all, one more sleep until ByteNight events across the UK on Friday night. >>> Please donate if you can electronically >>> >>> >>> See mydonate page linked to Byte Night https://mydonate.bt.com/fundraisers/colinjohnston1 >>> >>> For more information go to www.bytenight.org.uk or to donate Text Byte17 and the amount to 70070. >>> >>> In just 1 days time, on Friday 6 October, I am spending one night sleeping rough for Byte Night. Byte Night works to support some of the 83,000 young people who are homeless in the UK. One in four young people who are homeless have been diagnosed with mental health issues and one in five will have self-harmed due to their situation at home. £10 could provide an hour’s support with a mental health practitioner for 1 young people to help them get through their issues. Action for Children has supported many young people to a safe and happy future. Unfortunately, so many more still need our help. You can help support young people across the UK by generously donating to my page >>> >>> >>> >>> Yours >>> >>> Colin Johnston >>> >>> Colin Johnston >>> IT Support Senior Professional, Core IT Infrastructure >>> BT Technology Service & Operations  | Tel: 01313001324  | MyProfile  | colin.johnstone at bt.com  | http://fixit.bt.com/ >>> >>> BT Group plc Registered office: 81 Newgate Street London EC1A 7AJ. Registered in England and Wales no. 4190816 This electronic message contains information from BT Group plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please delete it and notify me immediately by telephone or email. >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From jerry at jtcloe.net Thu Oct 5 17:32:19 2017 From: jerry at jtcloe.net (=?utf-8?Q?Jerry_Cloe?=) Date: Thu, 5 Oct 2017 12:32:19 -0500 Subject: RFC 1918 network range choices In-Reply-To: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID: Several years ago I remember seeing a mathematical justification for it, and I remember thinking at the time it made a lot of sense, but now I can't find it.   I think the goal was to make it easier for routers to dump private ranges based on simple binary math, but not sure that concept ever got widely used.   Time to start writing  out all the binary.   -----Original message----- From:Jay R. Ashworth Sent:Thu 10-05-2017 09:41 am Subject:RFC 1918 network range choices To:North American Network Operators‘ Group ; Does anyone have a pointer to an *authoritative* source on why 10/8 172.16/12 and 192.168/16 were the ranges chosen to enshrine in the RFC?  Came up elsewhere, and I can't find a good citation either. To list or I'll summarize. Cheers, -- jra   From jra at baylink.com Thu Oct 5 17:39:04 2017 From: jra at baylink.com (Jay Ashworth) Date: Thu, 05 Oct 2017 13:39:04 -0400 Subject: RFC 1918 network range choices In-Reply-To: References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID: <7955F3C0-45E8-4F0C-A0F6-1A37FA8F3E3D@baylink.com> I have seen a number of versions of that in reading things people sent me and things I found myself, and all of them seem to depend on ASICs that didn't exist at the time the ranges were chosen, and probably also CIDR which also didn't exist. They sound good, but I'm not buying em. :-) On October 5, 2017 1:32:19 PM EDT, Jerry Cloe wrote: >Several years ago I remember seeing a mathematical justification for >it, and I remember thinking at the time it made a lot of sense, but now >I can't find it. > >  >I think the goal was to make it easier for routers to dump private >ranges based on simple binary math, but not sure that concept ever got >widely used. > >  >Time to start writing  out all the binary. > > >  >-----Original message----- >From:Jay R. Ashworth >Sent:Thu 10-05-2017 09:41 am >Subject:RFC 1918 network range choices >To:North American Network Operators‘ Group ; >Does anyone have a pointer to an *authoritative* source on why > >10/8 >172.16/12 and >192.168/16 > >were the ranges chosen to enshrine in the RFC?  Came up elsewhere, and >I can't >find a good citation either. > >To list or I'll summarize. > >Cheers, >-- jra > >  -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From valdis.kletnieks at vt.edu Thu Oct 5 19:04:42 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 05 Oct 2017 15:04:42 -0400 Subject: RFC 1918 network range choices In-Reply-To: <7955F3C0-45E8-4F0C-A0F6-1A37FA8F3E3D@baylink.com> References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> <7955F3C0-45E8-4F0C-A0F6-1A37FA8F3E3D@baylink.com> Message-ID: <12872.1507230282@turing-police.cc.vt.edu> On Thu, 05 Oct 2017 13:39:04 -0400, Jay Ashworth said: > I have seen a number of versions of that in reading things people sent me and > things I found myself, and all of them seem to depend on ASICs that didn't > exist at the time the ranges were chosen, and probably also CIDR which also > didn't exist. They sound good, but I'm not buying em. :-) Can't speak t the ASICs, but CIDR existed, even if your vendor was behind the times and still calling stuff class A/B/C. (Such nonsense persisted well into this century). Check the dates... 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. (Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Updated by RFC6761) (Also BCP0005) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1918) 1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR). Internet Engineering Steering Group, R. Hinden. September 1993. (Format: TXT=7357 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1517) 1518 An Architecture for IP Address Allocation with CIDR. Y. Rekhter, T. Li. September 1993. (Format: TXT=72609 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1518) 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993. (Format: TXT=59998 bytes) (Obsoletes RFC1338) (Obsoleted by RFC4632) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1519) 1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment. Y. Rekhter, C. Topolcic. September 1993. (Format: TXT=20389 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1520) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From Brian at ampr.org Thu Oct 5 19:21:23 2017 From: Brian at ampr.org (Brian Kantor) Date: Thu, 5 Oct 2017 12:21:23 -0700 Subject: RFC 1918 network range choices In-Reply-To: <12872.1507230282@turing-police.cc.vt.edu> References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> <7955F3C0-45E8-4F0C-A0F6-1A37FA8F3E3D@baylink.com> <12872.1507230282@turing-police.cc.vt.edu> Message-ID: <20171005192123.GA11461@UCSD.Edu> On Thu, Oct 05, 2017 at 03:04:42PM -0400, valdis.kletnieks at vt.edu wrote: > Can't speak t the ASICs, but CIDR existed, even if your vendor was behind the > times and still calling stuff class A/B/C. (Such nonsense persisted well into > this century). Check the dates... The concept of using a number-of-bits to describe what is now called CIDR existed as early as 1987: http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8706.mm.www/0011.html - Brian From randy at psg.com Thu Oct 5 20:28:46 2017 From: randy at psg.com (Randy Bush) Date: Fri, 06 Oct 2017 05:28:46 +0900 Subject: RFC 1918 network range choices In-Reply-To: <20171005102003.09909c5f@p50.localdomain> References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> <9caecccfb43b41198cfc4326621a4a3b@XCASPRD02-DFT.dpu.depaul.edu> <20171005102003.09909c5f@p50.localdomain> Message-ID: >> The answer seems to be "no, Jon's not answering his email anymore". jon was not a big supporter of rfc1918 From jfmezei_nanog at vaxination.ca Thu Oct 5 21:50:39 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 5 Oct 2017 17:50:39 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: got curious about the FCC's definition of "cell site" in the Maria outages reports in Puerto Rico. In the Oct 4 report: Arecibo is reported as having 68 cell sites served, 65 being out. (95.2% outage) The FCC has an "ASR" (Antenna Structure Registration) search for cell sites, and this points to actual masts (which I assume need some permit above certain height). For ARECIBO, there are 31 entries, 1 dismantled, 4 granted 2 cancelled That leaves 24 "constructed". These registrations do not mention which carrier(s) uses the mast. And include some owners such as Caribbean Broadcasting Corporation which isn't likiely being used for cellular. For all of Puerto Rico, it reports 930 ASR registrations. (haven't done the parsing to see how many are "Constructed" vs Cancelled, granted, dismantled). Lets assume 900 for sake of discussion. So the ~1600 quoted by another organisation would have to include more than just registered antenna masts. Except for water towers, what other structures would be amenable to having multiple carrier's antennas? What is also not clear from such statistics is the fact you could have a town with an high antenna broadcasting 850 to the whole area, and then lots of DAS antennas at telephone pole height in the town at 1900 or 1700. Having the 850 up and running at the top of the hill might cover the whole town, even if it would represent only 1 of say 50 cell sites in the area. Similarly, covering a windy road in a canyon might be done with lots of DAS anetnnas on telephone poles along the way. They may all be down, but would normally serve 0 population, so is this number of "down" antennas relevant? During the 1998 ce storm in Québec, Hydro Québec was overwhelmed and asked cities to identify priority sites inside their territories. It's fancy "point to where the break is based on where everyone reports an outage" software was useless because many breaks continued to happen after power had been lost. So it had to start from where there was power and work its way, fixing breaks along the line towards those priority sites. (and once done, fan out from there to power the non priority areas). In many rural areas, this involved planting new poles for long distances, rebuilding from scratch. (And only once the poles are up can the telco restring its wiring). What the media doesn't show after a disaster is what is still standing, what is still working. It could be that a large portion of telephone poles are still standing and intact and only require minor individual fixes. Or it could be that large swaths ave seen the poles toppled and new ones needed with new power and telco wiring done from scratch. Statistics may look bad showing 100,000 without power. But if it is a single break by a branch it is easy to fix compared to having 1000 breaks by 1000 branches. So again, statistics don't give the full story on the real extent of damage. From nanog-post at rsuc.gweep.net Thu Oct 5 22:47:42 2017 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 5 Oct 2017 18:47:42 -0400 Subject: RFC 1918 network range choices In-Reply-To: <12872.1507230282@turing-police.cc.vt.edu> References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> <7955F3C0-45E8-4F0C-A0F6-1A37FA8F3E3D@baylink.com> <12872.1507230282@turing-police.cc.vt.edu> Message-ID: <20171005224742.GA89457@gweep.net> On Thu, Oct 05, 2017 at 03:04:42PM -0400, valdis.kletnieks at vt.edu wrote: > On Thu, 05 Oct 2017 13:39:04 -0400, Jay Ashworth said: > > > I have seen a number of versions of that in reading things people sent me and > > things I found myself, and all of them seem to depend on ASICs that didn't > > exist at the time the ranges were chosen, and probably also CIDR which also > > didn't exist. They sound good, but I'm not buying em. :-) > > Can't speak t the ASICs, but CIDR existed, even if your vendor was behind the > times and still calling stuff class A/B/C. (Such nonsense persisted well into > this century). Check the dates... [snip] To be fair, the actual formal allocation was 1994 with rfc1597. 1918 was the reconciliation of 1597 and 1627 (ISTR the division was also why we saw 1796 and 1814). The practice had been used for a while before the codification but I don't have a good citation. IAB minutes of 1992 speak of the practice and the tut-tutting of not wanting people to do it, but not citing specific numbers and math. Cheers! Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From nanog at ics-il.net Thu Oct 5 23:11:44 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 5 Oct 2017 18:11:44 -0500 (CDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: <410332071.6038.1507245103433.JavaMail.mhammett@ThunderFuck> Broadcast towers that you ruled out often have cell companies on them. Buildings often have cell sites on them. DAS really isn't all that common. There's usually two, three, four providers on a given tower. My ASR search of Arecibo, PR gives me 19 constructed. Six of them are on known multi-tenant tower owners. All towers over 200' and some towers meeting various other requirements must be listed in ASR. The tower companies usually list many of them in ASR, but not always. Crown Castle has 299 sites in Puerto Rico and lists 196 "alternative" sites. These are likely options on various retail rooftops, open land, etc. American Tower lists 175 sites with about 2/3 of them being typical towers and the other third being random other things that may or may not be developed. SBA lists 97 sites. PTI lists 19 sites. There are likely other tower companies down there as well. My AT&T Towers login isn't working and they appear to have their own sites down there. It probably adds up with some margin of error. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Jean-Francois Mezei" To: nanog at nanog.org Sent: Thursday, October 5, 2017 4:50:39 PM Subject: Re: Hurricane Maria: Summary of communication status - and lack of got curious about the FCC's definition of "cell site" in the Maria outages reports in Puerto Rico. In the Oct 4 report: Arecibo is reported as having 68 cell sites served, 65 being out. (95.2% outage) The FCC has an "ASR" (Antenna Structure Registration) search for cell sites, and this points to actual masts (which I assume need some permit above certain height). For ARECIBO, there are 31 entries, 1 dismantled, 4 granted 2 cancelled That leaves 24 "constructed". These registrations do not mention which carrier(s) uses the mast. And include some owners such as Caribbean Broadcasting Corporation which isn't likiely being used for cellular. For all of Puerto Rico, it reports 930 ASR registrations. (haven't done the parsing to see how many are "Constructed" vs Cancelled, granted, dismantled). Lets assume 900 for sake of discussion. So the ~1600 quoted by another organisation would have to include more than just registered antenna masts. Except for water towers, what other structures would be amenable to having multiple carrier's antennas? What is also not clear from such statistics is the fact you could have a town with an high antenna broadcasting 850 to the whole area, and then lots of DAS antennas at telephone pole height in the town at 1900 or 1700. Having the 850 up and running at the top of the hill might cover the whole town, even if it would represent only 1 of say 50 cell sites in the area. Similarly, covering a windy road in a canyon might be done with lots of DAS anetnnas on telephone poles along the way. They may all be down, but would normally serve 0 population, so is this number of "down" antennas relevant? During the 1998 ce storm in Québec, Hydro Québec was overwhelmed and asked cities to identify priority sites inside their territories. It's fancy "point to where the break is based on where everyone reports an outage" software was useless because many breaks continued to happen after power had been lost. So it had to start from where there was power and work its way, fixing breaks along the line towards those priority sites. (and once done, fan out from there to power the non priority areas). In many rural areas, this involved planting new poles for long distances, rebuilding from scratch. (And only once the poles are up can the telco restring its wiring). What the media doesn't show after a disaster is what is still standing, what is still working. It could be that a large portion of telephone poles are still standing and intact and only require minor individual fixes. Or it could be that large swaths ave seen the poles toppled and new ones needed with new power and telco wiring done from scratch. Statistics may look bad showing 100,000 without power. But if it is a single break by a branch it is easy to fix compared to having 1000 breaks by 1000 branches. So again, statistics don't give the full story on the real extent of damage. From bill at herrin.us Thu Oct 5 23:14:46 2017 From: bill at herrin.us (William Herrin) Date: Thu, 5 Oct 2017 19:14:46 -0400 Subject: RFC 1918 network range choices In-Reply-To: References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID: On Thu, Oct 5, 2017 at 1:32 PM, Jerry Cloe wrote: > Several years ago I remember seeing a mathematical justification for it, > and I remember thinking at the time it made a lot of sense, but now I can't > find it. > Hi Jerry, If there's special ASIC-friendly math here, beyond what was later generalized with CIDR, it's not obvious. 10.0: 0000 1010 0000 0000 172.16: 1010 1100 0001 0000 172.31: 1010 1100 0001 1111 192.168: 1100 0000 1010 1000 AFAIK, it was simply one range each from classes A, B and C. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From feldman at twincreeks.net Thu Oct 5 23:52:54 2017 From: feldman at twincreeks.net (Steve Feldman) Date: Thu, 5 Oct 2017 16:52:54 -0700 Subject: RFC 1918 network range choices In-Reply-To: References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID: > On Oct 5, 2017, at 4:14 PM, William Herrin wrote: > > On Thu, Oct 5, 2017 at 1:32 PM, Jerry Cloe wrote: > >> Several years ago I remember seeing a mathematical justification for it, >> and I remember thinking at the time it made a lot of sense, but now I can't >> find it. >> > > Hi Jerry, > > If there's special ASIC-friendly math here, beyond what was later > generalized with CIDR, it's not obvious. > > 10.0: 0000 1010 0000 0000 > > 172.16: 1010 1100 0001 0000 > > 172.31: 1010 1100 0001 1111 > > 192.168: 1100 0000 1010 1000 > > AFAIK, it was simply one range each from classes A, B and C. As mentioned in one of the links posted earlier, 10.0.0.0/8 was the original ARPANET class A assignment. (See RFC 970, which brings back a lot of memories.) Once the ARPANET was shut down in 1990 that block was no longer used, so it became available for reuse in RFC1918. I have a vague recollection of parts of 192.168.0.0/16 being used as default addresses on early Sun systems. If that's actually true, it might explain that choice. Steve From lyndon at orthanc.ca Fri Oct 6 00:14:05 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 5 Oct 2017 17:14:05 -0700 Subject: RFC 1918 network range choices In-Reply-To: References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID: > On Oct 5, 2017, at 4:52 PM, Steve Feldman wrote: > > I have a vague recollection of parts of 192.168.0.0/16 being used as default addresses on early Sun systems. If that's actually true, it might explain that choice. 192.9.200.X rings a bell; but those might have been the example addresses they used in the SunOS 3.X documentation. From mike at mtcc.com Fri Oct 6 00:17:59 2017 From: mike at mtcc.com (Michael Thomas) Date: Thu, 5 Oct 2017 17:17:59 -0700 Subject: RFC 1918 network range choices In-Reply-To: References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID: On 10/05/2017 05:14 PM, Lyndon Nerenberg wrote: >> On Oct 5, 2017, at 4:52 PM, Steve Feldman wrote: >> >> I have a vague recollection of parts of 192.168.0.0/16 being used as default addresses on early Sun systems. If that's actually true, it might explain that choice. > 192.9.200.X rings a bell; but those might have been the example addresses they used in the SunOS 3.X documentation That's what i recall too. For some reason i thought it was hp, but that could easily be wrong. Mike From sean at donelan.com Fri Oct 6 00:45:51 2017 From: sean at donelan.com (Sean Donelan) Date: Thu, 5 Oct 2017 20:45:51 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: On Thu, 5 Oct 2017, Jean-Francois Mezei wrote: > Statistics may look bad showing 100,000 without power. But if it is a > single break by a branch it is easy to fix compared to having 1000 > breaks by 1000 branches. So again, statistics don't give the full story > on the real extent of damage. The FCC is a passive entity collecting only the outage details service providers choose to voluntarily share. Data about cell sites is from the Wireless Resiliency Cooperative Framework and any other wireless carriers which choose to provide data. https://www.fcc.gov/wireless-resiliency-cooperative-framework https://ecfsapi.fcc.gov/file/60001707365.pdf This is the data collected by DIRS: Wireline Carriers CLLI code of switches/STPs that are out Names of PSAPs that are out Estimated users out of service Major facilities out of service (> 192 DS3) Very short status description of the effects of event (e.g., “No major equipment out”) Wireless Carriers CLLI code of MSCs/STPs that are out Total cell sites out in disaster area Very short status description From ahebert at pubnix.net Fri Oct 6 12:30:31 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 6 Oct 2017 08:30:31 -0400 Subject: RFC 1918 network range choices In-Reply-To: References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID:     Well,     Some HP unixes, and documentation, still uses 192.1.1.x.     Hey free publicity for BBN.     I have a client still using 192.1.10/24 just because of it. Been 4 years and they still won't change it :( ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 10/05/17 20:14, Lyndon Nerenberg wrote: >> On Oct 5, 2017, at 4:52 PM, Steve Feldman wrote: >> >> I have a vague recollection of parts of 192.168.0.0/16 being used as default addresses on early Sun systems. If that's actually true, it might explain that choice. > 192.9.200.X rings a bell; but those might have been the example addresses they used in the SunOS 3.X documentation. From jsklein at gmail.com Fri Oct 6 13:51:31 2017 From: jsklein at gmail.com (Joe Klein) Date: Fri, 6 Oct 2017 09:51:31 -0400 Subject: RFC 1918 network range choices In-Reply-To: References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> <9caecccfb43b41198cfc4326621a4a3b@XCASPRD02-DFT.dpu.depaul.edu> <20171005102003.09909c5f@p50.localdomain> Message-ID: Which part? The allocation of the addresses or the security model (section 2, 4 & 5)? Note: Very few system, network, or security professionals have even read anything besides section 3, the private address allocation. Could be why we have some many compromises --- just saying. Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Thu, Oct 5, 2017 at 4:28 PM, Randy Bush wrote: > >> The answer seems to be "no, Jon's not answering his email anymore". > > jon was not a big supporter of rfc1918 > From owen at delong.com Fri Oct 6 16:28:12 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Oct 2017 09:28:12 -0700 Subject: RFC 1918 network range choices In-Reply-To: References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID: > On Oct 5, 2017, at 5:14 PM, Lyndon Nerenberg wrote: > > >> On Oct 5, 2017, at 4:52 PM, Steve Feldman wrote: >> >> I have a vague recollection of parts of 192.168.0.0/16 being used as default addresses on early Sun systems. If that's actually true, it might explain that choice. > > 192.9.200.X rings a bell; but those might have been the example addresses they used in the SunOS 3.X documentation. I recall 192.9.200.X being used both in documentation and in default system configurations. Owen (Former) Sun Employee #10056 From cscora at apnic.net Fri Oct 6 18:02:46 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Oct 2017 04:02:46 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171006180246.851CAC44AD@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 MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 07 Oct, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 666275 Prefixes after maximum aggregation (per Origin AS): 258788 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 320459 Total ASes present in the Internet Routing Table: 58610 Prefixes per ASN: 11.37 Origin-only ASes present in the Internet Routing Table: 50634 Origin ASes announcing only one prefix: 22344 Transit ASes present in the Internet Routing Table: 7976 Transit-only ASes present in the Internet Routing Table: 232 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 32 Max AS path prepend of ASN ( 29046) 25 Prefixes from unregistered ASNs in the Routing Table: 90 Number of instances of unregistered ASNs: 90 Number of 32-bit ASNs allocated by the RIRs: 20182 Number of 32-bit ASNs visible in the Routing Table: 15985 Prefixes from 32-bit ASNs in the Routing Table: 65602 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: 329 Number of addresses announced to Internet: 2855818080 Equivalent to 170 /8s, 56 /16s and 83 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 219686 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 184470 Total APNIC prefixes after maximum aggregation: 52431 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 183462 Unique aggregates announced from the APNIC address blocks: 74836 APNIC Region origin ASes present in the Internet Routing Table: 8365 APNIC Prefixes per ASN: 21.93 APNIC Region origin ASes announcing only one prefix: 2315 APNIC Region transit ASes present in the Internet Routing Table: 1201 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 32 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3222 Number of APNIC addresses announced to Internet: 765571296 Equivalent to 45 /8s, 161 /16s and 176 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 200599 Total ARIN prefixes after maximum aggregation: 96384 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 202201 Unique aggregates announced from the ARIN address blocks: 94047 ARIN Region origin ASes present in the Internet Routing Table: 17999 ARIN Prefixes per ASN: 11.23 ARIN Region origin ASes announcing only one prefix: 6666 ARIN Region transit ASes present in the Internet Routing Table: 1769 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2215 Number of ARIN addresses announced to Internet: 1110698016 Equivalent to 66 /8s, 51 /16s and 232 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 177740 Total RIPE prefixes after maximum aggregation: 87039 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 173740 Unique aggregates announced from the RIPE address blocks: 104942 RIPE Region origin ASes present in the Internet Routing Table: 24456 RIPE Prefixes per ASN: 7.10 RIPE Region origin ASes announcing only one prefix: 11213 RIPE Region transit ASes present in the Internet Routing Table: 3491 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6233 Number of RIPE addresses announced to Internet: 713210496 Equivalent to 42 /8s, 130 /16s and 186 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 85864 Total LACNIC prefixes after maximum aggregation: 18976 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 87097 Unique aggregates announced from the LACNIC address blocks: 39215 LACNIC Region origin ASes present in the Internet Routing Table: 6448 LACNIC Prefixes per ASN: 13.51 LACNIC Region origin ASes announcing only one prefix: 1805 LACNIC Region transit ASes present in the Internet Routing Table: 1194 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3967 Number of LACNIC addresses announced to Internet: 172591840 Equivalent to 10 /8s, 73 /16s and 138 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17510 Total AfriNIC prefixes after maximum aggregation: 3884 AfriNIC Deaggregation factor: 4.51 Prefixes being announced from the AfriNIC address blocks: 19446 Unique aggregates announced from the AfriNIC address blocks: 7160 AfriNIC Region origin ASes present in the Internet Routing Table: 1077 AfriNIC Prefixes per ASN: 18.06 AfriNIC Region origin ASes announcing only one prefix: 344 AfriNIC Region transit ASes present in the Internet Routing Table: 213 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 348 Number of AfriNIC addresses announced to Internet: 93300992 Equivalent to 5 /8s, 143 /16s and 169 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5270 4192 76 ERX-CERNET-BKB China Education and Rese 7545 3991 407 407 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2863 900 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2789 11126 751 KIXS-AS-KR Korea Telecom, KR 9829 2755 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2368 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2264 1465 142 VNPT-AS-VN VNPT Corp, VN 9394 2174 4931 27 CTTNET China TieTong Telecommunications 4755 2106 423 222 TATACOMM-AS TATA Communications formerl 7552 1796 1139 90 VIETEL-AS-AP Viettel Corporation, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3414 1341 88 SHAW - Shaw Communications Inc., CA 22773 3300 2952 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2208 405 107 MEGAPATH5-US - MegaPath Corporation, US 6389 2045 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2043 2264 431 CHARTER-NET-HKY-NC - Charter Communicat 209 1937 5067 653 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1848 4013 547 AMAZON-02 - Amazon.com, Inc., US 30036 1825 329 335 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 701 1679 10589 626 UUNET - MCI Communications Services, In 11492 1628 241 558 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2855 875 2056 AKAMAI-ASN1, US 8551 2441 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2056 330 423 TELLCOM-AS, TR 12389 1823 1659 689 ROSTELECOM-AS, RU 9121 1779 1691 17 TTNET, TR 12479 1742 1063 72 UNI2-AS, ES 13188 1604 100 52 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1199 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3570 541 253 Telmex Colombia S.A., CO 8151 3230 3471 584 Uninet S.A. de C.V., MX 11830 2076 370 65 Instituto Costarricense de Electricidad 6503 1552 437 53 Axtel, S.A.B. de C.V., MX 7303 1548 1015 242 Telecom Argentina S.A., AR 6147 1278 377 27 Telefonica del Peru S.A.A., PE 3816 1032 509 103 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 992 2301 182 CLARO S.A., BR 11172 914 126 86 Alestra, S. de R.L. de C.V., MX 18881 901 1056 24 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1215 398 48 LINKdotNET-AS, EG 37611 770 91 8 Afrihost, ZA 36903 706 355 138 MT-MPLS, MA 36992 666 1383 31 ETISALAT-MISR, EG 24835 515 850 15 RAYA-AS, EG 8452 423 1730 18 TE-AS TE-AS, EG 29571 421 36 10 CITelecom-AS, CI 37492 416 354 77 ORANGE-, TN 15399 356 35 7 WANANCHI-, KE 2018 297 327 73 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5270 4192 76 ERX-CERNET-BKB China Education and Rese 7545 3991 407 407 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3570 541 253 Telmex Colombia S.A., CO 6327 3414 1341 88 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 22773 3300 2952 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8151 3230 3471 584 Uninet S.A. de C.V., MX 17974 2863 900 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2855 875 2056 AKAMAI-ASN1, US 4766 2789 11126 751 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 3991 3584 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3414 3326 SHAW - Shaw Communications Inc., CA 10620 3570 3317 Telmex Colombia S.A., CO 22773 3300 3143 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2863 2786 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8151 3230 2646 Uninet S.A. de C.V., MX 8551 2441 2400 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2368 2336 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2755 2215 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:106 /12:284 /13:554 /14:1054 /15:1870 /16:13422 /17:7775 /18:13699 /19:25384 /20:39377 /21:42849 /22:80328 /23:65493 /24:371552 /25:854 /26:627 /27:653 /28:37 /29:39 /30:219 /31:2 /32:33 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3210 3414 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2523 3300 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2094 2208 MEGAPATH5-US - MegaPath Corporation, US 8551 1906 2441 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1601 1825 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1529 3570 Telmex Colombia S.A., CO 11830 1468 2076 Instituto Costarricense de Electricidad y Telec 11492 1447 1628 CABLEONE - CABLE ONE, INC., US 34984 1363 2056 TELLCOM-AS, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1564 2:841 4:18 5:2496 6:39 7:1 8:1074 12:1850 13:159 14:1710 15:28 16:3 17:174 18:76 20:60 23:2478 24:1633 25:2 27:2417 29:1 31:1943 32:89 35:21 36:421 37:2296 38:1390 39:73 40:98 41:3052 42:496 43:1963 44:84 45:3079 46:2824 47:170 49:1262 50:1006 51:19 52:860 54:353 55:1 56:4 57:43 58:1586 59:991 60:354 61:2020 62:1712 63:1900 64:4603 65:2213 66:4450 67:2292 68:1190 69:3172 70:1162 71:614 72:2144 74:2636 75:401 76:413 77:1539 78:1551 79:1889 80:1418 81:1401 82:1026 83:741 84:952 85:1896 86:464 87:1217 88:821 89:2231 90:171 91:6218 92:1025 93:2347 94:2396 95:2642 96:632 97:352 98:959 99:93 100:153 101:1464 102:1 103:15963 104:3044 105:210 106:559 107:1768 108:829 109:2911 110:1471 111:1750 112:1275 113:1268 114:1075 115:1585 116:1700 117:1792 118:2146 119:1642 120:910 121:1072 122:2437 123:1864 124:1503 125:1804 128:911 129:674 130:444 131:1499 132:612 133:193 134:802 135:226 136:334 137:494 138:1978 139:524 140:378 141:672 142:741 143:912 144:787 145:185 146:1113 147:682 148:1496 149:594 150:703 151:1002 152:719 153:300 154:920 155:767 156:687 157:733 158:596 159:1561 160:776 161:753 162:2507 163:511 164:990 165:1437 166:383 167:1299 168:3036 169:811 170:3578 171:382 172:994 173:2019 174:799 175:784 176:1857 177:3895 178:2490 179:1138 180:2210 181:2092 182:2455 183:827 184:901 185:10890 186:3322 187:2254 188:2584 189:1838 190:8403 191:1370 192:9673 193:5809 194:4714 195:3952 196:2169 197:1305 198:5529 199:5871 200:7527 201:4403 202:10378 203:9984 204:4546 205:2859 206:3005 207:3166 208:3954 209:4045 210:3937 211:2080 212:2884 213:2604 214:849 215:66 216:5894 217:2102 218:973 219:590 220:1671 221:940 222:757 223:1291 End of report From dfk at ripe.net Fri Oct 6 18:34:30 2017 From: dfk at ripe.net (Daniel Karrenberg) Date: Fri, 6 Oct 2017 11:34:30 -0700 Subject: RFC 1918 network range choices In-Reply-To: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> Message-ID: On 05/10/2017 07:40, Jay R. Ashworth wrote: > Does anyone have a pointer to an *authoritative* source on why > > 10/8 > 172.16/12 and > 192.168/16 > > were the ranges chosen to enshrine in the RFC? ... The RFC explains the reason why we chose three ranges from "Class A,B & C" respectively: CIDR had been specified but had not been widely implemented. There was a significant amount of equipment out there that still was "classful". As far as I recall the choice of the particular ranges were as follows: 10/8: the ARPANET had just been turned off. One of us suggested it and Jon considered this a good re-use of this "historical" address block. We also suspected that "net 10" might have been hard coded in some places, so re-using it for private address space rather than in inter-AS routing might have the slight advantage of keeping such silliness local. 172.16/12: the lowest unallocated /12 in class B space. 192.168/16: the lowest unallocated /16 in class C block 192/8. In summary: IANA allocated this space just as it would have for any other purpose. As the IANA, Jon was very consistent unless there was a really good reason to be creative. Daniel (co-author of RFC1918) From dfk at ripe.net Fri Oct 6 18:36:32 2017 From: dfk at ripe.net (Daniel Karrenberg) Date: Fri, 6 Oct 2017 11:36:32 -0700 Subject: RFC 1918 network range choices In-Reply-To: References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> <9caecccfb43b41198cfc4326621a4a3b@XCASPRD02-DFT.dpu.depaul.edu> <20171005102003.09909c5f@p50.localdomain> Message-ID: <59141a87-977f-d5cd-9895-eaa6203894a6@ripe.net> On 05/10/2017 13:28, Randy Bush wrote: >>> The answer seems to be "no, Jon's not answering his email anymore". > > jon was not a big supporter of rfc1918 If I recall correctly not one of the authors was a "big supporter". Some things are not full of beauty and glory; yet they have to be done. I recall a number of conversations with Jon about this, at least one of them face-to-face. I am convinced he fully agreed that it was necessary. Daniel From hardenrm at uchicago.edu Fri Oct 6 14:15:21 2017 From: hardenrm at uchicago.edu (Ryan Harden) Date: Fri, 6 Oct 2017 14:15:21 +0000 Subject: RFC 1918 network range choices In-Reply-To: References: <1891095257.48826.1507214457920.JavaMail.zimbra@baylink.com> <9caecccfb43b41198cfc4326621a4a3b@XCASPRD02-DFT.dpu.depaul.edu> <20171005102003.09909c5f@p50.localdomain> Message-ID: Interesting you call sections 2,4,5 a security model when section 6 explicitly states "Security issues are not addressed in this memo.” Sections 2, 4, and 5 are motivational and design considerations. Using RFC1918 space is not and should not be considered a security practice. /Ryan Ryan Harden Research and Advanced Networking Architect University of Chicago - ASN160 P: 773.834.5441 > On Oct 6, 2017, at 8:51 AM, Joe Klein wrote: > > Which part? The allocation of the addresses or the security model (section > 2, 4 & 5)? > > Note: Very few system, network, or security professionals have even read > anything besides section 3, the private address allocation. Could be why > we have some many compromises --- just saying. > > Joe Klein > > "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > > On Thu, Oct 5, 2017 at 4:28 PM, Randy Bush wrote: > >>>> The answer seems to be "no, Jon's not answering his email anymore". >> >> jon was not a big supporter of rfc1918 >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP URL: From cjwolff at nola.gov Fri Oct 6 20:41:04 2017 From: cjwolff at nola.gov (Christopher J. Wolff) Date: Fri, 6 Oct 2017 20:41:04 +0000 Subject: Cisco ISE Message-ID: <3A8C1FD9-F590-4EEF-B580-CFA39D46B1F6@nola.gov> Is anyone successfully deploying ISE 2.X? I’m six months into it on about 10,000 endpoints and it seems like it’s a highly challenged product. I’d love to hear your experiences on or off-list. Thanks in advance. From jamann at mt.gov Fri Oct 6 20:48:30 2017 From: jamann at mt.gov (Mann, Jason) Date: Fri, 6 Oct 2017 20:48:30 +0000 Subject: Cisco ISE In-Reply-To: <3A8C1FD9-F590-4EEF-B580-CFA39D46B1F6@nola.gov> References: <3A8C1FD9-F590-4EEF-B580-CFA39D46B1F6@nola.gov> Message-ID: As would I. We are going to start a project that is replacing ACS 5.7 with ISE 2.X -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher J. Wolff Sent: Friday, October 6, 2017 2:41 PM To: nanog at nanog.org Subject: Cisco ISE Is anyone successfully deploying ISE 2.X? I’m six months into it on about 10,000 endpoints and it seems like it’s a highly challenged product. I’d love to hear your experiences on or off-list. Thanks in advance. From cjwolff at nola.gov Fri Oct 6 20:53:32 2017 From: cjwolff at nola.gov (Christopher J. Wolff) Date: Fri, 6 Oct 2017 20:53:32 +0000 Subject: Cisco ISE In-Reply-To: References: <3A8C1FD9-F590-4EEF-B580-CFA39D46B1F6@nola.gov>, Message-ID: Proceed with extreme caution. You may want to have that end of life ACS deployment bake for another six months. You will want to have the highest level of Cisco engineering engaged should you choose to go this direction. On Oct 6, 2017, at 3:48 PM, Mann, Jason > wrote: As would I. We are going to start a project that is replacing ACS 5.7 with ISE 2.X -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher J. Wolff Sent: Friday, October 6, 2017 2:41 PM To: nanog at nanog.org Subject: Cisco ISE Is anyone successfully deploying ISE 2.X? I’m six months into it on about 10,000 endpoints and it seems like it’s a highly challenged product. I’d love to hear your experiences on or off-list. Thanks in advance. From synack at live.com Fri Oct 6 21:10:10 2017 From: synack at live.com (Darin Herteen) Date: Fri, 6 Oct 2017 21:10:10 +0000 Subject: Cisco ISE In-Reply-To: References: <3A8C1FD9-F590-4EEF-B580-CFA39D46B1F6@nola.gov>, , Message-ID: Any particular part of the product giving you trouble or just the migration to the product itself ? Running 5.7 here a multi-vendor endpoint environment using both TACACS+ & RADIUS for device administration and have been curious about the pain I may or may not have ahead of me... ________________________________ From: NANOG on behalf of Christopher J. Wolff Sent: Friday, October 6, 2017 3:53 PM To: Mann, Jason Cc: nanog at nanog.org Subject: Re: Cisco ISE Proceed with extreme caution. You may want to have that end of life ACS deployment bake for another six months. You will want to have the highest level of Cisco engineering engaged should you choose to go this direction. On Oct 6, 2017, at 3:48 PM, Mann, Jason > wrote: As would I. We are going to start a project that is replacing ACS 5.7 with ISE 2.X -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher J. Wolff Sent: Friday, October 6, 2017 2:41 PM To: nanog at nanog.org Subject: Cisco ISE Is anyone successfully deploying ISE 2.X? I’m six months into it on about 10,000 endpoints and it seems like it’s a highly challenged product. I’d love to hear your experiences on or off-list. Thanks in advance. From sean at donelan.com Sat Oct 7 01:06:35 2017 From: sean at donelan.com (Sean Donelan) Date: Fri, 6 Oct 2017 21:06:35 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: In addition to government and carriers working on the large-scale infrastructure to restore telecommunications in Puerto Rico, U.S. Virgin Islands and other Caribbean islands; I've found the following non-government organizations with people on the ground in the disaster areas working on communications needed emergency and relief efforts. I've limited this list to those groups I've been able to confirm on the ground response, not just a press release; and to the best of my ability to verify are legitimate organizations. If you know of other non-governmental organizations with on-the-ground teams restoring telecommunications in PR or USVI or other Caribbean islands, let me know. American Red Cross: mobile satellite stations at red cross shelters https://www.redcross.org/ns/apology/disaster_homepage.html ARRL Puerto Rico: Multiple communication efforts in Puerto Rico and U.S. Virigin islands in cooperation with Red Cross and government organizations. http://www.arrl.org/ Global DIRT: installing Vanu cellular terminals and GATR satellite dishes in the US Virgin Islands and Vieques, PR. http://globaldirt.org/ Information Technology Disaster Resource Center: installing voice and wifi networks in remote parts of puerto rico. https://www.itdrc.org/ NetHope: providing connectivity services to the response community and affected communities in puerto rico https://nethope.org/ From jfmezei_nanog at vaxination.ca Sat Oct 7 01:55:46 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 6 Oct 2017 21:55:46 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: I have not ound the official announcements, but the press is reporting that the FCC has granted Google rights to fly 30 of its "Loon" high altitude ballons to provide cellular cervice in Puerto Rico for up to 6 months. (From my readings, there are glorified relays of ground based signals (which I assume some antennas have to be oriented to face up towards the balloons). The Loon will use spectrum allocated to the carriers they relay (and got their OK) Altitude 20km. (so not sure they need 30 balloons, 1 probably suffices to cover all of PR). I suspect more concrete info will be coming. From smoot at tic.com Fri Oct 6 22:03:03 2017 From: smoot at tic.com (Smoot Carl-Mitchell) Date: Fri, 06 Oct 2017 15:03:03 -0700 Subject: Cisco ISE In-Reply-To: <3A8C1FD9-F590-4EEF-B580-CFA39D46B1F6@nola.gov> References: <3A8C1FD9-F590-4EEF-B580-CFA39D46B1F6@nola.gov> Message-ID: <1507327383.7079.114.camel@tic.com> On Fri, 2017-10-06 at 20:41 +0000, Christopher J. Wolff wrote: > Is anyone successfully deploying ISE 2.X?  I’m six months into it on > about 10,000 endpoints and it seems like it’s a highly challenged > product.  I’d love to hear your experiences on or off-list.  Thanks > in advance. ISE is challenging. I helped deploy and manage a 2.1.0.474 installation with about 5,000 end points. The hardest part was designing the access policies There is also some quirkiness depending on what switches you have in your environment. Different switches and different IOS levels require in some cases slightly different switchport configurations. Keeping everything in sync can also be painful. I ended up writing a web based tool to audit the switch configurations. The device profiler is less than perfect. We ended up having to statically configure some of the devices (notably printers and thin clients) to get them authorized correctly. Sometimes the RADIUS sessions from a switch to the ISE servers would hang in odd ways which required shutting and reenabling the port. Looking at the logs on the switches was vital to sorting out various issues. We also have DHCP snooping enabled in our environment which further complicated debugging. Also be aware upgrading the software can be painful and takes a long time. Our last upgrade required 18 hours of time. Mostly this was waiting around for the software to do the upgrade. Having an environment where you have redundancy is really a requirement for deploying ISE. Conversion to ISE also needs to be done switch by switch with lots of hand holding the users. Users do get irritated when their computers no longer work. A good communications plan is vital to be successful. -- Smoot Carl-Mitchell System/Network Architect voice: +1 480 922-7313 cell: +1 602 421-9005 smoot at tic.com From swm at emanon.com Sat Oct 7 03:23:10 2017 From: swm at emanon.com (Scott Morris) Date: Fri, 6 Oct 2017 23:23:10 -0400 Subject: Cisco ISE In-Reply-To: <1507327383.7079.114.camel@tic.com> References: <3A8C1FD9-F590-4EEF-B580-CFA39D46B1F6@nola.gov> <1507327383.7079.114.camel@tic.com> Message-ID: There are other products out there that give more successful results much quicker and with much less effort. While I won’t spam the list with things, I’d be happy to share my experience off-list if desired. Scott -----Original Message----- From: NANOG on behalf of Smoot Carl-Mitchell Date: Friday, October 6, 2017 at 10:09 PM To: "Christopher J. Wolff" , "nanog at nanog.org" Subject: Re: Cisco ISE On Fri, 2017-10-06 at 20:41 +0000, Christopher J. Wolff wrote: > Is anyone successfully deploying ISE 2.X? I’m six months into it on > about 10,000 endpoints and it seems like it’s a highly challenged > product. I’d love to hear your experiences on or off-list. Thanks > in advance. ISE is challenging. I helped deploy and manage a 2.1.0.474 installation with about 5,000 end points. The hardest part was designing the access policies There is also some quirkiness depending on what switches you have in your environment. Different switches and different IOS levels require in some cases slightly different switchport configurations. Keeping everything in sync can also be painful. I ended up writing a web based tool to audit the switch configurations. The device profiler is less than perfect. We ended up having to statically configure some of the devices (notably printers and thin clients) to get them authorized correctly. Sometimes the RADIUS sessions from a switch to the ISE servers would hang in odd ways which required shutting and reenabling the port. Looking at the logs on the switches was vital to sorting out various issues. We also have DHCP snooping enabled in our environment which further complicated debugging. Also be aware upgrading the software can be painful and takes a long time. Our last upgrade required 18 hours of time. Mostly this was waiting around for the software to do the upgrade. Having an environment where you have redundancy is really a requirement for deploying ISE. Conversion to ISE also needs to be done switch by switch with lots of hand holding the users. Users do get irritated when their computers no longer work. A good communications plan is vital to be successful. -- Smoot Carl-Mitchell System/Network Architect voice: +1 480 922-7313 cell: +1 602 421-9005 smoot at tic.com From javier at advancedmachines.us Sat Oct 7 08:02:46 2017 From: javier at advancedmachines.us (Javier J) Date: Sat, 7 Oct 2017 04:02:46 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: @ Jean Interesting stuff. Please keep this thread updated with info on that initiative. On Fri, Oct 6, 2017 at 9:55 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > I have not ound the official announcements, but the press is reporting > that the FCC has granted Google rights to fly 30 of its "Loon" high > altitude ballons to provide cellular cervice in Puerto Rico for up to 6 > months. > > (From my readings, there are glorified relays of ground based signals > (which I assume some antennas have to be oriented to face up towards the > balloons). > > The Loon will use spectrum allocated to the carriers they relay (and got > their OK) > > Altitude 20km. (so not sure they need 30 balloons, 1 probably suffices > to cover all of PR). > > I suspect more concrete info will be coming. > From jamann at mt.gov Sat Oct 7 14:20:53 2017 From: jamann at mt.gov (Mann, Jason) Date: Sat, 7 Oct 2017 14:20:53 +0000 Subject: Cisco ISE In-Reply-To: References: <3A8C1FD9-F590-4EEF-B580-CFA39D46B1F6@nola.gov>, Message-ID: <1507386052811.62085@mt.gov> Yes I would be curious as to what issues you are running into? We currently use ACS to do 802.1x authentication for all of our Wired/Wireless clients and will move that functionality over to ISE. We would also like to start doing provisioning/nac and certificate authority on the ISE, as well as PXGrid into InfoBlox, NetScout, F5, APIC-EM, and Cisco Prime 3.1 -----Original Message----- From: Rheams, Doug [mailto:doug.rheams at franklintempleton.com] Sent: Friday, October 6, 2017 3:01 PM To: Christopher J. Wolff ; Mann, Jason Cc: nanog at nanog.org Subject: RE: Cisco ISE We started at version 1.4 and we're up to 2.1 now but it's just for tacacs and certificate auth without any profiling or posturing. I agree it hasn't been the easiest product but it's working. What type of issues are you running into? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher J. Wolff Sent: Friday, October 6, 2017 1:54 PM To: Mann, Jason Cc: nanog at nanog.org Subject: Re: Cisco ISE Proceed with extreme caution. You may want to have that end of life ACS deployment bake for another six months. You will want to have the highest level of Cisco engineering engaged should you choose to go this direction. On Oct 6, 2017, at 3:48 PM, Mann, Jason > wrote: As would I. We are going to start a project that is replacing ACS 5.7 with ISE 2.X -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher J. Wolff Sent: Friday, October 6, 2017 2:41 PM To: nanog at nanog.org Subject: Cisco ISE Is anyone successfully deploying ISE 2.X? I'm six months into it on about 10,000 endpoints and it seems like it's a highly challenged product. I'd love to hear your experiences on or off-list. Thanks in advance. Notice: All email and instant messages (including attachments) sent to or from Franklin Templeton Investments (FTI) personnel may be retained, monitored and/or reviewed by FTI and its agents, or authorized law enforcement personnel, without further notice or consent. . From nanog at ics-il.net Sun Oct 8 19:59:59 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 8 Oct 2017 14:59:59 -0500 (CDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: <922068048.439733.1507492799553.JavaMail.zimbra@ics-il.net> >From a WISP in USVI A quick perspective from the US Virgin Islands of how the carriers have fared / performed: AT&T = had a couple towers with some cell coverage after Irma and Maria. A testament to good engineering at the tower, and redundancy in their network design. Primarily microwave backhaul, but leasing some fiber from the ILEC named Viya. AT&T has a major undersea cable station and POP on STT in downtown Charlotte Amalie. They have been making progress fixing their network, STX is over 50% fixed 2 weeks after Maria. 75% market share Sprint = 100% down for the 3+ weeks after Irma. They have a single point of failure, relying on 10ft dishes to shoot 20-50 miles, from STT to Puerto Rico. These cheap bastards wouldn’t buy a backup connection from Viya or Broadband VI. I have called them out to the PSC. Still weeks away from anything working. Most of their customers can roam on Viya’s cell network. 15% market share and rapidly declining. Viya = Celluar = 30-50% up, Celluar = 10% market share. Rolling out LTE upgrade. Cable TV/Phone/Internet = 10% up, 75% market share, have a long road to recovery. Have to wait for power company poles to be replaced / fixed before they can repair their badly damaged plant. Broadband VI = WISP = 50% AP's up, 15% of customers. Got up quickly after Irma, STX stayed up, STT had backhaul to every major tower repaired in 5 days. After Maria 100% down. Had to re-aim / repair every major tower on STX, and most of STT. Moving focus from backhaul to repairing AP’s next week. Tower by tower, with installers / subs going to customers in that area (who have power, almost all via generator). In the middle of a Mikrotik 2 Cambium 450 forklift upgrade. Impressive survival rate for Cambium AP’s, and Ceragon IP-20. viNGN = Government fiber middle-mile, lost 90% of their drops because there were aerial. I am off to guide the FEMA re-fuelers to a remote tower which ran out of fuel last night. There have been some lessons learned. I will compile a report in the next few weeks. Mike Meluskey CTO and Founder Broadband VI ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: Javier J To: Jean-Francois Mezei Cc: nanog at nanog.org Sent: Sat, 07 Oct 2017 03:02:46 -0500 (CDT) Subject: Re: Hurricane Maria: Summary of communication status - and lack of @ Jean Interesting stuff. Please keep this thread updated with info on that initiative. On Fri, Oct 6, 2017 at 9:55 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > I have not ound the official announcements, but the press is reporting > that the FCC has granted Google rights to fly 30 of its "Loon" high > altitude ballons to provide cellular cervice in Puerto Rico for up to 6 > months. > > (From my readings, there are glorified relays of ground based signals > (which I assume some antennas have to be oriented to face up towards the > balloons). > > The Loon will use spectrum allocated to the carriers they relay (and got > their OK) > > Altitude 20km. (so not sure they need 30 balloons, 1 probably suffices > to cover all of PR). > > I suspect more concrete info will be coming. > From marka at isc.org Mon Oct 9 01:09:15 2017 From: marka at isc.org (Mark Andrews) Date: Mon, 09 Oct 2017 12:09:15 +1100 Subject: Anyone from AT&T DNS? In-Reply-To: Your message of "Wed, 04 Oct 2017 23:18:25 -0400." <50298399-672D-4BA1-A726-7128B84B89FF@apple.com> References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> <252DB6B0-3537-4DC4-A43B-E20CAB5CEB52@apple.com> <50298399-672D-4BA1-A726-7128B84B89FF@apple.com> Message-ID: <20171009010915.6ECA98A59A77@rock.dv.isc.org> In message <50298399-672D-4BA1-A726-7128B84B89FF at apple.com>, Matt Peterman writes: > Got it! You’re the winner here. I just setup both of my zones the name > way and obviously AT&T changed the way they did RDNS entries from when I > got a /25 last November and this second /25 in June. Oh well! > > Now I am running into the challenge of Route53 does seem to support > creating an authoritative zone for "128/25.168.207.107.in-addr.arpa.” It > changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If > it isn't one thing its something else. Which is "128925.168.207.107.in-addr.arpa." when fed into a domain name parser. DNS escapes sequences are DECIMAL not OCTAL. I suggest that you log a bug report. 128/25.168.207.107.in-addr.arpa. == 128\04725.168.207.107.in-addr.arpa RFC 1035 \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. That said '/' is not special to DNS parsers and shouldn't need to be converted to \DDD. Mark % dig '128\05725.168.207.107.in-addr.arpa' ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0a1+hotspot+add-prefetch+marka <<>> 128\05725.168.207.107.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8078 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ac2bc18c4e18f907a872f2b559dacb6ab6e64fb72a9c71d5 (good) ;; QUESTION SECTION: ;128925.168.207.107.in-addr.arpa. IN A ;; AUTHORITY SECTION: 168.207.107.in-addr.arpa. 3600 IN SOA ns1.swbell.net. rm-hostmaster.ems.att.com. 2 10800 900 604800 7200 ;; Query time: 1244 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 09 12:05:46 AEDT 2017 ;; MSG SIZE rcvd: 163 % % dig '128\04725.168.207.107.in-addr.arpa' ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0a1+hotspot+add-prefetch+marka <<>> 128\04725.168.207.107.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54452 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: e6bdbbdf26697275cf492e9059dacbecc9eb8186d940bd69 (good) ;; QUESTION SECTION: ;128/25.168.207.107.in-addr.arpa. IN A ;; AUTHORITY SECTION: 128/25.168.207.107.in-addr.arpa. 900 IN SOA ns-1746.awsdns-26.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ;; Query time: 1142 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 09 12:07:56 AEDT 2017 ;; MSG SIZE rcvd: 175 % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Mon Oct 9 01:42:48 2017 From: marka at isc.org (Mark Andrews) Date: Mon, 09 Oct 2017 12:42:48 +1100 Subject: Anyone from AT&T DNS? In-Reply-To: Your message of "Thu, 05 Oct 2017 04:12:30 -0400." References: <044FD0AF-3B6D-412A-AC07-265A4F0CDD50@apple.com> <252DB6B0-3537-4DC4-A43B-E20CAB5CEB52@apple.com> <50298399-672D-4BA1-A726-7128B84B89FF@apple.com> <41BF05F7-FEF7-45AB-BF43-E30C57D0DB1E@apple.com> Message-ID: <20171009014248.BF8198A59FE6@rock.dv.isc.org> In message , Jay Farrell via NANOG writes: > Yep, the notation with the slash used to be ATT's standard method. At my > job (where we had some customers with ATT MIS T1 circuits) we transitioned > to a web front end for our DNS that didn't allow for the slash, so we had > to nudge ATT to allow us to use a dash notation instead for delegations. > > As far as to what can appear in a DNS entry, you'd be amazed. I encountered > a PTR record containing a full URL, http:// and everything; it didn't > actually work of course, but bind allowed it to exist. When I tracked down > the cow-orker who had entered it, he said he knew it wasn't valid, but he > did it that way when the customer insisted it had to be thus. :-D DNS labels can be octet string [0..63] with the zero length octet string being being reserved or the root label and '*' for the wildcard label (there is no way to turn this off). Hostnames on the other hand are restricted to LDH. Unfortunately many tools are not written by people who understand the difference. Additionally lots of administrators also don't know the difference. They also often don't understand why hostnames are restricted to LDH. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sean at donelan.com Tue Oct 10 04:47:21 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 10 Oct 2017 00:47:21 -0400 (EDT) Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: The Puerto Rico government has posted threee maps of cellular coverage and GPS coordinates of Cells on Wheels (COWs) in service. http://www.status.pr/Maps/ It still looks grim in Puerto Ricofrom a telecommunications perspective. Its will be an interesting after-action study. Other than "it was a hurricane," I haven't gotten a good idea why so much of the telecommunications network failed and backups still aren't working more than 2 weeks later. Claro, the ILEC but second in terms of mobile phone marketshare behind AT&T, has started to more fully explain what "restored" means, and that it doesn't mean everything as before the hurricane. It is minimum telecommunications. Claro has been more willing to talk about the situation in Puerto Rico, which is why I've referencing Claro a lot more than other carriers. This is a google translate of an interview from spanish. "It is important to clarify that the radio bases put into service to date, offer the same voice and data services as before the impact of the Hurricane. In other words, if the base radio is 4GLTE, that is the service it will offer. The other two components that influence the customer experience are the voice and data plan and the equipment of each user." "The network is also open to third-party customers as part of our commitment to connect everyone in the country. In fact, over a quarter of a million customers from other providers have connected daily to the Claro network. When these customers connect to our network they only have voice service as stipulated in the roaming agreement with the other providers. As for the fixed network, this morning the service was restored in the central offices (OC) of Fajardo and Humacao, whose optical fibers had been affected by the destruction of Hurricane Maria. In this way already have fixed voice, internet and long distance services in these municipalities: Ceiba, Fajardo, Luquillo, Humacao, Naguabo and Yabucoa. Already a total of 57 municipalities have all 3 services. It is possible that some customers of Claro served by these OCs do not have internet. This is possible as there could be cables and posts broken and / or VRADs without AEE service." https://www.metro.pr/pr/noticias/2017/10/06/senal-claro-esta-ya-accesible-34-municipios.html From web at typo.org Tue Oct 10 05:28:51 2017 From: web at typo.org (Wayne Bouchard) Date: Mon, 9 Oct 2017 22:28:51 -0700 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: <20171010052851.GA43108@spider.typo.org> Please note that there is another looming problem with restoration of services generally (not just telecommunications). The key here is the power grid. >From what I have read, a great deal of the operating infrastructure is operating on backup generator. These generators are not meant for this duty cycle. (Recall that most units are sized such that they will be providing ~70% output if not higher and thus will run hard.) It will not be long before some of them begin to fail. Even if they can keep running for the longer term, they need to be shut down every so many hours for service (oil change, etc.) Depending on the unit, that may be measured in the hundreds of hours. One week is 168 hours. One month is 720 hours. Fail to do this and the unit evntually becomes a big pile of scrap metal. Any facility, beit a pumping station, hospital, airport, cell tower, central office, or sewage plant that must rely on generators for the foreseeable future must consider this. On Tue, Oct 10, 2017 at 12:47:21AM -0400, Sean Donelan wrote: > > The Puerto Rico government has posted threee maps of cellular coverage and > GPS coordinates of Cells on Wheels (COWs) in service. > > http://www.status.pr/Maps/ > > It still looks grim in Puerto Ricofrom a telecommunications perspective. > Its will be an interesting after-action study. Other than "it was a > hurricane," I haven't gotten a good idea why so much of the > telecommunications network failed and backups still aren't working more > than 2 weeks later. > > Claro, the ILEC but second in terms of mobile phone marketshare behind > AT&T, has started to more fully explain what "restored" means, and that > it doesn't mean everything as before the hurricane. It is minimum > telecommunications. Claro has been more willing to talk about the > situation in Puerto Rico, which is why I've referencing Claro a lot more > than other carriers. > > This is a google translate of an interview from spanish. > > "It is important to clarify that the radio bases put into service to date, > offer the same voice and data services as before the impact of the > Hurricane. In other words, if the base radio is 4GLTE, that is the service > it will offer. The other two components that influence the customer > experience are the voice and data plan and the equipment of each user." > > "The network is also open to third-party customers as part of our > commitment to connect everyone in the country. In fact, over a quarter of > a million customers from other providers have connected daily to the Claro > network. When these customers connect to our network they only have voice > service as stipulated in the roaming agreement with the other providers. > As for the fixed network, this morning the service was restored in the > central offices (OC) of Fajardo and Humacao, whose optical fibers had been > affected by the destruction of Hurricane Maria. In this way already have > fixed voice, internet and long distance services in these municipalities: > Ceiba, Fajardo, Luquillo, Humacao, Naguabo and Yabucoa. Already a total of > 57 municipalities have all 3 services. It is possible that some customers > of Claro served by these OCs do not have internet. This is possible as > there could be cables and posts broken and / or VRADs without AEE > service." > > https://www.metro.pr/pr/noticias/2017/10/06/senal-claro-esta-ya-accesible-34-municipios.html --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From jfmezei_nanog at vaxination.ca Tue Oct 10 07:39:50 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 10 Oct 2017 03:39:50 -0400 Subject: Hurricane Maria: Summary of communication status - and lack of In-Reply-To: References: Message-ID: On 2017-10-10 00:47, Sean Donelan wrote: > > The Puerto Rico government has posted threee maps of cellular coverage and > GPS coordinates of Cells on Wheels (COWs) in service. > > http://www.status.pr/Maps/ > > It still looks grim in Puerto Ricofrom a telecommunications perspective. I found the coverage maps to be better than I would have expected. > Claro, the ILEC but second in terms of mobile phone marketshare behind > AT&T, Do AT&T and T_Mobile have much actual infrastructure or do they tend to roam or network share with Claro? From what I read, Sprint/Verizon ride on the Open Mobile network as it is the only one still providing CDMA signal. Of course a round coverage dot on the map which provide CDMA is of little use to those who have GSM phones (and vice versa). (I guess LTE roaming between Open Mobile and the GSM guys would work?) > has started to more fully explain what "restored" means, and that > it doesn't mean everything as before the hurricane. It is minimum > telecommunications. I would expect that priority is in expanding coverage, not capacity. Light up the one tower at the top of the hill with sub 1ghz band to have farthest reach. But that means lots of people on same tower, hence lower capacity per person. The maps still show lots of individual round circles. > Claro has been more willing to talk about the > situation in Puerto Rico, which is why I've referencing Claro a lot more > than other carriers. If AT&T and T_Mobile rely a lot of Claro, this could explain a lot why Claro is the one speaking out since it is its radios/antennae that are being lighted up and it would be the one with the info on work/progress. (and I suspect AT&T and T-Mo would provide crews to helop Claro restore basic service first). From jwm at horde.net Mon Oct 9 18:56:25 2017 From: jwm at horde.net (John Morrissey) Date: Mon, 9 Oct 2017 14:56:25 -0400 Subject: Clueful contact at Microsoft for Office365? Message-ID: <20171009185625.6o2cqnnpcj7x2svp@boost.horde.net> Anyone have a clueful contact at Microsoft for Office365? We're having some deliverability issues, and haven't gotten anywhere by going through normal channels. The joys of turning up e-mail for a new domain, I guess. :-/ -john From tnolen at internetpro.net Mon Oct 9 13:42:07 2017 From: tnolen at internetpro.net (Trey Nolen) Date: Mon, 9 Oct 2017 08:42:07 -0500 Subject: contact ATT Message-ID: <7ec98da0-6467-5c69-86ed-9fcfeb07714d@internetpro.net> We have a managed router which AT&T has put in place.   Because it is managed, we do not have control over the router.   It is going down every 5 to 6 days.  We were assured that it was a known issue for the model we have and worked for over 2 weeks to get the firmware updated.   The update did not fix the problem and we desperately need to find someone at AT&T who has the authority to replace this router.   If someone can contact me off list to help me get this accomplished, I'll be glad to furnish the tickets for circuit history and such.    Thanks. Trey Nolen From ghenry at suretec.co.uk Tue Oct 10 16:19:14 2017 From: ghenry at suretec.co.uk (Gavin Henry) Date: Tue, 10 Oct 2017 17:19:14 +0100 Subject: ATT NOC Message-ID: Hi all, For a while now (11 days) we've been trying to reach ATT as it some of our traffic is dying within their network. It's traffic destined for their customer networks so we can't raise a ticket with ATT directly. We've emailed their NOC, but nothing and since then been trying to raise tickes via phone with their customers that we can't reach, but we're not their customers either....I'm pretty certain one of our /22 is getting dropped, as our other /22 works (we're small guys). Can anyone help confirm our theory by putting us in touch? Thanks. -- Kind Regards, Gavin Henry. Managing Director. From ghenry at suretec.co.uk Tue Oct 10 16:35:49 2017 From: ghenry at suretec.co.uk (Gavin Henry) Date: Tue, 10 Oct 2017 17:35:49 +0100 Subject: ATT NOC In-Reply-To: References: Message-ID: Hi Nimrod, Sorry. Our resolvers that are having the issue live at: 185.8.92.12 185.8.92.13 part of 185.8.92.0/22 Destination IP's we're trying to reach are: dns4.hertz.com has address 12.5.245.250 dns5.hertz.com has address 12.147.231.250 dns6.hertz.com has address 12.28.81.250 These live within in our routing table: 12.5.245.0/24 12.147.231.0/24 12.28.81.0/24 Thanks. From ghenry at suretec.co.uk Tue Oct 10 17:00:46 2017 From: ghenry at suretec.co.uk (Gavin Henry) Date: Tue, 10 Oct 2017 18:00:46 +0100 Subject: ATT NOC In-Reply-To: References: Message-ID: On 10 October 2017 at 17:47, Nimrod Levy wrote: > We're not accepting the route from our peers due to the AS-SET in the path: > 174 199659 {65002}, (aggregated by 199659 10.10.10.3), (received-only) > 2914 199659 {65002}, (aggregated by 199659 10.10.10.1), (received-only) Thanks Nimrod, I'll speak to our transit providers again to see where 65002 is coming from. Gavin. From bryan at shout.net Tue Oct 10 17:48:43 2017 From: bryan at shout.net (Bryan Holloway) Date: Tue, 10 Oct 2017 12:48:43 -0500 Subject: TWCC engineer lurking? Message-ID: TWCC erroneously shut down one of our East coast circuits, and we keep getting bounced around from department to department, even though accounting has conceded that the circuit is fine and should be up. If anyone could assist, please contact me off-list? Thanks! From sean at donelan.com Tue Oct 10 18:02:03 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 10 Oct 2017 14:02:03 -0400 (EDT) Subject: California wildfires - communications status Message-ID: There have been many large wildfires in western states for the last couple of months, but most have been in less populated areas. Several folks have asked about cell phone problems because of the fires in California. Sonoma and Napa county sheriff departments are reporting widespread power outages, and spotty cell phone service in those counties. No specifics about how many cell towers are impacted. Landlines seem to be less affected. Comcast has announced open access to its WiFi access points in Napa and Sonoma county. From sean at donelan.com Tue Oct 10 18:25:28 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 10 Oct 2017 14:25:28 -0400 (EDT) Subject: California wildfires - communications status In-Reply-To: References: Message-ID: Expanding the area, Humboldt and Mendocino County sheriffs are reporting damage to a fiber-optic line has cut-off communications for parts of those counties. They are using amateur ham radio operators at hospitals and sheriff station for communications. AT&T and Verizon have confirmed telecommunications problems in California. But didn't provide any details about the problems. From sean at donelan.com Tue Oct 10 20:16:56 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 10 Oct 2017 16:16:56 -0400 (EDT) Subject: California wildfires - communications status In-Reply-To: References: Message-ID: >From Califonira Office of Emergency Services 77 cellular-services sites were damaged or out of service (35 repaired) A key cellular hub was damaged (location not provided) >From Comcast 38,000 subscribers out of service Xfinity WiFi hotspots are available for free in the area until Friday Providing WiFi hotspots in 33 evacuation centers >From AT&T Network disaster recovery teams deployed, mobile Cells On Wheels (COWs) being deployed >From T-Mobile Some cell service disrupted in California >From Sprint impact on customers "minimal," cable connecting cell towers was cut by the fire. Waiting for safety clearance from authorities to enter area to repair. >From Verizon Working to restore interrupted cell service in Napa, Sonoma, Lake and Mendocino counties where permitted by authorities and safe to access From ghenry at suretec.co.uk Tue Oct 10 20:58:05 2017 From: ghenry at suretec.co.uk (Gavin Henry) Date: Tue, 10 Oct 2017 21:58:05 +0100 Subject: ATT NOC In-Reply-To: References: Message-ID: Hi all, In an effort to embarrass myself and let someone else stumble across this, I did not have remove-private on our transit sessions and AS65002 leaked out. It seems Cogent removed it though. NTT and Level3 trusted us. I've added this to those groups and peering groups. Really appreciate the feedback and help from all and shows who is doing AS-SET right. Gavin. From sean at donelan.com Tue Oct 10 23:19:15 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 10 Oct 2017 19:19:15 -0400 (EDT) Subject: Why don't large carriers use alternate communication routes? Message-ID: This is an op-ed, but most California internet folks know about recurring outages for a decade on this fiber route. What was unusual is the local governments eventually used public funds to help pay for an east-west alternate fiber route. Instead of leasing capacity on alternate routes, the dominate carrier continued to use the single fiber route (which it owns). And the customer outages continue. Are the penalties for subscribe outages so minimal that it makes business sense not to use backup alternate routes? https://lostcoastoutpost.com/2017/oct/10/two-years-ago-t-promised-end-mass-telecommunicatio/ Two Years Ago, AT&T Promised to End Mass Telecommunication Outages. How’s That Working Out? From nanog at radu-adrian.feurdean.net Wed Oct 11 08:52:30 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Wed, 11 Oct 2017 10:52:30 +0200 Subject: Question about Customer Population by ASN for Canada In-Reply-To: References: <89bfb35b-fe89-98ff-95e9-985c84dd16f6@lists.esoteric.ca> Message-ID: <1507711950.4056945.1134959840.41A2E094@webmail.messagingengine.com> On Mon, Oct 2, 2017, at 22:15, Filip Hruska wrote: > * OVH is also a home ISP - just in France though; but not sure if/how > APNIC separated OVH as an ISP and OVH as a server provider. > I think it's all under the same ASN (might be wrong though) Hi, OVH ISP uses a slightly weird set-up: - separate AS for residentian IPv4 ranges. That AS is only seen in GRT via OVH main AS. - IPv6 is provided from the "main pool", advertised by the main AS. And yes, their hosting business hosts tons of VPNs (on VPS or dedicated servers) which are also used by a number of french users in order to get decent internet performance (for the case when their ISP does saturate transit - which is every day 17h-24h). From dhubbard at dino.hostasaurus.com Wed Oct 11 12:31:41 2017 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 11 Oct 2017 12:31:41 +0000 Subject: Temp at Level 3 data centers Message-ID: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> Curious if anyone on here colo’s equipment at a Level 3 facility and has found the temperature unacceptably warm? I’m having that experience currently, where ambient temp is in the 80’s, but they tell me that’s perfectly fine because vented tiles have been placed in front of all equipment racks. My equipment is alarming for high temps, so obviously not fine. Trying to find my way up to whomever I can complain to that’s in a position to do something about it but it seems the support staff have been told to brush questions about temp off as much as possible. Was wondering if this is a country-wide thing for them or unique to the data center I have equipment in. I have equipment in several others from different companies and most are probably 15-20 degrees cooler. Thanks, David From bicknell at ufp.org Wed Oct 11 13:23:06 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 Oct 2017 06:23:06 -0700 Subject: Why don't large carriers use alternate communication routes? In-Reply-To: References: Message-ID: <20171011132306.GA6210@ussenterprise.ufp.org> In a message written on Tue, Oct 10, 2017 at 07:19:15PM -0400, Sean Donelan wrote: > Are the penalties for subscribe outages so minimal that it makes business > sense not to use backup alternate routes? There are penalties for subscriber outages? Do tell! Where? -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From nimrodl at gmail.com Tue Oct 10 16:30:59 2017 From: nimrodl at gmail.com (Nimrod Levy) Date: Tue, 10 Oct 2017 16:30:59 +0000 Subject: ATT NOC In-Reply-To: References: Message-ID: Please provide source and destination. On Tue, Oct 10, 2017 at 12:22 PM Gavin Henry wrote: > Hi all, > > For a while now (11 days) we've been trying to reach ATT as it some of > our traffic is dying within their network. It's traffic destined for > their customer networks so we can't raise a ticket with ATT directly. > We've emailed their NOC, but nothing and since then been trying to > raise tickes via phone with their customers that we can't reach, but > we're not their customers either....I'm pretty certain one of our /22 > is getting dropped, as our other /22 works (we're small guys). > > Can anyone help confirm our theory by putting us in touch? > > Thanks. > > -- > Kind Regards, > > Gavin Henry. > Managing Director. > -- -- Nimrod From nimrodl at gmail.com Tue Oct 10 16:47:25 2017 From: nimrodl at gmail.com (Nimrod Levy) Date: Tue, 10 Oct 2017 16:47:25 +0000 Subject: ATT NOC In-Reply-To: References: Message-ID: We're not accepting the route from our peers due to the AS-SET in the path: 174 199659 {65002}, (aggregated by 199659 10.10.10.3), (received-only) 2914 199659 {65002}, (aggregated by 199659 10.10.10.1), (received-only) On Tue, Oct 10, 2017 at 12:35 PM Gavin Henry wrote: > Hi Nimrod, > > Sorry. Our resolvers that are having the issue live at: > > 185.8.92.12 > 185.8.92.13 > > part of 185.8.92.0/22 > > Destination IP's we're trying to reach are: > > dns4.hertz.com has address 12.5.245.250 > dns5.hertz.com has address 12.147.231.250 > dns6.hertz.com has address 12.28.81.250 > > These live within in our routing table: > > 12.5.245.0/24 > 12.147.231.0/24 > 12.28.81.0/24 > > Thanks. > -- -- Nimrod From sam at coeosolutions.com Wed Oct 11 14:42:54 2017 From: sam at coeosolutions.com (Sam Kretchmer) Date: Wed, 11 Oct 2017 14:42:54 +0000 Subject: Temp at Level 3 data centers In-Reply-To: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> Message-ID: with a former employer we had a suite at the L3 facility on Canal in Chicago. They had this exact issue for the entire time we had the suite. They kept blaming a failing HVAC unit on our floor, but it went on for years no matter who we complained to, or what we said. Good luck. On 10/11/17, 7:31 AM, "NANOG on behalf of David Hubbard" wrote: >Curious if anyone on here colo¹s equipment at a Level 3 facility and has >found the temperature unacceptably warm? I¹m having that experience >currently, where ambient temp is in the 80¹s, but they tell me that¹s >perfectly fine because vented tiles have been placed in front of all >equipment racks. My equipment is alarming for high temps, so obviously >not fine. Trying to find my way up to whomever I can complain to that¹s >in a position to do something about it but it seems the support staff >have been told to brush questions about temp off as much as possible. >Was wondering if this is a country-wide thing for them or unique to the >data center I have equipment in. I have equipment in several others from >different companies and most are probably 15-20 degrees cooler. > >Thanks, > >David From Jacques.Latour at cira.ca Wed Oct 11 15:40:51 2017 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Wed, 11 Oct 2017 15:40:51 +0000 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover Message-ID: Hi, Does anyone know if there's fibre resiliency between Calgary and Toronto over the Great lakes, I thinking redundancy could be achieved by using two paths one following the railroad and the other following the Trans-Canadian highway. Does anyone know if there is fibre following the Trans-Canadian highway and who owns it? Is this achievable? Thanks, Jacques CTO, CIRA From keiths at neilltech.com Wed Oct 11 15:45:30 2017 From: keiths at neilltech.com (Keith Stokes) Date: Wed, 11 Oct 2017 15:45:30 +0000 Subject: Temp at Level 3 data centers In-Reply-To: References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> Message-ID: <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> There are plenty of people who say 80+ is fine for equipment and data centers aren’t built for people. However other things have to be done correctly. Are you sure your equipment is properly oriented for airflow (hot/cold aisles if in use) and has no restrictions? On Oct 11, 2017, at 9:42 AM, Sam Kretchmer > wrote: with a former employer we had a suite at the L3 facility on Canal in Chicago. They had this exact issue for the entire time we had the suite. They kept blaming a failing HVAC unit on our floor, but it went on for years no matter who we complained to, or what we said. Good luck. On 10/11/17, 7:31 AM, "NANOG on behalf of David Hubbard" on behalf of dhubbard at dino.hostasaurus.com> wrote: Curious if anyone on here colo¹s equipment at a Level 3 facility and has found the temperature unacceptably warm? I¹m having that experience currently, where ambient temp is in the 80¹s, but they tell me that¹s perfectly fine because vented tiles have been placed in front of all equipment racks. My equipment is alarming for high temps, so obviously not fine. Trying to find my way up to whomever I can complain to that¹s in a position to do something about it but it seems the support staff have been told to brush questions about temp off as much as possible. Was wondering if this is a country-wide thing for them or unique to the data center I have equipment in. I have equipment in several others from different companies and most are probably 15-20 degrees cooler. Thanks, David --- Keith Stokes From math at sizone.org Wed Oct 11 15:53:24 2017 From: math at sizone.org (Ken Chase) Date: Wed, 11 Oct 2017 11:53:24 -0400 Subject: Temp at Level 3 data centers In-Reply-To: <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> Message-ID: <20171011155324.GC8671@sizone.org> My house isnt built for moving furniture, it's built for living in. I've not moved a bed in or out of the bedroom in 8 years now. But for the 15 minutes I did move a bed, the door and hallway had to accomodate it. Humans have to go into datacenters - often in an emergency. Complicating the servicing of equipment by having sweat drip off you into the electronics is not condusive to uptime. /kc On Wed, Oct 11, 2017 at 03:45:30PM +0000, Keith Stokes said: >There are plenty of people who say 80+ is fine for equipment and data centers aren???t built for people. > >However other things have to be done correctly. > >Are you sure your equipment is properly oriented for airflow (hot/cold aisles if in use) and has no restrictions? > >On Oct 11, 2017, at 9:42 AM, Sam Kretchmer > wrote: > >with a former employer we had a suite at the L3 facility on Canal in >Chicago. They had this exact issue for the entire time we had the suite. >They kept blaming a failing HVAC unit on our floor, but it went on for >years no matter who we complained to, or what we said. > >Good luck. > > >On 10/11/17, 7:31 AM, "NANOG on behalf of David Hubbard" > on behalf of dhubbard at dino.hostasaurus.com> wrote: > >Curious if anyone on here colo??s equipment at a Level 3 facility and has >found the temperature unacceptably warm? I??m having that experience >currently, where ambient temp is in the 80??s, but they tell me that??s >perfectly fine because vented tiles have been placed in front of all >equipment racks. My equipment is alarming for high temps, so obviously >not fine. Trying to find my way up to whomever I can complain to that??s >in a position to do something about it but it seems the support staff >have been told to brush questions about temp off as much as possible. >Was wondering if this is a country-wide thing for them or unique to the >data center I have equipment in. I have equipment in several others from >different companies and most are probably 15-20 degrees cooler. > >Thanks, > >David > > > >--- > >Keith Stokes > > > > /kc -- Ken Chase - math at sizone.org Guelph Canada From zacharyw09264 at gmail.com Wed Oct 11 16:54:26 2017 From: zacharyw09264 at gmail.com (Zachary Winnerman) Date: Wed, 11 Oct 2017 12:54:26 -0400 Subject: Temp at Level 3 data centers In-Reply-To: <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> Message-ID: <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> I recall some evidence that 80+F temps can reduce hard drive lifetime, though it might be outdated as it was from before SSDs were around. I would imagine that while it may not impact the ability for a server to handle load, it may reduce equipment lifetime. It also could be an indication that they lack redundancy in the case of an AC failure. This could cause equipment damage if the datacenter is unattended and temperatures are allowed to rise. On 2017年10月11日 11:45, Keith Stokes wrote: > There are plenty of people who say 80+ is fine for equipment and data centers aren’t built for people. > > However other things have to be done correctly. > > Are you sure your equipment is properly oriented for airflow (hot/cold aisles if in use) and has no restrictions? > > On Oct 11, 2017, at 9:42 AM, Sam Kretchmer > wrote: > > with a former employer we had a suite at the L3 facility on Canal in > Chicago. They had this exact issue for the entire time we had the suite. > They kept blaming a failing HVAC unit on our floor, but it went on for > years no matter who we complained to, or what we said. > > Good luck. > > > On 10/11/17, 7:31 AM, "NANOG on behalf of David Hubbard" > on behalf of dhubbard at dino.hostasaurus.com> wrote: > > Curious if anyone on here colo¹s equipment at a Level 3 facility and has > found the temperature unacceptably warm? I¹m having that experience > currently, where ambient temp is in the 80¹s, but they tell me that¹s > perfectly fine because vented tiles have been placed in front of all > equipment racks. My equipment is alarming for high temps, so obviously > not fine. Trying to find my way up to whomever I can complain to that¹s > in a position to do something about it but it seems the support staff > have been told to brush questions about temp off as much as possible. > Was wondering if this is a country-wide thing for them or unique to the > data center I have equipment in. I have equipment in several others from > different companies and most are probably 15-20 degrees cooler. > > Thanks, > > David > > > > --- > > Keith Stokes > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From josh at kyneticwifi.com Wed Oct 11 17:00:20 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Wed, 11 Oct 2017 12:00:20 -0500 Subject: Temp at Level 3 data centers In-Reply-To: <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> Message-ID: http://www.datacenterknowledge.com/archives/2008/10/14/google-raise-your-data-center-temperature On Oct 11, 2017 11:56 AM, "Zachary Winnerman" wrote: > I recall some evidence that 80+F temps can reduce hard drive lifetime, > though it might be outdated as it was from before SSDs were around. I > would imagine that while it may not impact the ability for a server to > handle load, it may reduce equipment lifetime. It also could be an > indication that they lack redundancy in the case of an AC failure. This > could cause equipment damage if the datacenter is unattended and > temperatures are allowed to rise. > > > On 2017年10月11日 11:45, Keith Stokes wrote: > > There are plenty of people who say 80+ is fine for equipment and data > centers aren’t built for people. > > > > However other things have to be done correctly. > > > > Are you sure your equipment is properly oriented for airflow (hot/cold > aisles if in use) and has no restrictions? > > > > On Oct 11, 2017, at 9:42 AM, Sam Kretchmer > wrote: > > > > with a former employer we had a suite at the L3 facility on Canal in > > Chicago. They had this exact issue for the entire time we had the suite. > > They kept blaming a failing HVAC unit on our floor, but it went on for > > years no matter who we complained to, or what we said. > > > > Good luck. > > > > > > On 10/11/17, 7:31 AM, "NANOG on behalf of David Hubbard" > > on behalf of > dhubbard at dino.hostasaurus.com> > wrote: > > > > Curious if anyone on here colo¹s equipment at a Level 3 facility and has > > found the temperature unacceptably warm? I¹m having that experience > > currently, where ambient temp is in the 80¹s, but they tell me that¹s > > perfectly fine because vented tiles have been placed in front of all > > equipment racks. My equipment is alarming for high temps, so obviously > > not fine. Trying to find my way up to whomever I can complain to that¹s > > in a position to do something about it but it seems the support staff > > have been told to brush questions about temp off as much as possible. > > Was wondering if this is a country-wide thing for them or unique to the > > data center I have equipment in. I have equipment in several others from > > different companies and most are probably 15-20 degrees cooler. > > > > Thanks, > > > > David > > > > > > > > --- > > > > Keith Stokes > > > > > > > > > > > From bicknell at ufp.org Wed Oct 11 17:05:56 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 Oct 2017 10:05:56 -0700 Subject: Temp at Level 3 data centers In-Reply-To: <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> Message-ID: <20171011170556.GA12774@ussenterprise.ufp.org> In a message written on Wed, Oct 11, 2017 at 12:54:26PM -0400, Zachary Winnerman wrote: > I recall some evidence that 80+F temps can reduce hard drive lifetime, > though it might be outdated as it was from before SSDs were around. I This is very much a "your infrastructure may vary" situation. The servers we're currently buying when speced with SSD only and the correct network card (generally meaning RJ45 only, but there are exceptions) are waranteed for 105 degree inlet operations. While we do not do "high temperature operations" we have seen operations where folks run them at 90-100 degree input chasing effiency. Famously, Intel ran computers outside in a tent just to prove it works fine: https://www.computerworld.com/article/2533138/data-center/running-servers-in-a-tent-outside--it-works.html It should be easy to purchase equipment that can tolerate 80-90 degree input without damage. But that's not the question here. The question is if the temp is within the range specified in the contract. If it is, deal with it, and if it is not, hold your vendor to delivering what they promised. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From zacharyw09264 at gmail.com Wed Oct 11 17:08:33 2017 From: zacharyw09264 at gmail.com (Zachary Winnerman) Date: Wed, 11 Oct 2017 13:08:33 -0400 Subject: Temp at Level 3 data centers In-Reply-To: References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> Message-ID: <85f956d1-1796-80ea-b40a-74493f0fc100@gmail.com> That's a good point, though if you are running your breakers that close I think you have bigger problems, as a power outage, however unlikely, could cause your equipment to not come back up at all. Software updates that reboot several servers in quick succession could also cause a breaker to trip under those circumstances. Unfortunately, there's no way to tell how close a breaker is to tripping without tripping it. Breakers may have amp meteres and a rated size, but the actual load before tripping is +-20% for common models, meaning a 20A breaker may trip as low as 16A. On 2017年10月11日 12:58, Matt Harris wrote: > Another thing to remember - and I've actually seen breakers tripped on > PDUs due to heat before because of this - is that it's going to spin > all of your fans harder to keep internal temps down if the ambient > temp is higher. This will increase your power draw, which means that > if you're paying for metered power by usage, you're going to pay more > - those fans really do add up in terms of power. In extreme cases, you > can draw too much power and trip a breaker on a PDU because every host > in a rack, or especially those towards the top, are spinning full > tilt. It's not a good condition and one that you should force them to > correct.  > > > On Wed, Oct 11, 2017 at 11:54 AM, Zachary Winnerman > > wrote: > > I recall some evidence that 80+F temps can reduce hard drive lifetime, > though it might be outdated as it was from before SSDs were around. I > would imagine that while it may not impact the ability for a server to > handle load, it may reduce equipment lifetime. It also could be an > indication that they lack redundancy in the case of an AC failure. > This > could cause equipment damage if the datacenter is unattended and > temperatures are allowed to rise. > > > On 2017年10月11日 11:45, Keith Stokes wrote: > > There are plenty of people who say 80+ is fine for equipment and > data centers aren’t built for people. > > > > However other things have to be done correctly. > > > > Are you sure your equipment is properly oriented for airflow > (hot/cold aisles if in use) and has no restrictions? > > > > On Oct 11, 2017, at 9:42 AM, Sam Kretchmer > >> wrote: > > > > with a former employer we had a suite at the L3 facility on Canal in > > Chicago. They had this exact issue for the entire time we had > the suite. > > They kept blaming a failing HVAC unit on our floor, but it went > on for > > years no matter who we complained to, or what we said. > > > > Good luck. > > > > > > On 10/11/17, 7:31 AM, "NANOG on behalf of David Hubbard" > > > on behalf of > dhubbard at dino.hostasaurus.com > >> wrote: > > > > Curious if anyone on here colo¹s equipment at a Level 3 facility > and has > > found the temperature unacceptably warm?  I¹m having that experience > > currently, where ambient temp is in the 80¹s, but they tell me > that¹s > > perfectly fine because vented tiles have been placed in front of all > > equipment racks.  My equipment is alarming for high temps, so > obviously > > not fine.  Trying to find my way up to whomever I can complain > to that¹s > > in a position to do something about it but it seems the support > staff > > have been told to brush questions about temp off as much as > possible. > > Was wondering if this is a country-wide thing for them or unique > to the > > data center I have equipment in.  I have equipment in several > others from > > different companies and most are probably 15-20 degrees cooler. > > > > Thanks, > > > > David > > > > > > > > --- > > > > Keith Stokes > > > > > > > > > > > > > > -- > Matt Harris - Chief Security Officer > Main: +1 855.696.3834 ext 103 > Mobile: +1 908.590.9472 > Email: matt at netfire.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From SNaslund at medline.com Wed Oct 11 17:09:33 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 11 Oct 2017 17:09:33 +0000 Subject: Temp at Level 3 data centers In-Reply-To: <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> If the ambient temperature is higher is means the temperatures throughout the device would be higher and the temp at those points is what really matters. I would also be concerned because if they lose one of the a/c units what would the ambient temperature rise to? I would want them to tell me what the set point of the a/c actually is. Bottom line 80 F input air is too hot in my opinion and apparently the equipment's opinion as well. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Zachary Winnerman >Sent: Wednesday, October 11, 2017 11:54 AM >To: nanog at nanog.org >Subject: Re: Temp at Level 3 data centers > >I recall some evidence that 80+F temps can reduce hard drive lifetime, though it might be outdated as it was from before SSDs were around. I would imagine that while it may not impact the ability for a server to handle load, it may >reduce equipment lifetime. It also could be an indication that they lack redundancy in the case of an AC failure. This could cause equipment damage if the datacenter is unattended and temperatures are allowed to rise. From SNaslund at medline.com Wed Oct 11 17:13:40 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 11 Oct 2017 17:13:40 +0000 Subject: Temp at Level 3 data centers In-Reply-To: <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40262155CD5@MUNPRDMBXA1.medline.com> I think the key here is that if your set point is at 80 F, you better be able to hit it with a unit down and you better be able to react instantly to any environmental failure. You just have no headroom to play with. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Zachary Winnerman >Sent: Wednesday, October 11, 2017 11:54 AM >To: nanog at nanog.org >Subject: Re: Temp at Level 3 data centers > >I recall some evidence that 80+F temps can reduce hard drive lifetime, though it might be outdated as it was from before SSDs were around. I would imagine that while it may not impact the ability for a server to handle load, it may >reduce equipment lifetime. It also could be an indication that they lack redundancy in the case of an AC failure. This could cause equipment damage if the datacenter is unattended and temperatures are allowed to rise. From jhaustin at gmail.com Wed Oct 11 17:25:49 2017 From: jhaustin at gmail.com (Jeremy Austin) Date: Wed, 11 Oct 2017 10:25:49 -0700 Subject: Temp at Level 3 data centers In-Reply-To: <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> Message-ID: My 0.0000041 BTC: 1) For small facilities, without separate temperature-controlled UPS zones, the optimum temperature for lead-acid batteries may be the lower bound. 77°F is optimal, with significant reduction in battery life even 15°F above that. Given that batteries' internal temperature will be higher than ambient, 80° set point is not stupid. I run cooler, FWIW. 2) Headroom. I try to have documented for each facility the climb in degrees per hour (determined empirically) as a backup so I know required response times when AC failure occurs. On Wed, Oct 11, 2017 at 10:09 AM, Naslund, Steve wrote: > > Bottom line 80 F input air is too hot in my opinion and apparently the > equipment's opinion as well. > > -- Jeremy Austin jhaustin at gmail.co m (907) 895-2311 office (907) 803-5422 cell Heritage NetWorks - Whitestone Power & Communications - Vertical Broadband, LLC From eric.kuhnke at gmail.com Wed Oct 11 18:56:34 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 11 Oct 2017 11:56:34 -0700 Subject: Temp at Level 3 data centers In-Reply-To: <20171011170556.GA12774@ussenterprise.ufp.org> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <20171011170556.GA12774@ussenterprise.ufp.org> Message-ID: Also worth noting that temperature tolerances for large scale numbers of 1U servers, Open Compute platform type high density servers, or blade servers is a very different thing than air intake temperatures for more sensitive things like DWDM platforms... There's laser and physics related issues where temperature stability is important as channel sizes get narrower in terms of optical THz. On Wed, Oct 11, 2017 at 10:05 AM, Leo Bicknell wrote: > In a message written on Wed, Oct 11, 2017 at 12:54:26PM -0400, Zachary > Winnerman wrote: > > I recall some evidence that 80+F temps can reduce hard drive lifetime, > > though it might be outdated as it was from before SSDs were around. I > > This is very much a "your infrastructure may vary" situation. > > The servers we're currently buying when speced with SSD only and > the correct network card (generally meaning RJ45 only, but there > are exceptions) are waranteed for 105 degree inlet operations. > While we do not do "high temperature operations" we have seen > operations where folks run them at 90-100 degree input chasing > effiency. > > Famously, Intel ran computers outside in a tent just to prove it works > fine: > > https://www.computerworld.com/article/2533138/data-center/ > running-servers-in-a-tent-outside--it-works.html > > It should be easy to purchase equipment that can tolerate 80-90 > degree input without damage. But that's not the question here. > The question is if the temp is within the range specified in the > contract. If it is, deal with it, and if it is not, hold your > vendor to delivering what they promised. > > -- > Leo Bicknell - bicknell at ufp.org > PGP keys at http://www.ufp.org/~bicknell/ > From bellman at nsc.liu.se Wed Oct 11 18:56:31 2017 From: bellman at nsc.liu.se (Thomas Bellman) Date: Wed, 11 Oct 2017 20:56:31 +0200 Subject: Temp at Level 3 data centers In-Reply-To: <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> Message-ID: On 2017-10-11 19:09, Naslund, Steve wrote: > I would also be concerned because if they lose one of the a/c units > what would the ambient temperature rise to? It doesn't matter much if the "normal" temperature in your DC is 10 or 30 degrees Celcius; if the cooling system is barely keeping up with that, and you loose half your cooling capacity, then temperature will rise pretty quickly, until the servers are literally cooked (i.e. temperature reaching 100°C or more). The spare capacity of the cooling system is the important information, not the starting temperature. That difference of 10-20°C in starting temperature will just give you a few minutes extra, not *save* you, if there is not enough spare capacity in the cooling system. Assuming a reasonably densly packed data centre, at least; with low power density, thin unisolated walls, and winter outside, you might survive even a full cooling failure. :-) Also, depending on your cooling solution, a partial failure might not be very common. We have district cooling providing us with cold water, and if that stops pumping water, and we use up our 30m³ buffer tank (which is enough for 30-40 minutes), *all* cooling stops. But on the other hand, we have capacity enough to survive even if they give us 16°C water instead of the normal 9°C water. > I would want them to tell me what the set point of the a/c actually is. That I agree with. > Bottom line 80 F input air is too hot in my opinion and apparently > the equipment's opinion as well. Unfortunately the default settings of most servers are not very well thought through. They will typically spin up fans *much* more than is actually needed to protect the hardware, and often there is no way of changing that for the user. And if you try to get the manufacturer to tell you what the most power-efficient inlet temperature is, they will just tell you "oh, we support anything between 5°C and 40°C" (or whatever their actual limits are), and absolutely refuse to answer your actual question. -- Thomas Bellman National Supercomputer Centre, Linköping University, Sweden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From ryangard at gmail.com Wed Oct 11 19:04:40 2017 From: ryangard at gmail.com (Ryan Gard) Date: Wed, 11 Oct 2017 15:04:40 -0400 Subject: Private Link between TOR and CHI Message-ID: Trying to source some cost effective solutions or vendors that could provide connectivity in this scenario. Essentially I'll be looking to expand presence into Chicago, and as such, will need to source a third party to provide connectivity from 151 Front Street in Toronto to 350 Cermak in Chicago. Specifically, we're looking to build a presence in Chicago to pursue peering agreements with other providers at 350 Cermak. If you're aware of any providers that would be able to provide this connectivity, that would be perfect. Thanks! -- Ryan Gard From jfmezei_nanog at vaxination.ca Wed Oct 11 19:04:52 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 11 Oct 2017 15:04:52 -0400 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: References: Message-ID: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> On 2017-10-11 11:40, Jacques Latour wrote: > Does anyone know if there's fibre resiliency between Calgary and Toronto over the Great lakes, I thinking redundancy could be achieved by using two paths one following the railroad and the other following the Trans-Canadian highway. Does anyone know if there is fibre following the Trans-Canadian highway and who owns it? More than likely one around lake Superior on CP Rail tracks, and the other along the CN tracks further north. Zayo in Canada is formerly CNCP telecommunications, and they are likely first to have fibre along tracks. Since the Trans Canada highway in that part of Ontario is actually a 2 lane rural road, I am not sure people would have laid fibre along it knowing the progressive work to widen it might require frequent relocation of the fibre. From adam.gregory at heidmar.com Wed Oct 11 19:09:22 2017 From: adam.gregory at heidmar.com (Adam Gregory) Date: Wed, 11 Oct 2017 19:09:22 +0000 Subject: Private Link between TOR and CHI In-Reply-To: References: Message-ID: HE, I use them for similar applications. Best Regards, ---------------------------------- adam gregory -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ryan Gard Sent: Wednesday, October 11, 2017 3:05 PM To: nanog at nanog.org Subject: Private Link between TOR and CHI Trying to source some cost effective solutions or vendors that could provide connectivity in this scenario. Essentially I'll be looking to expand presence into Chicago, and as such, will need to source a third party to provide connectivity from 151 Front Street in Toronto to 350 Cermak in Chicago. Specifically, we're looking to build a presence in Chicago to pursue peering agreements with other providers at 350 Cermak. If you're aware of any providers that would be able to provide this connectivity, that would be perfect. Thanks! -- Ryan Gard From math at sizone.org Wed Oct 11 19:13:11 2017 From: math at sizone.org (Ken Chase) Date: Wed, 11 Oct 2017 15:13:11 -0400 Subject: Temp at Level 3 data centers In-Reply-To: <85f956d1-1796-80ea-b40a-74493f0fc100@gmail.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <85f956d1-1796-80ea-b40a-74493f0fc100@gmail.com> Message-ID: <20171011191311.GG8671@sizone.org> As temp goes up wire resistance increases too, increasing heat, increasing resistance, etc - and I find breakers trip more easily at hotter temps too. /kc On Wed, Oct 11, 2017 at 01:08:33PM -0400, Zachary Winnerman said: >That's a good point, though if you are running your breakers that close >I think you have bigger problems, as a power outage, however unlikely, >could cause your equipment to not come back up at all. Software updates >that reboot several servers in quick succession could also cause a >breaker to trip under those circumstances. Unfortunately, there's no way >to tell how close a breaker is to tripping without tripping it. Breakers >may have amp meteres and a rated size, but the actual load before >tripping is +-20% for common models, meaning a 20A breaker may trip as >low as 16A. -- Ken Chase - math at sizone.org Guelph Canada From lathama at gmail.com Wed Oct 11 19:39:19 2017 From: lathama at gmail.com (Andrew Latham) Date: Wed, 11 Oct 2017 14:39:19 -0500 Subject: Temp at Level 3 data centers In-Reply-To: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> Message-ID: David The issue has several components and is vendor agnostic. Set Point: The systems are specifically set at a temperature Capacity Ability: The systems can maintain a temperature Customer Desire: What you expect from sales promises. Sales Promise: What they might carefully avoid promising. I suggest you review your SLA and discuss with legal asap. You could have a document defining your question's answer already but it sits in a filing cabinet file labeled business continuity. If the set point is X then they likely would answer quickly that that is the case. If the capacity is lacking then they would likely redirect the issue. If they don't care about the customer that alone should be an indicator If a promise exists in the SLA then the ball is in your court >From the emails I fear that we have confirmed that this is normal. So your question "Is the temperature at Level 3 Data Centers normally in the 80-90F range?" sounds like a Yes. Regardless of the situation always ask for names, titles, and ask vendors to repeat critical information like the status of cooling in a building designed to deal with cooling. Keep the vendors that do it well. On Wed, Oct 11, 2017 at 7:31 AM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Curious if anyone on here colo’s equipment at a Level 3 facility and has > found the temperature unacceptably warm? I’m having that experience > currently, where ambient temp is in the 80’s, but they tell me that’s > perfectly fine because vented tiles have been placed in front of all > equipment racks. My equipment is alarming for high temps, so obviously not > fine. Trying to find my way up to whomever I can complain to that’s in a > position to do something about it but it seems the support staff have been > told to brush questions about temp off as much as possible. Was wondering > if this is a country-wide thing for them or unique to the data center I > have equipment in. I have equipment in several others from different > companies and most are probably 15-20 degrees cooler. > > Thanks, > > David > -- - Andrew "lathama" Latham - From bryan at shout.net Wed Oct 11 19:59:29 2017 From: bryan at shout.net (Bryan Holloway) Date: Wed, 11 Oct 2017 14:59:29 -0500 Subject: Temp at Level 3 data centers In-Reply-To: References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> Message-ID: <981e1283-c118-9e30-c56a-ff0902742f69@shout.net> On 10/11/17 9:42 AM, Sam Kretchmer wrote: > with a former employer we had a suite at the L3 facility on Canal in > Chicago. They had this exact issue for the entire time we had the suite. > They kept blaming a failing HVAC unit on our floor, but it went on for > years no matter who we complained to, or what we said. > > Good luck. At $dayjob-1, we had a couple cabinets at that facility, and sometime around 2007, if I recall correctly, they kicked out all of the customers that were server-farms. Only carriers were allowed to stay (with a few exceptions, I'm sure ...) I know because we picked up a few of their customers. That facility was built out around 2000/2001, and things were a lot different back then (e.g. no one was really using 208/240 yet.) I think they just couldn't keep up when things really took off again post dot-com bust. > On 10/11/17, 7:31 AM, "NANOG on behalf of David Hubbard" > wrote: > >> Curious if anyone on here colo¹s equipment at a Level 3 facility and has >> found the temperature unacceptably warm? I¹m having that experience >> currently, where ambient temp is in the 80¹s, but they tell me that¹s >> perfectly fine because vented tiles have been placed in front of all >> equipment racks. My equipment is alarming for high temps, so obviously >> not fine. Trying to find my way up to whomever I can complain to that¹s >> in a position to do something about it but it seems the support staff >> have been told to brush questions about temp off as much as possible. >> Was wondering if this is a country-wide thing for them or unique to the >> data center I have equipment in. I have equipment in several others from >> different companies and most are probably 15-20 degrees cooler. >> >> Thanks, >> >> David > From jfmezei_nanog at vaxination.ca Wed Oct 11 20:10:08 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 11 Oct 2017 16:10:08 -0400 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: References: Message-ID: <122a4308-e774-d8fe-db08-493e728cbdbc@vaxination.ca> BTW, a web site showing list of registered cellular towers in Canada: http://www.ertyu.org/steven_nikkel/cancellsites.html In areas where the 17 or 11 stray from railroad, you could cobine that map with Street View to try to spot towers to see if they are on microwave or not. If I were to cycle the route again, I would be able to spot signs of fibre along the road. (do not dig, or orange tags on telephone pole lines where they exist). There may be stretches where there is fibre along the 17 (between Sudbury and White River, there are no through tracks, and a few towns, so one assumes some fibre has been laid). The folks at ViaNet.ca have laid FTTH in towns such as Chapleau, so they would know what fibre trunks exist in the region. From jk at ip-clear.de Wed Oct 11 20:32:05 2017 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Wed, 11 Oct 2017 22:32:05 +0200 Subject: Temp at Level 3 data centers In-Reply-To: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> Message-ID: <504C59B3-6576-489D-9EBB-095ECCBE7963@ip-clear.de> Hi there, been there, done that, rocky way ahead. In Europe the standard temperature Level3 SLA is 26C. The measurement is done on the cool aisle, at a distance of 45 cm to the equipment and a height of 100 cm. You can use a Testo 625 handheld for measurements, that is also handled by Level3 staff. Do you guys still at least have biometric access control devices at your Level3 dc? They even removed this things at our site, because there is no budget for a successor for the failing unit. And to be consistent, they event want to remove all biometric access devices at least across Germany. Regards Jörg On 11 Oct 2017, at 14:31, David Hubbard wrote: > Curious if anyone on here colo’s equipment at a Level 3 facility and > has found the temperature unacceptably warm? I’m having that > experience currently, where ambient temp is in the 80’s, but they > tell me that’s perfectly fine because vented tiles have been placed > in front of all equipment racks. My equipment is alarming for high > temps, so obviously not fine. Trying to find my way up to whomever I > can complain to that’s in a position to do something about it but it > seems the support staff have been told to brush questions about temp > off as much as possible. Was wondering if this is a country-wide > thing for them or unique to the data center I have equipment in. I > have equipment in several others from different companies and most are > probably 15-20 degrees cooler. > > Thanks, > > David From bill at herrin.us Wed Oct 11 20:46:02 2017 From: bill at herrin.us (William Herrin) Date: Wed, 11 Oct 2017 16:46:02 -0400 Subject: Temp at Level 3 data centers In-Reply-To: <504C59B3-6576-489D-9EBB-095ECCBE7963@ip-clear.de> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <504C59B3-6576-489D-9EBB-095ECCBE7963@ip-clear.de> Message-ID: On Wed, Oct 11, 2017 at 4:32 PM, Jörg Kost wrote: > Do you guys still at least have biometric access control devices at your > Level3 dc? They even removed this things at our site, because there is no > budget for a successor for the failing unit. And to be consistent, they > event want to remove all biometric access devices at least across Germany. > Hi Jörg, IMO, biometric was a gimmick in the first place and a bad idea when carefully considered. All authenticators can be compromised. Hence, all authenticators must be replaceable following a compromise. If one of your DCs' palm vein databases is lost, what's your plan for replacing that hand? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From math at sizone.org Wed Oct 11 21:04:08 2017 From: math at sizone.org (Ken Chase) Date: Wed, 11 Oct 2017 17:04:08 -0400 Subject: replacing compromised biometric authenticators Message-ID: <20171011210408.GN8671@sizone.org> (forking the thread here..) Biometrics are still the new hotness out in North America. Cologix whom I deal with in Canada has a dozen and a half odd POPs in canada/usa and I think has fingerprinting at all sites. If the current best operating practice is to avoid biometrics, why are they still in use out here? Has anyone gotten the message? Is anyone in North America ripping them out yet? Other factors include your country's privacy regulations for storing irreplaceable personal information, the burden of which might not be worth the security 'benefit'. /kc On Wed, Oct 11, 2017 at 04:46:02PM -0400, William Herrin said: >On Wed, Oct 11, 2017 at 4:32 PM, J??rg Kost wrote: > >> Do you guys still at least have biometric access control devices at your >> Level3 dc? They even removed this things at our site, because there is no >> budget for a successor for the failing unit. And to be consistent, they >> event want to remove all biometric access devices at least across Germany. >> > >Hi J??rg, > >IMO, biometric was a gimmick in the first place and a bad idea when >carefully considered. All authenticators can be compromised. Hence, all >authenticators must be replaceable following a compromise. If one of your >DCs' palm vein databases is lost, what's your plan for replacing that hand? > >Regards, >Bill Herrin > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: -- Ken Chase - math at sizone.org Guelph Canada From trelane at trelane.net Wed Oct 11 21:10:36 2017 From: trelane at trelane.net (Andrew Kirch) Date: Wed, 11 Oct 2017 17:10:36 -0400 Subject: replacing compromised biometric authenticators In-Reply-To: <20171011210408.GN8671@sizone.org> References: <20171011210408.GN8671@sizone.org> Message-ID: Since I'm not squeamish about such things, I do have tin snips and will happily assist in revocation of compromised biometric authentication factors. Andrew On Wed, Oct 11, 2017 at 5:04 PM, Ken Chase wrote: > (forking the thread here..) > > Biometrics are still the new hotness out in North America. Cologix whom I > deal > with in Canada has a dozen and a half odd POPs in canada/usa and I think > has > fingerprinting at all sites. > > If the current best operating practice is to avoid biometrics, why are they > still in use out here? Has anyone gotten the message? Is anyone in North > America > ripping them out yet? > > Other factors include your country's privacy regulations for storing > irreplaceable personal information, the burden of which might not be worth > the security 'benefit'. > > /kc > > > On Wed, Oct 11, 2017 at 04:46:02PM -0400, William Herrin said: > >On Wed, Oct 11, 2017 at 4:32 PM, J??rg Kost wrote: > > > >> Do you guys still at least have biometric access control devices at > your > >> Level3 dc? They even removed this things at our site, because there > is no > >> budget for a successor for the failing unit. And to be consistent, > they > >> event want to remove all biometric access devices at least across > Germany. > >> > > > >Hi J??rg, > > > >IMO, biometric was a gimmick in the first place and a bad idea when > >carefully considered. All authenticators can be compromised. Hence, all > >authenticators must be replaceable following a compromise. If one of > your > >DCs' palm vein databases is lost, what's your plan for replacing that > hand? > > > >Regards, > >Bill Herrin > > > > > >-- > >William Herrin ................ herrin at dirtside.com bill at herrin.us > >Dirtside Systems ......... Web: > > -- > Ken Chase - math at sizone.org Guelph Canada > From matt at netfire.net Wed Oct 11 21:10:51 2017 From: matt at netfire.net (Matt Harris) Date: Wed, 11 Oct 2017 16:10:51 -0500 Subject: replacing compromised biometric authenticators In-Reply-To: <20171011210408.GN8671@sizone.org> References: <20171011210408.GN8671@sizone.org> Message-ID: I would definitely not say that it is current best practice not to deploy biometrics. As part of a holistic approach, biometric systems can improve security greatly. As a singular approach, using it as a single factor for authentication and authorization of access/actions, it's as terrible an idea as any other. The difficult of passing a high-quality biometric authentication system, even knowing its success conditions, is non-trivial. The good ones check for basic signs of life, as well, so simply cutting off someone's hand and trying to use it would fail, for example. There are, of course, cheap biometric systems that are not as good, and ymmv depending on what and how you deploy biometrics. Taking the specific threat level you're up against is always relevant. All of the facilities I have in production have a three factor approach to access - "something you know, something you have, and something you are." Biometrics being the latter, plus a badge or dongle, and a four digit code. None of my production facilities can be access without all three. Take care, Matt On Wed, Oct 11, 2017 at 4:04 PM, Ken Chase wrote: > (forking the thread here..) > > Biometrics are still the new hotness out in North America. Cologix whom I > deal > with in Canada has a dozen and a half odd POPs in canada/usa and I think > has > fingerprinting at all sites. > > If the current best operating practice is to avoid biometrics, why are they > still in use out here? Has anyone gotten the message? Is anyone in North > America > ripping them out yet? > > Other factors include your country's privacy regulations for storing > irreplaceable personal information, the burden of which might not be worth > the security 'benefit'. > > /kc > > > On Wed, Oct 11, 2017 at 04:46:02PM -0400, William Herrin said: > >On Wed, Oct 11, 2017 at 4:32 PM, J??rg Kost wrote: > > > >> Do you guys still at least have biometric access control devices at > your > >> Level3 dc? They even removed this things at our site, because there > is no > >> budget for a successor for the failing unit. And to be consistent, > they > >> event want to remove all biometric access devices at least across > Germany. > >> > > > >Hi J??rg, > > > >IMO, biometric was a gimmick in the first place and a bad idea when > >carefully considered. All authenticators can be compromised. Hence, all > >authenticators must be replaceable following a compromise. If one of > your > >DCs' palm vein databases is lost, what's your plan for replacing that > hand? > > > >Regards, > >Bill Herrin > > > > > >-- > >William Herrin ................ herrin at dirtside.com bill at herrin.us > >Dirtside Systems ......... Web: > > -- > Ken Chase - math at sizone.org Guelph Canada > -- Matt Harris - Chief Security Officer Main: +1 855.696.3834 ext 103 Mobile: +1 908.590.9472 Email: matt at netfire.net From baldur.norddahl at gmail.com Wed Oct 11 22:55:56 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 12 Oct 2017 00:55:56 +0200 Subject: Temp at Level 3 data centers In-Reply-To: References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <504C59B3-6576-489D-9EBB-095ECCBE7963@ip-clear.de> Message-ID: Den 11. okt. 2017 22.47 skrev "William Herrin" : On Wed, Oct 11, 2017 at 4:32 PM, Jörg Kost wrote: > Do you guys still at least have biometric access control devices at your > Level3 dc? They even removed this things at our site, because there is no > budget for a successor for the failing unit. And to be consistent, they > event want to remove all biometric access devices at least across Germany. > Hi Jörg, IMO, biometric was a gimmick in the first place and a bad idea when carefully considered. All authenticators can be compromised. Hence, all authenticators must be replaceable following a compromise. If one of your DCs' palm vein databases is lost, what's your plan for replacing that hand? Basic two or three factor authentication: something that you know (password), something that you are (biometric) and something that you have (access card). You can tell your password to a coworker but he can not borrow your hand. Hence you need both. The password is the replaceable part. From cra at WPI.EDU Thu Oct 12 02:11:53 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 11 Oct 2017 22:11:53 -0400 Subject: Temp at Level 3 data centers In-Reply-To: References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> Message-ID: <20171012021153.GZ14632@angus.ind.wpi.edu> Install an air conditioner in your rack. On Wed, Oct 11, 2017 at 02:39:19PM -0500, Andrew Latham wrote: > David > > The issue has several components and is vendor agnostic. > > Set Point: The systems are specifically set at a temperature > Capacity Ability: The systems can maintain a temperature > Customer Desire: What you expect from sales promises. > Sales Promise: What they might carefully avoid promising. > > I suggest you review your SLA and discuss with legal asap. You could have a > document defining your question's answer already but it sits in a filing > cabinet file labeled business continuity. > > If the set point is X then they likely would answer quickly that that is > the case. > If the capacity is lacking then they would likely redirect the issue. > If they don't care about the customer that alone should be an indicator > If a promise exists in the SLA then the ball is in your court > > >From the emails I fear that we have confirmed that this is normal. So your > question "Is the temperature at Level 3 Data Centers normally in the 80-90F > range?" sounds like a Yes. > > Regardless of the situation always ask for names, titles, and ask vendors > to repeat critical information like the status of cooling in a building > designed to deal with cooling. Keep the vendors that do it well. > > > > On Wed, Oct 11, 2017 at 7:31 AM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > > > Curious if anyone on here colo’s equipment at a Level 3 facility and has > > found the temperature unacceptably warm? I’m having that experience > > currently, where ambient temp is in the 80’s, but they tell me that’s > > perfectly fine because vented tiles have been placed in front of all > > equipment racks. My equipment is alarming for high temps, so obviously not > > fine. Trying to find my way up to whomever I can complain to that’s in a > > position to do something about it but it seems the support staff have been > > told to brush questions about temp off as much as possible. Was wondering > > if this is a country-wide thing for them or unique to the data center I > > have equipment in. I have equipment in several others from different > > companies and most are probably 15-20 degrees cooler. > > > > Thanks, > > > > David From web at typo.org Thu Oct 12 02:25:19 2017 From: web at typo.org (Wayne Bouchard) Date: Wed, 11 Oct 2017 19:25:19 -0700 Subject: replacing compromised biometric authenticators In-Reply-To: References: <20171011210408.GN8671@sizone.org> Message-ID: <20171012022519.GA52052@spider.typo.org> I agree that multiple levels are best and, for the moment, I'd frankly be hesitant to give anything like finger print data since one can never change that and the harm of it getting loose can not yet be determined. (Not that the data being taken by these scanners is necessarily all that grandiose.) I also would accept a facility that did something like handscan and pin to access the lobby/security desk and keycard or fob to move around once inside along with scan in/scan out enforcement. (No tail gating.) I've never really been keen on relying on biometrics though. The handscanners can be convenient for not having to carry anything around but when all is said and done, they are really not all that much better than just a keycard. -Wayne On Wed, Oct 11, 2017 at 04:10:51PM -0500, Matt Harris wrote: > I would definitely not say that it is current best practice not to deploy > biometrics. As part of a holistic approach, biometric systems can improve > security greatly. As a singular approach, using it as a single factor for > authentication and authorization of access/actions, it's as terrible an > idea as any other. The difficult of passing a high-quality biometric > authentication system, even knowing its success conditions, is > non-trivial. The good ones check for basic signs of life, as well, so > simply cutting off someone's hand and trying to use it would fail, for > example. There are, of course, cheap biometric systems that are not as > good, and ymmv depending on what and how you deploy biometrics. Taking the > specific threat level you're up against is always relevant. > > All of the facilities I have in production have a three factor approach to > access - "something you know, something you have, and something you are." > Biometrics being the latter, plus a badge or dongle, and a four digit > code. None of my production facilities can be access without all three. > > Take care, > Matt > > > On Wed, Oct 11, 2017 at 4:04 PM, Ken Chase wrote: > > > (forking the thread here..) > > > > Biometrics are still the new hotness out in North America. Cologix whom I > > deal > > with in Canada has a dozen and a half odd POPs in canada/usa and I think > > has > > fingerprinting at all sites. > > > > If the current best operating practice is to avoid biometrics, why are they > > still in use out here? Has anyone gotten the message? Is anyone in North > > America > > ripping them out yet? > > > > Other factors include your country's privacy regulations for storing > > irreplaceable personal information, the burden of which might not be worth > > the security 'benefit'. > > > > /kc > > > > > > On Wed, Oct 11, 2017 at 04:46:02PM -0400, William Herrin said: > > >On Wed, Oct 11, 2017 at 4:32 PM, J??rg Kost wrote: > > > > > >> Do you guys still at least have biometric access control devices at > > your > > >> Level3 dc? They even removed this things at our site, because there > > is no > > >> budget for a successor for the failing unit. And to be consistent, > > they > > >> event want to remove all biometric access devices at least across > > Germany. > > >> > > > > > >Hi J??rg, > > > > > >IMO, biometric was a gimmick in the first place and a bad idea when > > >carefully considered. All authenticators can be compromised. Hence, all > > >authenticators must be replaceable following a compromise. If one of > > your > > >DCs' palm vein databases is lost, what's your plan for replacing that > > hand? > > > > > >Regards, > > >Bill Herrin > > > > > > > > >-- > > >William Herrin ................ herrin at dirtside.com bill at herrin.us > > >Dirtside Systems ......... Web: > > > > -- > > Ken Chase - math at sizone.org Guelph Canada > > > > > > -- > Matt Harris - Chief Security Officer > Main: +1 855.696.3834 ext 103 > Mobile: +1 908.590.9472 > Email: matt at netfire.net --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From James at arenalgroup.co Thu Oct 12 05:01:13 2017 From: James at arenalgroup.co (James Breeden) Date: Thu, 12 Oct 2017 05:01:13 +0000 Subject: 4 or smaller digit ASNs Message-ID: Hello NANOG... I have a client interested in picking up a new AS number but they really want it to be 3 or 4 digits in length. Is there a process to request this from ARIN, or doss anyone know of unused ASns fitting this that anyone is looking to sell for some quick cash? Thanks! James Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone From mel at beckman.org Thu Oct 12 05:47:30 2017 From: mel at beckman.org (Mel Beckman) Date: Thu, 12 Oct 2017 05:47:30 +0000 Subject: 4 or smaller digit ASNs In-Reply-To: References: Message-ID: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> James, As far as I know, you can't buy an existing ASN for any amount of money. You can buy the company that owns it, but that seems like boiling tea with a blowtorch. I sincerely doubt there are unused low-number ASNs, but you could always ask ARIN. I'm curious what your client's rationale is for wanting a low ASN. It can't be efficiency, since the numbers all take the same number of bits ultimately. If they just like small numbers, I'd advise them to forget it -- life is too short. If they have a real technical reason that nobody has foreseen (or at least I haven't foreseen), I'd love to hear it. -mel beckman > On Oct 11, 2017, at 10:01 PM, James Breeden wrote: > > Hello NANOG... > > I have a client interested in picking up a new AS number but they really want it to be 3 or 4 digits in length. > > Is there a process to request this from ARIN, or doss anyone know of unused ASns fitting this that anyone is looking to sell for some quick cash? > > Thanks! > James > > > > > Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone From owen at delong.com Thu Oct 12 06:57:14 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Oct 2017 23:57:14 -0700 Subject: 4 or smaller digit ASNs In-Reply-To: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> Message-ID: There are, for better or worse, ASN transfers under NRPM 8.3 in the ARIN region. (Personally, I find this silly, but the community came to consensus on the matter, so it is what it is). As such, if you can find someone with a low number ASN who is willing to part with it for what you are willing to offer to acquire same, then you can transfer it. Owen > On Oct 11, 2017, at 10:47 PM, Mel Beckman wrote: > > James, > > As far as I know, you can't buy an existing ASN for any amount of money. You can buy the company that owns it, but that seems like boiling tea with a blowtorch. > > I sincerely doubt there are unused low-number ASNs, but you could always ask ARIN. > > I'm curious what your client's rationale is for wanting a low ASN. It can't be efficiency, since the numbers all take the same number of bits ultimately. If they just like small numbers, I'd advise them to forget it -- life is too short. If they have a real technical reason that nobody has foreseen (or at least I haven't foreseen), I'd love to hear it. > > > -mel beckman > >> On Oct 11, 2017, at 10:01 PM, James Breeden wrote: >> >> Hello NANOG... >> >> I have a client interested in picking up a new AS number but they really want it to be 3 or 4 digits in length. >> >> Is there a process to request this from ARIN, or doss anyone know of unused ASns fitting this that anyone is looking to sell for some quick cash? >> >> Thanks! >> James >> >> >> >> >> Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone From web at typo.org Thu Oct 12 07:05:51 2017 From: web at typo.org (Wayne Bouchard) Date: Thu, 12 Oct 2017 00:05:51 -0700 Subject: 4 or smaller digit ASNs In-Reply-To: References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> Message-ID: <20171012070551.GA52873@spider.typo.org> > > I'm curious what your client's rationale is for wanting a low ASN. Dare I say it? Nerds often get overly excited at things that are generally pretty small... ;) --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From hugge at nordu.net Thu Oct 12 07:28:15 2017 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Thu, 12 Oct 2017 09:28:15 +0200 Subject: 4 or smaller digit ASNs In-Reply-To: References: Message-ID: <6fec5586-81a0-5c27-0100-ea94a4760b03@nordu.net> On 2017-10-12 07:01, James Breeden wrote: > Hello NANOG... > > I have a client interested in picking up a new AS number but they really want it to be 3 or 4 digits in length. > > Is there a process to request this from ARIN, or doss anyone know of unused ASns fitting this that anyone is looking to sell for some quick cash? > > Thanks! > James > > > > > Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone > AS251 comes to mind as one of few 3-digit ones that has existed, but doesent anymore (atleast not in DFZ). But do you really want a used and abused old asn? The old logic with the lower ASN you have the bigger E-penis you got doesent really apply anymore since the biggest players on the Internet doesent have 3 or 4 digit ASNs anymore. -- hugge From nanog at radu-adrian.feurdean.net Thu Oct 12 09:51:54 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Thu, 12 Oct 2017 11:51:54 +0200 Subject: 4 or smaller digit ASNs In-Reply-To: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> Message-ID: <1507801914.2945697.1136299784.4CF80257@webmail.messagingengine.com> On Thu, Oct 12, 2017, at 07:47, Mel Beckman wrote: > James, > > As far as I know, you can't buy an existing ASN for any amount of money. You can in RIPE region, but you must first find an "owner" ready to tranfer it (for money or for free). ASN transfers do happen here, and there are indications that they happen in ARIN region too ( https://www.ipv4auctions.com/customer/account/previous/ - search for ASN). From universe at truemetal.org Thu Oct 12 10:53:39 2017 From: universe at truemetal.org (Markus) Date: Thu, 12 Oct 2017 12:53:39 +0200 Subject: 4 or smaller digit ASNs In-Reply-To: References: Message-ID: <22c7021f-7787-5360-fa67-1957dc05df71@truemetal.org> Am 12.10.2017 um 07:01 schrieb James Breeden: > Is there a process to request this from ARIN, or doss anyone know of unused ASns fitting this that anyone is looking to sell for some quick cash? I can part ways with unused AS35777 but it's in the RIPE region. 5 digits but kind of nice to look at, and still better than e.g. AS57329 (no offense to AS57329!) :D Regards Markus From srchlm at its.cz Thu Oct 12 13:02:11 2017 From: srchlm at its.cz (Lumir Srchlm) Date: Thu, 12 Oct 2017 15:02:11 +0200 Subject: Seznam serveru Message-ID: Dobry den, zasilam slibeny seznam serveru. DC1 PHCZ_MIS PHCZ_WSUS PHCZ_RON DC01_NV PHCZ_ADFS01 nv-vrc-fug-v-02 pha-nav-v-003 PHCZ_DC01 DC01_NOS PHCZ_DADFS01 PHCZ_TERMGW HART_NV DC01_NSO PHCZ_TERM1 DC01_NSU PHCZ_ESET DC2 PHCZ_DADFS02 PHCZ_DC02 PHCZ_ADFS02 S pozdravem Lumir Srch From Quincy.Marshall at reged.com Thu Oct 12 13:27:38 2017 From: Quincy.Marshall at reged.com (Marshall, Quincy) Date: Thu, 12 Oct 2017 13:27:38 +0000 Subject: Temp at Level 3 data centers Message-ID: <3438B611A2B2C04495EF0E1B25729C46BCD6EB@mbx032-e1-va-8.exch032.serverpod.net> I have equipment in several L(3) DCs. I'd say that is generally the exception however I have two notable facilities (smaller type 3) that have troubles on occasion... reaching into the 80s as you commented. (Usually during the warm southern summer days) . I found that my getting to know the facility manager/personnel very useful. They gave staight up answers and have done what they could to assist. -------- Original message -------- From: Chuck Anderson Date: 10/11/17 22:13 (GMT-05:00) To: nanog at nanog.org Subject: Re: Temp at Level 3 data centers Install an air conditioner in your rack. On Wed, Oct 11, 2017 at 02:39:19PM -0500, Andrew Latham wrote: > David > > The issue has several components and is vendor agnostic. > > Set Point: The systems are specifically set at a temperature > Capacity Ability: The systems can maintain a temperature > Customer Desire: What you expect from sales promises. > Sales Promise: What they might carefully avoid promising. > > I suggest you review your SLA and discuss with legal asap. You could have a > document defining your question's answer already but it sits in a filing > cabinet file labeled business continuity. > > If the set point is X then they likely would answer quickly that that is > the case. > If the capacity is lacking then they would likely redirect the issue. > If they don't care about the customer that alone should be an indicator > If a promise exists in the SLA then the ball is in your court > > >From the emails I fear that we have confirmed that this is normal. So your > question "Is the temperature at Level 3 Data Centers normally in the 80-90F > range?" sounds like a Yes. > > Regardless of the situation always ask for names, titles, and ask vendors > to repeat critical information like the status of cooling in a building > designed to deal with cooling. Keep the vendors that do it well. > > > > On Wed, Oct 11, 2017 at 7:31 AM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > > > Curious if anyone on here colo’s equipment at a Level 3 facility and has > > found the temperature unacceptably warm? I’m having that experience > > currently, where ambient temp is in the 80’s, but they tell me that’s > > perfectly fine because vented tiles have been placed in front of all > > equipment racks. My equipment is alarming for high temps, so obviously not > > fine. Trying to find my way up to whomever I can complain to that’s in a > > position to do something about it but it seems the support staff have been > > told to brush questions about temp off as much as possible. Was wondering > > if this is a country-wide thing for them or unique to the data center I > > have equipment in. I have equipment in several others from different > > companies and most are probably 15-20 degrees cooler. > > > > Thanks, > > > > David --------------------------------------------------------------------------------------- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --------------------------------------------------------------------------------------- From matt at conundrum.com Thu Oct 12 14:04:08 2017 From: matt at conundrum.com (Matthew Pounsett) Date: Thu, 12 Oct 2017 10:04:08 -0400 Subject: Temp at Level 3 data centers In-Reply-To: <3438B611A2B2C04495EF0E1B25729C46BCD6EB@mbx032-e1-va-8.exch032.serverpod.net> References: <3438B611A2B2C04495EF0E1B25729C46BCD6EB@mbx032-e1-va-8.exch032.serverpod.net> Message-ID: I'm a few years removed from having direct involvement in our DCs now, so I don't have an example on hand to look at. Is cooling (and in-cabinet temperature) not a part of the SLA? If it is, then there shouldn't be a question of the DC staff brushing off complaints about the temperature–either L3 should fix it or pay the penalties. If it isn't, then I'd suggest having a look at your contract (and possibly looking a new DCs) at renewal time. From dwhite at olp.net Thu Oct 12 16:18:48 2017 From: dwhite at olp.net (Dan White) Date: Thu, 12 Oct 2017 11:18:48 -0500 Subject: TSYS Contact Message-ID: <20171012161848.xggy2ixm24b3ww7m@dan.olp.net> If there are any personnel from TSYS here, please contact me off list. -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at olp.net http://www.btcbroadband.com From Jacques.Latour at cira.ca Thu Oct 12 16:46:55 2017 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Thu, 12 Oct 2017 16:46:55 +0000 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> Message-ID: > Since the Trans Canada highway in that part of Ontario is actually a 2 lane > rural road, I am not sure people would have laid fibre along it knowing the > progressive work to widen it might require frequent relocation of the fibre. That's a good point, what about along the Trans-Canadian pipeline? https://www.transcanada.com/en/operations/maps/ Anyone know if there's fibre there? From hank at efes.iucc.ac.il Thu Oct 12 17:39:41 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 12 Oct 2017 20:39:41 +0300 Subject: 4 or smaller digit ASNs In-Reply-To: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> Message-ID: On 12/10/2017 08:47, Mel Beckman wrote: > James, > > As far as I know, you can't buy an existing ASN for any amount of money. You can buy the company that owns it, but that seems like boiling tea with a blowtorch. > > I sincerely doubt there are unused low-number ASNs, but you could always ask ARIN. > > I'm curious what your client's rationale is for wanting a low ASN. It is called ASN-envy. -Hank AS378 :-) > It can't be efficiency, since the numbers all take the same number of bits ultimately. If they just like small numbers, I'd advise them to forget it -- life is too short. If they have a real technical reason that nobody has foreseen (or at least I haven't foreseen), I'd love to hear it. > > > -mel beckman > >> On Oct 11, 2017, at 10:01 PM, James Breeden wrote: >> >> Hello NANOG... >> >> I have a client interested in picking up a new AS number but they really want it to be 3 or 4 digits in length. >> >> Is there a process to request this from ARIN, or doss anyone know of unused ASns fitting this that anyone is looking to sell for some quick cash? >> >> Thanks! >> James >> >> >> >> >> Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone From johnl at iecc.com Thu Oct 12 20:28:49 2017 From: johnl at iecc.com (John Levine) Date: 12 Oct 2017 20:28:49 -0000 Subject: 4 or smaller digit ASNs In-Reply-To: <20171012070551.GA52873@spider.typo.org> Message-ID: <20171012202849.43329.qmail@ary.lan> In article <20171012070551.GA52873 at spider.typo.org> you write: >> > I'm curious what your client's rationale is for wanting a low ASN. > >Dare I say it? > >Nerds often get overly excited at things that are generally pretty >small... Too bad I can't sell my old NSI handle. R's, JL7 From SNaslund at medline.com Thu Oct 12 20:40:42 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 12 Oct 2017 20:40:42 +0000 Subject: 4 or smaller digit ASNs In-Reply-To: <20171012202849.43329.qmail@ary.lan> References: <20171012070551.GA52873@spider.typo.org> <20171012202849.43329.qmail@ary.lan> Message-ID: <9578293AE169674F9A048B2BC9A081B40262159F01@MUNPRDMBXA1.medline.com> I've got a DDN TAC access card if they are interested in that as well. Might even be able to dig up a BBN PAD for them too. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Levine Sent: Thursday, October 12, 2017 3:29 PM To: nanog at nanog.org Subject: Re: 4 or smaller digit ASNs In article <20171012070551.GA52873 at spider.typo.org> you write: >> > I'm curious what your client's rationale is for wanting a low ASN. > >Dare I say it? > >Nerds often get overly excited at things that are generally pretty >small... Too bad I can't sell my old NSI handle. R's, JL7 From sam.silvester at gmail.com Wed Oct 11 23:52:31 2017 From: sam.silvester at gmail.com (Sam Silvester) Date: Thu, 12 Oct 2017 10:22:31 +1030 Subject: Temp at Level 3 data centers In-Reply-To: <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> Message-ID: On Thu, Oct 12, 2017 at 3:39 AM, Naslund, Steve wrote: > If the ambient temperature is higher is means the temperatures throughout > the device would be higher and the temp at those points is what really > matters. I would also be concerned because if they lose one of the a/c > units what would the ambient temperature rise to? I would want them to > tell me what the set point of the a/c actually is. > > Bottom line 80 F input air is too hot in my opinion and apparently the > equipment's opinion as well. > My quick thoughts on the matter: 1. Above all else, know what your DC provider states in their SLA/contract. 2. It's never a bad idea to try to be on the best possible personal terms with the DC manager(s), the better you get along the more they're inclined to share knowledge/issues and work with you on any concerns. 3. You can't infer faults or lack of redundancy from the running temperature - by way of example several facilities I know run at 25 degrees celsius but if a chilled water unit in a given data hall fails there's a number of DX units held in standby to take over. This is where point 2 comes in handy as knowing somebody on the ground they'll often be quite happy to run through failure scenarios with you and help make sure everybody is happy with the risk mitigation strategy. Out of idle curiosity - I'm curious as to if the equipment that is alarming is configurable or not? Reason I ask is I've heard users claiming environmental parameters were out of spec before, but then it turned out it was their own environmental monitoring they'd installed in the rack (using default parameters out of the box, not configured to match the facility SLA) that was complaining about a set point of 25... Cheers, Sam From thatoneguysteve at gmail.com Thu Oct 12 05:55:35 2017 From: thatoneguysteve at gmail.com (Steve Jones) Date: Thu, 12 Oct 2017 00:55:35 -0500 Subject: 4 or smaller digit ASNs In-Reply-To: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> Message-ID: as i understand it, you cant do bgp at all under 5 On Thu, Oct 12, 2017 at 12:47 AM, Mel Beckman wrote: > James, > > As far as I know, you can't buy an existing ASN for any amount of money. > You can buy the company that owns it, but that seems like boiling tea with > a blowtorch. > > I sincerely doubt there are unused low-number ASNs, but you could always > ask ARIN. > > I'm curious what your client's rationale is for wanting a low ASN. It > can't be efficiency, since the numbers all take the same number of bits > ultimately. If they just like small numbers, I'd advise them to forget it > -- life is too short. If they have a real technical reason that nobody has > foreseen (or at least I haven't foreseen), I'd love to hear it. > > > -mel beckman > > > On Oct 11, 2017, at 10:01 PM, James Breeden > wrote: > > > > Hello NANOG... > > > > I have a client interested in picking up a new AS number but they really > want it to be 3 or 4 digits in length. > > > > Is there a process to request this from ARIN, or doss anyone know of > unused ASns fitting this that anyone is looking to sell for some quick cash? > > > > Thanks! > > James > > > > > > > > > > Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone > From rsk at gsp.org Thu Oct 12 20:58:35 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 12 Oct 2017 16:58:35 -0400 Subject: replacing compromised biometric authenticators In-Reply-To: <20171011210408.GN8671@sizone.org> References: <20171011210408.GN8671@sizone.org> Message-ID: <20171012205835.GA5109@gsp.org> On Wed, Oct 11, 2017 at 05:04:08PM -0400, Ken Chase wrote: > If the current best operating practice is to avoid biometrics, why are they > still in use out here? (1) for the same reason some idiots still use captchas (2) new hotness > old and busted, regardless of merits (3) because they facilitate coerced risk transference away from the people who are actually responsible (and are paid to be so) to the people who shouldn't be responsible (and aren't paid to be) ---rsk From valdis.kletnieks at vt.edu Thu Oct 12 20:58:52 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 12 Oct 2017 16:58:52 -0400 Subject: 4 or smaller digit ASNs In-Reply-To: References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> Message-ID: <21717.1507841932@turing-police.cc.vt.edu> On Thu, 12 Oct 2017 00:55:35 -0500, Steve Jones said: > as i understand it, you cant do bgp at all under 5 AS1312 does BGP quite nicely... Not sure what you meant there, unless the text/plain lost the tags... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From jfmezei_nanog at vaxination.ca Thu Oct 12 21:53:16 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 12 Oct 2017 17:53:16 -0400 Subject: replacing compromised biometric authenticators In-Reply-To: <20171012205835.GA5109@gsp.org> References: <20171011210408.GN8671@sizone.org> <20171012205835.GA5109@gsp.org> Message-ID: <183bbe65-4d86-d26f-fdd1-66922d418928@vaxination.ca> On 2017-10-12 16:58, Rich Kulawiec wrote: > (3) because they facilitate coerced risk transference away from the > people who are actually responsible (and are paid to be so) to the > people who shouldn't be responsible (and aren't paid to be) I think biometrics are seen as a means to reduce the possible errors/corruption of a security guard by shifting responsibility to a computer. When you have multiple tennants, the DC can't assume all tennants will keep all access cards secure so has to protect tennant 2 from tennant 1 having cards stolen by some crook intent on damaging tennant 2's cards. A security guard matching face to picture on card AND picture in his computer for that card can be very good, and woudl eliminate card counterfeiting (with match against the DC's database of images) but would not eliminate security guard making mistakes and allowing people whose face does not match (corruption or lazyness). This is very different from a data centre owned by a single tennant who has full control over staff and knows who is and isn't staff and authorized to go in. From jlewis at lewis.org Thu Oct 12 22:13:32 2017 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 12 Oct 2017 18:13:32 -0400 (EDT) Subject: 4 or smaller digit ASNs In-Reply-To: References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> Message-ID: On Thu, 12 Oct 2017, Hank Nussbacher wrote: > On 12/10/2017 08:47, Mel Beckman wrote: >> James, >> >> As far as I know, you can't buy an existing ASN for any amount of money. You can buy the company that owns it, but that seems like boiling tea with a blowtorch. >> >> I sincerely doubt there are unused low-number ASNs, but you could always ask ARIN. >> >> I'm curious what your client's rationale is for wanting a low ASN. > It is called ASN-envy. And here smaller is better :) How would one go about cleaning up the provenance and either re-using or selling an ASN, supposing: 1) you are all the registered contacts for the ASN and your ARIN POC is still valid 2) the ASN was owned by (ok...it's ARIN[1], so "registered to") a defunct corporation (inactive >10 years) of which you were part-owner 3) the ARIN maintenance fees have been unpaid >10 years...yet the ASN still exists in whois [1] It was actually assigned pre-ARIN, but to an org that eventually signed the RSA...so I wonder...are the maintenance fees really past due...and is this why the ASN was never reclaimed while the IP space (which was allocated by ARIN) was? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bill at herrin.us Thu Oct 12 22:43:55 2017 From: bill at herrin.us (William Herrin) Date: Thu, 12 Oct 2017 18:43:55 -0400 Subject: Temp at Level 3 data centers In-Reply-To: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> Message-ID: On Wed, Oct 11, 2017 at 8:31 AM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Curious if anyone on here colo’s equipment at a Level 3 facility and has > found the temperature unacceptably warm? I’m having that experience > currently, where ambient temp is in the 80’s, but they tell me that’s > perfectly fine because vented tiles have been placed in front of all > equipment racks. Hi David, The thing I'm not understanding in this thread is that the last time I checked Level 3 was a premium player not a cost player. Has that changed? If a premium data center vendor is asking you to swallow 80F in the cold aisle, something is very wrong. But realize I just said 80F in the *cold aisle*. DC cooling is not about "ambient" or "sensible cooling" or similar terms bandied about by ordinary HVAC professionals. In a data center, air doesn't really stack up anywhere. It flows. If you haven't physically checked your racks, it's time to do that. There are lots of reasons for high temps in the cabinet which aren't the DC's fault. Is all the air flow in your cabinet correctly moving from the cold aisle to the hot aisle? Even those side-venting Cisco switches? You're sure? If you're looping air inside the cabinet, that's your fault. Have you or your rack neighbors exceeded the heat density that the DC's HVAC system supports? If you have, the air in the hot aisle may be looping over the top of the cabinets and back in to your servers. You can't necessarily fill a cabinet with equipment. When you reach the allowable heat density, you have to start filling the next cabinet. I've seen DC cabinets left half empty for exactly this reason. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From richard.hicks at gmail.com Thu Oct 12 22:53:07 2017 From: richard.hicks at gmail.com (Richard Hicks) Date: Thu, 12 Oct 2017 15:53:07 -0700 Subject: 4 or smaller digit ASNs In-Reply-To: References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> Message-ID: Anyone know the history behind ASN 2906 (Netflix)? How did they get a number that low? Rick On Thu, Oct 12, 2017 at 3:13 PM, Jon Lewis wrote: > On Thu, 12 Oct 2017, Hank Nussbacher wrote: > > On 12/10/2017 08:47, Mel Beckman wrote: >> >>> James, >>> >>> As far as I know, you can't buy an existing ASN for any amount of money. >>> You can buy the company that owns it, but that seems like boiling tea with >>> a blowtorch. >>> >>> I sincerely doubt there are unused low-number ASNs, but you could always >>> ask ARIN. >>> >>> I'm curious what your client's rationale is for wanting a low ASN. >>> >> It is called ASN-envy. >> > > And here smaller is better :) > > How would one go about cleaning up the provenance and either re-using or > selling an ASN, supposing: > > 1) you are all the registered contacts for the ASN and your ARIN POC is > still valid > > 2) the ASN was owned by (ok...it's ARIN[1], so "registered to") a defunct > corporation (inactive >10 years) of which you were part-owner > > 3) the ARIN maintenance fees have been unpaid >10 years...yet the ASN > still exists in whois > > [1] It was actually assigned pre-ARIN, but to an org that eventually > signed the RSA...so I wonder...are the maintenance fees really past > due...and is this why the ASN was never reclaimed while the IP space (which > was allocated by ARIN) was? > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From keiths at neilltech.com Thu Oct 12 22:57:30 2017 From: keiths at neilltech.com (Keith Stokes) Date: Thu, 12 Oct 2017 22:57:30 +0000 Subject: Temp at Level 3 data centers In-Reply-To: References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com>, Message-ID: <956175C1-7DCF-4930-B971-C3B8F1F3EBA6@neilltech.com> If you are using hot/cold aisles and don't fill the rack, don't forget you have to put in blank panels. -- Keith Stokes > On Oct 12, 2017, at 5:45 PM, William Herrin wrote: > > On Wed, Oct 11, 2017 at 8:31 AM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > >> Curious if anyone on here colo’s equipment at a Level 3 facility and has >> found the temperature unacceptably warm? I’m having that experience >> currently, where ambient temp is in the 80’s, but they tell me that’s >> perfectly fine because vented tiles have been placed in front of all >> equipment racks. > > > Hi David, > > The thing I'm not understanding in this thread is that the last time I > checked Level 3 was a premium player not a cost player. Has that changed? > > If a premium data center vendor is asking you to swallow 80F in the cold > aisle, something is very wrong. But realize I just said 80F in the *cold > aisle*. DC cooling is not about "ambient" or "sensible cooling" or similar > terms bandied about by ordinary HVAC professionals. In a data center, air > doesn't really stack up anywhere. It flows. > > If you haven't physically checked your racks, it's time to do that. There > are lots of reasons for high temps in the cabinet which aren't the DC's > fault. > > Is all the air flow in your cabinet correctly moving from the cold aisle to > the hot aisle? Even those side-venting Cisco switches? You're sure? If > you're looping air inside the cabinet, that's your fault. > > Have you or your rack neighbors exceeded the heat density that the DC's > HVAC system supports? If you have, the air in the hot aisle may be looping > over the top of the cabinets and back in to your servers. You can't > necessarily fill a cabinet with equipment. When you reach the allowable > heat density, you have to start filling the next cabinet. I've seen DC > cabinets left half empty for exactly this reason. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From jfmezei_nanog at vaxination.ca Thu Oct 12 23:56:14 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 12 Oct 2017 19:56:14 -0400 Subject: Temp at Level 3 data centers In-Reply-To: References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> Message-ID: <84c8cd8f-a2c2-f820-d210-114fdd5ae892@vaxination.ca> back in the arly 1990s, Tandem had a computer called "Cyclone". (these were mission critical, fault tolerant machines). The reason for "Cyclone" name was that the cabinets had huge fan capacity, and that was to deal with air conditioning failure by increasing the air flow over the electronics to still keep then "comfy" despite high data centre air temperature. (with the aim of having the Tandem continue to run despite HVAC failure). With dense computers packed in 1U, you just can't have that excessive airflow to cope with HVAC failure with tiny 1" fans. The other difference is data centre density. Bank computer rooms were sparse compared to today's densely packed racks. So lots of space relative to heat sources. The equivalent today would be the football field size data centres from the likes of Google with high ceilings and hot air from one area with failed HVAC to rise to ceiling and partly be taken out by the others. But when you are talking about downdown co-lo with enclosed suites that are packed to the brim, failure of HVAC results in quick temp increases because the heat has nowhere to spread to, and HVACs from adjoining also enclosed suites can't provide help. So when a tennant agrees to rent rack space in an small enclosed suite, it should be considerewd that the odds of failure due to heat are greater (and perhaps consider renting rack space in different suites to provide some redundancy). From joquendo at e-fensive.net Fri Oct 13 01:31:43 2017 From: joquendo at e-fensive.net (J. Oquendo) Date: Thu, 12 Oct 2017 20:31:43 -0500 Subject: Google Voice Security Message-ID: <20171013013143.he5jhxzelbb57d3l@e-fensive.net> Sorry for the noise. Can someone put me in touch with someone in the Google Voice (application iPhone/Android) department to discuss an issue. Greatly appreciated. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From brett at the-watsons.org Fri Oct 13 04:28:45 2017 From: brett at the-watsons.org (Brett Watson) Date: Thu, 12 Oct 2017 21:28:45 -0700 Subject: 4 or smaller digit ASNs In-Reply-To: References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> Message-ID: <501CC431-262C-453E-AB38-9BB80FDCA0A0@the-watsons.org> > On Oct 12, 2017, at 15:53, Richard Hicks wrote: > > Anyone know the history behind ASN 2906 (Netflix)? > How did they get a number that low? I didn’t recognize as2906 so went digging... and I can’t find a thing. ARIN has a “who has” service but my account on ARIN was locked and I wasn’t able to unlock without calling them (maybe tomorrow). The AS-Name is “AS-SSI” (there is an AS-Set listed on RIPE named this) which I suspect might lead to the original owner. It looks familiar-ish but I’m not sure who had it before Netflix. Clearly they must have bought it outright, acquired the original owner, or something, but I’ll be damned if I can find historical data on who it originally belonged to. -b From ahebert at pubnix.net Fri Oct 13 11:03:30 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 13 Oct 2017 07:03:30 -0400 Subject: replacing compromised biometric authenticators In-Reply-To: <20171012205835.GA5109@gsp.org> References: <20171011210408.GN8671@sizone.org> <20171012205835.GA5109@gsp.org> Message-ID: <33e87e9c-3a7e-bd35-5c47-81cb7f3237b4@pubnix.net>     Odd,     1. captcha(?)     In my millennia of experience I never saw a captcha used as a mean for DC access control.  Just as a programmatic way to reduce brute force for some website functions.     On my network janitor keychain I have (in order of hackability from easiest to hardest)         1. keycard only         2. keycard + fingerprints         3. keycard + face (2d)         4a. keycard + eye         4b. keycard + top of hand mapping     But all the DCs, I deal with, have highrez cameras and tailgating controls...  Biometrics are just a part of a wider system. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 10/12/17 16:58, Rich Kulawiec wrote: > On Wed, Oct 11, 2017 at 05:04:08PM -0400, Ken Chase wrote: >> If the current best operating practice is to avoid biometrics, why are they >> still in use out here? > (1) for the same reason some idiots still use captchas > (2) new hotness > old and busted, regardless of merits > (3) because they facilitate coerced risk transference away from the > people who are actually responsible (and are paid to be so) to the > people who shouldn't be responsible (and aren't paid to be) > > ---rsk > > From lee at asgard.org Fri Oct 13 11:59:36 2017 From: lee at asgard.org (Lee Howard) Date: Fri, 13 Oct 2017 07:59:36 -0400 Subject: 4 or smaller digit ASNs In-Reply-To: References: Message-ID: <2047F678-3C86-4DFC-9008-EDBD9A192718@asgard.org> > On Oct 12, 2017, at 1:01 AM, James Breeden wrote: > > Hello NANOG... > > I have a client interested in picking up a new AS number but they really want it to be 3 or 4 digits in length. > > Is there a process to request this from ARIN, or doss anyone know of unused ASns fitting this that anyone is looking to sell for some quick cash? > It's part of the ARIN transfer process, https://www.arin.net/policy/nrpm.html#eight specific 8.3, "IPv4 numbers resources and ASNs may be transferred according to the following conditions." ARIN has a Specified Transfer Listing Service, https://www.arin.net/resources/transfer_listing/index.html so you could check there. I didn't see any ASNs listed, so you may need to call a broker, such as one listed under https://www.arin.net/resources/transfer_listing/facilitator_list.html A list of ASNs that have been transferred policy can be found at https://www.arin.net/public/transferLog.xhtml#NRPM-8.3ASNs > Thanks! > James > Hope that helps, Lee > > > > Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone From contact at winterei.se Fri Oct 13 12:56:52 2017 From: contact at winterei.se (Paul S.) Date: Fri, 13 Oct 2017 21:56:52 +0900 Subject: Looking for a contact with clue at Choopa/Reliablesite network engineering Message-ID: <827ab68d-5915-1dc5-37ca-41ec9a9f4c61@winterei.se> Hi nanog, Choopa/reliablesite is announcing our IP space, and despite repeated requests from us, they are refusing to withdraw the announcements. Can someone with clue from this contact me? Does anyone know someone at Choopa neteng? Their abuse desk has so far proved useless. From dave at temk.in Fri Oct 13 13:19:23 2017 From: dave at temk.in (Dave Temkin) Date: Fri, 13 Oct 2017 13:19:23 +0000 Subject: 4 or smaller digit ASNs In-Reply-To: <501CC431-262C-453E-AB38-9BB80FDCA0A0@the-watsons.org> References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> , <501CC431-262C-453E-AB38-9BB80FDCA0A0@the-watsons.org> Message-ID: I appreciate your tenacity! SSI = Streaming Services Inc., always wholly owned by Netflix. We had three ASNs at one point. We needed a fourth to do a migration and the ASN gods smiled down on us and gave us 2906 out of a newly released pool of unallocated ASNs, back in 2011. That ASN birthed our CDN, Open Connect, and it became our primary because it was just too nice to use on a corporate network. ________________________________ From: NANOG on behalf of Brett Watson Sent: Thursday, October 12, 2017 9:28:45 PM To: nanog at nanog.org Subject: Re: 4 or smaller digit ASNs > On Oct 12, 2017, at 15:53, Richard Hicks wrote: > > Anyone know the history behind ASN 2906 (Netflix)? > How did they get a number that low? I didn’t recognize as2906 so went digging... and I can’t find a thing. ARIN has a “who has” service but my account on ARIN was locked and I wasn’t able to unlock without calling them (maybe tomorrow). The AS-Name is “AS-SSI” (there is an AS-Set listed on RIPE named this) which I suspect might lead to the original owner. It looks familiar-ish but I’m not sure who had it before Netflix. Clearly they must have bought it outright, acquired the original owner, or something, but I’ll be damned if I can find historical data on who it originally belonged to. -b From jk at ip-clear.de Fri Oct 13 13:24:02 2017 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Fri, 13 Oct 2017 15:24:02 +0200 Subject: replacing compromised biometric authenticators In-Reply-To: <33e87e9c-3a7e-bd35-5c47-81cb7f3237b4@pubnix.net> References: <20171011210408.GN8671@sizone.org> <20171012205835.GA5109@gsp.org> <33e87e9c-3a7e-bd35-5c47-81cb7f3237b4@pubnix.net> Message-ID: <9204295B-E60F-4277-9108-3067FE3992D4@ip-clear.de> Hi, in the case I mentioned, the datacenter provider (=Level3) removed hand geometry scanners from its facility and switched all users to card + pin. Also the provider is going to run this policy Germany- or even Europe-wide, as being told by Level3 account rep. The mentioned facility does not have any tailgating prevention, e.g. a mantrap or turnstile access. The outside door, which is visible from the street, and the inside colocation doors are now sharing the same access method (card + pin). So now the card becomes valuable and transferable. Before it was: Parking lot: Card, Outside door: Card + pin, Inside door: Card + hand. There is a security sub-sub-contractor on this site, but they are not responsible for access or any thing real :-], thats why I am interested how Level3 runs its others facility and I am still looking for feedback. From contract side the access device is not exactly defined, hence you can accept, quit end of term or of course upgrade your suites, racks, … with a custom solution, as long as Level3 staff can enter, too. To bring things back to the biometric topic: The hand geometry scanner does not save fingerprints but hand sizes and shapes. From current mailings I understand, that people have a lot of different definition of biometric and may not count the hand scanner as "(full?) biometric" device. Regards "bionic" Jörg On 13 Oct 2017, at 13:03, Alain Hebert wrote: >     Odd, > >     1. captcha(?) > >     In my millennia of experience I never saw a captcha used as a > mean for DC access control.  Just as a programmatic way to reduce > brute force for some website functions. > > >     On my network janitor keychain I have (in order of hackability > from easiest to hardest) > >         1. keycard only > >         2. keycard + fingerprints > >         3. keycard + face (2d) > >         4a. keycard + eye > >         4b. keycard + top of hand mapping > >     But all the DCs, I deal with, have highrez cameras and > tailgating controls...  Biometrics are just a part of a wider system. > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > On 10/12/17 16:58, Rich Kulawiec wrote: >> On Wed, Oct 11, 2017 at 05:04:08PM -0400, Ken Chase wrote: >>> If the current best operating practice is to avoid biometrics, why >>> are they >>> still in use out here? >> (1) for the same reason some idiots still use captchas >> (2) new hotness > old and busted, regardless of merits >> (3) because they facilitate coerced risk transference away from the >> people who are actually responsible (and are paid to be so) to the >> people who shouldn't be responsible (and aren't paid to be) >> >> ---rsk >> >> From alandaluz at gmail.com Fri Oct 13 09:25:09 2017 From: alandaluz at gmail.com (Cassidy B. Larson) Date: Fri, 13 Oct 2017 03:25:09 -0600 Subject: 4 or smaller digit ASNs In-Reply-To: <501CC431-262C-453E-AB38-9BB80FDCA0A0@the-watsons.org> References: <1296F0D8-34CD-4C9F-8EF2-82714EDC98CC@beckman.org> <501CC431-262C-453E-AB38-9BB80FDCA0A0@the-watsons.org> Message-ID: Check: https://web.archive.org/web/20030619092539/http://bgp. potaroo.net:80/cgi-bin/as-report?as=AS2906&view=(null) Appears in 2003 it was: OrgName: NCR Corporation -c On Thu, Oct 12, 2017 at 10:28 PM, Brett Watson wrote: > > > On Oct 12, 2017, at 15:53, Richard Hicks > wrote: > > > > Anyone know the history behind ASN 2906 (Netflix)? > > How did they get a number that low? > > I didn’t recognize as2906 so went digging... and I can’t find a thing. > ARIN has a “who has” service but my account on ARIN was locked and I wasn’t > able to unlock without calling them (maybe tomorrow). > > The AS-Name is “AS-SSI” (there is an AS-Set listed on RIPE named this) > which I suspect might lead to the original owner. It looks familiar-ish but > I’m not sure who had it before Netflix. Clearly they must have bought it > outright, acquired the original owner, or something, but I’ll be damned if > I can find historical data on who it originally belonged to. > > -b > From bicknell at ufp.org Fri Oct 13 13:38:51 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 13 Oct 2017 06:38:51 -0700 Subject: 4 or smaller digit ASNs In-Reply-To: References: Message-ID: <20171013133851.GA96852@ussenterprise.ufp.org> In a message written on Thu, Oct 12, 2017 at 05:01:13AM +0000, James Breeden wrote: > I have a client interested in picking up a new AS number but they really want it to be 3 or 4 digits in length. As other's have said, that's difficult. What about going the other way? Ask for 2^32-1. "We have the biggest ASN!" -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From ruairi.carroll at gmail.com Fri Oct 13 14:12:36 2017 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Fri, 13 Oct 2017 15:12:36 +0100 Subject: Rogers Cable contact Message-ID: Hello, Does anyone have a technical contact in Rogers (AS 812) they could refer me to to fix up some issues? Cheers /Ruairi From bzs at theworld.com Fri Oct 13 16:57:16 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 13 Oct 2017 12:57:16 -0400 Subject: Temp at Level 3 data centers In-Reply-To: <84c8cd8f-a2c2-f820-d210-114fdd5ae892@vaxination.ca> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> <84c8cd8f-a2c2-f820-d210-114fdd5ae892@vaxination.ca> Message-ID: <23008.61548.455557.832275@gargle.gargle.HOWL> On October 12, 2017 at 19:56 jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) wrote: > back in the arly 1990s, Tandem had a computer called "Cyclone". (these > were mission critical, fault tolerant machines). ok old fart stories...tho maybe current. IBM's big mainframes would repeat calculations as a way to detect hardware errors. Above a certain temperature they would do more repeating. If there was any disagreement it would be reported and they had some complex statistical formula to determine how many repetitions to try next and what to accept. I assume this was analogous to the various time sync game theoretic formulas to decide which time reference to believe when they conflict. It's not as simple as majority vote, the majority could be wrong (e.g., same stuck bit.) So, at least as it was explained to me, as it got warmer (e.g., A/C failure) the machine would get slower and slower, potentially to a crawl. And there was no doubt a point at which it'd just shut itself off, but before it got there. Since many mainframes were mission critical they were trying to avoid that. That was the kind of thing which made multi-million dollar mainframes cost multi-millions of dollars. Also, the IBM 3090 at least, was cooled via helium-filled pipes kind of like today's liquid cooled systems. It was full of plumbing. If you opened it up some chips were right on copper junction boxes (maybe they were just sensors but it looked cool.) There was always something amusing back then when an IBM service person would show up with one of those typical gas tanks on wheels, like one uses for welding, to top off your mainframe. -- -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 cma at cmadams.net Fri Oct 13 17:51:50 2017 From: cma at cmadams.net (Chris Adams) Date: Fri, 13 Oct 2017 12:51:50 -0500 Subject: Temp at Level 3 data centers In-Reply-To: <23008.61548.455557.832275@gargle.gargle.HOWL> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> <84c8cd8f-a2c2-f820-d210-114fdd5ae892@vaxination.ca> <23008.61548.455557.832275@gargle.gargle.HOWL> Message-ID: <20171013175149.GA3552@cmadams.net> Once upon a time, bzs at theworld.com said: > Also, the IBM 3090 at least, was cooled via helium-filled pipes kind > of like today's liquid cooled systems. It was full of plumbing. If you > opened it up some chips were right on copper junction boxes (maybe > they were just sensors but it looked cool.) Cray supercomputers had Freon lines through them for cooling, up until the last generation of the "old school" supercomputer. That was not sufficient to keep it cool, so they sealed the chassis (which was huge) and pumped it full of 4 tons of Fluorinert. -- Chris Adams From r.engehausen at gmail.com Fri Oct 13 18:10:51 2017 From: r.engehausen at gmail.com (Roy) Date: Fri, 13 Oct 2017 11:10:51 -0700 Subject: Temp at Level 3 data centers In-Reply-To: <20171013175149.GA3552@cmadams.net> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> <84c8cd8f-a2c2-f820-d210-114fdd5ae892@vaxination.ca> <23008.61548.455557.832275@gargle.gargle.HOWL> <20171013175149.GA3552@cmadams.net> Message-ID: <6a6f27d5-0039-8e1e-72f3-599c105d04fc@gmail.com> The IBM 308x and 309x series mainframes were water cooled.  They did have Thermal Conduction Modules which had a helium-filled metal cap, which contains one piston per chip; the piston presses against the back of each chip to provide a heat conduction path from the chip to the cap.  The cap was connected to the chilled water supply. On 10/13/2017 10:51 AM, Chris Adams wrote: > Once upon a time, bzs at theworld.com said: >> Also, the IBM 3090 at least, was cooled via helium-filled pipes kind >> of like today's liquid cooled systems. It was full of plumbing. If you >> opened it up some chips were right on copper junction boxes (maybe >> they were just sensors but it looked cool.) > Cray supercomputers had Freon lines through them for cooling, up until > the last generation of the "old school" supercomputer. That was not > sufficient to keep it cool, so they sealed the chassis (which was huge) > and pumped it full of 4 tons of Fluorinert. From randy at psg.com Fri Oct 13 18:26:56 2017 From: randy at psg.com (Randy Bush) Date: Fri, 13 Oct 2017 11:26:56 -0700 Subject: abha Message-ID: a moment of silence on this 16th anniversary of her tragic death From randy at psg.com Fri Oct 13 18:27:51 2017 From: randy at psg.com (Randy Bush) Date: Fri, 13 Oct 2017 11:27:51 -0700 Subject: abha In-Reply-To: References: Message-ID: > a moment of silence on this 16th anniversary of her tragic death and another for an idiot who can not use ical. sorry. From jfmezei_nanog at vaxination.ca Fri Oct 13 18:35:25 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 13 Oct 2017 14:35:25 -0400 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> Message-ID: Answer from Allstream (aka Zayo) A combination: Tor-Ott-Mtl N route is CP & S route is CN. From Tor-Wpg its mostly CN on the N route and the S goes thru various US routes. So Allstream would get you out west via the more northern CN line from Toronto. So you would need to find someone who has fibre along the CP line. (note: Ottawa to North Bay, the tracks have been removed a couple years ago, not sure if there is any fibre left. What is interesting is Allstream saying Tor-Ott-Mtl route is on CP. CP's transcontinental line from Montreal-Ottawa-Sudbury no longer exists. (Rigaud to Ottawa is Trans Canada Trail now). But CP still has its Smoth Falls to Montreal line. (and at the DOrion commuter train station (CP tracks) there are "do not dig" signs from Allstream. From jarenangerbauer at gmail.com Fri Oct 13 18:38:21 2017 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Fri, 13 Oct 2017 12:38:21 -0600 Subject: abha In-Reply-To: References: Message-ID: > > a moment of silence on this 16th anniversary of her tragic death > > and another for an idiot who can not use ical. sorry. > Friday the 13th. From michael.d.morrison at me.com Fri Oct 13 17:38:14 2017 From: michael.d.morrison at me.com (Michael Morrison) Date: Fri, 13 Oct 2017 10:38:14 -0700 Subject: Hong Kong to SHANGHAI routes Message-ID: <50AEA059-27E3-4802-B9D1-75209B712DE6@me.com> We have noticed there's been an increase in latency from Hong Kong to SHANGHAI. Usually running about 70-80ms, up over 300ms now. Per a traceroute I can see NTT is jumping over to LA before going over to Sha(China Unicom) via Level 3. Anyone else on this thread seen this behavior and or have any information at to why this is happening? Level3? China Unicom? NTT? Any engineers from these companies on this thread? Regards, Michael M Sent from my iPhone From eric.kuhnke at gmail.com Fri Oct 13 18:50:11 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 13 Oct 2017 11:50:11 -0700 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> Message-ID: On a somewhat related note, if anyone has KMZs of the railway-based ROWs from Calgary-Vancouver (Fraser Valley area) and is able to share them, please contact me off list. I'm hoping to avoid re-inventing the wheel and time/labor of manually creating vector lines along the known railway corridors, for a data set that already exists on somebody's desktop... On Fri, Oct 13, 2017 at 11:35 AM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > Answer from Allstream (aka Zayo) > > A combination: Tor-Ott-Mtl N route is CP & S route is CN. From Tor-Wpg > its mostly CN on the N route and the S goes thru various US routes. > > > > So Allstream would get you out west via the more northern CN line from > Toronto. > > So you would need to find someone who has fibre along the CP line. > > (note: Ottawa to North Bay, the tracks have been removed a couple years > ago, not sure if there is any fibre left. > > What is interesting is Allstream saying Tor-Ott-Mtl route is on CP. CP's > transcontinental line from Montreal-Ottawa-Sudbury no longer exists. > (Rigaud to Ottawa is Trans Canada Trail now). But CP still has its > Smoth Falls to Montreal line. (and at the DOrion commuter train station > (CP tracks) there are "do not dig" signs from Allstream. > > From jfmezei_nanog at vaxination.ca Fri Oct 13 19:02:35 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 13 Oct 2017 15:02:35 -0400 Subject: Temp at Level 3 data centers In-Reply-To: <6a6f27d5-0039-8e1e-72f3-599c105d04fc@gmail.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> <84c8cd8f-a2c2-f820-d210-114fdd5ae892@vaxination.ca> <23008.61548.455557.832275@gargle.gargle.HOWL> <20171013175149.GA3552@cmadams.net> <6a6f27d5-0039-8e1e-72f3-599c105d04fc@gmail.com> Message-ID: <55ea65b6-7954-f2ea-c3b3-f6e9c024abd2@vaxination.ca> On 2017-10-13 14:10, Roy wrote: > > > The IBM 308x and 309x series mainframes were water cooled. The bank I worked for had just installed one. A big change were noise levels, the thing was really quiet. But servicing now required a plumber too. (there was a separate cabinet for the water pumps as I recall.) But in all cases, the issue is how long you can survive when your "heat dump" is not available. If nobody is removing heat from your water loop it will eventually fail too. In the end, it is a lot easier to provide redundancy for HVAC in one large room than splitting the DC into small suites that each have their 1 unit. Redundancy there would require 2 units per suite. And the problem with having AC units that are capable of twice the load (in case other one fails) is that it increases the on-off cycles and thus reduces lifetime (increases likelyhood of failure). From hannigan at gmail.com Fri Oct 13 20:05:02 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 13 Oct 2017 16:05:02 -0400 Subject: Temp at Level 3 data centers In-Reply-To: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> Message-ID: Hi David, 80F seems ~reasonable to me. What is the inlet temp, the temperature air is going in at? What kind of gear are operating? Routers and switches? Servers? Disk? Is the cabinet top fan working? Most modern equipment should be able to handle those temps. As another poster noted, are these triggers modifiable (or have they been)? I would refer to the manufactures guidelines. You haven't given us enough information to help. You can refer (them) to ASHRAE standards in your conversation. I'd be surprised if they weren't already well aware of it and practicing most of what it preaches. They may operate safely outside of some norms. 15F-20F cooler? You might be paying too much for colo if that's true. Best, -M< On Wed, Oct 11, 2017 at 8:31 AM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Curious if anyone on here colo’s equipment at a Level 3 facility and has > found the temperature unacceptably warm? I’m having that experience > currently, where ambient temp is in the 80’s, but they tell me that’s > perfectly fine because vented tiles have been placed in front of all > equipment racks. My equipment is alarming for high temps, so obviously not > fine. Trying to find my way up to whomever I can complain to that’s in a > position to do something about it but it seems the support staff have been > told to brush questions about temp off as much as possible. Was wondering > if this is a country-wide thing for them or unique to the data center I > have equipment in. I have equipment in several others from different > companies and most are probably 15-20 degrees cooler. > > Thanks, > > David > From r.engehausen at gmail.com Fri Oct 13 20:24:49 2017 From: r.engehausen at gmail.com (Roy) Date: Fri, 13 Oct 2017 13:24:49 -0700 Subject: Temp at Level 3 data centers In-Reply-To: <55ea65b6-7954-f2ea-c3b3-f6e9c024abd2@vaxination.ca> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <37BBD972-0260-4207-8180-DD9C1D7A37FC@neilltech.com> <0f79a0d2-5ee5-a5d1-aea1-86487e9de60d@gmail.com> <9578293AE169674F9A048B2BC9A081B40262155CB8@MUNPRDMBXA1.medline.com> <84c8cd8f-a2c2-f820-d210-114fdd5ae892@vaxination.ca> <23008.61548.455557.832275@gargle.gargle.HOWL> <20171013175149.GA3552@cmadams.net> <6a6f27d5-0039-8e1e-72f3-599c105d04fc@gmail.com> <55ea65b6-7954-f2ea-c3b3-f6e9c024abd2@vaxination.ca> Message-ID: <36a23718-9479-3b97-e8c8-a071784544ab@gmail.com> > On 2017-10-13 14:10, Roy wrote: >> >> The IBM 308x and 309x series mainframes were water cooled. > > The bank I worked for had just installed one. A big change were noise > levels, the thing was really quiet. But servicing now required a plumber > too. (there was a separate cabinet for the water pumps as I recall.) > > But in all cases, the issue is how long you can survive when your "heat > dump" is not available. If nobody is removing heat from your water loop > it will eventually fail too. > > > In the end, it is a lot easier to provide redundancy for HVAC in one > large room than splitting the DC into small suites that each have their > 1 unit. Redundancy there would require 2 units per suite. And the > problem with having AC units that are capable of twice the load (in case > other one fails) is that it increases the on-off cycles and thus reduces > lifetime (increases likelyhood of failure). The separate box was a heat exchanger.     In the "old" days, buildings had central systems that provided chilled water.  Its similar to your house HVAC where an outside unit cools Freon and you have a heat exchanger that cools the inside air.  In the case of the water cooled mainframe, the same chilled water was connected  to the exchanger and not directly to the computer.  The water running through the computer was a closed system. From dhubbard at dino.hostasaurus.com Fri Oct 13 20:37:54 2017 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 13 Oct 2017 20:37:54 +0000 Subject: Temp at Level 3 data centers In-Reply-To: References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> Message-ID: <89F92405-4AD5-46B4-BDB0-8E792308CC4D@dino.hostasaurus.com> Thanks for all the opinions and experiences with this on this on and off list. The facility in question is not one that has a cold/hot row or containment concept so ambient temp plays a greater role than in other facilities. Some folks from Level 3 reached out and are working to help me with the situation, so hopefully things are headed in the right direction now. David From: Martin Hannigan Date: Friday, October 13, 2017 at 4:05 PM To: David Hubbard Cc: "nanog at nanog.org" Subject: Re: Temp at Level 3 data centers Hi David, 80F seems ~reasonable to me. What is the inlet temp, the temperature air is going in at? What kind of gear are operating? Routers and switches? Servers? Disk? Is the cabinet top fan working? Most modern equipment should be able to handle those temps. As another poster noted, are these triggers modifiable (or have they been)? I would refer to the manufactures guidelines. You haven't given us enough information to help. You can refer (them) to ASHRAE standards in your conversation. I'd be surprised if they weren't already well aware of it and practicing most of what it preaches. They may operate safely outside of some norms. 15F-20F cooler? You might be paying too much for colo if that's true. Best, -M< On Wed, Oct 11, 2017 at 8:31 AM, David Hubbard > wrote: Curious if anyone on here colo’s equipment at a Level 3 facility and has found the temperature unacceptably warm? I’m having that experience currently, where ambient temp is in the 80’s, but they tell me that’s perfectly fine because vented tiles have been placed in front of all equipment racks. My equipment is alarming for high temps, so obviously not fine. Trying to find my way up to whomever I can complain to that’s in a position to do something about it but it seems the support staff have been told to brush questions about temp off as much as possible. Was wondering if this is a country-wide thing for them or unique to the data center I have equipment in. I have equipment in several others from different companies and most are probably 15-20 degrees cooler. Thanks, David From SNaslund at medline.com Fri Oct 13 20:42:40 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 13 Oct 2017 20:42:40 +0000 Subject: Temp at Level 3 data centers In-Reply-To: <89F92405-4AD5-46B4-BDB0-8E792308CC4D@dino.hostasaurus.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <89F92405-4AD5-46B4-BDB0-8E792308CC4D@dino.hostasaurus.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40262163F5C@MUNPRDMBXA1.medline.com> Funny how NANOG posts seem to precede actual attention from vendors isn't it. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hubbard Sent: Friday, October 13, 2017 3:38 PM To: nanog at nanog.org Subject: Re: Temp at Level 3 data centers Thanks for all the opinions and experiences with this on this on and off list. The facility in question is not one that has a cold/hot row or containment concept so ambient temp plays a greater role than in other facilities. Some folks from Level 3 reached out and are working to help me with the situation, so hopefully things are headed in the right direction now. David From: Martin Hannigan Date: Friday, October 13, 2017 at 4:05 PM To: David Hubbard Cc: "nanog at nanog.org" Subject: Re: Temp at Level 3 data centers Hi David, 80F seems ~reasonable to me. What is the inlet temp, the temperature air is going in at? What kind of gear are operating? Routers and switches? Servers? Disk? Is the cabinet top fan working? Most modern equipment should be able to handle those temps. As another poster noted, are these triggers modifiable (or have they been)? I would refer to the manufactures guidelines. You haven't given us enough information to help. You can refer (them) to ASHRAE standards in your conversation. I'd be surprised if they weren't already well aware of it and practicing most of what it preaches. They may operate safely outside of some norms. 15F-20F cooler? You might be paying too much for colo if that's true. Best, -M< On Wed, Oct 11, 2017 at 8:31 AM, David Hubbard > wrote: Curious if anyone on here colo’s equipment at a Level 3 facility and has found the temperature unacceptably warm? I’m having that experience currently, where ambient temp is in the 80’s, but they tell me that’s perfectly fine because vented tiles have been placed in front of all equipment racks. My equipment is alarming for high temps, so obviously not fine. Trying to find my way up to whomever I can complain to that’s in a position to do something about it but it seems the support staff have been told to brush questions about temp off as much as possible. Was wondering if this is a country-wide thing for them or unique to the data center I have equipment in. I have equipment in several others from different companies and most are probably 15-20 degrees cooler. Thanks, David From bruns at 2mbit.com Fri Oct 13 20:55:18 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 13 Oct 2017 14:55:18 -0600 Subject: Temp at Level 3 data centers In-Reply-To: <9578293AE169674F9A048B2BC9A081B40262163F5C@MUNPRDMBXA1.medline.com> References: <39086E4C-0BDF-40BF-922A-38A9457F82FF@dino.hostasaurus.com> <89F92405-4AD5-46B4-BDB0-8E792308CC4D@dino.hostasaurus.com> <9578293AE169674F9A048B2BC9A081B40262163F5C@MUNPRDMBXA1.medline.com> Message-ID: <8e463028-e2a1-e0e4-4e0c-e442db476de4@2mbit.com> On 10/13/2017 2:42 PM, Naslund, Steve wrote: > Funny how NANOG posts seem to precede actual attention from vendors isn't it. Squeaky wheel, grease. Same reason why it takes me berating companies on Twitter publicly before things actually get done. *Stares directly at Verizon for a previous incident where rejection message from an e-mail block said to e-mail a support address to get removed, but support address has same filters and blocked unblocked request* -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From sean at donelan.com Fri Oct 13 20:59:17 2017 From: sean at donelan.com (Sean Donelan) Date: Fri, 13 Oct 2017 16:59:17 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts Message-ID: Has anyone heard if the smart speaker companies (Amazon Echo, Google Home) plan to include emergency alert capability? An estimate 10% of households own a smart speaker, and Gartner (well-known for its forecasting accuracy) predicts 75% of US households will have a smart speaker by 2020. Although most silicon valley tech nerds are still in the "invincible" years, were the california fires close enough to silicon valley that smart speaker developers might think an emergency could affect them. And an emergency alert capability in their smart speakers might be important? From math at sizone.org Fri Oct 13 21:02:42 2017 From: math at sizone.org (Ken Chase) Date: Fri, 13 Oct 2017 17:02:42 -0400 Subject: AS PATH limits In-Reply-To: <20170930144134.GU17040@sizone.org> References: <20170930144134.GU17040@sizone.org> Message-ID: <20171013210242.GJ11838@sizone.org> It is happening AGAIN. And of course it started on a friday aft 15 min before quittin' time in EDT: Last time it was 186.177.184.0/23 0 174 262206 262206 262197 262197 *> 186.176.186.0/23 38.x.x.x 45050 0 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 ? /kc -- Ken Chase - math at sizone.org Guelph Canada From job at instituut.net Fri Oct 13 21:17:53 2017 From: job at instituut.net (Job Snijders) Date: Fri, 13 Oct 2017 21:17:53 +0000 Subject: AS PATH limits In-Reply-To: <20171013210242.GJ11838@sizone.org> References: <20170930144134.GU17040@sizone.org> <20171013210242.GJ11838@sizone.org> Message-ID: Has anyone tried calling them? Kind regards, Job On Fri, 13 Oct 2017 at 23:03, Ken Chase wrote: > It is happening AGAIN. > > And of course it started on a friday aft 15 min before quittin' time in > EDT: > > Last time it was 186.177.184.0/23 0 174 262206 262206 262197 262197 > > *> 186.176.186.0/23 38.x.x.x 45050 0 174 262206 > 262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 > 262197 262197 262197 262197 ? > > /kc > -- > Ken Chase - math at sizone.org Guelph Canada > From clinton at scripty.com Fri Oct 13 21:20:03 2017 From: clinton at scripty.com (Clinton Work) Date: Fri, 13 Oct 2017 15:20:03 -0600 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> Message-ID: <1507929603.602724.1138184128.6C59596B@webmail.messagingengine.com> My understanding is that nobody has a 2nd diverse fiber route north of the great lakes from Winnipeg to Toronto. Every provider makes use of a fiber route south of the great lakes thru the US in order to provide diversity. The following map shows that the CN rail and CP Rail lines across over each other at multiple times from Winnipeg to Toronto. http://www.cpr.ca/en/choose-rail-site/Documents/cp-network-map-2016.pdf On Fri, Oct 13, 2017, at 12:35 PM, Jean-Francois Mezei wrote: > Answer from Allstream (aka Zayo) > > So Allstream would get you out west via the more northern CN line from > Toronto. > > So you would need to find someone who has fibre along the CP line. > From jfmezei_nanog at vaxination.ca Fri Oct 13 22:00:04 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 13 Oct 2017 18:00:04 -0400 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: <1507929603.602724.1138184128.6C59596B@webmail.messagingengine.com> References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> <1507929603.602724.1138184128.6C59596B@webmail.messagingengine.com> Message-ID: <8389c2ce-a875-3578-f3e5-ab24818be4cd@vaxination.ca> On 2017-10-13 17:20, Clinton Work wrote: > > My understanding is that nobody has a 2nd diverse fiber route north of > the great lakes from Winnipeg to Toronto. Every provider makes use of > a fiber route south of the great lakes thru the US in order to provide > diversity. But if provider 1 has its 1 fibre on the CN line and provider 2 has its 1 fibre along CP line (or road), then you can get diversity by getting bandwidth from both. > The following map shows that the CN rail and CP Rail lines across over > each other at multiple times from Winnipeg to Toronto. At Rennie MB, the CN line has a bridge over the CP line. Between Sudbury and Toronto, you may have to live with the crossings. But I suspect they are bridged too (with some interchange points near Sudbury). Ideally, there would be some link leftover from when there were tracks between Ottawa and Sudbury. Tracks remain between Mattawa and Sudbury. (Ottawa-Mattawa removed circa 2012). Bell Canada still wants to serve those areas even if tracks no longer present. Note: road has interesting side effects. A new bridge on highway 17 "broke" when it got too cold: the stay cables on suspension bridge contracted and ended up lifting bridge deck by about 1m above ground level. So any fibre conduits would have been severed as it crossed from ground to bridge. From aaron at heyaaron.com Fri Oct 13 22:33:05 2017 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 13 Oct 2017 15:33:05 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: I messaged the Nest guys a few weeks ago about that very issue. I think it would be somewhat simple for them to put an RF module in their Protect devices (smoke alarms) and a speaker to alert about the issue. Since they are wifi-enabled, they could probably also arrange a clearer audio feed over the internet with a fallback to RF if the internet is down/power is out. -A On Fri, Oct 13, 2017 at 1:59 PM, Sean Donelan wrote: > > Has anyone heard if the smart speaker companies (Amazon Echo, Google Home) > plan to include emergency alert capability? An estimate 10% of households > own a smart speaker, and Gartner (well-known for its forecasting accuracy) > predicts 75% of US households will have a smart speaker by 2020. > > Although most silicon valley tech nerds are still in the "invincible" years, > were the california fires close enough to silicon valley that smart speaker > developers might think an emergency could affect them. And an emergency > alert capability in their smart speakers might be important? > From jared at puck.nether.net Fri Oct 13 22:40:49 2017 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 13 Oct 2017 18:40:49 -0400 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: I’m quite surprised they didn’t send out a local emergency alert. I’ve gotten these for Tornadoes and amber alerts. Wildfires would be comparable to a Tornado IMO. Jared Mauch > On Oct 13, 2017, at 6:33 PM, Aaron C. de Bruyn via NANOG wrote: > > I messaged the Nest guys a few weeks ago about that very issue. I > think it would be somewhat simple for them to put an RF module in > their Protect devices (smoke alarms) and a speaker to alert about the > issue. Since they are wifi-enabled, they could probably also arrange > a clearer audio feed over the internet with a fallback to RF if the > internet is down/power is out. > > -A > >> On Fri, Oct 13, 2017 at 1:59 PM, Sean Donelan wrote: >> >> Has anyone heard if the smart speaker companies (Amazon Echo, Google Home) >> plan to include emergency alert capability? An estimate 10% of households >> own a smart speaker, and Gartner (well-known for its forecasting accuracy) >> predicts 75% of US households will have a smart speaker by 2020. >> >> Although most silicon valley tech nerds are still in the "invincible" years, >> were the california fires close enough to silicon valley that smart speaker >> developers might think an emergency could affect them. And an emergency >> alert capability in their smart speakers might be important? >> From brett at the-watsons.org Fri Oct 13 22:56:54 2017 From: brett at the-watsons.org (Brett Watson) Date: Fri, 13 Oct 2017 15:56:54 -0700 Subject: abha In-Reply-To: References: Message-ID: On Oct 13, 2017, at 11:26 AM, Randy Bush wrote: > > a moment of silence on this 16th anniversary of her tragic death One of the smartest geeks I have known, and she always lit up the room she was in with her smile and attitude. -b From jfmezei_nanog at vaxination.ca Fri Oct 13 22:58:47 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 13 Oct 2017 18:58:47 -0400 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: <9be96f14-bc12-d945-651b-ddf3ab251bd7@vaxination.ca> Note: Google Maps shows various alerts applicable to the region you are looking at in maps. So, assuming its Speaker is geolocated, Google would know if an alert is applicable to its location and be able to send it to the unit. From andreas at naund.org Fri Oct 13 23:24:49 2017 From: andreas at naund.org (Andreas Ott) Date: Fri, 13 Oct 2017 16:24:49 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: ; from sean@donelan.com on Fri, Oct 13, 2017 at 04:59:17PM -0400 References: Message-ID: <20171013162449.H4389@naund.org> On Fri, Oct 13, 2017 at 04:59:17PM -0400, Sean Donelan wrote: > Has anyone heard if the smart speaker companies (Amazon Echo, Google Home) > plan to include emergency alert capability? An estimate 10% of households > own a smart speaker, and Gartner (well-known for its forecasting > accuracy) predicts 75% of US households will have a smart speaker by 2020. How is geolocation achieved on these in-home devices? Is that tied to the ~80% accuracy of general purpose IP geolocation? Do they have GPS? Or is this done via account data in case it contains a street location? This is different from alerts to cellphones "tethered" to a tower where you get a better location info, even for E911 (exclude corner cases where you are on a "mountain" top overlooking silicon Valley and lock onto a tower further away). There you are effectively sending the alert to the tower at a certain location and it multicasts it out to the phones that are attached to it. -andreas From petebaldridge at gmail.com Fri Oct 13 23:31:09 2017 From: petebaldridge at gmail.com (Peter Baldridge) Date: Fri, 13 Oct 2017 16:31:09 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <20171013162449.H4389@naund.org> References: <20171013162449.H4389@naund.org> Message-ID: I know with Alexa products they just ask you for a postal code for weather updates. Probably covers 99 percent of cases. On Oct 13, 2017 4:26 PM, "Andreas Ott" wrote: > On Fri, Oct 13, 2017 at 04:59:17PM -0400, Sean Donelan wrote: > > Has anyone heard if the smart speaker companies (Amazon Echo, Google > Home) > > plan to include emergency alert capability? An estimate 10% of > households > > own a smart speaker, and Gartner (well-known for its forecasting > > accuracy) predicts 75% of US households will have a smart speaker by > 2020. > > How is geolocation achieved on these in-home devices? Is that tied to > the ~80% accuracy of general purpose IP geolocation? Do they have GPS? > Or is this done via account data in case it contains a street location? > > This is different from alerts to cellphones "tethered" to a tower where > you get a better location info, even for E911 (exclude corner cases > where you are on a "mountain" top overlooking silicon Valley and lock > onto a tower further away). There you are effectively sending the alert > to the tower at a certain location and it multicasts it out to the phones > that are attached to it. > > -andreas > From sean at donelan.com Sat Oct 14 00:01:45 2017 From: sean at donelan.com (Sean Donelan) Date: Fri, 13 Oct 2017 20:01:45 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: On Fri, 13 Oct 2017, Jared Mauch wrote: > I’m quite surprised they didn’t send out a local emergency alert. I’ve > gotten these for Tornadoes and amber alerts. Wildfires would be > comparable to a Tornado IMO. Like most news stories, its a little more complicated. Napa, Sonoma sent an evacuation alert by Nixle, SoCoAlert and social media (i.e. Facebook). They also made reverse-911 calls to landlines, and sent police to knock on doors in neighborhoods. Lake County sent an evacuation alert by both EAS and WEA (different from SMStext, like an Amber alert). Orange County sent an evacuation alert by WEA. The National Weather Service will forward alerts from local emergency management officials about evacuations and wildfires on request, but doesn't issue evacuation or wildfire alerts itself. The reason given by emergency management officials was WEA (cell phones) and EAS (cable, radio and TV) would cause public panic and traffic jams because those systems alert everyone in an entire county. One of the biggest challenges for emergency managers is reaching people in the middle of the night at homes as fewer people have landline phones. Smart speakers seem like an interesting way to notify people -- assuming the owner has a working broadband connection, allows "push" notifications, etc. While have a backup RF receiver would be nice, that's what a cell phone or weather alert radio is good at. Many emergency alerts are distributed through the Internet now, i.e. IPAWS, so smart speaker companies don't need to have special EAS receivers anymore. Most of the smart speaker companies aggressively try to get users to add their zip code/postal code to geolocate the unit. In addition to providing local weather and news, I assume it helps the smartspeaker companies target advertising. And since I've already gotten a private email about it, end-user/consumer alerting devices can filter alerts. The user could block the 3am amber alerts, but still allow evacuation, and other extreme alerts. Back to my question - Hey, smart speaker companies... Any plans? From nanog at ics-il.net Sat Oct 14 19:26:50 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 14 Oct 2017 14:26:50 -0500 (CDT) Subject: Private Link between TOR and CHI In-Reply-To: References: Message-ID: <659012525.2424.1508009209194.JavaMail.mhammett@ThunderFuck> I would start with this page: http://www.151frontstreet.com/en_tenantdirectory.htm or whatever datacenter you're in there. Chances are, any carrier listed in 151 Front St. will also be in 350 E. Cermak. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ryan Gard" To: nanog at nanog.org Sent: Wednesday, October 11, 2017 2:04:40 PM Subject: Private Link between TOR and CHI Trying to source some cost effective solutions or vendors that could provide connectivity in this scenario. Essentially I'll be looking to expand presence into Chicago, and as such, will need to source a third party to provide connectivity from 151 Front Street in Toronto to 350 Cermak in Chicago. Specifically, we're looking to build a presence in Chicago to pursue peering agreements with other providers at 350 Cermak. If you're aware of any providers that would be able to provide this connectivity, that would be perfect. Thanks! -- Ryan Gard From jbothe at me.com Sat Oct 14 19:48:15 2017 From: jbothe at me.com (JASON BOTHE) Date: Sat, 14 Oct 2017 14:48:15 -0500 Subject: Private Link between TOR and CHI In-Reply-To: <659012525.2424.1508009209194.JavaMail.mhammett@ThunderFuck> References: <659012525.2424.1508009209194.JavaMail.mhammett@ThunderFuck> Message-ID: Zayo provides a very reasonable 10G wave service between the two locations. J~ Sent from my iPhone > On Oct 14, 2017, at 14:26, Mike Hammett wrote: > > I would start with this page: > > http://www.151frontstreet.com/en_tenantdirectory.htm > > > or whatever datacenter you're in there. Chances are, any carrier listed in 151 Front St. will also be in 350 E. Cermak. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Ryan Gard" > To: nanog at nanog.org > Sent: Wednesday, October 11, 2017 2:04:40 PM > Subject: Private Link between TOR and CHI > > Trying to source some cost effective solutions or vendors that could > provide connectivity in this scenario. Essentially I'll be looking to > expand presence into Chicago, and as such, will need to source a third > party to provide connectivity from 151 Front Street in Toronto to 350 > Cermak in Chicago. Specifically, we're looking to build a presence in > Chicago to pursue peering agreements with other providers at 350 Cermak. > > If you're aware of any providers that would be able to provide this > connectivity, that would be perfect. > > Thanks! > > -- > Ryan Gard > From valdis.kletnieks at vt.edu Sun Oct 15 01:41:45 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 14 Oct 2017 21:41:45 -0400 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: <8389c2ce-a875-3578-f3e5-ab24818be4cd@vaxination.ca> References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> <1507929603.602724.1138184128.6C59596B@webmail.messagingengine.com> <8389c2ce-a875-3578-f3e5-ab24818be4cd@vaxination.ca> Message-ID: <91074.1508031705@turing-police.cc.vt.edu> On Fri, 13 Oct 2017 18:00:04 -0400, Jean-Francois Mezei said: > Note: road has interesting side effects. A new bridge on highway 17 > "broke" when it got too cold: the stay cables on suspension bridge > contracted and ended up lifting bridge deck by about 1m above ground > level. So any fibre conduits would have been severed as it crossed from > ground to bridge. Actually, it wasn't an entire meter - photos say an entire *foot* perhaps. Stupid metric-imperial conversion error :) http://www.cbc.ca/news/canada/thunder-bay/nipigon-bridge-transcanada-update-1.3398207 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From joe at nethead.com Sat Oct 14 01:50:51 2017 From: joe at nethead.com (Joe Hamelin) Date: Fri, 13 Oct 2017 18:50:51 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: I would think that Amazon knows where my Echo is since it's the same IP that I order (way too much crap) from. Same with Google, maps knows where home is. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 From valdis.kletnieks at vt.edu Sun Oct 15 05:01:09 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 15 Oct 2017 01:01:09 -0400 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: Message-ID: <101992.1508043669@turing-police.cc.vt.edu> On Fri, 13 Oct 2017 18:50:51 -0700, Joe Hamelin said: > I would think that Amazon knows where my Echo is since it's the same IP > that I order (way too much crap) from. It knows the usual delivery address. That's not necessarily the same thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From rjoffe at centergate.com Sun Oct 15 23:00:00 2017 From: rjoffe at centergate.com (Rodney Joffe) Date: Sun, 15 Oct 2017 19:00:00 -0400 Subject: 19 years ago today (Oct 16th, 1998) we lost our guide - Jon Postel - RFC2468 Message-ID: <8F5D9A89-7BBF-4A57-A2C9-1E8E500D4800@centergate.com> To us greaybeards, it feels like just yesterday. And as Randy points out, this coming Friday we also remember Abha who passed away 16 years ago, in 2001. http://www.neebu.net/~khuon/abha/ Sigh. From fergdawgster at mykolab.com Sun Oct 15 23:41:35 2017 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sun, 15 Oct 2017 16:41:35 -0700 Subject: 19 years ago today (Oct 16th, 1998) we lost our guide - Jon Postel - RFC2468 In-Reply-To: <8F5D9A89-7BBF-4A57-A2C9-1E8E500D4800@centergate.com> References: <8F5D9A89-7BBF-4A57-A2C9-1E8E500D4800@centergate.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I think of them often. Peace. - - ferg On 10/15/2017 4:00 PM, Rodney Joffe wrote: > To us greaybeards, it feels like just yesterday. And as Randy > points out, this coming Friday we also remember Abha who passed > away 16 years ago, in 2001. http://www.neebu.net/~khuon/abha/ > > Sigh. > - -- Paul Ferguson ICEBRG.io, Seattle USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlnj8i8ACgkQKJasdVTchbIlkwD/ZvveS3X+xLlanPe1VuLb88eu WfPsP69wcm8sr+V5TpABAKBUv7+KSuo8EITlhOiq2Rp1caQl6FarxbXIi6KH1hvU =cdBp -----END PGP SIGNATURE----- From joelja at bogus.com Mon Oct 16 01:20:52 2017 From: joelja at bogus.com (joel jaeggli) Date: Sun, 15 Oct 2017 18:20:52 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: <101992.1508043669@turing-police.cc.vt.edu> References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: <60cb72c6-2841-408d-7621-1cf485e35872@bogus.com> On 10/14/17 22:01, valdis.kletnieks at vt.edu wrote: > On Fri, 13 Oct 2017 18:50:51 -0700, Joe Hamelin said: >> I would think that Amazon knows where my Echo is since it's the same IP >> that I order (way too much crap) from. > > It knows the usual delivery address. That's not necessarily the same thing. It pairs with your phone via bluetooth, also wifi geolocation (e.g. skyhook) tends to be fairly accurate in moderately high density residential environments. From sean at donelan.com Mon Oct 16 02:09:21 2017 From: sean at donelan.com (Sean Donelan) Date: Sun, 15 Oct 2017 22:09:21 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: <101992.1508043669@turing-police.cc.vt.edu> References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: On Sun, 15 Oct 2017, valdis.kletnieks at vt.edu wrote: > On Fri, 13 Oct 2017 18:50:51 -0700, Joe Hamelin said: >> I would think that Amazon knows where my Echo is since it's the same IP >> that I order (way too much crap) from. > It knows the usual delivery address. That's not necessarily the same thing. > First, need to figure out if any smart speaker manufacturers have any plans to add emergency alerts to their product. Only need to solve the other problems if they do, otherwise it doesn't matter. While VOIP phones needed exact addresses for 9-1-1 purposes, emergency alerts are rarely as specific as a city or county. An exact longitude/latitude would be nice to have, but probably not necessary for most emergency alerts. All the smart speakers ask for the user's location, at least a zip code, during the installation. And they seem to use the typical advertising network IP address geolocation. It would be creepy if an emergency alert was too targetted. It may be better to keep it larger than a mile radius, rather than a single house. From aaron at heyaaron.com Mon Oct 16 02:52:06 2017 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Sun, 15 Oct 2017 19:52:06 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: Someone do a kickstarter already. I'll contribute. ;) -A On Sun, Oct 15, 2017 at 7:09 PM, Sean Donelan wrote: > On Sun, 15 Oct 2017, valdis.kletnieks at vt.edu wrote: >> >> On Fri, 13 Oct 2017 18:50:51 -0700, Joe Hamelin said: >>> >>> I would think that Amazon knows where my Echo is since it's the same IP >>> that I order (way too much crap) from. >> >> It knows the usual delivery address. That's not necessarily the same >> thing. >> > > First, need to figure out if any smart speaker manufacturers have any plans > to add emergency alerts to their product. Only need to solve the other > problems if they do, otherwise it doesn't matter. > > > While VOIP phones needed exact addresses for 9-1-1 purposes, emergency > alerts are rarely as specific as a city or county. An exact > longitude/latitude would be nice to have, but probably not necessary for > most emergency alerts. All the smart speakers ask for the user's location, > at least a zip code, during the installation. And they seem to use the > typical advertising network IP address geolocation. > > It would be creepy if an emergency alert was too targetted. It may be > better to keep it larger than a mile radius, rather than a single house. From beckman at angryox.com Mon Oct 16 03:08:50 2017 From: beckman at angryox.com (Peter Beckman) Date: Sun, 15 Oct 2017 23:08:50 -0400 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: It is theoretically simple to: 1. Turn the address of your Smart Speaker into coordinates 2. Receive ALL alerts and only act upon those that apply to your location This way it isn't creepy, because the emergency alert wasn't targeted to you, but your device was aware enough to determine that you are in the warned area. Taking this further, let's have manufacturers build the location awareness into the device, rather than the upstream service (e.g. Amazon, Google, Apple). Your smart speaker receives a stream of ALL the alerts, and if you are in a warned area, and you enable them, they alert you. With the processing power on these speakers, and the likely small quantity and amount of data per alert to determine if it applies, it should be achievable while still protecting your smart speaker location. Beckman On Sun, 15 Oct 2017, Sean Donelan wrote: > It would be creepy if an emergency alert was too targetted. It may be better > to keep it larger than a mile radius, rather than a single house. Jean-Francois Mezei wrote: > So, assuming its Speaker is geolocated, Google would know if an alert is > applicable to its location and be able to send it to the unit. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From roll at Stupi.SE Sun Oct 15 10:32:44 2017 From: roll at Stupi.SE (Peter Lothberg) Date: Sun, 15 Oct 2017 10:32:44 GMT Subject: 19 years ago today (Oct 16th, 1998) we lost our guide - Jon Postel - RFC2468 In-Reply-To: <8F5D9A89-7BBF-4A57-A2C9-1E8E500D4800@centergate.com> Message-ID: Abha... http://www.lothberg.org/cgi-bin/thumb?20010321/dscn6739.jpg --P From valdis.kletnieks at vt.edu Mon Oct 16 07:38:19 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 16 Oct 2017 03:38:19 -0400 Subject: Gonna be a long day for anybody with CPE that does WPA2.. Message-ID: <193712.1508139499@turing-police.cc.vt.edu> Looks like WPA2 may have just become the new WEP. And it looks like we're all going to be reflashing a lot of devices. "The proof-of-concept exploit is called KRACK, short for Key Reinstallation Attacks. The research has been a closely guarded secret for weeks ahead of a coordinated disclosure that's scheduled for 8 a.m. Monday, east coast time. An advisory the US CERT recently distributed to about 100 organizations described the research this way: "US-CERT has become aware of several key management vulnerabilities in the 4-way handshake of the Wi-Fi Protected Access II (WPA2) security protocol. The impact of exploiting these vulnerabilities includes decryption, packet replay, TCP connection hijacking, HTTP content injection, and others. Note that as protocol-level issues, most or all correct implementations of the standard will be affected. The CERT/CC and the reporting researcher KU Leuven, will be publicly disclosing these vulnerabilities on 16 October 2017." https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-protocol-leaves-wi-fi-traffic-open-to-eavesdropping/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From job at ntt.net Mon Oct 16 09:13:37 2017 From: job at ntt.net (Job Snijders) Date: Mon, 16 Oct 2017 11:13:37 +0200 Subject: Gonna be a long day for anybody with CPE that does WPA2.. In-Reply-To: <193712.1508139499@turing-police.cc.vt.edu> References: <193712.1508139499@turing-police.cc.vt.edu> Message-ID: <20171016091337.GJ19142@Vurt.local> Dear all, Website with logo: https://www.krackattacks.com/ Paper with background info: https://papers.mathyvanhoef.com/ccs2017.pdf Kind regards, Job From EPers at ansencorp.com Mon Oct 16 12:09:54 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Mon, 16 Oct 2017 12:09:54 +0000 Subject: Gonna be a long day for anybody with CPE that does WPA2.. In-Reply-To: <20171016091337.GJ19142@Vurt.local> References: <193712.1508139499@turing-police.cc.vt.edu> <20171016091337.GJ19142@Vurt.local> Message-ID: I see here that MikroTik has patched this about a week ago: https://forum.mikrotik.com/viewtopic.php?f=21&t=126695 Any word on other vendor's response to this? Ed -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Job Snijders Sent: Monday, October 16, 2017 5:14 AM To: valdis.kletnieks at vt.edu Cc: nanog at nanog.org Subject: Re: Gonna be a long day for anybody with CPE that does WPA2.. Dear all, Website with logo: https://www.krackattacks.com/ Paper with background info: https://papers.mathyvanhoef.com/ccs2017.pdf Kind regards, Job From tarko at lanparty.ee Mon Oct 16 12:33:59 2017 From: tarko at lanparty.ee (Tarko Tikan) Date: Mon, 16 Oct 2017 15:33:59 +0300 Subject: Gonna be a long day for anybody with CPE that does WPA2.. In-Reply-To: References: <193712.1508139499@turing-police.cc.vt.edu> <20171016091337.GJ19142@Vurt.local> Message-ID: <6814a1c5-2a4d-27c1-5f8a-18218f3756ef@lanparty.ee> hey, > Any word on other vendor's response to this? Aruba - http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007_FAQ_Rev-1.pdf -- tarko From bicknell at ufp.org Mon Oct 16 13:51:51 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 16 Oct 2017 06:51:51 -0700 Subject: Gonna be a long day for anybody with CPE that does WPA2.. In-Reply-To: <193712.1508139499@turing-police.cc.vt.edu> References: <193712.1508139499@turing-police.cc.vt.edu> Message-ID: <20171016135151.GA29297@ussenterprise.ufp.org> In a message written on Mon, Oct 16, 2017 at 03:38:19AM -0400, valdis.kletnieks at vt.edu wrote: > And it looks like we're all going to be reflashing a lot of devices. Based on my reading this morning many (but not all) of the attacks are against _clients_ with no way to migitate by simply upgrading AP's. Sure, Windows, Mac, Linux...but also Android and iOS...and that "smart" TV, the streaming stick plugged into it, the nanny cam, etc, etc, etc. :( -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From bruns at 2mbit.com Mon Oct 16 14:14:36 2017 From: bruns at 2mbit.com (Brielle) Date: Mon, 16 Oct 2017 08:14:36 -0600 Subject: Gonna be a long day for anybody with CPE that does WPA2.. In-Reply-To: <20171016135151.GA29297@ussenterprise.ufp.org> References: <193712.1508139499@turing-police.cc.vt.edu> <20171016135151.GA29297@ussenterprise.ufp.org> Message-ID: <0B8A7F91-1E6C-4E2C-9E67-0E6E15FC4F6C@2mbit.com> Ubiquiti already has it patched in UniFi firmware release 3.9.3 (see forums for more detail, or I'll be doing a sticky post in /r/ubiquiti later). 3.8.15 for Broadcom based APs like the first gen UAP-AC and ACv2 should be soon from what I read. Don't know about Airmax yet though. So, any bets on the likelihood of consumer gear getting fixes or are we pretty much only expecting prosumer and higher to actually get fixed? Sent from my iPad > On Oct 16, 2017, at 7:51 AM, Leo Bicknell wrote: > > In a message written on Mon, Oct 16, 2017 at 03:38:19AM -0400, valdis.kletnieks at vt.edu wrote: >> And it looks like we're all going to be reflashing a lot of devices. > > Based on my reading this morning many (but not all) of the attacks are > against _clients_ with no way to migitate by simply upgrading AP's. > > Sure, Windows, Mac, Linux...but also Android and iOS...and that "smart" > TV, the streaming stick plugged into it, the nanny cam, etc, etc, etc. > > :( > > -- > Leo Bicknell - bicknell at ufp.org > PGP keys at http://www.ufp.org/~bicknell/ From gogan at email.unc.edu Mon Oct 16 12:13:39 2017 From: gogan at email.unc.edu (Gogan, James Patrick) Date: Mon, 16 Oct 2017 12:13:39 +0000 Subject: Gonna be a long day for anybody with CPE that does WPA2.. In-Reply-To: References: <193712.1508139499@turing-police.cc.vt.edu> <20171016091337.GJ19142@Vurt.local> Message-ID: Aruba: http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007.txt -- Jim Gogan / UNC-Chapel Hill -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Edwin Pers Sent: Monday, October 16, 2017 8:10 AM To: Job Snijders ; valdis.kletnieks at vt.edu Cc: nanog at nanog.org Subject: RE: Gonna be a long day for anybody with CPE that does WPA2.. I see here that MikroTik has patched this about a week ago: https://forum.mikrotik.com/viewtopic.php?f=21&t=126695 Any word on other vendor's response to this? Ed -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Job Snijders Sent: Monday, October 16, 2017 5:14 AM To: valdis.kletnieks at vt.edu Cc: nanog at nanog.org Subject: Re: Gonna be a long day for anybody with CPE that does WPA2.. Dear all, Website with logo: https://www.krackattacks.com/ Paper with background info: https://papers.mathyvanhoef.com/ccs2017.pdf Kind regards, Job From teun at teun.tv Mon Oct 16 13:32:49 2017 From: teun at teun.tv (Teun Vink) Date: Mon, 16 Oct 2017 15:32:49 +0200 Subject: Gonna be a long day for anybody with CPE that does WPA2.. In-Reply-To: References: <193712.1508139499@turing-police.cc.vt.edu> <20171016091337.GJ19142@Vurt.local> Message-ID: <1508160769.10225.20.camel@teun.tv> On Mon, 2017-10-16 at 12:09 +0000, Edwin Pers wrote: > I see here that MikroTik has patched this about a week ago: https://f > orum.mikrotik.com/viewtopic.php?f=21&t=126695 > > Any word on other vendor's response to this? > https://github.com/kristate/krackinfo has a nice overview of various vendors and their statuses, including links to their responses. Best regards, Teun From spedersen.lists at gmail.com Mon Oct 16 14:39:48 2017 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Mon, 16 Oct 2017 07:39:48 -0700 Subject: Gonna be a long day for anybody with CPE that does WPA2.. In-Reply-To: <193712.1508139499@turing-police.cc.vt.edu> References: <193712.1508139499@turing-police.cc.vt.edu> Message-ID: <003d01d3468c$9eea5740$dcbf05c0$@gmail.com> Cisco's PSIRT: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco- sa-20171016-wpa Some fixes appear to be available, or will be soon. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of valdis.kletnieks at vt.edu Sent: Monday, October 16, 2017 12:38 AM To: nanog at nanog.org Subject: Gonna be a long day for anybody with CPE that does WPA2.. Looks like WPA2 may have just become the new WEP. And it looks like we're all going to be reflashing a lot of devices. "The proof-of-concept exploit is called KRACK, short for Key Reinstallation Attacks. The research has been a closely guarded secret for weeks ahead of a coordinated disclosure that's scheduled for 8 a.m. Monday, east coast time. An advisory the US CERT recently distributed to about 100 organizations described the research this way: "US-CERT has become aware of several key management vulnerabilities in the 4-way handshake of the Wi-Fi Protected Access II (WPA2) security protocol. The impact of exploiting these vulnerabilities includes decryption, packet replay, TCP connection hijacking, HTTP content injection, and others. Note that as protocol-level issues, most or all correct implementations of the standard will be affected. The CERT/CC and the reporting researcher KU Leuven, will be publicly disclosing these vulnerabilities on 16 October 2017." https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-p rotocol-leaves-wi-fi-traffic-open-to-eavesdropping/ From sean at donelan.com Mon Oct 16 15:32:44 2017 From: sean at donelan.com (Sean Donelan) Date: Mon, 16 Oct 2017 11:32:44 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: On Sun, 15 Oct 2017, Peter Beckman wrote: > It is theoretically simple to: > > 1. Turn the address of your Smart Speaker into coordinates > 2. Receive ALL alerts and only act upon those that apply to your > location > > This way it isn't creepy, because the emergency alert wasn't targeted to > you, but your device was aware enough to determine that you are in the > warned area. A very solid, technical response. Unfortunately, most people don't react that way. The top questions from the public about Wireless Emergency Alerts is How did FEMA get my phone number to send me WEA alerts? The technical response is WEA doesn't use phone numbers, its a cell broadcast to all phones in the area. Its not your individual phone. Non-technical people hear blah-blah-technical-nonense; and still think WEA is someone texting their phone, which means FEMA must know their phone number. A smart speaker suddenly announcing "There is a tornado warning in this area, would you like to hear more?" will probably freak-out those same non-technical people. From aaron at heyaaron.com Mon Oct 16 15:48:04 2017 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Mon, 16 Oct 2017 08:48:04 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: On Mon, Oct 16, 2017 at 8:32 AM, Sean Donelan wrote: > A smart speaker suddenly announcing "There is a tornado warning in this > area, would you like to hear more?" will probably freak-out those same > non-technical people. Simple programming problem. Speaker: "There is a tornado warning in this area, would you like to hear more?" User: "How did you get my phone number?" Speaker: "You have opted out of tornado warnings" Fast forward to the next tornado and techno-darwinism will take effect. Alternatively you could have the speaker ramble on for 10-15 minutes about how the weather alerting system works and maybe the end-user will hang around long enough listening to the explanation... -A From sean at donelan.com Mon Oct 16 16:01:40 2017 From: sean at donelan.com (Sean Donelan) Date: Mon, 16 Oct 2017 12:01:40 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: On Mon, 16 Oct 2017, Aaron C. de Bruyn wrote: > Simple programming problem. > > Speaker: "There is a tornado warning in this area, would you like to hear more?" > > User: "How did you get my phone number?" > > Speaker: "You have opted out of tornado warnings" > > Fast forward to the next tornado and techno-darwinism will take effect. > > Alternatively you could have the speaker ramble on for 10-15 minutes > about how the weather alerting system works and maybe the end-user > will hang around long enough listening to the explanation... Of course, on Amazon's Alexia, it will probably sound like this Alexia: "There is an immediate evacuation due to wildfires in this area, would you like to order N95 facemasks with free shipping for Amazon Prime members?" From mike-nanog at tiedyenetworks.com Mon Oct 16 20:50:52 2017 From: mike-nanog at tiedyenetworks.com (Mike) Date: Mon, 16 Oct 2017 13:50:52 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: On 10/16/2017 09:01 AM, Sean Donelan wrote: > On Mon, 16 Oct 2017, Aaron C. de Bruyn wrote: >> Simple programming problem. >> >> Speaker: "There is a tornado warning in this area, would you like to >> hear more?" >> >> User: "How did you get my phone number?" >> >> Speaker: "You have opted out of tornado warnings" >> >> Fast forward to the next tornado and techno-darwinism will take effect. >> I have done what I could to turn off all of these alerts. My first experience with one was several years ago with an amber alert, making my phone emit strange and somewhat unsettling noises I didn't recognize. The amber alert was for an event some 400 miles away from me (I was in northern cal, and this was taking place in los angeles). How useless. So there is a control you can set to make sure you don't get these... everything up to but not including 'presidential alerts'. From what I see, this is really wrong. Yes I would like there to be a broadcast capability with some kind of gps fencing. No, I am not the police nor will I do their job and be their eyes and ears. Yes, I want to know if there is a major fire or other natural disaster in my current area but otherwise, no, don't bother me. Is that too much to ask? Mike- From sabri at cluecentral.net Mon Oct 16 21:59:34 2017 From: sabri at cluecentral.net (Sabri Berisha) Date: Mon, 16 Oct 2017 14:59:34 -0700 (PDT) Subject: 4 or smaller digit ASNs In-Reply-To: <20171013133851.GA96852@ussenterprise.ufp.org> References: <20171013133851.GA96852@ussenterprise.ufp.org> Message-ID: <1257304634.38774.1508191174729.JavaMail.zimbra@cluecentral.net> From: "Leo Bicknell" > What about going the other way? Ask for 2^32-1. "We have the biggest > ASN!" Make ASNs great again? -- Sabri JNCIE #261 From jfmezei_nanog at vaxination.ca Mon Oct 16 22:13:17 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 16 Oct 2017 18:13:17 -0400 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: <7160d7e7-b876-235c-406b-4c1052c321af@vaxination.ca> re: alerts last march, Montréal had a nasty winter storm which resulted in a stretch of highway wheree all exits were blocked for hours (the government had inquiry on what happened). Cars stuck in there in middle of night for 6 hours. Once police woke up, it would have been extremely helpful if they could have broadcasted an alert to all cars in that area, giving them instruction on how to turn around and exit "backwards"). Similarly, in Atlanta, when a piece of highway collapsed, such alerts might have been helpful to all those drivers stuck and unable to proceed (and needing to turn around). But this has to be very targetted to one antenna, not an area. The problem is that people get annoyed by alerts that don't concern them and if they turn it off, then it defeats the purpose for "real" alerts. Last year, where Fort McMurray was hit by forest fires, Canada did not yet have emergency alerts enabled. Twitter and radio were the "official" evacuation orders. (and there were mistakes, underestimating it, mistakes in handling traffic etc). A telling video in case you hadn't seen it: https://www.youtube.com/watch?v=aC2iPvXAggM Communications systems become extremely important in such emergency events because of the time critical nature. For instance, in Fort McMurray, one neighbourhood had only road out and it was already in teh fire so people evacuating had to go through it. Yet, at intersection with highway, the first responders were slowing traffic exiting from Beacon hill to let highway traffic through, unaware of what was going on on that one exit from beacon Hill neighbourhood (bad neighbourhood design BTW). Had they stopped highway, they could have evacuated neighbourhood quickly instead of forcing cars to be stuck in traffic with fire all around them. And as a sign of the times, many home cameras ran and kept sending surveillance video to some service provider servers as the house burned down until power cut or camera burned. (and some of the evacuated people were able to get cable company to check iof theyr modem was still "there" as a means to find out if their home had burned or not. And while authorities refused to release real information on what areas were damaged or not, Google released "before/after" satellite images so people could check if their home was still there of not. (the information age defeating politicians fears of releasing information). on lighter note: this past summer while on an Amtrak train south of Wilmington, interesting experience to see everyuone's phone beep at roughly same time in train car due to flash flood alert, followed by skies opening up and dumping an ocean on the train. From lists at mtin.net Tue Oct 17 04:24:05 2017 From: lists at mtin.net (Justin Wilson) Date: Tue, 17 Oct 2017 00:24:05 -0400 Subject: Terminology Clarification - "Active Wave" In-Reply-To: References: Message-ID: <6C610D5C-328C-4CF5-AD24-DCFBB8133C8A@mtin.net> I agree with Tony Wicks. I have seen an “active” wave referred to on active wave gear a a “passive” wave on a passive mux. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On Oct 1, 2017, at 4:29 PM, jeff herbel wrote: > > Yes. They might be thinking of dark fiber.. > > On Sun, Oct 1, 2017, 4:20 PM Rod Beck > > wrote: > >> A financial firm asked me if a 10 gig wave offer was an "active wave". 😨 >> >> >> LAN PHY 10 GigE, WAN PHY 10 GigE, transparent, STM64, OC192. Yes. >> >> >> Active? >> >> >> Roderick Beck >> >> Director of Global Sales >> >> United Cable Company >> >> www.unitedcablecompany.com >> >> 85 Király utca >> >, >> 1077 Budapest >> >> rod.beck at unitedcablecompany.com >> >> 36-30-859-5144 >> >> >> [1467221477350_image005.png] From sean at donelan.com Tue Oct 17 06:28:10 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 17 Oct 2017 02:28:10 -0400 (EDT) Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: On Mon, 16 Oct 2017, Mike wrote: > 'presidential alerts'. From what I see, this is really wrong. Yes I would > like there to be a broadcast capability with some kind of gps fencing. No, I > am not the police nor will I do their job and be their eyes and ears. Yes, I > want to know if there is a major fire or other natural disaster in my current > area but otherwise, no, don't bother me. Is that too much to ask? Yes, there are various implementation problems and mistakes. It sometimes feels like companies and agencies deliberately implement alerts badly. Emergency alerts should not sound like a 1950's AM radio with lots of static anymore. And yes, due to lack of funding almost no emergency officials receive any formal training how to prepare public alerts or use emergency alert systems. So they make mistakes over-alerting or under-alerting or creating an understandable message. Those things are out of scope of NANOG. I've participated in the FCC rulemakings on emergency alerts and submitted suggestions things it could do to improve the implementation of emergency alerts (EAS, WEA, etc). I've also written some guidance for emergency managers about using public alerting systems http://www.donelan.com/eas.html Back in scope for network operators and NANOG. There are several things that could update the public alerting system for this century. I'd love to work with any teams that want to make things better. Heck, I got U-Verse to add an "exit" and "weather" button to its emergency alerts, so you can dismiss it instead of waiting for the entire message to play. And the original question -- alerting people at home seems like a natural fit for smart speakers in the home and better intelligent assistants, i.e. don't wake me up at 3am for anything less than an extreme emergency impacting my immediate area. Any of the smart speaker companies have any plans for this kind of feature? I've looked at the publically available SDKs and APIs. They have most of the pieces. From kmedcalf at dessus.com Tue Oct 17 13:48:00 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 17 Oct 2017 07:48:00 -0600 Subject: California fires: smart speakers and emergency alerts In-Reply-To: Message-ID: <93852245500414489ebbbc8b7cda7165@mail.dessus.com> > ... smart speakers ... Do not we need to find intelligent life on earth before we can find "Smart Speakers"? From alyssa at alyssamoore.ca Mon Oct 16 20:05:22 2017 From: alyssa at alyssamoore.ca (Alyssa Moore) Date: Mon, 16 Oct 2017 20:05:22 +0000 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover Message-ID: Regarding TransCanada: I recently read they are only just beginning to experiment with fibre optic monitoring systems for leak detection on short stretches of feeder pipeline in Alberta. The original plans for the RoW on the Northern Courier project (set to finish construction this year) included provisions for a communications conduit, but that was later scrapped. Leak detection: https://www.transcanada.com/en/stories-container/environmentsafety/new-rd-collaboration-adds-another-layer-to-leak-detection/ I doubt there's anything pipeline-related that spans the geography in question. On Fri, Oct 13, 2017 at 6:03 AM wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Seznam serveru (Lumir Srchlm) > 2. Re: Temp at Level 3 data centers (Marshall, Quincy) > 3. Re: Temp at Level 3 data centers (Matthew Pounsett) > 4. TSYS Contact (Dan White) > 5. RE: Calgary <-> Toronto 100% Canadian Fibre Resiliency on > failover (Jacques Latour) > 6. Re: 4 or smaller digit ASNs (Hank Nussbacher) > 7. Re: 4 or smaller digit ASNs (John Levine) > 8. RE: 4 or smaller digit ASNs (Naslund, Steve) > 9. Re: Temp at Level 3 data centers (Sam Silvester) > 10. Re: 4 or smaller digit ASNs (Steve Jones) > 11. Re: replacing compromised biometric authenticators (Rich Kulawiec) > 12. Re: 4 or smaller digit ASNs (valdis.kletnieks at vt.edu) > 13. Re: replacing compromised biometric authenticators > (Jean-Francois Mezei) > 14. Re: 4 or smaller digit ASNs (Jon Lewis) > 15. Re: Temp at Level 3 data centers (William Herrin) > 16. Re: 4 or smaller digit ASNs (Richard Hicks) > 17. Re: Temp at Level 3 data centers (Keith Stokes) > 18. Re: Temp at Level 3 data centers (Jean-Francois Mezei) > 19. Google Voice Security (J. Oquendo) > 20. Re: 4 or smaller digit ASNs (Brett Watson) > 21. Re: replacing compromised biometric authenticators (Alain Hebert) > 22. Re: 4 or smaller digit ASNs (Lee Howard) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Oct 2017 15:02:11 +0200 > From: "Lumir Srchlm" > To: " Lukáš Racek (lukas.racek at pentahospitals.cz > =?ISO-8859-2?B?KQ==?=" , > "=?ISO-8859-2?B?TWlyb3NsYXYgSHJpdvLhayAoZXh0ZXJuYWwp?=" > , "i mawsog via NANOG" > Cc: "Tomas Blinka" > Subject: Seznam serveru > Message-ID: > < > OF16ECBD77.EEE27B0E-ONC12581B7.00477A64-C12581B7.00479CD4 at post.its.cz> > > Content-Type: text/plain; charset="US-ASCII" > > Dobry den, > > zasilam slibeny seznam serveru. > > DC1 > > PHCZ_MIS > PHCZ_WSUS > PHCZ_RON > DC01_NV > PHCZ_ADFS01 > nv-vrc-fug-v-02 > pha-nav-v-003 > PHCZ_DC01 > DC01_NOS > PHCZ_DADFS01 > PHCZ_TERMGW > HART_NV > DC01_NSO > PHCZ_TERM1 > DC01_NSU > PHCZ_ESET > > > DC2 > PHCZ_DADFS02 > PHCZ_DC02 > PHCZ_ADFS02 > > S pozdravem > Lumir Srch > > ------------------------------ > > Message: 2 > Date: Thu, 12 Oct 2017 13:27:38 +0000 > From: "Marshall, Quincy" > To: "nanog at nanog.org" > Subject: Re: Temp at Level 3 data centers > Message-ID: > < > 3438B611A2B2C04495EF0E1B25729C46BCD6EB at mbx032-e1-va-8.exch032.serverpod.net > > > > Content-Type: text/plain; charset=UTF-8 > > I have equipment in several L(3) DCs. I'd say that is generally the > exception however I have two notable facilities (smaller type 3) that have > troubles on occasion... reaching into the 80s as you commented. (Usually > during the warm southern summer days) . > > I found that my getting to know the facility manager/personnel very > useful. They gave staight up answers and have done what they could to > assist. > > -------- Original message -------- > From: Chuck Anderson > Date: 10/11/17 22:13 (GMT-05:00) > To: nanog at nanog.org > Subject: Re: Temp at Level 3 data centers > > Install an air conditioner in your rack. > > On Wed, Oct 11, 2017 at 02:39:19PM -0500, Andrew Latham wrote: > > David > > > > The issue has several components and is vendor agnostic. > > > > Set Point: The systems are specifically set at a temperature > > Capacity Ability: The systems can maintain a temperature > > Customer Desire: What you expect from sales promises. > > Sales Promise: What they might carefully avoid promising. > > > > I suggest you review your SLA and discuss with legal asap. You could > have a > > document defining your question's answer already but it sits in a filing > > cabinet file labeled business continuity. > > > > If the set point is X then they likely would answer quickly that that is > > the case. > > If the capacity is lacking then they would likely redirect the issue. > > If they don't care about the customer that alone should be an indicator > > If a promise exists in the SLA then the ball is in your court > > > > >From the emails I fear that we have confirmed that this is normal. So > your > > question "Is the temperature at Level 3 Data Centers normally in the > 80-90F > > range?" sounds like a Yes. > > > > Regardless of the situation always ask for names, titles, and ask vendors > > to repeat critical information like the status of cooling in a building > > designed to deal with cooling. Keep the vendors that do it well. > > > > > > > > On Wed, Oct 11, 2017 at 7:31 AM, David Hubbard < > > dhubbard at dino.hostasaurus.com> wrote: > > > > > Curious if anyone on here colo’s equipment at a Level 3 facility and > has > > > found the temperature unacceptably warm? I’m having that experience > > > currently, where ambient temp is in the 80’s, but they tell me that’s > > > perfectly fine because vented tiles have been placed in front of all > > > equipment racks. My equipment is alarming for high temps, so > obviously not > > > fine. Trying to find my way up to whomever I can complain to that’s > in a > > > position to do something about it but it seems the support staff have > been > > > told to brush questions about temp off as much as possible. Was > wondering > > > if this is a country-wide thing for them or unique to the data center I > > > have equipment in. I have equipment in several others from different > > > companies and most are probably 15-20 degrees cooler. > > > > > > Thanks, > > > > > > David > > --------------------------------------------------------------------------------------- > This email has been scanned for email related threats and delivered > safely by Mimecast. > For more information please visit http://www.mimecast.com > > --------------------------------------------------------------------------------------- > > ------------------------------ > > Message: 3 > Date: Thu, 12 Oct 2017 10:04:08 -0400 > From: Matthew Pounsett > To: "nanog at nanog.org" , dhubbard at dino.hostasaurus.com > Subject: Re: Temp at Level 3 data centers > Message-ID: > gPxyqsFwmFmZZuv3w at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > I'm a few years removed from having direct involvement in our DCs now, so I > don't have an example on hand to look at. Is cooling (and in-cabinet > temperature) not a part of the SLA? If it is, then there shouldn't be a > question of the DC staff brushing off complaints about the > temperature–either L3 should fix it or pay the penalties. If it isn't, > then I'd suggest having a look at your contract (and possibly looking a new > DCs) at renewal time. > > > ------------------------------ > > Message: 4 > Date: Thu, 12 Oct 2017 11:18:48 -0500 > From: Dan White > To: > Subject: TSYS Contact > Message-ID: <20171012161848.xggy2ixm24b3ww7m at dan.olp.net> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > If there are any personnel from TSYS here, please contact me off list. > > -- > Dan White > BTC Broadband > Network Admin Lead > Ph 918.366.0248 <(918)%20366-0248> (direct) main: (918)366-8000 > <(918)%20366-8000> > Fax 918.366.6610 <(918)%20366-6610> email: dwhite at olp.net > http://www.btcbroadband.com > > > ------------------------------ > > Message: 5 > Date: Thu, 12 Oct 2017 16:46:55 +0000 > From: Jacques Latour > To: Jean-Francois Mezei , > "nanog at nanog.org" > Subject: RE: Calgary <-> Toronto 100% Canadian Fibre Resiliency on > failover > Message-ID: > Content-Type: text/plain; charset="utf-8" > > > > > Since the Trans Canada highway in that part of Ontario is actually a 2 > lane > > rural road, I am not sure people would have laid fibre along it knowing > the > > progressive work to widen it might require frequent relocation of the > fibre. > > That's a good point, what about along the Trans-Canadian pipeline? > https://www.transcanada.com/en/operations/maps/ Anyone know if there's > fibre there? > > ------------------------------ > > Message: 6 > Date: Thu, 12 Oct 2017 20:39:41 +0300 > From: Hank Nussbacher > To: nanog at nanog.org > Subject: Re: 4 or smaller digit ASNs > Message-ID: > Content-Type: text/plain; charset=utf-8 > > On 12/10/2017 08:47, Mel Beckman wrote: > > James, > > > > As far as I know, you can't buy an existing ASN for any amount of money. > You can buy the company that owns it, but that seems like boiling tea with > a blowtorch. > > > > I sincerely doubt there are unused low-number ASNs, but you could always > ask ARIN. > > > > I'm curious what your client's rationale is for wanting a low ASN. > It is called ASN-envy. > > -Hank > AS378 :-) > > > > It can't be efficiency, since the numbers all take the same number of > bits ultimately. If they just like small numbers, I'd advise them to forget > it -- life is too short. If they have a real technical reason that nobody > has foreseen (or at least I haven't foreseen), I'd love to hear it. > > > > > > -mel beckman > > > >> On Oct 11, 2017, at 10:01 PM, James Breeden > wrote: > >> > >> Hello NANOG... > >> > >> I have a client interested in picking up a new AS number but they > really want it to be 3 or 4 digits in length. > >> > >> Is there a process to request this from ARIN, or doss anyone know of > unused ASns fitting this that anyone is looking to sell for some quick cash? > >> > >> Thanks! > >> James > >> > >> > >> > >> > >> Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone > > > > > ------------------------------ > > Message: 7 > Date: 12 Oct 2017 20:28:49 -0000 > From: "John Levine" > To: nanog at nanog.org > Subject: Re: 4 or smaller digit ASNs > Message-ID: <20171012202849.43329.qmail at ary.lan> > Content-Type: text/plain; charset=utf-8 > > In article <20171012070551.GA52873 at spider.typo.org> you write: > >> > I'm curious what your client's rationale is for wanting a low ASN. > > > >Dare I say it? > > > >Nerds often get overly excited at things that are generally pretty > >small... > > Too bad I can't sell my old NSI handle. > > R's, > JL7 > > > ------------------------------ > > Message: 8 > Date: Thu, 12 Oct 2017 20:40:42 +0000 > From: "Naslund, Steve" > To: "nanog at nanog.org" > Subject: RE: 4 or smaller digit ASNs > Message-ID: > < > 9578293AE169674F9A048B2BC9A081B40262159F01 at MUNPRDMBXA1.medline.com> > Content-Type: text/plain; charset="utf-8" > > I've got a DDN TAC access card if they are interested in that as well. > Might even be able to dig up a BBN PAD for them too. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Levine > Sent: Thursday, October 12, 2017 3:29 PM > To: nanog at nanog.org > Subject: Re: 4 or smaller digit ASNs > > In article <20171012070551.GA52873 at spider.typo.org> you write: > >> > I'm curious what your client's rationale is for wanting a low ASN. > > > >Dare I say it? > > > >Nerds often get overly excited at things that are generally pretty > >small... > > Too bad I can't sell my old NSI handle. > > R's, > JL7 > > ------------------------------ > > Message: 9 > Date: Thu, 12 Oct 2017 10:22:31 +1030 > From: Sam Silvester > To: "nanog at nanog.org" > Subject: Re: Temp at Level 3 data centers > Message-ID: > YNRvBeZdUAwkAA at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Thu, Oct 12, 2017 at 3:39 AM, Naslund, Steve > wrote: > > > If the ambient temperature is higher is means the temperatures throughout > > the device would be higher and the temp at those points is what really > > matters. I would also be concerned because if they lose one of the a/c > > units what would the ambient temperature rise to? I would want them to > > tell me what the set point of the a/c actually is. > > > > Bottom line 80 F input air is too hot in my opinion and apparently the > > equipment's opinion as well. > > > > My quick thoughts on the matter: > > 1. Above all else, know what your DC provider states in their SLA/contract. > 2. It's never a bad idea to try to be on the best possible personal terms > with the DC manager(s), the better you get along the more they're inclined > to share knowledge/issues and work with you on any concerns. > 3. You can't infer faults or lack of redundancy from the running > temperature - by way of example several facilities I know run at 25 degrees > celsius but if a chilled water unit in a given data hall fails there's a > number of DX units held in standby to take over. This is where point 2 > comes in handy as knowing somebody on the ground they'll often be quite > happy to run through failure scenarios with you and help make sure > everybody is happy with the risk mitigation strategy. > > Out of idle curiosity - I'm curious as to if the equipment that is alarming > is configurable or not? Reason I ask is I've heard users claiming > environmental parameters were out of spec before, but then it turned out it > was their own environmental monitoring they'd installed in the rack (using > default parameters out of the box, not configured to match the facility > SLA) that was complaining about a set point of 25... > > Cheers, > > Sam > > > ------------------------------ > > Message: 10 > Date: Thu, 12 Oct 2017 00:55:35 -0500 > From: Steve Jones > To: Mel Beckman > Cc: James Breeden , "nanog at nanog.org" > > Subject: Re: 4 or smaller digit ASNs > Message-ID: > hFy5_qn84QunoAkw at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > as i understand it, you cant do bgp at all under 5 > > On Thu, Oct 12, 2017 at 12:47 AM, Mel Beckman wrote: > > > James, > > > > As far as I know, you can't buy an existing ASN for any amount of money. > > You can buy the company that owns it, but that seems like boiling tea > with > > a blowtorch. > > > > I sincerely doubt there are unused low-number ASNs, but you could always > > ask ARIN. > > > > I'm curious what your client's rationale is for wanting a low ASN. It > > can't be efficiency, since the numbers all take the same number of bits > > ultimately. If they just like small numbers, I'd advise them to forget it > > -- life is too short. If they have a real technical reason that nobody > has > > foreseen (or at least I haven't foreseen), I'd love to hear it. > > > > > > -mel beckman > > > > > On Oct 11, 2017, at 10:01 PM, James Breeden > > wrote: > > > > > > Hello NANOG... > > > > > > I have a client interested in picking up a new AS number but they > really > > want it to be 3 or 4 digits in length. > > > > > > Is there a process to request this from ARIN, or doss anyone know of > > unused ASns fitting this that anyone is looking to sell for some quick > cash? > > > > > > Thanks! > > > James > > > > > > > > > > > > > > > Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone > > > > > ------------------------------ > > Message: 11 > Date: Thu, 12 Oct 2017 16:58:35 -0400 > From: Rich Kulawiec > To: nanog at nanog.org > Subject: Re: replacing compromised biometric authenticators > Message-ID: <20171012205835.GA5109 at gsp.org> > Content-Type: text/plain; charset=us-ascii > > On Wed, Oct 11, 2017 at 05:04:08PM -0400, Ken Chase wrote: > > If the current best operating practice is to avoid biometrics, why are > they > > still in use out here? > > (1) for the same reason some idiots still use captchas > (2) new hotness > old and busted, regardless of merits > (3) because they facilitate coerced risk transference away from the > people who are actually responsible (and are paid to be so) to the > people who shouldn't be responsible (and aren't paid to be) > > ---rsk > > > > ------------------------------ > > Message: 12 > Date: Thu, 12 Oct 2017 16:58:52 -0400 > From: valdis.kletnieks at vt.edu > To: Steve Jones > Cc: Mel Beckman , "nanog at nanog.org" > Subject: Re: 4 or smaller digit ASNs > Message-ID: <21717.1507841932 at turing-police.cc.vt.edu> > Content-Type: text/plain; charset="utf-8" > > On Thu, 12 Oct 2017 00:55:35 -0500, Steve Jones said: > > as i understand it, you cant do bgp at all under 5 > > AS1312 does BGP quite nicely... Not sure what you meant there, unless the > text/plain lost the tags... > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 486 bytes > Desc: not available > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20171012/da809065/attachment-0001.sig > > > > ------------------------------ > > Message: 13 > Date: Thu, 12 Oct 2017 17:53:16 -0400 > From: Jean-Francois Mezei > To: nanog at nanog.org > Subject: Re: replacing compromised biometric authenticators > Message-ID: <183bbe65-4d86-d26f-fdd1-66922d418928 at vaxination.ca> > Content-Type: text/plain; charset=utf-8 > > On 2017-10-12 16:58, Rich Kulawiec wrote: > > > (3) because they facilitate coerced risk transference away from the > > people who are actually responsible (and are paid to be so) to the > > people who shouldn't be responsible (and aren't paid to be) > > > I think biometrics are seen as a means to reduce the possible > errors/corruption of a security guard by shifting responsibility to a > computer. > > When you have multiple tennants, the DC can't assume all tennants will > keep all access cards secure so has to protect tennant 2 from tennant 1 > having cards stolen by some crook intent on damaging tennant 2's cards. > > A security guard matching face to picture on card AND picture in his > computer for that card can be very good, and woudl eliminate card > counterfeiting (with match against the DC's database of images) but > would not eliminate security guard making mistakes and allowing people > whose face does not match (corruption or lazyness). > > > This is very different from a data centre owned by a single tennant who > has full control over staff and knows who is and isn't staff and > authorized to go in. > > > > > > ------------------------------ > > Message: 14 > Date: Thu, 12 Oct 2017 18:13:32 -0400 (EDT) > From: Jon Lewis > To: Hank Nussbacher > Cc: nanog at nanog.org > Subject: Re: 4 or smaller digit ASNs > Message-ID: > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > On Thu, 12 Oct 2017, Hank Nussbacher wrote: > > > On 12/10/2017 08:47, Mel Beckman wrote: > >> James, > >> > >> As far as I know, you can't buy an existing ASN for any amount of > money. You can buy the company that owns it, but that seems like boiling > tea with a blowtorch. > >> > >> I sincerely doubt there are unused low-number ASNs, but you could > always ask ARIN. > >> > >> I'm curious what your client's rationale is for wanting a low ASN. > > It is called ASN-envy. > > And here smaller is better :) > > How would one go about cleaning up the provenance and either re-using or > selling an ASN, supposing: > > 1) you are all the registered contacts for the ASN and your ARIN POC is > still valid > > 2) the ASN was owned by (ok...it's ARIN[1], so "registered to") a defunct > corporation (inactive >10 years) of which you were part-owner > > 3) the ARIN maintenance fees have been unpaid >10 years...yet the ASN > still exists in whois > > [1] It was actually assigned pre-ARIN, but to an org that eventually > signed the RSA...so I wonder...are the maintenance fees really past > due...and is this why the ASN was never reclaimed while the IP space > (which was allocated by ARIN) was? > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > ------------------------------ > > Message: 15 > Date: Thu, 12 Oct 2017 18:43:55 -0400 > From: William Herrin > To: David Hubbard > Cc: "nanog at nanog.org" > Subject: Re: Temp at Level 3 data centers > Message-ID: > e71PzmpRjd5xR3U-_KneHZ_vrU5Aw at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Wed, Oct 11, 2017 at 8:31 AM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > > > Curious if anyone on here colo’s equipment at a Level 3 facility and has > > found the temperature unacceptably warm? I’m having that experience > > currently, where ambient temp is in the 80’s, but they tell me that’s > > perfectly fine because vented tiles have been placed in front of all > > equipment racks. > > > Hi David, > > The thing I'm not understanding in this thread is that the last time I > checked Level 3 was a premium player not a cost player. Has that changed? > > If a premium data center vendor is asking you to swallow 80F in the cold > aisle, something is very wrong. But realize I just said 80F in the *cold > aisle*. DC cooling is not about "ambient" or "sensible cooling" or similar > terms bandied about by ordinary HVAC professionals. In a data center, air > doesn't really stack up anywhere. It flows. > > If you haven't physically checked your racks, it's time to do that. There > are lots of reasons for high temps in the cabinet which aren't the DC's > fault. > > Is all the air flow in your cabinet correctly moving from the cold aisle to > the hot aisle? Even those side-venting Cisco switches? You're sure? If > you're looping air inside the cabinet, that's your fault. > > Have you or your rack neighbors exceeded the heat density that the DC's > HVAC system supports? If you have, the air in the hot aisle may be looping > over the top of the cabinets and back in to your servers. You can't > necessarily fill a cabinet with equipment. When you reach the allowable > heat density, you have to start filling the next cabinet. I've seen DC > cabinets left half empty for exactly this reason. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > > > ------------------------------ > > Message: 16 > Date: Thu, 12 Oct 2017 15:53:07 -0700 > From: Richard Hicks > To: "nanog at nanog.org" > Subject: Re: 4 or smaller digit ASNs > Message-ID: > Wa_V74ZFUx1enoccYJqgTKRQ at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Anyone know the history behind ASN 2906 (Netflix)? > How did they get a number that low? > > Rick > > On Thu, Oct 12, 2017 at 3:13 PM, Jon Lewis wrote: > > > On Thu, 12 Oct 2017, Hank Nussbacher wrote: > > > > On 12/10/2017 08:47, Mel Beckman wrote: > >> > >>> James, > >>> > >>> As far as I know, you can't buy an existing ASN for any amount of > money. > >>> You can buy the company that owns it, but that seems like boiling tea > with > >>> a blowtorch. > >>> > >>> I sincerely doubt there are unused low-number ASNs, but you could > always > >>> ask ARIN. > >>> > >>> I'm curious what your client's rationale is for wanting a low ASN. > >>> > >> It is called ASN-envy. > >> > > > > And here smaller is better :) > > > > How would one go about cleaning up the provenance and either re-using or > > selling an ASN, supposing: > > > > 1) you are all the registered contacts for the ASN and your ARIN POC is > > still valid > > > > 2) the ASN was owned by (ok...it's ARIN[1], so "registered to") a defunct > > corporation (inactive >10 years) of which you were part-owner > > > > 3) the ARIN maintenance fees have been unpaid >10 years...yet the ASN > > still exists in whois > > > > [1] It was actually assigned pre-ARIN, but to an org that eventually > > signed the RSA...so I wonder...are the maintenance fees really past > > due...and is this why the ASN was never reclaimed while the IP space > (which > > was allocated by ARIN) was? > > > > ---------------------------------------------------------------------- > > Jon Lewis, MCP :) | I route > > | therefore you are > > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > > > ------------------------------ > > Message: 17 > Date: Thu, 12 Oct 2017 22:57:30 +0000 > From: Keith Stokes > To: William Herrin > Cc: David Hubbard , "nanog at nanog.org" > > Subject: Re: Temp at Level 3 data centers > Message-ID: <956175C1-7DCF-4930-B971-C3B8F1F3EBA6 at neilltech.com> > Content-Type: text/plain; charset="utf-8" > > If you are using hot/cold aisles and don't fill the rack, don't forget you > have to put in blank panels. > > -- > > Keith Stokes > > > On Oct 12, 2017, at 5:45 PM, William Herrin wrote: > > > > On Wed, Oct 11, 2017 at 8:31 AM, David Hubbard < > > dhubbard at dino.hostasaurus.com> wrote: > > > >> Curious if anyone on here colo’s equipment at a Level 3 facility and has > >> found the temperature unacceptably warm? I’m having that experience > >> currently, where ambient temp is in the 80’s, but they tell me that’s > >> perfectly fine because vented tiles have been placed in front of all > >> equipment racks. > > > > > > Hi David, > > > > The thing I'm not understanding in this thread is that the last time I > > checked Level 3 was a premium player not a cost player. Has that changed? > > > > If a premium data center vendor is asking you to swallow 80F in the cold > > aisle, something is very wrong. But realize I just said 80F in the *cold > > aisle*. DC cooling is not about "ambient" or "sensible cooling" or > similar > > terms bandied about by ordinary HVAC professionals. In a data center, air > > doesn't really stack up anywhere. It flows. > > > > If you haven't physically checked your racks, it's time to do that. There > > are lots of reasons for high temps in the cabinet which aren't the DC's > > fault. > > > > Is all the air flow in your cabinet correctly moving from the cold aisle > to > > the hot aisle? Even those side-venting Cisco switches? You're sure? If > > you're looping air inside the cabinet, that's your fault. > > > > Have you or your rack neighbors exceeded the heat density that the DC's > > HVAC system supports? If you have, the air in the hot aisle may be > looping > > over the top of the cabinets and back in to your servers. You can't > > necessarily fill a cabinet with equipment. When you reach the allowable > > heat density, you have to start filling the next cabinet. I've seen DC > > cabinets left half empty for exactly this reason. > > > > Regards, > > Bill Herrin > > > > > > -- > > William Herrin ................ herrin at dirtside.com bill at herrin.us > > Dirtside Systems ......... Web: > > ------------------------------ > > Message: 18 > Date: Thu, 12 Oct 2017 19:56:14 -0400 > From: Jean-Francois Mezei > To: nanog at nanog.org > Subject: Re: Temp at Level 3 data centers > Message-ID: <84c8cd8f-a2c2-f820-d210-114fdd5ae892 at vaxination.ca> > Content-Type: text/plain; charset=utf-8 > > back in the arly 1990s, Tandem had a computer called "Cyclone". (these > were mission critical, fault tolerant machines). > > The reason for "Cyclone" name was that the cabinets had huge fan > capacity, and that was to deal with air conditioning failure by > increasing the air flow over the electronics to still keep then "comfy" > despite high data centre air temperature. (with the aim of having the > Tandem continue to run despite HVAC failure). > > With dense computers packed in 1U, you just can't have that excessive > airflow to cope with HVAC failure with tiny 1" fans. > > The other difference is data centre density. Bank computer rooms were > sparse compared to today's densely packed racks. So lots of space > relative to heat sources. > > The equivalent today would be the football field size data centres from > the likes of Google with high ceilings and hot air from one area with > failed HVAC to rise to ceiling and partly be taken out by the others. > > But when you are talking about downdown co-lo with enclosed suites that > are packed to the brim, failure of HVAC results in quick temp increases > because the heat has nowhere to spread to, and HVACs from adjoining also > enclosed suites can't provide help. > > So when a tennant agrees to rent rack space in an small enclosed suite, > it should be considerewd that the odds of failure due to heat are > greater (and perhaps consider renting rack space in different suites to > provide some redundancy). > > > > > ------------------------------ > > Message: 19 > Date: Thu, 12 Oct 2017 20:31:43 -0500 > From: "J. Oquendo" > To: nanog at nanog.org > Subject: Google Voice Security > Message-ID: <20171013013143.he5jhxzelbb57d3l at e-fensive.net> > Content-Type: text/plain; charset=us-ascii > > > Sorry for the noise. Can someone put me in touch with > someone in the Google Voice (application iPhone/Android) > department to discuss an issue. Greatly appreciated. > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM > > "Where ignorance is our master, there is no possibility of > real peace" - Dalai Lama > > 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 > https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 > > > ------------------------------ > > Message: 20 > Date: Thu, 12 Oct 2017 21:28:45 -0700 > From: Brett Watson > To: nanog at nanog.org > Subject: Re: 4 or smaller digit ASNs > Message-ID: <501CC431-262C-453E-AB38-9BB80FDCA0A0 at the-watsons.org> > Content-Type: text/plain; charset=utf-8 > > > > On Oct 12, 2017, at 15:53, Richard Hicks > wrote: > > > > Anyone know the history behind ASN 2906 (Netflix)? > > How did they get a number that low? > > I didn’t recognize as2906 so went digging... and I can’t find a thing. > ARIN has a “who has” service but my account on ARIN was locked and I wasn’t > able to unlock without calling them (maybe tomorrow). > > The AS-Name is “AS-SSI” (there is an AS-Set listed on RIPE named this) > which I suspect might lead to the original owner. It looks familiar-ish but > I’m not sure who had it before Netflix. Clearly they must have bought it > outright, acquired the original owner, or something, but I’ll be damned if > I can find historical data on who it originally belonged to. > > -b > > > ------------------------------ > > Message: 21 > Date: Fri, 13 Oct 2017 07:03:30 -0400 > From: Alain Hebert > To: nanog at nanog.org > Subject: Re: replacing compromised biometric authenticators > Message-ID: <33e87e9c-3a7e-bd35-5c47-81cb7f3237b4 at pubnix.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > Odd, > > 1. captcha(?) > > In my millennia of experience I never saw a captcha used as a mean > for DC access control. Just as a programmatic way to reduce brute force > for some website functions. > > > On my network janitor keychain I have (in order of hackability from > easiest to hardest) > > 1. keycard only > > 2. keycard + fingerprints > > 3. keycard + face (2d) > > 4a. keycard + eye > > 4b. keycard + top of hand mapping > > But all the DCs, I deal with, have highrez cameras and tailgating > controls... Biometrics are just a part of a wider system. > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 <(514)%20990-5911> http://www.pubnix.net Fax: > 514-990-9443 <(514)%20990-9443> > > On 10/12/17 16:58, Rich Kulawiec wrote: > > On Wed, Oct 11, 2017 at 05:04:08PM -0400, Ken Chase wrote: > >> If the current best operating practice is to avoid biometrics, why are > they > >> still in use out here? > > (1) for the same reason some idiots still use captchas > > (2) new hotness > old and busted, regardless of merits > > (3) because they facilitate coerced risk transference away from the > > people who are actually responsible (and are paid to be so) to the > > people who shouldn't be responsible (and aren't paid to be) > > > > ---rsk > > > > > > > > ------------------------------ > > Message: 22 > Date: Fri, 13 Oct 2017 07:59:36 -0400 > From: Lee Howard > To: James Breeden > Cc: "nanog at nanog.org" > Subject: Re: 4 or smaller digit ASNs > Message-ID: <2047F678-3C86-4DFC-9008-EDBD9A192718 at asgard.org> > Content-Type: text/plain; charset=us-ascii > > > > > On Oct 12, 2017, at 1:01 AM, James Breeden wrote: > > > > Hello NANOG... > > > > I have a client interested in picking up a new AS number but they really > want it to be 3 or 4 digits in length. > > > > Is there a process to request this from ARIN, or doss anyone know of > unused ASns fitting this that anyone is looking to sell for some quick cash? > > > > It's part of the ARIN transfer process, > https://www.arin.net/policy/nrpm.html#eight specific 8.3, "IPv4 numbers > resources and ASNs may be transferred according to the following > conditions." > > ARIN has a Specified Transfer Listing Service, > https://www.arin.net/resources/transfer_listing/index.html so you could > check there. > I didn't see any ASNs listed, so you may need to call a broker, such as > one listed under > https://www.arin.net/resources/transfer_listing/facilitator_list.html > > A list of ASNs that have been transferred policy can be found at > https://www.arin.net/public/transferLog.xhtml#NRPM-8.3ASNs > > > > > Thanks! > > James > > > > Hope that helps, > > Lee > > > > > > > > > Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone > > > End of NANOG Digest, Vol 117, Issue 13 > ************************************** > From joe at nethead.com Mon Oct 16 21:13:35 2017 From: joe at nethead.com (Joe Hamelin) Date: Mon, 16 Oct 2017 14:13:35 -0700 Subject: California fires: smart speakers and emergency alerts In-Reply-To: References: <101992.1508043669@turing-police.cc.vt.edu> Message-ID: On Sun, Oct 15, 2017 at 7:09 PM, Sean Donelan wrote: > > > It would be creepy if an emergency alert was too targetted. It may be > better to keep it larger than a mile radius, rather than a single house. > Get out! The tornado is calling from your house! -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 From aaron1 at gvtc.com Tue Oct 17 19:54:49 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 17 Oct 2017 14:54:49 -0500 Subject: facebook fna Message-ID: <000301d34781$cad24ed0$6076ec70$@gvtc.com> Anyone out here with facebook fna ? I could use an assist please, you can contact me directly. -Aaron Gould From mathews at hawaii.edu Tue Oct 17 21:04:49 2017 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Tue, 17 Oct 2017 17:04:49 -0400 Subject: F Y I Message-ID: <59E67071.9000406@hawaii.edu> Judge Recommends Ruling to Block Internet Access to Sci-Hub The American Chemical Society seeks a broad order that includes millions of dollars in damages and demands action from Internet service providers and search engines. By Diana Kwon | October 4, 2017 http://www.the-scientist.com/?articles.view/articleNo/50563/title/Judge-Recommends-Ruling-to-Block-Internet-Access-to-Sci-Hub/ http://www.the-scientist.com/?articles.view/articleNo/50361/title/Publishers--Legal-Action-Advances-Against-Sci-Hub/ From morrowc.lists at gmail.com Tue Oct 17 21:33:14 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Oct 2017 17:33:14 -0400 Subject: F Y I In-Reply-To: <59E67071.9000406@hawaii.edu> References: <59E67071.9000406@hawaii.edu> Message-ID: you know, the Sci-Hub folk could fix this themselves... with some authentication requirements... and probably by just unplugging from the intertubes? On Tue, Oct 17, 2017 at 5:04 PM, Robert Mathews (OSIA) wrote: > > Judge Recommends Ruling to Block Internet Access to Sci-Hub > The American Chemical Society seeks a broad order that includes millions > of dollars in damages and demands action from Internet service providers > and search engines. > By Diana Kwon | October 4, 2017 > > http://www.the-scientist.com/?articles.view/articleNo/50563/ > title/Judge-Recommends-Ruling-to-Block-Internet-Access-to-Sci-Hub/ > http://www.the-scientist.com/?articles.view/articleNo/50361/ > title/Publishers--Legal-Action-Advances-Against-Sci-Hub/ > From mike-nanog at tiedyenetworks.com Tue Oct 17 21:43:52 2017 From: mike-nanog at tiedyenetworks.com (Mike) Date: Tue, 17 Oct 2017 14:43:52 -0700 Subject: Northern California fires and telecomm outages Message-ID: <3f345c93-4fdf-8a07-3039-27699d74a061@tiedyenetworks.com> Hello fellow operators, The recent northern California fires wiped us out along with many other service providers and services including cellular, landline, e-911, cable and the like and I feel it's of operational concern the fragility of the telecommunications networks that link us together and the experiences had during this most recent event. I hope this topic is welcome and I apologize in advance for length. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- I am the founder and owner of an Internet Service Provider business in Mendocino County, California and I also operate a CLEC (Competitive Local Exchange Carrier, a type of telecommunications company akin to ATT or Frontier), also in Mendocino County, California. The recent Northern California fires were again a direct and upfront demonstration of the potential for unanticipated widespread public disaster and again demonstrated how vulnerable we all are. Especially, the rising dependence on broadband service, and an expectation by end users that these services which are critical to them will continue functioning during emergencies as they may have no other access. There was a complete and total breakdown in telecommunication services due to fire which wiped out a primary telecommunications cable, and with it, e-911, land lines, cellular, cable and other telecommunication services. I hope that there will be a more complete public investigation and report on this latest incident, but in the mean time I would like to just offer what I know and to suggest where we could go from here. In the early morning of October 9, the Northern California fires were in effect and in Redwood Valley California, a fire was burning that destroyed a AT&T telecommunications cable that runs between Ukiah and Willits. This single cable is the primary carrier of nearly all telecommunications services north of Ukiah. Although I cannot comment on the totality of the outage due to this specific fire and line cut, it's widely reported elsewhere that services were affected all the way up to Arcata at least. For Mendocino County, I can report that this telecommunication outage resulted in loss of e-911, cellular, landline, cable and most all other broadband services, and caused a complete outage of our service too. This resulted in a virtual dark age, where reliable and up to date information concerning the emergency situation was unable to be communicated, people could not find their families or know whether they got out in time because nothing was working and no way to talk. We were reduced to using paper and posting notes at the Library or other emergency shelter locations or other places where people gathered in order to communicate. People in these areas also had to use cash to buy supplies. Nothing worked. We attempted to engage emergency restoration processes on our own for our own customers and services. We determined that we could rapidly deploy high capacity microwave connecting a remote location where we also already operate microwave, to our main point of presence at an ATT building in Ukiah, and provide a sufficient level of service to all of our customers that would be a huge benefit during this crisis. As a CLEC with an existing presence and power arrangement and so forth within this facility, it seemed natural that we should be able to go ahead and get a simple OK to go do the work. But, we encountered lethargy and insensitivity to the widespread outage and emergency conditions we are trying to address. We notified ATT of our need and only days later, without followup response, it was suggested that we somehow don't have the legal authority to install microwave (despite the fact that our 544 page contract with ATT that allows our presence within their facilities in the first place DOES SAY 'microwave' is allowed), and further they suggest we'd have to give up all of our existing contractual rights and that if it could happen, it would be only with months of delay and endless expense and bureaucratic nonsense that is only designed to slow down and de-incentivize any such initiative. The equipment we were proposing, is small, low power, lightweight, license free gear that could easily fit complete in a car and be deployed within hours without prior notice or coordination. The electrical and structural requirements are next to nothing, and present absolutely no risk to anyone or the facility. We could have had service restored and further, could have plugged a critical gap by creating an active backup telecommunications path which could be used in future emergencies. I am frustrated with the lack of cooperation to restore services during this latest incident and I think it speaks volumes about the mentality of the incumbent providers. They can't get it together, but here I am standing by with the solution at least for my own customers and why, they just don't want to allow me to do it either. Mendocino County (and northern counties also connected on this same telecommunication cable) have suffered similar telecommunications outages before. Prior to this event, a cable just north of Hopland was cut by two individuals thinking they were stealing copper, resulting in widespread outages lasting upwards of 14 hours. And prior to that, a car crash on the coast hit the one pole where the cable system comes in from the east, wiping out all services along the coast for an extended period of time. And before that, a fire in redwood valley just north of coyote valley casino along the roadway burned out the cable again as in this instance. And before that, another fire north of Willits burned the cable again. And the time before that, a backhoe south of Hopland dug up the cable and cut it, again resulting in far reaching outages affecting hundreds of thousands of people. These repeated outages are not being taken seriously and nothing in substance is being done to fortify the telecommunications network against the next disaster, despite the fact that disaster can and will occur again. We have repeatedly drawn attention to these vulnerabilities but the public perception and awareness of the risks wanes quickly once the crisis is over. I think the incumbent providers have had ample opportunity to address the underlaying causes of their repeated widespread outages, and the empty promises and assurances they have made after past prior disasters should be proof that no actual steps will be taken, that they either do not truly understand or care about the effect that loss of telecommunications services has and the risk it presents to the public. The basic fundamental problem facing the telecommunications network in Mendocino County, is the fact that it is structured without any sort of backup communication links. A primary communications cable extends north along highway 101 at Hopland and then goes into Ukiah. This cable then splits out at Ukiah and goes north up 101 thru Willits, while another segment goes west thru Boonville to Mendocino and then up and down along the coast. A cut at any of several points results in the complete isolation of communities past the cut as what occurred during the recent fire. A basic solution to such a situation then, is to have additional cables to increase the connections between areas, so that if a cable is cut and disrupts communication flowing one way, that the communications can flow over another path from another direction. But the incumbent providers have failed so far to do anything and are likely to continue to ignore this lack of redundancy. I believe that there are some realistic solutions available, and based on my business experience in Mendocino County, I have developed the beginnings of a plan of action. The short of it is, there needs to be a redundant network of geographically diverse, very high capacity telecommunication links that connect the core of the County, in order to overcome the existing problem of there being only 1 connection today. We would need new fiber to connect the major cities from alternate directions, and we further would need new connectivity to other sources of out of region telecommunication services besides AT&T (Such as Level3, who has their own independent cable route into the county). It would further require service providers and emergency responders to all lease connectivity on this redundant system for full effect, the net result however, could be a telecommunications system that stands up and continues functioning and with emergency first responders as well as the general public able to communicate during emergencies. Although I am busy with business and ensuring my customers recover from this event, I certainly am happy to add additional background or technical information if anyone is interested. Going forward, I also could also use help in identifying funding sources and other contacts who could help with some of the heavy lifting that is going to be needed here and so any pointers would certainly be appreciated. Thank you. Mike Ireton President Your Town Online, Inc DBA WillitsOnline Rural Broadband Now, LLC From sethm at rollernet.us Tue Oct 17 22:19:41 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 17 Oct 2017 15:19:41 -0700 Subject: Northern California fires and telecomm outages In-Reply-To: <3f345c93-4fdf-8a07-3039-27699d74a061@tiedyenetworks.com> References: <3f345c93-4fdf-8a07-3039-27699d74a061@tiedyenetworks.com> Message-ID: <85fc599e-01e4-35ab-4cba-cbbfff231e29@rollernet.us> Out of curiosity, why weren't there any existing emergency/last-resort microwave links already in place? It seems to be known that this cable is a single point of failure ahead of time. Were there previous plans to set up any microwave links that got put on the back burner or canceled? Is there too much focus on fiber being the only option? IMO it's harder for a fire to destroy a microwave path vs. a fiber path, and some capacity is better than no capacity. ~Seth From mathews at hawaii.edu Tue Oct 17 22:50:01 2017 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Tue, 17 Oct 2017 18:50:01 -0400 Subject: F Y I In-Reply-To: References: <59E67071.9000406@hawaii.edu> Message-ID: <59E68919.4080003@hawaii.edu> On 10/17/2017 5:33 PM, Christopher Morrow wrote: > you know, the Sci-Hub folk could fix this themselves... with some > authentication requirements... and probably by just unplugging from > the intertubes? *Hi Chris:* Apart from what the court's dictate(s) will be in technical and/or non-technical terms, from an infrastructure operations point of view, I shall at least be curious to understand "how" - many in non-technical political circles will be 'taking their seats' under net-neutrality, censorship, and capitalism banners among others. Regards. From mureninc at gmail.com Wed Oct 18 05:05:39 2017 From: mureninc at gmail.com (Constantine A. Murenin) Date: Tue, 17 Oct 2017 22:05:39 -0700 Subject: Northern California fires and telecomm outages In-Reply-To: <3f345c93-4fdf-8a07-3039-27699d74a061@tiedyenetworks.com> References: <3f345c93-4fdf-8a07-3039-27699d74a061@tiedyenetworks.com> Message-ID: Hi Mike, Thanks for sharing the story in what must be quite a difficult time. You mention that Level3 also has presence in the county, including their own independent route. Did they also suffer an outage during this latest incident? If not, then why did their connection not allow at least some customers to remain online? Also, as another poster pointed out, would also be interesting to know why the microwave link was not already established prior to this incident if the single point of failure was so well known. (Especially if your contract with AT&T already mentions that you are supposedly allowed to have microwave at their CO.) Cheers, Constantine. On 17/10/2017, Mike wrote: > Hello fellow operators, > > > The recent northern California fires wiped us out along with many > other service providers and services including cellular, landline, > e-911, cable and the like and I feel it's of operational concern the > fragility of the telecommunications networks that link us together and > the experiences had during this most recent event. I hope this topic is > welcome and I apologize in advance for length. > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > I am the founder and owner of an Internet Service Provider business > in Mendocino County, California and I also operate a CLEC (Competitive > Local Exchange Carrier, a type of telecommunications company akin to ATT > or Frontier), also in Mendocino County, California. The recent Northern > California fires were again a direct and upfront demonstration of the > potential for unanticipated widespread public disaster and again > demonstrated how vulnerable we all are. Especially, the rising > dependence on broadband service, and an expectation by end users that > these services which are critical to them will continue functioning > during emergencies as they may have no other access. There was a > complete and total breakdown in telecommunication services due to fire > which wiped out a primary telecommunications cable, and with it, e-911, > land lines, cellular, cable and other telecommunication services. I hope > that there will be a more complete public investigation and report on > this latest incident, but in the mean time I would like to just offer > what I know and to suggest where we could go from here. > > In the early morning of October 9, the Northern California fires > were in effect and in Redwood Valley California, a fire was burning that > destroyed a AT&T telecommunications cable that runs between Ukiah and > Willits. This single cable is the primary carrier of nearly all > telecommunications services north of Ukiah. Although I cannot comment on > the totality of the outage due to this specific fire and line cut, it's > widely reported elsewhere that services were affected all the way up to > Arcata at least. For Mendocino County, I can report that this > telecommunication outage resulted in loss of e-911, cellular, landline, > cable and most all other broadband services, and caused a complete > outage of our service too. This resulted in a virtual dark age, where > reliable and up to date information concerning the emergency situation > was unable to be communicated, people could not find their families or > know whether they got out in time because nothing was working and no way > to talk. We were reduced to using paper and posting notes at the Library > or other emergency shelter locations or other places where people > gathered in order to communicate. People in these areas also had to use > cash to buy supplies. Nothing worked. > > We attempted to engage emergency restoration processes on our own > for our own customers and services. We determined that we could rapidly > deploy high capacity microwave connecting a remote location where we > also already operate microwave, to our main point of presence at an ATT > building in Ukiah, and provide a sufficient level of service to all of > our customers that would be a huge benefit during this crisis. As a CLEC > with an existing presence and power arrangement and so forth within this > facility, it seemed natural that we should be able to go ahead and get a > simple OK to go do the work. But, we encountered lethargy and > insensitivity to the widespread outage and emergency conditions we are > trying to address. We notified ATT of our need and only days later, > without followup response, it was suggested that we somehow don't have > the legal authority to install microwave (despite the fact that our 544 > page contract with ATT that allows our presence within their facilities > in the first place DOES SAY 'microwave' is allowed), and further they > suggest we'd have to give up all of our existing contractual rights and > that if it could happen, it would be only with months of delay and > endless expense and bureaucratic nonsense that is only designed to slow > down and de-incentivize any such initiative. The equipment we were > proposing, is small, low power, lightweight, license free gear that > could easily fit complete in a car and be deployed within hours without > prior notice or coordination. The electrical and structural requirements > are next to nothing, and present absolutely no risk to anyone or the > facility. We could have had service restored and further, could have > plugged a critical gap by creating an active backup telecommunications > path which could be used in future emergencies. I am frustrated with the > lack of cooperation to restore services during this latest incident and > I think it speaks volumes about the mentality of the incumbent > providers. They can't get it together, but here I am standing by with > the solution at least for my own customers and why, they just don't want > to allow me to do it either. > > Mendocino County (and northern counties also connected on this same > telecommunication cable) have suffered similar telecommunications > outages before. Prior to this event, a cable just north of Hopland was > cut by two individuals thinking they were stealing copper, resulting in > widespread outages lasting upwards of 14 hours. And prior to that, a car > crash on the coast hit the one pole where the cable system comes in from > the east, wiping out all services along the coast for an extended period > of time. And before that, a fire in redwood valley just north of coyote > valley casino along the roadway burned out the cable again as in this > instance. And before that, another fire north of Willits burned the > cable again. And the time before that, a backhoe south of Hopland dug up > the cable and cut it, again resulting in far reaching outages affecting > hundreds of thousands of people. > > These repeated outages are not being taken seriously and nothing in > substance is being done to fortify the telecommunications network > against the next disaster, despite the fact that disaster can and will > occur again. We have repeatedly drawn attention to these vulnerabilities > but the public perception and awareness of the risks wanes quickly once > the crisis is over. I think the incumbent providers have had ample > opportunity to address the underlaying causes of their repeated > widespread outages, and the empty promises and assurances they have made > after past prior disasters should be proof that no actual steps will be > taken, that they either do not truly understand or care about the effect > that loss of telecommunications services has and the risk it presents to > the public. > > The basic fundamental problem facing the telecommunications network > in Mendocino County, is the fact that it is structured without any sort > of backup communication links. A primary communications cable extends > north along highway 101 at Hopland and then goes into Ukiah. This cable > then splits out at Ukiah and goes north up 101 thru Willits, while > another segment goes west thru Boonville to Mendocino and then up and > down along the coast. A cut at any of several points results in the > complete isolation of communities past the cut as what occurred during > the recent fire. A basic solution to such a situation then, is to have > additional cables to increase the connections between areas, so that if > a cable is cut and disrupts communication flowing one way, that the > communications can flow over another path from another direction. But > the incumbent providers have failed so far to do anything and are likely > to continue to ignore this lack of redundancy. > > I believe that there are some realistic solutions available, and > based on my business experience in Mendocino County, I have developed > the beginnings of a plan of action. The short of it is, there needs to > be a redundant network of geographically diverse, very high capacity > telecommunication links that connect the core of the County, in order to > overcome the existing problem of there being only 1 connection today. We > would need new fiber to connect the major cities from alternate > directions, and we further would need new connectivity to other sources > of out of region telecommunication services besides AT&T (Such as > Level3, who has their own independent cable route into the county). It > would further require service providers and emergency responders to all > lease connectivity on this redundant system for full effect, the net > result however, could be a telecommunications system that stands up and > continues functioning and with emergency first responders as well as the > general public able to communicate during emergencies. > > Although I am busy with business and ensuring my customers recover > from this event, I certainly am happy to add additional background or > technical information if anyone is interested. Going forward, I also > could also use help in identifying funding sources and other contacts > who could help with some of the heavy lifting that is going to be needed > here and so any pointers would certainly be appreciated. > > Thank you. > > > > Mike Ireton > President > Your Town Online, Inc DBA WillitsOnline > Rural Broadband Now, LLC > From jfmezei_nanog at vaxination.ca Wed Oct 18 06:51:41 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 18 Oct 2017 02:51:41 -0400 Subject: Northern California fires and telecomm outages In-Reply-To: <3f345c93-4fdf-8a07-3039-27699d74a061@tiedyenetworks.com> References: <3f345c93-4fdf-8a07-3039-27699d74a061@tiedyenetworks.com> Message-ID: On 2017-10-17 17:43, Mike wrote: > trying to address. We notified ATT of our need and only days later, > without followup response, it was suggested that we somehow don't have > the legal authority to install microwave My reaction would have been to call local mayor, mayor in twon where you try to setup the microwave base, and then if that fails FEMA and tell them that you can restore Internet but AT&T is blocking you. They would have the means to give a call to ATT and get them to stop blocking you. This is an emergency and AT&T would look very very bad if this were to become public. From nanog at ics-il.net Wed Oct 18 11:42:46 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Oct 2017 06:42:46 -0500 (CDT) Subject: Northern California fires and telecomm outages In-Reply-To: References: <3f345c93-4fdf-8a07-3039-27699d74a061@tiedyenetworks.com> Message-ID: <1165364938.3444.1508326963466.JavaMail.mhammett@ThunderFuck> I'd like to think that most independent operators avoided the ILEC at all costs due to them being difficult to work with, but every now and then you get one that loves to be with the ILEC. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" To: nanog at nanog.org Sent: Wednesday, October 18, 2017 1:51:41 AM Subject: Re: Northern California fires and telecomm outages On 2017-10-17 17:43, Mike wrote: > trying to address. We notified ATT of our need and only days later, > without followup response, it was suggested that we somehow don't have > the legal authority to install microwave My reaction would have been to call local mayor, mayor in twon where you try to setup the microwave base, and then if that fails FEMA and tell them that you can restore Internet but AT&T is blocking you. They would have the means to give a call to ATT and get them to stop blocking you. This is an emergency and AT&T would look very very bad if this were to become public. From mike-nanog at tiedyenetworks.com Wed Oct 18 14:08:11 2017 From: mike-nanog at tiedyenetworks.com (Mike) Date: Wed, 18 Oct 2017 07:08:11 -0700 Subject: Northern California fires and telecomm outages In-Reply-To: <85fc599e-01e4-35ab-4cba-cbbfff231e29@rollernet.us> References: <3f345c93-4fdf-8a07-3039-27699d74a061@tiedyenetworks.com> <85fc599e-01e4-35ab-4cba-cbbfff231e29@rollernet.us> Message-ID: On 10/17/2017 03:19 PM, Seth Mattinen wrote: > > Out of curiosity, why weren't there any existing emergency/last-resort > microwave links already in place? It seems to be known that this cable > is a single point of failure ahead of time. Were there previous plans > to set up any microwave links that got put on the back burner or > canceled? > > Is there too much focus on fiber being the only option? IMO it's > harder for a fire to destroy a microwave path vs. a fiber path, and > some capacity is better than no capacity. > > ~Seth > > The ATT building where we have collocation already however, would be quick and easy to add microwave, but they formally resist that idea and are of the position that we don't have the right to do so, despite it being in our interconnection agreement. They are digging in their heels and will have be addressed by the regulatory authority, which is not a quick process.  The cost of pulling a new cable to another building that has sufficient line of sight, is prohibitive. Not impossible, but could add six figures to the cost, and therefore is not realistic. Mike- From mike-nanog at tiedyenetworks.com Wed Oct 18 14:11:41 2017 From: mike-nanog at tiedyenetworks.com (Mike) Date: Wed, 18 Oct 2017 07:11:41 -0700 Subject: Northern California fires and telecomm outages In-Reply-To: References: <3f345c93-4fdf-8a07-3039-27699d74a061@tiedyenetworks.com> Message-ID: <9a01ebb0-1be8-a0ec-0749-f288aef20216@tiedyenetworks.com> On 10/17/2017 10:05 PM, Constantine A. Murenin wrote: > Hi Mike, > > Thanks for sharing the story in what must be quite a difficult time. > > You mention that Level3 also has presence in the county, including > their own independent route. Did they also suffer an outage during > this latest incident? If not, then why did their connection not allow > at least some customers to remain online? > > Also, as another poster pointed out, would also be interesting to know > why the microwave link was not already established prior to this > incident if the single point of failure was so well known. > (Especially if your contract with AT&T already mentions that you are > supposedly allowed to have microwave at their CO.) > > Cheers, > Constantine. We have attempted to engage exactly that for years - installing a microwave backup - but the only place it can be done, the top of the ATT central office where we are located - is resisted steadfastly by ATT despite it being a right enshrined in our contract, and there are no other realistic options that are also within our financial means to accomplish at this time. Mike- From nanog at ics-il.net Wed Oct 18 17:30:02 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Oct 2017 12:30:02 -0500 (CDT) Subject: AS36040 Prefix Limits In-Reply-To: <204096213.4175.1508347501222.JavaMail.mhammett@ThunderFuck> Message-ID: <495568468.4193.1508347798972.JavaMail.mhammett@ThunderFuck> I am looking for someone that can speak authoritatively regarding AS36040's ability to change their own prefix limits, prefix filtering, etc. My current contact is advising the IX to do the filtering for them, which is not something IXes should be doing. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From morrowc.lists at gmail.com Wed Oct 18 18:49:40 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 18 Oct 2017 14:49:40 -0400 Subject: AS36040 Prefix Limits In-Reply-To: <495568468.4193.1508347798972.JavaMail.mhammett@ThunderFuck> References: <204096213.4175.1508347501222.JavaMail.mhammett@ThunderFuck> <495568468.4193.1508347798972.JavaMail.mhammett@ThunderFuck> Message-ID: what's the question? On Wed, Oct 18, 2017 at 1:30 PM, Mike Hammett wrote: > I am looking for someone that can speak authoritatively regarding > AS36040's ability to change their own prefix limits, prefix filtering, etc. > > My current contact is advising the IX to do the filtering for them, which > is not something IXes should be doing. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From nanog at ics-il.net Wed Oct 18 20:16:07 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 18 Oct 2017 15:16:07 -0500 (CDT) Subject: AS36040 Prefix Limits In-Reply-To: References: <204096213.4175.1508347501222.JavaMail.mhammett@ThunderFuck> <495568468.4193.1508347798972.JavaMail.mhammett@ThunderFuck> Message-ID: <42739994.4454.1508357765149.JavaMail.mhammett@ThunderFuck> I need someone at 36040 that knows their head from their foot and can fix their prefix limits and\or filtering. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Christopher Morrow" To: "Mike Hammett" Cc: "NANOG list" Sent: Wednesday, October 18, 2017 1:49:40 PM Subject: Re: AS36040 Prefix Limits what's the question? On Wed, Oct 18, 2017 at 1:30 PM, Mike Hammett < nanog at ics-il.net > wrote: I am looking for someone that can speak authoritatively regarding AS36040's ability to change their own prefix limits, prefix filtering, etc. My current contact is advising the IX to do the filtering for them, which is not something IXes should be doing. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From morrowc.lists at gmail.com Wed Oct 18 20:28:40 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 18 Oct 2017 16:28:40 -0400 Subject: AS36040 Prefix Limits In-Reply-To: <42739994.4454.1508357765149.JavaMail.mhammett@ThunderFuck> References: <204096213.4175.1508347501222.JavaMail.mhammett@ThunderFuck> <495568468.4193.1508347798972.JavaMail.mhammett@ThunderFuck> <42739994.4454.1508357765149.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, Oct 18, 2017 at 4:16 PM, Mike Hammett wrote: > I need someone at 36040 that knows their head from their foot and can fix > their prefix limits and\or filtering. > > > sure, do you want to mail me at work and we can chat? :) (I can either fix or find a person to fix) > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Christopher Morrow" > To: "Mike Hammett" > Cc: "NANOG list" > Sent: Wednesday, October 18, 2017 1:49:40 PM > Subject: Re: AS36040 Prefix Limits > > > what's the question? > > > On Wed, Oct 18, 2017 at 1:30 PM, Mike Hammett < nanog at ics-il.net > wrote: > > > I am looking for someone that can speak authoritatively regarding > AS36040's ability to change their own prefix limits, prefix filtering, etc. > > My current contact is advising the IX to do the filtering for them, which > is not something IXes should be doing. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > > > > From large.hadron.collider at gmx.com Thu Oct 19 05:09:03 2017 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Wed, 18 Oct 2017 22:09:03 -0700 Subject: Looking for a contact with clue at Choopa/Reliablesite network engineering In-Reply-To: <827ab68d-5915-1dc5-37ca-41ec9a9f4c61@winterei.se> References: <827ab68d-5915-1dc5-37ca-41ec9a9f4c61@winterei.se> Message-ID: Thanks for reminding me to switch away from Vultr at my earliest opportunity. On 13/10/2017 05:56, Paul S. wrote: > Hi nanog, > > Choopa/reliablesite is announcing our IP space, and despite repeated > requests from us, they are refusing to withdraw the announcements. > > Can someone with clue from this contact me? Does anyone know someone > at Choopa neteng? > > Their abuse desk has so far proved useless. > From andy at nosignal.org Thu Oct 19 06:20:08 2017 From: andy at nosignal.org (Andy Davidson) Date: Thu, 19 Oct 2017 06:20:08 +0000 Subject: AS36040 Prefix Limits In-Reply-To: <495568468.4193.1508347798972.JavaMail.mhammett@ThunderFuck> References: <204096213.4175.1508347501222.JavaMail.mhammett@ThunderFuck> <495568468.4193.1508347798972.JavaMail.mhammett@ThunderFuck> Message-ID: Hi, Mike On 18/10/2017, 18:39, Mike Hammett wrote: > I am looking for someone that can speak authoritatively regarding AS36040's > ability to change their own prefix limits, prefix filtering, etc. > My current contact is advising the IX to do the filtering for them, which > is not something IXes should be doing. Unless this is in conjunction with a multilateral peering session (“route-server”), when prefix-filtering is something that the IXP very much should be doing. Andy From Nathan.Brookfield at simtronic.com.au Thu Oct 19 06:39:51 2017 From: Nathan.Brookfield at simtronic.com.au (Nathan Brookfield) Date: Thu, 19 Oct 2017 06:39:51 +0000 Subject: AS36040 Prefix Limits In-Reply-To: References: <204096213.4175.1508347501222.JavaMail.mhammett@ThunderFuck> <495568468.4193.1508347798972.JavaMail.mhammett@ThunderFuck>, Message-ID: <82E12819-A353-41C3-AB2D-49BCF720A0D6@simtronic.com.au> Both sides should be filtering advertisements. The IX may just filter by AS Path which is fairly normal by the originating AS or transiting AS should be filtering the prefixes they advertise as well/ Nathan Brookfield Chief Executive Officer Simtronic Technologies Pty Ltd http://www.simtronic.com.au On 19 Oct 2017, at 17:23, Andy Davidson > wrote: Hi, Mike On 18/10/2017, 18:39, Mike Hammett > wrote: I am looking for someone that can speak authoritatively regarding AS36040's ability to change their own prefix limits, prefix filtering, etc. My current contact is advising the IX to do the filtering for them, which is not something IXes should be doing. Unless this is in conjunction with a multilateral peering session (“route-server”), when prefix-filtering is something that the IXP very much should be doing. Andy From sean at donelan.com Thu Oct 19 07:00:44 2017 From: sean at donelan.com (Sean Donelan) Date: Thu, 19 Oct 2017 03:00:44 -0400 (EDT) Subject: Puerto Rico: Lack of electricity threatens telephone and internet services Message-ID: On October 18, 2017, the Puerto Rican Telecommunications Alliance warned the lack of utility power in the main telecommunications centers (Metro office park, Caparra and San Patricio) may not be sustainable soon. Although the telecommunication facilities are using generators, they are not intended for long-term, continuous use. The generators will need maintenance and likely experience unscheduled failures the longer they're used. While APT is avoiding identifying specific facilities or operators, this is the general area where several submarine cable operators and telecommunication providers interconnect. https://www.elnuevodia.com/negocios/empresas/nota/faltadeelectricidadponeenpeligroserviciosdetelefoniaeinternet-2367092/ From brandon at burn.net Thu Oct 19 12:04:12 2017 From: brandon at burn.net (Brandon Applegate) Date: Thu, 19 Oct 2017 08:04:12 -0400 Subject: TWC/Charter/Spectrum contact off-list ? (Reverse DNS issue) Message-ID: Hello, I had success with this issue about 2 years ago when some TWC folks contacted me. I don’t know if those folks are still with TWC/Charter here in the end of 2017 - hence posting on NANOG. The tl;dr is IPv6 reverse DNS issues. It was broken, got fixed, and seems to have broken again recently. Thanks in advance. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From nanog at ics-il.net Thu Oct 19 13:14:33 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 19 Oct 2017 08:14:33 -0500 (CDT) Subject: AS36040 Prefix Limits In-Reply-To: References: <204096213.4175.1508347501222.JavaMail.mhammett@ThunderFuck> <495568468.4193.1508347798972.JavaMail.mhammett@ThunderFuck> Message-ID: <846805176.5316.1508418871094.JavaMail.mhammett@ThunderFuck> Chris got me in touch with the right people. Thanks. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Christopher Morrow" To: "Mike Hammett" Cc: "NANOG list" Sent: Wednesday, October 18, 2017 1:49:40 PM Subject: Re: AS36040 Prefix Limits what's the question? On Wed, Oct 18, 2017 at 1:30 PM, Mike Hammett < nanog at ics-il.net > wrote: I am looking for someone that can speak authoritatively regarding AS36040's ability to change their own prefix limits, prefix filtering, etc. My current contact is advising the IX to do the filtering for them, which is not something IXes should be doing. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From nanog at ics-il.net Thu Oct 19 13:17:33 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 19 Oct 2017 08:17:33 -0500 (CDT) Subject: AS36040 Prefix Limits In-Reply-To: References: <204096213.4175.1508347501222.JavaMail.mhammett@ThunderFuck> <495568468.4193.1508347798972.JavaMail.mhammett@ThunderFuck> Message-ID: <1562353372.5328.1508419050348.JavaMail.mhammett@ThunderFuck> It is in conjunction with a route server. The filtering I meant would be that network A wants the IX to drop all advertisements to them from network B. Normally solved by network B putting a community on their routes to not advertise to network A, but network B doesn't want to do one-off configs. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Andy Davidson" To: "Mike Hammett" Cc: "NANOG list" Sent: Thursday, October 19, 2017 1:20:08 AM Subject: Re: AS36040 Prefix Limits Hi, Mike On 18/10/2017, 18:39, Mike Hammett wrote: > I am looking for someone that can speak authoritatively regarding AS36040's > ability to change their own prefix limits, prefix filtering, etc. > My current contact is advising the IX to do the filtering for them, which > is not something IXes should be doing. Unless this is in conjunction with a multilateral peering session (“route-server”), when prefix-filtering is something that the IXP very much should be doing. Andy From Brian at ampr.org Thu Oct 19 08:09:12 2017 From: Brian at ampr.org (Brian Kantor) Date: Thu, 19 Oct 2017 01:09:12 -0700 Subject: Looking for a contact with clue at Choopa/Reliablesite network engineering In-Reply-To: References: <827ab68d-5915-1dc5-37ca-41ec9a9f4c61@winterei.se> Message-ID: <20171019080912.GA31056@UCSD.Edu> The most recent contact I have had with Vultr (parent of Choopa) is Richard Simpliciano , who a week ago signed his note as "network administrator". He was checking with me as to whether a customer of theirs was authorized to have Vultr announce one of our prefixes, so he might be the right person to contact. - Brian On 13/10/2017 05:56, Paul S. wrote: >Hi nanog, > >Choopa/reliablesite is announcing our IP space, and despite repeated >requests from us, they are refusing to withdraw the announcements. > >Can someone with clue from this contact me? Does anyone know someone at >Choopa neteng? > >Their abuse desk has so far proved useless. > From lee at asgard.org Thu Oct 19 15:49:49 2017 From: lee at asgard.org (Lee Howard) Date: Thu, 19 Oct 2017 11:49:49 -0400 Subject: F Y I In-Reply-To: References: <59E67071.9000406@hawaii.edu> Message-ID: On 10/17/17, 5:33 PM, "NANOG on behalf of Christopher Morrow" wrote: >you know, the Sci-Hub folk could fix this themselves... with some >authentication requirements... and probably by just unplugging from the >intertubes? "Sci-Hub’s founder, has previously told The Scientist the site plans to ignore the lawsuit.” How would Sci-Hub consider this a “fix”? What enforcement mechanism would the Court have against Sci-Hub? The idea of making third parties (ISPs) incur costs (updating ACLs or poisoning DNS) to enforce the order is pretty bad, and doesn’t stop Tor access. Sorry I didn’t have a chance to file an amicus before the ruling tomorrow. Lee > >On Tue, Oct 17, 2017 at 5:04 PM, Robert Mathews (OSIA) > >wrote: > >> >> Judge Recommends Ruling to Block Internet Access to Sci-Hub >> The American Chemical Society seeks a broad order that includes millions >> of dollars in damages and demands action from Internet service providers >> and search engines. >> By Diana Kwon | October 4, 2017 >> >> http://www.the-scientist.com/?articles.view/articleNo/50563/ >> title/Judge-Recommends-Ruling-to-Block-Internet-Access-to-Sci-Hub/ >> http://www.the-scientist.com/?articles.view/articleNo/50361/ >> title/Publishers--Legal-Action-Advances-Against-Sci-Hub/ >> > From lista-gter at tbonet.net.br Thu Oct 19 15:57:01 2017 From: lista-gter at tbonet.net.br (=?UTF-8?Q?Jo=c3=a3o_Butzke?=) Date: Thu, 19 Oct 2017 13:57:01 -0200 Subject: F Y I In-Reply-To: References: <59E67071.9000406@hawaii.edu> Message-ID: it worked here in Brazil against whatsapp. Em 19/10/2017 13:49, Lee Howard escreveu: > > > > On 10/17/17, 5:33 PM, "NANOG on behalf of Christopher Morrow" > wrote: > >> you know, the Sci-Hub folk could fix this themselves... with some >> authentication requirements... and probably by just unplugging from the >> intertubes? > "Sci-Hub’s founder, has previously told The Scientist the site plans to > ignore the lawsuit.” How would Sci-Hub consider this a “fix”? > > What enforcement mechanism would the Court have against Sci-Hub? > > The idea of making third parties (ISPs) incur costs (updating ACLs or > poisoning DNS) to enforce the order is pretty bad, and doesn’t stop Tor > access. Sorry I didn’t have a chance to file an amicus before the ruling > tomorrow. > > > > Lee > > >> On Tue, Oct 17, 2017 at 5:04 PM, Robert Mathews (OSIA) >> >> wrote: >> >>> Judge Recommends Ruling to Block Internet Access to Sci-Hub >>> The American Chemical Society seeks a broad order that includes millions >>> of dollars in damages and demands action from Internet service providers >>> and search engines. >>> By Diana Kwon | October 4, 2017 >>> >>> http://www.the-scientist.com/?articles.view/articleNo/50563/ >>> title/Judge-Recommends-Ruling-to-Block-Internet-Access-to-Sci-Hub/ >>> http://www.the-scientist.com/?articles.view/articleNo/50361/ >>> title/Publishers--Legal-Action-Advances-Against-Sci-Hub/ >>> > From morrowc.lists at gmail.com Thu Oct 19 16:07:00 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Oct 2017 12:07:00 -0400 Subject: F Y I In-Reply-To: References: <59E67071.9000406@hawaii.edu> Message-ID: On Thu, Oct 19, 2017 at 11:57 AM, João Butzke wrote: > it worked here in Brazil against whatsapp. > > there are lots of cases of this sort of tomfoolery "working"... in part or in whole. Lee's point is it's dumb to offload this problem on every ISP in the jurisdiction, AND it's also not going to really fix the problem if the application is accessible via 'vpn' services (tor, real-vpns, etc). it's just sort of dumb all the way around :( > > Em 19/10/2017 13:49, Lee Howard escreveu: > >> >> >> On 10/17/17, 5:33 PM, "NANOG on behalf of Christopher Morrow" >> wrote: >> >> you know, the Sci-Hub folk could fix this themselves... with some >>> authentication requirements... and probably by just unplugging from the >>> intertubes? >>> >> "Sci-Hub’s founder, has previously told The Scientist the site plans to >> ignore the lawsuit.” How would Sci-Hub consider this a “fix”? >> >> What enforcement mechanism would the Court have against Sci-Hub? >> >> The idea of making third parties (ISPs) incur costs (updating ACLs or >> poisoning DNS) to enforce the order is pretty bad, and doesn’t stop Tor >> access. Sorry I didn’t have a chance to file an amicus before the ruling >> tomorrow. >> >> >> >> Lee >> >> >> On Tue, Oct 17, 2017 at 5:04 PM, Robert Mathews (OSIA) >>> >>> wrote: >>> >>> Judge Recommends Ruling to Block Internet Access to Sci-Hub >>>> The American Chemical Society seeks a broad order that includes millions >>>> of dollars in damages and demands action from Internet service providers >>>> and search engines. >>>> By Diana Kwon | October 4, 2017 >>>> >>>> http://www.the-scientist.com/?articles.view/articleNo/50563/ >>>> title/Judge-Recommends-Ruling-to-Block-Internet-Access-to-Sci-Hub/ >>>> http://www.the-scientist.com/?articles.view/articleNo/50361/ >>>> title/Publishers--Legal-Action-Advances-Against-Sci-Hub/ >>>> >>>> >> > From ahebert at pubnix.net Thu Oct 19 17:46:00 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 19 Oct 2017 13:46:00 -0400 Subject: F Y I In-Reply-To: References: <59E67071.9000406@hawaii.edu> Message-ID: <69d10e7e-d147-3014-cd6e-1d5b1a207012@pubnix.net>     Well,     We could also break that 200yo+ paradigm of having a paywall for what should pretty much be free.         Like that media supply chain still forcing licensing per country...     And yes $35USD can be a lot of money for people that are hungry for both food and knowledge. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 10/19/17 12:07, Christopher Morrow wrote: > On Thu, Oct 19, 2017 at 11:57 AM, João Butzke > wrote: > >> it worked here in Brazil against whatsapp. >> >> > there are lots of cases of this sort of tomfoolery "working"... in part or > in whole. > Lee's point is it's dumb to offload this problem on every ISP in the > jurisdiction, AND it's also not going to really fix the problem if the > application is accessible via 'vpn' services (tor, real-vpns, etc). > > it's just sort of dumb all the way around :( > > >> Em 19/10/2017 13:49, Lee Howard escreveu: >> >>> >>> On 10/17/17, 5:33 PM, "NANOG on behalf of Christopher Morrow" >>> wrote: >>> >>> you know, the Sci-Hub folk could fix this themselves... with some >>>> authentication requirements... and probably by just unplugging from the >>>> intertubes? >>>> >>> "Sci-Hub’s founder, has previously told The Scientist the site plans to >>> ignore the lawsuit.” How would Sci-Hub consider this a “fix”? >>> >>> What enforcement mechanism would the Court have against Sci-Hub? >>> >>> The idea of making third parties (ISPs) incur costs (updating ACLs or >>> poisoning DNS) to enforce the order is pretty bad, and doesn’t stop Tor >>> access. Sorry I didn’t have a chance to file an amicus before the ruling >>> tomorrow. >>> >>> >>> >>> Lee >>> >>> >>> On Tue, Oct 17, 2017 at 5:04 PM, Robert Mathews (OSIA) >>>> >>>> wrote: >>>> >>>> Judge Recommends Ruling to Block Internet Access to Sci-Hub >>>>> The American Chemical Society seeks a broad order that includes millions >>>>> of dollars in damages and demands action from Internet service providers >>>>> and search engines. >>>>> By Diana Kwon | October 4, 2017 >>>>> >>>>> http://www.the-scientist.com/?articles.view/articleNo/50563/ >>>>> title/Judge-Recommends-Ruling-to-Block-Internet-Access-to-Sci-Hub/ >>>>> http://www.the-scientist.com/?articles.view/articleNo/50361/ >>>>> title/Publishers--Legal-Action-Advances-Against-Sci-Hub/ >>>>> >>>>> From jfmezei_nanog at vaxination.ca Thu Oct 19 19:06:08 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 19 Oct 2017 15:06:08 -0400 Subject: Puerto Rico: Lack of electricity threatens telephone and internet services In-Reply-To: References: Message-ID: <7be29045-2f58-ad6f-890b-54f2f558499d@vaxination.ca> On 2017-10-19 03:00, Sean Donelan wrote: > not intended for long-term, continuous use. The generators will need > maintenance and likely experience unscheduled failures the longer they're > used. Permanent duty diesel generators exist. Many northern communities in Canada run on them as their 7/24 power source. It *shouldn't* have taken long after Maria for locals to know how much damage there had been to electrical grid and that if it's gonna take months to fix, you're gonna need constant duty generators. What isn't clear to me is whether everything still depends on FEMA/army help, or whether business is able to function autonomously and get their own generators without the army confiscating them to be delieved to a hospital instead. And if you're a telco who is deprived of revenues because almost all your customers are without power, do you spend your own money and effort to try to get a permanent duty diesel generator to maintain your central office, or do you wait for government to install one for you ? It is one thing to be benevolent and wanting to have your network backbone up, but financial realities of the cost of running a business without revenues will eventually hit you when the disaster lasts for months instead of days. From jeffshultz at sctcweb.com Thu Oct 19 22:11:37 2017 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Thu, 19 Oct 2017 15:11:37 -0700 Subject: Puerto Rico: Lack of electricity threatens telephone and internet services In-Reply-To: <7be29045-2f58-ad6f-890b-54f2f558499d@vaxination.ca> References: <7be29045-2f58-ad6f-890b-54f2f558499d@vaxination.ca> Message-ID: It does make you wonder about the electrical infrastructure of the island, and how much work is being done to repair it. With the Texas and Florida hurricanes you saw fleets of electrical service vehicles (boom trucks and the like) from other power companies with joint agreements waiting to deploy into the disaster area as soon as it was safe to do so. With PR.... well, it's not like you can drive to the island, much less (apparently) around on it. Getting those vehicles and people in, assuming joint agreements with off island power companies existed in the first place, would be a case of scheduling and determining priorities. And for those crying that the US Federal Gov't ought to do it - where do you think they're going to find the people? It's not like they have armies of infrastructure level electricians just sitting around playing cards until needed for an emergency - these are the sort of people who, by and large, are already working at jobs - where they are needed as well. When it comes to infrastructure it seems like PR has been knocked back to the "tools to make tools" stage - they need to build the infrastructure to rebuild their infrastructure, which was apparently in no great shape to begin with. On Thu, Oct 19, 2017 at 12:06 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 2017-10-19 03:00, Sean Donelan wrote: > > > not intended for long-term, continuous use. The generators will need > > maintenance and likely experience unscheduled failures the longer they're > > used. > > Permanent duty diesel generators exist. Many northern communities in > Canada run on them as their 7/24 power source. > > It *shouldn't* have taken long after Maria for locals to know how much > damage there had been to electrical grid and that if it's gonna take > months to fix, you're gonna need constant duty generators. > > What isn't clear to me is whether everything still depends on FEMA/army > help, or whether business is able to function autonomously and get their > own generators without the army confiscating them to be delieved to a > hospital instead. > > And if you're a telco who is deprived of revenues because almost all > your customers are without power, do you spend your own money and effort > to try to get a permanent duty diesel generator to maintain your central > office, or do you wait for government to install one for you ? > > It is one thing to be benevolent and wanting to have your network > backbone up, but financial realities of the cost of running a business > without revenues will eventually hit you when the disaster lasts for > months instead of days. > -- Jeff Shultz Central Office Technician SCTC (503) 769-2125 Go Big Ask for Gig -- 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 web at typo.org Thu Oct 19 22:18:06 2017 From: web at typo.org (Wayne Bouchard) Date: Thu, 19 Oct 2017 15:18:06 -0700 Subject: Puerto Rico: Lack of electricity threatens telephone and internet services In-Reply-To: References: <7be29045-2f58-ad6f-890b-54f2f558499d@vaxination.ca> Message-ID: <20171019221806.GA87968@spider.typo.org> Well, the problem as I understand it is that the infrastructure was not all that great to begin with. Much of it was damaged in the first storm and when this second one came through, what remained basically disappeared. That's why they say that the only thing you can do is start from the middle and slowly extend the tentacles outward. You're almost building the territory from scratch. Assuming that the reports of theft, misapproproation, and other nefarious occurences are correct, that certainly does not help matters. Still, this situation ought to make everyone sit up and think about their own DR capability. On Thu, Oct 19, 2017 at 03:11:37PM -0700, Jeff Shultz wrote: > It does make you wonder about the electrical infrastructure of the island, > and how much work is being done to repair it. With the Texas and Florida > hurricanes you saw fleets of electrical service vehicles (boom trucks and > the like) from other power companies with joint agreements waiting to > deploy into the disaster area as soon as it was safe to do so. > > With PR.... well, it's not like you can drive to the island, much less > (apparently) around on it. Getting those vehicles and people in, assuming > joint agreements with off island power companies existed in the first > place, would be a case of scheduling and determining priorities. > > And for those crying that the US Federal Gov't ought to do it - where do > you think they're going to find the people? It's not like they have armies > of infrastructure level electricians just sitting around playing cards > until needed for an emergency - these are the sort of people who, by and > large, are already working at jobs - where they are needed as well. > > When it comes to infrastructure it seems like PR has been knocked back to > the "tools to make tools" stage - they need to build the infrastructure to > rebuild their infrastructure, which was apparently in no great shape to > begin with. > > On Thu, Oct 19, 2017 at 12:06 PM, Jean-Francois Mezei < > jfmezei_nanog at vaxination.ca> wrote: > > > On 2017-10-19 03:00, Sean Donelan wrote: > > > > > not intended for long-term, continuous use. The generators will need > > > maintenance and likely experience unscheduled failures the longer they're > > > used. > > > > Permanent duty diesel generators exist. Many northern communities in > > Canada run on them as their 7/24 power source. > > > > It *shouldn't* have taken long after Maria for locals to know how much > > damage there had been to electrical grid and that if it's gonna take > > months to fix, you're gonna need constant duty generators. > > > > What isn't clear to me is whether everything still depends on FEMA/army > > help, or whether business is able to function autonomously and get their > > own generators without the army confiscating them to be delieved to a > > hospital instead. > > > > And if you're a telco who is deprived of revenues because almost all > > your customers are without power, do you spend your own money and effort > > to try to get a permanent duty diesel generator to maintain your central > > office, or do you wait for government to install one for you ? > > > > It is one thing to be benevolent and wanting to have your network > > backbone up, but financial realities of the cost of running a business > > without revenues will eventually hit you when the disaster lasts for > > months instead of days. > > > > > > -- > Jeff Shultz > Central Office Technician > SCTC > (503) 769-2125 > Go Big Ask for Gig > > -- > 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. **** --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From jfmezei_nanog at vaxination.ca Thu Oct 19 23:44:05 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 19 Oct 2017 19:44:05 -0400 Subject: Puerto Rico: Lack of electricity threatens telephone and internet services In-Reply-To: <20171019221806.GA87968@spider.typo.org> References: <7be29045-2f58-ad6f-890b-54f2f558499d@vaxination.ca> <20171019221806.GA87968@spider.typo.org> Message-ID: <658be549-1b22-652b-e813-c3031a41de35@vaxination.ca> On 2017-10-19 18:18, Wayne Bouchard wrote: > Well, the problem as I understand it is that the infrastructure was > not all that great to begin with. Much of it was damaged in the first > storm and when this second one came through, what remained basically > disappeared. Being hit with a Cat 5 hurricane/cyclone in a caribeean island that hasn't been a direct hit from severe storms in decades will cause extensive damage no matter what state its infrastructure was in before. Vegetation that does not regular storms to "prune" it will grow to a point where it will cause major damage when a big storm hits. And a caribbean island who has never been "rich" will not have had, as a priority, increasing building codes to widthstand hurricanes. Building codes get updated after a big devastating hurricane, whether it is for Darwin in 1974 (Tracy) or ones like Andrew in Florida. It's easy for a state the size of Texas to send all of its electrical utility trucks to the Houson area to repair damage. But they too would be stretched thin if all of Texas had been leveled. If buildings were not built to widthstand a 5 or a 4, then the building itself becomes destructor of infrastructure as its materials become high speed projectiles throuwn at other buildings and especially teleohone/electrical lines. I went through a category 4 (Olivia, Australia 1996). While the town and building I was in (Karatha) were built to new standards and had little damage, I witnessed the power of it, and I can totally understand Puerto Rico being destroyed. I know a politician with tendancy to skew facts points to Puerto Rico having had terrible infrastructure. But consider that Darwin, a "rich" town" was wiped out in 1974 by Tracy. https://www.youtube.com/watch?v=B89wBGydSvs Tracy was a 4. Maria was a 5. (note the alert sound at start of video still sends shivers down my spine because it was the same as I heard before Olivia hit). The population was evacuated by 747s because there was nothing there to support it. The road link to is (Stuart Highway) is so long that Darwin is tantamount to an island. (especially since Stuart wasn't fully paved back then). Also note: in Florida, the utilities positioned all their equipment in safe places so it could survive storm and be deployed when needed. But what happens when there is no safe place, or the safe places become isolated because roads become impassable? It is one thing when a state has some areas with high level of destruction. But when the whole state is destroyed, it is a truly different situation because its economy is also destroyed. Florida Power still has plenty of revenues from undamaged areas to pay for the repairs in damaged areas. The Utility in Puerto Rico doesn't. (and if it was finacially weak before, it makes things worse). When you see other states' utilities coming to help in a highly damaged area, don't think for a minute they do this for free. The local utility stll gets a bill at the end of the day for the work done. If the Puerto Rico company has no cash to pay, don't exopect other utilities to send crews. From toddunder at gmail.com Thu Oct 19 23:56:29 2017 From: toddunder at gmail.com (Todd Underwood) Date: Thu, 19 Oct 2017 19:56:29 -0400 Subject: Puerto Rico: Lack of electricity threatens telephone and internet services In-Reply-To: References: <7be29045-2f58-ad6f-890b-54f2f558499d@vaxination.ca> <20171019221806.GA87968@spider.typo.org> <658be549-1b22-652b-e813-c3031a41de35@vaxination.ca> Message-ID: This thread is mostly full of idle speculation, is at the least insensitive and verges on offensive. If you have operational information about Puerto Rico (see Sean Donelan's posts rather than these responses), please go ahead. If you would like to allocate blame, please go somewhere else to do it. The Internet is full of people who are blaming Puerto Rico for getting hit by a hurricane. I don't need it here. Thanks, T (From Humacao) El 19 oct. 2017 19:45, "Jean-Francois Mezei" escribió: On 2017-10-19 18:18, Wayne Bouchard wrote: > Well, the problem as I understand it is that the infrastructure was > not all that great to begin with. Much of it was damaged in the first > storm and when this second one came through, what remained basically > disappeared. Being hit with a Cat 5 hurricane/cyclone in a caribeean island that hasn't been a direct hit from severe storms in decades will cause extensive damage no matter what state its infrastructure was in before. Vegetation that does not regular storms to "prune" it will grow to a point where it will cause major damage when a big storm hits. And a caribbean island who has never been "rich" will not have had, as a priority, increasing building codes to widthstand hurricanes. Building codes get updated after a big devastating hurricane, whether it is for Darwin in 1974 (Tracy) or ones like Andrew in Florida. It's easy for a state the size of Texas to send all of its electrical utility trucks to the Houson area to repair damage. But they too would be stretched thin if all of Texas had been leveled. If buildings were not built to widthstand a 5 or a 4, then the building itself becomes destructor of infrastructure as its materials become high speed projectiles throuwn at other buildings and especially teleohone/electrical lines. I went through a category 4 (Olivia, Australia 1996). While the town and building I was in (Karatha) were built to new standards and had little damage, I witnessed the power of it, and I can totally understand Puerto Rico being destroyed. I know a politician with tendancy to skew facts points to Puerto Rico having had terrible infrastructure. But consider that Darwin, a "rich" town" was wiped out in 1974 by Tracy. https://www.youtube.com/watch?v=B89wBGydSvs Tracy was a 4. Maria was a 5. (note the alert sound at start of video still sends shivers down my spine because it was the same as I heard before Olivia hit). The population was evacuated by 747s because there was nothing there to support it. The road link to is (Stuart Highway) is so long that Darwin is tantamount to an island. (especially since Stuart wasn't fully paved back then). Also note: in Florida, the utilities positioned all their equipment in safe places so it could survive storm and be deployed when needed. But what happens when there is no safe place, or the safe places become isolated because roads become impassable? It is one thing when a state has some areas with high level of destruction. But when the whole state is destroyed, it is a truly different situation because its economy is also destroyed. Florida Power still has plenty of revenues from undamaged areas to pay for the repairs in damaged areas. The Utility in Puerto Rico doesn't. (and if it was finacially weak before, it makes things worse). When you see other states' utilities coming to help in a highly damaged area, don't think for a minute they do this for free. The local utility stll gets a bill at the end of the day for the work done. If the Puerto Rico company has no cash to pay, don't exopect other utilities to send crews. From sotnickd-nanog at ddv.com Fri Oct 20 03:41:46 2017 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Thu, 19 Oct 2017 20:41:46 -0700 Subject: Google DNS intermittent ServFail for Disney subdomain Message-ID: Hi Nanog, I am principal network engineer for sister-studio to Disney Studios. They have been struggling with DNS issues since Thursday 12th October. By all accounts it appears as though *some* of the Google DNS resolvers cannot reach the authoritative nameservers for "studio.disney.com". This is causing ~20-30% of all DNS requests against Google Public DNS 8.8.8.8 / 8.8.4.4 to fail for requests in this subdomain. The name servers reside in 153.7.233.0/24. Might someone be able to *connect me* with someone at Google to assist my poor colleagues who are banging their heads against a brick wall here. Thank you, David From d3e3e3 at gmail.com Fri Oct 20 04:15:46 2017 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 20 Oct 2017 00:15:46 -0400 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: Message-ID: Looks like some Disney services are/have been down. http://downdetector.com/status/disneyworld Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com On Thu, Oct 19, 2017 at 11:41 PM, David Sotnick wrote: > Hi Nanog, > > I am principal network engineer for sister-studio to Disney Studios. They > have been struggling with DNS issues since Thursday 12th October. > > By all accounts it appears as though *some* of the Google DNS resolvers > cannot reach the authoritative nameservers for "studio.disney.com". > > This is causing ~20-30% of all DNS requests against Google Public DNS > 8.8.8.8 / 8.8.4.4 to fail for requests in this subdomain. > > The name servers reside in 153.7.233.0/24. > > Might someone be able to *connect me* with someone at Google to assist my > poor colleagues who are banging their heads against a brick wall here. > > Thank you, > David > From sotnickd-nanog at ddv.com Fri Oct 20 05:10:26 2017 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Thu, 19 Oct 2017 22:10:26 -0700 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: Message-ID: Well well, it looks like a Direct Connect circuit to Google was leaking the route to this DMZ 153.7.233.0/24 back to Google via BGP. Return traffic from Google (for only some fraction of DNS queries) was passing back across this leaked route, and being dropped on this Direct Connect peering point at Disney. Gotta love it when a problem is solved, by the OP, within an hour of resorting to mailing the NANOG community. Thanks all, nothing to see here! -David On Thu, Oct 19, 2017 at 8:41 PM, David Sotnick wrote: > Hi Nanog, > > I am principal network engineer for sister-studio to Disney Studios. They > have been struggling with DNS issues since Thursday 12th October. > > By all accounts it appears as though *some* of the Google DNS resolvers > cannot reach the authoritative nameservers for "studio.disney.com". > > This is causing ~20-30% of all DNS requests against Google Public DNS > 8.8.8.8 / 8.8.4.4 to fail for requests in this subdomain. > > The name servers reside in 153.7.233.0/24. > > Might someone be able to *connect me* with someone at Google to assist my > poor colleagues who are banging their heads against a brick wall here. > > Thank you, > David > From bjorn at mork.no Fri Oct 20 06:01:00 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 20 Oct 2017 08:01:00 +0200 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: (David Sotnick's message of "Thu, 19 Oct 2017 22:10:26 -0700") References: Message-ID: <87r2ty2w9v.fsf@miraculix.mork.no> David Sotnick writes: > Gotta love it when a problem is solved, by the OP, within an hour of > resorting to mailing the NANOG community. That's the way it is. Posting to a public forum always make you think about the issue a second time, and that's what it takes. The weird thing is that I've tried to cheat the system by thinking without posting, and it doesn't work! Don't know why, but there appears to be a difference between thinking and thinking :-) Thanks a lot for posting the solution. Bjørn From valdis.kletnieks at vt.edu Fri Oct 20 13:19:54 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 20 Oct 2017 09:19:54 -0400 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: <87r2ty2w9v.fsf@miraculix.mork.no> References: <87r2ty2w9v.fsf@miraculix.mork.no> Message-ID: <5751.1508505594@turing-police.cc.vt.edu> On Fri, 20 Oct 2017 08:01:00 +0200, Bjørn Mork said: > That's the way it is. Posting to a public forum always make you think > about the issue a second time, and that's what it takes. > > The weird thing is that I've tried to cheat the system by thinking > without posting, and it doesn't work! Don't know why, but there appears > to be a difference between thinking and thinking :-) Worthy .sig fodder indeed. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nanog at ics-il.net Fri Oct 20 13:23:32 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 20 Oct 2017 08:23:32 -0500 (CDT) Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: Message-ID: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> I know it doesn't help your problem, but friends don't let friends use public DNS resolvers (Google, L3, Open DNS, etc.). ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "David Sotnick" To: "NANOG" Sent: Thursday, October 19, 2017 10:41:46 PM Subject: Google DNS intermittent ServFail for Disney subdomain Hi Nanog, I am principal network engineer for sister-studio to Disney Studios. They have been struggling with DNS issues since Thursday 12th October. By all accounts it appears as though *some* of the Google DNS resolvers cannot reach the authoritative nameservers for "studio.disney.com". This is causing ~20-30% of all DNS requests against Google Public DNS 8.8.8.8 / 8.8.4.4 to fail for requests in this subdomain. The name servers reside in 153.7.233.0/24. Might someone be able to *connect me* with someone at Google to assist my poor colleagues who are banging their heads against a brick wall here. Thank you, David From fhr at fhrnet.eu Fri Oct 20 13:29:15 2017 From: fhr at fhrnet.eu (Filip Hruska) Date: Fri, 20 Oct 2017 15:29:15 +0200 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> References: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> Message-ID: Would be great if makers of home routers would implement full recursive DNS resolvers instead of just forwards in their gear. -- Filip Hruska Linux System Administrator Dne 10/20/17 v 15:23 Mike Hammett napsal(a): > I know it doesn't help your problem, but friends don't let friends use public DNS resolvers (Google, L3, Open DNS, etc.). ;-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "David Sotnick" > To: "NANOG" > Sent: Thursday, October 19, 2017 10:41:46 PM > Subject: Google DNS intermittent ServFail for Disney subdomain > > Hi Nanog, > > I am principal network engineer for sister-studio to Disney Studios. They > have been struggling with DNS issues since Thursday 12th October. > > By all accounts it appears as though *some* of the Google DNS resolvers > cannot reach the authoritative nameservers for "studio.disney.com". > > This is causing ~20-30% of all DNS requests against Google Public DNS > 8.8.8.8 / 8.8.4.4 to fail for requests in this subdomain. > > The name servers reside in 153.7.233.0/24. > > Might someone be able to *connect me* with someone at Google to assist my > poor colleagues who are banging their heads against a brick wall here. > > Thank you, > David > From bortzmeyer at nic.fr Fri Oct 20 13:47:21 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 20 Oct 2017 15:47:21 +0200 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> Message-ID: <20171020134721.nq4vykenasxy5q3i@nic.fr> On Fri, Oct 20, 2017 at 03:29:15PM +0200, Filip Hruska wrote a message of 49 lines which said: > Would be great if makers of home routers would implement full recursive DNS > resolvers The good ones do From fhr at fhrnet.eu Fri Oct 20 14:22:01 2017 From: fhr at fhrnet.eu (Filip Hruska) Date: Fri, 20 Oct 2017 16:22:01 +0200 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: <20171020134721.nq4vykenasxy5q3i@nic.fr> Message-ID: <8704e602-ef0e-4aa2-96be-1a896968e80a@email.android.com> From morrowc.lists at gmail.com Fri Oct 20 14:35:41 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 20 Oct 2017 10:35:41 -0400 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: Message-ID: On Fri, Oct 20, 2017 at 1:10 AM, David Sotnick wrote: > Well well, it looks like a Direct Connect circuit to Google was leaking the > route to this DMZ 153.7.233.0/24 back to Google via BGP. > > Return traffic from Google (for only some fraction of DNS queries) was > passing back across this leaked route, and being dropped on this Direct > Connect peering point at Disney. > > Gotta love it when a problem is solved, by the OP, within an hour of > resorting to mailing the NANOG community. > > This shows some issues as well, I think? http://dnsviz.net/d/studio.disney.com/servers/ $ dig NS disney.com ;; ANSWER SECTION: disney.com. 4676 IN NS huey11.disney.com. disney.com. 4676 IN NS huey.disney.com. disney.com. 4676 IN NS Orns02.dig.com. disney.com. 4676 IN NS Orns01.dig.com. disney.com. 4676 IN NS Sens02.dig.com. disney.com. 4676 IN NS Sens01.dig.com. $ dig NS studio.disney.com @huey11.disney.com. ;; AUTHORITY SECTION: studio.disney.com. 600 IN NS wallyb.pixar.com. studio.disney.com. 600 IN NS andre.pixar.com. studio.disney.com. 600 IN NS cliff.studio.disney.com. studio.disney.com. 600 IN NS norm.studio.disney.com. $ for d in $(dig +short NS disney.com); do dig +short SOA disney.com @$d; done huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 $ for d in $(dig +short NS studio.disney.com); do dig +short SOA studio.disney.com @$d; done cliff.studio.disney.com. admin.studio.disney.com. 2017101904 10800 3600 604800 86400 cliff.studio.disney.com. admin.studio.disney.com. 2017101904 10800 3600 604800 86400 cliff.studio.disney.com. admin.studio.disney.com. 2017101904 10800 3600 604800 86400 cliff.studio.disney.com. admin.studio.disney.com. 2017101904 10800 3600 604800 86400 cliff.studio.disney.com. admin.studio.disney.com. 2017101904 10800 3600 604800 86400 it looks like the second-level and third-level don't agree with each other on whom should be the NS for the third-level? that shouldn't be fatal, but is something to cleanup. Thanks all, nothing to see here! > > -David > > On Thu, Oct 19, 2017 at 8:41 PM, David Sotnick > wrote: > > > Hi Nanog, > > > > I am principal network engineer for sister-studio to Disney Studios. They > > have been struggling with DNS issues since Thursday 12th October. > > > > By all accounts it appears as though *some* of the Google DNS resolvers > > cannot reach the authoritative nameservers for "studio.disney.com". > > > > This is causing ~20-30% of all DNS requests against Google Public DNS > > 8.8.8.8 / 8.8.4.4 to fail for requests in this subdomain. > > > > The name servers reside in 153.7.233.0/24. > > > > Might someone be able to *connect me* with someone at Google to assist my > > poor colleagues who are banging their heads against a brick wall here. > > > > Thank you, > > David > > > From bcassell at oar.net Thu Oct 19 19:42:46 2017 From: bcassell at oar.net (Cassell, Brandon) Date: Thu, 19 Oct 2017 19:42:46 +0000 Subject: Contact / RPF issue with GoDaddy at Equinix Chicago Message-ID: <1906316F-EE52-431F-89FC-9AB91A00B194@oar.net> Would anyone happen to have a name or number of an engineer at GoDaddy who could help me with an issue we’re seeing with them at equinix in Chicago? It looks like it might be related to some kind of RPF checking they’re doing on their side that’s causing traffic for some of our /16’s to get dumped. Thanks, Brandon Cassell Tier 2 NOC Technician OARnet A member of the Ohio Technology Consortium 1224 Kinnear Road, Columbus, Ohio 43212 Phone: (614) 688-8728 Mobile: (614) 679-5716 Fax: (614) 292-9390 bcassell at oar.net Learn more about OARnet at https://oar.net From simon at slimey.org Fri Oct 20 15:51:13 2017 From: simon at slimey.org (Simon Lockhart) Date: Fri, 20 Oct 2017 16:51:13 +0100 Subject: Chinese websites loading slower recently? Message-ID: <20171020155112.GX15390@dilbert.slimey.org> All, I know that access to Chinese websites from outside China is notorious for being slow or broken, but we seem to have had a major increase in support calls from our users over the last couple of weeks, complaining of slow or no access to major Chinese websites, such as www.baidu.com, www.youku.com and world.taobao.com. We can't find anything on our network that would be affecting this, and at various times can (and cannot!) reproduce it with off-net connections, which would indicate that it's an intermittent, but widespread issue. Is anyone else seeing an increase in problems related to Chinese websites? Thanks in advance, Simon From ryangard at gmail.com Fri Oct 20 16:09:31 2017 From: ryangard at gmail.com (Ryan Gard) Date: Fri, 20 Oct 2017 12:09:31 -0400 Subject: Private Link between TOR and CHI In-Reply-To: References: Message-ID: Just an update -- We've sourced a solution and have moved forward with it. Thanks for all the replies with vendors -- It definitely helped with the sourcing process to find vendors that service both locales :) On Wed, Oct 11, 2017 at 3:04 PM, Ryan Gard wrote: > Trying to source some cost effective solutions or vendors that could > provide connectivity in this scenario. Essentially I'll be looking to > expand presence into Chicago, and as such, will need to source a third > party to provide connectivity from 151 Front Street in Toronto to 350 > Cermak in Chicago. Specifically, we're looking to build a presence in > Chicago to pursue peering agreements with other providers at 350 Cermak. > > If you're aware of any providers that would be able to provide this > connectivity, that would be perfect. > > Thanks! > > -- > Ryan Gard > -- Ryan Gard From mloftis at wgops.com Fri Oct 20 17:00:07 2017 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 20 Oct 2017 10:00:07 -0700 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: Message-ID: None of the NS records/delegations are in agreement. com delegations don't agree with authoritative in disney.com, and disney.com's delegations don't agree with studio.disney.com's NSen. On Fri, Oct 20, 2017 at 7:35 AM, Christopher Morrow wrote: > On Fri, Oct 20, 2017 at 1:10 AM, David Sotnick > wrote: > >> Well well, it looks like a Direct Connect circuit to Google was leaking the >> route to this DMZ 153.7.233.0/24 back to Google via BGP. >> >> Return traffic from Google (for only some fraction of DNS queries) was >> passing back across this leaked route, and being dropped on this Direct >> Connect peering point at Disney. >> >> Gotta love it when a problem is solved, by the OP, within an hour of >> resorting to mailing the NANOG community. >> >> > > This shows some issues as well, I think? > http://dnsviz.net/d/studio.disney.com/servers/ > > $ dig NS disney.com > > ;; ANSWER SECTION: > disney.com. 4676 IN NS huey11.disney.com. > disney.com. 4676 IN NS huey.disney.com. > disney.com. 4676 IN NS Orns02.dig.com. > disney.com. 4676 IN NS Orns01.dig.com. > disney.com. 4676 IN NS Sens02.dig.com. > disney.com. 4676 IN NS Sens01.dig.com. > > $ dig NS studio.disney.com @huey11.disney.com. > ;; AUTHORITY SECTION: > studio.disney.com. 600 IN NS wallyb.pixar.com. > studio.disney.com. 600 IN NS andre.pixar.com. > studio.disney.com. 600 IN NS cliff.studio.disney.com. > studio.disney.com. 600 IN NS norm.studio.disney.com. > > $ for d in $(dig +short NS disney.com); do dig +short SOA disney.com @$d; > done > huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 > huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 > huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 > huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 > huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 > huey.disney.com. root.huey.disney.com. 2017102000 3600 900 3600000 3600 > > $ for d in $(dig +short NS studio.disney.com); do dig +short SOA > studio.disney.com @$d; done > cliff.studio.disney.com. admin.studio.disney.com. 2017101904 10800 3600 > 604800 86400 > cliff.studio.disney.com. admin.studio.disney.com. 2017101904 10800 3600 > 604800 86400 > cliff.studio.disney.com. admin.studio.disney.com. 2017101904 10800 3600 > 604800 86400 > cliff.studio.disney.com. admin.studio.disney.com. 2017101904 10800 3600 > 604800 86400 > cliff.studio.disney.com. admin.studio.disney.com. 2017101904 10800 3600 > 604800 86400 > > it looks like the second-level and third-level don't agree with each other > on whom should be the NS for the third-level? > > that shouldn't be fatal, but is something to cleanup. > > > Thanks all, nothing to see here! >> >> -David >> >> On Thu, Oct 19, 2017 at 8:41 PM, David Sotnick >> wrote: >> >> > Hi Nanog, >> > >> > I am principal network engineer for sister-studio to Disney Studios. They >> > have been struggling with DNS issues since Thursday 12th October. >> > >> > By all accounts it appears as though *some* of the Google DNS resolvers >> > cannot reach the authoritative nameservers for "studio.disney.com". >> > >> > This is causing ~20-30% of all DNS requests against Google Public DNS >> > 8.8.8.8 / 8.8.4.4 to fail for requests in this subdomain. >> > >> > The name servers reside in 153.7.233.0/24. >> > >> > Might someone be able to *connect me* with someone at Google to assist my >> > poor colleagues who are banging their heads against a brick wall here. >> > >> > Thank you, >> > David >> > >> -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From cscora at apnic.net Fri Oct 20 18:02:40 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Oct 2017 04:02:40 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171020180240.4E2F2CD2@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 MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 21 Oct, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 664841 Prefixes after maximum aggregation (per Origin AS): 259627 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 321831 Total ASes present in the Internet Routing Table: 58796 Prefixes per ASN: 11.31 Origin-only ASes present in the Internet Routing Table: 50787 Origin ASes announcing only one prefix: 22389 Transit ASes present in the Internet Routing Table: 8009 Transit-only ASes present in the Internet Routing Table: 235 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 30 Max AS path prepend of ASN (206156) 26 Prefixes from unregistered ASNs in the Routing Table: 87 Number of instances of unregistered ASNs: 87 Number of 32-bit ASNs allocated by the RIRs: 20331 Number of 32-bit ASNs visible in the Routing Table: 16153 Prefixes from 32-bit ASNs in the Routing Table: 66379 Number of bogon 32-bit ASNs visible in the Routing Table: 21 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 386 Number of addresses announced to Internet: 2856852064 Equivalent to 170 /8s, 72 /16s and 26 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 219481 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 183270 Total APNIC prefixes after maximum aggregation: 52668 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 182323 Unique aggregates announced from the APNIC address blocks: 75594 APNIC Region origin ASes present in the Internet Routing Table: 8418 APNIC Prefixes per ASN: 21.66 APNIC Region origin ASes announcing only one prefix: 2341 APNIC Region transit ASes present in the Internet Routing Table: 1206 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3261 Number of APNIC addresses announced to Internet: 765538528 Equivalent to 45 /8s, 161 /16s and 48 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 199937 Total ARIN prefixes after maximum aggregation: 96532 ARIN Deaggregation factor: 2.07 Prefixes being announced from the ARIN address blocks: 201429 Unique aggregates announced from the ARIN address blocks: 94119 ARIN Region origin ASes present in the Internet Routing Table: 18008 ARIN Prefixes per ASN: 11.19 ARIN Region origin ASes announcing only one prefix: 6655 ARIN Region transit ASes present in the Internet Routing Table: 1776 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2232 Number of ARIN addresses announced to Internet: 1110528800 Equivalent to 66 /8s, 49 /16s and 83 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 178718 Total RIPE prefixes after maximum aggregation: 87403 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 174719 Unique aggregates announced from the RIPE address blocks: 105434 RIPE Region origin ASes present in the Internet Routing Table: 24515 RIPE Prefixes per ASN: 7.13 RIPE Region origin ASes announcing only one prefix: 11223 RIPE Region transit ASes present in the Internet Routing Table: 3506 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6286 Number of RIPE addresses announced to Internet: 713571968 Equivalent to 42 /8s, 136 /16s and 62 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 85162 Total LACNIC prefixes after maximum aggregation: 19053 LACNIC Deaggregation factor: 4.47 Prefixes being announced from the LACNIC address blocks: 86402 Unique aggregates announced from the LACNIC address blocks: 39199 LACNIC Region origin ASes present in the Internet Routing Table: 6493 LACNIC Prefixes per ASN: 13.31 LACNIC Region origin ASes announcing only one prefix: 1818 LACNIC Region transit ASes present in the Internet Routing Table: 1190 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4015 Number of LACNIC addresses announced to Internet: 172256992 Equivalent to 10 /8s, 68 /16s and 110 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17665 Total AfriNIC prefixes after maximum aggregation: 3897 AfriNIC Deaggregation factor: 4.53 Prefixes being announced from the AfriNIC address blocks: 19582 Unique aggregates announced from the AfriNIC address blocks: 7168 AfriNIC Region origin ASes present in the Internet Routing Table: 1090 AfriNIC Prefixes per ASN: 17.97 AfriNIC Region origin ASes announcing only one prefix: 351 AfriNIC Region transit ASes present in the Internet Routing Table: 215 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 359 Number of AfriNIC addresses announced to Internet: 94459904 Equivalent to 5 /8s, 161 /16s and 88 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5278 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4000 408 405 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2787 900 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2776 11126 751 KIXS-AS-KR Korea Telecom, KR 9829 2763 1499 541 BSNL-NIB National Internet Backbone, IN 9808 2360 8699 32 CMNET-GD Guangdong Mobile Communication 9394 2173 4931 27 CTTNET China TieTong Telecommunications 4755 2104 422 221 TATACOMM-AS TATA Communications formerl 45899 2097 1482 150 VNPT-AS-VN VNPT Corp, VN 7552 2074 1180 84 VIETEL-AS-AP Viettel Corporation, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3359 1325 84 SHAW - Shaw Communications Inc., CA 22773 3304 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2175 405 107 MEGAPATH5-US - MegaPath Corporation, US 6389 2045 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2045 2272 429 CHARTER-NET-HKY-NC - Charter Communicat 209 1951 5067 651 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1863 4032 561 AMAZON-02 - Amazon.com, Inc., US 30036 1834 329 296 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 701 1679 10589 626 UUNET - MCI Communications Services, In 11492 1630 240 563 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2809 839 2026 AKAMAI-ASN1, US 8551 2508 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2064 333 428 TELLCOM-AS, TR 12389 1864 1675 722 ROSTELECOM-AS, RU 12479 1796 1063 72 UNI2-AS, ES 9121 1775 1691 17 TTNET, TR 13188 1604 100 52 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1213 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3545 538 287 Telmex Colombia S.A., CO 8151 3217 3467 585 Uninet S.A. de C.V., MX 11830 2327 367 41 Instituto Costarricense de Electricidad 6503 1580 437 53 Axtel, S.A.B. de C.V., MX 7303 1479 1013 195 Telecom Argentina S.A., AR 6147 1274 377 27 Telefonica del Peru S.A.A., PE 3816 1031 509 103 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 999 2304 179 CLARO S.A., BR 11172 912 126 86 Alestra, S. de R.L. de C.V., MX 18881 901 1058 25 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1209 398 48 LINKdotNET-AS, EG 37611 776 91 8 Afrihost, ZA 36903 706 355 139 MT-MPLS, MA 36992 668 1383 31 ETISALAT-MISR, EG 24835 515 850 15 RAYA-AS, EG 8452 509 1730 17 TE-AS TE-AS, EG 29571 428 36 10 CITelecom-AS, CI 37492 416 354 77 ORANGE-, TN 15399 356 35 7 WANANCHI-, KE 2018 298 327 73 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5278 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4000 408 405 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3545 538 287 Telmex Colombia S.A., CO 39891 3387 186 23 ALJAWWALSTC-AS, SA 6327 3359 1325 84 SHAW - Shaw Communications Inc., CA 22773 3304 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8151 3217 3467 585 Uninet S.A. de C.V., MX 20940 2809 839 2026 AKAMAI-ASN1, US 17974 2787 900 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2776 11126 751 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4000 3595 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3359 3275 SHAW - Shaw Communications Inc., CA 10620 3545 3258 Telmex Colombia S.A., CO 22773 3304 3146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2787 2710 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8151 3217 2632 Uninet S.A. de C.V., MX 8551 2508 2466 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2360 2328 CMNET-GD Guangdong Mobile Communication Co.Ltd. 11830 2327 2286 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:106 /12:285 /13:553 /14:1050 /15:1866 /16:13398 /17:7739 /18:13627 /19:25100 /20:38989 /21:42822 /22:80447 /23:65685 /24:370901 /25:842 /26:621 /27:646 /28:35 /29:21 /30:15 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3157 3359 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2525 3304 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2070 2175 MEGAPATH5-US - MegaPath Corporation, US 8551 1972 2508 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 1697 2327 Instituto Costarricense de Electricidad y Telec 30036 1609 1834 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1532 3545 Telmex Colombia S.A., CO 11492 1449 1630 CABLEONE - CABLE ONE, INC., US 34984 1367 2064 TELLCOM-AS, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1566 2:838 4:18 5:2471 6:38 7:1 8:1070 9:1 12:1849 13:163 14:1709 15:29 16:3 17:175 18:76 20:59 23:2458 24:1651 25:2 27:2357 29:1 31:1933 32:89 35:21 36:418 37:2386 38:1411 39:74 40:98 41:3046 42:496 43:1927 44:85 45:3110 46:2837 47:172 49:1328 50:1015 51:19 52:868 54:353 55:2 56:4 57:43 58:1562 59:993 60:355 61:2025 62:1736 63:1848 64:4590 65:2225 66:4450 67:2311 68:1189 69:3169 70:1161 71:610 72:2114 74:2623 75:388 76:411 77:1498 78:1563 79:1950 80:1419 81:1413 82:1024 83:750 84:983 85:1931 86:467 87:1213 88:829 89:2254 90:171 91:6217 92:1032 93:2315 94:2402 95:2645 96:650 97:352 98:963 99:97 100:153 101:1303 102:1 103:15969 104:3065 105:208 106:564 107:1686 108:829 109:2902 110:1485 111:1744 112:1286 113:1253 114:1063 115:1569 116:1666 117:1837 118:2148 119:1650 120:911 121:1069 122:2429 123:1864 124:1493 125:1817 128:934 129:670 130:443 131:1499 132:602 133:193 134:794 135:227 136:359 137:497 138:1963 139:536 140:381 141:677 142:740 143:915 144:785 145:186 146:1108 147:704 148:1514 149:600 150:705 151:1007 152:722 153:301 154:923 155:750 156:695 157:739 158:595 159:1569 160:773 161:730 162:2500 163:509 164:984 165:1438 166:387 167:1310 168:3039 169:818 170:3498 171:379 172:994 173:1898 174:810 175:758 176:1867 177:3967 178:2483 179:1130 180:2212 181:2076 182:2461 183:817 184:899 185:11159 186:3272 187:2281 188:2596 189:1886 190:8150 191:1354 192:9692 193:5831 194:4735 195:3968 196:2191 197:1264 198:5534 199:5874 200:7220 201:4630 202:10331 203:9950 204:4520 205:2857 206:3010 207:3120 208:3967 209:3961 210:3932 211:2084 212:2856 213:2586 214:856 215:66 216:5723 217:2097 218:915 219:598 220:1672 221:941 222:722 223:1298 End of report From Jacques.Latour at cira.ca Fri Oct 20 20:36:44 2017 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Fri, 20 Oct 2017 20:36:44 +0000 Subject: Puerto Rico: Lack of electricity threatens telephone and internet services In-Reply-To: References: <7be29045-2f58-ad6f-890b-54f2f558499d@vaxination.ca> <20171019221806.GA87968@spider.typo.org> <658be549-1b22-652b-e813-c3031a41de35@vaxination.ca> Message-ID: Here's a fact, the next ICANN meeting in March is still a go in San Juan PR. Hopefully bringing 2000 people will have a positive impact on the local economy. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Todd > Underwood > Sent: October 19, 2017 7:56 PM > To: Jean-Francois Mezei > Cc: NANOG list > Subject: Re: Puerto Rico: Lack of electricity threatens telephone and internet > services > > This thread is mostly full of idle speculation, is at the least insensitive and > verges on offensive. > > If you have operational information about Puerto Rico (see Sean Donelan's > posts rather than these responses), please go ahead. If you would like to > allocate blame, please go somewhere else to do it. The Internet is full of > people who are blaming Puerto Rico for getting hit by a hurricane. I don't > need it here. > > Thanks, > > T > (From Humacao) > > El 19 oct. 2017 19:45, "Jean-Francois Mezei" > > escribió: > > On 2017-10-19 18:18, Wayne Bouchard wrote: > > Well, the problem as I understand it is that the infrastructure was > > not all that great to begin with. Much of it was damaged in the first > > storm and when this second one came through, what remained basically > > disappeared. > > > Being hit with a Cat 5 hurricane/cyclone in a caribeean island that hasn't > been a direct hit from severe storms in decades will cause extensive damage > no matter what state its infrastructure was in before. > > Vegetation that does not regular storms to "prune" it will grow to a point > where it will cause major damage when a big storm hits. > > And a caribbean island who has never been "rich" will not have had, as a > priority, increasing building codes to widthstand hurricanes. Building codes > get updated after a big devastating hurricane, whether it is for Darwin in > 1974 (Tracy) or ones like Andrew in Florida. > > It's easy for a state the size of Texas to send all of its electrical utility trucks > to the Houson area to repair damage. But they too would be stretched thin if > all of Texas had been leveled. > > If buildings were not built to widthstand a 5 or a 4, then the building itself > becomes destructor of infrastructure as its materials become high speed > projectiles throuwn at other buildings and especially teleohone/electrical > lines. > > I went through a category 4 (Olivia, Australia 1996). While the town and > building I was in (Karatha) were built to new standards and had little damage, > I witnessed the power of it, and I can totally understand Puerto Rico being > destroyed. > > I know a politician with tendancy to skew facts points to Puerto Rico having > had terrible infrastructure. But consider that Darwin, a "rich" > town" was wiped out in 1974 by Tracy. > > https://www.youtube.com/watch?v=B89wBGydSvs > > Tracy was a 4. Maria was a 5. > (note the alert sound at start of video still sends shivers down my spine > because it was the same as I heard before Olivia hit). > > The population was evacuated by 747s because there was nothing there to > support it. The road link to is (Stuart Highway) is so long that Darwin is > tantamount to an island. (especially since Stuart wasn't fully paved back > then). > > > Also note: in Florida, the utilities positioned all their equipment in safe places > so it could survive storm and be deployed when needed. But what happens > when there is no safe place, or the safe places become isolated because > roads become impassable? > > > It is one thing when a state has some areas with high level of destruction. > But when the whole state is destroyed, it is a truly different situation because > its economy is also destroyed. Florida Power still has plenty of revenues from > undamaged areas to pay for the repairs in damaged areas. The Utility in > Puerto Rico doesn't. (and if it was finacially weak before, it makes things > worse). > > When you see other states' utilities coming to help in a highly damaged area, > don't think for a minute they do this for free. The local utility stll gets a bill at > the end of the day for the work done. If the Puerto Rico company has no > cash to pay, don't exopect other utilities to send crews. From beecher at beecher.cc Fri Oct 20 21:31:33 2017 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 20 Oct 2017 17:31:33 -0400 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: <8389c2ce-a875-3578-f3e5-ab24818be4cd@vaxination.ca> References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> <1507929603.602724.1138184128.6C59596B@webmail.messagingengine.com> <8389c2ce-a875-3578-f3e5-ab24818be4cd@vaxination.ca> Message-ID: "But if provider 1 has its 1 fibre on the CN line and provider 2 has its 1 fibre along CP line (or road), then you can get diversity by getting bandwidth from both." That's not diversity. That's just a matter of time before the same backhoe catches them both. :) On Fri, Oct 13, 2017 at 6:00 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 2017-10-13 17:20, Clinton Work wrote: > > > > My understanding is that nobody has a 2nd diverse fiber route north of > > the great lakes from Winnipeg to Toronto. Every provider makes use of > > a fiber route south of the great lakes thru the US in order to provide > > diversity. > > But if provider 1 has its 1 fibre on the CN line and provider 2 has its > 1 fibre along CP line (or road), then you can get diversity by getting > bandwidth from both. > > > > The following map shows that the CN rail and CP Rail lines across over > > each other at multiple times from Winnipeg to Toronto. > > At Rennie MB, the CN line has a bridge over the CP line. Between Sudbury > and Toronto, you may have to live with the crossings. But I suspect they > are bridged too (with some interchange points near Sudbury). > > Ideally, there would be some link leftover from when there were tracks > between Ottawa and Sudbury. Tracks remain between Mattawa and Sudbury. > (Ottawa-Mattawa removed circa 2012). Bell Canada still wants to serve > those areas even if tracks no longer present. > > > > Note: road has interesting side effects. A new bridge on highway 17 > "broke" when it got too cold: the stay cables on suspension bridge > contracted and ended up lifting bridge deck by about 1m above ground > level. So any fibre conduits would have been severed as it crossed from > ground to bridge. > From jason+nanog at lixfeld.ca Sat Oct 21 14:00:37 2017 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Sat, 21 Oct 2017 10:00:37 -0400 Subject: Allstream/Zayo in the house? Message-ID: Having an issue where you’re caching announcements for my AS via a peering session that was turned down hours ago causing * * *, and my Saturday to suck :) Emails out to NOC/Peering contacts on peeringdb haven’t had a response yet. Hoping someone here can poke and/or prod. Thanks in advance. From jason+nanog at lixfeld.ca Sat Oct 21 20:38:20 2017 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Sat, 21 Oct 2017 16:38:20 -0400 Subject: Allstream/Zayo in the house? In-Reply-To: References: Message-ID: <28C9AC5D-1930-4593-8198-81ADF651391A@lixfeld.ca> Thanks for all the private responses. Contact made, and the issue has been resolved. Thank you all. > On Oct 21, 2017, at 10:00 AM, Jason Lixfeld wrote: > > Having an issue where you’re caching announcements for my AS via a peering session that was turned down hours ago causing * * *, and my Saturday to suck :) > > Emails out to NOC/Peering contacts on peeringdb haven’t had a response yet. Hoping someone here can poke and/or prod. > > Thanks in advance. From sean at donelan.com Sun Oct 22 00:29:39 2017 From: sean at donelan.com (Sean Donelan) Date: Sat, 21 Oct 2017 20:29:39 -0400 (EDT) Subject: Puerto Rico: Lack of electricity threatens telephone and internet services In-Reply-To: References: <7be29045-2f58-ad6f-890b-54f2f558499d@vaxination.ca> <20171019221806.GA87968@spider.typo.org> <658be549-1b22-652b-e813-c3031a41de35@vaxination.ca> Message-ID: Its too early for an after-action review. Nevertheless, this report by the Miami Herald is the best summary to date of the aftermath in Puerto Rico. Its solid journalism, covers the wide-span of the destruction, and gives credit and blame based on documented evidence. Its longer than a typical newspaper article. Nevertheless, worth the read. http://www.miamiherald.com/news/weather/hurricane/article179744081.html ‘Days were lost’: Why Puerto Rico is still suffering a month after Hurricane Maria BY PATRICIA MAZZEI AND OMAYA SOSA PASCUAL pmazzei at miamiherald.com Center for Investigative Journalism OCTOBER 19, 2017 2:17 PM Sosa Pascual reports for Puerto Rico’s Center for Investigative Journalism (CPI), which worked jointly with the Miami Herald on this report. McClatchy correspondent Tim Johnson contributed from Utuado, Puerto Rico. From damian at google.com Sun Oct 22 06:59:35 2017 From: damian at google.com (Damian Menscher) Date: Sat, 21 Oct 2017 23:59:35 -0700 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, Oct 20, 2017 at 6:29 AM, Filip Hruska wrote: > Would be great if makers of home routers would implement full recursive > DNS resolvers > instead of just forwards in their gear. Ignoring the latency impact of your proposal, I wonder what would happen to the world's authoritative servers if all users hit them directly rather than going through large recursive resolvers that do caching? I'm guessing it wouldn't be pretty. Damian From drc at virtualized.org Sun Oct 22 16:23:12 2017 From: drc at virtualized.org (David Conrad) Date: Sun, 22 Oct 2017 09:23:12 -0700 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> Message-ID: Damian, Pragmatically speaking, I strongly suspect the increase in valid queries to authoritative servers even if all “large recursive resolvers” went away would be lost in noise of the overcapacity necessary to deal with even a lower-end DDoS attack. Perhaps more interestingly, if said recursive resolvers on home routers would implement DNSSEC with RFC 8198 (and the owners of the authoritative zones would sign those zones), an entire class of DDoS attack would be mitigated. Further, if said recursive resolvers also implemented RFC 7706, latency to the root would be reduced and the risk of to the network behind that recursive resolver of a DDoS against the root of the DNS would be removed. Regards, -drc On Oct 22, 2017, 12:00 AM -0700, Damian Menscher via NANOG , wrote: > On Fri, Oct 20, 2017 at 6:29 AM, Filip Hruska wrote: > > > Would be great if makers of home routers would implement full recursive > > DNS resolvers > > instead of just forwards in their gear. > > > Ignoring the latency impact of your proposal, I wonder what would happen to > the world's authoritative servers if all users hit them directly rather > than going through large recursive resolvers that do caching? I'm guessing > it wouldn't be pretty. > > Damian From nanog at ics-il.net Sun Oct 22 18:35:50 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 22 Oct 2017 13:35:50 -0500 (CDT) Subject: AS-Path - ORF Draft Message-ID: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-13 Not knowing anything about the draft\RFC process (and not really wanting to go beyond a 30k foot view), is this something with movement? Traction? This would have solved a situation I encountered a week ago. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From job at instituut.net Sun Oct 22 22:29:33 2017 From: job at instituut.net (Job Snijders) Date: Mon, 23 Oct 2017 00:29:33 +0200 Subject: AS-Path - ORF Draft In-Reply-To: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> Message-ID: Hi Mike, On Sun, 22 Oct 2017 at 20:45, Mike Hammett wrote: > https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-13 > > Not knowing anything about the draft\RFC process (and not really wanting > to go beyond a 30k foot view), is this something with movement? Traction? > > This would have solved a situation I encountered a week ago. Can you describe the situation in more detail? Kind regards, Job From nanog at ics-il.net Sun Oct 22 22:37:52 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 22 Oct 2017 17:37:52 -0500 (CDT) Subject: AS-Path - ORF Draft In-Reply-To: References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> Message-ID: <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> Network A was sending more routes into the route server than Network B could handle. Network B would like Network A's routes filtered before they even got to their router. Googling a bit I saw pages talking about saving CPU or what have you, but the main thing was Network B has a limited FIB. They have a prefix limit specified to protect that. Their device goes through prefix limit before prefix filter, so their filters wouldn't even see the advertisements as the prefix limit already killed the session. Raise the prefix limit so that the filters can get to work and now you're vulnerable to someone else injecting a ton of routes and melting their router. If that draft were supported by Network B's router and the route servers, I believe that Network B could tell the route servers to filter Network A's prefixes before sending them, thus saving their FIB. Obviously the most correct answer is for Network A to get routers with big enough FIBs, but that's not always possible or practical. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Job Snijders" To: "Mike Hammett" , "NANOG" Sent: Sunday, October 22, 2017 5:29:33 PM Subject: Re: AS-Path - ORF Draft Hi Mike, On Sun, 22 Oct 2017 at 20:45, Mike Hammett < nanog at ics-il.net > wrote: https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-13 Not knowing anything about the draft\RFC process (and not really wanting to go beyond a 30k foot view), is this something with movement? Traction? This would have solved a situation I encountered a week ago.
Can you describe the situation in more detail? Kind regards, Job From baldur.norddahl at gmail.com Sun Oct 22 22:53:48 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 23 Oct 2017 00:53:48 +0200 Subject: AS-Path - ORF Draft In-Reply-To: <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> Message-ID: I do not get why every BGP implementation kills the session at the prefix limit. It appears that is making a bad situation worse. Routing flaps creating lots of visible disturbance for end users. When the BGP session restarts, it will just happen again and again until operator intervention. Instead an implementation could ignore any additional prefixes or it could compare each additional prefix received to already learned prefixes and decide to drop one to make room for the new one. For example you could drop the most specific routes before less specific routes. Regards Baldur Den 23. okt. 2017 00.38 skrev "Mike Hammett" : > Network A was sending more routes into the route server than Network B > could handle. Network B would like Network A's routes filtered before they > even got to their router. > > Googling a bit I saw pages talking about saving CPU or what have you, but > the main thing was Network B has a limited FIB. They have a prefix limit > specified to protect that. Their device goes through prefix limit before > prefix filter, so their filters wouldn't even see the advertisements as the > prefix limit already killed the session. Raise the prefix limit so that the > filters can get to work and now you're vulnerable to someone else injecting > a ton of routes and melting their router. > > If that draft were supported by Network B's router and the route servers, > I believe that Network B could tell the route servers to filter Network A's > prefixes before sending them, thus saving their FIB. > > Obviously the most correct answer is for Network A to get routers with big > enough FIBs, but that's not always possible or practical. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Job Snijders" > To: "Mike Hammett" , "NANOG" > Sent: Sunday, October 22, 2017 5:29:33 PM > Subject: Re: AS-Path - ORF Draft > > > > > > Hi Mike, > > > On Sun, 22 Oct 2017 at 20:45, Mike Hammett < nanog at ics-il.net > wrote: > > > https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-13 > > Not knowing anything about the draft\RFC process (and not really wanting > to go beyond a 30k foot view), is this something with movement? Traction? > > This would have solved a situation I encountered a week ago. > > >
> >
> > > > > > Can you describe the situation in more detail? > > > > Kind regards, > > > Job > From nanog at ics-il.net Sun Oct 22 22:57:34 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 22 Oct 2017 17:57:34 -0500 (CDT) Subject: AS-Path - ORF Draft In-Reply-To: References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> Message-ID: <61258985.467.1508713051713.JavaMail.mhammett@ThunderFuck> In my situation, if it applied the filter before the limit, everything would work fine. Maybe the thought is the other peer has some runaway issue that you don't want to spend resources dealing with instead of grooming an otherwise normal condition? *shrugs* ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Sunday, October 22, 2017 5:53:48 PM Subject: Re: AS-Path - ORF Draft I do not get why every BGP implementation kills the session at the prefix limit. It appears that is making a bad situation worse. Routing flaps creating lots of visible disturbance for end users. When the BGP session restarts, it will just happen again and again until operator intervention. Instead an implementation could ignore any additional prefixes or it could compare each additional prefix received to already learned prefixes and decide to drop one to make room for the new one. For example you could drop the most specific routes before less specific routes. Regards Baldur Den 23. okt. 2017 00.38 skrev "Mike Hammett" : > Network A was sending more routes into the route server than Network B > could handle. Network B would like Network A's routes filtered before they > even got to their router. > > Googling a bit I saw pages talking about saving CPU or what have you, but > the main thing was Network B has a limited FIB. They have a prefix limit > specified to protect that. Their device goes through prefix limit before > prefix filter, so their filters wouldn't even see the advertisements as the > prefix limit already killed the session. Raise the prefix limit so that the > filters can get to work and now you're vulnerable to someone else injecting > a ton of routes and melting their router. > > If that draft were supported by Network B's router and the route servers, > I believe that Network B could tell the route servers to filter Network A's > prefixes before sending them, thus saving their FIB. > > Obviously the most correct answer is for Network A to get routers with big > enough FIBs, but that's not always possible or practical. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Job Snijders" > To: "Mike Hammett" , "NANOG" > Sent: Sunday, October 22, 2017 5:29:33 PM > Subject: Re: AS-Path - ORF Draft > > > > > > Hi Mike, > > > On Sun, 22 Oct 2017 at 20:45, Mike Hammett < nanog at ics-il.net > wrote: > > > https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-13 > > Not knowing anything about the draft\RFC process (and not really wanting > to go beyond a 30k foot view), is this something with movement? Traction? > > This would have solved a situation I encountered a week ago. > > > > > > > > > > > Can you describe the situation in more detail? > > > > Kind regards, > > > Job > From marka at isc.org Mon Oct 23 00:02:28 2017 From: marka at isc.org (Mark Andrews) Date: Mon, 23 Oct 2017 11:02:28 +1100 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: Your message of "Fri, 20 Oct 2017 17:31:33 -0400." References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> <1507929603.602724.1138184128.6C59596B@webmail.messagingengine.com> <8389c2ce-a875-3578-f3e5-ab24818be4cd@vaxination.ca> Message-ID: <20171023000228.148C58C73749@rock.dv.isc.org> In message , Tom Beecher writes: > "But if provider 1 has its 1 fibre on the CN line and provider 2 has its > 1 fibre along CP line (or road), then you can get diversity by getting > bandwidth from both." > > That's not diversity. That's just a matter of time before the same backhoe > catches them both. :) It depends on how the lines "cross" each other. Two tunnels and you have physical seperation. Crossing at the same level then you don't. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From job at ntt.net Mon Oct 23 05:36:24 2017 From: job at ntt.net (Job Snijders) Date: Mon, 23 Oct 2017 07:36:24 +0200 Subject: AS-Path - ORF Draft In-Reply-To: <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> Message-ID: <20171023053624.GB96229@Vurt.local> On Sun, Oct 22, 2017 at 05:37:52PM -0500, Mike Hammett wrote: > Network A was sending more routes into the route server than Network B > could handle. Network B would like Network A's routes filtered before > they even got to their router. > > Googling a bit I saw pages talking about saving CPU or what have you, > but the main thing was Network B has a limited FIB. They have a prefix > limit specified to protect that. Their device goes through prefix > limit before prefix filter, so their filters wouldn't even see the > advertisements as the prefix limit already killed the session. Raise > the prefix limit so that the filters can get to work and now you're > vulnerable to someone else injecting a ton of routes and melting their > router. > > If that draft were supported by Network B's router and the route > servers, I believe that Network B could tell the route servers to > filter Network A's prefixes before sending them, thus saving their > FIB. Your interpretation of the functionality described in the draft is correct. Work on this draft started in december 2000 as can be read here: https://tools.ietf.org/html/draft-keyur-bgp-aspath-orf. I am not aware of any implementations, and having read the draft and observing there are no IANA codepoint assignments yet, it is very unlikely there are any implementations available for production use. Generally speaking it is safe to say that 17 year old Internet-Drafts (without known implementations) may be lacking the required traction to become a RFC. So alternatively, network B can tell the route server operator via email "do not send me these prefixes", and the route server operator in the middle honors that request and doesn't send those prefixes to network B. Some IXP's offer a webportal for this type of functionality, other IXPs allow signaling via RPSL in the IRR or as mentioned before, email. > Obviously the most correct answer is for Network A to get routers with > big enough FIBs, but that's not always possible or practical. s/Network A/Network B/ - Yes, this can be a challenge. I fear that bgp-aspath-orf won't be of any help in the short term. Kind regards, Job From job at ntt.net Mon Oct 23 06:35:42 2017 From: job at ntt.net (Job Snijders) Date: Mon, 23 Oct 2017 08:35:42 +0200 Subject: AS-Path - ORF Draft In-Reply-To: References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> Message-ID: <20171023063542.GC96229@Vurt.local> Dear Baldur, On Mon, Oct 23, 2017 at 12:53:48AM +0200, Baldur Norddahl wrote: > I do not get why every BGP implementation kills the session at the > prefix limit. It appears that is making a bad situation worse. Routing > flaps creating lots of visible disturbance for end users. When the BGP > session restarts, it will just happen again and again until operator > intervention. Maximum prefix limits are used as a naive last resort to attempt to protect against catastrophic failures such as memory/fib overflow and full table route leaks. The moment a maximum prefix limit kicks in, something somewhere went wrong and indeed an operator has to intervene. That is the beauty and essence of the maxpfx feature. :) > Instead an implementation could ignore any additional prefixes This may work in some specific cases, but can be disastrous in other cases. In my opinion, in context of Internet routing, the potential for disaster outweighs any benefits I can see for "ignoring additional prefixes" (in L3VPN context different considerations may apply). You offered "killing a session may make a bad situation worse", but there are of scenarios where keeping the session up can make a bad situation into a diaster. I'll elaborate on the above with an example to hopefully clarify myself. Let's take this event and hypothetically assume 'soft maximum prefix limits' are a commonly deployed thing. https://bgpmon.net/bgp-leak-causing-internet-outages-in-japan-and-beyond/ According to PeeringDB AS 15169 recommends to configure 15,000 as the maximum prefix limit for IPv4. (https://www.peeringdb.com/asn/15169) Let's assume that Verizon had configured "a maximum of 15,000 but keep the BGP session up"-style of soft limit. I currently see roughly 419 prefixes via AS15169 in the DFZ. 15000 - 419 = 14581, so this leaves room for 14581 invalid announcements before the softlimit is kicks in. At that point I'd argue that it is better to just tear down the BGP session rather than create a situation where 14581 invalid announcements (which are part of a 160,000 prefix route leak) can continue to exist. We could go back and forth a bit on how high or low that '15,000' number should be and how things would look if it was closer to 500. But in the end actual operator intervention was needed, and soft maxprefix limits would have the potential to hide that. > or it could compare each additional prefix received to already learned > prefixes and decide to drop one to make room for the new one. For > example you could drop the most specific routes before less specific > routes. The moment a BGP implementation can do such RIB compression, it may indeed make sense to offer two types of limits: a 'pre-policy maximum prefix limit' and a 'post-policy maximum prefix limit'. The former type of limit would be useful in context of route leaks, the latter in context of protecting against overflow of the FIB capability. Kind regards, Job ps. RPKI Origin Validation and BGPSEC do have the potential to change the way we look at big hammers like maximum prefix limits, but we're not there yet. From job at ntt.net Mon Oct 23 10:37:13 2017 From: job at ntt.net (Job Snijders) Date: Mon, 23 Oct 2017 12:37:13 +0200 Subject: AS-Path - ORF Draft In-Reply-To: <20171023063542.GC96229@Vurt.local> References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> <20171023063542.GC96229@Vurt.local> Message-ID: <20171023103713.GH96229@Vurt.local> On Mon, Oct 23, 2017 at 08:35:42AM +0200, Job Snijders wrote: > > or it could compare each additional prefix received to already learned > > prefixes and decide to drop one to make room for the new one. For > > example you could drop the most specific routes before less specific > > routes. > > The moment a BGP implementation can do such RIB compression, it may > indeed make sense to offer two types of limits: a 'pre-policy maximum > prefix limit' and a 'post-policy maximum prefix limit'. The former type > of limit would be useful in context of route leaks, the latter in > context of protecting against overflow of the FIB capability. Apparently this already exists and is widely available, Saku Ytti gave me some additional information. There are various keywords available, and they operate at different attachment points in the conceptual model. | IOS XR | Junos =============================================================== pre-policy keyword | ???? | prefix-limit --------------------+------------------+------------------------ post-policy keyword | maximum-prefix | accepted-prefix-limit (????? means the keyword does not exist) Now I wonder what Arista EOS, Nokia SR-OS, etc offer in this regard. :-) (screenshot here http://instituut.net/~job/screenshots/baf76f9c29a31d2e55454ddd.png for those of you who can't easily view ASCII tables) Kind regards, Job From ghankins at mindspring.com Mon Oct 23 10:57:19 2017 From: ghankins at mindspring.com (Greg Hankins) Date: Mon, 23 Oct 2017 06:57:19 -0400 Subject: AS-Path - ORF Draft In-Reply-To: <20171023103713.GH96229@Vurt.local> References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> <20171023063542.GC96229@Vurt.local> <20171023103713.GH96229@Vurt.local> Message-ID: <20171023105719.GH27694@nokia.com> Nokia SR OS defaults to pre-policy but can be configured to post-policy by adding "post-import". prefix-limit ipv4 100 // pre-policy prefix-limit ipv6 100 post-import // post-policy Greg -- Greg Hankins -----Original Message----- Date: Mon, 23 Oct 2017 12:37:13 +0200 From: Job Snijders To: nanog at nanog.org Subject: Re: AS-Path - ORF Draft On Mon, Oct 23, 2017 at 08:35:42AM +0200, Job Snijders wrote: > > or it could compare each additional prefix received to already learned > > prefixes and decide to drop one to make room for the new one. For > > example you could drop the most specific routes before less specific > > routes. > > The moment a BGP implementation can do such RIB compression, it may > indeed make sense to offer two types of limits: a 'pre-policy maximum > prefix limit' and a 'post-policy maximum prefix limit'. The former type > of limit would be useful in context of route leaks, the latter in > context of protecting against overflow of the FIB capability. Apparently this already exists and is widely available, Saku Ytti gave me some additional information. There are various keywords available, and they operate at different attachment points in the conceptual model. | IOS XR | Junos =============================================================== pre-policy keyword | ???? | prefix-limit --------------------+------------------+------------------------ post-policy keyword | maximum-prefix | accepted-prefix-limit (????? means the keyword does not exist) Now I wonder what Arista EOS, Nokia SR-OS, etc offer in this regard. :-) (screenshot here http://instituut.net/~job/screenshots/baf76f9c29a31d2e55454ddd.png for those of you who can't easily view ASCII tables) Kind regards, Job From nanog at ics-il.net Mon Oct 23 12:53:03 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 23 Oct 2017 07:53:03 -0500 (CDT) Subject: AS-Path - ORF Draft In-Reply-To: <20171023053624.GB96229@Vurt.local> References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> <20171023053624.GB96229@Vurt.local> Message-ID: <1080703758.747.1508763182378.JavaMail.mhammett@ThunderFuck> Should I assume that invigorating traction for a 17 year old draft is rather difficult? It is my understanding that Network B does wish to accept Network A's prefixes elsewhere, just not here. I believe that specifying the block via IRR would be universal and probably not wanted. Some of my fellow IX operators have advised me to avoid doing manual filtering for a variety of reasons. Which IXes have a web portal for that? Offlist is fine. I'd like to see that and talk to them about their implementation. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Job Snijders" To: "Mike Hammett" Cc: "NANOG" Sent: Monday, October 23, 2017 12:36:24 AM Subject: Re: AS-Path - ORF Draft On Sun, Oct 22, 2017 at 05:37:52PM -0500, Mike Hammett wrote: > Network A was sending more routes into the route server than Network B > could handle. Network B would like Network A's routes filtered before > they even got to their router. > > Googling a bit I saw pages talking about saving CPU or what have you, > but the main thing was Network B has a limited FIB. They have a prefix > limit specified to protect that. Their device goes through prefix > limit before prefix filter, so their filters wouldn't even see the > advertisements as the prefix limit already killed the session. Raise > the prefix limit so that the filters can get to work and now you're > vulnerable to someone else injecting a ton of routes and melting their > router. > > If that draft were supported by Network B's router and the route > servers, I believe that Network B could tell the route servers to > filter Network A's prefixes before sending them, thus saving their > FIB. Your interpretation of the functionality described in the draft is correct. Work on this draft started in december 2000 as can be read here: https://tools.ietf.org/html/draft-keyur-bgp-aspath-orf. I am not aware of any implementations, and having read the draft and observing there are no IANA codepoint assignments yet, it is very unlikely there are any implementations available for production use. Generally speaking it is safe to say that 17 year old Internet-Drafts (without known implementations) may be lacking the required traction to become a RFC. So alternatively, network B can tell the route server operator via email "do not send me these prefixes", and the route server operator in the middle honors that request and doesn't send those prefixes to network B. Some IXP's offer a webportal for this type of functionality, other IXPs allow signaling via RPSL in the IRR or as mentioned before, email. > Obviously the most correct answer is for Network A to get routers with > big enough FIBs, but that's not always possible or practical. s/Network A/Network B/ - Yes, this can be a challenge. I fear that bgp-aspath-orf won't be of any help in the short term. Kind regards, Job From job at ntt.net Mon Oct 23 13:24:51 2017 From: job at ntt.net (Job Snijders) Date: Mon, 23 Oct 2017 15:24:51 +0200 Subject: AS-Path - ORF Draft In-Reply-To: <1080703758.747.1508763182378.JavaMail.mhammett@ThunderFuck> References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> <20171023053624.GB96229@Vurt.local> <1080703758.747.1508763182378.JavaMail.mhammett@ThunderFuck> Message-ID: <20171023132451.GK96229@Vurt.local> On Mon, Oct 23, 2017 at 07:53:03AM -0500, Mike Hammett wrote: > Should I assume that invigorating traction for a 17 year old draft is > rather difficult? John Heasley told me that a fundamental difficulty here is that not every implementation uses the same style/type of regular expressions. Unifying this behaviour across vendors will require a lot of pull. > It is my understanding that Network B does wish to accept Network A's > prefixes elsewhere, just not here. I believe that specifying the block > via IRR would be universal and probably not wanted. You can make it IX specific by using an old proposal called 'RPSL VIA'. Look for "The script supports most of the IETF snijders-rpsl-via draft extensions": https://ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers > Some of my fellow IX operators have advised me to avoid doing manual > filtering for a variety of reasons. Yes, they are right. The moment the route server operator introduces hacks like that, the affected participants may forget those hacks existed over time. On the flip side, if Network B can't filter out the announcements, or insists on using a pre-policy maximum prefix limit - and Network A refuses to add a suppression community to their announcements to the route server (maybe because they want to cookie stamp all those configs), what can you (as person in the middle) do? If both network A and network B refuse to cooperate / coordinate, it somewhat dilutes the value of the route server to participants C/D/E because network B keeps flapping. > Which IXes have a web portal for that? Offlist is fine. I'd like to > see that and talk to them about their implementation. I believe NL-IX (https://nl-ix.net/) and VIX (https://www.vix.at) are example IXPs that have this. There are probably a bunch more that offer this type of feature. Kind regards, Job From nanog at ics-il.net Mon Oct 23 14:56:43 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 23 Oct 2017 09:56:43 -0500 (CDT) Subject: AS-Path - ORF Draft In-Reply-To: <20171023132451.GK96229@Vurt.local> References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> <20171023053624.GB96229@Vurt.local> <1080703758.747.1508763182378.JavaMail.mhammett@ThunderFuck> <20171023132451.GK96229@Vurt.local> Message-ID: <1416333369.891.1508770599495.JavaMail.mhammett@ThunderFuck> I was looking at using arouteserver to automate my prefix filter generation. I'll do a feature request over there. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Job Snijders" To: "Mike Hammett" Cc: "NANOG" Sent: Monday, October 23, 2017 8:24:51 AM Subject: Re: AS-Path - ORF Draft On Mon, Oct 23, 2017 at 07:53:03AM -0500, Mike Hammett wrote: > Should I assume that invigorating traction for a 17 year old draft is > rather difficult? John Heasley told me that a fundamental difficulty here is that not every implementation uses the same style/type of regular expressions. Unifying this behaviour across vendors will require a lot of pull. > It is my understanding that Network B does wish to accept Network A's > prefixes elsewhere, just not here. I believe that specifying the block > via IRR would be universal and probably not wanted. You can make it IX specific by using an old proposal called 'RPSL VIA'. Look for "The script supports most of the IETF snijders-rpsl-via draft extensions": https://ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers > Some of my fellow IX operators have advised me to avoid doing manual > filtering for a variety of reasons. Yes, they are right. The moment the route server operator introduces hacks like that, the affected participants may forget those hacks existed over time. On the flip side, if Network B can't filter out the announcements, or insists on using a pre-policy maximum prefix limit - and Network A refuses to add a suppression community to their announcements to the route server (maybe because they want to cookie stamp all those configs), what can you (as person in the middle) do? If both network A and network B refuse to cooperate / coordinate, it somewhat dilutes the value of the route server to participants C/D/E because network B keeps flapping. > Which IXes have a web portal for that? Offlist is fine. I'd like to > see that and talk to them about their implementation. I believe NL-IX (https://nl-ix.net/) and VIX (https://www.vix.at) are example IXPs that have this. There are probably a bunch more that offer this type of feature. Kind regards, Job From job at ntt.net Mon Oct 23 15:11:13 2017 From: job at ntt.net (Job Snijders) Date: Mon, 23 Oct 2017 15:11:13 +0000 Subject: AS-Path - ORF Draft In-Reply-To: <1416333369.891.1508770599495.JavaMail.mhammett@ThunderFuck> References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> <20171023053624.GB96229@Vurt.local> <1080703758.747.1508763182378.JavaMail.mhammett@ThunderFuck> <20171023132451.GK96229@Vurt.local> <1416333369.891.1508770599495.JavaMail.mhammett@ThunderFuck> Message-ID: On Mon, 23 Oct 2017 at 16:57, Mike Hammett wrote: > I was looking at using arouteserver to automate my prefix filter > generation. Excellent choice. I would happily recommend arouteserver to any internet exchange operator looking to modernize their route servers. I'll do a feature request over there. > Great news! You can already do that in arouteserver: http://arouteserver.readthedocs.io/en/latest/CONFIG.html#bird-hooks Kind regards, Job From nanog at ics-il.net Mon Oct 23 15:13:15 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 23 Oct 2017 10:13:15 -0500 (CDT) Subject: AS-Path - ORF Draft In-Reply-To: References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> <20171023053624.GB96229@Vurt.local> <1080703758.747.1508763182378.JavaMail.mhammett@ThunderFuck> <20171023132451.GK96229@Vurt.local> <1416333369.891.1508770599495.JavaMail.mhammett@ThunderFuck> Message-ID: <2106470660.919.1508771591850.JavaMail.mhammett@ThunderFuck> > Great news! You can already do that in arouteserver: http://arouteserver.readthedocs.io/en/latest/CONFIG.html#bird-hooks If you're using Bird. ;-) We're using OpenBGPd. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From job at ntt.net Mon Oct 23 16:08:09 2017 From: job at ntt.net (Job Snijders) Date: Mon, 23 Oct 2017 18:08:09 +0200 Subject: AS-Path - ORF Draft In-Reply-To: <2106470660.919.1508771591850.JavaMail.mhammett@ThunderFuck> References: <1738791269.215.1508697337981.JavaMail.mhammett@ThunderFuck> <1977726038.455.1508711867226.JavaMail.mhammett@ThunderFuck> <20171023053624.GB96229@Vurt.local> <1080703758.747.1508763182378.JavaMail.mhammett@ThunderFuck> <20171023132451.GK96229@Vurt.local> <1416333369.891.1508770599495.JavaMail.mhammett@ThunderFuck> <2106470660.919.1508771591850.JavaMail.mhammett@ThunderFuck> Message-ID: <20171023160809.GN96229@Vurt.local> On Mon, Oct 23, 2017 at 10:13:15AM -0500, Mike Hammett wrote: > > Great news! You can already do that in arouteserver: http://arouteserver.readthedocs.io/en/latest/CONFIG.html > > If you're using Bird. ;-) We're using OpenBGPd. I enjoy using both BIRD and OpenBGPD. Please look more closely. Look for the string 'openbgpd' on that page. The attachment points for BIRD and OpenBGPD are different, but arouteserver supports hooking in manual config for both BIRD and OpenBGPD. YYCIX, ofcourse based on OpenBGPD :-), is successfully documenting manual overrides in a 'pre-filters' file. You'll want to do the same. Kind regards, Job From hxiao at dargasea.com Fri Oct 20 21:27:38 2017 From: hxiao at dargasea.com (Tianhao Xiao) Date: Fri, 20 Oct 2017 14:27:38 -0700 Subject: Chinese websites loading slower recently? In-Reply-To: <20171020155112.GX15390@dilbert.slimey.org> References: <20171020155112.GX15390@dilbert.slimey.org> Message-ID: <1508534858.3960426.1145860888.162AA544@webmail.messagingengine.com> Hi Simon, The National Congress[0] just happened, and the Chinese government does make a very big deal out of it. I know that many universities were asked to temporarily block inbound HTTP traffic, which even affected open source mirrors during that time. With all this going on it is only natural that something restrictive happened to the rest of the international network. I'm not exactly sure what has been done, but it is very likely that it is not your problem. [0]https://en.wikipedia.org/wiki/19th_National_Congress_of_the_Communist_Party_of_China -- Tianhao Xiao hxiao at dargasea.com On Fri, 20 Oct 2017, at 08:51, Simon Lockhart wrote: > All, > > I know that access to Chinese websites from outside China is notorious > for > being slow or broken, but we seem to have had a major increase in support > calls from our users over the last couple of weeks, complaining of slow > or > no access to major Chinese websites, such as www.baidu.com, www.youku.com > and > world.taobao.com. > > We can't find anything on our network that would be affecting this, and > at > various times can (and cannot!) reproduce it with off-net connections, > which > would indicate that it's an intermittent, but widespread issue. > > Is anyone else seeing an increase in problems related to Chinese > websites? > > Thanks in advance, > > Simon From howard at leadmon.net Sat Oct 21 18:31:05 2017 From: howard at leadmon.net (Howard Leadmon) Date: Sat, 21 Oct 2017 14:31:05 -0400 Subject: Allstream/Zayo in the house? In-Reply-To: References: Message-ID: <98a906b6-aae8-ed3f-7423-fb0acda4ee6f@leadmon.net>  If you haven't, make sure you also drop a note to ipncc at zayo.com as that is their IP specific network center.   Not sure it will help, but it sure can't hurt.. --- Howard Leadmon PBW Communications, LLC http://www.pbwcomm.com On 10/21/2017 10:00 AM, Jason Lixfeld wrote: > Having an issue where you’re caching announcements for my AS via a peering session that was turned down hours ago causing * * *, and my Saturday to suck :) > > Emails out to NOC/Peering contacts on peeringdb haven’t had a response yet. Hoping someone here can poke and/or prod. > > Thanks in advance. From olivier.benghozi at wifirst.fr Mon Oct 23 18:18:32 2017 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Mon, 23 Oct 2017 20:18:32 +0200 Subject: Chinese websites loading slower recently? In-Reply-To: <1508534858.3960426.1145860888.162AA544@webmail.messagingengine.com> References: <20171020155112.GX15390@dilbert.slimey.org> <1508534858.3960426.1145860888.162AA544@webmail.messagingengine.com> Message-ID: I can confirm, several customers complaining of being suddenly unable to access baidu/weibo and so on Same conclusion ensues. > On 20 oct. 2017 at 23:27, Tianhao Xiao wrote : > > The National Congress[0] just happened, and the Chinese government does > make a very big deal out of it. I know that many universities were asked > to temporarily block inbound HTTP traffic, which even affected open > source mirrors during that time. > > With all this going on it is only natural that something restrictive > happened to the rest of the international network. I'm not exactly sure > what has been done, but it is very likely that it is not your problem. > > > On Fri, 20 Oct 2017, at 08:51, Simon Lockhart wrote: >> >> Is anyone else seeing an increase in problems related to Chinese >> websites? From jheitz at cisco.com Mon Oct 23 18:24:27 2017 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Mon, 23 Oct 2017 18:24:27 +0000 Subject: AS-Path - ORF Draft Message-ID: <5c0ea5399aa94cd68c678c6b11c52759@XCH-ALN-014.cisco.com> IOS-XR does not have a pre-policy prefix limit. When the limit is reached, the session will not automatically re-establish. It needs to be manually cleared first. It has the extra options: warning-only - does not drop the session. discard-extra-paths - additionally, drops prefixes after the limit is reached. restart - automatically re-establish the session after the timeout. I agree with Job that the use of warning-only can lead to unexpected routing, because there is no control over which prefixes are dropped. This is a big hammer that only comes down when the other hammers don't work. Thanks, Jakob. ------------------------------ Date: Mon, 23 Oct 2017 06:57:19 -0400 From: Greg Hankins To: Job Snijders Cc: nanog at nanog.org Subject: Re: AS-Path - ORF Draft Message-ID: <20171023105719.GH27694 at nokia.com> Content-Type: text/plain; charset=us-ascii Nokia SR OS defaults to pre-policy but can be configured to post-policy by adding "post-import". prefix-limit ipv4 100 // pre-policy prefix-limit ipv6 100 post-import // post-policy Greg -- Greg Hankins -----Original Message----- Date: Mon, 23 Oct 2017 12:37:13 +0200 From: Job Snijders To: nanog at nanog.org Subject: Re: AS-Path - ORF Draft On Mon, Oct 23, 2017 at 08:35:42AM +0200, Job Snijders wrote: > > or it could compare each additional prefix received to already learned > > prefixes and decide to drop one to make room for the new one. For > > example you could drop the most specific routes before less specific > > routes. > > The moment a BGP implementation can do such RIB compression, it may > indeed make sense to offer two types of limits: a 'pre-policy maximum > prefix limit' and a 'post-policy maximum prefix limit'. The former type > of limit would be useful in context of route leaks, the latter in > context of protecting against overflow of the FIB capability. Apparently this already exists and is widely available, Saku Ytti gave me some additional information. There are various keywords available, and they operate at different attachment points in the conceptual model. | IOS XR | Junos =============================================================== pre-policy keyword | ???? | prefix-limit --------------------+------------------+------------------------ post-policy keyword | maximum-prefix | accepted-prefix-limit (????? means the keyword does not exist) Now I wonder what Arista EOS, Nokia SR-OS, etc offer in this regard. :-) (screenshot here http://instituut.net/~job/screenshots/baf76f9c29a31d2e55454ddd.png for those of you who can't easily view ASCII tables) Kind regards, Job From mjo at dojo.mi.org Mon Oct 23 21:39:44 2017 From: mjo at dojo.mi.org (Mike O'Connor) Date: Mon, 23 Oct 2017 17:39:44 -0400 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> References: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> Message-ID: <20171023213944.imjn6tlhjdwsn5mf@dojo.mi.org> :I know it doesn't help your problem, but friends don't let friends use public DNS resolvers (Google, L3, Open DNS, etc.). ;-) I've been experimenting with using Google's DNS resolvers for Google's assorted domains. At some point, I keep meaning to add Google's address space as in-addr.arpa domains, but just haven't gotten there yet. Why? Just curious, that's all. Thus far, I haven't really noted any major differences, but wasn't sure what to expect. Maybe something would be notably faster/slower, maybe different results/ads/whatever, I dunno. It just seemed reasonable to punt Google DNS to Google DNS and see how things work. YMMV, void where prohibited. ~Mike -- Michael J. O'Connor mjo at dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "If you have enough plutonium, everything starts looking like a city." -Ches -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mark.tinka at seacom.mu Tue Oct 24 03:57:49 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 24 Oct 2017 05:57:49 +0200 Subject: Fwd: [apops] APRICOT 2018 Call for Presentations In-Reply-To: <0c399e07-baf5-8da4-775c-54bb86a5877a@gmail.com> References: <0c399e07-baf5-8da4-775c-54bb86a5877a@gmail.com> Message-ID: <63a25b66-d182-d66f-b399-4240dd77c313@seacom.mu> Greetings - FYI. Mark. -------- Forwarded Message -------- Subject: [apops] APRICOT 2018 Call for Presentations Date: Thu, 12 Oct 2017 20:27:00 +1000 From: Philip Smith To: apops at apops.net Hi everyone, The call for presentations for APRICOT 2018 has now been published - a copy is below FYI. philip -- Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 25th - 28th February 2018, Kathmandu, Nepal https://2018.apricot.net CALL FOR PAPERS =============== The APRICOT 2018 Programme Committee is now seeking contributions for Presentations and Tutorials for the APRICOT 2018 Conference. We are looking for presenters who would: - Offer a technical tutorial on an appropriate topic; - Participate in the technical conference sessions as a speaker; - Convene and chair panel sessions of relevant topics. Please submit on-line at: http://papers.apricot.net/user/login.php?event=63 CONFERENCE MILESTONES --------------------- Call for Papers Opens: Now Draft Program Published: As Papers Confirmed Final Deadline for Submissions: 26 January 2018 Final Program Published: 2 February 2018 Final Slides Received: 16 February 2018 *NOTE THAT REGARDLESS OF DEADLINES, SLOTS ARE FILLED ON A FIRST COME, FIRST SERVED BASIS* PROGRAMME MATERIAL ------------------ The APRICOT Conference Programme consists of three parts, these being the Peering Forum, Tutorials, and Conference Tracks. Topics proposed must be relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and Operations - IPv6 deployment and transition technologies - Internet backbone operations - ISP and Carrier services - IXPs and Peering - Research on Internet Operations and Deployment - Software Defined Networking / Network Function Virtualisaton - Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware) - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including Cable/DSL, LTE/5G, wireless, metro ethernet, fibre, segment routing - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) and Cloud Computing CfP SUBMISSION -------------- 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 APRICOT 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. Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka, Jonny Martin & Philip Smith Co-Chairs, APRICOT 2018 Programme Committee -- _______________________________________________ apops mailing list apops at apops.net https://mailman.apnic.net/mailman/listinfo/apops Website: www.apops.net . From aaron1 at gvtc.com Tue Oct 24 14:56:40 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 24 Oct 2017 09:56:40 -0500 Subject: facebook fna Message-ID: <000001d34cd8$4c9e8360$e5db8a20$@gvtc.com> How long is typical for the newly installed fna server cache to stay in "testing" phase before moving to "in production" ? I've been watching ~100 mbps sustained towards mine since 6 p.m. last night and it's in "testing" mode according to the fna partner portal. .so I'm looking forward to it moving to production and wanted to know how long does it usually take? -Aaron From edugas at unknowndevice.ca Tue Oct 24 15:01:05 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 24 Oct 2017 11:01:05 -0400 Subject: facebook fna In-Reply-To: <000001d34cd8$4c9e8360$e5db8a20$@gvtc.com> References: <000001d34cd8$4c9e8360$e5db8a20$@gvtc.com> Message-ID: It takes a couple of days before it ramps up. Pretty sure it's all covered in the docs on the partner portal. On 24 October 2017 at 10:56, Aaron Gould wrote: > How long is typical for the newly installed fna server cache to stay in > "testing" phase before moving to "in production" ? I've been watching ~100 > mbps sustained towards mine since 6 p.m. last night and it's in "testing" > mode according to the fna partner portal. .so I'm looking forward to it > moving to production and wanted to know how long does it usually take? > > > > > > -Aaron > > From aaron1 at gvtc.com Tue Oct 24 15:41:23 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 24 Oct 2017 10:41:23 -0500 Subject: facebook fna In-Reply-To: References: <000001d34cd8$4c9e8360$e5db8a20$@gvtc.com> Message-ID: <001501d34cde$8be5cbe0$a3b163a0$@gvtc.com> Thanks. Btw, I looked through the ~50 page fb net appiance deplymnt install and op guide and didn’t see where it speaks to that exact question. -Aaron From: Eric Dugas [mailto:edugas at unknowndevice.ca] Sent: Tuesday, October 24, 2017 10:01 AM To: Aaron Gould Cc: NANOG Subject: Re: facebook fna It takes a couple of days before it ramps up. Pretty sure it's all covered in the docs on the partner portal. On 24 October 2017 at 10:56, Aaron Gould wrote: How long is typical for the newly installed fna server cache to stay in "testing" phase before moving to "in production" ? I've been watching ~100 mbps sustained towards mine since 6 p.m. last night and it's in "testing" mode according to the fna partner portal. .so I'm looking forward to it moving to production and wanted to know how long does it usually take? -Aaron From jheitz at cisco.com Tue Oct 24 15:49:20 2017 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Tue, 24 Oct 2017 15:49:20 +0000 Subject: AS-Path - ORF Draft In-Reply-To: References: Message-ID: <4AC9E674-B49C-4CA6-BA41-704622AA3C73@cisco.com> Even though the limit is applied before policy, the dropped prefixes don't count towards the limit. You can have a limit of 100 and receive 1000. If you drop 901 post policy, it will not kill the session, even when the limit is applied before policy. Thanks, Jakob. > Date: Sun, 22 Oct 2017 17:37:52 -0500 (CDT) > From: Mike Hammett > Their device goes through prefix limit before prefix filter, so their filters wouldn't even see the advertisements as the prefix limit already killed the session. Raise the prefix limit so that the filters can get to work and now you're vulnerable to someone else injecting a ton of routes and melting their router. > From javier at advancedmachines.us Tue Oct 24 16:45:35 2017 From: javier at advancedmachines.us (Javier J) Date: Tue, 24 Oct 2017 12:45:35 -0400 Subject: Chinese websites loading slower recently? In-Reply-To: References: <20171020155112.GX15390@dilbert.slimey.org> <1508534858.3960426.1145860888.162AA544@webmail.messagingengine.com> Message-ID: The great firewall. https://en.wikipedia.org/wiki/Great_Firewall On Mon, Oct 23, 2017 at 2:18 PM, Olivier Benghozi < olivier.benghozi at wifirst.fr> wrote: > I can confirm, several customers complaining of being suddenly unable to > access baidu/weibo and so on > Same conclusion ensues. > > > On 20 oct. 2017 at 23:27, Tianhao Xiao wrote : > > > > The National Congress[0] just happened, and the Chinese government does > > make a very big deal out of it. I know that many universities were asked > > to temporarily block inbound HTTP traffic, which even affected open > > source mirrors during that time. > > > > With all this going on it is only natural that something restrictive > > happened to the rest of the international network. I'm not exactly sure > > what has been done, but it is very likely that it is not your problem. > > > > > > On Fri, 20 Oct 2017, at 08:51, Simon Lockhart wrote: > >> > >> Is anyone else seeing an increase in problems related to Chinese > >> websites? > > From cgrundemann at gmail.com Tue Oct 24 18:49:35 2017 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 24 Oct 2017 14:49:35 -0400 Subject: Open-IX BCOP Committee Call for Volunteers In-Reply-To: References: Message-ID: The call for volunteers ends one week from today - reach out to me today! On Mon, Sep 25, 2017 at 11:24 AM, Chris Grundemann wrote: > Pardon the interruption. > > There is a new effort underway to ensure that BCOP has a home in North > America and your help is needed. > > Following the publication of the Open-IX Document Development Policy (OIX > DDP) and the formation of the Best Current Operational Practices committee > (BCOP) , the Open-IX Board > of Directors is now seeking volunteers to take on this valuable work. > > Open-IX Best Current Operational Practices (BCOP) Committee members are > expected to seek out subject matter experts and encourage the documentation > of BCOPs from the global network engineering community. This is typically > done through activity on mailing lists, conversations at industry events, > and leveraging personal relationships. Committee members are further > expected to shepherd appropriate documents through the process from Appeal > to published BCOP, including updates to existing documents as needed. > > If you share a passion for sharing knowledge, increasing the resiliency > and efficiency of the global internet infrastructure, and have a few hours > a month to dedicate to this effort, we encourage you to volunteer! Please > send your name, email address, and a brief statement of interest to > cgrundemann open-ix.org. > > While we continuously seek new voices for all committees, this call is > expected to close on 31 October, 2017. Please submit before that time to be > considered for an immediate opening on the BCOP committee. > > Thank you, > ~Chris > From nanog-announce at nanog.org Tue Oct 24 21:18:44 2017 From: nanog-announce at nanog.org (Ryan Woolley via NANOG-announce) Date: Tue, 24 Oct 2017 16:18:44 -0500 (CDT) Subject: [NANOG-announce] NANOG 72 CFP Open Message-ID: This message has been wrapped due to the DMARC policy setting to prevent NANOG subscribers from being unsubscribed due to bounces. -------------- next part -------------- An embedded message was scrubbed... From: Ryan Woolley Subject: NANOG 72 CFP Open Date: Tue, 24 Oct 2017 17:18:41 -0400 Size: 5290 URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From matt at conundrum.com Wed Oct 25 17:05:00 2017 From: matt at conundrum.com (Matthew Pounsett) Date: Wed, 25 Oct 2017 13:05:00 -0400 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> Message-ID: On 22 October 2017 at 12:23, David Conrad wrote: > Damian, > > Pragmatically speaking, I strongly suspect the increase in valid queries > to authoritative servers even if all “large recursive resolvers” went away > would be lost in noise of the overcapacity necessary to deal with even a > lower-end DDoS attack. > A 10x increase in baseline queries is still a 10x increase (for whatever value of "10" the real world would actually throw at us). Although small by comparison, that still has to be made up in an increase in the overhead for DDoS. I'm also led to wonder how much worse it would be if all those CPE were open recursives instead of open forwarders. I'd like to see CPE manufacturers' decision making and processes improved BEFORE we start encouraging them to go around ISPs' DNS servers or the large public recursive clouds. From jfmezei_nanog at vaxination.ca Wed Oct 25 17:53:44 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 25 Oct 2017 13:53:44 -0400 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> Message-ID: On 2017-10-25 13:05, Matthew Pounsett wrote: > I'm also led to wonder how much worse it would be if all those CPE were > open recursives instead of open forwarders. I'd like to see CPE > manufacturers' decision making and processes improved BEFORE we start > encouraging them to go around ISPs' DNS servers or the large public > recursive clouds. A while back, the Québec government, wanting to protect its gambling monopoly, decided to force ISPs to block a list of gambling sites (list drawn up by the gambling monopoly to block outside competitors). Recently, Bell Canada went to government suggesting the government setup a internet web site block list to prevent canadians from accessing pirating web sites. And of course, in the USA, the upcoming decision to drop Title II for ISPs may result in large ISPs quickly starting to play tricks on DNS (redirecting traffic to their own properties etc). While all this is in its infancy and may not happen, this could have serious impact on the architecture of DNS with large swaths of customers bypassing their ISP's DNS services. But it is more likely that everyone would be going to 8.8.8.8 instead of running their own recursive server. But if the "free" DNS servers also start to play games or charge money, then CPE equipment may start including a full bind recursive server and bypass everything. This is why it is important for network folks to educate politicians to not play with the internet. From zach at zachunderwood.me Wed Oct 25 14:21:57 2017 From: zach at zachunderwood.me (Zach Underwood) Date: Wed, 25 Oct 2017 10:21:57 -0400 Subject: Large amount of TCP resets today Message-ID: We are seeing a large number of tcp reset alerts today with a source AS of GOOGLE (15169), AMAZON-02 (16509), APPLE (714), APPLE-AUSTIN (6185), FACEBOOK (32934) and AKAMAI-ASN1 (20940). Does any one here know if something is going on like big os updates. -- Zach Underwood (RHCE,RHCSA,RHCT,UACA) My website advance-networking.com From ikiris at gmail.com Wed Oct 25 18:35:20 2017 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 25 Oct 2017 11:35:20 -0700 Subject: Google DNS intermittent ServFail for Disney subdomain In-Reply-To: References: <1584315077.7158.1508505810357.JavaMail.mhammett@ThunderFuck> Message-ID: And it is believed that sold end user devices wouldn't just be required to implement this blacklist themselves? This is reminding me of the xkcd coming with the encryption and the wrench. On Wed, Oct 25, 2017 at 10:53 AM, Jean-Francois Mezei wrote: > On 2017-10-25 13:05, Matthew Pounsett wrote: > >> I'm also led to wonder how much worse it would be if all those CPE were >> open recursives instead of open forwarders. I'd like to see CPE >> manufacturers' decision making and processes improved BEFORE we start >> encouraging them to go around ISPs' DNS servers or the large public >> recursive clouds. > > > A while back, the Québec government, wanting to protect its gambling > monopoly, decided to force ISPs to block a list of gambling sites (list > drawn up by the gambling monopoly to block outside competitors). > > Recently, Bell Canada went to government suggesting the government setup > a internet web site block list to prevent canadians from accessing > pirating web sites. > > And of course, in the USA, the upcoming decision to drop Title II for > ISPs may result in large ISPs quickly starting to play tricks on DNS > (redirecting traffic to their own properties etc). > > While all this is in its infancy and may not happen, this could have > serious impact on the architecture of DNS with large swaths of customers > bypassing their ISP's DNS services. > > But it is more likely that everyone would be going to 8.8.8.8 instead of > running their own recursive server. But if the "free" DNS servers also > start to play games or charge money, then CPE equipment may start > including a full bind recursive server and bypass everything. > > This is why it is important for network folks to educate politicians to > not play with the internet. From jared at puck.Nether.net Wed Oct 25 20:14:19 2017 From: jared at puck.Nether.net (Jared Mauch) Date: Wed, 25 Oct 2017 16:14:19 -0400 Subject: Large amount of TCP resets today In-Reply-To: References: Message-ID: <20171025201419.GA21228@puck.nether.net> On Wed, Oct 25, 2017 at 10:21:57AM -0400, Zach Underwood wrote: > We are seeing a large number of tcp reset alerts today with a source AS of > GOOGLE (15169), AMAZON-02 (16509), APPLE (714), APPLE-AUSTIN (6185), > FACEBOOK (32934) and AKAMAI-ASN1 (20940). Does any one here know if > something is going on like big os updates. Do you have a time frame of when this happened? I can look on the Akamai side if that's helpful. Ping me offline and we can follow up. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From dovid at telecurve.com Wed Oct 25 20:49:00 2017 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 25 Oct 2017 16:49:00 -0400 Subject: Optimum network loop to peerless Message-ID: Is there anyone from Optimum on here see why you are internally looping traffic to 208.93.46.128/25? From cvuljanic at gmail.com Thu Oct 26 15:08:37 2017 From: cvuljanic at gmail.com (Craig) Date: Thu, 26 Oct 2017 11:08:37 -0400 Subject: Physical Layer fiber Software Tools? Message-ID: I am hoping someone could help me out with some suggestions for any software that is available, for individuals that are doing physical layer wiring in a data center? The idea is the technician is performing the fiber runs from say RACK 111 router AAA port 1/1/1 to RACK 222 router BBB port 1/1/1 The fiber is connected to a LIU in the TOP of the rack, and then will require various cross connects to get to the other rack. If the various racks and LIU's are pre-populated into the software, and then a standard for the fiber labels is also installed ahead of time into the software tool. The technician has a tablet or laptop to enter the data, and then it will print out a cable label based on the info entered into the tool. The back-end data base is updated for each fiber so the complete path is known. This way its a one step process. Maybe my description of this is readily available or have other companies developed a custom software tool to achieve this? Appreciate any feedback. From lathama at gmail.com Thu Oct 26 15:24:46 2017 From: lathama at gmail.com (Andrew Latham) Date: Thu, 26 Oct 2017 10:24:46 -0500 Subject: Physical Layer fiber Software Tools? In-Reply-To: References: Message-ID: https://en.wikipedia.org/wiki/Data_center_infrastructure_management Many solutions exist. Some are targeted for different uses. Look at https://netbox.readthedocs.io/en/latest/data-model/circuits/ for some terminology that might help in your search. On Thu, Oct 26, 2017 at 10:08 AM, Craig wrote: > I am hoping someone could help me out with some suggestions for any > software that is available, for individuals that are doing physical layer > wiring in a data center? > > The idea is the technician is performing the fiber runs from say RACK 111 > router AAA port 1/1/1 to RACK 222 router BBB port 1/1/1 > > The fiber is connected to a LIU in the TOP of the rack, and then will > require various cross connects to get to the other rack. If the various > racks and LIU's are pre-populated into the software, and then a standard > for the fiber labels is also installed ahead of time into the software > tool. > > The technician has a tablet or laptop to enter the data, and then it will > print out a cable label based on the info entered into the tool. The > back-end data base is updated for each fiber so the complete path is known. > This way its a one step process. > > Maybe my description of this is readily available or have other companies > developed a custom software tool to achieve this? > > > > Appreciate any feedback. > -- - Andrew "lathama" Latham - From Daniel.Jameson at tdstelecom.com Thu Oct 26 17:31:54 2017 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Thu, 26 Oct 2017 17:31:54 +0000 Subject: Physical Layer fiber Software Tools? In-Reply-To: References: Message-ID: Give this a look. It can track to the cross-connect level, then provide a one-line drawing. Application is web driven and expandable. It should be able to do what you need. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Craig Sent: Thursday, October 26, 2017 9:09 AM To: nanog group Subject: Physical Layer fiber Software Tools? I am hoping someone could help me out with some suggestions for any software that is available, for individuals that are doing physical layer wiring in a data center? The idea is the technician is performing the fiber runs from say RACK 111 router AAA port 1/1/1 to RACK 222 router BBB port 1/1/1 The fiber is connected to a LIU in the TOP of the rack, and then will require various cross connects to get to the other rack. If the various racks and LIU's are pre-populated into the software, and then a standard for the fiber labels is also installed ahead of time into the software tool. The technician has a tablet or laptop to enter the data, and then it will print out a cable label based on the info entered into the tool. The back-end data base is updated for each fiber so the complete path is known. This way its a one step process. Maybe my description of this is readily available or have other companies developed a custom software tool to achieve this? Appreciate any feedback. From cvuljanic at gmail.com Thu Oct 26 17:34:22 2017 From: cvuljanic at gmail.com (Craig) Date: Thu, 26 Oct 2017 13:34:22 -0400 Subject: Physical Layer fiber Software Tools? In-Reply-To: References: Message-ID: was the link attached? On Thu, Oct 26, 2017 at 1:31 PM, Jameson, Daniel < Daniel.Jameson at tdstelecom.com> wrote: > Give this a look. It can track to the cross-connect level, then provide > a one-line drawing. Application is web driven and expandable. It should be > able to do what you need. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Craig > Sent: Thursday, October 26, 2017 9:09 AM > To: nanog group > Subject: Physical Layer fiber Software Tools? > > I am hoping someone could help me out with some suggestions for any > software that is available, for individuals that are doing physical layer > wiring in a data center? > > The idea is the technician is performing the fiber runs from say RACK 111 > router AAA port 1/1/1 to RACK 222 router BBB port 1/1/1 > > The fiber is connected to a LIU in the TOP of the rack, and then will > require various cross connects to get to the other rack. If the various > racks and LIU's are pre-populated into the software, and then a standard > for the fiber labels is also installed ahead of time into the software tool. > > The technician has a tablet or laptop to enter the data, and then it will > print out a cable label based on the info entered into the tool. The > back-end data base is updated for each fiber so the complete path is known. > This way its a one step process. > > Maybe my description of this is readily available or have other companies > developed a custom software tool to achieve this? > > > > Appreciate any feedback. > From Daniel.Jameson at tdstelecom.com Thu Oct 26 17:37:52 2017 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Thu, 26 Oct 2017 17:37:52 +0000 Subject: Physical Layer fiber Software Tools? In-Reply-To: References: Message-ID: <0cc6064b-a74e-43c1-af8a-0a12a54659ab@CMAILHUB2.corp.tds.local> http://www.crestpt.com/data-center-infrastructure-management-dcim.html -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jameson, Daniel Sent: Thursday, October 26, 2017 11:32 AM To: Craig; nanog group Subject: RE: Physical Layer fiber Software Tools? Give this a look. It can track to the cross-connect level, then provide a one-line drawing. Application is web driven and expandable. It should be able to do what you need. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Craig Sent: Thursday, October 26, 2017 9:09 AM To: nanog group Subject: Physical Layer fiber Software Tools? I am hoping someone could help me out with some suggestions for any software that is available, for individuals that are doing physical layer wiring in a data center? The idea is the technician is performing the fiber runs from say RACK 111 router AAA port 1/1/1 to RACK 222 router BBB port 1/1/1 The fiber is connected to a LIU in the TOP of the rack, and then will require various cross connects to get to the other rack. If the various racks and LIU's are pre-populated into the software, and then a standard for the fiber labels is also installed ahead of time into the software tool. The technician has a tablet or laptop to enter the data, and then it will print out a cable label based on the info entered into the tool. The back-end data base is updated for each fiber so the complete path is known. This way its a one step process. Maybe my description of this is readily available or have other companies developed a custom software tool to achieve this? Appreciate any feedback. From jason+nanog at lixfeld.ca Thu Oct 26 17:58:32 2017 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Thu, 26 Oct 2017 13:58:32 -0400 Subject: What's the point of prepend communities? Message-ID: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> Hi, Of all the ISPs that I am familiar with that have a BGP community structure usable by their peering partners and/or downstream customers, among other things, they allow the customer to signal the ISP to prepend their own AS to the as-path of a particular prefix announcement. What functionality does a provider prepend support that is otherwise lost in the absence of such a feature, but all the while, the customer would be able to prepend their own AS to the same prefix announcement anyway? Is this a relic from before ISPs allowed for local preference adjustment, or is there actually a use case for this? Thanks! From bill at herrin.us Thu Oct 26 18:37:56 2017 From: bill at herrin.us (William Herrin) Date: Thu, 26 Oct 2017 14:37:56 -0400 Subject: What's the point of prepend communities? In-Reply-To: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> Message-ID: On Thu, Oct 26, 2017 at 1:58 PM, Jason Lixfeld wrote: > Of all the ISPs that I am familiar with that have a BGP community > structure usable by their peering partners and/or downstream customers, > among other things, they allow the customer to signal the ISP to prepend > their own AS to the as-path of a particular prefix announcement. > > What functionality does a provider prepend support that is otherwise lost > in the absence of such a feature, but all the while, the customer would be > able to prepend their own AS to the same prefix announcement anyway? > Hi Jason, BGP routing is based on "distance". Distance in BGP is primarily calculated as the number of ASNs in the AS Path. Prepends make a path more distance, encouraging routers to choose a different path if one is available. So, prepends are the primary knob used for controlling which path gets taken. Is this a relic from before ISPs allowed for local preference adjustment, > or is there actually a use case for this? It's the exact opposite of a relic. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From jason+nanog at lixfeld.ca Thu Oct 26 18:47:44 2017 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Thu, 26 Oct 2017 14:47:44 -0400 Subject: What's the point of prepend communities? In-Reply-To: References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> Message-ID: <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Hi Bill, > On Oct 26, 2017, at 2:37 PM, William Herrin wrote: > > BGP routing is based on "distance". Distance in BGP is primarily calculated as the number of ASNs in the AS Path. Prepends make a path more distance, encouraging routers to choose a different path if one is available. I understand how prepends fit in the context of best path selection, but my question was more the difference between a customer signalling the ISP to prepend their AS using a BGP community stamped to a prefix vs. the customer prepending their own AS instead. From morrowc.lists at gmail.com Thu Oct 26 18:50:54 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 26 Oct 2017 14:50:54 -0400 Subject: What's the point of prepend communities? In-Reply-To: <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Message-ID: On Thu, Oct 26, 2017 at 2:47 PM, Jason Lixfeld wrote: > Hi Bill, > > > On Oct 26, 2017, at 2:37 PM, William Herrin wrote: > > > > BGP routing is based on "distance". Distance in BGP is primarily > calculated as the number of ASNs in the AS Path. Prepends make a path more > distance, encouraging routers to choose a different path if one is > available. > > I understand how prepends fit in the context of best path selection, but > my question was more the difference between a customer signalling the ISP > to prepend their AS using a BGP community stamped to a prefix vs. the > customer prepending their own AS instead. > > blame shifting? avoiding instances where a third party filters: ?$ vs .*$ or just people's particular picadellos. From job at ntt.net Thu Oct 26 18:55:58 2017 From: job at ntt.net (Job Snijders) Date: Thu, 26 Oct 2017 18:55:58 +0000 Subject: What's the point of prepend communities? In-Reply-To: <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Message-ID: Hi, In context of traffic engineering it may be that Network A (customer of Network B) observes that performance is suboptimal between Network B and Network C. If Network B offers some kind of “Prepend to Network C” BGP community, network A will be able to utilize all of network B except the pieces that perform less well. (This is ofcourse assuming that Network C picks some alternative path because of the prepends) I think prepend communities are useful to empower customers to debug and perhaps even resolve issues without waiting for action from their supplier. Prepends are also slightly more graceful than “don’t export”, since if there are no alternative paths there still is _a_ path - and often any path is better than no path. Kind regards, Job From bill at herrin.us Thu Oct 26 19:05:25 2017 From: bill at herrin.us (William Herrin) Date: Thu, 26 Oct 2017 15:05:25 -0400 Subject: What's the point of prepend communities? In-Reply-To: <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Message-ID: On Thu, Oct 26, 2017 at 2:47 PM, Jason Lixfeld wrote: > Hi Bill, > > > On Oct 26, 2017, at 2:37 PM, William Herrin wrote: > > > > BGP routing is based on "distance". Distance in BGP is primarily > calculated as the number of ASNs in the AS Path. Prepends make a path more > distance, encouraging routers to choose a different path if one is > available. > > I understand how prepends fit in the context of best path selection, but > my question was more the difference between a customer signalling the ISP > to prepend their AS using a BGP community stamped to a prefix vs. the > customer prepending their own AS instead. > > Hi Jason, You'd only use communities like that if you want to signal the ISP to deprioritize your advertisement on a particular peer or set of peers but not others. That's when you're getting fancy. It's not the norm. The norm is you want to deprioritize one of your paths as a whole. Maybe that link has less capacity or is enough better connected that it would always override your other links unless you detune it a little. I mean, you could tell the ISP to prepend everything based on a community, assuming they support such a community, but why would you? That needlessly makes things more complicated. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From jason+nanog at lixfeld.ca Thu Oct 26 19:09:46 2017 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Thu, 26 Oct 2017 15:09:46 -0400 Subject: What's the point of prepend communities? In-Reply-To: References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Message-ID: <5830263C-E143-4CC8-AB87-A0E5B0B9DDA2@lixfeld.ca> > On Oct 26, 2017, at 2:55 PM, Job Snijders wrote: > > If Network B offers some kind of “Prepend to Network C” BGP community, network A will be able to utilize all of network B except the pieces that perform less well. (This is ofcourse assuming that Network C picks some alternative path because of the prepends) Absolutely. I understand the "Prepend to Network blah” use case. The case I don’t get is where the ISP makes no distinction in their policy document about how the prepending of their own AS is applied to their upstream announcements, implying that it’s announced to everyone. From bill at herrin.us Thu Oct 26 19:14:38 2017 From: bill at herrin.us (William Herrin) Date: Thu, 26 Oct 2017 15:14:38 -0400 Subject: What's the point of prepend communities? In-Reply-To: References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Message-ID: On Thu, Oct 26, 2017 at 3:05 PM, William Herrin wrote: > On Thu, Oct 26, 2017 at 2:47 PM, Jason Lixfeld > wrote: > You'd only use communities like that if you want to signal the ISP to > deprioritize your advertisement on a particular peer or set of peers but > not others. That's when you're getting fancy. It's not the norm. The norm > is you want to deprioritize one of your paths as a whole. Maybe that link > has less capacity or is enough better connected that it would always > override your other links unless you detune it a little. > > I mean, you could tell the ISP to prepend everything based on a community, > assuming they support such a community, but why would you? That needlessly > makes things more complicated. > Ah, I see. I completely misread your question. The answer you may be looking for is that the ISP can be more subtle about which of their peers gets your prepend. Maybe you want to prefer ISP A for your overseas traffic but prefer ISP B for your domestic traffic. ISP A can design a community tag that causes your advertisement to be prepended but only when sent to domestic peers. Still not a relic but not a primary knob. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bicknell at ufp.org Thu Oct 26 19:19:43 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 26 Oct 2017 12:19:43 -0700 Subject: What's the point of prepend communities? In-Reply-To: <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Message-ID: <20171026191943.GA20822@ussenterprise.ufp.org> In a message written on Thu, Oct 26, 2017 at 02:47:44PM -0400, Jason Lixfeld wrote: > I understand how prepends fit in the context of best path selection, but my question was more the difference between a customer signalling the ISP to prepend their AS using a BGP community stamped to a prefix vs. the customer prepending their own AS instead. Imagine: You are 1. ISP is 2. ISP's peers are 3 & 4. Your B2B partner is 5. There are paths: 1 2 3 5 1 2 4 5 If you prepend your ASN, you get: 1 1 2 3 5 1 1 2 4 5 No difference. If you send the ISP a prepend community for 3, you get: 1 2 3 3 5 1 2 4 5 And you just forced all traffic to the second, shorter path. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From SNaslund at medline.com Thu Oct 26 19:20:48 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Oct 2017 19:20:48 +0000 Subject: What's the point of prepend communities? In-Reply-To: References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Message-ID: <9578293AE169674F9A048B2BC9A081B40262170B74@MUNPRDMBXA1.medline.com> That is exactly correct. It is normally used to control which peers the ISP is prepended to. Many times the ISP has a guide that shows several different communities you can use to further control BGP beyond what you normally could do yourself. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin Sent: Thursday, October 26, 2017 2:15 PM To: Jason Lixfeld Cc: NANOG Subject: Re: What's the point of prepend communities? On Thu, Oct 26, 2017 at 3:05 PM, William Herrin wrote: > On Thu, Oct 26, 2017 at 2:47 PM, Jason Lixfeld > > wrote: > You'd only use communities like that if you want to signal the ISP to > deprioritize your advertisement on a particular peer or set of peers > but not others. That's when you're getting fancy. It's not the norm. > The norm is you want to deprioritize one of your paths as a whole. > Maybe that link has less capacity or is enough better connected that > it would always override your other links unless you detune it a little. > > I mean, you could tell the ISP to prepend everything based on a > community, assuming they support such a community, but why would you? > That needlessly makes things more complicated. > Ah, I see. I completely misread your question. The answer you may be looking for is that the ISP can be more subtle about which of their peers gets your prepend. Maybe you want to prefer ISP A for your overseas traffic but prefer ISP B for your domestic traffic. ISP A can design a community tag that causes your advertisement to be prepended but only when sent to domestic peers. Still not a relic but not a primary knob. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From rbf+nanog at panix.com Thu Oct 26 19:52:07 2017 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Thu, 26 Oct 2017 14:52:07 -0500 Subject: What's the point of prepend communities? In-Reply-To: References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Message-ID: <20171026195207.GA14782@panix.com> On Thu, Oct 26, 2017 at 03:05:25PM -0400, William Herrin wrote: > > You'd only use communities like that if you want to signal the ISP to > deprioritize your advertisement on a particular peer or set of peers but > not others. That's when you're getting fancy. It's not the norm. The norm > is you want to deprioritize one of your paths as a whole. Maybe that link > has less capacity or is enough better connected that it would always > override your other links unless you detune it a little. > > I mean, you could tell the ISP to prepend everything based on a community, > assuming they support such a community, but why would you? That needlessly > makes things more complicated. Completely agree. I would add that some providers' "prepend everything" community is really "prepend to all peers" (or something else shy of "prepend to every BGP neighbor we have"). In that case, if the customer prepends, the prepend is seen by the provider's other customers, but if the customer sets the "prepend to all peers" community, the provider's customers won't see the prepend. There are cases where that functionality would be useful. I have never seen a provider with a true "prepend to every BGP neighbor we have" community, but it might well exist somewhere. -- Brett From clinton at scripty.com Thu Oct 26 19:54:17 2017 From: clinton at scripty.com (Clinton Work) Date: Thu, 26 Oct 2017 13:54:17 -0600 Subject: What's the point of prepend communities? In-Reply-To: <20171026191943.GA20822@ussenterprise.ufp.org> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> <20171026191943.GA20822@ussenterprise.ufp.org> Message-ID: <1509047657.3640410.1152209288.32152D70@webmail.messagingengine.com> I believe that Jason is asking about an ISP BGP community to prepend their AS when the BGP routes are received from the customer (not when advertising to a peer). I don't see a functional difference between the two and I suspect that ISPs added support for convenience. If you already send BGP communities to your ISP for other BGP route manipulation, you can add another community for ISP AS prepending rather than modifying your local policies to add AS prepending. You are 1. ISP is 2. 1 1 2 - You prepend 1 2 2 - ISP prepends -- Clinton Work Airdrie, AB On Thu, Oct 26, 2017, at 01:19 PM, Leo Bicknell wrote: > In a message written on Thu, Oct 26, 2017 at 02:47:44PM -0400, Jason > Lixfeld wrote: > > I understand how prepends fit in the context of best path selection, but my question was more the difference between a customer signalling the ISP to prepend their AS using a BGP community stamped to a prefix vs. the customer prepending their own AS instead. > From SNaslund at medline.com Thu Oct 26 20:22:36 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 26 Oct 2017 20:22:36 +0000 Subject: What's the point of prepend communities? In-Reply-To: <1509047657.3640410.1152209288.32152D70@webmail.messagingengine.com> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> <20171026191943.GA20822@ussenterprise.ufp.org> <1509047657.3640410.1152209288.32152D70@webmail.messagingengine.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40262170CCB@MUNPRDMBXA1.medline.com> No, Mr Herrin was correct in the first place. The BGP communities are used to control to which peers the prepend is applied. You cannot do this within your own BGP configuration. Here is the use case. I have a connection to AT&T and I have one to Comcast I want AT&T customers to come to me over the AT&T circuit. I want everyone else to come to me over Comcast. If I just prepend my own AS onto the AT&T connection I might actually cause AT&T customers to reach me via Comcast (shorter AS path potentially). If I want to prevent that I send a prepend community to AT&T which tells them to prepend toward their peers BUT NOT WITHIN THEIR OWN NETWORK. There are usually multiple choices here to affect different subsets of their peers (customers, peer carriers, etc). There is also the case where I have multiple AT&T connections. If I prepend just one of them the way you suggest, all of my traffic will probably come in the other connection. If I prepend using communities I can get some traffic (from AT&T peers) on one connection and get most of the transit on the other connection. What you are doing in effect is making your connection with AT&T look like AT&T is a peer rather than a transit AS. You can also do this to more selectively influence your inbound traffic when you are multihomed to different carriers (just a simple prepend like you suggest may not be granular enough, I have seen cases where a single prepend pushes almost all your traffic to your other carrier). The old way to do this was to ask your ISP to treat you like a peer rather than a transit customer. Now you can control that yourself just by setting the correct communities, it can also be programmatically controlled. Picture you have the configuration like I talked about above with AT&T and Comcast but now Comcast is overloaded or impaired. By changing your communities you can reroute most of the traffic to AT&T without a MACD request to them. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces+snaslund=medline.com at nanog.org] On Behalf Of Clinton Work Sent: Thursday, October 26, 2017 2:54 PM To: nanog at nanog.org Subject: Re: What's the point of prepend communities? I believe that Jason is asking about an ISP BGP community to prepend their AS when the BGP routes are received from the customer (not when advertising to a peer). I don't see a functional difference between the two and I suspect that ISPs added support for convenience. If you already send BGP communities to your ISP for other BGP route manipulation, you can add another community for ISP AS prepending rather than modifying your local policies to add AS prepending. You are 1. ISP is 2. 1 1 2 - You prepend 1 2 2 - ISP prepends -- Clinton Work Airdrie, AB On Thu, Oct 26, 2017, at 01:19 PM, Leo Bicknell wrote: > In a message written on Thu, Oct 26, 2017 at 02:47:44PM -0400, Jason > Lixfeld wrote: > > I understand how prepends fit in the context of best path selection, but my question was more the difference between a customer signalling the ISP to prepend their AS using a BGP community stamped to a prefix vs. the customer prepending their own AS instead. > From aaron at heyaaron.com Thu Oct 26 22:33:46 2017 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 26 Oct 2017 15:33:46 -0700 Subject: Ping a Comcast Business DNS Admin? Message-ID: I'm hoping a Comcast engineer can clear something up for me: If I recall correctly siteprotect.com is used by Comcast Business hosting. We have a mutual customer who has their domain NS pointed at ADNS.CS.SITEPROTECT.COM and BDNS.CS.SITEPROTECT.COM and those servers resolve their domain properly, but as of two weeks ago I no longer have the option to edit the customer's zone when signing in to businessclass.comcast.net. Phone reps have said "we don't manage you DNS" or "NetSol is their registrar", or even "Hmm...you're right, there's something wrong, but I don't know what's going on". On top of all of that, Comcast told this mutual customer to update their DNS records because they are being migrated to Office 365. But the customer can't access it to edit it. Feel free to contact me off-list for the domain and customer details. -A From aaron at heyaaron.com Fri Oct 27 03:17:34 2017 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 26 Oct 2017 20:17:34 -0700 Subject: Ping a Comcast Business DNS Admin? In-Reply-To: References: Message-ID: I received replied from several friendly Comcast staff members and it looks like there will be a resolution shortly. Thanks, and sorry for the list noise. -A On Thu, Oct 26, 2017 at 3:33 PM, Aaron C. de Bruyn wrote: > I'm hoping a Comcast engineer can clear something up for me: > > If I recall correctly siteprotect.com is used by Comcast Business hosting. > > We have a mutual customer who has their domain NS pointed at > ADNS.CS.SITEPROTECT.COM and BDNS.CS.SITEPROTECT.COM and those servers > resolve their domain properly, but as of two weeks ago I no longer > have the option to edit the customer's zone when signing in to > businessclass.comcast.net. > > Phone reps have said "we don't manage you DNS" or "NetSol is their > registrar", or even "Hmm...you're right, there's something wrong, but > I don't know what's going on". > > On top of all of that, Comcast told this mutual customer to update > their DNS records because they are being migrated to Office 365. But > the customer can't access it to edit it. > > Feel free to contact me off-list for the domain and customer details. > > -A From joelja at bogus.com Fri Oct 27 03:44:55 2017 From: joelja at bogus.com (joel jaeggli) Date: Thu, 26 Oct 2017 20:44:55 -0700 Subject: What's the point of prepend communities? In-Reply-To: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> Message-ID: On 10/26/17 10:58, Jason Lixfeld wrote: > Hi, > > Of all the ISPs that I am familiar with that have a BGP community structure usable by their peering partners and/or downstream customers, among other things, they allow the customer to signal the ISP to prepend their own AS to the as-path of a particular prefix announcement. > > What functionality does a provider prepend support that is otherwise lost in the absence of such a feature, but all the while, the customer would be able to prepend their own AS to the same prefix announcement anyway? It has no effect on the provider itself since they prefer customer routes anyway. prepending towards a peer of your provider is to encourage them to select an alternative (shorter) path. prepending when it works is preferable to no export since the later doesn't leave that provider available for fallback. > Is this a relic from before ISPs allowed for local preference adjustment, or is there actually a use case for this? local pref and med is um local to your upstream. > Thanks! > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: From cscora at apnic.net Fri Oct 27 18:02:48 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Oct 2017 04:02:48 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171027180248.6BED8DA8@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Oct, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 666071 Prefixes after maximum aggregation (per Origin AS): 259795 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 322065 Total ASes present in the Internet Routing Table: 58852 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 50848 Origin ASes announcing only one prefix: 22395 Transit ASes present in the Internet Routing Table: 8004 Transit-only ASes present in the Internet Routing Table: 234 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 30 Max AS path prepend of ASN (206156) 26 Prefixes from unregistered ASNs in the Routing Table: 88 Number of instances of unregistered ASNs: 88 Number of 32-bit ASNs allocated by the RIRs: 20390 Number of 32-bit ASNs visible in the Routing Table: 16223 Prefixes from 32-bit ASNs in the Routing Table: 66799 Number of bogon 32-bit ASNs visible in the Routing Table: 21 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 385 Number of addresses announced to Internet: 2857706336 Equivalent to 170 /8s, 85 /16s and 35 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 219410 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 184054 Total APNIC prefixes after maximum aggregation: 52741 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 183169 Unique aggregates announced from the APNIC address blocks: 75547 APNIC Region origin ASes present in the Internet Routing Table: 8433 APNIC Prefixes per ASN: 21.72 APNIC Region origin ASes announcing only one prefix: 2350 APNIC Region transit ASes present in the Internet Routing Table: 1211 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3283 Number of APNIC addresses announced to Internet: 766194656 Equivalent to 45 /8s, 171 /16s and 51 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 199932 Total ARIN prefixes after maximum aggregation: 96511 ARIN Deaggregation factor: 2.07 Prefixes being announced from the ARIN address blocks: 201370 Unique aggregates announced from the ARIN address blocks: 94150 ARIN Region origin ASes present in the Internet Routing Table: 18008 ARIN Prefixes per ASN: 11.18 ARIN Region origin ASes announcing only one prefix: 6660 ARIN Region transit ASes present in the Internet Routing Table: 1778 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2237 Number of ARIN addresses announced to Internet: 1110357280 Equivalent to 66 /8s, 46 /16s and 181 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 178976 Total RIPE prefixes after maximum aggregation: 87538 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 174947 Unique aggregates announced from the RIPE address blocks: 105618 RIPE Region origin ASes present in the Internet Routing Table: 24529 RIPE Prefixes per ASN: 7.13 RIPE Region origin ASes announcing only one prefix: 11210 RIPE Region transit ASes present in the Internet Routing Table: 3493 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6305 Number of RIPE addresses announced to Internet: 713466496 Equivalent to 42 /8s, 134 /16s and 162 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 85317 Total LACNIC prefixes after maximum aggregation: 19009 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 86557 Unique aggregates announced from the LACNIC address blocks: 39214 LACNIC Region origin ASes present in the Internet Routing Table: 6516 LACNIC Prefixes per ASN: 13.28 LACNIC Region origin ASes announcing only one prefix: 1823 LACNIC Region transit ASes present in the Internet Routing Table: 1193 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4037 Number of LACNIC addresses announced to Internet: 172714208 Equivalent to 10 /8s, 75 /16s and 104 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17702 Total AfriNIC prefixes after maximum aggregation: 3921 AfriNIC Deaggregation factor: 4.51 Prefixes being announced from the AfriNIC address blocks: 19643 Unique aggregates announced from the AfriNIC address blocks: 7220 AfriNIC Region origin ASes present in the Internet Routing Table: 1095 AfriNIC Prefixes per ASN: 17.94 AfriNIC Region origin ASes announcing only one prefix: 351 AfriNIC Region transit ASes present in the Internet Routing Table: 214 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 361 Number of AfriNIC addresses announced to Internet: 94477824 Equivalent to 5 /8s, 161 /16s and 158 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5270 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4017 408 407 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2787 11128 752 KIXS-AS-KR Korea Telecom, KR 17974 2784 900 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2764 1499 541 BSNL-NIB National Internet Backbone, IN 9808 2398 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2344 1490 147 VNPT-AS-VN VNPT Corp, VN 9394 2174 4931 27 CTTNET China TieTong Telecommunications 4755 2109 422 222 TATACOMM-AS TATA Communications formerl 7552 2084 1170 77 VIETEL-AS-AP Viettel Corporation, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3344 1325 92 SHAW - Shaw Communications Inc., CA 22773 3306 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2175 405 107 MEGAPATH5-US - MegaPath Corporation, US 6389 2045 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2045 2281 435 CHARTER-NET-HKY-NC - Charter Communicat 209 1947 5066 651 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1872 4035 567 AMAZON-02 - Amazon.com, Inc., US 30036 1835 328 305 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1625 237 573 CABLEONE - CABLE ONE, INC., US 701 1577 10589 626 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2828 847 2053 AKAMAI-ASN1, US 8551 2468 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2065 331 427 TELLCOM-AS, TR 12389 1880 1679 714 ROSTELECOM-AS, RU 12479 1815 1063 72 UNI2-AS, ES 9121 1795 1691 17 TTNET, TR 13188 1602 100 67 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1220 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3547 538 286 Telmex Colombia S.A., CO 8151 3222 3463 582 Uninet S.A. de C.V., MX 11830 2329 367 41 Instituto Costarricense de Electricidad 6503 1596 437 53 Axtel, S.A.B. de C.V., MX 7303 1482 1014 195 Telecom Argentina S.A., AR 6147 1272 377 27 Telefonica del Peru S.A.A., PE 3816 1031 509 103 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1001 2304 179 CLARO S.A., BR 11172 913 126 86 Alestra, S. de R.L. de C.V., MX 18881 902 1060 26 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1218 398 48 LINKdotNET-AS, EG 37611 778 91 8 Afrihost, ZA 36903 704 354 142 MT-MPLS, MA 36992 668 1383 31 ETISALAT-MISR, EG 24835 515 850 15 RAYA-AS, EG 8452 510 1730 17 TE-AS TE-AS, EG 29571 428 36 10 CITelecom-AS, CI 37492 416 354 77 ORANGE-, TN 15399 356 35 7 WANANCHI-, KE 2018 298 327 73 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5270 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4017 408 407 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3547 538 286 Telmex Colombia S.A., CO 39891 3387 186 23 ALJAWWALSTC-AS, SA 6327 3344 1325 92 SHAW - Shaw Communications Inc., CA 22773 3306 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8151 3222 3463 582 Uninet S.A. de C.V., MX 20940 2828 847 2053 AKAMAI-ASN1, US 4766 2787 11128 752 KIXS-AS-KR Korea Telecom, KR 17974 2784 900 77 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4017 3610 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 10620 3547 3261 Telmex Colombia S.A., CO 6327 3344 3252 SHAW - Shaw Communications Inc., CA 22773 3306 3148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 17974 2784 2707 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8151 3222 2640 Uninet S.A. de C.V., MX 8551 2468 2426 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2398 2366 CMNET-GD Guangdong Mobile Communication Co.Ltd. 11830 2329 2288 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65543 DOCUMENT 79.98.33.0/24 43950 SPILSBY-AS =================== Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:106 /12:285 /13:552 /14:1053 /15:1862 /16:13397 /17:7751 /18:13618 /19:25274 /20:39127 /21:43017 /22:80637 /23:65697 /24:371409 /25:847 /26:624 /27:651 /28:35 /29:21 /30:15 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3138 3344 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2527 3306 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2070 2175 MEGAPATH5-US - MegaPath Corporation, US 8551 1932 2468 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 1699 2329 Instituto Costarricense de Electricidad y Telec 30036 1607 1835 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1533 3547 Telmex Colombia S.A., CO 11492 1445 1625 CABLEONE - CABLE ONE, INC., US 34984 1369 2065 TELLCOM-AS, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1573 2:840 4:18 5:2491 6:36 7:1 8:1064 9:1 12:1850 13:164 14:1712 15:29 16:3 17:176 18:76 20:60 23:2462 24:1677 25:2 27:2359 29:1 31:1941 32:87 35:21 36:424 37:2409 38:1415 39:79 40:99 41:3033 42:509 43:1928 44:85 45:3138 46:2825 47:171 49:1331 50:1019 51:19 52:872 54:353 55:1 56:4 57:43 58:1570 59:995 60:356 61:2020 62:1738 63:1845 64:4604 65:2226 66:4443 67:2303 68:1190 69:3163 70:1129 71:588 72:2093 74:2626 75:390 76:409 77:1513 78:1558 79:1948 80:1413 81:1409 82:1019 83:747 84:981 85:1943 86:468 87:1206 88:855 89:2255 90:174 91:6194 92:1033 93:2321 94:2398 95:2640 96:649 97:352 98:963 99:97 100:153 101:1306 102:1 103:16097 104:3077 105:209 106:577 107:1696 108:825 109:2870 110:1497 111:1758 112:1294 113:1260 114:1058 115:1578 116:1655 117:1841 118:2158 119:1654 120:913 121:1074 122:2435 123:1873 124:1496 125:1817 128:955 129:661 130:445 131:1499 132:603 133:193 134:809 135:227 136:382 137:498 138:1940 139:538 140:380 141:666 142:750 143:916 144:797 145:188 146:1114 147:701 148:1519 149:592 150:707 151:1005 152:720 153:301 154:928 155:751 156:695 157:744 158:598 159:1600 160:815 161:732 162:2496 163:508 164:998 165:1442 166:388 167:1333 168:3059 169:818 170:3524 171:371 172:995 173:1906 174:814 175:760 176:1870 177:4007 178:2482 179:1125 180:2205 181:2092 182:2469 183:815 184:879 185:11210 186:3315 187:2305 188:2611 189:1866 190:8161 191:1351 192:9690 193:5841 194:4734 195:3954 196:2204 197:1237 198:5536 199:5872 200:7169 201:4601 202:10340 203:9976 204:4526 205:2854 206:3021 207:3126 208:3983 209:3893 210:3935 211:2092 212:2851 213:2572 214:843 215:65 216:5696 217:2104 218:921 219:599 220:1670 221:941 222:724 223:1298 End of report From sdodd at salesforce.com Thu Oct 26 19:10:12 2017 From: sdodd at salesforce.com (Steve Dodd) Date: Thu, 26 Oct 2017 13:10:12 -0600 Subject: What's the point of prepend communities? In-Reply-To: References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Message-ID: Keep in mind also that when you allow a customer to deprioritize a particular peer you can really blow up your COGS model (assuming you buy transit). Cheers, Steve On Thu, Oct 26, 2017 at 1:05 PM, William Herrin wrote: > On Thu, Oct 26, 2017 at 2:47 PM, Jason Lixfeld > wrote: > > > Hi Bill, > > > > > On Oct 26, 2017, at 2:37 PM, William Herrin wrote: > > > > > > BGP routing is based on "distance". Distance in BGP is primarily > > calculated as the number of ASNs in the AS Path. Prepends make a path > more > > distance, encouraging routers to choose a different path if one is > > available. > > > > I understand how prepends fit in the context of best path selection, but > > my question was more the difference between a customer signalling the ISP > > to prepend their AS using a BGP community stamped to a prefix vs. the > > customer prepending their own AS instead. > > > > > Hi Jason, > > You'd only use communities like that if you want to signal the ISP to > deprioritize your advertisement on a particular peer or set of peers but > not others. That's when you're getting fancy. It's not the norm. The norm > is you want to deprioritize one of your paths as a whole. Maybe that link > has less capacity or is enough better connected that it would always > override your other links unless you detune it a little. > > I mean, you could tell the ISP to prepend everything based on a community, > assuming they support such a community, but why would you? That needlessly > makes things more complicated. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From rwf at loonybin.net Thu Oct 26 19:56:17 2017 From: rwf at loonybin.net (Rob Foehl) Date: Thu, 26 Oct 2017 15:56:17 -0400 (EDT) Subject: What's the point of prepend communities? In-Reply-To: <5830263C-E143-4CC8-AB87-A0E5B0B9DDA2@lixfeld.ca> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> <5830263C-E143-4CC8-AB87-A0E5B0B9DDA2@lixfeld.ca> Message-ID: On Thu, 26 Oct 2017, Jason Lixfeld wrote: > Absolutely. I understand the "Prepend to Network blah” use case. The case I don’t get is where the ISP makes no distinction in their policy document about how the prepending of their own AS is applied to their upstream announcements, implying that it’s announced to everyone. The "prepend to everybody" communities are usually implemented as "prepend to all peers", excluding customers, and for some variable definition of "all". YMMV, caveat emptor, et cetera -- in most cases you'll need to experiment. I've used "prepend to all peers" communities a few times to avoid saturating transit links that are being consolidated but still under contract, in order to keep the link viable and in use by the immediate neighbor and their customers, but otherwise make it less attractive to the rest of the world under normal conditions. -Rob From nanog at ics-il.net Sun Oct 29 12:01:13 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 29 Oct 2017 07:01:13 -0500 (CDT) Subject: What's the point of prepend communities? In-Reply-To: <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> Message-ID: <1551560557.1648.1509278472868.JavaMail.mhammett@ThunderFuck> If I understand the OP correctly, I will use this real world example: https://onestep.net/communities/as174/ 174:3001 through 174:3003 as compared to doing the prepending yourself. What is the functional difference? BGP neighbors of 174 will see just as many AS hops either way, but non-BGP customers of 174 would see you just one hop away. It's just another method of traffic engineering. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jason Lixfeld" To: "William Herrin" Cc: "NANOG" Sent: Thursday, October 26, 2017 1:47:44 PM Subject: Re: What's the point of prepend communities? Hi Bill, > On Oct 26, 2017, at 2:37 PM, William Herrin wrote: > > BGP routing is based on "distance". Distance in BGP is primarily calculated as the number of ASNs in the AS Path. Prepends make a path more distance, encouraging routers to choose a different path if one is available. I understand how prepends fit in the context of best path selection, but my question was more the difference between a customer signalling the ISP to prepend their AS using a BGP community stamped to a prefix vs. the customer prepending their own AS instead. From rbf+nanog at panix.com Sun Oct 29 13:26:10 2017 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 29 Oct 2017 08:26:10 -0500 Subject: What's the point of prepend communities? In-Reply-To: <1551560557.1648.1509278472868.JavaMail.mhammett@ThunderFuck> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> <1551560557.1648.1509278472868.JavaMail.mhammett@ThunderFuck> Message-ID: <20171029132610.GA20529@panix.com> On Sun, Oct 29, 2017 at 07:01:13AM -0500, Mike Hammett wrote: > If I understand the OP correctly, I will use this real world example: > > https://onestep.net/communities/as174/ > > 174:3001 through 174:3003 as compared to doing the prepending > yourself. What is the functional difference? > > BGP neighbors of 174 will see just as many AS hops either way, but > non-BGP customers of 174 would see you just one hop away. It's just > another method of traffic engineering. According to the link you provided, 3001..3003 are effective on "ALL peer[s]" (which is differnet from all BGP neighbors). So BGP-speaking customers of 174 will not see the prepending if you use 174:3001..3003, but peers will; but if you do the prepending yourself, then all 174's peers and all 174's BGP-speaking customers see it. -- Brett From cvuljanic at gmail.com Mon Oct 30 12:17:15 2017 From: cvuljanic at gmail.com (Craig) Date: Mon, 30 Oct 2017 08:17:15 -0400 Subject: Physical Layer fiber Software Tools? In-Reply-To: References: Message-ID: We are trying out Patchmanager currently, we are asking them if they offer any software to speed up the physical install for the fiber techs. On Mon, Oct 30, 2017 at 7:31 AM, Arien Vijn wrote: > You probably want to look at Patchmanager: https://patchmanager.com > > They usually allow you a free testdrive. > > — Arien > > > On Oct 26, 2017(43), at 17:08, Craig wrote: > > > > I am hoping someone could help me out with some suggestions for any > > software that is available, for individuals that are doing physical layer > > wiring in a data center? > > > > The idea is the technician is performing the fiber runs from say RACK 111 > > router AAA port 1/1/1 to RACK 222 router BBB port 1/1/1 > > > > The fiber is connected to a LIU in the TOP of the rack, and then will > > require various cross connects to get to the other rack. If the various > > racks and LIU's are pre-populated into the software, and then a standard > > for the fiber labels is also installed ahead of time into the software > > tool. > > > > The technician has a tablet or laptop to enter the data, and then it will > > print out a cable label based on the info entered into the tool. The > > back-end data base is updated for each fiber so the complete path is > known. > > This way its a one step process. > > > > Maybe my description of this is readily available or have other companies > > developed a custom software tool to achieve this? > > > > > > > > Appreciate any feedback. > > From arien at vijn.net Mon Oct 30 11:31:23 2017 From: arien at vijn.net (Arien Vijn) Date: Mon, 30 Oct 2017 12:31:23 +0100 Subject: Physical Layer fiber Software Tools? In-Reply-To: References: Message-ID: You probably want to look at Patchmanager: https://patchmanager.com They usually allow you a free testdrive. — Arien > On Oct 26, 2017(43), at 17:08, Craig wrote: > > I am hoping someone could help me out with some suggestions for any > software that is available, for individuals that are doing physical layer > wiring in a data center? > > The idea is the technician is performing the fiber runs from say RACK 111 > router AAA port 1/1/1 to RACK 222 router BBB port 1/1/1 > > The fiber is connected to a LIU in the TOP of the rack, and then will > require various cross connects to get to the other rack. If the various > racks and LIU's are pre-populated into the software, and then a standard > for the fiber labels is also installed ahead of time into the software > tool. > > The technician has a tablet or laptop to enter the data, and then it will > print out a cable label based on the info entered into the tool. The > back-end data base is updated for each fiber so the complete path is known. > This way its a one step process. > > Maybe my description of this is readily available or have other companies > developed a custom software tool to achieve this? > > > > Appreciate any feedback. From bicknell at ufp.org Mon Oct 30 17:24:11 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 30 Oct 2017 10:24:11 -0700 Subject: What's the point of prepend communities? In-Reply-To: <1509047657.3640410.1152209288.32152D70@webmail.messagingengine.com> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> <20171026191943.GA20822@ussenterprise.ufp.org> <1509047657.3640410.1152209288.32152D70@webmail.messagingengine.com> Message-ID: <20171030172411.GA21203@ussenterprise.ufp.org> In a message written on Thu, Oct 26, 2017 at 01:54:17PM -0600, Clinton Work wrote: > I believe that Jason is asking about an ISP BGP community to prepend > their AS when the BGP routes are received from the customer (not when Yeah, I typoed my example, should have been: There are paths: 1 2 3 5 1 2 4 5 If you prepend your ASN, you get: 1 1 2 3 5 1 1 2 4 5 No difference. If you send the ISP a prepend community for 3, you get: 1 2 2 3 5 1 2 4 5 And you just forced all traffic to the second, shorter path. For only customers that are dual homed to 3 & 4 without affecting other traffic. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From mh at xalto.net Mon Oct 30 18:56:43 2017 From: mh at xalto.net (Michael Hallgren) Date: Mon, 30 Oct 2017 19:56:43 +0100 Subject: What's the point of prepend communities? In-Reply-To: <20171030172411.GA21203@ussenterprise.ufp.org> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> <20171026191943.GA20822@ussenterprise.ufp.org> <1509047657.3640410.1152209288.32152D70@webmail.messagingengine.com> <20171030172411.GA21203@ussenterprise.ufp.org> Message-ID: <16e20cc1-ae53-42a8-a355-7245930a9b09@xalto.net> Hi guys, But keep in mind that 'prepend communities' are fragile: I decide by local preference whereto I send my traffic. Cheers, mh Le 30 oct. 2017 à 18:25, à 18:25, Leo Bicknell a écrit: >In a message written on Thu, Oct 26, 2017 at 01:54:17PM -0600, Clinton >Work wrote: >> I believe that Jason is asking about an ISP BGP community to prepend >> their AS when the BGP routes are received from the customer (not when > >Yeah, I typoed my example, should have been: > >There are paths: > >1 2 3 5 >1 2 4 5 > >If you prepend your ASN, you get: > >1 1 2 3 5 >1 1 2 4 5 > >No difference. If you send the ISP a prepend community for 3, you get: > >1 2 2 3 5 >1 2 4 5 > >And you just forced all traffic to the second, shorter path. For only >customers that are dual homed to 3 & 4 without affecting other traffic. > >-- >Leo Bicknell - bicknell at ufp.org >PGP keys at http://www.ufp.org/~bicknell/