On Sat, Apr 03, 2021 at 10:53:58PM -0400, Daniel Jakots wrote:
> Hi,
>
> I was reading bgpd.conf(5) on how to set the weight. It says:
>
> > For prefixes with equally long paths, the prefix with the larger
> > weight is selected.
>
> However, in bgpd(8), it says:
>
> > 8. The path with the lowest local weight is selected.
>
> I went to read rde_decide.c to find which is right, prefix_cmp()
> comment says
>
> > Returns an integer greater than or less than 0, according to
> > whether the prefix p1 is more or less preferred than the prefix p2
>
> and the code is
>
> if (asp1->weight > asp2->weight)
> return 1;
>
>
> Comments? OK?
Looks all good, bgpd.conf.5 revision 1.87 nicely confirms previous
pitfalls around this and how the *highest* weight wins:
date: 2007/10/21 21:34:14; author: mk; state: Exp; lines: +4 -2;
Being able to set the decision weight of prefixes is a nice feature, but
when it's not really documented in what way it influences the decision
process, people like myself will screw it up and assume that it gets
added to the prefix path lenth, and thus that smaller weight wins.
.. which is not the case. Document the actual behaviour.
bgpd(8) got its list of steps around five years after that commit, so
bgpd(8) had it twisted from the start.
OK kn
> Index: bgpd.8
> ===================================================================
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.8,v
> retrieving revision 1.64
> diff -u -p -r1.64 bgpd.8
> --- bgpd.8 16 Feb 2021 08:29:16 -0000 1.64
> +++ bgpd.8 4 Apr 2021 02:38:17 -0000
> @@ -90,7 +90,7 @@ Comparison of the BGP session type.
> Paths learned over an external (EBGP) session are preferred over those
> learned via an internal (IBGP) session.
> .It
> -The path with the lowest local
> +The path with the highest local
> .Em weight
> is selected.
> .It
>
>
>
> Cheers,
> Daniel
>
Locked
