May 2013 - Bird-users - Mailing Lists

Flood of: <WARN> Netlink: File exists
by Tapio Haapala 22 May '13

22 May '13

Hello, We get <WARN> Netlink: File exists message to bird log about 25 times in minute. I think it comes when bird try add some routes to kernel table what are allready in table. Is there way to get more information what it try insert to table so then I maybe can resolve that with filters. I think it just get same routes from two different protocol. -- F-Solutions Oy Tapio Haapala PL7, 90571 Oulu GSM 0400 998371 Skype burner- IRC Burner@ircnet

3 2

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

17 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, this is a patch I just wrote up in need for this feature. I've tested it on a handful of systems and everything seems to be working correctly. Comments welcome :) 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..6e6f784 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(*attrs, 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(*attrs, 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

1 0

Cacti Scripts
by Joe Wooller 16 May '13

16 May '13

Hey All, We have just been making some cacti scripts for graphing routes. Please let me know what you think. https://github.com/dowlingw/bird-tool Cheers Joe

1 0

Fwd: Re: [Euro-ix-bird] BIRD support programme
by Ondrej Filip 15 May '13

15 May '13

Resent from Euro-IX and I have to thank DE-CIX as a gold supporter. Ondrej -------- Original Message -------- Subject: Re: [Euro-ix-bird] BIRD support programme Date: Wed, 15 May 2013 19:25:15 +0200 From: Arnold Nipper <arnold.nipper(a)de-cix.net> To: Ondrej Filip <feela(a)network.cz> CC: bird <bird-users(a)network.cz>, euro-ix-bird(a)euro-ix.net @all BIRD users, On 15.05.2013 15:47, Ondrej Filip wrote: > Dear BIRD users, > please excuse me for one non-technical e-mail. But in order to > increase the speed and the quality of BIRD development we have > launched a support programme. The funds raised from this programme > will serve on one hand to support BIRD users that need quicker > response times, consultancy etc. and also on the other hand to finance > BIRD development, travel costs of BIRD developers, equipment etc. > > So if you need BIRD support or you just want to help BIRD development, > please consider joining this programme. > > http://bird.network.cz/?support > > Kind regards > Ondrej > _______________________________________________ first of all thank you Ondrej and your team for his wonderful piece of software. BIRD still rocks! Next I only can encourage everyone to support, even if it is only a small contribution. DE-CIX is already contributing since 2013-04 with a substantial amount. Best regards and keep on the good work, Ondrej! Arnold -- Arnold Nipper e-mail: arnold.nipper(a)de-cix.net DE-CIX Management GmbH mobile: +49 172 2650958 Lichtstr. 43i, 50825 Koeln phone: +49 69 1730 902 22 Geschaeftsfuehrer Harald A. Summa fax: +49 69 4056 2716 Registergericht AG Koeln HRB 51135 http://www.de-cix.net

1 0

dumb question
by Henry Yen 15 May '13

15 May '13

Dumb question, but didn't readily see it in the documentation; pointers to where it is in the doc would be humbly appreciated. The following is typical response for BIRDC route query: bird> show route 192.168.5.0/24 all 192.168.5.0/24 via 10.110.110.5 on tun4 [bm 13:21 from 65.242.137.98] * (100/?) [i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 65.242.137.98 BGP.med: 0 BGP.local_pref: 100 bird> What does the '*' in the response signify? "Valid" like in cisco? What does the "100/" signify? Is it local preference, or the route metric, or something else? What does the "/?" signify? Some examples show "-" or a numeric value. Thanks. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York

2 1

OSPF HELLO wrong mask
by Slawa Olhovchenkov 15 May '13

15 May '13

BIRD 1.3.9 running on FreeBSD 9.1 with next interfaces (not all showed): 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 vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3<RXCSUM,TXCSUM> ether 50:46:5d:b1:98:6c inet 10.90.90.91 netmask 0xfffffff8 broadcast 10.90.90.95 inet6 2a03:e2c0::1 prefixlen 64 nd6 options=1<PERFORMNUD> media: Ethernet autoselect (1000baseT <full-duplex>) status: active vlan: 1 parent interface: re0 ospf configuration: protocol ospf { area 0 { interface "em0" ; }; } Bird send HELLO packet with wrong mask (and Designated Router also): tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes 20:04:06.186362 IP (tos 0xc0, ttl 1, id 29198, offset 0, flags [none], proto OSPF (89), length 64) 10.254.0.2 > 224.0.0.5: OSPFv2, Hello, length 44 Router-ID 185.17.0.1, Backbone Area, Authentication Type: none (0) Options [External] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.240, Priority 1 Designated Router 10.90.90.1

2 2

BIRD support programme
by Ondrej Filip 15 May '13

15 May '13

Dear BIRD users, please excuse me for one non-technical e-mail. But in order to increase the speed and the quality of BIRD development we have launched a support programme. The funds raised from this programme will serve on one hand to support BIRD users that need quicker response times, consultancy etc. and also on the other hand to finance BIRD development, travel costs of BIRD developers, equipment etc. So if you need BIRD support or you just want to help BIRD development, please consider joining this programme. http://bird.network.cz/?support Kind regards Ondrej

2 2

HOWTO: Learning recursive routes from kernel protocol
by Сергей Попович 15 May '13

15 May '13

Deploying VLAN per user with IP unnumbered schema using Linux as access server we face with following problem: BIRD's kernel protocol does not learn routes with nexthop, that resolves trought another route (recursive routes). This is reproducable for both IPv4 and IPv6. ---------------------------------------------------------- While for IPv4 this has minimal impact, as typically customer gets its /32 ip address and entire LAN part of the customer connection uses addresses from RFC1918 and NAT. For IPv6 this becomes more complicated: - there is no NAT in such view as with IPv4, (ok) - as with IPv4 customer gets one IPv6 address on its WAN interface (ok) - customer gets additional IPv6 block with 64 long prefix for its LAN interface (fail) So for typical IPv6 deplyment with IP unnumbered schema we need: # ip -6 route add fd11::2/128 dev vlan10 proto static src fd11::1 # ip -6 route add fd22::/64 dev vlan10 via fd11::2 proto static src fd11::1 # birdc 'show route filter { if proto = kernel254 then accept; reject; }' BIRD 1.3.9 ready. fd11::2/128 dev qinq22.226 [kernel254 12:57] * (10) Last route MUST be advertised using dynamic routing protocol (BGP in our case). Example of such routes for both IPv4 and IPv6 is: ------------------------------------------------------------------ # ip -4 route add 192.168.1.2/32 dev vlan10 proto static src 192.168.1.1 # ip -4 route add 10.0.1.0/24 dev vlan10 via 192.168.1.1 proto static src 192.168.1.1 # birdc 'show route filter { if net = 10.0.1.0/24 then accept; reject; }' BIRD 1.3.9 ready. # ip -6 route add fd8e:579a:623c:826a::2/128 dev vlan10 proto static src fd8e:579a:623c:826a::1 # ip -6 route add fd8e:579a:623c:ffff::/64 dev vlan10 # birdc 'show route filter { if net = fd8e:579a:623c:ffff::/64 then accept; reject; }' Kernel protocol configuration --------------------------------------- protocol kernel kernel254 { persist no; scan time 120; learn yes; device routes no; kernel table ipt_main; import filter { # Import only 'static' routes if krt_source != ipp_static then reject; accept; }; export all; } Workaround ----------------- Use static protocol with routes not learned from kernel. protocol static static254 { route fd8e:579a:623c:ffff::/64 drop; } Any ideas about solution/other workarouns for this problem are welcome. -- SP5474-RIPE Sergey Popovich

3 4

Bird RIP does not send some packages
by Aleksey Chudov 13 May '13

13 May '13

Hello, I ran into a situation that Bird RIP does not send some packages. Bird configuration file /etc/bird.conf log syslog all; debug protocols all; protocol device { scan time 5; } protocol direct { interface "*"; } protocol kernel { persist; scan time 5; export filter { if source = RTS_RIP then { if rip_metric > 15 then reject; if net ~ 10.0.0.0/8 then accept; if net ~ 192.168.0.0/16 then accept; } reject; }; } protocol rip { period 5; timeout time 20; garbage time 30; interface "gre*" { mode multicast; }; export filter { if net ~ 10.64.0.0/20 then accept; reject; }; } Log messages from Bird daemon Feb 19 18:25:00 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:03 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:06 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:12 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:13 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:15 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:20 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:26 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:28 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:33 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:36 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:38 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:44 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:48 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:50 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:56 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:58 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:00 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:03 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:05 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:06 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:07 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:13 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:16 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:19 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:21 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:25 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:31 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:33 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:39 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:42 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:45 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:46 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:49 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:51 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:52 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:57 srvc1 bird: rip1: Broadcasting routing table to gre1 And tcpdump for the same period 18:25:00.479028 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:25:03.482132 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:25:15.639027 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:25:26.478329 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:25:48.476297 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:05.639030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:13.473560 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:16.639029 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:21.473055 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:31.473049 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:33.472083 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 44 18:26:39.638030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:45.471432 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:57.637236 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 Are there any ideas why this is happening? Best regards, Aleksey

3 14

show route filter & static routes
by Dan Rimal 13 May '13

13 May '13

Hello, I've found confused behaviour "show route filter". I have basic test setup with some filters, see attachment. With this setup, i've got this result: bird> show route export test 1.0.0.0/20 blackhole [static_bgp 18:22] * (1200) bird> show route filter upstream_out bird> and error log shows: 12-05-2013 18:23:24 <ERR> filters, line 28: Prefix or path expected When i commented out line "if bgp_path.len > 64 then return false;" in "function rt_export_ebgp()", i've got expected result: bird> show route export test 1.0.0.0/20 blackhole [static_bgp 18:22] * (1200) bird> bird> show route filter upstream_out 1.0.0.0/20 blackhole [static_bgp 18:22] * (1200) Unexpected behaviour (for me) arrive when filter contain whatever with BGP PATH and exported routes are static, without bgp path. For example, if i add "bgp_path.prepend(65001);" to "filter usptream_out", i've got same bad result again: bird> show route export test 1.0.0.0/20 blackhole [static_bgp 18:22] * (1200) bird> show route filter upstream_out bird> Is this correct behaviour? Thank you, Regards, Daniel

3 2