Re: What's going on with AS147028?

[Mike Leber via NANOG]

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.


Mike.

On 7/12/22 12:49 PM, Eric Dugas via NANOG wrote:
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.


Eric

Re: What's going on with AS147028?

[August Yang via NANOG]

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 regards
August Yang

> On Jul 12, 2022, at 3:49 PM, Eric Dugas via NANOG  wrote:
> 
> 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.
> 
> Eric
> 



smime.p7s
Description: S/MIME cryptographic signature

What's going on with AS147028?

[Eric Dugas via NANOG]

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.

Eric

Re: Assumptions about network designs...

[Andrey Kostin]

This is actually not the case. Cable service in some regional areas was 
restored as late as on Monday and even in the same geographical area 
there was a partial connectivity, so it looks less probable that network 
could be overloaded only in some isolated segments longer than the rest 
of the network and require manual intervention to fix it.
OTOH, overloading network core of such big network should be hardly 
possible. Possible route "poisoning" could be isolated, so that it 
doesn't affect the whole network cost to cost. It must be very unlucky 
coincidence of such event to happen on such big scale. Maybe caused by 
HW or SW bug.
I'm talking just about probabilities of different scenarios and trying 
to compare them. So far, IMO provided version doesn't look very 
convincing.


Kind regards,
Andrey Kostin

sro...@ronan-online.com писал(а) 2022-07-11 20:18:

I’m “guessing” based on all the services that were impacted the
outage was likely cause by a change that caused a routing change in
their multi-service network which overloaded many network devices, and
by isolating the source the routes or traffic the rest of the network
was able to recover.

But just a guess.

Shane