On Wed, Sep 25, 2024 at 02:09:24PM +0200, Claudio Jeker wrote:
> When creating UPDATE messages bgpd can hit some error cases that can be
> triggered from remote.
> 
> Mainly up_dump_update() can fail if the produced attributes for the UPDATE
> are so large that they no longer fit into the default BGP packet size.
> bgpd kind of handles this but in a not so good way. Right now the bad prefix
> is silently dropped and the peer remains with stale data (the previous
> update).
> 
> Here is a diff that improves the situation. It withdraws the prefix in
> question and also logs the issue. On top of this I moved the ibuf
> allocation from rde_update_queue_runner() into up_dump_withdraws() and
> up_dump_update() which makes the queue runner simpler.
> 
> I have a regress test that currently tickles the goto drop cases for IPv4
> (but not yet the MP one).

Reads ok, except for the three times repeated 'worng'