[f-nsp] multiple service failover

[Oliver Adam]

It is not necessary to include the ports 8080 and 4443 into the 
hc-track-group - these ports are independent from the others and they 
are not used for production traffic.

Moving to move complex solutions implies as well to stay at a config 
which is most probably not as often used and tested as others :-)

An interesting question  would be of course if you are running at a 
release which is fine... there were some health checking issues 
talking about track groups in the past but they are fixed now if I am 
not wrong.
10.2.01 is a good code stream - I am personally using 10.2.01g and 
10.2.01h pretty heavily.

All I can think of is that there was a problem with stickiness and 
the fact that port 443 was still available from a health checking 
point of view. This should not happen but you can remove stickiness 
anyway because it is a single server you are working with which is 
active at a time if I am not wrong.

R, Oliver

At 18:27 15.07.2009, David Miller wrote:
>Oliver Adam wrote:
>>Do you have any traces from the time the problem occured? The 
>>config itself seems to be fine - testing this quickly at a 4G 
>>result in log messages like:
>>
>>Dynamic Log Buffer (50 lines):
>>Jul 15 16:56:34:N:L4 server 192.168.9.101 rs101 port 80 is down due 
>>to healthcheck
>>Jul 15 16:56:34:C:Real server rs101 track group 80 443  state 
>>changed from ACTIVE to DOWN
>>Jul 15 16:49:45:N:L4 server 192.168.9.101 rs101 port 80 is up
>>Jul 15 16:49:45:C:Real server rs101 track group 80 443  state 
>>changed from DOWN to ACTIVE
>
>Unfortunately, the logs are gone:(
>
>>The track group is working as expected. Is it anyhow possible that 
>>you had problems with sessions which were open already at the time 
>>the problem occured? The SI is not going to cut all the sessions 
>>hardly by default. Have a look at "reset-on-port-fail" as an option 
>>in this area.
>
>Interesting.  Why would they have a default behavior that keeps 
>connections tied to a port/server that's failed a health check?  But 
>I digress, that doesn't appear to be the problem I had.  Upon 
>hearing of the ports being split between the two servers I connected 
>and verified that news connections for http went to server2 while 
>ssl remained on server 1.
>
>
>>On top of that I am confused because you are using healthck's why 
>>do not you do it this way:
>>
>>
>>>server real server1 192.168.0.60
>>>source-nat access-list 1
>>>port http
>>>port http url "GET /status.html"
>>>port http content-match Content_Match
>>>port ssl
>>>port ssl keepalive
>>>port ssl l4-check-only
>>>port 8080
>>>port 9000
>>>port 4443
>>>hc-track-group 80 443
>>
>>
>>No healthck needed - much shorter and simple to understand - same behaviour.
>
>I'm a rookie with the foundry/brocade equipment and inherited the 
>configuration I posted.  There may be simpler ways to do many things.
>
>With these bind statements:
>
>bind http server1 8080 real-port http server2 8080 real-port http
>bind ssl server1 4443 real-port ssl server2 4443 real-port ssl
>
>is it necessary to add 8080 and 4443  to the hc-track-group ?
>
>
>
>>Please ensure you do have "server no-fast-bringup" in the config - 
>>this is to ensure the health check is only successful in case 
>>everything up to L7 is working.
>
>
>I do have that.
>
>>Something to look at in the future: http://community.brocade.com/adi
>
>Looks interesting.
>
>Thanks Oliver