- Bird-users - Mailing Lists

how to confirm which capabilities have been negotiated
by Eiichiro Watanabe 24 Oct '11

24 Oct '11

Hello, Do we have an appropriate command to show which BGP capabilities have been negotiated on bird after a peer has been established? Of course, I known I can recognize when I look into packets captured, or confirm it on the neighbor router by using "show ip bgp neighbor x.x.x.x" command (in the case of CiscoIOS). it wouldn't be smart. Thanks, eiichiro -- ################################################### Eiichiro Watanabe Internet Multifeed Co.

4 5

reading /etc/bird.conf (bird 1.3.4)
by Arkadiusz Miśkiewicz 24 Oct '11

24 Oct '11

Hi, Would be good if bird was reading /etc/bird.conf before it drops priviledges when -u user -g group is used. Right now it first changes uid/gid to specified and then tries to open bird.conf which will fail with my config: -rw-r----- 1 root root 6002 10-10 18:26 /etc/bird.conf and bird started with -u bird (uid=271) -g bird (gid=271). What's worse is that bird won't start when running it from init script at boot due to: 2441 open("/etc/bird.conf", O_RDONLY) = -1 EACCES (Permission denied) while it WILL start fine when doing the same thing from root@ ssh session (and that's because root belongs to root group which has access to bird.conf and that isn't lost at setresuid/setgid). strace at boot with additional capget and /proc/self/status reading just before bird.conf open: 2441 setgid32(271) = 0 2441 setresuid32(-1, 271, -1) = 0 2441 capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_ADMIN|CAP_NET_RAW, CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST| CAP_NET_ADMIN|CAP_NET_RAW, 0}) = 0 2441 prctl(PR_SET_KEEPCAPS, 1) = 0 2441 setresuid32(271, 271, 271) = 0 2441 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(5, 1), ...}) = 0 2441 ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 2441 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb784a000 2441 write(1, "crap\n", 5) = 5 2441 capget(0x20080522, 0, NULL) = 0 2441 capget(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_ADMIN|CAP_NET_RAW, CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST| CAP_NET_ADMIN|CAP_NET_RAW, 0}) = 0 2441 getresuid32([271], [271], [271]) = 0 2441 getresgid32([271], [271], [271]) = 0 2441 write(1, "crap2\n", 6) = 6 2441 open("/proc/self/status", O_RDONLY) = 5 2441 read(5, "Name:\tbird\nState:\tR (running)\nTgid:\t2441\nPid:\t2441\nPPid:\t2436\nTracerPid:\t2436\nUid:\t271\t271\t271\t271\nGid:\t271\t271\t271\t271\nFDSize:\t32\nGroups:\t\nVmPeak:\t 2588 kB\nVmSize:\t 2508 kB\nVmLck:\t 0 kB\nVmHWM:\t 752 kB\nVmRSS:\t 752 kB\nVmData:\t 180 kB\nVmStk:\t 132 kB\nVmExe:\t 308 kB\nVmLib:\t 1816 kB\nVmPTE:\t 16 kB\nVmSwap:\t 0 kB\nThreads:\t1\nSigQ:\t0/26059\nSigPnd:\t0000000000000000\nShdPnd:\t0000000000000000\nSigBlk:\t0000000000000000\nSigIgn:\t0000000000000000\nSigCgt: \t0000000180000000\nCapInh:\t0000000000000000\nCapPrm:\t0000000000003c00\nCapEff:\t0000000000003c00\nCapBnd:\tffffffffffffffff\nCpus_allowed:\tf\nCpus_allowed_list: \t0-3\nMems_allowed:\t1\nMems_allowed_list:\t0\nVxID: 0\nNxID: 0\nvoluntary_ctxt_switches:\t282\nnonvoluntary_ctxt_switches:\t1\n", 4096) = 754 2441 open("/etc/bird.conf", O_RDONLY) = -1 EACCES (Permission denied) strace when doing start at ssh root@...: 3279 setgid32(271) = 0 3279 setresuid32(-1, 271, -1) = 0 3279 capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_ADMIN|CAP_NET_RAW, CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST| CAP_NET_ADMIN|CAP_NET_RAW, 0}) = 0 3279 prctl(PR_SET_KEEPCAPS, 1) = 0 3279 setresuid32(271, 271, 271) = 0 3279 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 3279 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb789d000 3279 write(1, "crap\n", 5) = 5 3279 capget(0x20080522, 0, NULL) = 0 3279 capget(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_ADMIN|CAP_NET_RAW, CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST| CAP_NET_ADMIN|CAP_NET_RAW, 0}) = 0 3279 getresuid32([271], [271], [271]) = 0 3279 getresgid32([271], [271], [271]) = 0 3279 write(1, "crap2\n", 6) = 6 3279 open("/proc/self/status", O_RDONLY) = 5 3279 read(5, "Name:\tbird\nState:\tR (running)\nTgid:\t3279\nPid:\t3279\nPPid:\t3275\nTracerPid:\t3275\nUid:\t271\t271\t271\t271\nGid:\t271\t271\t271\t271\nFDSize:\t32\nGroups:\t0 1 2 3 4 6 10 \nVmPeak:\t 2588 kB\nVmSize:\t 2508 kB\nVmLck:\t 0 kB\nVmHWM:\t 752 kB\nVmRSS:\t 752 kB\nVmData:\t 180 kB\nVmStk:\t 132 kB\nVmExe:\t 308 kB\nVmLib:\t 1816 kB\nVmPTE:\t 16 kB\nVmSwap:\t 0 kB\nThreads:\t1\nSigQ:\t0/26059\nSigPnd:\t0000000000000000\nShdPnd:\t0000000000000000\nSigBlk:\t0000000000000000\nSigIgn: \t0000000000000000\nSigCgt:\t0000000180000000\nCapInh:\t0000000000000000\nCapPrm:\t0000000000003c00\nCapEff:\t0000000000003c00\nCapBnd:\tffffffffffffffff\nCpus_allowed: \tf\nCpus_allowed_list:\t0-3\nMems_allowed:\t1\nMems_allowed_list:\t0\nVxID: 0\nNxID: 0\nvoluntary_ctxt_switches:\t277\nnonvoluntary_ctxt_switches:\t4\n", 4096) = 769 3279 open("/etc/bird.conf", O_RDONLY) = 6 relevant difference: -Groups: +Groups: 0 1 2 3 4 6 10 So two things to do: - open bird.conf before dropping privledges - drop supplementary groups (or better set these groups based on where user (specified at "-u user") belongs) -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/

3 3

Questions on community handling
by Simone Morandini 24 Oct '11

24 Oct '11

Hi all, I have a couple of basic questions regarding communities: - is the "interpret communities switch" command meant only for well-known communities or for any community sent to the RS? - how can I see from birdc if a member is sending a specific community to the RS? "sh route where ((<mycommunity>)) ~ bgp_community"? Thanks, Simone. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

3 3

New release 1.3.2!
by Ondrej Filip 21 Oct '11

21 Oct '11

Hi! New version is ready! It includes mainly minor bugfixes and minor improvements all made by Santiago. We are working on packaging and other stuff. Changes: Version 1.3.2 o Allows run with restricted privileges. o Community list filter operation. o Fixes several problems in filter syntax: - Fixes several conflicts in the grammar. - Fixes a bug in (a..b, c) pair patterns. - Makes pair patterns orthogonal. - Allows term expressions in pair patterns without additional (). - Allows several comma separated values in switch cases. o Many bugfixes. Ondrej

9 17

IPv6 eBGP next_hop
by Mathias Wolkert 20 Oct '11

20 Oct '11

Hi I need to alter the next_hop for IPv6 prefixes advertised over IPv6 eBGP. I'm using a filter that says "bgp_next_hop = x:x:0:1c::1 ;". And it is seen in the birdc6 with: show route all <filtername> as BGP.next_hop: x:x:0:1c::1 but on the line I see: Next hop: x:x:0:1c::2 (16) #The GUA of the router Next hop: fe80::230:48ff:feba:6b17 (16) #The LL of the router which also is what I see on the receiving cisco. Has this behavior changed? i believe I had this working in bird-1.2.5 I'm now running bird-1.3.5 on Debian Lenny. What I'm really looking for is a way to only send a manually set globally unique address and no link-local. When I read the bird docs, it seems odd that this is referred to as a "improper bgp update". My interpretation of rfc2545 section 3 is that link-local is optional. It's not at all clear on how a receiver should treat an update with both LL and GUA NHs. My general feeling is that what was simple in IPv4, is not thought through in IPv6. /Tias

3 5

cidr aggregation of fib
by Tom Schmidt 18 Oct '11

18 Oct '11

Hello, maybe someone had similar requirement or an implementation pointer for me: I need to cidr aggregate a list of prefixes from my fib table (or an intermediate routing table) and export it into another routing table. Is there a smart way to hook in a a cidr aggregation script without breaking up BIRDs design? Thanks, -Tom

2 1

IEEE HPSR 2012
by Igor Maravić 17 Oct '11

17 Oct '11

********************************************************************************************************************* ********************************************************************************************************************* IEEE HPSR 2012 June 24-27 Belgrade Serbia http://www.ieee-hpsr.org Important Dates Full paper submission: January 20, 2012 Tutorial submission: January 20, 2012 Acceptance notifications: March 20, 2012 Camera-ready due: April 15, 2012 IEEE Conference on High Performance Switching and Routing 2012 will be held in Belgrade, the capital of Serbia. Belgrade is a lively metropolis that is a blend of different cultures whose representatives were visiting at various points of history. As such, it is very well suited to host the IEEE HPSR conference that gathers scientists and engineers from the entire world, after Heidelberg, Dallas, Kobe, Torino, Arizona, Hong Kong, Poznan, New York, Shanghai, Paris, Dallas (again), and Cartagena. Internet traffic keeps growing thanks to the access technologies whose speeds are increasing at a fast pace, and thanks to many non-profit and commercial efforts to bridge the digital-divide by providing all the advantages of the Internet to developing countries as well. At the same time, challenging applications are gaining popularity on the Internet such as multimedia and P2P applications. Multimedia applications require a lot of bandwidth and low delays, while the traffic patterns of P2P applications are impossible to predict. IPv4 addresses are being exhausted at this very moment. Data centers are moving a vast amount of content through thousands of switches. Also, routers and switches are being attacked, and energy available for them, as for everything else, is decreasing. All these circumstances put a higher burden than ever on switching and routing. So, there is a lot of work to be done, and IEEE HPSR 2012 will do its part by addressing the following topics: Architectures of high-performance switches and routers High-speed packet processors Address lookup algorithms Packet classification, scheduling and dropping Switching, bridging and routing protocols Multicasting P2P routing Routing in wireless, mobile and sensor networks Optical switching and routing Switching, bridging and routing in data centers and clouds Data placement and migration Multiprocessor networks Network management Pricing, accounting and charging QoS and scalability of switching, bridging and routing Traffic characterization and engineering Power-aware switching, bridging and routing protocols High-speed network security Paper submission guidelines: Submitted papers must be unpublished, and cannot be submitted elsewhere at the same time. Accepted papers should not exceed 6 pages in two-column IEEE Transactions style (www.ieee.org) Accepted papers longer than 6 pages will be charged $100 for each extra page. Papers cannot be longer than 8 pages. Papers should be submitted as PDF files through the EDAS system (http://edas.info) All submitted papers will be subject to three independent reviews. Awards: The Best Paper Award will be granted based on the reviewers’ comments and scores that it received. Presentation of the paper will be scored by the audience, and will influence its final ranking. Note: In order to publish the paper at the IEEE HPSR 2012 proceedings and IEEE Xplore, the paper must be presented at the conference, and at least one of its authors should have a full registration. Non-refundable registration fees must be paid prior to uploading the final IEEE formatted, publication-ready, version of the paper. General Chairs: Aleksandra Smiljanić (Belgrade University, Serbia), Mounir Hamdi (Hong Kong University of Science and Technology, China) Technical Program Committee Chairs: Jonathan Chao (Polytechnic Institute of NYU, USA), Eiji Oki (University of Electro-Communications in Tokyo, Japan), Cyriel Minkenberg (IBM Research, Switzerland) Publicity Chairs: Andrea Bianco (Politecnico di Torino, Italy), Aleksandar Kolarov (Telcordia, USA), Dominique Verchere (Alcatel-Lucent, France) Registration and Finance Chair: Milan Bjelica (Belgrade University, Serbia) Publication Chair: Ljiljana Trajković (Simon Fraser University, Canada) Local Arrangement Chairs: Zoran Čiča, Nataša Maksić, and Marija Antić (Belgrade University, Serbia) Tutorials Chair: Dejan Kostić (EPFL, Switzerland), dejan.kostic(a)epfl.ch Panel Chair: Mitchell Gusat (IBM, Switzerland) Q&A: aleksandra(a)etf.rs, zoran.cica(a)etf.rs

1 0

Export table
by Virgilio Pavel 13 Oct '11

13 Oct '11

Hello all! Bellow is a part of my bird.conf: # Static routes (again, there can be multiple instances, so that you # can disable/enable various groups of static routes on the fly). protocol static partial_20 { import all; # disabled; # Disable by default # table testable; # Connect to a non-default table # preference 1000; # Default preference of routes debug { states, routes, filters, interfaces, events, packets }; debug all; route 0.0.0.0/0 via 192.168.100.1; route 186.232.229.0/24 via 192.168.100.10; # route 62.168.0.0/25 reject; # route 10.0.0.0/8 reject; # route 10.1.1.0:255.255.255.0 via 192.168.100.10; # route 10.2.0.0/24 via "arc0"; } How can I export a route to my neighbor? []'s Virgilio Pavel

2 1

BGP multi-homed peering issue..
by Michael Vallaly 11 Oct '11

11 Oct '11

Fellow bird users, I currently have a single router with two upstream eBGP sessions to two separate ISPs. IE: ISP1 <---> Router <---> ISP2 I am attempting to advertise a public netblock to both of these ISPs simultaneously. I currently have a single kernel routing table (exterior) configured for the public netblock (203.0.113.0/24), below is a sample config. I seem to have a problem in Bird 1.3.3 with this configuration where the netblock only gets advertised out one of the two upstream peers. <snip> # Configure Additional Routing Tables table exterior; # BGP Linux Routing Table protocol kernel table_bgp { table exterior; kernel table 100; persist off; # Don't remove routes on bird shutdown learn off; # Bird exclusively manages this routing table import none; # Default is import all export all; # Default is export none } # BGP ingress filters filter ebgp_in { if net ~ [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 10.0.0.0/8+, 224.0.0.0/4+, 240.0.0.0/4+, 0.0.0.0/32-, 0.0.0.0/0{31,32}, 0.0.0.0/0{0,7} ] then { reject; } else accept; } # BGP egress filters filter ebgp_out { if net ~ [ 203.0.113.0/24 ] then { accept; } else reject; } # eBGP Uplink to ISP1 protocol bgp uplink_isp1 { table exterior; debug {events, states}; description "ISP1 Uplink"; source address 192.168.1.2; local as 65000; neighbor 192.168.1.1 as 65001; hold time 180; startup hold time 180; connect retry time 30; keepalive time 60; start delay time 5; error wait time 60, 300; error forget time 300; import filter ebgp_in; export where proto = "ext_isp1"; } # eBGP Uplink to ISP2 protocol bgp uplink_isp2 { table exterior; debug {events, states}; description "ISP2 Uplink"; source address 192.168.2.2; local as 65000; neighbor 192.168.2.1 as 65002; hold time 180; startup hold time 180; connect retry time 30; keepalive time 60; start delay time 5; error wait time 60, 300; error forget time 300; import filter ebgp_in; export where proto = "ext_isp2"; } protocol static ext_isp1 { description "Advertise netblock to ISP1"; disabled; table exterior; route 203.0.113.0/24 via "eth0"; }; protocol static ext_isp2 { description "Advertise netblock to ISP2"; disabled; table exterior; route 203.0.113.0/24 via "eth0"; }; </snip> When I enable both ext_isp1 and ext_isp2 protocols simultaneously it seems the BGP advertisement only happens via one peer only, (not both as I expect / want). Does it make sense that this doesn't work as I expect? <snip> bird> show protocols all "ext_*" name proto table state since info ext_isp1 Static exterior up 2011-10-06T05:04:18 Preference: 200 Input filter: ACCEPT Output filter: REJECT Routes: 1 imported, 0 exported, 1 preferred Route change stats: received rejected filtered ignored accepted Import updates: 1 0 0 0 1 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 ext_isp2 Static exterior up 2011-10-06T05:04:43 Preference: 200 Input filter: ACCEPT Output filter: REJECT Routes: 1 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 1 0 0 0 1 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 bird> show route table exterior for 203.0.113.0/24 203.0.113.0/24 dev eth0 [ext_isp1 2011-10-06T05:04:18] * (200) dev eth0 [ext_isp2 2011-10-06T05:04:43] (200) bird> show protocols all "uplink_*" name proto table state since info uplink_isp1 BGP exterior up 2011-10-06T05:03:53 --omitted-- Routes: 366176 imported, 0 exported, 239181 preferred --omitted-- uplink_isp2 BGP exterior up 2011-10-06T05:03:56 --omitted-- Routes: 369569 imported, 1 exported, 131359 preferred --omitted-- </snip> Do I need to make two further routing tables (one for each ISP and use pipes to sync up the existing "exterior table") to make this work? If so could someone give an example of how to use pipes in this case? I tried adding the following after adding two tables and altering the BGP protocols to use them: <snip> protocol pipe { table table_isp1; mode transparent; peer table exterior; } protocol pipe { table table_isp2; mode transparent; peer table exterior; } </snip> This addition doesn't seem to behave as I expect. Could anyone offer an insight on what im doing wrong, its got to be something really silly. Thanks -Mike -- Michael Vallaly <mvallaly(a)nolatency.com>

3 3

Re: bird patches review
by Ondrej Zajicek 11 Oct '11

11 Oct '11

On Mon, Oct 03, 2011 at 10:03:30PM +0400, Alexander V. Chernikov wrote: >>> In most hardware routers (and even in Quagga) it is possibly to see if >>> RIB entry is installed to FIB >>> (e.g. * ). Maybe kernel can set some flag at least when it sees >>> installed prefix gets removed from kernel table? >>> (or adds some flags on route installation and remove it on route removal) >>> >> There is already such flag (because kernel sync is a bit tricky and abuses >> routing table to rememer its state), perhaps we could show that flag in >> some way. >> >> > Should I [as usual] submit patch for that? :) I found that the flag signalizes whether route is expected to be installed (but the installation might failed). I added the flag signalizing that the last attempt to install the route to the kernel table failed, and showed that flag in 'show route': bird> show route 10.200.0.0/16 via xx.xx.xx.xx on eth0 [static1 16:13] ! (200) 192.168.0.0/16 via xx.xx.xx.xx on eth0 [static1 16:13] * (200) 10.220.0.0/16 via xx.xx.xx.xx on eth0 [static1 16:13] * (200) Showing just whether the route is (supposed to be) installed seems a bit pointless - it is usually 'export all' or 'export none' for kernel protocol. If someone removes the route from FIB (kernel) and BIRD notices that, it reinstalls the route, so unless there is a problem in route installation, it remains synced. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

3 8