For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Joseph_Johnson_'s avatar
Joseph_Johnson_
Icon for Nimbostratus rankNimbostratus
Aug 07, 2014

Troubleshooting F5 LTM vip and pool members

Hi,

 

Im trying to find out is there a way i can test my VIP/Pool configuration with maybe tcp dump or other application. We currently have a VIP on the ltm in the dmz with associated pool members in the lan. The pool members are set up with port 50024 and health monitor specific to weblogic servers. The icmp node monitor is showing the node up, but the pool members are all down. We have a firewall rule in place to allow communication on port 80,443, and 50024 from the F5 self ip's to the pool member servers. When you browse directly to the server, web page is served, when you browse through F5, you get proper re-direct to https, but the web page times out. Is there any way we can test if communication is being received or terminated when trying to communicate over port 50024 with tcpdump or other utility? Thanks

 

3 Replies

  • tcpdump sounds like your best option at this point.

     

    http://support.f5.com/kb/en-us/solutions/public/0000/400/sol411.html

     

    Feel free to post your captures here if you need assistance analyzing what the problem may be.

     

  • hi you can take tcpdump and it might be that communication is broken between internal vlan F5 and pool member .

     

  • If you are using SNAT, the packet travelling thru the firewall towards node will have the SNAT ip as source rather than your self IP (unless you use snat automap). This shouldn't affect the monitors though :(

     

    Best bet would be to setup packet capture on the F5 and server and see if packets reaches the server.

     

    Simple tcpdump command below: tcpdump -nni 0.0 host [node ip]

     

    Install wireshark/netmon on the server and see if traffic reaches the server and if it returns packets.

     

    If the packet is lost in journey, you might want to inspect the firewall, and capture packets there as well.