Hmm, thatâs actually an interesting question. From the little research Iâve done, depending on the platform, the MAC Address learning feature may or may not have the capability of being disabled.
There is the switchport mac-learn disable command, which will disable MAC learning at the switchport level. To enable it, you use the ânoâ version of that command. On the physical interface itself or, on a VLAN/SVI, you can configure the mac learn disable command. The ânoâ version once again enables it.
On the 9000 series devices, I believe these commands may be available only for portchannels. For other Nexus platforms, you may be able to apply them to interfaces. You may need to do some experimentation.
But the question is, why would it be disabled on the other end? I am assuming that youâre talking about the other end of the trunk link, correct? Check out these commands and see if you get anywhere with them. Let us know how you get along, and if we can be of further helpâŚ
Ive litteraly tried every command which i could think about. Funny part is that also in the terminal logging nothing pops out which could be related to this problem
I donât have a definitive answer for you, but Iâd like to ask, do you find that the switch is âmisbehavingâ in some way or you just see the indication on the output? For example, do you find that frames entering the port are not populating the MAC address table, and are being flooded out of all ports? Because this is the practical result of what would happen if MAC address learning is disabled. If you are not seeing this behavior, then itâs a bit of a discrepancy as to what that indicator actually means. Check to see if incoming frames do populate the MAC address table. If entries appear when traffic flows, MAC learning is working despite what the output says, and it could just be a bug that affects the display/output of the command.
Looking into the 3048 platform, it does not support the explicit disabling of MAC address learning at all. However, MAC address learning may automatically take place when certain other features are enabled. For example, if SPAN is being used, MAC address learning is disabled on the SPAN destination port. Otherwise it could be a hardware or ASIC limitation related to the mode or port role.
Another interesting nugget that I found is that in Nexus devices, by default, if the switch detects the movement of a MAC address from one port to another too many times, MAC address learning would be disabled for 180s on those ports. You can find more info about the MAC address table for the 3000 series nexus devices at this document:
If you do discover anything new or if you have some feedback on my suggestions, let us know!
Unfortunately, Packet Tracer doesnât support most of the features that go outside the CCNA curriculum so for any more âadvancedâ features, you should try a virtual emulator like Cisco CML or physical hardware.
@davidilles is correct, unfortunately Packet Tracer doesnât support this particular command. This has to do with the nature of Packet Tracer compared to other products.
Packet Tracer is a network simulator, not an emulator. This means that it does not run actual Cisco IOS code. Instead, it is programmed to respond to commands in the same way as Cisco IOS. In this sense, it simulates network device behavior. But it does so only for a limited subset of commands and features, typically those needed for fundamental CCNA-level content. Advanced hardware-dependent features, such as VACLs (specifically the vlan access-map and vlan filter commands), are not implemented in Packet Tracer, even in the latest version.
GNS3, CML, and EVE-NG are emulators. They run actual Cisco IOS/IOS-XE images that are used on real hardware, so they contain all of the same features and capabilities as their real-equipment counterparts.
Packet Tracer should be enough if youâre focusing primarily on CCNA, but for anything more advanced, itâs worth it to invest the time (and in some cases money) to obtain an emulator.
