|
Hi Peter,
>> After a little code holidays :) I have enhanced the code.
>> Please consider
>> this new release as a STABLE 1.0.0 release candidate. I would
>
> Your girlfriend must hate you now Alexandre. Good work. :D
I hope she will not read the mailing list :) My sleeping time is too short,
but I have set to myself a dead line for the STABLE release for december,
so I try to make it possible :) This is why it would be nice if people
currently using Keepalived spend time testing the tool to eradicate all
eventual stalled issues :) I want it to be robust :)
>> * VRRP : Finally extend the code to support VRRP IPSEC-AH
>> authentication
>> method. Created a IPSEC-AH seq_number
>> syncrhonization mecanism
>> during
>> VRRP MASTER/BACKUP elections.
>
> Does this ipsec authentication's primary function cause the directors to
> authenticate each other? Or does this transfer sync data over IPsec? Does
> this mean iptables rules should allow IPSEC traffic - protocol 50/51,
> udp:500?
With the previous release VRRP code doesn t support IPSEC-AH very well,
so I have take time to make regression tests and finally release a working
code.
The IPSEC-AH authentication method is related to VRRP packet authentication.
rfc2338.5.3.6.3.
So the VRRP packets multicasted on the wire will be as following :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| IP PACKET |
| . |
+---------------+---------------+---------------+---------------+
| Next Header | Length | RESERVED |
I +---------------+---------------+---------------+---------------+
P | Security Parameters Index |
S +---------------+---------------+---------------+---------------+
E | |
C + Authentication Data (variable number of 32-bit words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| VRRP PACKET |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So all VRRP adverts are strongly authenticated using HMAC-MD5-96bits. So
at the receiving point of view, incoming packet sanity_check check the
IPSEC authentication data for dropping decision. Since this field is
based on password encryption this increase strongly security. Because
on such a protocol as VRRP, the most sensible point is the incoming
packet handling since it drive state transition and so VIP.
This extension is only related to VRRP packet sanity_check not related
to ipvs synchronization daemon.
We must keep in mind that this encryption extension is CPU time consuming
but since this is only called during VRRP sending process (every second
per VRRP instances) this is quite acceptable and not degrade the global
performance.
=> For the IPVS sync daemon, we need a MD5 extension kernel-side, but
since last week this has been done for the 2.5 kernel, so it is quite
possible.
If you iptable the traffic you must grant the access to IP protocol
51 destinating to VRRP mcast group (224.0.0.18).
>> * VRRP : Extended the VRRP TSM to speed up instances
>> syncrhonization
>> during FAULT->BACKUP & FAULT->MASTER state transition.
>
> What kind of speed-up are we talking about?
The Keepalived/VRRP framework implements an extension of the VRRP
protocol I called the "syncrhonization group". That permit
multiple VRRP instances to keep state sync together. This is
needed for setup like LVS that need (NAT) persistent routing path.
Since VRRP is an election protocol, state transition introduce a
convergence delay. When you have such an extension as "vrrp_sync_group",
this introduce a global convergence delay that maximize the elementary
convergence delay. So in order to optimize to the max this delay,
VRRP code use a TSM (Transition State Machine) design that optimize
this delay handling all possible transition state in a group.
An exemple is : you run VRRP on a router of 6 NICs. You define one
VRRP instance per NICs. Then you put all this instances into the same
vrrp_sync_group. VI_1, VI_2, VI_3, VI_4, VI_5 & VI_6. If VI_3 transit
to MASTER state then the synchronization mecanism will force all
other VI_i to transit to the same state. That way timer and convergence
delay are reduced to the max since state transition is drived by the
global group transition delay, which is based on the first transition
state.
=> I can speak long time on this, since it has made me spagetti brain
though.
Best regards,
Alexandre
|
