Forum Discussion
pool member and self ip traffic
Your question would need more details to correctly answer. To wrap my head around the "selfs' and "float" i like to think of them this way:
The selfs IP belongs to an INDIVIDUAL f5 and provide layer2 adjacency to the vlan segment. As an exampled, If you have a HA pair (or cluster), the self -is what is used to allow traffic in/out of each one as a unique entitiy.
If a "float" is configured - it moves from f5-HA-pair1 to f5-HA-pair2 in the event of a failover. This is a sepeate IP that floats/ moves from one appiance to another .
As you define the virtual server, there will be a configuration item of "Source Address translation" - or as i think of it "After the f5 sends the packet to the server, how does it reply back to the f5". The configuration options are:
None: If this is configured, the f5 must be either the default gateway for the server directly - or possible the default gateway for the network segment (routing table). The backend server get the packet and reply to the sender directly - and f5 sees the packet in and out.
Automap: This tells the f5 to change the "source address" of the packet as it send it to the backend server, thusly the backend server reply to the f5 regardless of the routing that might be in place. When Automap is used, the f5 will pick either its default route or if defined ,a self address / range that provides a more specific route to the backend server.
SNAT: If defined - also changes the source address of the packet as it sends it to the backend server. This allows you to specify one or more IP addresses for the backend server to reply to.
From the CLI - from bash you can run ' ip route ' to see what the routing config looks like. And you can run ' ip route get IP.ADD.RE.SS ' to find which of the route would be used if you are sending traffic to that IP, you can test both inbound to the f5 - vip --- and outbound to the backend server pool memember. *- route domains if configured might effect this.
If you only have 1 self, this will be the source of all the f5 monitors going back to the pool members. If you have more then 1 self, it will pick the most specific to the route and follow the table provided with ip route. If you have a float that is most specific the float will be used for data packets - and the self will be used for monitor packets IF source address translation is enabled, if not enabled - it follow the network routing table for in and outbound.
I've take some techincal liberties with this, but i think you will be able to use this and find your answer - or ask a diffrent question with the details you find.
thank you for your extensive answer.
in the virtual server configuration I use autmap and vlan vlan_lbs (the address of virtual_servers is 10.168.17.0/24 - the question is whether it should be like this or should I provide the vlans which are pool members?
from what I understand, the self ip address is the address in a given vlan that allows me to communicate within this vlan, but does this apply to pool member?
I'm not fluent with F5, sorry. I am already working in an environment that I am not fully familiar with yet. Another strange thing for me is that the www servers (pool member) have their default ip set to the self ip of the vlan_lbs vlan (i.e. this address is 10.168.17.0).
because of this, the servers do not have the Internet because they send everything to the gateway, I would like to avoid this, so I think that's what self-IP is for.
I'm trying to understand how traffic gets to web servers:
Let's assume it looks like this
I have a firewall connected to the core switch, and I have servers, esxi hosts managed by vcenter, connected to the core switch (I have different machines in different vlans on the hosts) I have a big ip connected to the core switch where I tag the vlans in which I have a web server and the vlan from the virtual server - these vlans are also on the firewall - I want it to be a gateway for these web servers, not big ip.
I have a domain.com domain that points to a public address on the firewall. 1.1.1.1->10.168.17.50
this move goes to vs f5, and now I don't understand how traffic from vs is directed to the pool member. I suspect that it is because I have a self ip in the pool member vlan and f5 knows about it, so it directs traffic from the virtual server through self ip to the target www server.
but I don't see a vlan assignment to a pool member anywhere in the configuration, so how can f5 know that the www server 10.168.7.50 is in vlan 207 and that it should direct traffic there?
I want F5 to internally forward traffic from the VS vlan to the pool member vlans, and I want to have a default gw on the web server on the firewall, not F5
- PhatANhappyDec 11, 2023MVP
Missing from your diagram are the details of your text is what is going on at layer 3.
It is important to remember the f5 is a full proxy and there are 2 different conversations happening, Client to f5 - AND - f5 to backend server. The packet on the inbound from the firewall will appear on the vbs vlan, the f5 will know how to reply to the client based upon his source. The 2nd conversation - from the F5 - to the backend server. With "automap set" the f5 will pick the best match of selfs / routes to chose where the traffic is being sent.
Where is routing happening and what are the expectations?
If your f5's are "inline" as in the default gateway is being set on the servers to point to the f5, it should point to a floating address that way you can insure that the correct f5 is processing the traffic. If you point to a local only address, and that becomes the standby -or goes down you will no longer route. IMO - inline's are a lot easier to troubleshoot and manage, it certainly makes the packet capture process simpler to diagnose.
Lastly - if your servers are pointing to the float as the default gateway, and your servers are not getting to the internet - you will likely need a forwarding virtual server, start here.
https://my.f5.com/manage/s/article/K7595
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com