[f-nsp] bucket reassignment on failed health-check

Oliver Adam oadam at madao.de
Fri Aug 29 11:24:27 EDT 2008


The ServerIron is going to reassign stuff only in case there are NO 
free hash buffers. How is the hash buffer usage in your setup? Are 
all buffers getting used? If not you will have to use "server 
persist-hash-treshold x" globally to change the behaviour.

R, Oliver

At 11:31 29.08.2008, arne van theemsche wrote:
>Dear group
>
>this is the 2nd problem we have on our foundry setup
>
>we are using a VIP with persistent hash buckets (IP gets translated 
>to value between 1-255, and value is assigned to real server)
>
>each real server has a health-check policy assigned to it.
>
>Meaning is, that if a health check fails (not only if the server or 
>port fails) the buckets assigned to the real server get removed (this is ok)
>if a healthcheck returns to a true value (server can be attached 
>again to the VIP) we want the existing buckets to be reassigned to 
>get a equal load. This is not done. Acutally notthing is done, we 
>have to manually do a "port http clear-persist-hash-buckets"
>
>the default behaviour is to reassign on change, but am I missing something?
>
>relevant info below
>
>
>
>server l7-hashing-bucket-reassign
>server persist-hash-threshold 80 ### high number, are actually 12 
>servers attached
>
>healthck U1 tcp
>  dest-ip 192.168.x.y
>  port http
>  protocol http
>  protocol http url "GET /check.htm"
>  protocol http content-match webcontent
>  l7-check
>
>server remote-name U1 192.168.x.y
>weight 1 0
>port http
>port http healthck U1
>port http url "HEAD /"
>
>server virtual UPL-VIP 5.6.7.8
>sym-priority 200
>sym-active
>predictor round-robin
>port http
>port http persist-hash
>bind http U1 http U3 http U2 http U4 http
>
>
>  SW: Version 10.0.00bTD4 Copyright (c) 1996-2007 Foundry Networks, Inc.
>      Compiled on Aug 04 2007 at 13:40:20 labeled as WXR10000b
>  HW: ServerIronGT C-Series Router, SYSIF version 21, Serial #: Non-exist
>==========================================================================
>SL 1: WSM6-SSL Management Module, SYSIF 2, M6, ACTIVE
>      Serial #:
>    0 MB SHM, 1 Application Processors
>16384 KB BRAM, SMC version 5, BM version 21
>  SW: (1)10.0.00bTF3
>==========================================================================
>SL 2: J-BxGC16 JetCore Gig Copper Module, SYSIF 2
>      Serial #: 4096 KB BRAM, JetCore ASIC IGC version 49, BIA version 8a
>32768 KB PRAM and 2M-Bit*1 CAM for IGC  4, version 0449
>32768 KB PRAM and 2M-Bit*1 CAM for IGC  5, version 0449
>32768 KB PRAM and 2M-Bit*1 CAM for IGC  6, version 0449
>32768 KB PRAM and 2M-Bit*1 CAM for IGC  7, version 0449
>==========================================================================
>SL 3: J-BxGC16 JetCore Gig Copper Module, SYSIF 2
>      Serial #: 4096 KB BRAM, JetCore ASIC IGC version 49, BIA version 8a
>32768 KB PRAM and 2M-Bit*1 CAM for IGC  8, version 0449
>32768 KB PRAM and 2M-Bit*1 CAM for IGC  9, version 0449
>32768 KB PRAM and 2M-Bit*1 CAM for IGC 10, version 0449
>32768 KB PRAM and 2M-Bit*1 CAM for IGC 11, version 0449
>==========================================================================
>Active management module:
>  1.0 GHz Power PC processor 750GX (version 7002/0102) 66 MHz bus
>  512 KB boot flash memory
>16384 KB code flash memory
>  512 KB SRAM
>  512 MB DRAM
>The system uptime is 265 days 20 hours 45 minutes 31 seconds
>The system started at 13:44:55 GMT+01 Fri Dec 07 2007
>
>The system : started=cold start
>
>_______________________________________________
>foundry-nsp mailing list
>foundry-nsp at puck.nether.net
>http://puck.nether.net/mailman/listinfo/foundry-nsp





More information about the foundry-nsp mailing list