I have a router with a simple babel protocol announced on an interface: protocol babel babel { interface "eth2" { next hop prefer ipv6; }; ipv4 { export where net ~ [0.0.0.0/0]; import none; }; ipv6 { export where net ~ [::/0]; import none; }; randomize router id; } bird> show proto babel Name Proto Table State Since Info babel Babel --- up 17:32:00.497 Out of interest, I tried the 'show babel' commands, but couldn't work out the syntax: bird> show babel ? show babel interfaces [<name>] ["<interface>"] Show information about Babel interfaces show babel neighbors [<name>] ["<interface>"] Show information about Babel neighbors show babel entries [<name>] Show information about Babel prefix entries show babel routes [<name>] Show information about Babel route entries bird> show babel interfaces "eth2" syntax error, unexpected CF_SYM_KNOWN bird> show babel interfaces babel syntax error, unexpected CF_SYM_KNOWN bird> show babel routes babel syntax error, unexpected CF_SYM_KNOWN What would be a correct argument to supply to these commands? In case it's relevant, I'm running 2.17.1 on Linux, which is the latest 2.x version on https://bird.network.cz/ https://bird.network.cz/download/ although I've just spotted there was a 2.17.2 announced on the mailing list in September. Best wishes, Chris.
Chris Webb via Bird-users <bird-users@network.cz> writes:
I have a router with a simple babel protocol announced on an interface:
protocol babel babel { interface "eth2" { next hop prefer ipv6; }; ipv4 { export where net ~ [0.0.0.0/0]; import none; }; ipv6 { export where net ~ [::/0]; import none; }; randomize router id; }
bird> show proto babel Name Proto Table State Since Info babel Babel --- up 17:32:00.497
Out of interest, I tried the 'show babel' commands, but couldn't work out the syntax:
bird> show babel ? show babel interfaces [<name>] ["<interface>"] Show information about Babel interfaces show babel neighbors [<name>] ["<interface>"] Show information about Babel neighbors show babel entries [<name>] Show information about Babel prefix entries show babel routes [<name>] Show information about Babel route entries bird> show babel interfaces "eth2" syntax error, unexpected CF_SYM_KNOWN bird> show babel interfaces babel syntax error, unexpected CF_SYM_KNOWN bird> show babel routes babel syntax error, unexpected CF_SYM_KNOWN
What would be a correct argument to supply to these commands?
They're supposed to work the way you specify, and it does for me: bird> show proto babel1 Name Proto Table State Since Info babel1 Babel --- up 2025-10-11 bird> show babel interfaces babel1 "br-lan" babel1: Interface State Auth RX cost Nbrs Timer Next hop (v4) Next hop (v6) br-lan Up Yes 96 1 2.159 10.42.6.1 fe80::da58:d7ff:fe00:1d2b I think what's happening is a symbol collision: you've named your babel instance 'babel', but the command line parser has 'babel' as a reserved keyword, so it barfs. Indeed, I get a different error message for 'babel' vs (the also non-existent babel2): bird> show proto babel2 syntax error, unexpected CF_SYM_UNDEFINED, expecting END or CF_SYM_KNOWN or TEXT or ALL bird> show proto babel syntax error, unexpected BABEL, expecting END or CF_SYM_KNOWN or TEXT or ALL Notice BABEL instead of CF_SYM_UNDEFINED - indicating a keyword... So, erm, just rename your protocol instance, and things should work fine? Or, given that you only have on instance, just run 'show babel interfaces' with no arguments... -Toke
Toke Høiland-Jørgensen <toke@toke.dk> writes:
I think what's happening is a symbol collision: you've named your babel instance 'babel', but the command line parser has 'babel' as a reserved keyword, so it barfs.
Oh, fun. That'll be why I never noticed it before too, because I had multiple protocols called babel1, babel2, etc.
Or, given that you only have on instance, just run 'show babel interfaces' with no arguments...
When it's called 'babel', even that turns out to break: bird> show babel interfaces syntax error, unexpected CF_SYM_KNOWN All is fixed once I rename the protocol, as you say. Thanks! Best wishes, Chris.
On Mon, Oct 13, 2025 at 01:30:49PM +0200, Toke Høiland-Jørgensen via Bird-users wrote:
They're supposed to work the way you specify, and it does for me:
bird> show proto babel1 Name Proto Table State Since Info babel1 Babel --- up 2025-10-11 bird> show babel interfaces babel1 "br-lan" babel1: Interface State Auth RX cost Nbrs Timer Next hop (v4) Next hop (v6) br-lan Up Yes 96 1 2.159 10.42.6.1 fe80::da58:d7ff:fe00:1d2b
I think what's happening is a symbol collision: you've named your babel instance 'babel', but the command line parser has 'babel' as a reserved keyword, so it barfs.
Yes, exactly. In earlier versions, we forbade names that collide with keywords, but that caused compatibility issues when users upgrade to a new version, which may have new keywords that are accidentally the same as user-defined names. We changed that so a used-defined name overrides the keyword, so there is no compatibility problem, but it may lead to a strange behavior like this, as (due to how our parser is written) the name-keyword distinction is done independently of any context. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Hello, world!\n
Yes, exactly. In earlier versions, we forbade names that collide with keywords, but that caused compatibility issues when users upgrade to a new version, which may have new keywords that are accidentally the same as user-defined names. We changed that so a used-defined name overrides the keyword, so there is no compatibility problem, but it may lead to a strange behavior like this, as (due to how our parser is written) the name-keyword distinction is done independently of any context.
Perhaps it deserves a warning when parsing the configuration file then? Martin
On Thu, Oct 16, 2025 at 03:06:25PM +0200, Martin Mareš wrote:
Hello, world!\n
Yes, exactly. In earlier versions, we forbade names that collide with keywords, but that caused compatibility issues when users upgrade to a new version, which may have new keywords that are accidentally the same as user-defined names. We changed that so a used-defined name overrides the keyword, so there is no compatibility problem, but it may lead to a strange behavior like this, as (due to how our parser is written) the name-keyword distinction is done independently of any context.
Perhaps it deserves a warning when parsing the configuration file then?
Yes, thought about that, will add it. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
participants (4)
-
Chris Webb -
Martin Mareš -
Ondrej Zajicek -
Toke Høiland-Jørgensen