Forum Discussion

WeaverJK's avatar
WeaverJK
Icon for Nimbostratus rankNimbostratus
May 05, 2016

Troubleshootig LTM issues

Hi all. I'm new to load balancers and F5. In preparation for arrival of F5 hardware, I've been working with F5 evaluation licenses (usually, the 45-day licenses provided by F5 Sales staff).

 

Note that I've previously configured virtual servers and have had them up and running in a lab environment. Currently, I'm working with a different lab environment.

 

Today, I've run into a few problems that I'm hoping the community can help me out with.

 

I am using a Mac Mini and VMware Fusion. I created five virtual networks. The first four are each "host only" so that only the VMs and the host can talk to one another. The fifth is a NAT with the host so that, when these connections are enabled, I can activate Microsoft trial licenses.

 

VMs created:

 

- a MS 2012 R2 domain controller; acts as DNS server as well - two MS 2012 R2 member servers with IIS installed - a Windows 8 workstation - two BIG-IP v11.4.0 systems (I have not yet installed hotfixes)

 

The BIG-IPs are in a ConfigSync pair. Two traffic groups were created.

 

Created two Nodes a.b.c.71 and .72. Changed Node Default Monitor to icmp. Created Pool-01 and made .71 and .72 nodes members. Enabled http monitor for the pool. Created a virtual server for .81, gave it Pool-01, and tied it to Traffic Group 2. The workstation can get to the web pages on .71 and .72. Can ping .81 (the virtual server). The two BIG-IPs are in sync.

 

Issue 01: BIG-IP-01's network map shows everything green while BIG-IP-02's network map shows green except for .72 which is a red diamond.

 

Issue 02: The workstation can get to the web pages for .71 and .72 but going to .81 results in "the page cannot be displayed."

 

I've tried looking in log files on the BIG-IP devices but have not found any related entries.

 

Questions:

 

- what logs should I be checking? What log shows connection request and hand-offs? What log is related to monitors? - any idea why BIG-IP-02 would show down for a http check of .72 while BIG-IP-01 says the same check is good? - any idea where the problem with the .81 virtual server and its back-ends may lie?

 

Thank you,

 

John

 

9 Replies

  • Rebooted BIG-IP-02 and how the network map (which I had been refreshing with the Update button) now shows a blue square for the second pool member (.72). Of course, the icmp node monitors say all is green.
  • Have you enabled Source Address Translation: Automap on the Virtual Server? (It may show as SNAT in some versions).

    You can also check the Virtual Server and Pool statistics to see if traffic is going in and out. You can find those on:

    Local Traffic > Virtual Servers > Statistics

    Local Traffic > Pools > Statistics

    You can also run a tcpdump from the bash command line, for example:

    tcpdump -nni 0.0

    which will show you the traffic that's going through the traffic interfaces.

    Other examples:

    tcpdump -nni vlan_name

    tcpdump -nni 0.0 host 192.168.x.x

    You can see more examples in SOL411

    • WeaverJK's avatar
      WeaverJK
      Icon for Nimbostratus rankNimbostratus
      Thanks for the suggestions. The Auto Map, which I believe shouldn't be needed here, when enabled, resulted in the functionality I was expecting. I'll have to research further to see why it may be required. From my discussions with the technical F5 sales team as well as my own testing and research up until now, led me to believe that "auto map" was not required in this scenario.
    • WeaverJK's avatar
      WeaverJK
      Icon for Nimbostratus rankNimbostratus
      Just for giggles, after putting the workstation and the VS over to the 10.0.50.x network (and enabling automap) as indicated in the update I posted earlier, I created a second VS with an IP of 10.0.40.81 (again). Tried to access this from one of the web servers; failed. Modified the VS by enabling Auto Map; then the web server was able to pull a web page from 10.0.40.81. Thanks! Looks like I need to read up on auto map. Your assistance is appreciated.
    • neptune_121018's avatar
      neptune_121018
      Icon for Nimbostratus rankNimbostratus
      Source Address Translation Automap is used when the pool members don't have their default gateway or a route pointing to an F5 Self IP... When Automap is enabled the server side part of the connection originates from the F5 Self IP that's on the pool member's VLAN, this makes the pool member's response to be directed to the F5 Self IP, causing both request and response to go through the F5, a requirement of the full-proxy architecture. Check figure 15.1 on this link for a graphical explanation: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_1/ltm_snat.html1213504
  • There are a number of ways to troubleshoot this but without seeing your actual config...its kind of difficult. Consult SOL12531 as it will give you some good tools and commands to troubleshoot as well as locations of the log files you are seeking.

     

  • Further Updates... Last night, while drifting off to sleep, I realized I configured a few items not in the way I intended... Initial configuration: - management network 10.0.30.x - Internal network 10.0.40.x - external network 10.0.50.x - HA network 10.0.60.x Web Servers - 10.0.40.71 - 10.0.40.72 Here are the "whoops" in my initial configuration: - Windows 8 workstation had an IP on the "internal" network (10.0.40.41). - The Virtual Server IP was 10.0.40.81. To be honest, this connectivity should work. I've had the same connectivity working in our production environment for services that were set up and accessible internally only. So I'm still at a loss as to why the workstation could go to 10.0.40.71 and 10.0.40.72 but could not see the web page when going to 10.0.40.81. This morning, I reconfigured the network as follows: - Workstation on external network. Changed the virtual machine configuration, taking the second network interface card off of the Internal Network and placing it on the External Network. Changed the IP from 10.0.40.41 to 10.0.50.41. - Virtual Server - changed IP from 10.0.40.81 to 10.0.50.81 so that it is now on the external network. - Tested without automap; did not work. Enabled automap; worked fine after that. As for the Pool Member issue, that's just wonky: - updated traffic groups so that the VS IP of 10.0.50.81 was in TG2. - Failed TG2 over to BIG-IP-02 (BIP2). At this point, functionality remained the same with the second pool member a blue square. On BIP2, Modified the Pool. Disabled pool member (PM) one, 10.0.40.71:80. On BIP2, PM two, 10.0.40.72:80, remained a blue square. Workstation was still able to get to 10.0.50.81. As I set the index.html on each back-end IIS server to display which server is serving up the page, I could tell with certainty that the workstation received a web page from 10.0.40.72:80, the PM marked as a blue square. - Disabled PM 10.0.40.72:80. - Enabled PM 10.0.40.72:80. Came back as a red diamond instead of a blue square. Web server could no longer get to 10.0.50.81. - On BIGIP2, Modified Pool. Deleted PM 10.0.40.72:80. Added PM 10.0.40.72:80. - PM 10.0.40.72:80 came back as a green circle. Workstation could once again reach 10.0.50.81. Why would BIGIP2 see pool member 10.0.40.72:80 as unknown, then after being disabled and enabled, see the PM as down by a monitor, then when the PM is deleted and created, see the PM as available? What glitch in the BIG-IP operating system is this? And "aside" question for my own sanity: - Should a BIG-IP system be sending data to a pool member with an Unknown status? (because it did!) Thanks for your continued input on these situations! John
  • How do I post a comment such that the post retains my line breaks? The post I made a moment ago isn't easily readable without the line breaks.