DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

Thu Mar 31 22:44:03 UTC 2022

On Thu, Mar 31, 2022 at 3:16 PM Joe Maimon <jmaimon at jmaimon.com> wrote:

>
>
> Joe Provo wrote:
> > On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:
> >> :) probably the longest prepend in the world.
> >>
> >> A thought though, is it breaking any standard or best practice
> procedures?
> >
> > That said, prepending pretty much anything more than your current view
> > of the Internet's diameter in ASNs is useless in practice. Cascading
> > effects are considered in
> > https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
> > where a decent low number (5) is propsed.
> >
> > Chers,
> >
> > Joe
> >
>
> So is there a good way to signal along with a BGP route that the
> originator of the route wants you to know that this route has very high
> suckage factor and even if you normally prefer your peers customers
> whatever, you should perhaps think twice about that for this route,
> cause its really last resort.
>
> Because as-path is an overloaded multimeaning traffic influencing hammer
> that has imprecise and frequently undesirable results. And if that were
> not the case, than discussions of its relative size compared to internet
> diameter would be much more relevant.
>
> Joe
>
>
Unfortunately, the reason crazy-long prepends actually propagate so
widely in the internet core is because most of those decisions to prefer
your peer's customers are done using a relatively big and heavy hammer.

LOCAL_PREF is, in my opinion, the wrong tool to use, but it's what most
of the networks out there seem to have settled on, to the point of having
published BGP communities to use for controlling the LOCAL_PREF setting
on received routes: https://onestep.net/communities/

I've long practiced, and advocated for, the use of MEDs or tweaking origin
codes as a better way to nudge traffic towards customers, peers, customers
of peers, etc., because it still allows as-path to be a factor in nudging
traffic
away.   Prepend inbound 3 times on routes learned from your transit
provider,
but not on your peers, listen to MEDs from your peers, and enable
always-compare-med
and deterministic-med to allow values to be compared across different
pathways.

That way, someone trying to say "don't use this path" can do a simple
triple-prepend,
and see their traffic shift.  In our current world of using LOCAL_PREF,
however, the
poor customer keeps prepending more and more, and never sees their traffic
shift.
In desperation, they prepend the maximum number of times allowed, hoping
that
maybe this will somehow do the trick...not understanding that no matter
what they
do in the prepend realm, so long as their upstreams are using the
LOCAL_PREF
hammer, their prepends will fall on deaf ears.

For the most part--if you think LOCAL_PREF is the right knob to use for
moving
traffic, it probably means you need to go back and rethink your traffic
engineering
approach.   ^_^;

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220331/6f11f0aa/attachment.html>