MAC


Do SFP transceivers have a MAC address or does the address belongs to the SFP port?

SFP (Small Form-factor Pluggable) transceivers do not have a MAC address. The MAC address is assigned to the network interface controller (NIC) or network adapter, which is the hardware component responsible for connecting a device to a network.

The SFP transceiver is a hot-swappable input/output device that plugs into a port on a network switch, router, or other networking devices and allows the device to transmit and receive data over fiber optic or copper cables. The SFP port to which the SFP transceiver is connected is typically assigned a unique MAC address by the device manufacturer.

Therefore, the MAC address belongs to the device’s network interface using the SFP port, not the SFP transceiver itself.


Device has MAC address X, instead of configured address Y.

Recently, we tried to take a network interface down on a VM, when we executed the command

ifdown eth0

we got the following error:

ERROR    : [/etc/sysconfig/network-scripts/ifdown-eth] Device  has MAC address 00:00:00:00:00:00
 00:45:4D:04:02:36
 00:45:4D:04:02:40, instead of configured address 00:45:4D:16:0B:29. Ignoring.

We used ifconfig eth0 to check the information on the network interfaces which resulted in the following data:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
 inet 10.1.20.115  netmask 255.255.255.0  broadcast 10.1.20.255
 inet6 fe80::215:5dff:fe01:236  prefixlen 64  scopeid 0x20<link>
 ether 00:45:4d:04:02:36  txqueuelen 1000  (Ethernet)
 RX packets 10103919  bytes 5474528935 (5.0 GiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 6541413  bytes 1190276207 (1.1 GiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

We saw that the value ether for eth0 was 00:45:4d:04:02:36, which was one of the addresses the warning mentioned that are valid.

Apparently, we had an error in the following configuration file:

/etc/sysconfig/network-scripts/ifcfg-eth0

The value for HWADDR was set to 00:45:4D:16:0B:29 which was wrong (most likely this file was copied here from another source), after we updated the value to 00:45:4d:04:02:36 we were able to use the device normally.