|
Hello Julian,
Sorry for the delay, but days still only have 24 hours :(
> Currently, all schedulers can receive weight and in most
> cases this is enough. If you want to feed it with something else
> then it should be implemented. WRR is clever enough to keep the
> weights you set. From your words I assume it is not enough? As
It is enough actually for now. But I need to export the byte and packet
counter :) You smell it now?
> for testing new scheduler, why not to copy one simple scheduler
> and to fill all its hooks. Rename ip_vs_wrr.c to ip_vs_wrr_saved.c
> and ip_vs_thebestone.c to ip_vs_wrr.c and do ipvsadm -A -s wrr :)))
LOL, ip_vs_wrr will be so obsoleted, that I don't even care to copy it
anymore :)
>>way, the user can specify the timeout. This is transfered via the UDP
>>packets first which initiate the whole connection setup. After that the
>>IKE SA setup does some magic key handshaking and generates on each side
>>an SA for the connection. All those things have to be persistent. Now
>>the SPI stays for the session until the timeout expires and that is
>>where we have to pay attention. If a SA pool creates a new SPI we need
>>to figure that out and to some kind of RELATED entry and put that into
>>the persistence template of the old session.
>>
>
> If we look at the SPIs at all. I'm even thinking of
> code such as:
>
> - get the iph->protocol
>
> - if it is ICMP => try for related ICMP
>
> - if it is UDP/TCP/ICMP => do balancing
> - if it is ESP/AH => do balancing
Well, why not make it like with ftp? As soon as we get CIP:500 ->
VIP:500 we start a persistent entry and add ESP/AH to it, when we detect it?
>
> Yep, we need to know when one connection dies.
AFAIK a IPsec connection never dies or at least a router in between
doesn't know that without inspecting the packets. Ok, you know when a
connection dies, but this is only TCP state related. But an IPsec
session could not have packets for an hour and still claim to be related
to the old session with the same old SPI. This is the nasty point. We
can solve this, when we can tell the director about the rekeying timeout
by configuration.
> Yes, with the persistent fwmark service we can forward
> any protocol, the minimum we need to know is when to create and when
> to release a LVS entry. Everything else is routing. We don't want
> to rely on the dropentry memory-defense strategy to make the decision
for
> the entry life :)
Why? We should know when a SPI gets updated. The session might still be
valid for the dropentry but the SPI changed. Ok, the only problem we
would have there is that we would generate yet more imbalance because an
entry would stay persistent longer than it actually needed to.
> Yes, for our routing decisions ESP/AH is a IP protocol, we
> even don't need to look at the protocol header and as a bonus we
> even don't need to defragment these packets. Defrag is needed only
> for TCP/UDP/ICMP because we use information from their headers.
> So, ESP/AH is easy for forwarding but ISAKMP ... we still don't know.
Isn't it just a stupid UDP? I hardly ever talks anyway.
>>Well, tonight while cooking for Valentine's Day dinner this idea popped
>>into my head too. SNET->FWMARK template is the smallest possible working
>>subset for IPsec tunnels. I agree.
>>
>
> Yes, run your new scheduler, apply dynamic weights and
> the imbalance caused from persistence is gone :) Almost.
To bring it to the point. We should have a scheduler that calculates the
bytes and the packets and does weighting according to those values. This
is for all brain damaged AC super-ecommerce implementations that need a
persistency timeout of 7200s.
> The persistence timeout is useless if we don't have correct
> control for the ISAKMP and the ESP/AH entry life, they can't live
> forever in our context. We should analyze ISAKMP (if someone is
> aware please help) to add correct entry life timeouts because the
> problem with attacks can be unavoidable. This is DR method (input
> only).
See, we have to inspect packets, at least UDP/VIP:500 ones. There you
find the information about the SPI and the lifetime.
Cheers,
Roberto Nibali, ratz
|
