Exam 350-401 topic 1 question 761 discussion

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.

B - seen this in production multiple times, causes disasters SW_MATM-4-MACFLAP_NOTIF - MAC flap caused by the same MAC learned via different interfaces - Invalid port channel can cause this - i.e a port-channel from a VSS configured to a Dell VLT which does not combine the management plane as VSS does and requires a port-channel to each node in the VLT otherwise a loop and MAC flap is caused HA flap - virtual cluster flapping between primary and secondary nodes Highly redundant network topologies (service provider) if not managed carefully will see this too

B - seen this in production multiple times, causes disasters SW_MATM-4-MACFLAP_NOTIF - MAC flap caused by the same MAC learned via different interfaces - Invalid port channel can cause this - i.e a port-channel from a VSS configured to a Dell VLT which does not combine the management plane as VSS does and requires a port-channel to each node in the VLT otherwise a loop and MAC flap is caused HA flap - virtual cluster flapping between primary and secondary nodes Highly redundant network topologies (service provider) if not managed carefully will see this too

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 ?!

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.

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.

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.

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.

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 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.

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