yes, that is configured, one has a higher priority then the other. But
the issue is, if the one with the highest priority is "non-healthy" and
the one with the lowest is "healthy". I expected that the lowest
priority would become owner of the vip, but that seams not the case
arne
Please have a look at dynamic priorities - they are there to help you
to force the VIP to fail to the other SI in case something goes wrong.
The VIP is always linked to a single SI only and that is the one with
the higher sym-prio.
R, Oliver
At 10:15 05.09.2008, arne van theemsche wrote:
Hi
last night we had an issue with our redundant setup of 2 serverIrons.
We have a virtual IP configured on both serverirons, with VIP health
injection into ospf. Both serverirons are connected to the same
servers. and the sym-active setup is working and has prooved it's use
before.
For some reason (which is still unclear and irrelivant here) the
server iron which was master for this VIP decided the VIP was
unhealthy. The backup found the vip healthy. But due to the fact that
he was the "non-owner" he didn't inject the VIP into OSPF
if you read the manual
"Symmetric and sym-active topologies — In both symmetric and
sym-active topologies, only the owner of
the VIP (the VIP in the ACTIVE state) will inject the route. In this
topology, the ServerIron will withdraw the VIP
route when a VIP transitions from Active to Standby state. Similarly,
the ServerIron will inject the VIP route
when a VIP transitions from Standby to Active, if the VIP is healthy
at the time of the transition."
this makes logic.
You only read such articles if you've had an issue offcoure :(
I myself find this a little disapointing. Offcourse the sym-active is
there to allow failures of serverirons. But I was also in the
assumption (ok ok, never assume) that if 1 serveriron sees the VIP
healthy and the other not, the state would also change to the backup
serveriron, to he becomes the owner.
Am I seeing thins wrong this way?
kind regards
Arne
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
