Forum Discussion

JustinS_88353's avatar
JustinS_88353
Icon for Nimbostratus rankNimbostratus
Oct 15, 2010

Irule help 302 + maintain URI

I've got a high bandwidth application where I want to use the F5 to monitor a pool of available servers and send requests to them. However, I want to use a 302 redirect (or something else if you know of something better) that will maintain the URI however direct traffic asynchronously to the server to avoid pushing the traffic through the load balancer.

 

 

Round Robin load balancing would be fine. I suspect I have to do this via IRules.

 

 

 

I've got some ideas that I'll start testing out in QA but in the meantime, Suggestions greatly welcomed

 

 

 

Thanks,

 

Justin

 

 

9 Replies

  • I'm thinking something like the following snippet. I'm a total newb and haven't found any documentation yet. This would be where 10.1.1.[1-3] are pool members. being monitored. I'll test this out in the morning when I have some access, however I suspect this is close-ish. Is there anyway around editing the IRules anytime I want to add capacity? Is this even close to right?

     

     

    Thanks again,

     

    Justin

     

     

     

    when HTTP_REQUEST {

     

    switch [LB::select] {

     

    "10.1.1.1." {

     

    HTTP::respond "http://10.1.1.1""[HTTP::uri]"

     

    }

     

    "10.1.1.2." {

     

    HTTP::respond "http://10.1.1.2""[HTTP::uri]"

     

    }

     

    "10.1.1.3." {

     

    HTTP::respond "http://10.1.1.3""[HTTP::uri]"

     

    }

     

     

    }

     

  • Are you looking for feedback on your design as well, or just on how to accomplish this?

    I think you'll have to use your command from the HTTP_RESPONSE event and I believe HTTP::respond from that event can cause some functions to break, so you'll likely want to use header location replace.

    Something like this:

    
    when HTTP_RESPONSE {
      HTTP::header replace "Location" [IP::server_addr] }}
    

  • Hey Justin,

    If I understand you correctly, I think you're looking to effectively outsource the load balancing to the LTM but not have it handle all of the traffic processing. I think that doing this at HTTP_REQUEST rather than HTTP_RESPONSE is probably what you want to do. The HTTP_RESPONSE event means that the request has already been sent to the server and a response has come back. It sounds like you want to avoid this in general. To Chris's point, though, the HTTP::redirect does freak out a little bit in the wrong events. I think your original rule works in very basic structure, but you probably want to use the HTTP::redirect command instead of the respond command ( http://devcentral.f5.com/wiki/default.aspx/iRules/HTTP__redirect.html ).

    Something, then, like this:

    
    when HTTP_REQUEST {  
       switch [LB::select] {  
          "10.1.1.1." {  
             HTTP::redirect "http://10.1.1.1[HTTP::uri]"
          } 
          "10.1.1.2." {  
             HTTP::redirect "http://10.1.1.2[HTTP::uri]"  
          } 
          "10.1.1.3." {  
             HTTP::redirect "http://10.1.1.3[HTTP::uri]"  
       } 
      }

    I'm not sure this will work exactly, I would have to play with it a bit to see. I also think that you could save yourself the trouble of the switch statement by doing something like this (again, completely untested):

    
    when HTTP_REQUEST {
       HTTP::redirect "http://[LB::select][HTTP::uri]"
    }

    Hope this helps!

    \\ Ben

  • Hi Justin,

    It sounds like you want to load balance the requests but not have it handle the outgoing traffic. There is a technique called npath routing which sounds like it's what you need w/o putting in an iRule.

     

     

     

    The nPath method of traffic management increases outbound throughput because packets do not need to be transmitted to the BIG-IP system for translation and forwarding to the next hop.

     

     

     

    Check it out.

     

     

     

    http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip9_2solguide/BIG_IP9_2SolutionsGuide-03-1.html?sr=10627741

     

     

     

     

     

    I hope this helps

     

     

     

    Bhattman

     

  • Ben,

     

    You are correct redirect is more along the lines of what i need. I'll test both of those out. If I can get the latter to work, it will be perfect.

     

     

    Bhattman,

     

    I was looking at NPath routing over the weekend. A couple of caveats are that I don't want to modify anything on the server to support the load balancer. Additionally I'm not clear from my reading yet if NPath routing will also redirect the inbound traffic too. I can't let the heavy eight traffic go through the LB coming or going. I need to do the routing around the LB for got gets and puts.

     

     

    I'll post an update after I get some testing done in QA

     

     

    Thanks,

     

    Justin
  • A question for those of you watching. Also, links to any faqs or Docs would be great. Is LB::select able to be left undefined and it just inherits the pool ID from the pool it is assigned to?

     

     

    Tickle is easy enough, I just don't have clear definition of API and what is defined.

     

     

    Thanks,

     

    Justin
  • Hi Justin,

    Thanks for the additional details about your requirement. Npath routing simply allows the return traffic (outbound) to bypass the F5. As the oubound traffic is your heaviest. If you need the same for inbound it can also be done. Remember inbound/outbound is all relative. From my understanding of your comments above, are you saying that your request traffic (inbound) is as large as the outgoing traffic (return traffic)?

     

     

     

    Bhattman

     

  • when HTTP_REQUEST {

     

    eval [LB::select]

     

    HTTP::redirect "http://[LB::server addr][HTTP::uri]"

     

    }

     

     

     

    Looks like this doe the trick. I'll update after some more testing.
  • When testing with curl use -L to follow new header redirects. Otherwise your test will appear to fail.

     

     

    -- Justin