[c-nsp] packet monitoring?
barney gumbo
barney.gumbo at gmail.com
Mon Feb 27 11:51:22 EST 2006
I'm using mls full with nde sending to flow-tools. Setting up spans or
mirrors is certainly an option for an external or seperate listening device.
I've found ethereal/sniffer/etc provides too much information, and I don't
have a box that can handle that much traffic (150+ Mbps). Full packet data
isn't important for this app, and it seems that most standard sniffers are
interested in trying to caputre the entire payload, which I'm not interested
in.
I couldn't figure out how to get any of the existing flow-tools packaged
apps to aggregate the flows, so I can see all packets sent to a destination
subnet and what src-ports and dst-ports were used. We've found that this
can be done with nfdump, so that's where I'm at now.
I've also learned about an app called softflowd which is "like" a sniffer in
that it passively listens however then outputs what it's picked up into
neftflow packets back to a server. This could be useful for monitoring
networks which aren't actually routed by a SUP/MSFC, router or whatever, for
example in a DMZ where the firewalls are doing the forwarding not a router
or MSFC. I would span the relevant ports back to the softflowd nic for
monitoring.
If anyone has any feedback on the use of softflowd such as hardware specs
for 100-200 Mbps of traffic monitoring it would be appreciated.
On 2/25/06, Kim Onnel <karim.adel at gmail.com> wrote:
>
> Search for Port mirroring on your 6500 switches.
>
> or
>
> Get a linux box with two network cards, configure transparent bridging on
> them and use etheal or tcpdump on them.
>
> Connect the box in the path and everything will run fine, being able to
> sniff what you want, the first solution is cleaner.
>
> You will of course need to schedule down time for the first solution
>
> Read more about netflow.
>
> On 2/23/06, barney gumbo <barney.gumbo at gmail.com> wrote:
>
> > I have a complicated problem. I am trying to determine what
> > src-ip/src-prt
> > and dst-ip/dst-prt I need to allow outbound on the inside interface of
> > some
> > firewalls. Writing ACL's to restrict and then fixing later is not an
> > option.
> >
> > The firewalls are PIX 525 and 535. The typical traffic throughput is
> > 150-200 Mbps. Using log X interval Y on the PIX ACL's killed our CPU.
> > We've tried exporting netflow data from a set of 6509's with mls flow
> > cache
> > set to full and this is way to much data. To the best of my knowledge,
> > ethereal and sniffer can do this to a certain extent however I'm not
> > interested in using system resources to capture the whole packet
> > payload, I
> > just want to be able to sumarize layers 3 through 4 and if the app can
> > break
> > this down into complete sockets or estimate the UDP flows that would be
> > great too.
> >
> > I realize there may be a way to do this with the existing flow-tools
> > apps
> > but I've read through the manuals and perhaps I'm missing something. If
> > I
> > could just see aggregates of src-ip/src-port and dst-ip/dst-prt I think
> > this
> > will suit my needs well; I don't need to verify that the flow was part
> > of a
> > particular data transfer session or anything along those lines.
> >
> > Is there a tool that can listen passively (we would span the PIX inside
> > interface to this passive listener) and provide summarized data to meet
> > these requirements?
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
>
>
More information about the cisco-nsp
mailing list