[quagga-dev 8165] Re: [PATCH] Zebra zserv: bogus conditional

Joakim Tjernlund joakim.tjernlund at transmode.se
Thu Aug 19 21:17:46 BST 2010


Greg Troxel <gdt at ir.bbn.com> wrote on 2010/08/19 20:36:17:
>
>
>   From: Joakim Tjernlund <joakim.tjernlund at transmode.se>
>   Date: Thu, 19 Aug 2010 09:30:44 +0200
>
>   > On Wed, 18 Aug 2010 20:54:30 -0400
>   > Greg Troxel <gdt at ir.bbn.com> wrote:
>   >
>   > > Stephen Hemminger <shemminger at vyatta.com> writes:
>   > >
>   > > I certainly see your point.  But, do you have an explanation of why the
>   > > code used to work, or a description of how the behavior was wrong?  Or
>   > > is cmd always one of those two, so the fact that this devolved to if(1)
>   > > is not an actual bug, just a latent bug?
>   >
>   > What happens is the old code adds unnecessary distance and metric info
>   > when routes are deleted. The zebra client protocol is NAME/VALUE so
>   > the extra info was just being ignored by the other servers.
>
> OK, makes sense.  I'm always just nervous about changing things when I
> don't fully understand.
>
>   Shouldn't this info always be included when deleting routes? It is
>   possible to have routes which only differs in metric so how to tell
>   which one to delete?
>
> routes are key-value pairs.  AFAIK the key is protocol/prefix/length and
> the metric is part of the value.  So I don't think it makes sense to
> have two routes that differ only in metric, unless we're doing
> equal-cost multipath and we need a way to specify the value as well.
> But if we need that we should add it explicitly as a separate commit.

It just doesn't feel right that that one uses a wider key to delete
routes than when adding them.

>
> Are you saying that there are existing use cases which rely on this bug?

No, just a reflection considering how broken Q's route deletion code is.




More information about the Quagga-dev mailing list