Hi Simone,
I would guess that syslog has better buffering and load handling; so I
would try logging only to syslog--this should halve the load caused by
verbose logging.
Speaking of verbose, I've looked at BIRD logs, and I see lines like this:
Route A received by peer Y
Route A announced to pee
On Wed, Apr 08, 2015 at 01:33:43PM -0400, Jigar Mehta wrote:
> I am new to BIRD and routing engines in general. I needed to understand
> feasibility of using BIRD if the device has its own custom forwarding plane
> instead of letting Kernel do the forwarding.
> I have read through the coder's/user'
I am new to BIRD and routing engines in general. I needed to understand
feasibility of using BIRD if the device has its own custom forwarding plane
instead of letting Kernel do the forwarding.
I have read through the coder's/user's documents but did not find answers
to few questions :
1. What is t
I had same kind problem some years a go. Problem was that I accidentaly
miscofigure bgp session so that one of peers was connected to ip what
was announced via other hop. That caused route flapping and full
internet table flapping at that router -> 100% cpu load and 10-100Mbps
bgp traffic.
8.
Thanks for your explaination. I understand, and it seems to be functioning
OK with the following config. Is this the right way ? :
protocol rip rip1 {
#debug all;
interface "eth0" { mode multicast; ttl security tx only; };
honor neighbor;
authentication none;
import all;
export filter {
Hello list,
we are running BIRD on our IXP peering platform with no problems since
quite a while now.
We need to activate a new peer which is expected to announce a
considerable amount of prefixes (~100k), and the first try resulted in
having nearly 100% cpu load, ~60-70% for BIRD and the rema
