|
Hello Julian,
They are already exported. But you have to teach the WLC
scheduler to which estimator to apply the weights: cps, inpps, outpps,
inbps, outbps. Currently, it is to actconns&inactconns but this is
something like cps. May be you can add additional scheduler, say
ip_vs_wlt.c (Weighted Least Traffic). The problem is that you
This is the idea, actually.
can monitor outbps only for NAT. Using inbps is useless for normal
good point.
web or ftp traffic. You need stats from the interfaces and dynamicly
to change the WRR's weghts. Without additional information about
the memory or CPU load in the real servers, this new scheduler
is going to send more traffic to the already overloaded real
servers. You need a complex expression, not only the traffic.
I really would like to know how a simple think like the cps performs
when applied to pps.
Of course, there will be setups where the estimated traffic is
enough.
I definitely think so.
I'm not sure, WRR is very useful for user space control
that can provide a complex formula to set the weights dynamicly.
The actual traffic is only a small part from this expression. In
some of the cases the real servers can do CPU intensive job
which costs more than just to send packets.
Of course but as a starter it might as well be viable.
I even decided not to create any ESP/AH entries, see the
document I started yesterday, I updated it today with some info
for NAT Traversal. I can start coding soon but the funny part is
that opportunism is not widely used, nor the NAT Traversal :)
I see that.
Yes, for now, it seems a 2-state ISAKMP handling is enough.
Of course, we can base our timeouts only to the ISAKMP protocol.
Ok.
I don't think we can connect one client to many real servers
because this breaks the ISAKMP protocol. IMO, we need to create
Not so sure. After the first SA pool has been created new connection
setups are done encrypted over the initial SA pool. A client can
certainly generate a IPsec tunnel to another net entity.
only ISAKMP entries, no ESP or AH entries are needed, their packets
will just hold a reference to the ISAKMP entry (if such exists)
That's actually a very good idea.
while the packet is handled and even will not update the expiration
timer. Only the ISAKMP packets will update the expiration timer.
Implicit persistence with a slave ESP/AH traffic.
I see your point and I agree.
Yes, but we can look in the [ir]cookies to know one
of the 2 possible states we can support.
Only for the first connection not afterwards.
May be you are the one who should experiment with the
real server's estimators to tune WLC or a new scheduler :)
Yep.
No, if the payload is encrypted we can't see anything.
Only the cookies, if I understand correctly the issue.
Actually everything is encrypted as soon as both endpoints agreed on the
setup (a few packets) and have built their initial SA. From then on new
SA's will be negotiated with encryption on.
Best regards,
Roberto Nibali, ratz
| 