38.107.179.23138.107.179.231 Rich Brown - Network Management Expert and CEO of Dartware, Creator of InterMapper
InterMapper.comiMapper Community 
 
Rich Brown - Network Management Expert and CEO of Dartware, Creator of InterMapper

Rich Brown, President and Co-founder, Dartware, LLC

Prior to founding Dartware, Rich was Manager of Special Projects at Dartmouth College where he developed software to detect, diagnose, and visualize network problems. He and Bill Fisher authored InterMapper, an internal project that was quickly recognized for its commercial potential. Rich earned a Bachelors of Science in Electrical Engineering from Lehigh University and a Master of Science in Engineering from the University of Pennsylvania. He is a member of IEEE and ACM.



Using a Managed Switch as a Network "Tap"

You can use a managed switch as a tap into your network, and let it send packets to a NetFlow or sFlow exporter, which can, in turn, send flow records to a NetFlow or sFlow collector such as InterMapper Flows. (You might want to do this if your switches or routers don't support NetFlow or sFlow natively.)

The trick is that the switch must support "port mirroring" or a "SPAN port" (http://en.wikipedia.org/wiki/SPAN_port). The switch sends copies of packets flowing to/from one port or set of ports to a separate "span" or "mirror" port on the switch, and then to the Flow collector.

Dartware decided to evaluate the Cisco/Linksys SLM2005 Small Business Smart Switch based on a mention in Network World. This inexpensive switch (about $100) supports 10, 100, and Gigabit connections on its five ports. It also supports VLANs, 802.1X port authentication, Power over Ethernet, and more. The only downside that I saw with this switch is that it doesn't support SNMP.

The Web GUI allows you to enable port mirroring (Admin > Port Mirroring) so that the single Target port receives copies of all the packets sent to and from the Source port. 

As shown in the image below, we connected the SLM2005 between our external router/firewall and the backbone switch. (The screen shot is actually taken from an InterMapper map showing our production network.) We then connected the Target port of the switch to a NetFlow exporter (we used the nProbe software from ntop.org). This was configured to send the flow records into InterMapper Flows.

 Using a switch as a network tap

Update:

Uli Hertweck from System.de (one of Dartware's resellers in Germany) wrote to me with an excellent response to my earlier posting. His major points:

  • In my initial description of the system, I had left out the presence of a NetFlow exporter. The image above shows the actual interconnections. 
  • Uli also pointed out that any additional equipment introduces a possible point of failure. In this particular application, if the switch-as-network-tap fails, then the entire network stops. The Linksys SLM2005 introduces two kinds of failure possibilities:
    • Point of Attack: its web agent doesn't allow HTTPS, and it's unknown how much penetration testing the web interface has endured.
    • Point of Failure: It only has a single power supply that is easily stripped off, especially since it cannot be rack-mounted.
  • A better choice might be the Linksys SRW208. It's a bit more expensive ($150), supports essentially the same features as the cheaper SLM2005, but offers these capabilities:
    • It is SNMP managed, so InterMapper can see and monitor traffic on all ports.
    • It can be configured through HTTPS and SSH, and you can turn off the HTTPS agent if desired.
    • However, its external AC power adapter that is still prone to disconnection.
  • Uli points out that it is mandatory in a serious production environment to use a span port on the backbone switch. This eliminates the tap as a point of failure.
  • The best alternative of all (if your equipment supports it) is to use flow-capable routers and switches. They send the flow data directly to your collector, eliminating the need for a network tap, a span/mirror port, and the flow exporter. We have done this with our backbone HP Procurve switch. It exports sFlow records to our InterMapper Flows collector, as shown in the image above
 
What if I don't have Cisco/NetFlow-compatible Equipment?
Not all routers and switches support NetFlow. For example, only certain models of Cisco equipment provide NetFlow data; many other manufacturer's gear will not export NetFlow records, either. If you use non-NetFlow capable equipment, there are a few alternatives/workarounds:
  • Use a software exporter on a span or mirror port of a switch. If you have a managed switch, you can usually configure it to send all the traffic to a single span or mirror port. You can then install a software exporter on a computer and attach it to the span port. The software exporter will then send flow records to your NetFlow collector (such as InterMapper Flows).
  • Use a software exporter attached to a hub port. If you don't have a managed switch, you can still monitor NetFlow data by placing an unmanaged hub (not a switch) in the link whose traffic you want to monitor. For example, you might install the hub between your external router and your backbone equipment. The hub will pass all the traffic that flows through the link to the software exporter, as described above.
  • Use sFlow. Many prominent router and switch manufacturers (such as HP, Foundry, Extreme, Force10, and others) instead support the sFlow (sampled flow) protocol (link). Their equipment sends a copy of the header of one-in-N packets to an sFlow collector, which then performs much the same processing as a NetFlow collector. Watch this blog for information about an upcoming release of InterMapper Flows that handles sFlow.
 
Why NetFlow is Better than tcpdump

Tcpdump, and its graphical kin "sniffer" programs (such as Wireshark, OmniPeek, Ethereal, etc.), can give very deep view into the network traffic, showing the details of every packet. These tools are essential for debugging low-level interactions between devices.

Although it would be possible (but laborious) to sum up the traffic from each packet in a tcpdump. NetFlow systems automatically collect this information and display it.

Another concern is that a packet-sniffing tool such as tcpdump typically must be attached to the same network that you are monitoring. To view traffic on a remote network, you would have to install the tcpdump on a machine connected there, and contrive to have its results passed to your central location. With NetFlow, on the other hand, the router/switch involved in handling the data also collects and exports the flow records to the central NetFlow collector.

 
Why NetFlow is Better than SNMP
Most network monitoring software can retrieve lots of data about a device using SNMP. In particular, it's quite easy to get the volume of traffic flowing through various interfaces by reading the statistics from MIB-II. This shows total bits/bytes per second flowing on that port. This is extremely valuable for looking for overloaded links and for other kinds of trouble.

However, these SNMP stats won't answer the big questions, "How is the link being used?" or "Who's hogging the bandwidth?" For that, you need a more detailed look at the actual sessions, which is exactly what NetFlow is designed to do.
 
<< Start < Prev 1 2 Next > End >>

Page 1 of 2