Some L3 switches flood the traffic from new flows until they are 'learned'. It greatly improves throughput during flow / session setup in a large switch that may be CPU-bound, but you generally shouldn't see more than the first dozen or so frames, once the flow is set up, traffic should be unicast.
On 11/16/07, bmcmanus <bmcmanus@xxxxxxxxxxxxxx> wrote:
I recently installed a new managed switch at a Customer location. Initially, the only connections to the new switch
were two local PCs, my monitoring PC, and the link to the Customer's network. I noticed what seemed to be excessive
traffic on the network (lots of blinky lights), so I turned on Wireshark to see what might be going on in the
broadcast/multicast world.
What I found was a TCP session transferring cleartext data from one PC to another. The two PCs were on two separate
switches elsewhere in the network (see text diagram below):
PC1----SWITCH 1-----|
|
CORE SWITCH----NEW SWITCH----MONITORING PC
|
PC2----SWITCH 2-----|
There was no port mirroring active on the new switch. This is a flat class B network (Note: we are working to correct
that). My monitoring PC address was in a different subnet.
Disregarding the security implications (according the the Customer's IS tech, the owners of the two machines were in
separate departments, and there was no reason for them to be communicating the information found in the packets), I
don't understand how I could even see this info.
Assuming that something happened to cause a switch to fall into hub mode, then it would have needed to happen on at
least two switches (including my new switch), and I would have expected to see collisions in the high traffic
environment around the core switch. None were captured.
Any ideas on how those packets appeared at a remote switch port?
Jon "Buddy" McManus
Wireless Communications, Inc.
bmcmanus@xxxxxxxxxxxxxx
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users
