Mailing List Archive

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@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@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@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@lists.quagga.net
>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>>>
>>>
>>
>

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 <atul77@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 <balajig81@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 <atul77@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@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@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@lists.quagga.net
>>>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>>>>>
>>>>>
>>>>
>>>
>>
>

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 <atul77@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 <balajig81@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 <atul77@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 <balajig81@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 <atul77@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@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@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@lists.quagga.net
>>>>>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>