Forum Discussion
CirrostratusMultiple HOSTS -> Single VIP -> iRule routing to other Virtuals
In our environment, we're limited on the number of external IP addresses we can use. As we are adding additional applications that we want to deliver, we're setting up an environment where multiple hosts on a given domain will go to the same IP address that routes to a VIP, and then an iRule will route those requests to alternate VIPS based on the hostname.
I just wanted to know if anyone else is doing something similar and has uncovered any problems with this type of design.
So our design would look like this:
APP1 --> VIP --[iRule]--> APP1_VIP
APP2 --> VIP --[iRule]--> APP2_VIP
...
APPn --> VIP --[iRule]--> APPn_VIP
5 Replies
Apache1048_5684Nimbostratus
If I get what you are trying to do, conserve IP addresses by using a single external IP routing to multiple pools you can do that easily enough as follows.
when HTTP_REQUEST { switch [HTTP::host] { host1.example.com { pool poolname1 } host2.example.com { pool poolname2 } ... ... default { reject } } }
We do this in production with a self imposed rule of 10 sites per external IP - each of which has 3 servers per pool. This is not a hard and fast rule, just an arbitrary number we chose.
Sheigh_65772Cirrus
We have used this successfully when using the webgate feature using one external facing VIP that then forwarded to multiple internal VIPs based upon the [HTTP::host].
In this setup our external VIP had the client ssl profile (requires a wildcard cert ie *.abc.com) and then the internal VIPs were configured as the webgates.
- Sheigh_65772
I shouldn't say requires a wildcard cert as thats no longer the case but that's how I set it up.
Michael_JenkinsThat's how we're doing it as well, with wildcard certs. And our load won't be more than a few thousand connections a second, so my assumption is that we won't see any huge performance degradation because of this. It's a much simpler way to handle things than trying to get a bunch of additional public IPs.
- nitass
Employee
i used it because different virtual server type and profile are needed. the drawback are, obviously, it consumes more resource and connection mirroring is not supported.
sol14180: The connection mirroring feature is not compatible with VIP-targeting-VIP configurations
https://support.f5.com/kb/en-us/solutions/public/14000/100/sol14180.html
