In a particular multi-tenant filesystem configuration, I vary the sptlrpc security flavour by LNET network using per-network srpc.flavor rules: skn set for default, so that all dynamically created LNET networks require authentication, but the admin-only network (tcp0) set to null so admin / server-as-client mounts on the private admin-only network don't require a key.

For example:

# enforce shared-key on all networks by default...
lctl conf_param testfs.srpc.flavor.default.cli2mdt=skn
# ...but carve the backbone (tcp0) back to null
lctl conf_param testfs.srpc.flavor.tcp.cli2mdt=null

The MGS shows both rules as configured:

# lctl get_param -n mgs.MGS.live.testfs | grep srpc.flavor
  srpc.flavor.default.cli2mdt=skn
  srpc.flavor.tcp.cli2mdt=null 

But a client whose MDT connections runs over tcp0 }}still negotiates {{{}skn, so a keyless mount fails:

# mount -t lustre 192.168.0.10@tcp:/testfs /mnt/testfs
mount.lustre: ... Required key not available

If I configure a key, I can see the negotiated connection uses skn

# lctl get_param -n mdc.testfs-MDT0000-mdc-*.srpc_info | grep 'rpc flavor'  rpc flavor:  skn          <-- expected null; the tcp rule was ignored 

Deleting the default rule makes the same connection fall back to null, confirming it is the per-network rule being ignored — not a parse or precedence problem.

The failure is symmetric, and the other direction is the more serious one — a per-network rule that raises the flavour above the default also has no effect.

# enforce shared-key on one tenant network only, no global default
lctl conf_param testfs.srpc.flavor.tcp1.cli2mdt=skn

A client on tcp1 connects with null and no error is logged. An operator scoping skn per-tenant-network may believes those networks are authenticated when they are not.