Toke Høiland-Jørgensen writes:
>> It is true that this part is probably not described anywhere in depth.
>> There are some notes in nest/protocol.h that are not propagated to the
>> documentation. For the rest, you can use the source, but sometimes
>> even the source is 'wrong'.
>
> Will poke aro
On Tue, Aug 25, 2015 at 03:45:47PM -0500, Michael Vallaly wrote:
>
> For context on my end; this issue was experienced on physical hardware
> (64bit) with Intel 1Gbit NICs (no offloading).
>
> We only noticed this after some length of time, (> 180 days) during
> which we likely had < 40 BGP sessi
> With current default optmem_max values, this allows about 150 keys on
64bit arches, and 88 keys on 32bit arches.
I think you just solved it for me at least... I was seeing issues after
~147 BGP sessions, so running into this limit would make perfect sense.
I could reproduce it at will just
For context on my end; this issue was experienced on physical hardware
(64bit) with Intel 1Gbit NICs (no offloading).
We only noticed this after some length of time, (> 180 days) during
which we likely had < 40 BGP session flaps on our end via Bird.
optmem_max: Maximum ancillary buffer size all
I haven't tried the optmem_max option, but I did some more experimenting..
We have a virtual machine running a nearly identical BIRD config that's
not showing this issue.
The machine with the issue is physical, and has a Mellanox ConnectX
NIC. I'm wondering if there's some limitation with TC
> For my own education, why blackhole the route rather than simply not
> propagate it at all to the FIB (i.e. ignore it)?
Please see RFC 6126 Section 2.8:
https://tools.ietf.org/html/rfc6126#section-2.8
-- Juliusz
On 25 Aug 2015, at 19:34, Juliusz Chroboczek
wrote:
> Yes. Babel is designed to be robust not only on wired networks (where
> OSPF and IS-IS work just fine), but also on wireless mesh networks, where
> a routing loop, even a transient one, causes cross-link interference and
> may prevent the r
>> BTW, the argumentation in 3.5.5 of RFC 6126 seems a bit strange to me.
>> It essentially says that unreachable routes are added to avoid transient
>> routing loops before Babel converges. But transient routing loops until
>> convergence is a common behavior for IGPs (both RIP, OSPF and IS-IS do
Hi all,
I wanted to announce newer versions of BGPsec supporting code using
BIRD: bgpsec-bird-client v1.0 and v0.6 of BGPsec support code for
BIRD. They are available as a source tarballs at:
http://bgpsec.tislabs.com
The bgpsec-bird-client application has two main features. It uses the
rpki-
Ondrej Zajicek writes:
>> > Also note that unreachable routing entries should not be propagated to
>> > core.
>>
>> This is actually done to satisfy a requirement of the Babel protocol:
>> Temporary blackholing is used to avoid routing loops. Quoting section
>> 3.5.5 of RFC6126:
>> ...
>> Now, i
On Tue, Aug 25, 2015 at 03:01:05PM +0200, Toke Høiland-Jørgensen wrote:
> > Also note that unreachable routing entries should not be propagated to
> > core.
>
> This is actually done to satisfy a requirement of the Babel protocol:
> Temporary blackholing is used to avoid routing loops. Quoting sec
Hi All,
Just a courtesy email to anyone using my bird-tool scripts over at:
https://github.com/dowlingw/bird-tool
It’s well overdue (over 2 years), but I’ve finally pushed support for multiple
sessions with the tools.
Like everything else in the tools, this assumes your sessions are named using
Ondrej Zajicek writes:
> Hi, i am finally sending the first batch of comments. This time it is
> mostly general comments.
Thank you very much for the comments. I have a few follow-up questions
(below), but will otherwise revise the implementation accordingly and
resubmit :)
> The proper approa
On Tue, Aug 18, 2015 at 11:06:03PM +0100, Toke Høiland-Jørgensen wrote:
> The implementation is currently IPv6-only (since Bird does not support
> mixed IPv4/6 protocols in the same instance), but is otherwise complete
> as far as MUSTs in the RFC is concerned, with one exception: The RFC
> specifi
14 matches
Mail list logo