Forum Discussion
Allen_Yu_168758
Nimbostratus
NimbostratusRedirecting iRule by URL depth
Hi, There is a request from our biz users that redirecting packets according URL depth, just wondering if it can be achieved by iRule.
Much appreciate if anyone's feedback.
Example: the request uri to this domain will be a n-level depth path e.g. http://ws-im.xxx.com/xxx/im/123/456/xxxxxx The first 3-level path (""/im/123/456"" in this case) identifies a unique client request, which requires the http load balancer can redirect this request to the same backend server every time.
12 Replies
Yann_Desmarest_Nacreous
Hi,
You can do this using irule and universal persistence. I found a devcentral post that talk about your need. Maybe you can take the irule example provided to define your own :
https://devcentral.f5.com/questions/uri-session-id-based-persistence-issue
tpts6Hi Yann Recently I also have same request from customer on this case. But I'm curious, how to resolve if the case depend on "URI-Depth" not "URI-Path" or "URI-Session-id-based". In HAPorxy case, we can do this by declaring "balance uri depth 3" in the configuration file (as described in this article, the "uri" section: http://www.onaxer.com/tag/load-balancing-algorithm-in-haproxy-to-be-used-in-a-backend/). But, as of now the request need to do in on F5 SLB. Appreciate if you could help or any ideas/suggestions.
Yann_DesmarestCirrus
Hi,
You can do this using irule and universal persistence. I found a devcentral post that talk about your need. Maybe you can take the irule example provided to define your own :
https://devcentral.f5.com/questions/uri-session-id-based-persistence-issue
- tpts6Hi Yann Recently I also have same request from customer on this case. But I'm curious, how to resolve if the case depend on "URI-Depth" not "URI-Path" or "URI-Session-id-based". In HAPorxy case, we can do this by declaring "balance uri depth 3" in the configuration file (as described in this article, the "uri" section: http://www.onaxer.com/tag/load-balancing-algorithm-in-haproxy-to-be-used-in-a-backend/). But, as of now the request need to do in on F5 SLB. Appreciate if you could help or any ideas/suggestions.
- Yann_Desmarest_
Hi,
try this one instead, just tested and found I had an issue with the previous one :
when HTTP_REQUEST { set lb_depth 0 set lb_len 0 set timeout 3600 set path [string tolower [HTTP::path]] set depth [URI::path $path depth] define the depth of the path for hash calculation if { $depth < $lb_depth } { set depth_path [URI::path $path 1 $lb_depth] } else { set depth_path [URI::path $path 1 $depth] } set len [string length $depth_path] define the chars length to be processed for hash calculation if { $lb_len > 0 and $lb_len < $len } { binary scan [sha1 [string range $depth_path 0 $lb_len-1]] w1 key } else { binary scan [sha1 $depth_path] w1 key } persist uie $key $timeout }- tpts6Hi Yann Many thanks for your reply. And I really sorry ask more as below : May I have one more question ? If the condition also consideration for pool selection by match domain. Should we merge into same irule or split two ? For example : When access to https://www.abc123.com/111-xxx/222-yy/333-z/nnnnn if match www.abc.123.com then select pool_123 "AND" match depth eq 3 (/111-xxx/222-yy/333-z in this case) then redirect this request to the same node(backend server) everytime. When access to https://www.xyz456.com/444/555/666/mmmmm if match www.xyz456.com then select pool_456 "AND" match depth eq 3 (/444/555/6666 in this case) then redirect this request to the same node(backend server) everytime. elseif match www.qaz789.com then select pool_789 elseif macth www.wsx000.com then select pool_000 ***Note : only match www.abc123.com and www.xyz456.com apply "depth eq 3" rule.***
- Yann_Desmarest_Looks like pool and depth selection are linked by hostname, so yes would be good to merge into one irule. This avoid you to set the same "if/else" conditions on several irules
- tpts6Thanks for your advice !! ^^ I will keeping study syntax how to merge into one irule or try another workaround. Due to developer/vendor have no idea on F5-irule, but they are not prefer to implement on backend servers.
- Yann_Desmarest
Hi,
try this one instead, just tested and found I had an issue with the previous one :
when HTTP_REQUEST { set lb_depth 0 set lb_len 0 set timeout 3600 set path [string tolower [HTTP::path]] set depth [URI::path $path depth] define the depth of the path for hash calculation if { $depth < $lb_depth } { set depth_path [URI::path $path 1 $lb_depth] } else { set depth_path [URI::path $path 1 $depth] } set len [string length $depth_path] define the chars length to be processed for hash calculation if { $lb_len > 0 and $lb_len < $len } { binary scan [sha1 [string range $depth_path 0 $lb_len-1]] w1 key } else { binary scan [sha1 $depth_path] w1 key } persist uie $key $timeout }- tpts6Hi Yann Many thanks for your reply. And I really sorry ask more as below : May I have one more question ? If the condition also consideration for pool selection by match domain. Should we merge into same irule or split two ? For example : When access to https://www.abc123.com/111-xxx/222-yy/333-z/nnnnn if match www.abc.123.com then select pool_123 "AND" match depth eq 3 (/111-xxx/222-yy/333-z in this case) then redirect this request to the same node(backend server) everytime. When access to https://www.xyz456.com/444/555/666/mmmmm if match www.xyz456.com then select pool_456 "AND" match depth eq 3 (/444/555/6666 in this case) then redirect this request to the same node(backend server) everytime. elseif match www.qaz789.com then select pool_789 elseif macth www.wsx000.com then select pool_000 ***Note : only match www.abc123.com and www.xyz456.com apply "depth eq 3" rule.***
- Yann_DesmarestLooks like pool and depth selection are linked by hostname, so yes would be good to merge into one irule. This avoid you to set the same "if/else" conditions on several irules
- tpts6Thanks for your advice !! ^^ I will keeping study syntax how to merge into one irule or try another workaround. Due to developer/vendor have no idea on F5-irule, but they are not prefer to implement on backend servers.
