Hi all!
Wondering if we can briefly validate/discuss about ArubaOS-CX's configuration good practices when an interface is going to be used as access (used to connect an host, as example) or as trunk (used to connect a peer 3rd party switch, as example).
From what I was able to understand an interface 1/1/<n> (or a Layer 2 VSX-LAG or Standard-LAG) connected to an edge Host would probably have a configuration similar to this one:
interface 1/1/<n>
no shutdown
mtu 9198
description "Link-to-Edge-Host"
no routing
vlan access <vlan-id>
loop-protect
spanning-tree bpdu-guard [1]
spanning-tree port-type admin-edge [2]
spanning-tree tcn-guard [3]
exit
[1] the spanning-tree bpdu-guard enables the BPDU guard on the switch interface. When BPDU guard is enabled, interfaces receiving MSTP BPDUs remain disabled.
[2] the spanning-tree port-type admin-edge specifies the port type as administrative edge. During spanning tree establishment, ports with admin-edge enabled transition immediately to the forwarding state.
[3] the spanning-tree tcn-guard disables propagation of topology change notifications (TCNs) to other STP ports. Use this when you do not want topology changes to be noticed by peer devices.
The same interface configured in trunk mode (used to connect a peer 3rd party switch, as example) would be probably configure as:
interface 1/1/<n>
no shutdown
no routing
mtu 9198
flow-control rx
!actual flow-control none
description "Link-to-Remote-Switch"
vlan trunk native <vlan-id> tag [4]
vlan trunk allowed <vlan-id> [5]
spanning-tree link-type point-to-point [6]
spanning-tree ignore-pvid-inconsistency enable [7]
exit
[4] the vlan trunk native <vlan-id> tag enables tagging on native VLAN id <vlan-id>.
[5] the vlan trunk allowed <vlan-id> is used to specify exactly and only VLAN id <vland-id> as permitted. Eventually vlan trunk allowed all will allow instead all possible VLAN ids.
[6] the spanning-tree link-type point-to-point sets the spanning tree link type as point-to-point. Use this for full-duplex ports that provide a point-to-point link to devices such as a switch, bridge, or end-node. That's default.
[7] the spanning-tree ignore-pvid-inconsistency enable shouldn't be necessary if other end's port permits tagged only traffic (no untagged traffic will flow).
Clearly spanning-tree relevant configuration (and loop protect too) depend on other parameters set globally (e.g. spanning-tree needs to be enabled or, as examples, the loop-protect action tx-rx-disable - which is default - and loop-protect re-enable-timer 3600 or the like).
I've some doubts with regard to the best approach to follow in configuring an interface in trunk mode (access looks quite simple) from the VLAN tagging standpoint...I mean if a standalone/VSX ArubaOS-CX switch needs to be connected to a 3rd party switch using Layer 2, will:
vlan trunk native <vlan-id> tag
vlan trunk allowed <vlan-id>
simply require that the other end peer interface is configured to be a tagged member of VLAN id <vlan-id> (to use a ProCurve jargon) only to work?
Or - instead - will be better (or more common, less unusual) to avoid requesting that Native VLAN as tagged and also allow all VLAN ids on the trunk instead of exactly specifying one ore more VLAN ids?
As example:
vlan trunk native <vlan-id>
vlan trunk allowed all
I feel silly to ask those questions but experts opinions would be great to hear.