Juliusz Chroboczek writes:
>> Well, that is quite useful in any case.
>
> It's very useful, but it creates extra state, extra timers, and might
> timeout over wireless (EIGRP style). So I'm not really sure how I feel
> about it.
Sure, it adds a bit of temporary state; but if it
>>> My thinking on this is that you only need the host routes when a client
>>> actually roams.
>> This is only going to work if you either use no hold time, or implement
>> the optional algorithm in Section 3.1 of rfc6126bis.
> I'm assuming you mean the ACKed retraction algorithm in Section
Juliusz Chroboczek writes:
>> My thinking on this is that you only need the host routes when a client
>> actually roams.
>
> This is only going to work if you either use no hold time, or implement
> the optional algorithm in Section 3.1 of rfc6126bis.
I'm assuming you mean the
On Fri, Mar 9, 2018 at 3:29 PM, Christof Schulze
wrote:
>> I start running into trouble with 1000+ routes using 1Mbit mcast.
>> Sooner if I seriously
>> slam the network with flent or something else that abuses mcast like mdns.
>> YMMV.
>
> So what is the culprit here?
Christof Schulze writes:
> There are approaches to reduce the amount of routes per client
> including using nat66 on each node. You certainly are making it sound
> like there should be put some thought into reducing the amount of
> routes. This will be the next step
I start running into trouble with 1000+ routes using 1Mbit mcast.
Sooner if I seriously
slam the network with flent or something else that abuses mcast like mdns. YMMV.
So what is the culprit here? What would it take to add an order of
magnitude?
As for aggregation and filtering: Most of my
> One thing that fell out of that was mainline babeld had a very
> suboptimal routine for merging routes (also it's use of memcmp was
> inefficient) - and juliusz put out a call for a qsorted implementation
> a while back.
Just to be clear -- the quadratic behaviour is for routes redistributed
On Wed, Mar 7, 2018 at 2:41 PM, Juliusz Chroboczek wrote:
> Christof, I'm very much interested in your experiments, which are likely
> to improve the quality of the Babel implementations.
>
>> We have update-interval set to 5 minutes to reduce the load on the network
>> because we
> I think babel is meant to do triggered updates however using tcpdump I was
> not able to see them when the route was inserted.
That's a fair assessment. Triggered updates are broken in 1.8.0, they
should work in current master. (My fault for introducing the bug, and
full credit to Gwendoline
Hi Toke,
possible solutions that come to my mind are:
* making babel trigger updates on newly appeared routes
Wait, it isn't doing that already? Yeah, this would be an obvious
improvement :)
I think babel is meant to do triggered updates however using tcpdump I
was not able to see them when
Christof, I'm very much interested in your experiments, which are likely
to improve the quality of the Babel implementations.
> We have update-interval set to 5 minutes to reduce the load on the network
> because we are hoping to run this topology on 500+ APs with 1000+ Clients.
The protocol is
Christof Schulze writes:
> possible solutions that come to my mind are:
> * making babel trigger updates on newly appeared routes
Wait, it isn't doing that already? Yeah, this would be an obvious
improvement :)
Also, why isn't l3roamd detecting when the client
Hello,
When using babeld in a Freifunk network, I am seeing an issue with
network convergence on newly appearing routes in this topology:
Client AP1 AP2 === Gateway === (INTERNET) ===remote host
Each client has a /128 address and /128 route inside the same /64
net-wide prefix.
13 matches
Mail list logo