Forum Discussion
Nishal_Rai
Cirrocumulus
CirrocumulusHow does F5 virtual server forwards request based on LTM policies to another virtual server
Hello Everyone,
- I just wanted to know how the forwarded virtual server (the request forwarded by one VS to another VS using either iRule or LTM policies) works in the context of a TCP in f5 big-ip?
- And on the last forwarded virtual server where the requests are destinated, why don't we need to specify the exact service port of the node on the virtual server service port?
This is the configuration of the virtual server:
VS-LINUX-HTTP
VS-LINUX-HTTP-8080
Used LTM Policies:
The actual client IP - 10.250.250.6
Destinated Virtual Server: 192.168.180.129:80 (VS-LINUX-HTTP)
Forwared to virtual server - 192.168.180.129:8080 (VS-LINUX-HTTP-8080)
Node IP: 192.168.180.226:3000
When the user with IP address 10.250.250.6 destinated to virtual server with IP address 192.168.180.129 listening on port 80, based on the attached LTM policies, all the requests are directed to a virtual server with IP address 192.168.180.129 listening on port 8080. However, the service port listening on node is 3000 on the virtual server - 192.168.180.129:8080
With the packet captured in F5 BIG-IP, there are two SYN packets flagged as IN and OUT from the same source IP: 10.250.250.6, one for the port 80 and the other for the port 8080.
Outgoing SYN: SYN packet initiated by a device (usually a client) to establish a connection with another device (usually a server). Incoming SYN: SYN packet received by a device (usually a server) from another device (usually a client) attempting to establish a connection. |
As per my understanding, on the basis of the wireshark illustration, the client 10.250.250.6 initiated a second TCP connection with the forwarded virtual server 192.168.180.129:8080, right?
I also checked the active connection on the f5 big-ip and correlated it with the packet capture. The f5 big-ip didn't displayed the forwarded virtual server (192.168.180.129:8080) connection as the virtual server address and port only the initial virtual server - 192.168.180.129:80 was displayed.
Regarding the forwarded virtual server 192.168.180.129:8080, we don't necessarily need to configure the actual service port of the node (192.168.180.226:3000) on the virtual server until and unless the actual service port pool is attached to the destinated virtual server, since all the requests will be forwarded to the destinated virtual server.
So I want to know exactly how the forwarded virtual server works in context of a TCP in f5 big-ip? Does it complete its initial TCP handshake with the first destinated virtual server, and based on iRUle or LTM policies, a second TCP connection is initiated with the forwarded virtual server?
- Lucas_Thompson
Employee
Thanks for all the detail, it's really helpful to clarify your question.
The virtual command (or virtual selector in LTM policy) simply switches the virtual server of the existing flow. You can do this at a lot of different time-points. If you do this *before* the client-side flow is created, its properties will be inferred from the virtual server that you switch the flow to. If you do it after, the client-side flow will continue.
The node command should infer the destination TCP port from whatever the destination TCP port is of the server-side flow. You can read about that here:
https://clouddocs.f5.com/api/irules/node.html
Here's an in-depth discussion of big-ip architecture that might help understanding:
If you just want to redirect the user, it's usually a lot easier to just send them an HTTP redirect to the new destination.
- zamroni777
Nacreous
tcp ports of virtual server doesnt have to be the same as pool member's tcp port.
i can have virtual server on port 8881 and pool member A at 8882 and pool member B at 8883.by default, f5 will buffer full payload (tcp/http/etc payload based on profiles assigned to VS) of client side before forwarding to server side and vice versa.
it ensures that only healthy payloads are forwarded to other side.
this also provides some DOS protections againts syn flood, slow loris, etc.for your config, client doesn't create second TCP connection to second VS.
it's simply forwarding within the LTM.
more over, there is no redirection notification mechanism in IP/TCP layer.
there is redirection in HTTP layer using location header but it will break the application flow as http host header and http cookies will be different. - Nishal_Rai
Hello Lucas_Thompson & zamroni777,
Thanks for the insight and information about the virtual server forwarding in f5 big-ip.
Regarding the zamroni777 - for your config, client doesn't create a second TCP connection to second VS.
I verified there is only a single TCP connection between the client and the destinated virtual server (192.168.180.129:80)
So about the statement, it's simply forwarding within the LTM, When viewed from the packet capture on the f5 big-ip with the host of virtual server ip - 192.168.180.129.
On the second SYN flagged as OUT, what does that mean where the source IP is the actual client and the destination is the virtual server with port 8080?Does this mean f5 big-ip forwarded the whole TCP connection of the client (192.168.100.28) from the VS listening on port 80 to another VS listening on port 8080 (as per above conversation)?
If it is so then shouldn't the identification number of the packet be shared between the communication of the actual client and the f5 big-ip virtual server?- Lucas_Thompson
re: Does this mean f5 big-ip forwarded the whole TCP connection of the client (192.168.100.28) from the VS listening on port 80 to another VS listening on port 8080 (as per above conversation)?
Essentially, yes, but keep in mind that there are essentially two halves of each flow because BIG-IP is a full-proxy. Packet data is serialized/deserialized between them. This article may help explain it:
https://community.f5.com/t5/technical-articles/the-full-proxy-data-center-architecture/ta-p/279637
