- Bird-users - Mailing Lists

Bird within netns (no OS routing table injection with BGP)
by Julien VAUBOURG 04 Nov '13

04 Nov '13

Hi all, I'm trying to use bird within netns with something like "ip netns exec foo bird". I can see received routes in "show route" but the injection in the OS routing table is not done. Strangely, static routes are correctly injected. With BGP routes I have no particulary debug messages, except "Netlink: Invalid argument" with bird6. Using Quagga, routes are correctly injected inside netns. Any idea about that problem? * Bird 1.3.7-1 * GNU/Linux (Debian Wheezy) Regards, ju.

2 2

FreeBSD, OSPF, and multicast
by Claude Marinier 01 Nov '13

01 Nov '13

Hi, I am building a WAN emulator using a FreeBSD server with DummyNet for WAN effects and BIRD for OSPF. At first, no multicast packets left the server; then I added a default route and they left by that interface only. How can I configure the server so BIRD sends HELLO packets out all the interfaces. Thank you. Details: FreeBSD WAMemu 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013 root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 bird-1.3.11 P.S. I got it working by avoiding multicast with 'type nonbroadcast' and 'neighbors'. -- Claude Marinier

4 7

Where did the BGP examples go
by Bill Reid 31 Oct '13

31 Oct '13

I was looking for the BGP examples on the Bird web site. I thought I previously found them via the wiki link but that link does not point to the wiki page but to Labs Redmine. Thanks, Bill

3 2

Bird not installing OSPF learned routes into routing tables
by Lex van Roon 28 Oct '13

28 Oct '13

Hi All, Recently I've migrated one of my Debian Squeeze / bird 1.3.8 route reflectors to FreeBSD 10-BETA1 / bird 1.3.11. This reflector has multiple gre-based links, over which I advertise loopback addresses using OSPF, which are in turn used to establish iBGP sessions. The problem is that it seems that Bird is not installing OSPF learned routes into the routing table, and I'm not quite sure how to proceed with this. Please see the output below: I've got two OSPF neighbors, which successfully initialize: bird> show ospf neighbors as65342_igp: Router ID Pri State DTime Interface Router IP 10.42.0.1 1 full/ptp 00:15 gre0 10.42.4.1 10.42.0.3 1 full/ptp 00:10 gre1 10.42.8.2 I can see all routes that are being advertized within the OSPF network: bird> show ospf state area 0.0.0.0 router 10.42.0.1 distance 10 router 10.42.0.3 metric 10 router 10.42.0.4 metric 10 router 10.42.0.2 metric 10 stubnet 10.42.0.1/32 metric 0 stubnet 10.42.0.123/32 metric 0 stubnet 10.42.4.8/30 metric 10 stubnet 10.42.4.12/30 metric 10 stubnet 10.42.4.0/30 metric 10 router 10.42.0.2 distance 0 router 10.42.0.1 metric 10 router 10.42.0.3 metric 10 stubnet 10.42.4.0/30 metric 10 stubnet 10.42.0.2/32 metric 0 stubnet 10.42.8.0/30 metric 10 router 10.42.0.3 distance 10 router 10.42.0.2 metric 1000 router 10.42.0.1 metric 1000 stubnet 10.42.0.3/32 metric 1 stubnet 10.42.8.0/30 metric 1000 stubnet 10.42.4.8/30 metric 1000 router 10.42.0.4 distance 20 router 10.42.0.1 metric 10 stubnet 10.42.0.4/32 metric 0 stubnet 10.42.4.12/30 metric 10 However, I'd expect the stubnet routes to be available to the routing tables that are used within Bird, and it seems that they are not exported: bird> show route protocol as65342_igp 10.42.0.2/32 dev disc0 [as65342_igp 15:39] * I (150/0) [10.42.0.2] bird> show route table routers 10.42.0.2/32 dev disc0 [as65342_igp 15:39] * I (150/0) [10.42.0.2] The relevant configuration for this is below. The exact same configuration worked with Linux: function accept_loopback_prefixes() { if net ~ [ 10.42.0.0/24{32,32} ] then accept; } protocol ospf as65342_igp { table routers; rfc1583compat no; ecmp yes; import filter { accept_loopback_prefixes(); reject; }; export filter { accept_loopback_prefixes(); reject; }; area 0.0.0.0 { interface "disc0" { stub on; }; interface "gre0", "gre1" { wait 3; hello 5; dead count 3; retransmit 1; check link on; }; }; } When I enable Bird debugging (full OSPF log output available below), I can see all routes succesfully exchanging LSA's and starting the routing table calculation + synchronisation, however the calculated routes are never installed into the 'routers' table, nor do I see Bird make any attempts and/or throw errors while doing this. Do you know how I could proceed in getting this to work? Kind Regards, Lex van Roon ==> OSPF related debugging output: neutralino [~]# /usr/local/sbin/bird -d 2>&1 | grep as65342_igp 25-10-2013 15:59:51 <TRACE> as65342_igp: Initializing 25-10-2013 15:59:51 <TRACE> as65342_igp: Starting 25-10-2013 15:59:51 <TRACE> as65342_igp: Adding area 0.0.0.0 25-10-2013 15:59:51 <TRACE> as65342_igp: Connected to table routers 25-10-2013 15:59:51 <TRACE> as65342_igp: State changed to feed 25-10-2013 15:59:51 <TRACE> as65342_igp < interface lo0 goes up 25-10-2013 15:59:51 <TRACE> as65342_igp < primary address 127.0.0.0/8 on interface lo0 added 25-10-2013 15:59:51 <TRACE> as65342_igp < interface xn0 goes up 25-10-2013 15:59:51 <TRACE> as65342_igp < primary address x.x.x.0/24 on interface xn0 added 25-10-2013 15:59:51 <TRACE> as65342_igp < interface xn1 created 25-10-2013 15:59:51 <TRACE> as65342_igp < interface gre0 goes up 25-10-2013 15:59:51 <TRACE> as65342_igp < primary address 10.42.4.0/30 on interface gre0 added 25-10-2013 15:59:51 <TRACE> as65342_igp: Adding interface gre0 (10.42.4.0/30) to area 0.0.0.0 25-10-2013 15:59:51 <TRACE> as65342_igp < interface disc0 goes up 25-10-2013 15:59:51 <TRACE> as65342_igp < primary address 10.42.0.2/32 on interface disc0 added 25-10-2013 15:59:51 <TRACE> as65342_igp: Adding interface disc0 (10.42.0.2/32) to area 0.0.0.0 25-10-2013 15:59:51 <TRACE> as65342_igp < interface disc1 goes up 25-10-2013 15:59:51 <TRACE> as65342_igp < primary address 192.0.2.1/32 on interface disc1 added 25-10-2013 15:59:51 <TRACE> as65342_igp < interface gre1 goes up 25-10-2013 15:59:51 <TRACE> as65342_igp < primary address 10.42.8.0/30 on interface gre1 added 25-10-2013 15:59:51 <TRACE> as65342_igp: Adding interface gre1 (10.42.8.0/30) to area 0.0.0.0 25-10-2013 15:59:51 <TRACE> as65342_igp: State changed to up 25-10-2013 15:59:51 <TRACE> as65342_igp: Changing state of iface gre1 from down to ptp 25-10-2013 15:59:51 <TRACE> as65342_igp: Scheduling router-LSA origination for area 0.0.0.0 25-10-2013 15:59:51 <TRACE> as65342_igp: HELLO packet sent via gre1 25-10-2013 15:59:51 <TRACE> as65342_igp: Changing state of iface disc0 from down to waiting 25-10-2013 15:59:51 <TRACE> as65342_igp: Scheduling router-LSA origination for area 0.0.0.0 25-10-2013 15:59:51 <TRACE> as65342_igp: Changing state of iface gre0 from down to ptp 25-10-2013 15:59:51 <TRACE> as65342_igp: Scheduling router-LSA origination for area 0.0.0.0 25-10-2013 15:59:51 <TRACE> as65342_igp: HELLO packet sent via gre0 25-10-2013 15:59:51 <TRACE> as65342_igp: HELLO packet received from 10.42.8.2 via gre1 25-10-2013 15:59:51 <TRACE> as65342_igp: New neighbor found: 10.42.8.2 on gre1 25-10-2013 15:59:51 <TRACE> as65342_igp: Neighbor 10.42.8.2 changes state from " down" to " init". 25-10-2013 15:59:51 <TRACE> as65342_igp: Neighbor 10.42.8.2 changes state from " init" to " 2way". 25-10-2013 15:59:51 <TRACE> as65342_igp: Neighbor 10.42.8.2 changes state from " 2way" to " exstart". 25-10-2013 15:59:52 <TRACE> as65342_igp: Originating router-LSA for area 0.0.0.0 25-10-2013 15:59:52 <TRACE> as65342_igp: Scheduling routing table calculation 25-10-2013 15:59:52 <TRACE> as65342_igp: DBDES packet sent to 10.42.8.2 via gre1 25-10-2013 15:59:52 <TRACE> as65342_igp: length 32 25-10-2013 15:59:52 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:52 <TRACE> as65342_igp: imms MS M I 25-10-2013 15:59:52 <TRACE> as65342_igp: ddseq 2002210460 25-10-2013 15:59:52 <TRACE> as65342_igp: Starting routing table calculation 25-10-2013 15:59:52 <TRACE> as65342_igp: Starting routing table calculation for area 0.0.0.0 25-10-2013 15:59:52 <TRACE> as65342_igp: Starting routing table calculation for inter-area (area 0.0.0.0) 25-10-2013 15:59:52 <TRACE> as65342_igp: Starting routing table calculation for ext routes 25-10-2013 15:59:52 <TRACE> as65342_igp: Starting routing table synchronisation 25-10-2013 15:59:52 <TRACE> as65342_igp > filtered out 10.42.4.0/30 dev gre0 25-10-2013 15:59:52 <TRACE> as65342_igp > added [best] 10.42.0.2/32 dev disc0 25-10-2013 15:59:52 <TRACE> as65342_igp < rejected by protocol 10.42.0.2/32 dev disc0 25-10-2013 15:59:52 <TRACE> as65342_igp > filtered out 10.42.8.0/30 dev gre1 25-10-2013 15:59:52 <TRACE> as65342_igp: DBDES packet received from 10.42.8.2 via gre1 25-10-2013 15:59:52 <TRACE> as65342_igp: length 32 25-10-2013 15:59:52 <TRACE> as65342_igp: router 10.42.0.3 25-10-2013 15:59:52 <TRACE> as65342_igp: imms MS M I 25-10-2013 15:59:52 <TRACE> as65342_igp: ddseq 8873 25-10-2013 15:59:52 <TRACE> as65342_igp: I'm slave to 10.42.8.2. 25-10-2013 15:59:52 <TRACE> as65342_igp: Neighbor 10.42.8.2 changes state from " exstart" to "exchange". 25-10-2013 15:59:52 <TRACE> as65342_igp: DBDES packet sent to 10.42.8.2 via gre1 25-10-2013 15:59:52 <TRACE> as65342_igp: length 52 25-10-2013 15:59:52 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:52 <TRACE> as65342_igp: imms 25-10-2013 15:59:52 <TRACE> as65342_igp: ddseq 8873 25-10-2013 15:59:52 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 0, Seq: 80000001, Sum: ba53 25-10-2013 15:59:52 <TRACE> as65342_igp: DBDES packet received from 10.42.8.2 via gre1 25-10-2013 15:59:52 <TRACE> as65342_igp: length 112 25-10-2013 15:59:52 <TRACE> as65342_igp: router 10.42.0.3 25-10-2013 15:59:52 <TRACE> as65342_igp: imms MS 25-10-2013 15:59:52 <TRACE> as65342_igp: ddseq 8874 25-10-2013 15:59:52 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.1, Rt: 10.42.0.1, Age: 2, Seq: 800051d0, Sum: 3971 25-10-2013 15:59:52 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 47, Seq: 80000042, Sum: 397f 25-10-2013 15:59:52 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 0, Seq: 800013eb, Sum: ab03 25-10-2013 15:59:52 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.4, Rt: 10.42.0.4, Age: 309, Seq: 800003c5, Sum: 24cf 25-10-2013 15:59:52 <TRACE> as65342_igp: DBDES packet sent to 10.42.8.2 via gre1 25-10-2013 15:59:52 <TRACE> as65342_igp: length 32 25-10-2013 15:59:52 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:52 <TRACE> as65342_igp: imms 25-10-2013 15:59:52 <TRACE> as65342_igp: ddseq 8874 25-10-2013 15:59:52 <TRACE> as65342_igp: Neighbor 10.42.8.2 changes state from "exchange" to " loading". 25-10-2013 15:59:52 <TRACE> as65342_igp: HELLO packet received from 10.42.4.1 via gre0 25-10-2013 15:59:52 <TRACE> as65342_igp: New neighbor found: 10.42.4.1 on gre0 25-10-2013 15:59:52 <TRACE> as65342_igp: Neighbor 10.42.4.1 changes state from " down" to " init". 25-10-2013 15:59:52 <TRACE> as65342_igp: Neighbor 10.42.4.1 changes state from " init" to " 2way". 25-10-2013 15:59:52 <TRACE> as65342_igp: Neighbor 10.42.4.1 changes state from " 2way" to " exstart". 25-10-2013 15:59:53 <TRACE> as65342_igp: DBDES packet sent to 10.42.4.1 via gre0 25-10-2013 15:59:53 <TRACE> as65342_igp: length 32 25-10-2013 15:59:53 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:53 <TRACE> as65342_igp: imms MS M I 25-10-2013 15:59:53 <TRACE> as65342_igp: ddseq 43533694 25-10-2013 15:59:53 <TRACE> as65342_igp: LSREQ packet sent to 10.42.8.2 via gre1 25-10-2013 15:59:53 <TRACE> as65342_igp: length 72 25-10-2013 15:59:53 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:53 <TRACE> as65342_igp: LSR Type: 0001, Id: 10.42.0.1, Rt: 10.42.0.1 25-10-2013 15:59:53 <TRACE> as65342_igp: LSR Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2 25-10-2013 15:59:53 <TRACE> as65342_igp: LSR Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3 25-10-2013 15:59:53 <TRACE> as65342_igp: LSR Type: 0001, Id: 10.42.0.4, Rt: 10.42.0.4 25-10-2013 15:59:53 <TRACE> as65342_igp: DBDES packet received from 10.42.4.1 via gre0 25-10-2013 15:59:53 <TRACE> as65342_igp: length 112 25-10-2013 15:59:53 <TRACE> as65342_igp: router 10.42.0.1 25-10-2013 15:59:53 <TRACE> as65342_igp: imms 25-10-2013 15:59:53 <TRACE> as65342_igp: ddseq 43533694 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.4, Rt: 10.42.0.4, Age: 309, Seq: 800003c5, Sum: 24cf 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 49, Seq: 80000042, Sum: 397f 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.1, Rt: 10.42.0.1, Age: 1, Seq: 800051d0, Sum: 3971 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 4, Seq: 800013eb, Sum: ab03 25-10-2013 15:59:53 <TRACE> as65342_igp: I'm master to 10.42.4.1. 25-10-2013 15:59:53 <TRACE> as65342_igp: Neighbor 10.42.4.1 changes state from " exstart" to "exchange". 25-10-2013 15:59:53 <TRACE> as65342_igp: DBDES packet sent to 10.42.4.1 via gre0 25-10-2013 15:59:53 <TRACE> as65342_igp: length 52 25-10-2013 15:59:53 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:53 <TRACE> as65342_igp: imms MS 25-10-2013 15:59:53 <TRACE> as65342_igp: ddseq 43533695 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 1, Seq: 80000001, Sum: ba53 25-10-2013 15:59:53 <TRACE> as65342_igp: DBDES packet received from 10.42.4.1 via gre0 25-10-2013 15:59:53 <TRACE> as65342_igp: length 32 25-10-2013 15:59:53 <TRACE> as65342_igp: router 10.42.0.1 25-10-2013 15:59:53 <TRACE> as65342_igp: imms 25-10-2013 15:59:53 <TRACE> as65342_igp: ddseq 43533695 25-10-2013 15:59:53 <TRACE> as65342_igp: Neighbor 10.42.4.1 changes state from "exchange" to " loading". 25-10-2013 15:59:53 <TRACE> as65342_igp: LSUPD packet received from 10.42.8.2 via gre1 25-10-2013 15:59:53 <TRACE> as65342_igp: length 352 25-10-2013 15:59:53 <TRACE> as65342_igp: router 10.42.0.3 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.1, Rt: 10.42.0.1, Age: 5, Seq: 800051d0, Sum: 3971 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 50, Seq: 80000042, Sum: 397f 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 4, Seq: 800013eb, Sum: ab03 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.4, Rt: 10.42.0.4, Age: 312, Seq: 800003c5, Sum: 24cf 25-10-2013 15:59:53 <TRACE> as65342_igp: Scheduling routing table calculation 25-10-2013 15:59:53 <TRACE> as65342_igp: Received old self-originated LSA (Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2) 25-10-2013 15:59:53 <TRACE> as65342_igp: Reflooding new self-originated LSA with newer sequence number 25-10-2013 15:59:53 <TRACE> as65342_igp: LSUPD packet flooded via gre0 25-10-2013 15:59:53 <TRACE> as65342_igp: length 88 25-10-2013 15:59:53 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 1, Seq: 80000043, Sum: 3695 25-10-2013 15:59:53 <TRACE> as65342_igp: LSUPD packet flooded via gre1 25-10-2013 15:59:53 <TRACE> as65342_igp: length 88 25-10-2013 15:59:53 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 1, Seq: 80000043, Sum: 3695 25-10-2013 15:59:53 <TRACE> as65342_igp: Neighbor 10.42.4.1 changes state from " loading" to " full". 25-10-2013 15:59:53 <TRACE> as65342_igp: Scheduling router-LSA origination for area 0.0.0.0 25-10-2013 15:59:53 <TRACE> as65342_igp: Scheduling network-LSA origination for iface gre0 25-10-2013 15:59:53 <TRACE> as65342_igp: Neighbor 10.42.8.2 changes state from " loading" to " full". 25-10-2013 15:59:53 <TRACE> as65342_igp: Scheduling router-LSA origination for area 0.0.0.0 25-10-2013 15:59:53 <TRACE> as65342_igp: Scheduling network-LSA origination for iface gre1 25-10-2013 15:59:53 <TRACE> as65342_igp: LSACK packet received from 10.42.8.2 via gre1 25-10-2013 15:59:53 <TRACE> as65342_igp: length 44 25-10-2013 15:59:53 <TRACE> as65342_igp: router 10.42.0.3 25-10-2013 15:59:53 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 1, Seq: 80000043, Sum: 3695 25-10-2013 15:59:53 <TRACE> as65342_igp: HELLO packet received from 10.42.8.2 via gre1 25-10-2013 15:59:54 <TRACE> as65342_igp: Starting routing table calculation 25-10-2013 15:59:54 <TRACE> as65342_igp: Starting routing table calculation for area 0.0.0.0 25-10-2013 15:59:54 <TRACE> as65342_igp: Starting routing table calculation for inter-area (area 0.0.0.0) 25-10-2013 15:59:54 <TRACE> as65342_igp: Starting routing table calculation for ext routes 25-10-2013 15:59:54 <TRACE> as65342_igp: Starting routing table synchronisation 25-10-2013 15:59:54 <TRACE> as65342_igp: LSUPD packet sent to 10.42.4.1 via gre0 25-10-2013 15:59:54 <TRACE> as65342_igp: length 88 25-10-2013 15:59:54 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:54 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 1, Seq: 80000043, Sum: 3695 25-10-2013 15:59:54 <TRACE> as65342_igp: LSACK packet received from 10.42.4.1 via gre0 25-10-2013 15:59:54 <TRACE> as65342_igp: length 44 25-10-2013 15:59:54 <TRACE> as65342_igp: router 10.42.0.1 25-10-2013 15:59:54 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 1, Seq: 80000043, Sum: 3695 25-10-2013 15:59:56 <TRACE> as65342_igp: HELLO packet sent via gre0 25-10-2013 15:59:56 <TRACE> as65342_igp: HELLO packet sent via gre1 25-10-2013 15:59:56 <TRACE> as65342_igp: LSUPD packet received from 10.42.8.2 via gre1 25-10-2013 15:59:56 <TRACE> as65342_igp: length 112 25-10-2013 15:59:56 <TRACE> as65342_igp: router 10.42.0.3 25-10-2013 15:59:56 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 3, Seq: 800013ec, Sum: 3c03 25-10-2013 15:59:56 <TRACE> as65342_igp: LSUPD packet flooded via gre0 25-10-2013 15:59:56 <TRACE> as65342_igp: length 112 25-10-2013 15:59:56 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:56 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 4, Seq: 800013ec, Sum: 3c03 25-10-2013 15:59:56 <TRACE> as65342_igp: Scheduling routing table calculation 25-10-2013 15:59:57 <TRACE> as65342_igp: LSUPD packet sent to 10.42.4.1 via gre0 25-10-2013 15:59:57 <TRACE> as65342_igp: length 112 25-10-2013 15:59:57 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 3, Seq: 800013ec, Sum: 3c03 25-10-2013 15:59:57 <TRACE> as65342_igp: Starting routing table calculation 25-10-2013 15:59:57 <TRACE> as65342_igp: Starting routing table calculation for area 0.0.0.0 25-10-2013 15:59:57 <TRACE> as65342_igp: Starting routing table calculation for inter-area (area 0.0.0.0) 25-10-2013 15:59:57 <TRACE> as65342_igp: Starting routing table calculation for ext routes 25-10-2013 15:59:57 <TRACE> as65342_igp: Starting routing table synchronisation 25-10-2013 15:59:57 <TRACE> as65342_igp: LSUPD packet received from 10.42.4.1 via gre0 25-10-2013 15:59:57 <TRACE> as65342_igp: length 112 25-10-2013 15:59:57 <TRACE> as65342_igp: router 10.42.0.1 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 4, Seq: 800013ec, Sum: 3c03 25-10-2013 15:59:57 <TRACE> as65342_igp: LSUPD packet received from 10.42.4.1 via gre0 25-10-2013 15:59:57 <TRACE> as65342_igp: length 148 25-10-2013 15:59:57 <TRACE> as65342_igp: router 10.42.0.1 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.1, Rt: 10.42.0.1, Age: 1, Seq: 800051d1, Sum: fc25 25-10-2013 15:59:57 <TRACE> as65342_igp: LSUPD packet flooded via gre1 25-10-2013 15:59:57 <TRACE> as65342_igp: length 148 25-10-2013 15:59:57 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.1, Rt: 10.42.0.1, Age: 2, Seq: 800051d1, Sum: fc25 25-10-2013 15:59:57 <TRACE> as65342_igp: Scheduling routing table calculation 25-10-2013 15:59:57 <TRACE> as65342_igp: LSUPD packet received from 10.42.4.1 via gre0 25-10-2013 15:59:57 <TRACE> as65342_igp: length 232 25-10-2013 15:59:57 <TRACE> as65342_igp: router 10.42.0.1 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 4, Seq: 800013ec, Sum: 3c03 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.1, Rt: 10.42.0.1, Age: 0, Seq: 800051d1, Sum: fc25 25-10-2013 15:59:57 <TRACE> as65342_igp: LSACK packet sent via gre0 25-10-2013 15:59:57 <TRACE> as65342_igp: length 64 25-10-2013 15:59:57 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 4, Seq: 800013ec, Sum: 3c03 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.1, Rt: 10.42.0.1, Age: 0, Seq: 800051d1, Sum: fc25 25-10-2013 15:59:57 <TRACE> as65342_igp: LSACK packet received from 10.42.4.1 via gre0 25-10-2013 15:59:57 <TRACE> as65342_igp: length 44 25-10-2013 15:59:57 <TRACE> as65342_igp: router 10.42.0.1 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 3, Seq: 800013ec, Sum: 3c03 25-10-2013 15:59:57 <TRACE> as65342_igp: LSUPD packet received from 10.42.8.2 via gre1 25-10-2013 15:59:57 <TRACE> as65342_igp: length 148 25-10-2013 15:59:57 <TRACE> as65342_igp: router 10.42.0.3 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.1, Rt: 10.42.0.1, Age: 4, Seq: 800051d1, Sum: fc25 25-10-2013 15:59:57 <TRACE> as65342_igp: HELLO packet received from 10.42.4.1 via gre0 25-10-2013 15:59:57 <TRACE> as65342_igp: LSUPD packet received from 10.42.8.2 via gre1 25-10-2013 15:59:57 <TRACE> as65342_igp: length 112 25-10-2013 15:59:57 <TRACE> as65342_igp: router 10.42.0.3 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 4, Seq: 800013ec, Sum: 3c03 25-10-2013 15:59:57 <TRACE> as65342_igp: LSACK packet sent via gre1 25-10-2013 15:59:57 <TRACE> as65342_igp: length 44 25-10-2013 15:59:57 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:57 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.3, Rt: 10.42.0.3, Age: 4, Seq: 800013ec, Sum: 3c03 25-10-2013 15:59:58 <TRACE> as65342_igp: Originating router-LSA for area 0.0.0.0 25-10-2013 15:59:58 <TRACE> as65342_igp: LSUPD packet flooded via gre0 25-10-2013 15:59:58 <TRACE> as65342_igp: length 112 25-10-2013 15:59:58 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:58 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 1, Seq: 80000044, Sum: 3581 25-10-2013 15:59:58 <TRACE> as65342_igp: LSUPD packet flooded via gre1 25-10-2013 15:59:58 <TRACE> as65342_igp: length 112 25-10-2013 15:59:58 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:58 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 1, Seq: 80000044, Sum: 3581 25-10-2013 15:59:58 <TRACE> as65342_igp: Starting routing table calculation 25-10-2013 15:59:58 <TRACE> as65342_igp: Starting routing table calculation for area 0.0.0.0 25-10-2013 15:59:58 <TRACE> as65342_igp: Starting routing table calculation for inter-area (area 0.0.0.0) 25-10-2013 15:59:58 <TRACE> as65342_igp: Starting routing table calculation for ext routes 25-10-2013 15:59:58 <TRACE> as65342_igp: Starting routing table synchronisation 25-10-2013 15:59:58 <TRACE> as65342_igp: LSUPD packet sent to 10.42.4.1 via gre0 25-10-2013 15:59:58 <TRACE> as65342_igp: length 112 25-10-2013 15:59:58 <TRACE> as65342_igp: router 10.42.0.2 25-10-2013 15:59:58 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 0, Seq: 80000044, Sum: 3581 25-10-2013 15:59:58 <TRACE> as65342_igp: LSACK packet received from 10.42.4.1 via gre0 25-10-2013 15:59:58 <TRACE> as65342_igp: length 44 25-10-2013 15:59:58 <TRACE> as65342_igp: router 10.42.0.1 25-10-2013 15:59:58 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 0, Seq: 80000044, Sum: 3581 25-10-2013 15:59:58 <TRACE> as65342_igp: LSACK packet received from 10.42.8.2 via gre1 25-10-2013 15:59:58 <TRACE> as65342_igp: length 44 25-10-2013 15:59:58 <TRACE> as65342_igp: router 10.42.0.3 25-10-2013 15:59:58 <TRACE> as65342_igp: LSA Type: 0001, Id: 10.42.0.2, Rt: 10.42.0.2, Age: 1, Seq: 80000044, Sum: 3581 25-10-2013 15:59:58 <TRACE> as65342_igp: HELLO packet received from 10.42.8.2 via gre1 25-10-2013 16:00:01 <TRACE> as65342_igp: HELLO packet sent via gre1 25-10-2013 16:00:01 <TRACE> as65342_igp: HELLO packet sent via gre0 25-10-2013 16:00:03 <TRACE> as65342_igp: HELLO packet received from 10.42.4.1 via gre0 25-10-2013 16:00:03 <TRACE> as65342_igp: HELLO packet received from 10.42.8.2 via gre1 25-10-2013 16:00:06 <TRACE> as65342_igp: HELLO packet sent via gre0 25-10-2013 16:00:06 <TRACE> as65342_igp: HELLO packet sent via gre1 25-10-2013 16:00:07 <TRACE> as65342_igp: HELLO packet received from 10.42.4.1 via gre0 25-10-2013 16:00:07 <TRACE> as65342_igp: HELLO packet received from 10.42.8.2 via gre1 25-10-2013 16:00:11 <TRACE> as65342_igp: HELLO packet sent via gre1 25-10-2013 16:00:11 <TRACE> as65342_igp: HELLO packet sent via gre0 25-10-2013 16:00:12 <TRACE> as65342_igp: HELLO packet received from 10.42.8.2 via gre1 25-10-2013 16:00:12 <TRACE> as65342_igp: HELLO packet received from 10.42.4.1 via gre0 25-10-2013 16:00:16 <TRACE> as65342_igp: HELLO packet sent via gre0 25-10-2013 16:00:16 <TRACE> as65342_igp: HELLO packet sent via gre1 25-10-2013 16:00:17 <TRACE> as65342_igp: HELLO packet received from 10.42.8.2 via gre1 25-10-2013 16:00:17 <TRACE> as65342_igp: HELLO packet received from 10.42.4.1 via gre0 ^C neutralino [~]# -- LRO-RIPE | 570DE0BE | 9BF5 922E AF87 8584 E9CA C3AD C508 39A9 570D E0BE

3 7

AW: Re: BGP path prepend / route selection
by Amadeus 25 Oct '13

25 Oct '13

Thanks Alexander that helps! Best wishes, Amadeus >---- Original Message ---- >From: Alexander Shikov <a.shikov(a)dtel-ix.net> >To: "Amadeus" <amadeus(a)freehop.mooo.com> >Cc: bird-users(a)network.cz >Sent: Fr, Okt 25, 2013, 5:30 PM >Subject: Re: BGP path prepend / route selection > >Hi, > >On Fri, Oct 25, 2013 at 03:56:45PM +0000, Amadeus wrote: >> Dear list, >> can you explain why the following route (0.0.0.0/0) is selected to go via >> as403, as as4057 clearly displays the shortest path here? >> As you can see I have used bgp_path.prepend() 3x on as403 for its own ASN. >> Thanks, Amadeus >> bird> show route for 0.0.0.0/0 table ffc all >> 0.0.0.0/0 via 169.254.40.3 on ffc403 [as403 14:38] * (150) >> [AS403i] >> Type: BGP unicast univ >> BGP.origin: IGP >> BGP.as_path: 403 403 403 403 >> BGP.next_hop: 169.254.40.3 >> BGP.local_pref: 100 >> via 169.254.40.64 on ffc4064 [as4064 14:32] (100) >> [AS4057i] >> Type: BGP unicast univ >> BGP.origin: IGP >> BGP.as_path: 4064 40120 4057 >> BGP.next_hop: 169.254.40.64 >> BGP.local_pref: 100 >> via 169.254.40.57 on ffc4057 [as4057 Oct14] (100) >> [AS4057i] >> Type: BGP unicast univ >> BGP.origin: IGP >> BGP.as_path: 4057 >> BGP.next_hop: 169.254.40.57 >> BGP.local_pref: 100 > >it is because local-pref. Default route to AS403 has higher local-pref >than one to AS4057. > >-- >Alexander Shikov >Technical Staff, Digital Telecom IX >Tel.: +380 44 201 14 07 >http://dtel-ix.net/

1 0

BGP path prepend / route selection
by Amadeus 25 Oct '13

25 Oct '13

Dear list, can you explain why the following route (0.0.0.0/0) is selected to go via as403, as as4057 clearly displays the shortest path here? As you can see I have used bgp_path.prepend() 3x on as403 for its own ASN. Thanks, Amadeus bird> show route for 0.0.0.0/0 table ffc all 0.0.0.0/0 via 169.254.40.3 on ffc403 [as403 14:38] * (150) [AS403i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 403 403 403 403 BGP.next_hop: 169.254.40.3 BGP.local_pref: 100 via 169.254.40.64 on ffc4064 [as4064 14:32] (100) [AS4057i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 4064 40120 4057 BGP.next_hop: 169.254.40.64 BGP.local_pref: 100 via 169.254.40.57 on ffc4057 [as4057 Oct14] (100) [AS4057i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 4057 BGP.next_hop: 169.254.40.57 BGP.local_pref: 100

2 1

how to use bird in Freebsd system.
by 曾小小 22 Oct '13

22 Oct '13

Hello How to learn from the BIRD routing table to output to the freebsd multiple routing tables. Similar to the linux environment bird table specified routing table can be output to the rt_table in iproute2. My freebsd system version is FreeBSD 10.0-BETA1, BIRD version BIRD 1.3.11. Since my freebsd system configured setfib, and on the pf.conf of rtable. I was able to learn from the BIRD to the ospf routing (the route saved in the specified table in the) output to the freebsd pf the rtable in it? How do I configure it? At the same time, how can I be in the table BIRD route output to setfib in it? How to configure it?

2 1

[PATCH] Add bgp's allowas-in feature.
by Milan Kocian 21 Oct '13

21 Oct '13

Sometimes its useful feature. So make it optional per bgp protocol. Based on hint http://permalink.gmane.org/gmane.network.bird.user/944 Signed-off-by: Milan Kocian <milon(a)wq.cz> --- proto/bgp/attrs.c | 5 +++-- proto/bgp/bgp.h | 1 + proto/bgp/config.Y | 4 +++- 3 files changed, 7 insertions(+), 3 deletions(-) diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c index c27a498..27a2694 100644 --- a/proto/bgp/attrs.c +++ b/proto/bgp/attrs.c @@ -1704,8 +1704,9 @@ bgp_decode_attrs(struct bgp_conn *conn, byte *attr, unsigned int len, struct lin bgp_remove_as4_attrs(bgp, a); /* If the AS path attribute contains our AS, reject the routes */ - if (bgp_as_path_loopy(bgp, a)) - goto withdraw; + if (!bgp->cf->allow_as_in) + if (bgp_as_path_loopy(bgp, a)) + goto withdraw; /* Two checks for IBGP loops caused by route reflection, RFC 4456 */ if (bgp_originator_id_loopy(bgp, a) || diff --git a/proto/bgp/bgp.h b/proto/bgp/bgp.h index 77a3671..f45c3aa 100644 --- a/proto/bgp/bgp.h +++ b/proto/bgp/bgp.h @@ -44,6 +44,7 @@ struct bgp_config { int passive; /* Do not initiate outgoing connection */ int interpret_communities; /* Hardwired handling of well-known communities */ int secondary; /* Accept also non-best routes (i.e. RA_ACCEPTED) */ + int allow_as_in; unsigned connect_retry_time; unsigned hold_time, initial_hold_time; unsigned keepalive_time; diff --git a/proto/bgp/config.Y b/proto/bgp/config.Y index d5e5aac..709f5dc 100644 --- a/proto/bgp/config.Y +++ b/proto/bgp/config.Y @@ -26,7 +26,7 @@ CF_KEYWORDS(BGP, LOCAL, NEIGHBOR, AS, HOLD, TIME, CONNECT, RETRY, PREFER, OLDER, MISSING, LLADDR, DROP, IGNORE, ROUTE, REFRESH, INTERPRET, COMMUNITIES, BGP_ORIGINATOR_ID, BGP_CLUSTER_LIST, IGP, TABLE, GATEWAY, DIRECT, RECURSIVE, MED, TTL, SECURITY, DETERMINISTIC, - SECONDARY) + SECONDARY, ALLOW, ALLOW_AS_IN) CF_GRAMMAR @@ -49,6 +49,7 @@ bgp_proto_start: proto_start BGP { BGP_CFG->advertise_ipv4 = 1; BGP_CFG->interpret_communities = 1; BGP_CFG->default_local_pref = 100; + BGP_CFG->allow_as_in = 0; } ; @@ -78,6 +79,7 @@ bgp_proto: | bgp_proto MULTIHOP expr ';' { BGP_CFG->multihop = $3; if (($3<1) || ($3>255)) cf_error("Multihop must be in range 1-255"); } | bgp_proto NEXT HOP SELF ';' { BGP_CFG->next_hop_self = 1; BGP_CFG->next_hop_keep = 0; } | bgp_proto NEXT HOP KEEP ';' { BGP_CFG->next_hop_keep = 1; BGP_CFG->next_hop_self = 0; } + | bgp_proto ALLOW AS IN ';' { BGP_CFG->allow_as_in = 1; } | bgp_proto MISSING LLADDR SELF ';' { BGP_CFG->missing_lladdr = MLL_SELF; } | bgp_proto MISSING LLADDR DROP ';' { BGP_CFG->missing_lladdr = MLL_DROP; } | bgp_proto MISSING LLADDR IGNORE ';' { BGP_CFG->missing_lladdr = MLL_IGNORE; } -- 1.8.4.rc3 -- Milan Kocian

3 3

Proposing a patch for bird
by Pierre Pfister 21 Oct '13

21 Oct '13

Hello, I am using bird as an OSPFv3 daemon and I encountered a bug while playing with the wires. Therefore, I would like to propose this correcting patch. If you have any more formal way to do it, please tell me. I looked at your gitlab, but couldn't find any way to propose a patch. Cheers, Pierre Pfister ---------------Here is my own commit's commentary that explains the patch--------- [DEBUG] Keep latest source address as neighbor's address In RFC5340, it is stated: "For all link types except virtual links, the Neighbor IP address is set to the IPv6 source address in the IPv6 header of the received OSPF Hello packet." It is not said which source address should be kept among all received Hello packets from the same neighbor. In current implementation, the first is used. In some cases, the neighbor's source address can change. But, in OSPFv3, neighbors are always identified by their IDs. If we don't keep the latest address as the neighbor's address, all HELLO packets will be correctly considered, but further unicast packet sent to the router that changed its address may not be received, making the link state blocking indefinitly. Cases where the source address can change are: - A wire's end is moved from one port to another. - For some reason, a router decides to change its Active Interface, which choice is implementation dependent. ---------------Here is the patch as provided by git-------------- diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c index 58e87bb..0fbedc3 100644 --- a/proto/ospf/hello.c +++ b/proto/ospf/hello.c @@ -152,6 +152,12 @@ ospf_hello_receive(struct ospf_packet *ps_i, struct ospf_iface *ifa, n->iface_id = ntohl(ps->iface_id); #endif } +#ifdef OSPFv3 + else if (!ipa_equal(n->ip, faddr)) { + OSPF_TRACE(D_EVENTS, "Neighbor address changed from %I to %I", n->ip, faddr); + n->ip = faddr; + } +#endif ospf_neigh_sm(n, INM_HELLOREC); pnrid = (u32 *) ((struct ospf_hello_packet *) (ps + 1));

2 5

Strange MD5 Auth problem in BIRD 1.3.8
by Michael Vallaly 15 Oct '13

15 Oct '13

Hi, I recently had an interesting problem surrounding socket option buffers and its use in Bird on Linux 3.6 which I hope someone could shed some light on. Quite frequently see the following in our logs when enabling/starting BGP sessions when configured to use MD5 auth. <snip> Sep 24 23:12:46 rtr2 bird: sk_set_md5_auth_int: setsockopt: No such file or directory </snip> These never seem to cause any functionality problems, but seemed strange / maybe related to my new ongoing issue. ;) ## My functionality impacting problem ## Yesterday after some upstream BGP peers has connectivity issues (Hold timer expired), all of my previously working BGP sessions (using MD5 auth) attempted to reconnect and gave me the following in the logs: <snip> Oct 9 18:02:08 rtr2 bird: plxhq: Error: Hold timer expired Oct 9 18:02:08 rtr2 bird: plxhq: BGP session closed Oct 9 18:02:08 rtr2 bird: plxhq: State changed to flush Oct 9 18:02:08 rtr2 bird: plxhq: State changed to stop Oct 9 18:02:08 rtr2 bird: sk_set_md5_auth_int: setsockopt: No such file or directory Oct 9 18:02:08 rtr2 bird: plxhq: Down Oct 9 18:02:08 rtr2 bird: plxhq: Starting Oct 9 18:02:08 rtr2 bird: sk_set_md5_auth_int: setsockopt: Cannot allocate memory </snip> At which point the BGP session fails to establish/start, and all subsequent BGP sessions that are started (with MD5 Auth) also fail with the same message. Looking through the bird code it seems bird issues some socket control messages to update the TCP socket with MD5 parameters. And after digging around in the Linux system it seems I was running out of socket option memory buffers (duh!). Thusly I was able to "fix" this by issuing: <snip> echo 40960 > /proc/sys/net/core/optmem_max # Defaults to 20480 </snip> Is this expected? Any insight on how to properly size the socket option memory buffers used by bird? Is this some sort of a socket buffer leak? <snip> bird> show memory BIRD memory usage Routing tables: 307 MB Route attributes: 106 MB ROA tables: 192 B Protocols: 388 kB Total: 413 MB $ uptime 16:45:03 up 343 days, 1:23, 1 user, load average: 0.00, 0.03, 0.05 </snip> I have multiple identical machines running the same os/software/configuration and so far only one of them has shown this behavior. Thanks! -Mike -- Michael Vallaly <mvallaly(a)nolatency.com>

2 1