Re: Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing?

[Matthew Petach <mpetach () netflight com>]

On Thu, Oct 20, 2022 at 6:23 AM Jon Lewis <jlewis () lewis org> wrote:

> [...]
> While writing this though, two things occurred to me.
>
> 1) Are there any networks with routing policy that looks at prepends and
>     says "if we see a peering path with >X number of prepends (or maybe
>     just path length >X), demote the localpref to transit or lower"?  "i.e.
>     They obviously don't want us using this path, turn it into a backup
>     path."
>
> 2) Particularly back when it was found some BGP implementations broke when
>     encountering unusually long as-paths, I think it became somewhat common
>     to reject routes with "crazy long" as-paths.  If such policy is still
>     in place in many networks, excessive prepending would actually have the
>     desired effect for those networks.  i.e. The excessive prepends would
>     get that path rejected, keeping it from being used.

At a previous job, I explicitly crafted policies that were structured such
that:

if PREFIXLENGTH > MAXPREFIXLENGTH then reject
if ASPATH > MAXASPATH then reject
strip_internal_communities
if ASPATH > MAX_VALID_PATH then
   set localpref = TRANSIT_DEPREF_LOCALPREF
   set communities DEPREF_TRANSIT
   blah blah blah
if match external_signal_communities then
  set localpref
  set internal propagation communities
  set external propagation communities
  blah blah blah
then accept

that way, if the prefix size is too small, or the aspath is too long
(>100),
it gets dropped before even bothering to evaluate communities; save
every bit of CPU and memory you can.
Then, strip your internal communities off everything else that's a
reasonable
path length;
set a lower threshold for what you consider a "reasonable" internet
diameter
to be, including a reasonable 3x prepend at one or two levels; if it's
longer than
that, it's a backup path at best, treat it that way (below standard transit
level)
finally, on all the remaining routes, evaluate your external signalling
communities,
and apply internal signalling communities as appropriate, and process
normally.

There's a clear tradeoff between trying to ensure maximum reachability
to the rest of the internet versus protecting your CPU and memory from
unnecessary work and state-keeping.  As mentioned in another thread,
what each network decides the MAXPREFIXLENGTH is will depend on
their relationships and the capabilities of their hardware.  It doesn't
necessarily
have to be /24 and /48, but it should be set at the longest value your
network
can happily support, unless you want to chase down odd connectivity issues
in other people's networks.  ^_^;

Thanks!

Matt