[f-nsp] sym-active VIP's & state not-healthy

[Oliver Adam]

I am talking about DYNAMIC priotities - I doubt 
this is configured. All you have mentioned so far 
points to fixed priotities. Have a look at
the command dyn-sym-pri-factor below the virtual 
servers. This allows it to define a decrement for 
the sym-priority in case a single service is 
going down (or multiple services). The priority 
should move down to 1 anyway in case ALL services 
are down but this seems to be a problem. Are you 
running at one of the latest patch releases out 
of the 10.0 or 10.2 stream? That is what I would recommend currently.

R, Oliver

At 09:03 08.09.2008, arne van theemsche wrote:
>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
>>>foundry-nsp at puck.nether.net
>>>http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>_______________________________________________
>foundry-nsp mailing list
>foundry-nsp at puck.nether.net
>http://puck.nether.net/mailman/listinfo/foundry-nsp