My view of the arin db boarked?

Christopher_Morrow1 · June 8, 2012, 8:27pm

err, last 3 times I asked this I was shown the error of my ways, but
here goes...

209.250.228.241 - seems to not have any records in ARIN's WHOIS
database, everythign seems to roll up to the /8 record

I see this routed as a /23: (from routeviews)
  BGP routing table entry for 209.250.228.0/23, version 2072545487
Paths: (33 available, best #19, table Default-IP-Routing-Table)
  Not advertised to any peer
  3277 3267 174 27431 14037
    194.85.102.33 from 194.85.102.33 (194.85.4.4)
      Origin IGP, localpref 100, valid, external
      Community: 3277:3267 3277:65321 3277:65323 3277:65330

If I look at the ASN in particular: AS14037
no records exist for that in ARIN's WHOIS database either ;( If I look
at all the networks announced by AS14037:
14037 | 204.8.216.0/21 |
14037 | 209.250.224.0/19 |
14037 | 209.250.228.0/23 |
14037 | 209.250.242.0/24 |
14037 | 209.250.247.0/24 |
14037 | 64.18.128.0/19 |
14037 | 64.18.159.0/24 |

none of them have any records in the ARIN WHOIS database The
upstream for this network is AS 27431 - JTL Networks
who seems to get transit/peer with 3356/174.

It's nice to see folk who use IRR databases to filter their customers
still permit this sort of thing to go on though: AS3356 I'm looking at
you...

I think first: "Where are the records for this set of ip number resources?"
and second: "Why are we still seeing this on the network with no way
to contact the operators of the resources?"

-chris

Christopher_Morrow1 · June 8, 2012, 9:02pm

it seems fair to note that:
<http://lists.arin.net/pipermail/arin-issued/>

also doesn't mention this 209.250 range, nor the others from this
mystery ASN. (back to 12/2008 at least)

-chris

Suresh_Ramasubramani · June 9, 2012, 2:19am

The only mention I can find of AS14037 in nanog, funnily enough, is my
own post about it ..

http://www.gossamer-threads.com/lists/nanog/users/110097

Christopher_Morrow1 · June 9, 2012, 5:48am

The only mention I can find of AS14037 in nanog, funnily enough, is my
own post about it ..

Carbon60: Managed Cloud Services

it looks like cogent stopped propogating the prefixes in question...

helo 3356, are you out there?

Joe_Provo4 · June 9, 2012, 3:13pm

err, last 3 times I asked this I was shown the error of my ways, but
here goes...

209.250.228.241 - seems to not have any records in ARIN's WHOIS
database, everythign seems to roll up to the /8 record

I see this routed as a /23: (from routeviews)
  BGP routing table entry for 209.250.228.0/23, version 2072545487
Paths: (33 available, best #19, table Default-IP-Routing-Table)
  Not advertised to any peer
  3277 3267 174 27431 14037
    194.85.102.33 from 194.85.102.33 (194.85.4.4)
      Origin IGP, localpref 100, valid, external
      Community: 3277:3267 3277:65321 3277:65323 3277:65330

If I look at the ASN in particular: AS14037
no records exist for that in ARIN's WHOIS database either ;( If I look
at all the networks announced by AS14037:
14037 | 204.8.216.0/21 |
14037 | 209.250.224.0/19 |
14037 | 209.250.228.0/23 |
14037 | 209.250.242.0/24 |
14037 | 209.250.247.0/24 |

If you query filtergen.level3.com, they are expecting to see it from
this ASN:

Prefix list for policy as14037 =
LEVEL3::AS14037

204.8.216.0/21
209.250.224.0/20

14037 | 64.18.128.0/19 |
14037 | 64.18.159.0/24 |

...but not those, which are registered in ALTDB (as the /19)along
with the squatted 204.8.216.0/21 and 209.250.224.0/20

route: 64.18.128.0/19
descr: RackVibe LLC
origin: AS14037
admin-c: GC373-ARIN
tech-c: GC373-ARIN
notify: arin@6gtech.com
mnt-by: MNT-6GTECH
changed: arin@6gtech.com 20081007
source: ALTDB

none of them have any records in the ARIN WHOIS database The
upstream for this network is AS 27431 - JTL Networks
who seems to get transit/peer with 3356/174.

Amusingly, AS27431 is still the RR contacts cording to the IRR. Score
another one in the 'inaccurate IRR' column.

It's nice to see folk who use IRR databases to filter their customers
still permit this sort of thing to go on though: AS3356 I'm looking at
you...

Here's a clue of future prefixes to watch for 3356 allowing from
this particular nest:

% whois -h filtergen.level3.com -- "-searchpath=ARIN;RIPE;RADB;ALTDB;LEVEL3 as27431"
Prefix list for policy as27431 =
ARIN::AS27431 LEVEL3::AS27431 ALTDB::AS27431 RADB::AS27431
RIPE::AS27431

66.132.44.0/24
66.132.45.0/24
66.132.47.0/24
69.36.0.0/20
209.41.200.0/24
209.41.202.0/24
209.115.40.0/24
209.115.41.0/24
209.115.42.0/24
209.115.43.0/24
209.115.108.0/24
216.28.47.0/24
216.28.134.0/24
216.29.53.0/24
216.29.115.0/24
216.29.116.0/24
216.29.117.0/24
216.29.121.0/24
216.29.122.0/24
216.29.152.0/24
216.29.194.0/24
216.29.247.0/24
%

I think first: "Where are the records for this set of ip number resources?"
and second: "Why are we still seeing this on the network with no way
to contact the operators of the resources?"

You can try and contact the entities that are called 'RackVibe' accordin
and '6G Tech' according to the various IRR registry entries for 14037 and
46496. Sketchy things which geolocate to Seacaucus? Whoda thunk.

Christopher_Morrow1 · June 11, 2012, 3:36pm

err, last 3 times I asked this I was shown the error of my ways, but
here goes...

209.250.228.241 - seems to not have any records in ARIN's WHOIS
database, everythign seems to roll up to the /8 record

I see this routed as a /23: (from routeviews)
BGP routing table entry for 209.250.228.0/23, version 2072545487
Paths: (33 available, best #19, table Default-IP-Routing-Table)
Not advertised to any peer
3277 3267 174 27431 14037
194.85.102.33 from 194.85.102.33 (194.85.4.4)
Origin IGP, localpref 100, valid, external
Community: 3277:3267 3277:65321 3277:65323 3277:65330

If I look at the ASN in particular: AS14037
no records exist for that in ARIN's WHOIS database either ;( If I look
at all the networks announced by AS14037:
14037 | 204.8.216.0/21 |
14037 | 209.250.224.0/19 |
14037 | 209.250.228.0/23 |
14037 | 209.250.242.0/24 |
14037 | 209.250.247.0/24 |

If you query filtergen.level3.com, they are expecting to see it from
this ASN:

Prefix list for policy as14037 =
LEVEL3::AS14037

204.8.216.0/21
209.250.224.0/20

14037 | 64.18.128.0/19 |
14037 | 64.18.159.0/24 |

...but not those, which are registered in ALTDB (as the /19)along
with the squatted 204.8.216.0/21 and 209.250.224.0/20

route: 64.18.128.0/19
descr: RackVibe LLC
origin: AS14037
admin-c: GC373-ARIN
tech-c: GC373-ARIN
notify: arin@6gtech.com
mnt-by: MNT-6GTECH
changed: arin@6gtech.com 20081007
source: ALTDB

none of them have any records in the ARIN WHOIS database The
upstream for this network is AS 27431 - JTL Networks
who seems to get transit/peer with 3356/174.

Amusingly, AS27431 is still the RR contacts cording to the IRR. Score
another one in the 'inaccurate IRR' column.

yea, automated filter generation from IRR's ... not always good

It's nice to see folk who use IRR databases to filter their customers
still permit this sort of thing to go on though: AS3356 I'm looking at
you...

Here's a clue of future prefixes to watch for 3356 allowing from
this particular nest:

% whois -h filtergen.level3.com -- "-searchpath=ARIN;RIPE;RADB;ALTDB;LEVEL3 as27431"
Prefix list for policy as27431 =
ARIN::AS27431 LEVEL3::AS27431 ALTDB::AS27431 RADB::AS27431
RIPE::AS27431

66.132.44.0/24
66.132.45.0/24
66.132.47.0/24
69.36.0.0/20
209.41.200.0/24
209.41.202.0/24
209.115.40.0/24
209.115.41.0/24
209.115.42.0/24
209.115.43.0/24
209.115.108.0/24
216.28.47.0/24
216.28.134.0/24
216.29.53.0/24
216.29.115.0/24
216.29.116.0/24
216.29.117.0/24
216.29.121.0/24
216.29.122.0/24
216.29.152.0/24
216.29.194.0/24
216.29.247.0/24
%

most (by random sample of queries to whois.arin.net) of these at least
still had entries in the db.

I think first: "Where are the records for this set of ip number resources?"
and second: "Why are we still seeing this on the network with no way
to contact the operators of the resources?"

You can try and contact the entities that are called 'RackVibe' accordin
and '6G Tech' according to the various IRR registry entries for 14037 and
46496. Sketchy things which geolocate to Seacaucus? Whoda thunk.

yea I'd sort of prefer if the transit here would just stop
accepting the announcement(s) in question (which they do today ,
several filter-gen runs since friday).

-chris