CHANGE THE HOST NAME IF THE CONNECT IS A POOL MEMBER

You'll want to use either the HTTP_REQUEST_SEND or HTTP_REQUEST_RELEASE events, as these are triggered after the load balancing decision. Here's an example:

when HTTP_REQUEST_RELEASE {
    switch [LB::server addr] {
        "10.70.0.1" {
            HTTP::header replace Host "server1.internal.local"
        }
        "10.70.0.2" {
            HTTP::header replace Host "server2.internal.local"
        }
    }   
}

It is very interesting, but I need to add to other point,

When client set www.ejemplo.com/home/otro the irule found the word "home" and send the traffic a pool "home" and in this case if the connect is a pool member X, I re-writting the URL with http://server1:14002/home/other/site/same and if the connect is a pool member Y, I re-writting the URL with http://server2:14002/home/other/site/same.

In this case the load balancing changed the destine port destine, uri and hostname.

So if I understand you correctly, you're evaluating the URI to send to a pool, and you do this in the HTTP_REQUEST event. The LB events are triggered next and a pool member is selected. By the time you get to the HTTP_REQUEST_RELEASE event, you've already chosen a pool, selected a pool member, and can now alter the Host header going to that server based on the provided information.

when HTTP_REQUEST {
    if { [HTTP::uri] starts_with "/home" } {
        pool home_pool
    } else {
        pool other-pool
    }
}
when HTTP_REQUEST_RELEASE {
    switch [LB::server addr] {
        "10.70.0.1" {
            HTTP::header replace Host "server1:14002"
        }
        "10.70.0.2" {
            HTTP::header replace Host "server2:14002"
        }
    }   
}

If you also need to change the URI path, that can be done in either HTTP event with the HTTP::uri command. The ":14002" in the above is part of the Host header. Actual ports are defined in the individual pools and the VIP's port translation setting.

I wrote the next irule:

when HTTP_REQUEST {

switch -glob [string tolower [HTTP::uri]] { 

    "/swscersalud*" {         

        pool Pool_Consorcio_test

        set VARIABLE[string map -nocase {"/swscersalud/wscersalud.asmx" "/Services/Utility/certificacionSalud/WS/Implementation/Service.serviceagent/WSCERSALUDSoapEndpoint"} [HTTP::uri]]

        HTTP::uri $VARIABLE

        log local0. "Ingreso al swscersalud [HTTP::uri]"
        }

    "/wsconadmo*" {

        log local0. "Ingreso al wsconadmo [HTTP::uri]"

        set VARIABLE[string map -nocase {"/Wsconadmo/OyS.asmx" "/Services/Utility/OyS/WS/Implementation/WSCONADMO.serviceagent/OySSoapEndpoint"} [HTTP::uri]]

        HTTP::uri $VARIABLE

        pool Pool_Consorcio_test_V2

            }

    }

}

when HTTP_REQUEST_SEND {

switch [LB::server addr] {

    "10.237.146.1" {

        HTTP::header replace Host "vmpesbserver:14002"
    }
    "10.237.146.2" {

        HTTP::header replace Host "vmpesbserver2:14002"

    }

}   

}

Is this right? In the LTM the event HTTP_REQUEST_RELEASE is no found the version is 10.2.4

Ahh, yes the HTTP_REQUEST_RELEASE event was not available in v10. For the HTTP_REQUEST_SEND event, you'll need to explcitly call out the clientside context:

when HTTP_REQUEST_SEND {
    switch [LB::server addr] {
        "10.237.146.1" {
            clientside {
                HTTP::header replace Host "vmpesbserver:14002"
            }
        }
        "10.237.146.2" {
            clientside {
                HTTP::header replace Host "vmpesbserver2:14002"
            }
        }
    }   
}

Hi Kevin Stewart

I test the irule and the answer is good on client1 but client2 is bad, I changed the irule by see the events when client wrote the url, because I added instructions for generation the logs

when HTTP_REQUEST {

switch -glob [string tolower [HTTP::uri]] { 

    "/swscersalud*" {         
                    pool Pool_Consorcio_test
        log local0. " original [HTTP::uri]"
        HTTP::uri "/Services/Utility/certificacionSalud/WS/Implementation/Service.serviceagent/WSCERSALUDSoapEndpoint"
        log local0. "modificado [HTTP::uri]"
        }
    "/wsconadmo*" {
        log local0. "Ingreso al wsconadmo [HTTP::uri]"
        HTTP::uri "/Services/Utility/OyS/WS/Implementation/WSCONADMO.serviceagent/OySSoapEndpoint"
        pool Pool_Consorcio_test_V2
            }
    }

}

I saw the logs

Jul 25 09:48:27 local/tmm info tmm[4913]: Rule irule_consorcio_v5 : Ingreso al swscersalud sin modificar /swscersalud/wscersalud.asmx Jul 25 09:48:27 local/tmm info tmm[4913]: Rule irule_consorcio_v5 : Ingreso al swscersalud con modificacion /swscersalud/wscersalud.asmx Jul 25 09:48:29 local/tmm info tmm[4913]: Rule irule_consorcio_v5 : Ingreso al swscersalud sin modificar /swscersalud/wscersalud.asmx Jul 25 09:48:29 local/tmm info tmm[4913]: Rule irule_consorcio_v5 : Ingreso al swscersalud con modificacion /swscersalud/wscersalud.asmx Jul 25 09:48:30 local/tmm info tmm[4913]: Rule irule_consorcio_v5 : Ingreso al swscersalud sin modificar /swscersalud/wscersalud.asmx Jul 25 09:48:30 local/tmm info tmm[4913]: Rule irule_consorcio_v5 : Ingreso al swscersalud con modificacion /swscersalud/wscersalud.asmx Jul 25 09:48:30 local/tmm info tmm[4913]: Rule irule_consorcio_v5 : Ingreso al swscersalud sin modificar /swscersalud/wscersalud.asmx Jul 25 09:48:30 local/tmm info tmm[4913]: Rule irule_consorcio_v5 : Ingreso al swscersalud con modificacion /swscersalud/wscersalud.asmx Jul 25 09:48:31 local/tmm info tmm[4913]: Rule irule_consorcio_v5 : Ingreso al swscersalud sin modificar /swscersalud/wscersalud.asmx Jul 25 09:48:31 local/tmm info tmm[4913]: Rule irule_consorcio_v5 : Ingreso al swscersalud con modificacion /swscersalud/wscersalud.asmx

in this log the uri does not change and I don't understand why the URL not change on server2's test, and in the cliente2 gotten the error 404.

There's probably a few things going on here:

1. In versions of v10 (not sure when it changed) the HTTP::uri command does not update the filter cache to show the new value. So if you set a new value with HTTP::uri, and then go and read it with HTTP::uri, you'll get the original value. The URI is still changing for the traffic itself though. You can get around this in your logging by setting and using a variable instead.

    

2. I would add a log statement at the beginning of your HTTP_REQUEST event to show the actual URI request. You may not be catching it because it's not what you think it is.

    

ok Thanks for your time