- Bird-users - Mailing Lists

[PATCH 2/3] babel: Implement IPv6 prefix compression on outgoing updates
by Toke Høiland-Jørgensen 05 Jun '17

05 Jun '17

Previously, the Babel protocol would never use prefix compression on outgoing updates (but would parse it on incoming ones). This adds compression of IPv6 addresses of outgoing updates. The compression only works to the extent that the FIB is walked in lexicographic order; i.e. a prefix is only compressed if it shares bytes with the previous prefix in the same packet. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/packets.c | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/proto/babel/packets.c b/proto/babel/packets.c index 0f70898e..da7d8a50 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -133,6 +133,7 @@ struct babel_write_state { u8 router_id_seen; u8 next_hop_v4_seen; u8 next_hop_v6_seen; + net_addr def_ip6_prefix; /* Previous IPv6 prefix (for compression) */ }; @@ -682,9 +683,32 @@ babel_write_update(struct babel_tlv *hdr, union babel_msg *m, } else { + u8 omit = ip6_common_octets(net6_prefix(&state->def_ip6_prefix), + net6_prefix(&msg->net)); + DBG("%d bytes common between %I and %I\n", omit, + net6_prefix(&state->def_ip6_prefix), net6_prefix(&msg->net)); + tlv->ae = BABEL_AE_IP6; tlv->plen = net6_pxlen(&msg->net); - put_ip6_px(tlv->addr, &msg->net); + if (0 < omit) + { + u8 buf[16] = {}; + omit = MIN(omit, + MIN(tlv->plen, net6_pxlen(&state->def_ip6_prefix)) / 8); + + put_ip6_px(buf, &msg->net); + memcpy(tlv->addr, buf+omit, tlv->plen - omit); + + tlv->omitted = omit; + tlv->length -= omit; + len -= omit; + } + else + { + put_ip6_px(tlv->addr, &msg->net); + tlv->flags |= BABEL_FLAG_DEF_PREFIX; + state->def_ip6_prefix = msg->net; + } } put_time16(&tlv->interval, msg->interval); -- 2.13.0

1 0

Filter based on condition or watchdog
by Войнович Андрей Александрович 02 Jun '17

02 Jun '17

Hi all! Does BIRD allow to write a filter, where I can define a condition when it should import/export some route(s) and when it should not? To clarify my question, example: I want to check whether some process (lets say apache) is running and the server is listening TCP port 80, so if these conditions are true, BIRD should export some route to OSPF, if false - should not.

4 3

bird redhat repo missing rpms for 1.6.3
by Ruben Herold 30 May '17

30 May '17

hi, the repo for bird redhat rpms is still on 1.6.2. Ist it unmaintained? Ruben -- Ruben Herold ruben(a)insecure.pw

6 10

Re: bird redhat repo missing rpms for 1.6.3
by Ruben Kerkhof 30 May '17

30 May '17

On Tue, May 30, 2017 at 2:55 PM, Ondrej Zajicek <santiago(a)crfreenet.org> wrote: > Perhaps it would be possible to install also newer libtinfo/libncurses from > Fedora? That shouldn't be needed. I see indeed that the rpm from the bird.network.cz repo for redhat depends on a newer libncurses: rpm -qp --requires bird-1.6.3-1.x86_64.rpm | grep -E 'lib(ncurses|tinfo)' warning: bird-1.6.3-1.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 0baf6303: NOKEY libncurses.so.6()(64bit) libtinfo.so.6()(64bit) Ondrej, any chance you could just rebuild those, either on a CentOS 7 host or from a Fedora host with mock? Kind regards, Ruben

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 Tue, May 30, 2017 at 02:04:00PM +0200, Toke Høiland-Jørgensen wrote: >> Ondrej Zajicek <santiago(a)crfreenet.org> writes: >> >> > On Tue, May 30, 2017 at 01:48:10PM +0200, Ondrej Zajicek wrote: >> >> 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). >> > >> > Well i checked that one more time and it is possible that channel is added >> > after the protocol is up. So you should check that channel is non-NULL and >> > in state CS_UP, which is something slightly different than what is checked >> > by channel_is_active(). >> >> Right. In that case, is the overhead of always initialising both FIBs >> acceptable? If it is, I can just use the presence of the channel in all >> checks for whether an address family is active or not... > > I see no reason not to do conditional initialization of FIBs in > babel_start(). If a channel appears later, it will stay in CS_DOWN until > protocol restarts (and FIBs are reinitialized), so you could still just > use the presence and CS_UP state of channel and do not need to check for > FIB. Except that the way I implemented things, I just select select the right fib based on address family; so I'll have to litter checks through all of that code just to save a few dozens of bytes of memory... Is that really worth it? -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 Tue, May 30, 2017 at 01:48:10PM +0200, Ondrej Zajicek wrote: >> 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). > > Well i checked that one more time and it is possible that channel is added > after the protocol is up. So you should check that channel is non-NULL and > in state CS_UP, which is something slightly different than what is checked > by channel_is_active(). Right. In that case, is the overhead of always initialising both FIBs acceptable? If it is, I can just use the presence of the channel in all checks for whether an address family is active or not... -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 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