I suspect what is happening here is not as uncommon as some might think.

At one point in time, I was working for a network that was concerned about
table size growth on some of its older routers.
To alleviate those concerns, large aggregate routes were installed
internally sending regionalized prefix blocks towards their respective
portions of the planet.
IE, APNIC allocated ranges from IANA were pointed towards the APAC portion
of the network, RIPE allocations were pointed towards Europe, and then more
specifics were filtered out from iBGP at the cross-continental route
reflectors.  This worked fairly well for filtering out smaller prefixes
while still more or less keeping routes flowing in the right directions.

Then we started feeding routes to a routing intelligence platform; they
wanted a full feed of all our routes, not just our normal export list of
our customer cone.
So, we gave them a full feed of everything--which included the internal
traffic engineering super-aggregates that were used to steer traffic
internally.

The prefixes in question were never used for anything other than general
steering of traffic at trans-oceanic crossings, and were never announced
externally (other than to the routing intelligence platform), and thus were
never in a position to 'hijack' any traffic.  But they did indeed show up
when people dug through prefix information on the routing intelligence
platform.

You might be seeing similar artifacts here; internal traffic engineering
routes that aren't announced externally on any data-carrying links, but
that are being exported to a RIB-monitoring service only.

I wouldn't worry too much; unless there's a Pakistan/Youtube or AS7007
level leakage from the network in question, your traffic won't ever be
impacted by those RIB entries.

Matt

On Sat, Aug 30, 2025 at 7:34 AM Ties de Kock via NANOG <
[email protected]> wrote:

> I looked at some RIS (and routeviews) MRT data.
>
> First I looked at BGP updates:
> * There were no BGP updates captured by RIPE RIS between
> 2025-08-12..2025-08-26
>  for 2400::/12.
> * The largest prefix in 2400::/12 for which updates/withdraws were seen in
> that
>  period was 2400:2000::/20.
>
> When I look at the combined RIS+routeviews RIBS at 08:00 UTC on 2025-08-30,
> these are the largest prefixes in 2400::/12 and their visibility:
>
> ┌────────────────┬────────────┐
> │     prefix     │ visibility │
> │                │   (peers)  │
> ├────────────────┼────────────┤
> │ 2400:2000::/20 │        689 │
> │ 2400:4000::/22 │        690 │
> │ 2400:6280::/30 │        268 │
> │ 2400:7b80::/30 │        799 │
> │ 2400:a840::/31 │        795 │
> │ 2400:a842::/31 │        795 │
> │ 2400:a844::/31 │        795 │
> │ 2400:a846::/31 │        795 │
> │ 2400:a848::/31 │        795 │
> │ 2400:a84a::/31 │        795 │
> │ 2400:a84c::/31 │        795 │
> │ 2400:a84e::/31 │        795 │
> │ 2400:a980::/29 │        777 │
> │ 2400:ca00::/28 │        792 │
> │ 2400:d800::/30 │        780 │
> │ 2400:d800::/31 │        780 │
> │ 2400:dd00::/28 │        693 │
>
> If 2400::/12 was widely visible, it indicates a gap in the coverage of
> routeviews and RIS. I can’t speak for routeviews, but as RIS project we
> would
> be very happy to add peers that cover such a blindspot.
>
> We want to make data analysis like I just did easier. We have a prototype
> for a
> new way to search in MRT data. It started as an internal research/debugging
> aid,
> but we want to start releasing pre-processed data soon.
>
> If things work out I will do a talk on this at the next RIPE and NANOG
> meetings
> on this way to search in BGP data - the talk is about to be submitted.
>
> Kind regards,
>
> Ties
>
> On Sat, 30 Aug 2025 at 14:56, Tom Beecher via NANOG <[email protected]
> >
> wrote:
>
> > According to RIPEStat, 2400::/12 hasn't been seen since Oct 2023, from
> > AS13030 (Init7).
> >
> > I also cannot seem to see any recent announcement of that anywhere in the
> > usual sources, or my internal data. I would say this was an error on
> > Qrator's part.
> >
> > In that case, what more do I must do?
> >
> >
> > Although it didn't seem to happen here, best practice is to always
> announce
> > 100% of your allocated IPs at all times.  This provides protection
> against
> > someone announcing an umbrella and pulling traffic for any uncovered
> space.
> > It's not perfect , but protects against general stupid.
> >
> > On Sat, Aug 30, 2025 at 2:59 AM Pirawat WATANAPONGSE via NANOG <
> > [email protected]> wrote:
> >
> > > Dear Gurus,
> > >
> > >
> > > Radar tool by Qrator [Reference: https://radar.qrator.net ] claims
> that
> > > Zenlayer Inc. [AS4229] is “umbrella-ing” me by announcing ‘2400::/12’
> on
> > > top of my more-specific address block.
> > > The tool classifies it as a type of hijacking.
> > > [Disclaimer: apologies to Zenlayer if you didn’t do it; but that’s the
> > > information I received]
> > > My neighboring organization also has a more-specific block that falls
> > under
> > > The Umbrella too.
> > >
> > > However, other tools (https://stat.ripe.net ,
> > > https://irrexplorer.nlnog.net
> > > , https://bgp.he.net , etc.) seem unable to see that particular
> > > announcement.
> > >
> > > Questions:
> > > 1. Is Qrator claim true? (because I have already tried but cannot
> verify)
> > > 2. If so, should I be concerned?
> > > Even though I already ROA-ed *and* IRR-ed my own block, but if “the
> other
> > > end” doesn’t validate, it won’t do any good, correct?
> > > (Oh, yeah, the other end also has to somehow “not see” my
> longer-prefix.
> > > But that can happen as well, no?)
> > > 3. In that case, what more do I must do?
> > >
> > > I would extremely appreciate someone helping me out on this matter.
> > >
> > >
> > > Best Regards,
> > >
> > > Pirawat.
> > > _______________________________________________
> > > NANOG mailing list
> > >
> > >
> >
> https://lists.nanog.org/archives/list/[email protected]/message/GT2M54NGQQHRE7IU63ECEOMVTGH7FRIW/
> > _______________________________________________
> > NANOG mailing list
> >
> >
> https://lists.nanog.org/archives/list/[email protected]/message/47LPGUEA2E2LV3RIRZGEF35KC6SPQ53L/
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/[email protected]/message/FCMDVDY6D3WVWQC4GYNZIBTTNOHDIGHD/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/AL3VTHRLCHAXEPF5HSYIM27XF6PXMYIE/

Reply via email to