>> Matthieu, do you understand why that is? Is there a way to optimise away
>> conflict_solution in the easy case?
>
> I think so. Will fix it.
The attached patch should solve the problem. As a conflict need a specific
route, the first now loop iterates on specific routes only. If there is
> The attached patch should solve the problem.
Nice, applied.
> +if(!check_specific_first())
> +fprintf(stderr, "Invariant failed: specific routes first in RIB.\n");
#ifdef DEBUG, or if(debug_level >= 2) ?
-- Juliusz
___
Babel-users
On Mon, Dec 14, 2015 at 8:15 PM, Dave Taht wrote:
> Is there a reliable way of determining that an underlying interface is a
> bridge?
A local bridge/wifi? Sure...
just look into the source of the brctl tool... it can give you a list
of all bridge interfaces.
A "wifi
> #ifdef DEBUG, or if(debug_level >= 2) ?
Well, I was not sure about this one. The problem with debug_level is that it
produces too verbose output, it's not just "checks". I was rather thinking
about having a test-mode version of babeld, which let the clean babeld-code
as-is, and add some
Hi!
But it will be more complicated with upgrades, and more complicated
assuring that things are really the same (same patched version of
Babel, same kernel version, TCP/IP stack, sysctl settings, etc.).
Mitar
On Sun, Dec 13, 2015 at 1:00 PM, Juliusz Chroboczek
> Matthieu, do you understand why that is? Is there a way to optimise away
> conflict_solution in the easy case?
I think so. Will fix it. I may call you before.
Matthieu
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
On Sun, Dec 13, 2015 at 2:52 PM, Juliusz Chroboczek
wrote:
>> Ok, I can do some profiling on the babeld that is running on the VPN
>> server with the large number of links. Just tell me what profiling data
>> do you want? Should I just compile a debug build and run
On 13 December 2015 at 22:00, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:
> >> Ok, I'll see on Monday if I can get an extra VM before Christmas.
> >
> > Which VM system are you using? We might be able to generate you a
> > ready-made image.
>
> Please don't -- I'll let our system
>> Ok, I'll see on Monday if I can get an extra VM before Christmas.
>
> Which VM system are you using? We might be able to generate you a
> ready-made image.
Please don't -- I'll let our system administrators clone their usual
VMWare image, it's better for everyone if I use what they're familiar
>> Oh, sadly not 75 max. The number of neighbours of one node is
>> potentially very large, because all nodes with Internet uplink
>> connects to the VPN server. So, all those nodes are then neighbours of
>> that VPN server node. Currently this is for example 140 nodes on one
> So yes, 75 is the
Hello!
On 08. 12. 2015 17:58, Jernej Kos wrote:
> We are still on the lookout for unparsable packets ;-)
Got one!
Couldn't parse packet (8, 14) from fe80::2ff:1bff:fe10:3d34 on digger1438.
Packet dump: 08 0e 01 00 20 00 06 40 32 8e ff ff 0a fe 00 08
Jernej
signature.asc
Description:
Hi!
Hm, I thought that Babel was tested on large networks and that it was
tested on simulated large networks? Or are we now the largest network
using it and this is why we are getting in all this trouble? So this
is just another academic project which looks good on the paper but in
practice it is
> Hm, I thought that Babel was tested on large networks and that it was
> tested on simulated large networks?
Babel has been tested in one large network (1500 nodes). It took 20
minutes to converge, and worked fine after convergence time. I fixed the
initial convergence issues (too many
> Attaching some more dumps.
Thanks, Kosko.
These are all IPv4 retractions, and they look just fine to me. I'd need
to see the full packet to be sure, but it probably means that there's some
ambiguity in the code about handling retractions with no suitable next
hop.
I'll have a look when I
What about python scapy to generate bogus packets ?
Saverio
Il 08/dic/2015 18:01, "Dave Taht" ha scritto:
> On Tue, Dec 8, 2015 at 5:58 PM, Jernej Kos wrote:
> > Hello!
> >
> > On 07. 12. 2015 17:14, Juliusz Chroboczek wrote:
> >> Yes, that's expected.
Hello!
On 07. 12. 2015 17:14, Juliusz Chroboczek wrote:
> Yes, that's expected. Please increase the limits, be bold, multiply them
> by 20.
It seems that raising the limits solved the problem. Thanks!
We are still on the lookout for unparsable packets ;-)
Jernej
signature.asc
Description:
On Tue, Dec 8, 2015 at 5:58 PM, Jernej Kos wrote:
> Hello!
>
> On 07. 12. 2015 17:14, Juliusz Chroboczek wrote:
>> Yes, that's expected. Please increase the limits, be bold, multiply them
>> by 20.
>
> It seems that raising the limits solved the problem. Thanks!
>
> We are still
Hello!
On 07. 12. 2015 10:16, Juliusz Chroboczek wrote:
> How large is your network? How many routes through how many neighbours?
It is around 550 routes and there is one node, which currently has 75
neighbours. Is this be enough to trigger the limits?
Jernej
signature.asc
Description:
> It is around 550 routes and there is one node, which currently has 75
> neighbours.
Excellent.
> Is this be enough to trigger the limits?
Yes, that's expected. Please increase the limits, be bold, multiply them
by 20.
-- Juliusz
___
Babel-users
Hello!
I have recently discovered a lot of messages like the following in the
babeld log:
Warning: bucket full, dropping packet to digger1438.
Warning: bucket full, dropping unicast packet to
fe80::2ff:c3ff:fec1:a81c if digger1438.
Warning: bucket full, dropping packet to digger1438.
Any hints
20 matches
Mail list logo