June 2011 - Bird-users - Mailing Lists

radv bug?
by csszep 25 Jun '11

25 Jun '11

Hello! I testing the radv protocol with bird 1.3.1, but no luck. The configuration is simple: router id 1.2.3.4; debug protocols all; protocol kernel { persist; scan time 20; export all; } protocol device { scan time 10; } protocol static { } protocol radv { #interface "eth*"; interface "dummy0"; }; In the log i see the following: Jun 24 14:12:46 router2 bird6: radv1: Starting Jun 24 14:12:46 router2 bird6: radv1: State changed to feed Jun 24 14:12:46 router2 bird6: Started Jun 24 14:12:46 router2 bird6: device1: State changed to up Jun 24 14:12:46 router2 bird6: kernel1: Connected to table master Jun 24 14:12:46 router2 bird6: kernel1: State changed to up Jun 24 14:12:46 router2 bird6: static1 < interface lo goes up Jun 24 14:12:46 router2 bird6: static1 < interface eth0 goes up Jun 24 14:12:46 router2 bird6: static1 < interface eth1 goes up Jun 24 14:12:46 router2 bird6: static1 < interface eth2 goes up Jun 24 14:12:46 router2 bird6: static1 < interface eth3 created Jun 24 14:12:46 router2 bird6: static1 < interface eth1.3 goes up Jun 24 14:12:46 router2 bird6: static1 < interface ipsec0 goes up Jun 24 14:12:46 router2 bird6: static1 < interface ipsec1 created Jun 24 14:12:46 router2 bird6: static1 < interface dummy0 goes up Jun 24 14:12:46 router2 bird6: static1: State changed to up Jun 24 14:12:46 router2 bird6: radv1 < interface lo goes up Jun 24 14:12:46 router2 bird6: radv1 < primary address ::1/128 on interface lo added Jun 24 14:12:46 router2 bird6: radv1 < interface eth0 goes up Jun 24 14:12:46 router2 bird6: radv1 < primary address fe80::/64 on interface eth0 added Jun 24 14:12:46 router2 bird6: radv1 < interface eth1 goes up Jun 24 14:12:46 router2 bird6: radv1 < primary address fe80::/64 on interface eth1 added Jun 24 14:12:46 router2 bird6: radv1 < interface eth2 goes up Jun 24 14:12:46 router2 bird6: radv1 < primary address fe80::/64 on interface eth2 added Jun 24 14:12:46 router2 bird6: radv1 < interface eth3 created Jun 24 14:12:46 router2 bird6: radv1 < interface eth1.3 goes up Jun 24 14:12:46 router2 bird6: radv1 < primary address fe80::/64 on interface eth1.3 added Jun 24 14:12:46 router2 bird6: radv1 < interface ipsec0 goes up Jun 24 14:12:46 router2 bird6: radv1 < primary address fe80::20c:29ff:fec7:64fe/128 on interface ipsec0 added Jun 24 14:12:46 router2 bird6: radv1 < interface ipsec1 created Jun 24 14:12:46 router2 bird6: radv1 < interface dummy0 goes up Jun 24 14:12:46 router2 bird6: radv1: Adding interface dummy0 Jun 24 14:12:46 router2 bird6: radv1 < primary address 2001:db8:1::/64 on interface dummy0 added Jun 24 14:12:46 router2 bird6: radv1 < secondary address fe80::/64 on interface dummy0 added Jun 24 14:12:46 router2 bird6: radv1: State changed to up Jun 24 14:12:46 router2 bird6: kernel1: Scanning routing table Jun 24 14:12:46 router2 bird6: kernel1: Pruning table master Jun 24 14:12:46 router2 bird6: sk_set_ipv6_checksum: IPV6_CHECKSUM: Invalid argument Jun 24 14:12:46 router2 bird6: radv1: Socket open failed on interface dummy0 Jun 24 14:12:56 router2 bird6: device1: Scanning interfaces show interfaces dummy0 up (index=11) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 2001:db8:1::1/64 (Primary, scope univ) fe80::584a:9dff:fefe:bd0c/64 (Unselected, scope link) Same with eth* interface. The rdisc6 dummy0 command not seeing any prefix And one feature request: It would be great to support RFC6106 RDNSS and DNSSL extension in RADV- Thx Csszep

2 3

How to see routes rejected by a filter
by Mihai Claudiu Capatina 25 Jun '11

25 Jun '11

Hi, Can you please help me see the routes rejected by a filter ? I have the following problem : bird> show route preexport xxx count 9907 of 9946 routes for 9946 networks bird> show route export xxx count 9799 of 9946 routes for 9946 networks So the filter on export rejects 108 routes and i dont know why.... Thanks, Mihai Claudiu Capatina Managing Partner Vector Communications SRL Address : Aleea Cetatuia, Nr. 4, Bl. M22, Sc. 5, Et. 2, Ap. 276, Sect. 6, Bucuresti, 060834 Romania Phone: +40-729-087003 Fax: +40-318-146297 www.vector-communications.net

2 1

Error sending route to kernel
by Mihai Claudiu Capatina 25 Jun '11

25 Jun '11

Hi, We are using BIRD 1.3.1 on FreeBSD 6.2 and from time to time i see in the logs : bird: KRT: Error sending route xxx.xxx.xxx.xxx/yy to kernel Any ideas why ? Best Regards, Mihai Claudiu Capatina Managing Partner Vector Communications SRL Address : Aleea Cetatuia, Nr. 4, Bl. M22, Sc. 5, Et. 2, Ap. 276, Sect. 6, Bucuresti, 060834 Romania Phone: +40-729-087003 Fax: +40-318-146297 www.vector-communications.net

3 4

AS4 at BGP4 session open?
by Laurent GUERBY 19 Jun '11

19 Jun '11

Hi, One of our BPG4 peer is asking us to send directly an AS4 open message instead of going through transitional AS23456. We run a 32 bits ASN and our peer has a 16 bits ASN. If my reading of documentation and BIRD source code (1.2.5 and 1.3.1) is correct BIRD only starts using AS4 if the peer advertise the AS4 capability in its open message. << p->as4_session = conn->want_as4_support && conn->peer_as4_support; conn->want_as4_support = conn->bgp->cf->enable_as4 && (conn->start_state != BSS_CONNECT_NOCAP); conn->peer_as4_support = 0; // Default value, possibly changed by receiving capability. case 65: /* AS4 capability, RFC 4893 */ if (cl != 4) goto err; conn->peer_as4_support = 1; >> Our peer open doesn't currently send the AS4 capability in its open message so we're stuck for now. I don't know if hardware and software BGP4 implementations other than BIRD have this capability and what are the true implications of this request. We're using successfully so far BIRD 1.2.5 on debian squeeze to connect to our transit providers, IX route servers, and peers, thanks for providing BIRD as free software. Sincerely, Laurent GUERBY

2 3

Problem with clist
by Mihai Claudiu Capatina 16 Jun '11

16 Jun '11

Hi, We are trying to filter unwanted communities that our peering partners have forgot to remove in order not to send them to other peering parties. In order to do this we add the communities we want to a clist parameter, empty bgp_community, then add the clist back to bgp_community. The configuration is like this : function check_allow_communities() clist myc; { if ( (100,101) ~ bgp_community ) then { myc = add(myc, (100,101)); } if ( (100,102) ~ bgp_community ) then { myc = add(myc, (100,102)); } return myc; } function check_deny_communities() clist myc; { if ( (0,101) ~ bgp_community ) then { myc = add(myc, (0,101)); } if ( (0,102) ~ bgp_community ) then { myc = add(myc, (0,102)); } return myc; } filter bgp_in_100 pair set allow_communities; pair set deny_communities; { if ( is_martian() ) then { reject "Prefix filtered out by is_martian"; } else { allow_communities = check_allow_communities(); deny_communities = check_deny_communities(); bgp_community.empty; bgp_community.add((100,1000)); bgp_community.add((100,3000)); bgp_community.add(allow_communities); bgp_community.add(deny_communities); accept; } } The problem appears in the log fie : Jun 15 15:59:59 jls bird: filters, line 21: Can't add/delete to non-clist Jun 15 15:59:59 jls last message repeated 4 times Jun 15 15:59:59 jls bird: ... We are running BIRD 1.3.1 on FreeBSD 6.2. Can you please point me in the right direction ? Best Regards, Mihai Claudiu Capatina Managing Partner Vector Communications SRL Address : Aleea Cetatuia, Nr. 4, Bl. M22, Sc. 5, Et. 2, Ap. 276, Sect. 6, Bucuresti, 060834 Romania Phone: +40-729-087003 Fax: +40-318-146297 www.vector-communications.net

3 3

Re: BIRD routing daemon - exact session uptime
by Martin Mares 16 Jun '11

16 Jun '11

Hello! > I'd like to ask you a quick question. > I'm working on a BIRD looking glass script and what I need is an > exact uptime of BGP session. "sh protocols all" doesn't seem to be > particularly useful as it isn't accurate enough (e.g. session is up > since 18May) > Is there a simple way to get more accurate uptime of BGP session? I do not work on BIRD too much these days, but others do. So I am forwarding your query to the BIRD mailing list. Have a nice fortnight -- Martin `MJ' Mares <mj(a)ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth

3 2

keepalive timer problem
by Arnold Nipper 16 Jun '11

16 Jun '11

Hi, we run BIRD 1.2.5 and have an issue with one customer all the time where we see constantly a negative keepalive timer Ryyy_xxx BGP TableXYZ up 2011-06-16 11:32:42 Established Keepalive timer: -41901542/60 Any hints to debug this further? All other 360 sessions are doing fine. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold(a)nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333

2 2

BIRD exporting to kernel although disabled
by Bernhard Hahn 16 Jun '11

16 Jun '11

Dear Bird Mailinglist, We are running Bird 1.2.5 under Debian Etch AMD64 as a routeserver. Last Friday we changed a filter to allow the import of prefixes from a peer with the same AS as the routeserver. The broken design of the configuration, allowed the import of prefixes with empty AS-path to the master table and their export to the EBGP peers. Unfortunately this caused nearly all Cisco (&RFC compliant) machines to close their sessions. At this time, one of our two routeservers started exporting the Master table to the kernel table. There is currently no impact, but we are wondering how this could happen and how to resolve this situation, without affecting the running sessions. The kernel part of the configuration never changed and looks like: protocol kernel { disabled; import all; # Default is import all export all; # Default is export none scan time 10; # Scan kernel tables every 10 seconds } When we remove one of the kernel prefixes like: route del -net X.Y.Z.A netmask 255.255.255.0 gw X.X.X.X eth1 It reappears after around 10 seconds. Guess the scan time is taking effect here. "configure soft" was already triggered several times without effect to the kernel protocol. Regards Bernhard -- Bernhard Hahn DE-CIX Management GmbH e-mail: bernhard.hahn(a)de-cix.net Lindleystr. 12, 60314 Frankfurt Phone: +49 69 1730 902-34 Geschaeftsfuehrer Harald A. Summa Mobile: +49 171 552 3643 Registergericht AG Koeln, HRB 51135 Fax: +49 69 4056 2716

4 12

lists
by Robert Harris 15 Jun '11

15 Jun '11

1 0

IPv6 address classification
by lex 10 Jun '11

10 Jun '11

bird6 has a rather limited list of IPv6 address classifications, unfortunately limiting the routes that it will accept. ipv6_classify(ip_addr *a) in lib/ipv6.c: if ((x & 0xe0000000) == 0x20000000) /* 2000::/3 Aggregatable Global Unicast Address */ if ((x & 0xffc00000) == 0xfe800000) /* fe80::/10 Link-Local Address */ if ((x & 0xffc00000) == 0xfec00000) /* fec0::/10 Site-Local Address */ if ((x & 0xfe000000) == 0xfc000000) /* fc00::/7 Unique Local Unicast Address (RFC 4193) */ if ((x & 0xff000000) == 0xff000000) /* ff00::/8 Multicast Address */ Unfortunately there is a bad side-effect when a BGP peer sends a route for an address that does not fit any of these classifications; bird6 claims that they are "bogus routes", and then seems to drop any routes that have already been received by that peer. This problem can be very easily reproduced in bird6-1.3.1 by receiving a route outside of these ranges. The validation code appears below, and the problem can be very easily corrected by commenting it out: rte_validate(rte *e) in nest/rt-table.c: c = ipa_classify_net(n->n.prefix); if ((c < 0) || !(c & IADDR_HOST) || ((c & IADDR_SCOPE_MASK) <= SCOPE_LINK)) { log(L_WARN "Ignoring bogus route %I/%d received via %s", n->n.prefix, n->n.pxlen, e->sender->name); return 0; } I am interested to hear whether the strictness of the ipv6_classify(ip_addr *a) function would be considered a "bug" or a "feature", but from what I can tell, quagga and openbgpd do not classify addresses in such a strict fashion, and this can produce problems in mixed environments where quagga/openbgpd peers may try and send such routes to bird6. Perhaps any address that is not link-scoped should be implicitly classified as global? At the very least, receiving a "bogus route" should not result in all existing routes from that peer being dropped.

3 2