Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In the network we have a few vlans but at the moment I was investigating vlan2 which carries the most traffic. When tcpdumping on the eth0.2 interface, I see a lot of packets arriving which are not addressed to, nor coming from the server. I checked this on several servers in the network and they all have the same issues.

In short, our switches don't switch the traffic but threat it like they are a hub. Can you tell me what settings on the dell poweredge 6248 should prevent this behaviour?


I added some traffic I captured from the host. The ip address of the host is > > > > > > > > > > > > > > > > > > > > > > > > > > >

share|improve this question
Are you sure that you're not just seeing broadcast/multicast traffic? It's quite normal, and NOT something you'd want to filter inside a subnet.. – pauska Dec 4 '12 at 15:45
Thanks for the remark. The problem is less bad then first tought but I still see traffic between 2 unicast addresses of which none is the host on which I see the traffic. So I presume there is still a problem on my switch. – Hannes Dec 4 '12 at 15:55
could you give a log of this traffic? Hide/obfuscate any private data. – Mircea Vutcovici Dec 4 '12 at 16:13
up vote 2 down vote accepted

This sounds like a nasty bug I encountered on a pair of 5548's, which made the switches unable to learn new mac addresses after 49.7 days.. The symptom is that unicasts are sent out on all ports

Devices stop to learn MAC addresses after 49.7 days

After 49.7 days of operation, the device stops re-learning MAC addresses. These MACs which were previously learned will not appear in MAC address table. As a result traffic streams sent to previously learned MAC addresses are treated as unknown-unicast traffic and flooded within the VLAN.

MAC address learning mechanism was fixed so that both learning new addresses and re-learning existing addresses are updating the MAC Address database.


share|improve this answer
Sounds like a nasty one indeed. I will try to reboot the switch and see if this solves the problem, if so, I will upgrade the firmware. – Hannes Dec 5 '12 at 22:04
I rebooted the switch and the crosstalk disappeared, I presume this was the error. Thanks! – Hannes Dec 7 '12 at 9:31
I would try to verify exactly what problem it is and in which firmware version for your switches, as the referenced firmware fix is for 5548. – 3molo Dec 7 '12 at 20:09
I am planning to do a firmware upgrade on the switches and will monitor the behaviour afterwards. I will check if the problems disappear. – Hannes Dec 17 '12 at 9:56

The switches will filter only the frames for which the destination is in the MAC address table. This means that the traffic to unknown destinations, broadcast or multicast traffic will be send to all interfaces except the source interface.

Now the question is: What is the real problem? As you should expect some broadcast traffic all the time (CDP, LLDP, BPDU...)

share|improve this answer
As said in my comment, on one switch I see unicast traffic arriving between 2 'strangers' on my servers. (strangers of which 1 is connected the same switch as my server but none of them is my server) – Hannes Dec 4 '12 at 16:03
I can see the following causes: the MAC address table is expiring to quickly; the MAC address table is to small (you have more hosts on the network than entries in the switch); a bug in the switch (upgrade firmware); are you connected to a SPAN/tap port? – Mircea Vutcovici Dec 4 '12 at 16:13
Are the MAC addresses for the "strangers" in the MAC address/CAM table of the switch? – joeqwerty Dec 4 '12 at 16:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.