snat vs automap, whats the difference?
I'm trying to see the difference between the snat and automap for the Source Address Translation option. Currently I have traffic coming in to the F5 using automap. What though specifically does that mean? And why wouldn't I use SNAT? All the nodes, (servers in our lan), are not configured to have the F5 as its default gateway. I have a lot of virtual servers configured and I'm not sure how the self-ip plays a role in the nating or snating if at all. From what I understand (but could be wrong) an external client request is directed to the vip ip (since our firewall nats it there) and the destination IP is that of the vip. The F5 then translates the destination IP to that of the IP of the pool member. Then on the way back out the source is translated to the of the vip. But what about the selfip? Can someone please explain all this? Thanks!
How to preserve data in a HTTP 302 redirect of a POST
Hi, We are trying to implement the following scenario and would like to know if the LTM can do the following: An application execute an HTTP POST request with parameters inside the HTML body LTM sends back a 302 redirect request back to the client to another local url How can LTM sends back in the 302 redirect with the same parameters that were availble in the initial packet (see 1))? Can LTM look into HTML body and use them in packet 2) with an iRule? In initial packet 1) these parameters can be a small text or a large file that is being posted to the servers behind LTM Thanks, Giulio.
What exactly does FastL4 profile do?
Customer have to load balance a webserver. Using default settings it takes more than 10 seconds to completely load the webpage. After using the FastL4 profile it takes only 3 seconds. So what does it do to speed this up? We tested also the Fasthttp profile but some objects in the webpage cannot be loaded. Is there any limitation for this profile? Thanks a lot.
APM - How to create a keytab file with multiple SPNs
Hi, I have run into a problem using Kerberos Authentication when using CNAMEs in DNS. You can search the web but basically if you use a CNAME record like "www CNAME www1" and then A records "www1 A 10.10.10.1" and "www2 A 10.10.20.1", when IE or .NET needs to authenticate it forms the request to "www1" (or "www2") and not "www". Now, you can add the additional SPNs on the Domain Controllers using the MS tool "setspn" with the "-A" switch no problem against the same service account. The instructions for creating the keytab file only cover the use of the MS tool "ktpass". This tool can only create a keytab file with a single SPN and when you use this with APM it will only work for "www" and break for anything else. I'm unfamiliar with the Kerberos utilities on BIG-IP but I have seen that there are several (kadmin, kinit, ktutil). Can anyone give me a working example of how I can create a keytab file which will work using these tools for all 3 SPNs which will work with MS AD. Thanks.Can LTM be used to configure Active and Passive Servers?
For a given vip is it possible to define pool of servers that are active and also some pool of members that passive. Basically this is what I want to do: 1. Define active pool of servers for a vip 2. Define passive pool of servers for a vip 3. When all the members in pool go down then make passive pool active Is it possible to do that in LTM? If it's possible then when one of the pool members (previously active) become active again does it switch it back?
Application Web Pages Not Being Served Correctly by F5
Hi, One of our customers has an application that doesn't appear to perform very well when load-balanced by the F5. The application is currently using a Standard VS profile, which is not doing SSL offload, uses cookie persistence and a SNAT pool with a single IP address and pretty much everything else is default. We have recently applied a Web Acceleration profile to the VS to attempt to address the problem but it doesn't appear to have solved anything. The WA profile is only set to cache and serve up static CSS and JS files. The major issue, we believe, is that the client fails to receive some of the Javascript that is necessary for the page to render correctly. This was the case prior to the WA profile being applied as well as after. The application used to be load-balanced, in a very rudimentary way, by iptables and these issues were not seen then. I'm very keen to find any clue as to where to look on the F5 for what could be causing the problem. I'm considering changing the profile to Perf L4 to see if it helps but there are two problems with that: 1. I don't get to learn what was causing the problem 2. I think the client wants to have the F5 do SSL offload in the near future Any help would be greatly appreciated. Thanks in advance, Ben
The Full-Proxy Data Center Architecture
Why a full-proxy architecture is important to both infrastructure and data centers. In the early days of load balancing and application delivery there was a lot of confusion about proxy-based architectures and in particular the definition of a full-proxy architecture. Understanding what a full-proxy is will be increasingly important as we continue to re-architect the data center to support a more mobile, virtualized infrastructure in the quest to realize IT as a Service. THE FULL-PROXY PLATFORM The reason there is a distinction made between “proxy” and “full-proxy” stems from the handling of connections as they flow through the device. All proxies sit between two entities – in the Internet age almost always “client” and “server” – and mediate connections. While all full-proxies are proxies, the converse is not true. Not all proxies are full-proxies and it is this distinction that needs to be made when making decisions that will impact the data center architecture. A full-proxy maintains two separate session tables – one on the client-side, one on the server-side. There is effectively an “air gap” isolation layer between the two internal to the proxy, one that enables focused profiles to be applied specifically to address issues peculiar to each “side” of the proxy. Clients often experience higher latency because of lower bandwidth connections while the servers are generally low latency because they’re connected via a high-speed LAN. The optimizations and acceleration techniques used on the client side are far different than those on the LAN side because the issues that give rise to performance and availability challenges are vastly different. A full-proxy, with separate connection handling on either side of the “air gap”, can address these challenges. A proxy, which may be a full-proxy but more often than not simply uses a buffer-and-stitch methodology to perform connection management, cannot optimally do so. A typical proxy buffers a connection, often through the TCP handshake process and potentially into the first few packets of application data, but then “stitches” a connection to a given server on the back-end using either layer 4 or layer 7 data, perhaps both. The connection is a single flow from end-to-end and must choose which characteristics of the connection to focus on – client or server – because it cannot simultaneously optimize for both. The second advantage of a full-proxy is its ability to perform more tasks on the data being exchanged over the connection as it is flowing through the component. Because specific action must be taken to “match up” the connection as its flowing through the full-proxy, the component can inspect, manipulate, and otherwise modify the data before sending it on its way on the server-side. This is what enables termination of SSL, enforcement of security policies, and performance-related services to be applied on a per-client, per-application basis. This capability translates to broader usage in data center architecture by enabling the implementation of an application delivery tier in which operational risk can be addressed through the enforcement of various policies. In effect, we’re created a full-proxy data center architecture in which the application delivery tier as a whole serves as the “full proxy” that mediates between the clients and the applications. THE FULL-PROXY DATA CENTER ARCHITECTURE A full-proxy data center architecture installs a digital "air gap” between the client and applications by serving as the aggregation (and conversely disaggregation) point for services. Because all communication is funneled through virtualized applications and services at the application delivery tier, it serves as a strategic point of control at which delivery policies addressing operational risk (performance, availability, security) can be enforced. A full-proxy data center architecture further has the advantage of isolating end-users from the volatility inherent in highly virtualized and dynamic environments such as cloud computing . It enables solutions such as those used to overcome limitations with virtualization technology, such as those encountered with pod-architectural constraints in VMware View deployments. Traditional access management technologies, for example, are tightly coupled to host names and IP addresses. In a highly virtualized or cloud computing environment, this constraint may spell disaster for either performance or ability to function, or both. By implementing access management in the application delivery tier – on a full-proxy device – volatility is managed through virtualization of the resources, allowing the application delivery controller to worry about details such as IP address and VLAN segments, freeing the access management solution to concern itself with determining whether this user on this device from that location is allowed to access a given resource. Basically, we’re taking the concept of a full-proxy and expanded it outward to the architecture. Inserting an “application delivery tier” allows for an agile, flexible architecture more supportive of the rapid changes today’s IT organizations must deal with. Such a tier also provides an effective means to combat modern attacks. Because of its ability to isolate applications, services, and even infrastructure resources, an application delivery tier improves an organizations’ capability to withstand the onslaught of a concerted DDoS attack. The magnitude of difference between the connection capacity of an application delivery controller and most infrastructure (and all servers) gives the entire architecture a higher resiliency in the face of overwhelming connections. This ensures better availability and, when coupled with virtual infrastructure that can scale on-demand when necessary, can also maintain performance levels required by business concerns. A full-proxy data center architecture is an invaluable asset to IT organizations in meeting the challenges of volatility both inside and outside the data center. Related blogs & articles: The Concise Guide to Proxies At the Intersection of Cloud and Control… Cloud Computing and the Truth About SLAs IT Services: Creating Commodities out of Complexity What is a Strategic Point of Control Anyway? The Battle of Economy of Scale versus Control and Flexibility F5 Friday: When Firewalls Fail… F5 Friday: Platform versus Product
