May 2013 - Bird-users - Mailing Lists

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

Re: OSPF: LSA disappeared
by Bao Nguyen 21 Sep '13

21 Sep '13

Just want to add to this thread that I'm seeing this behavior on BIRD as well, I'm seeing this on all the machines that I've installed. From the timer, it appeared to happened every 5 seconds.... root@sje17:~# birdc -v 0001 BIRD 1.3.4 ready. Jan 8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0005, Id: 10.25.206.123, Rt: 10.25.15.11) Jan 8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0005, Id: 10.25.205.147, Rt: 10.25.15.17) Jan 8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0001, Id: 10.25.15.3, Rt: 10.25.15.3) Jan 8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0001, Id: 10.25.15.4, Rt: 10.25.15.4) Jan 8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0002, Id: 10.25.202.1, Rt: 10.25.239.11) Jan 8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0002, Id: 10.25.201.1, Rt: 10.25.239.10) Jan 8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0002, Id: 10.25.201.13, Rt: 10.25.239.10) Jan 8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0005, Id: 10.25.201.12, Rt: 10.25.10.4) Jan 8 02:34:35 sje17 bird: OSPF: LSA disappeared (Type: 0005, Id: 10.25.206.123, Rt: 10.25.15.11) Jan 8 02:34:35 sje17 bird: OSPF: LSA disappeared (Type: 0005, Id: 10.25.205.147, Rt: 10.25.15.17) Jan 8 02:34:35 sje17 bird: OSPF: LSA disappeared (Type: 0001, Id: 10.25.15.3, Rt: 10.25.15.3) Jan 8 02:34:35 sje17 bird: OSPF: LSA disappeared (Type: 0001, Id: 10.25.15.4, Rt: 10.25.15.4) Jan 8 02:34:35 sje17 bird: OSPF: LSA disappeared (Type: 0002, Id: 10.25.202.1, Rt: 10.25.239.11) Jan 8 02:34:35 sje17 bird: OSPF: LSA disappeared (Type: 0002, Id: 10.25.201.1, Rt: 10.25.239.10) Jan 8 02:34:35 sje17 bird: OSPF: LSA disappeared (Type: 0002, Id: 10.25.201.13, Rt: 10.25.239.10) Jan 8 02:34:35 sje17 bird: OSPF: LSA disappeared (Type: 0005, Id: 10.25.201.12, Rt: 10.25.10.4) -bn 0216331C

3 7

BGP syslog
by Jimmy Halim 05 Sep '13

05 Sep '13

Hi guys, Can I confirm with you guys that syslog is only logging the event for BGP Notification errors only? I mean, it does not log the BGP session up and down event? Thanks in advance! Cheers, Jimmy

7 26

Re: OSPF HELLO wrong mask
by Slawa Olhovchenkov 19 Aug '13

19 Aug '13

On Wed, May 15, 2013 at 07:29:04PM +0200, Ondrej Zajicek wrote: > On Wed, May 15, 2013 at 08:33:08PM +0400, Slawa Olhovchenkov wrote: > > > Interesting > > > What 'show interfaces' and 'show ospf interface' return? > > > And also 'show status' for router id. > > > > ifconfig em0 (full) > > em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > > options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO> > > ether 68:05:ca:0e:d3:e1 > > inet 10.254.0.2 netmask 0xffff0000 broadcast 10.254.255.255 > > inet6 fe80::6a05:caff:fe0e:d3e1%em0 prefixlen 64 scopeid 0x1 > > inet 185.17.0.1 netmask 0xffffff00 broadcast 185.17.0.255 > > inet 185.17.1.1 netmask 0xffffff00 broadcast 185.17.1.255 > > inet6 2a03:e2c0:0:1::1 prefixlen 64 > > inet 185.17.2.1 netmask 0xffffff00 broadcast 185.17.2.255 > > inet 185.17.3.1 netmask 0xffffff00 broadcast 185.17.3.255 > > inet 10.90.90.1 netmask 0xfffffff0 broadcast 10.90.90.15 > > inet 193.93.192.1 netmask 0xfffffc00 broadcast 193.93.195.255 > > nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> > > media: Ethernet autoselect (1000baseT <full-duplex>) > > status: active > > So this is a problem with multiple IPs on an iface. On BSD, we support > just one primary address in OSPF (others are just handled as stubs). > Lexicographically smallest address was chosen. Unfortunately the kernel > chose a different one as a source address. Why lexicographically smallest? Why not first from getifaddrs() list? > If you use multiple IPs on an iface in BSD with BIRD, you have to > use option 'primary' of device protocol to specify the proper one: > http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2 10x, working.

5 4

New release 1.3.10
by Ondrej Filip 28 Jul '13

28 Jul '13

Hi Bird users, we have a new version of your popular routing daemon. Ondrej Version 1.3.10 o Lightweight BIRD client for embedded environments. o Dynamic IPv6 router advertisements. o New 'next hop keep' option for BGP. o Smart default routing table for 'show route export/preexpot/protocol'. o Automatic router ID selection could be configured to use address of loopback. o Allows configured global addresses of NBMA neighbors in OSPFv3. o Allows BIRD commands from UNIX shell even in restricted mode. o Route limits inherited from templates can be disabled. o Symbol names enclosed by apostrophes can contain dots. o Several bugfixes.

1 1

Running BIRD 1.3.4 on custom config Linux 3.8.13 kernel
by Bao Nguyen 30 May '13

30 May '13

We testing BIRD on a custom 3.8.13 Linux kernel and seeing this message every 20 seconds. We did not see this on 3.2 kernel release by Ubuntu 12.04 LTS release. Is there any chance that there's a kernel config that's needed by BIRD that we are not aware of? I notice that the "wait 20" is the only time that matches this interval in the log... May 20 23:29:05 sja15 bird: Netlink: Invalid argument May 20 23:29:26 sja15 bird: Netlink: Invalid argument May 20 23:29:46 sja15 bird: Netlink: Invalid argument May 20 23:30:06 sja15 bird: Netlink: Invalid argument May 20 23:30:25 sja15 bird: Netlink: Invalid argument May 20 23:30:45 sja15 bird: Netlink: Invalid argument May 20 23:31:06 sja15 bird: Netlink: Invalid argument May 20 23:31:26 sja15 bird: Netlink: Invalid argument Here's our OSPF config. protocol ospf { import filter import_OSPF; export filter export_OSPF; ecmp 4; area 0 { interface "eth0", "eth1" { cost 100; type broadcast; hello 10; retransmit 5; wait 20; dead 40; }; interface "dummy0" { stub; }; }; Here's the kernel config related to the NETLINK stuff. root@sja15:~# cat config | grep NETLINK CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_ACCT=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CT_NETLINK=m CONFIG_NF_CT_NETLINK_TIMEOUT=m CONFIG_NF_CT_NETLINK_HELPER=m CONFIG_NETFILTER_NETLINK_QUEUE_CT=y CONFIG_SCSI_NETLINK=y CONFIG_QUOTA_NETLINK_INTERFACE=y -bn 0216331C

2 7

Importing/exporting only static routes from the kernel
by Rob Greenwood 29 May '13

29 May '13

Hi, I'm wondering if there is a way with bird to only import static routes from the kernel routing table. Routes are currently being managed directly in the linux routing table via keepalived, however, I want to announce them out via BGP. I have tried just; kernel { import all; export all; } and this picks up the routes I want, however, it also imports a load of unreachable routes that I don't want to advertise. [root@infra-fw1a ~]# birdc6 show route protocol kernel1 BIRD 1.3.9 ready. ::/96 unreachable [kernel1 11:55] * (10) 2002:a00::/24 unreachable [kernel1 11:55] * (10) 3ffe:ffff::/32 unreachable [kernel1 11:55] * (10) 2002:7f00::/24 unreachable [kernel1 11:55] * (10) 2002:a9fe::/32 unreachable [kernel1 11:55] * (10) 2002:ac10::/28 unreachable [kernel1 11:55] * (10) 2a03:b200:0:2::/64 via 2a03:b200:1:2::2 on eth1.227 [kernel1 11:55] * (10) 2002:e000::/19 unreachable [kernel1 11:55] * (10) 2002:c0a8::/32 unreachable [kernel1 11:55] * (10) ::ffff:0.0.0.0/96 unreachable [kernel1 11:55] * (10) [root@infra-fw1a ~]# I know I can probably filter these, but that seems less ideal. Is there a way of just importing the reachable routes? Thanks, Rob

2 4

debian testing bird 1.3.10 segfaults with virtual link enabled
by Martin Kraus 28 May '13

28 May '13

Hi. bird 1.3.10 in debian testing segfaults with ospfv2 virtual link enabled. [177145.632393] bird[19291]: segfault at 30 ip 00007f0e2f601fe8 sp 00007fffe6899e90 error 4 in bird[7f0e2f5db000+60000] mk

2 4

erroneous "Netlink: File exists" ?
by Aragon Gouveia 27 May '13

27 May '13

Hi, So I've seen this issue mentioned in past mailings, and the FAQ, but I think I might be experiencing a buggy form of it in Bird 1.3.10. In debug mode I'm getting this: May 23 23:59:06 wugpi bird: device1: Scanning interfaces May 23 23:59:06 wugpi bird: CTWUG: HELLO packet sent via eth0 May 23 23:59:06 wugpi bird: kernel1: Scanning routing table May 23 23:59:06 wugpi bird: kernel1: Pruning table master May 23 23:59:06 wugpi bird: kernel1: 172.18.102.32/32: reinstalling May 23 23:59:06 wugpi bird: Netlink: File exists May 23 23:59:06 wugpi bird: kernel1: 172.18.102.160/28: reinstalling May 23 23:59:06 wugpi bird: Netlink: File exists May 23 23:59:06 wugpi bird: kernel1: 172.18.102.224/28: reinstalling May 23 23:59:06 wugpi bird: Netlink: File exists May 23 23:59:06 wugpi bird: kernel1: 172.18.102.240/28: reinstalling May 23 23:59:06 wugpi bird: Netlink: File exists May 23 23:59:06 wugpi bird: kernel1: 172.18.128.0/22: reinstalling May 23 23:59:06 wugpi bird: Netlink: File exists May 23 23:59:06 wugpi bird: ... Those prefixes are from OSPF only, and are not alien routes. My routing table without bird: # ip route list default via 172.18.102.7 dev eth0 172.18.102.0/28 dev eth0 proto kernel scope link src 172.18.102.8 172.18.102.71 via 172.18.102.7 dev eth0 With bird: # ip route list default via 172.18.102.7 dev eth0 172.16.0.0/12 via 172.18.102.1 dev eth0 proto bird 172.18.0.0/16 via 172.18.102.1 dev eth0 proto bird 172.18.1.1 via 172.18.102.7 dev eth0 proto bird 172.18.100.0/24 via 172.18.102.1 dev eth0 proto bird 172.18.100.2 via 172.18.102.1 dev eth0 proto bird 172.18.100.16/30 via 172.18.102.1 dev eth0 proto bird 172.18.100.20/30 via 172.18.102.1 dev eth0 proto bird 172.18.100.22 via 172.18.102.1 dev eth0 proto bird 172.18.100.24/30 via 172.18.102.1 dev eth0 proto bird 172.18.100.28/30 via 172.18.102.1 dev eth0 proto bird 172.18.100.29 via 172.18.102.1 dev eth0 proto bird 172.18.101.0/24 via 172.18.102.1 dev eth0 proto bird 172.18.102.0/28 dev eth0 proto kernel scope link src 172.18.102.8 172.18.102.1 via 172.18.102.1 dev eth0 proto bird 172.18.102.16/29 via 172.18.102.1 dev eth0 proto bird 172.18.102.18 via 172.18.102.1 dev eth0 proto bird 172.18.102.24/30 via 172.18.102.1 dev eth0 proto bird 172.18.102.32 via 172.18.102.7 dev eth0 proto bird 172.18.102.64/28 via 172.18.102.7 dev eth0 proto bird 172.18.102.71 via 172.18.102.7 dev eth0 172.18.102.128/27 via 172.18.102.14 dev eth0 proto bird 172.18.102.160/28 via 172.18.102.11 dev eth0 proto bird 172.18.102.192/28 via 172.18.102.9 dev eth0 proto bird 172.18.102.208/28 via 172.18.102.12 dev eth0 proto bird 172.18.102.224/28 via 172.18.102.10 dev eth0 proto bird 172.18.102.240/28 via 172.18.102.13 dev eth0 proto bird 172.18.103.0/24 via 172.18.102.1 dev eth0 proto bird 172.18.103.1 via 172.18.102.1 dev eth0 proto bird 172.18.128.0/22 via 172.18.102.1 dev eth0 proto bird Kernel: # uname -a Linux wugpi 3.6.11+ #452 PREEMPT Fri May 17 14:25:40 BST 2013 armv6l GNU/Linux Bird config: filter ospfin { if net ~ 172.16.0.0/12 then accept; reject; } protocol kernel { learn; scan time 20; import none; export all; } protocol device { scan time 10; } protocol ospf CTWUG { import filter ospfin; export none; area 172.18.102.0 { interface "eth*" 172.16.0.0/12 { type broadcast; priority 0; }; }; } Any ideas please? Before I start fumbling in source code... :) Thanks, Aragon

2 6

[PATCH RFC v2] Preserve BGP attributes from non-BGP protocols
by Matthias Schiffer 24 May '13

24 May '13

There is no reason to overwrite attributes like AS path, next hop, etc. when the route source is not BGP. Preserving them has several advantages: * no attributes are lost by using opaque pipes * BGP attributes can by pre-populated in other protocols' import filters As a side effect of moving code from bgp_create_attrs() to bgp_update_attrs(), the BGP protocol now uses the same logic to determine if the "gw" attribute should be used as next hop for routes from BGP sources as for those from other sources. Previously, the "gw" attribute was never for routes from BGP. Limitations: * The handling of routes imported from/exported to route reflectors isn't preserved through opaque pipes --- Hi, I found a small issue with my first patch (origin and local_pref attributes not being preserved), so here is a v2. Regards, Matthias proto/bgp/attrs.c | 101 ++++++++++++++++++++++++------------------------------ 1 file changed, 45 insertions(+), 56 deletions(-) diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c index c27a498..7f3b739 100644 --- a/proto/bgp/attrs.c +++ b/proto/bgp/attrs.c @@ -903,47 +903,17 @@ bgp_rt_notify(struct proto *P, rtable *tbl UNUSED, net *n, rte *new, rte *old UN bgp_schedule_packet(p->conn, PKT_UPDATE); } -static int +static void bgp_create_attrs(struct bgp_proto *p, rte *e, ea_list **attrs, struct linpool *pool) { - ea_list *ea = lp_alloc(pool, sizeof(ea_list) + 4*sizeof(eattr)); rta *rta = e->attrs; - byte *z; - ea->next = *attrs; - *attrs = ea; - ea->flags = EALF_SORTED; - ea->count = 4; - - bgp_set_attr(ea->attrs, BA_ORIGIN, + if (!ea_find(rta->eattrs, EA_CODE(EAP_BGP, BA_ORIGIN))) + bgp_attach_attr(attrs, pool, BA_ORIGIN, ((rta->source == RTS_OSPF_EXT1) || (rta->source == RTS_OSPF_EXT2)) ? ORIGIN_INCOMPLETE : ORIGIN_IGP); - if (p->is_internal) - bgp_set_attr_wa(ea->attrs+1, pool, BA_AS_PATH, 0); - else - { - z = bgp_set_attr_wa(ea->attrs+1, pool, BA_AS_PATH, 6); - z[0] = AS_PATH_SEQUENCE; - z[1] = 1; /* 1 AS */ - put_u32(z+2, p->local_as); - } - - /* iBGP -> use gw, eBGP multi-hop -> use source_addr, - eBGP single-hop -> use gw if on the same iface */ - z = bgp_set_attr_wa(ea->attrs+2, pool, BA_NEXT_HOP, NEXT_HOP_LENGTH); - if (p->cf->next_hop_self || - rta->dest != RTD_ROUTER || - ipa_equal(rta->gw, IPA_NONE) || - ipa_has_link_scope(rta->gw) || - (!p->is_internal && !p->cf->next_hop_keep && - (!p->neigh || (rta->iface != p->neigh->iface)))) - set_next_hop(z, p->source_addr); - else - set_next_hop(z, rta->gw); - - bgp_set_attr(ea->attrs+3, BA_LOCAL_PREF, p->cf->default_local_pref); - - return 0; /* Leave decision to the filters */ + if (!ea_find(rta->eattrs, EA_CODE(EAP_BGP, BA_LOCAL_PREF))) + bgp_attach_attr(attrs, pool, BA_LOCAL_PREF, p->cf->default_local_pref); } @@ -973,7 +943,16 @@ static inline void bgp_path_prepend(rte *e, ea_list **attrs, struct linpool *pool, u32 as) { eattr *a = ea_find(e->attrs->eattrs, EA_CODE(EAP_BGP, BA_AS_PATH)); - bgp_attach_attr(attrs, pool, BA_AS_PATH, (uintptr_t) as_path_prepend(pool, a->u.ptr, as)); + if (a) + bgp_attach_attr(attrs, pool, BA_AS_PATH, (uintptr_t) as_path_prepend(pool, a->u.ptr, as)); + else + { + byte *z; + z = bgp_attach_attr_wa(attrs, pool, BA_AS_PATH, 6); + z[0] = AS_PATH_SEQUENCE; + z[1] = 1; /* 1 AS */ + put_u32(z+2, as); + } } static inline void @@ -986,6 +965,7 @@ bgp_cluster_list_prepend(rte *e, ea_list **attrs, struct linpool *pool, u32 cid) static int bgp_update_attrs(struct bgp_proto *p, rte *e, ea_list **attrs, struct linpool *pool, int rr) { + rta *rta = e->attrs; eattr *a; if (!p->is_internal && !p->rs_client) @@ -1000,6 +980,8 @@ bgp_update_attrs(struct bgp_proto *p, rte *e, ea_list **attrs, struct linpool *p if (a) bgp_attach_attr(attrs, pool, BA_MULTI_EXIT_DISC, 0); } + else if (!ea_find(e->attrs->eattrs, EA_CODE(EAP_BGP, BA_AS_PATH))) + bgp_attach_attr_wa(attrs, pool, BA_AS_PATH, 0); /* iBGP -> keep next_hop, eBGP multi-hop -> use source_addr, * eBGP single-hop -> keep next_hop if on the same iface. @@ -1019,7 +1001,15 @@ bgp_update_attrs(struct bgp_proto *p, rte *e, ea_list **attrs, struct linpool *p { /* Need to create new one */ byte *b = bgp_attach_attr_wa(attrs, pool, BA_NEXT_HOP, NEXT_HOP_LENGTH); - set_next_hop(b, p->source_addr); + if (p->cf->next_hop_self || + rta->dest != RTD_ROUTER || + ipa_equal(rta->gw, IPA_NONE) || + ipa_has_link_scope(rta->gw) || + (!p->is_internal && !p->cf->next_hop_keep && + (!p->neigh || (rta->iface != p->neigh->iface)))) + set_next_hop(b, p->source_addr); + else + set_next_hop(b, rta->gw); } if (rr) @@ -1079,30 +1069,29 @@ bgp_import_control(struct proto *P, rte **new, ea_list **attrs, struct linpool * if (p == new_bgp) /* Poison reverse updates */ return -1; - if (new_bgp) - { - /* We should check here for cluster list loop, because the receiving BGP instance - might have different cluster ID */ - if (bgp_cluster_list_loopy(p, e->attrs)) - return -1; - if (p->cf->interpret_communities && bgp_community_filter(p, e)) - return -1; + if (!new_bgp) + bgp_create_attrs(p, e, attrs, pool); - if (p->local_as == new_bgp->local_as && p->is_internal && new_bgp->is_internal) - { - /* Redistribution of internal routes with IBGP */ - if (p->rr_client || new_bgp->rr_client) - /* Route reflection, RFC 4456 */ - return bgp_update_attrs(p, e, attrs, pool, 1); - else - return -1; - } + /* We should check here for cluster list loop, because the receiving BGP instance + might have different cluster ID */ + if (bgp_cluster_list_loopy(p, e->attrs)) + return -1; + + if (p->cf->interpret_communities && bgp_community_filter(p, e)) + return -1; + + if (new_bgp && p->local_as == new_bgp->local_as && p->is_internal && new_bgp->is_internal) + { + /* Redistribution of internal routes with IBGP */ + if (p->rr_client || new_bgp->rr_client) + /* Route reflection, RFC 4456 */ + return bgp_update_attrs(p, e, attrs, pool, 1); else - return bgp_update_attrs(p, e, attrs, pool, 0); + return -1; } else - return bgp_create_attrs(p, e, attrs, pool); + return bgp_update_attrs(p, e, attrs, pool, 0); } static inline u32 -- 1.8.2.3

2 4