Hi Folks, This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site. I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior. If anyone has any advice on next steps, it would be appreciated. Thanks, Matt
The u-del folk (as2?) have some fun stories about this sort of problem :( I think they've even done at least 1 nanog talk about this? There's also a long history of 'bad actors' using ASN at IX's (amsix and u-new-mexico I recall for us in the past) in order to make it seem like legit sources were sending traffic to places. "Gosh, I don't THINK UNM has a network out to AMS do they? that seems sus (as the kids say these days)" The impact you might see is non-reachability to things they announce? and/or them not being able to access your announced resources :( Also, people on the intertubes are going to be made about your 'bad behaviors' coming out of brazil :( Its likely that the 2/1 abuse contacts you reached out to are the part of the problem here, escalate perhaps? :) On Fri, Sep 11, 2026 at 10:26 AM Matt Brennan via NANOG <nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/63VQ3WKN...
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. Regards, Christopher Hawker Sent from my iPhone
On 11 Sep 2026, at 7:57 pm, Matt Brennan via NANOG <nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/63VQ3WKN...
Hi Matt, If AS27421 is being originated from an unexpected network in Brazil, I would recommend first confirming the exact prefixes and BGP paths being advertised by the suspected ASN. You can check the announcements and AS paths using tools such as BGPStream, RIPEstat, or HE BGP Toolkit. It would also be worth checking whether the affected prefixes are covered by valid RPKI ROAs. If they are, and the Brazilian announcement is RPKI Invalid, that provides strong evidence of an unauthorized origin. Since you have already contacted the upstream abuse contacts without a response, I would suggest escalating through their upstream/transit providers and the relevant RIR (ARIN for AS27421, and LACNIC for networks involved in Brazil). You can also report the incident to the NOC/security contacts listed in the relevant WHOIS/RDAP records. If there is no traffic impact at the moment, it may be a route leak or limited hijack rather than a full traffic interception. However, I would still recommend documenting the observed prefixes, timestamps, AS paths, and collectors reporting the announcement so you have a clear record for escalation. Hope this helps. Regards, Althaf On Fri, Sep 11, 2026 at 7:56 PM Matt Brennan via NANOG < nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/63VQ3WKN...
Maybe this is a bigger problem (loop or intentional)? This happened to a newly managed ASN for me as well: https://bgp.he.net/AS21752#_peers Ryan On Fri, Sep 11, 2026 at 10:54 AM Christopher Morrow via NANOG < nanog@lists.nanog.org> wrote:
The u-del folk (as2?) have some fun stories about this sort of problem :( I think they've even done at least 1 nanog talk about this?
There's also a long history of 'bad actors' using ASN at IX's (amsix and u-new-mexico I recall for us in the past) in order to make it seem like legit sources were sending traffic to places.
"Gosh, I don't THINK UNM has a network out to AMS do they? that seems sus (as the kids say these days)"
The impact you might see is non-reachability to things they announce? and/or them not being able to access your announced resources :( Also, people on the intertubes are going to be made about your 'bad behaviors' coming out of brazil :(
Its likely that the 2/1 abuse contacts you reached out to are the part of the problem here, escalate perhaps? :)
On Fri, Sep 11, 2026 at 10:26 AM Matt Brennan via NANOG <nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of
the
hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/63VQ3WKN... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/76THYD7L...
oopsie, I realize I wasn't super clear below... see below. On Fri, Sep 11, 2026 at 10:53 AM Christopher Morrow <morrowc.lists@gmail.com> wrote:
The u-del folk (as2?) have some fun stories about this sort of problem :( I think they've even done at least 1 nanog talk about this?
There's also a long history of 'bad actors' using ASN at IX's (amsix and u-new-mexico I recall for
I don't think there was anything AMSIX could have actually done here. Why? becuse the actor showed AMSIX RS the 'correct' asn... the peerings in question were not via the RS though:( I believe this was also seen at several other IX's :( it's one of the reasons focus was brought on filtering and RPKI by us at the time. My larger point is really that: "This happens, because people are people... and your best path is to escalate up the peering fabric with logs and evidence of the behavior."
But our AS2 "hijacks" and MIT, etc. are usually the result of router syntax errors trying to prepend, I really hope someone isn't trying to prepend 27421 times... 🙂 On 9/11/26 10:53 AM, Christopher Morrow via NANOG wrote:
The u-del folk (as2?) have some fun stories about this sort of problem :( I think they've even done at least 1 nanog talk about this?
There's also a long history of 'bad actors' using ASN at IX's (amsix and u-new-mexico I recall for us in the past) in order to make it seem like legit sources were sending traffic to places.
"Gosh, I don't THINK UNM has a network out to AMS do they? that seems sus (as the kids say these days)"
The impact you might see is non-reachability to things they announce? and/or them not being able to access your announced resources :( Also, people on the intertubes are going to be made about your 'bad behaviors' coming out of brazil :(
Its likely that the 2/1 abuse contacts you reached out to are the part of the problem here, escalate perhaps? :)
On Fri, Sep 11, 2026 at 10:26 AM Matt Brennan via NANOG <nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list...
Matt- This is semi common occurrence. Your best option is what you have done, reach out to the networks they are advertising to, and keep going upstream until you reach someone who is responsive and can take action. Getting your as_paths in ASPA is nice, but ASPA is not widely implemented, and it's still pretty trivial to bypass. Good luck. On Fri, Sep 11, 2026 at 10:27 AM Matt Brennan via NANOG < nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/63VQ3WKN...
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
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...
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...
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...
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...
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...
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...
My 2 cents, AS1000 and AS271253 are listed as IPv4 peers on 21752 (and others), both of those ASs have Lucas Garcia as the POC. Like Matt, I looked at their extensive IPv4 peer list and can name quite a few that definitely are not peers. Looking back on bgp.he.net at AS271253, on April 14th they went from 3.6k -> 5k IPv4 peers, which is the same day these two AS's got noted as being peers of AS21752. Looking at AS1000, they went from 47 IPv4 peers to 6k June 2nd -> June 5th. This is looking like a config issue? intentional or not. Ryan On Mon, Sep 14, 2026 at 10:28 AM Matt Brennan via NANOG < nanog@lists.nanog.org> wrote:
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...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QJLNDLFH...
Matt, Excellent application of Hanlon's Razor - "Never attribute to malice that which is adequately explained by stupidity" Wish more ops could learn to embrace same. $0.02 Mike On 9/14/26 07:28, Matt Brennan via NANOG wrote:
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
Hey Matt -
We're not receiving those routes from them over peering, and it looks
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
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
On Fri, 11 Sept 2026 at 17:51, Bryton Herdes <bryton@cloudflare.com> wrote: like this ... 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...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QJLNDLFH...
Could you expand on what is mean by "b) resolve AS-SET into an ASN tree"?
When you generate a prefix-list, you start from AS-SET. AS-SET is a list of ASN and AS-SET. You can build a graph/tree out of this data, but you cannot prune ASN/AS-SET or AS-SET/ASN pairs. You need ASN/ASN pairs to prune ASPA violating branches. You'd need to translate the AS-SET in the list into an ASN that is advertising that AS-SET. For the top level AS-SET this is easy, you are configuring that ASN so you know it explicitly. For any recursed AS-SETs, you don't actually know which ASN that AS-SET represents. You can do some heuristics to translate AS-SET into the ASN that is advertising that AS-SET. Two that come to mind 1) Parse RIR data, for every ASN look at (mp-)export, if this yields to exactly one AS-SET, then consider that ASN/AS-SET relation 2) PeeringDB has ASN/AS-SET relation, use that If neither work, then it just means you cannot translate that AS-SET, and it will not be subject to pruning due to ASPA violation. You don't have to be able to translate everything to be able to prune. Possibly there are other mechanisms to translate that I've not identified. On Wed, 16 Sept 2026 at 00:18, Steven Wallace via NANOG <nanog@lists.nanog.org> wrote:
Could you expand on what is mean by "b) resolve AS-SET into an ASN tree"? _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7UZ67EVT...
-- ++ytti
participants (12)
-
Althaf Navaskhan -
Bryton Herdes -
Christopher Hawker -
Christopher Morrow -
Dan Mahoney -
Matt Brennan -
Mike -
Mike Davis -
Ryan McIntosh -
Saku Ytti -
ssw＠internet2.edu -
Tom Beecher