- Bird-users - Mailing Lists

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

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

05 Mar '17

Hello! Would You please show the output for 'show route all for 192.168.1.0/24' and also 'show route all where proto = "static1"' *Regards,* *Boris* -- С уважением, Борис Коваленко

3 2

OSPF ptmp
by Борис Коваленко 05 Mar '17

05 Mar '17

Hello, Ondrej! There was something wrong with my previous test. So I did new one. Answering your questions: 1) Where interface is broadcast and mode is ptmp - bird does not send any packet (checked with tcpdump) but with "debug all" there are messages "<TRACE> main_ospf: HELLO packet sent via em0" every tick. 2) Yes, if neighbors are configured ptmp works as expected. Without neighbors configured it even does not learn neighbors from incoming packets. 3) I read FreeBSD related post, but 1.6.3 is official port for FreeBSD and it includes patch: +#if (defined __OpenBSD__) || (defined __DragonFly__) || (defined __FreeBSD__ && (__FreeBSD_version >= 1100030)) + /* Different BSDs have different expectations of ip_len endianity */ ip->ip_len = htons(ip->ip_len); #endif 4) There really are no problems with mode == broadcast >* Hello! *> >* Trying to run bird on ethernet interface with type = ptmp. Yes, I know that *>* ethernet is broadcast interface, but there is a good practice to use ptmp *>* on ethernet. I found a strange bug. When type = ptmp, bird sends only one *>* Hello packet and then stops (and even receive?) next packets until I fully *>* restart bird, while other side (cisco or mikrotik) sends packets every 10s *>* (as configured). * Hello To which address it sends the Hello packet? To the first learned neighbor? What you see in logs if you enable 'debug all' for OSPF? What is shown by 'show ospf neighbors'? Note that BIRD expect that you specify neighbors in 'neighbors' section for NBMA or PTMP modes, but it would learn neighbors from received Hello packets. >* There is no problems with type = broadcast * >* FreeBSD - 11-STABLE *>* Bird 1.6.3 * There were people reporting problems in FreeBSD 11 due to API change, but that would affect also broadcast mode: https://www.mail-archive.com/bird-users@network.cz/msg01542.html -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org <http://trubka.network.cz/mailman/listinfo/bird-users>) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." -- С уважением, Борис Коваленко

2 8

iBGP - Simple static route exchange
by Cedric Lemarchand 05 Mar '17

05 Mar '17

Hello, I am trying to distribute 2 static routes between 2 hosts, not directly connected, and I am having hard time to make it works … host1 10.10.1.1 (eth0) own subnet 192.168.1.0/24 ( 192.168.1.1 on eth1) host2 10.10.2.1 (eth0) own subnet 192.168.2.0/24 ( 192.168.2.1 on eth1) I get the following error : host1 bird: bgp1 < rejected by protocol 192.168.2.0/24 unreachable host1 bird: bgp1 > updated [best] 192.168.2.0/24 unreachable Bellow the bird.conf of both hosts : log syslog all; router id 10.10.1.1; debug protocols all; protocol direct { interface "*"; # Restrict network interfaces it works with } protocol kernel { learn; # Learn all alien routes from the kernel #persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds import all; # Default is import all export all; # Default is export none } protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol static { debug all; route 192.168.1.0/24 via 10.10.2.254; export all; } protocol bgp { multihop; #gateway recursive; import all; export all; #export where proto = "static1"; local as 3000; neighbor 10.10.2.1 as 3000; #next hop self; } — log syslog all; router id 10.10.2.1; protocol direct { interface "*"; # Restrict network interfaces it works with } protocol kernel { learn; # Learn all alien routes from the kernel #persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds import all; # Default is import all export all; # Default is export none } protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol static { route 192.168.2.0/24 via 10.10.1.254; export all; } protocol bgp { multihop; #gateway recursive; import all; #export where proto = "static1"; export all; local as 3000; neighbor 10.10.1.1 as 3000; #next hop self; } — Cédric Lemarchand

2 7