Forum Discussion
mreco_159588
Cirrus
CirrusNo response after added virtual server IP address as floating self-IP address
Hi,
I have an F5 HA pair that serves several virtual servers.
VS1: ip1
VS2: ip2
Now, the IP address of VS1 (ip1) was already defined as a floating self-IP, but I found out that the IP address of VS2 was not defined as a self-IP. So I added ip2 as a floating self-IP.
From that moment on, no traffic was accepted on either ip1 or ip2.
Moreover, when I add a floating self-IP (let's say ip3), the virtual servers stop accepting traffic.
Any idea what can be causing this? Is it necessary to define the IP address of a virtual servers as a floating self-IP? Are there benefits of doing that?
On other units I manage, I always first add the floating self-IP and then I add the virtual server on that IP address.
I'm running version "BIG-IP 11.6.0 Build 0.0.401 Final"
Thanks.
It was driving me nuts, since I just want to understand what's going.
After reading this post: https://devcentral.f5.com/questions/self-ip-address-selection-with-multiple-to-choose-from, I checked the firewall logs again. And now the pieces fit.
On the Virtual Servers I have SNAT Automap enabled. When I only have one floating self IP, that floating self IP is used to initiate traffic to backend servers. When I add more floating self IPs, it will use any of those floating self IPs to initiate traffic towards the backend servers.
The firewall between the F5 and the backend servers does not accept this traffic, meaning not actually the VS stopped responding after I added the VS IP address as a floating self IP, but the firewall blocked traffic towards the backend servers.
So, conclusion (just to summarize):
- only one floating self IP is needed for SNAT communication towards the backend servers (if the amount of connections is less than 65000, otherwise more are needed and I must define a SNAT pool or allow the other floating IP addresses to communicate to the backend servers)
- I will remove the unneeded floating self IP, since they're not needed for a VS to function as a listener IP
Thanks all for your help!
mreco_159588I have already answered the question myself in a previous post.
Thanks for your help!
dragonflymrCirrostratus
Hi,
Can you just post output of commands listed below (masking what you consider confidential info):
- tmsh list net self-allow
- tmsh list net vlan [name of the vlan used by floating IP mentioned below]
- tmsh list net self [name of floating IP that equals IP of VS that stopped to work] all-properties
- tmsh list ltm virtual-address [IP for the VS that equals floating IP mentioned above] all-properties
- tmsh list ltm virtaul [name of VS mentioned above]
Piotr
- mreco_159588
It was driving me nuts, since I just want to understand what's going.
After reading this post: https://devcentral.f5.com/questions/self-ip-address-selection-with-multiple-to-choose-from, I checked the firewall logs again. And now the pieces fit.
On the Virtual Servers I have SNAT Automap enabled. When I only have one floating self IP, that floating self IP is used to initiate traffic to backend servers. When I add more floating self IPs, it will use any of those floating self IPs to initiate traffic towards the backend servers.
The firewall between the F5 and the backend servers does not accept this traffic, meaning not actually the VS stopped responding after I added the VS IP address as a floating self IP, but the firewall blocked traffic towards the backend servers.
So, conclusion (just to summarize):
- only one floating self IP is needed for SNAT communication towards the backend servers (if the amount of connections is less than 65000, otherwise more are needed and I must define a SNAT pool or allow the other floating IP addresses to communicate to the backend servers)
- I will remove the unneeded floating self IP, since they're not needed for a VS to function as a listener IP
Thanks all for your help!
marin_266716Nimbostratus
Im confused, you said floating IP but you also said VS, are you adding a floating IP and thinking it will be the VIP for a pool?
VS1 = VIP1 (Application 1) VS2 = VIP2 (Application 2)
Self IP = IP in segment used to to reach into segments for monitoring or other purposes.
A Self IP is just that, in an HA cluster you could have 2-3 IP's per VLAN. 2x would be 1 Self IP (Non-Floating) per device in your HA group. The 3rd IP would be the floating IP added to the Active node and synced across to the standby. Floating IP's sync, self IP's do not. The Floating IP can be used as a default gateway for instance since it will always follow the active member.
What are you trying to accomplish with said "Self/Floating IP"
- marin_266716
Let me read this and digest what your real setup is based upon your examples.
Example:
VLAN 10 = External (204.12.15.0/24)
VLAN 20 = Internal (10.0.0.0/24)To keep you moving on last bullet in your answers. This needs to be looked at on the switch side. For example, if you have 2x 1G interfaces (1.1/1.2) on the Big-IP going in a Port Channel on the switch (2G aggregate) and say VLAN 10 is the only VLAN trunked in the Port Channel. Then on the F5 I would create a "Virtuals" trunk and add interface members 1.1 and 1.2. On the other side I would use 1.3/1.4 as my "Virtuals" and trunk VLAN 20 on the switch on that side. From there you can then create your VLAN's on F5 and create say vlan_10 with tagged 10 traffic and the same for vlan_20 tagged for vlan 20.
My point in the last bullet is, you need to verify on the switch, what VLAN is going into which "trunk" on both the switch and F5 side.
Again let me kind of whiteboard what you put for the VS examples above and I will respond.
- mreco_159588
Well, on the unit is is not working on, I have (I have changed the IPs not to be the real world IPs) the following setup:
VS1: 204.12.15.183
VS2: 204.12.15.184I recently added a couple VS's more:
VS3: 204.12.15.185
VS4: 204.12.15.186
VS5: 204.12.15.187Self IP of unit 1 (non-floating): 204.12.15.180
Self IP of unit 2 (non-floating): 204.12.15.181
Floating IP on cluster: 204.12.15.183Everything working just fine until now.
The I added to IP address of VS3, VS4 and VS5 as a floating self-IP (because I also have this on other units without problems) and then things stopped working: all VS's didn't accept traffic anymore. I then tested and as soon as I add a second floating self-IP to the cluster, all traffic VS's stop responding.
To answer your questions:
- Are the working VS's and this VS in question here all in the same subnet? Yes, all mentioned IPs and VS's are on the same VLAN.
- Are they even on the same F5? Yes.
- Can you give an example IP of a VS and the 2x Self-IP's and the Floating (which should match the VS IP)? See above.
- Also if you can tell me which VLAN's are trunked in your "Reals" and "Virtuals" along with the VLAN that said "working" VS is on? All VS's are on 'All VLANs and Tunnels'. Above mentioned self-IPs are on VLAN 'external'.
- On the VS that works, but also has a Floating of the same IP, I have a sneaking suspicion that the VLAN that supports that network is not trunked on the side where the "Floating" IP is used? That would be 204.12.15.183 then. How can I check if that's the case? I don't really understand what you mean here.
- marin_266716
I would assume there is then an IP conflict when you assign the IP of the VS to the floating IP on the self side. This would then cause there to be 2x MAC addresses for the same IP on the switch side thus the IP conflict. Are the working VS's and this VS in question here all in the same subnet? Are they even on the same F5?
From the working side. Can you give an example IP of a VS and the 2x Self-IP's and the Floating (which should match the VS IP)? Also if you can tell me which VLAN's are trunked in your "Reals" and "Virtuals" along with the VLAN that said "working" VS is on?
On the VS that works, but also has a Floating of the same IP, I have a sneaking suspicion that the VLAN that supports that network is not trunked on the side where the "Floating" IP is used. This would mean it is on the device on say the "Reals" interface but the VLAN is not there. If the IP is present but no VLAN on that trunk, there wouldnt be a conflict.
- dragonflymr
Hi,
There is no need to add floating IP equal to VS IP. It is rather other way around.
You can use floating IP as your VS IP to save IPs - let's say you have only two free IPs in given subnet - one for self IP, one for floating IP.
But you need VS to configure - solution is to use same IP as floating IP.
If you use Floating IP as VS IP you need to modify Floating IP Port Lockdown setting. As incoming traffic is matching Floating IP first then this setting is evaluated (most often it's set to None or Default) and if there is no port/protocol match traffic is rejected.
So if you have VS at port 80 you need to add TCP port 80 to the Port Lockdown List (probably using Allow Custom).
Piotr