F5 Viprion bit size hash bit size in hardware for LACP
Dear all, For optimal traffic distribution accross links inside a Trunk / LACP port channel it is important to know what bit size is used built inside the F5 hardware As explained here a comparison between 3-bit and 8-bit where the first one is optimized for 2, 4 or 8 links the the 8-bit can be used for almost equal link distribution when using 6 links inside the Trunk. https://www.packetmischief.ca/2012/07/24/doing-etherchannel-over-3-5-6-and-7-link-bundles/ I suppose the F5 hardware uses 3-bit hashing size built inside the Viprion hardware, but can someone confirm? Is it perhaps adjustable by perhaps using a database variable to switch between 3-bit and 8-bit? The following article explains the hashing methods but it does not provide information about bit-size. https://support.f5.com/csp/article/K13562
URL PATH HASHING
how could i hash the url:: path for a vip by default client access the site as www.mysite.com/admin , i just wanna make the url path is hashed to client as www.mysite.com/ i created an irule as when HTTP_RESPONSE { [CRYPTO::hash -alg sha384 [HTTP::path]] { } } but it didn`t work with me...
HTTP Redirect persistence logic
Hello! 1) The client comes into the first VIP (SSL offload) and picks a MEM-ID server. Let's say MEM-ID-SRV01. It then talks to Service-SRV-01. The client wants all future connections to stay in the same color servers. (The connections to the back end service srv's are a direct connection (not through the LB). 2) MEM-ID-SRV01 will send a redirect back to the client to go to the other VIP(SSL offload). But the requirement is that the request will go to OLB-SRV-01 in this case. Is it best to have the MEM-ID-SRV01 send a specific header or append a unique HTTP path to the redirect back to the client? Then have the 2nd VIP have irule logic to send it to the specific server, or is there a way to create a hash value on the F5 during the initial LB selection and make sure that hash value gets appended to the MEM-ID-SRV redirect back to the client. (This 2nd option would prevent work done on the MEM-ID Servers) Thanks!
