An engineer receives a report that an application exhibits poor performance. On the switch where the server is connected, this syslog message is visible: SW_MATM-4-MACFLAP_NOTIF: Host 0054.3962.7651 in vlan 14 is flapping between port Gi1/0/1 and port Gi1/0/2.
What is causing the problem?
The issue is most likely due to an invalid port channel configuration on the switch. When the server has two interfaces bonded together but the switch does not have a corresponding valid port-channel configuration, the MAC address may appear on multiple ports because the switch is seeing the same MAC address on different interfaces independently. This results in what is observed as MAC flapping, where the switch's MAC address table keeps updating with the port on which the MAC address is last seen.
It's B. This is a scenario where you have two interfaces bonded together on the server, but there is no valid port channel configuration on the switch. This way the server will send always the same MAC on both interfaces, which will appear twice on the switch on both its G1/0/1 and G1/0/2 ports, rather than only once on its port-channel interface. A is wrong, actually misleading, as if anything you'd have to change load balancing on the server as a rough workaround, not on the switch. C is wrong as the interface[s] would be down, therefore no MAC flapping would occur. D is wrong as the interface[s] would be down as well.
I was going to choose A, since the load balancing configuration for port-channel on the switch would dictate which port was used for the MAC. But you made a good point that the flapping is based on ingress learned MAC which would be controlled by the server. I believe too that if 2 interfaces were bundled into port-channel, then the switch would not consider the MAC appearing on two member interfaces as flapping.
When a server is connected to two ports on a switch, it is typically part of a port channel (also known as link aggregation or EtherChannel). If the port channel is not configured correctly on both the switch and the server, the switch might see the MAC address on both ports independently rather than as a single aggregated link. This causes the MAC address to flap between the ports as the switch constantly updates its MAC address table with the port on which it most recently saw the MAC address.
On IOS-based switches, if the physical member ports of an EtherChannel do not successfully negotiate the bundling through LACP, they will continue operating as individual ports. That can lead to MAC flap scenarios indeed.
You can't bring LACP with switch up when ports are not in PO. When you have server NICs TEAMed/BONDed, they run active/standby and switch only learns MAC on Active side. If Active NIC bounces, MAC will bounce as well.
I also vote for B cause it states that the server is connected to the switch and those are the links with the problem. But it can also be A or D :)
I'm a bit doubtful on this question.... To me sounds good B because if the EtherChannel has not been established (for some misconfiguration), and the switch still treats the ports as individual ports while the other end is already using them as a bundle We have MAC flapping... https://learningnetwork.cisco.com/s/question/0D53i00000Kt7h8CAB/mac-address-flapping-on-port-channel
A. undesirable load-balancing configuration on the switch - Probably NOT B. invalid port channel configuration on the switch - Possibly, although nothing to suggest a Po is actually configured. C. wrong SFP+ and cable connected between the server and the switch - Probably NOT D. failed NIC on the server - This is the most likely, with the server set up for active/backup NICs, and the primary fails. The logs don't suggest that the event keeps on happening, so it's a one time event where the primary server NIC dies and fails over.
Only 'B'. Switch and server side can be conf'd as ON. (No LACP.) Real world experience.
im going with B with failed NIC i don´t think there will be a link flapping, but maybe packet loss.
i think D should be correct. B will make an effect directly after the configuration, while D is something that can happen anytime. i chose to understand the question as a real-life situation that I face in my Job, a NIC decided to start acting crazy and I got a report from co-workers about a performance issue. if we consider B in real life, as soon as I do the configuration I will start getting the Syslogs, even if was blind and I missed the Syslog, we will still face another question: if this is the situation from the beginning, how do the co-workers notice a performance change ?!
but with failed NIC i don´t think there will be a link flapping, but maybe packet loss, so i think B would be the correct answer
D. Failed NIC on the Server: A failed network interface card (NIC) on the server can lead to connectivity problems, including MAC address flapping. If the NIC is malfunctioning or flapping, it could cause the observed behavior. This option also remains plausible.
A failed NIC typically results in a loss of connectivity or intermittent connection issues, but it would not typically cause the MAC address to appear on two different ports unless there are redundant NICs configured improperly.
I'm leaning towards B... https://support.hpe.com/hpesc/public/docDisplay?docId=c02936677 Can anyone confirm if misconfiguring the "port-channel load-balance xxx" can result in MAC flapping? If so, then the answer could be A, especially since it's obviously a LAG/bonded/teaming connection to a server/host.
mac stays on PO regardless of the load balancing method, that affects only hashing