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

Joakim Tjernlund joakim.tjernlund at transmode.se
Fri Aug 20 21:48:31 BST 2010


Greg Troxel <gdt at ir.bbn.com> wrote on 2010/08/20 20:26:25:
>
>
> Joakim Tjernlund <joakim.tjernlund at transmode.se> writes:
>
> > 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
> >>
> >>   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.
>
> Is the metric something matched by OS kernels in doing a lookup, or
> something that is looked up?  I still think metric is part of the value,
> not the key.

you can routes in kernel that only differs in metric and/or interface. When
you want to delete such routes you need to specify metric/interface when
deleting routes, otherwise the kernel just selects the closest match and
delete that one.

>
> >> 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.
>
> I can see your point, but decided that if there is an issue here it's a
> layered issue beyond something that obviously should be fixed, and
> having verified that nothing bad happens with the first fix, I did it.

Right, I just whish you would apply the fix(es) to the route delete code
that have been floating around for a long time, lots of people uses it
with no complaints.




More information about the Quagga-dev mailing list