(unfortunately) more BIRD-2.0.0 woes ...

[Ondrej Zajicek]

On Fri, Dec 15, 2017 at 05:56:09PM +0100, Clemens Schrimpe wrote:
> Hello again -
> 
> a couple of days ago I converted one of my test route-server setups from „dual BIRD-1.6.3“ to „single BIRD-2.0.0“ by simply „merging“ bird6.conf and bird.conf into a single (unified) new bird.conf - also observing the guidelines laid out in https://gitlab.labs.nic.cz/labs/bird/wikis/transition-notes-to-bird-2 <https://gitlab.labs.nic.cz/labs/bird/wikis/transition-notes-to-bird-2> . 
> 
> The results of this simple approach are between weird and stunning:
> 
> I now have a bird process which is consuming 100% of one CPU. It is
> still talking to me through birdc, but is very sluggish, i.e. bringing up
> peers or tearing them down takes a long time - you even see states, like
> „flushing“ in „show proto all XXX“ for quite some time, which you
> normally don’t even notice, because they are usually very transitive :-)
>
> I haven’t gotten deeper into the problem, yet, but there appears to be a loop involving the affected peer’s Export Updates:
> 
>     Route change stats:     received   rejected   filtered    ignored   accepted
>       Import updates:         670962          0          0          0     670962
>       Import withdraws:          216          0        ---          0        216
>       Export updates:      317034802  159525749  157509053        ---          0
>       Export withdraws:          468        ---        ---        ---          0
> 
> (those numbers are increasing fast)
> 
> Some of my peers were/are already MP-BGP capable and so some IPv6 peers
> now came up with „Hey, you speak IPv4 too? Cool! Here are some 700.000
> routes for your, my friend!“, which is totally explicable, yet it
> surprised my a teeny bit, anyway :-)
> 
> It should be made clear in the documentation, that BGP protocol
> definitions without explicit address-family → „channel“ definitions my
> eventually (see below) ending up MP-BGP sessions with the above effect!?

Hi

This should not happen. In BGP, only explicitly configured channels are
created and announced. Perhaps you have both channels configured in the
template? That would be expected behavior, there is no difference between
channel configured in template or in protocol. It is valid use case to
have all channels configured in template and then just 'remote' in
protocol.

> Most surprising: My multiple-inheritance approach, using multiple,
> chained template definitions for my BGP „protocols“/sessions/peers broke
> in the weirdest way: I now have multiple IPv6 and IPv4 channels on some
> of my protocols with different parameterizations:
> ...
> (it seems the ipv6/ipv4 channel definitions within the templates each
> create their own instances instead of inheriting/enhancing (from) the
> ones upstream???)

This are two issues:

1) Nested options from templates are not merged, just concatenated.
Templates always behaved this way but it is true that with advent
of channel config blocks this make them less useful and change of
the behavior is perhaps necessary. At least i will add a note to
the guidelines.

2) Config file containing BGP with multiple channels of the same type
(either directly or through templates) is not rejected. This was already
discussed and will be fixed soon:

http://trubka.network.cz/pipermail/bird-users/2017-December/011704.html


> @Ondrej, et.al., is this even a „supported mode of operation“ → multiple IPv6 and IPv4 channels within one protocol?

No

> So this still somehow works, yet still with the 100% CPU consumption.
> 
> @bird-devs: How would you like to address above issues? Yes, I can
> probably clean up the config file, which would probably even make the
> 100%-issue go away. But imho it shouldn’t be possible in the first place
> to create configs like these without BIRD at least kicking and screaming
> loudly about it.

Yes, i will fix the #2 so that such config files are rejected, and perhaps 
template-channel merging, but it is not a simple bug such that i will send
a patch immediately.

It would be a good idea if you could try to clean up the config file
to eliminate duplicit channels. I guess that will also fix the 100%
issue. I will send you a ssh-pubkey.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20171215/f695e8e9/attachment.asc>