Hi, I have a PIX 520 in a rack with 8 servers behind it. It's a very simple setup as I have little knowledge of Cisco Pix systems. All the servers behind the firewall are working fine with various web servers etc running and all accessible from the outside world. What I want to do though is see how much bandwidth each server is using. Can this be done by monitoring the outside interface of the Pix 520 or will it only log the IP's and ports as opposed to the actual volume of data per IP?
PIX 5.x and 6.x only allow SNMP monitoring of total traffic per interface, with no SNMP ability to monitor traffic per IP.
The message logs for PIX 5.x and PIX 6.x do not provide any summary of traffic: only volume counts per TCP or UDP connection (other kinds of traffic are not counted.)
You might wish to extend the program that I posted in
Unfortunately you wrote this without quoting any context. Ah, you are using googlegroups, so you might be under the impression that everyone can easily see the context "right there", but that is far far from the case. The original message has probably expired for many of the readers of this Usenet newsgroup.
According to ntop.org, ntop works by sniffing traffic, except that it can also work as a NetFlow/sFlow collector. Therefor in order to apply ntop to the situation, the original poster would have to be able to do one of the following:
a) run ntop directly on the LANWAN interface device; or
b) transparently interpose a device running ntop between the LAN and LANWAN interface; or
c) "mirror" / "span" the boundary traffic off of the LANWAN interface device over to the device that would run ntop; or
d) use a [half-duplex] hub between the LAN and LANWAN interface device so that an ntop-running device can be hung off the hub and view all the traffic; or
e) be using a LANWAN interface device that supports NetFlow or sFlow; or
f) be using a switch (or router) between the LAN and the LANWAN interface device, with NetFlow or sFlow supported on the switch (or router); or
g) use some mechanism on the LANWAN interface device to capture packets, and from time to time send copies of the capture to the ntop device for post-processing.
The original poster was asking specifically about a PIX 520, which a fairly old model of Cisco PIX firewall.
PIX run proprietary real-time operating systems ("finesse), not any of the operating systems that ntop is available for, so (a) is not an option.
PIX are not able to mirror / span ports, so (c) is not an option.
PIX do not support NetFlow or sFlow, so (e) is not an option.
The PIX 520 -does- support packet "capture", but when not used very very selectively, the available capture memory would soon fill up; and the PIX does not support any method of automatically (e.g., at intervals) forwarding the captured packets, and there are no SNMP operations available that affect packet capture. Thus in order to use option (g), one would have to have have some system running an expect script that connected to the PIX, created a new capture, turned off the old capture, tftp'd out the old capture file and then removed the old capture file. There would be some overlap between the capture buffers reflecting the interval between when the new capture was activated and the old was turned off... you don't want to turn off the old and -then- activate the new because that way you would lose the packets that went by in that interval. I would say that, in practice, this option (g) is not realistic for any network that had more than -very- light traffic.
The options that are left are those that would require changing the topology ((b) interpose a transparent device; (d) interpose a hub).
That or rely upon the somewhat unlikely circumstance that one is using advanced modern switch equipped with NetFlow/sFlow whilst staying with a firewall model (PIX 520) that was last sold 4 1/2 years ago, for which software support has not been available for a 1 1/2 years, and for which repairs will no longer be possible within 6 months.
In my experience, sites which stick with PIX 520 usually have weak management support for networking ("it works, why spend money on it; if there's a problem, that young guy in accounting who knows a bit about PCs can have a look at it"); that or (much less common) there is some kind of very heavy disincentive to upgrade, such as if one would be required to re-do ISO 9001 certification, or if one is running e.g., a space shuttle simulator lab, for which
*every* change must be accompanied by 5 weeks worth of testing and documentation.
The PIX 520 with the newest software available for that model, is able to do only interface-level metrics. The original poster asked for per-server (i.e., per-IP) metrics.
The switch the PIX 520 is connected to probably does NOT do per-IP SNMP metrics. For example, if you investigate the IP accounting metrics available on Cisco switches, you will find that the only Cisco switches that support such things are the "Content Switch" (CSS) series, and the SS7 telephony IOS images for a few major switches. For other Cisco devices/images, IP accounting information is available via Netflow, which does *not* support queries or reporting via SNMP. And I already covered Netflow earlier.
Didn't notice you needed per-ip accounting. A traffic logging package is your only option then. Something like NetIQ taking all the traffic logs in syslog format would give you all the information you could ever want on a per-ip basis.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.