Q/A with itacs GmbH's Kai Wilke - DevCentral's Featured Member for February

Kai Wilke is a Principal Consultant for IT Security at itacs GmbH – a German consulting company located in Berlin City specializing in Microsoft security solutions, SharePoint deployments, and customizations as well as classical IT Consulting. He is also a 2017 DevCentral MVP and DevCentral’s Featured Member for February!

For almost 20 years in IT, he’s constantly explored the evens and odds of various technologies, including different operating systems, SSO and authentication services, RBAC models, PKI and cryptography components, HTTP-based services, proxy servers, firewalls, and core networking components. His focus in these areas has always been security related and included the design, implementation and review of secure and high availability/high performance datacenters.

DevCentral got a chance to talk with Kai about his work, life and mastery of iRules.

DevCentral: You’ve been a very active contributor to the DevCentral community and wondered what keeps you involved?

Kai: Working with online communities has always been an important thing for me and it began long time ago within the good old Usenet and the predecessor of the Darknet. Before joining the F5 community, I was also once an honored member of the Microsoft Online Community and was five times awarded as a Microsoft MVP for Enterprise Security and Microsoft-related firewall/proxy server technologies. 

My opinion is that if you want to become an expert for a certain technology or product, you should not just learn THE-ONE straight-forward method fetched from manuals, guides or even exams. Instead, you have to dive deeply into all of those edge scenarios and learn all the uncountable ways to mess the things up. And dealing with questions and problems of other peers is probably the best catalyst to gain that kind of experience. 

Besides of that, the quality of the DevCentral content and the knowledge of other community members are absolutely astonishing. It makes simply a lot of fun for me to work within the DevCentral community and to learn every day a little bit more…

DC: Tell us a little about the areas of BIG-IP expertise you have.

KW: Over the years, I successfully implemented BIG-IP LTM, APM, ASM, and DNS Service deployments for our customers. Technologically, I internalized TMOS and its architecture very well and I pretty much learned how to write simple but also somewhat complex iRules to control the delivery of arbitrary data on their way from A to B in any possible fashion.

DC: You are a Principal Consultant for IT Security at itacs GmbH - a German consulting company. Can you describe your typical workday?

KW: Because of my history with Microsoft related infrastructures, my current workload is pretty versatile.

Many of my current projects are still settled in the Microsoft / Windows system environment and are covering the design and review of security related areas. Right now, I’m working with several DAX companies and also LaaS, PaaS and SaaS service providers to analyze their Active Directory and System Management infrastructures and to design and implement a very unique, fundamental and comprehensive security concept to counter those dreaded PtH (Pass-the-Hash) and APT (Advance Persistent Threat) attacks we are facing these days. 

Over the last years, my F5 customer base has periodically grown so I would say my work is a 50:50 mix right now. I do F5 workshops, designs, implementations, second and third level support as well as configuration reviews and optimization of existing environments. I work with some big web 2.0 customers that have the demand to pretty much exhaust all the capabilities of an F5. This challenges me as a network architect and as an ADC developer. 

I realize every day that working with F5 products makes so much more fun than any Microsoft product I have ever dealt with. So in the future, I will even more put my focus on F5!

DC: Describe one of your biggest BIG-IP challenges and how DevCentral helped in that situation.

KW: In my opinion, the F5 products themselves are not that challenging – but sometimes the underlying technologies and the detailed project requirements are. But as long as those requirements can be drawn and explained on a sheet of paper, I am somewhat confident that the BIG-IP platform is able to support the requirements – thanks to the F5 developers who have created a platform which is not purely scenario driven but rather supports a comprehensive list of RFC standards which can be combined as needed. 

For an example, one of my largest customers operates an affiliate resource tracking system with three billion web requests per day with a pretty much aggressive session setup rate during peak hours. I have designed and implemented their BIG-IP LTM platform to offload SSL-encryption and the TCP-connection handling to various backend systems using well selected and performance optimized settings. 

Other scenarios require slightly more complex content switching, the selective use of pre-authentication and/or combination with IDS/IPS systems. To support those requirements, I developed a very granular and scalable iRule administration framework which is able to simplify the configuration by using rather easy-to-use iRule configuration files (operated by non TCL developers) which will then trigger the much more complex iRule code (written and tested by TCL developers) as needed. The latest version of my iRule administration framework (which is currently under testing/development) will be able to support a couple thousand websites on a single Virtual Server, where each websites can trigger handcrafted TCL code blocks as needed, but without adding linear or even exponential overhead to the system as the regular iRule approaches would do. The core and the configuration files of the latest version are heavily based on TCL procedures to create a very flexible code base and also conditional control structures, but completely without calling any TCL procedures during runtime to boost the performance dramatically. Sounds interesting? Then stay tuned, I am sure I will publish this framework to the CodeShare once it’s stable enough… ;-)

DC: Lastly, if you weren’t an IT admin – what would be your dream job? Or better, when you were a kid – what did you want to be when you grew up?

KW: I was typing my first assembler code out of a C64 magazine at the age of 10, so I really wanted to be a developer and/or IT admin since then. But besides of my current job, I can also imagine being a racecar driver. I really have petrol in my blood and pretty much enjoy driving on the German Autobahn. As an alternative, I could also imagine being a cook. I really love cooking and enjoy awesome food!

DC: Thanks Kai! Just don't fire up that sterno while shifting gears!! Check out all of Kai’s DevCentral contributions and check out their blog websites: ops365.de, flow365.de and brandmysharepoint.de.

What is an Application Delivery Controller - Part II

Application Delivery Basics

One of the unfortunate effects of the continued evolution of the load balancer into today's application delivery controller (ADC) is that it is often too easy to forget the basic problem for which load balancers were originally created—producing highly available, scalable, and predictable application services. We get too lost in the realm of intelligent application routing, virtualized application services, and shared infrastructure deployments to remember that none of these things are possible without a firm basis in basic load balancing technology. So how important is load balancing, and how do its effects lead to streamlined application delivery?

Let’s examine the basic application delivery transaction. The ADC will typically sit in-line between the client and the hosts that provide the services the client wants to use. As with most things in application delivery, this is not a rule, but more of a best practice in a typical deployment. Let's also assume that the ADC is already configured with a virtual server that points to a cluster consisting of two service points. In this deployment scenario, it is common for the hosts to have a return route that points back to the load balancer so that return traffic will be processed through it on its way back to the client.

The basic application delivery transaction is as follows:

1. The client attempts to connect with the service on the ADC.
2. The ADC accepts the connection, and after deciding which host should receive the connection, changes the destination IP (and possibly port) to match the service of the selected host (note that the source IP of the client is not touched).
3. The host accepts the connection and responds back to the original source, the client, via its default route, the load balancer.
4. The ADC intercepts the return packet from the host and now changes the source IP (and possible port) to match the virtual server IP and port, and forwards the packet back to the client.
5. The client receives the return packet, believing that it came from the virtual server or host, and continues the process. 

Figure 1. A basic load balancing transaction.

This very simple example is relatively straightforward, but there are a couple of key elements to take note of. First, as far as the client knows, it sends packets to the virtual server and the virtual server responds—simple. Second, the NAT takes place. This is where the ADC replaces the destination IP sent by the client (of the virtual server) with the destination IP of the host to which it has chosen to load balance the request. Step three is the second half of this process (the part that makes the NAT "bi-directional"). The source IP of the return packet from the host will be the IP of the host; if this address were not changed and the packet was simply forwarded to the client, the client would be receiving a packet from someone it didn't request one from, and would simply drop it. Instead, the ADC, remembering the connection, rewrites the packet so that the source IP is that of the virtual server, thus solving this problem.

The Application Delivery Decision

So, how does the ADC decide which host to send the connection to? And what happens if the selected host isn't working?

Let's discuss the second question first. What happens if the selected host isn't working? The simple answer is that it doesn't respond to the client request and the connection attempt eventually times out and fails. This is obviously not a preferred circumstance, as it doesn't ensure high availability. That's why most ADC technology includes some level of health monitoring that determines whether a host is actually available before attempting to send connections to it.

There are multiple levels of health monitoring, each with increasing granularity and focus. A basic monitor would simply PING the host itself. If the host does not respond to PING, it is a good assumption that any services defined on the host are probably down and should be removed from the cluster of available services. Unfortunately, even if the host responds to PING, it doesn't necessarily mean the service itself is working. Therefore most devices can do "service PINGs" of some kind, ranging from simple TCP connections all the way to interacting with the application via a scripted or intelligent interaction. These higher-level health monitors not only provide greater confidence in the availability of the actual services (as opposed to the host), but they also allow the load balancer to differentiate between multiple services on a single host. The ADC understands that while one service might be unavailable, other services on the same host might be working just fine and should still be considered as valid destinations for user traffic.

This brings us back to the first question: How does the ADC decide which host to send a connection request to? Each virtual server has a specific dedicated cluster of services (listing the hosts that offer that service) which makes up the list of possibilities. Additionally, the health monitoring modifies that list to make a list of "currently available" hosts that provide the indicated service. It is this modified list from which the ADC chooses the host that will receive a new connection. Deciding the exact host depends on the ADC algorithm associated with that particular cluster. The most common is simple round-robin where the ADC simply goes down the list starting at the top and allocates each new connection to the next host; when it reaches the bottom of the list, it simply starts again at the top. While this is simple and very predictable, it assumes that all connections will have a similar load and duration on the back-end host, which is not always true. More advanced algorithms use things like current-connection counts, host utilization, and even real-world response times for existing traffic to the host in order to pick the most appropriate host from the available cluster services.

Sufficiently advanced application delivery systems will also be able to synthesize health monitoring information with load balancing algorithms to include an understanding of service dependency. This is the case when a single host has multiple services, all of which are necessary to complete the user's request. A common example would be in e-commerce situations where a single host will provide both standard HTTP services (port 80) as well as HTTPS (SSL/TLS at port 443) and any other potential service ports that need to be allowed. In many of these circumstances, you don't want a user going to a host that has one service operational, but not the other. In other words, if the HTTPS services should fail on a host, you also want that host's HTTP service to be taken out of the cluster list of available services. This functionality is increasingly important as HTTP-like services become more differentiated with this things like XML and scripting.

To Load Balance or Not to Load Balance?

Load balancing in regards to picking an available service when a client initiates a transaction request is only half of the solution. Once the connection is established, the ADC must keep track of whether the following traffic from that user should be load balanced. There are generally two specific issues with handling follow-on traffic once it has been load balanced: connection maintenance and persistence.

Connection maintenance

If the user is trying to utilize a long-lived TCP connection (telnet, FTP, and more) that doesn't immediately close, the ADC must ensure that multiple data packets carried across that connection do not get load balanced to other available service hosts. This is connection maintenance and requires two key capabilities: 1) the ability to keep track of open connections and the host service they belong to; and 2) the ability to continue to monitor that connection so the connection table can be updated when the connection closes. This is rather standard fare for most ADCs.

Persistence

Increasingly more common, however, is when the client uses multiple short-lived TCP connections (for example, HTTP) to accomplish a single task. In some cases, like standard web browsing, it doesn't matter and each new request can go to any of the back-end service hosts; however, there are many more instances (XML, JavaScript, e-commerce "shopping cart," HTTPS, and so on) where it is extremely important that multiple connections from the same user go to the same back-end service host and not be load balanced. This concept is called persistence, or server affinity. There are multiple ways to address this depending on the protocol and the desired results. For example, in modern HTTP transactions, the server can specify a "keep-alive" connection, which turns those multiple short-lived connections into a single long-lived connection that can be handled just like the other long-lived connections. However, this provides little relief. Even worse, as the use of web and mobile services increases, keeping all of these connections open longer than necessary would strain the resources of the entire system. In these cases, most ADCs provide other mechanisms for creating artificial server affinity.

One of the most basic forms of persistence is source-address affinity. Source address affinity persistence directs session requests to the same server based solely on the source IP address of a packet. This involves simply recording the source IP address of incoming requests and the service host they were load balanced to, and making all future transaction go to the same host. This is also an easy way to deal with application dependency as it can be applied across all virtual servers and all services. In practice however, the wide-spread use of proxy servers on the Internet and internally in enterprise networks renders this form of persistence almost useless; in theory it works, but proxy-servers inherently hide many users behind a single IP address resulting in none of those users being load balanced after the first user's request—essentially nullifying the ADC capability. Today, the intelligence of ADCs allows organizations to actually open up the data packets and create persistence tables for virtually anything within it. This enables them to use much more unique and identifiable information, such as user name, to maintain persistence. However, organizations one must take care to ensure that this identifiable client information will be present in every request made, as any packets without it will not be persisted and will be load balanced again, most likely breaking the application.

Final Thoughts

It is important to understand that basic load balancing technology, while still in use, is now only considered a feature of Application Delivery Controllers. ADCs evolved from the first load balancers through the service virtualization process and today with software only virtual editions. They can not only improve availability, but also affect the security and performance of the application services being requested.

Today, most organizations realize that simply being able to reach an application doesn't make it usable; and unusable applications mean wasted time and money for the enterprise deploying them. ADCs enable organizations to consolidate network-based services like SSL/TLS offload, caching, compression, rate-shaping, intrusion detection, application firewalls, and even remote access into a single strategic point that can be shared and reused across all application services and all hosts to create a virtualized Application Delivery Network. Basic load balancing is the foundation without which none of the enhanced functionality of today's ADCs would be possible.

And if you missed What is an ADC Part 1, you can find it here.

ps

Next Steps

Now that you’ve gotten this far, would you like to dig deeper or learn more about how application delivery works? Cool, then check out these resources:

• Go Beyond POLB (Plain Old Load Balancing)
• The Cloud-Ready ADC
• BIG-IP Virtual Edition Products, The Virtual ADCs Your Application Delivery Network Has Been Missing
• Cloud Balancing: The Evolution of Global Server Load Balancing

What is an Application Delivery Controller - Part 1

A Little History

Application Delivery got its start in the form of network-based load balancing hardware. It is the essential foundation on which Application Delivery Controllers (ADCs) operate. The second iteration of purpose-built load balancing (following application-based proprietary systems) materialized in the form of network-based appliances. These are the true founding fathers of today's ADCs. Because these devices were application-neutral and resided outside of the application servers themselves, they could load balance using straightforward network techniques. In essence, these devices would present a "virtual server" address to the outside world, and when users attempted to connect, they would forward the connection to the most appropriate real server doing bi-directional network address translation (NAT).

Figure 1: Network-based load balancing appliances.

With the advent of virtualization and cloud computing, the third iteration of ADCs arrived as software delivered virtual editions intended to run on hypervisors. Virtual editions of application delivery services have the same breadth of features as those that run on purpose-built hardware and remove much of the complexity from moving application services between virtual, cloud, and hybrid environments. They allow organizations to quickly and easily spin-up application services in private or public cloud environments.

Basic Application Delivery Terminology

It would certainly help if everyone used the same lexicon; unfortunately, every vendor of load balancing devices (and, in turn, ADCs) seems to use different terminology. With a little explanation, however, the confusion surrounding this issue can easily be alleviated.

Node, Host, Member, and Server

Most ADCs have the concept of a node, host, member, or server; some have all four, but they mean different things. There are two basic concepts that they all try to express. One concept—usually called a node or server—is the idea of the physical or virtual server itself that will receive traffic from the ADC. This is synonymous with the IP address of the physical server and, in the absence of a ADC, would be the IP address that the server name (for example, www.example.com) would resolve to. We will refer to this concept as the host.

The second concept is a member (sometimes, unfortunately, also called a node by some manufacturers). A member is usually a little more defined than a server/node in that it includes the TCP port of the actual application that will be receiving traffic. For instance, a server named www.example.com may resolve to an address of 172.16.1.10, which represents the server/node, and may have an application (a web server) running on TCP port 80, making the member address 172.16.1.10:80. Simply put, the member includes the definition of the application port as well as the IP address of the physical server.  We will refer to this as the service.

Why all the complication? Because the distinction between a physical server and the application services running on it allows the ADC to individually interact with the applications rather than the underlying hardware or hypervisor. A host (172.16.1.10) may have more than one service available (HTTP, FTP, DNS, and so on). By defining each application uniquely (172.16.1.10:80, 172.16.1.10:21, and 172.16.1.10:53), the ADC can apply unique load balancing and health monitoring based on the services instead of the host. However, there are still times when being able to interact with the host (like low-level health monitoring or when taking a server offline for maintenance) is extremely convenient.

Most load balancing-based technology uses some concept to represent the host, or physical server, and another to represent the services available on it— in this case, simply host and services.

Pool, Cluster, and Farm

Load balancing allows organizations to distribute inbound application traffic across multiple back-end destinations, including cloud deployments. It is therefore a necessity to have the concept of a collection of back-end destinations. Clusters, as we will refer to them (also known as pools or farms) are collections of similar services available on any number of hosts. For instance, all services that offer the company web page would be collected into a cluster called "company web page" and all services that offer e-commerce services would be collected into a cluster called "e-commerce."
The key element here is that all systems have a collective object that refers to "all similar services" and makes it easier to work with them as a single unit. This collective object—a cluster—is almost always made up of services, not hosts.

Virtual Server

Although not always the case, today the term virtual server means a server hosting virtual machines. It is important to note that like the definition of services, virtual server usually includes the application port was well as the IP address. The term "virtual service" would be more in keeping with the IP:Port convention; but because most vendors, ADC and Cloud alike use virtual server, this article uses virtual server as well.

Putting It All Together

Putting all of these concepts together makes up the basic steps in load balancing. The ADC presents virtual servers to the outside world. Each virtual server points to a cluster of services that reside on one or more physical hosts.

Figure 2: Application Delivery comprises four basic concepts—virtual servers, clusters, services, and hosts.

While the diagram above may not be representative of a real-world deployment, it does provide the elemental structure for continuing a discussion about application delivery basics.

ps

Next Steps

Check out Part II coming January 26!

ps

What is Load Balancing?

The entire intent of load balancing is to create a system that virtualizes the "service" from the physical servers that actually run that service. A more basic definition is to balance the load across a bunch of physical servers and make those servers look like one great big server to the outside world. There are many reasons to do this, but the primary drivers can be summarized as "scalability," "high availability," and "predictability."

Scalability is the capability of dynamically, or easily, adapting to increased load without impacting existing performance. Service virtualization presented an interesting opportunity for scalability; if the service, or the point of user contact, was separated from the actual servers, scaling of the application would simply mean adding more servers or cloud resources which would not be visible to the end user.

High Availability (HA) is the capability of a site to remain available and accessible even during the failure of one or more systems. Service virtualization also presented an opportunity for HA; if the point of user contact was separated from the actual servers, the failure of an individual server would not render the entire application unavailable. Predictability is a little less clear as it represents pieces of HA as well as some lessons learned along the way. However, predictability can best be described as the capability of having confidence and control in how the services are being delivered and when they are being delivered in regards to availability, performance, and so on.

A Little Background

Back in the early days of the commercial Internet, many would-be dot-com millionaires discovered a serious problem in their plans. Mainframes didn't have web server software (not until the AS/400e, anyway) and even if they did, they couldn't afford them on their start-up budgets. What they could afford was standard, off-the-shelf server hardware from one of the ubiquitous PC manufacturers. The problem for most of them? There was no way that a single PC-based server was ever going to handle the amount of traffic their idea would generate and if it went down, they were offline and out of business. Fortunately, some of those folks actually had plans to make their millions by solving that particular problem; thus was born the load balancing market.

In the Beginning, There Was DNS

Before there were any commercially available, purpose-built load balancing devices, there were many attempts to utilize existing technology to achieve the goals of scalability and HA. The most prevalent, and still used, technology was DNS round-robin. Domain name system (DNS) is the service that translates human-readable names (www.example.com) into machine recognized IP addresses. DNS also provided a way in which each request for name resolution could be answered with multiple IP addresses in different order.

Figure 1: Basic DNS response for redundancy

The first time a user requested resolution for www.example.com, the DNS server would hand back multiple addresses (one for each server that hosted the application) in order, say 1, 2, and 3. The next time, the DNS server would give back the same addresses, but this time as 2, 3, and 1. This solution was simple and provided the basic characteristics of what customer were looking for by distributing users sequentially across multiple physical machines using the name as the virtualization point.

From a scalability standpoint, this solution worked remarkable well; probably the reason why derivatives of this method are still in use today particularly in regards to global load balancing or the distribution of load to different service points around the world. As the service needed to grow, all the business owner needed to do was add a new server, include its IP address in the DNS records, and voila, increased capacity. One note, however, is that DNS responses do have a maximum length that is typically allowed, so there is a potential to outgrow or scale beyond this solution.

This solution did little to improve HA. First off, DNS has no capability of knowing if the servers listed are actually working or not, so if a server became unavailable and a user tried to access it before the DNS administrators knew of the failure and removed it from the DNS list, they might get an IP address for a server that didn't work. 

Proprietary Load Balancing in Software

One of the first purpose-built solutions to the load balancing problem was the development of load balancing capabilities built directly into the application software or the operating system (OS) of the application server. While there were as many different implementations as there were companies who developed them, most of the solutions revolved around basic network trickery. For example, one such solution had all of the servers in a cluster listen to a "cluster IP" in addition to their own physical IP address.

Figure 2: Proprietary cluster IP load balancing

When the user attempted to connect to the service, they connected to the cluster IP instead of to the physical IP of the server. Whichever server in the cluster responded to the connection request first would redirect them to a physical IP address (either their own or another system in the cluster) and the service session would start. One of the key benefits of this solution is that the application developers could use a variety of information to determine which physical IP address the client should connect to. For instance, they could have each server in the cluster maintain a count of how many sessions each clustered member was already servicing and have any new requests directed to the least utilized server.

Initially, the scalability of this solution was readily apparent. All you had to do was build a new server, add it to the cluster, and you grew the capacity of your application. Over time, however, the scalability of application-based load balancing came into question. Because the clustered members needed to stay in constant contact with each other concerning who the next connection should go to, the network traffic between the clustered members increased exponentially with each new server added to the cluster. The scalability was great as long as you didn't need to exceed a small number of servers.

HA was dramatically increased with these solutions. However, since each iteration of intelligence-enabling HA characteristics had a corresponding server and network utilization impact, this also limited scalability. The other negative HA impact was in the realm of reliability. 

Network-Based Load balancing Hardware

The second iteration of purpose-built load balancing came about as network-based appliances. These are the true founding fathers of today's Application Delivery Controllers. Because these boxes were application-neutral and resided outside of the application servers themselves, they could achieve their load balancing using much more straight-forward network techniques. In essence, these devices would present a virtual server address to the outside world and when users attempted to connect, it would forward the connection on the most appropriate real server doing bi-directional network address translation (NAT).

Figure 3: Load balancing with network-based hardware

The load balancer could control exactly which server received which connection and employed "health monitors" of increasing complexity to ensure that the application server (a real, physical server) was responding as needed; if not, it would automatically stop sending traffic to that server until it produced the desired response (indicating that the server was functioning properly). Although the health monitors were rarely as comprehensive as the ones built by the application developers themselves, the network-based hardware approach could provide at least basic load balancing services to nearly every application in a uniform, consistent manner—finally creating a truly virtualized service entry point unique to the application servers serving it.

Scalability with this solution was only limited by the throughput of the load balancing equipment and the networks attached to it. It was not uncommon for organization replacing software-based load balancing with a hardware-based solution to see a dramatic drop in the utilization of their servers. HA was also dramatically reinforced with a hardware-based solution. Predictability was a core component added by the network-based load balancing hardware since it was much easier to predict where a new connection would be directed and much easier to manipulate. 

The advent of the network-based load balancer ushered in a whole new era in the architecture of applications. HA discussions that once revolved around "uptime" quickly became arguments about the meaning of "available" (if a user has to wait 30 seconds for a response, is it available? What about one minute?). 

This is the basis from which Application Delivery Controllers (ADCs) originated.

The ADC

Simply put, ADCs are what all good load balancers grew up to be. While most ADC conversations rarely mention load balancing, without the capabilities of the network-based hardware load balancer, they would be unable to affect application delivery at all. Today, we talk about security, availability, and performance, but the underlying load balancing technology is critical to the execution of all.

ps

Next Steps

Ready to plunge into the next level of Load Balancing? Take a peek at these resources:

• Go Beyond POLB (Plain Old Load Balancing)
• The Cloud-Ready ADC
• BIG-IP Virtual Edition Products, The Virtual ADCs Your Application Delivery Network Has Been Missing
• Cloud Balancing: The Evolution of Global Server Load Balancing

Deploy BIG-IP VE in AWS

Cloud is all the rage these days as it has matured into a bona fide, viable option to deploy your applications. While attractive, you may also want to apply, mimic or sync your traditional data center policies like high availability, scalability and predictability in the cloud.

Here we’ll walk through how to create a simple single NIC (sometimes called “one ARM”) instance of BIG-IP VE in the Amazon Web Services console.

Open the AWS management console and click VPC (Virtual Private Cloud) to dive right into the VPC wizard and create a simple, single public subnet VPC.

Give it a name, accept the other defaults and click Create VPC. When it creates a VPC, it also creates a security group for the VPC. There we’ll want to check some of the rules associated with the security group.

You may also want to update the Name tag field so you can more easily find your group going forward.

The source can be the security group itself or you can replace with a specific IP range. While not the safest, here we’re allowing all traffic. You can also edit the outbound rules if needed.

Next, for our application server, we’ll want to create an EC2 instance of a Microsoft Windows machine with a webpage on it in the VPC. The location of your application server is up to you. For this article, you can see we’ve created an application server with a private IP address along with a corresponding public IP address. You don’t need the public address unless you need to connect directly to the app server.

Next we’ll want to deploy an instance of BIG-IP in the VPC. We’ll search the Marketplace for BIG-IP hourly but you can also use your current BIG-IP license in a Bring Your Own License scenario. There are various throughput limits and BIG-IP module bundles so choose what’s appropriate for your situation. (See this doc for more info on recommended instances)

We’ll choose our region and click continue and then Launch.

We’ll then want to select an instance type and when we get to the Instance Details screen, we’ll choose the VPC and subnet we created earlier. You can make more adjustments here or simply accept the auto-assign defaults.

We’ll move through the Storage step and hit the Add Tags spot and give it a name value, like BIG-IP VE1. Often it is just a simple name so you can find it in the list of instances.

Next we select the existing security group we created or we can create a new one. Since the one we created was wide open, you could create one that allows only port 22 (for SSH), port 443 (for web application/virtual server traffic), and 8443 (for management/Config utility access).

Once that’s done we’ll click launch and select our key pair. You’ll use the key pair when you use SSH to connect to BIG-IP VE.

We get the status page as it launches. The one thing to remember is to allocate an elastic public IP so the BIG-IP instance can hit the license server for verification. You can also use that public IP to connect to the config utility and as the Virtual server address. Once the BIG-IP instance is up and running, you can’t access it until you’ve connected and set a strong admin password. You can do this with PuTTy and the key (Connection > SSH >Auth).

Once we’ve locked it down with a strong password, we’ll use the public IP and take a look at the Config utility which allows us to manage our BIG-IP. Using the new password, now we’re able to start the BIG-IP setup wizard like you would any other BIG-IP. That public IP will be the target to serve traffic to the application through BIG-IP.

From here, you can also update management ports, provision modules, and of course, create the virtual server(s) and pools for your application.

Go back to the AWS console, get the private address of the webserver and that becomes the resource address for your pool.

Same thing for the virtual server. Go to AWS, grab the BIG-IP private address (as opposed to the webserver above) and that is what you enter for the virtual server.

Finish the other resource settings, including the appropriate pool and the virtual server is live and visitors can now enjoy the application. We can add whatever services and profiles we need for a fast, available and secure application.

ps

Related:

• BIG-IP VE in Amazon Web Services (Video)
• F5 in AWS Part 1 - AWS Networking Basics
• F5 BIG-IP Instance Migration in AWS
• DevCentral Wiki: Amazon Web Services
• BIG-IP Virtual Edition and Amazon Web Services: Single NIC Setup

Lightboard Lessons: What is MQTT?

The mad dash to connect virtually every noun to the internet or The Internet of Things, is creating a massive M2M network for all the devices, systems, sensors and actuators to connect & communicate on the Internet.

With that, they need a communications protocol to understand each other. One of those is Message Queue Telemetry Transport (MQTT). MQTT is a “subscribe and publish” messaging protocol designed for lightweight machine-to-machine (or IoT) communications.

In this episode of Lightboard Lessons, I light up how MQTT works.



ps

Related:

• IoT Ready Infrastructure
• IoT Effect on Applications
• IoT Influence on Society
• What are These "Things?
• The Intruders of Things

OK 2017, Now What?

The Year of the (Fire) Rooster will soon be upon us and the talkative, outspoken, frank, open, honest, and loyal Rooster could influence events in 2017. Whether you were born under the symbol or not, Roosters strive on trust and responsibility, essential for any organization especially in these times.

2016 (Year of the Monkey) brought us a crazy year of high profile breaches, a 500% increase in ransomware, a 0-day per day and slick malware each looking to cause havoc on all parts of society including your mobile device. The monkey’s shenanigans exhausted many of us in 2016 and 2017 will require some quick thinking and practical solutions to battle the ongoing, ever-growing threats.

A year ago I noted, Mobility, both the state of being and the devices we use, will continue to grow and be an immense enabler and/or inhibitor for organizations. Today, we are the devices, controllers and data generators and we’re interacting, even socially, with a growing list of robots and objects. Security continues to flummox folks both from a development standpoint – talking to you IoT manufacturers – and from a purely personal realm. The more connected devices we have in and around our lives, homes and offices the more opportunities for the bad guys to take advantage.

This is sure to continue as our digital, software-defined lives connect and intersect with the things around us. We’ll likely see a number of significant IoT security discussions coming out of CES this week too with cars and robots the starring attraction this year.

And as our lives – personal and professional – continue to be chronicled on the internet, the various thieves, nation states, and activists will continue to be one step ahead, probing data and looking for that golden slab of info. Making money, causing disruptions, or orchestrating outright take-downs through online attacks are big motivations for those seeking notoriety or simply a big score. But it’s not always from the crook or spy half a globe away. Insider threats, malicious or not, have made traditional concepts of the perimeter almost useless.

Here at DevCentral, our community is ready to help you through many of your most challenging application delivery endeavors this year. Like the rooster, we aim to be open and honest about how to accomplish a task with BIG-IP...including when it cannot do something.  In recent weeks we’ve posted mitigations for Mirai bots, the recent PHP 0-days, along with a bunch of iControlREST solutions and an excellent article from Kevin Stewart about TLS Fingerprinting. And we look forward to answering your most perplexing BIG-IP questions. Also our very own Jason Rahm passed his Exam 201 - TMOS Administration so make sure you hit him up for some of your harder questions. The rest of the team will be looking to take the F5 Certified 201 sometime this quarter.

While trends like cloud, mobility, IoT, DevOps and big data will consume your attention, securing those trends and how they map to business objectives will come to roost in 2017 and DevCentral is here to help. Let’s try to be smart, practical, open and honest about our challenges and guard against the vain, boastful and attention grabbing bad guys trying to get the best of us.

The 2017 Rooster arrives January 28, 2017 and we’ll need to be prepared and stay calm when the proverbial fan starts spinning.

ps

Related:

• OK 2016, Now What?
• OK 2015, Now What?
• OK 2014, Now What

*Rooster Image courtesy: http://astrologyclub.org/