Hello, I work with Bernardo. One piece of additional information: the problem seems to be caused by the interfaces being link down when BIRD comes up. They are already configured by the OS scripts, but they haven't finished negotiating the link yet (NO-CARRIER, state DOWN). After a few seconds the interfaces do come up, but it seems something inside BIRD (OSPF protocol, perhaps) is not noticing this. At the moment, as a workaround, we're doing a few sleeps before starting BIRD, until the interfaces are actually link up. But of course this isn't a solution. How can we help debug this further? Regards, -- Israel G. Lugo Núcleo de Redes e Comunicações Direção de Serviços de Informática Instituto Superior Técnico On 04-08-2015 13:03, Bernardo Figueiredo wrote:
Sorry for the delay.
I include the output of the commands you asked as attachments.
Doing birdc restart ospf1 worked.
Às 09:26 PM de 07/27/2015, Ondrej Zajicek escreveu:
On Wed, Jul 22, 2015 at 05:50:09PM +0100, Bernardo Figueiredo wrote:
Hello,
When restarting some routers at the institution I work, sometimes bird doesn't start announcing any routes until we either restart bird or restart When this happens: ... "bird> show ospf (...) Area networks: 10.3.0.0/16 Advertise 10.0.0.0/16 Advertise (...) I think that even though when bird first starts it shouldn't immediately start announcing(because it didn't see that the interfaces ip addresses), it should after 10 seconds when it scans again, because then the interfaces are already fully configured. ... So, my question is, shouldn't the Device protocol scan update see that the ip addresses of an interface have changed and if so, start announcing the route. Hello
BIRD Device protocol generally does not have problems with noticing new addresses. Most likely it could be problem with BIRD OSPF protocol not activating the interfaces / areas.
Could you also report results of 'show interfaces' and 'show ospf interfaces' when it works and when it does not? Does help just restarting the OSPF protocol (birdc restart ospf1)?