February 2014 - Bird-users

IS-IS
by kveri new 01 Jun '15

01 Jun '15

Hello, I would like to implement IS-IS as a part of my master thesis. Are there any apparent problems which would prevent successful implementation, political and/or technical? Also I would like to hear opinions of the authors. Implementation timeframe is 2013 (if we live past 21th). Regards, Martin Čechvala Faculty of Informatics and Information Technologies Slovak Technical University

7 8

RIP not doing "triggered update" following route deletion
by Tore Anderson 15 Oct '14

15 Oct '14

I've noticed that BIRD doesn't withdraw (i.e., advertising them with metric 16) RIP routes when they disappear from the routing table. This means that the neighbour router ends up waiting for the route to time out before ceasing to send traffic to the BIRD router, rather than doing so immediately. I'm running v1.4.0 with a bird.conf containing: log syslog { info, remote, warning, error, auth, fatal }; router id 192.0.2.1; protocol device {} protocol direct {} protocol rip { interface "*" { mode nolisten; ttl security on; }; import none; export all; } To reproduce the issue, look at "tcpdump -v port 520" while doing: 1) ip address add 192.0.2.2/32 dev lo -> a triggered update appears (advertising 192.0.2.2/32) 2) ip address delete 192.0.2.2/32 dev lo -> a triggered update doesn't appear (it should have) For what it's worth, step #2 does increase the RIP protocol's "Export withdraws" counter. This issue also applies to RIPng/bird6. AFAICT, not sending these triggered updates immediately is a standards violation. Quoting RFC 1812 F.2: «A router MUST send a triggered update when routes are deleted or their metrics are increased.» Also see RFC 2453 section 3.10.1. Tore

2 3

[PATCH] More multipath support for OSPF
by Peter Christensen 23 Apr '14

23 Apr '14

Hi, I noticed that the multipath support in OSPF seems to be fairly limited. Essentially I was only able to make it do multipath if I had two interfaces connecting to the same router. At my company, we need true multipath between multiple routers using a single interface. (If I needed the other, I could use LACP) I am aware of the implications the default multipath implementation in Linux which operates on a per-packet basis, which is why we've patched our kernels to do it per-flow instead. Anyway, I seemed to have managed to make multipath work as expected - at least in our setup. (Patch attached) Essentially, I've hooked my multipath code into ri_install_ext() and ri_install_net(), where I add the equal routes if the routes share the same type, metrics and OSPF area. I realize that my add_nexthops() is /very/ similar to merge_nexthops() in functionality, but it seemed that the top_hash_entry() could be null, so I wrote a new method which did not rely on that - at the cost of more calls to copy_nexthop(), I guess. Any thoughts? Best regard Peter Christensen

2 5

Prioritising default routes
by Michael Ludvig 25 Mar '14

25 Mar '14

Hi Short version: Can I assign different priorities (metrics?) to the same route inserted by Bird into different routing tables? Long version: I've got a main office router with these uplinks: - 1x SDSL with BGP, receives national routes - 1x ADSL with OSPF Cisco modem that advertises default route - 2x OpenVPN tunnel to our Datacentre (one over each physical connection) with OSPF that's primarily for internal nets. The SDSL and Datacentre are with the same ISP and I can propagate our DMZ subnets over BGP from either location. Then I've got two routing tables - one for internal LAN and one for DMZ which has different rules. In normal circumstances the LAN traffic goes out over ADSL unless there is a better route learnt from BGP in which case it'd go out over SDSL. The DMZ traffic (public IPs) always goes out over SDSL, and the DMZ routing table has a static default rule in that sense. Now if SDSL goes down - as it did yesterday after a fibre cut down the road... - all LAN traffic goes out over ADSL, that's good - DMZ subnet advertised from DC router over BGP and incoming traffic arrives over the OpenVPN tunnel (which still works over ADSL). - all DMZ egress is blocked though until I replace the default route in DMZ routing table to go via the tunnel to datacentre and from there to the internet. If ADSL goes down... - LAN traffic is restricted to BGP learned routes (national traffic) until I add a static default route via SDSL - DMZ is fine What I want is an automatic fail over for both LAN and DMZ if any one of the links fails. My idea is to advertise a default route over all the uplinks and for the LAN routing table use them in this order of preference: 1. ADSL (OSPF), 2. SDSL (BGP), 3. one of the tunnels (unlikely if both physical links are down) For DMZ routing table do this order: 1. SDSL (BGP), 2. tunnel over ADSL (OSPF), 3. plain ADSL (OSPF) I know I can manage different routing tables from Bird but how do I assign different priorities (metrics?) for the same route going into different tables? Thanks! Michael

2 2

bitwise operation in filters
by Daniel Wendler 03 Mar '14

03 Mar '14

Hello List, at the moment we try to implement an fine granulary filter mechanism in our Bird OSPF setup. We ask ourselfes if anyone has implementet bitwise operations in Bird filters which is not in official code. If not, are there any plans to implement such an feature in Bird filters or should we try it to implement on our own and contribute this to the mailing list? For better understanding i include an example: We use the ospf_tag attribute as an group identifier. at the moment we have 4 groups. There are routers which could belong to more than one group. So we would like to combine the groups in any way. The most efficient way to reach this is an bitwise operation. -- Mit freundlichen Grüßen --------------------------------- Daniel Wendler

3 3

Filter being ignored.
by Steve (Telsat Broadband) 02 Mar '14

02 Mar '14

Hi All, I've configured the following 'export' filter in my OSPF protocol: protocol ospf { import all; export filter { ospf_metric1 = 1000; if ( net = [ 192.168.0.0/16+ ] ) then reject; if ( source = RTS_STATIC ) then accept; else reject; }; Yet on my router, I'm still seeing the route coming in via OSPF: O 192.168.38.0/24 [110/1001] via xxx.xxx.xxx.xxx, 00:00:05, GigabitEthernet0/1 O 192.168.39.0/24 [110/1001] via xxx.xxx.xxx.xxx, 00:00:05, GigabitEthernet0/1 Is there something I'm missing? How can I get these network's excluded? Cheers. Steve.

2 3

Combining routes in BIRD OSPF export
by Steve (Telsat Broadband) 28 Feb '14

28 Feb '14

Hi All, I have a question which I can't seem to find the answer for. We allocate network ranges to our customers (both IPv4 and v6). All our v6 ranges (say /64's) get allocated out of a single larger /56 block. What I want to do is prevent BIRD from picking up the individual /64's assigned to customers and only 'export' the larger '/56' block to OSPF as this is really all that's required. What configuration would I need to alter to achieve this. This is the current (v6) config we're using: log syslog all; router id xxx.xxx.xxx.xxx; debug protocols all; protocol device { scan time 10; } protocol kernel { export all; scan time 15; } protocol static { import all; } protocol ospf { import all; export filter { ospf_metric1 = 1000; if source = RTS_STATIC then accept; else reject; }; area 0 { interface "eth0" { cost 5; type broadcast; hello 10; retransmit 5; wait 40; dead 40; authentication none; }; interface "*" { cost 1000; stub; }; }; } Cheers Steve

2 4

BIRD 1.4.0 bugfixes [2/2]
by Pierluigi Rolando 26 Feb '14

26 Feb '14

Hi, This patch fixes a situation where a route that becomes unviable because of a configuration change (i.e. next hop of its new version is unreachable) is marked as not installed internally, but actually remains in the kernel routing table until a subsequent configuration change makes the next hop reachable again. The code that updates static routes seems to process changes as deletions + insertions, but if the insertion can't happen for any reason the deletion won't happen as well, even though the route is already marked as uninstalled by then. When that happens BIRD and the kernel get out of sync until BIRD tries to install the route again, which might be never. The patch is supposed to fix the problem by detecting routes that (a) have changed but (b) are not getting deleted because their updated version can't get installed, and deletes them anyway. There's also a quick sanity check to make sure we don't end up with 3 states for the installed flag (which should obviously be a base 2 boolean), even though 3 states are needed temporarily when processing updates. Thanks, Pierluigi diff -a -u -r a/proto/static/static.c b/proto/static/static.c --- a/proto/static/static.c 2013-04-29 14:41:58.000000000 -0700 +++ b/proto/static/static.c 2014-02-24 12:45:46.433136581 -0800 @@ -62,10 +62,15 @@ rta a, *aa; rte *e; - if (r->installed) + /* 3 cases here: + * (a) r->installed > 0: already installed, no op; + * (b) !r->installed: really really not installed, create; + * (c) r->installed < 0: needs update but it's there. + */ + if (r->installed > 0) return; - DBG("Installing static route %I/%d, rtd=%d\n", r->net, r->masklen, r->dest); + DBG("Installing static route %I/%d->%I, rtd=%d\n", r->net, r->masklen, r->via, r->dest); bzero(&a, sizeof(a)); a.proto = p; a.source = (r->dest == RTD_DEVICE) ? RTS_STATIC_DEVICE : RTS_STATIC; @@ -82,7 +87,7 @@ struct mpnh **nhp = &nhs; for (r2 = r->mp_next; r2; r2 = r2->mp_next) - if (r2->installed) + if (r2->installed > 0) { struct mpnh *nh = alloca(sizeof(struct mpnh)); nh->gw = r2->via; @@ -122,10 +127,17 @@ { net *n; + /* 3 cases here: + * (a) r->installed > 0: remove; + * (b) !r->installed: it's not there, don't remove; + * (c) r->installed < 0: update, needs removal even + * if new route can't be installed. + */ + if (!r->installed) return; - DBG("Removing static route %I/%d\n", r->net, r->masklen); + DBG("Removing static route %I/%d->%I\n", r->net, r->masklen, r->via); n = net_find(p->table, r->net, r->masklen); if (n) rte_update(p->table, n, p, p, NULL); @@ -410,6 +422,7 @@ static_match(struct proto *p, struct static_route *r, struct static_config *n) { struct static_route *t; + int new_installed = 0; /* * For given old route *r we find whether a route to the same @@ -422,17 +435,28 @@ r->neigh->data = NULL; WALK_LIST(t, n->iface_routes) if (static_same_net(r, t)) - { - t->installed = r->installed && static_same_dest(r, t); - return; - } + goto mark_for_deletion; WALK_LIST(t, n->other_routes) if (static_same_net(r, t)) - { - t->installed = r->installed && static_same_dest(r, t); - return; - } + goto mark_for_deletion; static_remove(p, r); + return; + +mark_for_deletion: + new_installed = r->installed && static_same_dest(r, t); + if(new_installed == 0 && r->installed) { + /* XXX: this will silently uninstall a route that changed even though its new + * version cannot be installed immediately. + * Without this the route won't be removed (as required by the change), since + * its new version cannot currently be installed. + * So what we want to do is to remove the route here for real. BIRD + * will worry about adding it again later after the next hop becomes + * reachable again. + */ + t->installed = -1; + } else + t->installed = new_installed; + return; } static inline rtable * @@ -467,6 +491,20 @@ WALK_LIST(r, n->other_routes) static_add(p, n, r); + /* route->installed has now 3 possible values: + * (a) > 0, route is installed; + * (b) == 0, route is not installed; + * (c) < 0, route was marked as not installed because it changed and it needs update. + * + * Beyond this point it's not legal to keep the < 0 case. It's actually a bug in the + * code. Any route that is < 0 needed to be removed. The proper thing to do + * would be asserting or so. + */ + WALK_LIST(r, n->iface_routes) + ASSERT(r->installed >= 0); + WALK_LIST(r, n->other_routes) + ASSERT(r->installed >= 0); + return 1; }

2 2

BIRD 1.4.0 bugfixes [1/2]
by Pierluigi Rolando 26 Feb '14

26 Feb '14

Hi, This patch fixes a situation where an interface enters TMPDOWN state and doesn't leave it until a device scan is triggered by timer. This seems to happen whenever the interface is up but with no IP address configured. BIRD will then put the interface in TMPDOWN state (correctly), but the state is not left even though an IP address is assigned later. The problem in turn appears to be the way IF_UPDATE flags are used to pass state information between if_update and ifa_update calls. A scan will make it right, but simply processing RTM messages won't. A workaround to this issue is to scan devices frequently, which might be not acceptable if reactions to RTM_NEWADDR/RTM_DELADDR/etc. are expected to happen without much average delay. As you'll see, this patch is probably overkill. Thanks, Pierluigi diff -a -u -r a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c --- a/sysdep/linux/netlink.c 2013-11-25 06:19:10.000000000 -0800 +++ b/sysdep/linux/netlink.c 2013-12-05 18:33:09.282768865 -0800 @@ -963,11 +963,24 @@ case RTM_DELLINK: DBG("KRT: Received async link notification (%d)\n", h->nlmsg_type); nl_parse_link(h, 0); + kif_do_scan(NULL); break; case RTM_NEWADDR: case RTM_DELADDR: DBG("KRT: Received async address notification (%d)\n", h->nlmsg_type); nl_parse_addr(h); + /* XXX: this (and the one above) are to get unstuck when the if comes up + * with no IP address, then a route gets installed, then an IP address + * gets configured. The crux of the problem is that async message processing + * apparently never gets the interface unstuck from TMPDOWN state, + * but the scan will fix it. + * + * I believe that the problem is that BOTH if_update AND ifa_update must + * be called within the same scan (IF_UPDATE flags are relevant). + * This will scan ALL interface which is overkill. The parameter (currently + * unused) might be used to indicate which one to scan. + */ + kif_do_scan(NULL); break; default: DBG("KRT: Received unknown async notification (%d)\n", h->nlmsg_type);

4 6

BIRD 1.4.0 bugfixes [0/2]
by Pierluigi Rolando 24 Feb '14

24 Feb '14

Hi, Over the course of the next few emails I'd like to post 2 bugfixes for your consideration. These derive from similar patches that my organization (www.embrane.com) has adopted (internally, at this time) to work around issues that we've encountered in BIRD 1.4.0 and 1.3.11 builds. Before I begin, let me be clear on one point. The patches I'm about to post are not intended to be included as-is in BIRD. I'm posting them in order to explain the problem a bit better than I could with words alone. You guys know BIRD much, much better than I do and you will probably be able to come up with cleaner ways to fix these issues. These are quick'n'dirty hacks. All patches should apply cleanly to 1.4.0, v4 and v6. They've been tested, in slightly different form, under Linux kernel version 3.2.14 or later. Their formatting might be a little messed up as I need to massage them a bit before posting to take out comments and debugging statements that are out of scope. What will follow is: [1/2] - fix for an interface never leaving TMPDOWN state unless a full interface scan is initiated by timer; [2/2] - fix for a situation where a static route change gets silently ignored if the new gateway for that route is unreachable. Both these problems seem present in released BIRD versions. I haven't been able to find anything about them on the ML so I'm assuming they're currently unpatched. If that's not the case please let me know. Since it's my first time posting patches here I apologize in advance for anything I might get wrong. Thanks, Pierluigi

1 0