MAC Addresses Changes with Mode

Products PMP
1

So it recently occurred to me (troubleshooting a bizarre issue) that for some bizarre reason the first octet of MAC addresses changes on the PMP product line depending on what mode you have it running in.

This is extremely inconvenient, and I’m not aware of any other vendor that operates this way.

The biggest problem comes in that:

  • The NAT MAC is not shown on the packaging (for scanning into inventory/stock)
    AND
  • The Web GUI continues to show the bridge MAC even when you’re using the NAT mode, causing confusion to the end user.

What is the reason that the MAC on the RF interface changes, vs just staying the same in modes, and why does the MAC shown in the GUI not update depending on mode being used?

If no other explanation for anything can be given, can we at least get the NAT MAC and bar code on the outside of the box?

2

What specific product are you referring to? Do you have a model number?

3

I was told this is the case across the board with the PMP product line, but specifically it’s the PMP 450b in 3GHz.

4

This has been a way that PMP MAC allocation has worked from the early days of Canopy. There are some historical compatibility reasons for it, but one of the main reasons and benefits is that it allows us to limit consumption of the MAC address pool and add additional interfaces with software upgrades without having to over-allocate finite MAC addresses.

This product line has always used the locally administered bit in the OUI and we derive additional MAC addresses for other interfaces from that OUI. This allows us to limit our consumption of the MAC address pool. The base MAC you would see on a web page and on the sticker (0a-00-3e based) reflects the MAC address of the ethernet interface. This is true for any device at all times and is a main identifier of a device.

From this base MAC address we derive other addresses as the configuration demands. This is most entirely on the SM as the AP really only supports 2 interfaces, the Ethernet (0a-00-3e), and a “private RF” (1a-00-3e), which is used for internal AP - SM communication as well as for proxy traffic.

On an SM, out of the box, the SM is not manageable from the “public” (upstream, RF) side of the system. To allow this, you have to enable “Public Accessibility” on the SM, at which point the SM’s 0a-00-3e interface will be accessible from both Public (upstream/RF side) and Private (downstream/Ethernet) side of the device. This is for bridged mode operation.

When you enable NAT, we now have a situation where we have to isolate the Ethernet/Private side interface from the RF/Public side of the device which requires an additional MAC address. As stated before, we are able to do this by deriving another MAC address from our base MAC and since 1a was used for internal RF-RF communications, 2a is used for NAT WAN.

Additionally, we also have the ability to either manage the SM via NAT WAN interface itself (2a), or, setup a separate management interface which can have a management VLAN, which would use a 3a based address. And finally (at this point), if PPPoE is enabled, we have yet another interface to terminate at the SM (the PPPoE link), and so we use 4a for that interface.

To your question as to why the MAC on the webpage doesn’t change based on mode, the answer is because that 0a based mac is always in use and is a serial number of the device.

This is a summary of how the 0a-00-3e base address is used:

0a - base ethernet address for management of AP and SM. For SM in Private Accessibility mode this only works on the RJ-45 physical side of the device. For AP, this will work from either side of the device.
1a - used for internal RF-RF private communications, not accessible from external interfaces.
2a - used when NAT is enabled on the SM for NAT WAN user data. Can be configured to also be used for SM device management
3a - Used when NAT is enabled on the SM for SM device management traffic when NAT WAN management is not enabled. Allows for separation of device management traffic from user traffic
4a - Used when PPPoE is enabled for the PPPoE end point termination - takes the place of 2a in this configuration scenario

5

Hello,
I understand all of that… but for anyone who runs the radios in NAT mode this causes massive inventory and management headaches, since the NAT MAC is not on the box to scan in but is the MAC that’s used for authentication on the RF side.

Other vendors have 2 MAC addresses. One for wireless side and one for radio side. Doesn’t matter what mode you put it in. If you put it in bridge mode it uses the one MAC on the box. If you put it in NAT/Route mode it uses the MAC on the box on the RF side and uses a different one on the inside.

For example, why is 4a needed? Why not just have the external MAC be 2a regardless of configuration?

6

We can look at adding this as maybe a feature for configuration option to use the base MAC address on a desired interface, since it really wouldn’t matter to swap where 0a and 2a are used. But at this point, there is alot of backward compatibility concerns and in-the-field history with our current approach. When we added PPPoE around 15 years ago, we wanted to keep it distinguished from being standard NAT WAN interface for both internal code isolation reasons as well as for any customer that may have already had setup systems assuming the 2a address meant standard NAT WAN L3 interface. I don’t recall much more specific than that as to why that decision was made back then.

7

That makes some sense.

Honestly I would be OK with either solution:

A) Being able to select which MAC address is used (in a way that configuration files can be uploaded to a SM for mass configuration and have it properly select). If this is an option, and can allow current deployments to remain as is this would be fine too, I think? Does this need to get submitted as a formal feature request somewhere?

B) Just having the NAT MAC on the side of the box with a barcode to be able to be scanned.

8

It is very unlikely we’ll do the label approach - not alot of room on some of the newer devices’ labels. But we can look at the A) option. But there will always be a chicken and egg scenario as you have to configure the device to enable NAT in the first place. But if you are using something like Installation Color Code and/or DHCP option 66 to deliver a configuration file, this configuration could come along at the same time as enabling NAT.

For submitting feature request, I have it captured here. Thanks for reaching out!

9

OK… Yes ultimately, that would work well – so long as the MAC we see on the wire (past the AP) is the MAC we scan in from the side of the box.