[Lucas10] 2.2. Sensor Considerations

2.2. Sensor Considerations

The sensor is the device or program that captures flow data from your network and forwards it to the collector. Flow sensors are perhaps the most difficult portion of a flow-based management system to implement, especially on a geographically large network. You don't want to drive across the continent just to install a flow sensor!

The good news is, you don't need to worry about making those road trips. In fact, you probably already have flow sensors installed that you just haven't configured yet. Do you have Internet border routers? Have them act as sensors. Got a high-end Cisco switch? Great, use that.

If you don't have hardware that can do the job, you can implement a flow sensor in software.

2.2.1. Location

If you have even a medium-sized network, you'll quickly realize that you need to be selective about your sensor locations. Perhaps you have a couple dozen small switches and a hefty central core switch at your headquarters, half a dozen DMZs, an Internet border, and several remote facilities connected via VPN or MPLS. You could conceivably have sensors at each of these locations. Which are worth the effort?

2.2.1.1. Internet Border

Start with your Internet border. Almost all modern commercial-grade routers can export flow records. Analyzing those flows will tell you how you're using your Internet access. Knowing how much of your traffic is web surfing versus how much of your traffic is accessing your VPN will immediately help you make better decisions.

2.2.1.2. Ethernet Core

Look at your network's Ethernet core next. The internal LAN will have much more traffic than the wide-area Internet connection. Analyzing flow data from your internal network will quickly expose problems, misconfigurations, and performance issues. Your network architecture dictates sensor placement.

If you have a single large core switch, such as a Cisco 4000 or 7000, the switch itself can probably export flow information.

If you have multiple switches in your Ethernet core, you might think you need flow export on every one of them, but that's overly ambitious. You do not need a complete record of every last packet that passes through every switch on your office network.

When considering where to capture data, think about how traffic flows from device to device, and configure flow export only from central "choke" points. For example, my main data center has a configuration common in large enterprises: a large Cisco switch at its core and client switches in wiring closets on each floor. Every closet switch and every server is attached directly to the core switch. Any traffic that leaves a local switch must pass through the core switch.

I collect flow data only from the central switch. This means that I'm blind to any traffic that remains entirely on a closet switch, but I capture all client broadcast traffic and anything that goes to servers or leaves the network. Even if a client uses a printer attached to the local switch, the print job traverses the print server attached to the core switch. One single flow export point offers adequate visibility into the entire network.

If your Ethernet core is only one or two small switches and none of the switches can export flow information, you can still implement flow-based network management if one of the switches has a "sniffer" or "monitor" port. One of the switches is effectively the network core. If you haven't designated a particular switch as the core, use the switch that serves the highest number of servers. Attach a software flow sensor to the monitor port (see Section 2.10 in Section 2.10).

2.2.2. From Remote Facilities

Apply similar reasoning to remote facilities. Each remote facility has at least one router connecting it to the global network. It might be connected to an MPLS cloud or the Internet, but it's still your link into the outside world. Capture flows from that device.

If a remote facility has a export-capable core switch, use it as well. If the site reports many problems and the central switch cannot export flows, consider implementing a software sensor or upgrading the core switch.

Have remote sites export their flows to your central collector. Maintaining multiple collectors increases your workload with very little gain.

2.2.3. From Private Network Segments/DMZs

Tracking flows from your core network, and your Internet border provides insight into your entire network, including servers on isolated or private network segments such as DMZs. You can see the traffic DMZ servers exchange with your core network and the Internet. What you cannot see is the traffic among DMZ servers.

If you have only one or two servers on a DMZ, you probably don't need flow export on that network segment. If you have several servers, you'll want flow export. You don't need to decide right away, however. Fine-tune your flow management installation on your core and border networks, and then implement flow export on your DMZs.