[c-nsp] packet monitoring?

Brian Desmond brian at briandesmond.com
Sat Feb 25 13:21:20 EST 2006


> You will of course need to schedule down time for the first solution

I think you meant the second one ... mirroring a port does not require
any downtime. 

Thanks,
Brian Desmond
brian at briandesmond.com
 
c - 312.731.3132
 
 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Kim Onnel
> Sent: Saturday, February 25, 2006 6:06 AM
> To: barney gumbo
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] packet monitoring?
> 
> 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/
> >
> _______________________________________________
> 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