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 <[email protected]>
Кому: [email protected]
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
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
