AAM: how to cache home page? (when path = /)
I'm trying to figure out how to cache pages if the request doesn't contain a file name (e.g. http://www.domain.com/)..) I assumed that the MIME-type of the Object Type (under Policies) would classify HTML-pages as such, but it looks like this doesn't cover requests without a matching file extension. What am I missing?
Squid forward caching proxy server conflicting with Load Balancer; images, JS, CSS not rendering in application
Have an interesting one here that I hope others can help unravel. A user tells me that the website application, which sits behind an F5 LB, is not rendering properly: E.g.: is missing images, stylesheets, javascript files, and the like. And it's not just this user but a colleague at his workplace has the same issue and seemingly others in the company also can reproduce this issue. I will say that this client (as in the company) is the only one who has reported such an issue. No other companies who use the application are reporting pages not rendering content properly. He had tried testing with a work laptop, work phone, personal phone, over the company network, cellular network, and home network and using multiple browsers. It was consistent across multiple browsers. I asked him to clear cache and cookies and that did not help. Here are the results of his testing: Work laptop on home network: Pass. Work laptop on company network : Fail. Work laptop at their customer's location (possibly connected to customer's network): Fail Work phone on company network: Fail. Work phone on cellular network (Verizon)*: Fail. Personal phone on cellular network (AT&T)*: Pass. Work colleague of user laptop connected to said colleague's phone configured as hotspot (Sprint) (not sure if devices are work or personal)**: **This was conducted while on company premises. It didn't seem to matter what browser was employed. I didn't get a report that it worked in one browser but not another, for instance. To make a long story short, I asked him to send me a fiddler log and the logs showed something that I cannot reproduce on my end. The Fiddler log shows the page loaded with HTTP 200 but the content on the page (i.e. JavaScript files, stylesheets, images) show HTTP 304. In the response headers, under Transport, for all requests, I see Connection: close and Via: 1.1 {unique ID} (squid/3.5.23) (The unique ID is some kind of specific value. It might be sensitive information so I decided to not include it in this post). For , the response header Cache shows: X-Cache: MISS from {unique ID} X-Cache-Lookup: HIT from {unique ID}:{Port number} For , the response header Cache shows: X-Cache: HIT from {unique ID} X-Cache-Lookup: HIT from {unique ID}:{Port number} I don't recall seeing anything like this before. It looks to be Squid, a caching and forward proxy server, that is sitting in front of the client and making requests to the LB. Since this company is the only one who has reported this issue and I cannot reproduce it on my end, it's probably safe to say that either this company is running Squid, their ISP is running Squid, or even both. I pressed the user to inquire with the company's IT if they are running any proxies and the answer was no. It's certainly possible the company's IT could be mistaken. Today, the user says that he came into his office and everything is working now. He tried Firefox, IE, wireless network, cellular network and does not understand why it's working. The likely possibilities I can think of as to what and why is: Squid cache was flushed, which means this problem may return in the future. Squid was not configured properly by company's IT/ISP and now it is, thus resolving the issue. Squid was taken offline and the client is connecting directly to the LB now. What I am very concerned about is what happens if the company reports the same issue or maybe another company who is running Squid or some other forward caching/proxy server reports the same issue? I really don't know if this is something where I have to tell the user that this is not our problem, this is your IT infrastructure and/or your local ISP's problem. In other words, whether the Squid server is configured properly or not, is this something where the LB needs to be configured such that it works around the problem? Does that make sense? If there is a configuration change that I need to enact on the LB, what are these changes and what are step-by-step instructions? I'm sorry for the long-winded explanation but I'm trying to be detailed and thorough with this. Thank you very much.dns transparent cache as authoritative?
Hello, I have inherited an f5 pair that is (in theory) an authoritative-only name server. it has a pool of three dns servers it passes queries to. The first lookup using the f5 as the dns server has the authoritative bit set. However, subsequent queries (cache hit) do not, until the ttl time has elapsed. In other words, it acts as a standard dns caching server that sets authoritative when it has to query an authoritative server for an answer. Is there a way to set up the F5 with this configuration to always answer authoritative? bigip version 15.1.0.5 udp listener with dns profile name: "authoritative_dns" authoritative_dns profile set: parent == dns dns express enabled dns cache enabled: set to "authoritative_cache" authoritative_cache set: resolver type: transparent (NONE)
TLS Session resumption (caching) - NO
Hi, My SSL profile keeps giving me this orange warning on SSLLABS: TLS Session resumption (caching) No (IDs assigned but not accepted) I've did my research, and it was known to give this when more SSL profiles are used under on VS - this is not the case with me. I have Cache size set to default 262144 sessions with 7200 seconds timeout (lowering the numbers did not do the trick). My ciphers are: !LOW:!SSLv2:!SSLv3:!MD5:!RC4+SHA:!EXPORT:!DHE:ECDHE+AES:AES+SHA+RSA:@STRENGTH but I don't really believe it's the ciphers fault (though I have read similar problem was with TLS1.2 on windows server, and a rollback to TLS1.1 fixed the issue). Any ideas or experience with this? Or should I now worry (though my client is a bit picky, and anything less than green on SSLLABS is a problem...)
LTM Web Acceleration Profile Configuration
My organization and I are new to BIG-IP. Everything has been working quite well, but I do have a question about Web Acceleration profiles. For LTM, the iApps I have used so far create one by default. This seemed to be working satisfactorily, until the programmers began complaining about it. The previous load balancer my company used apparently did not do anything like F5's Web Acceleration profiles do, so the old ADC wasn't caching any items in that regard. I got with the programmers and told them we can clear the cache when we make changes, we can reduce the maximum age, and we can limit what items are cached, but they don't like that either. They want the LTM to recognize a document has changed without any cache clearing or anything like that. They want to be able to make changes to web pages (including to items the Web Acceleration profiles caches) and have all machines see those changes instantly and automatically. Of course, this obviously needs to happen, and the web pages we serve up change often, but the only way I see of doing that is clearing the cache on the Web Acceleration profile. Is there a provision for the LTM to check the web server for items to get their last modified dates so that if an item is changed the new version will be served up automagically instead of the old version? Do Web Acceleration profiles provide enough improvement to justify their use in a medium sized environment? What do other companies regularly do?
Big IP LTM 11.6 caching support
Dear All, I am wondering what kind to caching functionality LTM provides without additional licenses like WA. Within the virtual server configuration I can select a certain Web Acceleration Profile like optimized-caching. Is this function supported within the LTM? What kind of caching functionality does the LTM provide? Best regards, Marvin
F5 Friday: In the NOC at Interop
#interop #fasterapp #adcfw #ipv6 Behind the scenes in the Interop network Interop Las Vegas expects somewhere in the realm of 10,000+ attendees this year. Most of them will no doubt be carrying smart phones, many tablets, and of course the old standby, the laptop. Nearly every one will want access to some service – inside or out. The Interop network provides that access – and more. F5 solutions will provide IT services, including IPv4–IPv6 translation, firewall, SSL VPN, and web optimization technologies, for the Network Operations Center (NOC) at Interop. The Interop 2012 network is comprised of the show floor Network Operations Center (NOC), and three co-location sites: Colorado (DEN), California (SFO), and New Jersey(EWR). The NOC moves with the show to its 4 venues: Las Vegas, Tokyo, Mumbai, and New York. F5 has taken a hybrid application delivery network architectural approach – leveraging both physical devices (in the NOC) and virtual equivalents (in the Denver DC). Both physical and virtual instances of F5 solutions are managed via a BIG-IP Enterprise Manager 4000, providing operational consistency across the various application delivery services provided: DNS, SMTP, NTP, global traffic management (GSLB), remote access via SSL VPNs, local caching of conference materials, and data center firewall services in the NOC DMZ. Because the Interop network is supporting both IPv6 and IPv4, F5 is also providing NAT64 and DNS64 services. NAT64: Network address translation is performed between IPv6 and IPv4 on the Interop network, to allow IPv6-only clients and servers to communicate with hosts on IPv4-only networks DNS64: IPv6-to-IPv4 DNS translations are also performed by these BIG-IPs, allowing A records originating from IPv4-only DNS servers to be converted into AAAA records for IPv6 clients. F5 is also providing SNMP, SYSLOG, and NETFLOW services to vendors at the show for live demonstrations. This is accomplished by cloning the incoming traffic and replicating it out through the network. At the network layer, such functionality is often implemented by simply mirroring ports. While this is sometimes necessary, it does not necessarily provide the level of granularity (and thus control) required. Mirrored traffic does not distinguish between SNMP and SMTP, for example, unless specifically configured to do so. While cloning via an F5 solution can be configured to act in a manner consistent with port mirroring, cloning via F5 also allows intermediary devices to intelligently replicate traffic based on information gleaned from deep content inspection (DCI). For example, traffic can be cloned to a specific pool of devices based on the URI, or client IP address or client device type or destination IP. Virtually any contextual data can be used to determine whether or not to clone traffic. You can poke around with more detail and photos and network diagrams at F5’s microsite supporting its Interop network services. Dashboards are available, documentation, pictures, and more information in general on the network and F5 services supporting the show. And of course if you’re going to be at Interop, stop by the booth and say “hi”! I’ll keep the light on for ya… F5 Interopportunities at Interop 2012 F5 Secures and Optimizes Application and Network Services for the Interop 2012 Las Vegas Network Operations Center When Big Data Meets Cloud Meets Infrastructure Mobile versus Mobile: 867-5309 Why Layer 7 Load Balancing Doesn’t Suck BYOD–The Hottest Trend or Just the Hottest Term What Does Mobile Mean, Anyway? Mobile versus Mobile: An Identity Crisis The Three Axioms of Application Delivery Don’t Let Automation Water Down Your Data Center The Four V’s of Big DataWhen using APM with an LDAP AAA server, are results cached?
I'm making extensive use of this sort of test: [mcget {session.ldap.last.attr.memberOf}] contains "My_Groupname" I was previously using Active Directory authentication and queries rather than LDAP, but changing to LDAP has cut down the login wait from up to 15 seconds down to several seconds. I'm almost certain that the APM is caching the membership results, however, because I make changes on the domain controller and the changes are not reflected on the BigIP - it seems to be using stale results. Any suggestions on the expected behavior, and how to change it? I know I can mix and and match AD and LDAP authentication and queries if necessary, and AD was also caching but didn't seem to be as long when I set it to 0 days, and I could manually clear that cache for testing purposes.Writing URI for caching in regex
Hello everyone. Happy new year. In the web acceleration profile we want to use caching wit a URI list. We want to match these URIs: /appsuite/api/apps/load/* /appsuite/v=* So i've put this in the Include List: \/appsuite\/api\/apps\/load\/.+ \/appsuite\/v=.+ It does not work. I'm not an expert with regex and I don't have an equipment for testing. Could you help me to write it right or give me a link to a regex writing book for Big-IP ? ThanksTrue or False: Application acceleration solutions teach developers to write inefficient code
It has been suggested that the use of application acceleration solutions as a means to improve application performance would result in programmers writing less efficient code. In a comment on “The House that Load Balancing Built” a reader replies: Not only will it cause the application to grow in cost and complexity, it's teaching new and old programmers to not write efficient code and rely on other products and services on [sic] thier behalf. I.E. Why write security into the app, when the ADC can do that for me. Why write code that executes faster, the ADC will do that for me, etc., etc. While no one can control whether a programmer writes “fast” code, the truth is that application acceleration solutions do not affect the execution of code in any way. A poorly constructed loop will run just as slow with or without an application acceleration solution in place. Complex mathematical calculations will execute with the same speed regardless of the external systems that may be in place to assist in improving application performance. The answer is, unequivocally, that the presence or lack thereof of an application acceleration solution should have no impact on the application developer because it does nothing to affect the internal execution of written code. If you answered false, you got the answer right. The question has to be, then, just what does an application acceleration solution do that improves performance? If it isn’t making the application logic execute faster, what’s the point? It’s a good question, and one that deserves an answer. Application acceleration is part of a solution we call “application delivery”. Application delivery focuses on improving application performance through optimization of the use and behavior of transport (TCP) and application transport (HTTP/S) protocols, offloading certain functions from the application that are more efficiently handled by an external often hardware-based system, and accelerating the delivery of the application data. OPTIMIZATION Application acceleration improves performance by understanding how these protocols (TCP, HTTP/S) interact across a WAN or LAN and acting on that understanding to improve its overall performance. There are a large number of performance enhancing RFCs (standards) around TCP that are usually implemented by application acceleration solutions. Delayed and Selective Acknowledgments (RFC 2018) Explicit Congestion Notification (RFC 3168) Limited and Fast Re-Transmits (RFC 3042 and RFC 2582) Adaptive Initial Congestion Windows (RFC 3390) Slow Start with Congestion Avoidance (RFC 2581) TCP Slow Start (RFC 3390) TimeStamps and Windows Scaling (RFC 1323) All of these RFCs deal with TCP and therefore have very little to do with the code developers create. Most developers code within a framework that hides the details of TCP and HTTP connection management from them. It is the rare programmer today that writes code to directly interact with HTTP connections, and even rare to find one coding directly at the TCP socket layer. The execution of code written by the developer takes just as long regardless of the implementation or lack of implementation of these RFCs. The application acceleration solution improves the performance of the delivery of the application data over TCP and HTTP which increases the performance of the application as seen from the user’s point of view. OFFLOAD Offloading compute intensive processing from application and web servers improves performance by reducing the consumption of CPU and memory required to perform those tasks. SSL and other encryption/decryption functions (cookie security, for example) are computationally expensive and require additional CPU and memory on the server. The reason offloading these functions to an application delivery controller or stand-alone application acceleration solution improves application performance is because it frees the CPU and memory available on the server and allows it to be dedicated to the application. If the application or web server does not need to perform these tasks, it saves CPU cycles that would otherwise be used to perform them. Those cycles can be used by the application and thus increases the performance of the application. Also beneficial is the way in which application delivery controllers manage TCP connections made to the web or application server. Opening and closing TCP connections takes time, and the time required is not something a developer – coding within a framework – can affect. Application acceleration solutions proxy connections for the client and subsequently reduce the number of TCP connections required on the web or application server as well as the frequency with which those connections need to be open and closed. By reducing the connections and frequency of connections the application performance is increased because it is not spending time opening and closing TCP connections, which are necessarily part of the performance equation but not directly affected by anything the developer does in his or her code. The commenter believes that an application delivery controller implementation should be an afterthought. However, the ability of modern application delivery controllers to offload certain application logic functions such as cookie security and HTTP header manipulation in a centralized, optimized manner through network-side scripting can be a performance benefit as well as a way to address browser-specific quirks and therefore should be seriously considered during the development process. ACCELERATION Finally, application acceleration solutions improve performance through the use of caching and compression technologies. Caching includes not just server-side caching, but the intelligent use of the client (usually the browser) cache to reduce the number of requests that must be handled by the server. By reducing the number of requests the server is responding to, the web or application server is less burdened in terms of managing TCP and HTTP sessions and state, and has more CPU cycles and memory that can be dedicated to executing the application. Compression, whether using traditional industry standard web-based compression (GZip) or WAN-focused data de-duplication techniques, decreases the amount of data that must be transferred from the server to the client. Decreasing traffic (bandwidth) results in fewer packets traversing the network which results in quicker delivery to the user. This makes it appear that the application is performing faster than it is, simply because it arrived sooner. Of all these techniques, the only one that could possibly contribute to the delinquency of developers is caching. This is because application acceleration caching features act on HTTP caching headers that can be set by the developer, but rarely are. These headers can also be configured by the web or application server administrator, but rarely are in a way that makes sense because most content today is generated dynamically and is rarely static, even though individual components inside the dynamically generated page may in fact be very static (CSS, JavaScript, images, headers, footers, etc…). However, the methods through which caching (pragma) headers are set is fairly standard and the actual code is usually handled by the framework in which the application is developed, meaning the developer ultimately cannot affect the efficiency of the use of this method because it was developed by someone else. The point of the comment was likely more broad, however. I am fairly certain that the commenter meant to imply that if developers know the performance of the application they are developing will be accelerated by an external solution that they will not be as concerned about writing efficient code. That’s a layer 8 (people) problem that isn’t peculiar to application delivery solutions at all. If a developer is going to write inefficient code, there’s a problem – but that problem isn’t with the solutions implemented to improve the end-user experience or scalability, it’s a problem with the developer. No technology can fix that.
