- Bird-users - Mailing Lists

Hardware requirements for BIRD
by Clément Guivy 11 Mar '17

11 Mar '17

Hello, I am considering the setup of BIRD as a router to handle our internet traffic. One information I fail to find is hardware requirements. My use case is as follows : - Two transit providers, each sending a full internet view - Two peerings on an IXP (less than 100k routes each) - One iBGP session between the two BIRD routers - One eBGP session to our internal network (advertising a default route and receiving less than 500 internal routes) - Traffic would be less than 1Gbps but as I understand it, this is relevant to forwarding plane and therefore out of the scope of BIRD. Which kind of hardware would be fit for that ? especially regarding CPU and RAM. I was considering an entry-level server with low-end Xeon CPU (E5-2603, 1.7Ghz 6 cores) and 8GB RAM, does that look sufficient, insufficient, or overkill ? I cant really tell. By the way, is BIRD able to use multiple cores ? and are there hardware requirements to be careful of, disregard CPU and RAM ? Thanks. Regards, Clément Guivy

5 5

Foster one BGP peer in case of AS path equality
by Alarig Le Lay 09 Mar '17

09 Mar '17

Hi, I have an AS (204092) with two upstreams (174 and 198507). On some cases, the AS path is the same on both peers. I would like to use 198507 over 174 only in this situation (so, no localpref). If I read the documentation correctly, I have take of « Prefer routes with lower internal distance to a boundary router. ». But I don’t see where I can set this internal distance. Does anybody have any clue about that? Thanks, -- alarig

2 2

RIP with passive option
by Alexander Festl 09 Mar '17

09 Mar '17

Hi, this is my first post in a mailing list. I hope I do it fine. My server should receive routes via RIP. I have tried it on Ubuntu 10.04 with bird from *ppa:cz.nic-labs/bird* . The server should work with the interface option passive. (Receive routes and do not send) My config file looks like: protocol kernel { persist; scan time 20; export all; } protocol device { scan time 10; } protocol rip { export none; import all; interface "eth0" { passive yes; }; debug all; } If I start bird, I get bird: /etc/bird.conf, line 15: syntax error I tried "yes", "true" and "" as switch for the passive option. I posted the question at stackexchange too. ( http://networkengineering.stackexchange.com/questions/39548/bird-rip-routes… ) Thank you in advance. Alexander Festl

3 7

Re: [PATCH 1/9] Adding configuration option --enable-sadr.
by Dean 07 Mar '17

07 Mar '17

On 03/07/2017 09:23 PM, Toke Høiland-Jørgensen wrote: > Basically, I want to do the opposite: We are going to have several > (well, at least two) protocols that understand source-specific routing, > so the nest data structures should work with both. And since Babel at > least is perfectly happy to mix source-specific and regular routes (and > will interoperate with an implementation that only supports the latter), > the nest data structures and lookup functions shouldn't be hidden behind > a configure switch (but the OSPF support might be I guess, unless you > can make it run-time configurable without too much hassle). > >> 1. the fib_node structure having a couple more data fields. If a >> protocol >> doesn't use them, this data won't hurt it, right? > Some data structure overhead is probably fine. > >> 2. fib_get, fib_find, fib_route, net_get, and net_find functions might >> do some more processing, but they should ultimately have the same >> behavior. > Yeah, the behaviour for non-source-specific routes should be unchanged, > and it should do something sensible when both types of routes exist. > Haven't gotten around to thinking seriously about how I'd implement > source-specific routing for Babel in Bird yet, so you're kinda breaking > new ground here; but happy to be a voice in the background at least > > -Toke Oh, I see what you mean. Since Babel works better with SADR, the nest changes should be more focused on Babel, *then* OSPF should make use of them. Instead of the other way around.

3 4

[PATCH 1/9] Adding configuration option --enable-sadr.
by Dean Luga 07 Mar '17

07 Mar '17

From: dean <dluga93(a)gmail.com> It compiles with the macro SADR_OSPF defined. --- configure | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 09c6acf..ad92c7f 100755 --- a/configure +++ b/configure @@ -704,6 +704,7 @@ enable_debug enable_memcheck enable_client enable_ipv6 +enable_sadr enable_pthreads with_suffix with_sysconfig @@ -725,7 +726,6 @@ LIBS CPPFLAGS CPP' - # Initialize some variables set by options. ac_init_help= ac_init_version=false @@ -2317,6 +2317,13 @@ else enable_ipv6=no fi +# Check whether --enable-sadr was given. +if test "${enable_sadr+set}" = set; then : + : +else + enable_sadr=no +fi + # Check whether --enable-pthreads was given. if test "${enable_pthreads+set}" = set; then : enableval=$enable_pthreads; @@ -2401,6 +2408,10 @@ else SUFFIX="" fi +if test "$enable_sadr" = yes ; then + CPPFLAGS="$CPPFLAGS -D SADR_OSPF" +fi + if test "$given_suffix" = yes ; then SUFFIX="$with_suffix" fi -- 2.7.4

4 20

additional attributes of static routes
by Anton Danilov 07 Mar '17

07 Mar '17

Hello folks. I have a strange desire to set the bgp community to static routes to implement the advanced route policy on my border router. I've written this configuration of additional static protocol with only default route to advertise it to other peers: protocol static def_route { route 0.0.0.0/0 reject; import filter { bgp_community.add((135402, 101)); bgp_community.add((135402, 211)); accept; }; } But I don't see any communities on this route in the master RIB: bird> show route all for 0.0.0.0/0 table master 0.0.0.0/0 unreachable [def_route 2017-02-26] ! (200) Type: static unicast univ So my question is simple: can I implement this behaviour (set attributes on static routes) this way? -- Anton.

2 2

Source Address Dependent Routing Patch
by Dean 06 Mar '17

06 Mar '17

Note: I used BIRD 1.6.2 when working on these patches. I don't know if they will work on other versions. The following patches extend the static and OSPFv3 protocol to support Source Address Dependent Routing (SADR), also called Source Specific Routing. This basically means that routing will take into account not only the destination address, but the source address as well. SADR can be enabled by using the option `--enable-sadr` when configuring BIRD. Routes can be added in the static protocol using the `from` keyword, and OSPF can spread the routes through the network. The grammar rules to add a source dependent route in the static protocol are: route <dst_prefix> from <src_prefix> via <ip> or route <dst_prefix> from <src_prefix> via "<interface>" IPv6 subtrees are used to support SADR in the kernel tables. They should be available for Linux kernel versions newer than 3.11. If they are not enabled, the kernel needs to be compiled with the option to enable them. However, as mentioned in net/ipv6/Kconfig in the Linux kernel source, to avoid some unintended behavior of IPv6 subtrees, source constrained routes might need to be put on a routing table separate from the normal routes.

1 0

Re: Source Address Dependent Routing for BIRD
by Dean 06 Mar '17

06 Mar '17

Static routes can be added in the configuration file with a source address constraint. To match an entry in the routing table, you have to match both the source and destination address. The same thing as running the command: ip -6 route add 2001:db9:1::/64 from 2001:db9:2::/64 dev eth0 Meaning we can only send packets to the network 2001:db9:1::/64 if the source address is part of the 2001:db9:2::/64 subnet. Otherwise we get a network unreachable message. One little problem is that it needs the IPV6_SUBTREES kernel option, which is available in linux kernel versions later than 3.11, but it might not be enabled by default. It's being explored in the IETF as a way of handling multihoming for IPv6 without NAT. OSPF can then spread the route through the network. It's also called source-specific routing. There's a paper out there for an implementation in babel. About the patch: it might be a little long, about 60 commits. And I started working last year, on BIRD 1.6.2, so some things might be different. Should I still just send each commit one by one here? On 03/05/2017 08:57 PM, Ondrej Zajicek wrote: > On Sun, Mar 05, 2017 at 07:39:57PM +0100, Dean wrote: >> Hello, >> >> I have been working on implementing SADR (Source Address Dependent Routing) >> in BIRD for the static and OSPFv3 protocols. > Interesting. How it works? > >> What's the procedure for publishing the code? Should I put it on a >> repository online and send you a link? > Generally just send a patch / patch set to the mailing list. >

4 8

Source Address Dependent Routing for BIRD
by Dean 05 Mar '17

05 Mar '17

Hello, I have been working on implementing SADR (Source Address Dependent Routing) in BIRD for the static and OSPFv3 protocols. What's the procedure for publishing the code? Should I put it on a repository online and send you a link? Regards, Dean

2 1

Re: iBGP - Simple static route exchange
by Борис Коваленко 05 Mar '17

05 Mar '17

No, off the list is not special, returning to it. Yes, overlapping is in bird as it import routes from kernel. Just remove routes from kernel and you'll get working config. ⁣С уважением, Борис Коваленко На 5 марта 2017 г., 22:39, в 22:39, Cedric Lemarchand <yipikai7(a)gmail.com> написал:>Hum I am starting to understand that the overlaps is in bird and not in >the OS itself … > >— >Cédric Lemarchand > >> On 5 Mar 2017, at 17:06, Борис Коваленко <b.ju.kovalenko(a)gmail.com> >wrote: >> >> Cedric, Ondrej already answered your question. But I need to know - >why are you trying to redistribute 192.168.1.0/24 ><http://192.168.1.0/24> as it is connected for both hosts? >> >> С уважением, >> Борис Коваленко >> На 5 марта 2017 г., в 17:51, Cedric Lemarchand <yipikai7(a)gmail.com ><mailto:yipikai7@gmail.com>> написал: >> On host1 (10.10.1.1) : >> >> bird> show route all for 192.168.1.0/24 >> 192.168.1.0/24 dev eth1 [direct1 13:44:52] * (240) >> Type: device unicast univ >> via 10.10.1.1 on eth0 [static1 13:44:52] (200) >> Type: static unicast univ >> >> bird> show route all for 192.168.2.0/24 >> Network not in table >> >> bird> show route all where proto = "static1" >> 192.168.1.0/24 via 10.10.1.1 on eth0 [static1 13:44:52] (200) >> Type: static unicast univ >> >> On host2 (10.10.2.1) : >> >> bird> show route all for 192.168.1.0/24 >> Network not in table >> >> bird> show route all for 192.168.2.0/24 >> 192.168.2.0/24 dev eth1 [direct1 13:44:58] * (240) >> Type: device unicast univ >> via 10.10.2.1 on eth0 [static1 13:44:58] (200) >> Type: static unicast univ >> >> bird> show route all where proto = "static1" >> 192.168.2.0/24 via 10.10.2.1 on eth0 [static1 13:44:58] (200) >> Type: static unicast univ >> >> Bird 1.4.5 >> >> Thx ! >> >> — >> Cédric Lemarchand >> >>> On 5 Mar 2017, at 10:39, Борис Коваленко < b.ju.kovalenko(a)gmail.com ><mailto:b.ju.kovalenko@gmail.com>> wrote: >>> >>> Hello! >>> >>> Would You please show the output for 'show route all for >192.168.1.0/24 <http://192.168.1.0/24>' and also 'show route all where >proto = "static1"' >>> >>> Regards, >>> Boris >>> >>> -- >>> С уважением, >>> Борис Коваленко >>> >>

1 0