0

sFlow leads convergence of multi-vendor application, server, and network performance management

Over the last six months, leading Application Delivery Controller (ADC) vendors F5 and A10 have added support for the sFlow standard to their respective TMOS and ACOS operating systems, making multi-vendor, real-time application layer visibility available in approximately 50% of commercial ADC market.

Figure 1: Best of Velocity 2012, The sFlow Standard

Equally important is the availability of sFlow support in leading open source web servers, load balancers, applications servers, hypervisors and operating systems, including: Apache, NGINX, Tomcat, Java, HAproxy, Hyper-V, Xen, KVM, Linux, Windows, Solaris, FreeBSD and AIX. The combination sFlow in ADCs and the application infrastructure behind them provides comprehensive end to end visibility in multi-tier, scale-out, application architectures.

Figure 1 shows the strategic role that ADCs (load balancers) play in controlling the flow of application requests, regulating admission, filtering, directing loads, and virtualizing services. RESTful control of ADCs combined with real-time visibility provides a powerful capability for flexing resources as demand changes, reducing costs and increasing performance as resources are closely matched to workloads.

What is unusual about diagram is the inclusion of the network. Application architects often give little thought to the network since its complexity is conveniently hidden behind APIs. Unfortunately, it is in the Continue reading

0

Physical switch hybrid OpenFlow example

Alcatel-Lucent OmniSwitch analytics driven control provided an example with a physical switch, using the Web Services API to send CLI controls to the switch as HTTP requests, the following screen shot shows the results:

Figure 1: Controller using HTTP / REST API

Integrated hybrid OpenFlow describes how the combination of normal forwarding combined with OpenFlow for control of large flows provides a scaleable and practical solution for traffic engineering. The article used the Mininet testbed to develop a DDoS mitigation controller consisting of the sFlow-RT real-time analytics engine to detect large flows and the Floodlight OpenFlow controller to push control rules to the software virtual switch in the testbed.

Figure 2: Performance aware software defined networking

The OmniSwitch supports hybrid mode OpenFlow and this article will evaluate the performance of a physical switch hybrid OpenFlow solution using the OmniSwitch. The following results were obtained when repeating the DDoS attack test using Floodlight and OpenFlow as the control mechanism:

Figure 3: OmniSwitch controller using hybrid OpenFlow

Figure 3 shows that implementing traffic controls using OpenFlow is considerably faster than those obtained using the HTTP API shown in Figure 1, cutting the time to implement controls from seconds to milliseconds.

Figure Continue reading

0

Alcatel-Lucent OmniSwitch analytics driven control

There are a many articles on this blog that demonstrate how real-time sFlow analytics driven control of switches using a Mininet testbed. This article is the first of a series that will shift the focus to physical switches and demonstrate different techniques for adapting network behavior to changing traffic.

Performance Aware SDN describes the theory behind analytics driven orchestration. The talk describes how fast controller response, programmatic configuration interfaces and consistent instrumentation of all the elements being orchestrated are pre-requisites for feedback control.

This article uses an Alcatel-Lucent OmniSwitch 6900 as an example. The switch has hardware sFlow support for line rate visibility on all ports, and support for OpenFlow and a RESTful configuration API to deploy control actions. In this example a basic DDoS mitigation filtering function will be triggered when large flood attacks are detected. The script is based on the version described in the article Integrated hybrid OpenFlow, but modified to use the OmniSwitch RESTful API.
RESTful control of switches describes how RESTFul configuration access to switches can be used to develop simple, controller-less SDN solutions. In this example the controller application is implemented using JavaScript that runs within the sFlow-RT analytics engine. The script has Continue reading

0

Configuring Alcatel-Lucent switches

The following configuration enables sFlow monitoring of all interfaces on an Alcatel-Lucent OmniSwitch switch (10.0.0.235), sampling packets at 1-in-512, polling counters every 30 seconds and sending the sFlow to an analyzer (10.0.0.1) on UDP port 6343 (the default sFlow port):

sflow agent ip 10.0.0.235
sflow receiver 1 name InMon address 10.0.0.1 udp-port 6343
sflow sampler 1 port 1/1-20 receiver 1 rate 512
sflow poller 1 port 1/1-20 receiver 1 interval 30

The switches also support the sFlow MIB for configuration.

See Trying out sFlow for suggestions on getting started with sFlow monitoring and reporting.

0

OpenDaylight

This article looks takes the DDoS example and repeats it using the OpenDaylight controller.

First install Open Daylight in the Mininet testbed.

$ wget https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/opendaylight/distribution/opendaylight/target/distribution.opendaylight-osgipackage.zip
unzip distribution.opendaylight-osgipackage.zip

Next start Mininet.

sudo mn --topo single,3 --controller=remote,ip=127.0.0.1

Enable sFlow on the switch:

sudo ovs-vsctl -- --id=@sflow create sflow agent=eth0  target="127.0.0.1:6343" sampling=10 polling=20 -- -- set bridge s1 sflow=@sflow

Start OpenDaylight.

cd opendaylight
./run.sh

Confirm that the controller is running and has discovered the switch by connecting a browser to port 8080 on the testbed - the screen shot at the start of the article shows the OpenDaylight Devices tab with the switch 00:00:00:00:00:00:00:01 shown in the Nodes Learned list and in the map (the default credentials to log into the OpenDaylight interface are User:admin, Password:admin).

The following sFlow-RT script modified the original to use the OpenDaylight Flow Programmer REST API to push OpenFlow rules to the switch.

include('extras/json2.js');

var flowkeys = 'ipsource';
var value = 'frames';
var filter = 'outputifindex!=discard&direction=ingress&sourcegroup=external';
var threshold = 1000;
var groups = {'external':['0.0.0.0/0'],'internal':['10.0.0.2/32']};

var metricName = 'ddos';
var controls = {};
var enabled = true;
var  Continue reading

0

Centec V330: My Kind of OpenFlow Switch

This is my third and probably last installment of an ongoing story about our quest for OpenFlow 1.0 capable switches with a specific requirement - the capability to modify L3 destination addresses. The background of why Sakura Internet needs such switches for the purpose of DDoS attack mitigation is explained in my first article, along with […]

Author information

The post Centec V330: My Kind of OpenFlow Switch appeared first on Packet Pushers Podcast and was written by Tamihiro Yuzawa.

0

Wanted: OpenFlow Switch With ofp_action To Modify The Destination L3 Address

This article is meant to serve in part as an appendix to my previous post on PacketPushers.net. Therefore, please take a moment to read this introduction of Sakura Internet’s DDoS detection and mitigation app if you haven’t already. At Sakura, we are in the process of implementing source-and-destination-based DDoS packet filtering that should be effective and […]

Author information

The post Wanted: OpenFlow Switch With ofp_action To Modify The Destination L3 Address appeared first on Packet Pushers Podcast and was written by Tamihiro Yuzawa.

0

OpenFlow 1.0 Actual Use-Case: RTBH of DDoS Traffic While Keeping the Target Online

Sakura Internet operates several data centers across Japan, including this one, and my team is in charge of building and taking care of our IP backbones. In this article, I will introduce the ongoing process of upgrading our DDoS mitigation solution, which happens to be a down-to-earth, if not widely applicable, use case for OpenFlow. […]

Author information

The post OpenFlow 1.0 Actual Use-Case: RTBH of DDoS Traffic While Keeping the Target Online appeared first on Packet Pushers Podcast and was written by Tamihiro Yuzawa.

0

IPv6 and flows (using nfsen)

This will be about already having nfsen/nfdump configured, and are looking to just make a flow profile to graph IPv6 traffic from your routers. If you are looking to get nfsen iniitially configured, definitely follow their instructions on their site.

Say you have an sFlow capable router like…picking one totally not at random…..a Brocade XMR or MLX(e), and you want some basic flow data, especially IPv6. Depending on how many routers you are going to collect flow data from, will determine how beefy of a machine you will need. I know that at $lastjob, it was a hefty CPU (and definitely more than 1), tons of RAM, and hardware RAID. Right now, I’m using dual quad-core Xeon, tons of RAM and a small hardware RAID, but this machine serves many purposes. Right now I’m also only polling 4 MLX routers.

Go ahead and access your nfsen website, and on the Profiles pulldown, select “New Profile …”. In the creation dialog, give the profile whatever title you like; I went with the generic title of “IPv6″. If you want to add it to a group or make one for it, do as you please. I left that alone so I’d Continue reading