Forum Discussion
NimbostratusCannot ping external interface
NimbostratusHi All
Thanks for the suggestions. I can provide some further insight.
My external facing interface will now happily accept http requests. Using curl I will get a response and a handshake but then it will immediately shutdown the connection with an error 52 Empty reply from server. I am assuming this means external requests are reaching the virtual server but the server cannot connect to the pool hence the response.
The pool is running and has active health monitors to the nodes , including an HTTP monitor that is green. tcpdump shows the monitors working and gettng the appropriate response from the webservers on the nodes.
So it seems the virtual server is not routing to the pool, though the pool shows as available.
The pool is using the internal network 10.1.0.0 . The external Virtual Server has the public IP address . The external VLAN does NOT have any self-IPs since A) i only have one public facing IP which I have assigned to the virtual server and B) i cannot tell from the conflicting information if self-ips are required or not.
MVPI still see a lot of confusion, let me help you out with this.
Let's start from connecting F5 to your network. You have one internal VLAN (10.1.0.0) and one external VLAN, correct? And you mentioned that the VLANs are untagged, so you have 2 physical interfaces as well, correct?
For every network segment where F5 talks, it needs a self-ip address. This is pretty much to let your gateway and your LAN know you exist and to provide a MAC address for layer 2 operation. 2 VLANS means 2 self IP addresses in this case.
If you want the self-ip's to respond to ICMP probes (ping), then you need to tune the self-ip lockdown behavior.
Last thing you need is a default route. In every deployment I ran, this is configured to point to the Gateway of the external VLAN so that packets destined to my client IP addresses are routed back where they came from.
Now, let's configure a virtual server. You create nodes, you configure a load balancing pool, and you make sure F5 can talk with them (you already mentioned monitor's green, so great!)
Next step is to set up the VIP responder. It can have any IP address and it's not restricted to your VLANs! Altough it's common practice to assignn an IP in the same network as your external interface, just because it's easier to route. But don't worry - if you want a public IP to be on F5 you can totally do it withous having to use public addressing on the connected LANs.
When F5 receives packets for that specific IP address AND port AND on the external VLAN since you configured such interaction (it has to fully match the virtual server responder configuration), it will accept the packet. There's built-in counters in the GUI that help you understand if this is happening.
Now the F5 makes a load balancing decision and forwards the packet to the servers.
You said that from pcap files you see this is happening, and this is great, but .. do you also see response from servers?
My bet is that the server is trying to send the packet back to the original source, instead of routing it back to F5. An easy way to force this interaction is changing NAT configuration on the Virtual Server to "auto map". This means that when the packet leaves F5 on the server-side connection, F5 changes the source IP address to one of his own self-ip's (specifically, the one of the interface that was used to route the packet out).
