[Lucas10] 2.2. Sensor Considerations

2.2. Sensor Considerations
Thesensor is the device or program that captures flow data from yournetwork and forwards it to the collector. Flow sensors are perhaps themost difficult portion of a flow-based management system to implement,especially on a geographically large network. You don't want to driveacross the continent just to install a flow sensor!
Thegood news is, you don't need to worry about making those road trips. Infact, you probably already have flow sensors installed that you justhaven't configured yet. Do you have Internet border routers? Have themact 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
Ifyou have even a medium-sized network, you'll quickly realize that youneed to be selective about your sensor locations. Perhaps you have acouple dozen small switches and a hefty central core switch at yourheadquarters, half a dozen DMZs, an Internet border, and several remotefacilities connected via VPN or MPLS. You could conceivably havesensors at each of these locations. Which are worth the effort?
2.2.1.1. Internet Border
Startwith your Internet border. Almost all modern commercial-grade routerscan export flow records. Analyzing those flows will tell you how you'reusing your Internet access. Knowing how much of your traffic is websurfing versus how much of your traffic is accessing your VPN willimmediately help you make better decisions.
2.2.1.2. Ethernet Core
Lookat your network's Ethernet core next. The internal LAN will have muchmore traffic than the wide-area Internet connection. Analyzing flowdata from your internal network will quickly expose problems,misconfigurations, and performance issues. Your network architecturedictates 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.
Ifyou have multiple switches in your Ethernet core, you might think youneed flow export on every one of them, but that's overly ambitious. Youdo not need a complete record of every last packet that passes throughevery switch on your office network.
Whenconsidering where to capture data, think about how traffic flows fromdevice to device, and configure flow export only from central "choke"points. For example, my main data center has a configuration common inlarge enterprises: a large Cisco switch at its core and client switchesin wiring closets on each floor. Every closet switch and every serveris attached directly to the core switch. Any traffic that leaves alocal switch must pass through the core switch.
Icollect flow data only from the central switch. This means that I'mblind to any traffic that remains entirely on a closet switch, but Icapture all client broadcast traffic and anything that goes to serversor leaves the network. Even if a client uses a printer attached to thelocal switch, the print job traverses the print server attached to thecore switch. One single flow export point offers adequate visibilityinto the entire network.
Ifyour Ethernet core is only one or two small switches and none of theswitches can export flow information, you can still implementflow-based network management if one of the switches has a "sniffer" or"monitor" port. One of the switches is effectively the network core. Ifyou haven't designated a particular switch as the core, use the switchthat serves the highest number of servers. Attach a software flowsensor to the monitor port (seeSection 2.10 inSection 2.10).
2.2.2. From Remote Facilities
Applysimilar reasoning to remote facilities. Each remote facility has atleast one router connecting it to the global network. It might beconnected to an MPLS cloud or the Internet, but it's still your linkinto the outside world. Capture flows from that device.
Ifa remote facility has a export-capable core switch, use it as well. Ifthe site reports many problems and the central switch cannot exportflows, consider implementing a software sensor or upgrading the coreswitch.
Haveremote sites export their flows to your central collector. Maintainingmultiple collectors increases your workload with very little gain.
2.2.3. From Private Network Segments/DMZs
Trackingflows from your core network, and your Internet border provides insightinto your entire network, including servers on isolated or privatenetwork segments such as DMZs. You can see the traffic DMZ serversexchange with your core network and the Internet. What you cannot seeis the traffic among DMZ servers.
Ifyou have only one or two servers on a DMZ, you probably don't need flowexport on that network segment. If you have several servers, you'llwant flow export. You don't need to decide right away, however.Fine-tune your flow management installation on your core and bordernetworks, and then implement flow export on your DMZs.