April 2019 - Bird-users - Mailing Lists

Adding more then one bgp community at once
by Борис Коваленко 05 May '23

05 May '23

Hello! Is this possible to add many communites at once? bgp_community.add([(1,1), (1,2)]) is wrong "Setting clist attribute to non-clist value" Regards, Boris -- С уважением, Борис Коваленко

4 5

[PATCH] feature to keep protocol's state while configuring
by Alexander Zubkov 29 Jan '23

29 Jan '23

Hello. I have created a patch (attached) with new protocol option: disabled keep on|off. To keep the protocol's state while loading new config. It is useful when protocols disabled manually in the runtime, but we want to keep that state when loading new config. Patch is attached. I have made it against the current int-new branch.

3 16

IGP Metric to MED
by Corban Johnson 29 Apr '22

29 Apr '22

Hello, I am trying to set MED on a BGP route using the metric value from OSPF, but the attributes of the next-hop route do not seem to be available in filter evolution. Am I missing something? Example Bird 2.0 config: protocol bgp test_peer { bfd on; med metric on; graceful restart on; ipv4 { table test_table; gateway recursive; }; local as 65656; } protocol ospf t1_igp { ipv4 { table test_table; }; } OSPF is distributing loopbacks and link nets only. BGP protocols from ‘test_peer’ will use routes learned from ‘t1_igp’ in ‘test_table’ to resolve next hop information (gateway recursive). So far, so good. However, I also have an eBGP peer (i.e. who is not participating in my IGP above) who is multi homed with AS65656. I would like to use MED to inform the peer about my IGP distances to each exit — something like the ‘metric-out minimum-igp <offset>’ command in Junos (https://www.juniper.net/documentation/en_US/junos/topics/reference/configur…) > You can increase or decrease the variable metric calculated from the IGP metric (either from the igp or minimum-igp statement) by specifying a value for offset. The metric is increased by specifying a positive value for offset, and decreased by specifying a negative value for offset. The problem seems to be that filters may only access attributes of the route currently processed, and the 'gateway recursive’ channel directive only calculates next-hop without passing any route attributes of that next-hop through. Has anyone had any luck trying something similar? Many thanks.

3 5

Bug: BFD confuses sessions with identical IPv6 link-local addresses
by Julian Brost 14 Jan '21

14 Jan '21

Hi, I just tried to enable BFD for some OSPF and BGP connections and ran into an issue which BFD sessions flapping up and down and Bird logging many messages like these: bfd1: Bad packet from fe80::2 - unknown session id (130079069) bfd1: Bad packet from fe80::2 - unknown session id (3102513000) bfd1: Bad packet from fe80::2 - unknown session id (3650438750) bfd1: Bad packet from fe80::2 - unknown session id (1597034259) This presumably happens due to this piece of code in bfd_rx_hook() in proto/bfd/packets.c: s = bfd_find_session_by_addr(p, sk->faddr); I use fe80::1/fe80::2 as addresses for most of my IPv6 peering connections and sk->faddr is just a 128 bit value, so it contains no interface identifier, which likely leads to Bird confusing multiple BFD sessions. Regards, Julian

3 5

[PATCH] babel: Set onlink flag for IPv4 routes with unreachable next hop
by Toke Høiland-Jørgensen 14 Apr '20

14 Apr '20

If the next hop of a route is not a reachable address, the route should be installed as onlink. This enables a configuration common in mesh networks where the mesh interface is assigned a /32 and babel handles the routing by installing onlink routes. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 88c4711e..4fd88042 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -640,6 +640,13 @@ babel_announce_rte(struct babel_proto *p, struct babel_entry *e) .nh.iface = r->neigh->ifa->iface, }; + /* If we cannot find a reachable neighbour, set the entry to be onlink. This + * makes it possible to, e.g., assign /32 addresses on a mesh interface and + * have routing work. + */ + if (!neigh_find2(&p->p, &r->next_hop, r->neigh->ifa->iface, 0)) + a0.nh.flags = RNF_ONLINK; + rta *a = rta_lookup(&a0); rte *rte = rte_get_temp(a); rte->u.babel.seqno = r->seqno; -- 2.17.0

3 4

Bird 1.6.3 removing IPv6 device routes on Linux (3.10.0)
by Ben Arblaster 12 Oct '19

12 Oct '19

Hi, I’m seeing an issue with bird 1.6.3 where IPv6 device routes are unexpectedly removed from the kernel table on Linux (3.10.0, CentOS 7) when bird removes a matching route learned via another protocol (in this case OSPF). To reproduce, I’ve rigged up a very simple test with two bird6 instances running OSPF in a single area 0 over a ptp tunnel. Configs are here - https://gist.github.com/andatche/ca5b5ac120e09b6b8171ec5ca95d2e25 If I add an address/network (e.g. fd00::1/64) to an interface (dummy0) on host A, the route is flooded by A, learned by B and correctly installed in the kernel table on B: fd00::/64 via fe80::5efe:ae2:b006 dev tun0 proto bird metric 1024 If I then add the same address/network (e.g. fd00::1/64) to an interface (dummy0) on host B, at that instant a device route is installed in the kernel table alongside the existing route on host B and it now looks like this: fd00::/64 dev dummy0 proto kernel metric 256 fd00::/64 via fe80::5efe:ae2:b006 dev tun0 proto bird metric 1024 Shortly after, bird picks up the new address/network on dummy0, recalculates the area and correctly selects the connected route as the new best. It then removes the old route via host A from the kernel table, as expected: kernel1 < removed fd00::/64 via fe80::5efe:ae2:b006 on tun0 However, this causes both the route via host A *and* the device route to be removed from the kernel table, leaving the kernel table on host B with no route to fd00::/64 at all. # ip -6 route show fd00::/64 # This is a change in behaviour from 1.4.5 and seems like a bug, rather than the expected behaviour? Regards, Ben -- Ben Arblaster e: ben(a)andatche.com t: +447943860840 w: https://andatche.com

3 3

Option --runstatedir in BIRD 2.0.4 broken?
by Robert Scheck 06 Aug '19

06 Aug '19

Hello folks, when trying to use --runstatedir in BIRD 2.0.4, it looks like this here: + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --runstatedir=/run/bird BUILDSTDERR: configure: error: unrecognized option: `--runstatedir=/run/bird' https://kojipkgs.fedoraproject.org//work/tasks/7262/33807262/build.log is the full buildsystem log. So is --runstatedir in BIRD 2.0.4 broken? When looking to configure, it feels very much like a autoconf generation issue. Because in difference to that BIRD 2.0.3 doesn't complain, buildsystem log: https://kojipkgs.fedoraproject.org//work/tasks/7292/33807292/build.log Regards, Robert

3 4

static default route not always pushed to kernel (2.0.4)
by Kenth Eriksson 08 May '19

08 May '19

Hi! There are cases where bird does not push a static default route to the kernel. One way to see this is as follows; A default route from the kernel bird> show route for 0.0.0.0 Table master4: 0.0.0.0/0 unicast [kernel1 13:46:07.958] (215) via 10.210.137.1 on eth1 Add two static default routes bird> show static 0.0.0.0/0 via 10.210.137.1 0.0.0.0/0 via 192.168.120.1 (dormant) bird> The static default route has higher preference, hece I expected it to be pushed to the kernel. But it is not... bird> show route for 0.0.0.0 Table master4: 0.0.0.0/0 unicast [kernel1 13:46:07.958] (215) via 10.210.137.1 on eth1 bird> Next remove both static routes, configure, add one of them back again and both are shown. bird> show route for 0.0.0.0 Table master4: 0.0.0.0/0 unicast [static1 14:13:16.762] * (255) via 10.210.137.1 on eth1 unicast [kernel1 13:46:07.958] (215) via 10.210.137.1 on eth1 bird> Thanks, Kenth

3 11

Full (regression) test suite?
by Robert Scheck 04 May '19

04 May '19

Hello all, is there something like a full (regression) test suite for BIRD that one could run after building BIRD 2.0.x? Regards, Robert

4 10

ibgp bird 1.6 vs 2.0
by Matěj Grégr 30 Apr '19

30 Apr '19

Hello, we have encountered a different ibgp behavior between bird 1.6 and bird2, and I am not sure if it's an intentional change in bird2 or a bug. Let's consider the following topology: 192.168.1.0/24 192.168.2.0/24 R1 ------- ebgp ------- R2 ------- ibgp ------- R3 .2 .1 .1 .2 R1 uses AS 65001, R2 and R3 uses AS 65000. R1 propagates some routes (e.g. 10.10.10.0/24) via eBGP to R2, which sends them to R3 via iBGP. bird2 config on R3: template bgp IBGP { local as 65000; direct; ipv4 { next hop self; import keep filtered on; import all; }; } protocol bgp from IBGP { neighbor 192.168.2.1 as 65000; } Now there are two issues: 1) the bird on R3 reports "Invalid NEXT_HOP attribute" and doesn't learn any R1 routes from R2. If the "direct" option is removed from the config, R3 will learn R1 routes. However, if R3 runs bird1.6, it learns all routes even with the direct option. According to the docs, "direct" is a check for directly connected neighbors. The neighbor 192.168.2.1 is directly connected and in the same subnet, so I don't understand, why there is an issue with NEXT_HOP and why are routes silently dropped on R3? 2) If direct is removed from the config, bird2 on R3 learns R1 routes, but with status unreachable. Even if I send 192.168.1.0/24 from R2 to R3 so the route 192.168.1.0/24 is in R3's routing table and ping from R3 to the NEXT_HOP IP address is successful. bird1.6 works without a problem with or without direct option and all routes are learned and reachable. According to the docs, iBGP should find route to NEXT_HOP IP address in its routing table, so why are the routes marked as unreachable in bird2, if the route is there? Thank you and best regards, M.

2 4