Saturday, February 27, 2016

Open vSwitch version 2.5 released

The recent Open vSwitch version 2.5 release includes significant network virtualization enhancements:
   - sFlow agent now reports tunnel and MPLS structures.
   ...
   - Add experimental version of OVN.  OVN, the Open Virtual Network, is a
     system to support virtual network abstraction.  OVN complements the
     existing capabilities of OVS to add native support for virtual network
     abstractions, such as virtual L2 and L3 overlays and security groups.
The sFlow Tunnel Structures specification enhances visibility into network virtualization by capturing encapsulation / decapsulation actions performed by tunnel end points. In many network virtualization implementations VXLAN, GRE, Geneve tunnels are terminate in Open vSwitch and so the new feature has broad application.

The second related feature is the inclusion of the Open Virtual Network (OVN), providing a simple method of building virtual networks for OpenStack and Docker.

The following articles provide additional background:

Friday, February 26, 2016

Linux bridge, macvlan, ipvlan, adapters

The open source Host sFlow project added a feature to efficiently monitor traffic on Linux host network interfaces: network adapters, Linux bridge, macvlan, ipvlan, etc. Implementation of high performance sFlow traffic monitoring is made possible by the inclusion of random packet sampling support in the Berkeley Packet Filter (BPF) implementation in recent Linux kernels (3.19 or later).

In addition to the new BPF capability, hsflowd has a couple of other ways to monitor traffic:
  • iptables, add a statistic rule to the iptables firewall to add traffic monitoring
  • Open vSwitch, has built-in sFlow instrumentation that can be configured by hsflowd.
The BPF sampling mechanism is less complex to configure than iptables and can be used to monitor any Linux network device, including: network adapters (e.g. eth0) and the Linux bridge (e.g. docker0). Monitoring a network adapter also provides visibility into lightweight macvlan and ipvlan network virtualization technologies that are likely to become more prevalent in the Linux container ecosystem, see Using Docker with macvlan Interfaces.

The following commands build and install hsflowd on an Ubuntu 14.03 host:
sudo apt-get update
sudo apt-get install build-essential
sudo apt-get install libpcap-dev
sudo apt-get install git
git clone https://github.com/sflow/host-sflow
cd host-sflow
make
sudo make install
Installing Host sFlow on a Linux server provides basic instructions for configuring the Host sFlow agent (hsflowd). To monitor traffic on the host, edit the /etc/hsflowd.conf file configure the sFlow collector and enable packet sampling on eth0
pcap { dev = eth0 }
Now start the daemon:
sudo hsflowd start
At this point packet traversing eth0 will be sampled and sent out as part of the standard sFlow telemetry stream sent to an sFlow analyzer. For example, using sFlow-RT with the top-flows application as the sFlow analyzer generated the top flows table below.
There a numerous server monitoring agents available in the open source community that will export similar host statistics (CPU, memory, disk) to the Host sFlow agent. Host sFlow differs by also including network traffic visibility using the same packet sampling mechanism supported by most data center switches. Significant advances are extending the visibility into the physical network, for example, Broadcom BroadView Instrumentation tracks buffer utilization and microbursts that effect application performance.
A common standard for monitoring physical and virtual network and server infrastructure reduces operational complexity. Visibility into network activity is critical to understanding the performance of scale out applications that drive large amounts of East-West traffic. Host sFlow, along with support for sFlow in the physical network, delivers scaleable data center wide telemetry to SDN and DevOps tools so that they can better orchestrate the allocation of resources to maximize performance and reduce costs.

Sunday, February 21, 2016

CloudFlare DDoS Mitigation Pipeline

The Usenix Enigma 2016 talk from Marek Majkowski describes CloudFlare's automated DDoS mitigation solution. CloudFlare provides reverse proxy services for millions of web sites and their customers are frequently targets of DDoS attacks. The talk is well worth watching in its entirety to learn about their experiences.
Network switches stream standard sFlow data to CloudFlare's "Gatebot" Reactive Automation component, which analyzes the data to identify attack vectors. Berkeley Packet Filter (BPF) rules are constructed to target specific attacks and apply customer specific mitigation policies. The rules are automatically installed in iptables firewalls on the CloudFlare servers.
The chart shows that over a three month period CloudFlare's mitigation system handled between 30 and 300 attacks per day.
Attack volumes mitigated regularly hit 100 million packers per second and reach peaks of over 150 million packets per second. These large attacks can cause significant damage and automated mitigation is critical to reducing their impact.

Elements of the CloudFlare solution are readily accessible to anyone interested in building DDoS mitigation solutions. Industry standard sFlow instrumentation is widely supported by switch vendors. Download sFlow-RT analytics software and combine real-time DDoS detection with business policies to automate mitigation actions. A number of DDoS mitigation examples are described on this blog that provide useful starting point for implementing an automated DDoS mitigation solution.

Monday, February 1, 2016

SignalFx

SignalFx is an example of a cloud based analytics service. SignalFx provides a REST API for uploading metrics and a web portal that it simple to combine and trend data and build and share dashboards.

This article describes a proof of concept demonstrating how SignalFx's cloud service can be used to cost effectively monitor large scale cloud infrastructure by leveraging standard sFlow instrumentation. SignalFx offers a free 14 day trial, making it easy to evaluate solutions based on this demonstration.

The diagram shows the measurement pipeline. Standard sFlow measurements from hosts, hypervisors, virtual machines, containers, load balancers, web servers and network switches stream to the sFlow-RT real-time analytics engine. Metrics are pushed from sFlow-RT to SignalFx using the REST API.

Over 40 vendors implement the sFlow standard and compatible products are listed on sFlow.org. The open source Host sFlow agent exports standard sFlow metrics from hosts, virtual machines and containers and local services. For additional background, the Velocity conference talk provides an introduction to sFlow and case study from a large social networking site.

SignalFx's service is priced based on the number of data points that they need to store and they estimate a cost of $15 per host per month to record comprehensive host statistics at 10 second granularity. Collecting metrics from a cluster of 1,000 hosts would cost as much as $15,000 per month.
There are important scaleability and cost advantages to placing the sFlow-RT analytics engine in front of the metrics collection service. For example, in large scale cloud environments the metrics for each member of a dynamic pool isn't necessarily worth trending since virtual machines are frequently added and removed. Instead, sFlow-RT tracks all the members of the pool, calculates summary statistics for the pool, and logs the summary statistics. This pre-processing can significantly reduce storage requirements, reducing costs and increasing query performance. The sFlow-RT analytics software also calculates traffic flow metrics, hot/missed Memcache keys, top URLs, exports events via syslog to Splunk, Logstash etc. and provides access to detailed metrics through its REST API.
The following steps were involved in setting up the proof of concept.

First register for free trial at SignalFx.com.

Download and install sFlow-RT.

Create a signalfx.js script in the sFlow-RT home directory with the following lines (use the token from your SignalFx account):
var url = "https://ingest.signalfx.com/v2/datapoint";
var token = "YOUR_APP_API_TOKEN";

setIntervalHandler(function() {
  var metrics = ['min:load_one','q1:load_one','med:load_one',
                 'q3:load_one','max:load_one'];
  var vals = metric('ALL',metrics,{os_name:['linux']});
  var gauges = [];
  for each (var val in vals) {
     gauges.push({
       metric: val.metricName.replace(/[^a-zA-Z0-9_]/g,"_"),
       dimensions:{cluster:"Linux"},
       value: val.metricValue
     });
  }
  var body = {"gauge":gauges};
  var req = {
    url:url,
    operation:'post',
    headers: {
      'Content-Type':'application/json',
      'X-SF-TOKEN':token
    },
    body: JSON.stringify(body)
  };
  try { http2(req); }
  catch(e) { logWarning("metric upload failed " + e); }
} , 10); 
Add the following sFlow-RT configuration entry to load the script:
script.file=signalfx.js
Now start sFlow-RT. Cluster performance metrics describes the summary metrics that sFlow-RT can calculate. In this case, the load average minimum, maximum, and quartiles for the cluster are being calculated and pushed to SignalFx every minute.

Install Host sFlow agents on the physical or virtual machines in your cluster and direct them to send metrics to the sFlow-RT host. The installation steps can be easily automated using orchestration tools like Puppet, Chef, Ansible, etc.

Physical and virtual switches in the cluster can be configured to send sFlow to sFlow-RT in order to add traffic metrics to the mix, exporting metrics that characterizing traffic between service tiers etc. However, in public cloud environments, traffic flow information is typically not available. The articles, Amazon Elastic Compute Cloud (EC2) and Rackspace cloudservers describe how Host sFlow agents can be configured to monitor traffic between virtual machines in the cloud.
Metrics should start appearing in SignalFx as soon as the Host sFlow agents are started.

In this example, sFlow-RT is exporting 5 metrics to summarize the cluster performance, reducing the total monthly cost of monitoring the 1,000 host cluster to less than $15 per month. Of course there are likely to be more metrics that you will want to track, but the ability to selectively log high value metrics provides a way to control costs and maximize benefits.

If you are managing physical infrastructure then sFlow provides a simple way to incorporate network telemetry. For example, add the following metrics to the script to summarize network health:
  • max:ifinutilization
  • max:ifoututilization
  • sum:ifindiscards
  • sum:ifinerrors
  • sum:ifoutdiscards
  • sum:ifouterrors
A network connecting 1,000 physical hosts would have considerably more than 1,000 switch ports and summarizing the per port statistics greatly reduces the cost of monitoring the network. For a catalog of network, host, and application metrics, see Metrics.

Friday, January 22, 2016

Dell OS10 SDN router demo


In this video from Dell's Network Field Day 11 (#NFD11) presentation,  Madhu Santhanam demonstrates an interesting use case for the new OS10 switch operating system that was introduced at the event.
The core of OS10 is an unmodified Linux kernel with an application development environment for Control Plane Services (CPS). These APIs allow software running on the switch: native linux applications, third party applications, and native OS10 applications to run on the core OS10 operating system.
The FIB Optimization application consists of three components: an sFlow agent to provide network visibility, Quagga for BGP routing, and the Selective Route Push agent which provides a REST API for selectively populating the hardware routing tables in the switch ASIC. The FIB Optimization application allows an inexpensive data center switch to replace a much more expensive high capacity Internet router.
In this use case, the data center is connected to a single transit provider and multiple additional peer networks. Initially all traffic is sent via a default route to the transit provider. The full Internet routing table consists of nearly 600,000 prefixes - far too many to fit in the switch hardware forwarding tables which in typical low cost switches can only handle 20,000 - 30,000 routes.

However, for any given site, only a small number the advertised prefixes are destinations for traffic. The challenge is to identify the most active prefixes so that they can be selectively installed in hardware tables. In this demonstration sFlow-RT is used to process the industry standard sFlow telemetry exported by the sFlow agent on the switch and compute the top N active prefixes. Every minute active prefixes installed and inactive prefixes are removed from the hardware using the Selective Route Push REST API.
In the demo, an IXIA traffic generator simulates a mixture of traffic to 1 peer and to other prefixes handled by the transit provides. Initially, all traffic is sent to the transit provider, but after a minute 76% of the traffic is being directed to the peer, and after two minutes over 90% of the traffic is being directed to the peer. As traffic patterns change, prefixes are automatically added and removed from the hardware forwarding table.

Analytics driven SDN is poised to disrupt the router market, replacing expensive, custom hardware with commodity switches. Solutions like the one Dell presented are already in production. Last year, David Barroso gave a talk showing that 99% of Spotify’s Internet traffic was contained in only 20,000 prefixes and started the  SDN Internet Router project which similarly combines BGP routing information with sFlow telemetry, but only updates the active routes every hour. In the Dell demo, updates occur every minute. The speed of response can be increased even further, the sFlow-RT Active Route Manager application detects and updates active routes within a second. Speed is important since the faster the application can react to changing traffic, the more effectively the hardware forwarding, opening up additional use cases for SDN routing.

Thursday, January 21, 2016

Podcast with Nick Buraglio and Brent Salisbury

"Have you seen sFlow options in your router configuration or flow collector? Are you looking for alternatives to SNMP or NetFlow? Have you been curious about the instrumentation of your new white box or virtual switch? Yes? Then you will probably enjoy learning more about sFlow!"

Non-Blocking #1: SFlow With Peter Phaal Of InMon And SFlow.Org is a discussion between Brent Salisbury (networkstatic.net), Nick Buraglio (forwardingplane.net), and Peter Phaal (blog.sflow.com).

Web sites and tools mentioned in the podcast:
  1. sFlow.org
  2. Devices that support sFlow
  3. Software to analyze sFlow
  4. sFlow.org mailing list
  5. sFlow structures
  6. blog.sflow.com (incorrectly referenced as blog.sflow.org in the podcast)
  7. Host sFlow
  8. sflowtool

The podcast touches on a number of topics that have been explored in greater detail on this blog. The topics are listed in roughly the order they are mentioned in the podcast:
  1. Widespread support for sFlow among switch vendors
  2. Disaggregated flow cache
  3. ULOG
  4. Push vs Pull
  5. sFlow vs SNMP for interface counters
  6. Broadcom ASIC table utilization metrics, DevOps, and SDN
  7. Broadcom BroadView Instrumentation
  8. Rapidly detecting large flows, sFlow vs. NetFlow/IPFIX
  9. SDN and large flows
  10. Probes
  11. Packet headers
  12. Network virtualization visibility demo
  13. History of sFlow
  14. Standards
  15. Open vSwitch performance monitoring
  16. Wireless
  17. Prescriptive vs descriptive standards (sFlow / IPFIX)
  18. RMON (4 groups)
  19. Observability
  20. Host sFlow distributed agent
  21. Host sFlow data model
  22. Multi-tenant traffic in virtualized network environments
  23. Workload placement
  24. SDN router using merchant silicon top of rack switch
  25. White box Internet router PoC
  26. Active Route Manager
  27. Leaf and spine traffic engineering using segment routing and SDN
  28. CORD: Open-source spine-leaf Fabric (demo from 2015 Open Networking Summit)
  29. sflowtool
  30. sflowtool for packet caputure
  31. sflowtool with Wireshark

Monday, January 18, 2016

Demystifying NFV Infrastructure Hotspots

Slides from the recent Dell NFV Summit 2015 are now available. Steve Wright's 7 Fallacies of NFV talk describes the importance of managing network resources in an NFV stack. The diagram above shows the complex network data paths that result from NFV as packets flow between virtual functions across physical and virtual switches.
The presentation describes how the Fallacies of Distributes Computing apply to NFV, highlighting the importance of effective management of network resources for effective NFV deployment.

Another paper, Demystifying NFV Infrastructure Hotspots by Ramki Krishnan, Anoop Ghanwani, and Michael Tien, demonstrates how industry standard sFlow instrumentation build into physical and virtual switches can provide the comprehensive real-time analytics needed to manage NFV deployments.
The vIMS (virtualized IP Multimedia Subsystem) is used as an example. The diagram below shows the functional elements of the logical architecture deployed on the hardware testbed shown above.
sFlow telemetry from the physical switches in the leaf and spine network, virtual switch instances, and hypervisors is streamed to an instance of the sFlow-RT analytics platform.
The dashboard application running on sFlow-RT demonstrates visibility into the traffic flows between virtual network functions.
The final set of charts in the dashboard shows the multi-media traffic flows running across the infrastructure. All elements are monitored and any hotspots are rapidly identified so that corrective actions can be automatically applied by the orchestration system.