Re: Networks ignoring prepends?

[Tom Beecher <beecher () beecher cc>]

> Because big operators think it reasonable to localpref distance routes
> ahead of nearby ones so long as the distant routes arrive from
> customers. I'll remember that the next time folks complain about the
> size of the routing table. This one you did to yourselves.

That has absolutely nothing to do with it, at all.

3356 is following common practice : Use customer routes before peer routes.
This is not some Illuminati based conspiracy , it's pretty standard stuff.
Nobody at 3356 is doing some magic latency based twerking to mess with you.
You kinda have a lousy upstream IMO.

It just so happens that their customer ( 47787 ) happens to takes a
*physical* pathway that is less performant than you'd prefer.

Two people ( myself and Andrew Hoyos ) went and looked , and found that the
upstream you use ( 53356 ) provides TE communities that you can use to
prevent your advertisement from being sent to 47787, thus avoiding that
poorly performing pathway, and hopefully using someone else better. Again,
for reference ( https://docs.freerangecloud.com/en/bgp/communities ).

You can:
1. Experiment with 53356's TE communities to prevent them from announcing
to upstreams that give you poor performance to 3356.
2. See if 47787 will talk to you about their path to 3356.  ( Doubtful,
since you aren't a direct customer of theirs.)
3. Pick an upstream that has better / more direct connectivity to 3356, use
them instead of /in parallel with 53356.
4. Get yourself connected to 3356 directly.
5. Keep yelling at the clouds about 3356 , even though they are doing the
same thing that (to the best of my knowledge) every large transit provider
does.


On Tue, Jan 23, 2024 at 3:02 PM William Herrin <bill () herrin us> wrote:

> On Tue, Jan 23, 2024 at 11:45 AM Owen DeLong via NANOG <nanog () nanog org>
> wrote:
> > The catch to all of that, however, is that he’s not directly peered with
> 3356 and many AS operators strip communities.
>
> And even if I didn't, the problem isn't just one ISP localprefing to
> prefer distant routes. Centurylink most directly impacts me, but as
> others have pointed out: many ISPs do the same darn thing. The only
> workable solution available to me appears to be tripling my presence
> in the DFZ tables.
>
> Because big operators think it reasonable to localpref distance routes
> ahead of nearby ones so long as the distant routes arrive from
> customers. I'll remember that the next time folks complain about the
> size of the routing table. This one you did to yourselves.
>
> Regards,
> Bill
>
>
> --
> William Herrin
> bill () herrin us
> https://bill.herrin.us/