Forum Discussion
If all you want to do is replace the HTTP Host header on the server-side request, you should be able do this with an iRule but not using BIG-IP configuration data alone.
On the LB_SELECTED event, you can ask the system to return information about the pool member the server-side connection will target, including the name of the pool the member is in, along with the member's IP address and port. Unfortunately, it looks like the FQDN of the underlying node is not accessible from an iRule. However, if you can map an IP address to its associated FQDN, perhaps using a datagroup, then you can have the iRule grab the IP address of the selected member and then use it to obtain the FQDN. For example, here is a small datagroup I set up mapping three node IP addresses to their respective FQDN:
ltm data-group internal node_addr_to_fqdn_mapping {
records {
172.16.20.1/32 {
data wwa.f5trn.com
}
172.16.20.2/32 {
data wwb.f5trn.com
}
172.16.20.3/32 {
data wwc.f5trn.com
}
}
type ip
}
And here is the iRule I used to replace the HTTP Host header:
when LB_SELECTED {
log local0. "HTTP Host header changed from [HTTP::host] to [class match -value [LB::server addr] equals node_addr_to_fqdn_mapping]"
# Replace the HTTP host header with the node's FQDN as found in datagroup
HTTP::header replace host [class match -value [LB::server addr] equals node_addr_to_fqdn_mapping]
}
I tested this on v14.1 using a small web application that we use in our customer-facing training environment, and it produced the following log messages. (I would remove the log command for use in production.)
Nov 23 11:24:25 bigip4 info tmm1[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwa.f5trn.com
Nov 23 15:29:34 bigip4 info tmm1[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwb.f5trn.com
Nov 23 15:29:35 bigip4 info tmm[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwb.f5trn.com
Nov 23 15:29:35 bigip4 info tmm[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwc.f5trn.com
Nov 23 15:29:35 bigip4 info tmm[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwa.f5trn.com
Nov 23 15:29:35 bigip4 info tmm1[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwc.f5trn.com
Nov 23 15:29:35 bigip4 info tmm1[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwa.f5trn.com
Nov 23 15:29:35 bigip4 info tmm1[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwb.f5trn.com
Nov 23 15:29:35 bigip4 info tmm[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwb.f5trn.com
Nov 23 15:29:35 bigip4 info tmm[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwc.f5trn.com
Nov 23 15:29:35 bigip4 info tmm1[9878]: Rule /Common/change_http_header <LB_SELECTED>: HTTP Host header changed from virt.f5trn.com to wwc.f5trn.com
...
You get the idea...
Although it's not the most elegant solution, it works, even if the connection is persisting rather than actually being load balanced.