DevCentral Weblogs

2011 Telly Award Winner - The F5 Dynamic Data Center

Pete Silva — Wed, 22 Feb 2012 19:43:41 GMT

Founded in 1978 to honor excellence in local, regional, cable TV commercials along with non-broadcast video and TV programs, The Telly Awards is the premier award honoring the finest film and video productions, groundbreaking web commercials, videos and films, and outstanding local, regional, and cable TV commercials and programs. Produced in conjunction with Connect Marketing, we are proud to share that F5’s video, The Dynamic Data Center, is a Silver Winner for the 32nd Annual Telly Awards.

This video sets the stage for IT having to manage multiple networking challenges when faced with a natural disaster causing their data center to shut down. With careful planning, the evolution of the network and application delivery allows the single point of control to automate, provision and secure their virtual and cloud environments.

The F5 Dynamic Data Center

Resources:

Technorati Tags: F5, F5 News, dynamic data center, security, performance, availability, video, Telly Award, youtube

Connect with Peter:	Connect with F5:

The Conflation of Pay-as-you-Grow Hardware with On-Demand

Lori MacVittie — Wed, 22 Feb 2012 12:36:00 GMT

#cloud Today’s post is brought to you by the Law of Diminishing Returns

The conflation of “pay-as-you-grow” with “on-demand” tends to cause confusion in the realm of networking and hardware. This is because of the way in which networking vendors have attempted to address the demand of organizations to pay only for what you use and to expand on-demand. The premise is that costs grow proportionally with capacity. In cloud computing organizations achieve this. As more capacity (resources from hardware) are necessary, they are provisioned an paid for. On-demand scale. The costs per transaction (or user) remain consistent with growth because there is a direct relationship between an increase in capacity (hardware resources such as memory and CPU) and capacity.

Networking vendors have attempted to simulate this capability through licensing based restrictions, allowing customers to initially provision resources at a much lower cost per transaction. The fallacy in this scheme is that, unlike cloud computing, no additional capacity (hardware resources) are ever provisioned. It is only the artificial limitation on the use of that capacity that is lifted at a price during the “growth” stage. Regardless of form-factor, this has a profound impact on the cost-per-transaction (or user) and, it turns out, on the scalability of performance.

The difference between the two models is significant. A “pay-as-you-grow” licensing-based model is like having a great kitchen that is segmented. You can only use a portion of it initially. If you need to use more because you’re giving a dinner party, you can pay for anther segment. The capabilities of the kitchen don’t change, just how much of you can use. Conversely, an on-demand model such as is offered by cloud lets you start out with a standard-sized kitchen, and if you need more room you tack on another kitchen, increasing not only size, but capability. If you’ve ever cooked for a large number of people, you know that one oven is likely not enough, but that’s what you get with “pay-as-you-grow” – one oven with initially limited access to it. The on-demand model gives you two. Or three, or as many as you need to make dinner for your guests.

SCALE of PERFORMANCE

While appearing more cost effective at the outset, “pay-as-you-grow” strategies do not always provide for the scalability of all performance metrics.

This is because licensing restrictions do not impact the underlying hardware capacity, and it is the hardware capacity and load that is always the most constraining factor for performance. As utilization of hardware increases, capacity degrades, albeit in some cases more slowly than others. The end result is that scale-by-license produces increasingly diminishing returns on performance. This is true whether we’re considering layer 4 throughput or layer 7 requests per second, two common key performance metrics for application delivery solutions.

The reason for this is simple – you aren’t increasing the underlying speed or capacity, you’re only the load that can be handled by the device. That means the overall utilization is higher, and it is nearly a priori knowledge in networking that as utilization (load) increases, performance and capacity degrade. The result is uneven scalability as you progress through the “upgrade” of licenses. You’re still paying the same amount per increase, but each increase nets you less capacity and slower performance than the upgrade before.

Conversely, a true on-demand model, based on the same premises as cloud computing, scales more linearly. Upgrading four times nets you four times the performance at four times the cost, because the resources available also increase four times. Cost and performance scale equally with a platform-based model. Licensing-based models do not, nay they cannot, because they aren’t scaling out resources, they’re only scaling out what portion of the resources you have access to.

It’s a subtle difference but one that has a significant impact on capacity and performance.

ECONOMY of SCALE

As has been noted, as utilization of hardware increases, capacity degrades.

When we start looking at the total costs when compared to the scaling value received, it becomes apparent that the pay-as-you-grow model produces increasing costs per transaction while the platform-based model produces decreasing costs per transaction. This is simply a matter of math. If each upgrade in a pay-as-you-grow model increases the overall cost by 1/4, but returns increasingly smaller performance and capacity gains, you end up with a higher cost per transaction. Conversely, a more linear on-demand approach actually ends up producing slightly lower or consistent costs per transaction.

The economy of scale is important as it’s a fairly common financial metric used to evaluate infrastructure as it directly translates into business costs and can be used to adjust pricing and facilitate estimated expenses.

This disparity is not one that is often considered up front, as it is usually the up-front, capital investment that is most important to the initial decision. This oversight, however, almost always proves to be problematic as it is rarely the case that an organization does not need additional capacity and performance, and thus the long-term costs of Pay-as-you-Grow result in a much poorer return on investment in terms of performance than a Platform-based scalability model.

DISRUPTION and CapEx

The arguments against a platform-based model generally consist of disruptiveness of upgrades and initial costs.

Disruption is a valid concern and it is almost always true that hardware-based devices require a certain amount of disruption to upgrade. The lifting of an artificially imposed limitation on the amount of existing hardware that can be utilized, conversely, does not. This is where the cloud computing on-demand (i.e. throw more (virtual) hardware at the problem) usually diverges from the on-demand model used to scale out networking hardware, such as an application delivery controller.

The introduction of virtual application delivery controllers and the ability to seamlessly scale out in a model similar to cloud computing eliminates the disruption-based argument. There do exist models and technology which closely models a cloud computing on-demand scalability strategy that are as non-disruptive as scaling out via a licensing-based model.

This leaves the initial cost argument, which generally boils down to a CapEx versus OpEx argument. You are going to pay over the long run, the question is whether you pay up front or over time and what the return on those investments will ultimately be.

Just don’t let the conflation of cloud computing’s on-demand with pay-as-you-grow licensing-based models obscure what those real costs will be.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,cloud computing,scalability,pay-as-you-grow,on-demand,load balancing,virtualization,performance,network,blog

F5 und Traffix.

Stefan Maierhofer — Wed, 22 Feb 2012 11:47:56 GMT

Nun haben wir also einen „Neuzugang“ in der F5-Familie: Traffix Systems, ein israelischer Anbieter von 4G Signalisierungsprodukten gehört nun zu F5. Warum diese Übernahme Sinn macht und was passiert, wenn heute immer mehr Daten- und Sprachdienste in einem Netzwerk auflaufen, beschreibt meine Kollegin Lori McVittie ziemlich umfangreich und sehr bildlich in Ihrem Blog-Artikel When Worlds Collide.

Carrier und Service Provider stellen für F5 in EMEA große und wichtige Kunden dar. Ein großer Teil unseres Geschäfts resultiert aus diesen Bereichen. Aus diesem Grund schauen wir kontinuierlich nach Möglichkeiten diesen Kunden ganzheitliche Lösungsansätze zu bieten. Die Integration von Traffix in unser Unternehmen bringt uns ein Kernelement für F5´s Service Provider Lösungsstrategie für Carrier. Es wird F5 nun möglich sein den Signalverkehr zusätzlich zum Subscriber IP-Verkehr zu optimieren.

Service Provider hier in Deutschland und EMEA können von F5 ab jetzt eine noch bessere Unterstützung erwarten, um den Bedürfnissen ihrer Kunden Rechnung zu tragen.

F5 and vCloud Director: A Yellow Bricks How-to

F5 Networks News — Wed, 22 Feb 2012 10:56:24 GMT

Guest Post by: Duncan Epping, Principal Architect in the Technical Marketing group at VMware

This post was originally published Feb 16, 2012 at: Using F5 to balance load between your vCloud Director cells and is reprinted with permission of the author

** I want to thank Christian Elsen and Clair Roberts for providing me with the content for this article **

A while back Clair contacted me and asked me if I was interested in getting the info to write an article about how to setup F5’s Big IP LTM VE to front a couple of vCloud Director cells. As you know I used to be part of the VMware Cloud Practice and was responsible for architecting vCloud environments in Europe. Although I did design an environment where F5 was used I never actually was part of the team who implemented it, as it is usually the Network/Security team who takes on this part. Clair was responsible for setting this up for the VMworld Labs environment and couldn’t find many details around this on the internet, hence the reason for this article.

This post will therefore outline how to setup the below scenario of distributing user requests across multiple vCloud Director cells.

figure 1:

For this article we will assume that the basic setup of the F5 Big IP load balancers has already been completed. Besides the management and HA interface, one interface will reside on the external – end-user facing – part of the infrastructure and another interface on the internal – vCloud director facing – part of the infrastructure.

Configuring a F5 Big IP load balancer to front a web application usually requires a common set of configuration steps:

Creating a health monitor
Creating a member pool to distribute requests among
Creating the virtual server accessible by end-users

Let’s get started configuring the health monitor. A monitor is used to “monitor” the health of the service. Go to the Local Traffic page, then go to monitors. Add a monitor for vCD_https. This is unique to vCD, we recommend to use the following string “http://<cell.hostname>/cloud/server_status“ (figure 3). Everything else can be set to default.

figure 2:

figure 3:

figure 4:

Next you will need to define the vCloud Director Cells as nodes of a member pool. The F5 Big IP will then distribute the load across these member pool nodes. You will need to type in the IP address, add the name and all the info. We suggest to use 3 vCloud Director Cells as a minimum. Go to Nodes and check your node list, depicted in figure 5. You should have three defined as shown in figure 5 and 6. You can create these by simply clicking “Create” and defining the ip-address and the name of the vCD Cell

figure 5:

figure 6:

figure 7:

Now that you have defined the cells you will need to pool them. If vCloud Director needs to respond to both http and https (figure 8 and 9) you will need to configure two pools. Each pool will have the three cells added. We are going with most of the basics settings. (Pools menu) Don’t forget the Health Monitors.

figure 8:

figure 9:

Now validate if the health monitor has been able to successfully communicate with the vCD cells, you should see a green dot! The green dot means that the appliance can talk to the cells and that the health monitoring is fine and getting results on the query.

Last you will need to create a Virtual IP (VIP) per server. In this case two “virtual servers” (as the F5 appliance names them, figure 10) will have the same IP but with different ports!, http and https. These can be simply created by clicking “Create” and then define the IP Address which will be used to access the cells (figure 11).

figure 10:

figure 11:

Repeat the above steps for the Consoleproxy IP address of your vCD setup.

Last you will need to specify these newly created VIPs in the vCD environment.

See Hany’s post on how to do the vCloud Director part of it… it is fairly straight forward. (I’ll give you a hint: Administration –> System Settings –> Public Addresses)

Connect with F5:

Latest F5 Information

Technorati Tags: F5,F5 News,VMware,virtualization,BIG-IP,load balancing,how-to,vCloud Director,vCloud,blog

Network Virtualization Reality Check.

Don MacVittie — Tue, 21 Feb 2012 19:43:38 GMT

There are quite a few pundits out there that would like to convince you that a purely virtual infrastructure is the wave of the future. Most of them have a bias to drive them to this conclusion, and they’re hoping you’ll overlook it. Others just want to see everything virtualized because they’re aware of the massive benefits server and even in most cases desktop virtualization has brought to the enterprise.

But there’s always a caveat with people who look ahead and see One True Way. The current state of high tech rarely allows for a single architectural solution to emerge, if for no other reason than the existence of a preponderance of legacy code, devices, etc. Ask anyone in storage networking about that. There have been several attempts at One True Way to access your storage. Unfortunately for those who propound them, the market continues to purchase what’s best for its needs, and that varies greatly based upon the needs of an organization – or even an application within an organization.

Network appliances – software running on Commercial Off The Shelf (COTS) server hardware – have been around forever. F5 BIG-IP devices used to fall into this category, and like most networking companies that survive their first few years, we eventually created purpose-built hardware to handle the networking speeds required of a high-performance device. The software IP stacks available weren’t fast enough, and truth be told, the other built-in bottlenecks of commodity hardware were causing performance problems too.

And that, in a nutshell, is why network virtualization everywhere will not be the future. There are certainly places where virtualized networking gear makes sense – like in the cloud, where you don’t have physical hardware deployed. But there are places – like your primary datacenter – where it does not. The volume that has to be supported on a VM which will have at least two functional operating systems (the VM host and the VM client) between the code and the hardware, and physical hardware that is more than likely shared with other client images, is just not feasible in many situations.

You can scale out, that is truth, but how many VMs equals a physical box? Because it’s not just the cost of the VMs, the server they’re residing on costs money to acquire and maintain too, and as you scale out it takes more and more of them. Placing a second instance of a VM on the server to alleviate a problem with network throughput would be… Counterproductive, after all.

Image Courtesy of iPadWalls.com

So there are plenty of reasons to make use of a hybrid environment in networking architecture, and those reasons aren’t going away any time soon. So as I often say, treat pundits who are trying to tell you there is only one wave of the future with a bit of skepticism, they normally have a vested interest in seeing a particular solution be the One True Way.

Just like in the storage networking space, ignore those voices that don’t suit your needs, choose solutions that are going to address your architecture and solve your problems. And they’ll eventually stop trying to tell you what to do, because they’ll realize the futility of doing so. And you’ll still be rocking the house, because in the end it is about you, serving the needs of the business, in the manner that is most efficient.

*** Disclaimer: yes, F5 sells both physical and virtual ADCs, which are in the category “network infrastructure”, but I don’t feel that creates a bias in my views, it simply seems odd to me to claim that all solutions are best served by one or the other. Rather I think that F5 in general, like me in particular, sees the need for both types of solutions and is fulfilling that need.

Think of it like this… I reject One True Way in my Roleplaying, and I reject it in my technology. The two things I most enjoy, so working at F5 isn’t the cause of my belief, just a happy coincidence.

Technorati Tags: Virtualization,Cloud,Network,Infrastructure,Appliances,Application Delivery Controller,IT Management,F5 BIG-IP,F5 Networks,Don MacVittie,blog

Connect with Don:	Connect with F5:

F5 and Traffix: When Worlds Collide

Lori MacVittie — Tue, 21 Feb 2012 16:16:35 GMT

#mwc12 #traffix #mobile Strategic points of control are critical to managing the convergence of technology in any network - enterprise or carrier

What happens when technology converges? When old meets new?

A fine example of what might happen is what has happened in the carrier space as voice and data services increasingly meet on the same network, each carrying unique characteristics forward from the older technology from which they sprung. In the carrier space having moved away from older communications technology does not mean having left behind core technology concepts. Though voice may be moving to IP with the advent of LTE/4G, it still carries with it the notion of signaling as a means to manage communication and users, and the impact on networks from that requisite signaling mechanism is significant.

Along with the well-discussed and often-noted explosive growth of mobile and its impact on the enterprise comes a less-discussed and rarely noted explosive growth of signaling traffic and its impact on service providers. Enterprise experience with voice and signaling remains largely confined to SIP-focused deployments and are on a scale much smaller than that of the service provider. Hence the term “carrier-grade” to indicate the much more demanding environment. The number of signaling messages in 4G networks, for example, associated with a 3 minute IP voice call with data is 520. The same voice call today requires only 3. That exponential growth will put increasing pressure on carriers and require massive scale of infrastructure to support.

All that signaling traffic in carrier networks occurs via Diameter, the standard agreed upon by 3GPP (3^rd Generation Partner Project) for network signaling in all 4G/LTE networks. Diameter is to carrier networks what HTTP is to web applications today: it’s the glue that makes it all happen. As the preeminent Diameter routing agent (DRA) for for 3G, 4G / LTE and IMS environments, Traffix’ solutions are fluent in the signaling language used by carriers across the globe to identify users, manage provisioning, and authorize access to services and networks. One could reasonably describe Diameter as the Identity and Access Management (IAM) technology of choice for service providers. When a user does anything on a 4G network, Diameter is involved somehow.

What Traffix Signaling Delivery Controller (which is both a highly capable DRA as well as Diameter Edge Agent (DEA)) offers is a strategic point of control in the service providers network, serving as an intelligent tier in that network that enables interoperability, security, scale, and flexibility in how signaling traffic is managed and optimized. That should sound familiar, as F5 is no stranger to similar responsibilities in enterprise and web-class data centers today. F5 with its application and control plane technologies serves as an intelligent tier in the network that ensures interoperability, security, scale, and flexibility for how applications and services are delivered, secured, and optimized. What service providers do with Diameter – user identification, permission to roam, authorization to use certain networks, basically anything a user does on a 4G network – is akin to what F5 does with application delivery technology in the data center.

F5’s vision has been to create a converged carrier architecture that unifies IP services end-to-end across the application, data, and control plane. Diameter is a foundational piece of that puzzle, just as any-IP support is critical to providing that same converged application services approach in the data center, a data center routing agent, if you will.

Both approaches are ultimately about context, control, and collaboration.

CONVERGENCE BREEDS FRAGMENTATION

These three characteristics (context, control, collaboration) are required for a dynamic data center to handle the volatility inherent in emerging data center models as well as the convergence in service provider networks of voice and data. But as technologies converge, supporting infrastructure tends to fragment. This dichotomy is clearly present even in the enterprise, where unified communications (UC) implementations are creating chaos. In its early days, Diameter deployments in service provider networks experienced similar trends, and it was the development of the DRA that resolved the issue, bringing order out of chaos and providing a strategic point of control through which subscriber activity could be more efficiently managed. Out of chaos, order. That’s the value Traffix brings to carrier networks with its Signaling Delivery Controller (SDC). Traffix solutions optimize signaling traffic, offering service provider operators scalability, availability, visibility, interoperability, and more in an operationally consistent solution. With the number of mobile devices predicted to exceed the world population in the next year, and the advanced services those devices provide driving exponential growth in signaling traffic, the need to optimize signaling traffic is top of mind for most service providers today.

When diverse systems converge, their infrastructure must also converge in terms of support for the resulting unified system. This is particularly true as mobile and virtual desktops become more prevalent and bring with them their own unique delivery challenges to both the service provider and data center networks.

The two worlds are colliding, out there on the Internets and inside data centers, with more and more IP-related traffic requiring management within the carrier networks, and more and more traditionally carrier network traffic such as voice being seen inside the data center. What both worlds need is a fully end-to-end IP core infrastructure solution – one that can support IP and Diameter and scale regardless of whether the need is enterprise-class or carrier-grade. One that maintains context and manages access to resources across both voice and data and does so both seamlessly and transparently.

Bringing together F5’s control plane with that of Traffix brings a holistic approach to controlling a converged voice-data network that enhances critical network functions across the application, control, and data planes.

Traffix aligns well with F5’s overall vision of enabling intelligence in the network and providing context and control for all types of network services – whether carrier or enterprise.

Additional Resources:

F5 Networks Acquires Traffix Systems

The LTE signaling challenge

F5 Circles The Wagons and Adds Diameter to its Portfolio

Traffix Systems

F5 Sends LTE Signal With Acquisition

F5 Friday: The Dynamic Control Plane

Connect with Lori: Connect with F5:

Related blogs & articles:

What Does Mobile Mean, Anyway?

What is a Strategic Point of Control Anyway?

Force Multipliers and Strategic Points of Control Revisited

What CIOs Can Learn from the Spartans

The Three Axioms of Application Delivery

At the Intersection of Cloud and Control…

Carrier Grade DNS: Not your Parents DNS

The New Data Center Firewall Paradigm

Traffix Systems’ Blog

Technorati Tags: F5,MacVittie,Traffix Systems,Diameter,service provider,network,strategic point of control,AAA,security,availability,performance,blog

Ode to FirePass

Pete Silva — Mon, 20 Feb 2012 20:52:32 GMT

A decade ago, remote VPN access was a relatively new concept for businesses; it was available only to a select few who truly needed it, and it was usually over a dial-up connection. Vendors like Cisco, Check Point, and Microsoft started to develop VPN solutions using IPsec, one of the first transport layer security protocols, and RADIUS Server. At first organizations had to launch the modem and enter the pertinent information, but soon client software was offered as a package. This client software had to be installed, configured, and managed on the user’s computer. As high-speed broadband became a household norm and SSL/TLS matured, the SSL VPN arrived, allowing secure connections via a browser-based environment. Client pre-installation and management hassles were eliminated; rather the masses now had secure access to corporate resources with just a few browser components and an appliance in the data center.

These early SSL VPNs, like the first release of F5’s FirePass, offered endpoint checks and multiple modes of access depending on user needs. At the time, most SSL VPNs were limited in areas like overall performance, logins per second, concurrent sessions/users, and in some cases, throughput. Organizations that offered VPN extended it to executives, frequent travelers, and IT staff, and it was designed to provide separated access for corporate employees, partners, and contractors over the web portal. But these organizations were beginning to explore company-wide access since most employees still worked on-site.

Today, almost all employees have multiple devices, including smartphones, and most companies offer some sort of corporate VPN access. By 2015, 37.2 percent of the worldwide workforce will be remote and therefore mobile—that’s 1.3 billion people. Content is richer, phones are faster, and bandwidth is available—at least via broadband to the home. Devices need to be authenticated and securely connected to corporate assets, making a high-performance Application Delivery Controller (ADC) with unified secure access a necessity. As FirePass is retired, organizations will have two ADC options with which to replace it: F5 BIG-IP Edge Gateway, a standalone appliance, and BIG-IP Access Policy Manager (APM), a module that can be added to BIG-IP LTM devices. Both products are more than just SSL VPNs—they’re the central policy control points that are critical to managing dynamic data center environments.

A Little History

F5’s first foray into the SSL VPN realm was with its 2003 purchase of uRoam and its flagship product, FirePass. Although still small, Infonetics Research predicted that the SSL VPN market will swell from around $25 million [in 2002] to $1 billion by 2005/6 and the old meta Group forecasted that SSL-based technology would be the dominant method for remote access, with 80 percent of users utilizing SSL by 2005/6. They were right—SSL VPN did take off.

Using technology already present in web browsers, SSL VPNs allowed any user from any browser to type in a URL and gain secure remote access to corporate resources. There was no full client to install—just a few browser control components or add-on to facilitate host checks and often, SSL-tunnel creation. Administrators could inspect the requesting computer to ensure it achieved certain levels of security, such as antivirus software, a firewall, and client certificates. Like today, there were multiple methods to gain encrypted access. There was (and still is) the full layer-3 network access connection; a port forwarding or application tunnel–type connection; or simply portal web access through a reverse proxy.

SSL VPNs Mature

With more enterprises deploying SSL VPNs, the market grew and FirePass proved to be an outstanding solution. Over the years, FirePass has lead the market with industry firsts like the Visual Policy Editor, VMware View support, group policy support, an SSL client that supported QoS (quality of service) and acceleration, and integrated support with third-party security solutions. Every year from 2007 through 2010, FirePass was an SC Magazine Reader Trust finalist for Best SSL VPN.

As predicted, SSL VPN took off in businesses; but few could have imagined how connected the world would really become. There are new types of tablet devices and powerful mobile devices, all growing at accelerated rates. And today, it’s not just corporate laptops that request access, but personal smartphones, tablets, home computers, televisions, and many other new devices that will have an operating system and IP address.

As the market has grown, the need for scalability, flexibility, and access speed became more apparent. In response, F5 began including the FirePass SSL VPN functionality in the BIG-IP system of Application Delivery Controllers, specifically, BIG-IP Edge Gateway and BIG-IP Access Policy Manager (APM). Each a unified access solution, BIG-IP Edge Gateway and BIG-IP APM are scalable, secure, and agile controllers that can handle all access needs, whether remote, wireless, mobile, or LAN.

The secure access reigns of FirePass have been passed to the BIG-IP system; by the end of 2012, FirePass will no longer be available for sale. For organizations that have a FirePass SSL VPN, F5 will still offer support for it for several years. However those organizations are encouraged to test BIG-IP Edge Gateway or BIG-IP APM.

Unified Access Today

The accelerated advancement of the mobile and remote workforce is driving the need to support tens of thousands concurrent users. The bursting growth of Internet traffic and the demand for new services and rich media content can place extensive stress on networks, resulting in access latency and packet loss. With this demand, the ability of infrastructure to scale with the influx of traffic is essential. As business policies change over time, flexibility within the infrastructure gives IT the agility needed to keep pace with access demands while the security threats and application requirements are constantly evolving. Organizations need a high-performance ADC to be the strategic point of control between users and applications. This ADC must understand both the applications it delivers and the contextual nature of the users it serves.

BIG-IP Access Policy Manager

BIG-IP APM is a flexible, high-performance access and security add-on module for either the physical or virtual edition of BIG-IP Local Traffic Manager (LTM). BIG-IP APM can help organizations consolidate remote access infrastructure by providing unified global access to business-critical applications and networks. By converging and consolidating remote access, LAN access, and wireless connections within a single management interface, and providing easy-to-manage access policies, BIG-IP APM can help free up valuable IT resources and scale cost-effectively. BIG-IP APM protects public-facing applications by providing policy-based, context-aware access to users while consolidating access infrastructure.

BIG-IP Edge Gateway

BIG-IP Edge Gateway is a standalone appliance that provides all the benefits of BIG-IP APM—SSL VPN remote access security—plus application acceleration and WAN optimization services at the edge of the network—all in one efficient, scalable, and cost-effective solution.

BIG-IP Edge Gateway is designed to meet current and future IT demands, and can scale up to 60,000 concurrent users on a single box. It can accommodate all converged access needs, and on a single platform, organizations can manage remote access, LAN access, and wireless access by creating unique policies for each. BIG-IP Edge Gateway is the only ADC with remote access, acceleration, and optimization services built in. To address high latency links, technologies like intelligent caching, WAN optimization, compression, data deduplication, and application-specific optimization ensure the user is experiencing the best possible performance, 2 to 10 times faster than legacy SSL VPNs. BIG-IP Edge Gateway gives organizations unprecedented flexibility and agility to consolidate all their secure access methods on a single device.

FirePass SSL VPN Migration
A typical F5 customer might have deployed FirePass a few years ago to support RDP virtual desktops, endpoint host checks, and employee home computers, and to begin the transition from legacy IPsec VPNs. As a global workforce evolved with their smartphones and tablets, so did IT's desire to consolidate their secure access solutions. Many organizations have upgraded their FirePass controller functionality to a single BIG-IP appliance.

Migrating any system can be a challenge, especially when it is a critical piece of the infrastructure that global users rely on. Migrating security devices, particularly remote access solutions, can be even more daunting since policies and settings are often based on an identity and access management framework. Intranet web applications, network access settings, basic device configurations, certificates, logs, statistics, and many other settings often need to be configured on the new controller.

FirePass can make migrating to BIG-IP Edge Gateway or BIG-IP APM a smooth, fast process. The FirePass Configuration Export Tool, available as a hotfix (HF-359012-1) for FirePass v6.1 and v7, exports configurations into XML files. Device management, network access, portal access, and user information can also all be exported to an XML file. Special settings like master groups, IP address pools, packet filter rules, VLANS, DNS, hosts, drive mappings, policy checks, and caching and compression are saved so an administrator can properly configure the new security device. It’s critical that important configuration settings are mapped properly to the new controller, and with the FirePass Configuration Export Tool, administrators can deploy the existing FirePass configurations to a new BIG-IP Edge Gateway device or BIG-IP APM module. A migration guide will be available shortly.

SSL VPNs like FirePass have helped pave the way for easy, ubiquitous remote access to sensitive corporate resources. As the needs of the corporate enterprise change, so must the surrounding technology tasked with facilitating IT initiates. The massive growth of the mobile workforce and their devices, along with the need to secure and optimize the delivery of rich content, requires a controller that is specifically developed for application delivery. Both BIG-IP Edge Gateway and BIG-IP APM offer all the SSL VPN functionality found in FirePass, but on the BIG-IP platform.

ps

Resources:

2011 Gartner Magic Quadrant for SSL VPNs

F5 Positioned in Leaders Quadrant of SSL VPN Magic Quadrant

SOL13366 - End of Sale Notice for FirePass

SOL4156 - FirePass software support policy

Secure Access with the BIG-IP System | (whitepaper)

FirePass to BIG-IP APM Migration Service

F5 FirePass to BIG-IP APM Migration Datasheet

FirePass Wiki Home

Audio Tech Brief - Secure iPhone Access to Corporate Web Applications

In 5 Minutes or Less - F5 FirePass v7 Endpoint Security

Pete Silva Demonstrates the FirePass SSL-VPN

Technorati Tags: F5, infrastructure 2.0, integration, cloud connect, Pete Silva, security, business, education, technology, application delivery, intercloud, cloud, context-aware, infrastructure 2.0, automation, web, internet

Connect with Peter: Connect with F5:



Moore’s (Traffic) Law

Lori MacVittie — Mon, 20 Feb 2012 13:10:00 GMT

#centaur #40gbe Pop quiz time – and you get +100 geek points if you get this one right.

What was the main difference between a 386SX and a 386DX?

If you answered (without using Google) the data bus (16-bit for an SX and 32-bit for a DX) then award yourself 100 geek points and a pat on the back.

How, you are asking, is this relevant to Moore’s Law? Well, if you recall, Moore’s law is, in layman’s terms, that processing power doubles approximately every two years. A little known corollary (little known because I just made it up) should be that along with processing power, traffic – data – on the network always significantly increases along with with processing power. Call it Moore’s Traffic Law.

A variety of industry analysts and experts have been predicting such growth for years now.

"We expect the Ethernet Switch market to experience two significant years of market growth in 2013 and 2014 from the migration of servers towards 10 Gigabit Ethernet," said Alan Weckel, Senior Director of Dell'Oro Group. "We believe that in 2013, most large enterprises will upgrade to 10 Gigabit Ethernet for server access through a mix of connectivity options ranging from blade servers, SFP+ direct attach and 10G Base-T.

-- Data Center to Drive Ethernet Switch Revenue Growth through 2016, According to Dell'Oro Group Forecast

Back in 2007, an IEEE presentation also described this growth, attributing it in part to, you guessed it, Moore’s Law:

Global IP traffic has increased eightfold over the past 5 years, and will increase fourfold over the next 5 years. Overall, IP traffic will grow at a compound annual growth rate (CAGR) of 32 percent from 2010 to 2015.

Server I/O bandwidth generators

Moore’s Law processing improvements

Data center virtualization

Networked storage

Clustered servers

Internet applications (e.g. IPTV, VoIP, Web2.0, Finance)

-- IEEE April 2007 from http://www.ieee802.org/3/hssg/public/apr07/hays_01_0407.pdf

Interestingly, the rate at which core networking doubled is faster than Moore’s Law’s interval of 24 months, according to one industry expert:

The presenters at the conference made a compelling case that server IO doubled every 24 months, while core networking doubled every 18 months. Server bus architectures must also mature to take advantage of the high bandwidth interconnect. This led to the idea to create 100Gb for the core (between switches) and 40Gb for the distribution/aggregation (pedestal/rack/blade servers to switches). As for the uses for these speeds, it is the next generation of servers which are characterized by dense computing and high utilization through virtualization which will use 40Gb and 100Gb will enable the success of 10Gb servers.

-- 40Gb and 100Gb Ethernet status and outlook (March 2010), Stuart Miniman

So how does this all relate again to the difference between a 386SX and 386DX? Well, if you were a geek back when these models were popular, you generally built your own desktop. And when you built that desktop you had to choose a motherboard. If you could afford it, you got the DX because the bus speed difference was noticeable; it was important to the performance of applications because one of the primary bottlenecks in a computer is – you guessed it – the data bus speed. It’s equivalent to having a very fast car, but being on the 101 at rush hour. This is relevant to today’s data center networks because one of the primary data center bottlenecks is the “data bus” speed: the network.

WHAT THIS MEANS for the NETWORK

With the growth of both server and desktop virtualization, demand for high-performance applications, increasing consumption of video, consumerization, and increasing connectivity, we’re seeing challenges in the core data center network related to bandwidth. Where 1GB between services in the data center used to suffice, we’re now seeing a need for 10GB. And when we start seeing servers and desktops leveraging fatter pipes, we start seeing a demand for fatter pipes and greater capacity at aggregation points throughout the network, like in the application delivery tier.

Adding pressure to legitimate traffic growth is the need for higher capacity protection. With Internet data center firewalls failing to withstand the load of massive and increasingly diverse attacks, scalable and higher performance security platforms are necessary to provide more comprehensive coverage. Without increased network capacity, data centers must manage the multitude of attacks through several point products, which increases the complexity, latency, and points of failure in the data center architecture.

This is unacceptable at a time when operational efficiency is required to manage constrained budgets and resources.

Switching, routing, application delivery. These critical data center components will need to increase their bandwidth capacity sooner rather than later to keep up with the growth of internet traffic (expected to quadruple by 2015¹) and the growing density of server virtualization within the data center (anticipated growth by a factor of five between 2010 and 2015²). Critical network infrastructure will need to consider Moore’s (Traffic) Law and increase dramatically its capacity to manage larger volumes of traffic – and soon.

The adoption of 40GBE is ramping up as costs decline, and that means infrastructure must also step up and meet that demand – and comply with Moore’s (Traffic) Law.

¹ Top Ten Trends and How they will affect the Data Center, Gartner, Inc, David Cappuccio December 2011

² Gartner, From Virtual Machines to cloud computing , Tom Bittman, December 2011

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Friday: Goodbye Defense in Depth. Hello Defense in Breadth.

The Three Axioms of Application Delivery

The Fundamental Problem with Traditional Inbound Protection

Desktop VDI May Be Ready for Prime Time but Is the Network?

Performance in the Cloud: Business Jitter is Bad

The API is the Center of the Application (Integration) Universe

Virtualization and Cloud Computing: A Technological El Niño

Technorati Tags: F5,MacVittie,performance,40gbe,scalability,availability,hardware,network,aplication delivery,Moore's Law,DDoS,security,blog

F5 Friday. IT Brand Pulse Awards

Don MacVittie — Fri, 17 Feb 2012 21:07:26 GMT

IT Brand Pulse carries a series of reports based upon surveys conducted amongst IT professionals that attempt to ferret out the impression that those working in IT have of the various vendors in any given market space. Their free sample of such a report is the November 2010 FCoE Switch Market Leader Report and it is an interesting read, though I admit it made me want to paw through some more long-form answers from the participants to see what shaped these perceptions. The fun part is trying to read between the lines, since this is aimed at the perceived leader, you have to ask how much boost Cisco and Brocade received in the FCoE space just because they’re the FC vendors of choice. But of course, no one source of information is ever a complete picture, and this does give you some information about how your peers feel – whether that impression is real or not – about the various vendors out there.

It’s not the same as taking some peers to lunch, but it does give you an idea of the overall perceptions of the industry in one handy set of charts.

This February, F5 was honored by those who responded to their Load Balancer Market Leader Report with wins in three separate categories of Load Balancing – price, performance, and innovation, and took the overall title of “Market Leader” in load balancing.

We, of course, prefer to call ourselves an Application Delivery Controller (ADC), but when you break out the different needs of users, doing a survey on load balancing is fair enough. After all, BIG-IP Local Traffic Manager (LTM) has its roots in load balancing, and we think it’s tops.

IT Brand Pulse is an analyst firm that provides a variety of services to help vendors and IT staff make intelligent decisions. While F5 is not, to my knowledge, an IT Brand Pulse customer, I (personally) worked with the CEO, Frank Berry while he was at QLogic and I was writing for Network Computing. Frank has a long history in the high tech industry and a clue what is going on, so I do trust his company’s reports more than I trust most analyst firms.

We at F5 are pleased to have this validation to place next to the large array of other awards, recognition, and customer satisfaction we have earned, and intend to keep working hard to earn more such awards. It is definitely our customers that place us so highly, and for that we are very grateful. Because in the end it is about what customers do with our gear that matters. And we’ll continue to innovate to meet customer needs, while keeping our commitment to quality.

Technorati Tags: Load Balancing,Application Delivery Controller,IT Brand Pulse,Market Leader,F5 Networks,F5 Friday,Don MacVittie

Connect with Don: Connect with F5:



Related Articles and Blogs:

F5 Friday: Speed Matters

F5 Friday: No DNS? No … Anything.

F5 Friday: Zero-Day Apache Exploit? Zero-Problem

F5 Friday: Speeds, Feeds and Boats

F5 Friday: What's Inside an F5?

F5 Friday: 'IPv4 and IPv6 Can Coexist' or 'How to eat your cake and ...

F5 Friday: Performance, Throughput and DPS

F5 Friday: Domain Sharding On-Demand

F5 Friday: New Services from F5 Ease Migration and Upgrades

Working with One of Top Ten Women in the Cloud

Pete Silva — Fri, 17 Feb 2012 19:28:31 GMT

Our colleague, Lori MacVittie, has been honored with the CloudNOW Top Ten Women in Cloud Award for her contributions, accomplishments, and thought leadership. Now you might think it would be cool working with such a cloud know-it-all: she writes the best blogs/articles, she corrects you when you’re mistaken, she knows network/infrastructure/security/applications inside out, she’s not too fond of Mondays, she’s gluten-free, has a wicked sense of humor and she’s fairly feisty. Yeah, it’s fun.

I first met Lori a few years back when she started at F5 and joined the Technical Marketing Team. Prior to F5, Lori was an award-winning Senior Technology Editor at Network Computing Magazine. She conducted product research and evaluations focusing on the integration between application and network architectures. She has extensive programming experience as an application architect, as well as network and systems development and administration expertise. While many of us on the Technical Marketing Team have real world technical experience within our areas of focus, Lori crosses all disciplines. She has an amazing grasp of everything application delivery. But she does not gloat about it or make you feel silly if you didn’t know something. She has a way of teaching while correcting.

Lori has been actively involved in the cloud community, participating in a variety of both active and now- defunct standards working groups. She has been a prolific voice on the topic through a variety of publications and her blog on F5’s DevCentral, which is syndicated throughout the cloud community. Additionally, Lori has been recognized as one of the 50 top bloggers on Cloud Computing and one of the ten most powerful voices in Cloud Security by SYS-CON Media. “It is an honor to be recognized by CloudNOW with this award,” she said. “It is extremely gratifying to be recognized by an organization whose mission I respect and support.”

Not only has Lori been recognized by the industry, but it's also awesome to work with her and F5 is better for having her influence across the market. We’re proud of her accomplishments and honored to be working alongside such a knowledgeable person. [Collective ‘awwwwwwwww’] Not to mention that I know having her name so many times in this blog will be good SEO!

Here is an interview I did with Lori a couple years back at Cloud Connect: Interview with Lori MacVittie at Cloud Connect

So, how do we build a cloud again, Lor?

ps

Technorati Tags: video, F5, cloudnow, Cloud Computing, Lori MacVittie, social media, application delivery

Connect with Peter: Connect with F5:



F5 Friday: Doing VDI, Only Better

Lori MacVittie — Fri, 17 Feb 2012 13:31:00 GMT

#F5 does #VDI, and it does it better.

There are three core vendors and protocols supporting VDI today. Microsoft with RDP, Citrix with ICA, and VMware with PCoIP. For most organizations a single vendor approach has been necessary, primarily because the costs associated with the supporting network and application delivery network infrastructure required to deliver VDI with the appropriate levels of security while meeting performance expectations of users and the need to maintain high availability.

It’s a tall order that’s getting taller with every mobile client introduced, especially when you toss in a liberal dose of enforcing policies regarding access to virtual desktops.

Most folks are well aware of F5’s long history of deep integration with its partners Microsoft and VMware. Whether it’s integrating with management systems or designing, testing, and documenting the often times complex joint architectures required to deliver enterprise-class applications like SharePoint and Exchange or building out a dynamic data center model to support cloud computing , F5 works in tandem with its partners to ensure the best experience possible not only for the ultimate consumers but for the IT operations folks who must deploy the solutions.

But what most folks aren’t likely as aware of is F5’s commitment and expertise to delivering Citrix VDI as well. That’s natural. After all, Citrix competes with F5 at the application delivery tier and it might seem natural to assume that Citrix could deliver its own technology better than any competitor.

But that assumption ignores that F5’s core focus has been and continues to be unified application delivery rather than applications – like VDI - themselves. That unified is in bold because it’s a key factor in why F5 is able to deliver all VDI solutions better, faster, and more efficiently than any other solution today.

See, F5’s approach since introducing v9 and its platform has been about the integration of application delivery services. Whether those services reside on the same physical (or virtual) platform is not as important as the integration and collaboration between those services that is made possible by being designed, developed, and ultimately deployed on a common, high-speed, high-security application delivery platform.

Consider, for example, the case of a comprehensive Citrix VDI delivery solution:

That’s a lot of components, each of which adversely impacts performance and increases operational risk by adding additional complexity and components to the architecture. That’s ignoring the cost, as well, added by not only the need to deploy these solutions but to power them, manage them, and maintain them over time. It’s costly, it’s complex, and it’s ultimately not very extensible.

Authentication, for example, must be managed in multiple locations, which increases the risk of misconfiguration or human error, and makes it more likely that orphaned identities will be left behind, always a concern as it creates an opportunity for a breach. This solution also requires manual scripting to integrate the disparate authentication sources, yet another tedious, manual and error-prone process.

Now consider the same solution, but leveraging F5 and its platform with BIG-IP Local Traffic Manager and BIG-IP Access Policy Manager deployed:

Consolidated (and integrated) authentication. Highly extensible policy management and enforcement, and we’ve eliminated the Web Interface Servers (and NetScalers, but as we’ve replaced them with BIG-IP that’s more of a wash than a win).

But it’s not just about reducing the complexity (and ultimately the cost) of such a deployment. BIG-IP LTM and APM can simultaneously support Microsoft and VMware VDI while delivering Citrix VDI – as well as a host of other applications. F5’s solution isn’t a VDI delivery solution, it’s an application delivery solution with support for all VDI implementations and protocols. That includes Citrix Session Reliability to session roaming and reconnection as well as SmartAccess filters. F5 BIG-IP APM can populate SmartAccess filter values based upon any information discovered using VPE(source IP address, AV presence, client certificate presence, etc.) and pass them to the XML broker for evaluation.

And let’s not forget about Citrix Multi-Streaming, which to give Citrix credit where due is an innovative solution to the problem of traffic prioritization in VDI delivery. If you aren’t familiar with Multi-streaming, it was introduced in XenDesktop 5.5 & XenApp 6.5 and uses multiple TCP connections (aka Multi-Stream ICA) to carry the ICA traffic between the client and the server. Each of the connections is associated with a different class of service, which allows the network administrator to prioritize each class of service, independently from each other, based on the TCP port number used for the connection. F5 supports Multi-Streaming and has for some time now. No worries.

Then there’s VMware PCoIP – which can be challenging, especially when paired with DTLS for security. F5 has that covered, too, as well as its long-term support for optimal delivery of Microsoft-based solutions including its broad set of VDI solutions .

I know, you’ve heard configuring F5 BIG-IP is hard and cumbersome. Well, in the past that may have been true but the introduction of iApp with BIG-IP v11 has changed that tune from a dirge to a delightful melody. iApp deployment templates and accompanying deployment guides for XenApp and XenDesktop make deploying BIG-IP painless and far less error-prone than manual processes.

One of the drawbacks of VDI architectural complexity is it often presents itself as a single-vendor solution – and a reason for a single vendor virtualization strategy. If your application delivery and access management solution is capable of unifying access while delivering secure, highly performing, very available <virtual, physical> <desktops, applications, solutions> of any flavor, you’d have more of a choice in what your overall architecture would look like. That kind of choice is enabled through flexibility of the underlying application delivery network infrastructure, which is exactly the role F5 plays in your data center.

If your application delivery solution is a flexible platform and not a product, then your network becomes an enabler of architecture and choice rather than being the limiting factor.

VDI Resources:

Updated Citrix XenApp/XenDesktop APM Template

Citrix XenApp/XenDesktop Combined Load-balancing iApp

VMware View 5 iApp Template

Delivering Virtual Desktop Infrastructure with a Joint F5-Microsoft Solution

Optimizing VMware View VDI Deployments

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Friday: A Single Namespace to Rule Them All (Overcoming VMware Pod Limitations)

F5 Friday: Cookie Cutter vApps Realized (Overcoming IP address dependencies to enable application mobility)

More Users, More Access, More Clients, Less Control

WILS: The Importance of DTLS to Successful VDI

From a Network Perspective, What Is VDI, Really?

Scaling VDI Architectures

VMworld 2011: F5 BIG-IP v11 iApps for Citrix

Technorati Tags: F5,F5 Friday,MacVittie,blog,VDI,Citrix,XenApp,XenDesktop,v11,iApp,BIG-IP,BIG-IP APM,VMware,Microsoft,VMware View,virtualization,application delivery

Servicebereitstellung … und F5

Thorsten Freitag — Thu, 16 Feb 2012 14:03:17 GMT

Serviceanbieter stehen ständig vor der Herausforderung, die Kosten für die Bereitstellung eines differenzierten Services, die Aufrechterhaltung eines durchschnittlichen Erlöses pro Kunde (ARPU) und die Erwartungen an die Dienstgüte (QoS) abzuwägen. Eine sehr wettbewerbsorientierte Branche lässt keinen einzigen Fehler zu.

Aber die Möglichkeiten für Fehler sind zahlreich, insbesondere im mobilen Bereich, in dem die ständigen Kämpfe zwischen Bandbreite und Leistung in direktem Widerspruch zur erforderlichen Technologie stehen. Aber auch im Festnetzbereich gibt es zahlreiche Punkte in der Servicebereitstellung, an denen Betreiber mehr Kontrolle und Funktionen benötigen, um die Bandbreite in Relation zu den angebotenen Services und den Abonnenten, die diese benutzen, verwalten zu können.

Aufgrund der Komplexität und Anforderungen der verschiedenen Services wird das Versprechen von Kosteneinsparungen für ein konvergiertes IP-Netzwerk, das Sprache, Daten und Video bereitstellt, über eine konsolidierte und integrierte Architektur nicht unmittelbar eingelöst werden. Deshalb werden ähnliche Funktionen wie NAT, IPv6, DNS, AAA, Optimierung, Steuerung des Datenverkehrs und Lastausgleich oft für jedes Serviceangebot separat bereitgestellt.

Eine weitere akute Herausforderung ist eine passende Methode für die Migration von Benutzern von gemischten leitungs-/paketvermittelten Netzwerken zu den IP-Core- und Zugriffsnetzwerken der nächsten Generation, die mehr Kapazität, geringere Betriebskosten und eine schnellere Bereitstellung von differenzierten Mehrwertservices versprechen. Die Migration von IPv4 zu IPv6 bringt neben den vielen Vorteilen des neuen Protokolls das zusätzliche komplexe Problem der Rückwärtskompatibilität mit sich.

Im Idealfall ist die Lösung ein architekturbasierter Ansatz, der die Grundlage für eine vereinheitlichte Lösung schafft, die Komplexität, Investitionskosten und Betriebskosten reduziert und gleichzeitig eine schnelle und effiziente Implementierung neuer und differenzierter Services ermöglicht.

Diese Lösung basiert auf einer tiefgehenden Sitzungsintelligenz, die einen echten Einblick in den Datenverkehr und die bereitgestellten Services gewährt. Darüber hinaus bietet die Lösung eine integrierte Serviceverwaltung, die sich nahtlos in ergänzende Services und Back-Office-Systeme einfügt, Programmierbarkeit für eine schnelle, effiziente und zuverlässige Richtliniendurchsetzung sowie Anpassbarkeit an alle Serviceangebote. Letztendlich reduziert die Lösung die Kosten für die Serviceverwaltung, steigert die Zuverlässigkeit und kann für die einfache Einrichtung neuer Services genutzt werden, die neue Umsatzmöglichkeiten und einen höheren durchschnittlichen Erlös pro Kunde generieren.

Lassen Sie uns jetzt über die Rolle von F5 im Bereich der Servicebereitstellung auf dem diesjährigen Mobile World Congress sprechen. Sie finden uns in Halle 1 an Stand 1H21. Bitte wenden Sie sich an r.stromberg@f5.com, wenn Sie uns während der Messe treffen möchten.

Ihr Thorsten Freitag

VP Sales EMEA

SuperSizing the Data Center: Big Data and Jumbo Frames

Lori MacVittie — Thu, 16 Feb 2012 13:10:00 GMT

#centaur #40GBE Data center transformation discussions too often overlook the impact on the network – and its necessary transformation.

For many of the same reasons IPv6 migration is moving slower than perhaps it should given the urgent need for more IP addresses (to support all those cows connecting to the Internet) is the sheer magnitude of such an effort. Without the ability for IPv6-only nodes to talk to IPv4-only nodes, there’s a lot of careful planning that has to happen around the globe to ensure success and continued communication between the two incompatible protocols.

In many ways, Jumbo Frames – despite performance advantages – suffer from the same technological incompatibility. Remember that Jumbo Frames – 9000 bytes – are incompatible with regular old sized Ethernet frames (1500 bytes). It makes sense for much the same reasons – you simply can’t stuff 9000 bytes into a frame designed to hold 1500. And one of the basic rules of Ethernet is that the smallest MTU (maximum transmission unit) used by any component in a network path determines the maximum MTU for all traffic that flows along that path.

And yet the benefits of Jumbo Frames have been demonstrated many times. It reduces fragmentation overhead (the process of splitting data into chunks small enough to fit into a 1500 byte frame) which translates into lower CPU overhead on hosts. It also allows for more aggressive TCP dynamics, which results in greater throughput and better responses to some kinds of loss. But even though Jumbo Frames can deliver an increase in throughput along with a simultaneous decrease in CPU utilization they are rarely, if ever, used in a data center network.

That, however, is changing.

You might recall some predictions with respect to 10GB adoption in the data center:

"We expect the Ethernet Switch market to experience two significant years of market growth in 2013 and 2014 from the migration of servers towards 10 Gigabit Ethernet," said Alan Weckel, Senior Director of Dell'Oro Group. "We believe that in 2013, most large enterprises will upgrade to 10 Gigabit Ethernet for server access through a mix of connectivity options ranging from blade servers, SFP+ direct attach and 10G Base-T.

-- Data Center to Drive Ethernet Switch Revenue Growth through 2016, According to Dell'Oro Group Forecast

Historically in the switching market the deployment of 10G in the core networks and the use of Jumbo Frames went pretty much hand-in-hand. Until recently, however, 10GB just wasn’t making its way into the data center (costs were too high) and the only place Jumbo Frames were really seen was within storage networks, particularly in conjunction with FCIP implementations.

For the most part, a lack of support within the data center infrastructure and no real urgency for the efficiency gains that come from Jumbo Frames (and the fact that the Internet is not using Jumbo Frames from end-to-end, which pretty much kills the value proposition) meant enterprise organizations looked at Jumbo Frames with a “someday, but not right now” attitude. But with the increasing adoption of virtualization and movement of 10G networks into datacenters (in part driven by virtualization), Jumbo Frames are becoming more of a reality for a larger population of organizations.

Consider the following support and recommendations for jumbo frames within VMware’s documentation:

TCP Segmentation Offload and Jumbo Frames:
Jumbo frames must be enabled at the host level using the command-line interface to configure the MTU size for each vSwitch. TCP Segmentation Offload (TSO) is enabled on the VMkernel interface by default, but must be enabled at the virtual machine level.
-- ESX 4.0 Config Guide, page 57

Optimizing vMotion Performance
Use of Jumbo Frames is recommend for best vMotion performance.
-- Page 188 vSphere 4.0 System Admin Guide

vSphere 4 Performance
Jumbo Frames is one of the suggested means of improving CPU performance with respect to vSphere
-- CPU Performance Enhancement Advice (Table 22-6, page 278)

Add in cloud computing and a desire to more quickly move big data (virtual machines) over the WAN to cloud providers for a variety of business initiatives – a process in which the number of frames sent and low latency is key to success - and Jumbo Frames suddenly start looking a lot more like a requirement than a “Yeah, yeah, we’ll get to that eventually. Maybe.”

Virtualization and cloud computing are transformative technologies. As some have often – and loudly – reminded us, the network is part of the data center, and indeed an integral part of the data center. While we tend to focus on the management and provisioning and automation of the data center and its cultural impact, we should not overlook the impact that these technologies and the changes they bring are having – and will have – on the network.

If cloud and virtualization and consumerization and emerging technologies like HTML5 are going to transform the data center, that’s going to necessarily include the network. Ultimately, support for Jumbo Frames will be a requirement – a checkbox item – for every component in the data center.

Connect with Lori: Connect with F5:



Related blogs & articles:

Sometimes It Is About the Hardware

Live Migration versus Pre-Positioning in the Cloud

F5 and VMware–One Step Closer to the Cloud as a Seamless Data Center Extension

Cloud is an Exercise in Infrastructure Integration

Performance in the Cloud: Business Jitter is Bad

Like Cars on a Highway.

Technorati Tags: F5,MacVittie,Jumbo Frames,Vmware,vmotion,live migration,network,MTU,ethernet,performance,40GBE,blog

DevCentral Top5 02/15/2012

Colin Walker — Wed, 15 Feb 2012 23:51:34 GMT

Welcome to a special "yes I know it's Wednesday but I won't be here Friday" edition of the Top5. There has already been some great content in the last week or so, which makes it easy to do an edition mid-week, but that's not unusual. Given the amount of awesome content that can generally be found roaming the wilds of DevCentral, it isn't uncommon to have enough to fill up the Top5 by Wednesday. This week I am taking advantage of that fact. Though I have no doubt there will be still more goodness to come this week, you'll have to manage for yourselves...so dig deep and see what's out there! In the meantime, here are a few great pieces with which to get started:

iRules Concepts: Tcl, The How and Why

http://bit.ly/z9j18P

One of the questions that we get asked from time to time is, "Why Tcl". Those people are referring to the interpreter we chose as the underlying infrastructure for iRules, of course. I've answered this question several times, and frankly it belies many solid, deep dive style concepts about iRules: how they work at their core, TMM interaction, byte code compilation and more, that are worth discussing. So...that's what I did. This article looks to shed some light on iRules history, anatomy, our choices in regards to their underpinnings, and why we do what we do how we do it. What it lacks in code samples and graphs, it makes up for in sheer word count (if, you know, that's your thing) but hopefully others find it useful content...I certainly did.

Google reCaptcha Verification With Sideband Connections

http://bit.ly/A4PAma

One of the many awesome Tech Tips that George has written recently...this one eluded the Top5 in previous weeks as there was just too much good stuff to share. Having read through it again this week, though, I decided it needs to make the hit list. This shows off one of the key features in iRules for v11, sideband connections, and how to do something very handy with them. Real world applications of bleeding edge iRules features in a consumable, organized, easy to follow format ... yep, that's kind of my thing. So here it is, better late than never. Take a read and see what else George has been up to, it's definitely worth the time.

F5 ARX WAN Optimization with WOM

http://bit.ly/w9bhsg

Pushing out an example from the field is a treat for me, and this week is no exception. Michael Fabiano, one of the FSEs here at F5, put together a very solid article on ARX WAN Opt with WOM. If you've been curious about possible solutions for multi-data center storage, this is the article for you. There are many things from an F5 perspective that can be done to streamline and optimize the general multi-location storage deployment, and those benefits are broken out here in an easy to follow (and implement) format. Whether it's ARX, WOM or both that you're looking to deploy or investigate, this picture is a good one, especially given the ways they work together. Michael does a good job of making this approachable and interesting, so take a look and learn something.

F5 Friday: What's Inside an F5?

http://bit.ly/yAwUi0

Lori came through last week with a solid answer to a question that seems to take many forms with this look at what actually goes on inside F5 devices. We have come a long, long way from the old 4.x and before days. As she points out things have changed all the way up and down the stack from hardware to software, as well as many massive leaps forward conceptually, allowing us to deliver a whole new level of power. Many people don't fully understand what it is that these products we talk about all the time offer at a somewhat base level. Lori does a good job here of giving some insight into that without going so deep that she loses the passengers on the trip. If you've ever wondered about TMOS, vCMP, or any of the other magic that happens internally...take a look.

New iOS Edge Client

http://bit.ly/wE68Lv

Last but not least Pete delivered a friendly reminder today that there is a new iOS Edge Client available for download in the App store. If you, like me, are one of the many folks making use of the Edge Client from an iOS device, this new version adds some worthwhile features. I love seeing the effort being put into making our products easier to use and more accessible not just for the administrators, but for the end users as well. This new release won't change the lives of the people running the systems, but it makes it just that much easier for those of us using the products as an end user (yes, I'm an end user too), and that is valuable. I just updated my device, and figured I'd pass on the heads up as a nice way to round out the Top5 for this week.

That's it for this week, as always feel free to drop me some feedback or suggestions.

#Colin

Technorati Tags: Top5,DevCentral,iRules,Security,iOS,ARX,WAN Opt,Google,Colin Walker

New iOS Edge Client

Pete Silva — Wed, 15 Feb 2012 20:22:42 GMT

If you are running the BIG-IP Edge Client on your iPhone, iPod or iPad, you may have gotten an AppStore alert for an update. If not, I just wanted to let you know that version 1.0.3 of the iOS Edge Client is available at the AppStore.

The main updates in v1.0.3:

URI scheme enhancement allows passing configuration data to the client upon access. For example, you could have a link on the WebTop that invokes the client and forces web logon mode.

Other Bug fixes.

The BIG-IP Edge Client application from F5 Networks secures and accelerates mobile device access to enterprise networks and applications using SSL VPN and optimization technologies. Access is provided as part of an enterprise deployment of F5 BIG-IP Access Policy Manager, Edge Gateway, or FirePass SSL-VPN solutions. BIG-IP Edge Client for iOS Features:

Provides accelerated mobile access when used with F5 BIG-IP Edge Gateway.

Automatically roams between networks to stay connected on the go.

Full Layer 3 network access to all your enterprise applications and files.

I loaded it yesterday on my devices without a hitch.

ps

Related:

iDo Declare: iPhone with BIG-IP

F5 Announces Two BIG-IP Apps Now Available at the App Store

F5 BIG-IP Edge Client App

F5 BIG-IP Edge Portal App

F5 BIG-IP Edge Client Users Guide

iTunes App Store

Securing iPhone and iPad Access to Corporate Web Applications – F5 Technical Brief

Audio Tech Brief - Secure iPhone Access to Corporate Web Applications

Technorati Tags: F5, infrastructure 2.0, integration, cloud connect, Pete Silva, security, business, education, technology, application delivery, ipad, cloud, context-aware, infrastructure 2.0, iPhone, web, internet, security, hardware, audio, whitepaper, apple, iTunes

Connect with Peter: Connect with F5:



Oops! HTML5 Does It Again

Lori MacVittie — Wed, 15 Feb 2012 12:28:00 GMT

#HTML5 #infosec A multitude of security-related solutions rely upon the ability to extract and examine mime-objects from web-content. HTML5 may significantly impair their ability to do so.

The trade off between security and performance has long been a known issue across IT organizations. One of the first things to go when performance is unacceptable is a security solution. This isn’t just an IT phenomenon either; consider how many of us have disabled endpoint security solutions like anti-virus scanners to improve performance?

Our refusal to be slowed down by what may seem to some as extraneous security is what eventually led IT security professionals to revise their strategies and enforce such scans on inbound content in the network. Network-attached security scanning solutions have long been a staple of inbound e-mail and has found increasing use as a means to scan inbound web-content, as well, as an attempt to eliminate potential malware from having access to the corporate network.

IT Organizations That Trade Security for Performance Deserve Neither

A new [at the time of publication, July 2011] survey of 487 IT professionals that was conducted by Crossbeam, a provider of high-performance security gateways, finds that while 91 percent of the respondents were not only making tradeoffs between security and performance, a full 81 percent were actually disabling security features.

HTML and soon, if we believe the predictions HTML5, is the lingua franca of Internet communication. Oh, applications may speak JSON under the covers, but in the end it’s just data to be displayed to the user which means HTML(5).

What does that mean for anti-virus and malware web scanners? Well, if one of the features of HTML5 being leveraged is WebSockets, a lot. Otherwise, not much. At least not yet.

You see, WebSockets accidentally trades performance for security.

OOPS

One of the things WebSockets does to dramatically improve performance is eliminate all those pesky HTTP headers. You know, things like CONTENT-TYPE. You know, the header that tells the endpoint what kind of content is being transferred, such as text/html and video/avi. One of the things anti-virus and malware scanning solutions are very good at is detecting anomalies in specific types of content. The problem is that without a MIME type, the ability to correctly identify a given object gets a bit iffy. Bits and bytes are bytes and bytes, and while you could certainly infer the type based on format “tells” within the actual data, how would you really know? Sure, the HTTP headers could by lying, but generally speaking the application serving the object doesn’t lie about the type of data and it is a rare vulnerability that attempts to manipulate that value. After all, you want a malicious payload delivered via a specific medium, because that’s the cornerstone upon which many exploits are based – execution of a specific operation against a specific manipulated payload. That means you really need the endpoint to believe the content is of the type it thinks it is.

But couldn’t you just use the URL? Nope – there is no URL associated with objects via a WebSocket. There is also no standard application information that next-generation firewalls can use to differentiate the content; developers are free to innovate and create their own formats and micro-formats, and undoubtedly will. And trying to prevent its use is nigh-unto impossible because of the way in which the upgrade handshake is performed – it’s all over HTTP, and stays HTTP. One minute the session is talking understandable HTTP, the next they’re whispering in Lakota, a traditionally oral-only language which neatly illustrates the overarching point of this post thus far: there’s no way to confidently know what is being passed over a WebSocket unless you “speak” the language used, which you may or may not have access to.

The result of all this confusion is that security software designed to scan for specific signatures or anomalies within specific types of content can’t. They can’t extract the object flowing through a WebSocket because there’s no indication of where it begins or ends, or even what it is. The loss of HTTP headers that indicate not only type but length is problematic for any software – or hardware for that matter – that uses the information contained within to extract and process the data.

WEDGE NETWORKS

Wedge Networks, whose name you may never before heard even though you might have had content scrubbed by their devices and not known it, has a solution to the problem of disaggregating web objects without requiring specific identification by HTTP headers, thus solving this problem and several other similar ones where protocols lack the means to definitively identify specific content by type.

WedgeOS - Network Data Processor Architecture

The WedgeOS Network Data Processor ("NDP") is the proprietary architecture that allows content inspection at Gigabit speeds without impacting network performance. The WedgeOS NDP architecture revolutionized Web Security Appliances with the introduction of BeSecure. BeSecure is capable of intercepting and actively scanning all internet traffic for malicious content as it enters the network.

What they meant to say was “we do deep content inspection on streaming traffic and are able to accurately identify – and subsequently extract – MIME objects at line rate and then scan them for bad stuff you don’t want on your network.” Content comes into their device (and it’s off-the shelf hardware, I’m told), MIME objects are disaggregated regardless of transport or application protocol, shoved down a high-speed internal bus into which are plugged a variety of security scanning functions, and then shoved back out the other side, assuming all was well. Policies enable the ability to determine exactly what happens if there are anomalies or malicious code discovered.

Wedge Networks has partnered with a number of well-known and industry leading security scanning solutions and brought them together into a single device. Applying the old “crack the packet only once” doctrine, the device is able to perform its scans as fast as objects can traverse its internal bus.

The devices deploys in either proxy or transparent mode, with the latter being most popular simply due to the mitigation of disruption that can come with inserting a proxy-based solution into an established network.

Let’s assume for a moment that a Wedge Networks device really does accomplish all this – at line rate. I can’t know, I don’t evaluate products in lab environments any more, so I can take their word for it. But let’s assume it does. That opens a wide variety of possibilities – both inbound and outbound – for protecting web applications and customers alike, and not just for HTML5.

Assuming no degradation of overall performance, the ability to detect and prevent delivery of malware that may have been surgically inserted into your database or CMS via XSS or SQLi would be a boon, if only to let you know it happened much sooner and provide the time necessary to redress the infection. Nearly every rational organization scans inbound e-mail for potential risks, but very few (if any) scan outbound. We all know why – the belief that performance is more important than security, especially when consumer dollars are on the line. If Wedge Networks can do as it promises and not impede performance while still providing a valuable security service, well, that might be something to think about.

Connect with Lori: Connect with F5:



Related blogs & articles:

IT Organizations That Trade Security for Performance Deserve Neither

Performance in the Cloud: Business Jitter is Bad

The Ascendancy of the Application Layer Threat

HTML5 Web Sockets Changes the Scalability Game

HTML5 Going Like Gangbusters But Will Anyone Notice?

Fire and Ice, Silk and Chrome, SPDY and HTTP

Technorati Tags: F5,MacVittie,Wedge Networks,network,security,HTML5,WebSockets,malware,anti-virus,performance,application security,blog

iRule Love - A Valentines Day Webcast With iRules Experts

DevCentral TV — Tue, 14 Feb 2012 21:43:38 GMT

April Spence sits down with F5's Dave Hansen, Colin Walker, and George Watkins to talk a little about iRules history and field some questions from the live audience.

Related Articles on DevCentral

iRules Wiki Home - DevCentral Wiki

DevCentral Groups - iRules

Cloud Chemistry 101

iRules Reference - DevCentral Wiki

v11.1: DNS Blackhole with iRules > DevCentral > Tech Tips on ...

Commands - DevCentral Wiki

iRules 101 - #01 - Introduction to iRules > DevCentral > Tech Tips ...

HTTP Request Cloning via iRules, Part 1 > DevCentral > Tech Tips ...

iRules Concepts: Tcl, The How and Why > DevCentral > Tech Tips ...

iRules 101 - #14 - TCL String Commands Part 2 > DevCentral ...

Technorati Tags: iRules, Dave Hansen, Colin Walker, George Watkins, April Spence

Broken Yo Yo!

Nick Bowman — Tue, 14 Feb 2012 10:17:35 GMT

An emergency. VIPRION blade down. But this wasn’t the worst of it. In Denmark, the F5 expert team at security and networking reseller Snex faced a dire situation.

The F5 Yo Yo had broken.

The Technical Support team at F5 swung into action immediately. First, the secondary, non business-critical stuff. Snex had a new VIPRION blade the following day, and were able to maintain their ability to demonstrate the advantages of the world’s only application delivery controller able to scale on-demand.

And then they turned their attention to the knotty problem of the Yo Yo.

F5 are a billion-dollar organisation that sells to most of the world’s biggest banks and service providers. We have a reputation for quality, an important component of our market share and technology leadership.

And so there were important issues at stake. Should we metaphorically – and literally - sweep the defective Yo Yo under the carpet? Hope that it got forgotten about?

No.

As all business leaders are aware, the cogs of commerce depend on inexpensive promotional items. And so, after great efforts from procurement, a replacement Yo Yo was located, purchased and shipped in second class post to Denmark, only weeks after the breakage and fulfilling the strict terms of F5’s Yo Yo SLA.

Here it is in action.

What Does Mobile Mean, Anyway?

Lori MacVittie — Mon, 13 Feb 2012 15:18:00 GMT

We tend to assume characteristics upon hearing the term #mobile. We probably shouldn’t…

There are – according to about a bazillion studies - 4 billion mobile devices in use around the globe.

It is interesting to note that nearly everyone who notes this statistic and then attempts to break it down into useful data (usually for marketing) that they almost always do so based on OS or device type – but never, ever, ever based on connectivity.

Consider the breakdown offered by W3C for October 2011. Device type is the chosen taxonomy, with operating system being the alternative view. Unfortunately, aside from providing useful trending on device type for application developers and organizations, this data does not provide the full range of information necessary to actually make these devices, well, useful.

Consider that my Blackberry can either connect to the Internet via 3G or WiFi. When using WiFi my user experience is infinitely better than via 3G and, if one believes the hype, will be even better once 4G is fully deployed.

Also not accounted for is the ability to pair my Blackberry Playbook to my Blackberry phone and connect to the Internet via that (admittedly convoluted) chain of connectivity. Bluetooth to 3G or WiFi (which in my house has an additional chain on the LAN and then back out through a fairly unimpressive so-called broadband connection). But I could also be using the Playbook’s built-in WiFi (after trying both this is the preferred method, but in a pinch…)

You also have to wonder how long it will be before “mobile” is the GPS in your car, integrated with services via Google Map or Bing to “find nearby” while you’re driving? Or, for some of us an even better option, find the nearest restroom off this highway because the four-year old has to use it – NOW.

Trying to squash “mobile” into a little box is about as useful as trying to squash “cloud” into a bigger box. It doesn’t work. The variations in actual implementation in communication channels across everything that is “mobile” require different approaches to mitigating operational risk, just as you approach SaaS differently than IaaS differently than PaaS.

Defining “mobile” by its device characteristics is only helpful when you’re designing applications or access management policies. In order to address real user-experience issues you have to know more about the type of connection over which the user is connecting – and more.

CONTEXT is the NEW BLACK in MOBILE

This is not to say that device type is not important. It is, and luckily device type (as well as browser and often operating system), are an integral part of the formula we all “context.”

Context is the combined set of variables that make it possible to interpret any given connection with respect to its unique client, server, network, and application needs.

It’s what allows organizations to localize, to hyperlocalize, and to provide content based on location. It’s what enables the ability to ensure performance whether over 3G, 4G, LAN, or congested WAN connections. It’s the agility to route application requests to the best server-side location based on a combination of client location, connection type, and current capacity across multiple sites – whether cloud, managed hosting, or secondary data centers.

Context is the ‘secret sauce’ to successful application delivery. It’s the ingredient that makes it possible to make the right decisions at the right time based on current conditions that address operational risk – performance, security, and availability. Context is what makes the application delivery tier of the modern data center able to adapt dynamically. It’s the shared data that forms the foundation for the collaboration between application delivery network infrastructure and provisioning systems both local and in the cloud, enabling on-demand scalability and at some point, instant mobility in an inter-cloud architecture.

Context is a key component to an agile data center, because it is only be inspecting all the variables that you can interpret them in a way that leads to optimal decisions with respect to the delivery of an application, which includes choosing the right application instance whether it’s deployed remotely in a cloud computing environment or locally on an old-fashioned piece of hardware. Knowing what device a given request is coming from is not enough, especially when the connection type and conditions cannot be assumed. The same user on the same device may connect via two completely different networking methods within the same day – or even same hour. It is the network connection which becomes a critical decision point around which to apply proper security and performance-related policies, as different networks vary in their conditions.

So while we all like to believe that our love of our chosen mobile platform is vindicated by statistics, we need to dig deeper when we talk about mobile strategies within the walls of IT. The device type is only one small piece of a much larger puzzle called context.

“Mobile” is as much about the means of connectivity as it is the actual physical characteristic of a small untethered device. We need to recognize that, and incorporate it into our mobile delivery strategies sooner rather than later.

[Updated: This post was updated 2/17/2012 - the graphic was updated to reflect the proper source of the statistics, w3schools ]

Connect with Lori: Connect with F5:



Related blogs & articles:

Long-distance live migration moves within reach

HTML5 Web Sockets Changes the Scalability Game

At the Intersection of Cloud and Control…

F5 Friday: The Mobile Road is Uphill. Both Ways

More Users, More Access, More Clients, Less Control

Cloud Needs Context-Aware Provisioning

Call Me Crazy but Application-Awareness Should Be About the Application

The IP Address – Identity Disconnect

The Context-Aware Cloud

Technorati Tags: F5,MacVittie,mobile,context-aware,network,security,performance,availability,quasar,blog

The Lock May be Broken

Or Katz — Mon, 13 Feb 2012 05:47:09 GMT

A couple of weeks ago, a new security advisory was published: CVE-2012-0053 - “Apache HttpOnly Cookie Disclosure”. While the severity of this vulnerability is just “medium”, there are some things that we can learn from it.

As far as I see it, this vulnerability actually uses a more sophisticated approach in order to steal sensitive information. It suggests an exploit proof of concept that combines two attack methods:

1. A well-known application security vulnerability named “Cross-Site Scripting (XSS)”.

2. A newly introduced vulnerability in Apache, where sending a cookie HTTP-Header that is too long, the HttpOnly cookie value, is returned by the web server in a “400 Bad Request” response page.

From the OWASP page on HttpOnly - Mitigating the Most Common XSS attack using HttpOnly

“The majority of XSS attacks target theft of session cookies. A server could help mitigate this issue by setting the HTTPOnly flag on a cookie it creates, indicating the cookie should not be accessible on the client.

If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result. This causes the attack to fail by preventing the malicious (usually XSS) code from sending the data to an attacker's website.”

So the HttpOnly cookie that is not supposed to be accessed by Java-Script on client browser can be accessed when exploiting this vulnerability. In other words, the lock may be broken, and the mechanism that is supposed to prevent an attack, in some circumstances, can be bypassed. This leads me to say that while security countermeasures are becoming more and more sophisticated over the years, security vulnerabilities and their exploits are becoming more and more elusive.

Web Application Firewalls were designed from the beginning to solve such zero-day vulnerabilities presenting multi layered protection for the web application by combining signature based, HTTP protocol constraints and web application behavioral anomalies protection.

From BIG-IP Application Security Manager perspective, this vulnerability can be easily mitigated by performing the following:

i. Using Cross-Site Scripting signatures in order to mitigate Cross-Site Scripting vulnerabilities.

ii. Applying a security policy that limits the header’s length.

iii. Creating a custom error page when this violation occurs.

F5 Friday: What’s Inside an F5?

Lori MacVittie — Fri, 10 Feb 2012 11:45:16 GMT

Is it Linux? Is it third-party? Is it proprietary? Isn’t #vcmp just a #virtualization platform? Just what is inside an F5 BIG-IP that makes it go vroom?

Over the years I’ve seen some pretty wild claims about what, exactly, is “inside” a BIG-IP that makes it go. I’ve read articles that claim it’s Linux, that it’s based on Linux, that it’s voodoo magic. I’ve heard competitors make up information about just about every F5 technology – TMOS, vCMP, iRules – that enables a BIG-IP to do what it does.

There are two sources of the confusion with respect to what’s really inside an F5 BIG-IP. The first stems, I think, from the evolution of the BIG-IP. Once upon a time, BIG-IP was a true appliance – a pure software solution delivered pre-deployed on pretty standard hardware. But it’s been many, many years since that was true, since before v9 was introduced back in 2004. BIG-IP version 9 was the beginning of BIG-IP as not a true appliance, but a purpose-built networking device. Appliances deployed on off the shelf hardware generally leverage existing operating systems to manage operating system and even networking tasks – CPU scheduling, I/O, switching, etc… but BIG-IP does not because with version 9 the internal architecture of BIG-IP was redesigned from the ground up to include a variety of not-so-off-the-shelf components. Switch backplanes aren’t commonly found in your white-box x86 server, after all, and a bladed chassis isn’t something common operating systems handle.

TMOS – the core of the BIG-IP system – is custom built from the ground up. It had to be to support the variety of hardware components included in the system – the FPGAs, the ASICs, the acceleration cards, the switching backplane. It had to be custom built to enable advances in BIG-IP to support the non-disruptive scale of itself when it became available on a chassis-based hardware platform. It had to be custom built so that advances in internal architectures to support virtualization of its compute and network resources, a la vCMP, could come to fruition.

The second source of confusion with respect to the internal architecture of BIG-IP comes from the separation of the operational and traffic management responsibilities. Operational management – administration, configuration, CLI and GUI – resides in its own internal container using off-the-shelf components and software. It’s a box in a box, if you will. It doesn’t make sense for us – or any vendor, really – to recreate the environment necessary to support a web-based GUI or network access (SSH, etc…) for management purposes. That side of BIG-IP starts with a standard Linux core operating system and is tweaked and modified as necessary to support things like TMSH (TMOS Shell).

That’s all it does. Monitoring, management. It generates pretty charts and collects statistics. It’s the interface to the configuration of the BIG-IP. It’s lights out management. This “side” of BIG-IP has nothing to do with the actual flow of traffic through a BIG-IP aside from configuration. At run time, when traffic flows through a BIG-IP, it’s all going through TMOS – through the purpose and very custom built system designed specifically to support application delivery services.

This very purposeful design and development of technology is too often mischaracterized – intentionally or unintentionally – as third-party or just a modified existing kernel/virtualization platform. That’s troubling because it hampers the understanding of just what such technologies do and why they’re so good at doing it.

Take vCMP, which has sometimes been maligned as little more than third-party virtualization. That’s somewhat amusing because vCMP isn’t really virtualization in the sense we think about virtualization today. vCMP is designed to allow the resources for a guest instance to span one or multiple blades. It’s an extension of multi-processing concepts as applied to virtual machines. If we analogized the technology to server virtualization, vCMP would be the ability to assign compute and network resources from server A to a virtual machine running on server B. Cloud computing providers cannot do this (today) and it’s not something that’s associated with today’s cloud computing models; only grid computing comes close, and it still takes a workload-distributed view rather than a resource-distributed view.

vCMP stands for virtual CMP – clustered multi-processing. CMP was the foundational technology introduced in BIG-IP version 9.4 that allowed TMOS to take advantage of multiple multi-core processors by instantiating one TMM (Traffic Management Microkernel) per core, and then aggregating them – regardless of physical location on BIG-IP – to appear as a single pool of resources. This allowed BIG-IP to scale much more effectively. Basically we applied many of the same high-availability and load distribution techniques we use to ensure applications are fast and available to our internal architecture. This allowed us to scale across blades and is the reason adding (or removing) blades in a VIPRION is non-disruptive.

Along comes a demand for multi-tenancy, resulting in virtual CMP. vCMP isn’t the virtual machine, it’s the technology that manages and provisions BIG-IP hardware resources across multiple instances of BIG-IP virtual machines; the vCMP guests, as we generally call them. What we do under the covers is more akin to an application (a vCMP guest) being comprised of multiple virtual machines (cores), with load balancing providing the mechanism by which resources are assigned (vCMP) than it is simple virtualization.

So now you know a lot more about what’s inside a BIG-IP and why we’re able to do things with applications and traffic that no one else in the industry can. Because we aren’t relying on “standard” virtualization or operating systems. We purposefully design and develop the internal technology specifically for the task at hand, with an eye toward how best to provide a platform on which we can continue to develop technologies that are more efficient and adaptable.

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Friday: Sync, Share, and Scale

F5 Monday? The Evolution To IT as a Service Continues … in the Network

F5 Friday: Speeds, Feeds and Boats

If a Network Can’t Go Virtual Then Virtual Must Come to the Network

Architecturally, Is There Such A Thing As Too Scalable?

Sometimes It Is About the Hardware

Medium is the New Large in Enterprise

Technorati Tags: F5,MacVittie,F5 Friday,vCMP,virtualization,BIG-IP,scalability,network,hardware,blog

F5 - iApp for VMware View

F5 Networks News — Thu, 09 Feb 2012 11:44:34 GMT

#VDI Deploying virtual desktops involves many different elements and be complex.

Rolling out your deployment across data centers is time-consuming and prone to human error. F5 iApp technology is a user-customizable framework for deploying application. With iApp for VMware View, you can easily roll out configuration across your F5 devices, to cut deployment time from hours to minutes. F5 can help by making VMware View secure, fast, scalable, and available.

More information about F5's solution for VMware View can be found at http://www.f5.com/view

F5 - iApp for VMware View

Resources:

Overview: F5 for VMware View

F5 - Availability and Scalability for VMware View

F5 - Simplifying Access for VMware View

F5 - Mobile Device Support for VMware View

F5 YouTube Channel

Connect with F5:


Latest F5 Information

F5 News Articles

F5 Press Releases

F5 Events

F5 Web Media

F5 Technology Alliance Partners

F5 YouTube Feed

Technorati Tags: F5,F5 News,VDI,virtualization,VMware,iApp,video,VMware View

Does Social Media Reflect Society?

Pete Silva — Wed, 08 Feb 2012 13:37:21 GMT

A Community within our Society

You are what you eat; You become what you believe; I am not my art. A 2011 study from the University of Texas at Austin's Department of Psychology titled "Manifestations of Personality in Online Social Networks: Self-Reported Facebook-Related Behaviors and Observable Profile Information" found that Facebook users are no different online than they are offline. The study also declared a strong connection between someone’s real personality and their Facebook-related behavior. Social and personality processes, according to the study, accurately mirror non-virtual environments. It was published in the academic journal Cyberpsychology, Behavior, and Social Networking. Professor Samuel D. Gosling and his team looked at the big five personality traits - openness, conscientiousness, extraversion, agreeableness and neuroticism and found that self-reported personality traits are accurately reflected in online social networks such as Facebook. Extroverted users reported the most friends and the highest engagement while conscientious types had the least. Simply, extroverts engaged more than introverts.

Merriam-Webster defines society in part as, companionship or association with one's fellows : a voluntary association of individuals for common ends : an organized group working together or periodically meeting because of common interests, beliefs, or profession : an enduring and cooperating social group whose members have developed organized patterns of relationships through interaction with one another : a community, nation, or broad grouping of people having common traditions, institutions, and collective activities and interests.

Social media has changed society in many ways. We used to just live in a society – our neighborhood, town, city – and (hopefully) looked out for each other, cared for each other and got together for specific causes. This is our community. The human social creature needed human contact/interaction and participated within that society…but the circle was somewhat limited to a geographic region. Granted, some societies are nationwide clubs, groups, memberships or associations that span greater distances – Toastmasters, Kiwanis or college alumni for instance. Now, our circle of friends or association with one’s fellows requires no physical gathering. We live in our physical geographic society but also engage in our cyber communities that span cities, states, countries and with SETI, universes. Years ago I often wondered if the internet would create a society of hermits since no one really needed to go outside and interact with others in the real world. But we are social creatures and our survival requires us to participate in a non-cyber way. Of course there are people that do not want anything to do with society and live in secluded locations to avoid any human interaction. Most of us, however, like it or not, must interact in society on a daily basis.

Often our social cyber-interaction is in response to events in the physical society. We use social media as a way to report, learn and engage with those who are experiencing anything from turmoil to joy in their physical society. World events. Even the Occupiers, who have used social media to great extent, still came together physically – within their geographic circle(s) – to form their mini-societies. In some situations, social media has been the only avenue for ‘breaking’ news getting out to the masses. (Incidentally, it seems like every story on news websites is ‘breaking’ these days – it seems to have lost it’s power)

Breaking Bad, on the other hand, is a darn good show.

In societies we often share – information, goods, ideas, secrets – for the benefit of the society. Many of us have heard the warnings from security experts about keeping passwords a secret. Now, as a form of affection and devotion, teens are sharing their passwords to email, social networks and other accounts. Since it is risky and relationships can quickly sour via social media, they feel that the symbolism is powerful. Apparently, the world’s first divorce by Facebook occurred back in 2009 and more recently Deion Sanders announced his divorce on Facebook this past December. In addition, a survey conducted by UK divorce website www.divorce-online.co.uk in December 2009 found that 20% of behavior petitions contained the word “Facebook.” A follow up survey in December 2011 found that number has greatly increased during 2011 to 33% of behavior allegations in petitions.

Even the crooks are involved. We’ve seen the stories about hijacked accounts, malware distribution and the ever popular, ‘I’m stuck in some foreign country, lost my wallet and need to pay the hotel’ scam. I’m amazed that just a decade ago, security experts warned that you shouldn’t say, ‘We’re not home right now,’ on your answering machine. That tells riff-raff that the property is ripe for the pickings. Yet, just a few years later people are posting that they are over the river and through the woods to grandmother’s house some 300 miles away. Their coordinates are available, their home town and sometimes a picture of the actual empty home are posted on the social network. And then they wonder how they could have been burglarized. It’s has also caught/captured the idiot criminals who feel the need to share their misdeeds. In some cases, we share too much and don’t even realize that we’re diminishing our own privacy. And, of course, there are some who can’t get enough exposure with 24 hour cams following their every move.

Social networks have become one of our society’s primary tools for communication and as a society it is important to communicate effectively. I’ve always felt that the internet, particularly the web, was a reflection of society. It’s chronicled, reflected and magnified our lives along with automatically storing and archiving almost every move we make. People have fallen in love, ordered goods, started movements, spread rumors, gotten arrested/fired/dumped, done banking, filed complaints/kudos, kept in touch, tracked progress, committed crimes, shared ideas and pretty much anything else that didn’t require physical contact. It’s our journal, reminder, mirror, confidant and has certainly wiggled it’s way into and become part of society. A community within our society. But remember, What Happens on the Internet, Stays on the Internet.

ps

Related:

Your Parents on Facebook: To friend or not to friend?

Alarming increase in Facebook related divorces in 2011

Teens, kindness and cruelty on social network sites

Young, in Love and Sharing Everything, Including a Password

Study: Your Facebook Personality Is The Real You

Husband dumps his wife with online message in 'world's first divorce by Facebook'

Employers, workers navigate pitfalls of social media

6 painful social media screwups

The effect of social media on Occupy

Our Digital Life Deciphered

Best Day to Blog Experiment – The Results

How Terms Have Changed over Time

Technorati Tags: blog, social media, comscore, music, statistics, society, web traffic, digital media, mobile device, analytics

Connect with Peter: Connect with F5:



The Potential Ramifications of Platform-Based Vulnerabilities on Cloud Computing

Lori MacVittie — Wed, 08 Feb 2012 13:26:00 GMT

#infosec #adcfw #cloud Alternate title: How to take out an entire PaaS cloud with one vulnerability

Apache Killer.

Post of Doom.

What do these two vulnerabilities have in common? Right, they’re platform-based vulnerabilities. Meaning they are vulnerabilities peculiar to the web or application server platform upon which applications are deployed. Mitigations for such vulnerabilities generally point to changes in configuration of the platform – limit post size, header value sizes, turn off some value in the associated configuration.

But they also have something else in common – risk. And not just risk in general, but risk to cloud providers whose primary value is in offering not just a virtual server but an entire, pre-integrated and pre-configured application deployment stack. Think LAMP, as an example, and providers like Microsoft (Azure) and VMware (CloudFoundry), more commonly adopting the moniker of PaaS. It’s an operational dream to have a virtual server pre-configured and ready to go with the exact application deployment stack needed and offers a great deal of value in terms of efficiency and overall operational investment, but it is – or should be – a security professional’s nightmare. It’s not unlike the recent recall of Chevy Volts – a defect in the platform needs to be mitigated. The only way to do it, for car owners, is to effectively shut down their ability to drive while a patch is applied. It’s disruptive, it’s expensive (you still have to get to work, after all), and it’s frustrating for the consumer. For the provider, it’s bad PR and negatively impacts the brand. Neither of which is appealing.

A vulnerability in the application stack, in the web or application server, can be operationally devastating to the provider – and potentially disruptive to the consumer whether the vulnerability is exploited or not.

STANDARDIZATION is a DOUBLE-EDGED SWORD

Assume a homogeneous cloud environment offering an application stack based on Microsoft ASP. Assume now an exploit, oh say like Post of Doom, is discovered whose primary mitigation lies in modifying the configuration of each and every instance. Virtualization of any kind provides a solution, of course, but introduces the possibility of disruption in the impact to consumer applications from the configuration change. A primary mitigation for the Post of Doom is to limit the size of data in a POST to under 8MB. Depending on the application, this has to potential to “break” application functionality, particularly those for which uploading big data is a focus. Images, video, documents, etc… These all may be impacted negatively, disrupting applications and angering consumers.

Patching, of course, is preferred, as it eliminates the underlying vulnerability without potentially breaking applications. But patching takes time – time to develop, time to test, time to deploy. The actual delivery of such patches in a PaaS environment is a delicate operation. You can’t just shut the whole cloud down and restart it after the patches are applied to the base images, can you? Do you wait, quiesce the vulnerable images and only force the patched ones when new instances are provisioned? A configuration-based mitigation, too, has these same issues. You can’t just shut down the whole cloud, apply the change, and reboot.

It’s a delicate balance of security versus availability that must struck for the provider, and certainly their position in such cases is one not to be envied. Damned if they do, damned if they don’t.

Then there is the risk of exploitation before any mitigation is applied. If I want to wreak havoc on a PaaS, I may be able to accomplish simply by finding one with the appropriate platform vulnerable to a given exploit, and attack. Cycling through applications deployed in that environment (easily identified at the network layer by the IP ranges assigned to the provider) should result in a wealth of chaos being wrought. The right vulnerability could take out a significant enough portion of the environment to garner attention from the outages caused.

Enterprise organizations that think they are immune from such issues should think again, as even a cloud provider is often not as standardized on a single application platform as an enterprise is, and it is that standardization that is at the root of the potential risk from platform-based vulnerabilities. Standardization, commoditization, these are good things in terms of many financial and operational benefits, but they can also cause operational risk to increase.

MITIGATE in the MIDDLE

There is a better solution, a better strategy, a better operational means of mitigating platform-based risks.

This is where the role of a flexible, broad-spectrum layer of security applies. One that enables security professionals to broadly apply security policies to quickly mitigate potentially disastrous vulnerabilities. Without disrupting a single running instance, an organization can deploy a mitigating solution that detects and prevents the effects of such vulnerabilities. Applying security policies that mitigate such vulnerabilities before they reach the platform is critical to preventing a disaster of epic (and newsworthy) proportions.

Whether stop gap or a permanent solution, by leveraging the application delivery tier of any data center – enterprise or cloud provider – such vulnerabilities can be addressed without imposing harsh penalties on applications and application owners, such as requiring complete shutdown and reboots.

Leveraging such a flexible data center tier insulates the platform from exploitation while insulating customers from the disruption required to mitigate immediately on the platform layer, allowing time to redress through patches or, at least, understand the potential implication to the application from the platform configuration changes required to mitigate the vulnerability.

In today’s data center, time is perhaps the biggest benefit afforded to IT by any solution, and yet the one least likely to be provided. A flexible application delivery tier capable of mitigating threats across the network and application stack without disruption is one of the few solutions available that offers the elusive and very valuable benefit of time. Providers and enterprises alike need to consider their current data center architecture and whether it supports the notion of such a dynamic tier. If not, it’s time to re-evaluate and determine whether a strategic change of direction is necessary to ensure the ability of operations and security teams to address operational risk as quickly and efficiently as possible.

Connect with Lori: Connect with F5:



Related blogs & articles:

At the Intersection of Cloud and Control…

The Full-Proxy Data Center Architecture

The Pythagorean Theorem of Operational Risk

The Future of Cloud: Infrastructure as a Platform

Infrastructure Architecture: Whitelisting with JSON and API Keys

If Security in the Cloud Were Handled Like Car Accidents

VU#903934 – Post of Doom

F5 Friday: Zero-Day Apache Exploit? Zero-Problem

Technorati Tags: F5,MacVittie,security,architecture,availability,cloud computing,virtualization,devops,threat mitigation,application delivery,blog

Mobile Device Support for VMware View

Nick Bowman — Tue, 07 Feb 2012 15:57:06 GMT

End user computing means that a wide range of mobile devices from laptops to tablets and from desktops to smartphones are being used. The diversity of these mobile devices and the sheer number of them in the workplace can overwhelm IT and strain your resources. Access and performance are key support concerns. And, since many mobile devices are personal, security is absolutely critical. F5 provides intelligent mobile device support for VMware View. This benefits IT with greater access and compliance control, while at the same time, allowing your employees the freedom to use their mobile device of choice. F5 can help by making VMware View secure, fast, scalable, and available.

More information about F5’s solution for VMware View can be found at http://www.f5.com/view

Making VMware View fast, secure and available

Nick Bowman — Tue, 07 Feb 2012 15:55:05 GMT

VMware View is a leading solution for desktop virtualization offering simplified administration while increasing security and control. When deploying VMware View, there are several issues your business must deal with: from the management of a wide range of devices, to ensuring availability, scalability, and performance. F5 can help by making VMware View secure, fast, scalable, and available.

More information about F5’s solution for VMware View can be found at http://www.f5.com/view

1024 Words: Honey IT Badger Don’t Care

Lori MacVittie — Tue, 07 Feb 2012 18:24:05 GMT

The reaction in IT when there’s something wrong with a core router is to avoid disruption and its associated costs to the business.

The reaction in IT when a user has problems is to embrace disruption and its associated costs to the business.

There’s something wrong with this model.

Thanks, I know VMware tote a 3:1 Desktop/Thin Client ratio in terms of support burden, i.e. one engineer can service 100 fat clients or 300 thin clients (in user terms). Would you say that this is realistic?

I have a school district with 3 tech's who support 5k devices. Its powerful. 90% of problems can be finished with "log out, login get a new desktop".

-- SpiceWorks, Virtualization Adoption Thread

Connect with Lori: Connect with F5:



Technorati Tags: 1024 Words,MacVittie,honey badger,IT,VDI,reboot,productivity,blog

Technische und organisatorische Rahmenbedingungen moderner Cloud-Dienste

Ralf Sydekum — Mon, 06 Feb 2012 10:37:53 GMT

Moderne Unternehmen befinden sich zunehmend im verschärften Wettbewerb zur Konkurrenz und nur diejenigen, die bei stetigen Kostensenkungen dennoch den Profit steigern können, werden sich langfristig am Markt behaupten können. Diesen Kostendruck spürt natürlich auch die interne IT und auf der Suche nach flexiblen und gleichzeitig günstiger werdenden IT-Services wird man zwangsläufig auf Cloud-Dienste stoßen. Entscheidet man sich die Cloud-Services bei einem Dienstleister zu beauftragen, so ergeben sich eine Vielzahl von Fragen, die einerseits eine technische Realisierung beinhalten, andererseits aber auch eine organisatorische, sowie eine sicherheits- und regulatorische Dimension haben.

Hier nun ein paar Beispiele, die ein Projektleiter „Cloud-Services“ unter Berücksichtigung von Sicherheitsaspekten beachten sollte:

- Wie steht es um den Datenschutz (Vertraulichkeit, Integrität)?

- Welche regulatorische Anforderungen bestehen an das Löschen von Daten?

- Ist Mandantentrennung gewährleistet?

- Beachtung von Complianceanforderungen in verschiedenen Ländern

- Besteht mittel-/langfristig eine Insolvenzgefahr des Cloud Providers?

- Arbeitet der Cloud Provider mit Subunternehmern?

- Wie hoch ist das Risiko der Erpressbarkeit?

Damit Cloud Provider ihrerseits hocheffizient und kostengünstig ihre Dienste anbieten können, sind diverse Grundtechniken eine zwingende Voraussetzung. Die Virtualisierung spielt hierbei eine ganz entscheidende Rolle, aber auch hier müssen potentielle Kunden ein Verständnis für Vertraulichkeit, Integrität, Verfügbarkeit, Kontrolle und Zuverlässigkeit entwickeln und dies weitestgehend in SLAs umsetzen lassen. Im Folgenden sei hier eine kleine Stichwortliste gegeben, die bei der Ausarbeitung von Serviceverträgen berücksichtigt werden sollten:

- Architectural Framework

- Governance, Enterprise Risk Management

- Legal, e-Discovery

- Compliance & Audit

- Information Lifecycle Management

- Portability & Interoperability

- Security, Business Continuity, Disaster Recovery

- Data Center Operations

- Incident Response Issues

- Application Security

- Encryption & Key Management

- Identity & Access Management

- Virtualization

F5 unterstützt mit einer Vielzahl unterschiedlichster Technologien wesentliche Ziele der Verfügbarkeit, Sicherheit und auch schnellstmöglichen Zugang zu Anwendungen. Als einige Beispiele seien schlagwortartig der Schutz vor DDoS- (netz- und anwendungsseitig) und Web-Attacken, Authentifizierung und Autorisierung der Anwender, Schutz der DNS-Infrastruktur, High-Speed-Logging, flexibles Deployment durch Virtual Editions (VE) und viele weitere Funktionalitäten der BIG-IP erwähnt.

Desktop VDI May Be Ready for Prime Time but Is the Network?

Lori MacVittie — Mon, 06 Feb 2012 12:20:00 GMT

#VDI #quasar #mobile The proliferation of mobile devices is pushing VDI closer to being “the solution” of the year to resolve the increasing complexity – and costs – associated with consumerization.

Considering the innate differences between just the two most popular mobile operating systems – Android and iOS – gives rise to understanding how costly and complex an infrastructure might need to be to support both. It’s not at all unlike the issues with server virtualization. Management and delivery architectures require different solutions depending on the platform, so despite potentially costly investments to scale, organizations are often staying single-vendor with respect to its virtualization platform strategy.

Organizations had taken that approach – standardized on a single mobile platform – only to discover that employees blatantly ignored such mandates and began using whatever they brought from home. Worse, they expected support when applications didn’t work quite right.

Thus IT is stuck trying to figure out how to efficiently deliver, secure, and manage applications to multiple operating systems right now. Not tomorrow, not next week. Today.

VDI is thus rearing its head as a viable solution; one that promises consistency regardless of platform, without worry about Bob wanting to access corporate resources via his Internet-enabled HDTV. For the most part, experts and implementers deem VDI ready to meet the challenge. But what they haven’t asked, nor considered, is whether the network is ready for VDI.

Desktop Virtualization Ready for Prime Time

The appeal of VDI remains the same: it improves flexibility, simplifies administration and boosts security. What has changed are ongoing price drops and a growing need to seamlessly manage an IT infrastructure that includes desktops running Windows, Mac laptops using Apple OS X and mobiles devices using iOS and Android. In many cases, VDI streamlines data exchange and accessibility in an increasingly bring-your-own device (BYOD) IT world.

VDI OFFLOADS the PROBLEMS to the INFRASTRUCTURE

Interestingly enough, the problems with delivering applications to multi-endpoint environments do not actually disappear with the introduction of VDI. Oh, the problem of supporting every device under the sun is neatly resolved, but other problems quickly arise, and these are not necessarily easy problems to solve.

Roaming

The issue with roaming isn’t just that of a device roaming across service boundaries or WiFi networks, it’s roaming geographically. VDI deployments carry with them some strict and often constraining infrastructure requirements that are not easily overcome without the assistance of infrastructure. Typical network environments are ill-prepared to deal with not just the basic constraints but the resolution to those constraints. They lack the flexibility of an application delivery tier to mediate between roaming users and virtual desktop infrastructure.

A user that roams between two completely different network types may in fact appear to be two different network users from an IP perspective. While we know we must one day eliminate our dependency on IP addressees, today it remains a factor that must be addressed. Users who suddenly move from one network to another may cause undue stress along the entire infrastructure – but especially on VDI servers that maintain their understanding of users based on connections, which base their identification on IP addresses. A mediating connectivity layer such as an application delivery tier eliminates not the dependency, but the impact on the actual VDI servers and applications by becoming the endpoint and handling the possible volatility in device identification on behalf of the services, mitigating the impact by absorbing and managing it itself.

Network Impact on Performance

What, exactly, is the network over which the mobile device is connecting? Is it WiFi? Is it the mobile network? The network over which a device is connecting has a significant impact on performance, particularly from the perspective of the end-user. It isn’t so much a question of whether or not the network is fat enough, it’s whether or not the external (read: out of IT control) network is fat enough, or fast enough.

Latency is the biggest concern among networking pros considering a VDI deployment, according to an informal survey of 1,197 VMworld 2010 attendees conducted by storage vendor Xiotech and WAN optimization vendor Silver Peak. The vendors say 62% of respondents named latency as their top VDI network consideration.
A minority named other WAN-related issues as concerns, such as the ability to shape or prioritize traffic (7%) and bandwidth (6%).

-- VDI over the WAN: How latency affects virtual desktop performance

While WAN Optimization and similar technologies can certainly address issues when a WAN is involved, it won’t necessarily be of assistance when mobile devices experience issues over WiFi or mobile networks or any configuration in which there is no control over both endpoints. Yet the same network problems will plague these devices, and likely with more frequency than remote desktops over IT controlled WAN channels.

Scale of Dependent and Primary Services

Likely the most overlooked of all is the scalability of dependent network services. Simple things like NAT, like application access control, like network security infrastructure that must deal with the possibility that users will be logged in from several places at the same time, trying to access different resources. It’s the scalability of network security devices that suddenly must contend with connections coming from a wide variety of networks and locations, and must decide – quickly – which of those connections will be allowed, and which should – and must – be denied.

It’s also about the ability of applications themselves to scale when faced with suddenly very different network profiles that significantly impact the capacity and load on existing services. Applications that have performed well with capacity X suddenly perform poorly even though concurrent user counts have not changed. This is because the network characteristics may have changed in such a way as to change the way in which the applications are served. Users connecting over the LAN are able to receive content quickly and thus reduce the overall burden on server infrastructure by clearing queues and releasing connections that can be used by other users. Users connecting over mobile networks are not able to receive content as quickly and thus increase the burden on server infrastructure by receiving content more slowing and taking more time to complete a session. This reduces the capacity of server infrastructure and may require additional scaling to ensure consistent, acceptable performance levels across all device types and users.

Thus, while VDI may be ready for prime-time, and is certainly a valid solution to the problem of consumerization with respect to mobile device proliferation in the enterprise, the network may not be ready for VDI – regardless of endpoint form factor.

VDI, like server virtualization and cloud computing , will necessarily change the way in which we architect and ultimately view the network because of the very characteristics that make these technologies appealing – abstraction, elasticity, dynamism. These characteristics make it more difficult to deliver applications and services like VDI because of the volatility and diversity they introduce into the data center and impose on the network.

New architectural and technological solutions will be required in the network to manage such issues as they arise.

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Friday: A Single Namespace to Rule Them All

WILS: The Importance of DTLS to Successful VDI

F5 Friday: The Dynamic VDI Security Game

Mobile versus Mobile: An Identity Crisis

WILS: WPO versus FEO

The Magic of Mobile Cloud

Fire and Ice, Silk and Chrome, SPDY and HTTP

The Mobile Chimera

Technorati Tags: F5,MacVittie,mobile,VDI,virtualization,scalability,performance,network,optimization,blog

DevCentral Top5 02/03/2012

Colin Walker — Sat, 04 Feb 2012 00:16:58 GMT

We're putting the band back together. And by band, I mean team. And by "putting back together" I mean we're all going to be in the same place, physically. This is a rarity for our remotely distributed team, but next week it is happening, and that is a great thing. It means planning, policies, preparation, prognostication and many other things that don't begin with the same letter. It also means that there will be some new, cool things to look forward to in what will likely be the near future, from a DevCentral perspective. Rarely do we get the whole team together to brainstorm and plan without something hawesome coming out of it. For that, I recommend you keep your eyes peeled the next few weeks. In the meantime, however, there is nowhere near a shortage of killer content on DevCentral just waiting for your perusal. So much so, in fact, I find myself again compelled to pick a few of my favorites and disseminate them to you in a format that takes the guess work out for those of you not neck deep in DC goodness, as I am. For the fun of it I'll pick only 5 topics this week, and here they are. Oh, and there might be some iRules involved. A lot of iRules. All over the place. Once you recover from your shocked state, given my lack of a propensity for sharing iRules topics, read on:

Transparent Web Bot Application Protection

http://bit.ly/zRt5TF

Joe takes us out of the gates this week with an awesome new take on an old problem. Forms being abused by web bots is a story as old as ... well ... forms and web bots. It has been "solved" or worked around or just plain dealt with through gritted teeth for years. One of the most common, reliable ways of stopping bots from abusing the forms on your site is to implement captchas. Captchas, in case you haven't been on the web since 14.4 was blistering, have gotten pretty advanced these days, asking you to input multiple phrases, playing back audio to help you decipher them, etc. There are even some iRules on DevCentral to help you implement them seamlessly. Also? I hate them. I am not a captcha fan. They are annoying, time consuming, and just plain not fun. Necessary bits of not fun that I tolerate, certainly, but I, much like Joe it would seem, am not a fan. So, when Joe presents a solution to provide what is effectively a transparent captcha, meaning the user has no interaction but the functionality is very much similar to a traditional captcha, I sat up and took notice. I suggest you do the same, it's worth the read.

Introduction to iStats Part1: Overview

http://bit.ly/AAmDhv

I'm kind of in the business of documenting iRules. Along with talking about them to anyone that will listen, or is in earshot, or is passing by, or sits next to me on the plane or ... well you get the idea. In addition to talking about them and writing them and working with the wicked smart folks in the depths of F5 to better them for future generations of iRulers, I document them a fair amount, as do my DC compatriots. That process is great and all, but every so often one of the software engineers will produce a chunk of documentation that allows an article to all but write itself. That is what happened here. One of our iRules engineers put together a simply outstanding document detailing what iStats are, how they work, how to use them, etc. and sent it off to the iRules experts. I couldn't help myself, so I wrote it up in more detail, with some more background, etc. and put it out on DevCentral for the masses to consume. iStats will change the way many people are using iRules. They will allow things that were previously impossible. iStats are cool, but you'll have to read the document to find out just how cool and why.

Populating Tables With CSV Data Via Sideband Connections

http://bit.ly/wqtg8f

George is off in his own world these days. It's a world wherein awesome iRule ideas leap from the walls, complex code lays itself out at his feet, and outstanding Tech Tips come flowing out as the result. If you find where that place is, send me directions, would you? I have serious article envy. George continues making it absolutely rain wicked solutions with his newest installment of applications hawesomeness by way of the new super powers garnered to iRules in v11, namely Sideband Connections. In this example George shows off an iRule that will connect to an out of band server to look up CSV data pertinent to the connection before processing the client request, then cache that data as necessary within the BIG-IP. Yeah, if you're not impressed and thinking that's pretty darn cool, you're doing it wrong. That or I'm just bonkers for this stuff. Perhaps both. Seriously folks, go read this article right now. It's worth it. I'll be over re-mapping the keys on George's keyboard to slow him down a bit so he stops making me look bad.

Advanced Load Balancing for Developers. The Network Dev Tool.

http://bit.ly/zfWnuM

Hitting near and dear to my heart, Don dusts off his Load Balancing for Developers series and dives straight into one of my favored topics: Business logic offloading to the network. He draws you the picture, first, of ZapnGo (a make believe company) and their growth, the struggles brought with it, and how they're working to address them. This is something that is very real to many businesses in a similar place as ZapnGo. Growth is fantastic but it brings along very real issues that need addressing, and doesn't always provide the extra cycles to deal with them. Offloading some of the functionality that might traditionally go into the back-end to the network layer can be an extremely effective way of saving cycles, both in man-hours and processing time. This is something that I've spoken with droves of people about over the years, and I love seeing it brought up in another light and hearing someone else's take on it. This is a good read and very well may give you some insight into how to solve some issues you're having, if you're in a similar place as ZapnGo.

Enterprise Apps are Not Written for Speed

http://bit.ly/wK84ib

Another topic that will often times quickly lead to a soap-box being produced out of thin air and those perhaps unfortunate people near enough to be caught in the path of the diatribe that follows is performance vs. maintainability. Lori hits the nail on the head with her topic, and the ensuing discussion she presents in this blog post. The reality is, most developers building enterprise level applications are focused on reliability, maintainability, and functionality. Performance is a nice to have in a world of strict requirements. That's not even taking into account the real time killer - security. Back in the day when I was writing such apps and automation tools in an enterprise environment the concept of "performance" was relegated to "Does it work? Does it work twice? Awesome..." and that was about it. In a world of more and more web accessible or hosted apps, increasing numbers of mobile users, larger object counts and sizes, and a host of other performance degrading factors, now more than ever the ability to up the performance outside of the application is a valuable one. The network layer can help with that, if you let it, and Lori talks about how in this post.

There are five more picks from the past couple weeks of content surging through DevCentral. It shows no signs of stopping, so I guess I'll have to come back in a week or so to give you some more hints on where to look for the pieces that were my favorite. Until then, happy coding, configuring, networking or whatever else it is that you do when not cruising DevCentral.

#Colin

Technorati Tags: DevCentral,Top5,iRules,Performance,Security,Networking,Sideband Connections,iStats,Colin Walker

Advanced Load Balancing For Developers. The Network Dev Tool

Don MacVittie — Fri, 03 Feb 2012 18:54:59 GMT

It has been a while since I wrote an installment of Load Balancing for Developers, and now I think it has been too long, but never fear, this is the grad-daddy of Load Balancing for Developers blogs, covering a useful bit of information about Application Delivery Controllers that you might want to take advantage of. For those who have joined us since my last installment, feel free to check out the entire list of blog entries (along with related blog entries) here, though I assure you that this installment, like most of the others, does not require you to have read those that went before.

ZapNGo! Is still a growing enterprise, now with several dozen complex applications and a high availability architecture that spans datacenters and the cloud. While the organization relies upon its web properties to generate revenue, those properties have been going along fine with your Application Delivery Controller (ADC) architecture.

Now though, you’re seeing a need to centralize administration of a whole lot of functions. What worked fine separately for one or two applications is no longer working so well now that you have several development teams and several dozen applications, and you need to find a way to bring the growing inter-relationships under control before maintenance and hidden dependencies swamp you in a cascading mess of disruption.

With maintenance taking a growing portion of your application development manhours, and a reasonably well positioned test environment configured with a virtual ADC to mimic your production environment, all you need now is a way to cut those maintenance manhours and reduce the amount of repetitive work required to create or update an application. Particularly update an application, because that is a constant problem, where creating is less frequent.

With many of the threats that your ZapNGo application will be known as ZapNGone eliminated, now it is efficiencies you are after. And believe it or not, these too are available in an ADC. Not all ADC’s are created equal, but this discussion will stay on topics that most ADCs can handle, and I’ll mention it when I stray from generic into specific – which I will do in one case because only one vendor supports one of the tools you can use, but all of the others should be supported by whatever ADC vendor you have, though as always, check with your vendor directly first, since I’m not an expert in the inner workings of every one.

There is a lot that many organizations do for themselves, and the array of possibilities is long – from implementing load balancing in source code to security checks in the application, the boundaries of what is expected of developers are shaped by an organization, its history, and its chosen future direction. At ZapNGo, the team has implemented a virtual test environment that as close as possible mirrors production, so that code can be implemented and tested in the way it will be used. They use an ADC for load balancing, so that they don’t have to rewrite the same code over and over, and they have a policy of utilizing a familiar subset of ADC functionality on all applications that face the public.

The company is successful and growing, but as always happens in companies in that situation, the pressures upon them are changing just by virtue of their growth. There are more new people who don’t yet have intimate knowledge of the code base, network topology, security policies, whatever their area of expertise is. There are more lines of code to maintain, while new projects are being brought up at a more rapid pace and with higher priorities (I’ve twice lived through the “Everything is high priority? Well this is highest priority!” syndrome while working in IT. Thankfully, most companies grow out of that fast when it’s pointed out that if everything is priority #1, nothing is). Timelines to complete projects – be they new development, bug fixes, or enhancements are stretching longer and longer as the percentage of gurus in the company is down and the complexity of the code and the architecture it runs on is up.

So what is a development manager to do to increase productivity? Teaming newer developers with people who’ve been around since the beginning is helping, but those seasoned developers are a smaller and smaller percentage of the workforce, while the volume of work has slowly removed them from some of the many products now under management. Adopting coding standards and standardized libraries helps increase experience portability between projects, but doesn’t do enough.

Enter offloading to the ADC. Some things just don’t have to be done in code, and if they don’t have to be, at this stage in the company’s growth, IT management at ZapNGo (that’s you!) decides they won’t be. There just isn’t time for non-essential development anymore.

Utilizing a policy management tool and/or an Application Firewall on the ADC can improve security without increasing the code base, for example. And that shaves hours off of maintenance projects, while standardizing on one or a few implementations that are simply selected on the ADC. Implementing Web Application Acceleration protocols on the ADC means that less in-code optimization has to occur. Performance is no longer purely the role of developers (but of course it is still a concern. No Web Application Acceleration tool can make a loop that runs for five minutes run faster), they can allow the Web Application Acceleration tool to shrink the amount of data being sent to the users’ browser for you. Utilizing a WAN Optimization ADC tool to improve the performance of bulk copies or backups to a remote datacenter or cloud storage… The list goes on and on.

The key is that the ADC enables a lot of opportunities for App Dev to be more responsive to the needs of the organization by moving repetitive tasks to the ADC and standardizing them. And a heaping bonus is that it also does that for operations with a different subset of functionality, meaning one toolset gives both App Dev and Operations a bit more time out of their day for servicing important organizational needs. Some would say this is all part of DevOps, some would say it is not. I leave those discussions to others, all I care is that it can make your apps more secure, fast, and available, while cutting down on workload.

And if your ADC supports an SSL VPN, your developers can work from home when necessary. Or more likely, if your code is your IP, a subset of your developers can. Making ZapNGo more responsive, easier to maintain, and more adaptable to the changes coming next week/month/year. That’s what ADCs do. And they’re pretty darned good at it.

That brings us to the one bit that I have to caveat with F5 only, and that is iApps. An iApp is a constructed configuration tool that asks a few questions and then deploys all the bits necessary to set up an ADC for a particular application. Why do I mention it here? Well if you have dozens of applications with similar characteristics, you can create an iApp Template and use it to rapidly bring new applications or new instances of applications online. And since it is abstracted, these iApp templates can be designed such that AppDev, or even the business owner, is able to operate them Meaning less time worrying about what network resources will be available, how they’re configured, and waiting for operations to have time to implement them (in an advanced ADC that is being utilized to its maximum in a complex application environment, this can be hundreds of networking objects to configure – all encapsulated into a form). Less time on the project timeline, more time for the next project. Or for the post deployment party. One of the two. That’s it for the F5 only bit.

And knowing that all of these items are standardized means less things to get mis-configured, more surety that it will all work right the first time. As with all of these articles, that offers you the most important benefit… A good night’s sleep.

Technorati Tags: Application Delivery Controllers,VPN,Security,Applicaiton Development,Acceleration,WAN Optimization,Encryption,F5 Networks,Load Balancing For Developers,Don MacVittie,blog

Connect with Don: Connect with F5:



Related Articles and Blogs

Intro to Load Balancing for Developers – How they work

Load Balancing For Developers: Improving Application Performance ...

Load Balancing For Developers: Security and TCP Optimizations

Intro to Load Balancing for Developers – The Algorithms

Advanced Load Balancing For Developers: Virtual Benefits

Advanced Load Balancing for Developers – ADCs, What's the ...

Load Balancers for Developers – ADCs Wan Optimization ...

Intro to Load Balancing for Developers – The Gotchas

Cloud Load Balancing Fu for Developers Helps Avoid Scaling Gotchas

F5 Friday: New Services from F5 Ease Migration and Upgrades

Lori MacVittie — Fri, 03 Feb 2012 13:14:00 GMT

I get by with a little help from my friends…

While cloud and virtualization primarily focus on improving the provisioning process, there is a lot more to managing a data center and its critical components than just deployment. There’s upgrades – both software and hardware – and migration to new solutions as well as tweaking knobs and buttons to optimize and troubleshoot issues. While public cloud computing may alleviate much of the pain associated with forward movement, private and hybrid environments as well as traditional data center models must face the reality of dealing with these admittedly often tedious tasks.

It’s a foregone conclusion that new technology and devices like mobile, tablets, unified application delivery and cloud computing as well as an evolving threat spectrum put pressure on IT to maintain a healthy and modern set of services to ensure availability, performance, and security. As pressures increase on infrastructure services, vendors respond with new and or updated solutions to help IT combat the growing complexity of data center architectures.

But sometimes, IT needs a little help from its friends to get there, and that’s where professional service organizations enter into the picture.

One of F5’s top priorities is a world-class service organization. From implementation and ongoing support to migration and upgrades, our professional services organization continues to evaluate the technology landscape and address the most pressing issues facing IT through new offerings designed to ease those pain points introduced by a need to upgrade or migrate to new platforms.

New Services Offerings from F5

F5 is introducing three new services offerings that address many of these issues. Each assessment covers four phases: planning, analysis, a detailed report, and review with recommendations.

BIG-IP Local Traffic Manager (LTM) Upgrade Assessment

Understand Your Infrastructure’s Readiness for Change

The flexible infrastructures made possible by BIG-IP LTM can drive efficiencies, support business growth, and optimize new capabilities that become available as the infrastructure devices evolve. Nonetheless, version upgrades require planning and analytical validation that new functionality will align with the organization’s infrastructure vision.

The BIG-IP LTM configuration is assessed in four broad categories:

Platform, including current TMOS release level, device health, network configuration, and system monitoring and management

Availability, including HA configuration, active/standby preferences, network redundancy, connection mirroring, and persistence settings

Performance, including optimized service profiles, CPU throughput, simple F5 iRules scripting, virtual server types, and health monitors

Security, including secure socket layer (SSL) cipher strengths, port lockdown settings, and administrative access configurations

Firepass to BIG-IP Access Policy Manager (APM) Migration Assessment

Migrate to BIG-IP APM for Faster, Flexible Access

The rapid proliferation of mobile devices, an increasingly dispersed workforce, and the need to secure and optimize content delivery combine to make high-performance, high-concurrency remote access solutions crucial to organizations. Migrating now from a FirePass device to BIG-IP APM ensures your applications remain fast, secure, and available. BIG-IP APM provides a flexible, high-performance access and security solution within an agile infrastructure that will position your organization to effectively support today’s mobile workforce.

The F5 Professional Services consultant reviews your current FirePass configuration and conducts a high-level design discussion to understand the target architecture requirements for meeting your organization’s remote access needs. The configuration review includes analysis of web services, landing URIs, authentication method, certificates, master and resource groups, and network, portal, and application access.

Proactive Assessment

Assess Your F5 Infrastructure Agility

An F5 Proactive Assessment Service audits your F5® BIG-IP® products to ensure optimal configuration. Specifically, the Proactive Assessment Service reviews your current environment to uncover potential issues or areas for improvement and makes recommendations that help optimize F5 technologies. The result is an action plan designed to boost your BIG-IP platform performance, strengthen security, and increase availability.

Network configuration is assessed with a comprehensive review of infrastructure characteristics in five categories:

Operating system, including hotfix level and consistency within products and across BIG-IP device high-availability (HA) pairs

Architecture, including virtual servers, pools, network address translation, and address resolution protocol (ARP) settings

Security, including password policy, authentication methods, and network forwarding

Availability, including fail-over, mirroring, HA configuration, health monitors, and backup policies

Performance, including CPU performance graphs, memory consumption, and throughput

Another great self-service resource can be found in iHealth, which enables you to verify the proper operation of your BIG-IP system and ensure your hardware and software function at peak efficiency. New to iHealth is a comparison feature that can assist with assessments as well as troubleshooting. iHealth requires registration, but is a free service from F5 designed to ease the support process as well as providing organizations with the means to self-support when desired.

Additional Resources:

F5 Professional Services

F5 Professional Services Data Sheet

iHealth Overview

BIG-IP iHealth Data Sheet

F5 Security Vignette: iHealth

Connect with Lori: Connect with F5:



Related blogs & articles:

F5 Security Vignette: iHealth

And Now, A Word About iHealth

Need a Little Help Deploying IPv6? We’ve Got Your Back

F5 Friday: Goodbye Defense in Depth. Hello Defense in Breadth.

F5 Friday: Platform versus Product

F5 Friday: Engineering, Experience, and Bacon?

Technorati Tags: F5,F5 Friday,MacVittie,professional Services,BIG-IP,LTM,APM,iRules,iHealth,blog

F5 - Mobile Device Support for VMware View

F5 Networks News — Fri, 03 Feb 2012 13:07:00 GMT

#mobile #vdi #virtualization

End user computing means that a wide range of mobile devices from laptops to tablets and from desktops to smartphones are being used. The diversity of these mobile devices and the sheer number of them in the workplace can overwhelm IT and strain your resources. Access and performance are key support concerns. And, since many mobile devices are personal, security is absolutely critical.

F5 provides intelligent mobile device support for VMware View. This benefits IT with greater access and compliance control, while at the same time, allowing your employees the freedom to use their mobile device of choice. F5 can help by making VMware View secure, fast, scalable, and available.

More information about F5's solution for VMware View can be found at http://www.f5.com/view

F5 - Mobile Device Support for VMware View

Resources:

Overview: F5 for VMware View

F5 - Availability and Scalability for VMware View

F5 - Simplifying Access for VMware View

F5 YouTube Channel

Connect with F5:


Latest F5 Information

F5 News Articles

F5 Press Releases

F5 Events

F5 Web Media

F5 Technology Alliance Partners

F5 YouTube Feed

Technorati Tags: F5,F5 News,VMware,VMWare view,virtualization,vdi,mobile,video

5 Stages of a Data Breach

Pete Silva — Fri, 03 Feb 2012 00:53:19 GMT

One thing I’ve noticed over the last couple years is that there are 5 Stages of a Data Breach:

Denial: We do not believe these attacks breached our critical servers.

Anger: We want to make it clear that we take security seriously!

Bargaining: We’d like to offer our affected customers a credit monitoring service.

Depression: We wish we could have done things differently.

Acceptance: Well, it just shows that no one is safe from hackers.

ps

Technorati Tags: F5, cyber-crime, trojan, Pete Silva, security, business, education, 5 stages, cyber war, hackers, breach, verisign, internet, security, privacy,

Connect with Peter: Connect with F5:



Come Join DevCentral for the Seattle DotNetNuke User Group Meeting

Jason Rahm — Thu, 02 Feb 2012 16:07:20 GMT

If you didn’t know, the DevCentral platform runs on DotNetNuke, the leading open source ASP.Net CMS. It’s a great development platform for turning out rich sites, and we’re excited to be hosting the next Seattle DNN User Group meeting next Wednesday, February 8th, beginning at 6pm at 401 Elliot Ave West, Seattle, WA.

Agenda

6:00 - Arrive Sign in

6:10 - Tour F5 facilities

6:30 – Presentation Begins

Steven – Introductions and DC/DNN Overview

April – Managing a Community

Jason – Overview of the infrastructure we run

7:20 – Q & A

7:30 – Social Hour – Buckley’s

We’re super excited to be involved in this next DNN user group, hope to see you there!

Technorati Tags: F5 DevCentral,DotNetNuke,DNN,Seattle DNN User Group,Buckley's

The reaction in IT when there’s something wrong with a core router is to avoid disruption and its associated costs to the business.	The reaction in IT when a user has problems is to embrace disruption and its associated costs to the business.