I have an interesting issue that may be a little hard to explain.
So I took a laptop with wireshark and plugged it into a nexus 5000 port that is configured as a trunk with 3 vlans allowed on it. The laptop was seeing all kinds of traffic on the wire, most of it was not involving my laptop.
For example: Server A VLAN 10= 10.10.10.1 Server B VLAN 20= 10.20.20.1 and wireshark laptop is plugged into a trunk port which is allowing those vlan's. The vlan's are routable.
10.10.10.3 is seeing the entire conversation when 10.10.10.1 backs up 10.20.20.1 even though it has no reason to see it. It is as if the trunk is spanning traffic to the laptop port. No span is setup however. It's really weird. This is not just broadcast traffic, but actual tcp taffic between Server A and B.
Why would a trunk port see traffic between 2 other servers talking to each other on the vlan.
Thanks for any info.
Trunk port configuration below:
Interface Ethernet 141/1/3
switchport mode trunk
switchport trunk allowed vlan 10, 20
The end result is the same, but I am using stacked pairs of 3750G.
I see unicast traffic over the Trunk interface, but the destination IPs/Servers are definitely not connected to this switch
This sounds as if it could be flooded unicast traffic.
You see this for routed traffic when the router has an ARP entry with a valid MAC, but that MAC is no longer seen in the switch CAM tables. If the router forward traffics towards a MAC address that is no longer in the switch CAM table, the behavior of a switched network is to forward that traffic on all ports that carry the VLAN the traffic is sent in. This happens in campus networks when you have asymmetric routing.
The workaround for this is to configure the router ARP timeout to some value lower than the switch MAC address aging time. When the ARP timeout is reached the router ARPs for the destination IP address, the ARP response repopulates the switch CAM tables and we avoid unicast flooding.
There's no details of your topology so I can't say for certain, but take a read through Unicast Flooding in Switched Campus Networks and/or Case Study #8: Asymmetric Routing and HSRP (Excessive Flooding of Unicast Traffic in Network with Routers That Run HSRP) to understand why this could be seen and if the scenarios presented match your topology.
Hi I have delved deeper - I cannot attribute the problem to asymmetric routing, mainly because the problem appears within the subnet too. I have found that there is no MAC table entry for certain servers, but there is an ARP table entry. I shall try and find out why there is no MAC entry....
In my scenario, it turns out that it is MS NLB on the servers that is causing this. e.g.