How Do I Ensure Optimization when Cloud IP Addresses are Always Changing?
Introducing Host Based Name Interception
When cloud services meet enterprise networks, a “hybrid” network is created. Suddenly gaps become apparant as differences in cloud and enterprise networks start to surface. Riverbed introduced Host Name Based Interception to bridge one of these key gaps—IP address changes in cloud services.
With enterprises, there is an assumption that IP addresses are more or less fixed, but cloud services have a more fluid address space. For example, let’s say you want to whitelist all IP addresses to and from a cloud service, and block everything else to enforce security. Sounds good, but cloud services were built from the ground up with the notion that IP addresses for the most part should be unimportant to the customer. All that matters is when you try to connect to blob1234.storage.core.windows.net, the name resolves via DNS and you get the current IP address of service you intended.
IP address changes for cloud resources are very common. With Azure, when you shut down a virtual machine from the Azure management portal, the IP address changes when the VM is restarted unless you have purchased a static IP. With Platform as a Service, you don’t have the option of static IPs. Let’s say you want to optimize a service like Azure Site Recovery which pushes large amounts of data to blob storage. You must lookup the IP address of the storage account and instruct the SteelHead to optimize all traffic to that public IP, but Microsoft does not guarantee that address is static. So how do you tell the SteelHead to optimize the traffic in a reliable way?
To really be “cloud-ready”, optimization rules cannot depend on IP addresses and subnets to identify traffic that is cloud-bound, as those can change. To solve this problem specfically, Riverbed introduced Host Name Based Interception (HNBI) starting in RiOS 9.2.
With HNBI, you instruct the SteelHead to optimize all traffic headed to a DNS name, rather than IP address or subnet. If someone shuts down then restarts your mission critical VM and IP address changes, HNBI will resolve the FQDN for the service and pick up the new address.
Creating a host label
To use HNBI, in the SteelHead administration console, browse to Networking > Host Labels and enter the FQDN of the VM or other service you want to optimize. You also assign a label (which is essentially just name for easy identification) to that entry. Below you can see an entry that designates a blob storage account in Azure assigned to the name label (ASR, which stands for Azure Site Recovery).
After entering then name, click ‘Resolve Hostnames’ to identify the IP address of the entry.
Using a host label in an in-path rule
Then, when you create an in-path rule (shown below). Under destination, just enter the host label associated with FQDN.
Domain labels and wildcards
Say you want to optimize all traffic for your SharePoint farm hosted in Azure. The namespace for your farm is *.widgetfarm.com. HNBI allows you to create a domain label and create a rule using the label to identify and optimize all traffic headed to <anything>.widgetfarm.com.
Summary and resources
That’s it! Of course, we’re assuming here a standard setup for SteelHead optimization of cloud services where your on premise SteelHead is paired with a cloud SteelHead hosted in Azure or AWS to provide an optimization path between your on-premise users and cloud content and services.
HNBI, a feature built into SteelHead is just one of the many ways a SteelHead solution is crafted to improve the performance and efficiency of cloud network services. For more important details and best practices on HBNI, search for “Host Labels” in the SteelHead Management Console User’s Guide.