|
Hello,
On Mon, 29 May 2000, hotman wrote:
> Hi,all.
>
> I want know whether the following functions is implemented in the lvs.
> Thank you.
>
> $B"#(BDelayed Removal of TCP Connection Context
> Because of IP packet ordering anomalies, IOS SLB might "see"
> the termination of a TCP connection (a finish [FIN] or reset [RST])
> followed by other packets for the connection. This problem usually
> occurs when there are multiple paths that the TCP connection packets
>
> can follow. To correctly redirect the packets that arrive after the
> connection is terminated, IOS SLB retains the TCP connection
> information, or context, for a specified length of time.
> The length of time the context is retained after the connection
> is terminated is controlled by a configurable delay timer.
There is a default timeout of 10+ seconds for the
CLOSE* states and 60+ seconds for states after FIN but you
can tune them in the proc fs (/proc/sys/net/ipv4/vs/) if
secure_tcp is ON. You can read about these settings in
http://www.linuxvirtualserver.org/defense.html
>
> $B"#(BTCP Session Reassignment
> IOS SLB tracks each TCP synchronous idle character (SYN) sent to
> a real server by a client attempting to open a new connection.
> If several consecutive SYNs are not answered, or if an SYN is
> replied
> to with an RST, the TCP session is reassigned to a new real server.
> The number of SYN attempts is controlled by a configurable reassign
> threshold.
LVS has many forwarding methods. Only using one of
them (LVS/NAT) LVS can see the output traffic from the real
servers. Under dDoS when the real servers doesn't support
SYN cookies it is very hard to determine if the real server
is running by sending SYN probes.
Currently, LVS allows a monitor software to do its
checks for the real server availability. Normally the SYNs
are answered from the kernel, not from the real service, so
you can't determine by using SYN probes if your real service
is working, only if it is present and not overloaded.
There is an easy way to check in the real host if
the real service is listening on specific port. Just let
your monitor software to bind to this port on each 5
seconds(2 seconds?). But this trick only detects if the port
is busy. Is that enough? You don't need to pass a real
requests to any real service on each 5 seconds just to check
if the daemon is running.
>
> $B"#(BAutomatic Server Failure Detection
> IOS SLB automatically detects each failed connection attempt to
> a real server, and increments a failure counter for that server.
> (The failure counter is not incremented if a failed connection from
> the same client has already been counted.) If a server's failure
> counter exceeds a configurable failure threshold, the server is
> considered out of service and is removed from the list of
> active real servers.
LVS puts a deleted service in a trash. If all
entries to this real service expire it is purged. But if the
real service is recreated we restore it in the state when it
was deleted but with the counters of active/inactive entries
updated. The connections can continue after this period of
inactivity, they are blocked from the director but not
droped.
>
> $B"#(BAuto Unfail
> When a real server fails and is removed from the list of active
> servers,
> it is assigned no new connections for an amount of time specified
> by a configurable retry timer. After that timer expires, the server
> is again eligible for new virtual server connections and IOS SLB
> sends
> the server the next connection for which it qualifies. If the
> connection
> is successful, the failed server is placed back on the list of
> active
> real servers. If the connection is unsuccessful, the server remains
> out of service and the retry timer is reset.
It is a monitor software's job to decide when a real
service is alive and to add it in the list for the virtual
service. You are free to use any monitor software which
uses any kind of checks to determine when a real service is
alive: connection establishment, local if-port-busy checks,
receiving a known reply from the real service, the number
of retries and the interval between these checks, etc.
>
> $B"#(BSlow Start
> In an environment that uses weighted least connections load
> balancing,
> a real server that is placed in service initially has no
> connections,
> and could therefore be assigned so many new connections that
> it becomes overloaded. To prevent such an overload, the slow start
> feature controls the number of new connections that are directed to
> a real server that has just been placed in service.
This can be achieved from the monitor/control
software if that looks as a big problem. It is preferred the
weights to be updated often and not only on the start of the
real service. If the real server is deleted and added again
it is not put with zeroed connection counters (remember for
the trash), i.e. may be the director thinks it is even more
loaded than the time it was deleted. This is because new
connections are not created to this service, the traffic is
stopped and LVS doesn't update the entry state. So, it is
possible some connections to expire in the real host but not
to be marked in the director. So, in this case it is
recommended even fast start :) Remember that in LVS/DR and
LVS/TUN mode the Director listens only to the clients
packets, what the clients think is the state of the
connection. This is different from the number of connections
accounted in the real server. "least connections" methods
are easy to maintain but are not correct. The real host's
load must be used as weight. The problem is that each kind
of real service leads to different load in the real host.
Don't rely on the "lc" and "wlc" methods fully to distribute
the load. If you consider the real host's load there is no
problem with any slow/fast starts.
>
> $B"#(BSynGuard
> The SynGuard feature limits the rate of TCP SYNs handled by
> a virtual server to prevent a type of network problem known as
> an SYN flood denial of service attack. A user might send a large
> number of SYNs to a server, which would overwhelm or crash the
> server,
> denying service to other users. The SynGuard feature prevents
> an SYN flood denial of service attack from bringing down IOS SLB or
> a real server. SynGuard monitors the number of SYNs to a virtual
> server over a specific time interval and does not allow the number
> to exceed a configured SYN threshold. Once the threshold is reached,
>
> any new SYNs are dropped
In NAT mode when secure_tcp is enabled LVS tries to
listen to the real server replies. If the TCP handshake is
completed this connection is marked as established in the
director's table. Before that we use little timeouts for the
entry and we don't follow some of the TCP flags from the
client's packets. This mode (secure_tcp) is suitable for
most of the known services. Of course, the real servers
must be tuned too: SYN cookies, SYN-ACK retries, etc. The
state timeouts in the director must be tuned too. Of course,
this complex task results in a violation of the TCP protocol
but the result is very good. The valid clients can work, the
Director's memory is not full.
This is only one of the defense strategies used from
LVS. There are more strategies you can read about, in the
above URL. If that is not enough you can try with the packet
schedulers (CONFIG_NET_SCHED) which work on lower (device)
level.
>
> Regards.
> zhao.
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|
