- Test - lists.nanog.org

WTR: 1-2RU @ Equinix Ashburn
by Jason Lixfeld 04 Feb '20

04 Feb '20

Hi, I’m wondering if anyone is looking to subsidize their Equinix Ashburn colo costs by way of carving out 1-2 RU to a friendly for a low density networking application. If so, I’d love to hear from you! Thanks in advance!

1 0

EVPN multicast route (multi home case ) implementation / deployment information
by Mankamana Mishra (mankamis) 04 Feb '20

04 Feb '20

Folks Wondering if there is any known implementation of EVPN multihome multicast routes which are defined in https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04 there is some change planned in NLRI , we want to make sure to have solution which does work well with existing implementation. Note: Discussion involves Nokia, Juniper, Cisco, Arista already. So looking for any other vendor who have implementation. Mankamana

2 1

Recommended DDoS mitigation appliance?
by Rabbi Rob Thomas 04 Feb '20

04 Feb '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, NANOG! I'm in the midst of rebuilding/upgrading our backbone and peering - sessions cheerfully accepted :) - and am curious what folks recommend in the DDoS mitigation appliance realm? Ideally it would be capable of 10Gbps and circa 14Mpps rate of mitigation. If you have a recommendation, I'd love to hear it and the reasons for it. If you have an alternative to an appliance that has worked well for you (we're a mix of Cisco and Juniper), I'm all ears. Private responses are fine, and I'm happy to summarize back to the list if there is interest. Thank you! Rob. - -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree." - Leo McKern -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAl3Rx08ACgkQQ+hhYvqF 8o0snw/8CxTOujcodNh/huMXZaUNlMNoNRz3IoPqBiAP9BZomMz9xqlpDW/qvWBF xhoJ07C0O0mo5ilNjnPR308uifIBu6ylw02PshOCU06dV0afgtndxGg5AoG9npUV 7uCi2afWaf22dq5TwKLut8QPNNQJTRzndX88xJw9MzzoBTemxRtM7ft4H3UhJ0hv oKo83FCNZQt36I+GZA9GBJeXM+o0f5h0w6fhRqARzttf6brJZdXgROyIQ7jptGuZ N3Yrjk/8RM4XKMnYbtIwl8NS3c0nEGN3ndn+Bz7p2FE7QJrZKonk/o03dvr2kU0Y 7gUQliOOzV9EsptVGyLCVyDJSElvXTBaps0giEVZhdmEIDJPWvBc+93j1g7xbmti 27lT6+5qBmEN0oKJWxXgtw9/n1yX9vsc7tXlgYDoXGhIlszdB3baRao1tYEp8BBQ hTGAULRfHe94tRzvOOQUQIuhzNcK1Q4E2jU6kzBB1wJsBD4zuHk+QIJLSHBmmnka VNKlQ+5zP8dmSMBp6k4feqAtt3hy0Bj+34FbdQZYPutIe3VXHEjpWI3jI9vKjhtC g7U/9CQIjVUl2APn1IllArpUpETBlNq7dSeJNUN/4Xh+eHglUnEn/m2kFG5mizmP d0YvLEVe0/+WzDUz+y3KxDVP5tdJT1VM46FHIgeiB4KrWNGRPUo= =uuel -----END PGP SIGNATURE-----

18 30

The curious case of 159.174.0.0/16
by Ronald F. Guilmette 03 Feb '20

03 Feb '20

[[ Fair warning to newcomers: I write and post longish pieces here regarding my various investigations of funny business I find going on within the IPv4 address space and the allocations and uses thereof. If you're looking for a quick 2 minute read then you are advised to skip this message now. ]] I confess that I have been meaning to write about the 159.174.0.0/16 legacy IPv4 block for quite some time now. What can I say? I was busy. The Present State of 159.174.0.0/16 ----------------------------------- I discovered quite some long time ago that this block was getting routing from a rather unusual place, and that the ASN in question was also announcing a few other nice juicy /16 legacy blocks, which by itself was more than a little suspicious. But that's not imporant now. Please allow me to just talk about who is routing this block at present, and who the alleged legitimate registrants are, going by ARIN's relevant current WHOIS record for this block: https://pastebin.com/raw/FBWMN9p3 As you can see, this block is registered to an entity located in Wilton, Connecticut. The block appears to have been originally assigned on 1992-05-11, well before the formation of ARIN. It is thus an unusually valuable "legacy" block. The first indication that something might be a bit off about this block is the contact phone number, +1-407-476-9854. In this modern era of number portability the area code portion of that may or may not have any real-world geographical implications at all, but it turns out to be notable, in this case, that area code 407 corresponds, historically, to the greater Orlando, Florida area and surrounding Florida counties. A quick bit of research reveals that there is in fact an entity calling itself Dunsnet, LLC and that it is located in Winter Park, Florida, a northern suburb of Orlando: http://search.sunbiz.org/Inquiry/CorporationSearch/SearchResultDetail?inqui… Further research on the Florida Secretary of State's web site confirms that this entity does exist, that it is "active", and that it has one and only one manager, that being another corporate entity called Ahosting, Inc.: http://search.sunbiz.org/Inquiry/CorporationSearch/SearchResultDetail?inqui… As you can see via the above link, Ahosting, Inc. has only two corporate directors, i.e. a Mr. Erkan Ozdogan and a Mr. Adnan Canturk, both apparently residents of Istanbul, Turkey. At the present time, 100% of the 159.174.0.0/16 legacy block is being routed by AS54163, aka Ahosting, Inc.: https://bgp.he.net/AS54163#_prefixes The question is: Is this proper? A Brief History of 159.174.0.0/16 --------------------------------- When the 159.174.0.0/16 block was first allocated and registered, way back on 1992-05-11 it was assigned at that time to a unit of the famous Dun & Bradstreet financial information company for use in connection with one of the company's early forays into the world of the Internet: Fortune Magazine, August 19, 1985: https://archive.fortune.com/magazines/fortune/fortune_archive/1985/08/19/66… "Dun & Bradstreet also operates DunsNet, a $20- million private telecommunications network completed in March, which connects customers in 155 cities directly to the company's mainframes." On June 8th, 1994, Dun & Bradstreet's "Dunsnet" operation announced that it had elected to partner with a European company named Eunetcom SA, which was itself a partnership between Deutsche Bundespost Telekom and France Telecom: https://www.cbronline.com/news/eunetcom_wins_dunsnet_pact/ In August, 1994, Eunetcom apparently elected to buy out its customer, Dunsnet: "The Information Superhighway" (Randall L. Carlson - 1996) https://bit.ly/2O7kV48 "Eunetcom is actively pursuing customers and entry into the North American market. Its first customer was worth $200 million over five years and was {subequently} acquired by purchasing the networking services of Dun & Bradstreet's DunsNet. DunsNet provides data communications services for the Dun & Bradstreet companies, a role that Eunetcom now assumes." https://www.postjobfree.com/resume/pumacu/unix-administrator-technical-anal… "In August 1994, DunsNet was acquired by eunetcom, a joint venture between Deutsche Telekom and France Telecom." As we all know, unlike the situation today, IPv4 blocks in the 1990s had essentially no monetary value. And thus the 159.174.0.0/16 block became forgotten and abandoned by its rightful owners, which is to say Deutsche Telekom and France Telecom. Fast forward some 16 years to June 29, 2011, on which date it appears that two clever fellows in Istanbul, Turkey began what would seem to be a quite deliberate, premeditated, and determined effort to take control of the (now quite valuable) 159.174.0.0/16 legacy block via the same sort of simple-minded ruse that had already, by that time, worked so well for others who likewise coveted various ARIN-administered large and valuable legacy IPv4 blocks. They simply pretended to be "Dunsnet" and began the process of requesting from ARIN complete control over "their" legacy block. ARIN apparently obliged and permitted these two Turkish geentleman to make various changes to the relevant ARIN WHOIS records. The official ARIN "WhoWas" historical records relating to the 159.174.0.0/16 block show quite clearly various changes being made to the relevant organization record on 06-29-2011, 09-24-2011, and again on 11-06-2017: https://pastebin.com/raw/WTgvjXg2 Also and similarly, changes were made to the NET-159-174-0-0-1 record for the block itself on 06-29-2011 and again on 11-06-2017: https://pastebin.com/raw/b3F1eTua These latter day changes to the relevant ARIN WHOIS records might have been and remained mostly unsuspicious had it not been for the creation, by the aforementioned two Turkish gentlemen, on 08/06/2012, of the new Florida LLC named "Dunsnet, LLC". (See link above.) In this context, it seems more than plausible that the name of this newly minted Florida LLC was chosen specifically and deliberately with the intent of hiding the facts regarding the illicit usurpation of the valuable 159.174.0.0/16 block. This pattern of apparent corporate-level identity theft is one that I have already seen on multiple previous occasions in association with fraud, perpetrated against some Regional Internet Registry (and ARIN in particular) with the goal being the theft of some sizable IPv4 legacy block. In fact, the only thing that is actually striking and somewhat remarkable in this case is the exact timing of the relevant events. As noted above, the relevant ARIN WHOIS records were, it appears, improperly fiddled on various dates in 2011. It is not immediately clear why ARIN would have allowed such manipulations in that year, given that the fradulent Florida shell company, Dunsnet, LLC was not actually incorporated until 08/06/2012 according to Florida state records. (See link above.) As noted above, official Florida state records for Dunsnet, LLC say that it has one and only one manager, that being Ahosting, Inc. As also noted above, two specific persons appear to be in control of Ahosting, Inc., Mr. Erkan Ozdogan and Mr. Adnan Canturk, both residents of Istanbul, Turkey. Despite the strikingly inconvenient commute that these two gentlemen must apparently have to deal with, these gentlemen quite obviously are the principals of at least the two Florida corporate entities named above. A look at some relevant web sites provides us with some further clues. Whereas ahosting.com formerly was associated with a fuilly functioning web site, that appears to not be the case at the present time. There is some downloadable content that can be reached via a URL which, in normal circumstances, would be expected to take you to the home page of this company, but the content in question is just some small bit of HTML that my various web browsers refuse to render for some reason. The same problem seems to also and likewise afflicts what should be the home page for dunsnet.com. And the same again also for the web site associated with tthe domain name mentioned in the WHOIS record for AS54163, ahostinginc.com. (Remember that this ASN is currently routing all of the 159.174.0.0/16 block.) In this last case however the content provides some clues as to an apparently related business known as aseohosting.com, where the "SEO" part apparently stands for "Search Engine Optimization". https://pastebin.com/raw/PnpgnA2A A simple Google search for Mr. Erkan Ozdogan turns up little of interest, however a similar search in the case of Mr. Adnan Canturk turns up multiple bits of his social media footprint: https://www.linkedin.com/in/adnan-canturk-24a66633 https://twitter.com/adnan_canturk The latter page provides us with a link to Mr. Canturk's personal web site, adnancanturk.com, but this also appears to have a dysfunctional home page. Nontheless, the text content that can be fetched from that URL further confirms Mr. Canturk's apparent connection to a business named "Aseohosting": https://pastebin.com/raw/NTW9nH6G Despite all of these dysfunctional web sites and home pages, the web site and the home page of aseohosting.com appears to be very much alive and well at present: https://www.aseohosting.com/ It is my hope that I will not have to go into too much detail in order to explain to the audience here why the use of large numbers of unique IPv4 addresses might be viewed by some as an integral part of any one of the net's myriad and almost entirely useless "SEO" schemes whose intent is the fundamental hoodwinking of search engines, such as Google, and their algorithms. The ultimate goal of these schemes, of course, is to snooker the search engines into displaying certain results above others. The bottom line is that it would appear that in this case, in the year 2011, Mr. Ozdogan and Mr. Canturk found themlseves a convenient and zero cost way of acquiring a sizable supply of IPv4 addreses, and that at the present time these valuable legacy IPv4 addrdesses are being employed (wasted?) on one big and undoubtedly fruitless search engine optimization scheme. To say that this is not the highest, best or most efficient use of the increasingly scarce supply of IPv4 addresses would, I'm sure, be a serious understatement. (To paraphrase my mother's early admonitions to me at dinner time "There are children starving in Asia would would like to have those IP addresses!") I must note that before posting this message I have made what I believe to be reasonable efforts to contact both Mr. Ozdogan and Mr. Canturk via every email address I could find for them, offering them the opportunity to respond to the preceeding facts and my interpretation of them, while promising those gentlemen that I would post their responses, whatever they might be. No response was received to this offer by press time. I also emailed John Curran, CEO of ARIN, prior to posting this message, and also offered him an opportunity to provide me with a response. This is his response: "ARIN does not comment on specific registry changes (as number resource change requests are made in confidence), but we do take matters of potential number resource fraud quite seriously. As you have chosen not to report this case of potential fraud, ARIN will not be investigating at this time, but we would welcome a fraud report if you believe that there is a need for investigation." -- John Curran, CEO, ARIN In closing I would just like to offer my personal observation that over time it appears to me that ARIN has been repeatedly victimized by this exact form of rather transparent fraud based on corporate identity theft. Instances of this date back to 2008, and now appear to have occurred as recently as last year. (More about that later.) I find this fact more than a little troubling, not least because of the apparent correlation between the specific IPv4 blocks that have been purloined in this manner and the congregation of Internet bad actors... spammers, hackers, and all manner of other Internet hooligans and miscreants... in and around the relevant stolen blocks. I understand that ARIN has neither the mandate to perform exhaustive investigations of all requests it receives, nor the kind of unlimited resources that might be required in order to do exhaustive investigations on a routine basis. That having been said however, in this and other such instances, the fradulent nature of the requests has been really rather obvious and transparent, requiring only the most modest amount of effort to note one or more of the glaring red flags and thus the need for further inquiry. I feel compelled to also note that ARIN's responses to cases such as this (e.g. the case of the 143.95.0.0/16 block) or, more accurately, the general lack of such responses may ultimately prove to be problematic, not just for ARIN but for the United States Department of Justice, e.g. in its current prosecution of federal criminal case 3:18-CR-04683-GPC: https://krebsonsecurity.com/2019/09/feds-allege-adconion-employees-hijacked… I am not immediately persuaded that a case could not be made, by the defense in that case, for selective prosecution. To an outsider such as myself, it seems that it might be difficult to defend and justify a decision to criminally prosecute one case in which ARIN was allegedly defrauded, apparently by persons of less-than-impressive means, while electing to -not- prosecute a half-billion dollar corporation, such as EIGI, against which the weight of the evidence may perhaps be equally compelling. This is the kind of slippery slope that one begins to traverse when one is guided by convenience or pragmatics, rather than by even-handed principal. Regards, rfg P.S. I have previously been in contact with a representative of Orange S.A., formerly France Telecom, and have requested that he arrange for his company to take back control of what would appear to be their partial ownership of the 159.174.0.0/16 block. To the best of my knowledge, no action has been taken by the company in this direction. To date I have to date been utterly unable to make contact with any representative of Deutsche Telekom in order to likewise encourage that company to reassert its apparently rightful claims to the 159.174.0.0/16 block. I would thus appreciate any referrals to any actual natural persons in that company with whom I might be able to discuss this matter. (I have a standing policy of never attempting to converse with unaccountable anonymized role accounts. Based on past experience, this is without exception an utter waste of my time.)

6 6

Re: Starting to Drop Invalids for Customers
by Jakob Heitz (jheitz) 03 Feb '20

03 Feb '20

Mark, Thanks for bringing this up again. I remember this from nearly 3 years ago when Randy brought it up. A bug was filed, but it disappeared in the woodwork. I have now given it the high priority tag that it should have had initially. Sorry about the mess up. In the meantime, you may be able to signal the validation state in iBGP once it is validated at the network edge. For an iBGP neighbor, use a configuration like this: neighbor 192.0.2.1 announce rpki state Regards, Jakob. Date: Sat, 11 Jan 2020 23:12:27 +0200 From: Mark Tinka <mark.tinka(a)seacom.mu> On 10/Jan/20 16:15, Lukas Tribus wrote: > Thanks for sharing all this. Regarding those 2 platforms specifically, > what release are you using here that does not blow up? On the ASR920, we are on 16(11)01a. On the ME3600X, we are on 15.6(2)SP6. > IIRC you had > some RPKI related crash bugs at some point in time? Yes, that was the first time we were deploying RPKI in 2014 and the code back then crashed the ME3600X. No such problem this time around. > - there is no ROA, so prefixes are supposed to be UNKNOWN on all nodes > - but IOS-XE prefers VALID over UNKNOWN (changing best path selection) > - iBGP is *always* VALID (even if it's really UNKNOWN), eBGP is > showing UNKNOWN, so iBGP is preferred over eBGP which breaks a lot of > assumptions and "hot potato" concepts (possible temporary routing > loops, other than of course different egress behavior) So your timing on this is ominous. In the last day or so, we had an issue with a customer on one of our ASR1006 edge routers that fell victim to this IOS XE stupidity. An alternate path toward them learned from a peer was sent back to the edge router they are connected to, which chose it over the local one because, well, it was an iBGP route. We didn't notice this issue with this customer since enabling ROV on this box weeks ago, which means the alternate route became available in the last 2 - 3 days, e.g., perhaps they turned up an alternative provider, or changed their routing toward them for us to see another path. Since this IOS XE stupidity is not configurable, what we've decided to do is disable ROV on all ASR1006 boxes for now. This is not a big issue for us. We've only got 2 customers using them as these boxes only carry non-Ethernet customers. While this should be an issue for our ASR920 and ME3600X routers also, it isn't because we run BGP-SD on those, i.e., even if the RIB will have all iBGP routes marked as Valid, they won't be installed in FIB, whereas the eBGP routes learned locally from the customer will. Having to create a ROA to solve this, while feasible, is inappropriate for a solution, especially when Juniper do it correctly. Randy and I complained to Cisco about this years back, and AFAIK, it was only fixed in IOS XR. That this is still going on in 2020 is silly, especially when it's clear that they are in violation of the RFC. > Apparently there is an IOS feature "Announce RPKI Validation State to > Neighbors" to transmit the *real* RPKI state in iBGP (so as opposed to > defaulting to VALID for all iBGP neighbors), I'm not sure if that > fixes this problem or not. It doesn't really address the root cause > (which is: unwanted and not configurable interference with the best > path selection algorithm) - but at it can at least hide it's symptoms. I've not tried communicating RPKI state between routers via BGP communities. One of the reasons I like RPKI is because it is a feature that works on each router independent of another. Each router has a discrete RTR session to a validator, and can make its own RPKI decisions without any regard for the rest of the network. And yet all routers in the network can do this and equally have a converged RPKI state, without ever speaking to one another. So the idea of having routers co-ordinate RPKI information through communities is one I am not so keen on, if I'm honest. Not only do you need to worry about inter-op issues between vendors, there is potential for problems when code changes over time. I'd rather not deal with that, especially since what Cisco are doing with IOS XE is simply a broken implementation. That said, if there is anyone out there who has done this and sees it as a solution to the problem, I'm sure this list would like to hear about it. > RPKI implementations should not touch best path selection. Dropping > RPKI invalids is the real use-case here, and if someones wants to > loc-pref based on RPKI status we should allow it (even if it doesn't > make a lot of sense), but having the RPKI implementation intervene in > the best path selection without the possibility to disable it is ... > frustrating. Agreed. At least, if IOS XE had a knob that could "set rpki [valid|notfound|invalid]" this would somewhat help. But alas, they don't :-(. You can only match on existing RPKI state. You cannot manually set RPKI state in IOS XE routing policy. I mean, how dumb is that? It's pretty presumptuous of Cisco to automatically apply policy for you re: RPKI in IOS XE, but then show they can do it right in IOS XR. Unreal! > > How much do you rely on "hot potato" routing for peers/transit and > customers? How does that work for you with RPKI unkowns? As above, we've disabled RPKI on all ASR1006 edge routers. It affects only 2 of our customers, so not an issue. I'll go through a few bottles of wine and some music this weekend as I summon up the energy to write to Cisco again to fix this. If I don't, I'll just keep sending money Juniper's way. Simple, and simpler! Mark.

3 3

AS16509 contacts in peering?
by Siyuan Miao 01 Feb '20

01 Feb '20

Hello, Anyone has peering contacts in AS16509 other than peering#amazon(dot)com? We'd like to establish peering with additional locations to balance the AnyCast traffic but unfortunately got no response in the last 6 months. Also, they forgot to update PeeringDB records on PTT Metro SP. Thanks,

1 0

AFRINIC: The Saga Continues
by Ronald F. Guilmette 01 Feb '20

01 Feb '20

My apologies to all. Certain of the blocks mentioned in my prior posting here have already been reclaimed, and are currently being routed by appropriate parties. In particular, these ones: 152.108.0.0/16 155.237.0.0/16 165.4.0.0/16 165.5.0.0/16 Also, I somehow managed to miss mentioning a few blocks that were also quite clearly stolen as part of this extensive and elaborate scheme, specifically these ones: 160.116.0.0/16 163.198.0.0/16 164.88.0.0/16 196.15.96.0/18 A full list of all of the stolen AFRINIC blocks that are still of ongoing concern at the present moment, taking into account the above adjustments, is available here: https://pastebin.com/raw/71zNNriB Note that many of the blocks listed at the link above have already been "reclaimed" as far as the AFRINIC WHOIS records are concerned. But because routing remains almost entirely decoupled from RIR WHOIS data bases, much of this "reclaimed" space is still being routed as I write this. The only difference is that now the space is being routed as bogons, rather than as "legitimately" allocated space. A summary of all of the current routing for all of the stolen AFRINIC IPv4 address space that is still of concern, including routing for recently reclaimed address space that AFRINIC will eventually be returning to its free pool is provided below. This list is sorted by the number of constituent stolen /24 blocks being routed by each listed network, thus showing the most major offenders at the top. A few footnotes concerning specific ASNs in this list follow below the listing. I urge everyone on this mailing list to share this data as widely as possible in and among the global networking connunity. In all cases noted below, the networks in question are unambiguously routing IP blocks that were obtained, in the first instance, via thefts perpetrated by one or more AFRINIC insiders and then resold on the black market in secretive deals. In many and perhaps most cases listed below, the relevant networks appear to have been more than happy to accept some cash in exchange for their services, while not looking all that carefully at the purported (but fradulent) "LOA" documents they were handed. (Repeated use of blatantly fradulent documents has been one of the consistant features of this entire ongoing criminal enterprise.) All routing data is derived from current data published by RIPEstat. ====================================================================== 3719 0 ?? UNROUTED IP SPACE 629 132165 PK Connect Communication 512 18013 HK Asline Limited 504 19969 US Joe's Datacenter, LLC 500 62355 CO Network Dedicated SAS 423 202425 SC IP Volume inc 286 58895 PK Ebone Network (PVT.) Limited 250 136525 PK Wancom (Pvt) Ltd. 192 18530 US Isomedia, Inc. 186 9009 GB M247 Ltd 134 262287 BR Maxihost LTDA 132 204655 NL Novogara LTD 79 132116 IN Ani Network Pvt Ltd 75 136384 PK Optix Pakistan (Pvt.) Limited 68 132422 HK Hong Kong Business Telecom Limited 60 137443 HK Anchnet Asia Limited 48 63956 AU Colocation Australia Pty Ltd 26 132335 IN LeapSwitch Networks Pvt Ltd 21 131284 AF Etisalat Afghan 20 139043 PK WellNetworks (Private) Limited 19 43092 JP OSOA Corporation., LTD 17 36351 US SoftLayer Technologies Inc. 16 56611 NL REBA Communications BV 16 199267 IL Netstyle A. Ltd 16 23679 ID Media Antar Nusa PT. 14 137085 IN Nixi 10 63018 US Dedicated.com 9 136782 JP Pingtan Hotline Co., Limited 8 45671 AU Servers Australia Pty. Ltd 8 57717 NL FiberXpress BV 7 49335 RU LLC "Server v arendy" 7 134451 SG NewMedia Express Pte Ltd 6 49367 IT Seflow S.N.C. Di Marco Brame' & C. 6 26754 ?? {{unknown organization}} 5 198504 AE Star Satellite Communications Company - PJSC 5 198381 AE Star Satellite Communications Company - PJSC 4 38001 SG NewMedia Express Pte Ltd 4 263812 AR TL Group SRL ( IPXON Networks ) 4 30827 GB Extraordinary Managed Services Ltd 4 42831 GB UK Dedicated Servers Limited 4 37200 NG SimbaNET Nigeria Limited 4 133495 PK Vision telecom Private limited 4 198394 AE Star Satellite Communications Company - PJSC 2 44066 DE First Colo GmbH 2 198247 AE Star Satellite Communications Company - PJSC 2 133933 PK NetSat Private Limited 2 328096 UG truIT Uganda Limited 2 38713 PK Satcomm (Pvt.) Ltd. 2 31122 IE Digiweb ltd 2 46562 US Total Server Solutions L.L.C. 2 13737 US Riverfront Internet Systems LLC 2 11990 US Unlimited Net, LLC 2 20860 GB Iomart Cloud Services Limited 2 45382 KR Ehostict 2 17216 US Dc74 Llc 2 16637 ZA Mtn Sa 2 53999 CA Priority Colo Inc 1 23470 US ReliableSite.Net LLC 1 35074 NG Cobranet Limited 1 19832 ZA Link Data Group 1 43945 IL Netstyle A. Ltd 1 134917 IN Ragsaa Communication pvt. ltd. 1 203833 DE First Colo GmbH ====================================================================== The actual current route announcements corresponding to all of the above are listed in the table given here, which is sorted by ASN: https://pastebin.com/raw/XQyJ8EK2 Footnotes: [1] AS62355 gives all indications of being a false front fradulent network, possibly one that was set up by one or more of the black market dealers involved in this case. There is no actual web site associated with its contact domain (networkdedicated.com) at present, the alleged contact phone number in the associated AS WHOIS record was non-orking when I tried it, and the street address given for this entity in Bogotá, Columbia, is one that Google maps cannot locate. Traceroutes to the one and only IPv4 block that is being routed by this AS and that is actually registed to the company itself (185.39.8.0/22) do not terminate in Columbia, South America, as one would expectm, based on the WHOIS, but rather such traceroutes dead- end somwhere on the network of core-backbone.com (Core-Backbone GmbH, Germany) in the general vicinity of Amsterdam, Netherlands. [2] The networks of AS202425 (IP volume, Inc. - Seychelles), AS204655 (Novogara, Ltd. - Netherlands), AS56611 (REBA Communications BV - Netherlands), and AS57717 (FiberXpress BV - Netherlands), are all believed by me to be onwed and controled by a certain pair of Dutch gentlemen who I have previously posted about. For more information on these characters, please google for "Ecatel" and/or "Quasi Networks". Both of those are, I believe, demonstratably the predecessors of what is now called "IP volume, Inc." [3] AS199267 (Netstyle A. Ltd. - Israel) and AS43945 (Netstyle A. Ltd. - Israel) belongs to one of the persons featured in Jan Vermeulen's detailed December 4th report on this whole AFRINIC caper, i.e. the particular fellow who has been going around passing out fradulent LOAs of such shockingly low quality that one wonders why he even bothers. [4] AS26754 was formerly an AFRINIC-assigned ASN which was assigned to the entirely fictitious business entity called "ITC'. That entity appears to have just been an imaginary concoction of Mr. Ernest Byaruhanga, formerly of AFRINIC, and now the target of an ongoing crimininal investigation in Africa, and/or other AFRINIC insiders who worked with or along side Mr. Byaruhanga to criminally strip assets from AFRINIC and its legacy block holders. The registration for this AS number has now been withdrawn by AFRINIC, thus rendering the ASN itself a bogon. [5] AS19832 ("Link Data Group") is yet another fiction that was manufactured out of -nearly- whole cloth, either by Mr. Byaruhanga and/or by other AFRINIC insiders who were working with him. It is not immediately clear why this ASN is still registered, let alone why is its route announcements are still being accepted or propagated anywhere.

5 5

CBS All acess/irdeto
by Michael Crapse 31 Jan '20

31 Jan '20

Our eyeball customers all of a sudden can no longer reach their CBS all access content. Inspection of the network connections now show a 403 error when trying to post to https://cbsi.live.ott.irdeto.com/widevine/getlicense code: 100214 message: "The request originated from ip address 196.53.97.0 which is not included in the JWT ips claim." I'm going to assume that they randomly started geolocating differently. Wonder if it's either CBS, or irdeto that can help us resolve our IP block 196.53.96.0/22 issues.

2 1

Weekly Routing Table Report
by cscora＠apnic.net 31 Jan '20

31 Jan '20

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 01 Feb, 2020 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 793947 Prefixes after maximum aggregation (per Origin AS): 302112 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 388441 Total ASes present in the Internet Routing Table: 66890 Prefixes per ASN: 11.87 Origin-only ASes present in the Internet Routing Table: 57486 Origin ASes announcing only one prefix: 24176 Transit ASes present in the Internet Routing Table: 9404 Transit-only ASes present in the Internet Routing Table: 288 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 34 Max AS path prepend of ASN (132972) 29 Prefixes from unregistered ASNs in the Routing Table: 1298 Number of instances of unregistered ASNs: 1299 Number of 32-bit ASNs allocated by the RIRs: 30389 Number of 32-bit ASNs visible in the Routing Table: 24990 Prefixes from 32-bit ASNs in the Routing Table: 114681 Number of bogon 32-bit ASNs visible in the Routing Table: 21 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 1125 Number of addresses announced to Internet: 2852816000 Equivalent to 170 /8s, 10 /16s and 132 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.4 Total number of prefixes smaller than registry allocations: 266322 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 210695 Total APNIC prefixes after maximum aggregation: 61420 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 204156 Unique aggregates announced from the APNIC address blocks: 84890 APNIC Region origin ASes present in the Internet Routing Table: 10335 APNIC Prefixes per ASN: 19.75 APNIC Region origin ASes announcing only one prefix: 2869 APNIC Region transit ASes present in the Internet Routing Table: 1537 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 33 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5383 Number of APNIC addresses announced to Internet: 768326144 Equivalent to 45 /8s, 203 /16s and 186 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 233287 Total ARIN prefixes after maximum aggregation: 107371 ARIN Deaggregation factor: 2.17 Prefixes being announced from the ARIN address blocks: 231091 Unique aggregates announced from the ARIN address blocks: 116754 ARIN Region origin ASes present in the Internet Routing Table: 18392 ARIN Prefixes per ASN: 12.56 ARIN Region origin ASes announcing only one prefix: 6756 ARIN Region transit ASes present in the Internet Routing Table: 1908 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: 3144 Number of ARIN addresses announced to Internet: 1078449664 Equivalent to 64 /8s, 71 /16s and 214 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 224318 Total RIPE prefixes after maximum aggregation: 104312 RIPE Deaggregation factor: 2.15 Prefixes being announced from the RIPE address blocks: 221116 Unique aggregates announced from the RIPE address blocks: 130594 RIPE Region origin ASes present in the Internet Routing Table: 26771 RIPE Prefixes per ASN: 8.26 RIPE Region origin ASes announcing only one prefix: 11688 RIPE Region transit ASes present in the Internet Routing Table: 3792 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8872 Number of RIPE addresses announced to Internet: 723775104 Equivalent to 43 /8s, 35 /16s and 238 /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: 102985 Total LACNIC prefixes after maximum aggregation: 23759 LACNIC Deaggregation factor: 4.33 Prefixes being announced from the LACNIC address blocks: 104184 Unique aggregates announced from the LACNIC address blocks: 45364 LACNIC Region origin ASes present in the Internet Routing Table: 9373 LACNIC Prefixes per ASN: 11.12 LACNIC Region origin ASes announcing only one prefix: 2388 LACNIC Region transit ASes present in the Internet Routing Table: 1765 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: 6940 Number of LACNIC addresses announced to Internet: 174168320 Equivalent to 10 /8s, 97 /16s and 153 /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: 21363 Total AfriNIC prefixes after maximum aggregation: 4482 AfriNIC Deaggregation factor: 4.77 Prefixes being announced from the AfriNIC address blocks: 32275 Unique aggregates announced from the AfriNIC address blocks: 9846 AfriNIC Region origin ASes present in the Internet Routing Table: 1358 AfriNIC Prefixes per ASN: 23.77 AfriNIC Region origin ASes announcing only one prefix: 475 AfriNIC Region transit ASes present in the Internet Routing Table: 264 Average AfriNIC Region AS path length visible: 5.0 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 651 Number of AfriNIC addresses announced to Internet: 107333120 Equivalent to 6 /8s, 101 /16s and 198 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 5235 642 598 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4622 4192 73 ERX-CERNET-BKB China Education and Rese 7552 3303 1331 24 VIETEL-AS-AP Viettel Group, VN 45899 3123 1787 108 VNPT-AS-VN VNPT Corp, VN 7713 2696 813 498 TELKOMNET-AS-AP PT Telekomunikasi Indon 9808 2606 9043 62 CMNET-GD Guangdong Mobile Communication 4766 2264 11101 566 KIXS-AS-KR Korea Telecom, KR 9498 2224 433 213 BBIL-AP BHARTI Airtel Ltd., IN 9829 2145 1374 236 BSNL-NIB National Internet Backbone, IN 4755 2136 441 195 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 7155 4047 280 27 VIASAT-SP-BACKBONE, US 11492 3926 260 654 CABLEONE, US 16509 3784 7728 1670 AMAZON-02, US 22773 3522 2971 151 ASN-CXA-ALL-CCI-22773-RDC, US 6327 3365 1324 93 SHAW, CA 16625 2976 1560 2137 AKAMAI-AS, US 209 2343 5075 532 CENTURYLINK-US-LEGACY-QWEST, US 30036 2291 358 92 MEDIACOM-ENTERPRISE-BUSINESS, US 20115 2138 2780 520 CHARTER-20115, US 18566 2059 405 103 MEGAPATH5-, 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 12479 5855 1622 133 UNI2-AS, ES 39891 4034 219 19 ALJAWWALSTC-AS, SA 31334 3431 484 13 KABELDEUTSCHLAND-AS, DE 8551 3092 379 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2817 450 1942 AKAMAI-ASN1, US 12389 2420 2244 700 ROSTELECOM-AS, RU 9009 2073 220 1119 M247, GB 34984 2067 348 557 TELLCOM-AS, TR 9121 1932 1691 18 TTNET, TR 13188 1604 100 47 TRIOLAN, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6211 3300 610 Uninet S.A. de C.V., MX 10620 3357 533 471 Telmex Colombia S.A., CO 11830 2681 369 63 Instituto Costarricense de Electricidad 6503 1683 323 390 Axtel, S.A.B. de C.V., MX 7303 1484 1030 266 Telecom Argentina S.A., AR 28573 1267 2235 193 CLARO S.A., BR 13999 1182 504 288 Mega Cable, S.A. de C.V., MX 3816 1120 562 134 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 1100 379 39 Telefonica del Peru S.A.A., PE 11172 955 112 70 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1100 393 23 LINKdotNET-AS, EG 24835 1097 566 24 RAYA-AS, EG 36992 1039 1535 73 ETISALAT-MISR, EG 36903 876 452 97 MT-MPLS, MA 6713 613 1863 34 IAM-AS, MA 29571 560 68 12 ORANGE-COTE-IVOIRE, CI 37342 476 32 1 MOVITEL, MZ 36935 383 522 40 Vodafone-, EG 15399 355 45 10 WANANCHI-, KE 23889 351 231 15 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6211 3300 610 Uninet S.A. de C.V., MX 12479 5855 1622 133 UNI2-AS, ES 7545 5235 642 598 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4622 4192 73 ERX-CERNET-BKB China Education and Rese 7155 4047 280 27 VIASAT-SP-BACKBONE, US 39891 4034 219 19 ALJAWWALSTC-AS, SA 11492 3926 260 654 CABLEONE, US 16509 3784 7728 1670 AMAZON-02, US 22773 3522 2971 151 ASN-CXA-ALL-CCI-22773-RDC, US 31334 3431 484 13 KABELDEUTSCHLAND-AS, DE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 12479 5855 5722 UNI2-AS, ES 7545 5235 4637 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4622 4549 ERX-CERNET-BKB China Education and Research Net 7155 4047 4020 VIASAT-SP-BACKBONE, US 39891 4034 4015 ALJAWWALSTC-AS, SA 31334 3431 3418 KABELDEUTSCHLAND-AS, DE 22773 3522 3371 ASN-CXA-ALL-CCI-22773-RDC, US 7552 3303 3279 VIETEL-AS-AP Viettel Group, VN 11492 3926 3272 CABLEONE, US 6327 3365 3272 SHAW, CA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Net Originated Transit AS Transit AS Name 17076 UNALLOCATED 8.12.244.0/24 3356 LEVEL3, US 62828 UNALLOCATED 8.21.130.0/24 3356 LEVEL3, US 393266 UNALLOCATED 8.23.52.0/24 174 COGENT-174, US 62485 UNALLOCATED 8.23.229.0/24 3356 LEVEL3, US 32985 UNALLOCATED 8.28.31.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 174 COGENT-174, US 27205 UNALLOCATED 8.38.16.0/21 6461 ZAYO-6461, US 27205 UNALLOCATED 8.38.16.0/22 32787 PROLEXIC-TECHNOLOGIES-DDOS-M 27205 UNALLOCATED 8.38.20.0/22 32787 PROLEXIC-TECHNOLOGIES-DDOS-M 14109 UNALLOCATED 8.38.252.0/24 3356 LEVEL3, US Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 192.88.99.0/24 6939 HURRICANE, US Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Unassigned Network ASN Information AS Name 23.136.224.0/24 Origin: 15206 UNASSIGNED Transit: 174 COGENT-174, US 23.137.192.0/24 Origin: 31798 CANAD-86-31798, CA Transit: 174 COGENT-174, US 27.100.7.0/24 Origin: 56096 UNASSIGNED Transit: 45455 TH-2S1N-AP Two S One N Co Ltd, Internet 27.126.156.0/22 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad, MY 27.126.156.0/23 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad, MY Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:10 /9:11 /10:38 /11:98 /12:287 /13:580 /14:1157 /15:1918 /16:13385 /17:8191 /18:13886 /19:25821 /20:40462 /21:47563 /22:98402 /23:80949 /24:459851 /25:1338 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4830 5855 UNI2-AS, ES 31334 3276 3431 KABELDEUTSCHLAND-AS, DE 6327 3153 3365 SHAW, CA 7155 3139 4047 VIASAT-SP-BACKBONE, US 11492 3062 3926 CABLEONE, US 39891 2946 4034 ALJAWWALSTC-AS, SA 22773 2740 3522 ASN-CXA-ALL-CCI-22773-RDC, US 8551 2552 3092 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 2040 2291 MEDIACOM-ENTERPRISE-BUSINESS, US 11830 2029 2681 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1502 2:1163 3:30 4:19 5:3265 6:48 8:1378 9:1 12:1787 13:478 14:2230 15:71 16:9 17:283 18:79 20:58 23:3275 24:2627 25:4 27:2496 31:2859 32:101 35:43 36:933 37:3230 38:1833 39:314 40:132 41:3273 42:872 43:2122 44:190 45:13057 46:3644 47:274 49:1430 50:1567 51:343 52:1109 54:271 55:670 56:6 57:48 58:1885 59:1117 60:682 61:2210 62:2159 63:1927 64:5034 65:2328 66:4836 67:2846 68:1233 69:3820 70:1412 71:670 72:2779 74:2615 75:1438 76:670 77:2576 78:1978 79:2365 80:1851 81:1565 82:1206 83:1117 84:1215 85:2473 86:573 87:1697 88:1074 89:2687 90:298 91:7544 92:1455 93:2434 94:2588 95:3702 96:1013 97:337 98:963 99:965 100:83 101:1088 102:813 103:23042 104:3616 105:398 106:826 107:1873 108:702 109:3613 110:1770 111:1950 112:1544 113:1369 114:1488 115:1834 116:1792 117:2033 118:2122 119:1693 120:839 121:1024 122:2372 123:1879 124:1558 125:2015 128:1391 129:912 130:610 131:1825 132:780 133:301 134:1225 135:274 136:597 137:886 138:2168 139:990 140:596 141:876 142:865 143:1162 144:947 145:292 146:1449 147:1023 148:2036 149:1103 150:807 151:1270 152:1476 153:370 154:4694 155:901 156:3279 157:1082 158:720 159:1939 160:1716 161:1009 162:3010 163:770 164:1422 165:1227 166:541 167:1468 168:3526 169:488 170:4232 171:747 172:1857 173:2354 174:1036 175:1008 176:2617 177:4105 178:2902 179:1446 180:2198 181:2356 182:2836 183:1118 184:2388 185:16009 186:3734 187:2540 188:3629 189:2086 190:8267 191:1506 192:10235 193:7305 194:5973 195:4287 196:3373 197:1860 198:6121 199:5936 200:7168 201:5126 202:10402 203:10224 204:4552 205:3073 206:3243 207:3268 208:4012 209:4358 210:4003 211:1992 212:3236 213:3015 214:1169 215:53 216:5933 217:2333 218:897 219:605 220:1976 221:921 222:1013 223:1398 End of report

1 0

Austin, San Antonio, Houston
by Rod Beck 31 Jan '20

31 Jan '20

I am looking for a list of dark fiber providers in these cities. Particularly those who have conduit or aerial rights of way or relatively new fiber to sell (title, not IRUs or leases). Please contact off list with free advice or if you represent such a carrier and are authorized to sell its products. No old fiber. No leases. Roderick Beck VP of Business Development United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> New York City & Budapest rod.beck(a)unitedcablecompany.com 36-70-605-5144 [1467221477350_image005.png]

1 0