APM site slowness/timeout

When you say "the site will resolve immediately", what are you referring to specifically? Do you any reason to believe that a portion of the access policy is failing? Where and how does it fail? Does it fail once in a valid session, or only for new connections? If it's only on new connections, try adding some message boxes in the APM visual policy at different points to see where it might be getting stuck.

I do not believe so because when I go to resolve the address from the web right after saving the policy for access, the site resolves for logon and I can reach to the full webtop successfully. Fast forward about 3 -4 hours of no use and the site times out when attempting to reach it. Our firewall shows that the attempts are coming back as incomplete. Funny part is, usually, if I keep trying the site will eventually "wake up" and start resolving again. This happens internally and externally. I was just wondering if anyone had enough experiencing with these to know what to look at? My co worker believes it is a monitor that is failing, however, that does not appear to be the case.

Your last description brings up some good points. I don't think we can rule out a monitor, or even a network issue at this point, but we can come close to eliminating what it isn't. You say this happens for internal and external users. Is there a common path that all users traverse? A router or switch? When it is failing, do you see the requests making it to the BIG-IP? If not, do you see them arriving at the device before the BIG-IP? Does it matter if you try to access by name or IP address? If you can verify that the request is getting to the VIP, then you can rule out network (and potentially DNS) issues.

Yes, this is an address in our DMZ. We are using this for external access so it really wont be used internally, however, it does react the same going from internal. Yes, I see the requests hitting our firewall and randomly being marked as incomplete. THis seems to mean that the handshake isnt completing. However, if you try a few times eventually the site will "wake up". Also, if I go into the APM policy and just re save it, it works instantly to "wake it up". it really isnt a time of day or length of time I can pinpoint that makes it drop off. This is sitting in the same subnet in the DMZ that other sites hit and work fine. That is why this has been so tricky. You make a good point with the IP address. THat works instantly but just to bring you to the cert page (not recognized because you are using IP) Once you hit "continue to site" it behaves the same way as if I used the URL. So that proves the IP is popping up immediately, maybe DNS? THank you for your help!

Also, if I go into the APM policy and just re save it, it works instantly to "wake it up"

Can you elaborate on your access policy configuration? And also, just to clarify, when it fails, do yon see the request coming to the front side of the F5 (past the firewall)?

I hate to be this green but I may ask a newbie question here... our config is that it hits our DMZ address/URL then it hits the GTM Pool where two DMZ addresses reside. These are both on our LTM and one is a redirect to https. That is about the extent of it. There is no target pool on the LTM since this is a full webtop.

in this setup, where should I look first past the firewall?

Client request traffic should arrive at the external VLAN of the LTM (where the LTM VIP lives). If you run a tcpdump on the LTM and filter for traffic to the destination address (the VIP address) you can see whether or not client requests are making it to the VIP when there is a failure. You're specifically looking for packets arriving at the VIP address when it's failing. If you do see packets arriving to the VIP, then you can mostly rule out any network issues and focus on the LTM/APM configuration.

So yea, the problem must exist before the LTM because when I get my timeout, nothing is recorded on the TCP dump on the external DMZ address. As I was saying, if you try a few times it eventually works, on the 4th attempt of trying to resolve the URL the traffic finally came pouring accross. So would you be lead to believe it is a problem with the LTM VIP? I created this via the Wizard on the LTM so I wonder if that didnt create something I need for constant traffic flow.

-Tom

So would you be lead to believe it is a problem with the LTM VIP?

I guess that depends on where the external DMZ address is in context to the LTM VIP. Let's say, for example, you have a network path like the following:

client - Internet - router - firewall - DMZ - firewall - router - LTM VIP                

This likely isn't a correct representation of your environment, but illustrates the path that a packet might take to go from the client to the LTM VIP; and like an electronic circuit, you can place a multimeter probe anywhere along this path and "see" the electrons flowing. So then the question becomes, if you stick a probe at the LTM VIP interface when it's failing, do you see the client traffic reaching the interface? If not, do you see it reaching (and leaving) the device preceding it (and so on)? Only if you see traffic at the LTM VIP when it's failing can you assume that the problem is at/in the VIP.