A friend of mine mentioned that both our Canadian ASNs were listed in AS147028’s peer list on https://bgp.he.net/AS147028 but we have no adjacency to this network.
Their peer count jumped from 1 in May 2022 to 1,800 and just a few days ago jumped to 8,800. Beside NL-IX, all the IX they are listed on are virtual IX with a few dozen “hobby networks”.
The only lead I have is they use HE as transit and they’re pumping back BGP feed to route collectors like RIPE RIS or Route Views with routes stripped of HE’s ASN.
Indeed the network feeds some of the major route collectors.
One known cause is LL-IX which operates in a topology that partially transits routes from physical exchanges to its participants and strips their ASN in path.
Possibility to peer with a large number of AMS-IX (Netherlands, Haarlem), DE-CIX (Germany, Frankfurt), MSK-IX (Russia, Moscow), SIX (USA, Seattle) and PLIX (Poland, Warsaw) participants
The network operator might have intentionally or unintentionally forgot to prepend his own ASN before exporting to the collectors. Chances are misconfigured route reflector or the eager of more visible peers on those toolkits.
The issue is widely observed on a number of hobby networks.
Best regardsAugust Yang
This kind of thing is a problem from time to time with the data we get from route collectors.
When we see it we have to add the culprit ASN to a filter list we keep in bgp.he.net.
It tends to be a repeat problem with some collectors and some ASNs.
We haven't really figured out why people send junk routes to route collectors.
The things we've seen aren't just route leaks. We've seen a variety of AS path spoofing.
We've already added this specific ASN to the filter list and pushed an update for bgp.he.net.
Note, this email is specifically talking about routes received from route collectors and not routes operationally received by he.net via BGP sessions with actual networks.
Just to name few others with the same issue.
No reason to feed fake routes to route collectors.
Some BGP players (ASN Operator) like that, and make the AS number one in stats.
Maybe someone knows bgp.tools, they also run route collectors but rejected AS Number which joined LL-IX.
(This IXP removes the as-path and feeds to their rs client.)
I’m not targeting anyone, but feed fake route has no benefit, just vanity ;(
PGP: 114A A514 776D BEAF
I run bgp.tools (with it's own route collectors, that people should
totally feed Setup BGP Sessions for Route Collection - bgp.tools ) but I feel like
I can add some insight here to what I think is happening with
I've had multiple issues with networks feeding me that also are on
LL-IX (PeeringDB) or LL-HOST (Maybe? AS59947).
It appears (based on my discussions with a few of the offending
networks) that LL-IX or LL-HOST strips their own ASN (59947) from the
path when you take up a transit or maybe (i'm not sure) peer on their
route servers on LL-IX
When you combine this and exporting to projects like RouteViews/RIPE
RIS/bgp.tools, you get a peer graph that looks like the feeder ASN is
peering with... almost everyone who AS59947 peers with.
This has become so much of a problem (as I am slightly mad for getting
this kind of data right) that bgp.tools disallows sessions to be setup
if it looks like the AS either is upstreamed by AS59947 or has a port
with LL-IX, (with a message to email me)
The users who do email me, about 50% of them commit to adding the
AS59947 ASN back on, and I enable their ability to export to
Hope this clears things up! This exact AS has been the cause of many
frustrations for me for a while now!