Displaying 4 results from an estimated 4 matches for "block_ip".
Did you mean:
block_dp
2023 Feb 13
1
ctdb tcp kill: remaining connections
...quot; lines in a row which is more than the reported 394.
This output is coming from the releaseip section in /etc/ctdb/events/legacy/10.interface, which calls kill_tcp_connections (in /etc/ctdb/functions) which calls the ctdb_killtcp utility to actually kill the connections. This happens inside a block_ip/unblock_ip guard that temporarily sets up a firewall rule to drop all incoming packages for the ip (x.x.253.252 in this case).
Obviously the tool fails to be 100% successful.
I am wondering about possible reasons for ctdb not killing all affected connections. Are there tunables regarding this beh...
2023 Feb 15
1
ctdb tcp kill: remaining connections
...more than the
> reported 394.
> This output is coming from the releaseip section in
> /etc/ctdb/events/legacy/10.interface, which calls
> kill_tcp_connections (in /etc/ctdb/functions) which calls the
> ctdb_killtcp utility to actually kill the connections. This happens
> inside a block_ip/unblock_ip guard that temporarily sets up a
> firewall rule to drop all incoming packages for the ip (x.x.253.252
> in this case).
>
> Obviously the tool fails to be 100% successful.
The main aim of this code is to terminate the server end of TCP
connections. This is meant to stop pr...
2023 Feb 16
1
ctdb tcp kill: remaining connections
...es and then:
"Killed 230/394 TCP connections to released IP x.x.253.252
Remaining connections:"
Followed by 164 remaining connections. That numbers match (230+164=394). But in the remaining list there are indeed 93 IPs that are not contained in the sending list.
> * If not, then the block_ip part isn't working (and you would expect to
> see errors from iptables) because they are new connections.
I have not seen any errors from iptables.
> * If there has been an attempt to RST the connections then I'm
> interested to know if the public address is on an ordinary et...
2023 Feb 16
1
ctdb tcp kill: remaining connections
...e indeed 93 IPs that
> are not contained in the sending list.
This means the problem must be one of 2 things:
1. The left over connections are new connections and iptables is not
blocking incoming connections
2. ctdb_killtcp is not terminating all connections.
> > * If not, then the block_ip part isn't working (and you would expect to
> > see errors from iptables) because they are new connections.
>
> I have not seen any errors from iptables.
>
So, I think it is (2). :-)
The problem seems to be that ctdb_killtcp is not capturing a response
to its TCP tickle...