- Test - lists.nanog.org

Re: Cleveland/Cincinnati Co-location
by David Kehoe 07 Jan '19

07 Jan '19

Former employer was in Expedient’s DC. You can honestly do better than Expedient. Look into the Power Redundancy, Cooling Efficiency of the building, if the site is a purpose built DC (Expedient in Cleveland is not). Is Cloud Connect for backups important? Have you identified your requirements? If you need a starting point look at the following: Data Center Certification (from the Uptime Institute), Distance, Compliance (if needed), Level of Controlled Access, Power SLA, N+1 Cooling, Multi-Homed ISPs, Uptime %, Monitoring, NOC, Purpose Built DC. Involta has a really good data center in Independence, Akron, and a very impressive site near Pittsburgh. They would give you the option of having Hot/Hot datacenters with their connectivity. I’m not sure if you have to be in Cleveland or Cincinnati, but Cyxtera has an AMAZING data center in Columbus. (The DC can withstand winds up 140 MPH, is on the Century Link backbone, and has a solid rubber roof with no holes or cooling systems on the roof.) Thank you, David Kehoe From: NANOG <nanog-bounces(a)nanog.org> On Behalf Of nanog-request(a)nanog.org Sent: Friday, January 4, 2019 7:00 AM To: nanog(a)nanog.org Subject: NANOG Digest, Vol 132, Issue 4 Send NANOG mailing list submissions to nanog(a)nanog.org<mailto:nanog@nanog.org> To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog<https://mailman.nanog.org/mailman/listinfo/nanog> or, via email, send a message with subject or body 'help' to nanog-request(a)nanog.org<mailto:nanog-request@nanog.org> You can reach the person managing the list at nanog-owner(a)nanog.org<mailto:nanog-owner@nanog.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: Cleveland/Cincinnati Co-location (Allen McKinley Kitchen (gmail)) 2. Re: Service Provider NetFlow Collectors (Aaron) 3. Re: Cleveland/Cincinnati Co-location (Shawn Ritchie) 4. Re: Announcing Peering-LAN prefixes to customers (Andy Davidson) 5. Report on Legal Barriers to RPKI Adoption (Christopher S. Yoo) 6. 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 (Dominik Bay) 7. Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 (Jeff Shultz) 8. Astronaut accidently calls 911 from space (Sean Donelan) 9. Re: Cellular backup connections (Dovid Bender) 10. Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 (Job Snijders) ---------------------------------------------------------------------- Message: 1 Date: Thu, 3 Jan 2019 10:50:45 -0500 From: "Allen McKinley Kitchen (gmail)" <allenmckinleykitchen(a)gmail.com<mailto:allenmckinleykitchen@gmail.com>> To: "Justin M. Streiner" <streinerj(a)gmail.com<mailto:streinerj@gmail.com>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: Cleveland/Cincinnati Co-location Message-ID: <91679AF9-E310-463C-B427-630F69C02222(a)gmail.com<mailto:91679AF9-E310-463C-B427-630F69C02222@gmail.com>> Content-Type: text/plain; charset=us-ascii +1 for Expedient. Not a current customer but a VERY satisfied former customer. (Decision to leave them was a foul case of penny-pincher mismanagement, above my pay grade and over my objections.) ..Allen > On Jan 3, 2019, at 01:00, Justin M. Streiner <streinerj(a)gmail.com<mailto:streinerj@gmail.com>> wrote: > >> On Tue, 1 Jan 2019, Mitchell Lewis wrote: >> >> I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. >> >> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. > > Expedient has two facilities in Cleveland that might be worth looking at. > > Thank you > jms ------------------------------ Message: 2 Date: Thu, 3 Jan 2019 10:40:44 +0900 From: Aaron <aaron_ppus(a)fmad.com<mailto:aaron_ppus@fmad.com>> To: "Michel 'ic' Luczak" <lists(a)benappy.com<mailto:lists@benappy.com>> Cc: Erik Sundberg <ESundberg(a)nitelusa.com<mailto:ESundberg@nitelusa.com>>, "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: Service Provider NetFlow Collectors Message-ID: <CABq4n+TREPexPGWJJRdgRJZSuLBhVpO9pEd5mxz+Vn7p122FaQ(a)mail.gmail.com<mailto:CABq4n+TREPexPGWJJRdgRJZSuLBhVpO9pEd5mxz+Vn7p122FaQ@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" Throwing my hat in the ring also (vendor from fmadio) https://github.com/fmadio/pcap2json<https://github.com/fmadio/pcap2json> Not exactly a newflow collector, its pcap -> flowgen -> elk on a single box, working very well so far, still work in progress. Problem with logstash is its too slow for high flow rates. So we did everything inside the flow generator for direct ELK bulk uploads removing logstash completely. Cheers Aaron On Mon, 31 Dec 2018 at 18:40, Michel 'ic' Luczak <lists(a)benappy.com<mailto:lists@benappy.com>> wrote: > Don’t underestimate good old ELK > https://www.elastic.co/guide/en/logstash/current/netflow-module.html<https://www.elastic.co/guide/en/logstash/current/netflow-module.html> > + https://github.com/robcowart/elastiflow<https://github.com/robcowart/elastiflow> > > BR, ic > > On 31 Dec 2018, at 04:29, Erik Sundberg <ESundberg(a)nitelusa.com<mailto:ESundberg@nitelusa.com>> wrote: > > Hi Nanog…. > > We are looking at replacing our Netflow collector. I am wonder what other > service providers are using to collect netflow data off their Core and Edge > Routers. Pros/Cons… What to watch out for any info would help. > > We are mainly looking to analyze the netflow data. Bonus if it does ddos > detection and mitigation. > > We are looking at > ManageEngine Netflow Analyzer > PRTG > Plixer – Scrutinizer > PeakFlow > Kentik > Solarwinds NTA > > > Thanks in advance… > > Erik > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190103/2975478b/atta…<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/2975478b/atta…>> ------------------------------ Message: 3 Date: Thu, 3 Jan 2019 11:21:32 -0600 From: Shawn Ritchie <me(a)shawnritchie.com<mailto:me@shawnritchie.com>> To: "Allen McKinley Kitchen (gmail)" <allenmckinleykitchen(a)gmail.com<mailto:allenmckinleykitchen@gmail.com>> Cc: "Justin M. Streiner" <streinerj(a)gmail.com<mailto:streinerj@gmail.com>>, NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: Cleveland/Cincinnati Co-location Message-ID: <19433FF4-0E0C-4D7A-9CF2-CF385AE0AAB1(a)fastmail.fm<mailto:19433FF4-0E0C-4D7A-9CF2-CF385AE0AAB1@fastmail.fm>> Content-Type: text/plain; charset=utf-8 On Jan 3, 2019, at 9:50 AM, Allen McKinley Kitchen (gmail) <allenmckinleykitchen(a)gmail.com<mailto:allenmckinleykitchen@gmail.com>> wrote: > > +1 for Expedient. Not a current customer but a VERY satisfied former customer. (Decision to leave them was a foul case of penny-pincher mismanagement, above my pay grade and over my objections.) > > ..Allen > >> On Jan 3, 2019, at 01:00, Justin M. Streiner <streinerj(a)gmail.com<mailto:streinerj@gmail.com>> wrote: >> >>> On Tue, 1 Jan 2019, Mitchell Lewis wrote: >>> >>> I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. >>> >>> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. >> >> Expedient has two facilities in Cleveland that might be worth looking at. >> >> Thank you >> jms I’m in Expedient’s Cleveland DC and will second that they’re decent. — Shawn ------------------------------ Message: 4 Date: Thu, 3 Jan 2019 20:08:46 +0000 From: Andy Davidson <andy(a)nosignal.org<mailto:andy@nosignal.org>> To: Dominic Schallert <ds(a)schallert.com<mailto:ds@schallert.com>> Cc: "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: Announcing Peering-LAN prefixes to customers Message-ID: <34E9593E-5004-4A01-BAFC-E56CA6520433(a)nosignal.org<mailto:34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org>> Content-Type: text/plain; charset="utf-8" Hi, Dominic -- On 20/12/2018, 17:49, Dominic Schallert <ds(a)schallert.com<mailto:ds@schallert.com>> wrote: > this might be a stupid question but today I was discussing with a colleague if > Peering-LAN prefixes should be re-distributed/announced to direct customers/peers. > My standpoint is that in any case, Peering-LAN prefixes should be filtered and not > announced to peers/customers because a Peering-LAN represents some sort of > DMZ and there is simply no need for them to be reachable by third-parties not being > physically connected to an IXP themselves. There are no stupid questions! It is a good idea to not BGP announce and perhaps also to drop traffic toward peering LAN prefixes at customer-borders, this was already well discussed in the thread. But there wasn’t a discussion on how we got to this point. Until the Cloudflare 2013 BGP speaker attack, that sought to flood Cloudflare’s transfer networks and exchange connectivity (and with it saturating IXP inter-switch links and IXP participant ports), it was common for IXP IPv4/6 peering LANs to be internet reachable and BGP transited. This facilitated troubleshooting (e.g. traceroutes showing peering lan interfaces in traceroutes instead of ‘starring out’) and PMTUD (e.g. see recommendation in https://www.ripe.net/ripe/mail/archives/ipv6-wg/2011-July/001839.html<https://www.ripe.net/ripe/mail/archives/ipv6-wg/2011-July/001839.html> which actually asked for IXP peering LANs to be announced). There are good reasons to announce but there are better reasons to filter. The security benefits of filtering outweigh the upsides on today’s internet, but fashions and best practice may further evolve over time. Andy -- Andy Davidson Director, Asteroid International BV www.asteroidhq.com<http://www.asteroidhq.com> Director, Euro-IX - The European Internet Exchange Association www.euro-ix.net<http://www.euro-ix.net> ------------------------------ Message: 5 Date: Thu, 3 Jan 2019 20:51:56 +0000 From: "Christopher S. Yoo" <csyoo(a)law.upenn.edu<mailto:csyoo@law.upenn.edu>> To: "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Cc: David Wishnick <dwishn(a)law.upenn.edu<mailto:dwishn@law.upenn.edu>> Subject: Report on Legal Barriers to RPKI Adoption Message-ID: <BYAPR01MB4936273F035E0BE12EB3DCD8FD8D0(a)BYAPR01MB4936.prod.exchangelabs.com<mailto:BYAPR01MB4936273F035E0BE12EB3DCD8FD8D0@BYAPR01MB4936.prod.exchangelabs.com>> Content-Type: text/plain; charset="utf-8" As many of you know, the prospects for widespread RPKI adoption grew more promising in 2018. Cloudflare issued route origin authorizations ("ROAs") to cover 25% of its prefixes, including its 1.1.1.1<http://1.1.1.1> resolver and DNS servers. NTT began treating RPKI ROAs as if they were IRR route(6)-objects. Google announced its intention to begin filtering routes in early 2019. The Mutually Agreed Norms for Routing Security now has over 100 network operators signed on. Still, as 2019 begins, many worry that legal issues are hindering RPKI adoption. This is especially true for North American networks, which have a comparatively low percentage of IPv4 space covered by ROAs, and whose ROAs are comparatively underutilized by parties using RPKI-based route origin validation ("ROV") to inform their routing decisions. My coauthor (David Wishnick) and I have spent the past year delving into the legal issues surrounding RPKI. Today, we are publicizing our report on how the network operator community should address these issues. It is available here<https://ssrn.com/abstract=3308619<https://ssrn.com/abstract=3308619>>. If you are interested in the future of routing security, we encourage you to read it (or its Executive Summary). We've tried to keep the legalese to a minimum. RPKI was a major topic of discussion at NANOG 74 and ARIN 42 in Vancouver. Going forward, we expect to continue a fruitful dialogue about how the network operator community can reduce the legal barriers to RPKI adoption. Here is a summary of our recommendations: On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing access to the RPKI repository offered by ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed to ensure the agreement is binding. Regarding ROV: 1. The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA altogether. This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI repository. Second, because the legal risks faced by ARIN in an RPA-free world are ultimately uncertain, it would also be reasonable for ARIN to maintain the RPA for the purposes of contractually allocating risks to the parties best positioned to reduce and mitigate them. If ARIN keeps the RPA, ARIN should consider removing the RPA's indemnification clause, instead relying solely on the RPA's disclaimers of warranties and limitations of liability, or at least reducing the indemnification clause's scope to eliminate the problem of moral hazard. 2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. 3. The network operator community and ARIN should broadly publicize ARIN's policy of revising various RPA clauses for government entities that are prohibited from agreeing to them. 4. In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development imposed by the RPA's prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved developers to make use of RPKI information as an input into more sophisticated services. 5. Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information created with RPKI as an input for research and analysis purposes. 6. As a general alternative, the Internet community should consider whether to develop a separate corporate entity that would be responsible for operational aspects of RPKI repository provision. That corporation could conduct such activities for the North American region, or on a worldwide basis. Regarding the ROA-issuance side of the equation, the principal legal obstacles stem from the terms and conditions found in ARIN's Registration Services Agreement ("RSA"), Legacy Registration Services Agreement ("LRSA"), and RPKI Terms of Service. Regarding these, the report recommends the following: 1. ARIN should consider adopting a pathway to provide RPKI services that would explicitly refrain from altering the existing balance of property and transferability rights associated with IP address allocations. 2. The network operator community and ARIN should broadly publicize ARIN's policy of revising certain RSA/LRSA and RPKI Terms of Service clauses for government entities that are prohibited from agreeing to them. ARIN should also begin presenting the RPKI Terms of Service to newly-onboarded members alongside their RSA/LRSA, so that organizations spend less time dealing with legal issues overall. Separately, the report recommends that the network operator community consider whether to encourage companies and the federal government to include RPKI adoption in procurement best practices or requirements. In tandem with recommendations designed to encourage adoption, the report also makes two recommendations concerning operational readiness for widespread RPKI deployment. Specifically: 1. To reduce any legal risks associated with RPKI, the network operator community should focus on adopting operational best practices. No system is 100% reliable across all contingencies; as a result, operators should prepare for outages and other headaches. RPKI implementations should be resilient in the face of such contingencies. 2. The five RIRs should work to ensure readiness for widespread RPKI adoption and strive to publicize deeper details on their service-level intentions to the Internet community. This research is supported by NSF Award No. 1748362. The contents of the report represent our independent views, not those of the NSF. Any mistakes, of course, are also ours alone. Christopher S. Yoo John H. Chestnut Professor of Law, Communication, and Computer & Information Science Founding Director, Center for Technology, Innovation and Competition University of Pennsylvania Law School 3501 Sansom St. Philadelphia, PA 19104-6204 (215) 746-8772 (o) (215) 573-2025 (f) csyoo(a)law.upenn.edu<mailto:csyoo@law.upenn.edu<mailto:csyoo@law.upenn.edu%3cmailto:csyoo@law.upenn.edu>> http://www.law.upenn.edu/faculty/csyoo/<http://www.law.upenn.edu/faculty/csyoo/> For more information on the Center for Technology, Innovation and Competition, see https://www.law.upenn.edu/institutes/ctic/<https://www.law.upenn.edu/institutes/ctic/>. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190103/82ae6154/atta…<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/82ae6154/atta…>> ------------------------------ Message: 6 Date: Thu, 3 Jan 2019 22:01:56 +0000 From: Dominik Bay <db(a)rrbone.net<mailto:db@rrbone.net>> To: "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 Message-ID: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06(a)rrbone.net<mailto:4E73CA49-E9B1-4F26-9986-D64DE9E0DB06@rrbone.net>> Content-Type: text/plain; charset="utf-8" I see the follwowing ASN transiting a leak concerning 192.208.19.0/24<http://192.208.19.0/24> originated by 4812 209 286 3320 5400 5511 6327 6461 6762 6830 8218 8220 8447 8551 9002 12956 The proper source is 32982 (Department of Energy). More details to be found here: https://bgpstream.com/event/171779<https://bgpstream.com/event/171779> And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0<http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0> Cheers, Dominik ------------------------------ Message: 7 Date: Thu, 3 Jan 2019 14:37:28 -0800 From: Jeff Shultz <jeffshultz(a)sctcweb.com<mailto:jeffshultz@sctcweb.com>> To: Dominik Bay <db(a)rrbone.net<mailto:db@rrbone.net>> Cc: "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 Message-ID: <CAGb3Bgf60fye4W5HwLXqwvv3K06sVJmBA6HNzJywsTRjVZumXg(a)mail.gmail.com<mailto:CAGb3Bgf60fye4W5HwLXqwvv3K06sVJmBA6HNzJywsTRjVZumXg@mail.gmail.com>> Content-Type: text/plain; charset="UTF-8" China Telecom originating a network that belongs to the agency that controls all things nuclear in the US... nothing suspicious there. On Thu, Jan 3, 2019 at 2:03 PM Dominik Bay <db(a)rrbone.net<mailto:db@rrbone.net>> wrote: > > I see the follwowing ASN transiting a leak concerning 192.208.19.0/24<http://192.208.19.0/24> originated by 4812 > > 209 > 286 > 3320 > 5400 > 5511 > 6327 > 6461 > 6762 > 6830 > 8218 > 8220 > 8447 > 8551 > 9002 > 12956 > > The proper source is 32982 (Department of Energy). > More details to be found here: https://bgpstream.com/event/171779<https://bgpstream.com/event/171779> > And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0<http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0> > > Cheers, > Dominik > > -- Jeff Shultz -- Like us on Social Media for News, Promotions, and other information!! <https://www.facebook.com/SCTCWEB/<https://www.facebook.com/SCTCWEB/>> <https://www.instagram.com/sctc_503/<https://www.instagram.com/sctc_503/>> <https://www.yelp.com/biz/sctc-stayton-3<https://www.yelp.com/biz/sctc-stayton-3>> <https://www.youtube.com/c/sctcvideos<https://www.youtube.com/c/sctcvideos>> _**** 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. ****_ ------------------------------ Message: 8 Date: Thu, 3 Jan 2019 17:45:00 -0500 (EST) From: Sean Donelan <sean(a)donelan.com<mailto:sean@donelan.com>> To: nanog(a)nanog.org<mailto:nanog@nanog.org> Subject: Astronaut accidently calls 911 from space Message-ID: <nycvar.OFS.7.76.4444.1901031742280.94156(a)cnex.qbaryna.pbz<mailto:nycvar.OFS.7.76.4444.1901031742280.94156@cnex.qbaryna.pbz>> Content-Type: text/plain; format=flowed; charset=US-ASCII I was disappointed that it was just a misdial. I was looking forward to how IP geolocation worked with 9-1-1 calls from space. I always wondered how that altitude parameter in 911 packets was used. :-) https://www.newsweek.com/astronaut-accidentally-calls-911-space-1276892<https://www.newsweek.com/astronaut-accidentally-calls-911-space-1276892> ------------------------------ Message: 9 Date: Thu, 3 Jan 2019 18:46:08 -0500 From: Dovid Bender <dovid(a)telecurve.com<mailto:dovid@telecurve.com>> To: Mark Milhollan <mlm(a)pixelgate.net<mailto:mlm@pixelgate.net>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: Cellular backup connections Message-ID: <CAM3TTh0mNx4apFpZFTXEzW4=HUM4OQND65gW3f5V2=jtdGpVyw(a)mail.gmail.com<mailto:CAM3TTh0mNx4apFpZFTXEzW4=HUM4OQND65gW3f5V2=jtdGpVyw@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" All, Thanks for all of the feedback. I was on site today and noticed two things. 1) As someone mentioned it could be for static IP's they have the traffic going to a specific location. The POP is in NJ there was a min. latency of 120ms which prob had to do with this. 2) I was watching the ping times and it looked something like this: 400ms 360ms 330ms 300ms 260ms 210ms 170ms 140ms 120ms 400ms 375ms It seems to have been coming in "waves". I assume this has to do with "how cellular work" and the signal. I tried moving it around by putting it down low on the floor, moving it locations etc. and saw the same thing every time. I am going to try Verizon next and see how it goes. On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan <mlm(a)pixelgate.net<mailto:mlm@pixelgate.net>> wrote: > On Fri, 28 Dec 2018, Dovid Bender wrote: > > >I finally got around to setting up a cellular backup device in our new > POP. > > >When SSH'ing in remotely the connection seems rather slow. > > Perhaps using MOSH can help make the interactive CLI session less > annoying. > > >Verizon they charge $500.00 just to get a public IP and I want to avoid > >that if possible. > > You might look into have it call out / maintain a connection back to > your infrastructure. > > > /mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190103/b4c3f157/atta…<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/b4c3f157/atta…>> ------------------------------ Message: 10 Date: Fri, 4 Jan 2019 11:21:32 +0300 From: Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> To: Dominik Bay <db(a)rrbone.net<mailto:db@rrbone.net>> Cc: "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 Message-ID: <CACWOCC8DRPSWCvsa6n-Yyf0LwR=81APcL+HAvgOF9GHwvYhvuA(a)mail.gmail.com<mailto:CACWOCC8DRPSWCvsa6n-Yyf0LwR=81APcL+HAvgOF9GHwvYhvuA@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" Dear all, NTT / AS 2914 deployed explicit filters to block this BGP announcement from AS 4134. I recommend other operators to do the same. I’d also like to recommend AS 32982 to remove the AS_PATH prepend on the /24 announcement so the counter measure is more effective. Kind regards, Job On Fri, Jan 4, 2019 at 1:02 Dominik Bay <db(a)rrbone.net<mailto:db@rrbone.net>> wrote: > I see the follwowing ASN transiting a leak concerning 192.208.19.0/24<http://192.208.19.0/24> > originated by 4812 > > 209 > 286 > 3320 > 5400 > 5511 > 6327 > 6461 > 6762 > 6830 > 8218 > 8220 > 8447 > 8551 > 9002 > 12956 > > The proper source is 32982 (Department of Energy). > More details to be found here: https://bgpstream.com/event/171779<https://bgpstream.com/event/171779> > And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0<http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0> > > Cheers, > Dominik > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190104/0c84b757/atta…<http://mailman.nanog.org/pipermail/nanog/attachments/20190104/0c84b757/atta…>> End of NANOG Digest, Vol 132, Issue 4 *************************************

3 3

IP Dslams
by Nick Edwards 06 Jan '19

06 Jan '19

Howdy, We have a requirement for an aged care facility to provide voice and data, we have the voice worked out, but data, WiFi is out of the question, so are looking for IP-Dslams, preferably a system that is all-in-one, or self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has a property managment API, or even just a webpage manager where admin can add in new residents when they arive, or delete when they depart I know these used to be available many years ago, but that vendor has like many vanished, only requirement is for ADSL2+, prefer units with either 48 ports or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 etc) If anyone knows of such units, would appreciate some details on them, brand/model suppliers if known, etc, we can try get out google fu back if we have some steering:) Thank Y'all (resent - original never made it to the list for some gremlin reason)

14 23

Verizon IDE
by Mitchell Lewis 05 Jan '19

05 Jan '19

How common is it for Verizon to deliver "Internet Dedicated Ethernet" over sonet? Ran into a situation where the canoga-perkins nte was uplinked to a Flashwave 4100es in the basement (uplinked by an OC-48). There is in a Verizon ILEC area. Thanks & Regards, Mitchell Lewis mlewis(a)techcompute.net

3 2

Re: Changing upstream providers, opinions/thoughts on 123.net and cogent
by Neader, Brent 05 Jan '19

05 Jan '19

Looks like they already are? https://bgp.he.net/AS14374 Depending on which peer you might be replacing 123.net or cogent with, that could possibly change someone’s opinion. However, at least from past topics on this, given cogent history with peering issues (such as HE.net cake), I think one would certainly want to understand what impact peering/routing quirks would cause them and their ability to work around them before selecting cogent. Given I doubt your international reach is a big deal, and given 123.net is more of a tier2 (https://bgp.he.net/AS12129) with local and regional peering ( https://www.peeringdb.com/net/3899 ), they could be better suited for your traffic patterns and local customers? Also if you are not already interconnected with 123.net from a transport perspective, given their footprint in the state, there could be opportunities for an NNI to expand your reach to help interconnect your customer’s locations (aka customer has a branch office inside and outside your direct footprint and wants ELAN type service). I have looked at them before but never got serious, and thus cannot offer any input on their actual service or support. From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Ben Cannon Sent: Friday, January 4, 2019 8:16 PM To: Aaron Henderson <ahenderson(a)avci.net> Cc: nanog(a)nanog.org Subject: EXT_Re: Changing upstream providers, opinions/thoughts on 123.net and cogent Run BGP and use multiple upstream providers as soon as you can. -Ben On Jan 4, 2019, at 4:57 AM, Aaron Henderson <ahenderson(a)avci.net<mailto:ahenderson@avci.net>> wrote: I work for a rural ISP and the powers that be have been thinking about changing our upstream providers. The big names on the table right now are 123.net<http://123.net/> and Cogent. I, along with the people in my circle, do not have any experience with these providers and all we are getting is what sales are dishing us. I was hoping some of you here might have experience with these providers and could share your experiences and opinions. Thanks, A

1 0

How to choose a transport(terrestrial/subsea)
by Mehmet Akcin 04 Jan '19

04 Jan '19

Thank you everyone incredible amounts of responses for my how to choose a transit provider smail earlier. How do you choose transport & backbone? Looking at key aspects like route information, diversity, aerial vs under ground fiber, age of fiber, outage history, length, but what else? I will get both transport and transit as two seperate blogs. I will also submit as a nanog paper for the meeting after next, or maybe next? I am probably too late by now. Thank you for all your help. I will add your names to the thank you line ;-) -- Mehmet +1-424-298-1903

14 25

Weekly Routing Table Report
by cscora＠apnic.net 04 Jan '19

04 Jan '19

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 05 Jan, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 732608 Prefixes after maximum aggregation (per Origin AS): 281600 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 352811 Total ASes present in the Internet Routing Table: 62818 Prefixes per ASN: 11.66 Origin-only ASes present in the Internet Routing Table: 54157 Origin ASes announcing only one prefix: 23519 Transit ASes present in the Internet Routing Table: 8661 Transit-only ASes present in the Internet Routing Table: 267 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 22 Number of instances of unregistered ASNs: 24 Number of 32-bit ASNs allocated by the RIRs: 25373 Number of 32-bit ASNs visible in the Routing Table: 20560 Prefixes from 32-bit ASNs in the Routing Table: 88488 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 263 Number of addresses announced to Internet: 2838813409 Equivalent to 169 /8s, 52 /16s and 218 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.1 Total number of prefixes smaller than registry allocations: 244490 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200435 Total APNIC prefixes after maximum aggregation: 56904 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 197571 Unique aggregates announced from the APNIC address blocks: 81259 APNIC Region origin ASes present in the Internet Routing Table: 9328 APNIC Prefixes per ASN: 21.18 APNIC Region origin ASes announcing only one prefix: 2633 APNIC Region transit ASes present in the Internet Routing Table: 1390 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4326 Number of APNIC addresses announced to Internet: 769208320 Equivalent to 45 /8s, 217 /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-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 216909 Total ARIN prefixes after maximum aggregation: 102896 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 216224 Unique aggregates announced from the ARIN address blocks: 103607 ARIN Region origin ASes present in the Internet Routing Table: 18302 ARIN Prefixes per ASN: 11.81 ARIN Region origin ASes announcing only one prefix: 6801 ARIN Region transit ASes present in the Internet Routing Table: 1842 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2528 Number of ARIN addresses announced to Internet: 1077014688 Equivalent to 64 /8s, 49 /16s and 240 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 200092 Total RIPE prefixes after maximum aggregation: 95539 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 196443 Unique aggregates announced from the RIPE address blocks: 116298 RIPE Region origin ASes present in the Internet Routing Table: 25720 RIPE Prefixes per ASN: 7.64 RIPE Region origin ASes announcing only one prefix: 11484 RIPE Region transit ASes present in the Internet Routing Table: 3611 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7702 Number of RIPE addresses announced to Internet: 716014656 Equivalent to 42 /8s, 173 /16s and 132 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 94946 Total LACNIC prefixes after maximum aggregation: 22030 LACNIC Deaggregation factor: 4.31 Prefixes being announced from the LACNIC address blocks: 96333 Unique aggregates announced from the LACNIC address blocks: 42307 LACNIC Region origin ASes present in the Internet Routing Table: 7953 LACNIC Prefixes per ASN: 12.11 LACNIC Region origin ASes announcing only one prefix: 2180 LACNIC Region transit ASes present in the Internet Routing Table: 1476 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5500 Number of LACNIC addresses announced to Internet: 173201152 Equivalent to 10 /8s, 82 /16s and 215 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 20203 Total AfriNIC prefixes after maximum aggregation: 4214 AfriNIC Deaggregation factor: 4.79 Prefixes being announced from the AfriNIC address blocks: 25774 Unique aggregates announced from the AfriNIC address blocks: 9097 AfriNIC Region origin ASes present in the Internet Routing Table: 1233 AfriNIC Prefixes per ASN: 20.90 AfriNIC Region origin ASes announcing only one prefix: 421 AfriNIC Region transit ASes present in the Internet Routing Table: 240 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 504 Number of AfriNIC addresses announced to Internet: 102971904 Equivalent to 6 /8s, 35 /16s and 58 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4656 515 522 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4644 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3011 1160 90 VIETEL-AS-AP Viettel Group, VN 45899 2985 1717 115 VNPT-AS-VN VNPT Corp, VN 4766 2815 11129 768 KIXS-AS-KR Korea Telecom, KR 9829 2749 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2500 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2408 4906 29 CTTNET China TieTong Telecommunications 17974 2253 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2140 437 181 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3503 1326 92 SHAW - Shaw Communications Inc., CA 11492 3484 225 600 CABLEONE - CABLE ONE, INC., US 22773 3309 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2604 5293 975 AMAZON-02 - Amazon.com, Inc., US 16625 2201 1229 1692 AKAMAI-AS - Akamai Technologies, Inc., 20115 2150 2754 533 CHARTER-20115 - Charter Communications, 18566 2138 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2095 349 129 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2087 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2076 5077 589 CENTURYLINK-US-LEGACY-QWEST - CenturyLi Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5261 1628 138 UNI2-AS, ES 39891 3517 185 20 ALJAWWALSTC-AS, SA 8551 3289 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2632 577 1935 AKAMAI-ASN1, US 12389 2228 2221 626 ROSTELECOM-AS, RU 34984 2049 338 528 TELLCOM-AS, TR 9121 1683 1691 17 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 8402 1292 544 17 CORBINA-AS OJSC "Vimpelcom", RU 9009 1222 131 684 M247, GB Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5470 3319 589 Uninet S.A. de C.V., MX 10620 3150 475 905 Telmex Colombia S.A., CO 11830 2679 371 71 Instituto Costarricense de Electricidad 6503 1649 449 54 Axtel, S.A.B. de C.V., MX 7303 1438 960 233 Telecom Argentina S.A., AR 28573 1186 2237 182 CLARO S.A., BR 6147 1079 377 29 Telefonica del Peru S.A.A., PE 3816 1025 511 112 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 939 143 67 Alestra, S. de R.L. de C.V., MX 13999 938 539 259 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1161 393 22 LINKdotNET-AS, EG 37611 898 107 9 Afrihost, ZA 36903 797 401 139 MT-MPLS, MA 36992 781 1411 44 ETISALAT-MISR, EG 24835 683 634 21 RAYA-AS, EG 8452 650 1731 19 TE-AS TE-AS, EG 29571 481 70 12 ORANGE-COTE-IVOIRE, CI 37492 459 470 57 ORANGE-, TN 37342 421 32 1 MOVITEL, MZ 15399 415 45 11 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5470 3319 589 Uninet S.A. de C.V., MX 12479 5261 1628 138 UNI2-AS, ES 7545 4656 515 522 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4644 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3517 185 20 ALJAWWALSTC-AS, SA 6327 3503 1326 92 SHAW - Shaw Communications Inc., CA 11492 3484 225 600 CABLEONE - CABLE ONE, INC., US 22773 3309 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3289 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 10620 3150 475 905 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5261 5123 UNI2-AS, ES 4538 4644 4570 ERX-CERNET-BKB China Education and Research Net 7545 4656 4134 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3517 3497 ALJAWWALSTC-AS, SA 6327 3503 3411 SHAW - Shaw Communications Inc., CA 8551 3289 3246 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3309 3135 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3011 2921 VIETEL-AS-AP Viettel Group, VN 11492 3484 2884 CABLEONE - CABLE ONE, INC., US 45899 2985 2870 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 4200058511 PRIVATE 103.111.177.0/24 137522 OERL-AS-AP Origin Energy Retai 4200058511 PRIVATE 103.111.178.0/24 137522 OERL-AS-AP Origin Energy Retai 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.64.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:12 /9:10 /10:36 /11:99 /12:291 /13:568 /14:1127 /15:1913 /16:13341 /17:7877 /18:13854 /19:25515 /20:39677 /21:46098 /22:91160 /23:74548 /24:413605 /25:925 /26:820 /27:880 /28:32 /29:18 /30:9 /31:2 /32:191 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4113 5261 UNI2-AS, ES 6327 3266 3503 SHAW - Shaw Communications Inc., CA 11492 2764 3484 CABLEONE - CABLE ONE, INC., US 8551 2745 3289 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 39891 2689 3517 ALJAWWALSTC-AS, SA 22773 2549 3309 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2033 2138 MEGAPATH5-US - MegaPath Corporation, US 11830 2024 2679 Instituto Costarricense de Electricidad y Telec 30036 1843 2095 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2087 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1626 2:889 3:1 4:23 5:2411 6:43 7:1 8:1174 12:1876 13:303 14:1884 15:37 16:2 17:209 18:59 20:48 23:2563 24:2418 25:2 27:2551 31:2012 32:92 35:31 36:824 37:2998 38:1600 39:282 40:121 41:3157 42:730 43:2007 44:136 45:6478 46:3114 47:244 49:1333 50:1080 51:319 52:1088 54:363 55:1 56:6 57:41 58:1715 59:1070 60:461 61:2090 62:2211 63:1809 64:5093 65:2200 66:4823 67:2685 68:1165 69:3443 70:1145 71:603 72:2278 74:2745 75:407 76:525 77:1707 78:1720 79:2320 80:1645 81:1416 82:1063 83:879 84:1077 85:2130 86:559 87:1502 88:992 89:2399 90:210 91:6535 92:1224 93:2359 94:2373 95:3117 96:909 97:349 98:934 99:169 100:88 101:1162 102:335 103:19647 104:3564 105:242 106:897 107:1834 108:703 109:3611 110:1633 111:1911 112:1395 113:1380 114:1153 115:1720 116:1618 117:1924 118:2204 119:1685 120:1150 121:1029 122:2363 123:1636 124:1451 125:1942 128:1195 129:690 130:523 131:1644 132:716 133:213 134:1043 135:229 136:539 137:673 138:1931 139:790 140:569 141:762 142:803 143:996 144:897 145:504 146:1250 147:775 148:1706 149:799 150:780 151:998 152:935 153:324 154:2413 155:965 156:1639 157:852 158:658 159:1899 160:1491 161:904 162:2654 163:772 164:1121 165:1586 166:465 167:1350 168:3207 169:866 170:3985 171:496 172:1072 173:2143 174:996 175:879 176:2274 177:4050 178:2558 179:1292 180:2097 181:2355 182:2678 183:1352 184:1139 185:14512 186:3666 187:2463 188:2975 189:2087 190:8281 191:1402 192:10021 193:6483 194:5332 195:4046 196:2896 197:1733 198:5701 199:5964 200:7418 201:5006 202:10235 203:10195 204:4628 205:3022 206:3306 207:3281 208:3943 209:4190 210:3904 211:2009 212:3072 213:2826 214:1073 215:52 216:5978 217:2197 218:899 219:575 220:1834 221:997 222:980 223:1421 End of report

1 0

192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956
by Dominik Bay 04 Jan '19

04 Jan '19

I see the follwowing ASN transiting a leak concerning 192.208.19.0/24 originated by 4812 209 286 3320 5400 5511 6327 6461 6762 6830 8218 8220 8447 8551 9002 12956 The proper source is 32982 (Department of Energy). More details to be found here: https://bgpstream.com/event/171779 And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0 Cheers, Dominik

3 3

Cleveland/Cincinnati Co-location
by Mitchell Lewis 03 Jan '19

03 Jan '19

Good Evening All, I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. Thanks & Regards, Mitchell Lewis 203-816-0371<tel:+12038160371>

7 6

does emergency (911) dispatch uses IP ?
by Mankamana Mishra (mankamis) 02 Jan '19

02 Jan '19

Guys, While reading CL network down impacting 911 services, was trying to get more information about how does this network looks like. From end user to center, I guess VOIP is used. Wondering what is the communication method from Emergency service center to end units (Police, Fire or any other services). Do they also use IP ? or its Still Radio only ? if it is IP, do they use Unicast or multicast or broadcast ? Tried googling, but did not get much information. Any insight would be appreciated. Thanks Mankamana

3 4

CenturyLink RCA?
by Saku Ytti 02 Jan '19

02 Jan '19

Apologies for the URL, I do not know official source and I do not share the URLs sentiment. https://fuckingcenturylink.com/ Can someone translate this to IP engineer? What did actually happen? >From my own history, I rarely recognise the problem I fixed from reading the public RCA. I hope CenturyLink will do better. Best guess so far that I've heard is a) CenturyLink runs global L2 DCN/OOB b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU, I've had this failure mode) c) DCN had direct access to control-plane, and L2 congested control-plane resources causing it to deprovision waves Now of course this is entirely speculation, but intended to show what type of explanation is acceptable and can be used to fix things. Hopefully CenturyLink does come out with IP-engineering readable explanation, so that we may use it as leverage to support work in our own domains to remove such risks. a) do not run L2 DCN/OOB b) do not connect MGMT ETH (it is unprotected access to control-plane, it cannot be protected by CoPP/lo0 filter/LPTS ec) c) do add in your RFP scoring item for proper OOB port (Like Cisco CMP) d) do fail optical network up -- ++ytti

15 22