Network Monitoring Using Free Linux Tools
The material on this page was prepared using Sarge or Etch|
configured using our Installation and Packages pages.
If you did not use our pages to set up your system, what you
encounter on your system may be different than what is given here.
Network administrators need to "see" whats going on with their network. They need to know what the traffic on their network is comprised of, who's using the bandwidth, and how their infrastructure is handling the load. Fortunately, Linux runs a wide variety of free, open source network monitoring and traffic analysis applications that can give net admins this type of insight.
Many of these applications utilize server-based daemons which generate HTML-formatted data that can be viewed from anywhere on the network using a Web browser. This allows you to set up monitoring systems at remote points on your network and access them from a central location to establish centralized monitoring. The applications we will set up on this page are:
We also cover security-type monitoring using an IDS (Intrusion Detection System) on our Snort page.
- MRTG - Monitor router traffic
- MRTG - Monitor router CPU and RAM
- nTop - Monitor wire traffic for top bandwidth users and protocols
- nTop - Monitor Cisco NetFlow data for top bandwidth users and protocols
- TCPdump and Wireshark - Sniffer software for packet analysis
A Note About Placement
MRTG reads SNMP data from routers. When nTop is configured for Cisco NetFlow, Cisco routers are configured to send NetFlow data to the nTop system. As a result, you only need one MRTG system and only one nTop/NetFlow system for your network, located at a central point of your network. The output of these systems can be viewed from anywhere on a network using a Web browser. Although I have not tried it, because the SNMP data for MRTG and the NetFlow data for nTop come in on different ports, you should be able to run both applications on the same system.
In contrast, when nTop is configured to read network traffic directly off the wire, you'll need to place multiple systems at key monitoring points around your network (ideally one nTop system on each network segment of interest). You would then access each of them using a Web browser.
Because you could eventually end up with numerous monitoring systems running different monitoring applications, and because the output of these systems are presented in HTML format, you may want to set up a single monitoring home page with links to each of the monitoring systems. This home page could be located on any Web server or system running Apache.
When nTop is configured to read network traffic directly off the wire, it puts the NIC in "promiscuous" mode. Sniffers and similar applications also do this. Normally a NIC will ignore any packets that are not destined for it (i.e. the destination MAC address of the packet does not match its MAC address). However, when a NIC is placed in promiscuous mode, it reads in all of the packets it sees and forwards them up to the application. Well, almost all traffic is forwarded.
By default, Windows drops runt or malformed packets so sniffing with a Windows system isn't a good idea. You'd have no problem capturing/viewing normal traffic on your network, but you could have a defective NIC jabbering a ton of runts on the wire and you'd never know it. Use a Linux system to monitor your network so you get the most accurate view of what's happening.
Monitoring On A Switched Network
Monitoring traffic (capturing packets), either with an application like nTop or with a "sniffer" application, used to be a lot easier back in the days when networks used hubs instead of switches. All packets entering a hub on one of its' ports were "seen" on all other ports. Every system connected to a hub saw all the traffic meant for all the other systems connected to that same hub. This is because a hub is a "layer 1" device, an electrical tie-point only. As a result, you could monitor the traffic to/from any system simply by plugging your monitoring system into the same hub your target system was plugged into.
Switches are different. They're "layer 2" devices so they pay attention to MAC addresses. When a packet comes into a switch, it'll only go out the one port that the destination system is connected to (or the uplink port if the destination system is on another switch). A system connected to a switch only see two types of traffic, unicast traffic destined specifically for it and broadcast traffic. As a result, if you connect a monitoring system to a switch all you'll see is traffic meant for it (which shouldn't be much at all) and broadcast traffic. While knowing what kind of broadcast traffic is on your network is a valuable thing and can help you spot some problems, monitoring traffic to/from a specific system on a switched network (which most are these days) requires a little more work.
Most switches have a port mirroring type of function that causes all switch traffic to appear on a given port (that you would hook a monitoring system or sniffer up to). Cisco calls it "port spanning" and the commands to set up a spanned port vary depending on the switch OS and version of it.
There is one option that doesn't require entering Cisco OS commands to reconfigure a switch. Lets say you want to monitor the traffic to and from SystemA and it's network cable goes to a switch. Get your hands on two extra network cables and a hub that has an RJ-45 uplink port (even a small 4-port hub is fine as long as it has an uplink port). Use the hub and cables to "tap" into SystemA's network drop by doing this:
Small hubs can be gotten for very little on eBay. Just make sure the seller is indeed selling a hub and not a switch (and that it has an uplink port).
- Unplug SystemA's network cable from its NIC and plug it into the uplink port of the hub.
- Connect one of the extra network cables from the hub to the NIC on SystemA.
- Connect the second extra network cable from the hub to the NIC on the monitoring system.
The only time this option would present a problem is if SystemA is a server or other system that needs to be available 24/7. In that case you have no choice but to set up port spanning.
Another issue to be concerned about it is speed. While Linux will run great on old hardware, a Pentium-II system may not have the horsepower to capture packets at gigabyte wire speeds. The speed of the wire and the horsepower of your monitoring system will dictate whether packets get dropped because the monitoring package wasn't reading in the packets fast enough.
Be advised that this potential speed problem is more of an issue with sniffer type systems and when nTop is configured to capture traffic off the wire. Because SNMP and Cisco NetFlow represent information about traffic flow, and not the traffic itself, MRTG and nTop configured for NetFlow can be run on older hardware with less likelihood of it being overwhelmed with traffic data.
MRTG for Router Links
MRTG (Multi-Router Traffic Grapher - www.mrtg.org) can be configured to graph all sorts of values from WAN link bandwidth usage to Apache Web server accesses. On this page we will use it monitor bandwidth utilization on WAN and LAN links between routers as well as router CPU utilization and free memory.
Debian's MRTG package includes a utility called indexmaker which generates a sort of overview home page that shows all of the graphs for all of the links you're monitoring.
Note: MRTG uses SNMP to query routers for traffic statistics. You must have read-only SNMP enabled on the target routers. For Cisco routers, this is accomplished with the IOS command:
snmp-server community public ro
The public keyword is the SNMP "community string" and is kind of like a password. An SNMP application will present the community string to the router when it requests traffic statistics. If the community string is not correct, the router will not respond. (The community string is set in the router configuration and in the MRTG configuration file and they must be the same.) "Public" is the default community string for read-only access. Because it is the default, it is not secure. As a result, many organizations will use a different community string for read-only access.
Clicking on one of these graphs brings up a details page for that link which shows byte counts along with the same daily graph you saw on the home page as well as weekly, monthly, and yearly graphs for historical trend analysis.
Setting up MRTG is pretty easy. In summary, all you have to do is:
The single most difficult thing about getting MRTG working is creating the configuration file. The MRTG package does include a utility called cfgmaker that you can use but you have to supply so much information on the command line when you run it that you might as well just enter it directly into the configuration file using a text editor. Directly editing the configuration file also allows you to enter more than the just the basic configuration information to customize its appearance and operation.
- Install the MRTG package
- Create the configuration file
- Create the summary home Web page
MRTG's configuration file has two major parts. Global settings and Target settings. Global settings affect program operation and cover a few settings that apply to all "targets" (router interfaces in our case). You create a target entry in the configuration file for each router interface you want to monitor.
Since MRTG presents its output in HTML format, you'll need to install Apache on your system. If you haven't already done so, do so with the command:
apt-get install apache
That's all you need to do. Because you're not running any Internet Web sites on this system you don't need to make any changes to the Apache configuration file. Then install MRTG with the command:
apt-get install mrtg
The installation will create an mrtg subdirectory where the Apache Web pages reside. On your Debian system the path of this subdirectory is:
and there will be a few PNG-type graphics files in it. The installation will also create the configuration file in the /etc directory. However, this default configuration file is of little use so we'll create our own from scratch. Use the 'move' command to rename the original one with the command:
mv /etc/mrtg.cfg /etc/_mrtg.cfg
Below is a sample configuration file. The are only a few settings in the Global section of the file and they should be entered in all configuration files. The Target section is different. The entries in this section are specific to your network. Notice that there are two target entries in this sample configuration file. They relate to the two Corp HQ router interfaces in this diagram:
Here is the configuration file for the above network.
# Global Settings
Title[172.21.0.17]: Corp to Engineering Ethernet - 172.21.0.17
PageTop[172.21.0.17]: <h1>Corp to Engineering Ethernet - 172.21.0.17</h1>
Title[172.20.0.41]: Corp To Warehouse T1 - 172.20.0.41
PageTop[172.20.0.41]: <h1>Corp To Warehouse T1 - 172.20.0.41</h1>
Target Section Notes
You need to set up a target entry for each router link (interface) that you want to monitor. Each target entry in the configuration file equals a graph on the summary home page (as well as an underlying page with statistics and historical graphs).
- The format of the Target statement is as follows:
Target[ID]: /Target Interface IP Address:Community String@Resolvable Host Name
- The ID can be anything that uniquely identifies the target and it must be the same for each statement in the target entry. It can be descriptive text (with no spaces) and it is also the name of the Web pages that are created for this interface in the /var/www/mrtg directory.
- The target interface address is the IP address of the router interface that you want to graph the traffic of. It must be preceded by a slash.
- We mentioned the community string earlier. This value must be the same community string entered in the router.
- The resolvable host name is typically used when monitoring values on servers, etc. When dealing with routers, simply use the address of an interface that the MRTG system has connectivity to.
- The MaxBytes statement is a value that sets the max value of the graph for this interface. Because the graphs show bits, the MaxBytes value has to be the bitrate of the target interface divided by 8. Typical MaxBytes values for various interface types are:
193000 for a T1 (1.5 Megabit) interface
1250000 for an Ethernet (10 Megabit) interface
12500000 for a Fast Ethernet (100 Megabit) interface
- The Title statement specifies the text that will appear in the blue title bar of the browser when the stats/history page for this interface is viewed.
- The PageTop statement specifies the text appears at the top of the stats/history page for this interface. It is also the text that appears above this interface's graph on the summary home page. It can be, but does not have to be, the same as the Title value. Note that the <h1> tags are required.
- The Unscaled statement is not required but is a good idea. Without it, the vertical scale will be automatically re-scaled so that very small values will show up significantly on the graph. The problem with this is that the max value (the speed of the interface) won't be displayed on the graph unless there is significant traffic and it can be misleading if you want to review your network traffic with a quick glance at the MRTG summary home page. Each letter after the colon represents one of the graphs (year, month, etc.).
But now lets say that business has picked up and the CEO wants to put the call center in their own building and that their bandwidth requirements, like Engineering, warrant running fiber between the buildings for Ethernet (10 Mb). And lets say you want to add MRTG graphing for the new building. Your current configuration monitors the 172.21.0.17 interface which is both the Engineering Building and the Call Center combined.
There's no way to determine how much of the traffic is going to each building. As a result, we have to replace the 172.21.0.17 target entry in the original configuration file above with two different target entries so the Target section of our configuration file becomes:
Title[172.21.0.18]: Corp to Engineering Ethernet - 172.21.0.18
PageTop[172.21.0.18]: <h1>Corp to Engineering Ethernet - 172.21.0.18</h1>
Title[172.21.0.19]: Corp to Call Center Ethernet - 172.21.0.19
PageTop[172.21.0.19]: <h1>Corp to Call Center Ethernet - 172.21.0.19</h1>
Title[172.20.0.41]: Corp To Warehouse T1 - 172.20.0.41
PageTop[172.20.0.41]: <h1>Corp To Warehouse T1 - 172.20.0.41</h1>
Because the target interfaces are on "the other end" of the router link there are a couple things to note here. The first is that the IP address after the @ is the same as the IP address of the target interface. That's simply because the target interface is the "closest" interface to the MRTG system.
In addition, note the - (dash) in front of the /172.21.... target interface addresses. This is done to reverse the In/Out numbers. Think about it. If our graphs normally give us a traffic perspective from the headquarters point of view, but now we start monitoring traffic at the remote site routers, we have to reverse the numbers to keep our perspective. For the most part, the traffic going in a remote site router will be going out of the Corp HQ router.
If you'd like to explore other configuration bells and whistles offered by MRTG check out the MRTG Configuration Reference.
Once you have MRTG installed you can create your own configuration file using the nano text editor with the command:
Enter the global configuration statements given in the example file above and the correct target entries for your network and the interfaces you want to monitor. Then exit the editor saving the file.
With the configuration file created correctly there's only one other thing you have to do and that's to use the indexmaker utility to create the summary home page. Since you have to re-run this command every time you make certain changes to the /etc/mrtg.cfg configuration file, you might as well put the command in a shell script. At the shell prompt type in the command:
and type the following command into the file:
indexmaker /etc/mrtg.cfg --output /var/www/mrtg/index.html
If you want to have a large title at the top of your summary home page, put a space after the index.html and add
replacing the "Corp_Router_Traffic" with whatever you want. There can be NO SPACES in the title text however. Exit the nano editor saving the file and enter the following command to make your new shell script executable:
chmod 770 /var/www/mrtg/newindex.sh
Now you can create your summary home page (and recreate it any time you make a change to the configuration file) by typing in the command:
The First Run
The downside of running MRTG as a daemon is that some errors aren't displayed on the screen, only written to the /var/log/mrtg/mrtg.log file. The first few times you run MRTG you'll get some errors because it's looking for files that don't exist yet, but after that you shouldn't.
To make sure everything is configured correctly with MRTG, you may want to change the RunAsDaemon setting in the configuration file to No and initially running it from the command line three for four times by just typing in:
Once it's running type in the command:
to get its process ID and kill the process. For example, if the process ID is 1032, enter the command:
and then just type in
at the shell prompt again. If you do this four times and you still get errors when you run MRTG, check your configuration file for errors. If it starts cleanly, change the RunAsDaemon setting to Yes and reboot your system.
After rebooting your system wait for five minutes or so and then take a look at your summary home page. If your Debian system's IP address is 172.16.0.20 then you'd type in the following in the address bar of a browser running on a system on the same network:
Your summary home page should come up with a graph for each target entry in the configuration file. If a graph looks like there's no data on it, click on it and check the statistics to see if any traffic is being seen. Small amounts of traffic won't show up on the graphs because we used the Unscaled statement (but small amounts of traffic aren't a problem so no news is good news).
MRTG for Router CPU and RAM
When we set up MRTG to monitor router interfaces, it is basically reading two SNMP MIB OIDs (Object IDentifiers). One object is traffic In and the other object is traffic Out. An SNMP MIB (Management Information Base) is a database that can contain thousands of objects, and many are application- or equipment-specific. Think of MIB objects as records in a database. Each object (database record) has a field with a name that indicates what type of information it stores (Bits/sec In, Bits/sec Out, CPU utilization percentage, etc.). The record also has a field with the corresponding value (132000000, 79000000, 10).
The MIB databases are embedded in the hardware, either in firmware or software. As the equipment operates, the values for all of the MIB objects is updated. The MIB can then be queried by an SNMP application like MRTG to retreive the values. Values can text or numeric. Since MRTG is a graphing application, it makes sense to only query objects with numeric values.
There are two types of integer values in the SNMP world, counters and gauges. Counters are accumulators so the numeric values only go up (until they are reset), like traffic through an interface. Gauge type values can go up or down, like CPU utilization. MRTG handles them differently. Gauge values are graphed directly. Counter values are averaged. Any value that is measured "per second" must be a counter. MRTG defaults to counter values. To graph gauge values, you must use the gauge option for that graph. Be careful though. Some OID values be already be in a per-second or per-minute format. In this case, because they've already been averaged by the SNMP routine in the device, you'd want to display them using gauge graphs.
You may be asking "If traffic on a WAN link goes up and down, why isn't it a gauge?" Because the value that MRTG is getting from the router isn't a "bits-per-second" value. It's a "This many bits have passed through this interface since the router was started" value. MRTG polls for values every 5 minutes so counter values (like bits through the interface) have gone up. MRTG takes the old counter value it had 5 minutes ago and subtracts it from the higher counter value it just got, leaving only the difference between the two. It then divides this difference number by 300 (the number of seconds in 5 minutes) to get the average per second. Bits through an interface is a quantity that increases over time (accumulates). CPU utilization and the amount of free memory in a router are values that don't accumulate over time.
Because many MIB objects are specific to a piece of hardware or an application, manufacturers make their own MIBs available for download for use in SNMP user applications. This means that the MIBs are located in the equipment and on a PC running an SNMP application. This allows you to interactively browse through all of the objects in the SNMP application, and then use that application to query the corresponding object on the equipment to get the current value.
I lied a little earlier. A MIB object doesn't really contain a name indicating what value is being stored. It contains the OID, a unique object number that uniquely identifies that particular value on that particular system for that particular manufacturer. To be that unique, you probably think an OID has got to be pretty hideous, and you're right. Here is the OID for the "number of buffer create failures due to no free memory" (which would indicate the router needs more RAM) on most models of Cisco routers:
SNMP applications take care of translating these hideous object IDs into something a little more readable. The translated name for the above OID is bufferNoMem. You can use an SNMP application to navigate through all of the MIB object names and then query the equipment to get the values for them. Most applications will, in addition to returning the value, return the OID as well. This is useful for us because we need the OIDs for MRTG.
MIBs are hierarchical databases with a structure which branches out from the top much like a file system branches out from the root of a drive. Each period in an OID represents a branch point in the inverted tree. We could use an OID style of specifying the hosts file on a Windows file system:
There are many "MIB browser" applications available. An excellent Windows application called getif includes a MIB browser and allows you to query your routers for a lot of other information (routing tables, interfaces addresses and states, etc.). However, you will need to also download and install the Cisco MIB for it.
Some SNMP utilities don't require a local MIB of their own because it'll read the MIB off of a device, but you need to give them starting point. snmpwalk is a Linux command line utility for browsing a MIB directly. You give it a starting point in a MIB (like 18.104.22.168.4.1) and point it at a piece of equipment and it'll query the equipment and display all of the objects below the one you specified. The snmpwalk and snmpget utilities are installed with the command:
apt-get install snmp
Once installed, use the snmpwalk utility to view the above bufferNoMem OID (47) with the command:
snmpwalk -v1 -c public 172.16.0.1 22.214.171.124.126.96.36.199.1
The public parameter is the SNMP "community string" and the 172.16.0.1 parameter is the router we want to query. Then we specify the MIB starting point.
The really cool thing about MRTG is that it will graph just about any OID value (as long as it's numeric). And the really cool thing about that is that the number of OID ojects you could graph with MRTG runs well into 6 figures. And it's not all hardware. Some applications maintain MIBs during their operation (like Apache tracking how many hits your Web server has gotten). To get an idea of how many MIBs there are out there, and what types of values you can be graphing with MRTG, check out MIBdepot.com. Here you can get individual OID to use in target lines (but you may have to put a '.0' or other index value at the end of them). If nothing gets graphed the SNMP routine on the device may not be enabled. Check the hardware or software documentation for the device to see how you go about enabling SNMP functionality on it.
Now that we know what OIDs are about, we can use them with MRTG. Edit the /etc/mrtg file to add the following lines to the bottom of it:
Title[16-CPU]: Router CPU Load on Corp HQ
PageTop[16-CPU]: <h1>Router CPU Load on Corp HQ</h1>
YLegend[16-CPU]: Utilization %
Title[16-RAM]: Router Free Memory on Corp HQ
PageTop[16-RAM]: <h1>Router Free Memory on Corp HQ</h1>
YLegend[16-RAM]: Free RAM
Notice that each target line has two OIDs, separated by the & character. This is because MRTG graphs a minimum of two values per graph. (When we specify a single interface address it graphs both In and Out traffic.) If we only want to graph one value, such as with CPU utilization, we just enter the same OID twice. The target line for the RAM does have two different OIDs, the first is for free RAM and the second (which will be the blue line) is for total RAM. Note that for the RAM entry you have to adjust the Maxbytes value so that it's a little higher than the amount of physical memory you have in the router. (If you're not sure how much RAM is in the router you can use a MIB browser to look for a name which matches that OID.) You also may have noticed that there's no / character before the OID. Those are only used when you use an IP address in the target line.
Note one other thing about the OIDs. They both have a .0 at the end of them. That's an index value. For example, we could have two processors that we want to monitor the utilization of. Index numbers, which start at 0, are needed to specify a single instance of a value. The index number of an OID is usually displayed with the OID in a MIB browser so you may have to use a MIB browser to find out what the index number is if you're not getting any data graphed using an index number of 0.
Once you've added the above to your /etc/mrtg file you'll need to recreate your MRTG home page and restart MRTG (just reboot the system). Note that it takes a little longer for the graphs to start showing the CPU and RAM information. I'm not sure why. But give it 15 minutes before you start looking for the results of your work.
Note that, unlike the earlier section where we used IP address targets, OID targets are vendor, and in some cases equipment, specific. The examples we gave in this section were for Cisco routers. If your routers are from a different manufacturer you'll need to research which MIB ODIs for that vendor will return the same information.
Using SNMP utilities to explore MIBs is fun and interesting. And most any numeric value in a MIB can be graphed withh MRTG. That opens up a lot of monitoring possibilities. Just remember that if you don't use the gauge option for a graph, MRTG will average the OID value and present it in a per-second format.
nTop Wire Monitoring
nTop (www.ntop.org) reads traffic data and compiles all sorts of statistics pertaining to hosts and protocols. It typically sorts the tabular results in descending order of bytes so that you can easily see who the top users of your bandwidth are (by host name). It also shows similar results broken down by application level protocol (HTTP, FTP, SMTP, etc.) allowing you to identify to most common types of traffic on your network.
nTop is incredibly easy to get running on a Debian system. Just install the package and then enter an nTop command. Literally. Type in the command:
apt-get install ntop
During the setup it will ask you to select the interface nTop will listen on (i.e. put in promiscuous mode). Note that it says that you can enter a comma-separated list of interfaces so you could install multiple NICs in a system and monitor multiple LAN segments on the same system.
Accept the ntop user name by hitting Enter. After the program is set up you'll see the message:
device eth0 entered promiscuous mode
A few seconds later you'll see the message:
device eth0 left promiscuous mode
The NIC dropping out of promiscuous mode indicates a problem. Here the "problem" is that we need to set a password for the nTop account we created during the nTop installation (that the daemon uses). To do that, enter the command
The uppercase A switch is for setting the program's Admin password. After entering (and re-entering) a password, reboot the system. Just before the login prompt appears you'll see that the NIC has again gone into promiscuous mode. But now, if you were to wait and watch, it would not drop out of promiscuous mode as it did before. There is no need to log into the system because nTop runs as a daemon.
Now that nTop is configured and running, just point a Web browser at port 3000 on the Debian system. For example, if the Debian system's IP address is 172.16.0.20 then you'd type in the following in the address bar of a browser running on a system on the same network:
and the nTop home page should appear.
NOTE: The menu of links at the top of the page has two rows. Clicking on the links on the top row will not change the main Web page. It only changes what's on the lower row of the menu. Clicking on the links on the second row will change the main Web page.
On the Summary/Traffic page you'll see several protocol distribution pie charts. Under one of them is a "Historical Data" icon that you can click on.
Doing so will bring up a page of historic charts of traffic broken down by TCP, UDP, ICMP, etc.
There is a lot of information collected and presented by nTop. It's simply a matter of taking the time to go through all of it so you can appreciate what a robust application it is.
nTop NetFlow Monitoring
NetFlow is a monitoring protocol developed by Cisco and it has numerous advantages over SNMP. If you're running a Cisco shop it should definitely be your first choice in monitoring tools. Other switch and router vendors may support the NetFlow protocol as well. Check with your vendor. It was developed to add an accounting function to routers and switches so it offers more detailed information on traffic flows and usage.
NetFlow aggregates information on the router which cuts down on the network traffic going to a reporting tool like nTop. In addtition to interface statistics (like MRTG), it collects information on coversations between systems and application-level information on hosts and protocols.
Luckily nTop natively supports (accepts) NetFlow data. It does this by creating a virtual interface specifically tuned to NetFlow data. If you've got nTop set up to monitor data off the wire as outlined above, adding the ability to look at NetFlow data is easy.
Start out by clicking on the Admin link on the top menu line and then click on Plugins on the lower menu line. On the Plugins page, click on the NetFlow link.
On the NetFlow Configuration page you only need to enter the first two values. The others can just be left alone.
The first value is the port you want nTop to list on for NetFlow data. There is no standard for this value. You just have to make sure that the same value is entered here and on the router. A commercial packages uses port 9996 so enter that and click on the "Set Port" button.
As mentioned, nTop creates a virtual interface to collect NetFlow data. We need to enter a network address for it that coincides with one of the networks that the router is connected to. Note that this is NOT a device address. You need to enter a network address which coincides with the netmask value you also enter.
For example, say we were primarily interested in looking at traffic in the Engineering Building which is a Class B segment with a network address of 172.18.0.0. The network address and mask we'd enter for the virtual interface would be:
Be sure to click on the "Set Interface Address" button. Now go baack to the Plugins page and click on No in the "Active" column to change the NetFlow active status to Yes.
Finally, we have to switch the interface to make sure that nTop is listening on the NetFlow virtual interface. You do this using the Switch NIC link under the Admin menu.
That's all there is to that. The nTop system is now listening for NetFlow data. However, that's not of much use until you configure a Cisco device to send some data to it.
There are five global config commands and an interface command that you need to enter in the Cisco IOS to have the device begin sending NetFlow data.
(config)# interface fe0/1
(config-if)# ip route-cache flow
(config)# ip flow-export source fe0/1
(config)# ip flow-export destination 172.16.0.20 9996
(config)# ip flow-export version 5
(config)# ip flow-cache timeout active 5
(config)# ip flow-cache timeout inactive 10
The Cisco device will now start sending the NetFlow data to the address and port number you specified. It will take some time for sufficient data to be collected, aggregated, and sent to nTop so be patient.
All of the previous utilities have taken network traffic (packets) and aggregated them into statistical data for presentation in tablular or graphical formats. But some times this higher-level information doesn't give you the detail you need to track down a problem. For that you need to look at the individual packets to see what's going on.
A popular command-line sniffer is tcpdump and it has a ton of command-line options. To install it just type in:
NOTE: Recall that sniffers put NICs in promiscuous mode and that in switch environments you're not going to see much except broadcasts unless you set up port spanning or tap into the drop of a specific target system.
However, the problem you're trying to track down may be related to broadcast traffic. Before implementing port spanning or tapping into a drop, just fire up a command-line sniffer and see what you can see.
apt-get install tcpdump
and once it's installed, run it with the command:
You can get even more information by using the -v and -vv command-line options (for verbose and more verbose). If the information starts coming too fast to be of use, redirect the output to a text file that you can look at with the nano text editor.
tcpdump -vv > iptrace.txt
tcpdump has a lot more command-line options that allow you to do some pretty sophisticated captures. Be sure to view the man page and Web documentation for this utility to see all it can do.
The more you know about the 7-layer OSI model the better you'll be at using a sniffer. Wireshark (and other sniffers) break down the presentation of the packet decoding by OSI layer. Wireshark is an excellent open source GUI sniffer with a lot of analysis features. There are three panes. The top pane lists the packets captured. When you click on one of these packets the various layers associated with it are shown in the middle pane. Clicking on the + sign next to each layer expands it to the details for that layer. The bottom fram shows the actual binary data that makes up the packet.
The Wireshark application itself doesn't do any packet capturing. The Linux version uses libpcap to do the actual capturing. That doesn't really make any difference in the use of the programs but you'll see those capture libraries referred to so you should know what they are. The libpcap package gets installed automatically when you install the Wireshark package with the command:
apt-get install wireshark
Note that Wireshark is a GUI application so you'll need to have installed the x-window-system package as we covered back on the Installation page.
If you have an older (slower) system and you need to capture a lot of data, you may want to use the command-line version of Wireshark called Tshark to do the actual packet capturing and then use the GUI Wireshark to view the capture file.
Wireshark is a fantastic piece of open source software. It has capabilities of sniffers that cost thousands of dollars for the Windows platform including capture and display filters and the ability to display just the packets associated with a given TCP stream.
Where to learn more - The best of our bookshelves:
Wireshark and Ethereal Network Protocol Analyzer is the best book out there on *using* Wireshark. It not only covers all the various menu options to help you get the most out of the program and its analysis tools, but goes into writing both capture and display filters. Chapter 8 presents some real-world captures of worms, trojans, etc. and they're also on the included CD if you want to load them into Wireshark yourself while you're going through the chapter. The book also covers Tshark and several other utilities that come with Wireshark.
Using all of these tools eventually leads you to an IP address, system name, or a domain name. However, many times it's ultimately a person that you're trying to locate because it's a person running that app that's affecting your network. Given that most corporate workstations are Windows workstations here are a couple tools you can use to try and track back to an individual user.
If you have an IP address and you would like a Windows machine name, try using:
ping -a <ip address>
to see if you can do a reverse lookup to get the machine name from the IP address.
If you're users are running Windows 2000 Pro or XP Pro workstations another good tool is psloggedon. The command:
psloggedon \\ip address or machine name
will show you what user is logged into the machine locally. When a system is part of a Windows domain and someone with a domain account logs into the domain, they automatically get logged into the machine locally too. Therefore, the "local" logon that's displayed will be in the form of:
A lot of times you'll get an IP address of an external site that one of your users is accessing. Trying to find out what this site is can be difficult at times. You can try putting the IP address in a browser address bar but that only works some of the times.
You likely already have the Apache Web server app installed on your Debian system. Do you know you can enable PHP functionality on your Web server with a single command? Simply enter the command:
apt-get install php4
Adding this capability to your Web server allows you to use all of the freely available PHP pages available on the Web. PHP pages are Web pages with embedded scripts. When you save the PHP files to a Web pages directory you give them a .php extension so that the PHP interpreter on the Web server parses for and executes the embedded code.
One example of such a page is PHP Net Tools by Eric Robertson. To use it do the following:
Once the file is in the directory, access it using a Web browser. If your Debian system's IP address is 172.16.0.20 then you'd type in the following in the address bar of a browser running on a system on the same network:
- Click on the above link
- Save the file as nettools.php
- If necessary, FTP the file to your Debian server using ASCII mode
- Copy it to the /var/www directory
You can use this page to do an IP Whois to see who that IP address belongs too. It may just be registered to an ISP, but sometimes the customer information is also included. You can also do it to try and do a reverse lookup when all you have is an IP address.
Did you find this page helpful ?
If so, please help keep this site operating
by using our DVD or book pages.
Site, content, documents, original images Copyright © 2003-2013 Keith Parkansky All rights reserved
Duplication of any portion of this site or the material contained herein without
the express written consent of Keith Parkansky, USA is strictly prohibited.
This site is in no way affiliated with the Debian Project, the debian.org Web site, or
Software In The Public Interest, Inc. No endorsement of this site by the Debian Project
or Software In the Public Interest is expressed or implied. Debian and the Debian logo
are registered trademarks of Software In The Public Interest, Inc. Linux is a registered
trademark of Linus Torvalds. The Tux penguin graphic is the creation of Larry Ewing.
IN NO EVENT WILL KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES BE LIABLE TO ANY PARTY (i) FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR INFORMATION, AND THE LIKE), OR ANY OTHER DAMAGES ARISING IN ANY WAY OUT OF THE AVAILABILITY, USE, RELIANCE ON, OR INABILITY TO USE THE INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED OR TRANSMITTED FILES OR GENERATED COMMUNICATIONS OR DATA EVEN IF KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES SHALL HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE; OR (ii) FOR ANY CLAIM ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN, OR DESTRUCTIVE PROPERTIES OF ANY INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED, TRANSMITTED, OR GENERATED FILES, COMMUNICATIONS, OR DATA. ALL INFORMATION, METHODS, HTML OR COMPUTER CODE IS PROVIDED STRICTLY "AS IS" WITH NO GUARANTY OF ACCURACY AND/OR COMPLETENESS. USE OF THIS SITE CONSTITUTES ACCEPTANCE OF ALL STATED TERMS AND CONDITIONS.