Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] 8-10% packet error/loss is normal wired network?

From: Flako <subforos@xxxxxxxxx>
Date: Thu, 12 Jul 2012 17:23:49 -0300
Hello Frank
Now they are connected as:

swich B (1GB)  <-> swich A (100Mb) <-> switch C (100Mb) -- > Desktop
                       |                                  |
                       |-----> Printer
                       |                                  |--> some desktop
                       |--> some dektop and server


I am now analyzing data from Wireshark, when finished I commented.



2012/7/11 Frank Bulk <frnkblk@xxxxxxxxx>:
> What does the switch show the printer port being linked up as?
>
> Frank
>
> -----Original Message-----
> From: wireshark-users-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Flako
> Sent: Wednesday, July 11, 2012 2:57 PM
> To: Community support list for Wireshark
> Subject: Re: [Wireshark-users] 8-10% packet error/loss is normal wired
> network?
>
> 2012/7/10 Jim Aragon <Jim@xxxxxxxxxxxxxxxxx>:
>> At 08:32 AM 7/10/2012, you wrote:
>>
>> Counting only "tcp.analysis.retransmission" I'm from 0.95% to 1.21%, a
> value
>> more enjoyable. :)
>>
>> I think it's despicable for further research .. but I get the question if
>> this value is normal :)
>> In a wireless link, a loss of 1% is acceptable, but in a network cableda?
>>
>>
>> I would expect lost packets within local traffic in a wired LAN to be
> close
>> to zero; certainly under 0.5%. However, depending on the traffic levels on
>> your network, if the 0.95% to 1.21% retransmissions are not causing a
>> problem, it might not be worth your time to track down.
>>
>> If you do want to try to track it down, packets generally get lost at a
>> network device, so go to your switches one at a time and capture
>> simultaneously on both sides of the switch. If you see "previous segment
>> lost" on one side of the switch, but not on the other, then that switch is
>> dropping packets. The same for any other network devices that the traffic
>> passes through, such as routers or firewalls.
>>
>> If you can't capture on both sides of the switch simultaneously, then
>> there's another method to identify the point of packet loss. Find a TCP
>> retransmission, then apply a display filter for the tcp stream index
> number
>> and the TCP sequence number. If you see both the original packet and the
>> retransmission, then the packet loss was downstream from you. If you see
>> only the retransmission, but not the original packet, then the packet loss
>> was upstream from you. Be sure to do this for several retransmissions. As
>> you identify whether packet loss was upstream or downstream from you, you
>> can keep moving your capture point until you find the device that is
>> dropping packets.
>>
>> You also said that you have a 100mps switch and a 1Gbps switch.  Are these
>> switches directly connected to each other? If so, I'd start with the 1
> gbps
>> switch. If the 1 gbps switch is receiving traffic from the attached
> devices
>> faster than 100 mbps, then it will be forced to drop packets because it
>> can't transmit the packets to the other switch any faster than 100 mbps.
> In
>> other words, it will be receiving packets faster than it can send them,
> and
>> at some point, the switch's buffers will fill up and it will have to drop
>> packets.
>>
>> Jim
>>
>
> Hello Prigge, Jim
> The printer is at 100Mb / s FULL with autonegotiation disabled, the
> desktop was as 1Gb / s FULL with autonegotiation enabled.
> The swicth A (100Mb / s) and B (1Gb / s) are connected directly to each
> other.
>
>
> Now connect the Desktop Printer and a switch C (only two), then swich
> C connects directly to swicth A.
> I'm sniffer on the Desktop to see differences and discard things. I
> tell them when finished.
>
> Thank you for writing so far.
> (Examples of how to find a fault will serve me now or the next)
> ___________________________________________________________________________
> 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
>
>
> ___________________________________________________________________________
> 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