Operating System - OpenVMS
1748074 Members
5597 Online
108758 Solutions
New Discussion юеВ

OpenVMS network hardware addresses versus switch MAC authentication

 
Graham Allan
Advisor

OpenVMS network hardware addresses versus switch MAC authentication

We're running into an issue where we have someone trying to set up a VMS satellite node on a network where switch port access is authenticated by the MAC address (you can probably see where this is going!).

This is using OpenVMS 7.3 on some Alpha systems (either Personal Workstation or XP1000), with whatever version of DECnet matches (my own VMS knowledge is a little rusty, please forgive me) - ie phase V rather than IV. If it matters, he is using Multinet as the IP software layer.

The main cluster node (which provides the boot service) is registered on the network with its DECnet-style hardware address AA-00-04-00-xx-yy and works fine; it gets access to the network as soon as (I guess) DECnet has started.

The satellite node is registered with its hardware address, which gives it access to the network for MOP boot, but then it loses access when it changes MAC address.

Of course we have some possible workarounds at the network level - either hard-code the switch port for the satellite, or register both hardware addresses and permit two addresses per port.

But I am curious if there is any workaround possible on the VMS side? I was a little surprised to see the MAC address change taking place at all, as I thought this was only a DECnet IV thing. Can it be disabled, or is it also required for LAVC?

Thanks for any ideas!

Graham
7 REPLIES 7
Robert Gezelter
Honored Contributor

Re: OpenVMS network hardware addresses versus switch MAC authentication

Graham,

In a word: No.

The MAC Address is reset to a value computed based upon the DECnet node address. This computed MAC Address is in the form AA-00-04-00-xx-xx, where xx-xx is the 16 bit DECnet address (This address block assignment is in the original Ethernet specification, and is an allocated block of MAC addresses under the present IEEE 802.3 specification).

It is a DECnet feature, not limited to Phase IV, although it appeared with the initial release of DECnet that supported Ethernet networks.

- Bob Gezelter, http://www.rlgsc.com
Richard Stockdale
Frequent Advisor

Re: OpenVMS network hardware addresses versus switch MAC authentication

There is one other case where the MAC address is changed - if you have a LAN Failover set, LLDRIVER constructs a MAC address to represent the failover set.

Note also that an application (other than DECnet) can start up and request to use the DECnet address. I don't know if Multinet does this.

- Dick
Richard Stockdale
Frequent Advisor

Re: OpenVMS network hardware addresses versus switch MAC authentication

>>I was a little surprised to see the MAC >>address change taking place at all, as I >>thought this was only a DECnet IV thing.

So either DECnet is starting which changes the address (unless DECnet-Plus and Phase-IV address is not enabled), or some other application is changing the address. LAVC doesn't change the address.

- Dick
Graham Allan
Advisor

Re: OpenVMS network hardware addresses versus switch MAC authentication

Thank you for the feedback. I got the impression that the MAC address didn't necessarily have to change from reading one of Hoff's pages http://labs.hoffmanlabs.com/node/854 where he says:

"DECnet Phase IV (and any DECnet-Plus, DECnet-OSI, DECnet Phase V host operating in backward-compatibility with DECnet Phase IV) changes the MAC address to AA-00-04-00-lo-hi"

- my reading being that Decnet-Plus can be configured without Phase IV compatibility, so avoiding the problem? But, I don't know how to do that. Clearly having the compatibility address is the default, as the OpenVMS system I still have access to (which I probably set up 8-10 years ago) does have both hardware and physical (decnet) MAC addresses in action.

Regardless it may be easier for us to change the network side!
Hoff
Honored Contributor

Re: OpenVMS network hardware addresses versus switch MAC authentication

With DECnet-Plus, you would disable the Phase IV (NSP) transport via DECNET_REGISTER; this change (also, obviously, inherently) blocks Phase IV networking and connectivity.

In addition to DECnet Phase IV, there are other products which can be set up (requested) to be compatible with the Phase IV address change; LAT being a salient example.

MAC-based access control isn't necessarily either secure or easy to scale. Where the clients support it (and OpenVMS doesn't), RADIUS or such seemed a better approach. Here, I'd tend to authorize the ports for a particular VLAN involving OpenVMS boxes and OpenVMS LAN protocols (as these network protocols otherwise tend to get dropped by various intervening switches), and move on to other and more pressing problems.

I've added a few more links to other DECnet and LAN-related discussions in that article, FWIW.
Volker Halle
Honored Contributor

Re: OpenVMS network hardware addresses versus switch MAC authentication

Graham,

to disable DECnet-Plus changing the MAC address of the LAN interface, you need to modify the following line in NET$ROUTING_STARTUP.NCL:

SET NODE 0 ROUTING CIRCUIT CSMACD-0 ENABLE PHASEIV ADDRESS = TRUE

Change TRUE to FALSE and reboot afterwards.

The correct method to change this attribute is via @NET$CONFIGURE ADVANCED re-doing

[3] Configure Devices on this machine

and answering NO to the appropriate question on Phase IV compatible address.

Volker.
Graham Allan
Advisor

Re: OpenVMS network hardware addresses versus switch MAC authentication

Thank you everyone for all the great information.

It sounds like I can (or could) probably "fix" this at the VMS end, but I can agree with your advice that the network might be a better place to make the change (I'm not 100% certain that they won't be using LAT).

We aren't using static MAC address security, incidentally - the Procurve switches support MAC-based authentication via RADIUS, so it's akin to 802.1x but without requiring any client supplicant software. The radius response sets the port to the correct vlan, or to a guest vlan if unrecognised.

At present we limit each port to one address, but permitting two, and registering both addresses in radius, should solve the problem.

Thanks again.