[Lee <ler762@xxxxxxxxx>]

On 12/28/11, Chad Dailey <wireshark@xxxxxxxxxxxxxxxxxxx> wrote:
> Larry--
>
> What you're seeing is likely 'fast switching' noise (or at least that's
> what I call it).

I think you might be confusing layer 2 and layer 3 operations, but the
term is unicast flooding.  See, for example,
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801d0808.shtml

Cisco routers have a default arp timeout of 4 hours and the switches
have a default mac address table timeout of 5 minutes.  So if the
outbound path (host -> router) is not the same as the inbound path
(router -> host) you can get 5 minutes of the traffic being switched
and 3:55 of the traffic being unicast flooded.

The standard fix is to lower the arp timeout on the router, increase
the switch mac address table timeout or have the host send a broadcast
pkt every few minutes.

Lee

> 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