Configuring Cisco switches

The following commands configure a Cisco switch (10.0.0.250), sampling packets at 1-in-5000, polling counters every 20 seconds and sending sFlow to an analyzer (10.0.0.50) over UDP using the default sFlow port (6343):

switch# configure terminal
switch(config)# feature sflow
switch(config)# sflow agent-ip 10.0.0.250
switch(config)# sflow sampling-rate 5000
switch(config)# sflow counter-poll-interval 20
switch(config)# sflow collector-ip 10.0.0.50 vrf default
switch(config)# sflow data-source interface ethernet 1/1
...
switch(config)# sflow data-source interface ethernet 1/24
switch(config)# copy running-config startup-config

A previous posting discussed the selection of sampling rates. Additional information can be found on the Cisco web site.

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

Configuring a ZTE switch

The following commands configure a ZTE switch (10.0.0.254) to sample packets at 1-in-1024, poll counters every 30 seconds and send sFlow to an analyzer (10.0.0.50) using the default sFlow port 6343:

sflow enable
sflow agent-config ipv4-address 10.0.0.254
sflow collector-config ipv4-address 10.0.0.50 6343

For each interface:

interface gei_1/1
sflow-sample-rate ingress 1024
sflow-sample-rate egress 1024
exit

A previous posting discussed the selection of sampling rates. Additional information can be found on the ZTE web site.

Note: For bi-directional sampling, the ingress and egress sampling rates must be set to the same value since sFlow doesn't support asymmetric sampling on an interface. Ingress only or egress only sampling is supported, so you can disable sampling in either direction. The ZTE documentation doesn't describe how to configure counter polling. Counter export is a required component of the sFlow protocol, so this is either an omission in documentation, or a defect that should be fixed in a future release.

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

Configuring Edge-Core switches

The following commands configure an Edge-Core switch to sample packets at 1-in-1024, poll counters every 30 seconds and send sFlow to an analyzer (10.0.0.50) using the default sFlow port 6343:

sflow receiver 1 10.0.0.50 port 6343

For each interface:

interface te1
sflow flow-sampling 1024 1
sflow counter-sampling 20 1

A previous posting discussed the selection of sampling rates. Additional information can be found on the Edge-Core web site.

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

Push vs Pull

Push-me-pull-you from Doctor Doolittle

There are two major performance monitoring architectures:

• Push, metrics are periodically sent by each monitored system to a central collector. Examples of push architectures include: sFlow, Ganglia, Graphite, collectd and StatsD.
• Pull, a central collector periodically requests metrics from each monitored system. Examples of pull architectures include: SNMP, JMX, WMI and libvirt.

The remainder of this article will explore some of the strengths and weaknesses of push and pull architectures:

	Push	Pull
Discovery	Agent automatically sends metrics as soon as it starts up, ensuring that it is immediately detected and continuously monitored. Speed of discovery is independent of number of agents.	Discovery requires collector to periodically sweep address space to find new agents. Speed of discovery depends on discovery sweep interval and size of address space.
Scalability	Polling task fully distributed among agents, resulting in linear scalability. Lightweight central collector listens for updates and stores measurements. Minimal work for agents to periodically send fixed set of measurements. Agents are stateless, exporting data as soon as it is generated.	Workload on central poller increases with the number of devices polled. Additional work on poller to generate requests and maintaining session state in order to match requests and responses. Additional work for agents to parse and process requests. Agents often required to maintain state so that metrics can be retrieved at a later time by the poller.
Security	Push agents are inherently secure against remote attacks since they do not listen for network connections.	Polling protocol can potentially open up system to remote access and denial of service attacks.
Operational Complexity	Minimal configuration required for agents: polling interval and address of collector. Firewalls need to be configured for unidirectional communication of measurements from agents to collector.	Poller needs to be configured with list of devices to poll, security credentials to access the devices and the set of measurements to retrieve. Firewalls need to be configured to allow bi-directional communication between poller and agents.
Latency	The low overhead and distributed nature of the push model permits measurement to be sent more frequently, allowing the management system to quickly react to changes. In addition, many push protocols, like sFlow, are implemented on top of UDP, providing non-blocking, low-latency transport of measurements.	The lack of scalability in polling typically means that measurements are retrieved less often, resulting in a delayed view of performance that makes the management system less responsive to changes. The two way communication involved in polling increases latency as connections are established and authenticated before measurements can be retrieved.
Flexibility	Relatively inflexible: pre-determined, fixed set of measurements are periodically exported.	Flexible: poller can ask for any metric at any time.

The push model is particularly attractive for large scale cloud environments where services and hosts are constantly being added, removed, started and stopped. Maintaining lists of devices to poll for statistics in these environments is challenging and the discovery, scalability, security, low-latency and the simplicity of the push model make it a clear winner.

The sFlow standard is particularly well suited to large scale monitoring of cloud infrastructures, delivering the comprehensive visibility into the performance of network, compute and application resources needed for effective management and control.

In practice, a hybrid approach provides the best overall solution. The core set of standard metrics needed to manage performance and detect problems is pushed using sFlow and a pull protocol is used to retrieve diagnostic information from specific devices when a problem is detected.

Configuring Huawei switches

The following commands configure a Huawei switch (10.0.0.254) to sample packets at 1-in-1024, poll counters every 30 seconds and send sFlow to an analyzer (10.0.0.50) using the default sFlow port 6343:

system-view
sflow collector 1 ip 10.0.0.50 port 6343
sflow agent ip 10.0.0.254

For each interface:

system-view
interface gigabitethernet 1/0/2
sflow flow-sampling collector 1
sflow flow-sampling rate 1024
sflow counter-sampling collector 1
sflow counter-sampling interval 30

A previous posting discussed the selection of sampling rates. Additional information can be found on the Huawei web site.

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

Configuring F5 BIG-IP

The latest TMOS 11.2.0 release includes an initial, partial (counters only), implementation of sFlow. The following steps enable export of interface counters and CPU/memory statistics:

1. On the Main tab, click System > Performance > sFlow. The sFlow screen opens.
2. Click Add. The New sFlow Receiver screen opens.
3. In the Name field, type a name for the sFlow receiver.
4. In the Address field, type the IPv4 or IPv6 address on which the sFlow receiver listens for UDP datagrams.
5. Click Finished.

The article, Link utilization, describes some of the benefits of using sFlow to export performance counters. Fully implemented, sFlow delivers detailed visibility into L2-7 traffic. Additional information can be found on the F5 web site.

June 11, 2013 Update: TMOS 11.4.0 now includes comprehensive L2-7 support for sFlow, from packet sampling and interface counters to application response times, URLs and status codes. 

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

Configuring Pica8 Pronto switches

The following commands configure a Pica8 Pronto series switch to sample packets at 1-in-1024, poll counters every thirty seconds and send sFlow to an analyzer (10.0.0.50) over UDP using the default sFlow port (6343):

XorPlus# set open-flow sflow sflow-1 address 10.0.0.50
XorPlus# set open-flow sflow sflow-1 port 6343
XorPlus# set open-flow sflow sflow-1 polling-interval 30
XorPlus# set open-flow sflow sflow-1 sampling-rate 1024
XorPlus# set open-flow sflow sflow-1 interface ge-1/1/1 
... 
XorPlus# set open-flow sflow sflow-1 interface ge-1/1/24
XorPlus# commit

A previous posting discussed the selection of sampling rates. Additional information can be found on the Pica8 web site.

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