iRule redirect URI to another pool

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