Re: Bogon IPs traffic only seen by netflow, confined within a VLAN only

On Sat, 08 Apr 2006 18:17:53 CDT, Stef said:
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: to a few
IPs in the network (e..g,,, 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 ...).

You might want to see if you can get a packet capture of this odd traffic
from a spanning port, and take a *careful* look at the packet and ask yourself
"what if the packet is missing a byte or several at the front, or has some
noise bytes added"? Take some of the headers, and try shifting everything
a byte or two in either direction, and see if it makes sense.

The usual cause for this is a busticated NIC - in years gone by, similar
things were caused by "jabbering" transceivers that would start transmitting
their packet sooner than the spec allowed, resulting in the first few bytes
being dropped, or noise bytes being added...

There's an outside chance that there's a packet-crafting program with an
off-by-one error, but I've seen this caused more often by broken hardware.

Attachment: pgprylupAlQl9.pgp
Description: PGP signature