IPv4 Subnet 23.151.232.0/24 blackholed?

Hi,

I recently got the IPv4 allocation 23.151.232.0/24 from ARIN. I also had my hosting company ReliableSite announce it to the internet.

Right now, I can only access networks that peer with ReliableSite via internet exchanges, such as Google, CloudFlare, OVH, Hurricane Electric, et al.

It seems the Tier 1 ISPs (e.g. Lumen, Cogent, AT&T, et al.) are blackholing the IPv4 subnet 23.151.232.0/24. Could someone who works at a Tier 1 NOC please check and remove the blackhole if any exists?

Normally when ReliableSite announced my prior (then-leased) IPv4 space it gets propagated via BGP almost immediately. This time it's not going through at all.

Best,

Neel Chauhan

Neel,

Carriers rebuild their prefixes lists once or twice in a 24 hour period. Considering that you just got the block today and is in ReliableSite's AS-SET, you just got to be patient.

Having announcements propagated immediately either sounds like it happened a day after you gave them the LOA, or they have unfiltered transit circuits, which is worrisome.

Ryan

From "Neel Chauhan" <neel@neelc.org>
To nanog@nanog.org
Date 4/25/2023 7:35:40 PM
Subject IPv4 Subnet 23.151.232.0/24 blackholed?

You need to talk to ReliableSite and have them talk to their transits about accepting 23.151.232.0/24.

I see that you did create a route object...

route: 23.151.232.0/24
origin: AS23470
descr: Qeru Systems, LLC
mnt-by: MAINT-AS23470
changed: jcid@reliablesite.net 20230425 #01:09:36Z
source: RADB

but I'd dump RADB and create this object in the authoratative IRR, in this case ARIN's rr.arin.net. At least some "Tier 1's" no longer honor route objects from non-authoratative IRRs when building prefix-list filters for their customers BGP sessions.

I'm not receiving your route, and route-views doesn't see it either.

The range has only been announced for 2 hours. Just wait longer for filters to refresh as Ryan advised.

We are able to see your range from Cogent and Hurricane Electric now. Just took time

Routes For: 23.151.232.0/24

Timestamp: 2023-04-26 11:27:07 UTC

  • Prefix: 23.151.232.0/24

  • RPKI State: Not Verified

  • AS Path: 6939 → 23470 → 23470 → 23470 → 23470

  • Next Hop: 184.105.58.113

  • Weight: 170

  • Local Preference: 100

  • MED: 0

  • Communities:

  • Originator:

  • Peer: 216.218.253.50

  • Age: 6 hours (Wed, 26 Apr 2023 05:01:41 UTC)

  • Prefix: 23.151.232.0/24

  • RPKI State: Not Verified

  • AS Path: 6939 → 23470 → 23470 → 23470 → 23470

  • Next Hop: 184.105.92.241

  • Weight: 170

  • Local Preference: 100

  • MED: 0

  • Communities:

  • Originator:

  • Peer: 100.78.0.6

  • Age: 6 hours (Wed, 26 Apr 2023 05:01:39 UTC)

  • Prefix: 23.151.232.0/24

  • RPKI State: Not Verified

  • AS Path: 174 → 3257 → 23470 → 23470 → 23470 → 23470

  • Next Hop: 38.140.137.161

  • Weight: 170

  • Local Preference: 100

  • MED: 10020

  • Communities:

  • 174:21000

  • 174:22013

  • Originator:

  • Peer: 66.28.1.16

  • Age: 3 hours (Wed, 26 Apr 2023 08:57:05 UTC)

Thanks

Travis

You’re welcome to use our looking glasses which over Europe and Africa:

https://as37100.net/

But so far, we are seeing this in AMS:

BGP routing table entry for 23.151.232.0/24, version 2411923092
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 1
37100 3257 23470 23470 23470 23470
105.26.64.17 from 105.26.64.17 (105.16.0.131)
Origin IGP, metric 0, localpref 100, valid, external
Community: 37100:1 37100:13
path 211B5070 RPKI State not found
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
37100 3257 23470 23470 23470 23470
105.26.64.1 from 105.26.64.1 (105.16.0.131)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 37100:1 37100:13
path 211B6A5C RPKI State not found
rx pathid: 0, tx pathid: 0x0

And in JNB:

BGP routing table entry for 23.151.232.0/24, version 1526622268
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 1
37100 3257 23470 23470 23470 23470
105.22.32.1 from 105.22.32.1 (105.16.0.163)
Origin IGP, metric 0, localpref 100, valid, external
Community: 37100:1 37100:13
path 44E5427C RPKI State not found
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
37100 3257 23470 23470 23470 23470
105.22.40.1 from 105.22.40.1 (105.16.0.162)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 37100:1 37100:13
path 44E60E94 RPKI State not found
rx pathid: 0, tx pathid: 0x0

Mark.

Now this is kind of interesting. I see route-views can see the route now...

BGP routing table entry for 23.151.232.0/24, version 2814701286
Paths: (19 available, best #19, table default)
   Not advertised to any peer
   Refresh Epoch 1
   3333 1257 6453 23470 23470 23470 23470
     193.0.0.56 from 193.0.0.56 (193.0.0.56)
       Origin IGP, localpref 100, valid, external
       Community: 1257:50 1257:51 1257:3528 1257:4103
       path 7FE0DBA20378 RPKI State not found
       rx pathid: 0, tx pathid: 0
   Refresh Epoch 1
...

The only IRR route object I see for it is

route: 23.151.232.0/24
origin: AS23470
descr: Qeru Systems, LLC
mnt-by: MAINT-AS23470
changed: jcid@reliablesite.net 20230425 #01:09:36Z
source: RADB
rpki-ov-state: not_found # No ROAs found, or RPKI validation not enabled for source

and there appears to be no ROA.

According to TATA Communications Customer BGP Filter Update Policy for IP Transit, I would not have expected Tata to accept this route from RELIABLESITE (not based on the above route object), unless Tata is not using an IRR-based auto-generated prefix-list filter for RELIABLESITE, but rather a manually edited one.