The connected hosts themselves have no problem seeing each other, i.e arping returns the proper mac addresses and all hosts are reachable within the local network. I went as far as checking the mac hashing functions and whether there might be collisions, but still no luck. Strangely enough, adding the mac statically does not resolve the situation - all packets to this mac result in a unicast to all connected hosts. I've captured some packets on the problem interfaces and they all seem correct, i.e the source mac address is the correct one and the proper vlan tag is received. Some of the switch interfaces learn properly and some do not, and all share the same configuration. The most frustrating thing is that the same configuration of interface 0/0/12, for example, learns the mac of its host properly.

traffic on the interface is untagged, but set to the proper default vlan.

spanning tree protocol is disabled and thus the interface is not blocked.

there are no loops and there is no mac flapping in the network.the interface receives/sends packets properly.mac learning is enabled on the vlan level and on the interface level.the vlan of the interface is configured properly.the number of the mac addresses in the table is way below the maximum (less than 1%).

there are no mac table limits configured in the switch (not globally, not on the vlan level, not on the interface level).I've researched all of the possible causes: Strangely enough host A has an IPMI interface with a separate mac, which the switch learns dynamically without a problem (very strange). For example host A is connected to switch S1 on port 0/0/30.Įach packet to host A results in a unicast to all connected hosts of S1, because the mac address of A is missing from the table. We have a very strange problem, where certain ports refuse to learn the mac addresses of their hosts.

Huawei mac address table