Hi Atul
i get your point. This looks like an issue. It does not make sense to have
that route on the peer. This route should be withdrawn from Router B as the
OSPF route is no more the best route. Can you open a bug for this in
bugzilla.quagga.net
Thanks,
- Balaji
On Sat, May 13, 2017 at 1:06 AM, Atul Chowdhry <atu...@gmail.com> wrote:
> Hi Balaji,
> Router A--------Router B---------Router C
> Lets say Router B and C have an RIP session and Router A and B have OSPF
> session. Router B's RIP is redistributing OSPF.
> Router B learns 50.1.1.0/24 route from Router A through OSPF and
> redistributes that route to Router C.
> Now On Router B, user configures a static route with same prefix (
> 50.1.1.0/24). This static route on router B will be chosen as best route
> because
> of lesser administrative distance.
> Now question is Doesn't Router B withdraw its earlier distributed OSPF
> route (50.1.1.0/24) from Router C ?
>
> Rgds
> Atul
>
>
>
> On Fri, May 12, 2017 at 10:54 AM, Balaji Gurudoss <balaji...@gmail.com>
> wrote:
>
>> Hi Atul
>>
>> My example also is about configuring static route on the same box where
>> the route is learned as an OSPF route.
>>
>> Can you let me know if my understanding below is right
>>
>> Router A--------Router B
>>
>> 1.Router B has a static route configured (eg: 50.1.1.0/24 10.1.1.50)
>> 2. Router B has redistribute static configured
>> 3. There is OSPF/BGP session configured between Router A and Router B
>> 4. On Router A the prefix 50.1.1.0/24 would be shown as an OSPF/BGP
>> learned route
>> 5. On Router A a static route pointing to 50.1.1.0/24 is now configured
>> with a different next-hop.
>> 6. On Router A, the static route is displayed as the best route instead
>> of the OSPF route because of lesser administrative distance for static
>> route.
>>
>> Now in the above mentioned scenario, what is your expectation and whats
>> your question
>>
>> Thanks,
>> - Balaji
>>
>>
>>
>> On Fri, May 12, 2017 at 11:11 PM, Atul Chowdhry <atu...@gmail.com> wrote:
>>
>>> Hi Balaji,
>>> May be I am missing something but I am talking about both static and
>>> OSPF route on same router. In ur example, Its assuming that static route is
>>> added on Router B rather than A.
>>> Any other quagga Guru, who can pls clarify my query here ?
>>>
>>> Rgds
>>> Atul
>>>
>>> On Wed, May 10, 2017 at 7:56 PM, Balaji Gurudoss <balaji...@gmail.com>
>>> wrote:
>>>
>>>> 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 <atu...@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 <balaji...@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 <atu...@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-us...@lists.quagga.net
>>>>>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
