<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 20, 2022 at 6:23 AM Jon Lewis <<a href="mailto:jlewis@lewis.org">jlewis@lewis.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...]<br>
While writing this though, two things occurred to me.<br>
<br>
1) Are there any networks with routing policy that looks at prepends and<br>
    says "if we see a peering path with >X number of prepends (or maybe<br>
    just path length >X), demote the localpref to transit or lower"?  "i.e.<br>
    They obviously don't want us using this path, turn it into a backup<br>
    path."<br>
<br>
2) Particularly back when it was found some BGP implementations broke when<br>
    encountering unusually long as-paths, I think it became somewhat common<br>
    to reject routes with "crazy long" as-paths.  If such policy is still<br>
    in place in many networks, excessive prepending would actually have the<br>
    desired effect for those networks.  i.e. The excessive prepends would<br>
    get that path rejected, keeping it from being used.<br></blockquote><div><br></div><div>At a previous job, I explicitly crafted policies that were structured such that:</div><div><br></div><div>if PREFIXLENGTH > MAXPREFIXLENGTH then reject</div><div>if ASPATH > MAXASPATH then reject</div><div>strip_internal_communities</div><div>if ASPATH > MAX_VALID_PATH then </div><div>   set localpref = TRANSIT_DEPREF_LOCALPREF</div><div>   set communities DEPREF_TRANSIT</div><div>   blah blah blah</div><div>if match external_signal_communities then</div><div>  set localpref</div><div>  set internal propagation communities</div><div>  set external propagation communities</div><div>  blah blah blah</div><div>then accept</div><div><br></div><div>that way, if the prefix size is too small, or the aspath is too long (>100), </div><div>it gets dropped before even bothering to evaluate communities; save </div><div>every bit of CPU and memory you can.</div><div>Then, strip your internal communities off everything else that's a reasonable </div><div>path length;</div><div>set a lower threshold for what you consider a "reasonable" internet diameter </div><div>to be, including a reasonable 3x prepend at one or two levels; if it's longer than </div><div>that, it's a backup path at best, treat it that way (below standard transit level)</div><div>finally, on all the remaining routes, evaluate your external signalling communities, </div><div>and apply internal signalling communities as appropriate, and process normally.</div><div><br></div><div>There's a clear tradeoff between trying to ensure maximum reachability </div><div>to the rest of the internet versus protecting your CPU and memory from </div><div>unnecessary work and state-keeping.  As mentioned in another thread, </div><div>what each network decides the MAXPREFIXLENGTH is will depend on </div><div>their relationships and the capabilities of their hardware.  It doesn't necessarily </div><div>have to be /24 and /48, but it should be set at the longest value your network </div><div>can happily support, unless you want to chase down odd connectivity issues </div><div>in other people's networks.  ^_^;</div><div><br></div><div>Thanks!</div><div><br></div><div>Matt</div><div><br></div><div><br></div><div><br></div></div></div>