> Just working around [...] babeld's non-atomic route replacement interacting
> badly with BIRD's proto/radv.
I guess we could revive atomic updates in babeld, perhaps the buggy
kernels it didn't work with are no longer relevant.
> *neighbour table*. I think the crux of the issue I was seeing is
> I've just come across a reason I'd want to run babel with both bird and
> babeld on the same node and have them become neighbours.
I hope you know what you're doing.
The simplest solution would be to run each daemon in a different container.
If you don't want to use containers, you'll want to
> I don't think it's a violation of the Babel protocol to use IPv6 next hops
> when
> an IPv4 address is present.
Yes, it's legal, but discouraged. Please see RFC 9229 Section 2.1:
If the outgoing interface has been assigned an IPv4 address, then, in
the interest of maximising
> As an alternative suggestion, I have since evaluated babel which mostly
> suits my purposes (except for some features not yet implemented in bird,
> like strict bind)
Could you please explain what's the feature you're missing?
Thanks,
-- Juliusz
> Is tying source address filtering to the routing table the right thing to do
> here? It seems to me that it would cause issues similar to those we see more
> generally with Unicast Reverse Path Filtering
Issues are caused by the kernel performing filtering that the routing
protocol is not aware
>> And babeld the reference implementation also allows enabling link quality
>> estimation and the RTT extension at the same time, matching the current
>> behavior of bird.
Exactly right.
> Considering that ETX estimates number of retransmissions, then for
> algorithm that takes into account
> default type tunnel rtt-min 1 rtt-max 1001 max-rtt-penalty 1000
> enable-timestamps true
> ```
> It causes the RTT to be equal to the latency to the other node.
More precisely, it causes the cost to be equal to the RTT.
The recommended default values are much more conservative:
rtt-min 10
Daniel, Kyle,
I've read the whole discussion, and I'm still not clear what advantages
the proposed route attribute has over having one interface per peer. Is
it because interfaces are expensive in the Linux kernel? Or is there some
other reason why it is better to run all WG tunnels over a
> + link quality
> + If set, link quality estimation is performed on this interface.
There are multiple algorithms for estimating link quality, and the one
currently implemented by BIRD is ETX. Hence, I feel that this should not
be a mere switch, but a selector with possible values
> You basically shouldn't do it. BIRD does something like last-resort pointer
> comparison and we should probably even add a warning if somebody misconfigures
> in this way.
Why not use the protocol's default preference as a last-resort tie-breaker?
It's probably less code than the warning you
> The field sin6_scope_id should be used only for link-local addresses (to
> define their scope), not as a way to route multicasts.
>
> (Hmm, ff02::/16 is defined as link-local multicast address, so perhaps
> setting sin6_scope_id makes sense.)
FWIW, babeld uses the sin6_scope_id when sending
> I would approach the stability problem from an electronics/signal
> processing/control theory background.
I have no signal processing background whatsoever; to my eyes, signal
processing is a fairly advanced for of magic. (My background is in logic
and programming languages.)
> Frankly I
Hi Daniel,
> In order to prevent RTT based routing from causing persistent traffic
> oscillations we delay core rte announcement of each prefix by a
> configurable but metric invariant amount of time.
Could you please explain how that works? How does it interact with
cost smoothing and route
>> (There's also the PMTUD problem described in RFC 9229 Section 3.)
> Juliusz, do you, or any one else, have info on:
> How does ${vendor} behave when reverse path filters are enabled?
I was under the impression that some kinds of ICMP pakets are not subject
to RPF. See RFC 4890 Section 4.3.1.
> I don't really have a particular use case in mind for exposing the
> metric, as indicated by my comment above. It just occurred to me as
> something that *might* be useful for someone :)
I certainly emphatise with your instinct to export as many useful knobs as
possible. However, just like
> My thinking was that filters may want to do something like:
>
> if (metric == smoothed_metric)
> metric += 100; /* route is stable, we can apply our policy */
>
> but I honestly don't know if that's useful for anything in reality :)
I'm a little conflicted on this. On the one hand, it's
>> Agreed. https://www.rfc-editor.org/how-to-report/
> Done :)
Perfect, thanks a lot.
> That's a bug in the new RFC text then ;)
Agreed. https://www.rfc-editor.org/how-to-report/
-- Juliusz
> I don't think RFC8966 is really framed in bird's "multi protocol" mindset
See the beginning of Section 3.7, which describes how a route
redistributed from another protocol has router-id set to the local
router's id. Babel updates for the same prefix are processed as usual,
with the routes
Hi,
Discussions related to Babel are currently distributed across three
distrinct mailing-lists (babel-users@alioth, babel@ietf, bird-users), and
I'm a little concerned that those of you who are subscribed to just one of
them are missing out on the whole picture. Since I'm on strike today, and
> btw, there is one question that i noticed. If an Update is ignored for
> semantic reasons (e.g. update with valid metric, but missing next hop or
> router id), should it update last prefix with P-flag?
Such a packet would be incorrect. What to do in presence of an incorrect
packet is left to
> I just though that the default value for the option is enabled, but
> perhaps it should be enabled only if such routes are supported by
> platform code (i.e. enabled on Linux, but disabled on BSD, as we do
> not support such routes on BSD).
IMHO, it should not be possible to enable v4-via-v6
> 1) Changed the name of the option to 'extended next hop', for consistency
> with BGP (and in the future also with other protocols). As the option is
> enabled by default, the name likely does not matter that much.
I rather like v4-via-v6, which succintly and clearly states what it is
about.
> I've just read this draft and I must say that it looks nice, simple and
> clean.
Thanks for the kind words. I've read your comments, and agree on all counts.
-- Juliusz
>> Thanks for the answer! I hope it's not too annoying when I ask, however
>> I can not find any information about this online: Are there also plans
>> to implement the Babel RTT extension?
> The core team doesn't have this in current plans. As there is no RFC for
> this yet, it's under my radar.
>>> We do actually update the garbage collection time regardless of the
>>> route metric in the regular update function (but not when sending an
>>> explicit retraction). I think that's OK, though?
>> Does that mean that a retracted route never expires?
> Hmm, no, this is the garbage collection
> This has been clarified in RFC8966 as: "Note that the feasibility
> distance is not updated and the garbage-collection timer is not reset
> when a retraction (an update with infinite metric) is sent."
>
> The feasibility distance is only updated if the metric is lower, which
> is never true for
> Introduce a strict-inequality version of the modulo-comparison for this
> purpose.
Thanks.
I'm a little worried about the code around line 1017:
struct babel_source *s = babel_get_source(p, e, e->router_id);
s->expires = current_time() + BABEL_GARBAGE_INTERVAL;
if
> The problematic bit is, I think, 's' in babel_handle_update can be NULL
> because nothing ensures the babel_source for a particular neighbour
> actually exists here:
s will be passed to babel_is_feasible, which returns true if s is null.
Later on, s is only used if feasible is false, in which
>> The issue has been described in draft-ietf-babel-mac-relaxed, which is
>> currently pending RFC publication. That also describes two mitigation
>> mechanisms: Keeping separate PC counters for unicast and multicast, and
>> using a reorder window for PC values. This patch implements the former as
As Toke said, OSPFv3 is a fine protocol. OSPFv2 was already pretty good,
and the designers of OSPFv3 fixed the two significant flaws in OSPFv2.
But of course I'd be delighted if you could experiment with Babel.
>> routes). I'm simplifying wildly here, and I'm sure Juliusz will jump in
>> and
> But this filter applies in the antenna that advertise the route.
> 10.20.2.2 and 10.20.2.36 advertise 10.0.0.0/8
>
> 10.20.2.162 and 10.20.3.1 links with 10.20.2.2 and i want that 10.20.2.162
> uses
> 10.20.2.36 (not direct link) for 10.0.0.0/8 not 10.20.2.2 and 10.20.3.1 uses
> 10.20.2.2
For
> We have a series of wireless antennas deployed in mesh with the babel
> protocol using bird.
>Two of those antennas advertise the route 10.0.0.0/8.
>The rest of the antennas choose one of the two outputs depending on the
> babel protocol.
>How can I force it to go out through one
>> BTW, are third-party next hops allowed in Babel? I checked RFC 6126
>> but found nothing.
They're not forbidden, but I don't think they are useful. There's no
reason I can see why they wouldn't work, but I haven't actually tested.
> Not sure how babeld will react to non-LL next hop
> Using random router-id seems like a good idea. Perhaps even an TLV that
> describes 'nominal' configured router-id, so regular router-id could be
> random, but routes could still contain configured router-id for admin
> purposes. Unfortunately, Babel does not have support for something like
>
> Well, section 2.8 (and in more detail section 3.5.5) specifies that we
> should keep unreachable entries, but IMHO it does not specify that the
> old route is considered selected/installed for a purpose of conditions in
> section 3.5.4. The unreachable entry after retraction could be undestood
>
What you describe is perfectly correct.
> I have two questions w.r.t. this sequence of events:
> 1) How is router restart and seqnos supposed to be handled without
> waiting for route timeout?
It's worse than that, actually -- it's not the route timeout, it's the
source GC time.
The issue is a
> If this is not the case, I think the RFC needs to specify what, exactly,
> is meant by a "wildcard address". I've always thought of ::/0 as the
> wildcard address; and doesn't "default route" also mean "wildcard
> route"?
Wow, no.
The main purpose of a routing protocol is to carry prefixes.
> Also now it seems to me that even the current code is not valid as it
> implicitly assumes that the prefix length is 128 with this flag.
> As the spec says 'low-order 8 octets of the advertised prefix' then
> if one advertise 2001:DB8:1020:3040:5060:7080::/96, then low-order
> 8 octets of this
> So I was referring to the text stating "the current router-id and seqno
> is not used" - does that refer to all retractions or just wildcard ones?
RFC 6126 doesn't say. It should be all retractions.
> Well, I've always thought about 0x40 as specifying that the router ID be
> the 64 bits from
> Okay, actually trying to put this into code: Is the intention here that
> a null-router ID update is acceptable only on *wildcard* retractions or
> on *all* retractions?
In RFC 6126, there's nothing special about a null router-ID: it's just
a router ID.
However, for AEs 0 and 1, the address is
> Ah, I see. But surely, having an update with AE 0 and the flag set would
> not be out of spec either, as long as router ID 0 is not disallowed?
That's what I thought too, but Markus disagreed.
-- Juliusz
> Well I would certainly argue that it was allowed; but apparently easy to
> miss.
Ok. Then please consider it as allowed, as all current implementation
parse it fine.
> Why is babeld setting the 0x40 flag on those updates, though?
It was supposed to clear the router-id. Recent versions no
> But those updates seem to set flag 0x40, so that's not "without a router
> ID" is it?
Yeah, it was meant to clear the router-id.
>> The plan is to explicitly allow such retractions in RFC 6126-bis, but
>> they are clearly not allowed by RFC 6126.
> Hmm, the RFC says this (which I seem to have
>> The packet format encodes intervals in centiseconds, so it would make
>> sense to allow any fractional Hello interval down to 0.01 seconds.
> since the internal Bird timers run at a granularity of seconds only
> there's not much point in having the ability to configure smaller
> values.
Nice.
> + tx length ;
Please don't make this configurable, it only breaks interoperability.
Section 4 of RFC 6126 is very clear about the maximum size of a Babel
packet:
It MUST NOT send packets larger than the attached interface's MTU
(adjusted for lower-layer headers) or 512
46 matches
Mail list logo
