- Bird-users - Mailing Lists

merge paths on gives syntax error
by Eelco Nieuwstad 09 Aug '16

09 Aug '16

Hi, I am running the default Bird install (1.5.0-4build1) from Ubuntu 16.0.4 and when I enable merge paths on the kernel protocol bird refuses to start because of a syntax error. This is the very default config I use. Do I miss something obvious? log syslog { info, remote, warning, error, auth, fatal, bug }; router id 172.16.1.252; # The Kernel protocol is not a real routing protocol. Instead of communicating # with other routers in the network, it performs synchronization of BIRD's # routing tables with the OS kernel. protocol kernel { import none; merge paths on; export all; } protocol bgp { local as 65000; neighbor 172.16.3.2 as 65000; } protocol device { scan time 60; } Eelco Nieuwstad

3 3

Source address on OSPFv2 HELLO
by Iain Buchanan 04 Aug '16

04 Aug '16

How is the source address for OSPFv2 HELLO packets decided? I'm hitting a problem where I can see them going out with the wrong source address, preventing the other side from setting up communication. I've got a real network adapter with Bird working over a GRE tunnel. Bird chooses the real network adapter's source address, not the GRE tunnel (another instance of bird on the other side of the GRE tunnel correctly uses the tunnel address). If I send a ping over the tunnel it uses the GRE tunnel's source address, and the routing table matches this. Why would bird use a different address? Iain

2 1

Getting details about LSAs
by Israel G. Lugo 01 Aug '16

01 Aug '16

Hello, Is there a way to obtain more information about LSAs? I've been debugging an issue with a hardware router. I know I can do this: bird> show ospf lsadb lsid 10.16.80.0 Global Type LS ID Router Sequence Age Checksum 0005 10.16.80.0 192.168.253.6 800012e8 1193 e030 0005 10.16.80.0 193.136.152.3 8000042a 1464 0a6f But I'd like to see things such as the Forwarding Address in AS-external-LSAs, the Options field, and so on. Would this be possible to do? Perhaps adding an "all" option to the show ospf lsadb command. I think it would prove valuable for troubleshooting those weird cases. Regards, -- Israel G. Lugo Núcleo de Redes e Comunicações Direção de Serviços de Informática Instituto Superior Técnico

2 3

BFD parameters not taken into account
by Benoit Portrat 29 Jul '16

29 Jul '16

Hello, After some lab tests with bfd and bgp, I've encountered a problem. bfd sessions associated with bgp sessions are up but bfd parameters in config file are not taken into account and there is no sign of error in the logs. I have reproduced it with bird 1.5.0 and bird 1.6.0. I've not found any trace of a problem like this in the mailing list. I don't know if I've missed something or if this is a bug. For debug purpose, I have two nodes with a config like this : log syslog all; debug protocols all; define local_as = 65101; # Router params router id 192.168.10.1; # Protocols protocol device { scan time 10; } protocol direct { interface "*"; } protocol kernel { persist; scan time 20; import none; export all; } protocol bgp { local as local_as; source address 192.168.10.1; import none; export none; neighbor 192.168.10.2 as local_as; bfd; } protocol bfd { interface "*" { interval 400 ms; multiplier 10; }; } But when I display the bfd session, I can see that interval and timeout are on default values : bird> show bfd sessions bfd1: IP address Interface State Since Interval Timeout 192.168.10.2 --- Up 18:19:37 0.100 0.500 Explicitly declaring the bfd neighbors in the config block doesn't change anything. Does someone have already encountered this problem ? Regards, -- Benoit Portrat

2 2

[PATCH] Gate boolean protocol options on filename.
by João Taveira Araújo 29 Jul '16

29 Jul '16

Toggling session parameters currently requires editing the configuration file and reloading BIRD. Doing so programatically requires keeping up with the syntax and layout of a particular configuration. This commit introduces an alternative method for gating configuration of boolean protocol properties. In addition to the keywords on/off and yes/no, a user can instead provide a filename on which to predicate whether the flag is set. In particular, this makes toggling protocols programatically much simpler, since we can decouple state from configuration more cleanly, i.e: protocol kernel { disabled filename "/etc/disable-kernel"; } --- conf/cf-lex.l | 23 +++++++++++++++++++++++ conf/conf.h | 1 + conf/confbase.Y | 3 ++- doc/bird.sgml | 5 +++-- 4 files changed, 29 insertions(+), 3 deletions(-) diff --git a/conf/cf-lex.l b/conf/cf-lex.l index 5a2a4d6..af85291 100644 --- a/conf/cf-lex.l +++ b/conf/cf-lex.l @@ -693,6 +693,29 @@ cf_symbol_class_name(struct symbol *sym) } } +/** + * cf_file_exists - check if expanded filename exists + * @arg: filename + * + * This function expands relative filenames and returns + * whether file is present. + */ +int +cf_file_exists(char *arg) +{ + char *patt = arg; + + if (*arg != '/') + { + int dlen = strlen(ifs->file_name); + char *dir = alloca(dlen + 1); + patt = alloca(dlen + strlen(arg) + 2); + memcpy(dir, ifs->file_name, dlen + 1); + sprintf(patt, "%s/%s", dirname(dir), arg); + } + + return access(patt, F_OK) != -1; +} /** * DOC: Parser diff --git a/conf/conf.h b/conf/conf.h index 89a2c5b..6f6a33d 100644 --- a/conf/conf.h +++ b/conf/conf.h @@ -160,6 +160,7 @@ char *cf_symbol_class_name(struct symbol *sym); static inline int cf_symbol_is_constant(struct symbol *sym) { return (sym->class & 0xff00) == SYM_CONSTANT; } +int cf_file_exists(char *arg); /* Parser */ diff --git a/conf/confbase.Y b/conf/confbase.Y index 5f487c1..7ee26f3 100644 --- a/conf/confbase.Y +++ b/conf/confbase.Y @@ -88,7 +88,7 @@ CF_DECLS %left '!' %nonassoc '.' -CF_KEYWORDS(DEFINE, ON, OFF, YES, NO, S, MS, US, PORT) +CF_KEYWORDS(DEFINE, ON, OFF, YES, NO, S, MS, US, PORT, FILENAME) CF_GRAMMAR @@ -143,6 +143,7 @@ bool: | YES { $$ = 1; } | OFF { $$ = 0; } | NO { $$ = 0; } + | FILENAME text { $$ = cf_file_exists($2); } | /* Silence means agreement */ { $$ = 1; } ; diff --git a/doc/bird.sgml b/doc/bird.sgml index a0b45f4..03682cb 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -493,8 +493,9 @@ protocol (see sections talking about the protocols). <p>Several options use a <m/switch/ argument. It can be either <cf/on/, <cf/yes/ or a numeric expression with a non-zero value for the option to be enabled or <cf/off/, <cf/no/ or a numeric expression evaluating to zero to -disable it. An empty <m/switch/ is equivalent to <cf/on/ ("silence means -agreement"). +disable it. Alternatively you can gate the value of <m/switch/ on the presence +of a file through the <cf/filename/ "<m/name/" directive. An empty <m/switch/ +is equivalent to <cf/on/ ("silence means agreement"). <descrip> <tag>preference <m/expr/</tag> -- 2.8.1

5 10

Addresses in the lo interface not being announced in OSPFv3
by Bernardo Figueiredo 29 Jul '16

29 Jul '16

I'm having a problem with bird 1.5.0 running OSPFv3. When I add a host route(/128) to "lo" interface, and add the "lo" interface to an OSPF area, the interface doesn't get picked up, and consequently the route isn't announced. This problem doesn't happen using bird when running in IPv4 using OSPFv2. I digged through the code and think found the cause of difference in behaviour. When being notified of interface changes, the protocols use different functions: OSPFv2 uses proto/ospf/iface.c:ospf_ifa_notify2 OSPFv3 uses proto/ospf/iface.c:ospf_ifa_notify3 In OSPFv2 the interface is added to the ospf protocol(ospf_iface_new) if it has a address that is not secondary, with scope greater than link and the interface is changed to up. This works, because the IPv4 we add to the lo interface is primary and global. In OSPFv3 the interface is added to the ospf protocol if it has an address that is not secondary and has scope link. The lo interface only has 2 addresses: ::1 which is host scope the /128 address that we add, which is scope global Neither of those make the function add the interface, thus causing the problem which I'm describing. The workaround I found to this problem is to add a link local address to the lo interface, but I don't think it's a good one, because it makes no sense for the lo to have a link local address. I think a better fix, could be something like this: --- proto/ospf/iface.c 2016-04-29 10:13:23.000000000 +0100 +++ proto/ospf/iface.c.fixed 2016-07-26 14:37:12.528817401 +0100 @@ -1108,7 +1108,7 @@ /* In OSPFv3, we create OSPF iface for link-local address, other addresses are used for link-LSA. */ - if (a->scope == SCOPE_LINK) + if (a->scope == SCOPE_LINK || (a->iface->flags & IF_LOOPBACK)) { if (flags & IF_CHANGE_UP) { I don't know if it compiles. >From what I saw in the structs, I think it does what I want. I just don't know if you think this is a good way to do it. I'll include the information that I think is relevant: # ip a l dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet x.x.x.x/32 scope global lo valid_lft forever preferred_lft forever inet6 x:x:x:x::x/128 scope global valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever *** bird configuration Relevant bird configuration # cat /etc/bird/bird.conf (....) protocol ospf backbone { area x.x.x.x { stub no; (...) interface "lo" { stub; }; } } Information in birdc bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 x.x.x.x/32 (Primary, scope univ) 127.0.0.1/8 (Unselected, scope host) (...other interfaces...) bird> show ospf interface backbone: Interface lo (x.x.x.x/32) (...lo info) (...other interfaces...) *** bird6 information # cat /etc/bird/bird6.conf (....) protocol ospf backbone { area x.x.x.x { stub no; (...) interface "lo" { stub; }; } } Information in birdc6 bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 x:x:x:x::x/128 (Primary, scope univ) ::1/128 (Unselected, scope host) (...other interfaces...) bird> show ospf interface (...other interfaces...) (no lo interface) Thanks, Bernardo Figueiredo

2 1

How can I configure a BIRD router to communicate to a neighbor on a different subnet with RIPv2?
by Travis Pressler 26 Jul '16

26 Jul '16

I'm attempting to set up basic communication with the RIPv2 protocol with BIRD v1.6.0. I've got `Host A` with an interface `enp0` that has address `10.0.1.50/24`. I've got another host `Host B` with an interface `enp1` that has address `10.1.1.25/24`. These interfaces are directly connected by cable. I can ping between both machines if I add a static route on both machines. I have the following `bird.conf` on `Host A`: protocol kernel { learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds export all; # Default is export none } protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol direct { interface "enp0" } protocol rip MyRIP { export all; import all; interface "enp0" { mode multicast;}; } The `bird.conf` on `Host B` is identical except the `enp0` is replaced with `enp1` After starting the bird daemon on both hosts, I can do a `tcpdump -ni enp0 -vv` 13:21:41.943537 IP (tos 0xc0, ttl 1, id 4933, offset 0, flags [none], proto UDP (17), length 132) 10.1.1.25.520 > 224.0.0.9.7742: [udp sum ok] UDP, length 104 13:21:41.943704 IP (tos 0xc0, ttl 1, id 150, offset 0, flags [none], proto UDP (17), length 272) 10.0.1.50.520 > 224.0.0.9.7742: [bad udp cksum 0xec48 -> 0x1219!] UDP, length 244 I can hop inside the `birdcl` command-line and run `show rip neighbors` and get an empty table. If I set the addresses to be on the same subnet, I can run `show rip neighbors` and I can see `10.0.1.50` in my lists of neighbors. If I run 'echo all' in the bird command line I see this message: >>> MyRIP: Bad packet from 10.1.1.25 via enp2s0f0 - not from neighbor (0) How can I get these routers to list each other as neighbors if the two ends of the link aren't on the same subnet? Best Regards, Travis Pressler

2 1

[PATCH v2] Babel: Immediately update hello interval on interface reconfigure.
by Toke Høiland-Jørgensen 20 Jul '16

20 Jul '16

An interface reconfiguration may change both the hello and update intervals. An update interval change is immediately put into effect, while a hello interval change is not. This also updates the hello interval immediately (if the new interval is shorter than the old one), and sends a hello to notify peers of the change. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 8e104d6..15451ab 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -1529,6 +1529,9 @@ babel_reconfigure_iface(struct babel_proto *p, struct babel_iface *ifa, struct b ifa->cf = new; + if (ifa->next_hello > (now + new->hello_interval)) + ifa->next_hello = now + (random() % new->hello_interval) + 1; + if (ifa->next_regular > (now + new->update_interval)) ifa->next_regular = now + (random() % new->update_interval) + 1; @@ -1538,8 +1541,10 @@ babel_reconfigure_iface(struct babel_proto *p, struct babel_iface *ifa, struct b if (new->check_link != old->check_link) babel_iface_update_state(ifa); - if (ifa->up) + if (ifa->up) { + babel_send_hello(ifa, 0) babel_iface_kick_timer(ifa); + } return 1; } -- 2.9.0

2 5

[PATCH 0/7] Babel: Fixes for version 1.6.0
by Toke Høiland-Jørgensen 20 Jul '16

20 Jul '16

This patch series fixes a series of small-ish issues uncovered during testing of the 1.6.0 release of Bird. Thanks to Baptiste Jonglez for reporting most of them. Toke Høiland-Jørgensen (7): Babel: Make sure intervals don't overflow. Babel: Immediately send a hello on interface reconfigure. Babel: Rework handling of retractions. Babel: Documentation updates. Babel: Send wildcard retractions on shutdown and startup. Babel: Don't keep an infeasible route as selected. Babel: Don't maintain feasibility distance for our own routes. doc/bird.sgml | 33 ++++++++++-- nest/config.Y | 2 +- nest/rt-attr.c | 2 +- proto/babel/babel.c | 144 +++++++++++++++++++++++++++++++++++++------------- proto/babel/babel.h | 3 ++ proto/babel/config.Y | 9 ++-- proto/babel/packets.c | 42 +++++++++++---- 7 files changed, 179 insertions(+), 56 deletions(-) -- 2.8.0

2 10

[PATCH 2/7] Babel: Immediately send a hello on interface reconfigure.
by Toke Høiland-Jørgensen 19 Jul '16

19 Jul '16

An interface reconfiguration may change the hello interval. Section 3.4.1 of the RFC specifies that either the change shouldn't be applied until the next hello is due, or an additional hello should be sent immediately. This does the latter. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 8e104d6..4b28f69 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -1539,7 +1539,10 @@ babel_reconfigure_iface(struct babel_proto *p, struct babel_iface *ifa, struct b babel_iface_update_state(ifa); if (ifa->up) + { + babel_send_hello(ifa, 0); babel_iface_kick_timer(ifa); + } return 1; } -- 2.8.0

2 2