Packet paths

Monitoring packet paths is an important component of sFlow monitoring. When a switch captures a packet header, it also captures the forwarding decision it made for the packet. The forwarding information includes the ingress and egress switch ports, VLANs and priorities, and if the packet is routed, subnet and next hop information is also provided. Additional information such as BGP AS path, MPLS tunnel and label stack will also be captured if it is relevant to the forwarding decision.

A traffic analyzer can thread together the path information from all the switches to provide a constantly updating network wide view of topology and the location of all hosts connected to the network.

The combination of packet header and packet forwarding data provides an integrated view of network traffic. For example, sFlow makes it possible to filter on forwarding attributes (VLAN , MPLS, route) and see traffic, or filter on traffic and identify forwarding paths. The integrated view of traffic makes it easy to answer questions such as: "Which links carry voice traffic?", "Is the voice traffic getting the correct priority value?" and "Who is sending traffic on a particular VLAN?"

Packet headers

There are a large number of protocols that can run over a switched network (the chart, from Agilent Technologies, shows the major protocol families). It is not reasonable to expect a layer 2 switch to be able to decode and report on all these protocols - the switch is there to forward packets and should only be concerned with the information it needs to make forwarding decisions. With sFlow, the switch simply forwards the Ethernet packet header and leaves it up to the traffic analyzer to decode the protocols.

This approach has a number of important advantages:

1. Capturing packet headers simplifies the monitoring task on the switch, making it easy to implement in hardware.
2. It is much easier to add new protocol decodes to a central traffic analyzer than it is to develop and deploy new switch firmware releases to add the new functionality. This is particularly true if you have a variety of switch models and vendors in your network.
3. Packet headers are well standardized, they have to be, or you wouldn't be able to interconnect switches. If packets are decoded on the switches there can be differences in the way switches from different vendors decode the packets and report on the data, making it difficult to combine data to provide a network-wide view.
4. Packet headers capture the complex layering (MAC, VLAN, MPLS, VPLS, IPv6 over IPv4 etc.) that is critical to understanding how traffic flows across the network.
   

In order to get the full benefit of sFlow monitoring, select an sFlow collector that decodes all the protocols that you use on your network.

Link utilization

One of the basic tasks in monitoring network traffic is to accurately track the utilization of links in your network. A managed switch will provide a standard set of counters for each interface that can be retrieved retrieved periodically using SNMP and used to trend link utilization, packet rates, errors and discards.

sFlow provides an alternative to SNMP counter polling. The sFlow agent in the switch will periodically send, or "push" its own counters to the central collector. Pushing counters is much more efficient than than retrieving them using SNMP, requiring 10-20 times fewer network packets to retrieve the same information. The sFlow protocol uses XDR to encode the counters. XDR is much simpler to encode and decode than the ASN1 encoding that the SNMP protocol uses, so the CPU load on the switches and the collectors is also significantly reduced. Finally, distributing the counter polling task among the switches further reduces the load on the central collector.

The benefits of using sFlow to retrieve interface statistics become clear when you monitor large networks. Instead of requiring 5-10 servers dedicated to SNMP polling, a single sFlow analyzer can collect counters from all the interfaces in the network, providing a centralized view of utilization throughout the network, rapidly identifying any areas of congestion.

Network-wide visibility

One of the unique features of sFlow is its ability to monitor entire networks, not just selected devices or links. When configuring sFlow monitoring, enable sFlow on every switch port on every switch in your network. sFlow is implemented in hardware so it can operate at line rate without impacting switch performance.

Don't just monitor WAN links and core switches, enabling sFlow on access switches gives detailed visibility into every server in the data center and every PC on the campus without the need to install software agents on the servers and PCs.

The scalability of sFlow extends to the traffic analyzer software. A single, well designed, sFlow analyzer should be able to monitor all the switch ports in the network. When choosing a traffic analyzer, count the total switch ports in your network and select software that will be able to monitor all the ports. A modest size campus network may have 20,000 switch ports and a large corporate network may have in excess of 100,000 switch ports. It is a good idea to request an evaluation and perform a full scale test to verify that the software delivers the required scalability.

Why an sFlow blog?

sFlow has been quietly emerging as the leading multi-vendor standard for monitoring traffic in switched networks. The first sFlow capable switches were shipped in 2001. Since then vendor support has been increasing each year and now switches from Brocade, Hewlett-Packard, Juniper Networks, Extreme Networks, 3Com, D-Link, Alcatel-Lucent, H3C, Hitachi, NEC, AlaxalA, Allied Telesis and Comtec have embedded sFlow. Chances are you already have switches in your network that support sFlow (for a complete list of switches that support sFlow, see Network Equipment).

sFlow monitoring solutions provide traffic visibility for the full range of switched networks, from an organization running a large, busy 10G network (see Amsterdam Internet Exchange) to a small office trying to see who is hogging bandwidth on their T1 link (see sFlowTrend).

Through the postings in this blog, we hope to increase awareness of sFlow and the way it can be used to solve problems that challenge network administrators every day.