Tuesday, November 22, 2011

Packet capture


Why use sFlow for packet analysis? To rephrase the Heineken slogan, sFlow reaches the parts of the network that other technologies cannot reach. The sFlow standard is widely supported by switch vendors, embedding wire-speed packet monitoring throughout the network. With sFlow, any link or group of links can be remotely monitored. The alternative approach of physically attaching a probe to a SPAN/Mirror port is becoming much less feasible with increasing network sizes (10's of thousands of switch ports) and link speeds (10, 40 and 100 Gigabits). Using sFlow for packet capture doesn't replace traditional packet analysis, instead sFlow extends the capabilities of existing packet capture tools into the high speed switched network.

This article uses the tcpdump packet analyzer, readily available on most platforms, to demonstrate how to use sFlow to remotely capture and analyze network traffic.

The first step is to configure the network switches to monitor selected links and send sFlow to the host that will be used for packet analysis -  configuration instructions for most switch vendors are available on this blog. Alternatively, if sFlow is already being used for network-wide visibility then obtaining an sFlow feed can be as simple as directing the sFlow analyzer to forward sFlow to the packet analyzer.

Next, perform packet analysis on the host. The following command displays a packet trace, using sflowtool to extract packets from the sFlow feed and pipe them into tcpdump:

[root@xenvm4 ~]# sflowtool -t | tcpdump -r - -vv
reading from file -, link-type EN10MB (Ethernet)
10:30:01.000000 arp who-has 10.0.0.66 tell 10.0.0.220
10:30:07.000000 IP (tos 0x0, ttl  64, id 49952, offset 0, flags [DF], proto: TCP (6), length: 1500) xenserver1.sf.inmon.com.39120 > openfiler.sf.inmon.com.iscsi-target: . 2757963136:2757964584(1448) ack 4136690254 win 3050 
10:30:07.000000 IP (tos 0x0, ttl  64, id 49953, offset 0, flags [DF], proto: TCP (6), length: 1500) xenserver1.sf.inmon.com.39120 > openfiler.sf.inmon.com.iscsi-target: . 1448:2896(1448) ack 1 win 3050 
10:30:07.000000 IP (tos 0x0, ttl  64, id 49954, offset 0, flags [DF], proto: TCP (6), length: 1500) xenserver1.sf.inmon.com.39120 > openfiler.sf.inmon.com.iscsi-target: . 2896:4344(1448) ack 1 win 3050 

Note: Using sflowtool to convert sFlow into standard pcap format makes the sFlow data accessible to the wide variety of packet analysis applications that support the standard.

Next time you have to diagnose a network problem, rather than spending the night in the data center with a crash cart, stay at your desk and try out remote monitoring with sFlow. It may not be the solution to all problems, but it is surprising how many can be quickly resolved without leaving your desk.

4 comments:

  1. The problem is that BPF doesn't works when using it this way :/

    ReplyDelete
    Replies
    1. You can enter BPF filters, e.g.
      sflowtool -t | tcpdump -r - ip host 10.0.0.70

      Delete
  2. Hi all,

    One thing is not much clear for me. The sFlow protocol sends the payload of original packages? I mean, is possible use sFlow to identifify a malicious activity (like a vulnerable exploit)?
    Can i see all data of original packages (even be a sampling technologie).

    Best Regards

    ReplyDelete
    Replies
    1. The sFlow agent randomly samples packets and sends the first N bytes of the sampled packet (typically, 128 bytes). The sflowtool -t option extracts the packet headers from the sFlow feed and coverts them into pcap format so that they can be used with any pcap aware tool: tcpdump, wireshark, snort ...

      You can use this information to identify malicious activity, for example DNS amplification attacks and ICMP unreachable

      Delete