DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

Tom Beecher beecher at beecher.cc
Sat Mar 26 16:34:50 UTC 2022


Mostly what Matt said. ( I should have also said 'ride the 0/0 train INTO
the DFZ, my mistake.)

Essentially, if ASN X is announcing a prefix with an excessive number of
prepends, they are saying to the world 'This path exists , but it is hot
garbage.' I'm more than happy to oblige those instructions and just drop
that announcement completely. If ASN X announces that prefix with a
reasonable number of prepends, happy to take it and use it.

If I get a prefix with an as-path longer than 10, (regardless of the state
of prepends), I interpret that as :

1. They have made a mistake.
2. Someone else made a mistake.
3. They think that's a good idea, and have some things yet to learn. ( The
old clue by four as Matt put it.)
4. It's malicious.
5. They actually are somehow more than 10 ASNs away from me. ( I don't even
know if this is possible anymore without extreme effort. )

In any of those scenarios , I don't really care about optimized routing to
that destination. Perfectly happy to just follow 0/0 to a DFZ upstream and
let it go how it's going to go, or not. If there is a traffic impact such
that an exception HAS to be made, that can be addressed as needed, but I
can't think of a single circumstance I have hit where the correction
involved accepting an obnoxiously long as_path announcement. ( I don't mean
to imply none exist ; I'm sure someone has had to work though that. )

Maybe a length of 10 doesn't work for some environments and use cases, but
I still am a firm believer that at a certain point, there is a length that
becomes straight 'really don't care'.  I'd rather not discover a BGP
implementation problem or acid trip memory pointer party by accepting
announcements that are useless.







On Fri, Mar 25, 2022 at 5:56 PM Adam Thompson <athompson at merlin.mb.ca>
wrote:

> Tom, how exactly does someone “ride the 0/0” train in the DFZ?
>
>
>
> I’m connected to both commercial internet and NREN, and unfortunately-long
> paths are not uncommon in this scenario, in order to do traffic steering.
> If there’s another solution that affects global *inbound* traffic
> distributions, I’d love to hear about it (and so would a lot of my peers in
> edu).
>
>
>
> If there were a usable way to “dump” the excessively-long path only as
> long as a better path was already known by at least one edge router, that
> might be workable, but you’d have to keep track of it somewhere to
> reinstall it if the primary route went away… at which point you may as well
> have not dropped it in the first place.
>
>
>
> -Adam
>
>
>
> *Adam Thompson*
> Consultant, Infrastructure Services
> [image: MERLIN]
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athompson at merlin.mb.ca
> www.merlin.mb.ca
>
>
>
> *From:* NANOG <nanog-bounces+athompson=merlin.mb.ca at nanog.org> *On Behalf
> Of *Tom Beecher
> *Sent:* Friday, March 25, 2022 4:13 PM
> *To:* Paschal Masha <paschal.masha at ke.wananchi.com>
> *Cc:* nanog <nanog at nanog.org>
> *Subject:* Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255
> times
>
>
>
> The best practice with regards to as_path length is to have an edge filter
> that dumps any prefix with a length longer than say 10. Depending on the
> situation, might even be able to go smaller.
>
>
>
> At a certain point, keeping that route around does nothing for you, just
> shoot it and ride the 0/0 train.
>
>
>
> On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha <
> paschal.masha at ke.wananchi.com> wrote:
>
> :) probably the longest prepend in the world.
>
> A thought though, is it breaking any standard or best practice procedures?
>
> Regards
> Paschal Masha | Engineering
> Skype ID: paschal.masha
>
> ----- Original Message -----
> From: "Erik Sundberg" <ESundberg at nitelusa.com>
> To: "nanog" <nanog at nanog.org>
> Sent: Friday, March 25, 2022 6:43:38 AM
> Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
>
> If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends
> for 46.42.196.0/24 from 255 prepends to a more reasonable number of
> prepends let's say 20. Thanks!
>
> This is a Kazakhstan register IP Block and ASN
>
>
>
> Network Next Hop Metric LocPrf Weight Path
>
> *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21 299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 i
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files
> or previous e-mail messages attached to it may contain confidential
> information that is legally privileged. If you are not the intended
> recipient, or a person responsible for delivering it to the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution or use of any of the information contained in or attached to
> this transmission is STRICTLY PROHIBITED. If you have received this
> transmission in error please notify the sender immediately by replying to
> this e-mail. You must destroy the original transmission and its attachments
> without reading or saving in any manner.
> Thank you.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220326/7339404f/attachment.html>


More information about the NANOG mailing list