I'm not willing to say that it's intentional, or malicious, as I don't have the evidence to back that up. However, considering the same thing is happening to at least 2 different ASNs, and when they fixed mine it didn't fix the other ... IMO the best case scenario is that it's an inexperienced network engineer making a lot of mistakes. As I review the list of peers they have, there are several which don't make obvious sense for a Brazilian telecom company. I'm betting it's more than 2, and the others just haven't realized it yet. -Matt On Sat, 12 Sept 2026 at 18:36, Dan Mahoney <danm@prime.gushi.org> wrote:
Any chance this was a digit-flip from an existing legit peer? It happens to the best of us.
-Dan
On Sep 12, 2026, at 3:32 PM, Matt Brennan via NANOG < nanog@lists.nanog.org> wrote:
Hi Folks,
After filing abuse tickets with a few of their upstreams, I received an email today (from a different contact than the abuse contact) apologizing and telling me the issue has been resolved. I am not seeing my ASN in their peering anymore, so it does appear to be resolved.
Ryan -- I still see yours in their list. If you want the email address of who apologized to me let me know and I'll provide it off-list.
Thanks again, everyone, for the advice.
-Matt
On Fri, 11 Sept 2026 at 17:51, Bryton Herdes <bryton@cloudflare.com> wrote:
Hey Matt -
We're not receiving those routes from them over peering, and it looks like they're not propagating widely to their upstreams or peers. I checked today's RIB dumps, and see the routes in RouteViews (amsix, ix-br.gru, saopaulo), only with paths "271253 27421" and "1000 27421" from their own peer IPs toward the collectors. I'm not sure what they (or someone else) have done, but maybe they're just sharing these routes with collectors (fingers crossed!).
I'll send you the dumps I grabbed separately via email, and can give you a couple of LINK contacts if you don't already have them.
-- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare
On Fri, Sep 11, 2026 at 3:24 PM Matt Brennan <brennanma@gmail.com> wrote:
Thanks, everyone, for the feedback. FYI we do have ROA set up for our prefixes, and I set up ASPA earlier this week hoping it might help this ... situation.
After reviewing Ryan's note, I reviewed the list of their peers further and I feel like a number of them are likely hijacked. I have now reached out to who I am confident are upstreams of them (HE, Cogent, Level3) and we'll see where that gets me. Of course, with more than 5,000 alleged peers this could easily be a zero sum game.
@Bryton -- as a note, both of the upstream ASs are peering with you as well, but your abuse form doesn't really have an option for this type of submission.
-Matt
On Fri, 11 Sept 2026 at 16:06, Bryton Herdes via NANOG < nanog@lists.nanog.org> wrote:
b) resolve AS-SET into an ASN tree
c) prune from the tree ASPA violating branches
I've discussed this with a few people with the same ideas, and I can think of few reasons not to ship it as long as it's done right.
It is appealing to get some value from the ASPAs as early as possible, and pruning bad members from an expanded AS-SET tree could offer that.
-- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare
On Fri, Sep 11, 2026 at 11:58 AM Saku Ytti via NANOG < nanog@lists.nanog.org> wrote:
On Fri, 11 Sept 2026 at 18:04, Christopher Hawker via NANOG <nanog@lists.nanog.org> wrote:
> I would look at creating ASPAs objects with $rir in the first instance. Would help combat these sorts of issues :) > Ask your upstream to create objects, then ask them to ask their upstreams, and so on… You get the picture.
If someone feels like vibing, may I suggest.
a) recover AS-SET <-> ASN relation - look at RIR data, check if (mp-)export has exactly one AS-SET -> match - look at peeringDB
b) resolve AS-SET into an ASN tree
c) prune from the tree ASPA violating branches
d) return prefix-list, and origin ASN list
This way anyone already doing RIR prefix-list generation, without any ASPA support in NOS, could get a significant amount of ASPA benefits without changing anything in the NOS side, just changing command they call to translate customer AS-SET into prefix-list or AS origin list or both.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UOBGN4KM...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2FQHH6LN...
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JPZJACIK...