MAC Address Assignment of ftServer® System Network Interface Adapters
 

Noah Davids
Stratus Support Engineer
Stratus Technologies

mailto:noah.davids@stratus.com

Ninety-nine percent of the time you can live in blissful ignorance of the MAC addresses on your server's network interface adapters. But when you are tracking down a problem by looking at a switch's address cache table or Ethernet traces, understanding how MAC addresses are assigned and may change is critical. This article will explain how MAC addresses are assigned to network interface adapters running on a Stratus® ftServer® system.

ftServer systems have several different network interface adapters depending on the model. However, there are two broad classes of adapters; embedded adapters and PCI adapters. The embedded adapters are housed in the core IO chassis. The PCI adapters are PCI cards that can be inserted into any of the PCI slots in either the core or expansion chassis.

MAC addresses on the PCI adapters

Each adapter has an address assigned by the factory when it is made. The first three bytes are assigned to the manufacturer by the Institute of Electrical and Electronics Engineers (IEEE). These three bytes are called the Organizationally Unique Identifier (OUI). You can search for a specific OUI at http://standards.ieee.org/regauth/oui/index.shtml. The last three bytes are assigned by the manufacturer. Typically, ports on the same adapter will have sequential values but there is no predictability when going from one adapter to another.

You can see the MAC address in the Intel® PROSet II GUI (Figure 1). Select the adapter of interest in the left hand "Network Components" tree view (1) and press the "Details…" button (2).

Figure 1 - Intel® PROSet II GUI showing MAC address of Network Interface adapter

For the Stratus® U515, U570, U571, U574 and U575 adapters, the OUI will belong to Intel, since Intel makes the cards. All the U515, U570 and U571 adapters that I have seen have an OUI of 00-03-47, while all the U574 and U575 adapters that I have seen have an OUI of 00-04-23. However, I cannot guarantee that these OUIs are consistent for all cards or that Intel will continue to use these OUIs for these cards in the future.

Note, in a teamed environment, the adapter may not be using its "Permanent Ethernet Address" (refer to the section "Effects of teaming on MAC address" later in this article).

MAC addresses on the embedded adapters

The architecture of the embedded adapters in the ftServer W Series systems has changed over time. First, there was the W Series 3200 and 3210 models which had one 10/100 embedded adapter in each IO module. These adapters both have the same MAC address, which was taken from the data in the SROM chip in the system.

Second, there are the ftServer W Series 3300, 5600, and 6600 systems. These models have one 10/100 and one 10/100/1000 embedded adapter in each core IO chassis. Next come the W Series 4300 and 4600 models with two 10/100/1000 embedded adapters in each core IO chassis. All these models use a base MAC address taken from the data in the SROM chip in the system. The first adapter (the 10/100 on the W Series 3300, 5600 and 6600) in core IO 10 is given the base address, the second adapter in core IO 10 is given the base address + 1 and the two adapters in core IO 11 are given the next two addresses.

Finally there is the ftServer W Series 2300 system. This system has one 10/100/100 embedded adapter in each core IO chassis. Again, the base address taken from data in the SROM chip is assigned to the adapter in core IO 10 and the base address + 1 is assigned to the adapter in core IO 11.

You can see this with Intel PROSet (figure 2). The 00-04-FC OUI is registered to Stratus.

Note, in a teamed environment, the adapter may not be using its "Permanent Ethernet Address" (refer to the section "Effects of teaming on MAC address" later in this article).




Figure 2 - checking on MAC address assignments of embedded adapters

Effects of teaming on MAC address

There are several types of teaming available on an ftServer W Series System (figures 3 and 4).


Figure 3 - team types using PROSet 4.01

Figure 4 - team types using PROSet 9.0.0.0

Since both embedded adapters in a W Series 3200 or 3210 have the same MAC address you MUST team the adapters. The only team type that can be selected is Adapter Fault Tolerance. For other adapters teaming is strongly recommended but not required.

When a team is created, the permanent MAC address of one of the members is selected as the team MAC address. This is the destination MAC address that other systems use when sending a frame to the ftServer system (see figure 5). This address is recorded in the registry and is used as long as the team exists - even if the adapter with that permanent MAC address is removed from the team and the ftServer system is rebooted. See, "removing a teamed adapter" later in this article for instructions on safely removing a teamed adapter

Figure 5 - The Team's MAC address

Note: All the adapters in the team may transmit packets using their own permanent MAC address, as well as the team's MAC address. Any switch port security settings should accept frames where the source MAC address is either the permanent MAC address of the adapter or the team MAC address.

To see the current MAC address as well as the permanent MAC address select an adapter (1), select the General tab (2) and then press the "Details" button (3) (see figure 6).

Figure 6 - showing current and permanent addresses

When looking at a trace, if the source MAC address is the team's MAC address, it may not be possible to determine which adapter actually sent the frame. However, you can figure it out if the team mode is "Adapter Fault Tolerance" or "Switch Fault Tolerance". In these modes only one adapter ever sends out data frames. You can determine which adapter is sending by looking at the "Packets Sent" statistics in PROSet. Only one adapter should have the "Packets Sent" count go up (see figure 7).

Figure 7 - checking the "Packets Sent" statistic

If you notice that more than one member of the team has "Packets Sent" increasing (not just non-zero, but increasing), it is probably because probes are turned on. Probes are used to test link connectivity as well as confirm that the adapters can send and receive frames. You can turn off probes by selecting the team (1), and then the advanced tab (2) and then the probe setting (3) and changing the value from Enabled to Disabled (4) (see figure 8).

Figure 8 - turning off probes

Don't forget to turn probes back on. Note on a ftServer W Series 3200 or 3210 system probes MUST NOT be enabled.

Moving a teamed adapter from one ftServer system to another

First, assume that there is a team on ftServer system A made up of adapters 1A and 2A with addresses 00-04-23-1A-1A-1A and 00-04-23-2A-2A-2A. The team's address is 00-04-23-1A-1A-1A. Adapter 1A will be moved to ftServer system B.

If you just remove the adapter from ftServer system A and insert it into ftServer system B both the team in ftServer system A and the adapter in ftServer system B will have the same MAC address. A more subtle scenario would be if you add adapter 1A into a team on ftServer system B. At that point, depending on the team mode, it may use the team's address and if probes are disabled there will not be a problem. However, if you ever change the team mode or remove the adapter from the team and create a new team, ftServer system B may select adapter 1A's permanent address as the team address.

The only way to safely move a PCI adapter from ftServer system A to ftServer system B is to:

  1. Remove the adapter from ftServer system A
  2. Change the team on ftServer system A to another mode
  3. Change the team on ftServer system A back to its original mode
  4. Install the adapter into ftServer system B.
This will force the team to find a new team MAC address. When you change the team mode, you need to completely exit out of PROSet before the change will take effect. There will be a temporary loss of network connectivity as the virtual interface created by PROSet goes off line for a brief time. You will, therefore, have two brief outages — the first when you change the team to another mode and the second when you change the team back to its original mode. You should also flush the ARP cache of hosts on the local subnet that communicate with the team's IP address, including any routers, so that they are forced to learn the new MAC address. Until the hosts on the local subnet learn the team's new MAC address, they will not be able to communicate with the team. A brief outage from the point of view of the ftServer system may look like a longer outage to these other hosts.

This is not a problem for the embedded adapters, since the permanent MAC address is based on the SROM of the system. This means that the embedded adapter of any core IO chassis placed into the system will always have the MAC addresses for that system. It is also not a problem if the PCI adapter's permanent MAC address is not being used as the team address.

Changing an ftServer backplane

If the MAC address of the embedded adapters is taken from the SROM and the SROM is part of the backplane, what happens if the backplane is replaced? Adapters not part of a team will get the new MAC address when the system is rebooted. Teamed adapters, however, will continue to use the MAC address stored in the registry. This may lead to some confusion, since the MAC address will no longer correspond to the value in the SROM chip. Unless you have an ftServer W Series 2300 system, Stratus recommends that you reset the MAC address by changing the team mode (if you haven't read the previous section read it now).

On the ftServer W Series 2300 system, the MAC address from the original system's SROM is saved to disk and copied back into the system's new SROM as part of the process to change the backplane. As a result everything matches correctly and there is no MAC address change.

The views expressed in this article are entirely those of the author(s), and should not be attributed in any manner to Stratus, or its affiliated entities. The author(s) are solely responsible for the information, material and content of this articles.

Copy & Trademark Statement