April 2018 - 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

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

[PATCH 1/3] babel: Fix type of route entry router ID
by Toke Høiland-Jørgensen 09 May '18

09 May '18

The router ID being assigned to routes was a uint, which discards the upper 32 bits. This also has the nice side effect of echoing the wrong router ID back to other routers. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 4fd88042..a8eb5ea8 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -2140,7 +2140,7 @@ babel_rt_notify(struct proto *P, struct channel *c UNUSED, struct network *net, uint internal = (new->attrs->src->proto == P); uint rt_seqno = internal ? new->u.babel.seqno : p->update_seqno; uint rt_metric = ea_get_int(attrs, EA_BABEL_METRIC, 0); - uint rt_router_id = internal ? new->u.babel.router_id : p->router_id; + u64 rt_router_id = internal ? new->u.babel.router_id : p->router_id; if (rt_metric > BABEL_INFINITY) { -- 2.17.0

2 10

[PATCH 2/3] babel: Short-circuit route selection for routes we originate ourselves
by Toke Høiland-Jørgensen 09 May '18

09 May '18

Routes that are originated by this Babel instance doesn't have an entry in e->selected, which means that the best route selection logic will always pick another route when an update arrives for the same prefix. This will be rejected by Bird core, which will cause a nice looping selection procedure (depending on filters, of course). To avoid this problem, simply short-circuit the route selection procedure if the entry has our own router ID set. 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 a8eb5ea8..f7981333 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -727,6 +727,9 @@ babel_select_route(struct babel_proto *p, struct babel_entry *e, struct babel_ro { struct babel_route *r, *best = e->selected; + if (e->router_id == p->router_id) + return; + /* Shortcut if only non-best was modified */ if (mod && (mod != best)) { -- 2.17.0

2 5

Setting ONLINK flag for arbitrary routes
by Toke Høiland-Jørgensen 29 Apr '18

29 Apr '18

Hi Is it possible to set the ONLINK flag for arbitrary routes? The use case is a common setup in mesh networks: All devices have a /32 assigned to the interface and advertise this as the nexthop for v4 routes. The routing protocol then installs all kernel routes as onlink, allowing routes to be installed even though the nexthop is not in the same subnet as the local link address. Is this possible to configure in Bird currently? -Toke

2 2

Difference between loopback and dummy interfaces for use in Linux routing
by Wilhelm Schuster 28 Apr '18

28 Apr '18

Hi, I’m learning about IP-networking and am in the process of setting up a Linux router using bird. During my research I’ve come across the usage of loopback interfaces. I could gather that this is done, because Ethernet interfaces for example (in contrast to loopbacks) can go down making the addresses configured on them unavailable. In addition, the kernel accepts packets destined to loopbacks addresses on other interfaces making these addresses available on multiple interfaces and not just the loopback. On Linux I found both the lo(opback), and dummy interfaces recommended to achieve the behavior outlined above. What I’m struggling with is understanding the differences between both interface types (besides the obvious difference in packet processing) and when to use which. Searching this mailing list I’ve seen people use lo, on other sites dummy interfaces are recommended. From a quick test (assigning address to lo/dummy; pinging/receiving pings on the host) I wasn’t able to find a difference. When should I use which interface? Cheers, Wilhelm.

7 12

BGP filter
by Arvin Gan 28 Apr '18

28 Apr '18

Hi All, I am implementing a function that send default route to BGP peer, and I am facing an issue about BGP filter, when I use "show route filter" in birdc, the filter result is correct; when I add this filter to config-file and start bird, the bird will occur coredump issue. Does anyone know the reason? Appreciated in advance. 1. bird>show route filter {if format(net) = "0.0.0.0/0" then accept;} //correct result /* show route filter {if net = "0.0.0.0/0" then accept;} // incorrect result */ 2. config-file: filter filter_bgp1{ if format(net) = "0.0.0.0/0" then accept; // "format(net) = ..." , bird coredump ??? /* if net = "0.0.0.0/0" then accept; // " net= ..." , not bird coredump*/ } protocol bgp bgp1 { ...... ipv4 { import all; export filter filter_bgp1; }; ........ } Thanks Arvin

2 8

Incoming connection rejected
by Julien Sansonnens 27 Apr '18

27 Apr '18

Hello all, I'm having a hard time trying to peer with some router over GRE tunnel. I'm using bird 1.6.4 I have many GRE tunnels and BGP sessions is working fine on all of the them except one. Session is locked on "Idle" state. Here are my logs: 2018-04-25 15:22:00 <TRACE> carl: Waiting for fd00:1111::2 to become my neighbor 2018-04-25 15:22:02 <TRACE> carl: Incoming connection from fd00:1111::2 (port 32967) rejected 2018-04-25 15:22:06 <TRACE> carl: Incoming connection from fd00:1111::2 (port 53399) rejected 2018-04-25 15:22:10 <TRACE> carl: Incoming connection from fd00:1111::2 (port 50357) rejected 2018-04-25 15:22:14 <TRACE> carl: Incoming connection from fd00:1111::2 (port 53999) rejected 2018-04-25 15:22:18 <TRACE> carl: Incoming connection from fd00:1111::2 (port 36137) rejected 2018-04-25 15:22:23 <TRACE> carl: Incoming connection from fd00:1111::2 (port 59443) rejected I can ping6 f d00:1111::2 withou problem. Tunnel looks OK to me. No problem with firewall. BGP packets are exchanged through the tunnel: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on peer-carl, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 15:26:59.597762 IP6 fd00:1111::2.47991 > fd00:1111::1.bgp: Flags [S], seq 3532263744, win 28320, options [mss 1416,sackOK,TS val 1966373497 ecr 0,nop,wscale 5], length 0 15:26:59.597898 IP6 fd00:1111::1.bgp > fd00:1111::2.47991: Flags [S.], seq 2214438171, ack 3532263745, win 28320, options [mss 1416,nop,wscale 7], length 0 15:26:59.601269 IP6 fd00:1111::2.47991 > fd00:1111::1.bgp: Flags [.], ack 1, win 885, length 0 15:26:59.601442 IP6 fd00:1111::2.47991 > fd00:1111::1.bgp: Flags [P.], seq 1:48, ack 1, win 885, length 47: BGP 15:26:59.601467 IP6 fd00:1111::1.bgp > fd00:1111::2.47991: Flags [.], ack 48, win 222, length 0 15:26:59.602785 IP6 fd00:1111::1.bgp > fd00:1111::2.47991: Flags [R.], seq 1, ack 48, win 222, length 0 15:27:02.621914 IP6 fd00:1111::2.34513 > fd00:1111::1.bgp: Flags [S], seq 1485692031, win 28320, options [mss 1416,sackOK,TS val 1966374253 ecr 0,nop,wscale 5], length 0 15:27:02.622016 IP6 fd00:1111::1.bgp > fd00:1111::2.34513: Flags [S.], seq 3172792013, ack 1485692032, win 28320, options [mss 1416,nop,wscale 7], length 0 15:27:02.625695 IP6 fd00:1111::2.34513 > fd00:1111::1.bgp: Flags [.], ack 1, win 885, length 0 15:27:02.625726 IP6 fd00:1111::2.34513 > fd00:1111::1.bgp: Flags [P.], seq 1:48, ack 1, win 885, length 47: BGP 15:27:02.625736 IP6 fd00:1111::1.bgp > fd00:1111::2.34513: Flags [.], ack 48, win 222, length 0 15:27:02.626707 IP6 fd00:1111::1.bgp > fd00:1111::2.34513: Flags [R.], seq 1, ack 48, win 222, length 0 15:27:08.248676 IP6 fd00:1111::2.42773 > fd00:1111::1.bgp: Flags [S], seq 4186722687, win 28320, options [mss 1416,sackOK,TS val 1966375660 ecr 0,nop,wscale 5], length 0 15:27:08.248777 IP6 fd00:1111::1.bgp > fd00:1111::2.42773: Flags [S.], seq 4273937540, ack 4186722688, win 28320, options [mss 1416,nop,wscale 7], length 0 15:27:08.252422 IP6 fd00:1111::2.42773 > fd00:1111::1.bgp: Flags [.], ack 1, win 885, length 0 15:27:08.252457 IP6 fd00:1111::2.42773 > fd00:1111::1.bgp: Flags [P.], seq 1:48, ack 1, win 885, length 47: BGP 15:27:08.252501 IP6 fd00:1111::1.bgp > fd00:1111::2.42773: Flags [.], ack 48, win 222, length 0 15:27:08.253429 IP6 fd00:1111::1.bgp > fd00:1111::2.42773: Flags [R.], seq 1, ack 48, win 222, length 0 I do not really see where the problem may come from, the same configuration works with all my other peers. Thank you for your help ! -- Julien Sansonnens

3 3