This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

WireShark detect many other devices TCP ACK packets

0

Hi, My PC IP is 1.177, but when I run WireShark, I always detect many many TCP ACK packets from 2.105 to 1.74, which our backup servers. I know 2.105 need backup all things to 1.74 during day time. but why my PC 1.177 can detect those packets? those packets need over 90% on my PC WireShark log. I checked and there is no mirroring port. Does anyone have idea about it ? it's virus or faulty nic?

Thanks

asked 13 Jan '15, 19:36

Hardwater's gravatar image

Hardwater
11113
accept rate: 0%

edited 14 Jan '15, 15:12

grahamb's gravatar image

grahamb ♦
19.8k330206


2 Answers:

1

This kind of thing happens when switches have to flood frames to all ports because they don't have the MAC address of the target IP in their MAC/CAM table. This often happens if a switch is really under heavy load and the MAC/CAM table is too small to keep all relevant IP-MAC combinations in memory.

You should really check your switch (login to the switch console) to see how utilized it is. My guess is you should see lots of warning messages as soon as you do.

answered 14 Jan '15, 00:54

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thanks, Jasper. After I moved 1.74 to another switch, the traffic stops now. But I still got some kinds of traffic for another servers. Also I'm keeping get ping time out in whole network. I'm not sure if it's related to it. Sometimes after 10 seconds I get one Ping time out, some time around 1 or 2 mins. before I'm thinking of STP issue, but time period is not right for STP.

Do you think after reboot switch will fix this issue. our core switch is HP 5800 and edge switches all HP 5210

Many Thanks

(14 Jan '15, 14:26) Hardwater

Hi, Jasper, I just checked switches MAC address table size, they can hole 32000 Mac address, I think it's enough for our network.

(14 Jan '15, 14:39) Hardwater

Here's the output from the switch:

MAC TYPE            LEARNED    USER-DEFINED  SYSTEM-DEFINED IN-USE    AVAILABLE
Dynamic   Unicast   853        0             4              857
Static    Unicast   0          3             28             31        1024
Total     Unicast                                           888       32768

Dynamic Multicast 0 0 0 0 Static Multicast 0 13 12 25 256 Total Multicast 25 0

but total Multicast available as above is 0, is it something about it?

(14 Jan ‘15, 14:43) Hardwater

1

Is there asymmetric routing in your environment? When the 1.74 communicates back to the 2.105 over a different path than the active routing engine in the network, then the FDB entry of a switch in the other path might be flushed due to a lower timeout of the FDB entry than the ARP entry.

This means that the routing engine has to flush the traffic since it no longer has the entry in the FDB (because return traffic does not pass this switch so it's table is not refreshed).

Please check the presence of the mac address of 1.74 on the switches when you see the ACK's coming by.

answered 15 Jan '15, 12:56

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Thanks, SYN-bit, Not only 2.105 have this issue, even the same subnet 1.XXX also have this issue. When I got ping time out, I can see those unexpected TCP ACK packets between other vlan 1 servers (they plugged in same core switch) Currently we have 3 HP S5800 switch stacking together to become one core. Before 1.74 plug into core 1, and then I plug it to core 3, I can see mac address table on core switches pick up new port immediately. But still can detected those unexpected TCP packets to 1.74. I doubt if there is any know bug for HP S5800 currently? Anyway, I logged a request to HP and hope they can have some idea as well.

(15 Jan '15, 19:04) Hardwater