[patch] Source entries removing is awfully slow.

Kajetan Staszkiewicz vegeta at tuxpowered.net
Sat Mar 9 16:15:48 UTC 2013


Dnia sobota, 9 marca 2013 o 16:11:56 napisałeś:

> > > Though the src node removal option through pfctl -K does a lot of job
> > > to cleanup things
> > > Still need to undertand why it takes so much time for you to loop
> > > through 500K states.
> > 
> > That is because the loop will not be called just once.
> > 
> > `pfctl -K 0.0.0.0/0 -K ip.of.internal.server.behind.this.loadbalancer`
> > will
> > match multiple Source entries, up to a thousand of them in normal
> > conditions
> > ("normal" for my loadbalancers) and many many more when under a DDoS
> > attack.
> 
> I would expect from a proper software to kill states from those clients and
> then kill the srcnode for the backend server.

First of all, I do not know which clients are affected. I know which server is 
dead. But I can not remove states to this server using pfctl, as states are 
from clients' public IP addresses to loadbalancer's public IP address. Sources 
on the other hand point to the internal IP address of the broken server.

And the second thing is, that under normal conditions removing just a bit of 
states would not help the performance. Also the server health checking software 
is unaware of DDoS attacks and will not remove states resulting from the attack 
in advance.

> It does not make proper sense to not kill state before src nodes since that
> is what will impact your connectivity.

I agree, it makes only sense to remove both sources and linked states at the 
same time. With removing sources only, states are still pointing to the broken 
server and clients are still connected to it in existing tcp connections. If 
states would be also removed, clients will loose all connectivity (which I 
prefer rather than them seeing wrong data) and (hopefully) reconnect to another 
live server.

> Though the patch improves your use case a lot still would be better to even
> kill those states during this step, with an extra option,
> since otherwise you'd have to create for each of those client a separate
> request.

That would be in updated version of the patch I hope to send to the list on 
Monday.

-- 
| pozdrawiam / greetings | powered by Debian, CentOS and FreeBSD |
|  Kajetan Staszkiewicz  | jabber,email: vegeta()tuxpowered net  |
|        Vegeta          | www: http://vegeta.tuxpowered.net     |
`------------------------^---------------------------------------'


More information about the freebsd-pf mailing list