[quagga-dev 16614] Re: [quagga-users 14675] Potential problem in rib_process function

Balaji Gurudoss balajig81 at gmail.com
Thu May 11 03:56:59 BST 2017


Hi Atul

This would happen with any protocol and not with ospf because this is an
expected behaviour. I believe the following is what you are looking at

Router A-----Router B

You have configured a static route in Router B and are doing a redistribute
static into OSPF/BGP in Router B. The show ip route on Router B would show
the route as a BGP/OSPF learned route. Now on router B you configure a
static route with the same prefix pointing to a next-hop and in RTM the
newly created static route would be marked as the Best route instead of BGP
as the static route has more preference.

Now as per  BGP/OSPF is concerned, 50.1.1.0/24 is still the best route on
the router where the route was originated i.e Router B. On router A it
isn't the best route because a static route for the same prefix has been
created. In this scenario why should Router B withdraw the route ? How
would router B know that there is a static route existing in Router A for
the same destination ?

Hope you get my point.

Thanks,
  - Balaji


On Thu, May 11, 2017 at 12:07 AM, Atul Chowdhry <atul77 at gmail.com> wrote:

> Hi Balaji,
>  What do you mean when you say implicit withdraw ? I am seeing this in
> very simple topology of two routers running ospf and connected back to back.
>
> Rgds
> Atul
>
> On Wed, May 10, 2017 at 11:03 AM, Balaji Gurudoss <balajig81 at gmail.com>
> wrote:
>
>> Ideally speaking the implicit withdraw would happen when the new one gets
>> selected and old one gets validated. Are you seeing this issue with a very
>> simple topology with two routers connected back to back running OSPF or do
>> you see it in a specific topology ?
>>
>> Thanks,
>>   - Balaji
>>
>> On Wed, May 10, 2017 at 10:27 PM, Atul Chowdhry <atul77 at gmail.com> wrote:
>>
>>> Hi Guys,
>>>  I am using quagga release 1.2.1. I see one potential problem in
>>> rib_process function related to withdrawal of redistributed route from
>>> zebra.
>>> Problematic line is marked in bold letters.
>>> Suppose a prefix was already learned via OSPF. Now if I try to add a
>>> static route for same prefix, I hit this code.
>>> In this case. old_selected will point to OSPF and new_selected will
>>> point to Static. Now since ospf route is not the selected one, don;t we
>>> always have to withdraw this ospf route from clients redistributing
>>> OSPF.  Why there is extra check there ?
>>> I also tested this locally. If I comment this if statement then I see
>>> zebra sending delete for OSPF route else not.
>>>
>>> Pls give advice.
>>>
>>> Rgds
>>> Atul
>>>
>>>
>>>   /* Redistribute SELECTED entry */
>>> 1308   if (old_selected != new_selected
>>> 1309       || (new_selected && CHECK_FLAG (new_selected->status,
>>> RIB_ENTRY_CHANGED)))
>>> 1310     {
>>> 1311       if (old_selected)
>>> 1312         {
>>> 1313          * if (! new_selected)       >>>> Why this if statement is
>>> there ?? I fell this shouldn't be there.*
>>> 1314             redistribute_delete (&rn->p, old_selected);
>>> 1315           if (old_selected != new_selected)
>>> 1316             UNSET_FLAG (old_selected->flags, ZEBRA_FLAG_SELECTED);
>>> 1317         }
>>> 1318
>>> 1319       if (new_selected)
>>> 1320         {
>>> 1321           /* Install new or replace existing redistributed entry */
>>> 1322           SET_FLAG (new_selected->flags, ZEBRA_FLAG_SELECTED);
>>> 1323           redistribute_add (&rn->p, new_selected);
>>> 1324         }
>>> 1325      }
>>>
>>>
>>> _______________________________________________
>>> Quagga-users mailing list
>>> Quagga-users at lists.quagga.net
>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20170511/cf93e1cf/attachment.html>


More information about the Quagga-dev mailing list