Switch sending tcp traffic to incorrect interface

[Travis Marzo]

Need help diagnosing a layer 2 networking issue. We had a report from an end user of slow file server access from his computer but local applications were responding normally. No one else was having issues in his area. Port mirrored the employees access port (Gi1/0/33) and noticed traffic from another computer crossing onto his port. Our design is to have one computer per port. This traffic was not intended for his computer as it was another employee opening and closing files on the file server (file server located on another switch). Checked MAC address table and his MAC address was the only one associated on the port. Traced the 2nd employees MAC address to a neighboring port (Gi1/0/35). Only MAC address associated on Gi1/0/35 was the 2nd employees. Cleared the mac address entry for Gi1/0/33 only and the extra traffic was eliminated immediately. 

Why would a switch send tcp traffic to a port that a client does not communicate on? I asked the second employee if they noticed any issue in accessing the file server and none were reported.  Switch is a 3750x with version 12.2. 

[Charles Hill]

Hello LarsonDesignGroup,

Possible man in the middle attack.

To test/ verify:

Enter arp -a from the file server and verify the correct mac address is mapped to the correct ip address(destination pc). (Testing ok)

When traffic is being sent to both pc's, enter arp-a again and if there is a man in the middle attack, you would see a different mac. 

Here is a link that discusses arp poisoning and mitigation techniques.

http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11_603839.html

"Man-in-the-Middle attacks are generally network-related attacks used to sniff network connections or to act as a proxy and hijack a network connection without either of the victims being aware of this."

Hope this helps.

Please rate helpful posts,

Thanks.

[Travis Marzo]

I've been double checking everything this morning and I feel we were not attacked. All the MAC addresses in my capture are valid system addresses. ISE does not show any authorized machines attempting to connect to the switch. We have DHCP snooping enabled throughout the organization. That was a great article to learn from though.

I've included a visio of the setup and a snippet of the wire capture and arp/mac tables as were captured during the incident. Traffic from the fileserver intended for employee 2 was flooding the port employee 1 was connected on. The destination MAC address of the packets were not meant for employee 1. 

Default config for both ports:

 switchport access vlan 101
 switchport mode access
 ip access-group ACL_DEFAULT in
 authentication event fail action next-method
 authentication host-mode multi-auth
 authentication open
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication port-control auto
 authentication violation restrict
 mab
 snmp trap mac-notification change added
 snmp trap mac-notification change removed
 dot1x pae authenticator
 dot1x timeout tx-period 10
 spanning-tree portfast
 spanning-tree bpduguard enable

Am I missing something? Was this an attack? Was it a fluke? 

[Charles Hill · Accepted solution]

I'm not able to see the packet capture in the visio.  Distorted when I zoom in.

Does it show the traffic destined for the correct mac and IP but entering the wrong port?

Maybe the arp cache was corrupt.  Did you do a

show arp | i x.x.101.99

show arp | i x.x.101.68

on all switches involved?

[Travis Marzo]

It did show traffic destined for the correct mac and IP but entering wrong port. It was very strange and cleared its when clearing the mac address entry. I just looked through my notes and I only did a show arp on the 101.68 address.

I'm going with it was a corrupt arp cache unless anyone has any other ideas. I haven't been able to find any known bugs for this issue and it hasn't returned.

[Charles Hill]

Thank you for the update.