Static routes stuck in dormant state (interface discovery broken?)

[Kenth Eriksson]

On Tue, 2018-09-18 at 16:45 +0200, Ondrej Zajicek wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you recognize the sender
> and know the content is safe.
> 
> 
> On Tue, Sep 18, 2018 at 02:14:35PM +0000, Kenth Eriksson wrote:
> > On Tue, 2018-09-18 at 14:27 +0200, Ondrej Zajicek wrote:
> > > CAUTION: This email originated from outside of the organization.
> > > Do
> > > not click links or open attachments unless you recognize the
> > > sender
> > > and know the content is safe.
> > > 
> > > 
> > > On Tue, Sep 18, 2018 at 08:38:56AM +0000, Kenth Eriksson wrote:
> > > > Hi!
> > > > 
> > > > I'm using BIRD 2.0.2 and have trouble with static routes that
> > > > gets
> > > > stuck in dormant state.  It looks as the problem happens if the
> > > > static route is pushed into BIRD config before the interface
> > > > exists. BIRD detects when interfaces go up and down, but misses
> > > > when interfaces are added. The only way I have found to kick
> > > > BIRD
> > > > out if this state is to issue another configure command after
> > > > the
> > > > interface exists.
> > > > 
> > > > Reproducing this is very easy, simply add a static route over a
> > > > sub-interface that is not yet created, this leaves the route in
> > > > dormant state
> > > 
> > > Hi
> > > 
> > > Works for me:
> > > 
> > > # ./birdc -l show static static4
> > > BIRD v2.0.2-40-g0ed3129f-x ready.
> > > 10.10.10.0/24
> > >     dev ve0.10 (dormant)
> > > 
> > > # ./birdc -l show route 10.10.10.0/24
> > > BIRD v2.0.2-40-g0ed3129f-x ready.
> > > Network not found
> > > 
> > > 
> > > # vconfig add ve0 10
> > > Added VLAN with VID == 10 to IF -:ve0:-
> > > 
> > > # ifconfig ve0.10 up
> > > 
> > > 
> > > # ./birdc -l show static static4
> > > BIRD v2.0.2-40-g0ed3129f-x ready.
> > > 10.10.10.0/24
> > >     dev ve0.10
> > > 
> > > # ./birdc -l show route 10.10.10.0/24
> > > BIRD v2.0.2-40-g0ed3129f-x ready.
> > > Table master4:
> > > 10.10.10.0/24        unicast [static4 14:21:18.093] * (200)
> > >     dev ve0.10
> > > 
> > > Although i am trying it on current int-new Git branch, i don't
> > > see
> > > any
> > > relevant changes since v2.0.2
> > > 
> > > Could you try it with enabled 'debug all' for static and device
> > > protocols
> > > and report the logs?
> > > 
> > > --
> > > Elen sila lumenn' omentielvo
> > > 
> > > Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
> > > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3,
> > > wwwkeys.pgp.net)
> > > "To err is human -- to blame it on a computer is even more so."
> > 
> > See traces below; the static protocol picks up the interface when
> > I'm
> > reconfiguring BIRD. This happens for PPC32 with libc-2.12.2.so and
> > Linux 4.14.51+. But I'm also able to see this on x86 (4.14.70).
> > 
> > 2018-09-18 15:25:33.304 <TRACE> device1: Scanning interfaces
> > 2018-09-18 15:25:38.303 <TRACE> device1: Scanning interfaces
> > 2018-09-18 15:25:43.304 <TRACE> device1: Scanning interfaces
> > 2018-09-18 15:25:44.299 <INFO> Reconfiguring
> > 2018-09-18 15:25:44.299 <TRACE> static1 > added [best]
> > 172.24.1.0/24
> > unicast
> > 2018-09-18 15:25:44.299 <TRACE> static1: Reconfigured
> > 2018-09-18 15:25:44.299 <TRACE> device1: Reconfigured
> > 2018-09-18 15:25:44.299 <INFO> Reconfigured
> 
> So there are no log messages when interface is created and enabled?

No I did not see any more logs. Maybe I need to enable more logs? This
was my log config;

log "/tmp/bird.log" all;
protocol device {debug all; ...}
protocol static {debug all; ...}

> 
> 
> > Can you give me your git sha you are running on? I can re-test on
> > that
> > and see if it makes a difference.
> 
> I am running on a043f2d79488cdfbc4d97ac0bad4926d29bf9a82 (int-new
> branch)

If I switch to that git sha, then this works for me as well.

bird> show status
BIRD 092c493
...
bird> 

2018-09-18 17:02:48.061 <TRACE> device1: Scanning interfaces
2018-09-18 17:03:11.377 <TRACE> static1 > added [best] 172.50.4.0/24
unicast

Looks broken in 2.0.2. Can you retest on 2.0.2 as well? 

Thanks,
Kenth