Linux Storage 05 - Port security

Linux Storage Solution · Previous: FC aliases, zones and zonesets · Next: Linux HBA and SCSI inventory

Zoning says which WWNs may talk to each other. It does not say where a WWN may appear: a device that presents the right port WWN on any port of the VSAN is in the zone. Port security closes that gap by binding each WWN to the one switch interface it may log in on. This Article is the last of the three about FCSwitch1: the feature and its licence message, the two databases, the activation without learning, and the checks. The command set with its outputs is a Config document: MDS port security commands.

Why port security after zoning

As I understand it, zoning on the MDS is enforced by WWN: the switch learns the port WWN at fabric login and lets frames pass between members of a common zone, and a port WWN is something an HBA can be told to present. If someone plugs a host into a free bay and gives its HBA the WWN of HV01, the switch sees HV01 log in and gives it HV01's storage. Port security makes the switch refuse a login that does not match its database: this WWN on this interface, and nothing else on it. In an enclosure where every blade slot is a switch port and the blades are not all in the same security zone, that is what keeps a DMZ blade from being re-cabled, or re-addressed, into the datacenter VSAN. The notes do not argue the case; they do it as the natural third step after the zoning, and the argument above is mine.

The feature and the licence

In configuration mode on FCSwitch1:

$ feature port-security

ENTERPRISE_PKG license not installed. Port Security feature will be shut down after grace period of approximately 119 day(s).

Port security is part of Cisco's Enterprise package, which this switch did not have. NX-OS lets the feature run anyway for a grace period and says how long: approximately 119 days from that day. The notes stop here; what happened after the grace period, whether the licence was bought or the feature shut itself down, is not in them. A reader who finds this configuration on a switch without the licence should expect the second.

The prompt in this section of the notes reads FCwitch1(config)# throughout, not FCSwitch1. It is a typo in the notes; the switch name was set to FCSwitch1 in the base configuration and the zoning section shows it correctly.

The two databases

A port-security database belongs to a VSAN, like a zoneset. Each entry pairs a port WWN with the interface it is allowed on. The WWNs are the ones the flogi database showed logged in, so the database describes exactly the state the fabric was in. The notes write the interface names with a space, bay 1 and ext 1. In configuration mode on FCSwitch1, the port-security database vsan N line opens a sub-mode and exit leaves it:

$ port-security database vsan 11
$ pwwn 50:01:43:80:12:34:56:c0 interface bay 1
$ pwwn 50:01:43:80:12:34:56:d4 interface bay 2
$ pwwn 50:01:43:80:12:34:40:2c interface bay 5
$ pwwn 21:12:00:02:ac:00:ab:cd interface ext 1
$ exit

Seven bindings for seven logins. The 3PAR port numbers in the table are the cabling schema's; the port names themselves decode to node 1, see SCSI addressing and FC names. The storage ports are bound too, which matters as much as the servers: a device presenting the array's WWN on a bay port would otherwise be a target every server in the VSAN is zoned to.

flowchart LR
  subgraph v11["VSAN 11, port-security database"]
    w1["50:01:43:80:12:34:56:c0, HV01"] --> i1["bay1"]
    w2["50:01:43:80:12:34:56:d4, HV02"] --> i2["bay2"]
    w5["50:01:43:80:12:34:40:2c, MGMT01"] --> i5["bay5"]
    s1["21:12:00:02:ac:00:ab:cd, Storage1-C0P0"] --> x1["ext1"]
  end
  subgraph v12["VSAN 12, port-security database"]
    w3["50:01:43:80:12:34:57:90, HV03"] --> i3["bay3"]
    w4["50:01:43:80:12:34:57:92, HV04"] --> i4["bay4"]
    s2["21:11:00:02:ac:00:ab:cd, Storage1-C0P1"] --> x2["ext2"]
  end

VSAN 21 and 22 in the headings

The two step titles above the database commands in my notes say "List the WWPN identifiers that may appear on those physical ports for VSAN 21" and "for VSAN 22", while the commands under them say vsan 11 and vsan 12, and the WWNs are the ones logged into FCSwitch1. The cabling schema numbers the VSANs of the second switch 21 and 22. My inference is that the headings were copied from the notes of the second switch, where the same step was done with vsan 21 and vsan 22, and not corrected; the commands are what ran on FCSwitch1. Those second-switch notes are not in the Source material, so this is also the only trace of SW2 having been configured at all.

Activation without learning

A port-security database does nothing until it is activated for its VSAN. The command has an option that decides what kind of security one gets, and the notes mark the point with three exclamation marks on each side of the word "note": when we do not want to leave the switch in learning, non-intrusive mode, we must not forget the keyword no-auto-learn. In configuration mode on FCSwitch1:

$ port-security activate vsan 11 no-auto-learn
$ port-security activate vsan 12 no-auto-learn

As I understand the feature, with auto-learning on the switch adds every device that logs in to the active database instead of refusing it; that is the mode for discovering what is there, and it protects against nothing until learning is switched off. no-auto-learn activates the database as written and refuses everything not in it. The author's warning is the whole point of the Article: the command without the keyword looks the same, reports "activated database" the same, and secures nothing.

The checks

Four show commands follow, all from configuration mode on FCSwitch1. The configured database for VSAN 11 and the active database for VSAN 11 list the same four rows; the active one has a Learnt column, empty, because nothing was learnt:

$ sh port-security database active vsan 11

--------------------------------------------------------------------------------
VSAN Logging-in Entity             Logging-in Point       (Interface)     Learnt
--------------------------------------------------------------------------------
11   50:01:43:80:12:34:56:c0(pwwn) 20:0d:54:7f:ee:ab:cd:18(bay1)*
11   50:01:43:80:12:34:56:d4(pwwn) 20:0f:54:7f:ee:ab:cd:18(bay2)*
11   50:01:43:80:12:34:40:2c(pwwn) 20:05:54:7f:ee:ab:cd:18(bay5)*
11   21:12:00:02:ac:00:ab:cd(pwwn) 20:15:54:7f:ee:ab:cd:18(ext1)*
[Total 4 entries]

The Logging-in Point column is new information. The database was typed with interface names, and the switch prints each interface as a WWN with the interface name in brackets: 20:0d:54:7f:ee:ab:cd:18(bay1), 20:0f:54:7f:ee:ab:cd:18(bay2), 20:05:54:7f:ee:ab:cd:18(bay5) and 20:15:54:7f:ee:ab:cd:18(ext1). The listing pairs each with its interface name; I read them as the WWNs of the switch ports themselves (fWWNs), but the notes do not say, and how they are formed the notes do not say either, beyond what the eye sees: the last six bytes are those of the switch WWN 20:00:54:7f:ee:ab:cd:18 that the old interface-based zones used. The * after each row is not explained in the notes either; as I read the command, it marks an entry whose device is logged in.

Fabric Distribution Disabled means, as I understand it, that the database is not distributed to other switches over Cisco Fabric Services, which is right for a fabric with one switch in it. No Session means no configuration session is open. VSAN 1 is the default VSAN that every port starts in; it has no interfaces here and no database. The notes check the databases of VSAN 11 only; for VSAN 12 the evidence is the one line in the all-VSAN status.

What is missing

The notes end with the status check. There is no test of the feature: no blade moved to another bay, no WWN changed, no line in sh port-security violations ever. There is nothing about the licence afterwards, nothing about saving the configuration, and nothing about port security on SW2 beyond the two headings discussed above. The Linux side, which the next Article turns to, does not know that any of this exists: an HBA whose login is refused by port security would simply see no fabric.

Today

Checked against the MDS NX-OS 9.4(5a) guides: the port-security commands and the show outputs of this Article are unchanged, down to the no-auto-learn keyword and the "Fabric Distribution Disabled" line. The licence is where things moved. The feature "requires the advantage or premier tiers license, previously known as ENTERPRISE_PKG license", the traditional per-switch licences reached end of sale on 4 October 2025 with a last date of support of 31 October 2028, and the grace period is still documented as 120 days, after which the switch "automatically disables the feature and removes the configuration". That last clause is what the notes could not know: if no licence followed, the seven bindings removed themselves about four months after they were typed, and the switch went back to zoning alone. The companion feature, fabric binding, which ties the switches of a fabric to each other rather than devices to ports, needs the same licence tiers for open-systems VSANs.

What I would do differently

Buy the licence or not enable the feature. A security control with a known expiry date of about four months, and no note of what was done about it, is the kind of thing that is found by accident a year later, either as a feature that silently stopped or as a syslog message nobody read. And I would run one violation on purpose, with a spare blade in a spare bay, to see the refusal and the violations row once before relying on it.