Saturday, August 8, 2009

Voice quality of service


Complaints were coming in about poor voice quality and dropped calls.

The challenge in managing VoIP (Voice over IP) deployments is that voice traffic can take a variety of paths across the network and problems anywhere along the path can affect call quality. In the diagram, the voice traffic is shown by the RTP (Real-time Transport Protocol) connections between the phones and computers.

Fortunately, the network switches support sFlow and the network management team had recently installed an sFlow analyzer (Traffic Sentinel), providing them with network-wide visibility. The sFlow analyzer alerted the team to excessive broadcast traffic affecting a large part of the network (see Link utilization to see how sFlow provides network-wide interface statistics). The packet header and packet path information provided by sFlow allowed the analyzer to rapidly locate the source of the broadcasts to a single server. A call to the server administrator identified the cause of the recent broadcast activity; they were testing a new application for distributing software on the network and the application was generating the broadcast traffic. Shutting down the application resolved the problem.

This example demonstrates how sFlow monitoring can assist in ensuring quality of service (QoS). Proactively managing traffic allows network managers to act before service levels deteriorate to the point where users are complaining. The paper, Managing Quality of Service Using sFlow, provides a detailed discussion of this approach.

Finally, the example illustrates the challenges created by network convergence and virtualization. Typically, different teams manage voice, data, computing and storage services using their own management tools. The example shows how the "siloed" approach to management fails as services converge to share the same network resources. As well as creating challenges, convergence offers the opportunity to dramatically simplify management. Instrumenting the converged network, by selecting network equipment with sFlow support, reduces the number of tools needed to provide visibility into each of these areas (voice, data, computing, storage) and delivers the shared visibility into the network infrastructure essential for avoiding conflicts.

Tuesday, July 28, 2009

Configuring Extreme switches

The following commands configure an Extreme Networks switch (10.0.0.246), sampling packets at 1-in-512, polling counters every 30 seconds and sending the sFlow to an analyzer (10.0.0.50) over UDP using the default sFlow port (6343):
enable sflow
configure sflow agent 10.0.0.246
configure sflow collector 10.0.0.50 port 6343
configure sflow sample-rate 512
configure sflow poll-interval 30
enable sflow backoff-threshold
configure sflow backoff-threshold 100
enable sflow ports all
A previous posting discussed the selection of sampling rates. Additional information can be found on the Extreme Networks web site.

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

Note: Extreme Networks switches support automatic backoff of sampling rates based on a settable samples-per-second threshold. This mechanism ensures that a poorly selected sampling rate will not generate excessive numbers of samples (see sFlow Version 5, section 4.2.2).

Wednesday, July 15, 2009

Configuring Force10 switches

The following commands configure a Force10 switch (10.0.0.245), sampling packets at 1-in-512, polling counters every 30 seconds and sending the sFlow to an analyzer (10.0.0.50) over UDP using the default sFlow port (6343):
config> sflow collector 10.0.0.50 agent-addr 10.0.0.245
config> sflow sample-rate 512
config> sflow polling 30
config> sflow enable
Then for each interface:
interface> sflow enable
You can also use the following command to list the configuration settings:

show sflow
A previous posting discussed the selection of sampling rates. Additional information can be found on the Force10 Networks web site.
See Trying out sFlow for suggestions on getting started with sFlow monitoring and reporting.

Wednesday, July 8, 2009

Configuring Brocade switches

The following configuration enables sFlow monitoring of all interfaces on a Brocade (formerly Foundry) FGS switch, sampling packets at 1-in-512, polling counters every 30 seconds and sending the sFlow to an analyzer (10.0.0.50) on UDP port 6343 (the default sFlow port):
fgs(config)# int e 0/1/1 to 0/1/24
fgs(config-mif-0/1/1-0/1/24)# sflow forwarding
fgs(config-mif-0/1/1-0/1/24)# exit
fgs(config)# sflow destination 10.0.0.50 6343
fgs(config)# sflow sample 512
fgs(config)# sflow polling-interval 30
fgs(config)# sflow enable
You can also use the following command to list the configuration settings:
fgs# show sflow
A previous posting discussed the selection of sampling rates. Additional information can be found on the Brocade web site.

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

Monday, July 6, 2009

Configuring Juniper switches

The following configuration enables sFlow monitoring of all interfaces on a Juniper EX3200 switch, sampling packets at 1-in-500, polling counters every 30 seconds and sending the sFlow to an analyzer (10.0.0.50) on UDP port 6343 (the default sFlow port).
protocols {
 sflow {
  polling-interval 30;
  sample-rate 500;
  collector 10.0.0.50 {
   udp-port 6343;
  }
  interfaces ge-0/0/0.0;
  interfaces ge-0/0/1.0;
  interfaces ge-0/0/2.0;
  interfaces ge-0/0/3.0;
  interfaces ge-0/0/4.0;
  interfaces ge-0/0/5.0;
  interfaces ge-0/0/6.0;
  interfaces ge-0/0/7.0;
  interfaces ge-0/0/8.0;
  interfaces ge-0/0/9.0;
  interfaces ge-0/0/10.0;
  interfaces ge-0/0/11.0;
  interfaces ge-0/0/12.0;
  interfaces ge-0/0/13.0;
  interfaces ge-0/0/14.0;
  interfaces ge-0/0/15.0;
  interfaces ge-0/0/16.0;
  interfaces ge-0/0/17.0;
  interfaces ge-0/0/18.0;
  interfaces ge-0/0/19.0;
  interfaces ge-0/0/20.0;
  interfaces ge-0/0/21.0;
  interfaces ge-0/0/22.0;
  interfaces ge-0/0/23.0;
 }
}
A previous posting discussed the selection of sampling rates. Additional information on configuring Juniper switches can be found on the Juniper Networks web site.

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

Friday, June 26, 2009

Sampling rates


A previous posting discussed the scalability and accuracy of packet sampling and the advantages of packet sampling for network-wide visibility.

Selecting a suitable packet sampling rate is an important part of configuring sFlow on a switch. The table gives suggested values that should work well for general traffic monitoring in most networks. However, if traffic levels are unusually high the sampling rate may be decreased (e.g. use 1 in 5000 instead of 1 in 2000 for 10Gb/s links).

Configure sFlow monitoring on all interfaces on the switch for full visibility. Packet sampling is implemented in hardware so all the interfaces can be monitored with very little overhead.

Finally, select a suitable counter polling interval so that link utilizations can be accurately tracked. Generally the polling interval should be set to export counters at least twice as often as the data will be reported (see Nyquist-Shannon sampling theory for an explanation). For example, to trend utilization with minute granularity, select a polling interval of between 20 and 30 seconds. Don't be concerned about setting relatively short polling intervals; counter polling with sFlow is very efficient, allowing more frequent polling with less overhead than is possible with SNMP.

Tuesday, June 23, 2009

sFlow MIB


Configuring switches through the switch command line interface (CLI) can be complex and time consuming, especially when monitoring needs to be configured on every switch in order to achieve network-wide visibility.

The sFlow MIB provides a way for an sFlow analysis application to use SNMP to automatically configure sFlow settings on the switches that it wants to monitor. Since the sFlow MIB is an optional part of the sFlow standard, not all sFlow capable switches can be configured using SNMP. However, HP ProCurve and Alcatel-Lucent switches support the sFlow MIB making it easy to quickly try out sFlow monitoring using the free sFlowTrend application. The screen capture above shows the sFlowTrend setting needed to enable SNMP configuration of sFlow.

Many traffic analyzers that claim sFlow support do not support the sFlow MIB. If you have switches that support the sFlow MIB, then selecting an analyzer that supports the sFlow MIB will ensure a successful deployment.

Future posts on this blog will describe the configuration commands needed to enable sFlow on additional vendor's switches.