On Sat, Mar 06, 2021 at 12:21:59AM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > > If I understand correctly, the connection tracking netlink interface
> > > is an exception here because it has its own handling of dealing with
> > > congestion ("more reliable"?) so you need to disable the "default
> > > congestion control"?
> >
> > In conntrack, you have to combine NETLINK_NO_ENOBUFS with
> > NETLINK_BROADCAST_ERROR, then it's the kernel turns on the "more
> > reliable" event delivery.
>
> The "more reliable" event delivery guarantees that the kernel will
> deliver at least the DESTROY notification (connection close).
>
> If the userspace program is stuck, kernel has to hold on the expired
> entries. Eventually conntrack stops accepting new connections because
> the table is full.
>
> So this feature can't be recommended as a best-practice for conntrack
> either.
There are two use-cases for this:
- If you run conntrackd and you really want to sure you backup firewall
does not get out of sync.
- If you run ulogd2 and you want to make sure your connection log is
complete (no events got lost).
In both cases, this might comes at the cost of dropping packets if the
table gets full. So it's placing the pressure on the conntrack side.
With the right policy you could restrict the number of connection per
second.
I agree though that combination of NETLINK_NO_ENOBUFS and
NETLINK_BROADCAST_ERROR only makes sense for very specific use-cases.
