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
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
