Re: Is there an established method for reporting/getting removed a company with 100% false peeringdb entries?

[IP Abuse Research]

That could be Justin, based on the timeline from domain registration to
ARIN Object Creation ( Network and Abuse ) to PeeringDB Contact Update.
That doesn't explain the recent update to Public Peering Info on
2021-03-07T20:35:22 months after the ASN stopped routing any IP space.

The domain name associated with Manhattan Networks Corporation was created
on June 2nd, on the same day it was updated, the operator created multiple
ARIN objects:

Domain Name: manhattannetworksco.com
Updated Date: 2020-06-04T05:21:24Z
Creation Date: 2020-06-02T13:05:12Z

NETWO9241-ARIN - Thu, 04 Jun 2020 14:44:24 GMT (Thu Jun 04 2020 local time)
ABUSE7921-ARIN - Thu, 04 Jun 2020 14:50:50 GMT (Thu Jun 04 2020 local time)

The PeeringDB contact information entry was updated over an hour later.
https://www.peeringdb.com/asn/18894
Contact Info Updated 2020-06-04T16:11:24Z
Peering Facility Info Updated 2020-06-17T10:37:57Z
Last Updated 2020-07-01T14:22:01Z
Public Peering Info Updated 2021-03-07T20:35:22

On Jun 11th they created MNC-415
Registration - Thu, 11 Jun 2020 17:53:51 GMT (Thu Jun 11 2020 local time)
Last Changed - Wed, 17 Jun 2020 04:39:38 GMT (Wed Jun 17 2020 local time)
Comments - PDB: https://www.peeringdb.com/net/23440

On Jun 16th days later, the ASN was registered with ARIN.
Source Registry ARIN
Number 18894
Name MANHATTAN-US
Handle AS18894
Registration - Tue, 16 Jun 2020 20:02:32 GMT (Tue Jun 16 2020 local time)
Last Changed - Tue, 16 Jun 2020 20:02:32 GMT (Tue Jun 16 2020 local time)

Activity wise, the IP space they were routing were leased from Cogent?
Jul 17th - November 20th: announcing Cogent prefix 154.13.160.0/24
Aug 12th - Oct 6th: announcing Cogent prefix 154.13.161.0/24

On Fri, Mar 5, 2021 at 3:23 PM Justin Wilson (Lists)  wrote:

> I see from peering db:  2020-07-01T14:22:01Z
> According to the bg.he.net link
> AS18894 has not been visible in the global routing table since November
> 28, 2020
> The information displayed is from that time.
>
>
> Are they causing you or someone issues Eric? Maybe they went out of
> business? Many businesses don’t worry about peering db entries. Looks like
> the website has been under constructions since 2020.
>
> Sounds to me like they made a splash, and faltered.
>
>
> Justin Wilson
> j...@mtin.net
>
> —
> https://j2sw.com - All things jsw (AS209109)
> https://blog.j2sw.com - Podcast and Blog
>
> > On Mar 4, 2021, at 7:14 PM, Eric Kuhnke  wrote:
> >
> > First, take a look at this:
> >
> > https://www.peeringdb.com/asn/18894
> >
> >
> > Now look at these (or use your own BGP table analysis tools):
> >
> > https://bgp.he.net/AS18894
> >
> > https://stat.ripe.net/18894
> >
> > The claimed prefixes announced, traffic levels and POPs appear to have
> no correlation with reality in global v4/v6 BGP tables.
> >
> > It is also noteworthy that I have inquired with a number of persons I
> know who are active in network engineering in NYC, and nobody has ever
> encountered this company.
> >
> >
> >
> >
>
>

Re: Is there an established method for reporting/getting removed a company with 100% false peeringdb entries?

[James Breeden]

Yeah, I know a couple of people who have thrown massive peeringdb operations up 
just to make them look big but their routing table analysis looks nothing like 
what they say they have.


James W. Breeden

Managing Partner



[cid:3c34773f-9c3e-42cf-87ba-144ee1fa163f]

Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media | Atheral 
| BlueNinja

PO Box 1063 | Smithville, TX 78957

Email: ja...@arenalgroup.co | office 512.360. 
| cell 512.304.0745 | www.arenalgroup.co
Executive Assistant: Chelsea Nichols: chel...@arenalgroup.co | 737.302.8742


From: NANOG  on behalf of Eric 
Kuhnke 
Sent: Thursday, March 4, 2021 6:14 PM
To: nanog@nanog.org list 
Subject: Is there an established method for reporting/getting removed a company 
with 100% false peeringdb entries?

First, take a look at this:

https://www.peeringdb.com/asn/18894


Now look at these (or use your own BGP table analysis tools):

https://bgp.he.net/AS18894

https://stat.ripe.net/18894

The claimed prefixes announced, traffic levels and POPs appear to have no 
correlation with reality in global v4/v6 BGP tables.

It is also noteworthy that I have inquired with a number of persons I know who 
are active in network engineering in NYC, and nobody has ever encountered this 
company.

Re: Is there an established method for reporting/getting removed a company with 100% false peeringdb entries?

[Justin Wilson (Lists)]

I see from peering db:  2020-07-01T14:22:01Z
According to the bg.he.net link
AS18894 has not been visible in the global routing table since November 28, 2020
The information displayed is from that time.


Are they causing you or someone issues Eric? Maybe they went out of business? 
Many businesses don’t worry about peering db entries. Looks like the website 
has been under constructions since 2020.

Sounds to me like they made a splash, and faltered.  


Justin Wilson
j...@mtin.net

—
https://j2sw.com - All things jsw (AS209109)
https://blog.j2sw.com - Podcast and Blog

> On Mar 4, 2021, at 7:14 PM, Eric Kuhnke  wrote:
> 
> First, take a look at this:
> 
> https://www.peeringdb.com/asn/18894
> 
> 
> Now look at these (or use your own BGP table analysis tools):
> 
> https://bgp.he.net/AS18894
> 
> https://stat.ripe.net/18894
> 
> The claimed prefixes announced, traffic levels and POPs appear to have no 
> correlation with reality in global v4/v6 BGP tables.
> 
> It is also noteworthy that I have inquired with a number of persons I know 
> who are active in network engineering in NYC, and nobody has ever encountered 
> this company.
> 
> 
> 
> 

Re: Is there an established method for reporting/getting removed a company with 100% false peeringdb entries?

[Stefan Funke]

On 05/03/2021 01:14, Eric Kuhnke wrote:

First, take a look at this:

https://www.peeringdb.com/asn/18894 


Now look at these (or use your own BGP table analysis tools):

https://bgp.he.net/AS18894 

https://stat.ripe.net/18894 

The claimed prefixes announced, traffic levels and POPs appear to have 
no correlation with reality in global v4/v6 BGP tables.


It is also noteworthy that I have inquired with a number of persons I 
know who are active in network engineering in NYC, and nobody has ever 
encountered this company.


Hi Nanog!

If you stumble across such things, drop us a note at 
supp...@peeringdb.com and we will take a look at it.




-Stefan

Re: Is there an established method for reporting/getting removed a company with 100% false peeringdb entries?

[Tom Beecher]

supp...@peeringdb.com is fairly prominently displayed at the bottom of
every page that peeringdb displays.

On Thu, Mar 4, 2021 at 7:16 PM Eric Kuhnke  wrote:

> First, take a look at this:
>
> https://www.peeringdb.com/asn/18894
>
>
> Now look at these (or use your own BGP table analysis tools):
>
> https://bgp.he.net/AS18894
>
> https://stat.ripe.net/18894
>
> The claimed prefixes announced, traffic levels and POPs appear to have no
> correlation with reality in global v4/v6 BGP tables.
>
> It is also noteworthy that I have inquired with a number of persons I know
> who are active in network engineering in NYC, and nobody has ever
> encountered this company.
>
>
>
>
>

Is there an established method for reporting/getting removed a company with 100% false peeringdb entries?

[Eric Kuhnke]

First, take a look at this:

https://www.peeringdb.com/asn/18894


Now look at these (or use your own BGP table analysis tools):

https://bgp.he.net/AS18894

https://stat.ripe.net/18894

The claimed prefixes announced, traffic levels and POPs appear to have no
correlation with reality in global v4/v6 BGP tables.

It is also noteworthy that I have inquired with a number of persons I know
who are active in network engineering in NYC, and nobody has ever
encountered this company.