Networking – Router vs VLAN

With Cisco devices, you do not need to configure a native VLAN, and it is recommended that you do not configure one. Traffic that is local to the link (CDP, VTP, PAgP, DTP, etc.) will still be sent and received untagged, and it will work correctly. This traffic will never be sent beyond the link, even with a native VLAN configured.

Having a native VLAN configured can present a security risk, as can the use of VLAN 1 (the default VLAN and default native VLAN). If you don't have a native VLAN, then any traffic spoofed to be on the native VLAN will never travel beyond the single link, and that limits any damage which may be done.

You can never delete VLAN 1, but you can limit which VLANs are allowed on a trunk with the switchport trunk allowed vlan <list> command, and just not allow VLAN 1 by excluding it from the list.

As mentioned in my comments on Ron Royston's answer, I assume you mean "why can't switches also use some sort of protocol to populate their mac-address-table". If that is not what you meant then disregard the rest of this answer. If that is what you meant then I think this is a great question!

First of all, if you really meant "why can't switches use..." then I think the answer is, theoretically they could - or at least off the top of my head I can't think of a reason why they could not. You could invent a L2 protocol that allows switches to query the device connected to a port to get the device's MAC address, or a list of MAC addresses reachable through that device (in case it is another switch). This could perhaps even remove the need for STP. Of course this are just my initial thoughts and real experts (which I don't consider myself to be) may have already given this much more thought and may have found specific reasons why this would not work.

However if your question (or next question) is "why don't switches use..." then I can think of a few reasons:

• Ethernet existed before Ethernet switches were invented. Implementing a new protocol would mean no backward compatibility or in other words, you would have to upgrade firmware or hardware on all the devices on your network to implement this new protocol.
• Time-to-market and competition may have been important (business driven rather than technical) considerations when the first switches were introduced.
• CPU power in early switches may not have been enough to run such a protocol, or switches would have required more expensive CPUs.
• the KISS principle. Such a new protocol would be much more complex than the current mac learning method.
• as Ron Maupin mentions in his answer, in a network hosts may frequently connect/disconnect or roam (consider your phone connecting to different wifi APs when you walk around, so the LAN switches will see its mac address on different ports all the time), so this could generate a high amount of overhead (in terms of bandwidth used by the protocol, and CPU load on the switches to process the changes).
• as Ron Maupin also mentions in his answer, unicast flooding happens (much) less than you may think. There are very few network connected devices that do not (or rarely) transmit frames on the network, and as soon as a device transmits a single frame, the switch learns its mac address. I want to add to that that many (most?) OS will send Gratuitous ARP packets causing the switch to learn the MAC as soon as the link comes up. Also, in the unlikely (but possible) scenario where a device does not transmit any frames, a managed switch typically offers you the possibility to configure a static entry in the mac-address-table (e.g. using mac-address-table static ... on a Cisco Catalyst switch.