[Chad Dailey <wireshark@xxxxxxxxxxxxxxxxxxx>]

Larry--

What you're seeing is likely 'fast switching'
 noise (or at least that's what I call it).  Modern layer three switches
 often will flood unknown or stale (to the control plane) layer three 
flows to all ports in a VLAN until the path (source and destination 
ports) are learned by the control plane, which then trims the forwarding
 plane flooding to unicast to the involved ports.  This can take several
 seconds, and sometimes results in a great deal of data bursting to 
hosts (like yours) that should not see the flow, but it is considered 
normal by all vendors that I have queried about it.  Most do not 
consider it a leakage problem, as flows are generally learned within the
 first few frames, and it is uncommon to push data during the 
handshake.  If fast switching
 is not used, delays in handling TCP handshakes and UDP flow setup could
 cause slow start to kick in and inhibit end station performance, which 
is especially noticeable when using a web browser for lots of short TCP 
connections.  In especially 'dirty' L3 switch implementations, unknown 
flows from *all* VLANs are copied to VLAN 1 in addition to flooding the 
VLAN the traffic is sourced from; in those cases, I disable VLAN 1 or 
remove all ports from it, and create new VLANs to limit leakage.  I test
 every piece of switching equipment I buy for this behavior.

Hopefully this helps clear your switching question.

Chad

On Wed, Dec 28, 2011 at 1:08 AM, Larry Dieterich <macworks@xxxxxxx> wrote:

I am fairly new to Wireshark and I have a remote Wireshark installation running with which I am trying to solve a problem wherein a Helix database server periodically denies services to different and random clients.

I am administering the Wireshark machine via the WAN using a USB Ethernet connection with a static WAN IP and screensharing.

I do not have access to any of the other devices on the network; I shipped a box of gear with instructions for the connections and it was set up by the owner of the network.

The computer is a black MacBook with Wireshark Version 1.4.1 running on Darwin 10.8.0 (Mac OS 10.6.8), with libpcap version 1.1.1, with libz 1.2.5. The machine is listening to the built-in Ethernet port on the computer which has IPV4 turned off.

I have made provisions to "hub out" the server using an OvisLink 8 port 10-100 hub, which connects to the server, the built-in Ethernet port of the Wireshark machine, and the switch, which is a Cisco SGE2010P 48-Port Gigabit Switch (there are three of these switches).

I am expecting this arrangement to limit traffic that Wireshark sees. I expect to see broadcast traffic, and traffic directed to the server, (which has a reserved IPV4 address of 192.168.0.50).

I have two puzzles about which I am seeking advice.

first-
I am seeing a lot of traffic that is not to or from to the server. All sorts of things that shouldn't be, as far as I understand, passed by the switch to the server/hub/sniffer port.


Here are some sample mysteries in the packet list-
These list source, destination,         protocol and info.

169.254.73.47      192.168.0.112        TCP               58526 > 4242 [ACK] Seq=1 Ack=67 Win=66542 Len=0 TSV=595095964 TSER=419853412
192.168.0.55       192.168.0.32 LANMAN    WPrintQGetInfo Request
192.168.0.202      192.168.0.113        TCP               afpovertcp > 50959 [ACK] Seq=1 Ack=1 Win=32760 Len=0 TSV=293317725 TSER=993629410
192.168.0.213      192.168.0.114        AFP               FPFlushFork reply
74.125.157.148  192.168.0.121   TCP               http > 60533 [SYN, ACK] Seq=0 Ack=1 Win=5672 Len=0 MSS=1430 SACK_PERM=1 TSV=1183932478 TSER=570689780 WS=6
69.31.132.32       192.168.0.121        TCP               http > 60515 [FIN, ACK] Seq=1 Ack=2 Win=248 Len=0 TSV=1127482958 TSER=570689780
192.168.0.121      38.126.142.136       TCP               60523 > http [ACK] Seq=1 Ack=1 Win=66608 Len=0 TSV=570689775 TSER=1834995510
192.168.0.121      69.31.132.57 TCP               60538 > http [ACK] Seq=1 Ack=1 Win=66608 Len=0 TSV=570689780 TSER=3998751447
192.168.0.121     69.31.132.57        HTTP                GET /PointRoll/Media/Banners/Ford/927258/Ford_DriveOne_ECOBOOST_970x250_Panel_122211_pr02_BACKUP.jpg?PRAd=1560455&PRCID=1560455&PRplcmt=1529995&PRPID=1529995 HTTP/1.1

There is a lot more of these. This is but a sample.

My limited understanding has me wondering about this traffic. Why should my setup be seeing so much (apparently) non-broadcast traffic that is not intended for the server? (which is at 192.168.0.50) Shouldn't the switch isolate such traffic? FWIW, I *am* seeing an enormous amount of traffic intended for the server which is functioning as well as it was before this sniffer rig was connected.



A second part of this puzzle has arisen as I prepare this question.

I have a running capture on the Wireshark machine. When I turn off IPV6 on the MacBook, the computer advises that there is no connection on the Ethernet port and the packet stream stops. When IPV6 is set to automatically configure, the packet stream resumes. (IPV6 has been turned on with auto-configure during the capture so far)



So, I have three questions-

Is there a problem with turning off IPV4 on the Wireshark interface - should I do it differently?

Why does the packet stream stop and the network port go inactive when I turn off IPV6?

Why does my connection to the switch show me so much traffic that is not apparently broadcast, nor intended for the server?


I appreciate any insight or suggestions.


thanks,
Larry
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe