Mailing List Archive

Hi Dimitry,

Does it solve a problem you're seeing? If so, I can queue it onto
volatile/next.

regards,

Paul

On Tue, 14 Feb 2017, Dmitry Melekhov wrote:

>
> Hello!
>
> There are no replies in users mailing list,
> so I decided to ask developers.
>
> Thank you!
>
>
> -------- ???????????????? ????????? --------
> ????: Re: nssa, external routes from bgp, problem
> ????: Mon, 13 Feb 2017 12:19:02 +0400
> ??: Dmitry Melekhov <dm@belkam.com>
> ????: quagga-users@lists.quagga.net
>
>
>
> OK, I found similar bug report
> https: //bugzilla.quagga.net/show_bug.cgi?id=493
>
> There is proposed patch there and it is not included into quagga 1.2.0.
>
> Could you tell me this bug status?
> Is patch from there usable?
>
> Thank you!
>
> 13.02.2017 11:47, Dmitry Melekhov ?????:
>> Hello!
>>
>>
>> I run quite old version of quagga - version 0.99.24.1 , from centos7 ,
>>
>> but looks like there are no changes in ospf in newer versions....
>>
>>
>> I have following scheme:
>>
>>
>> area0 <->quagga<->area2<->cisco-router<->bgp.
>>
>>
>> I need to advertise routes from bgp to ospf, so I have:
>>
>> redistribute bgp ...
>>
>> on cisco,
>>
>>
>> but I don't need any routes from my ospf on cisco router,
>>
>> although I can have these routes on cisco right now.
>>
>> I decided make area2 nssa , so any ospf routes, including external,
>> will not be on cisco router.
>>
>> It worked OK for several days, but then , at weekend, there was
>> connectivity loss on bgp side and
>>
>> today I found that there are no routes from bgp in area 0, although
>> they are in area 2.
>>
>> Unfortunately, I had no time to read manuals and debug, so I just removed
>>
>> area 2 nssa .
>>
>>
>> I guess that when bgp routes were lost and appeared again, for some
>> reason LSA7 was not converted by quagga to LSA5.
>>
>>
>> Could you tell me how to solve this problem?
>>
>>
>> Thank you!
>>
>>
>
>
>

--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
What is now proved was once only imagin'd.
-- William Blake

Hello!


I did not tested patch from there yet, because we are in production, but
there are no replies,

so I'll try , when possible, and inform you about results.


Thank you!


23.02.2017 15:30, Paul Jakma ?????:
> Hi Dimitry,
>
> Does it solve a problem you're seeing? If so, I can queue it onto
> volatile/next.
>
> regards,
>
> Paul
>
> On Tue, 14 Feb 2017, Dmitry Melekhov wrote:
>
>>
>> Hello!
>>
>> There are no replies in users mailing list,
>> so I decided to ask developers.
>>
>> Thank you!
>>
>>
>> -------- ???????????????? ????????? --------
>> ????: Re: nssa, external routes from bgp, problem
>> ????: Mon, 13 Feb 2017 12:19:02 +0400
>> ??: Dmitry Melekhov <dm@belkam.com>
>> ????: quagga-users@lists.quagga.net
>>
>>
>>
>> OK, I found similar bug report
>> https: //bugzilla.quagga.net/show_bug.cgi?id=493
>>
>> There is proposed patch there and it is not included into quagga 1.2.0.
>>
>> Could you tell me this bug status?
>> Is patch from there usable?
>>
>> Thank you!
>>
>> 13.02.2017 11:47, Dmitry Melekhov ?????:
>>> Hello!
>>>
>>>
>>> I run quite old version of quagga - version 0.99.24.1 , from
>>> centos7 ,
>>>
>>> but looks like there are no changes in ospf in newer versions....
>>>
>>>
>>> I have following scheme:
>>>
>>>
>>> area0 <->quagga<->area2<->cisco-router<->bgp.
>>>
>>>
>>> I need to advertise routes from bgp to ospf, so I have:
>>>
>>> redistribute bgp ...
>>>
>>> on cisco,
>>>
>>>
>>> but I don't need any routes from my ospf on cisco router,
>>>
>>> although I can have these routes on cisco right now.
>>>
>>> I decided make area2 nssa , so any ospf routes, including external,
>>> will not be on cisco router.
>>>
>>> It worked OK for several days, but then , at weekend, there was
>>> connectivity loss on bgp side and
>>>
>>> today I found that there are no routes from bgp in area 0, although
>>> they are in area 2.
>>>
>>> Unfortunately, I had no time to read manuals and debug, so I just
>>> removed
>>>
>>> area 2 nssa .
>>>
>>>
>>> I guess that when bgp routes were lost and appeared again, for some
>>> reason LSA7 was not converted by quagga to LSA5.
>>>
>>>
>>> Could you tell me how to solve this problem?
>>>
>>>
>>> Thank you!
>>>
>>>
>>
>>
>>
>


_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Hello!

Looks like this patch fixes this problem, i.e. LSA5 is generated from LSA7:

2017/03/04 11:18:29 OSPF: LSA[Flooding]: start, NBR 172.17.0.18 (Full),
cur((nil)), New-LSA[Type7,id(10.236.16.0),ar(172.17.0.18)]
2017/03/04 11:18:29 OSPF: ospf_flood_through_interface(): considering
int eth1:10.18.0.254, INBR(172.17.0.18),
LSA[Type7,id(10.236.16.0),ar(172.17.0.18)]
2017/03/04 11:18:29 OSPF: ospf_flood_through_interface(): considering
nbr 172.17.0.18 (Full)
2017/03/04 11:18:29 OSPF: Skip this neighbor: inbr == onbr
2017/03/04 11:18:29 OSPF: ospf_flood_through_interface(): considering
nbr 10.18.0.254 (2-Way)
2017/03/04 11:18:29 OSPF: Route[External]: Calculate AS-external-LSA to
10.236.16.0/24
2017/03/04 11:18:29 OSPF: Route[External]: type-2 created.
2017/03/04 11:18:29 OSPF: Route[External]: Adding a new route 10.236.16.0/24
2017/03/04 11:18:29 OSPF: Route[External]: Calculate AS-external-LSA to
10.236.16.0/24
2017/03/04 11:18:29 OSPF: Route[External]: type-2 created.
2017/03/04 11:18:29 OSPF: Route[Compare]: Path types are the same.
2017/03/04 11:18:29 OSPF: Route[External]: Routes are equal
2017/03/04 11:18:29 OSPF: LSA[Type5]: Originate AS-external-LSA instance
2017/03/04 11:18:29 OSPF: LSA[Type5,id(10.236.16.0),ar(10.18.0.254)]:
Install AS-external-LSA



But I found another problem- LSA7 MaxAge does not remove routes from
local table and does produce LSA7:

2017/03/04 11:11:44 OSPF: LSA[Type7:10.236.16.0]: MaxAge LSA removed
from list
2017/03/04 11:11:44 OSPF: LSA[Type7:10.236.16.0]: data freed 0x7efe18430f00

And that's all , still have:

10.236.16.0 10.18.0.254 239 0x80000003 0xcebc E2 10.236.16.0/24
[0xfdf3]
10.236.16.0 172.17.0.18 891 0x80000001 0x0473 E2 10.236.16.0/24
[0xfde8]


netstat -rn | grep 10.236.16.
10.236.16.0 10.18.0.1 255.255.255.0 UG 0 0 0
eth1



btw, nssa translation only works with
nssa translate-always
with
translate-candidate Configure NSSA-ABR for translate election (default)
it does not translate all routes, although there is only one NSSA-ABR
here...



23.02.2017 17:06, Dmitry Melekhov ?????:
> Hello!
>
>
> I did not tested patch from there yet, because we are in production,
> but there are no replies,
>
> so I'll try , when possible, and inform you about results.
>
>
> Thank you!
>
>
> 23.02.2017 15:30, Paul Jakma ?????:
>> Hi Dimitry,
>>
>> Does it solve a problem you're seeing? If so, I can queue it onto
>> volatile/next.
>>
>> regards,
>>
>> Paul
>>
>> On Tue, 14 Feb 2017, Dmitry Melekhov wrote:
>>
>>>
>>> Hello!
>>>
>>> There are no replies in users mailing list,
>>> so I decided to ask developers.
>>>
>>> Thank you!
>>>
>>>
>>> -------- ???????????????? ????????? --------
>>> ????: Re: nssa, external routes from bgp, problem
>>> ????: Mon, 13 Feb 2017 12:19:02 +0400
>>> ??: Dmitry Melekhov <dm@belkam.com>
>>> ????: quagga-users@lists.quagga.net
>>>
>>>
>>>
>>> OK, I found similar bug report
>>> https: //bugzilla.quagga.net/show_bug.cgi?id=493
>>>
>>> There is proposed patch there and it is not included into quagga 1.2.0.
>>>
>>> Could you tell me this bug status?
>>> Is patch from there usable?
>>>
>>> Thank you!
>>>
>>> 13.02.2017 11:47, Dmitry Melekhov ?????:
>>>> Hello!
>>>>
>>>>
>>>> I run quite old version of quagga - version 0.99.24.1 , from
>>>> centos7 ,
>>>>
>>>> but looks like there are no changes in ospf in newer versions....
>>>>
>>>>
>>>> I have following scheme:
>>>>
>>>>
>>>> area0 <->quagga<->area2<->cisco-router<->bgp.
>>>>
>>>>
>>>> I need to advertise routes from bgp to ospf, so I have:
>>>>
>>>> redistribute bgp ...
>>>>
>>>> on cisco,
>>>>
>>>>
>>>> but I don't need any routes from my ospf on cisco router,
>>>>
>>>> although I can have these routes on cisco right now.
>>>>
>>>> I decided make area2 nssa , so any ospf routes, including external,
>>>> will not be on cisco router.
>>>>
>>>> It worked OK for several days, but then , at weekend, there was
>>>> connectivity loss on bgp side and
>>>>
>>>> today I found that there are no routes from bgp in area 0, although
>>>> they are in area 2.
>>>>
>>>> Unfortunately, I had no time to read manuals and debug, so I just
>>>> removed
>>>>
>>>> area 2 nssa .
>>>>
>>>>
>>>> I guess that when bgp routes were lost and appeared again, for some
>>>> reason LSA7 was not converted by quagga to LSA5.
>>>>
>>>>
>>>> Could you tell me how to solve this problem?
>>>>
>>>>
>>>> Thank you!
>>>>
>>>>
>>>
>>>
>>>
>>
>


_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On Sat, 4 Mar 2017, Dmitry Melekhov wrote:

> Hello!
>
> Looks like this patch fixes this problem, i.e. LSA5 is generated from LSA7:

Great.

> But I found another problem- LSA7 MaxAge does not remove routes from
> local table and does produce LSA7:

> 2017/03/04 11:11:44 OSPF: LSA[Type7:10.236.16.0]: MaxAge LSA removed from
> list
> 2017/03/04 11:11:44 OSPF: LSA[Type7:10.236.16.0]: data freed 0x7efe18430f00

> And that's all , still have:
>
> 10.236.16.0 10.18.0.254 239 0x80000003 0xcebc E2 10.236.16.0/24
> [0xfdf3]
> 10.236.16.0 172.17.0.18 891 0x80000001 0x0473 E2 10.236.16.0/24
> [0xfde8]

Hmm, is it perhaps that the type-5 wasn't flushed at the same time? I.e.
the type-7 is gone, but the synthesised type-5 that was translated from
it hung around and is leading to this and the route?

What does 'show ip ospf database' say?

> netstat -rn | grep 10.236.16.
> 10.236.16.0 10.18.0.1 255.255.255.0 UG 0 0 0 eth1
>
>
>
> btw, nssa translation only works with nssa translate-always with
> translate-candidate Configure NSSA-ABR for translate election
> (default) it does not translate all routes, although there is only one
> NSSA-ABR here...

Ah.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Mouse has out-of-cheese-error

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

06.03.2017 02:14, Paul Jakma ?????:
> On Sat, 4 Mar 2017, Dmitry Melekhov wrote:
>
>> Hello!
>>
>> Looks like this patch fixes this problem, i.e. LSA5 is generated from
>> LSA7:
>
> Great.
>
>> But I found another problem- LSA7 MaxAge does not remove routes from
>> local table and does produce LSA7:
>
>> 2017/03/04 11:11:44 OSPF: LSA[Type7:10.236.16.0]: MaxAge LSA removed
>> from list
>> 2017/03/04 11:11:44 OSPF: LSA[Type7:10.236.16.0]: data freed
>> 0x7efe18430f00
>
>> And that's all , still have:
>>
>> 10.236.16.0 10.18.0.254 239 0x80000003 0xcebc E2
>> 10.236.16.0/24 [0xfdf3]
>> 10.236.16.0 172.17.0.18 891 0x80000001 0x0473 E2
>> 10.236.16.0/24 [0xfde8]
>
> Hmm, is it perhaps that the type-5 wasn't flushed at the same time?
No, I guess that type-5 was not generated because of this bug.
Although even local (on NSSA-ABR ) routing database was not altered:

netstat -rn | grep 10.236.16.
10.236.16.0 10.18.0.1 255.255.255.0 UG 0 0 0
eth1

I.e. quagga just ignores MaxAge LSA Type 7.
At least it looks like this.

> I.e. the type-7 is gone, but the synthesised type-5 that was
> translated from it hung around and is leading to this and the route?
>
> What does 'show ip ospf database' say?


This (on NSSA-ABR):

10.236.16.0 10.18.0.254 239 0x80000003 0xcebc E2 10.236.16.0/24
[0xfdf3]
10.236.16.0 172.17.0.18 891 0x80000001 0x0473 E2 10.236.16.0/24
[0xfde8]


>
>> netstat -rn | grep 10.236.16.
>> 10.236.16.0 10.18.0.1 255.255.255.0 UG 0
>> 0 0 eth1
>>
>>
>>
>> btw, nssa translation only works with nssa translate-always with
>> translate-candidate Configure NSSA-ABR for translate election
>> (default) it does not translate all routes, although there is only
>> one NSSA-ABR here...
>
> Ah.
>
> regards,


_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev