|
Hello,
On Tue, 5 Jun 2018, Michal Koutný wrote:
> On 06/02/2018 08:50 PM, Julian Anastasov wrote:
> > [...]
> > net/netfilter/ipvs/ip_vs_proto.c | 19 ++++++++++++++++---
> > net/netfilter/ipvs/ip_vs_proto_sctp.c | 7 +++++++
> > net/netfilter/ipvs/ip_vs_proto_tcp.c | 7 +++++++
> > net/netfilter/ipvs/ip_vs_proto_udp.c | 7 +++++++
> > net/netfilter/ipvs/ip_vs_sync.c | 18 ++++++++----------
> > 7 files changed, 55 insertions(+), 18 deletions(-)
> >
> > diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> > index 824d7ef..d786649 100644
> > --- a/include/net/ip_vs.h
> > +++ b/include/net/ip_vs.h
> > @@ -347,6 +347,11 @@ enum ip_vs_sctp_states {
> > IP_VS_SCTP_S_LAST
> > };
> >
> > +/* Connection templates use bits from state */
> > +#define IP_VS_CTPL_S_NONE 0x0000
> A new template is in NONE state (unassured). I see you modified also UDP
> and SCTP protocols. The AH/ESP protocols (which I'm not familiar with)
> don't specify any transition function. Potential new protocols may lack
For AH/ESP we use UDP connection, so we rely on UDP.
> the function/body as well. Would not it be confusing if persistent
> templates won't be persistent with drop_entry enabled?
In practice, it would be very difficult to drop template:
- it start in NONE state but ... is referred by connection(s)
- there must be no connections that point to it: all must be
expired (eg. 60 secs for SYN_RECV), 5min for UDP (configurable
via ip_vs_set_timeout) that has no replies, 4 seconds (Init RTO+1)
for SCTP if S:INIT-ACK or C:COOKIE-ECHO are not received.
At highest risk appears to be UDP with DR/TUN methods,
especially UDP with OPS service which is not changed by this
patch.
- it must be unassured: all conns expired in SYN_RECV state
without being established. If one conn is established, we
can not drop the template.
Let me know if you see any problems in tests...
Regards
--
Julian Anastasov <ja@xxxxxx>
|
