Static routes stuck in dormant state (interface discovery broken?)
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 Add static route over a sub-interface protocol static { route 172.23.1.0/24 via "eth1.666"; } Reconfigure BIRD, note it picks it up as dormant. bird> configure Reading configuration from /tmp/bird.conf Reconfigured bird> show static 172.23.1.0/24 dev eth1.666 (dormant) bird> Now create the sub-interface and bring it up vconfig add eth1 666 ifconfig eth1.666 up BIRD does not discover that the interface was created and does not push the route into the kernel. Thanks, Kenth
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@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."
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@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 Can you give me your git sha you are running on? I can re-test on that and see if it makes a difference. Thanks, Kenth
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@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?
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) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
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@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
On Tue, Sep 18, 2018 at 03:08:19PM +0000, Kenth Eriksson wrote:
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; ...}
My mistake, these protocols do not generate interface log messages.
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.
Looks broken in 2.0.2. Can you retest on 2.0.2 as well?
You are right, it is broken on 2.0.2, it is fixed by patch: 586c1800c447ff099d34889b23647c4733876d9b Nest: Neighbor cache cleanups -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On Tue, Sep 18, 2018 at 07:34:03PM +0200, Ondrej Zajicek wrote:
Looks broken in 2.0.2. Can you retest on 2.0.2 as well?
You are right, it is broken on 2.0.2, it is fixed by patch:
586c1800c447ff099d34889b23647c4733876d9b Nest: Neighbor cache cleanups
So it is likely specific to interface neighbor cache entries (which are used by static protocol), general interface discovery / notifications should work fine. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On Tue, 2018-09-18 at 19: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 07:34:03PM +0200, Ondrej Zajicek wrote:
Looks broken in 2.0.2. Can you retest on 2.0.2 as well?
You are right, it is broken on 2.0.2, it is fixed by patch:
586c1800c447ff099d34889b23647c4733876d9b Nest: Neighbor cache cleanups
So it is likely specific to interface neighbor cache entries (which are used by static protocol), general interface discovery / notifications should work fine.
I can confirm that 586c1800c447ff099d34889b23647c4733876d9b cherry- picked on top of 2.0.2 works as well. Are you planning a 2.0.3 any time soon to address this issue? We could make use of that. Thanks, Kenth
participants (2)
-
Kenth Eriksson -
Ondrej Zajicek