Forum Discussion
ssam_189734
Nimbostratus
NimbostratusWild card virtual servers ?
Can anyone pls help me in understanding the wildcard virtual servers with an example ? when it is used ?
Wildcard VS are useful when the destination is unknown (any). I will give you two examples, but they are virtually unlimited depending on your use case.
What if you have servers in your infrastructure that needs to connect to the Internet to download binaries using HTTP and your BIG-IP is their gateway ? Also, you need to load balance through 2 ISP with your BIG-IP when going to the Internet. To allow the traffic through, you could use a Wildcard VS 0.0.0.0:80, disable Address Translation and load balance through a pool of gateways (ISP).
Another example could be, you are loadbalancing forward proxy caching device and you want to ensure that for the same destination, you use the same caching proxy (a pool member in this case) (so a.com requests are only cached on cache1 and not others to avoid cache duplicates). Clients requests various websites a.com, b.com etc... that resolves to various IP addresses 1.1.1.1, 2.2.2.2 ; to allow that traffic through you will need a 0.0.0.0:* VS in place and you may use a destination address persistence profile to achieve the requirement. Connection to 1.1.1.1 is allowed and loadbalanced to cache 1; you set a persistence record. Future requests to 1.1.1.1 will persist to cache 1.
In the end, it's just an 'any' destination that needs processing in your BIG-IP.
Wildcard VS are useful when the destination is unknown (any). I will give you two examples, but they are virtually unlimited depending on your use case.
What if you have servers in your infrastructure that needs to connect to the Internet to download binaries using HTTP and your BIG-IP is their gateway ? Also, you need to load balance through 2 ISP with your BIG-IP when going to the Internet. To allow the traffic through, you could use a Wildcard VS 0.0.0.0:80, disable Address Translation and load balance through a pool of gateways (ISP).
Another example could be, you are loadbalancing forward proxy caching device and you want to ensure that for the same destination, you use the same caching proxy (a pool member in this case) (so a.com requests are only cached on cache1 and not others to avoid cache duplicates). Clients requests various websites a.com, b.com etc... that resolves to various IP addresses 1.1.1.1, 2.2.2.2 ; to allow that traffic through you will need a 0.0.0.0:* VS in place and you may use a destination address persistence profile to achieve the requirement. Connection to 1.1.1.1 is allowed and loadbalanced to cache 1; you set a persistence record. Future requests to 1.1.1.1 will persist to cache 1.
In the end, it's just an 'any' destination that needs processing in your BIG-IP.
dragonflymrCirrostratus
Hi, That's very useful example. I have some doubts if I understand second example correctly. So you have setup like that: Client (internal LAN with def gateway set to LTM) -> WIidcard VS -> forward proxies (in pool set for wildcard VS) - Am I correct? There are many forward proxies in a pool and (in this example) each should server requests for given TLD like one for .com, other for .org etc. Then you mentioned using Destination Address persistence to always direct request for .com url's to the same forward proxy - that part I can't figure out. If client is requesting page www.something.com this is resolved to some IP that is used as des.IP for HTTP request, when this request is processed by VS persistence record will be created based on this des.IP but how this is mapped to correct TLD so all request with different dst.ip for .com urls are directed to the same forward proxy? Piotr- Did not mean to add more confusion to this, but this could be a real scenario where you'd use wildcard VS. In this second example, you'd need Destination Address persistence profile to map a destination IP address to a Pool member. It has nothing to do with TLD. Here is a dummy example: Client tries http://www.f5.com . www.f5.com resolves to 5.6.7.8. Client opens a TCP connection to 5.6.7.8:80 and sends packet to LTM self/floating IP (it's default gateway). LTM handles the connection because it's configured with a 0.0.0.0:0 VS and the VS is configured with Address translation disabled and destination address persistence profile. LTM load balances to Caching server Pool -Pool member 1 (it 'forwards' the packet to Pool member 1 MAC Address but does not alter the destination IP address (which remains 5.6.7.8), this is why you need Address translation disabled, otherwise you'd send the packet TO the pool member and not THROUGH). A persistence record is created with : destination IP Address 5.6.7.8 and pool member 1. Subsequent connections through this wildcard VS to 5.6.7.8 will be sent through pool member 1. Hope that makes sense. Salim
- dragonflymrYes, it makes perfect sense, I know more ore less tjis kind of configs (and why Addr Translation has to be disabled - took me a while to figure it out :-). What was a puzzle for me was how to use dest addr persistence to map connections to given TLD to the same proxy server :-) If this is unrelated then of course mapping given dest ip aways to the same pool member via dest addr persistence makes perfect sense. Anyway what would you suggest for sticking given TLDs or SLDs to the same proxy? Using CARP for example? Using part of host name like for a.com,b.com use .com as a base for hash? Piotr
- You could use universal persistence and persist on the TLD with an iRule based on HTTP Host header value. You'd end up with entries in a table in memory (with timeout), but there aren't that many TLDs out there anyway that I'd be concerned.
- dragonflymrThanks! Sure for TDLs that will not be a lot but going more granular I guess it's better to use CARP? Or there is some reason why CARP can't be used for that? Piotr
- Hash CARP persistence could be used to have no persist-records in memory (stateless).