- Bird-users - Mailing Lists

Re: [PATCH 0/3] babel: Add compression and support for subtlvs
by Toke Høiland-Jørgensen 06 Jun '17

06 Jun '17

Ondrej Zajicek <santiago(a)crfreenet.org> writes: > On Mon, Jun 05, 2017 at 11:49:51PM +0200, Toke Høiland-Jørgensen wrote: >> This patch series adds compression of outgoing IPv6 prefixes to the >> Babel protocol, and also adds support to the parser for parsing subtlvs >> as per RFC6126 bis (see >> https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-02#section-4.4) > > Hi > > The subtlv parser looks OK. W.r.t. prefix compression i would prefer if > it would be done in the same manner as in the other direction (parsing), > i.e. having u8 def_ip6_prefix[16] in network order in babel_write_state > and using a memcmp()-like function that returns first differing byte > instead of using ip6_common_octets(). > > + omit = MIN(omit, > + MIN(tlv->plen, net6_pxlen(&state->def_ip6_prefix)) / 8); > > Note that MIN() is a macro that expands its arguments two times, so it is > not a good idea to nest them. OK, will fix and resend. Should I just resend that one patch, or would you prefer I resend all three (including the dualstack patch) in a common series? -Toke

2 1

[PATCH 1/3] lib: Add ip6_common_octets function
by Toke Høiland-Jørgensen 06 Jun '17

06 Jun '17

This function computes the number of common octets between two IPv6 addresses, for use in Babel prefix compression. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- lib/ip.c | 14 ++++++++++++++ lib/ip.h | 1 + 2 files changed, 15 insertions(+) diff --git a/lib/ip.c b/lib/ip.c index 9497248c..af81704b 100644 --- a/lib/ip.c +++ b/lib/ip.c @@ -33,6 +33,20 @@ ip6_compare(ip6_addr a, ip6_addr b) return 0; } +int +ip6_common_octets(ip6_addr a, ip6_addr b) +{ + int i, j, common = 0; + for (i=0; i<4; i++) + for (j=3; j>=0; j--) + if ((0xff & (a.addr[i] >> (8*j))) == (0xff & (b.addr[i] >> (8*j)))) + common++; + else + return common; + + return common; +} + ip6_addr ip6_mkmask(uint n) { diff --git a/lib/ip.h b/lib/ip.h index 5cfce1f1..b4909984 100644 --- a/lib/ip.h +++ b/lib/ip.h @@ -205,6 +205,7 @@ static inline int ip4_compare(ip4_addr a, ip4_addr b) { return (_I(a) > _I(b)) - (_I(a) < _I(b)); } int ip6_compare(ip6_addr a, ip6_addr b); +int ip6_common_octets(ip6_addr a, ip6_addr b); #define ipa_hash(x) ip6_hash(x) #define ipa_compare(x,y) ip6_compare(x,y) -- 2.13.0

3 3

Re: Increasing the granularity of internal timers in Bird?
by Toke Høiland-Jørgensen 06 Jun '17

06 Jun '17

Ondrej Zajicek <santiago(a)crfreenet.org> writes: > On Mon, Jun 05, 2017 at 06:53:02PM +0200, Toke Høiland-Jørgensen wrote: >> Hey >> >> I have been looking at changing the internal timers in Bird to operate >> at millisecond granularity instead of the current one-second steps. I >> have two motivations for this: > > Hi > > Check this: > > https://gitlab.labs.nic.cz/labs/bird/tree/timers > > It is a recent branch that replaces current timers with microsecond > timers (already used in BFD). You could just swap bird_clock_t, timer > and tm_*() functions with btime, timer2 and tm2_*() functions (with > updated arguments). Also time constants in config file should be > specified by expr_us instead of expr. Ah, awesome! I'll look into that, thanks :) Is this going to be merged for 2.0? -Toke

2 1

[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