On Apr 8, 2006, at 4:17 PM, Stef wrote:
So ... short of doing one of the above - has anybody seen this before?
Do you have an idea of how else we could trace down the perpetrator?
TIA,
Stef
A few comments/questions:
1. Your approach with RSPAN is sound. I'd suggest snagging a copy of
the
packets via tcpdump or somesuch.
2. Once you've isolated the host(s) generating the problematic traffic,
I'd suggest implementing DHCP Snooping and Source Guard, so that
spoofed traffic is stopped prior to reaching the first layer-3
hop. Only do this after you've tracked things down, done any
necessary cleanup, and test prior to doing a general deployment,
of course.
3. You don't have to write a TCL script on the switch itself, you could
do this any number of ways from an external box, if you like. You
could
even do it by hand. The idea would be to have a box running tcpdump on
the RSPAN destination port with a capture filter which samples only
the problematic traffic; you'd do one blade at a time using the
appropriate port-range for the blade in question, then once you've
isolated it to a blade, do groups of 2 or 4 ports, then narrow down to
just one. Don't assume it's a single system, do this for all blades/
ports (this should take a matter of minutes).
4. What's the destination interface reported by NetFlow? Is it Null?
Is uRPF enabled on the first-hop router?
5. Since the default gateway isn't seeing this traffic, on what device
are you seeing the NetFlow?
6. I'd be interested in seeing a capture of these packets, if possible.
7. You could also use nfdump or the flow-tools to record some of the
NetFlow records for this traffic. It would be interesting to
see this, as well, in order to look for communications patterns.
I think you're on the right track - I hope this helps!
----------------------------------------------------------------------
Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice
Everything has been said. But nobody listens.
-- Roger Shattuck
