May 2017 - Bird-users - Mailing Lists

Re: [PATCH] babel: Add support for dual-stack v4/v6 operation
by Toke Høiland-Jørgensen 30 May '17

30 May '17

Ondrej Zajicek <santiago(a)crfreenet.org> writes: > On Tue, May 30, 2017 at 01:37:56PM +0200, Toke Høiland-Jørgensen wrote: >> > Also channel_is_active() is called but channel may not even exist? >> >> Ah, proto_configure_channel can leave the channel var entirely unset? > > Yes, it could add/remove/reconfigure the channel, based on whether there > is or is not the configuration and the old channel. > >> was assuming it was just leaving it in place but inactive. Can I just >> check for NULL, then? > > Yes, that should be enough, as all channels goes up together with the > protocol and channel cannot be deconfigured when up (protocol will be > restarted in that case). Right, so a new channel can appear on reconfigure, but existing ones cannot go away? -Toke

2 1

Re: [PATCH] babel: Add support for dual-stack v4/v6 operation
by Toke Høiland-Jørgensen 30 May '17

30 May '17

Ondrej Zajicek <santiago(a)crfreenet.org> writes: > On Mon, May 29, 2017 at 10:24:57PM +0200, Toke Høiland-Jørgensen wrote: >> This adds support for dual-stack v4/v6 operation to the Babel protocol. Routing >> messages will be exchanged over IPv6, but IPv4 routes can be carried in the >> messages being exchanged. This matches how the reference Babel >> implementation (babeld) works. > > Hi > > Thanks for the patch. I have one major remark - If i undestand it > correctly, both IPv4 and IPv6 FIBs are always created and used, but > IPv4 and IPv6 channels may or may not be configured and created. > Although when a channel is not configured, Babel would not propagate > routes (as they have to be imported to nest and back exported to Babel > to be propagated outside), it is still strange to keep received > routes. Yeah, that's true I guess. I'll fix that. > Also channel_is_active() is called but channel may not even exist? Ah, proto_configure_channel can leave the channel var entirely unset? I was assuming it was just leaving it in place but inactive. Can I just check for NULL, then? -Toke

2 2

Re: [PATCH 2/4] Static protocol supports SADR
by Dean 27 May '17

27 May '17

On 05/24/2017 03:53 PM, Ondrej Zajicek wrote: > On Tue, May 23, 2017 at 08:03:38PM +0200, Dean wrote: >>>> And routes from other protocols with normal IPv6 channels should be >>>> transformed to SADR routes with a ::/0 source? >>> That is a tricky issue. I see four possibilities: >>> >>> 2) Soma hack to Pipe protocol that allows to bridge IP6 table and >>> SADR_IP6 table. I.e., SADR-aware protocols connected to SADR_IP6 >>> table and other protocol to regular IP6 table, both tables connected >>> by pipe that translates IP6 routes to SADR routes with a ::/0 source >>> and vice versa (ignoring SADR routes with other source). >> In #2 which table would bird table would be used as the main kernel table? > Usually the SADR table. Otherwise, no SADR route could be pushed to main > kernel table. > > Something like: > > ipv6 table tab1; > ipv6 sadr table tab2: > > protocol ospf v3 { > ipv6 sadr { > table tab2; > } > } > > protocol rip { > ipv6 { > table tab1; > } > } > > protocol kernel { > ipv6 sadr { > table tab2; > export all; > } > } > > protocol pipe { > table tab1; > peer table tab2; > export all; > import all; > } > > For clarity, the example uses explicit tables in channel definitions. > > >> What I'm worried about is that in a network that has both SADR and non-SADR >> routers, there can be routing loops if not explicitly avoided (my last patch >> tries to do this in OSPF). Keeping both SADR and non-SADR tables might cause >> a problem with this, the router might advertise to OSPF that it has SADR >> capability, but it would cause routing loops anyway when using the non-SADR >> routing table. > Well, it is potentially problematic issue, but IMHO it is more an > operational issue to have reasonable configuration and network design. > The alternatives #1-#4 are more or less equivalent w.r.t. that. > > > Also, we discussed that internally and agreed that #2 is a way to go. It > avoids pitfalls of #1 and allows additional configuration. As sometimes > it makes sense that non-SADR routes are translated to SADR routes with > configurable src/from other than ::/0. E.g.: > > I have a gateway router with internal OSPF SADR network and two uplinks > from two ISPs that propagate a default route by RIP. Each uplink is valid > for associated prefix range assigned by that ISP, but RIP itself does not > know about that. So configuration would be like main SADR table connected > to OSPF and Kernel, and two non-SADR tables connected to appropriate RIPs, > and pipes between non-SADR tables and the SADR table, the pipes would be > configured to assign appropriate src/from to the routes propagated from > non-SADR to SADR table based on ISP range. > > Now i have a pretty clear idea how to implement the pipe hack anyway, so > perhaps the best way to continue would be that you just ignore the issue > and implement just interaction between SADR-aware protocols, while i will > add the pipe hack later. > Ok, sounds good.

1 0

Re: [PATCH 2/4] Static protocol supports SADR
by Toke Høiland-Jørgensen 24 May '17

24 May '17

Ondrej Zajicek <santiago(a)crfreenet.org> writes: > On Tue, May 23, 2017 at 10:27:30PM +0200, Toke Høiland-Jørgensen wrote: >> Ondrej Zajicek <santiago(a)crfreenet.org> writes: >> >> >> And routes from other protocols with normal IPv6 channels should be >> >> transformed to SADR routes with a ::/0 source? >> > >> > That is a tricky issue. I see four possibilities: >> > >> > 1) Some hack that allows connecting IP6 channels to SADR_IP6 tables, >> > so unmodified protocols could add SADR routes with a ::/0 source. >> >> Semantically, a SADR-aware route with source ::/0 is equivalent to a >> non-SADR aware route. So what about a variant of this that makes the >> SADR information be always available in the routing table, and just >> filters out routes with non-zero source prefix for protocols that are >> not SADR-aware? >> >> I'm not sure if it's even necessary with a separate address type for >> SADR in this case? > > Having separate SADR address type and routing table type is mostly an > implementation issue. We do not want to have unused src field in > net_addr_ip6 to make it always two times larger for a border case of > SADR users. Hmm, fair enough I suppose ;) > In the far future, perhaps we change SADR source field to be an > optional route attribute. That would be elegant and allow to have > optional SADR routes in regular routing table (like in Linux kernel). > But it is incompatible with many BIRD design decisions w.r.t. how > routes, routing table and channels interact. Currently, we use > net_addr as a primary key, so if we want to have multiple 'best' > routes with the same dst (and different src), both dst+src have to be > in net_addr. Yeah, this makes sense, longer term. And is, incidentally, pretty close to how the Babel working group is converging on encoding SADRs (as an attribute (sub-TLV) of routes). -Toke

1 0

Re: [PATCH 2/4] Static protocol supports SADR
by Dean 24 May '17

24 May '17

On 05/23/2017 07:29 PM, Ondrej Zajicek wrote: > On Tue, May 23, 2017 at 03:27:43PM +0200, Dean wrote: >> On 05/23/2017 03:04 PM, Ondrej Zajicek wrote: >>> My opinion is that behavior of OSPF and Kernel protocols should be >>> consistent. If OSPFv3 uses one channel and one table for SADR and >>> non-SADR routes, then Kernel should do the same and there is no >>> reason to connect two Kernel protocols to one kernel table. >> So if I understand correctly, you are saying that if the static or OSPF >> protocols use SADR, the kernel protocol should be required to use SADR? > Not exactly, protocol instances are independent and may be connected to > unrelated tables or just configured differently. > > I am saying that both OSPF and Kernel protocols should be designed and > implemented in consistent way w.r.t. mixing SADR and non-SADR in one > routing domain. > > If OSPF is designed to mix SADR and non-SADR routes in SADR_IP6 channel > connected to SADR_IP6 table, so should do Kernel protocol when attached > to SADR_IP6 table. > > >> And routes from other protocols with normal IPv6 channels should be >> transformed to SADR routes with a ::/0 source? > That is a tricky issue. I see four possibilities: > > 1) Some hack that allows connecting IP6 channels to SADR_IP6 tables, > so unmodified protocols could add SADR routes with a ::/0 source. > > 2) Soma hack to Pipe protocol that allows to bridge IP6 table and > SADR_IP6 table. I.e., SADR-aware protocols connected to SADR_IP6 > table and other protocol to regular IP6 table, both tables connected > by pipe that translates IP6 routes to SADR routes with a ::/0 source > and vice versa (ignoring SADR routes with other source). > > 3) Modify other protocols to support SADR_IP6 (with ::/0 source). > > 4) Ignore the issue (use only SADR-aware protocols). > > I don't like variant #3. I am not sure how acceptable is variant #4, but > it may be OK - seems to me that mixing SADR-aware and SADR-unaware > routing protocols rarely makes sense and in cases it does (disjunct IP > ranges), it can be done by using two real kernel tables. Variant #2 is > probably more clean than variant #1 from implementation POW, but probably > more confusing from user POW. What is your opinion? > > In #2 which table would bird table would be used as the main kernel table? What I'm worried about is that in a network that has both SADR and non-SADR routers, there can be routing loops if not explicitly avoided (my last patch tries to do this in OSPF). Keeping both SADR and non-SADR tables might cause a problem with this, the router might advertise to OSPF that it has SADR capability, but it would cause routing loops anyway when using the non-SADR routing table.

2 1

Re: [PATCH 2/4] Static protocol supports SADR
by Toke Høiland-Jørgensen 24 May '17

24 May '17

Ondrej Zajicek <santiago(a)crfreenet.org> writes: >> And routes from other protocols with normal IPv6 channels should be >> transformed to SADR routes with a ::/0 source? > > That is a tricky issue. I see four possibilities: > > 1) Some hack that allows connecting IP6 channels to SADR_IP6 tables, > so unmodified protocols could add SADR routes with a ::/0 source. Semantically, a SADR-aware route with source ::/0 is equivalent to a non-SADR aware route. So what about a variant of this that makes the SADR information be always available in the routing table, and just filters out routes with non-zero source prefix for protocols that are not SADR-aware? I'm not sure if it's even necessary with a separate address type for SADR in this case? -Toke

2 1

Re: [PATCH 1/4] Core changes to support SADR
by Dean 24 May '17

24 May '17

On 05/22/2017 03:30 PM, Ondrej Zajicek wrote: > >> @@ -231,6 +232,20 @@ fib_find(struct fib *f, const net_addr *a) >> case NET_ROA6: return FIB_FIND(f, a, roa6); >> case NET_FLOW4: return FIB_FIND(f, a, flow4); >> case NET_FLOW6: return FIB_FIND(f, a, flow6); >> + case NET_SADR_IP6: >> + { >> + if (a->length != sizeof(net_addr_sadr_ip6)) >> + { >> + // dst only search >> + net_addr_ip6 a0; >> + net_copy((net_addr *)&a0, a); >> + a0.length = sizeof(net_addr_sadr_ip6); >> + >> + return FIB_FIND(f, &a0, sadr_dst); >> + } >> + else >> + return FIB_FIND(f, a, sadr_ip6); >> + } > No. Generic fib_find() should implement exact-match search with matching > net_addr type. If you need/want partial match, it should be done as a > separate function. BTW, where do you need that? I use it in net_route_sadr_ip6 below, the call to net_route_ip6 does destination only search. I wouldn't want to search all source prefix lengths for a specific dst length if there is no entry for that dst length at all. > Perhaps we should add some generic function partial-match IP-based search > for network types that support it (e.g., ROA, SADR). But it would need > a different interface, so caller could enumerate all valid matches. This seems like a good idea. > >> +static inline void * >> +net_route_sadr_ip6(rtable *t, net_addr_sadr_ip6 *n) >> +{ >> + net *r; >> + >> + net_addr_ip6 dst = NET_ADDR_IP6(n->dst_prefix, n->dst_pxlen); >> + dst.type = NET_SADR_IP6; >> + >> + // search for matching dst >> + while (r = net_route_ip6(t, &dst)) >> + { >> + // found a matching dst, start search for entries that match both prefixes >> + net_addr_sadr_ip6 full_addr = >> + NET_ADDR_SADR_IP6(dst.prefix, dst.pxlen, n->src_prefix, n->src_pxlen); >> + >> + while (r = net_find_valid(t, (net_addr *) &full_addr), (!r) && (full_addr.src_pxlen > 0)) >> + { >> + full_addr.src_pxlen--; >> + ip6_clrbit(&full_addr.src_prefix, full_addr.src_pxlen); >> + } >> + >> + if (r) >> + return r; >> + dst.pxlen--; > You should set dst.pxlen based on r found by net_route_ip6(), > to avoid repeated iteration over the same prefix lengths that > did not match in the inner cycle. That would be set in the call to net_route_ip6.

3 3

Re: [PATCH 2/4] Static protocol supports SADR
by Dean 23 May '17

23 May '17

On 05/23/2017 03:04 PM, Ondrej Zajicek wrote: > My opinion is that behavior of OSPF and Kernel protocols should be > consistent. If OSPFv3 uses one channel and one table for SADR and > non-SADR routes, then Kernel should do the same and there is no > reason to connect two Kernel protocols to one kernel table. So if I understand correctly, you are saying that if the static or OSPF protocols use SADR, the kernel protocol should be required to use SADR? And routes from other protocols with normal IPv6 channels should be transformed to SADR routes with a ::/0 source?

2 1

PopRouting (and NetJSON) for OSPF
by Gabriel 23 May '17

23 May '17

Hello, I'm trying to implement NetJSON [1] in Bird to expose the OSPF topology using the NetworkGraph[2] specification of NetJSON. I started tweaking the ospf_sh_state to print the topology of my test network. However, using the cli_msg() macro my json is printed in birdc with some ???< > symbols on each line. I've tryied with several msg_code (0,-1016, -1017) but it doesn't work. Is there something easy I can do to print the json in the CLI? Otherwise I'll have to modify the cli code to add such a function. Moreover, I'm implementing NetJSON in order to support PopRouting [3] in OSPF. I'm doing it for my GSOC project. [4] PopRouting is an algorithm that calculate the Centrality of each node in a network (using the topology of the net) and then tune the Hello and TC timers of the routing protocol to improove the convergence time. I've already implemented it for OLSR2[5] that is widely used in mesh network. Since AWMN in Greece is using OSPF we decided to implement it also for OSPF. Apart form the Wireless Community Network world, where the network are complex and dynamic do you think such an algorithm could be useful for other networks? We don't have topologies from ISP or other big networks to judge. Finally I'd need a way to set the interfaces' hello timer of OSPF remotely. I've seen that using the cli is possible to set the whole configuration of a node, but not a single parameter. How could I accomplish that? Cheers, Gabriel [1]: http://netjson.org/ [2]: http://netjson.org/docs/what.html#networkgraph [3]: https://ans.disi.unitn.it/users/maccari/assets/files/bibliography/INFOCOM20… [4]: https://summerofcode.withgoogle.com/projects/#4969019225407488 [5]: https://github.com/AdvancedNetworkingSystems/poprouting/

1 0

OSPF?
by Jason Kopacko 23 May '17

23 May '17

Is anyone using BIRD and peered with an OSPF device? If so, can you send me the sanitized output of this command? [ sudo birdc show protocols all ] I am building a web based interface to our current deployment and we are do not use OSPF, we are using BGP. I wanted to build my parsing so that it included both BGP and OSPF outputs. Sent from my Verizon Wireless 4G LTE Droid Turbo 2.

2 5