Archive for devcentral

Cloud Month on DevCentral

Posted in f5, big-ip, cloud, cloud computing, application delivery, devcentral, aws, azure by psilva on June 1st, 2017

 

#DCCloud17

dc-logo.jpgThe term ‘Cloud’ as in Cloud Computing has been around for a while. Some insist Western Union invented the phrase in the 1960s; others point to a 1994 AT&T ad for the PersonaLink Services; and still others argue it was Amazon in 2006 or Google a few years later. And Gartner had Cloud Computing at the top of their Hype Cycle in 2009.

No matter the birth year, Cloud Computing has become an integral part of an organization’s infrastructure and is not going away anytime soon. A 2017 SolarWinds IT Trends report says 95% of businesses have migrated critical applications to the cloud and F5's SOAD report notes that 20% of organizations will have over half their applications in the cloud this year. It is so critical that we’ve decided to dedicate the entire month of June to the Cloud.

We’ve planned a cool cloud encounter for you this month. We’re lucky to have many of F5’s Cloud experts offering their 'how-to' expertise with multiple 4-part series. The idea is to take you through a typical F5 deployment for various cloud vendors throughout the month. Mondays, we got Suzanne Selhorn & Thomas Stanley covering AWS; Wednesdays, Greg Coward will show how to deploy in Azure; Thursdays, Marty Scholes walks us through Google Cloud deployments including Kubernetes.

But wait, there’s more!

On Tuesdays, Hitesh Patel is doing a series on the F5 Cloud/Automation Architectures and how F5 plays in the Service Model, Deployment Model and Operational Model - no matter the cloud and on F5 Friday #Flashback starting tomorrow, we’re excited to have Lori MacVittie revisit some 2008 #F5Friday cloud articles to see if anything has changed a decade later. Hint: It has…mostly. In addition, I’ll offer my weekly take on the tasks & highlights that week.

Below is the calendar for DevCentral's Cloud Month and we’ll be lighting up the links as they get published so bookmark this page and visit daily! Incidentally, I wrote my first Cloud tagged article on DevCentral back in 2009. And if you missed it, Cloud Computing won the 2017 Preakness. Cloudy Skies Ahead!

June 2017

 

Monday

Tuesday

Wednesday

Thursday

Friday

 

28

29

30

31

1

Cloud Month Intro & Calendar

2

Flashback Friday: The Many Faces of Cloud

Lori MacVittie

3

4

5

Successfully Deploy Your Application in the AWS Public Cloud

Suzanne Selhorn

6

Cloud/Automated Systems need an Architecture

Hitesh Patel

7

The Hitchhiker’s Guide to BIG-IP in Azure

Greg Coward

8

Deploy an App into Kubernetes in less than 24 Minutes

Marty Scholes

9

F5 Flashback Friday: The Death of SOA Has (Still) Been Greatly Exaggerated

-Lori

10

11

12

Secure Your New AWS Application with an F5 Web Application Firewall

-Suzanne

13

The Service Model for Cloud/Automated Systems Architecture

-Hitesh

14

The Hitchhiker’s Guide to BIG-IP in Azure – ‘Deployment Scenarios

-Greg

15

Deploy an App into Kubernetes Even Faster (Than Last Week)

-Marty

16

F5 Flashback Friday: Cloud and Technical Data Integration Challenges Waning

-Lori

17

18

19

Shed the Responsibility of WAF Management with F5 Cloud Interconnect

-Suzanne

20

The Deployment Model for Cloud/Automated Systems Architecture

-Hitesh

21

The Hitchhiker’s Guide to BIG-IP in Azure – ‘High Availability’

-Greg

22

Deploy an App into Kubernetes Using Advanced Application Services

-Marty

23

Flashback Friday: Is Vertical Scalability Still Your Problem?

-Lori

24

25

26

​Get Back Speed and Agility of App Development in the Cloud with F5 Application Connector

-Suzanne

27

The Operational Model for Cloud/Automated Systems Architecture

-Hitesh

28

The Hitchhiker’s Guide to BIG-IP in Azure – ‘Life Cycle Management’

-Greg

29

Peek under the Covers of your Kubernetes Apps

-Marty

30

Cloud Month Wrap!

 

Titles subject to change...but not by much.

ps

 




Device Discovery on BIG-IQ 5.1

Posted in f5, big-ip, cloud computing, adc, application delivery, devcentral, aws, azure, access, big-iq by psilva on May 23rd, 2017

The first step in using a BIG-IQ to manage BIG-IP devices

BIG-IQ enables administrators to centrally manage BIG-IP infrastructure across the IT landscape.  BIG-IQ discovers, tracks, manages, and monitors physical and virtual BIG-IP devices - in the cloud, on premise, or co-located at your preferred datacenter.

Let’s look at how to get BIG-IQ 5.1 to gather the information needed to start managing a BIG-IP device. This gathering process is called Device Discovery.

To get started, the first thing is to logon to the BIG-IQ

iq2.jpg

Once in, the first thing you do is let the BIG-IQ know about the BIG-IP device that you want to manage. Here, in Device Management>Inventory>BIG-IP Devices, we’ll click Add Device.

iq3.jpg

Here we’ll need the IP address, user name and password of the device you want to manage. If the device you want to manage is part of a BIG-IP Device Service Cluster (DSC), you’ll probably want to manage that part of its configuration by adding it to a DSC group on the BIG-IQ. After selecting a DSC, tell the BIG-IQ how to handle synchronization when you deploy configuration changes so that when you deploy changes to one device, the other DSC members get the same changes. Best practice is to let BIG-IQ do the sync.

iq5.jpg

Next click Add at the bottom of the page to start the discovery process.

iq6.jpg

Once the device recognizes your credentials, it’ll prompt you to choose the services that you want to manage. You always select LTM, even if you only mange other services because the other services depend on LTM. To finish the device discovery task, click Discover.

iq7.jpg

The BIG-IQ gathers the information it needs for each of the services you requested. This first step takes only a few moments while the BIG-IQ discovers your devices. You are done with discovery once the status update reads, Complete import tasks.

iq8.jpg

Now, we need to import the service configurations that the BIG-IQ needs before we can start managing that BIG-IP device. Click the link that says, Complete import tasks.

Next, you’ll begin the process of importing the BIG-IP LTM services for this device. Just like the discovery task, you’ll import LTM first.

Click Import.

iq9.jpg

This could take a little time depending on how many LTM objects are defined on this BIG-IP device. When the import finishes, BIG-IQ will display the date and time of when the operation was completed.

iq91.jpg

Now, we repeat the process for the second service provisioned on this device.

iq92.jpg

Importing an access device like BIG-IP APM is slightly different. Part of the import task is to identify the Access Group that this device uses to share its configuration. Whether you’re adding to an existing or creating a new access group, when you’re done entering the name of the group, click Add to start the import process. Here again, the time to process depends on how many BIG-IP APM configuration objects are defined on the device.

iq93.jpg

When the BIG-IP APM services import finishes and the time completed displays, you can simply click Close to complete the task.

iq94.jpg

You can now see that the device has been added to BIG-IQ.

iq95.jpg

That’s it! Now you can start managing the BIG-IP LTM and APM object on this device. For this article, we only imported LTM and APM objects but the process is the same for all services you manage.

Thanks to our TechPubs group and watch the video demo here.

ps

Related:

What is BIG-IQ




Lightboard Lessons: What is BIG-IP?

Posted in security, f5, big-ip, silva, video, application delivery, lightboard, devcentral by psilva on May 10th, 2017

In the early days of F5, BIG/IP was our original load balancer. Today, BIG-IP is a family of products covering software and hardware designed around application availability, access control, and security solutions.

In this Lightboard Lesson, Peter Silva lights up the various BIG-IP modules and what they do.

 

 

Watch Now:



DevCentral’s Featured Member for May – NTT Security’s Leonardo Souza

Posted in security, f5, big-ip, interview, silva, devcentral, irules, programmability by psilva on May 2nd, 2017

leonardo.jpgLeonardo Souza lives in the United Kingdom, with his partner, 5-year-old daughter, and a (very) recently newborn son. He’s Brazilian and lived in Portugal for quite a while. He then moved to UK about 5 years ago ‘because of the amazing weather,’ he jokes.

Leonardo started to work with computers when he was 18 years old (he’s not 18 anymore), so he’s worked with many technologies. Fast forward a bit (he’s not that old) and while working as a network engineer, he was working on a project to migrate applications from Alteon load balancers to F5 BIG-IP LTMs. He completed his LTM Essentials and LTM Advanced training during that time (2011) and with the migration project, he was impressed with BIG-IP.

He even applied for a job at F5 in 2012 and joined as a Network Support Engineer. That moved him from Portugal to UK, and has been doing F5 products exclusively ever since.

With all that, Leonardo is DevCentral’s Featured Member for May and we got a chance to talk with Leonardo about his life, work and scripting prowess.

DevCentral: You were an F5er from 2012-15 and continue to be a very active contributor in the DevCentral community. What keeps you involved?

Leonardo: I often say that 1 year in F5 support is equal to 5 years as a F5 customer.

While in F5 support, I had multiple technical challenges every day, and I would typically go to DevCentral to check iRules documentation and get ideas for uncommon cases. After I left F5, I started using DevCentral to stay up to date about what is going on in the F5 world by reading the DevCentral articles. Then I started to go there daily and answer some questions myself.

Short answer: to keep me updated, both about F5 news and my F5 knowledge.

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

LS: Is difficult to know all F5 products, because some are for very specific networks/scenarios, but I know the common ones:

BIG-IP BIG-IP LTM, GTM/DNS, AFM, APM, ASM, EM, BIG-IQ, and iRules.

I had been a little bit lazy about the F5 certifications but recently I have done all level 300 exams. I have started study for the 401, so that should be done in the next couple months.

DC: As a Security Consultant at NTT Security, what’s your typical workday?

LS: First to clarify, the company recently changed names from NTT Com Security to NTT Security.

nttlogo.jpgI work in professional services, doing projects that use F5 products. My daily work includes doing some pre-sales activities advising pre-sales team about the F5 products, doing projects, and finding solutions or writing scripts to automate some F5 tasks.

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

LS: I have been using DevCentral for many years, and iRules, to a point where it is part of my daily job. Flexibility is a major advantage for F5 and people ask all the time “Can you do this with an iRule?”

Recently, I was working in a project to upgrade many F5 devices. We had to perform an extensive inventory for each device which was taking about 3 days per device. I wrote a Python script using iControl SOAP to perform that task. (I still prefer bash script, but there is no iControl SOAP for bash)

It would take around 240 days to do that manually, and we did in around 3 days using the script.

DC: Finally, if you weren’t in technology – what would be your dream job? Or better, when you were a kid – what did you want to be when you grew up?

LS: I am doing the job I wanted since I was young and I can’t picture myself doing any other type of job.

Thanks Leonardo! Check out all Leonardo’s DevCentral contributions or connect with him on LinkedIn. And visit NTT Security on the web or follow on Twitter and LinkedIn.

 




Configure HA Groups on BIG-IP

Posted in f5, big-ip, availability, load balance, application delivery, devcentral by psilva on April 25th, 2017

Last week we talked about how HA Groups work on BIG-IP and this week we’ll look at how to configure HA Groups in BIG-IP.

To recap, an HA group is a configuration object you create and assign to a traffic group for devices in a device group. An HA group defines health criteria for a resource (such as an application server pool) that the traffic group uses. With an HA group, the BIG-IP system can decide whether to keep a traffic group active on its current device or fail over the traffic group to another device when resources such as pool members fall below a certain level.

First, some prerequisites:

  • Basic Setup: Each BIG-IP (v13) is licensed, provisioned and configured to run BIG-IP LTM
  • HA Configuration: All BIG-IP devices are members of a sync-failover device group and synced
  • Each BIG-IP has a unique virtual server with a unique server pool assigned to it
  • All virtual addresses are associated with traffic-group-1

To the BIG-IP GUI!

First you go to System>High Availability>HA Group List>and then click the Create button.

hab1.jpg

 

The first thing is to name the group. Give it a detailed name to indicate the object group type, the device it pertains to and the traffic group it pertains to. In this case, we’ll call it ‘ha_group_deviceA_tg1.’

hab2.jpg

 

Next, we’ll click Add in the Pools area under Health Conditions and add the pool for BIG-IP A to the HA Group which we’ve already created. We then move on to the minimum member count. The minimum member count is members that need to be up for traffic-group-1 to remain active on BIG-IP A. In this case, we want 3 out of 4 members to be up. If that number falls below 3, the BIG-IP will automatically fail the traffic group over to another device in the device group.

hab34.jpg

 

Next is HA Score and this is the sufficient threshold which is the number of up pool members you want to represent a full health score. In this case, we’ll choose 4. So if 4 pool members are up then it is considered to have a full health score. If fewer than 4 members are up, then this health score would be lower. We’ll give it a default weight of 10 since 10 represents the full HA score for BIG-IP A. We’re going to say that all 4 members need to be active in the group in order for BIG-IP to give BIG-IP A an HA score of 10. And we click Add.

hab6.jpg

 

We’ll then see a summary of the health conditions we just specified including the minimum member count and sufficient member count. Then click Create HA Group.

hab7.jpg

 

Next, we go to Device Management>Traffic Groups>and click on traffic-group-1.

hab8.jpg

 

Now, we’ll associate this new HA Group with traffic-group-1. Go to the HA Group setting and select the new HA Group from the drop-down list. And then select the Failover Method to Device with the Best HA Score. Click Save.

hab81.jpg

 

Now we do the same thing for BIG-IP B. So again, go to System>High Availability>HA Group List>and then click the Create button. Give it a special name, click Add in the Pools area and select the pool you’ve already created for BIG-IP B. Again, for our situation, we’ll specify a minimum of 3 members to be up if traffic-group-1 is active on BIG-IP B. This minimum number does not have to be the same as the other HA Group, but it is for this example. Again, a default weight of 10 in the HA Score for all pool members. Click Add and then Create HA Group for BIG-IP B.

hab82.jpg

 

And then, Device Management>Traffic Groups> and click traffic-group-1. Choose BIG-IP B’s HA Group and select the same Failover method as BIG-IP A – Based on HA Score. Click Save.

Lastly, you would create another HA Group on BIG-IP C as we’ve done on BIG-IP A and BIG-IP B. Once that happens, you’ll have the same set up as this:

ha2a.jpg

As you can see, BIG-IP A has lost another pool member causing traffic-group-1 to failover and the BIG-IP software has chosen BIG-IP C as the next active device to host the traffic group because BIG-IP C has the highest HA Score based on the health of its pool.

Thanks to our TechPubs group for the basis of this article and check out a video demo here.

ps

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 




Lightboard Lessons: The BIG-IP Profiles

Posted in Uncategorized, f5, big-ip, application delivery, lightboard, devcentral by psilva on April 19th, 2017

BIG-IP can manage application-specific network traffic in a variety of ways, depending on the protocols and services being used. On BIG-IP, Profiles are a set of tools that you can use to intelligently control the behavior of that traffic.

In this Lightboard Lesson, I light up the BIG-IP Profiles. What they are, what they do and why you should care.

 

ps

Related:

Watch Now:



Deploy BIG-IP VE in Microsoft Azure Using an ARM Template

Posted in f5, big-ip, cloud, application delivery, devcentral, azure, access by psilva on April 12th, 2017

arm_logo1.jpgAzure Resource Manager (ARM) templates allow you to repeatedly deploy applications with confidence. The resources are deployed in a consistent state and you can easily manage and visualize resources for your application.

ARM templates take the guesswork out of creating repeatable applications and environments. Deploy and deploy again, consistently.

Let’s walk through how to deploy a simple, single-NIC configuration of BIG-IP VE in Microsoft Azure using an ARM template.

First, go to the F5 Networks Github site where we keep our supported templates. There are other community-based templates at www.github.com/f5devcentral if needed but for F5 supported templates, go to the F5 Networks site.

ave1.jpg

To view Azure templates, click f5-azure-arm-templates. In that folder you’ll see experimental and right under that is supported (the one you want).

ave2.jpg

Then click on the standalone folder and then the 1nic folder, which is the simplest deployment.

ave34.jpg

And as you scroll through and review the ‘Read Me,’ you’ll see the Deploy to Azure button under Installation. Select either Bring Your Own License (BYOL) or Pay As You Go (PAYG), depending on your situation.

ave5.jpg

This will launch the Azure Portal and the only thing you’ll really need is a license key if you chose BYOL. Then simply fill out the template.

In this case, we’re going to use an existing resource group that already contains an application.

ave7.jpg

Important: In the Settings section under Admin UN/PW, enter the credentials you want to use to log in to BIG-IP VE. The DNS Label (where you see REQUIRED) will be used to access your BIG-IP VE, for example, if you enter mybigip, the address will be something like  ‘mybigip.westus.cloudapp.azure.com.’ Give the Instance Name something familiar for easy finding.

ave9.jpg

There are different Azure Instance Types, which determine CPU and memory for your VM, and F5 licensing (Good/Better/Best), which determines the BIG-IP modules you can deploy. Then, if needed, enter your BYOL license key.

In addition, to be more secure, you should enter a range of IP addresses on your network in the Restricted Src Addresses field so it’s locked to your address range. This setting determines who gets access to the BIG-IP instance in Azure, so you’ll want to lock it down.

After the tag values, agree to the terms and conditions and click Purchase.

ave91.jpg

Next, you can monitor progress on the deploy status. Keep hitting refresh and you’ll start seeing resources getting populated along with the top blue ‘Deploying’ indicator. When the Deploying bar disappears, you know you’re done.

ave93.jpg

Once complete, you get the notification that the BIG-IP VE was deployed successfully. Next, we’ll navigate to the resource group we selected at the top and then the security group for the BIG-IP.

ave96.jpg

You can see that within the security rules we’ve allowed ports 443 (HTTPS) and 22 (SSH). 22 allows access to the management port; this is the way we’d connect to the BIG-IP to configure and administer.

ave97.jpg

Going back to the resources, the BIG-IP VE itself is listed at the top.

ave98.jpg

When we click on the Virtual BIG-IP we can get the IP address and using a browser through port 443, we can connect either with the DNS name or the IP address to the config utility.

ave97.jpg

Here you would enter the Azure credentials you specified in the template.

ave991.jpg

And that’s all there is to it. Now you can configure your virtual servers, pool, profiles and anything you’d normally do on BIG-IP VE for your unique requirements. Thanks to Suzanne Selhorn for the basis of this article and catch a video demo here.

ps

Related:

 

 




Q/A with Betsson’s Patrik Jonsson - DevCentral’s Featured Member for April

Posted in f5, big-ip, silva, devcentral, infrastructure, games by psilva on April 4th, 2017

 

 

patrik.jpgPatrik Jonsson lives in Stockholm with his wife and son and works as a network engineer for a company providing online casino games across the world.

Outside work, he likes to spend time with his family, play around with his home VMware lab and enjoys watching movies. He also loves travelling and having a beer with friends.

Patrik is also a 2017 DevCentral MVP and DevCentral’s Featured Member for April! DevCentral got a chance to talk with Patrik about his work, life and his project the BIG-IP Report.

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

Patrik: One of the best, and fun ways to learn new things is to take on problems, or discussions presented by fellow technicians. It forces you to continuously challenge what you think you know and keeps your knowledge up to date. In addition, when I need input, or help myself, DevCentral has so many brilliant and helpful members ready to take on whatever you throw at them.

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

PJ: The first time I ran into a BIG-IP was just after I graduated from university. It was a 1000 series running BIG-IP v4. When I quit that job 6 years later I considered asking to bring it home with me, but somehow my girlfriend at the time was not as keen to the idea. Still don’t know why. :-)

I’ve been working mostly with BIG-IP LTM and iControl, but recently I’ve started to dabble a bit with APM, GTM/DNS and ASM as well.

DC: You are a Network Security Specialist at Betsson. Can you describe your typical workday?

PJ: At Betsson you never know what’s going to happen when you step into the office. The gaming industry has very tough competition and getting comfortable as one of the bigger players around is not an option since rivals are always ready to take your place. This, combined with awesome colleagues, makes it a joy to step into the office every morning.

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


betsson_logo.jpgPJ:
Being a multinational company with offices supporting multiple brands, one of the biggest challenges we have is knowledge sharing. Giving the developers the correct information when they need it is vital for an efficient application delivery. In order to provide this, we have used iRules to present troubleshooting information in the form of custom headers so developers can see which pool and member that responded to their request and the current status of all members. We also have a smarter version of the traditional sorry page which shows information about the failed pool and what’s being monitored. And then of course, BIG-IP Report.

All of these are using iRules and iControl and would not have been possible without the DevCentral API documentation and of course, my hero Joe Pruitt.

DC: What can readers learn from your blog: https://loadbalancing.se/ and what is the BIG-IP Report?

PJ: My blog is where I post ideas and projects that I have. There’s a BIG-IP APM + Google Authenticator guide, F5 Web UI augmentation script for version 11 and a few other things.

BIG-IP Report was born out of a need to show people the load balancing configuration in a simple manner without giving them access to the BIG-IP interface. After implementing it we have gone from developers asking us where things are, to instead them telling us about bad configuration. We also discovered that it is awesome for us as well, as we can get an overview of the configuration across multiple devices. Finding a specific VIP, or pool is so much easier when the information is in one place.

I guess the best way to understand it is to try it at http://loadbalancing.se/bigipreportdemo/

The blog is not updated that often, so it’s safe to subscribe without getting too much spam.

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?

PJ: I think my dream would be working with a non-profit organization helping people in need. I love travelling and combining that with something meaningful would be really nice.

Thanks Patrik! Check out all of Patrik’s DevCentral contributions, check out his blog, or connect on LinkedIn. And visit Betsson on the web or follow on Twitter.

 

 




Lightboard Lessons: Service Consolidation on BIG-IP

Posted in f5, adc, silva, application delivery, lightboard, devcentral, infrastructure, consolidate by psilva on March 29th, 2017

The Consolidation of point devices and services in your datacenter or cloud can help with cost, complexity, efficiency, management, provisioning and troubleshooting your infrastructure and systems.

In this Lightboard Lesson, I light up many of the services you can consolidate on BIG-IP.

ps

 

Watch Now:



What is a Proxy?

Posted in Uncategorized, security, big-ip, silva, application delivery, devcentral, proxy by psilva on March 28th, 2017

devcentral_basics_article_banner.png

 

The term ‘Proxy’ is a contraction that comes from the middle English word procuracy, a legal term meaning to act on behalf of another. You may have heard of a proxy vote. Where you submit your choice and someone else votes the ballot on your behalf.

In networking and web traffic, a proxy is a device or server that acts on behalf of other devices. It sits between two entities and performs a service. Proxies are hardware or software solutions that sit between the client and the server and does something to requests and sometimes responses.

The first kind of proxy we’ll discuss is a half proxy. With a Half-Proxy, a client will connect to the proxy and the proxy will establish the session with the servers. The proxy will then respond back to the client with the information. After that initial connection is set up, the rest of the traffic with go right through the proxy to the back-end resources. The proxy may do things like L4 port switching, routing or NAT’ing but at this point it is not doing anything intelligent other than passing traffic.

halfvsfull.jpg
Basically, the half-proxy sets up a call and then the client and server does their thing. Half-proxies are also good for Direct Server Return (DSR). For protocols like streaming protocols, you’ll have the initial set up but instead of going through the proxy for the rest of the connections, the server will bypass the proxy and go straight to the client. This is so you don’t waste resources on the proxy for something that can be done directly server to client.

A Full Proxy on the other hand, handles all the traffic. A full proxy creates a client connection along with a separate server connection with a little gap in the middle. The client connects to the proxy on one end and the proxy establishes a separate, independent connection to the server. This is bi-directionally on both sides. There is never any blending of connections from the client side to the server side – the connections are independent. This is what we mean when we say BIG-IP is a full proxy architecture.

The full proxy intelligence is in that OSI Gap. With a half-proxy, it is mostly client side traffic on the way in during a request and then does what it needs…with a full proxy you can manipulate, inspect, drop, do what you need to the traffic on both sides and in both directions. Whether a request or response, you can manipulate traffic on the client side request, the server side request, the server side response or client side response. You get a lot more power with a full proxy than you would with a half proxy.

reverseproxy_thumb.jpgWith BIG-IP (a full proxy) on the server side it can be used as a reverse proxy. When clients make a request from the internet, they terminate on the reverse proxy sitting in front of application servers. Reverse proxies are good for traditional load balancing, optimization, server side caching, and security functionality. If you know certain clients or IP spaces are acceptable, you can whitelist them. Same with known malicious sources or bad ranges/clients, you can blacklist them. You can do it at the IP layer (L4) or you can go up the stack to Layer 7 and control an http/s request. Or add a BIG-IP ASM policy on there. As it inspects the protocol traffic if it sees some anomaly that is not native to the application like a SQL injection, you can block it.

forwardproxy_2.jpgOn the client side, BIG-IP can also be a forward proxy. In this case, the client connects to the BIG-IP on an outbound request and the proxy acts on behalf of the client to the outside world. This is perfect for things like client side caching (grabbing a video and storing locally), filtering (blocking certain time-wasting sites or malicious content) along with privacy (masking internal resources) along with security.

You can also have a services layer, like an ICAP server, where you can pass traffic to an inspection engine prior to hitting the internet. You can manipulate client side traffic out to the internet, server side in from the internet, handle locally on the platform or or pass off to a third party services entity. A full proxy is your friend in an application delivery environment.

If you'd like to learn more about Proxies, check out the resources below including the Lightboard Lesson: What is a Proxy?

Related:

 





« Older episodes · Newer episodes »