On Wed, Sep 25, 2024 at 03:01:27PM +0200, Theo Buehler wrote:
> 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'

That went horribly worng :) 
Fixed.

-- 
:wq Claudio