iRule redirect URI to another pool

Maybe normalize the URI to lower case?

when HTTP_REQUEST {
  if { [string tolower [HTTP::uri]] starts_with "/video" } {
    pool Video_pool
  }
}

In general, as the following recipe explains, HTTP::path is the right choice for this type of selection and case normalization is typically not desirable:

• iRule Recipe 1: Single URL Explicit Redirect

However, that doesn't answer your question. I recommend implementing this rule:

when HTTP_REQUEST { 
    log local0. "PATH = (HTTP::path)"
    if { [HTTP::path] starts_with "/video" } { 
        log local0. "  .. starts_with /video"
        pool Video_pool 
    }
}

Assuming the rule is executed at all, the first message should be logged on each request. It will also tell you what the extracted HTTP::path is. The second message should be logged only if there is a match. From here, you may be able to see what's occurring. If not, can you share which of these is ending up in the log?

My apologies. I forgot square braces around the logged HTTP::path. The code should be:

when HTTP_REQUEST { 
    log local0. "PATH = ([HTTP::path])"
    if { [HTTP::path] starts_with "/video" } { 
        log local0. "  .. starts_with /video"
        pool Video_pool 
    }
}

In any case, it appears that you are occasionally matching, so at least in those cases, the rule is doing what you instruct. What suggests that it is failing? You mention a "404". I presume that the default pool members don't host anything at /video/*. Are you certain that Video_pool has at least one member that is up and that you are not using persistence on the flow?

You may try adding this:

when LB_FAILED {
    log local0. "Trapped LB_FAILED from client [IP::client_addr]"
}

which will be raised if the pool call fails to select a pool member.

I'm sure you're already aware of this, but that response is coming from one of your servers. Presumably, the issue here is whether it's coming from the server in the Video_pool. There are several ways to figure that out. One is to use tshark on the BIG-IP:

tshark -nni 0.0 host 

where is the IP address of your client. If you are using SNAT, then you need to do something like this:

tshark -nni 0.0 host  or host 

where is the IP address of your Video_pool pool member. If you see a client-side connection followed by a server-side connection, then requests are going to that server. If you want to find out exactly what the server is responding with, you can use tshark:

tshark -nni 0.0 host 

(again, add the clause if you are using SNAT).

In my setup, my client is 10.11.218.200 and my pool member is 10.10.218.200. Here is what a transaction may look like:

  0.000000 10.11.218.200 -> 10.11.218.100 TCP 85 33418 > 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=350747607 TSecr=0 WS=128
  0.000149 10.11.218.100 -> 10.11.218.200 TCP 103 80 > 33418 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 TSval=517489230 TSecr=350747607 SACK_PERM=1
  0.001592 10.11.218.200 -> 10.11.218.100 TCP 95 33418 > 80 [ACK] Seq=1 Ack=1 Win=29200 Len=0 TSval=350747607 TSecr=517489230
  0.001732 10.11.218.200 -> 10.10.218.200 TCP 103 33418 > 80 [SYN] Seq=0 Win=4380 Len=0 MSS=1460 TSval=517489231 TSecr=0 SACK_PERM=1
  0.002857 10.11.218.200 -> 10.11.218.100 HTTP 178 GET /video/ HTTP/1.1
  0.002998 10.11.218.100 -> 10.11.218.200 TCP 95 80 > 33418 [ACK] Seq=1 Ack=84 Win=4463 Len=0 TSval=517489233 TSecr=350747607
  0.003297 10.10.218.200 -> 10.11.218.200 TCP 99 80 > 33418 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=350747608 TSecr=517489231
  0.003326 10.11.218.200 -> 10.10.218.200 TCP 95 33418 > 80 [ACK] Seq=1 Ack=1 Win=4380 Len=0 TSval=517489233 TSecr=350747608
  0.003358 10.11.218.200 -> 10.10.218.200 HTTP 178 GET /video/ HTTP/1.1 
  0.004821 10.10.218.200 -> 10.11.218.200 TCP 95 80 > 33418 [ACK] Seq=1 Ack=84 Win=28960 Len=0 TSval=350747608 TSecr=517489233
  0.005120 10.10.218.200 -> 10.11.218.200 HTTP 539 HTTP/1.1 404 Not Found  (text/html)
  0.005132 10.11.218.100 -> 10.11.218.200 HTTP 539 HTTP/1.1 404 Not Found  (text/html)
  0.005134 10.11.218.200 -> 10.10.218.200 TCP 95 33418 > 80 [ACK] Seq=84 Ack=445 Win=4824 Len=0 TSval=517489235 TSecr=350747608
  0.006469 10.11.218.200 -> 10.11.218.100 TCP 95 33418 > 80 [ACK] Seq=84 Ack=445 Win=30016 Len=0 TSval=350747609 TSecr=517489235
  0.006474 10.11.218.200 -> 10.11.218.100 TCP 95 33418 > 80 [FIN, ACK] Seq=84 Ack=445 Win=30016 Len=0 TSval=350747609 TSecr=517489235
  0.006494 10.11.218.100 -> 10.11.218.200 TCP 95 80 > 33418 [ACK] Seq=445 Ack=85 Win=4463 Len=0 TSval=517489236 TSecr=350747609
  0.006500 10.11.218.200 -> 10.10.218.200 TCP 95 33418 > 80 [FIN, ACK] Seq=84 Ack=445 Win=4824 Len=0 TSval=517489236 TSecr=350747608
  0.008038 10.10.218.200 -> 10.11.218.200 TCP 95 80 > 33418 [FIN, ACK] Seq=445 Ack=85 Win=28960 Len=0 TSval=350747609 TSecr=517489236
  0.008078 10.11.218.200 -> 10.10.218.200 TCP 95 33418 > 80 [ACK] Seq=85 Ack=446 Win=4824 Len=0 TSval=517489238 TSecr=350747609
  0.008081 10.11.218.100 -> 10.11.218.200 TCP 95 80 > 33418 [FIN, ACK] Seq=445 Ack=85 Win=4463 Len=0 TSval=517489238 TSecr=350747609
  0.009381 10.11.218.200 -> 10.11.218.100 TCP 95 33418 > 80 [ACK] Seq=85 Ack=446 Win=30016 Len=0 TSval=350747609 TSecr=51748923

The most interesting lines are these:

...
  [1] 0.002857 10.11.218.200 -> 10.11.218.100 HTTP 178 GET /video/ HTTP/1.1
...
  [2] 0.003358 10.11.218.200 -> 10.10.218.200 HTTP 178 GET /video/ HTTP/1.1 
...
  [3] 0.005120 10.10.218.200 -> 10.11.218.200 HTTP 539 HTTP/1.1 404 Not Found  (text/html)
  [4] 0.005132 10.11.218.100 -> 10.11.218.200 HTTP 539 HTTP/1.1 404 Not Found  (text/html)
...

The first line is the client's request arriving at the BIG-IP Virtual Server. The second is the BIG-IP proxying the request to the pool member. The third is the pool member responding with a 404, and the fourth is the BIG-IP proxying it to the client.

Of course, what you want to look for is whether requests that match your rule are going to the expected pool member, and if so, what the pool member's response is.

A second way to figure this out is to extend the iRule again. Now, it would look something like this:

when HTTP_REQUEST { 
    if { [HTTP::path] starts_with "/video" } {
        log local0. "Ingress request starts_with /video"
        set video_match 1
        pool Video_pool 
    }
}

when HTTP_RESPONSE {
    if { [info exists video_match] } {
        log local0. " .. Response is from: [IP::server_addr] and HTTP Status Code is [HTTP::status]"
    }
}

This will tell you the IP address from which the response is arriving. It should produce results like this:

Nov  1 00:54:52 b218 info tmm2[18014]: Rule /Common/log-result : Ingress request starts_with /video
Nov  1 00:54:52 b218 info tmm2[18014]: Rule /Common/log-result :  .. Response is from: 10.10.218.200 and HTTP Status Code is 404

I don't see the server-side of the connection in your trace. I suspect your pcap filter is too restrictive, perhaps because you are using SNAT on the Virtual Server. The server-side is critical to seeing what's happening.

By the way, you may consider reaching out to your F5 account SE to see if he or she may be able to assist you directly.

I asked about the SNAT because that explains why the server-side doesn't show up in the tshark output. You would need to add a host pcap filter for the SNAT address that is used.

Contacting Support is a good step. Do let us know how it goes.

I'm very pleased to hear it is working. Happy F5ing! :)