Hello Mrityunjay,
Although Cisco Catalyst switches have their own MAC addresses, you should be aware that for the elementary switching function of a switch, it does not need any own MAC addresses. The primary function of a switch is to forward frames based on their destination address so that in ideal case, they are forwarded only out the port that truly leads to the intended destination, and only if the destination is unknown or is a group of receivers (multicasts, broadcasts), the frame is replicated out all ports except the one that the frame came in through. In order for this to happen, a switch has to learn MAC addresses of attached stations by observing the Source MAC addresses of incoming frames, and forward the frames based on their Destination MAC address. In this entire process, there is neither a place nor a need for a switch to have its own MAC address, and in fact, the cheap small unmanaged switches from many vendors truly do not have any MAC address assigned - they do not need any.
Well then, if a switch does not really need its own MAC address to perform the actual switching, why do Catalysts have a MAC address assigned to each of their ports? The answer lies in the fact that these switches do something that goes beyond the basic switching - they actually cooperate with each other to perform many control plane functions, including loop prevention using STP and LOOP frames, perform mutual discovery using CDP and LLDP, negotiate trunks using DTP, advertise VLANs using VTP, negotiate EtherChannels using PAgP and LACP, prevent problems caused by uni-directional links using UDLD, and I could go on and on. In other words, these smart switches need to communicate with each other, and naturally, in order for the switches to be themselves sources and destinations of these control plane messages, they need to have their own MAC addresses. To sum it up, a switch needs its own MAC address if it is itself going to be a final source or recipient of an Ethernet frame, which is obviously the case whenever a switch speaks any control plane protocol.
Now to your questions:
1)Why switches not show both the learned as well as the actual port mac in mac-address table.
My personal take on this is that the MAC address table defines how the frames should be forwarded, that is, how they should be treated if their destination is not the MAC address of the ingress switchport. However, if your switchport receives a frame that is destined to the MAC address of that switchport itself, you are not going to forward the frame out some other port - that frame is already at the final destination and the CPU is supposed to process it. That is why you do not see the switch's own MAC address in the output of the show mac address-table command.
2)How switches knows on which mac(I mean the mac that learned from attached devices or its own port mac) it should send bpdu.
A simple rule: If I am the source of a BPDU then it must be my own MAC address that is used as a source MAC. This is just a specific case of a much more general rule that says that if I am a source of a message then my own address should be placed in the source field of that message. If a BPDU is originated and sent out a switchport, that switchport's MAC address is used as the source MAC.
Another rule: You never use another device's address as the source when sending your own messages. That would be a classic source spoofing scenario - not to mention the fact that by stealing someone else's address, you can never be sure if the replies will be delivered to you or to the rightful owner of the address.
3)Is it correct if I say switches(layer 2) uses its own mac address only for sending and receiving bpdu.
Almost correct. To be entirely correct, we should say that Layer2 switches use their own MAC addresses only when they purposefully and intentionally communicate with each other using a control plane protocol: STP, LOOP, CDP, VTP, DTP, LLDP, LACP, PAgP, UDLD, ... Switches never use their own MAC addresses when simply forwarding user traffic.
Feel welcome to ask further!
Best regards,
Peter
