|
Re,
> Do you have a state diagram other than the one in you PDF?
Hmm, currently not since I am very busy with the code... But look the
following.
With the current code, synchronization is done using a "by pair" approach
this mean that 2 VRRP Instances are monitoring together and then the
transition to a different state is replicated to the monitored Instance (=>
noisy to code since there is no master/slave definition). This approach was
done ni configuration file like this :
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
virtual_ipaddress {
192.168.200.18
}
sync_instance VI_2
}
vrrp_instance VI_2 {
state MASTER
interface eth1
virtual_router_id 52
priority 100
advert_int 1
virtual_ipaddress {
192.168.201.18
}
sync_instance VI_1
}
No imagine you have a big firewall with 8 NICs, and you want to run one
VRRP Instance per NIC all synced together. So the current configuration,
due to the "by-pair" approach will be like this :
VI_1->VI_2->VI_3->VI_4->VI_5->VI_6->VI_7->VI_8->VI_1 => So you define a
synchronization loop to tell the VRRP framework that all instance need to
be synced.
But using this approach introduce convergeance loop introduced by the
convergence timer. Convergence (time between two state) is specific to the
routing software, here with VRRP we speak with lower or egal to 3secs
convergence per instance. But if we run many (8 in our sample conf)
instance all synced together, you define a loop and this loop is very
sensible to timer. => Imagine VI_1 transit to another state, this new state
will be replicated to the other VRRP Instances using the "by-pair" algo,
but we start with VI_1 and finish by VI_1 too... the time to converge from
VI_1 to VI_1 is the global loop time, if this time is greater or egal to
VRRP convergeance timer, we will have an infinite syncing loop ! WTF :)
Since this kind of setup can be very usefull for big backbone env we need
to find a way to sync many instances together without this noisy infinite
loop. To reach the goal we need to re-design completly the sync policy
(mathematics modelisation) to define a new way to specify into the
framework the way we want to work. The code I am working on currently
implement a new way defining a global "vrrp_sync_group" to deal with this
problem. Example is :
vrrp_sync_group VG1 {
VI_1
VI_2
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
virtual_ipaddress {
192.168.200.18
}
}
vrrp_instance VI_2 {
state MASTER
interface eth1
virtual_router_id 52
priority 100
advert_int 1
virtual_ipaddress {
192.168.201.18
}
}
=> and thats all, all the rest is done in the code, the user abstraction is
very restrictive even if this imply a big code scheduling rewritte... So if
you have 8 NICs with one VRRP instance on each NIC you will configure VRRP
framework like this :
vrrp_sync_group VG1 {
VI_1
VI_2
VI_3
VI_4
VI_5
VI_6
VI_7
VI_8
}
=> All the state transition will not be degradate by the protocol
convergence timer (3s).
=> I am currently coding this...
> Why do you want a 1.0.0 release?
Well, I think that the global framework design and functionnality is good
enough to release a 1.0.0 release. I just need to finish some consmetic
work (libipvs integration, ...) and the base functionnalities will be good.
IMHO, the code stability is currently stable enough for 1.0.0. Feel free to
tell me if you don t agree :) => I plan after to enhance VRRP code to
driver netfiler stateful table replication (Harald Welte will done a speech
at OLS on this).
Best regs,
Alexandre
|
