Stef,
Why don't you just span the entire VLAN to a machine capable of running
tcpdump, use tcpdump -e to find the hardware address of the station(s)
sending the traffic, and look up that address in the CAM table of your
switch? Would be quicker than spanning 1 port at a time..
Kr,
Nicolai van der Smagt
-----
I have a question, that - in case someone has seen this somewhere -
may save us a lot of work: our netflow tool has been reporting lots of
traffic (100s of MB/day) between some bogon IPs: 0.10.94.27 to a few
IPs in the 37.245.0.0/24 network (e..g 37.245.0.64, 37.245.0.18,
37.245.0.14, etc.). The report comes exclusively for one VLAN, from a
4506 switch. The IP protocols being reported are not among the well
known ones (TCP, UDP, ICMP, etc.), but rather #140 (for the majority
of traffic) and #63 (and some other ones). We have tried to reach
(ICMP echo, nmap, etc.) those IPs from various stations from the same
VLAN, with no success. Monitoring a few ports (span to a probe), at
random, have not revealed any ARP traffic for those IPs, either, thus
- at this stage - being unable to determine who is responsible for
that traffic. The default gateway for all the systems on that VLAN
does not see any of this traffic, either - and neither any other
systems form that point on, upstream, al the way to the internal
interface of the firewall, which makes us think that somehow that odd
traffic is really confined to that specific VLAN (thus - probably -
some sort of spoofing, combined with systems aware of each other's
MAC, thus no need to hit the gateway ...).
The next step is to write a script on the switch itself (TCL -
probably) or on an external probe, so that we could span/monitor one
port at a time, and go through all the ports on all blades from that
4506 (4 modules * 48 ports), until the probe hooked up t the
destination port will report the traffic we are looking for (as
netflow data reports this traffic going on continuously - so it must
exist at all times), from one of the ports. Another simpler approach
(but unfeasible, unfortunately, in our scenario, due to the need for
machines to be up 3 shifts/day) would be to shut down one system at a
time, and watch netflow when it stops reporting this junk.
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?
