Is there any particular reason why Ethernet switches don't change the MAC address of a packet?
Is it for end host identification using the MAC address, or anything else?
-
5Suppose your name was Kumar. Would you like it if people started calling you "Jessica"?– Mike PenningtonDec 6, 2013 at 6:15
-
1switches don't rewrite packets (frames); they simply move them from interface to interface. (in the case of broadcast/multicast, this includes copying to multiple ports.)– RickyDec 6, 2013 at 6:49
-
5Can you think of a valid reason why a switch should change the MAC address?– Teun Vink ♦Dec 6, 2013 at 7:57
-
Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.– Ron Maupin ♦Jan 3, 2021 at 5:07
Add a comment
|
3 Answers
If a switch were to change MAC addresses, this would break networking entirely.
The MAC address is a unique identifier which is used by hosts on the local network.
If the switch were to change the destination MAC, the frame would not get delivered to the appropriate host. In the cases that it would, for example if the frame gets flooded, the destination host would drop it because it would no longer be destined for the host.
If the switch were to change the source MAC address, the destination host would use this MAC address for any responses (including updating any ARP entries with bad data). This would result in the same situation I already described, just for all return traffic.
This could further create problems with things like 802.1X and other mechanisms that use the MAC address to identify/classify the device.
Could mechanisms be developed to do this? I am sure they could. But there is no reason to do so at this point and this would only complicate networking and add unnecessary processing. We are not close to exhausting the available MAC address pool so there is no need for something like MAT (don't know if the concept of MAC address translation even exists anywhere so maybe I just coined a term?).
Rewrites of addresses of datagrams happens at layer 3 for example when gateways (router or firewall) running NAT rewrites IP addresses of hosts on the inside network so they all appear from one (or a few) external IP addresses on the gateway itself.
The reason for something similar not happening at the layer 2 level (where we use MAC addresses to distinguish hosts and switches do the movement of datagrams, that is frames) is as said in comments above that there really is no need for it.
In the layer three case with NAT, the NAT solves a number of problems:
- IP addresses are used for global communication, and there is a limited pool of IP addresses available that has to be shared. By using NAT, one makes sure that a larger number of internal hosts can share fewer (commonly just one) IP address that is visible on the public internet.
- The rewriting of IP addresses are considered by some but not everyone to add a layer of security by masquerading the IP addresses of the internal machines.
So, if we stick with the NAT example, there is really no need for a layer two counterpart of NAT.
- MAC addresses are not used globally for addressing datagrams on the internet, they are used for sending frames to the right hosts on the local subnet. As local subnets are relatively small, and the number of possible MAC addresses is very large, one does not "run out of" available MAC addresses at the layer 2 level. (The option to manually reconfigure the MAC addresses of NICs to an arbitrary value does not change this)
- And for the debatable security benefit of rewriting datagram addresses when forwarding: As MAC addresses are used within a local subnet only, one usually have, in relative terms, much better control from a security perspective over that subnet (physically as well as most of the involved devices) compared to the counterpart in the layer 3 case, which is the entire internet (which we as connected users and network engineers in practice have no security control over).
Hope this shed some light over why switches do not rewrite MAC addresses. The only layer 3 case I came up with from the top of my head was NAT, others certainly can provide example of other layer 3 cases where IP rewrites are warranted (and why those technologies don't really make sense on the layer 2 level).
-
3Spot-on, but I do have one tiny little quibble with your answer. You mentioned that "there is really no need for a layer two counterpart of NAT"... while I haven't seen MAC NAT, I have seen mac-level tunneling. In a few circumstances, it does make sense for a switch to "tunnel" mac addresses inside other mac-addresses. The situation that immediately comes to mind is IEEE 802.1ah Provider Based Bridging (PBB). Typically, this is used to scale available vlans / reduce mac learning in service provider metro rings Dec 6, 2013 at 16:05
-
1@IllvilJa: Well said..! You solved a doubt which confuses me last few weeks. Few weeks ago, I thought as follows... "a router, when it deals with a WAN, tend to put its MAC address instead of a sender's MAC address(on each packet) and passes the packets to receiver. But in case of LAN, the router doesn't put its MAC address instead of a sender's MAC address(on each packet) but just passes the packets between sender and receiver" But after your explanation I've clear enough to distinguish between 'a router' & 'a switch'. Thanks again..! Apr 29, 2014 at 15:56
Rewriting the MAC address would add considerable complexity (the switch would have to know about higher level protocols like arp so it could rewrite address resoloution), would make troubleshooting harder, would prevent protocols like STP from working and would generally be a PITA. It's also not normally needed.
Which is not to say it's not possible. ebtables (the layer 2 counterpart to iptables) does have some options for MAC address translation. This can be useful if you have switches that don't use per-vlan MAC tables and you want to do some layer 2 filtering.
answered Mar 7, 2016 at 19:01
