On the edge of cloud computing

CloudFlare Railgun on AWS

Instructions for configuring a highly available CloudFlare Railgun setup within Amazon Web Services (AWS), using ElastiCache, AutoScaling and Elastic Load Balancing (ELB).

Read More...

RUM “Light” with CloudFlare and Google Analytics

Would you like to know the ratio of visitors accessing your website over IPv4 vs. IPv6? Or curious about how many visitors you serve over HTTP/2 vs. SPDY or HTTP 1.1? Using Google Analytics, CloudFlare and some JavaScript magic we can easily get answers to these questions. For this we will use the principle of Real User Monitoring (RUM). In a previous post I’ve already shown how we can track the usage of CloudFlare data centers for the delivery of our website in Google Analytics. In this blog post I want to show you how to refine this method even further and also include information about other interesting metrics, such as IPv6 and HTTP/2 usage . Possible custom dimensions In the previous post I used response header information, presented by the CloudFlare edge servers to extract information about the served traffic. This time we will instead use a special debugging URL that is available for all CloudFlare powered sites. It is available under https://www.example.com/cdn-cgi/trace, where https://www.example.com/ corresponds to the CloudFlare powered domain. The result will look like this: fl=4f96 h=www.cloudflare.com ip=2606:4700:1000:8200:7847:642:dc8e:b176 ts=1454615047.969 visit_scheme=https uag=Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36 colo=SJC spdy=h2 loc=US Let’s have a closer look at the fields that are interesting to us and what they mean: ip: This lists the IP address that was used to contact CloudFlare for this request. We can use this value to determine whether the request was made over IPv4 or IPv6. visit_scheme: This will tell you whether the request was made over HTTP or HTTPS. In case you serve traffic only over HTTPS, this is rather not interesting. Otherwise you could use it to determine the traffic split between visitor using an encrypted vs. un-encrypted connection. colo: The CloudFlare Points-of-Presence (PoP), which served this traffic. In the previous post you have already seen how to use this. spdy: The HTTP protocol version that was used to serve this content. Even though the key is called “spdy”, the value can also indicate HTTP/2 via “h2” (as depicted above). A value of “3.1” will indicate SPDY/3.1 and “off” will indicate HTTP 1.x. It would make more sense to have the field “http” available with “http=h2” for HTTP/2, “http=spdy/3.1” for SPDY/3.1, and “http=http/1.x” for HTTP/1.x. But for now the “spdy” field is good enough. loc: The country that CloudFlare located the visitor in. This information is already available in Google Analytics, we therefore do not need to extract it here. How does Real User Monitoring fit into the picture? Now that we know about all this great data at /cdn-cgi/trace for our website, how can we make this accessible in Google Analytics? Especially while keeping in mind, that this data is only available for the current connection and differs from user to user. The trick: We make the user download the data, extract the values and push the results into Google Analytics. This approach of leveraging a real user to measure or monitor something is called Real User Monitoring or RUM for short. Figure 1: Interaction between browser, CloudFlare and Google Analytics The workflow that will be execute on every page load is as follows (See Figure 1): Step 1: A user requests a page via his or her browser. Step 2: The content is returned and includes a JavaScript to be executed by the browser. Step 3: The JavaScript requests the content from /cdn-cgi/trace. Step 4: The different values for that particular visitor and browsing session are returned to the JavaScript. Step 5: The JavaScript pushes the values as custom dimension into Google Analytics. The additional request of the browser to /cdn-cgi/trace is similar to the browser loading stylesheets or images for rendering a page. This added round-trip to the closest CloudFlare edge for one more element does not impact the performance of the site. Create custom dimensiosn in Google Analytics For each value from /cdn-cgi/trace that we want to track, we need to create a custom dimension in Google Analytics. Here is an example mapping for the values that we want to track in this blog post: dimension1: CloudFlare PoP location dimension2: Access Scheme (HTTPS vs. HTTP) dimension3: IP Transport Method (IPv4 vs. IPv6) dimension4: HTTP version (HTTP 1.1 vs. SPDY vs. HTTP/2) First, set up the custom dimensions in Google Analytics: Sign in to Google Analytics. Select the Admin tab and navigate to the property to which you want to add custom dimensions. In the Property column, click Custom Definitions, then click Custom Dimensions. Click New Custom Dimension. Add a Name. This can be any string, but use something unique so it’s not confused with any other dimension or metric in your reports. Only you will see this name in the Google Analytics page. 6. Select the **Scope**. Choose to track at the Hit, Session, User, or Product level. For this scenario I recommend to choose Hit or rather Session. 7. Check the **Active** box to start collecting data and see the dimension in your reports right away. To create the dimension but have it remain inactive, uncheck the box. 8. Click **Create**. 9. Note down the dimension ID from the displayed example codes. In the example for this blog post the dimension IDs are listed above for the three monitored values. Figure 2: Create a Google Analytics Custom Dimension Embed the Google Analytics Tracking Code Next we need to embed the Google Analytics tracking code within the website, in order to fill the newly created custom dimensions with data. This tracking code has to be placed between the code for creating the Google Analytics tracker, which looks like this: __gaTracker('create','UA-12345678-1','auto');, and the code to submit the tracker, which looks like this __gaTracker('send','pageview');. If you are using WordPress the easiest way to include the custom tracking code is by using the “Google Analytics by Yoast” plugin. This plugin allows you under Advanced > Custom Code to embed the below code right away and without any coding requirements. The below JavaScript code will read the values from /cdn-cgi/trace, extract the information we are interested it and push it into the Google Analytics custom dimension variables. Ensure that the numeric IDs of these custom dimension variables matches what you have created in above steps. function processData(x) { var y = {}; for (var i = 0; i < x.length-1; i++) { var split = x[i].split('='); y[split[0].trim()] = split[1].trim(); } return y; } function objData(x) { return obj[x]; } function isIPv6() { ipv6 = (objData('ip').indexOf(":") > -1); switch (ipv6){ case true: return "IPv6"; break; default: return "IPv4"; } } var data; var obj; var client = new XMLHttpRequest(); client.open("GET", "/cdn-cgi/trace", false); client.onreadystatechange = function () { if(client.readyState === 4){ if(client.status === 200 || client.status == 0){ data = client.responseText.split("\n"); } } }; client.send(null); obj= processData(data); __gaTracker('set','dimension1',objData('colo')); __gaTracker('set','dimension2',isIPv6()); __gaTracker('set','dimension3',objData('spdy')); Embedded in your website along with the standard Google Analytics tracking code, this custom JavaScript code will be executed by a visitor, collect metrics data from /cdn-cgi/trace and push it into Google Analytics. A few hours after embedding the code you should see your first custom dimension data in Google Analytics. Create custom reports in Google Analytics You can now create custom reports with the custom dimensions in Google Analytics. A simple example would be to determine the IPv4 vs. IPv6 traffic ratio. Make sure you are still signed in to Google Analytics. Select the Customization tab and click on New Custom Report. Name your Custom Report here. Select a Metric for which you want to see your Custom Dimensions. I recommend the metric “Sessions” within the “Users” Metric Group. Next select the custom dimension for the IP Transport Method (IPv4 vs. IPv6), that you created as the “Dimension Drilldown” (See Figure 3). Click on the Save button. Figure 3: Create a Custom Report in Google Analytics The resulting Custom Report will show you how many session – in total numbers, but also in percent – were served by which transport method. Figure 4: Traffic served over IPv4 vs. IPv6 You can generate similar graphs for the other custom dimensions. E.g. in order to find out how much of your web-sites traffic was served over HTTP/2 (See Figure 5). Figure 5: Traffic served over HTTP/2 vs. SPDY vs. HTTP 1.x By combining data from the custom dimension with data collected by Google Analytcis natively you can answer many interesting questions for your website, such as: Is IPv6 traffic really mostly driven by mobile traffic? Where are all these users with HTTP/2 capable browsers located? Summary This article has shown you, that you can easily built your own Real User Monitoring system with Google Analytics Custom dimension and some JavaScript code. It allows you to extract many interesting metrics out of your CloudFlare usage and make it available in Google Analytics for further data analysis. Not only has this site been using the above described method since November 2015, but also another well-known site, which has provided interesting insights into the HTTP/2 adoption.

Read More...

Track your CloudFlare PoPs usage in Google Analytics

Cloudflare provides a content delivery network and distributed domain name server services to help secure and accelerate websites. This cloud-based service sits between the visitor and the CloudFlare user’s hosting provider, acting as a reverse proxy for the website. This article will help you visualize the global presence of your website, when using CloudFlare, with the well-known tool Google Analytics. You need to have your website running through CloudFlare for this to work. Signing up wit CloudFlare is easy and free and usually only takes 5 minutes. About CloudFlare’s Points-of-Presence CloudFlare currently uses 63 data centers worldwide as points-of-presence to deliver fast and secure website traffic (See Figure 1). Figure 1: Current CloudFlare Network Map This means that as a CloudFlare customer your website is delivered to your audience from all these locations worldwide, reducing the network hops and lowering latency. As a result your website gains a global presence on an affordable budget, while improving performance. Wouldn’t it be great to get insight into how much these worldwide locations help you with your website? In this post you will learn how to get started by gaining insight into which CloudFlare location delivers your website traffic. Create a custom dimension in Google Analytics First, set up a custom dimensions for the location of the CloudFlare PoP that serves a request in Google Analytics: Sign in to Google Analytics. Select the Admin tab and navigate to the property to which you want to add custom dimensions. In the Property column, click Custom Definitions, then click Custom Dimensions. Click New Custom Dimension. Add a Name. This can be any string, but use something unique so it’s not confused with any other dimension or metric in your reports. Only you will see this name in the Google Analytics page. 6. Select the **Scope**. Choose to track at the Hit, Session, User, or Product level. For this scenario I recommend to choose Hit or rather Session. 7. Check the **Active** box to start collecting data and see the dimension in your reports right away. To create the dimension but have it remain inactive, uncheck the box. 8. Click **Create**. 9. Note down the dimension ID from the displayed example codes. In the example for this blog post the dimension ID is &#8220;1&#8221; (See Figure 2). Figure 2: Create a Google Analytics Custom Dimension Embed the Google Analytics Tracking Code Next we need to embed the Google Analytics tracking code within the website, in order to fill the newly created custom dimension with data. This tracking code has to be placed between the code for creating the Google Analytics tracker, which looks like this: __gaTracker('create','UA-12345678-1','auto');, and the code to submit the tracker, which looks like this __gaTracker('send','pageview');. If you are using WordPress the easiest way to include the custom tracking code is by using the “Google Analytics by Yoast” plugin. This plugin allows you under Advanced > Custom Code to embed the below code right away and without any coding requirements. But first we have to actually determine the CloudFlare PoP location that serves a request. For this we can use the HTTP response header “cf-ray”, which is added by CLoudFlare for troubleshooting purposes. It includes a numeric value, as well as the location code of the CloudFlare PoP. The below JavaScript code will read the “cf-ray” response header, extract the location ID and push it into the Google Analytics custom dimension variable. Ensure that the numeric ID of this custom dimension variable matches what you have created in above steps. function loc(){ var req = new XMLHttpRequest(); req.open('HEAD', document.location, false); req.send(null); return (req.getResponseHeader("cf-ray").split("-"))[1]; } __gaTracker('set','dimension1',loc()); Embedded in your website along with the standard Google Analytics tracking code, this custom JavaScript code will determine the CloudFlare PoP over which the corresponding site was served and push it into Google Analytics. A few hours after embedding the code you should see your first custom dimension data in Google Analytics. Create a custom report in Google Analytics You can now create custom reports with the custom dimension in Google Analytics. A simple example would be to determine which CloudFlare PoP serves how many of your audience’s session. Make sure you are still signed in to Google Analytics. Select the Customization tab and click on New Custom Report. Name your Custom Report here. Select a Metric for which you want to see your Custom Dimensions. I recommend the metric “Sessions” within the “Users” Metric Group. Next select the custom dimension that you created as the “Dimension Drilldown” (See Figure 3). Click on the Save button. Figure 3: Create a Custom Report in Google Analytics The resulting Custom Report will show you how many session – in total numbers, but also in percent – were served by which CloudFlare PoP. Using the “Percantage” button you can quickly generate a pie chart with the data (See Figure 4). In the example below you can see that the three most used CloudFlare PoPs for this site are San Jose, Chicago and Frankfurt (Germany). Figure 4: Your CloudFlare PoP utilization Combining the new custom dimension with Google Analytics Data Now that we have the CloudFlare Point-of-Presence that served a web site in Google Analytics, we can leverage this data for many more interesting reports. One such report could be to map the location from where users connect to the CloudFlare PoPs. Figure 5 shows all 9 CloudFlare PoPs in the United States and the cities from which end-users connect to them, while accessing this blog. Figure 5: Geographic Reach of CloudFlare PoP for the US In this report we can see various users not being served by the closest Point of Presence, but one farther away. This is mostly caused by the way that the Internet works and especially by some ISPs not peering directly with content or CDN networks. Instead these ISP use Tier 1 network provider, which can cause these inefficiencies. Summary Google Analytics Custom dimension provide a simple way to visualize the great benefits of the global presence of your website, thanks to CloudFlare. Leverage it to see the benefits to your website, while using CloudFlare.

Read More...

TYPO3 with Cloudflare

Cloudflare is an ideal and free addition for anyone running a website. And while Typo3 doesn't work smoothly with Cloudflare out of the box, it is trivial to change this with a few small changes.

Read More...

SDDC Architecture – Core and POD design

This article is part of a series of articles, focusing on the architecture of an SDDC as well as some of its design elements. In this post we want to look at the physical layer of our SDDC architecture (See Figure 1).

Read More...

Software Defined Data Center (SDDC) Architecture – Introduction

A Software Defined Data Center (SDDC) is a vision for a new IT infrastructure that applies virtualization concepts such as abstraction, pooling, and automation to all resources of a data center. It promises to improve the delivery, operation, and recovery of Business Applications through increased agility and performance, while reducing service delivery times.

Read More...

Use a Cisco WLC based Wifi with the CloudTrax captive portal

The Cisco Wireless LAN Controller (WLC) solution provides 802.11 wireless networking solutions for enterprises and service providers via a combination of a central wireless LAN controllers and associated lightweight access points controlled by the controller, all concurrently managed by any or all of the operating system user interfaces. The solution simplifies deploying and managing large-scale wireless LANs by managing all data client, communications, and system administration functions, performing radio resource management (RRM) functions, managing system-wide mobility policies, and coordinating all security functions (See Figure 1). Figure 1: Simple Cisco WLC based network Despite these outstanding capabilities, Cisco’s WLC brings rather limited and complicated capabilities to the table when it comes to creating a simple captive portal for Wifi users, where authentication of valid customers is performed via voucher codes. Here Open-Mesh with it’s cloud-based CloudTrax controller offers a very simple and cost-effective solution to deploy a Wifi network – e.g. within a hotel, restaurant, college campus or other location – for users to authenticate via a Captive Portal for free, with a free or prepaid voucher or via PayPal payment (See Figure 2). Figure 2: Captive Portal provided by CloudTrax But if you already made a large financial and time investment into your Cisco WLC based Wifi network you do not necessarily want to rip and replace this network with an Open-Mesh network. Instead you might want to use the best of both worlds: The rock solid Cisco hardware with the easy to use CloudTrax captive portal. In this article I’ll show you how to do exactly this. Existing Cisco WLC network With Cisco WLC a service set identifier (SSID) is mapped to a VLAN within a port. As shown in Figure 3, each controller port connection is an 802.1Q trunk and should be configured as such on the neighbor switch. As an alternative you can also use the untagged VLAN within the WLC, thus not requiring a 802.1Q on the neighbor switch side. But in this case only a single SSID can be configured. As we want to provide a single public SSID with a CloudTrax backed captive portal, this setup would be sufficient. Figure 3: Ports, Interfaces, and WLANs in a Cisco WLC Open-Mesh physical setup The Cisco WLC does not directly support interacting with the CloudTrax-based Captive Portal. This capability is restricted to Open-Mesh based devices. In order to make a Cisco WLC based WiFi network work with CloudTrax, the solution is to place an Open-Mesh device – e.g. the OM2P – between the Cisco WLC based WiFi network an the internet (See Figure 4). Figure 4: Physical Open-Mesh setup Make sure to plug the internet uplink into the port closest to the power plug and the Cisco WLC to the other port. Also keep in mind that not all Open-Mesh devices come with a second ethernet port. The Open-Mesh OM2P does and is therefore the recommended device for this project. From the perspective of the Cisco WLC, the OM2P just acts like an upstream switch and from the perspective of the OM2P the Cisco WLC just appears to be a wired device. Keep in mind that the OM2P does not support an 802.1Q trunk towards the WLC. You therefore either have to use the native VLAN capability on the WLC when connecting it directly to the OM2P. Or you have to place a switch that does support an 802.1Q trunk between the WLC and the OM2P. In this case the VLAN from the 802.1Q trunk towards the WLC needs to be mapped to an access port towards the OM2P. CloudTrax Online Dashboard Configuration Please refer to the CloudTrax documentation at https://www.cloudtrax.com/ for the quick start guide and documentation on how to use the splash page. Below are the configuration items that need to be changed for CloudTrax to work with the WLC: Public SSID settings tab You don’t actually want to use the Open-Mesh device to provide any wireless capabilities. This should all be handled by the Cisco WLC-based network. Unfortunately it is not possible to turn off the wireless capabilities on an Open-Mesh device completely. Instead we will need to make some configuration changes to make the wireless network on the Open-Mesh device as inaccessible as possible. First, choose an SSID that does not correspond to the SSID that is configured in the Cisco WLC for the public accessible network and also hide this SSID (See Figure 5). Bottom-line: You don’t want clients to connect to the Open-Mesh device, but to the Cisco WLC network. Figure 5: CloudTrax Public SSID settings Private SSID settings tab Similar for the private SSID. You do not actually want to provide this network via the Open-Mesh device. Therefore turn it off completely. But also make sure that the “Wired Clients” tick box is not selected (See Figure 6). This way the Cisco WLC based network will be mapped to the public network in CloudTrax and can use the captive portal. Figure 6: CloudTrax Private SSID settings Radio settings tab Next reduce the transmit power of the Open-Mesh device to the minimum available (See Figure 7). This will reduce the likelihood that devices can connect to the Open-Mesh device over the wireless network. Instead they will connect over the Cisco WLC network. Figure 7: CloudTrax Radio settings You can also remove the antenna from the Open-Mesh device to further reduce the likelihood of a device connecting over the wireless interface to that device. But doing so will burn out the wireless chip of the Open-Mesh device over time. This approach is therefore not advisable if you plan on using this Open-Mesh device as a WiFi unit in the future. CloudTrax scripting Unfortunately we are not done yet at this point. We need to add a custom script on the Open-Mesh device, so that it can handle the static IP address of the WLC device. We also need to configure the WLC with such a static address for the network issued by the Open-Mesh device. First connect to the Open-Mesh device via SSH and lookup the IP address information used for the public SSID via the command “ifconfig br-pub”. The result should look like this: root@N3:~# ifconfig br-pub br-pub Link encap:Ethernet HWaddr AC:86:12:34:56:78 inet addr:10.255.48.1 Bcast:10.255.51.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2379186 errors:0 dropped:306 overruns:0 frame:0 TX packets:1812674 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:178505478 (170.2 MiB) TX bytes:2171022384 (2.0 GiB) root@N3:~# Note that in this case the public SSID network operated by Open-Mesh is 10.255.48.0 with a netmask of 255.255.252.0 and the Open-Mesh device itself will operate at 10.255.48.1. With these information we can now configure the Cisco WLC device to be at 10.255.48.2 (See Figure 8). Note that both the Gateway and the Primary DHCP Server are filled with the IP address of the Open-Mesh device. Figure 8: Cisco WLC Interface configuration Next create the file “/sbin/wlc” inside the Open-Mesh device with the following content. Replace the IP address 10.255.48.2 with the IP address that corresponds to the WLC in your setup. #!/bin/sh echo "Checking for WLC" ping -c3 10.255.48.2 > /dev/null 2>&1 || { ifconfig br-lan2 down ifconfig br-pub down brctl delif br-lan2 eth1 brctl addif br-pub eth1 ifconfig br-pub up ifconfig br-lan2 up } This script will test connectivity to the WLC and if this test fails, re-configure the network interfaces on the Open-Mesh device. This script should run regularly, as configuration changes pushed from CloudTrax can undo any changes. This can be accomplished by creating a symbolic link from /sbin/wlc to /etc/cron.5mins/wlc with the command “ln -s /sbin/wlc /etc/cron.5mins/wlc“. Check your results with: root@N3:~# ls -l /etc/cron.5mins/wlc lrwxrwxrwx 1 root root 9 Dec 29 22:41 /etc/cron.5mins/wlc -> /sbin/wlc root@N3:~# Results After a maximum of 5 minutes you should be able to connect to the Cisco WLC-provided SSID and receive an IP address on the above mentioned network. Upon opening a web browser and connecting to any web-page you will be displayed with the captive portal, where you can login via a free or prepaid voucher. The client device will connect to the lightweight Cisco access point that is managed via the WLC. When asking for an IPv4 address via DHCP, the WLC acts as a DHCP proxy with the Open-Mesh device being the actual DHCP server. Keep in mind that all Internet traffic from the Cisco WLC based WiFi network will now traverse through the Open-Mesh device. This means that a high number of parallel user sessions on the WiFi network can cause a high CPU utilization on the Open-Mesh device.

Read More...

Implementing IPv6: Six steps to success

Implementing IPv6 in your network does not require tearing down your aging IPv4 network and replacing it with a new IPv6-enabled network. Instead it is possible - and often wise - to run the IPv4 and IPv6 networks in parallel in what the industry calls a "dual-stack" network, thus adding IPv6 capabilities to your network's existing IPv4 capabilities. While such an endeavor is certainly not trivial, it might be easier than your think. The following article introduces a six step plan for implementing IPv6. It has served me well in past deployments and will hopefully give you some ideas and guidance.

Read More...

Protecting your website with DNS-Based Authentication of Named Entities (DANE)

DNS-based Authentication of Named Entities (DANE, RFC6698) allow X.509 certificates, commonly used for Transport Layer Security (TLS), to be bound to DNS names using Domain Name System Security Extensions (DNSSEC). DNSSEC assures users that the information they obtain from DNS - in this case the fingerprint of the X.509 certificate came from the correct source, was complete and its integrity was not compromised during the transfer.

Read More...

Handling the VMware vSphere 5.5 Active Directory integration error

While attempting to integrate the VMware vSphere 5.5 vCenter Server Appliance (vCSA) with Microsoft Active Directory you might have stumbled over the error message "Error: Idm client exception: Failed to establish server connection". This article will show you how to work around this issue and still use Active Directory with your vCSA.

Read More...

Jumbo Frames with VMware ESXi

Using Jumbo Frames with ESXi reduces CPU overhead and gives you much higher performance with 10 GigE. This article shows you how to enable Jumbo Frames with vSphere 5.1 or higher.

Read More...

Using F5 Big-IP LTM with IPv6

A very simple way to enable legacy IPv4-based web applications to be reachable via IPv6 is to use an IPv4/IPv6-enabled load balancer - such as the F5 Big-IP LTM - to frontend the application. This is e.g. the approach that Netflix took in mid 2012 to enable their service for IPv6 via the AWS Elastic Load Balancers (ELBs). In this post we will use the F5 Big-IP Local Traffic Manager (LTM) load balancer to provide this capability.

Read More...

Network troubleshooting via Arista EOS shell

Arista EOS is based on a Linux kernel and provides full and open access to a Linux shell, allowing installation and use of Linux based management and troubleshooting tools. In this short post I want to show you two use cases where this capability comes in extremely handy in the daily network management work.

Read More...

“Breaking” Amazon AWS S3

While working with Amazon AWS S3 it turned out, that it allows users to specify S3 bucket names in the "US Standard" regions that are not allowed like this in any other zone. As most libraries building on top of S3 assume the naming restrictions for all non-"US Standard" regions are also enforced in "US Standard", this breaks quite a bit of things.

Read More...

Arista vEOS on VMware ESX

EOS is released as a single image that supports all of their hardware platforms. But that same single image can also be run in a virtual machine! While a great article on "Building a Virtual Lab with Arista vEOS and VirtualBox" already exists, I wanted to accomplish the same with vSphere 5.x.

Read More...

Measuring Network Throughput

The topic of measuring network throughput between network devices comes up quite frequently: It ranges from users claiming (and often blaming) that the 100 Mbps Internet uplink in reality is only 10 Mbps or being surprised why they can't transfer that multi-gigabyte file via FTP faster between data center locations. Let's have a look behind the scenes of network throughput measurement and understand why users are actually measuring something completely different, but also how to get more "performance" out of these connections.

Read More...

Infoblox vNIOS HA pair VIP unreachable when deployed on vSphere

Yesterday I stumbled over an interesting networking problem while deploying an Infoblox vNIOS IPAM HA pair on a fresh installation of VMware vSphere: After setting up the vNIOS appliances to act as an HA pair, it’s floating virtual IP address was not reachable from the rest of the network. Yet, at the same time the individual IP addresses of the LAN interface were reachable.

Read More...